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 are 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.
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:
We can further qualify risks as direct or indirect:
Attributes of a risks:
The two can often be combined in a single risk magnitude indicator: High, Significant, Moderate, Minor, Low.
The key idea in risk management is not to wait passively until a risk materializes and becomes a problem or kills the project, but 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:
When accepting a risk, you should do 2 things:
For more information on risk management see [BOE91],
[FAI94], and [JON94].