If you were one of those people who spent a lot of time in outdoors-themed organizations growing up, then you know that they emphasize being prepared for whatever life throws at you. The goal, at least in a wilderness setting, is to anticipate potential problems to the degree that they’re easier to handle. In survival situations, proactivity outweighs reactivity.
The same strategies hold true with project risk management. The better prepared you are, the less time you spend struggling to deal with issues, which leads to successful projects.
What is project risk management?
Project risk management is the act of identifying, assessing, and mitigating risks that might occur during any given project. Risk, in this case, is defined as anything (good or bad) that might have an effect on the project objectives and outcome. It could be taking a chance on a new team member and who ends up helping you finish the project ahead of schedule. Or it could be a network crash that sets you back weeks.
Like wilderness survival, the goal of project risk management is to be as prepared as possible for anything that might happen. You’re planning for the just-in-case moments, rather than expecting to fail. But, without solid risk management plans, things can go south quickly.
What are the 6 steps in the project risk management process?
I’ve broken down the project risk management process into 6 steps. I’ve published a
that will guide you through most of these steps. And I’ve linked a few other helpful templates you can adapt into your own efficient process to identify, assess, and plan for potential risks.
1. Risk identification
The first thing to do is identify all the possible sources of risk in your new project. This could be good things (yay!) or bad things (Boo-urns!), even things that are just mildly annoying (meh). The goal is to simply figure out what they are.
Chances are, you’ll be able to identify most of the potential sources of risk based on previous experiences in past projects. However, there might also be things that happen that you’ve never encountered before. That’s why it’s a good idea to include others in the risk identification process. Running a
of sorts can be an effective method for coming up with new risks that you’ve never encountered before.
2. Risk analysis
Once you’ve identified risks you may encounter in a project, it’s time to take a deeper look into each. In this analysis phase, you’ll classify the risk, determine its impact on the project, and plan an initial strategy for mitigating the risk.
There are a few ways you could analyze risk. A
allows you to create a visual representation of the impact of the risk and how likely it is to happen. Again, this is where you can jump into my
, which will help you run both quantitative risk analysis and qualitative risk analysis.
3. Risk ownership
Being prepared on every single level also means knowing exactly how to avoid a not-so-fun round of the blame game. By assigning ownership of risk, you proactivity hand off the response to the appropriate team — while fostering a culture of support and empowerment. The risk owner should be the person who has the best skills to mitigate individual risks on your team.
For example, if something goes wrong with the back-end of an app you just finished, you can’t expect your copywriter to step up and solve the problem (unless you want to market it as a feature, rather than a bug). If you’re following this project risk management process, you would have given ownership of this risk to your engineers and empowered them to put the mitigation plan in motion when ready.
You can see an example of risk ownership assignments in my
4. Risk prioritization
Once you decide who’s responsible for the risk, prioritize it. In this step, you’re looking for things that are going to have a big impact on the end result (either good or bad) and that are very likely to happen. Prioritization is a part of the risk assessment process and where the
comes in handy. As you can see by the diagram below, the matrix clearly tells you what kind of priority each kind of risk should be — guesswork is typically not part of this step.
5. Risk response plan
This is probably the most critical step of the process. Each type of risk you encounter (or at least the high priority ones) should have a risk response plan in place to help with risk mitigation, should the risk actually occur. Ideally, you’ll have a plan in place for everything you’ve identified, but focusing on the high-priority risks is a good place to start.
Your response plan should have clear steps to follow that help mitigate the risk, including who’s in charge of what, what needs to be done, and how fast it needs to happen. Here’s what the plan looks like in my
6. Monitor risk management strategy
Finally, you need to monitor your strategy to make sure that it’s working the way that it should and that you’re adequately prepared for each potential risk. This should include post-mortems at the end of the project to assess how you handled the situations that came up, as well as a way to improve your processes around how you manage risk.
Positive vs negative risks and the impact they can have on your project
Even though we’ve already touched on this a little, it’s always worth calling out that
It’s entirely possible that when you’re running your project, you’re going to encounter situations that are risky, but ultimately very good for your project. These are going to be things that allow you to finish early, find innovative solutions to your business problems, or even bring in more customers to your business.
The other end of this is negative risk. This is the bad place you want to avoid as much as possible.
Negative risk tends to result in things like failed projects, blown deadlines, or scope creep.
It’s worth noting here that good or bad, risks can’t necessarily be prevented and they’re not your fault when they happen. That’s why project risk management focuses so much on planning for potential situations that may never happen. But, if they do, you’re prepared.
Improve project risk management with Coda
Coda can’t help you prevent risk from occurring, but Coda’s building blocks and templates can help you better manage the situations when they come up. I want to mention two of my favorite that work to clearly identify both the risk itself and the points in the project where something might happen.
Gantt charts, or timelines as Coda calls them, are excellent ways of visually identifying potential risks. Seeing your entire schedule laid out this way can help you identify moments where risk may occur. I highly recommend playing around with
to highlight those moments. For example, you could use different colors within the chart that indicate the severity of the potential risk (red for high impact, green for positive impact, etc.).
There are also going to be moments when critical tasks overlap in ways that aren’t ideal or conflict with other aspects of the project, Gantt charts, because of the way they’re designed, make those moments obvious.
Test out this
to decide whether it’s a useful tool for your project risk management.
Similar to Gantt charts, kanban boards can be used as a way to help with project risk management. The kanban system uses cards that identify the various tasks that need to be completed within a project. As a risk management tool, these cards can be color-coded to highlight moments where risk may occur. It provides you with a quick way to identify risks, so you can hand off potential issues to the people most suited to dealing with them (that’s the assign risk step from above).
It ends up looking something like this.
Of course, if you’d like to play around with that, we’ve got you covered. This
has everything you need to get started.
Project risk management FAQ
What are the 3 types of project risk?
Because life likes to keep us guessing, there is more than one kind of risk that you might encounter during a project. The actual risk itself may vary depending on the specifics of your project (we’ll talk about that shortly), but the impact of that risk typically falls into one of three categories.
These are the risks that cost you money in some way, shape, or form. This could be something that delays the end of the project, adding to the cost, it could be needing more tools than you initially thought, it could be something breaking that you need to stop and fix because you can’t work without it. Whatever the cause, you feel this one in your pocketbook (so to speak).
These are things that affect the schedule of the project (both for the better and for the worse). Scope creep is a classic example of this because increased scope means increased time. But, it doesn’t end with just scope creep. This could be everything from team members being away from work longer than expected to aspects of the project being more challenging than initially thought.
This is anything that results in a lower quality deliverable (or final product) than the project plan called for. Here, we’re looking at things like team members who are burning out or maybe don’t have the skills you thought they did. It could also be that the timeline was too short and people had to rush.
What are examples of project risks?
We’re going to get a little more specific here with the types of risk. Above, we talked about the overall impact of the risk. Here, we’re looking at specific kinds of risks that you might encounter while working that could impact project success.
Anything technical that might go wrong. This covers all the potential tech issues that exist out there, including your network crashing, computers going down, a cyberattack, the power going out in your building, or the tools you’re using going down. Technology risks can be hard to plan for because they’re often unexpected and usually require the help of an IT department to get things running again.
This happens when there isn’t enough clear communication at all levels. It could involve key stakeholders, team members, or clients and often is the result of either too many different communication channels (leading to confusion), too much communication, or not enough.
Scope creep -
Scope creep is every project manager’s nightmare. This happens when the clients (or stakeholders) ask for small changes to a project that add work and increase the project length. This often starts out innocent enough, but if not properly managed it can become very overwhelming very quickly as the project scope increases beyond the point of being able to manage it.
Cost becomes a problem when you overshoot your budget. Sometimes, cost and scope creep go hand in hand (because the cost increases with the scope), but sometimes it’s the result of either unexpected project costs along the way or poor budgeting.
There’s a reason project managers spend a lot of time fine-tuning their workflows and using systems that help them keep everything on track and that’s because without a smooth workflow, your project can fall behind and costs can increase.
Lack of skills -
If your team doesn’t have the skills you need them to have to complete the job (or those skills aren’t as developed as they could be), you’re going to run into problems. This one can be avoided by either running training sessions with your team or ensuring that you pick team members you’ve worked with in the past and know they can get the job done.
What is the difference between project risk and project crisis?
The biggest difference between a project risk and a project crisis is that a risk is something that
, where a crisis is something that
. With project risk management you’re identifying and preparing for anything that could happen during a project and coming up with response plans.
Crisis management focuses more on implementing those plans once something has happened. Crisis management is also something that covers unforeseen events, things that you
plan for, but are often so unlikely that you don’t. This could include the death of someone in your company or a major natural disaster in an area not usually prone to disasters.
How does a project manager mitigate the risks?
The best way to mitigate risks is to be prepared. We talked about this back at the beginning a little bit, the more you’re expecting and ready for certain things to happen (risk), the better you’ll be able to mitigate the event should it actually happen. Here’s what this looks like:
Use risk management -
You’d think this would be an obvious step towards mitigation, but people don’t like to think about what could go wrong. But, positive thinking isn’t going to pull you out of the weeds if things start happening during a project (although good planning will).
Communicate with your team -
You don’t have to bombard your project team with doom and gloom. But you should talk about it during your
. This way, your team knows what to expect and what do to if things go south.
Prioritize risk -
It’s one thing to know what risks you may encounter, it’s another thing to know which risks will cause major problems when they happen (and which will make you go, “Oh no. Anyway…”). A risk matrix (as talked about above) helps you rank risk according to the severity and impact.
Analyze risk -
Risk analysis helps you figure out exactly what the impact of the various kinds of risks might be. It’s part of how you determine whether something is going to shut down your company, have little to no impact, or start small and turn into something catastrophic. The more in-depth your analysis, the more accurate your response will be.
Respond quickly -
Like a lot of things, the sooner you deal with something when it happens, the better. If you drag your feet when responding to a small problem (either because you don’t have a good plan in place and have to figure things out or because you just don’t want to deal with it), you give that issue time to get worse. Think of it like a fire starting in your trash can outside. If you get it while it’s small, it’s going to cause problems, but nearly as many problems as it’s going to cause if you ignore it and it burns down your garage.
Analyze your response -
You can’t just let things happen, deal with them, and then never speak of them again. That doesn’t help you learn. Instead, take the time to look at how you responded to an incident, whether or not your response was successful, and what you could do differently next time. This helps you gain a better understanding of how you handle things. You should also take time to identify what led to something happening in the first place. If you can, run through the events that led to the incident and determine what, if anything, you might have been able to do to prevent it. This, in turn, gives you a path to follow next time you identify certain kinds of risk in the future.