The risk management process is a structured approach to identifying, assessing, responding to, and monitoring project risks. In the PMBOK® Guide, it has seven steps: plan risk management, identify risks, perform qualitative risk analysis, perform quantitative risk analysis, plan risk responses, implement risk responses, and monitor risks.
Key takeaways
- Seven steps, one cycle. Plan, identify, analyze, plan responses, implement them, and monitor, until the last day of the project. Quantitative analysis is optional.
- Start on day one. You inherit risks from your organization before the project starts, sometimes in pre-sales.
- Focus on the top dozen. Log every risk, score them all, and plan responses only for the ones that matter most.
- Delegate ownership. Give each risk an owner, so you can watch the big picture.
I’ve been managing software development projects for more than 15 years. Risk management is the most important piece of my project management approach. It’s also the piece I spent the most time making practical.
When I got my PMP, I tried to bring its processes to a company that had none. Nobody followed them, and I was back to managing chaos. If you’ve tried to manage risks by the book, you may know that feeling. Don’t blame yourself. The book gives you every process and never tells you how much of it a real team will follow.
What worked for me in the end was just enough process to stay in control, light enough that your team follows it.
Below, you’ll get the whole risk management process in that spirit, so you can spot problems while they’re still cheap to fix. Each step links to an in-depth article on that process and its tools.
One ingredient matters more than any of the seven steps. My mentor taught it to me on my first project, and you’ll find the story near the end.
The 7 Risk Management Steps at a Glance
| # | Process | What you do | Main output |
|---|---|---|---|
| 1 | Plan Risk Management | Decide how you’ll find, score, and track risks on this project | Risk management plan |
| 2 | Identify Risks | Find threats and opportunities and write them down | Risk register |
| 3 | Perform Qualitative Risk Analysis | Score probability and impact (low, medium, high) and prioritize | Shortlist of top risks |
| 4 | Perform Quantitative Risk Analysis (optional) | Put numbers on risks: percentages, money, days | Expected monetary value, reserves |
| 5 | Plan Risk Responses | Choose how you’ll handle each top risk | Risk response plans |
| 6 | Implement Risk Responses | Assign owners and carry out the plans | Tasks, budget, owners |
| 7 | Monitor Risks | Track responses, spot new risks, review the overall risk level | Updated risk register |
Short Glossary of Project Risk Management
There is no universal risk management process. You select the tools, techniques, and processes for each project. Many organizations also have their own approach to risk management that you need to follow.
Risk management process, framework, and approach mean the same thing in this article. I’ll use them interchangeably.
In simple terms, risk management is your effort to identify and tackle project risks.
The PMBOK® Guide describes a simple framework for risk management. It gave me inspiration, so credit where it’s due to PMI. Here’s how it defines a risk:
“An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”
So a risk can go both ways. A threat is a risk with a negative effect. An opportunity is a risk with a positive effect. As a project manager, you should work to exploit opportunities as hard as you work to avoid threats.
“Impact” is the effect of a threat or opportunity. A risk may change the feasibility, costs, duration, overall risk level, or the availability of resources and people. A risk can hit any part of your project.
You can assess impact qualitatively, as low, medium, or high.
You can also assess it quantitatively: a cost of $2,450, a delay of four calendar days, or both at once.
But don’t limit yourself to costs and duration. Risks show up in every area of project management, and one risk may hit several at once. For example, a risk may affect quality, team motivation, resources, and staffing together.
“Probability” is the likelihood that a threat or opportunity happens.
Again, it can be qualitative (low, medium, high) or quantitative (a percentage).
A “risk response” or “risk response plan” describes the action you’ll take on a risk: avoid, mitigate, transfer, or accept a threat, or exploit, enhance, share, or accept an opportunity.
What Are the 7 Risk Management Processes?
Each step in the table above is a separate process. I explain each one in detail in the related articles.
Keep in mind that it’s a framework. You can add or remove tools and techniques in each process, and you’ll tailor your approach to each project.
Your main consideration is cost. Risk management is not free. It takes time from your whole team and your stakeholders. So you need to balance your effort against the benefit of avoiding the risks.
In this video, I walk you through all the risk management processes from the PMBOK® Guide:
Process #1: Plan How to Manage Risks
As with everything in project management, risk management starts with planning. There are three reasons for this:
- Risk management draws on all your project documents, processes, and workflows. You need to plan what you’ll analyze and how.
- You don’t do risk management alone. You need input from stakeholders, so you need to know who they are and plan how to engage them.
- You need to collect your organization’s assets and knowledge, so you don’t reinvent the wheel.
There are too many moving parts to keep in your head. So you need a simple project risk management plan. It should cover each step below.
Process #2: Continuously Identify Risks
Next, you identify risks with the techniques from your risk management plan and all the information you have at hand.
I cover the different risk identification techniques in detail here:
Risk Identification (What Is It, Techniques and Examples)
One technique deserves your attention first, because it gets you started even if you’ve never done this before: the analysis of risk categories.
The catch: your company probably doesn’t keep a list of risk categories.
I’ve got you covered. In my experience, there are 43 risk categories. Take them as a starting point. Add the categories from your industry. Then keep the list updated throughout your career.
43 Risk Categories: Complete List of Categories of Risks
How many risks should you identify? Even a small project can have up to a hundred.
So what do you do with all of them? First, log them in a risk register. Don’t evaluate them yet. Just write them down!
Risk Register Example From a Real IT Project
Want a first list faster? Run the Hidden Deliverable Detective prompt from my free AI Prompt Pack, and AI lists the governance, compliance, and handover deliverables your plan doesn’t cover yet. Log each gap as a risk.
Process #3: Perform Qualitative Risk Analysis
Qualitative risk analysis means you score each risk’s probability and impact on a simple scale, like low, medium, and high, and then rank the risks.
Remember, mitigation costs money. You’ll never work on a project that lets you mitigate every possible risk.
That’s why the main goal of qualitative risk analysis is a shortlist: the risks with the worst impact on the project and a real chance of happening.
Soon, a hundred risks shrink to maybe a dozen. Next, you plan responses for each of them.
The rest stay on a “watch list” in the risk register. Why keep them? Because the impact and probability of risks change over the life of the project.
My key piece of advice: don’t overcomplicate it!
If you can prioritize risks with low, medium, and high, do it. A finer scale only pays off when you have hundreds of risks or need a more detailed analysis.
Qualitative Risk Analysis Example
Process #4 (Optional): Perform Quantitative Risk Analysis
Quantitative risk analysis puts numbers on risks: percentages for probability and dollars (or your currency) or days for impact. It also looks at the combined effect of all the risks on your budget and deadline.
With these numbers, you can calculate the expected monetary value (EMV) of each risk: probability × impact. A risk with a 20% chance of costing you $10,000 has an EMV of $2,000. Add up the EMVs of your top risks, and you have a solid starting point for your contingency reserve.
On smaller projects, this usually isn’t worth the effort.
It does help when you face a costly, critical decision. A decision tree like the one below compares your options by their expected value. If you’re doing it for the first time, ask your peers and leadership for guidance.
Process #5: Plan How to Overcome Risks
So now you have a dozen top risks. What next? For each threat, you have these options:
- Avoid: you do something to remove the risk.
- Mitigate: you do something to reduce the impact or probability of the threat.
- Transfer: you shift the impact to someone else, like a vendor with a fixed-price contract or an insurer.
- Accept actively: you do nothing now, but when the threat happens, you use risk reserves to limit the damage.
- Accept passively: you do nothing and live with the effects. Then you may need to adjust the project plan.
Opportunities have their own strategies: exploit, enhance, share, and accept.
The risk response plan gets you one of these results. But don’t settle for a cookie-cutter solution. The best response plans come from working with your stakeholders.
Sometimes you need to look beyond your Gantt chart, your budget, and your team. Sometimes a word with the right people removes the risk altogether.
Risk Response Strategies (Definitive Guide with Examples)
Process #6: Implement Risk Responses
Each risk response plan becomes part of your project management plan:
- a budget allocated to a specific risk,
- a separate task someone needs to perform,
- or a new process you developed.
More often than not, someone needs to carry out the response plan before the risk happens. At the very least, that person monitors the risk and reports on how well the response works.
In most cases, that person shouldn’t be you. You don’t have time to track dozens of risks.
So you need to do the following:
- Assign an owner to each risk. The owner monitors their risk and acts on it when the time comes.
- Tell your stakeholders about the upcoming risks and the responses you’ve planned.
- Collect data on the risks: how many did or didn’t happen, how well the responses worked, and the effect on schedule, budget, and scope. Don’t forget your client’s satisfaction.
- Identify any residual risks left after your responses.
You’ll recognize these activities from the rest of project management. Each risk response is like a small sub-project inside the bigger one, never a stand-alone activity.
Here’s an expert tip:
Delegate ownership of risk responses as much as you can.
You need to focus on the bigger picture: project progress, the overall risk level, and new sources of risk. Only take on the risks in your own area of expertise.
Risk Management Examples: 9 Behind the Scenes Stories
Process #7: Continuously Monitor Risks
When you monitor risks, you first check that your planned responses work and happen on time.
Then you watch for new risks. They surface all the time! Known risks may also change their probability and impact. New and updated risks can threaten the feasibility of your whole project.
Next, you check the overall risk level of the project on a regular schedule. Based on what you find, you may need to change the project baselines or your risk management approach.
In essence, you use the same risk identification techniques over and over again.
When Does the Risk Management Process Start on a Project?
It starts on day one, often before the project officially begins. Why so early?
First, you inherit risks from your organization: internal stakeholders, processes, lack of support from leadership, missing expertise, recurring or seasonal problems. They’re all there before your project starts.
The good news?
The longer you work at one company, the more you know about its inefficiencies and weak spots. Rest assured, the same challenges will come back on every new project. Organizations don’t fix these problems quickly.
Second, you may take part in the pre-sales phase. There, you can avoid a whole treasury of risks by adjusting stakeholders’ expectations from the start. But you need to know how to identify and track those risks.
That’s why you focus on risk management from the start. You apply these processes and tools to every part of the project. Build risk management activities into your project plan.
Repeat this mantra after me:
“I will perform risk management activities throughout the whole project life cycle and in between projects. It never stops.”
Secret Ingredient of Risk Management
I was sitting in the office early one morning. I’d created a perfect plan to fix a problem that I believed would appear in a few days. It was my first project, and I was a little proud that I’d spotted a potential risk!
A few days later, it happened!
With barely concealed enthusiasm, I escalated it to management and presented my plan to fix it. After a few hours of intense meetings, senior management accepted my plan.
We solved the problem quickly. But once everyone left, my mentor came over. “What the hell was that?” he said. “Fixing the consequences is a passive mindset. You should be proactive! If you knew the solution, you should have prevented the problem.”
I’ve remembered that lesson for my whole career. He was right. A quiet meeting with an expert before the problem arose would have got us the same result. It would have been cheaper and less stressful, and we wouldn’t have pulled senior managers and engineers into a firefight.
So risk management is about preventing problems or reducing their impact on your project.
The secret to efficient risk management is proactivity.
What if Risks Mess Up Your Project?
This process doesn’t protect you from every problem:
- You may miss a severe risk.
- Your risk response plan may not work.
- Small risks may snowball into big ones.
- Some risks will be out of your control.
When a risk hits your project hard, focus on getting back to your original plan. Don’t re-plan the whole project, because that creates new risks.
But that’s the worst case. You won’t see many risks that can sink a project overnight. When they exist, you usually know about them and try to avoid them from day one with a prototype or a feasibility analysis.
In the real world, worry about two things: the compound effect of many small risks, and the risks you failed to identify. They won’t sink your project at once. They’ll cause delay after delay, until your project owner starts questioning your competence. You definitely want to avoid that!
Every one of those small delays costs you evenings and weekends of catching up. In this video, I explain why risk management decides whether you finish your project on time:
Risk Management Templates: Why the Documents Are the Easy Part
If you came here for risk management templates, I get it. You want something you can fill in today.
Templates help. They give you the headings for a risk management plan and the columns for a risk register.
But how many perfect risk registers have you seen that nobody opened after kickoff? You can have flawless templates and still spend your days putting out fires.
Control comes from the seven steps above: you plan, identify, score, respond, assign owners, and review risks as the project changes. Once you understand the process, the documents are the easy part.
And today, AI drafts those documents better than any template, as long as you give it context. Type “create a risk management plan for my project” into ChatGPT, and you’ll get a generic plan that could belong to anyone’s project.
I put together a free AI Prompt Pack for project managers to solve that: 27 copy-paste prompts for real IT project work. Three of them fit the risk management process:
- Project Context File Builder. You build one file with your project goal, scope, stakeholders, team, timeline, known risks, and constraints. You attach it to every prompt, so AI answers with your project’s details.
- Hidden Deliverable Detective. AI lists the governance, compliance, and handover deliverables you haven’t planned for yet, and flags the blind spots and compliance risks it sees in your context. That’s a strong start for risk identification.
- Impact and Probability Grades Descriptor. AI asks you a few questions about your project and builds a 5-point scale for probability and impact, with cost, schedule, and scope thresholds. Your team and your sponsor then mean the same thing by “high.”
Get the free AI Prompt Pack. When you run these three prompts on the project you’re managing now, you’ll walk into your next status meeting with a first list of hidden risks and a clear scale to score them.
Risk Management Process FAQ
What are the 5 steps of the risk management process?
Many guides shorten the process to five steps: identify risks, analyze them, plan responses, implement the responses, and monitor risks. The PMBOK® Guide adds two more: planning risk management at the start, and splitting analysis into qualitative and quantitative. You get the same process at a different level of detail.
What are project risks? Examples from IT projects
A project risk is anything that might happen and affect your scope, schedule, budget, or quality. On IT projects, I see the same ones again and again: a key developer leaves mid-project, a vendor delivers an API late, requirements stay vague until the demo, a security review blocks the release, or a stakeholder changes priorities. You’ll find many more in my list of 43 risk categories.
What is the difference between qualitative and quantitative risk analysis?
Qualitative analysis scores probability and impact on a simple scale, like low, medium, and high, to prioritize risks. Quantitative analysis puts numbers on them, like a 20% chance of a $10,000 loss, and calculates their effect on the budget and schedule. Every project needs the first, and only large or high-stakes projects need the second.
What is a watch list in risk management?
A watch list holds the low-priority risks you decided not to act on yet. They stay in your risk register, and you review them with the rest. If a risk’s probability or impact grows, you move it to the top list and plan a response.
How do you manage risks without overcomplicating it?
Use just enough process to stay in control, light enough that your team follows it. Log every risk, score it as low, medium, or high, act on the top dozen, give each one an owner, and review them on a schedule. Skip quantitative analysis unless the project is big or the decision is expensive.
What is the difference between a risk and an issue?
A risk is something that might happen, and an issue is a problem that has already happened. You track risks in a risk register and issues in an issue log. When a risk happens, it becomes an issue, and you use the response plan you prepared.
Conclusion on Risk Management
Risk management is a cycle of seven steps that you repeat until the last day of your project.
Keep it simple. Start early, log every risk, focus on the top dozen, give each one an owner, and review them on a schedule. Use as much process as your project needs, and no more.
Do that, and your project runs on a system, not on overtime. That’s how you stop managing chaos and start managing projects.
You’ll find the rest of my articles on this topic on the Risk Management page.
Before you start on the risks of your next project, grab the free AI Prompt Pack and build your Project Context File first. You’ll get answers about your project instead of generic risks.