It’s Time To Play … The Contingency Game!

 

GTIM Nation knows of my low regard for risk management (no initial caps) analysis as a source for reliable management information. The one area, though, where it might be of some use is in the creation of a Contingency Budget for projects that have been negotiated as a Cost Plus-type contract. This type of contract is normally used for projects that involve a significant degree of risk, typically due to being performed at a venue where personal and materiel security can’t be guaranteed, or else due to the incorporation of new technology, truly novel scope, or some combination of these. Due to this inherent level of uncertainty, many project sponsors will allow for the development of a Contingency Budget, for work that is definitely in-scope, but isn’t in any of the baselines.

Ah, but there’s the rub: what, exactly, is in-scope, uncosted? This question is the very essence, the raison d’être of the whole Baseline Change Control process. For if there was an easy litmus test for which requests for additional budget were legitimate, and which were based on poor performance (and should therefore be rejected), then it wouldn’t take a multi-member Baseline Change Control Board to micro-evaluate each and every Baseline Change Proposal (BCP), deliberate it, and hand down a determination days (or even weeks) later. Such a litmus test could have conceivably prevented the entire Agile/Scrum Project Management theory codex from coming into existence, since its main purpose was to streamline configuration management in such a way as to keep BCCBs from delaying needed changes to software projects’ baselines that had to happen in the very near-term in order to prevent IT project failure.

Alas, such a litmus test does not exist, requiring the now-elaborate processes embedded in the Baseline Change Control Board charter to ensure the funding of true contingency events, the exclusion of false ones, and an equitable treatment of the in-between events. These processes are highly resistant to formulaic remedies and, due to this chaotic aspect, begin to assume the characteristics of some grand game. For example, a common assertion from the risk management (no initial caps) crowd is that, if an uncosted event occurs, and it was described in detail in that Project’s risk register, then the approval of the Contingency BCP should be somewhat automatic. However, if a true contingency event has happened, but it was not documented as a possibility, then the risk managers’ strategy with respect to the role of the risk register has to change, from being an adequate tool that captures potential risk events, to a document that only addresses some of the things that might happen, and we just missed this one, don’t you know. It’s the risk managers’ version of the heads-I-win, tails-you-lose trick, rephrased as “If it happens, and it’s in the risk register, it’s automatically a legit contingency event; but, if it’s not, it still might be a contingency event, we just need more time to tell you why.”

Then we have the very real possibility that either the customer or the PM may act in a way that would allow only one of them to win this game, as depicted in the following Payoff Grid:

Scenarios (B) and (C) depict the BCCB functioning as it should. Savvy customer oversight management will be on the lookout for Scenario (D), in order to prevent a “get well” BCP from getting through the process, and covering the costs of poor performance, a bad initial estimate, PM-initiated scope creep, or any of the other drivers of project overruns and delays. Conversely, PMs will work to prevent Scenario (A) from unfolding, which would lead to the contractor having to absorb the costs from an event that had nothing to do with the Project Team’s performance, or even the agreed-to Scope Baseline. It’s noteworthy that Scenario (A)’s outcome is exactly the same as those instances where the Customer induces scope creep, in that (1) the Project Team performs work that was not costed, but somehow slithered was informally introduced into the Scope Baseline. Within the game vernacular, this could be seen as either master-level play, or cheating, but what’s clear is that we’ve moved well beyond the nominal method of disposing business conflicts and into a winner/loser configuration, meaning we are, essentially, playing a game.

And Game Theory is what this blog is all about.