In the last couple of articles I have covered earned value and work breakdown structures. In my discussions about earned value I have talked about the need to have a budget on work-pack level and I have stated this as if it was self-explanatory. As anyone who has done any work with budgets knows (either from making them, or from controlling them) there are as many ways to do budgets as there are people. While I don't believe there is a single right way of making budgets, there are a number of wrong ways to do it.
In this article I will discuss some of the key elements I think are needed to make a good budget, and how they can be achieved from the controllers point of view.
First off I will start by looking at what a budget is; it is, simply put, a plan for how the economy (or the schedule) of the project should progress. Therefore the plan should be detailed enough for us to follow-up on during the project. A budget with only a total cost on it is as useful as a planned route with only the destination. A good budget will include the expected cost for the activities, broken down to the same level as the goals are (which should be work-pack level, but no further). This will allow the controller to follow-up on cost development for each activity and hopefully detect deviations much sooner.
If we return to the 'planned route' metaphor, we can easily imagine the difference between the two types of planning. The first kind, with only and end destination doesn't allow you to see if you took a wrong turn along the route. Either you get to your goal or you don't. If you planned the route out in smaller steps, you would find out much sooner if you deviated from the planned route, and you would be able to pin-point where on the route the deviation occurred.
So a budget should be sufficiently detailed to allow you to follow-up on the planned activities separately during the project. I also stated that the project shouldn't be more detailed than what you plan to follow-up on. The reason for this should be quite straightforward; there is no value in spending your time over-planning the activities, and certainly not if the planning isn't used for anything afterwards. Project managers tend to look unkindly on controllers who asked for detailed planning and then just threw it away afterwards.
Now that we have covered a bit about what a budget is, and the level of detail that should go into the budget, it's time to cover how this can be done. In some companies, the project organisation is extremely competent at making budgets and execute the discipline almost perfectly. Unfortunately these are far from the majority, and my experience is that the project managers does not deliver a budget that is more detailed than what they are asked to deliver. As I said, I believe a key component in successful controlling is a good budget, and achieving this often means having to change the way the project organisation delivers a budget. My experience is that if you want them to deliver a good result, you have to be specific and you have to explain yourself.
My experience with technical organisations is that they actually do want to deliver the best possible piece of work, but if you give them a list of seemingly arbitrary things their budgets should include, they won't feel a sense of involvement. If you take the time to explain why these things are needed, and what you use them for, then there will be a much greater understanding, and they won't be nearly as reluctant to do them when making a budget. Being specific, is also very important. Firstly because what might seem obvious or straightforward to a controller, might be something completely different for a technical project manager. Secondly, being as specific as possible will give the project managers a much greater idea about what they are asked to deliver, and the more people know what is asked of them, the more willing they are to do it.
What I have found to be a very effective way is make a template, with a list of the the things they need to input (for instance asking them to list the work-packs on the lowest level of the hierarchy and their associated budget).
If you experience that project managers often are unaware of certain costs always associated with the project, this might also be a good place to include those as well. An example from a previous workplace was that almost all projects included off-shore installation, but the project managers rarely included the costs for helicopter flights offshore and the price for a accomodation on the offshore installation. The reason was that these costs were added automatically to the projects, and the PM didn't know how to price it in the budget.
The last thing I am going to cover is contingency. Every project, without exception, should include a contingency for unforeseen events. I will go into much greater detail in a later article about how and why this contingency should be included, but for now it is merely important to know, as a controller, that the project need have an added cost in the budget, which represents an estimate of the unforeseen costs. There are a lot of different ways to calculate the appropriate size of the contingency, but a quick-and-dirty way of doing it, is merely to include a percentage added on top. Later I will discuss why this is far from the best solution, but it is still better than not including a contingency. Especially when keeping an eye on business cases (and NPV calculations) and when the budgets (and forecasts) are used in cash-flow calculations. A final word, in this article, on contingency is that it should always (always!) be presented separately and not included in the individual costs for the work-packs.
The last thing to remember is that a budget is just a budget. It's not a strict manuscript that the project must follow at all cost. There is a saying, that no plan survives contact with the enemy. Even fewer budgets survive contact with the real world. The role of the controller (in my opinion) is not to enforce the budget, but rather to be able to foresee if the project is going to deviate from the budget, estimate the size of the deviation, and present this information to the project owners, so that they can decide which, if any, action is needed.
No comments:
Post a Comment