Better Project Cost Planning and Project Cost Control with SAP
I sent a colleague of mine this link recently in connection with a discussion we were having on project budgeting.
It’s very difficult to pick a start point in this ‘Mandelbrot’- and it’s sometimes like that for project budgeting. If you are an SAP customer it’s important to have a ‘start point’ in the process as this will help you decide which of the tools delivered by SAP will best meet your requirements.
Let’s look at internal projects (customer projects have a revenue leg which just confuses the discussion at this stage – the principle is the same) – maybe R&D projects or six-sigma projects would be good examples. There are two main areas I’ll talk about in this blog, firstly the planning of the project and secondly the execution of the project. There are some critical questions to ask concerning both of these areas, the answers to which will help you get to a stating point in designing a robust cost planning and tracking process.
Does the organisation do top-down or bottom-up planning? Do you plan your costs at the WBS level, and distribute a lump sum across the duration of the WBS (top-down) or do you plan down to hours and dollars per day, and then roll this up to the WBS level (bottom-up)? There is no reason an organisation can’t do both. Or indeed plan at different levels in a single project. For example you may allocate a lump sum to the ‘Planning ‘stage of a project, while doing cost planning at a lower level for the execution phase. It is not an either or choice but you have to be able to give your project managers clear guidance on the options and which to use in which case. This guidance is not meant to be restrictive but to ensure that subsequent processing of the project is as smooth as possible. As an example we could say that all WBS elements that the Project Manager expects to be less than $50k don’t need detailed planning. Another guidance statement could be: All projects with a start date less than a year into the future need detail planning. This allows Project Manager and budget seekers to get budget allocated but not have to do the detailed planning.
So what happens on execution of the project? The level of planning chosen initially determines what can be reported on during the execution of the project. If your planning is done at a high level, on WBS elements, as a lump sum, then the progress of the WBS element can only be done by time or total costs. You’d not be able to use effort as a determinant of percentage of completion (POC). If lower level planning is done on the project then effort, as the number of hours expected to be done and then compared to the actual hours can be used to determine percentage of completion. During the execution of the project it is often a requirement to be able to check budget availability during the project. The decision here, when using SAP tools (RPM or Investment Management), is whether or not you need ‘real-time’ checking of funds available, or whether reporting on planned costs against actual costs is a sufficient control. Many organisations, initially at least, select real-time budget control, i.e. a transaction (purchase order, time confirmation, etc) is stopped if funds are not available. While this might seem appealing initially, what does the organisation do when this happens? Stop the project? Usually not (although there may be cases where you want this to happen) so reporting, perhaps with an e-mail sent if a budget is exceeded is a often a more pragmatic solution.
As you look at your SAP supported project cost planning processes a good starting point is to decide when you do top-down and when you do bottom-up cost planning and, once planned and started, how you control the actual costs flowing against the project. These decisions will be a good framework on which to build better project cost management processes.