CONTINGENCY: ALLOW A MARGIN FOR ERROR, HAVE A FALLBACK POSITION

Explicit or hidden contingency

If you were a project manager and you worked in construction, then on your plans people would expect to see a line item called Contingency. It might be set, for example, at 15 percent of the project budget and/or elapsed time. If people didn't see this, they would assume one of two things: the more charitable of the two would be that it was an omission on your part; the other would be that you had taken leave of your senses. They would believe this because in omitting contingency, it would imply that you felt confident you could predict the future.

There are some software companies “ regrettably few, I have to say “ where a similar ethos applies. The management and the customers of these companies expect to see contingency built into plans. Not doing so is regarded as project management practice somewhere in the range of improper to criminally negligent.

So what happens in the other software companies? Well, in these, contingency is actually what the management or the customer takes the red pencil to first. "OK, now where can we shorten this baby [or make it cheaper]?" ponders the Big Cheese, the Great Gorgonzola. "Ah, contingency, you won't need that for starters."

If your organization is one of the enlightened ones, then put in the contingency explicitly, and plenty of it “ as much as you can get away with.

If, on the other hand, your organization is of the red-pencil variety, then you need to hide the contingency. PC-based tools are very powerful in helping you to do this quickly. Another useful way of doing it “ and they'll never spot it “ is to put in fake activities. You can couch these in technobabble (there are numerous software packages that will generate buzzwords and acronyms for you) and so you have activities like:

• Update table lookup

• Memory maintenance

• Changes to existing

• Decision on tool

• Re-work

You know the kind of thing I mean “ just find some applicable to your particular application area and you can reuse them time after time. Of course it's better if you can put your cards on the table and set out the contingency explicitly, but failing that you have to get it in there somehow.

Not so long ago, I did some consultancy for a company. It essentially ended up with me spending an afternoon working with a project manager helping him to hide contingency in an MS Project plan. It was his management who were paying my fee and here I was preparing material to, in a sense, hoodwink them. I have to tell you that I felt entirely morally justified in doing what I was doing, on the basis that one day they would thank me for it.

They did too. About a month ago; when their project came in on time and within budget “ the time and budget that included the contingency.

Finding contingency

You can use the four parameters we first identified in Chapter 1 to help you build in your contingency. These are:

• Functionality

• Delivery date

• Effort (cost)

• Quality

Functionality

Some projects get structured such that on some happy day in the future, somebody will pull the great lever and the whole system will power up and work perfectly. (The nuclear deterrent system operated by the superpowers during the Cold War was such a system! I had a friend who ran a small software house and he was a veteran of more payroll system installations than you could shake a stick at. Based on his experience of these, he was confident that there could never be a nuclear war: he'd never seen a payroll system work right first time, so why should thermonuclear Armageddon be any different?) Either it all works perfectly on the promised delivery date or it doesn't work at all. That's how some projects are conceived.

You can certainly organize your project this way, but then you're really asking for trouble. You've given yourself no room for maneuver, no fallback position.

As an alternative to this you can do what is called phased delivery. Is there some minimal set of functionality your project can deliver which will get your customer off the ground (start them doing useful work) while at the same time familiarizing themselves with, and debugging the system? Then, can you add some more functionality and some more and some more? At any point, if you find you've reached for a milestone too far, you can always fall back on the last version you delivered.

Delivery date and effort (cost)

You can add contingency using either of these merely by adding on an additional percentage to allow for contingency. Typical numbers tend to be in the range 10 “15 percent, but I suspect the only significance of these numbers is that they tend to be what people can get away with. As a general rule, I would say the more you can get the better. Certainly the more chance you have of your model being seen to be right and hence, of having a successful project.

You can add the contingency:

• on a blanket basis, across the entire project

• on a per phase basis, that is, to each phase

• to those jobs on the critical path

Also, it's probably better to aim for adding a percentage onto the delivery date, because in doing so, it often means you can hold onto people for that extra period of time, and so achieve an even bigger contingency on the effort.

Quality

If you can measure the quality of your project deliverables, then you can use these as bargaining counters in the contingency game.

For example, in the development of a software system you might use mean time to defect (MTTD) as a measure of quality. (For an excellent discussion on this, see Puttnam and Myers (1992).) Then you might aim for an MTTD of, say, 2 days, but in a pinch you'd be prepared to settle for 1 day or 1.5 days. Again, you gain some room for maneuver, some margin for error.