If projects were completely predictable, there would be no need for risk management. Everything could be planned and executed according to plan. However, we know better. Unexpected things happen, disrupt the original plans and cause time and cost overruns. In IT projects, these overruns are far too common to be ignored.
How do you handle unexpected events which cause your schedule to extend or your project to cost more? If you hope to address such events as they happen, you must expect to either spend unallocated funds, or to give up on quality. Neither choice is too good: spending unplanned funds is frowned upon by project sponsors, and sacrificing quality to mitigate unexpected overruns is always bad.
To address situations such as these, you need to allocate special funds called contingency reserve.
Contingency reserve are funds allocated above the project budget, which are intended to be used when unexpected events occur, to reduce the risks of cost overruns. It cannot account for everything unexpected in a way to cover any unexpected costs, but a properly created contingency reserve should be able to help a project go smoothly even when costs go over budget.
One way to define a good contingency reserve is through risk management processes. First, you need to identify the risks which can result in cost overruns. Then you need to qualify the risks to identify the most critical ones, or those worth focusing on. Finally, you need to quantify those risks and express them in terms of financial impact on project budget and probability of their occurrence. The product of impact and probability is a monetary value called exposure.
Exposure isn’t the amount of money that the realized risk event is going to cost you if it occurs. If the risk event occurs, it should cost you the amount of money you determined to be the impact of the risk. However, if you have twenty possible risks, each having its specific impact and probability, the total sum of exposure of all those risks should suffice to cover for any risks that are realized. Statistically, not all risks are going to happen, but some of them most likely will. Probability that all risk events are going to happen is statistically equal to the product of all probabilities, making it extremely unlikely that all of them will happen.
To define a good contingency, you simply sum all exposures: the result is amount of funds you need to set aside to be used whenever something unplanned or unexpected happens. Since contingency is sum of exposures, and probability of all risks occurring is the product of all risk probabilities, statistically a contingency reserve defined in this way should do for majority of projects.
Let’s see how projects work with and without contingency.
Imagine you had $100K budget to build a house. A delivery trucks has an accident, losing you $10K in building material.
Without contingency, you don’t have extra $10K to finance this loss, and the only way to get the loss compensated and get project on track is to reduce the quality by cutting costs somewhere else on the project, such as choosing lower quality materials, or using less material than required or something of the sort.
With contingency, you have extra funds available to you specifically for such occasions. So, you simply tap into contingency reserve funds, and finance those extra $10K, get the needed materials and stay on track. Quality stays unaffected, because you don’t need to compensate for anything, and you don’t need to cut costs anywhere.
Contingency is necessary on any project which is likely to exceed its allocated budget, and IT projects are very likely to do so. With such reserves you can execute your projects smoothly, without panic when (not if, when) risk events occur and cause budget overruns.
In my next post I’ll explain the difference between contingency consumption and budget re-baselining, which I’ve seen confused many times in practice by both customers, and consultants.
{ 1 trackback }
{ 0 comments… add one now }