How is project risk measured?

Ask two builders to describe the same project and the answers often differ completely — one sees a clean, profitable job, the other a minefield of delays and overruns. They are not looking at different buildings. They are carrying different mental models of risk. Risk analysis exists to make that model explicit, shared and numeric, so a team can argue about the right things and decide with its eyes open.

Risk is a probability and a consequence, taken together

The most useful idea in the field is also the simplest. Stripped of jargon, risk is two things multiplied together.

How likely something is, times how much it costs if it happens. Both halves matter. A near-certain nuisance — minor finish defects on every floor — can multiply out to the same number as a one-in-a-thousand catastrophe. Looking at only one half is how teams either panic over trivia or sleepwalk into disaster.

The field has worked from the same formal definition since 1981, when Kaplan and Garrick set risk out as the answer to three questions taken together: what can go wrong, how likely it is, and what the consequences would be. The equation above is that definition in its most compact form. Treating risk as a number rather than an impression is what makes it comparable, rankable and budgetable: “the façade worries me” becomes “the façade is the largest exposure, here is the figure, here is the response.”

The four things every project balances

Managing risk requires knowing what is at stake. On a building project, almost everything reduces to four objectives competing for the same finite resources.

• Safety — people first: injuries, code compliance, liability.
• Quality — does the finished building perform as designed?
• Schedule — every week of delay carries a real, often contractual, price.
• Budget — cost certainty, contingency, and protected margin.

A risk is anything that threatens one of these four. Because the four pull against each other, most decisions on a job are not problems to be solved but trade-offs to be priced. Accelerating the schedule usually costs money or accepts quality risk. Cutting cost often borrows against safety or durability. Naming the four objectives turns vague worry into a checklist that can actually be worked.

The first question: what can go wrong?

The first tool in the kit is not software. It is a list. The risk register is the structured answer to “what can go wrong?” Every credible threat gets a row, scored by likelihood and impact, so attention flows to the rows that matter rather than the rows that happen to be loudest in the room.

A good register is a living document, revisited at every phase. Its value is not the table but the conversation the table forces. Threats nobody owned suddenly have an owner; risks everyone assumed someone else was watching get watched.

Expressing likelihood as a number

Scoring that register honestly means expressing likelihood as a number between 0 and 1 — 0 impossible, 1 certain, 0.5 a coin flip. It feels unnatural at first, but it is what allows risks to be combined and fed into the tools that follow.

Probabilities come from two places. From data: historical frequencies, such as past delay records, defect rates and material test results. From judgment: calibrated expert estimates, used where no dataset exists. A first-of-its-kind façade detail or a novel ground condition has no history; that is not an excuse to skip the number, it is the case for structured expert elicitation. Either way the estimates obey the same rules of probability — they have to add up.

Comparing options: expected value

Once outcomes carry probabilities, options can be compared using expected monetary value — each outcome weighted by its probability. The decision is laid out as a tree and folded back from right to left, keeping the branch with the best expected payoff.

Which inputs actually move the result

Not all risks deserve equal effort. Sensitivity analysis ranks the inputs by how much each one swings the final result, most familiarly as a tornado diagram with the widest bars on top. On a typical project those tend to be ground and foundation conditions, long-lead procurement and labour productivity, while permit timing or a minor material price barely register.

The lesson is where to spend the analysis budget: model the big bars carefully and leave the small ones alone. It is a discipline against the very human habit of polishing the assumptions that are interesting rather than the ones that matter.

Contingency comes from simulation, not from a percentage

A single-number budget is a fiction; real projects live in a range. Monte Carlo simulation takes that seriously. Instead of one estimate, each uncertain input is given a distribution and the whole project is run thousands of times, drawing different values each pass. The output is not a number but a curve of possible outcomes.

That curve is where defensible contingency comes from. The P50 is the coin-flip cost; the P80 is the cost the project will come in under eight times out of ten. Setting contingency at P80 is not padding — it is a figure that can be defended to a lender or a board, with the arithmetic behind it. This is what schedule-and-cost risk tools do under the hood.

The hazards outside the project’s control

Construction risk ends at handover. Hazard risk runs for the life of the building: fire, earthquake, wind, flood — low-probability, high-consequence events that combine by the rules of probability. For two independent hazards:

Taking an illustrative annual fire probability of 0.005 and earthquake probability of 0.05, the chance of structural damage from either in a given year is about 0.0547 — not simply the two added together, because the slim chance of both is not double-counted. Scaled across a 50-year service life, the difference stops being academic.

Quantifying these hazards is what underpins design codes, drives insurance pricing and justifies how much a client should invest in resilience. It is the same relationship as at the start — probability times consequence — applied to events measured in decades rather than months.

Where this shows up on a project

None of this is academic. The same toolkit appears across the life of a real project: sizing contingency that can be defended; making go / no-go and competitive bid decisions; prioritising safety and QA spend where exposure is greatest; structuring insurance and risk transfer; and giving investors and lenders the confidence that the team understands its own downside. Risk analysis does not make uncertainty disappear. It makes uncertainty legible — and a legible risk can be priced, shared and managed.

Formal definition of risk after Kaplan and Garrick, “On the Quantitative Definition of Risk”, Risk Analysis, 1981. Adapted from a graduate risk-analysis course in civil engineering and construction management. Figures throughout — dollar values, probabilities and confidence levels — are illustrative teaching examples, not data from any specific project.