Project Risk Management: What Could Go Wrong (And How We Figure It Out)
Early in my career, I thought I had risk management nailed. I ran the right workshops, filled out the risk register, colour-coded everything red, amber, green, and listed out every mitigation action. It looked complete.
But during one rail project. We were testing a new machine and we missed something simple but important. We'd followed the process, but we hadn't looked beyond the project. We didn't stop to ask how our work might affect the operations team or what the wider impacts could be.
Some of those risks did materialise. It wasn't just operational disruption, it could have easily become reputational too. We weren't far off making the news.
That experience showed me that you can follow the process and still get caught out. Because risk management isn't just about ticking boxes. It's about thinking wider, asking better questions, and including the right people in the conversation.
What Is Risk Management?
When we talk about project risk management, it's easy to jump straight to logs and templates, but it starts with mindset.
According to the Association for Project Management (APM):
"Risk management is a process that allows individual risk events and overall risk to be understood and managed proactively, optimising success by minimising threats and maximising opportunities."
When we look into the future, we can't always predict how things will play out. But in every walk of life, we try to guess what might go wrong. If the chance of something going wrong is high, we usually do something about it: we adapt, prepare, or change course.
That's the heart of project risk management.
It's not about spreadsheets or processes. It's about asking the right questions early enough to give your team a better chance of success. In simple terms:
Risk management is about exploring uncertainty so we can act before things go wrong or seize a chance to make things go right.
Why Risk Management Matters
Projects rarely run in a straight line. Unexpected issues, delays, and changes are part of the territory. But many of them are avoidable or at least manageabl, if spotted early.
That's where risk management comes in. When done well, it helps you:
Avoid nasty surprises that derail progress
Make smarter decisions with better foresight
Get ahead of problems, not just react to them
Spot opportunities to deliver better, faster, or cheaper
Build trust with teams and stakeholders by showing you're thinking ahead
Risk management isn't extra admin. It's how we lead with clarity.
Where Do Risks Come From?
Most risks have common origins. Understanding these sources helps you know where to look when identifying potential problems or opportunities.
Here are five common sources:
Assumptions: Things we believe are true, but haven't confirmed. "We'll get the permits in time."
Uncertainties: Areas where the outcome is unclear. "We've never worked with this supplier before."
Unknowns: Things we simply can't foresee. "What if new regulations are introduced halfway through?"
Constraints: Time, money, resources or dependencies that limit flexibility. "We only have one weekend access window."
Past patterns: Known issues from similar projects that resurface if ignored. "It's gone wrong before, are we doing anything differently this time?"
What Is a Risk in Project Management?
In simple terms, a risk is something that might happen and could affect your project.
It could be negative, something going wrong (we call that a threat), like a delay, extra cost, or missed deadline.
Or it could be positive, something going better than expected (we call that an opportunity), like finding a faster way to deliver or saving money.
If a threat actually happens, it turns into an issue that you need to manage right away.
Good risk management means staying alert to both sides: stopping problems before they hit, and spotting ways to make the project even better.
A Simple Risk Management Process (That Actually Helps)
You don't need to be an expert in risk. You just need a process that makes sense and works in real life. Here's one I use across most of my projects, from railway upgrades to construction projects.
1. Spot the Risk (Identify)
This is about finding and documenting potential risks before they become problems. You're actively looking for what could go wrong (threats) or what could go better than expected (opportunities).
Don't overcomplicate this. Risk identification isn't about filling templates or running formal workshops (though those can help). It's about honest conversations and asking the right questions.
Start simple. In your next team meeting, ask:
"What could go wrong here?"
"What assumptions are we making that might not be true?"
"What would we regret not preparing for?"
"What's the one thing that could catch us off guard?"
"What happened on similar projects?"
The best risks come from different perspectives. Talk to your delivery teams, they know where things usually break. Chat with suppliers, they've seen this movie before. Check in with stakeholders, they understand the politics and constraints you might miss. Don't forget end users, they often spot practical risks that technical teams overlook.
Write everything down somewhere accessible. Ideally in a risk log, think of it as your project's worry list. It doesn't need to be sophisticated. Even multi-million pound programmes can work with a simple spreadsheet. What matters is that it's visible, updated, and used.
2. Understand It (Assess)
Once you've got your risks, you need to work out which ones to lose sleep over. For each risk, ask three simple questions:
How likely is it to happen? Don't overthink this. Is it almost certain (like "the client will change their mind"), quite possible ("key supplier might be late"), or unlikely but worth watching ("new regulations could be introduced")?
How bad would it be if it did? Would it be a showstopper? Cause major delays? Or just be a minor hassle? I think about it like this: would I need to call my boss immediately, mention it in the weekly report, or just handle it myself?
When might it hit? Is this something that could happen next week, or is it a slower-burning risk that might emerge in three months? Near-term risks need immediate action. Longer-term ones need monitoring.
This isn't about precise percentages or complex matrices. It's about understanding what matters most. That risk about the printer not working? Probably not worth your time. The risk about your specialist engineering resource leaving that could bring the project to a standstill? Yeah, let's talk about that one.
3. Decide What to Do (Respond)
Every significant risk needs a response, not just documentation. You've got different options depending on whether it's a threat or an opportunity.
For threats (things that could go wrong):
Avoid it: Change the plan so the risk disappears. Dependent on third-party deliverables you can't control? Bring that work in-house to eliminate the dependency if viable.
Reduce it: Make it less likely or less painful. Worried about a supplier? Build in buffer time or line up a backup.
Transfer it: Share the risk with someone else. Include warranty provisions in the contract to transfer defect risks to the vendor.
Accept it: Sometimes you just have to live with it. But monitor it. Accepting doesn't mean ignoring.
For opportunities (things that could go better than expected):
Exploit it": Make sure the opportunity happens. Found a faster delivery method? Restructure the plan to guarantee you can use it.
Enhance it: Increase the probability or positive impact. Early finish looking possible? Add resources to make it more likely.
Share it: Partner with others to maximise the benefit. Potential to deliver a new capability early? Partner with another team who can help resource and benefit from it.
Accept it: Be ready to take advantage if it happens. Monitor and be prepared to act if the opportunity arises.
The key is taking action, not just writing "monitor and review" next to every risk (we've all done it).
4. Assign Ownership (Allocate)
This is where most risk management falls apart. If no one owns it, no one manages it.
Every significant risk needs a name next to it, not "the team," not "TBD," but an actual person who'll be accountable if it happens. They don't have to fix it alone, but they need to track it, update it, and raise the flag if it's getting worse.
In my experience, people are happy to own risks when they understand why it matters and have the authority to do something about it. Don't just dump risks on people. Have a conversation: "This could really impact your area, would you be best placed to keep an eye on it?"
5. Review Regularly (Monitor)
Here's the truth: most risk registers die after the first month. They get created with enthusiasm, then sit untouched while real risks evolve and new ones emerge.
Build risk reviews into your existing rhythm. You don't need a separate meeting. Take 10 minutes in your weekly team catch-up:
"Any new risks emerged this week?"
"Any of our existing risks getting worse?"
"Any we can close off?"
Keep it conversational. I've found that informal risk chats over coffee often surface more real concerns than formal monthly risk reviews.
Remember: risks are dynamic. That supplier risk that seemed minor when you had six months? It's critical when you're six weeks from delivery. That regulatory change that seemed unlikely? It might be moving through parliament right now.
Risk Categories (So You Don't Miss the Big Stuff)
To help teams think more broadly about what might go wrong (or right), it helps to group risks into a few common categories:
Delivery Risks: These are the classic ones: delays, budget overruns, scope creep, or poor quality. They're the things most people think of first.
People Risks: Projects rely on people. That includes availability, skills, morale, or changes in team members. Losing a key person mid-project can have a bigger impact than a missed milestone.
Operational Risks: These are risks that affect the day-to-day running of services, systems, or business operations. In my earlier story, we missed risks that impacted the operational team and it nearly caused much bigger problems.
External Risks: These come from outside the project's control: weather, supply chain issues, new regulations, political changes. Anything from the outside world that could impact delivery.
Reputational Risks: These are about perception. If something goes wrong, who will hear about it? Will it damage trust with your stakeholders, customers, or the public? In that same project, it wasn't hard to imagine our testing incident ending up in the Evening Standard.
Use these categories as a guide to help you think wider, not as a checklist but as prompts to ask better questions.
The Real-World Side of Risk Management
Risk management in real projects isn't perfect. It's often not as neat or linear as the textbooks suggest. Here's what I've seen time and again:
Risk registers created at the start and never updated I once inherited a project where the risk register still listed "Easter holidays might affect progress", it was October. No one had looked at it since March. The real risks? They were being managed in WhatsApp messages and corridor conversations, completely invisible to governance.
PMs scared to raise risks because it might "look bad" In steering committees, everyone often knows the deadline is impossible, but no one wants to be the person who raises it. One PM told me: "If I flag too many risks, they'll think I can't handle the project." So instead, we all pretend everything's fine until it explodes.
The "green watermelon" effect Everything's green on the outside (the status reports) but red on the inside (reality). I've seen projects report green status right up until the week they failed. Why? Because admitting yellow or red means uncomfortable conversations today, while keeping it green means you can defer that pain until tomorrow.
Risk theatre vs actual risk management We run the workshops, fill the templates, update the logs. But is anyone actually doing anything different? I've been in projects where we spent more time formatting the risk register than actually managing risks. Perfect heat maps, pristine documentation, but when a real issue hit? "Oh, we never saw that coming."
The "that's not my risk" game "That's a technical risk, not a project risk." "That's a business risk, we only manage delivery risks." "That's a supplier risk, not our problem." I've watched critical risks bounce between departments like a hot potato while everyone argues about whose register it belongs in.
In reality, the best risk management happens when teams treat it as part of delivery, not an isolated task. It's honest, collaborative and transparent.
It's far better to say:
"This might go wrong and here's what we're doing about it."
Than:
Hide it in the details and hope no one asks.
Strong PMs surface risks early and create space to deal with them. Not because they're being negative, but because they want to lead with confidence and protect delivery.
The Psychology of Risk (Why It's Hard to See What's Coming)
Risk management isn't just a process, it's a human challenge.
We often rely on experience and past lessons to anticipate risks. But even with experience, there's a natural bias we all face:
We're better at spotting short-term risks than long-term ones.
This is backed by neuroscience. Our brains are wired to prioritise what feels close and tangible. Research in Neuroscience & Biobehavioral Reviews confirms that we place less weight on future risks — a concept known as temporal discounting (Peters & Büchel, 2011). If something feels far away in time, our brain treats it as less urgent or important.
That's why near-term risks (like next week's delivery deadline) get more attention than long-term threats (like that same delivery causing maintenance problems in 18 months).
The problem is, if you only focus on what's immediately in front of you, you miss the bigger risks building up. You end up in a constant cycle of firefighting: always reacting, never preventing. Every week becomes about surviving the latest crisis rather than avoiding the next one.
Painting the Future Together
The project manager's job is to help the team visualise the future, to make abstract risks feel real enough to act on.
Here's what helps:
Ask vivid, time-based questions:
"Think about the week before go-live — what could throw us off track?"
"What would we regret not preparing for?"
"What's an assumption we're treating as fact?"
Use relatable timeframes:
Instead of "Q4 risk," say "This might affect our Christmas shutdown and what would that mean for us?"
By painting the picture together, you help the team prepare with clarity, not fear.
Celebrate When It Works
Here's something we rarely do: celebrate when risk management actually works. When you avoid a major issue because someone spotted it early, that's a win. When an opportunity gets exploited and delivers extra value, that deserves recognition.
I've found that calling out these successes (Remember that supplier risk we flagged? Good thing we had that backup ready), helps teams see the value in the process. It's not just admin; it's what kept the project on track.
Keep It Real Through Reflection
Risk management can become challenging, especially when things get difficult. At key checkpoints in your project: after major milestones, at stage gates, or quarterly, take time to reflect:
Is our risk process actually helping or just creating paperwork?
What risks did we miss, and why?
What did we worry about that never materialised?
Are we learning from near-misses or just moving on?
This reflection stops you falling into the trap of just going through the motions. If your risk process isn't helping you make better decisions, change it. The goal is to manage uncertainty, not to have perfect documentation.
Risk management isn't about being negative. It's about building confidence in an uncertain world.
Risk Management Tools
Just like a project plan often ends up as a Gantt chart or schedule, risks need a place to live and be tracked.
In some industries: especially engineering, construction, and infrastructure. Tools like ARM (Active Risk Manager), Predict!, or other enterprise systems are used to manage and report on risks at scale. These tools can integrate with programme-level reporting and governance frameworks.
In other sectors, you might find simpler tools: Excel spreadsheets, risk logs in SharePoint, or even ClickUp or Jira boards with dedicated risk fields.
But here's the reality: you often don't get to choose. The tool is usually set by your organisation's wider risk strategy. So the key is learning to use what's in place well and making sure the risks are actively managed, not just filed away.
Whatever the tool, the value comes from the conversations, updates, and action not the software itself.
Key Takeaways
Risk is anything that might affect your project goals
It could be a threat (to avoid) or an opportunity (to exploit)
Risks often come from assumptions, unknowns, constraints and past issues
A simple risk process: spot it, understand it, act on it, track it, review it
Don't wait for risks to turn into issues
Help teams see the future more clearly and make it feel real enough to care
Celebrate when risk management prevents problems or captures opportunities
Risk management builds trust, not fear
What's a risk you spotted early that helped your project? Or one you wish you'd seen coming?
References
Association for Project Management (APM). "What is Risk Management?" APM. https://www.apm.org.uk/resources/what-is-project-management/what-is-risk-management/
Peters, J., & Büchel, C. (2011). "The neural mechanisms of inter-temporal decision-making: understanding variability." Neuroscience & Biobehavioral Reviews, 35(3), 463-475. https://pubmed.ncbi.nlm.nih.gov/21497544/
Want more practical PM insights like this?
Subscribe to The PM Notebook for regular insights straight to your inbox, or listen to The Real PM Podcast for honest conversations about what actually works.
Ready to bridge theory and practice? Try Mindcast - the first-of-its-kind interactive experiences I developed where you step through real project scenarios and make PM decisions hands-on. It's my way of helping and guiding you beyond traditional learning to build the practical judgment that only comes from doing.
Connect with me on LinkedIn for project management insights or get in touch to share your thoughts and experiences.