The Paperwork Problem
In late 2018, I was reviewing a risk register for a fifty-million-dollar infrastructure project with the newly assigned project manager. The register contained two hundred risks, each with a probability and impact score and a mitigation plan. I asked him: which of these risks worries you most this week? He looked at me with embarrassment and said, "I cannot pinpoint one — there are too many." That was exactly what I expected. This risk register was not a management tool — it was a catalog. No project manager can actively manage two hundred risks. The register had become noise, and noise gets ignored. By the end of the project, we lost three percent of margin on risks that were not on the list of two hundred. The risks were not unforeseen — they were unmanaged, because the register was too large to be useful.
Most risk registers I have seen in my career 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. The problem is not the concept of a risk register — the concept is sound. The problem is the execution: a register designed for compliance instead of management.
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 five-thousand-dollar potential impact on a fifty-million-dollar project is not a risk that belongs in the register — it is an operational issue that the site team handles. A risk with a two-million-dollar potential impact belongs in the register, because two million dollars is four percent 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 one percent 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 four and a half million dollars against a project margin of five 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 fifteen-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 five hundred thousand dollars 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 multiplied by impact for all active risks — is the minimum contingency the project should hold. If the risk exposure is four and a half million dollars and the contingency budget is two 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 one million dollars 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.