5.1 Elements of Risk Management
5.2 Risk Identification
5.3 Risk Analysis
5.4 Risk Prioritization
5.5 Risk Control
5.6 Risk, High Risk, and Gambling
Related Topics
Rapid-development strategy: Chapter 2
Classic mistakes: Chapter 3
Software-development fundamentals: Chapter 4
Summary of requirements scrubbing: Chapter 32
Summary of top-10 risks list: Chapter 41
IF YOU WANT A SAFE BET, GO TO LAS VEGAS and play the slot machines. The casinos have figured the odds carefully and determined that they can make a profit even when the slots pay out 97 percent of the money they take in. Odds are that if you spend a day pumping $1000 in quarters into the slot machines, you'll get back $970. If you don't like slot machines, you can play blackjack and count cards to tilt the odds slightly in your favor. (Just don't get caught counting!)
If Las Vegas sounds too tame for you, software might be just the right gamble. Software projects include a glut of risks that would give Vegas oddsmakers nightmares—shifting user requirements, poor schedule estimates, unreliable contractors, management inexperience, personnel problems, bleeding-edge technology failures, changing government regulations, and performance shortfalls—just to name a few. The odds of a large project finishing on time are close to zero. The odds of a large project being canceled are an even-money bet (Jones 1991).
In 1988, Peat Marwick found that about 35 percent of 600 firms surveyed had at least one runaway software project (Rothfeder 1988). The damage done by runaway projects makes the Las Vegas prize fights look as tame as having high tea with the queen. Allstate set out in 1982 to automate all of its office operations. They set a 5-year timetable and an $8 million budget. Six years and $15 million later, Allstate set a new deadline and readjusted its sights on a new budget of $100 million. In 1988, Westpac Banking Corporation decided to redefine its information systems. It set out on a 5-year, $85 million project. Three years later, after spending $150 million with little to show for it, Westpac cut its losses, canceled the project, and eliminated 500 development jobs (Glass 1992). Even Vegas prize fights don't get this bloody.
There are a multitude of risk-management practices that can prevent disasters such as these, and you can learn most of them more easily than you could learn to count cards at blackjack. Of course many people who play blackjack don't bother learning to count cards, and many people who manage software projects don't bother learning much about risk management. But the unalterable fact is this: if you don't manage risks, you will not achieve rapid development. As Tom Gilb says, "If you don't actively attack the risks, they will actively attack you."
Risk management does involve a few disadvantages. Projects that manage risks effectively are a lot less exciting to work on than projects that don't. You'll miss the adrenaline rush of telling your boss the day that the project is due that it's going to be 3 months late because of a problem that you've never mentioned before. You won't get to be a hero for working nights and weekends 6 months in a row. For a lot of us, those are disadvantages we can live with.
Risk management in software is a fairly new topic, but already too much information exists to cover it thoroughly in one chapter. The discussion in this chapter focuses on schedule risks and ignores cost and product risks except when they affect the schedule. This chapter also focuses on practical aspects of schedule risk management. Risk-management theory is interesting and important, but it's less directly useful so I have mostly ignored it, instead describing where to find more information in the further-reading section at the end of the chapter.
The job of software risk management is to identify, address, and eliminate sources of risk before they become threats to successful completion of a software project. You can address risks at any of several levels. Table 5-1 describes some different levels of risk management.
Table 5-1. Levels of Risk Management
Source: Adapted from A Manager's Guide to Software Engineering (Pressman 1993). |
|---|
|
The purpose of this chapter is to describe how to address software schedule risks at levels 4 and 5 rather than at levels 1 through 3. If you're addressing risks at level 1, 2, or 3, you've already lost the schedule battle.
Generally, risk management is made up of risk assessment and risk control. These, in turn, are made up of several subcategories as shown in Figure 5-1. These are outlined in the following subsections.
Figure 5-1. Risk management is composed of risk assessment and control. Source: Software Risk Management (Boehm 1989).
Risk assessment is made up of risk identification, risk analysis, and risk prioritization:
Risk identification produces a list of risks that have the potential to disrupt the project's schedule.
Risk analysis assesses the likelihood and impact of each risk and the risk levels of alternative practices.
Risk prioritization produces a list of risks prioritized by impact. This list serves as a basis for risk control.
Risk control is made up of risk-management planning, risk resolution, and risk monitoring:
Risk-management planning produces a plan for dealing with each significant risk. It also makes sure that the risk-management plans for each of the individual risks are consistent with each other and with the overall project plan.
Risk resolution is the execution of the plan for dealing with each significant risk.
Risk monitoring is the activity of monitoring progress toward resolving each risk item. Risk monitoring can also include the ongoing activity of identifying new risks and feeding them back into the risk-management process.
The subsections in the following section explain each of these aspects of risk management as they apply to managing software schedule risks.