Chapter 6. Know Your Enemy: Introduction to Risk Management[8]
Note
When my wife and I moved from Rochester, New York, to Portland, Oregon, we had a great project plan. We had a realistic schedule for daily travel distances, routes and hotels selected, and sightseeing activities planned along the way. None of our planning, however, considered the possibility of hitting the world’s largest pothole in the middle of South Dakota, which cracked a wheel rim and caused a slow air leak from that tire. Nor did we anticipate the major wreck we had in Boise, Idaho. These unforeseen events were low-probability risks with high impacts. We eventually made it to Portland, but sometimes I think Lewis and Clark had an easier trip west.
Software engineers are eternal optimists. When planning software projects, we usually assume that everything will go exactly as planned. Or, we take the other extreme position: the creative nature of software development means we can never predict what’s going to happen, so what’s the point of making detailed plans? Both of these perspectives can lead to software surprises, when unexpected things happen that throw the project off track. In my experience, software surprises are never good news.
Risk management has become recognized as a best practice in the software industry for reducing the surprise factor (Brown 1996; DeMarco and Lister 2003). Although we can never predict the future with certainty, we can apply structured risk management practices to peek over the horizon at the traps that might be looming. Then we can take actions to minimize the likelihood or impact of these potential problems. Risk management means dealing with a concern before it becomes a crisis. This improves the chance of successful project completion and reduces the consequences of those risks that cannot be avoided.
During project initiation take the time to do a first cut at identifying significant risks. At this stage it’s most important to consider business risks, the risks of either undertaking or not undertaking the project. The project charter template described in Chapter 7 includes a slot for business risks. It’s possible that the risks will outweigh the potential benefits of the project. More likely, getting an early glimpse of potential pitfalls will help you make more sensible projections of what it will take to execute this project successfully. Build time for risk identification and risk management planning into the early stages of your project. You’ll find that the time you spend assessing and controlling risks will be repaid many times over.
A "risk" is a problem that could cause some loss or threaten the success of your project, but which hasn’t happened yet. And you’d like to keep it that way. These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of your products, or team morale. Risk management is the process of identifying, addressing, and controlling these potential problems before they do any harm.
Whether we tackle them head-on or keep our heads in the sand, risks have a potentially huge impact on many aspects of our project. The tacit assumption that nothing unexpected will derail the project is simply not realistic. Estimates should incorporate our best judgment about the potentially scary things that could happen on each project, and managers need to respect the assessments we make. Risk management is about discarding the rose-colored glasses and confronting the very real potential of undesirable events conspiring to throw the project off track.
[8] This chapter was originally published in Software Development, 1998, 6(10): 38–42. It is reprinted here, with modifications, with permission of CMP Media Inc.