Difference Between Project Contingency and Re-baselining
By Vjekoslav Babić
I’ve seen a few projects where customers said they didn’t need contingency, because they decided to adjust the budget as changes happen.
How does this sound to you?
To me, this sounds pretty bad, because there is an important distinction between adjusting the budget based on change requests and consuming the contingency reserve.
Let’s start with the project budget. After most planning activities have been completed, after all project activities have been defined and estimated, and after the resources have been assigned to the activities, you create the project budget.
After you define the budget, you create the cost baseline. Cost baseline is the approved plan for project costs at any given point in time, and it reflects the how much the project is expected to cost at that specific point.
Baseline is useful when determining the success of a project, because any difference between the actual costs and cost baseline tell you how much above or below budget your project went.
However, budget is not the Holy Scripture. Once it has been defined, it can easily change.
Let’s take a look at house building project, it’s easy to imagine. You approve the plans, define activities and resources, and establish the budget at $200,000. Then half way into the project your customer changes their mind about the house and decides to have two additional balconies. A typical example of a change request. You change the plans, and adjust the project budget by additional $40,000.
This is an example of re-baselining. After you get a change request which affects the project budget, you need to establish a new baseline. Imagine that after approving the change request for two balconies you didn’t adjust the budget by the additional $40K. Your house would cost $240,000 and your estimated costs were $200,000. Your customer can easily complain that you trampled over the budget. If you did the rebaselining after accepting the change request, your new budget is $240,000 and if that’s how your house ends up costing your customer, you have done it within the budget.
But, when your windows are ready to be installed, the truck delivering them crashes in an accident, destroying all the windows. You order another shipment, causing you extra $15,000 in costs. Since your customer didn’t “order” the windows to be broken in the accident, they can’t be expected to bear any extra costs related to that accident. In the end, your house ends up costing $215,000 instead of $200,000. If you didn’t have a contingency reserve – this extra money comes out of your pocket.
Contingency reserve is used to cover for known unknowns. You know that something might go wrong, but you don’t know what and when, and you want to be prepared for these events. These events might cause you time delays or budget overruns, so you need to include them into the baseline in order to be able to cope with them if (or better yet, when) they occur. If they happen, they don’t justify a change in budget, because they don’t change the scope; they are just events which interfere with the project execution, causing you unplanned trouble.
Change requests are different. They change the scope, so they have to change the budget. If you just say at the beginning of your project that you are going to address the changes as they occur – of course you are! How else would you handle them? But still, handling change has nothing to do with having contingency – you still need it, or else you’ll face serious trouble when the unknown occurs, and you know it will occur, don’t you?
Vjekoslav Babić is an ERP consultant with ten years experience in the IT industry and six years experience delivering project success on large-scale, high-risk, and international implementations of Microsoft Dynamics ERP solutions. He has project experience in various industries, including telecommunications, insurance, pharmaceuticals, industrial gasses, chemicals, food and beverage, manufacturing, printing, distribution, and retail. He is a PMI certified Project Management Professional, a Microsoft Certified Trainer and holds a number of Microsoft technical certifications. He co-authored the book “Implementing Microsoft Dynamics NAV 2009”, published more than forty articles on business solutions, software development, database design, and internet technologies. He is the author of the NAV Insights column and an Editorial Advisory Board member with MSDynamicsWorld.com, and he frequently writes about Microsoft Dynamics implementation methodologies and project management topics on his blog http://NavigateIntoSuccess.com/. Based in Zagreb, Croatia, he is employed as a consultant at Microsoft.
No comments yet.