What Makes a Risk Register Useful?

Article

A risk register is useful when it changes a decision: what is watched this period, where contingency is held, which interface needs a meeting, which remaining duration in the programme is still a guess. If the register cannot support those decisions, it is a compliance artefact. Many projects maintain both without noticing they are not the same document.

A risk is an event, not a department

“Weather,” “design,” and “contractor performance” are categories. They are too broad to own. A usable entry names a plausible event: late issue of foundation-loads for Block B; a known utility relocation that has no agreed access window; a single-source vendor with no tested alternative. The cause and the effect should be separable. If the line item is only a desired outcome (“finish on time”), it is a objective, not a risk.

Scoring that can be challenged

Probability and impact scores are only helpful if two competent readers would place the item in the same band for the same reasons. Vague red/amber/green labels without a stated scale cannot be compared from month to month. Where a time or cost range is given, the basis should be visible: a remaining-duration range, a quote, a historical production rate — not a round number chosen because it looks serious.

Ownership and response

Every live item needs a named owner who can actually act, not a company name. The response should be a verb with a date: order long-lead spares by Friday; freeze the interface drawing; add a logic tie once the access date is confirmed. “Monitor” is acceptable for a short period. It is not a response if it repeats for six reporting cycles with no change in residual rating.

• Identify: the event, where it would appear in the work, and the evidence that it is still live.
• Assess: a stated scale for likelihood and for time/cost/safety effect.
• Respond: mitigate, transfer, avoid, or accept — with an action, not a slogan.
• Review: residual rating after the action, and a date for the next check.

Connection to time and cost

A register that never touches the programme or the cost forecast is describing a parallel project. Material time risks should be visible as remaining-duration uncertainty, logic options, or schedule-risk inputs. Material cost risks should be visible in contingency or in the estimate to complete. The register does not have to duplicate those files. It does have to point at them.

Quantitative schedule risk analysis is a different product. A useful qualitative register is still worth keeping when a simulation is not justified. The failure mode is not the absence of a Monte Carlo run. It is a list of worries that cannot be checked, owned, or closed.