What goes into a project risk management plan?

 

This article is part six of my look into project risk management, and today the topic is the project risk management plan.

Read part 1 here: An introduction to risk management

Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)

Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)

Read part 4 here: Tailoring Risk Management

Read part 5 here: Planning Risk Management

So: risk management plans. What should you expect to see in one?

Here are some things you can include in your risk management plan. You don’t always need all of them – good project management is all about tailoring, so pick and choose what is appropriate and necessary for your project.

Risk strategy

This is a statement about the general approach you are taking to managing risk on the project. You can reference any organisational guidelines, the risk appetite of the company and the business context for risk management.

Methodology

The methodology section is where you define the specific way you are going to manage risk on the project. That includes the approaches you will use, any software tools or other tools that are available to you and that you’ll use, and the places you’ll get data from to make decisions about risk actions and planning.

Include information about tracking risks: how will this be done? How will you record what has happened and how will adherence to the process be audited (if it will)?

Roles and responsibilities

I think it’s always useful to have this section in the risk management plan, even if you refer to the main roles and responsibilities document or a different place in the project management plan. I think it helps to know who is responsible for what, and for everyone to see that it is everyone’s responsibility to be on the look out for new risks.

Document who is going to lead risk management, any supporting roles, and who else is ‘hands on’ with the risk management process. Explain what their responsibilities are.

Risk budget

It’s also handy to record the project funding available for risk management (if you are lucky enough to have a dedicated risk budget). I think it’s worth calling out even if there is no dedicated risk budget, because it makes it clear to  senior execs and the project sponsor that managing risk takes money, and if there is none, there’s a limit on what you can usefully do to avoid or mitigate the risk.

In this section you’ll want to talk about how you can access the risk budget – because let’s be positive and assume there is one – and how the funding will be tracked and reported so you can see when it’s running out.

Timing and reporting

Write a short section that talks about how often you’ll do risk management reviews, when each part of the process takes place and how risk management is woven into your project schedule. I would include formal risk workshops in here, alongside a formal monthly risk review, while noting that risk management is an ongoing activity bound into everything else we do on the project.

You can also record how and when risk reporting is going to be done, and what is going to be included in the risk reports. I would mention what level of risk is going to be reported in each place. For example, in Steering Group meetings I would report every significant risk. In monthly project reporting, the template we used to use only had space for the top 3 risks.

Categorisation of risk

Finally, document how you are going to categorise risk on the project. You might already have organisational-wide definitions and categories, in which case you should use them. If you don’t, you can easily make up some categories. Things like Technical, Commercial, Reputational, Environmental etc are all common categories. Think about what the project is trying to achieve and what departments are involved, and that can be the basis for your categorisation. I would start with a simple list and allocate each risk to one category only.

If you want to get a bit more detailed and dive into risk management further, you can create a risk breakdown structure which is a useful way of grouping risks and seeing how they interact and relate to each other.

Risk appetite

Include a statement about how much risk the project (or organisation) is prepared to accept. You’ll get this either from ‘official’ company sources or from the project sponsor.

Remember that risks can aggregate together: lots of small, insignificant risks can make for one massive problem if they all happen at the same time.

Definitions and matrix

Include definitions of how you calculate probability and impact. It’s really important that everyone understands what these two concepts are and then what the different levels mean. Ideally, you should have this at PMO level if not organisational level, because then you can more easily comparer the risk profile of different projects.

Alongside your definitions, include the probability and impact matrix that helps you assess the risk score. Or link to where it can be found – there’s no need to reinvent the wheel or create lots of additional pages in your documentation, just reference the PMO documentation if there is any.

Pin for later reading: