(Please read the entry “Caveat lector” first)
One of the unwritten yet fundamental laws of large-scale IT projects is that their costs always exceed the original budget. Tickets could be sold to allow spectators witness the often fatalistic mood among otherwise hard-charging executives with which they absorb the budget requirement news (blows rather) from the PMO. To avoid making a mockery of themselves they sometimes even predict such a development at the outset of the project, portraying budget increases as an inevitable fact of life - message to the audience: “Even I can do nothing about it”. Except for granting bonuses and promotions there probably is no better way to thrill the responsible project team more than with this blank check of sorts (the key challenge for them will be to keep their face muscles straight). And if you ever need a good example of a self-fulfilling prophecy…
Fortunately, or unfortunately for some, it does not have to be this way. Why? Because there are several clearly identifiable, typical errors or misconceptions people fall prey to when they think about the project budget. And there are also some clearly identifiable counter-strategies available on how to avoid them or deal with them. In order to keep the blog tidy I shall spread the various facets of this topic across several entries. The focus of this section is the sizing of what is commonly called the “contingency budget” and the governance process associated with it.
The excitement of solving puzzles is one of the few things that sets humans apart from other creatures. So once people noticed the always-over-budget-symptom they started to investigate. In most cases not with a rigorously scientific methodology (“no time for that”) but rather with a pragmatic “lessons learned” objective in mind. Leaving aside the fact that those effort should more accurately be called “lessons to learn”, three broad categories of reasons for budget explosion are being diagnosed:
As you possibly agree it makes little sense (in this
space) to discuss situations where the initial budget is fixed artificially low (jargon: “top-down”), e.g. in order to obtain approval. Significantly more
interesting are the other two categories: The self-perception bias
acknowledges the fact that people tend to
overestimate their own capabilities, skills, and performance relative to
others (the archetypical 90% of college professors rating themselves as above
average university teachers). In the context of large-scale IT projects this
bias implies systematically overoptimistic assumptions concerning the
availability of best-in-class competence, tools, and motivation which, taken
together, yield exceptional productivity. As a consequence, the time and
resources needed to complete a given task is systematically underestimated. So, would a correction factor not be helpful in determining a more realistic budget?
While there is a lot of evidence available for this type of bias in the psychology literature, I firmly believe that unwarranted “Goldilocks” assumptions are used repeatedly in organizations only when planners intend to please the perceived desire of someone higher up in the hierarchy - otherwise they´d quickly experience a rendezvous either with this “someone” or with reality! Thus, there is in fact no illusion and we are back at category 1: Political bias which ipso facto negates all corrective action. So a self-perception bias in this type of setting is unlikely to prevail for long on its own.
The third category “ceteris paribus fallacy” relates to the remarkable insight that large-scale IT projects take a looong time to complete and during that looong time a looot can happen. In fact, a lot will happen over the course of a project simply due to the dynamic environment of modern organizations: The project manager will be transferred to a line position somewhere else, a critical piece of infrastructure breaks down, in order to solve an operational emergency key people are temporarily withdrawn from the project, due to new regulations the scope of the project has to be extended, another project in the portfolio induces an architecture modification that needs to be accommodated, a key supplier is being replaced in the wake of a serious professional disagreement and so on.
As so many different types of contingencies may occur planners would be overwhelmed with trying to assign impact estimates and probabilities to calculate expected values and add those to the project budget. Fortunately, one particular Donald (not you-know-who) comes to the rescue: While you don´t know exactly what is going to happen you do know something will, and there is a body of experience available, across organizations, how to properly account for those known unknowns namely, in form of a contingency budget.
Few people today dispute the need for a contingency budget and the immediate next question is “what would be the right number for a contingency budget?”. Typical common response, fired without hesitation from the hip: “Let´s take 10%”. Why? Ten percent somehow “feels right” in an organizational context. The number is neither too big to change the overall picture, nor too small to cover a contingency when the need actually arises. Furthermore, even without any self-perception bias the regular budget estimate will not be entirely accurate, and, hey, who could be blamed for being off by 10%?
And there you have it again: Biased thinking concealed as “pragmatism”. As emphasized before, large-scale projects have a long duration and obviously, what happens until the end of next month can be much better predicted and controlled than what happens over the course of, say, three years. Therefore, any formula applied to calculate the size of the contingency budget should somehow embrace project duration. So unless you have better information pertinent to your particular setting I propose that you use the “1-percent-per-month” heuristic to set a contingency budget. Let ´s take an example: Suppose you have properly planned a large-scale IT project with a roadmap and resource schedules etc., and the project is bound to take 24 months from kick-off through go-live then the contingency budget to add should be 24% of the base budget as calculated during the planning exercise. To state it differently: You should expect to spend 124% of the amount calculated in the regular budgeting exercise - the extra 24% you just don´t know specifically what for and when!
There are several reasons why this 1% -per-month heuristic makes sense: Firstly, it links a time dimension to the contingency budget. Secondly, as there is a probability distribution around the real number, it is by design a bit on the high-end and will in most cases prevent negative surprises. Thirdly, it shocks the 10%-pragmatists out of their complacency and fosters a creative debate about ways to shorten the timeline of a project. By divine coincidence, it is also easy to remember.
Now, having a number alone is not sufficient: The contingency budget approach advocated here will work only as intended if it is used exclusively for contingencies. So apart from setting a proper value there needs to be a governance mechanism that prevents the project team (or anyone else) to easily tap into the contingency budget, e.g. in order to cover regular effort estimation errors. A good way of establishing such a hurdle is to require supervisory committee approval before spending parts of the contingency budget. This will ensure that people with…
assess the merits of a request for spending approval.
To summarize, any large-scale IT project requires a special contingency budget besides the base budget as determined through the regular project planning exercise. The contingency budget is for contingencies only. It should be set at 1% of the base budget, per month of project duration. Spending of the contingency budget should require approval by a supervisory committee.
As pointed out above, the contingency budget is only one component of a comprehensive strategy to avoid/minimize negative budget surprises. So, in case you are interested, watch this space for further entries on other aspects of the subject matter.
(all rights reserved)