Mitigating project risks just may be the wrong strategy. With the release of the latest version of the PMBOK® Guide from the Project Management Institute (PMI®) comes a change to the response strategies that have been in use since risk was introduced as a knowledge area in the 1996 First Edition.
Throughout the last five releases, these strategies had remained the same, while most people still did not comprehend how to properly put them to use and tended to favor one above all the rest. We will attempt to demystify a bit around the risk resolution strategies that are available, going beyond mitigation.
Ask anyone, “What are you going to do about this risk if it were to occur?” and most will tell you that they will mitigate the risk. In my experience, during the process of planning for risk responses, mitigation is, in fact, the risk response strategy used over 80% of the time, wrongly or not.
Teaching risk management at a college level, I hear it all the time in a variety of forms.
- Where can I find a mitigation plan?
- How do I mitigate this or that risk?
My favorite one? The fact that we see a mitigation column in the risk register and not a response strategy column.
According to the PMBOK® Guide (6th Edition), there are five risk strategies for dealing with each threats and opportunities in risk management. In an article to follow in the near future, I will discuss the issue for most people with threat and opportunity recognition but for the time being, let’s look at threats and how mitigation fits in predominantly.
Mitigating risks could be the wrong strategy
Why? In dealing with risks that are a threat to your project, you could be missing these four other possible response strategies.
Escalate has been added to this list with this new edition of the PMBOK® Guide and basically deals with risks that are out of the normal control of a project manager. This might have a greater impact than just to the project itself. This response was needed for risks that need to be escalated outside of the project, potentially beyond even the sponsor. Think of risks that could impact an entire organization stemming from a project having to be resolved or examined from a different perspective. This response strategy has become necessary as there is much more riding on projects now then there used to be, and the connection to the nervous system of an organization is often exposed. Think of privacy risks, reputational risks, and operational risks whereby they are not within a project manager’s role to make the decision. Escalation can be used in cases of both threats or opportunities.
The rest of the responses follow the introduction of risk as a knowledge area in the body of knowledge of 1996 or the First Edition of the PMBOK® Guide.
In avoiding risks, teams typically try to eliminate the source or cause of the threat, therefore taking away what is often a large threat to the project. This does not mean that you are taking away all of the risk, you have avoided head-on confrontation which will often mean that you will have a lesser or different impact on the objectives.
In accepting the risk, the team looks at the impact and the work that would need to be done in order to deal with the risk and makes a passive or active decision around how to best keep control without too much work. One cannot accept high-level risks, which implies that risks that are accepted are within a defined threshold set by the organization around the risks.
Transfer is a bit misunderstood if not explained properly and is often confused with sharing, which is used to deal with opportunity risks. Transfer is actually simple if you define it in this manner, strategy used to transfer the burden of a risk to another entity or group. Associated with transfer is buying of insurance, bonds and “expertise” to ensure that we are covered for certain risks for which we could not otherwise be able to deal with. An issue that often occurs with the transfer of a risk is the fact that it will more than likely create a secondary risk by employing other resources and having to now manage those as part of your plan. Transferring risks can be a double-edged strategy where caution and control should be used.
Finally, we have the last strategy, mitigation. That word just flows off the tongue, doesn’t it? People seem to love to use mitigation for responding to risks so much so that they often neglect to look at other strategies that might be much more favorable to the project’s outcomes. Mitigation in real life is a common response strategy as it is meant to lessen either the impact or the probability of a risk which would be considered too high for the project. In some cases, mitigation is used first followed by acceptance or transfer if the risk still needs to be responded to and dealt within a threshold specific level.
So, from this short review of risk response strategies, I hope that you can go beyond mitigating everything in site and can propose some other ways to deal with risks on your project. Mitigation is nice but it should get a day off once in a while especially if other responses are available and applicable.