From Risk Register to Quantified Model

The first attempt usually fails in a specific and instructive way. Someone exports the register, opens the modelling tool, and finds that a large share of the entries cannot be attached to anything. “Stakeholder resistance.” “Insufficient resources.” “Scope creep.” Each is a real concern and none of them is a quantity.

Why will most registers not simulate?

Because a register is written to be reviewed and a model is written to be computed, and those are different jobs.

A model needs three things for each item: a quantity, an attachment point, and a shape. What is the impact in days or dollars, which activity or cost item does it land on, and what is the range or the probability. A typical register entry supplies a description, a likelihood word, an impact word and an owner. None of those four is an input.

This is where the work becomes valuable rather than annoying. Forcing an entry to name its attachment point reveals that nobody had thought about where the consequence would actually land. Forcing a quantity surfaces disagreement that the shared vocabulary had been concealing, which is the argument in Why 'Likely' Is Not a Probability.

What are the two kinds of uncertainty?

Inherent uncertainty

Variability present whatever else happens. Productivity will not exactly match the assumption, quantities move as design matures, a thirty-day activity is genuinely a twenty-five to forty-five day activity. This is modelled by ranging the estimate or the durations, and on a well-run project it is usually the larger contributor.

It is also usually absent from the register, because a register is a list of things that might go wrong and ordinary variability does not feel like a risk. Ward and Chapman made exactly this argument in proposing that project risk management be reframed as uncertainty management: an event-based framing overlooks variability and ambiguity, which are not events and so never get logged.

Discrete risk events

Things that either happen or do not. The permit is refused. The long-lead item slips. These carry a probability and an impact and attach to specific activities or items. This is the category a register is actually built for, and the modelling approach, including the risk driver method where one risk can affect several activities at once, is set out in AACE Recommended Practice 57R-09 and in Hulett's treatment of integrated cost and schedule risk.

Where does double counting come from?

From modelling the same uncertainty twice under two names, and it is the most common reason these models overstate contingency.

The classic version: an activity is given a duration range wide enough to accommodate a possible supplier delay, and a discrete risk event for that same delay is also attached to the same activity. Both are defensible individually. Together they charge the project twice. The subtler version is a base estimate that already contains buried contingency with modelled uncertainty layered on top, which is precisely why FTA requires a stripped and adjusted base before its model runs.

I should be straight about the evidence. This failure mode is well known to practitioners and I could find no peer-reviewed study addressing it. The guidance lives in the AACE recommended practices and in Hulett's book rather than in the journal literature, so treat it as experienced practice rather than a published finding.

Why does correlation matter more than people think?

Because independence is the default assumption in most tools and it is almost always wrong.

Cost and schedule elements on a real project move together. The same labour market drives several trades. The same design immaturity affects several packages. The same weather season affects everything outdoors. A model that samples them independently produces a distribution that is too narrow, because offsetting highs and lows cancel in a way reality does not permit. Too narrow means the tail is understated, and the tail is where contingency comes from.

Wall analysed cost data from 216 office buildings and found that omitting correlation distorts risk results more than the choice of input distribution does, which is striking given how much practitioner argument is spent on distribution shape. Touran and Wiser had earlier set out a technique for Monte Carlo simulation with correlated random variables, and Touran and Lerdwuthirong followed with rank correlations in construction cost simulation.

The practical implication is unglamorous. An hour spent agreeing which cost groups move together is worth more than an afternoon arguing about triangular versus PERT.

Why is this an Adaptability problem?

Because the translation forces the organization to say things it has been comfortable not saying, and that is a learning capability rather than an analytical one.

Quantifying a register converts vague collective anxiety into specific, attributable numbers. “Stakeholder resistance” becomes an estimate of how many weeks a particular approval could slip and who believes it. That is more useful and more uncomfortable. Organizations that cannot hold the discomfort resolve it by keeping the register qualitative, which preserves the appearance of risk management while removing anything that could be tested against outcomes.

The tell is a quantification exercise that stalls at the estimating step and is never restarted. The obstacle is rarely the mathematics. It is that someone would have to put a number next to a colleague's work, and nothing in the organization has made that a normal thing to do.

Evidence matrix

What to do with this

Take the top ten entries in your register and try to write, for each, the activity or cost item it lands on and the impact in days or dollars. The ones you cannot complete are not badly written risks. They are places where the organization has not yet decided what it believes, and that list is more valuable than the model you were trying to build.