Jory MacKay on April 03, 2020 7 Steps to Write a Risk Management Plan For Your Next Project (With Free Template!)
🎁 Bonus Material: Free Risk Management Template
When you fail to plan, you’re planning to fail. As a project manager, you of all people know the truth of this old adage. Poor planning is at the root of most project failures. But while it’s easy to plan for positive outcomes (like milestones, OKRs, and success metrics), it’s not always easy to plan for the worst.
We’d all like to think that our project will go smoothly. But ignoring potential risks isn’t just being overly optimistically. It’s downright dangerous. In fact, nearly ⅓ of all project failures are due to undefined risks!
A project risk management plan is a document that helps you identify, evaluate, and plan for potential issues that could come up during your project. It’s like a roadmap that shows you every pothole and accident-prone corner on your path so you can avoid, re-route, or, at the bare minimum, be ready for whatever’s coming your way.
In this post, we’re going to dig into the specifics of creating a project risk plan and then provide you with a free project risk management plan template you can use on your own projects today.
Read our other documentation guides and plans:
The basics: What is risk management, anyway?
In the most basic terms possible, a risk management plan is a document used by project managers to identify potential risks to the project, estimate the impact and the probability of them happening, and then define responses.
That’s the technical description. But it misses a few nuances that explain just why risk management is so important to project managers.
First off, it’s important to remember that risks aren’t all bad. A risk is simply a moment of uncertainty. You don’t know for sure what will happen, and the potential outcomes can be positive or negative.
Risks can be uncertainties in scope, schedule, cost, or quality. The point of creating a risk management plan is to identify those moments and create a system to maximize the positive impacts (and mitigate any potential negative ones!)
But this is easier said than done.
It's easy to fall victim to cognitive biases. A reliable risk management plan shouldn't.
For one thing, studies have found that we overestimate our ability to influence events that are heavily determined by chance. In other words, we think we have more control over uncertainties than we actually do.
You can blame cognitive biases (mental shortcuts that influence our thinking) for this problem. More specifically, when imagining the outcomes of a project, it’s easy to fall victim to:
- Anchoring: When we give too much value to readily available information instead of thinking about less-likely outcomes. (i.e. you only think about the risks you faced on a previous project and not other ones).
- Confirmation bias: When we value information that aligns with our current position and de-value anything that contradicts it.
- Survivorship bias: When we give too much value to the stories of success and ignore all the ones of failure.
- Groupthink: When we get sucked into a group’s decision and don’t bring up objections (even if they’re valid).
- The planning fallacy: When we’re overly optimistic about how much time or resources a project will take.
As you build out your project risk management plan, ask if you’re falling victim to any of these biases and ignoring real risks.
What sort of risks do you need to think about?
So what sort of risks and uncertainties do you need to consider when writing a risk management plan? According to the Project Management Institute, most project risks fall under a few key categories:
- Technical. This includes risks based on requirements, the technology being used, interfaces, performance, and quality.
- Management. This includes any risks that come up from planning, scheduling, estimating, or communication.
- Organizational. This includes any project dependencies, logistics, resources, budget, etc...
- External risks. These are risks that come from your customers, users, contractors, or even the market itself.
Remember, each of these risks could potentially give you a positive outcome. For example, maybe a change in demand will suddenly mean your sales numbers are way under. Have you thought about how you might take advantage of that sudden increase in the budget?
For each risk, there are 3 levels of knowability to consider
By definition, project risks are unplanned. But that doesn’t mean they’re always unknown. Part of understanding risk management is also knowing how much you’re expected to know going into it. Risks fall into three levels of knowability:
- A known risk is something that has been brought up already by a stakeholder, teammate, or yourself. Maybe it came up during the project planning stage or was voiced by an expert. These need to be carefully analyzed (see the next step!) and documented.
- An unknown risk is one that didn’t come up right away and might only be known or recognized by a few people, such as an expert or specialist. You need to spend a careful amount of time trying to discover these while writing your project risk management plan.
- An unknowable risk is one that you can’t be reasonably expected to foresee, such as total system failure, a market crash, or an accident. While there’s no point listing all these out in your plan, it’s important to accept that you can’t anticipate every risk. But that doesn’t mean they’re not out there.
The 7 steps to creating a proper project risk management plan
Alright, it’s time to bring all this together into a proper risk management plan.
The process for creating your risk management plan follows a simple flow: identify, evaluate, plan, and monitor. Here’s how to fill out each:
1. Risk analysis: Identify potential risks (and then document and prioritize them)
The first step is to identify all the potential risks that your project is facing. This should happen at the beginning of the project as well as periodically throughout (such as after hitting a key milestone).
Here’s where you need to dig into the four risk categories (technical, management, organizational, external) as well as consider all levels of knowability (known risks, unknown risks, unknowable risks).
There are many different ways you can identify risks and which strategy you use will come down to your resources, team, and the size of your project. To get started, try a few of these:
- Interviews. Set time aside to speak with key project stakeholders, outside experts, and other teammates who might be able to shed light on some of the more unknown risks.
- Brainstorming sessions. Your team is one of the best sources of information on potential risks. In many cases, they’ve worked on similar projects and will know where things broke down. Like any other group meeting, a brainstorming session needs to be carefully planned and run to keep it on track. Send out an agenda and context beforehand and set the tone when people arrive. You want to invite discussion but keep it focused on what risks people have experienced in the past on similar projects.
- Risk checklists. Does your company already have a workflow in place for identifying risks? If so, they probably have a checklist of areas and categories for you to explore. If not, this is a great tool to build and use in later projects.
- Assumption analysis. Every assumption is a source of potential risk (remember the cognitive biases we listed above?) Take a few minutes and think about everything you’re assuming to be true or real about this project. Are your thoughts valid? Do you have proof?
A risk management plan should involve as many people as possible. Consult with your team, project stakeholders, and even outside experts if you can.
The best course of action here is to involve as many people as possible in each process. Consult with your team, project stakeholders, and even outside experts if possible.
Once you’ve identified potential risks, you need to document and prioritize them.
Let’s start with writing a risk statement. Instead of a vague, one-word risk like “budget”, you can use what’s called an if-then statement to clearly define each risk. Simply put, this is a language formula that goes:
If [Event/Risk], then [Consequence].
These statements not only help you understand what will trigger the risk or uncertainty but also what the potential impact is.
Next, each risk scenario needs to be prioritized. As reliability engineering consultant Fred Schenkelberg writes:
“Understanding the risks, then prioritizing which require attention focuses resources to best meet business and customer objectives.”
You can’t stop every risk from happening. Instead, you need to know just how badly they need to be addressed if they come up.
These go in what’s called a risk register, which is a simple table that helps you organize your risks and list common responses. As we work through the rest of the steps, you’ll fill out the remaining sections of the register.
2. Evaluate and assess the consequence, impact, and probability of each potential risk
As you prioritize your risks you’ll naturally ask three questions:
- What will happen if this situation takes place?
- How likely is it that this will happen?
- How bad will the resulting impact be on the project?
These factors—consequence, probability, and impact—give context and importance to each of your risks. Instead of just being a simple statement, you’re able to understand exactly how bad they are and how much you should be planning ahead for them.
In this step, you’re going to review the qualitative and quantitative impact of the risk and then assign a likelihood score (from low to high probability) and a risk impact score (either low, medium, or high).
If you have a lot of risks, you might use a more complex system to score the likelihood and impact of them. For example, you might use percentages or a modified version of the RICE method.
Once you’ve scored your risks, many people like to use what’s called a risk assessment matrix to plot them out visually.
For example, if we’re using our basic low, medium, high scores, our matrix might look like this:
In this case, the lightest squares can be monitored to see if they increase. The midtone squares should try to be mitigated if you have the resources and the closer you get to the darker squares, the more these should be mitigated throughout the project. The darkest squares need to be dealt with right away.
This shows you just how dangerous certain risks are and how urgent your response needs to be. The more complex your scores, the more complex your matrix will become (but the more visibility you’ll have into which risks are most dangerous).
3. Assign roles and responsibilities to each risk
It’s not enough to just write risks down and hope they don’t come up. Each risk needs to be assigned to a team member, prioritized, and given an estimate of the resources needed to handle it.
The designated team member will be responsible for taking ownership if the risk becomes an actual issue. As part of this, they need to understand the risk triggers or warning signs that signify they need to jump into action.
Risk management is a circle, not a linear path. Because you’re dealing with unknowns, your risk management plan needs to be a living document.
A risk trigger might be identified in advance (when it’s a knowable risk), while in other cases it’ll be pretty much impossible to pinpoint its exact cause. For example, you might know that there are risks to your brand when you change your pricing structure, but you won’t necessarily be able to identify the exact trigger, such as a Facebook post or blog from a customer.
This is where using a project management tool is so important. While your risk management plan can live as a wiki page, transferring individual risks into issues means you can assign and track their progress alongside the rest of your project tasks.
While risks should be assigned to a single person, they should be visible to all. This way, everyone is aware of what to watch out for and who to contact if they see one of the triggers.
4. Come up with preventative strategies for each risk
The point of a risk management plan is to give you a clear path towards solving any potential issues that come up. For each of the identified risks, the project manager and the assigned teammate should brainstorm a proper response.
In most cases, you’ll handle a risk that has become an issue in one of four ways:
- Avoid: Change your plan to bypass the issue. In other words, remove the cause of the threat altogether.
- Transfer: Outsource the risk (or a portion of it) to a different team or agency. Think of this as a typical “insurance” policy.
- Mitigate: Take immediate steps to reduce the impact of the risk. This could mean reviewing your requirements, going through additional testing, or looking for different options.
- Accept: Assume the chance of a negative impact or eventually budget in the cost of dealing with it.
When writing out your risk response plan your depth of details should match the significance of the risk. There’s no point in creating an in-depth response to a low impact, low probability risk.
Lastly, you can also escalate a risk if the response feels like it’s beyond the scope of your project. This takes us to our next step...
5. Create a contingency plan in case things go really wrong
In the case that you’re accepting the potential fallout of a risk, you should know what to do if it becomes realized. This is called a contingency plan. In other words, you’re answering the question: “What do we do now?”
Contingency plans should be saved for risks that are high priority and high impact but without an obvious solution for what to do if they happen. In this case, you’ll want to have a workflow mapped out that follows a few steps:
- Find and document resources that can be used in an emergency. This could mean moving team members off a different task, diverting budget, or increasing the scope.
- Know who will need to be notified in the case of this issue. You can use your communication plan to help find these people.
- Create a plan of action for dealing with this issue. Are there alternatives you can propose or flexibility you can add to your current project plan? Do you know who to bring in and where to ask for help? A checklist can help keep you focused when you’re in crisis mode.
- Keep an eye on the risk triggers for these issues (especially deadlines).
Of course, the balance of contingency planning is that these are usually issues with a small probability of actually happening. It’s easy to get sucked into imagining every terrible situation that might creep up. However, if the potential downfall of one of these risks could threaten your project, it’s worth thinking it through early on.
6. Measure your risk threshold and work with project stakeholders
While every project comes with some level of risk, there are ones where the potential negative outcomes are just too much to gamble on. This is what’s known as your risk threshold—the amount of risk your company or stakeholders are willing to take on.
As you create your risk management plan, it’s important to stay in contact with your key stakeholders and sound out how they’re feeling.
Is there too much risk to justify the project as scoped? Can you make changes to your project plan before you start to reduce the risks?
While this might feel annoying, it’s better to make changes early on rather than hit serious issues once you’ve already committed time and energy.
7. Continue to monitor and report on each risk
Lastly, risk management is a circle, not a linear path. Because you’re dealing with unknowns, your risk management plan needs to be a living document.
Whoever owns the risk needs to be responsible for tracking it, updating it in your project management tool, and making sure other people are aware of what’s going on. As your project progresses, there is a good chance new risks will come up or current ones will evolve and change.
Maybe what seemed like a low-probability risk early on is suddenly much more likely. By using a tool like Planio to keep track of your risks, you can quickly update them and keep everyone up-to-speed with what’s going on.
Project risk management can’t be done in a silo. To have the best chance of hitting project success it needs to be an integrated part of your project management process.
How to create a powerful risk management system using Planio wikis and tasks
By using a project management tool like Planio, your risk management plan can live alongside your issues, tasks, and milestones. This way, you keep risks upfront and transparent.
One of the best ways to do this is with Wikis and our Agile project management boards.
Planio Wikis are powerful ways to store your team’s knowledge in a way that’s accessible and transparent. In this case, you can include your entire risk management plan in a Wiki to make sure everyone knows your methodology, which risks are being assessed, and how to respond.
Each Wiki entry can include files and images (such as your risk register) and link out to individual issues or tasks. This is where things get interesting.
As we mentioned earlier, you can create a Planio issue for each risk and individualize them with custom fields to add information such as impact, description, plan of action and priority, and then assign that issue to the risk owner.
Now, when you plan out your tasks for the next sprint, you can include any associated risks right on your Agile board alongside the work being done. Not only does this give more visibility into the risks, but it can even help reduce their impact.
While other software development processes (like Waterfall) only provide feedback once a major milestone has been reached, Agile brings it in early and often. As Mike Robinson, an Agile consultant at Indigo Blue writes:
Agile’s core practice of incremental delivery can be leveraged to transform risk management, by seeking fast feedback from stakeholders.
Planning for failure is actually planning to succeed
The only way to pretty much ensure project failure is to stick your head in the sand and pretend nothing could possibly go wrong. By following this project risk management plan and creating your own version (in Planio!) you’ll always be one step ahead of issues and one step closer to a successful project.
