Project risk management is what separates good project managers from great ones. Even when everything has been planned and executed to perfection, an unexpected event can cause considerable duress on the project stakeholders and even cause the project to be considered a failure.
Risk management is a three step process:
- Risk Identification
- Risk Analysis
- Qualitative Analysis
- Quantitative Analysis
- Develop Risk Response Plans
The first two steps have been covered here and here. This article will cover the development of risk response plans.
The Four Risk Responses
There are four possible ways to deal with risk.
- Avoid. Eliminate the threat or protect the project from its impact. Here is a list of common actions that can eliminate risks.
- Change the scope of the project.
- Extend the schedule to eliminate a risk to timely project completion.
- Change project objectives.
- Clarify requirements to eliminate ambiguities and misunderstandings.
- Gain expertise to remove technical risks.
- 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. Subcontracting a phase of the work can also transfer risk, but you must ensure the party is capable of handling the risk better than you are.
- 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.
- 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.
Trigger Conditions
Trigger conditions ensure that project stakeholders do not question why a response plan was implemented. Each response plan should have at least one trigger condition. For example,
Risk: Weather makes the haul road impassable.
Trigger: The site foreman drives the haul road each morning and decides whether the haul road is safe for haul trucks
The corresponding response plan might include various measures for moving more material to account for the lack of production during the weather event.
Risk Consequences
Since there are two underlying factors to risk, probability and impact, each risk falls into one of the following four zones:
- 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.
- High Probability / Low Impact: These risks are essentially minor annoyances but their frequency means that actions should be taken to reduce their occurrence.
- 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.
- 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 Register
According to the Project Management Body of Knowledge (PMBOK), a risk register is developed prior to the development of a risk response plan. This is is an itemized list of the important risk events that could affect the project’s critical success factors. The risks are prioritized based on their two underlying elements, probability and impact.
Risk = Probability x Impact
An example risk register would look like this:
| Risk Register | ||||
|---|---|---|---|---|
| ID | Description | Probability | Impact | Risk Score |
| 1 | Haul truck breaks down | 10% | $50,000 | $5,000 |
| 2 | Weather makes haul road impassable | 20% | $50,000 | $10,000 |
| 3 | Truck drivers call in sick | 2% | $20,000 | $400 |
Alternatively, for small projects, the Probability and Impact score can be a 1-10 scale and the Risk Score is a simple multiplication.
Risk Response Plan Example
In the above risk register, Risk #2 is the most important risk, followed by Risk #1 and lastly Risk #3. The necessity of risk response plans is a judgment call dependent on the severity of the risks. Maybe none of the risks need a response plan. But most of the time it is prudent to include at least one. Let’s develop a risk response plan for Risk #2.
- Determine trigger condition: What defines bad weather? Who decides it is bad enough?“Trigger Condition: The site foreman drives the haul road each morning and decides whether the haul road is safe for haul trucks”
- Decide which risk response type to use: Avoid, transfer, mitigate, or accept.Mitigate by re-assigning the haul trucks to move other materials down the highway.
- Develop the response plan: Utilize the checklist above. It must be:
- Cost effective
- Scaled to the magnitude of the risk
- Agreed upon by stakeholders
- Achievable.“The project manager will mitigate the impact of the lack of production by re-assigning the haul trucks to haul other materials that need to be moved but can be moved down the paved highway.”
Note that this response falls into the category of risk mitigation, not avoidance, because there is no change to the project’s scope, schedule, or objectives. Avoidance would be creating a condition whereby the haul road does not have to be used anymore.
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.
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.
