Two risks, one colour
At the steering committee meeting for a municipal IT migration, the project manager points to a risk matrix on the screen: twelve risks, spread across green, amber and red. Risk A — a supplier delivering the critical integration module late — is amber. Risk B — a test environment that occasionally runs slow — is also amber. No one in the room asks why.
That's the problem. Risk A has maybe a ten percent chance of occurring, but the impact is large: weeks of delay and a penalty clause. Risk B happens more often, perhaps in forty percent of sprints, but costs a few hours of disruption each time. Two very different risks, the same colour, the same place on the action list. Anyone prioritising by the matrix spends as much attention on a penalty clause as on a slow test server.
Why the colour doesn't show that
This isn't an exception — it's a structural feature of the risk matrix as a tool. Cox (2008) describes its formal weaknesses: a matrix squeezes two continuous quantities — probability and impact — into a small number of cells. Combinations that are intuitively not equal end up in the same cell, and the ranking you read from the colours doesn't necessarily match the actual urgency. The matrix looks precise — a grid of numbers and colours — but the precision sits mostly in the form, not in the content.
That's not a reason to throw the matrix out. It is a reason not to read it as a final verdict.
Risk is more than probability times impact
There's another assumption under the matrix worth questioning. ISO 31000 defines risk not as probability times impact, but as "the effect of uncertainty on objectives". That's a broader concept: it also covers dependencies, timing and ambiguity — things that don't fit neatly into a single probability figure and a single impact figure. Take a dependency on an external party that only becomes visible once a sub-project has already been completed: by then, correcting course costs more than it would have three months earlier, even if the matrix score never changed. The matrix doesn't see that difference; the conversation about it does.
The matrix as a starting point, not a verdict
The practical conclusion isn't "stop using a matrix" but "use it differently". Start with a fixed breakdown of risk sources — a risk breakdown structure as described by Hillson (2002) — as a prompt list, so you map the full field of possible risks before you start scoring. Apply the matrix afterwards, not to decide, but to flag where two risks happen to land in the same cell. That signal should trigger a question, not an automatic ranking: what assumption about probability, what assumption about impact, what time pressure sits behind this?
That slows the steering committee meeting down, at least for the risks that deserve the attention. But it stops a penalty clause and a slow test server getting equal action just because they happen to share a colour.
Next time two risks land in the same cell of the matrix: ask what assumption is behind it, before you prioritise any further.