Concept: Risk Management

Introduction

Every project contains a part of uncertainty. The role of Risk Management is to deal with this uncertainty to try to understand its potential influence on the project. Project risks may be seen as threats or opportunities. The former means the risk should be mitigated (see risk management strategies below) where the latter means that taking a calculated risk may bring, for example, competitive advantage for a product or organization [SEI99].

Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. A common mistake is to identify risks only at the beginning of the project and then only track the status of these initial risks. The risk list should be revisited weekly, or as a minimum once per iteration, to add any newly discovered risk.

Risks Prioritization

A good approach for prioritizing risks is to have an attribute called risk magnitude, a combination of the risk probability and the risk impact. Each iteration provides a chance for better understanding of stakeholder needs, the team capabilities, the technology at hand, and so on. As risks arise, capture, quantify and prioritize them. High level of magnitude risks are attacked first, thus improving the chances of project success and minimizing uncertainty. See Template: Risk List for more information.

Risk Management Strategies

Once you have chosen a set of risks to focus on, choose a mitigation strategy, as described below. Then, identify and assign tasks to apply the strategy to the given risk. Follow up regularly on risk-mitigation actions. Try another strategy if your chosen strategy does not reduce the magnitude of a risk.

Common mitigation strategies are:

Risk avoidance: reorganize the project so that it cannot be affected by that risk.
- For example: you need to use a new framework. A risk avoidance strategy could be to drop this new framework and using another one that is well-known by the team.
Risk transfer: reorganize the project so that someone or something else bears the risk.
- For example: the application you are developing need to communicate with a legacy system. Rather that taking the risk. A risk transfer strategy could be to make the legacy support team responsible of providing the APIs to access the legacy system.
Risk mitigation: define a mitigation plan to reduce the probability or the impact of the risk.
- For example: you need to use a new middleware. A risk mitigation strategy could be to build a prototype using this new middleware to validate that it will provide the features you need for your application.
Risk acceptance: decide to live with the risk, and define a contingency plan.
- For example: your integrator is the only one who knows how to integrate the different components of your application. A contingency plan could be to identify a resource on another project that you could bring on if your integrator is sick, leave the company, etc.