Why most risk registers cannot be quantified
QRA is quantitative risk analysis. A QSRA models schedule risk and a QCRA models cost risk. Both run a Monte Carlo simulation, which means they need numbers a model can sample, and most registers hold bands and prose.
Most registers are built for qualitative management: RAG-rated reviews, owner follow-ups and a monthly status pack. Probabilities are scored 1–5, impacts are scored low, medium or high, the link to the schedule and estimate is implicit, and baseline variability sits in the same list as discrete events.
A QRA-ready register holds five things for each risk: a cause-event-consequence statement, a decimal probability, a three-point impact in days and pounds, an explicit link to the schedule activities or cost lines affected, and a clean split between event risk and the uncertainty already in the baseline. The rest of this guide takes them in turn, then adds the fields a model needs beyond them.
Retrofitting is mostly re-elicitation. As an illustration, re-eliciting a 100-risk register at ten minutes a risk is about 17 hours of workshop time (100 × 10 minutes) before any mapping to the programme or estimate has started. Building the fields in from the start spreads that effort across normal register reviews.
The risk statement format that supports quantification
Write each risk as: "Because of [cause], there is a risk that [event] occurs, which would lead to [consequence]." The cause is the condition. The event is the discrete occurrence the model switches on or off. The consequence is what drives the time and cost distributions.
"Supplier performance" is a category, not a risk. "Because supplier X has limited experience with the required specification, there is a risk that delivery is late or defective, leading to rework and delay on the commissioning critical path" is a risk, and it can be quantified.
The format also shapes mitigation. A mitigation can act on the cause (earlier supplier qualification, an alternative supplier identified), the event (enhanced receipt inspection) or the consequence (float in the commissioning programme, parallel commissioning paths). "Monitor closely" is not a mitigation. A usable one reads "Qualify an alternative supplier by week 12; decision point at week 16" (illustrative), with an owner, a date and a funding status.
Probability: bands for review, decimals for the model
A 1–5 probability score is fine for review but a model cannot sample it. It needs a decimal such as 0.15, 0.30 or 0.55, so that the simulation includes the event in that proportion of iterations. "Medium" can mean 0.30 on one team and 0.50 on another unless the mapping is written down.
Define bands with non-overlapping ranges and a tie-break rule. For example: 1 = under 10%, 2 = 10% to under 25%, 3 = 25% to under 50%, 4 = 50% to under 75%, 5 = 75% to under 100%. Each lower bound is inclusive and each upper bound is not, so 25% is band 3. Something certain to happen is an issue, not a risk, and belongs outside the model's event list.
Record the specific elicited decimal next to the band, and feed that value to the model. Using the band midpoint distorts the tails, because a risk at 0.12 and one at 0.22 would both be entered as 0.175.
Eliciting the decimal directly works with experienced people but needs facilitation, because rooms cluster on 0.25 and 0.50. Bands for routine review with a decimal for quantification is a workable hybrid.
Impact: ranges, not single numbers
Impact needs a distribution for each of time and cost: a minimum, a most likely value and a maximum. Ask "if this occurs, what is the range of effect, and where is the most likely point within it?" A single "£500k" implies certainty. "£200k, £500k, £1.2m" says what is actually known.
The three points are fitted with a distribution shape, usually triangular or PERT (a beta distribution). PERT puts less weight on the extremes than triangular does, so the choice changes the tails of the output. Agree it once for the model and record it.
Range matters because the tornado chart ranks risks by their contribution to variance, which depends on probability and on the spread of impact. At the same 0.3 probability, a risk of £200k–£300k contributes less to the spread than one of £50k–£450k, even though both have a mid-point of £250k. A register that stores one impact value hides that difference.
Mapping to activities and cost lines
Each quantifiable risk needs the schedule activities or cost lines it affects. The risk owner knows them. A QRA analyst who is not given them has to ask, and has to ask again at every refresh. Record them in the register, for example "Schedule activities: B-100, B-105, B-110" or "Cost lines: WBS 3.2.1, 3.2.3".
The mapping decides how much of a risk reaches the finish date. Take an illustrative risk with a probability of 0.40 and a schedule impact of 5, 10 and 30 working days (triangular, mean 15 days). Mapped to a critical activity, it adds a mean of 15 days when it occurs, which is 6 days across all iterations (0.40 × 15).
Now map the same risk to an activity with 15 days of float. Under a triangular 5/10/30 distribution there is a 55% chance the delay is fully absorbed, and the expected delay beyond the float is 2.25 days. Across all iterations that is 0.9 days (0.40 × 2.25). The same risk contributes 6 days or 0.9 days to the finish depending on where it is mapped, and that difference flows through to the P80. These are single-activity figures. In a full network, other paths can become critical, which is why the simulation does the final calculation and why the mapping has to be right.
Separating baseline uncertainty from event risk
Variability in activities that will happen is different from events that might. "Weather delay" can mean either. The routine effect of winter on outdoor concrete pours is variability, and it belongs in the three-point durations of the activities concerned. A 15% chance (illustrative) of an extreme weather event stopping work for 2–4 weeks is an event, and it belongs in the register with a probability and an impact range.
Mix the two and the weather is counted twice, once in the durations and once in the register, or not at all if the register line is assumed to replace the duration treatment. Either way the confidence position is wrong. The same test applies to cost: if the estimate already carries an allowance for the uncertainty, the register line should cover only what is not in it. Use the "In the baseline?" field to record the decision.
Untreated and treated values, correlation, opportunities and secondary risks
Record probability and impact twice: untreated (no further action) and treated (after mitigation). The difference shows what the mitigation is worth. For the model, use the treated values only where the mitigation is in place or funded and in progress. A mitigation that is hoped for but not approved stays untreated.
Risks that share a driver move together. Late design information, one supplier, a single weather window and one approvals body are typical examples. Sampled independently, they understate the spread of outcomes. Record a correlation group or shared driver for each, so the analyst can model a common driver risk or apply correlation deliberately and justify it.
Opportunities use the same fields with a negative impact, and should sit in their own lines so a saving is not netted against a threat before the model runs. A mitigation can also create a new risk, such as an acceleration measure that raises cost or safety exposure. Register it as a secondary risk with its own probability and impact.
A field-by-field register structure
The table on this page lists the fields we recommend, with the reason each one is needed for quantification. It is a column list you can copy into a spreadsheet or risk tool. The model cannot use a line without probability, impact range and mapping, so enforce those three before any refresh.
The NEC4 Early Warning Register and the project risk register
Under NEC4 ECC the contractual register is the Early Warning Register, kept by the Project Manager and updated under clause 15 after early warning meetings. It records matters either party has notified as able to affect cost, time or performance, with proposals to avoid or reduce them and decisions taken. It is a contractual notification record. It does not hold probabilities, impact ranges or a link to the programme. Check the clause text and the Contract Data for the contract in front of you.
The project risk register is a different document. The client, the contractor and often the supplier each keep one, and the quantified version used for a QSRA or QCRA is a management tool with no contractual status. The two registers should be reconciled and not merged. Each early warning should either map to a risk ID in the project register or be closed with a note that it is immaterial. Each quantified risk that is also a notified matter should carry the early warning reference. When an early warning becomes a compensation event, the matter leaves the risk register and moves to change control, and the model should take it out of the risk list and put the agreed or assessed effect in the baseline.
They will not match line for line, because a contractor's register includes risks the client does not own. Name who reconciles them, and when, and share IDs where they overlap.
Ownership and cadence
Each risk needs a named owner with authority to manage the mitigation and to update the probability and impact. A risk whose owner has left the project, or who cannot authorise the mitigation, is being tracked and not managed.
Our rule is to tie cadence to triggers and not to the calendar. Owners review their own lines monthly. The register is brought up to date, and a QSRA or QCRA refresh considered, at each trigger: a baseline or programme change, a major milestone, a gateway or assurance review, or a significant change in scope or cost. A register not updated since the last trigger describes the project as it was. This is SOMA's view of good practice, and a client's governance may set its own intervals.
Putting it together
Structure the register around five conventions: cause-event-consequence statements, decimal probabilities alongside bands, three-point impacts alongside bands, explicit mapping to activities and cost lines, and a clean split between event risk and baseline uncertainty. Add untreated and treated values, correlation, baseline overlap and secondary risks, and the register can be read by a monthly review and used by a model.
On a QSRA or QCRA we test a register against the field list above before any modelling starts, and agree with the client which gaps to close and who owns each.