Risk response strategies are the basic ways you can handle project risks. They are also one of the areas of project management practice that the PMI updated in the 6th Edition of its Project Management Body of Knowledge (PMBoKⓇ).
So, it seems like a good time to look at this vital aspect of project management in some detail.
In this article, we’ll examine the risk response strategies you have available to you, what they mean, and when you should use them.
Before we get started on risk responses, let’s be sure you are familiar with the basics. Here is a short (3 minute) video that answers the question: ‘What is Project Risk Management?’
This video introduces a four-stage risk management process. It’s at the third stage, ‘Plan’, that we build our risk responses. And we build them from the basic, underlying strategies which I’ll take you through here.
As a reference though, here is a version of the Risk Management Process you will have seen in the video. Because we’ll be taking a look at the PMBoK’s approach to risk responses to, I’ve added its Project Project Risk Management Processes to the diagram.
All the risk responses you can make are drawn from a short list of risk responses strategies. Once you understand these, you can use them to develop detailed responses – the tactical response to your risks.
I suppose this is a bit like asking: ‘how long is a piece of string?’ But there is a reasonable measure of consensus. The strategies it throws up are big, in the sense of representing clear principles.
Up until September 2017, when they published the 6th Edition, PMI documented four strategies in the PMBoK. Now, they have added a fifth.
The PMI’s four original strategies are often referred to as the ‘four Ts’ because, with a small change in wording, they can all be described with an English language word beginning with T.
However, I have always taught six strategies. These map neatly onto the PMI’s four original strategies. Of these, I split two of the four into two each, because I see them as qualitatively different.
I have found that this slightly enhanced classification is better for learning, and more practical for day-to-day risk planning. I have thought long and hard about the new risk response in the PMBoK 6th Edition. In this article, I’ll explain why I don’t think it’s anything new.
Here’s a summary of the comparison of the frameworks, which I’ll describe. At the end of the article, I’ll show how I fit the new PMBoK risk response into the comparison fully.
Here is my assessment of the risk response strategies from which you can build your detailed risk management plans, for each risk.
The first and always the best strategy is to remove the risk. This is the gold standard so, as you may expect; it isn’t easy to achieve. Often, the only way to remove the risk, is to not undertake the risky activity. And that may be your project or a big chunk of it.
I also like the label ‘eliminate‘ for this strategy, but it’s a less familiar word to non-native English speakers. It is a word that PMBoK uses in its description of its ‘Avoid‘ response. And I certainly prefer it to that word, Avoid.
Avoid to me seems too passive. Remove carries the sense that you can not incur the risk (avoid it) or you can take active steps to eliminate it. This means making it impossible to occur, so it’s a big challenge. Note, you can consider this as a subset of ‘Reduce Likelihood’ below, but I don’t think that’s very helpful.
To implement this strategy often needs creative thinking. You usually need to replace one plan, that carries the risk, with an alternate approach. Examples include:
You can view the last two as creating adequate contingency to eliminate the possibility of over-run.
If you accept that you cannot remove the risk, the next strategy is to try to make it less bad, if it happens.
This is the usual meaning of the word ‘mitigate‘. But, as we’ll see below, PMBoK uses the word more widely.
Smaller steps and more frequent testing are typical examples of this strategy, which account for the rise in popularity of Agile methods. Some of these have this approach baked in. reducing complexity and interdependencies also reduced the ‘knock-on’ impacts of a risk materializing.
We define risk in terms of impact and likelihood. So the alternate approach to reducing the threat of a risk is to reduce the probability that it will occur. We can categorize most approaches to this as being either:
There are often rules, procedures, process, or good practice that we can follow. And, often, these are as they are for a reason. Rigorously following them and being diligent in the way we do so is likely to reduce the likelihood of errors and missions. This is one of the reasons I am such a big advocate of templates and checklists.
Secondly, in the presence of a significant risk, caution can reduce the likelihood of it occurring. When there’s a hazard on the road, you slow down, pay more attention, and drive carefully.
PMBoK conflates Reduce Impact and Reduce Likelihood into a single risk response: ‘Mitigate‘. It states (with dreadful English):
In risk mitigation, action is taken to reduce the probability of occurrence and/or impact of a threat
A Guide to the Project Management Body of Knowledge, PMBOKⓇ Guide Sixth Edition, Project Management Institute, 2017.
What if the risk happens, but you don’t have to bear the consequences? Great.
That is the effect of risk transfer; transferring ownership of and responsibility for a risk to someone else.
The generic way to make this happen in an enforceable way is through a contract. This allocates risks and returns to the parties, and is why project managers often contract or sub-contract specialist aspects of their projects.
Some projects also take out insurance on specific risks (the construction industry is an excellent example). Insurance is just a specialized contract where one party receives a payment in advance to bear the financial element of a specific risk. They could also bear other elements of the risk, like schedule, but do so in a way that translates the schedule impact into a financial value. The challenge with all insurance is to value the risk. This means specifying what you want to insure with great precision, and evaluating the value for money of a certain payment now, against recovery of costs if that risk materializes. Insurance is most often used where the impacts are high – at a level where the financial cost would be a severe imposition.
Other examples of contracts or contract terms that transfer risk are:
If something goes wrong, what will you do? You need to stabilize the situation and start to fix some of the problems.
If you plan how you will do this in advance, you have a risk response called a contingency plan. It is also sometimes known as a:
You can also consider contingency in your budget or schedule as part of a contingency plan.
Contingency plans often contain:
Soe risks are not worth worrying about. They may happen, but probably won’t. And, if they do happen, it won’t be a huge deal, and you’ll be able to handle them at the time.
The benefit of investing time and resources in reducing the likelihood or impact, or transferring the risk, or developing a contingency plan is minimal.
Every day of your working (and private) life, you accept many risks. What matters in a project environment is this. You should accept risks only when you have evaluated them, and you conclude that:
In all cases, a contingency plan does not reduce the likelihood or impact of a risk; it merely gives you a guide and resources to deal with that risk if it occurs. So, in a sense, a contingency plan is an enhanced form of accepting the risk and hoping it will be all right. For this reason, the PMBoK does not distinguish it. I think that is sad.
Small risks do not merit the effort of developing a contingency plan. It will often be a lot of wasted work:
The sixth edition of the PMBoK introduced a new risk response strategy: Escalate.
There are two reasons why I reject this as a valid additional strategy. This does not mean that I don’t agree completely with the view that we sometimes need this approach. We do. I just don’t think it’s worthy of being considered a strategy.
This isn’t what the narrative of the PMBoK says about ‘Escalate’. But any casual interpretation suggests it means: ‘I can’t deal with this myself, so I’ll escalate it to someone with more authority, experience, or expertise’.
Of course, you’ll need to do this sometimes. But is this a strategy? I say ‘no’. Rather, it is deferring the choice of strategy until someone else has had a chance to review the threat and make a decision. Their choices are the six strategies above.
The PMBoK actually describes this response as what to do if you and your sponsor agree that the threat is outside the scope of your project, and needs to be dealt with at a higher organizational level. So, you escalate it to them. Or, to re-phrase this… ‘So, you transfer it to them.’
Yup, I reckon this is really just a specific instance of risk transfer. I will accept it’s one I haven’t fully encountered or thought about, so I salute the authors of the 6th Edition for spotting it. (In particular, I expect, Dr David Hilsom.)
But, I don’t feel it merits a separate place in my list of strategies.
So, here is my revised comparison table of Risk Response Strategies…
If you are studying for CAPM, PMP, or any other PMI accredited examination, please be aware of what I have said above, and then stick to the PMI’s preferred structure.
If, on the other hand, you are free of that constraint because you already have your qualifications, don’t want or need them, or have chosen alternative qualifications, then… Consider what I have said, and use the framework that makes the most sense to you!
I’m always keen to read your thoughts and questions. And I will respond to any comments you make, below.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.