Chapter 6: Know Your Enemy: Introduction to Risk Management


In this chapter:

What Is Risk?

Why Manage Risks Formally?

Typical Software Risks

Risk Management Components

Documenting Risks

Risk Tracking

Risk Management Can Be Your Friend

Learning from the Past

Practice Activities

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.

1 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.
     Next >