IntroductionTo top of page

The software development process takes care mainly of the known aspects of software development. You can only precisely describe, schedule, assign and review what you know will have to be done. Risk management takes care of the unknown aspects. Risk management is there with us for a long time; as Tim Lister says: "All the risk-free projects have been done." Many organizations still work in a ‘risk denial’ mode: estimating and planning is done as if all variables are known, it assumes work is mechanical, personnel is interchangeable, etc. But more and more organizations are at least paying lip service to risk management; pushed to the extreme, you may discover that it is often just on the surface, a faint attempt at risk minimization.

Definitions To top of page

Many decisions in an iterative lifecycle are driven by Risks. In order to achieve this you need to get a good grip on the risks the project is faced with, and have clear strategies on how to mitigate or deal with them.

In everyday life a risk is an exposure to loss or injury; a factor, thing, element, or course involving uncertain danger. But more specifically in software development:

  • A risk is 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.
  • Success is meeting the entire set of all requirements and constraints held as project expectations by those in power.

We can further qualify risks as direct or indirect:

  • Direct risk: a risk that the project has a large degree of control over
  • Indirect risk: a risk with little or no project control

Attributes of a risks:

  • Probability of occurrence
  • Impact on the project (severity)

The two can often be combined in a single risk magnitude indicator: High, Significant, Moderate, Minor, Low.

Strategies To top of page

The key idea in risk management is not to wait passively until a risk materializes and becomes a problem or kills the project to decide what to do with it. For each perceived risk you decide in advance what you are going to do. There are 3 main possible routes:

  • Risk avoidance: reorganize the project so that it cannot be affected by that risk.
  • Risk transfer: reorganize the project so that someone or something else bears the risk (customer, vendor, bank, another element, etc.)
  • Risk acceptance: decide to live with the risk as a contingency. Monitor the risk symptom, and decide on a contingency plan of what to do if the risk emerges.

When accepting a risk, you should do 2 things:

  • Risk mitigation: take some immediate, pro-active step to reduce the probability or the impact of the risk
  • Define a contingency plan: what course of action you should take if the risk become an actual problem.

For more information on Risk management see BOE91, CAR93, CHA89, FAI94, and JON94.

Display Rational Unified Process using frames


Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)