Guideline: Identifying Risk Actions
This guideline explains how to identify and propose risk actions or strategies used to attack project risks.
Main Description

Risk mitigation

For direct risks, that is, risks for which the project has some degree of control, identify what actions will be taken to reduce the probability of the risk, or to reduce the risk impact on the project (the mitigation strategies). Typically, the risk itself derives from lack of information; often, the mitigation strategy itself is one of investigating the topic further to reduce the uncertainty.

Note: before implementing risk mitigation strategies as described below, determine the cost-benefit ratio of implementing each strategy. If it is more expensive to implement a mitigation strategy than the actual consequence cost of a risk materializing, you may decide to accept the risk instead of pursuing action to mitigate it. However, be sure to take into consideration that cost and benefit do not always translate to monetary value only - there may be other aspects of benefit and cost such as company reputation, market share, etc., that should be considered in the cost-benefit evaluation.

Take action to either make the risk materialize or retire. Allocate such actions to early phases or iterations of the project lifecycle to mitigate the risk as early as possible. Confront the risks as early as possible. If a risk is in the form "X may not function as planned?", then plan to try X as soon as possible.

Determine the levels and thresholds that define when a risk becomes unacceptable and triggers the execution of a risk mitigation plan or a contingency plan.

The following are examples of risk mitigation strategies:

  • To reduce the risk that products X and Y cannot be integrated, a prototype will be built to investigate the difficulty of integration. The following features (enumerated in a list) will be tested to ensure the integration is successful.
  • To reduce the risk that database A will not perform adequately, it will be benchmarked using a suite of tests which model the workload of the target application.
  • To reduce the risk that the test tool Z will not be able to effectively perform regression test of the application, we will acquire and use it during the upcoming iteration.

The result of these actions should be to reduce the probability that certain risks will occur, perhaps to near zero. In cases where the risk is confirmed, the risk is responded to with a contingency plan.

Risk contingency

For each risk, whether you have a plan to actively mitigate it or not, you must decide what actions are to be taken when or if the risk materializes, that is, if it becomes a problem - a 'loss event' in insurance jargon. This is commonly called "a plan B" or contingency plan. A contingency plan is needed when risk avoidance and risk transfer have failed, when mitigation was not successful, and now the risk must be addressed head-on. This is very often the case for indirect risks, that is, the risks for which the project has no control, or when the mitigation strategies are too costly to implement.

The contingency plan should answer the following questions:

  • Risk: What is the risk? 
  • Indicator: How will you know that the risk has become a reality? How is the 'loss event' recognized? 
  • Action: What should be done to address the 'loss event' (how can you stop the "bleeding"?)

Identify Risk Indicators

Some risks can be monitored using project metrics or looking at trends and threshold; for example:

  • Rework remaining too high
  • Breakage remaining too high
  • Actual expenditure far above plans

Some risks can be monitored based on project requirements and test results; for example:

  • Response times one order of magnitude above requirement.

Some risks are associated to a specific event; for example:

  • Software component not delivered in time by third party.

There are many other, "softer" indicators, none of which will fully diagnose the problem. For example, there is always a risk that morale will drop (in fact, at certain points in the project, this is almost predictable). There are a number of other indicators: grumbling, "gallows humor", missed deadlines, poor quality, and so on. No one of these "measures" is a sure indicator; joking about the futility of a particular deliverable can be a healthy way of relieving stress, but if it continues, it may be an indication that the team feels an increasing sense of impending doom.

Listen to all indicators without passing judgment. It is easy to label the bearer of 'bad news' as someone who has a bad attitude; behind cynicism there is often more than a grain of truth. Often, the 'bearer of bad news' is acting as the 'conscience of the project'. Most people want the project to succeed, and they feel frustrated when momentum is carrying the project in the other direction.

Identify "Loss" Actions, or "Plan B"

For simple cases, the contingency plan enumerates alternate solutions. The impact is usually costs and delays to scrap the current solution and implement the new one.

For other, "softer" risks is often not one action to take when a loss has occurred, but several. When morale drops, for example, it is best to acknowledge the condition and gather as a group to discuss the prevailing attitudes on the project. Listen to concerns, identify issues, and generally let people vent. After an appropriate amount of venting, though, move on to address the causes of concern. Use the risk list as a way to focus the discussion. Translate the concerns into a concrete action plan by reprioritizing risks and then reformulating the iteration plans to systematically address the top risks. Positive action has a stronger effect than positive (but empty) words.

Despite the mood at the time, a loss occurrence has a positive side: it forces action. Too often it is easy to postpone risks by ignoring them, lulled into complacency by the apparent quiet. When a loss event occurs, action is required. The risk is no longer a risk, there is no longer any uncertainty about its occurrence.

Yet a loss occurrence is also a failure to avoid or mitigate risk. It should force a re-examination of the risk list to determine whether the project team may have some systematic blind-spots. As difficult as frank self-assessment is, it may prevent other problems later on.

Risk avoidance

While not always possible, sometimes you can side-step risks altogether. Often risk is caused by poor system scope; if you can reduce the scope of the system (by eliminating non-essential requirements), whole sections of the risk list are removed with the dropped requirements. An equally important risk is not having enough resources (including time) to do the work.

In other cases, technology can be acquired to reduce the risk of building particular functionality, a form of risk avoidance in which one set of risks (that of building the technology) is exchanged for another (that of being dependent upon forces outside one's control).

Finally risks can be transferred to other organizations.