Project risk assessment

Project risk assessment is the practice of identifying the events that could threaten a project and scoring each one by how likely it is to happen and how much it would cost if it did. Each risk gets a probability and an impact rating, and the two are multiplied to give a risk exposure score. A risk that is almost certain but trivial scores low. A risk that is unlikely but catastrophic scores high. The assessment ranks every open risk so the team works the ones that matter.

The reason to quantify risk rather than just list it is prioritisation. Every project has more risks than the team can actively manage. Without a score, attention drifts to whatever was raised most recently or shouted loudest. With a score, the register sorts itself, and the highest-exposure risks rise to the top where they belong.

A risk assessment is not a one-off document produced at kickoff and filed away. Probabilities and impacts change as the project moves. A dependency that was low risk in planning becomes high risk when the supplier slips. The assessment is a live measure that should be reviewed every cycle, because a stale risk register is worse than none, since it offers false comfort.

A project risk assessment produces a risk exposure score for each risk, and a total exposure for the project. The core calculation is probability multiplied by impact. The inputs below are the elements that go into a defensible, comparable assessment.

1. 1

   Probability

   The likelihood the risk occurs, scored on a consistent scale. Many teams use 1 to 5, where 1 is rare and 5 is almost certain. Others use a percentage from 0 to 1. The key is that the same scale and definitions apply to every risk so the scores stay comparable.

2. 2

   Impact

   The damage if the risk occurs, expressed in cost, schedule delay or quality terms. A delay of one day is a different impact from a delay of one month. Where possible, anchor impact to concrete figures such as pounds at risk or days of slippage rather than a vague high, medium, low.

3. 3

   Risk exposure

   Probability multiplied by impact, giving a single severity number per risk. A risk with probability 4 and impact 5 has an exposure of 20, ranking above one with probability 2 and impact 3, which scores 6. Exposure is the number you sort the register by.

4. 4

   Total project exposure

   The sum of exposure across all open risks, optionally adjusted for risks that overlap or compound. This rolls the register up into one figure that lets you compare the overall risk position of one project against another, or track a single project over time.

5. 5

   Mitigation effect

   The reduction in exposure expected from a planned response. Subtracting the mitigated exposure from the raw exposure shows whether the response actually moves the number, which is the test of whether mitigation work is worth doing.

Worked example. A supplier delay risk is scored probability 3 and impact 5, giving an exposure of 15. A minor tooling risk is scored probability 4 and impact 1, giving an exposure of 4. Despite being more likely, the tooling risk ranks well below the supplier delay, which is exactly the prioritisation the score exists to provide. The team works the 15 before it touches the 4.

A metric tree decomposes total project risk exposure into risk categories, and each category into the specific risks and the inputs that drive their exposure. This turns a flat register into a structured map of where risk concentrates. When total exposure rises, the tree tells you whether the increase came from technical risk, supplier risk, scope risk or resource risk, and which named risk inside that category moved.

The first level splits exposure by category. Technical risk decomposes into dependency complexity and unproven technology. Schedule and resource risk decomposes into key-person dependency and capacity gaps. External risk decomposes into supplier reliability and regulatory change. Each leaf is a real risk with an owner, a probability and an impact you can act on.

The gap between a register and a decision is ownership and timing. A risk log lists threats but rarely says who is accountable or when exposure crossed a line. A metric tree puts RACI ownership on every risk, so the person accountable for the supplier relationship owns the supplier risk branch, and pushes the signal to them when their category exposure rises, rather than waiting for the next risk review meeting to surface it.

There is no industry benchmark for total exposure because scales differ by organisation. What is benchmarkable is how you classify a single risk by its probability and impact rating, and what response each band demands. The bands below assume a 1 to 5 scale on both axes, giving an exposure range of 1 to 25.

Track total exposure over time as a trend, not just at a point. A project whose exposure is climbing each week is accumulating risk faster than the team is retiring it, regardless of the absolute level. A falling total exposure shows that mitigation is outpacing new threats, which is the healthiest signal a risk assessment can give.

Improving a risk assessment means two things: reducing real exposure through mitigation, and making the assessment itself more accurate so it ranks threats correctly. A precise register pointed at the wrong risks is as dangerous as no register at all.

The metric tree approach to risk starts by ranking categories by total exposure, then drilling into the category carrying the most, and acting on the named risks inside it. If external risk holds the majority of exposure, the supplier and dependency branches are where the effort belongs.

KPI Tree lets you connect each risk category to the person accountable for it and the action that reduces it. The technical lead owns dependency and integration risk. The resourcing manager owns key-person and capacity risk. The commercial owner owns supplier and regulatory risk. With RACI ownership on every branch and a push to the accountable owner when category exposure crosses a threshold, a risk assessment stops being a document reviewed monthly and becomes a signal acted on in time. A verified impact loop then checks whether each mitigation actually moved the exposure it was meant to, so effort goes where it works.

1. 1

   Treating it as a kickoff exercise

   A risk assessment done once at the start and never revisited is stale within weeks. Risks change as the project moves. Reassess on a regular cadence, or the register becomes a source of false comfort rather than a live measure.

2. 2

   Using inconsistent scales

   When different people interpret a probability of 4 or an impact of 5 differently, the exposure scores are not comparable and the ranking is meaningless. Define the scales precisely and apply them the same way to every risk.

3. 3

   Confusing risks with issues

   A risk is something that might happen. An issue is something that already has. Mixing the two clutters the assessment and inflates exposure with problems that are no longer probabilistic. Track active issues separately from open risks.

4. 4

   Logging risks without owners

   A risk with no named owner is a risk no one is managing. Every entry on the register needs a person accountable for monitoring it and acting on its mitigation, or the assessment becomes a list of worries rather than a plan of action.