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.
|