The Paperwork Problem
Most risk registers are paperwork. They exist because the project management methodology requires them, or because the client asked for one, or because the auditor needs to see one. They are created at the start of the project, filed in a folder, and updated occasionally when someone remembers. They have no impact on the project's outcome because they are not used to make decisions.
I have seen risk registers with 200 risks listed, each with a probability and impact score, each with a mitigation plan, and none of them have prevented a single problem. The reason is simple: a risk register that lists 200 risks is not a management tool — it is a catalog. No project manager can actively manage 200 risks. The register becomes noise, and noise gets ignored.
The Margin Protection Principle
The purpose of a risk register is not to document risks. The purpose is to protect margin. Every risk on a project has a potential cost impact, and the sum of those potential costs is the risk exposure that threatens the project's profit margin. A risk register that does not connect risks to margin is not doing its job.
This principle changes how you build the register. Instead of listing every possible risk, you list only the risks that could materially affect the project's financial outcome. A risk with a $5,000 potential impact on a $50 million project is not a risk that belongs in the register — it is a operational issue that the site team handles. A risk with a $2 million potential impact is a risk that belongs in the register, because $2 million is 4% of the project's value and could be the difference between profit and loss.
Building the Register: The Top Ten
I advocate for a risk register that has no more than ten active risks at any time. Ten risks can be actively managed — reviewed weekly, updated with new information, and discussed at every project meeting. Two hundred risks cannot.
The selection criteria for the top ten are simple: the risk must have a potential cost impact greater than 1% of the project's margin, and it must be a risk that the project team can influence through mitigation. Risks that cannot be influenced (force majeure, macroeconomic shifts) are noted but not actively managed — they are contingency items, not mitigation items.
Each risk in the top ten has a standard set of fields: description, probability (high/medium/low), cost impact (dollar value), schedule impact (days), mitigation plan, owner, target resolution date, and current status. The key field is the cost impact — this is what connects the risk to the margin. When the register shows that the top ten risks represent a combined exposure of $4.5 million against a project margin of $5 million, the project manager knows exactly how much of the margin is at risk.
The Weekly Risk Review
The risk register is not a static document. It is a living management tool that is reviewed every week. The weekly risk review is a 15-minute agenda item in the regular project meeting. Each of the top ten risks is reviewed: has the probability changed? Has the impact changed? Has the mitigation plan been executed? Are there new risks that should replace one of the current ten?
This weekly cadence is what transforms the register from paperwork into a management tool. When the team knows that risks will be discussed every week, they pay attention to risks during the week. When the register is updated with new information every week, it stays current and credible. When the project manager can say 'our risk exposure has increased by $500,000 this week because risk X's probability went from low to high,' that is a statement that drives action.
Connecting Risk to Contingency
The risk register should directly inform the project's contingency budget. The total risk exposure — the sum of (probability × impact) for all active risks — is the minimum contingency the project should hold. If the risk exposure is $4.5 million and the contingency budget is $2 million, the project is under-reserved, and the project manager needs to either increase the contingency or reduce the risk exposure through additional mitigation.
This connection between risk and contingency is what makes the register a decision-making tool. When a sponsor asks 'do we have enough contingency?', the answer is not a guess — it is a calculation based on the risk register. When a risk materializes and contingency is consumed, the register shows exactly which risk caused the consumption and how much of the remaining exposure is still outstanding.
Risk Closure and Learning
Risks are closed when they are no longer risks — either because the mitigation was successful and the probability dropped to near-zero, or because the risk materialized and became an issue (and the cost was absorbed). Both outcomes should be recorded. The closure record for a mitigated risk shows what worked — which mitigation actions were effective, which were not. The closure record for a materialized risk shows what was learned — what early warning signs were missed, what could be done differently next time.
Over time, these closure records become a knowledge base that improves risk identification on future projects. The risks that materialized on the STC FTTH programme informed the risk registers I built for subsequent healthcare and hospitality projects. The specific risks were different, but the patterns — supply chain delays, permit uncertainty, contractor scalability — were transferable.
The Register as a Communication Tool
The risk register is also a communication tool. When the project manager goes to the sponsor and says 'we need an additional $1 million in contingency because three new risks have been identified,' the register provides the evidence. When the project manager tells the team that risk X is the priority for this week, the register provides the rationale.
The most effective risk communication I have used is a one-page risk summary that shows the top ten risks, their combined exposure, the contingency balance, and the trend over the last four weeks. This one-pager goes to the sponsor monthly, and it tells the story of the project's risk position in a format that takes two minutes to read and understand.
That is what a risk register should be: not a folder of paperwork, but a one-page summary that tells the sponsor whether their margin is safe, and a weekly management tool that tells the project team where to focus their attention.
