Risk Management is not a Loose or Subjective Discipline: How to Make your Risk Register Actually Useful

Recently, a Project Manager asked me (and it's not the first time I have been asked this) "how do we use the risk register to actually make a difference on the project?"

Now, I could have been offended that he thought that a risk register might not be useful on his project, or I could have launched into talking about Monte Carlo simulations to help his project (I do love a Monte Carlo). But what he really was getting at is a key insight that a lot of people feel. A feeling that their risk registers are just too subjective or too full of uncertainty to really make a difference.

It's a valid observation in many cases. Registers filled with vague assumptions and "maybes" rather than facts representing the loose, woolly side of Project Management. Probability scores with no rationale, ambiguous risk descriptions, and cluttered registers that read more like anxiety journals than the strategic decision-making tools and drivers of action that are needed on your project.

So what's the answer to the question about what an "actually useful" Risk Register looks like then?

A good risk register is like a good schedule or cost model: a representation of realities, or in the case of risk, potential realities, on your project. Risks must be specific and relevant, not vague, subjective or (dare I say it) politically motivated. Only then do you create a tool that provides informed decision-making and prioritises the actions of the project team.

Here’s the truth then: Risk management is not meant to be loose, fluffy, or subjective. It should be treated as a structured, technical discipline. When it’s not, it becomes a tick in a box and loses its value. Why don't we fix that?

Focus on What Matters Most - The Pareto Principle

Imagine your risk register only included the few most significant, high-impact potential events. Events that have (or something similar has) happened before, that could majorly affect your project if left unmanaged.

It would be clear and simple. It would be actionable. And, let’s face it, might actually be useful. Think of how proud Wilfredo Pareto would be as well, if you focused on the 20% of the risks that usually drive 80% of the exposure.

To achieve this, evaluate each risk with a critical eye. Ask things like: Is there really sufficient likelihood of this derailing us from our objectives for us to bother documenting it? Can it be tied to a specific cause? Does the impact of the event genuinely impact the project’s objectives? Am I only writing this risk because I'm trying to get someone to do their job properly?

If it feels like a vague worry rather than a defined event, you probably should think about leaving it out and maybe tracking that elsewhere, if at all.

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

— Antoine de Saint-Exupéry

This approach not only streamlines your register but also aligns it with the project’s core objectives and eliminates entries that no one really believes in but are scared to delete “just in case.”

Could You Model It? Risks Grounded in Reality

For a risk register to be useful, every entry must be quantifiable and somehow mappable to your project’s framework. Put another way, if you went to the doctor and said, ‘Something might be wrong somewhere here,’ you wouldn’t expect a treatment plan, you'd be asked exactly where the pain is and when it started. Same goes for your risk register.

When building a quantitative model, such as a Cost and Schedule Risk Analysis (CSRA), you are forced to link risks to specific schedule activities and/or cost lines. While performing this discipline as a Consultant, I experienced countless times how vague or unrealistic risks start dropping like flies when subjected to this rigour, i.e. defining them properly and mapping them to the actual model of the project.

If a risk couldn't be simulated with clear impacts on the model, if it couldn't stand up to the test of simulation, have a think about why it's on your Risk Register in the first place and whether it needs to be there.

Risks are Specific and Relevant, but are also Dynamic

Risks, though not loose or subjective like we said, are nevertheless subject to continual change as they are mitigated over time, or as the project progresses.

This dynamic nature actually demands more rigour to the updates, the mitigations, and the reporting, not less.

A robust risk register requires rigorous updates, clear mitigation plans, and concise reporting to reflect these changes. Each update should communicate the current state of risks and the effectiveness of mitigation efforts over time. Another reason, if one were needed, to focus only on the ones that matter.

As a dynamic part of your project (even if you only have 10 or even 5 risks), the risk register is an essential document containing things that people really need to know about. If you swamp your risk register with too much bloat, visibility and focus will be lost and people won't see the great work mitigating and updating the risks you are doing over time.

Real Project Risk Management

A serious risk register doesn’t need to be long. It needs to be clear, simple, actionable, grounded in the reality of the project and giving a clinical view of events that could happen along the way on the project.

If you want risk to be taken seriously - by leadership, by stakeholders, by your own team - then treat it as seriously as you would your schedule or your cost model. Disciplined insight and thorough review into what could go wrong and what you’re doing about it.

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.

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!