While we can never predict the future with any sort of certainty, having a clear and detailed risk management plan will allow you to see all of the potential outcomes from your decisions and then assess the impact of the various risks that exist to support your decision-making during periods of uncertainty.
Risk management plans are often seen as a box to check by project managers rather than a strategic part of your planning endeavors (if they are done at all!). I’ve seen projects fail because the risk management plan was not taken seriously, or because there wasn’t really any risk management strategy being implemented in the project.
What is a Risk Management Plan?
Simply put, a risk management plan is a document describing how your project team will monitor and respond to unexpected or uncertain events that could impact the project.
You may see the term “risk management plan” shortened to “RMP”, but it hardly has exclusive rights to the acronym: RMP can also refer to the Risk Management Professional certification from PMI or Resource Management Plan in a similar context, so be mindful!
Some organizations like to have vast, convoluted approaches to risk management, but at its core risk management does not need to be complex. You need to analyze the risks that exist in your organization/project and then categorize a risk response and responsible person.
What’s Covered In A Risk Management Plan?
The fidelity of your risk management plan will vary depending on the nature of your project and the standard operating procedures used by the organizations involved.
In general, a risk management plan seeks to answer:
- What is this project, and why does it matter?
- Why is risk management important for the project’s success?
- What will the team do to identify, log, assess, and monitor risks throughout the project?
- What categories of risk will we manage?
- What methodology will be used to evaluate risk severity?
- What is expected of the people who own the risks?
- How much risk is too much risk?
- What are the risks, and what are we going to do about them?
The tricky bit is that, depending on the project, this document could be hundreds of pages or it could be less than a dozen.
We did a workshop on managing risk—DPM Members can access it here.
So how do you decide how much detail to provide? Here are two illustrative examples (but by no means are they the only ways to do it!).
Risk Management Plan Examples
A Simple Example: Lightweight RAID Log
In its most minimal form, a risk management plan could be a handful of pages describing:
- how and when the risk will be assessed
- the roles and responsibilities for risk owners
- at what point the project risk should trigger an escalation
This is what a basic example of a risk management plan could look like.
Instead of a formal risk register designed to calculate risk severity, a lightweight risk management approach may simply maintain a list in your weekly status report.
This list (also known as a RAID log) usually tracks Risks, Assumptions, Issues, and Dependencies for the team and your sponsor to review and discuss.
Here’s an example RAID log showing how it’s used to tracks Risks, Assumptions, Issues, and Dependencies.
When to use it: this approach could be useful for a small non-technical project being executed by a team of 3-4 people in an organization that does not have a standard approach to risk management.
Related: What Are RAID Logs? Expert Template + Easy Example
A More Complex Example: Heavy Duty Risk Matrix
When an organization already has a culture of risk management, there may be a template to follow that demands a high level of detail. These details may include a full description of the methodology that will be used to perform a combination of qualitative and quantitative risk analysis as well as an impact matrix.
An impact matrix, also called a risk assessment matrix, shows the relationship between risk factors in calculating risk severity (e.g., risks that are high-probability and high-impact are the most severe).
Here’s an example of an impact matrix, also called a risk assessment matrix. It shows the relationship between risk factors in calculating risk severity.
Often, the risk register template will be designed to prioritize and provide a numerical severity score to each risk as it does in the template I have provided below.
- Additionally, you may need to create a Risk Breakdown Structure to decompose higher-level risk categories into smaller, more specific risk subcategories.
Here’s an example of a Risk Breakdown Structure. The higher-level risk categories are broken into some common smaller, more specific risk subcategories.
When to use it: making a detailed RMP isn’t about creating complexity for complexity’s sake—you and your team will be glad to have this level of detail on a large enterprise project that involves larger teams, multiple stakeholders, and high stakes that could have a significant impact on the business.
There are some great options available for managing risk in your project. Excel templates remain favored in a lot of organizations but there are also some online providers who can also support risk management planning. Two examples of risk management software are Wrike and Monday.com. These tools integrate the entire risk management process with the wider project management plan.
The most important thing is not necessarily the document itself, but the discussions you’ll have with your team and your project sponsor about navigating risks and giving your project the highest likelihood of success.
The Digital Project Manager is reader-supported. When you click through links on our site such as the software links above, we may earn a commission. Learn more.
Risk Management In The Project Management Process
When to create a risk management plan in your projects?
In terms of sequencing, you should be creating your risk management plan:
- after you have started defining your project management plan, and
- before the project begins so that everyone can get on the same page about the processes and expectations.
The plan should be approved by the project sponsor, seeing as they are accountable for the project.
Risk assessment—identifying and assessing the risks themselves—should be done by your team members and project stakeholders.
Ideally, you do this together in a risk identification workshop, which I have described below. Potential risks should then be continually identified, assessed, and monitored throughout the project life cycle.
Risk Management in Real Life
Admittedly, the word “risk” is itself a bit broad. Not having enough resources to hit the project deadline is a risk. Hurricane season is a risk. Disruption of the space-time continuum is a risk.
So, where do you draw the line on what types of risks to consider—which risks have a large enough potential impact to require attention, or even a contingency plan?
My answer:
If it is related to people, processes, resources, or technology and has any likelihood of threatening project success, it should be logged.
Now, you might not need to do a full analysis of every risk in your risk register, but you do need to revisit the risks and monitor them throughout the project. If someone starts testing a time machine near your office, your highly unlikely space-time continuum risk just escalated.
Does all of this matter?
Yes. To prove it, here’s a simple example of risk management that I’ve seen save a project:
A colleague was working on a service design project that required in-person research (this was before COVID-19), and on her RACI chart she had clearly communicated to the client that it was the client’s responsibility to book a space for this research. She had logged a risk with her team that the client might not be able to secure a space.
Two days before the research commenced, the client informed her they weren’t able to secure the space. Luckily, her risk mitigation strategy on this particular risk was to book a backup space at the office, which she had done weeks ago.
Something that could have stalled the project for weeks had become nothing more than an email that said something like “All good, we’ll use our space.”
This is what it feels like to have a great risk management plan in place.
Here’s another risk event example:
An agency had agreed to an aggressive timeline for a highly technical project. The team had raised concerns as the project was being initiated, but leadership still wanted to proceed. The PM and Technical Architect logged the timeline risk before the project started, and their risk response strategy was to re-evaluate the project timeline using a Monte Carlo simulation.
After calculating a pessimistic, optimistic, and likely duration for every project activity on the critical path, they determined mathematically that the project had a 3% chance of hitting the deadline.
The PM raised this with the client, and the client agreed to rescope the project and re-baseline the project before getting going. It was literally too big of a risk for them to take.
You can use a Monte Carlo simulation and other risk analysis tools to alter the course of a risky project before it gains too much momentum.
Step-by-Step: How To Make a Risk Management Plan
Okay, so how you go about making a project risk management plan could vary depending on the type of project you’re embarking on, but generally speaking the steps are as follows:
1. Get your supporting documents in order
- Project Charter: among other things, this document establishes the objectives of your project, the project sponsor, and you as the project manager. Frankly, it gives you the right to create a project management plan and then a risk management plan within that. If formal project charters aren’t used at your organisation, you should at least have this documented in an email or a less formal brief.
- Project Management Plan: Not to be confused with the Project Plan, this document outlines at a high level how the project will be managed, monitored, and controlled—what methodology will be used, how will progress be reported, what is the escalation chain if the project moves outside of its controls, etc. Your risk management plan should act as a subcomponent of the project management plan.
- Stakeholder Register: it’s always good to have a solid idea of who the project stakeholders are before thinking about risk. The reason is that each of these stakeholder groups will present a different set of risks in terms of people, processes, and technology. They can even be invited to identify risks throughout the project and can also sometimes become risk owners!
2. Frame up the context
- Take the project description and objectives from the project charter and frame the business value of the project and the negative impact of the project not succeeding.
- Describe the intent of the document and refer back to the project management plan as the overarching document.
- Use this context to drive a conversation about risk management with your team and your project sponsor.
3. Decide with your team how you will identify and assess risks
- Different methodologies will be appropriate for different types of projects.
- The methods you choose also need to be sustainable for the team to do throughout the project.
- The key here is to have the right discussions and gather input to build consensus with your team and your stakeholders early on.
- Use your discussions to agree on risk categories, types of risk responses, and ways to calculate risk severity.
4. Start identifying risks (and continue to iterate on it!)
- Okay, now the fun begins: thinking about all the things that could go astray during your project!
- A great way to do this is using a Risk Workshop – a group session involving your team, key stakeholders, project sponsor, and SMEs to identify, evaluate, and plan responses to risks.
- In the example below, I have used a simple overview of a sample project. During the workshop, we will discuss everything in columns E-R and make sure that we have clear, SMART outcomes to put in each of the boxes. I like to keep a copy of the risk register on my desk during the workshop to make sure that each column is discussed and filled in on the post-it. After the workshop, you will detail out any items to complete the document fully.
Tab C is the risk register and the core information of the entire document
- As a project manager, I try to act as a facilitator in risk workshops to be able to support the attendees in thinking through the risks that exist but also to look at risks they may not have considered. It could look something like this:
Here are some examples of risks that the project team or client may not have considered.
- In the example below, I have used a simple overview of a sample project. During the workshop, we will discuss everything in columns E-R and make sure that we have clear, SMART outcomes to put in each of the boxes.
- I like to keep a copy of the risk register on my desk during the workshop to make sure that each column is discussed and filled in on the post-it. After the workshop, you will detail out any items to complete the document fully.
- An important result of a workshop is ensuring that not only we have a list of risks available but that all stakeholders are aligned on what the risks are, what the risk response is, and the impact that this is likely to have on the project. It’s critical to spend this time with the stakeholders so that you can also get buy-in from them to have a successful project.
5. Assign risk owners
- As you identify risks, you should work with the team to assign owners. Just because you are the project manager doesn’t mean you own all the risk responses!
- That being said, this accountability and risk response can be the most difficult area of risk management to finalize as you’re reliant on people taking accountability for their task.
- Make sure that all risk owners are clear on their responsibilities and have read the RMP.
6. Populate the risk register
- Once you have completed the workshop, I recommend taking photos of all of the papers/outcomes so that you have a visual record and not just sticky notes available.
If you’ve filled out sticky notes to help fill in your risk register, take a picture of them just in case for future reference.
- It might seem logical but filling out the risk management template can be more complex than initially thought. I recommend taking each line item as its own isolated item and looking at the key areas: Description, Risk response category, Risk Response, and Risk Owner before looking at wider correlations that might exist between risks.
Make sure you log each risk and key details about the risk.
- Once you’ve broken this down, you’re able to enter each item and make it fully descriptive and SMART (Specific, Measurable, Accurate, Realistic, Time Specific). This also allows you to also find any ‘weaknesses’ that might exist in any of the identified risks and rectify it.
- What’s important to remember during this exercise is ensuring that the Risk Response is reflective of the severity and importance of the risk.
7. Publish the risk register
- I send around the updated risk register within 48 hours of the workshop to give everyone time to read and process the output.
- This can also be used within wider Project discussions to explain or define the timeline for the project or specific actions that need to be completed. It’s important to be timely so that the output can be used in other project artifacts.
8. Monitor and assess risks continuously throughout the project
- New risks are introduced to a project all the time. In fact, mitigating one risk might create another risk or leave “residual risk”.
- If feasible within your project constraints, try to run your risk workshops periodically throughout the duration of the project or incorporate risk register reviews into other recurring planning activities.
- Nothing feels quite as deflating as when you swerve to avoid one risk only to drive blindly into another, much bigger risk.
9. Archive your RMP in a reusable and accessible format
- After your project, it’s a good idea to archive your RMP for future reference. There are many reasons why (in fact, it may be mandatory in your organisation), but here’s the main one for me: while not every RMP will suit every project, some of the risk and response strategies will still be applicable. Use past project risks to create a foundation for your next project.
Risk Register Template
There are a lot of risk register templates available online and I would recommend looking at one that fits your needs rather than one that includes every possible scenario.
In the risk management plan template available in DPM Membership, I’ve tried to keep the entire risk register as simplistic as possible to ensure that you’re able to enter the relevant information for your project.
Tab A is the Cover Sheet. This is purely for housekeeping purposes and enables you to keep a track of the project, owner, and versioning.
Tab B provides some advice for filling in the risk register
Tab C is the risk register and the core information of the entire document
Tab D are open questions. I like to use this tab during the workshop to enter open questions/areas needing clarification.
Tab E is purely administrative.
What Do You Think?
Whether you’re a novice project manager or a seasoned pro, having a good risk management plan is vital to your project success, and reviewing the basics of risk management is important for this. The key to a successful risk management plan is adaptability. You need to make sure that with every project you run, you can adapt the risk management plan to the project and industry that you are working in.
If you’ve got a great story about a risk you mitigated successfully on your project or a different way to manage risk, please share it in the comments below!
Related Listen: What's A RAID Log (And How To Integrate One Into Your Project Workflow)
1 Comment