With about 7 out of my 20 years in Projects being in Risk Management or Consultancy, I know all about Project Risk being treated as an admin task. I also know that, done well, it’s a powerful way not only to protect your project objectives, but to give justification to act early and decisively - thus providing early warnings and driving a forward-looking culture in your team.
Unfortunately, many teams treat it like a tick-box compliance form, or worse, like a worry list. They fill it in, talk about it once a month, then get back to spinning plates. Or sometimes they ignore it altogether.

Here’s how to do it properly - and turn risk management into a genuine driver of project success.
1. Start with the Key Objectives and Context to Identify Real Risks
Starting with the project context, goals and objectives is the single most important and overlooked part of the risk management process I have seen used.
To be clear, I'm not saying re-review documents or even to spend very long with this, but starting a risk discussion with the questions "what are we delivering?", "what is important?" and "what therefore are we measuring the risks against?" can be the crucial pieces of context people need.
Is it a key priority to meet a drop-dead date? Maintain a squeaky-clean reputation? Is it a priority that the project comes in under budget? (we know the answer to this one)
The answer to any or all of these may be yes, and so start there, with that list. The priority level of these should, in the end, be reflected in the content of the risk register.
The damage is done when "not-risks" are included in the register and the team either wastes time on them or worse, doesn't bother. Nobody has the time, when you get into the weeds of the project, to trawl through hundreds of risks, many of them spurious.
Example: Office furniture not delivered on time! Schedule risk! But the IT infrastructure is the critical objective, and so while the furniture is in scope, that objective can still be achieved easily within the timeframe with furniture installed later. So unless the key objective is "we should ensure we do not have to re-jig the order in which we're doing things", leave it out!
If a risk doesn’t threaten (or help, see point 6) a project objective, it doesn’t belong on your radar. The best risk registers are focused only on what matters.
2. Don’t Forget About Opportunities
Most teams focus on threats—but opportunities are part of risk too. If there’s a realistic but uncertain chance of cutting costs, speeding up delivery, or adding high-margin scope, now's the time to flag it and write it down!
Examples:
Potential adoption of new technology to boost efficiency
Product standardisation where possible to reduce design time
Consider performing long-duration activities in parallel, if capacity allows
Replace materials with cheaper alternatives if approved
Use underutilised internal resources if they can be made useful on the project
Move scope to lower-cost regions or time periods if feasible
Leverage favourable regulatory or policy changes if they happen on time
These all include some uncertainty but with a realistic chance of a positive impact on the project objectives.
“Luck is what happens when preparation meets opportunity.”
— Seneca
I can't talk for every project, but in my experience, opportunity identification is exceedingly rare, even if everybody talks about it at the beginning of every project. Why not do it then? I have found that challenging teams to raise at least one opportunity for every risk or maybe every two risks, can be an interesting creative challenge that can sometimes bear fruit!
3. Describe Risks and Opportunities Properly
Clear articulation is everything.
If anyone in your business couldn't read and immediately understand what the risk is getting at, it needs to be re-written, because guess what. Anyone in your business might read your Risk register, including your boss, the Project Sponsor or the CEO.
Communicating clearly is fundamental to Project Management and Controls. So it is with the articulation of your project risks.
There are a couple of different ways this can be approached, depending on the risk management system used, but the bare minimum requirements are clear articulation of Risk Cause -> Risk Event -> Risk Consequence -> Risk Impact whether these are in written exactly like this, in separate fields, or written as a single sentence.
Including these fundamental elements makes the logic of each risk transparent, so everyone understands why it matters and how to respond. It also makes it easier to update, explain, and take action later on.
There is another hidden benefit to rigorously analysing what we really mean by a risk in order to articulate it properly. It helps weed out those lurking "not-risks" that have been sitting there (in the back of our minds, or on an Excel sheet) being vague. When subjected to some scrutiny, we find that we didn't really need them after all.
So, an example. Which of the following descriptions helps you understand what we're getting at with this project risk?
Description 1: "Small Supplier operating in a difficult financial environment -> Supplier enters financial difficulties -> Delays delivery of key component -> Schedule delay causing extension of time cost of project team mobilisation"
Description 2: "Supplier problems"
4. Assign Actions and Actually Manage the Risks
I'm not arguing that there isn't value in identification, awareness and reporting of project risks, after all those activities do promote forward thinking and awareness in the team. But if you want to translate the risk process into concrete improvements, get out your action tracker. We need to start treating Risk Management as the discipline that drives real action on your project.
For every significant risk, ask the questions: What are we doing about it? Who’s responsible? When will the action be done? How will we track progress? Real risk management is active.
What your project really needs is accountability and a clear line of sight between the risk and the steps being taken to manage that risk. Time to apply some rigour then, to what is sometimes seen as a woolly and subjective process. Once the mitigation actions are in place, keep them alive. Regularly review them. Not just to tick boxes, but to genuinely interrogate whether they’re working.
During each review, take the time to think the actions through and discuss them with the team. Are the actions still relevant? Are they being delivered on time? Do they reduce the exposure in the way you expected? Are there any new actions?
Final Thoughts
Follow the above 4 steps to use Project Risk Management for clarity, control, and confidence in your project execution. When you focus on the right risks, look for opportunities as well as threats, describe them properly to justify the required action, and most importantly assign and follow through on actions—it stops being a tick in a box and becomes a core part of how you lead successful projects
Here’s the test: open your current risk register and ask yourself—does this drive real action, or is it just a list of worries? If it’s the latter, now’s the time to change how you manage risk.
EMAIL NEWSLETTER
Subscribe for updates on what I'm up to and new articles, plus I have personally put together a Project Management Cheat Codes PDF containing 5 things I wish I had known 10 years ago, free for those who subscribe.
*By entering your email address, you are agreeing to our Privacy Policy and you are agreeing to receive emails from Macaulay Projects.
ARTICLE CATEGORIES

ABOUT ME
This is the website of Rod Macaulay. I'm a Project Management Professional with two decades of project experience. I love learning and writing about Project Management, Risk Management and Project Controls. Enjoy!
Created with ©systeme.io