Project risk management is what distinguishes good project managers from great ones. Even if everything has been meticulously planned and executed, an unexpected event can put significant strain on project stakeholders and even cause the project to be considered a failure. In this article, we will explain everything about risk response planning in project management.
Risk management is a three-step process:
- Risk Identification
- Risk Analysis
- Qualitative Analysis
- Quantitative Analysis
- Develop Risk Response Plans
Four Risk Response Planning
- Avoid. Remove the threat or shield the project from its consequences. Here is a list of common risk-reduction actions.
- Change the project’s scope.
- Extend the timeline to eliminate the risk of project completion being late.
- Change project objectives.
- Clarify requirements to avoid ambiguity and misunderstandings.
- Gain expertise to remove technical risks.
- Transfer. This entails shifting the risk’s impact to a third party. Insurance, warranties, and performance bonds are examples of direct methods. Indirect methods include unit price contracts rather than lump sum payments (or vice versa depending on which side of the contract you’re on), legal opinions, and so on. Subcontracting a portion of the work can also transfer risk; however, you must ensure that the party is capable of handling the risk better than you are.
- Mitigation. Reduce the risk’s likelihood or impact. This is not always possible and frequently comes at a cost that must be balanced against the value of the mitigating action.
- Accept. Every project involves some level of risk. At the very least, there is a chance that it will fail to achieve its goal. As a result, stakeholders must accept certain risks by definition. Accepting risk is a strategy just like any other, and it should be documented and communicated just like any other strategy. Risk acceptance can be passive, in which the consequences are dealt with after the risk occurs, or active, in which contingencies (time, budget, etc.) are built in to allow for the consequences of the risk to the project.
Trigger conditions ensure that project stakeholders do not wonder why a response plan was put in place. At least one trigger condition should be included in each response plan.
The site foreman drives the haul road every morning and determines whether it is safe for haul trucks.
To compensate for the lack of production during the weather event, the corresponding response plan could include a variety of measures for moving more material.
Because risk has two underlying factors, probability and impact, each risk falls into one of four categories:
- 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 no longer a reason to focus on them.
- High Probability / Low Impact: These risks are essentially minor annoyances, but their frequency necessitates action to reduce their occurrence.
- Low Probability / High Impact: In general, these risks must be assessed to ensure that they do not occur. Any potential roadblocks or trigger factors should be addressed during project planning in order to reduce their likelihood of occurrence to zero, or as close to zero as possible. For example, consider the previously mentioned nuclear reactor maintenance project, where the likelihood of a nuclear radiation leak is already low, but it would be prudent to seek out and eliminate even minor potential trigger points.
- High Probability / High Impact: When these risks exist, the stakeholders are usually aware of them, and they are an integral part of the decision to initiate/fund the project. A potential traffic impact risk on a large freeway paving project is one example. However, if the risk analysis step uncovers one of these that is unknown to the project sponsor(s) or stakeholders, communication is critical. Because these types of risks can pose serious, even existential, threats to the project, they almost always necessitate action on the project manager’s part during project planning to ensure stakeholders understand the project risks.
Parts of a Risk Response in Planning
There is no single correct way to generate a risk response planning, but the following principles can serve as a guide. The risk response planning should be as follows:
- Cost-effective in relation to the significance of the risk
- based on the magnitude of the risk
- Agreed upon by the applicable project stakeholders
- Achievable and realistic
Implementing risk response planning necessitates adequate time and funding. This should be budgeted for in the project budget or another strategy should be developed to ensure that the project does not go over budget or behind schedule due to unforeseen events.
Changes to other aspects of the project management plan, such as schedule, cost, and scope, may be required after planning risk responses.
A risk register is created before developing a risk response plan, according to the Project Management Body of Knowledge (PMBOK). This is a detailed list of the major risk events that could have an impact on the project’s critical success factors. The risks are ranked according to their two underlying components, probability, and impact.
Risk = Probability x Impact
When you Need a Risk Response Plan?
A proper risk management plan does not have to include response plans for every risk on the risk register. All risks that are significant enough to warrant tracking and monitoring are listed in the risk register. It is neither feasible nor necessary to create response plans for each individual.
Every risk exists on a scale. On the one hand, it does not have a significant enough impact on the project to warrant tracking and monitoring. The event should be tracked and monitored in the middle, but response plans do not need to be developed ahead of time. On the other hand, the risk is significant enough that a response plan is required.