The Rational Unified Process: An Introduction (3rd Edition)

THE CONCEPT OF RISK

As Tim Lister says, "All the risk-free projects have been done." ^[2] The software development process primarily takes care of the known aspects of software development. You can precisely describe, schedule, assign, or review only what you know must be done. Risk management takes care of the unknown aspects. Many organizations work in a "risk denial" mode: estimating and planning proceed as if all variables were known and as if the work were mechanical and the personnel interchangeable.

^[2] Software Risk Management Is Software Project Management , Seminar at Software Productivity Center, Vancouver, B.C., Canada, May 1996.

What Is a Risk?

Many decisions in an iterative lifecycle are driven by risks. To make effective decisions, you need a good grasp of the risks the project faces and clear strategies for mitigating or dealing with them.

In everyday life, a risk is an exposure to loss or injury or a factor, thing, element, or course that involves uncertain danger. We can define risk more specifically in software development as a variable that, within its normal distribution, can take a value that endangers or eliminates success for a project.

In plain terms, a risk is whatever may stand in our way to success and is currently unknown or uncertain. We can define success as meeting the entire set of all requirements and constraints held as project expectations by those in power.

We can qualify risks further as direct or indirect:

• Direct risk:  

  a risk over which the project has a large degree of control

• Indirect risk:  

  a risk over which the project has little or no control

We can also add two important attributes:

• The probability of occurrence

• The impact on the project (severity)

These two attributes often can be combined in a single risk magnitude indicator , and five discrete values are sufficient: high, significant, moderate, minor, and low.

Strategies: How to Cope with Risks

The key idea in risk management is that you not wait passively until a risk becomes a problem (or kills the project) before you decide what to do with it. For each perceived risk, you must decide in advance what you are going to do.

Three main routes are possible: ^[3]

^[3] Barry W. Boehm, "Software Risk Management: Principles and Practice," IEEE Software , Jan. 1991, pp. 32 “41.

• Risk avoidance :  

  Reorganize the project so that it cannot be affected by the risk.

• Risk transfer:  

  Reorganize the project so that someone or something else bears the risk (the customer, vendor, bank, or another element).

• Risk acceptance:  

  Decide to live with the risk as a contingency. Monitor the risk symptoms and determine what to do if the risk materializes.

When accepting a risk, you should do two things:

• Mitigate the risk:  

  Take immediate, proactive steps to reduce the probability or the impact of the risk.

• Define a contingency plan:  

  Determine the course of action to take if the risk becomes an actual problem; in other words, create a "plan B."

Risks play a major role in planning iterations, as you will see later.