9. Mechanics of Risk Management

“We aren’t really bad at estimating. What we are really bad at is enumerating all the assumptions that lie behind our estimates.”

—Paul Rook¹

¹Paul Rook, from his keynote on risk management, European Conference on Software Methods, London, October 1994.

An easy test of risk awareness in a project is this: Look through the project plan and ask the manager to indicate any tasks that might not have to be done at all. You may suddenly find yourself on the receiving end of a baffled expression. Put into words, that confused look seems to ask, If a task doesn’t have to be done, why on earth would we ever put it into the plan? You’ve just learned that the plan, in this manager’s view, is the set of all tasks that definitely have to be done.

There is bad news and good news here. The bad news is that since all real-world projects produce their share of surprises, managers often fail to deliver on their promises, sunk by those “might have to be done” tasks that subsequently need doing. The good news is that these conditional tasks are, at least at a coarse level, fairly predictable.

The principle underlying this approach is this:

There is a part of each of us that has trouble with this formulation. We want to “correct” it to something like Today’s problem is yesterday’s risk, or Today’s risk is tomorrow’s problem. Such restatements have a surface likeability, but they don’t do much for you. It’s the equation of past problem with present risk (in other words, a recognition of the repeating nature of project problems) that gives you a leg up on how to practice risk management. If you find that a project you just completed ran into trouble when a few key employees left the company, then personnel loss is automatically entered onto your new project risk list. The word “automatically” is worth stressing here: Loss of people, particularly key people, is such a defeat that can-do management may refuse to consider it. Never underestimate the seductive comfort of “Erghhhh, I just don’t want to think about that.”

So, one way to populate your risk list—at least initially—is through the methodical use of postmortem results. This assumes that your company is already enlightened enough to perform a postmortem analysis at the end of each successful or unsuccessful project, to understand what happened. If you’re not doing that, you might want to take a look at the References for two recommendations on postmortem analysis.

Project postmortems are hardly new. What is new is use of the output of the postmortem process as input to the risk management process:

Project problems tend to repeat with sufficient frequency so that if you’ve analyzed half-a-dozen past projects, you probably have enough data. Keep in mind that postmortem data is only one source of risk information. There is also the risk-discovery process, which we treat in a later chapter.

Fortunately, some risks expire during the course of a project. Perhaps you were worried that one of your subcontractors would fail to deliver a needed component; the risk of non-delivery expires when the subcontractor delivers and the component passes acceptance testing. By the end of the project, all the risks that didn’t materialize have expired.

Managers who are applying pressure to do something about risks (in other words, to make them go away) are not likely to be content waiting for them to expire. They want something done now. So, what somethings might you be able to do? We identify four things you can do about a risk:

• You can avoid it.

• You can contain it.

• You can mitigate it.

• You can evade it.

You avoid a risk when you don’t do the project or the part of the project that entails the risk. The natural consequence of avoiding a risk is that you forgo the benefit that going into the risky area offered. For example, Merrill Lynch avoided the risks of moving into Web trading during the early 1990’s. In doing so, the company had to forgo the benefits of increased product distinction and improved branding.

You contain a risk when you set aside sufficient time and money to pay for it, should it materialize. In practice, it doesn’t make much sense to contain a single risk; instead, you contain your entire set of risks. Some of them will materialize and others won’t. A containment strategy sets aside enough resources, on average, to offset the risks that are likely to materialize. We’ll offer more about how to do this in a later section.

You mitigate a risk when you take steps before its materialization to reduce eventual containment costs. These are the steps required in advance so that the containment strategy you’ve chosen will be implementable at transition time.

You evade a risk when you do none of the above and the risk just happens not to come back and bite you. It doesn’t materialize. When you plan to evade a risk, it is customary to cross your fingers.

The first three of these cost money: Avoidance costs you lost benefit; containment costs you the portion of risk reserves that gets used up; mitigation costs you whatever you spend to reduce containment cost. Only risk evasion appears to be free.

When you are fortunate enough to dodge the bullet, it in fact costs you nothing. For example, you worried that key people would leave during the project, but they didn’t; you worried that your supplier would be late, but he wasn’t; you worried that the users would balk at your rudimentary interface, but they swallowed hard and said okay. You worried about these things, but you didn’t do anything about them. In spite of the happy outcome, you didn’t really do any risk management, because of this key point:

As it turns out, you evaded all three risks. Like the shipowner in Clifford’s example, you have not been proved right. You have only been “not found out” to be wrong. There is a difference.

We all evade some risks sometimes and are happy for it. Planning on evading risks, however, is hardly a good strategy. Even a short risk list with only a dozen items on it suggests a very low probability of evading all twelve. If each one is only 10-percent likely, the chance that at least one of the twelve will come back to bite you is nearly 75 percent.¹

¹ That is, one minus the twelfth power of 0.9.

This is worth talking about because some companies have the rather pathological characteristic of making risk evasion a performance objective. In such a company, risk management is futile; the entire risk management effort looks like nothing more than another cost to be reduced.

The Vendor Authorized Contractor did some risk management. Its manager supplied a risk list of twelve items. All of them were concerned with ways that the customer might not live up to the bargain (the customer might delay the project by making decisions very slowly, the customer might not supply adequate workspace to the Vendor Authorized Contractor, and so on).

By now, you should be ready for the next development: The risk that actually sank the project (the vendor’s software wasn’t delivered in time to make the May operational date) was not even mentioned in the risk list. No one even named the risk until so late in the game that it was no longer a risk, but a problem. To make matters worse, the software was on the critical path.

The first runnable version of the software finally appeared well after the project had been canceled and the lawyers had been called in.

This story brings into focus the complicated problem of risk management in a contracted development project. The key danger in such a situation is a misunderstanding about who manages which risks. The client has every right to nominate certain risks for the contractor to manage, and vice versa. If you are the client, your safest posture is to assume that only those risks specifically allocated to the contractor are his, and that all the rest are yours. Incentives or penalties in the contract allocate risk.

The contractor’s risks are those that endanger the successful completion of the contract or diminish the value of completion to the contractor. Everything else is judged by the contractor to be somebody else’s risk, and thus a candidate for exclusion from his risk management. That means that you, as the client, have to manage these risks or no one will.

A common class of litigation arises out of projects in which the client is surprised to find that certain important risks never made it onto the contractor’s radar. Usually, fault lies with a contract that failed to assign those risks. As a general rule, there are no contracts that successfully transfer all responsibility to a single party. If you are either client or contractor, expect to have to do some risk management.

risk exposure = cost x probability

So, if you identify a risk that is 20-percent likely to occur, and it will cost you a million dollars if it does, your risk exposure is $200,000.

You can be perfectly sure that the actual cost to pay for a given risk will never be exactly equal to the exposure. The risk cited above, for example, will either materialize or not. If it does, it will cost you a million dollars; if it doesn’t, it will cost you nothing. Nonetheless, the exposure associated with that risk is $200,000.

If you calculate exposure for all your risks and set aside a risk reserve equal to the total exposure, that risk reserve will, on average, be sufficient to pay for the risks that do materialize. You may end up short on some projects and have some reserve left on others, but over the long run, your risk reserve will be about right.

Assessing exposure is not a well-defined science. Your best guess about likely materialization may come from industry data, previous problem lists, the risk repository, or just a flat-out guess. Don’t excuse yourself from this essential act just because any answer you come up with will never be demonstrably correct. Whether the likelihood of an oncoming train plowing into your project is 25 percent as opposed to 35 percent is not nearly as important as the understanding that there may be a train coming. Get the risk onto your census and start scanning the horizon for plumes of smoke from the locomotive.

So far, we’ve treated containment as a money matter. You will probably also need to contain risks in a time sense. Risk exposure can be expressed in months of expected delay. If a risk is 20-percent likely to occur and will cost you five months if it does, your time-denominated risk exposure is one month of delay.

Identification of one or more showstoppers does not invalidate the risk management process, even though they resist proper quantification. They represent an inherently different kind of risk, one that calls for an entirely different treatment. Showstoppers can only be managed by what we call project assumptions. In order for you to continue your work, you must assume that the showstoppers will not occur. Should any one of these assumptions prove false, you will have to escalate the issue to those above you. Showstoppers are beyond the responsibility and authority of the project.

Here are a few showstoppers we’ve come across:

• A company embarks on a project to completely reinvent a backbone product. Project management expects this effort to take somewhere on the order of two to two-and-one-half years. There is a chance that one of the competitors will deliver the same product well before the anticipated project complete date.

• A new product is being built to run on the dominant OS used within a target market. What if that OS is upgraded to an incompatible version?

You might be inclined to be fatalistic about such a risk, to say that if it hits you, you’re dead, so there’s no sense in even looking out for it. You can’t control it, so relax and just deal with what you can reasonably expect to handle. There is something very wrong about this logic. For example, imagine yourself promoted two levels in your organization. Now tell us, Aren’t you suddenly very, very interested in this risk? You have just discovered that it’s not the project team itself but the people who gave birth to your project who own these risks. Those who give can take away. They will have to decide what to do if any of the project assumptions turn false.

The rule here is that a risk owned above you in the hierarchy is an assumption to you. The risk still belongs on your risk list (since you still need to watch it), but it should be explicitly noted as a project assumption. That means it’s not going to be managed by you and must therefore be managed by your boss or your boss’s boss. You would do well to make a little ritual of passing this risk upward. When you present your risk management plan, formally delegate the management of some risks upward, to someone above you in the hierarchy. You can only do this in the context of a respectable effort on your part to manage the rest of the risks.

A more defensive strategy would be to allocate something more than aggregate exposure, while a less defensive strategy would be to allocate less. If you allocate 0 percent of your calculated exposure, you’re back where you started.

In the following graphic, the gray area is your most optimistic manpower-loading plan over time, expressed in dollars. The white area is the budget reserve that you will need to allocate in order to compensate for a probabilistic expectation of materialized risks.

The optimistic project plan (in gray) shows an earlier delivery date than that of the buffered (gray plus white) project plan. The difference between the two dates is your schedule reserve. By setting budget and schedule reserve equal to budget and schedule exposure, you are allocating a reserve that is sufficient, on average, to contain your risks.

In the following two graphics, we show how the upper managers of DIA could have assessed the value of building dual-use tunnels to mitigate the risk of late ABHS software. The first figure shows the project plan with no mitigation:

Without mitigation, the schedule reserve is large; the entire airport project will be stalled if the software project is delayed. The budget reserve then has to be enormous to pay for the additional cost of financing.

Contrast this situation with the mitigating action of building dual-use tunnels, early in the project:

Both reserves are now considerably reduced, but the shaded area is larger. It has been increased by the darker portions shown in the first two columns. This is the cost of mitigation, the added cost of the larger tunnels. The schedule has also been stretched out somewhat to the right, about one column width, since mitigation has a time cost as well as a dollar cost. The result is that the optimistic date on the graph is somewhat less optimistic than it was in the no-mitigation plan.

The mitigation plan’s rosy scenario (the best case, possible only when all risks fail to materialize) is less rosy than the rosy scenario of the no-mitigation plan. How can that be good? Here’s how:

• The area under the outer curve (representing realistic cost) is less than in the no-mitigation case.

• The total of the optimistic date plus the schedule reserve (representing the realistic delivery date) is shorter than in the no-mitigation case.

It’s tempting to say that the earliest possible indicator is the only one worth watching, but the problem is a bit more complicated than that. The earliest indicator may expose you to false-positive signals. You’d be ill-advised, for example, to make travel plans based on a five-day weather forecast if waiting for the 24-hour forecast (which is bound to be more accurate) would still leave you sufficient time to act.

On the other hand, the indicators that are least likely to yield false positives may appear too late to be useful. As an example of this, consider the trucker’s maxim:

While it’s not strictly true that each and every rolling ball is an indicator that a kid is about to come hurtling out under your wheels, you would still be well-advised to hit the brake as soon as you see the ball.

Your choice of transition indicator requires a thoughtful assessment of urgency and of the cost of false-positive triggering.