On most projects, the risk register is created once — usually because the contract demands one — then filed and never opened again. Ask for it in month six and someone digs out a spreadsheet listing “adverse weather” and “material delay,” scored by whoever filled it in during the first week, updated never.
That document is not risk management. That’s risk documentation, and it protects nobody.
Real risk management is a simpler and much more useful habit: regularly asking “what could hurt us next?”, deciding what to do about the biggest answers, and writing down both. Here’s why it earns its keep, and how to run it without ceremony.
An issue is a fact. A risk is a forecast.
Mixing these up ruins registers. The glass supplier who iseight weeks late — that’s an issue; it exists and needs managing today. The approval cycle that coulddelay your next order the same way — that’s a risk; it hasn’t happened, and you still have moves available.
Issues go in an issues log with actions. Risks go in the register with responses. The reason the separation matters: risks are the cheap ones. A risk handled before it happens costs a phone call, an early order, a second supplier on standby. The same event handled after it happens costs weeks and money.
Score it roughly, but score it
Two questions per risk: how likely, one to five, and how bad if it lands, one to five. Multiply. Anything above 15 gets attention this week; the middle band gets watched; the small stuff gets accepted and forgotten without guilt.
Is this scientific? No. Precision isn’t the point — ranking is. Twenty risks and limited hours means you need to know which five matter. A rough P×I score sorts them in ten minutes, and it’s the ten minutes that separates managing risk from merely listing it.
Every real risk has a next move
Four options, and naming one forces honesty about whether you’re managing the risk or just admiring it:
Avoid— change the plan so the risk can’t occur. Unitized panels instead of stick-built because you doubt site labour availability.
Mitigate — reduce likelihood or damage. Order glass three weeks earlier than strictly needed. Pre-book the crane slots.
Transfer — put it contractually where it belongs: insurance, supplier LDs, a clarification letter before signing.
Accept— decide it’s tolerable, and say so on the record. Perfectly respectable, as long as it’s a decision and not a default.
A register where every line has one of these words, an owner, and a date is a management tool. A register without them is a list of worries.
The review is the management
Fifteen minutes, once a month, same agenda: any new risks? Any scores changed? Did the mitigations actually happen? Anything that landed moves to the issues log; anything that passed gets closed with a small quiet satisfaction.
That recurring fifteen minutes is the entire system. Skip it and the register dies within a quarter — I’ve watched it happen on more projects than I can count. Hold it and something interesting develops: your team starts raising risks beforethe meeting, because there’s finally somewhere for them to go and someone who’ll act on them. The register stops being your document and becomes the project’s radar.
What it’s actually worth
I once inherited a package where a single unmanaged risk — one long-lead item, no early order, no alternate supplier — cost eleven weeks and most of the project’s margin. The risk had been obvious in week one. It was even on the register. Nobody owned it, so nobody moved, so it happened at full price.
Since then I treat the register the way I treat the programme: a live document, reviewed on rhythm, with names and dates on everything. It has paid for that fifteen minutes a month every single time.
If you want a starting point, the risk register in the Project Mate librarycomes with the P×I scoring matrix built in and the response columns ready — the structure described here, waiting for your project’s answers.