Every Project Management Risk Response Strategy: Are there 6, 7 or more?

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^Ⓡ Guide) and retained in the 7th Edition.

So, it seems like a good time to look at this vital aspect of project management in some detail.

Oh, and not to brag, but the previous edition of this article won a prestigious award…

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 Guide’s approach to risk responses to, I’ve added its Project Project Risk Management Processes to the diagram.

Planning your Risk Responses

All the risk responses you can make are drawn from a shortlist of risk response 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?

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.

Project Management Institute’s Risk Response Strategies

Up until September 2017, when they published the 6th Edition, PMI documented four strategies in the PMBOK Guide. 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.

Buy the current (7th Edition) of the PMI’s ‘Guide to the Project Management Body of Knowledge’.

My Approach

However, I have always taught six strategies. These risk management strategies 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 that PMI introduced in the PMBOK Guide 6th Edition. In this article, I’ll explain why I don’t think it’s anything new.

PRINCE2 and Risk Response Strategies

Another Framework is PRINCE2. That has 6 strategies. These are slightly different from my six, so I’ll need to explain those, as well.

Buy the current edition of the PRINCE2 Manual, ‘Managing Successful Projects with PRINCE2’.

But, to start, 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.

The Six (or Seven, or Eight?) 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-native English speakers. It is a word that the PMBOK Guide 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.

Implementing 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, processes, or technology
• Strengthening processes for defining, planning, quality assurance and control, or communication
• Scheduling significantly more time to remove schedule risk, or
• Providing significantly greater resources or budget, to remove the budget risk

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

2. Reduce the Impact

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, the PMBOK Guide uses the word more widely.

Smaller steps and more frequent testing are typical examples of this strategy, which account for the rise in the 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 the Likelihood

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:

• diligent, or
• cautious

There are often rules, procedures, processes, or good practices 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.

The PMBOK Guide’s ‘Mitigate’ Risk Response

PMBOK conflates Reduce Impact and Reduce Likelihood into a single risk response: ‘Mitigate‘. It states (using 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 pointers to where you can find them easily
• essential information like contact details, locations of isolation switches, or medical records

6. Accept the Risk

Some 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 the:

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

The PMBOK Guide’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 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 the point of impact.

7a. PRINCE2’s ‘Share’ Risk Response

The PRINCE2 manual, ‘Managing Successful Projects with PRINCE2’ is clear about what its authors intend:

Share is an option that is different in nature from the transfer response

Managing Successful Projects with PRINCE2
Axelos, 2017

It is about sharing the risk (or opportunity) among multiple parties – often contracting partners or parties within a part of the supply chain.

As a principle, this can lead to excellent collaborative results, but it is hard to achieve and so, as the PRINCE2 authors suggest, this risk response strategy is rare.

This rarity, however, whilst a contributing factor, is not the reason why I choose to see this as a variant within the wider category of ‘Transfer’. Effectively, by sharing a risk, you are transferring part of it. So, risk sharing is partial risk transfer.

Insurance as Partial Risk Transfer… ‘Sharing’

The commonest example that people cite for risk transfer is insurance, as I discussed above. But think about what happens when you insure, say, against a motor vehicle accident…

Let’s, for the moment, set aside the fact that most insurance policies carry an excess, which means the claimant needs to accept the first portion of the financial loss.

If you have a motor vehicle accident, you insurance covers you for the financially quantifiable losses at best. You still have to accept other losses, like pain, inconvenience, distress… So, you do not transfer all this risk to your insurer. You simply share the total risk, with them accepting the bulk of the financial risk.

So, I don’t feel ‘Share‘ merits a separate place in my list of strategies.

7b. PMBOK Guide’s ‘Escalate’ Risk Response

The sixth edition of the PMBOK Guide 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 Guide 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 Guide 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 ‘Escalate‘ merits a separate place in my list of strategies.

So, here is my revised comparison table of Risk Response Strategies…

Important Note #1: Risk Responses ‘Share’ & ‘Escalate’

In the figure above, I have shown PRINCE2 ‘Share’ strategy and the PMBOK Guide’s ‘Escalate’ strategy as being on the same ‘line’. Please do not read this as implying that I think they are equivalent. I do not. I have done this merely as a graphical short-hand to simplify the image. As I hope is clear above, these are two different approaches to managing risk.

Important Note #2: Qualifications

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.

Likewise, if you are studying for PRINCE2 Foundation, Practitioner, or any other related Axelos examination, please be aware of what I have said above, and then stick to the preferred structure in the official manual.

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!

Other Articles You May Like, related to Risk Response Strategies

• How to Build a Robust Project Risk Culture [8 Steps]

• The Project Manager’s Guide to Simple Risk Analysis

• How Project Risk Management will Make You a Better PM

• Indispensable Guide to the Sources of Project Risk
• Hear Risk Management Explained on this short Podcast

Bonus Extra Video…

What are Your Thoughts?

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