Why most risk registers cannot be quantified
Ask ten UK project controls practitioners whether their risk register is "QRA-ready" and nine will say yes. Ask them to export the register and feed it into a Monte Carlo model and the answer changes. Most registers, however diligently maintained, are structured for qualitative risk management — RAG-rated reviews, owner follow-ups, monthly status — rather than for quantification. Converting them to QRA-ready format is often a rebuild, not a transformation.
The gap is structural. A QRA-ready register needs each risk to have: a probability expressed as a decimal (not a band), an impact expressed as a distribution on schedule days and/or cost (not a band), explicit mapping to the schedule activities or cost lines the risk would affect, and a separation between inherent uncertainty and discrete risk events. Most registers have none of these in a directly usable form — probabilities are scored 1-5, impacts are scored low/medium/high, the mapping to schedule and cost is implicit at best, and variability and event risk are mixed together.
The practical consequence is that when the project decides to commission a QRA, the first 30-40% of the effort goes into rebuilding the register so it can actually be quantified. This is wasted effort that could have been avoided by structuring the register correctly from the start. The cost of doing it right on day one is low; the cost of retrofitting is substantial.
The risk statement format that supports quantification
A well-structured risk statement follows a cause-event-consequence format: "Because of [cause], there is a risk that [event] occurs, which would lead to [consequence]." This format forces clarity about what is being managed. The cause is the underlying condition that creates the risk. The event is the discrete occurrence being modelled. The consequence is the impact that drives the cost and schedule effects.
Without this discipline, risk statements drift into vague summaries that cannot be quantified. "Supplier performance" is not a risk — it is a category. "Because supplier X has limited experience with the required specification, there is a risk that delivery is late or defective, leading to rework and schedule delay on the commissioning critical path" is a risk. The second version is quantifiable; the first is not.
The cause-event-consequence format also supports mitigation planning. A mitigation that addresses the cause (earlier supplier qualification, alternative supplier identification) is different from one that addresses the event (enhanced receipt inspection) or the consequence (float in the commissioning programme, parallel commissioning paths). A register that does not distinguish between cause, event and consequence often lists "monitor closely" as its mitigation — which is not a mitigation.
Probability: bands are not enough
Most registers score probability on a 1-5 scale: very low, low, medium, high, very high. This is fine for qualitative review but inadequate for quantification. A QRA needs a probability expressed as a decimal — 0.15, 0.30, 0.55 — so the Monte Carlo simulation can sample the risk event at the correct frequency. Converting bands to decimals is a common source of trouble: "medium probability" could mean 0.30 to 0.50 depending on the scoring framework, and different team members will use different numbers if the mapping is not explicit.
The better approach is to define the probability bands with decimal ranges from the start: "1 = 0-10%, 2 = 10-25%, 3 = 25-50%, 4 = 50-75%, 5 = 75-95%", and record the specific percentage used for quantification alongside the band. This maintains the simplicity of banded scoring for reviewers while giving the QRA model a specific decimal input that can be traced.
There is also a case for eliciting probability directly as a decimal during risk workshops, rather than via bands. Asking "what is the probability this risk materialises" and getting an answer of 0.35 or 0.55 works for experienced risk practitioners, although it requires more facilitator discipline to avoid everyone clustering on the same round numbers. Hybrid approaches — banded for routine review, decimal for QRA quantification — are common and workable.
Impact: distributions, not single numbers
The impact side has the same issue and is often worse. Registers typically score impact on a 1-5 scale against cost and schedule criteria. For QRA, the impact needs to be a distribution — typically three-point, sometimes PERT — covering the range of cost and schedule effects if the risk materialises.
The elicitation question is not "what is the impact if this risk occurs?" but "if this risk occurs, what is the range of cost and schedule impact, and what is the most likely point within that range?". A single-number impact ("£500k") assumes certainty that is never real; a three-point impact ("£200k low, £500k most likely, £1.2m high") reflects the actual uncertainty.
The range matters because the tornado chart in the QRA output will rank risks by their contribution to variance — which depends on both probability and impact range. A risk with a 0.3 probability and a narrow £200-300k impact is less influential than one with the same probability and a £100k-2m impact, even if the mid-points are similar. Register formats that only capture a single impact value systematically obscure this distinction.
Mapping to schedule and cost
For QRA, every quantifiable risk needs to be mapped to the activities in the schedule or the cost lines in the estimate that it would impact. This mapping is what allows the Monte Carlo simulation to apply the risk's impact at the right point in the model rather than as a generic addition to the total.
A schedule risk impacting the critical path has different effect on project completion than the same risk impacting a non-critical activity with float. A cost risk affecting the structural steel package has different total cost implication than a similar-magnitude risk on the M&E package if the two packages have different escalation exposure. The mapping captures this.
Most registers do not have this mapping explicitly. The risk owner knows which activities the risk affects; the QRA practitioner does not, and has to reconstruct the mapping by asking. A register field that captures the mapping — "Schedule activities: B-100, B-105, B-110" or "Cost lines: WBS 3.2.1, 3.2.3" — keeps the information where it belongs and avoids the reconstruction effort each time the QRA is refreshed.
Separating inherent uncertainty from event risk
The classic confusion in register construction is bundling inherent uncertainty (variability in activities that definitely will happen) with event risk (things that might or might not happen). Entries like "risk of weather delay" can represent either — the unavoidable effect of seasonal weather on outdoor work, or the specific risk of an extreme weather event. These are different and should be modelled differently.
Inherent uncertainty belongs in the three-point estimates on the activities themselves. If outdoor concrete pours in winter months typically take longer than in summer months, that is variability — capture it in the pessimistic end of the three-point estimate for the relevant activities. If there is a 15% probability that an extreme weather event disrupts work for 2-4 weeks, that is an event risk — capture it in the register as a discrete entry with probability and impact distribution.
Registers that mix these produce QRA models where the weather impact is counted twice — once in the activity distributions and once in the register — or not at all, if the register entry is assumed to replace the variability treatment. Either failure undermines the confidence position. The discipline of separating variability and event risk at register construction is what prevents this.
Ownership and governance that keeps the register live
A QRA-ready register is only useful if it stays current. Each risk needs a named owner with authority to manage the mitigation and monitor the probability and impact inputs over time. A risk whose owner has left the project, or whose owner cannot authorise the mitigation, is a risk the register is tracking but nobody is managing.
The review cycle matters. A register updated every six weeks with full review (probability, impact, mitigation progress, inputs to the QRA refresh) keeps the data live. A register updated at year-end or only when the QRA is re-run produces QRA outputs that reflect the position as it was months ago, not as it is now. For UK major programmes, monthly or six-weekly register cadence with quarterly QRA refresh is a practical discipline.
The integration with the Early Warning Register on NEC4 contracts is worth attention. Early warnings feed potential risks that should flow into the risk register; mitigated early warnings might resolve as risks that drop off the register without ever being formally quantified. The two registers should be run as complementary tools by the same risk owner group, not as separate workstreams that lose information between them.
Putting it together
Structuring a risk register to be QRA-ready from day one takes marginally more discipline than structuring it for qualitative use only — and saves substantial effort when quantification is required. The four structural choices that matter most: cause-event-consequence risk statements, decimal probabilities alongside banded scores, three-point impact distributions alongside banded scores, and explicit mapping to schedule activities and cost lines.
Teams that adopt these conventions find that their register supports both qualitative review (RAG status for the monthly pack) and quantitative analysis (inputs to the QRA model) from the same document. There is no "QRA register" and "management register" — there is one register, structured so both audiences can read the information they need from it.
SOMA helps clients stand up risk registers in this format from project inception, and restructures registers mid-programme when the controls function needs to move to a more mature quantitative footing — including on MoD CADMID programmes where the register has to feed both the IPA gateway QRA and the ongoing risk-management cadence between gates. The change pays back within one QRA cycle — not having to rebuild the register is a significant saving — and produces better risk management in the interim because the discipline of the format surfaces weaker risk statements and forces them to improve.