“If I Guess How Much You Have In Contingency, Can I Keep It?”

 

One of the things that strike me as exceedingly weird about the way Change Control is currently practiced has to do with the establishment and use of a project’s Contingency Budget, or reserve. This is the amount that is “set aside” for “risk events,” and is tapped whenever said “risk events” take place. Already tired of my using quotation marks to signal the phrase “so-called”? I’m just getting warmed up.

So, how do these Contingency Budgets come into being in the first place? Well, they’re typically created after a thorough risk analysis has been performed on the cost, schedule, and scope baselines, including in-depth use of Monte Carlo and Decision-Tree Analysis techniques, and calculated to an 80% confidence interval through expert usage of the rules of probability. In other words, they’re pulled out of thin air, anywhere between a 5 to 15% flat rate.

As the project gets underway, the next phase of decision-making in the Change Control arena has to do with what “unexpected” things happen as the scope is pursued. In order to maintain discipline in the process used to change the cost, scope, or schedule baselines, a standard rule is that you can’t change one of these baselines without changing the other two. So, when a Baseline Change Proposal is issued to do just that, highly-trained experts will describe in detail what ought to be altered in the scope baseline first, and its ramifications for cost and schedule. This complete and even-handed assessment then goes to a Baseline Change Control Board, or BCCB, where its particulars are scrutinized prior to approval and implementation. In short, millions of dollars are removed from the contingency reserve based on hastily-assembled verbiage that contains syntax errors that would flunk a 7^th grade essay, in order to re-align the cost baseline, coincidently enough, to the exact amount of the cumulative negative cost variance, and everybody’s supposed to be okay with that.

As the Contingency Budget nears its exhaustion point, the BCPs being placed before the BCCB undergo higher levels of scrutiny, particularly in those instances where the cumulative percent complete for the project is below half-way. Here is where the risk managers (finally!) begin to earn their pay, since, if the “event” that is driving the “request” happened to be included in the initial risk analysis, some claim of “I told you customers that this might happen!” suddenly becomes the legitimate basis for increasing the project’s overall budget. After carefully considering the original risk analysis, and taking into account several project management axioms such as “things change,” the BCP is approved, and the Contingency Budget moves ever closer to extinction, even as the cumulative cost variance is, once again, reset to zero.

Once the project nears completion, and the Contingency Budget is all but gone, “changes” are harder to “manage.” Should a meteor strike the project site, Godzilla himself wreck catastrophe, or a key supplier’s rates suddenly escalate (all equal events, save that one is perfectly predictable), the onus now falls on the previously-confident customer, who is placed in a most unfortunate position: pony up more funds, or see the project stall in-place, with nothing to show for it. Any attempt from the customer to pinpoint what should have taken place in baseline change space previously is pretty much futile (well, maybe not for the first two instances, but stay with me), since any forensic analysis – say, that the contractor shouldn’t have chewed up the Contingency Budget already on suspect grounds – almost always points to the customer being asleep at the BCCB switch.

So, going all the way back to the initial stages of the project, the question simply must be asked: for all of the baseline development, risk analysis, and baseline change negotiations that have taken place, wouldn’t a straight-up answer to the question in the title have saved a lot of money, time, and energy?