Please Share

Risk Response Strategies: Full Roundup

Risk Response Strategies

Risk response strategies are the basic ways you can handle project risks. They are also 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.

PMI Talent Triangle - Technical Project Management

In this article we’ll examine the risk response strategies you have available to you, what they mean, and when you should use them.

Introducing Project Risk Management

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.

The Risk Management Process

The Risk Management Process

Planning your Risk Responses

Low priority risks may merit a single risk response. Larger, more serious risks will need a basket of responses. Click To Tweet

All the risk responses you can make are drawn from a sport list of risk responses strategies. Once you understand these, you can use them to develop detailed responses – the tactical response to your risks.

How many Risk Response Strategies are there?

Risk Response Strategies

Risk Response Strategies

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 planing. 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.

Project Risk Response Strategies - with new strategy

Project Risk Response Strategies – with new strategy

The Six (or Seven?) Risk Response Strategies

Here is my assessment of the risk response strategies from which you can build your detailed risk management plans, for each risk.

1. Remove the 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-ative 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 to o 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:

  • Doing things in a different way
  • Using alternate materials, specifications, process
  • Strengthening processes for defining, panning, quality assurance and control, or communication
  • Scheduling significantly more time to remove schedule risk, or
  • Providing significantly greater resources or budget, to remove budget risk

You can view thee last two as creating adequate contingency to eliminate the possibility of over-run.

2. Reduce Impact

If you accept that you cannot remove the risk, then 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.

3. Reduce Likelihood

We define risk in terms 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:

  • diligent, or
  • cautious

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 ore attention, and drive carefully.

The PMBoK’s ‘Mitigate’ Strategy

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.

4. Transfer the Risk

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:

  • Performance bonds
  • Guarantees
  • Penalty clauses (not legal in some jurisdictions)

5. Contingency Plan

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:

  • fallback plan
  • plan B
  • recovery plan

You can also consider contingency in your budget or schedule as part of a contingency plan.

Contingency plans often contain:

  • processes, steps or checklists
  • roles and sometimes allocation of them to key individuals
  • resources or pointer to where you can find them easily
  • essential information like contact details, locations of isolation switches, or medical records

6. Accept the Risk

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:

  1. The level of the threat is sufficiently low, and
  2. the value for money of any of the other risk responses is too low, compared to the scale of the threat.

The PMBoK’s ‘Accept’ Strategy

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:

  • if a load of risks are highly unlikely, you would be do a lot of contingency planning, little of which would ever be needed
  • If a load of risks have very low impact, then contingency plans would have little value, as you could always design your response at point of impact.

7. PMBoK 6th Edition’s ‘Escalate’ Strategy

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.

The first case

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 second case

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 revise comparison table of Risk Response Strategies…

Project Risk Response Strategies - with new strategy integrated

Project Risk Response Strategies – with new strategy integrated

Important Note

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 most sense to you!

Other Articles You may Like

What are Your Thoughts?

I’m always keen to read your thoughts and questions. And I will respond to any comments you make, below.


About the Author Mike Clayton

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 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.

follow me on:
WordPress Security