Creating Risk Response Plans

In a proper project risk analysis, once the risks to the project have been identified (step 1), their probability and impact given a value and an overall priority (step 2), risk responses are drawn up (step 3).

For each response plan, trigger conditions should be identified.  These are the conditions that warrant the implementation of the response plan.  For example, an oil well fracking project might have as a trigger condition:

“An oil price below $50/barrel for 3 days”

The corresponding response plan might include various cost saving measures aimed at keeping the well economic.

Scale to the Project

The risk management plan needs to scale to the project.  For small projects it might not be a necessity to have any response plans drawn up during project planning.  For medium sized projects several risk response plans might be developed.  And for megaprojects there are usually multiple response plans that have been well researched and communicated to the project team.

When you Need a Risk Response Plan

A proper risk management plan does not need to include response plans for all risks within the risk register.  The risk register contains all risks that are significant enough to warrant tracking and monitoring.  It is not feasible nor necessary to develop response plans for every one.

All risks fall within a continuum.  On the one extreme it does not affect the project enough to warrant tracking and monitoring.  In the middle, the event should be tracked and monitored but response plans do not need to be developed in advance.  And on the other extreme, the risk is substantial enough that a response plan needs to be developed.

Generally, risk response plans are required for risks that are high in both probability and impact.  For example, a nuclear power repair project might have response plans developed for radiation exposure events.

Four Risk Responses

There are four possible ways to deal with risk.

1. Avoid.  Eliminate the threat or protect the project from its impact.  Here is a list of common actions that can eliminate risks.
   1. Change the scope of the project.
   2. Extend the schedule to eliminate a risk to timely project completion.
   3. Change project objectives.
   4. Clarify requirements to eliminate ambiguities and misunderstandings.
   5. Gain expertise to remove technical risks.
2. Transfer.  This involves moving the impact of the risk to a third party.  Direct methods might be through the use of insurance, warranties, or performance bonds.  Indirect methods such as unit price contracts instead of lump sum (or vice versa depending on which side of the contract you’re on), legal opinions, and so forth.
3. Mitigation.  Reduce the probability or impact of the risk.  This is not always possible and often comes with a price that must be balanced against the value of performing the mitigating action.
4. Accept.  All projects contain risk.  As a minimum, there is the risk that it does not accomplish its objective.  Thus stakeholders, by definition, must accept certain risks.  Accepting risk is a strategy like any other, and should be documented and communicated like any other strategy.  Risk acceptance can be passive, whereby the consequences are dealt with after the risk occurs, or active, whereby contingencies (time, budget, etc.) are built in to allow for the consequences of the risk to the project.

The four risk response strategies can be applied to overall project risk as well.

Risk Consequences

Since there are two underlying factors to risk, probability and impact, each risk falls into one of the following four zones:

1. Low Probability / Low Impact:  These risks are low on the priority scale, and some of them can be removed from the risk register if there is little value in focusing on them any longer.
2. High Probability / Low Impact:  These risks are essentially minor annoyances but their frequency means that actions should be taken to reduce their occurrence.
3. Low Probability / High Impact:  These risks generally need to be analyzed to ensure they do not occur.  Any road blocks or potential trigger factors should be addressed during project planning to reduce their likelihood of occurrence to zero, or as close to zero as possible.  An example is the previously mentioned nuclear reactor maintenance project, where the chance of nuclear radiation leak is already low but it would be prudent to attempt to find and eliminate even the small potential trigger points.
4. High Probability / High Impact:  When these risks exist, they are usually known to the stakeholders and an integral part of the decision to initiate/fund the project.  An example is potential traffic impact risk on a large freeway paving project.  However, if the risk analysis step turns up one of these which is not necessarily known to the project sponsor(s) or stakeholders, communication is essential.  Usually these types of risks can pose serious, even existential, threats to the project, therefore they almost always require action on the part of the project manager during project planning to make sure stakeholders understand the project risks.

Parts of a Risk Response

There is no one correct way to generate a risk response, but here are several principles which can be used as a guide.  The risk response should be:

• Cost effective relative to the significance of the risk
• Scaled to the magnitude of the risk
• Agreed upon by the applicable project stakeholders
• Achievable and realistic

Implementing a risk response plan requires the appropriate levels of time and funding.  This should be planned for in the project budget or another strategy developed to ensure the project does not go over budget or behind schedule because of unforeseen events.

After planning risk responses, changes to other areas of the project management plan could be necessary, such as schedule, cost, and scope.

Risk Communication

Communication during a crisis can be more important than the response itself.  Therefore, because the strength of the response to an unexpected event is often judged on communication, it is important that the risk register and response plans be communicated to the applicable stakeholders.

Because of this, the risk register and response plans should be communicated to the appropriate stakeholders in advance, i.e. during project planning.  Then, when an unexpected event occurs the stakeholders will not only be more supportive of the response, but the final judgment will be much more favorable.  The project manager will be off to a running start.