Risk Probability and Impact Assessment

Risk technique · See it on the map

Runnable here

Rating each risk's likelihood and effect on agreed scales so risks can be fairly compared.

When to use it

For every risk entering the register, as a standard step right after it's identified — you need probability and impact figures before you can compute exposure or decide what deserves a response plan.

When to avoid it

Don't build an elaborate 5x5 probability-impact matrix for a project where three people already agree, informally and correctly, on what matters most. The matrix earns its keep on a project big enough, or political enough, that 'high' and 'low' mean different things to different people until you write the scale down.

Steps

1. Before scoring any risk, define what each probability band means in concrete terms — 'low' might be 'has not happened on the last three similar projects,' not just a number between 0 and 1.
2. Define each impact level the same way, in terms your organization can actually judge: schedule days, cost, or a scope/quality description — not just 'severe' or 'minor.'
3. Score each risk's probability against the defined bands, not against your impression of the risk overall.
4. Score impact the same way, independently of the probability score.
5. Record both numbers on the risk (Driftless stores probability as 0-1 and impact as a number; exposure is derived automatically as their product).
6. Revisit scores when new information arrives — a probability assessed at project start is a snapshot, not a fact.

What it produces

• A probability and an impact value on every scored risk.
• A derived exposure figure per risk, usable to rank and compare.
• Written scale definitions the next risk gets scored against consistently.

Common pitfalls

• Multiplying two ordinal ratings (a 1-5 'how likely' and a 1-5 'how bad') and presenting the product as if it were a real number. Ordinal scales aren't arithmetic — a 4 isn't twice a 2 — so a computed '16' out of a 5x5 grid looks precise and isn't; it only orders risks correctly if the scale steps happen to be roughly even, which nobody checks.
• Skipping the step of writing down what each band means, so two people scoring the same risk land on different numbers and neither is wrong by the (nonexistent) definition.
• Letting probability scores creep toward whatever makes exposure look acceptable, especially near a status report deadline.
• Treating impact as cost alone when a risk's real consequence is schedule slip, reputational damage, or scope compromise that doesn't fit a dollar figure.

Worked example

A hospital records-migration project defines probability bands up front: low = 'no precedent in our last four migrations,' medium = 'happened once,' high = 'happened on more than one.' Two different leads independently score the risk 'legacy export tool corrupts date fields' as medium probability because it happened once, on a similar system, eighteen months ago — because the band was written down, they agree without a meeting.

Source

• PMBOK-6 §11.3.2.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.