When a project goes sideways, one sentence always comes back: "we had a risk on that". Nine times out of ten it was not a risk. It was an unknown nobody could have anticipated, a problem already sitting there that nobody wanted to look at, or a worry nobody had ever taken the time to name.
As long as those words stay mixed together, you are not steering anything. You are reacting. You are putting out fires.
The good news is that a risk can be managed. Provided you know what you are looking at.
A risk is not an unknown
An unknown is an event you could neither identify nor anticipate. By definition it cannot be managed: there is nothing to do in advance.
A risk is the opposite.
A risk is an identifiable, uncertain and measurable event which, if it occurs, will have a measurable effect on the objectives of the project.
Confusing the two blocks everything, because you do not handle something you suffer the same way you handle something you can see coming.
The three questions that settle it
To know whether what you have in front of you is a risk, three questions are enough.
- Is the event identifiable? You can say which one it is.
- Is it uncertain? You do not know whether it will happen.
- Is its effect measurable? You can put a number on it.
One no and it is not a risk. The test looks simplistic, and it removes most of what clutters a risk register.
The five false synonyms
Five words get used in place of "risk". None of them is one, and each fails the test at a different point.
- The unknown: an event that is neither identifiable nor measurable. You cannot prepare for it, only react to it.
- The hazard: an identifiable event whose probability and impact you cannot estimate. The measure is missing.
- The problem: an event that has already happened and whose effect is now observed. There is no uncertainty left, only a reality to deal with.
- The forecast: a probable event you expect, without knowing its precise effect on the project.
- The worry: a feared effect with no named event behind it. It is the most common of the five, and the hardest to handle, because there is nothing to take hold of.
Each of these describes something real. None of them can be managed with the tools of risk.
The two real synonyms: threat and opportunity
A risk is not necessarily bad news. The definition says nothing about the sign of the effect, only that it is measurable.
- A threat: a risk whose occurrence would have a negative effect on the objectives of the project.
- An opportunity: a risk whose occurrence would have a positive effect.
That symmetry changes how a workshop runs. Looking only for what can go wrong produces an anxious list nobody reads twice. Looking for both produces a list of decisions.
Wording a risk you can act on
Once the event is spotted, the wording matters as much as the identification. A three-part structure removes every ambiguity:
Since… (the cause) → it could happen that… (the event) → which would affect… (the effect)
An example: "Since the supplier has not confirmed their availability in August, it could happen that acceptance testing starts two weeks late, which would push the go-live back by the same amount."
Compare that with what registers usually hold: "supplier risk". The first one can be worked on, the second one can only be looked at. A risk written the long way shows, in the wording itself, the three places where you can act to reduce it: the cause, the event, the effect.
What poker taught me about risk
At the poker table it took me a while to understand one thing: good players do not bet at random. They do not "try their luck". They evaluate. A hand, a probability, a stake, then a calculated risk.
The day I stopped playing on instinct and started identifying, analysing and measuring, everything changed.
Project management works exactly the same way. For a long time, like most people, I used risk, unknown, hazard, problem and worry as if they meant the same thing. That mixture brought me nothing but a vague fear, and fear stops you steering anything.
Anticipating a risk is not pessimism. You do not anticipate it to scare yourself. You anticipate it to stop being scared.
Why it changes something on a project
A risk that is properly worded can be measured. Criticality is a simple product:
criticality = probability × impact
Two numbers, and a list becomes an order of priority. That is what lets you decide where to put the effort, instead of treating twenty register lines with the same energy, which amounts to treating none of them.
The stakes are not theoretical. Among projects that fail, the PMI reports inadequate requirements gathering in 35% of cases, an inadequate vision or goal in 29%, and inadequate planning in 25%. Source: PMI, Pulse of the Profession 2018, 4,455 practitioners, see the PMI standards.
Those three causes have one thing in common: every one of them is identifiable before kick-off. They are risks, not unknowns. Bringing them up while you can still act on them is exactly the job of scoping the project.
The measurement is also what connects a risk to the schedule. A risk carried by a task that sits on the critical path does not cost the same as the same risk somewhere with float, and a delay that spreads does so through dependencies nobody declared.
In short
A risk is an identifiable, uncertain and measurable event whose effect on the objectives of the project can be quantified. If the effect is negative it is a threat. If it is positive it is an opportunity.
Everything else has another name and is handled another way. The sorting takes three questions, and the wording takes one structure: cause, event, effect.
Identifying risks is a team exercise, and it works better when everyone knows who answers for what, which is what a RACI matrix settles. The events themselves usually come out of the work itself, so a work breakdown structure is the natural place to go looking for them.
