Risk management for projects

What is risk management in project management?

A risk is any possible outcome or event that can occur over the course of a project or during a process. Risks can be related to timeline, budget, or performance, but there is no limit to its flavours. Project risk management is the process of making educated guesses and mapping out strategies related to these perceived risks.

At its core, risk management is about reducing uncertainty. You're not predicting the future — you're acknowledging that multiple futures are possible, and preparing for the ones that matter most. The goal isn't to eliminate every risk (that's impossible), but to identify the risks that could seriously derail your project and have a plan for dealing with them before they happen.

A good risk management process helps you:

• Make better decisions — when you understand what could go wrong, you make smarter choices about scope, timeline, and resourcing
• Build trust with clients — stakeholders respect a PM who says "here's what could go wrong, and here's how we'll handle it" far more than one who promises everything will be fine
• Reduce stress — surprises are the enemy of calm project delivery; a risk plan turns surprises into anticipated events
• Improve future projects — each risk you identify and document becomes institutional knowledge that makes your next project smoother

How does risk affect project planning?

Understanding risks allows you to plan more accurately, learn from your mistakes, and create smoother processes for future projects. It also helps you estimate time, money, and people resources better, which is good news for your team and your clients.

It can be tempting to skimp on this stage and push these little risks under the rug or to ignore them altogether. But ignoring them doesn't make them disappear. They'll come back and bite, and when you're not prepared, they can kill an entire project. Nothing's more important to the success of a project than a project manager's ability to identify and manage risk. All projects have risks—if you don't see them, look harder (psst: look under the rug! They're under the rug.)

Risk and estimation

Risk directly affects how you estimate. If you ignore risk entirely, your estimates will be too optimistic — you'll plan for the happy path and get blindsided when reality arrives. If you account for every possible risk, your estimates will be so padded that you'll never win a project. The sweet spot is identifying the risks that are both likely and impactful, and building contingency into your estimates for those specifically.

A practical approach: when estimating, start with your best-case scenario, then add time and budget buffers proportional to the number and severity of identified risks. A project with three high-severity risks deserves more buffer than one with two low-severity risks. Document your reasoning so you can revisit it later — "we added 15% buffer because of the API integration risk" is far more defensible than a guess.

When to do risk planning

Risk planning isn't a one-time activity. The best PMs revisit their risk register:

• During project scoping — before you commit to a timeline or budget
• At kickoff — with the full team, so everyone can contribute risks you might have missed
• At each sprint or milestone — risks evolve; new ones emerge, old ones resolve
• When scope changes — any change to scope, timeline, or team introduces new risks
• During retrospectives — what risks materialised? What did we miss? What can we learn?

Are project risks the same thing as red flags?

Nope—even though red flags can point you in the direction of possible risks, don't treat them as interchangeable. Risks are all the pathways that a project could take while red flags are observable clues that tell you whether risks are more likely to happen. If you're a smarty pants, you can use those handy red flag spotting skills to help you assess project risks.

Here's how: red flags can't prove a risk will happen, but they are good indicators. If you see a red flag in a project, you can make a safe bet that risk is likely to happen. Consider this a courteous heads up that you should stick your eyeballs on this project and watch it like a bird watches a breakfast worm.

Projects with fewer red flags mean you probably have smooth sailing ahead. Probably—just because you don't see it doesn't mean risk isn't lurking below the surface. It's just less likely.

Using red flags to assess risk

Think of red flags as your early warning system. When you spot one, ask yourself:

• What risk does this flag point toward?
• How likely is that risk to materialise?
• How severe would the impact be?
• What can I do right now to reduce the likelihood or impact?

Documenting these connections turns vague feelings of "something's off" into actionable risk entries. Over time, you'll build a mental library of which red flags reliably predict which risks — and that pattern recognition is what separates experienced PMs from beginners.

Types of risks

Remember—don't be a downer. Not every risk that crosses your path is going to be negative. Check out the difference between negative and positive risks.

Negative risks

Negative risks are anything bad that can happen to a project that would increase complexity or kill its chance at success. Negative risks range from mild to serious, but they all have the power to affect that golden PM triangle of scope, time, and cost. And people, they definitely impact your people.

You can respond to negative risk using four strategies:

• Avoid: change your plan to eliminate the risk entirely (e.g., choose a different technology stack that your team already knows)
• Transfer: shift the risk to a third party (e.g., use a contract clause that passes liability to a vendor)
• Mitigate: reduce the likelihood or impact (e.g., add extra QA time to reduce the risk of post-launch bugs)
• Accept: acknowledge the risk and deal with it if it happens (appropriate for low-impact, low-likelihood risks)

Positive risks

Positive risks make a project easier, more successful, more profitable, and more sustainable. If you are willing to hedge your bets and sense a powerful opportunity (say, a new client that's out of your norm approaches you and wants to work together)—it's definitely worthwhile to weigh out the positive and negative risks before advancing. You may win out big, but if the project doesn't pan out, it could burn you, so have a backup plan.

You can respond to positive risk by doing any of the following:

• Exploit: eliminate uncertainty and make this thing happen
• Enhance: increase your odds that this risk will pay off
• Share: go in halfsies with your stakeholders and share the risk
• Accept: take what comes

Risk categories in detail

People risks

People risks affect your project team and your stakeholders. For example, employee turnover is a common people risk (either in your own org or your client's).

Relationship risks

Relationship risks depend on team members' (and stakeholders') ability to align, communicate, and cooperate. An example would be a new stakeholder added mid-project.

Schedule risks

Scheduling risks affect the mighty calendar. This includes things like time off, team member availability, and anything that affects project length.

Scope risks

Remember our old friend scope creep? Project scope is such a fickle beast that it has a risk category all its own. This risk category includes any risk related to scope, like introducing changes or adding features.

Financial risks

Financial risks relate to the budget of both your org and your client. Commonly pops up as late (or withheld) payments, outdated budgets, and the gross, over-budget project.

Business risks

Business risks are concerned with the long-term longevity of both your organization and the organization of your stakeholders. This includes more significant risks like taking a project that would hurt your org's reputation or taking a financially risky project that could hurt your organization's sustainability.

Technical risks are worth calling out separately — they relate to the technology stack, integrations, and infrastructure your project depends on. Will the API you're building against behave as documented? Will the CMS handle the content volume? Will the hosting environment scale? Technical risks are especially common in software and digital projects, and they're often underestimated because the team assumes "we've done something like this before." Each project's technical context is unique, so treat prior experience as a starting point, not a guarantee.

External risks are those outside your organisation's control: regulatory changes, market shifts, natural disasters, pandemics, third-party service outages. You can't prevent these, but you can have contingency plans. Ask: "If this external event happened, what would we do? How would we keep the project moving?"

The four stages of the project risk management process

Now that you know what risks are, let's look at how to stay one step ahead and catch them before they destroy your project.

There are four steps to think about when building a risk management plan on a large project:

Identify

Brainstorm any possible risks that come to mind. Risk identification is a collaborative process, so don't be shy to ask for everyone's input.

At the end of this stage, you should have a long list of all possible risks you and your team can imagine. Even if they start sounding ridiculous—that's how you know you can stop.

Tips for effective risk identification:

• Hold a dedicated risk workshop — gather your team and stakeholders for a focused session. Use prompts like "What could delay us?", "What could blow the budget?", "What don't we know yet?"
• Review past projects — what went wrong last time? What surprised you? History is the best predictor of future risks
• Talk to the people doing the work — developers, designers, and content folks often see technical and practical risks that PMs miss from a higher level
• Use a checklist — go through each risk category (people, relationship, schedule, scope, financial, business, technical, external) and brainstorm risks for each
• Don't filter yet — this stage is about quantity, not quality. Write everything down, even if it seems unlikely. You'll assess in the next stage

Common risks to look for:

• Key team member availability (vacations, illness, departure)
• Dependencies on third parties (vendors, APIs, client-provided assets)
• Unclear or changing requirements
• New technology or tools the team hasn't used before
• Tight deadlines with little room for error
• Budget constraints that limit options
• Stakeholder misalignment on goals or priorities

Assess

Once you have a list of risks, it's time to determine which ones are worth worrying about (and which aren't). Bring all your stakeholders together for this: designers, developers, or any other folks whose trade insight will be valuable.

As you assess risks, think of them in three different levels: less serious, a bit serious, and pretty damn serious. If you want to get fancy, you can assign each a numerical value (a traditional risk matrix uses a value between 1 to 4 or 5).

At the end of this stage, you'll have narrowed your list down to risks likely to pose a threat. Assessing the threat-level of risks allows you to determine how much attention and energy each deserves.

How to assess risk:

Score each risk on two dimensions:

1. Likelihood — how probable is this risk? (Low / Medium / High, or 1–5)
2. Impact — if it happens, how bad is it? (Low / Medium / High, or 1–5)

Multiply the two scores to get a risk priority. A risk that's high-likelihood and high-impact gets your full attention. A risk that's low-likelihood and low-impact can be accepted and monitored.

Critical — high likelihood, high impact. Your full attention: mitigate now. High priority — high likelihood with medium impact, or medium likelihood with high impact. Mitigate actively and plan a response. Medium priority — medium likelihood with medium impact, or low likelihood with high impact. Monitor and prepare a contingency plan. Low priority — medium likelihood with low impact, or low likelihood with medium impact. Keep an eye on it. Accept — low likelihood, low impact. Note it and move on.

This helps you focus your energy where it matters most. Don't spend hours mitigating a low-likelihood, low-impact risk when a high-likelihood, high-impact one needs your attention.

Mitigate

Now that you know your real risks, what plans can you put in place to avoid them, or at least manage them as they happen? Now is the time to be proactive rather than reactive. It's vital to consult every risk owner at this stage so they're aware of how they can help to mitigate risks. That way you and your team will avoid any surprises and scrambling down the road.

It's impossible to avoid all the risks swooping down on you, no matter how good you are at spotting them. That's why reducing impact is also another part of mitigating risk. Even if you can't prevent a fire from happening, you can stop it from burning the whole house down. Map out how you can stop risk in its tracks as soon as you see it happening.

At the end of this stage, you'll have a plan that will help you avoid as many negative risks as possible. Remember: your risk mitigation strategy is always proportional to your risk threat level.

Creating a mitigation plan for each risk:

For every risk that scored medium or higher in your assessment, document:

• Risk owner — who is responsible for monitoring and responding to this risk?
• Mitigation actions — what can be done now to reduce likelihood or impact?
• Trigger conditions — what signals tell us this risk is materialising?
• Response plan — what will we do if the risk occurs?
• Contingency — what's our backup if the first response doesn't work?

Example:

Risk: The client's content team may not deliver final copy by the agreed deadline.

Owner: Project Manager

Likelihood: Medium, Impact: High

Mitigation: Set interim content deadlines two weeks before the final deadline. Provide content templates and examples. Schedule weekly content check-ins starting at project kickoff.

Trigger: Content is more than 3 days behind at any interim checkpoint.

Response: Escalate to client lead. Offer to bring in a copywriter at additional cost. Adjust the project timeline and communicate the impact.

Contingency: If content is delayed by more than one week, pause development of content-dependent pages and resequence the project plan.

Plan

You're not a fortune teller. Despite your best efforts to put safeguards in place or course correct, project pitfalls will happen. Whip-smart PMs know it's important to have both an emergency response plan (to handle the risks that come true) and a contingency plan (to prevent risks from striking twice or, dare we say, thrice).

By the end of this stage, you will have a thoughtful summary of best-laid plans to take with you as you traverse this risky world of ours.

Your final risk management plan should include:

1. Risk register — a living document listing all identified risks, their scores, owners, and mitigation plans
2. Response triggers — clear conditions that indicate when to act
3. Escalation paths — who needs to be informed and when
4. Contingency budgets — time and money set aside for risks that materialise
5. Review schedule — when you'll revisit and update the risk register

Share this plan with your team and stakeholders. A risk plan that lives only in the PM's head helps no one. Make it visible, make it accessible, and make it a regular topic in your project meetings.

How to manage risks in project management

Project management software

Some PMs use software to help track risk. The right PM software can help you keep on top of documentation and collect data about common risks. This data can provide aggregated insights that help inform future decisions and preparations. The tool we teach to our apprentices does it.

Risk assessment matrix

Want to really lay your risks out on the lawn? A risk assessment might be the crystal-clear vision that you are after. Not to be confused with a RACI matrix, a risk assessment matrix organizes your risks by severity and likelihood to give a high-level overview that is digestible at a quick glance. If this sounds like your thing, we've got a template for you.

DIY risk management tracker

If neither of the above options works for you, you can roll your own. There's no wrong way to do it as long as you at least include the risk name, owner, probability, and outcome. This resource from the Bureau of Digital offers a great example of what a DIY risk register looks like.

What to include in a risk register

At minimum, your risk register should track:

• Risk description — what is the risk, clearly stated
• Category — people, schedule, scope, financial, technical, etc.
• Likelihood — low, medium, high (or 1–5)
• Impact — low, medium, high (or 1–5)
• Priority score — likelihood × impact
• Owner — who's responsible for this risk
• Mitigation plan — what you're doing to reduce it
• Status — open, monitoring, mitigated, occurred, closed
• Date identified — when you first logged it
• Last reviewed — when you last checked on it

Keep it simple — a spreadsheet or a table in your PM tool works fine. The value isn't in the format; it's in the habit of maintaining it.

Common risk management mistakes

Even experienced PMs fall into these traps:

• Treating risk planning as a one-time activity — risks change throughout a project. A register you created at kickoff and never looked at again is worse than useless; it gives false confidence
• Only identifying negative risks — positive risks (opportunities) deserve attention too. If you only plan for what could go wrong, you'll miss chances to make things go very right
• Being too vague — "the timeline is tight" isn't a risk. "The QA phase has only 3 days allocated, and if more than 5 bugs are found, we'll miss the launch date" is a risk you can act on
• Not assigning owners — a risk without an owner is a risk no one is watching. Every risk should have a name attached
• Ignoring low-likelihood, high-impact risks — these are the "black swans." They're unlikely, but when they happen, they're devastating. At least have a contingency plan
• Confusing issues with risks — a risk is something that might happen. An issue is something that has happened. Track them separately — risks go in your risk register, issues go in your issue log
• Not communicating risks to stakeholders — clients and leadership need to know about significant risks. Hiding risks to avoid uncomfortable conversations only makes things worse when they materialise

---

Pointing out risks sometimes feels like shining a spotlight on an empty stage—you can't always catch the culprit midflight, but you can try. Think of the pain if you don't. It festers. But brave project leaders fearlessly tackle risk management and stop these risk monsters in their tracks. Yes, your future self will thank you.