Risk is not a problem: the distinction that changes your meetings

Open any project’s risk register at random — yours, a client’s, a major owner’s. You will almost always find lines like these:

“Steel delivery delay.”

“Engineering resource shortage.”

“Package 3 cost overrun.”

None of those is a risk. They are problems — things that have already happened or are happening now. And that confusion, trivial as it looks, quietly distorts the whole management of the project: prioritisation, meetings, the numbers shown to the steering committee, and even how the team pictures its own future.

The distinction in one sentence

A problem is certain: it is here, it has a known or estimable cost, and it demands correction. A risk is potential: it might occur, with an estimable probability and impact, and it demands preparation.

This is not a vocabulary nicety. The two objects call for different management actions, different budgets, and different people around the table. A problem belongs to whoever must fix it now. A risk belongs to whoever can decide to act before it materialises — almost never the same person, and never the same horizon.

ISO 31000 defines risk as “the effect of uncertainty on objectives”. Hold on to the word uncertainty: it is precisely what disappears when a risk becomes a problem. A certain event no longer has an uncertain effect — it has an effect, full stop. It leaves risk management and enters issue management.

The probability test

The test is one question: does the statement still carry a probability below 100%?

“Steel is three weeks late.” Probability: 100%. It happened. That is a problem, and it deserves a recovery plan, a date and an owner — but not a place in the risk register.

“The steel supplier is showing signs of financial distress, which could delay Q4 deliveries and push out commissioning.” That is a risk. Note the structure: an observable cause (the signs of distress), an uncertain event (the delayed deliveries), a consequence for the project’s objectives (commissioning).

That structure — cause → uncertain event → consequence — is the best diagnostic tool I know. A statement that refuses to fit it is either a problem in disguise or a worry too vague to manage. Either way, it cannot stay as written.

Four statements, reworked

Here is what the opening lines become once the test is applied.

“Steel delivery delay”

A problem if the steel is already late → issue register, with a recovery plan. A risk if the delay is anticipated: “Port congestion observed since March could delay Q4 steel deliveries and push back structural erection.”

“Engineering resource shortage”

Almost always an observed problem. The associated risk reads: “The announced departure of two senior engineers could leave structural design without key expertise at the 60% review, delaying issue-for-construction.”

“Package 3 cost overrun”

If the overrun is booked: an issue, with variance analysis. If anticipated: “The productivity gap observed over the last four weeks, if sustained, could carry package 3 beyond its envelope before excavation completes.”

“Weather risk”

Neither — that is a category, not a statement. It has to be made specific: “An early frost before mid-November would prevent the foundation pour and push the work to spring.” Only then can it be assessed and treated.

What the confusion actually costs

Four effects, from the most visible to the most insidious.

• You manage the past instead of the future. A “risk” meeting full of problems is a catch-up meeting. It is useful — problems must be managed — but it consumes the one slot where the team looks forward. Nobody notices, because the meeting feels productive: it deals with real, urgent things.
• Real risks die quietly. Problems are loud by nature: somebody is waiting on an answer, an invoice, a decision. The risk that will hit in three months does not shout. It waits patiently for someone to give it twenty minutes — and in a meeting dominated by the present, those twenty minutes never arrive.
• Your numbers become unusable. A register where half the entries are problems overstates future exposure — impacts already absorbed get added to potential ones — and understates the current corrective load, since it is buried in the register instead of tracked as itself. The two numbers leadership uses to decide are wrong simultaneously, in opposite directions.
• Responses are mis-calibrated. A problem calls for corrective action: a date, an owner, a cost. A risk calls for a different vocabulary — avoid, mitigate, transfer, accept — and often a contingency plan with a trigger threshold. Confusing the two produces hybrid “plans” that do neither job properly: too late to prevent, too vague to correct.

Where problems go: the issue register

Removing a problem from the risk register does not mean abandoning it. It changes address. Most methodologies — PRINCE2 is explicit, the PMBOK implies it — provide for a separate issue register: what happened, what we are doing, who leads, by when.

That separation has an underrated benefit: it makes the materialisation rate visible. When a risk becomes an issue, it should be closed on the risk side and opened on the issue side, with a link between them. After a few months you can answer a question almost no organisation can handle: of the risks we identified, how many occurred — and of the issues we are living with, how many did we see coming? The second number is a direct measure of how good your identification is.

The fix: twenty minutes, three questions

At your next register review, test every line.

• Has it already happened? If so, move it to issue tracking with a corrective action and a date. Do not delete it — link it, so the materialisation is on record.
• Can you write cause → uncertain event → consequence? If the statement will not fit, it is too vague to assess and therefore to prioritise. Rewrite it with its owner — the exercise takes three minutes and often surfaces the real disagreement.
• Is there still a probability below 100%? That is the only thing that justifies its place in the risk register.

In the registers I review, this exercise reclassifies about a quarter of the entries. The effect is immediate and slightly unsettling: the register shrinks, and the meeting starts talking about the future again. Early on, some people read that as a loss — we used to have “more risks”. The opposite is true: you mostly had more noise.

Going further

Next week we look at what happens to a register nobody maintains — the seven signs of a dead register, and how to measure them rather than lament them.

If you want the test applied to your own register, write to me: I will review a dozen statements and send back the sorting, with rewrites. It is an hour’s exercise that often changes the next conversation with your committee.

References: ISO 31000:2018, Risk management — Guidelines · PRINCE2, risk and issue management · PMI, Standard for Risk Management in Portfolios, Programs, and Projects.