The Difference Between a Risk and an Issue, and Why It Matters at Programme Close
These two words get used interchangeably throughout most engineering programmes. By the time the programme closes, that habit has cost someone real time and real credibility.
A risk is something that has not happened yet. An issue is something that has already happened. That distinction sounds obvious when stated plainly, and yet almost no engineering programme holds it consistently from kickoff to close. The two words get used as synonyms in meeting rooms, in status reports, and in the registers that are meant to track them separately. By the time a programme reaches close out, that habit has usually cost someone real time. Occasionally it has cost someone their credibility in front of a client or regulator.
The confusion is not really about vocabulary. A risk and an issue require completely different management responses. Treating them the same way in language leads directly to treating them the same way in practice.
What a risk actually requires
A risk is a statement about the future. It has a likelihood, because it has not happened yet, and there remains a live question about whether it will. Managing a risk well means understanding its trajectory. Is the underlying condition getting better, staying the same, or getting worse. What would need to change in the surrounding system for the likelihood to shift. What is the earliest observable signal that would tell you the risk is about to convert into something real.
This is forward looking work. It requires monitoring, not remediation. The correct question for a risk is always some version of this: what would we need to see to know this is about to happen, and what do we do before it does.
What an issue actually requires
An issue is a statement about the present. It has already occurred, which means the likelihood question is closed. The only questions that remain are how bad the consequence is, how quickly it needs to be contained, and what permanent fix prevents recurrence. An issue does not need a trajectory analysis. It needs a remediation plan with an owner and a date.
Treating an issue as though it were still a risk, still something to monitor rather than something to fix, is how issues sit unresolved on programme trackers for months. The entry gets reviewed every week. The status gets updated. Nothing about the underlying condition ever changes, because the management action being applied to it, ongoing monitoring, was never the action it needed.
Where the confusion actually causes damage
The place this distinction matters most is not day to day management. It is at programme close, when someone has to produce a final account of what happened and why. A closing report that lists live issues under a heading called risk register looks, to an external reviewer, like a programme that either does not understand its own exposure or is trying to soften the language around problems that actually occurred. Neither reading helps the person writing the report. Both readings are avoidable.
The same confusion causes a subtler problem earlier in a programme. When an issue is logged as a risk, its likelihood field gets scored using the same instinct used for genuine risks, an estimate of probability. But the issue already happened. Scoring it at anything less than certain is not an assessment. It is a category error, and it distorts whatever prioritisation logic the register uses to decide what gets attention first. A genuine high consequence risk with a real chance of occurring can end up ranked below an issue that has already occurred and is quietly getting worse, simply because the issue was scored as though its probability were still open to question.
The practical fix
None of this requires new tooling or additional process. It requires holding the definitions apart consistently, in language and in the register structure. When something has already happened, it moves to an issue log with a remediation owner and a closure date, not a likelihood score. When something has not yet happened, it stays in the risk register with a trajectory assessment, not a remediation plan.
The habit is easy to build once it is named. Before writing any entry, ask whether the thing being described has already occurred. If it has, the word is issue, and the response is a fix. If it has not, the word is risk, and the response is a trajectory watch. Holding that line consistently across a programme, even under the pressure of a fast moving status meeting, is what makes a closing report defensible rather than something a reviewer has to squint at and reinterpret.