10. Risk Management Prescription

Most of what still remains to be described is detail. The preceding chapters have put enough of the basic concepts on the table so that we can now lay out a general prescription for what it means to do risk management.

1. Use a risk-discovery process (details in Chapter 14) to compile a census of the risks facing your project.

2. Make sure all of the core risks of software projects (details in Chapter 13) are represented in your census.

3. Do all of the following homework on a per-risk basis:

• Give the risk a name and unique number.

• Brainstorm to find a transition indicator—the earliest practical indication of materialization—for the risk.

• Estimate the cost and schedule impact of risk materialization.

• Estimate the probability of risk materialization.

• Calculate the schedule and budget exposure for the risk.

• Determine in advance what contingency actions the project will need to take if and when transition occurs.

• Determine what mitigation actions need to be taken in advance of the transition to make the selected contingency actions feasible.

• Add mitigation actions to the overall project plan.

• Write all the details down on a template like the one in Appendix B.

4. Designate showstoppers as project assumptions. Perform the ritual of passing each of these risks upward.

5. Make a first pass at schedule estimation by assuming that no risks will materialize. In other words, your initial estimating step is to determine the nano-percent date, the earliest date by which you can’t yet prove to yourself that you won’t be done.

6. Use local and industry-wide uncertainty factors (details in Chapter 13) to construct a risk diagram with intersection at N.

7. Express all commitments using risk diagrams, explicitly showing the uncertainty associated with each projected date and budget.

8. Monitor all risks for materialization or expiration, and execute contingency plans whenever materializations occur.

9. Keep the risk-discovery process going throughout the project, to cope with late-apparent risks.

These steps are easy enough to list, but a bit more difficult to do. A few comments are in order:

Of course, N-based scheduling can be abused. Someone who is desperate to get you to commit to a 12-month delivery, for example, may try to assert that N is four months, and that therefore your risk diagram should be based at 4. But the burden of proof is on the asserter here: He or she has to show that four months is at least technically feasible and consistent with optimal performance in the same context on past projects.

This is new and different: a project with a scheduled commit date that is different from the stretch goal. The rule in most companies has long been

Schedule = Goal = N really dumb equation

N is a mean-spirited goal because it’s unreachable. And it’s a disastrous commit date for the same reason. What we’re proposing instead is

Schedule > Goal > N more sensible

If we’ve persuaded you that this makes good sense, don’t automatically assume that everybody in your organization will see it that way. The bad habit of committing to deliver at N is deeply ingrained. We need to break ourselves of it, but you have to expect—as in breaking any other bad habit—a certain amount of pain along the way.

TRL:    My father is a mathematician, a retired professor of math. He chided me one day about all the software projects that seem to come in late, more or less 100 percent of them.

“Why is that?” he asked.

I told him, “Well, there are just two possible outcomes for a project: It can be done on time, or it can be done late. I guess the odds seem to favor late, except in a few very remarkable cases.”

“There aren’t just two possible outcomes, Tim,” he responded. “There is a third: Early.”

That got me thinking. I visit companies all the time where early is utterly inconceivable. A manager who finished early would be accused of unconscionable gaming of the schedule and would probably be drummed out of the corps.

By making the third result, early, effectively illegal, we have reduced the odds of on-time delivery to nearly zero. Our anti-gaming measure has made gaming the schedule the rule rather than the exception.

We need to make early delivery legal again in order to inspire confidence in our commit dates. This, too, is going to require some serious work on corporate culture. As soon as we make it safe for a project to come home ahead of schedule, our stakeholders can begin to have some reasonable expectation of delivery on schedule. We can realistically assign goals that are different from commit dates, and we can begin the long-postponed business of demonstrating to all that we can meet the commitments we make.

Fortunately, you have some options for trading off schedule uncertainty for functional uncertainty. If the date is utterly fixed, then you need to express the uncertainty of your project with a risk diagram like this:

The date is now fixed and the uncertainty is entirely a matter of what will be delivered on that date. If absolutely no risk materializes, all of the functionality of Versions 1 through 24 (represented by V24) can be delivered. Since the odds of evading each and every risk are extremely low, this is the nano-percent functionality—it’s not impossible, only extremely unlikely. Judging from the area under the curve to the left of V21, the functionality of Versions 1 through 21 appears to be approximately 50-percent likely by the date. If the stakeholders are adamant that nothing less than V22 will be useful to them, the diagram shows that you have barely a 30-percent probability of giving them what they need. Again, this may be unwelcome news, but concealing it only delays (and worsens) the eventual day of reckoning.

Three caveats here: First, this approach only makes sense if you commit in advance to a highly incremental implementation, and if you lock in, in advance, what the functional extent will be of each version. If you’re planning on delivering in only two or three versions, the resultant uncertainty diagram is practically meaningless. And if you defer the decision on what functions are included in which version, your users will be unable to assess what functionality is at risk.

Second, beware of the project that is presented with a fixed deadline but doesn’t really have one:

TDM:    I was consulting on a project in upstate New York that had a “firm, fixed deadline.” The product absolutely had to be delivered by end of the second quarter, no excuses. But it wasn’t. In fact, it was finally delivered more than eighteen months late. In retrospect, I couldn’t help wonder what all the song and dance about “firm, fixed deadline” was really about, since the deadline was clearly neither firm nor fixed.

This was a rare case when I had such an easy relationship with the stakeholder that I could simply ask that uncomfortable question and get a pretty straightforward answer. So I did. He told me—over beers—that what he’d been most concerned about was that the cost would get out of hand. The deadline he’d initially set had no particular time significance, but he figured that the project could only use up a limited amount of money in that time. When the time was up, he could see that he was getting his money’s worth from the development team, so he bought into the revised schedule.

Some fixed deadline projects really do have to be done on time (say your company wins the contract for CNN’s election night forecasting software). Other fixed deadline projects, like the one described above, have an arbitrary deadline that has nothing to do with a real need on that date. In either case, you’ll want to respond with a highly incremental implementation. That much incrementalism has a cost, though; in the second case, much of that cost is wasted.

Incrementalism also doesn’t do much for you if there is a significant likelihood that not even the first version can be delivered by the fixed date:

Here we see a project that has a probability of 60 percent or more of arriving at the guaranteed date with not even its first version working.

As we hinted in Chapter 5, you can only feel safe publishing your risk census if your peer managers are publishing theirs as well. (Being the only honest person in a room full of liars puts you at a dreadful disadvantage.) The organization is far better off when all risk lists are public, since the omission by any manager of a core risk stands out glaringly. Managers who overcommit by ignoring important risks are exposed by a simple comparison of the lists. Instead of looking good for committing ambitiously, they look a little foolish for not acknowledging their risks.