Change Control Anomalies Baked Into The PM Cake

 

Buckle up, GTIM Nation. I’m about to take you on a series of mental exercises that may very well change your perceptions about change control/change agency (ProjectManagement.com’s theme for December), a concept central to virtually all medium-to-large projects. Proper management of the change control process is often key to project success, and I intend to show it in a rather novel light.

First stop: why do we even need change control? The obvious answer is because the project in question isn’t proceeding according to plan. Of course, no project goes entirely according to plan, but we don’t convene an emergency meeting of the Baseline Change Control Board each time the PM has to take an unplanned afternoon off to see the dentist. A change has to be significant to justify initiating the Change Control process, right? The real question then becomes, how big of a change are we talking? Consider the following graph:

The dotted line represents the original cost, scope, and schedule baseline. The dashed lines show the inherent flexibility in the baseline – it’s how much scope, cost, or schedule can deviate before some adjustment to the baseline is deemed necessary. Finally, we have the solid line, showing the actual experience of the Project Team. Note how, while October is within the bracket for determining the necessity of changing the baseline, starting in November the Project rides the upper bracket until February, where it exceeds the upper limit. Within this metaphor the BCCB would need to process a Baseline Change Proposal in its March meeting. But, as fate would have it, progress snaps back to being consistent with the baseline in April, and continues within acceptable limits to Project completion. There was no way that the March BCCB could have known beforehand that this would end up being the case and, in any event, they didn’t change the baseline for whatever reasons. Now consider this graph of the same project:

Alert GTIM Nation members will readily perceive that the only changes have to do with the values of the upper and lower limits of the brackets where the Change Control function would be invoked. In other words, this plan was robust enough to handle larger fluctuations in scope, cost, and schedule when compared to the first example.

So, what about a baseline leads it to be more robust, or at least less brittle? Note that nothing in the risk managers’ (no upper case) bag of tricks set of techniques could expand the tolerance brackets in the above graphs. The risk analysis document, reduced to its core, is basically a list of things that could happen to a project that would lead to the Team laying claim to additional budget, whether that budget has been funded or not, under the rubric that such events had been predicted and somewhat quantified. Indeed, the more extensive the risk analysis, the more the original baseline should be considered intolerant of the changes that will inevitably occur during project execution. To be fair, for any project awarded on a competitive basis (the majority of them, presumably) there is going to be Marianas Trench-levels of pressure to prepare a Basis of Estimate that meets the bare minimum of the Request for Proposal’s scope requirements, since most winning bids are also the lowest ones. This being the case, even bad weather events (for construction projects, among others) can and do receive their own line item in the contingency budget estimate.

On the other side of this strange little change control phenomena is one of the deadliest project influencers, scope creep. If bad weather makes an appearance in the risk management plan (no initial caps) due to its capacity for inducing delays and overruns, how much more so would the stripped-to-its-core cost or schedule baseline be harmed by the introduction of non-aligned additional scope? I would go so far as to assert that the propensity of certain customers to request some additional capability or detail that wasn’t in any of the scope baseline documents points to an assumption that the original baseline was fairly robust in the first place, not in need of additional budget or time for “just” this one little addition (I wonder how many instances of scope creep would be eliminated if the word “just” was prohibited at project review meetings).

All of which points to a couple of observations about the whole Change Control process, specifically that the more the original cost/schedule baseline is intolerant of nominal performance deviations, the greater the need for a Baseline Change Control Board, and that these are a natural result of the competitive bid process, particularly when the lowest bid that appears to be able to meet the scope requirement(s) is all but guaranteed the win.

Interestingly, Firm Fixed Price contracts are largely immune to the anomalies of BCCBs, or the basis of the Contingency Budget, or the documents associated with risk management, but that’s a topic for another blog.