Keeping risks, issues and assumptions apart
The categories look like filing. They are not — putting something in the wrong one changes how the whole organisation treats it.
The four, and why they differ
Risk — might happen. Has a probability and an impact, and gets mitigated.
Assumption — believed true and not verified. Becomes an issue the moment it is wrong.
Issue — has happened. Needs a response now, not a mitigation.
Dependency — outside your control and needed by the plan. Managed through relationships and early warning rather than through action.
The mis-filing that matters
Logging issues as risks is the common failure, and it is comfortable: a risk has a mitigation and a future tense, an issue demands a response today.
The effect is that a project reports a manageable risk register while several things have already gone wrong. If every open item on a live project is a risk and none is an issue, that is worth looking at directly — it is usually a reporting culture rather than an unusually lucky project.
Assumptions are the quiet ones
An assumption sits in the log looking harmless for months and then becomes the reason the project is late. They do not get managed; they get verified.
The useful question at every review is which assumption could now be checked cheaply. Most can, and most never are, because nothing in the log format prompts anyone to try.
A date is what makes something close
Open items with no date accumulate. An issue without one is not being worked on, it is being carried, and the log slowly becomes a document everyone has stopped reading.
Unowned means unmanaged
The strongest predictor of an item being ignored is having no name against it. "The team" owns nothing. It will be discussed at every review and acted on at none.
Risk and issue differ by tense, not by severity
A risk might happen; an issue already has. That is the whole distinction, and it is not a measure of how bad something is — a catastrophic risk is still a risk, and a trivial issue is still an issue.
Getting this wrong in the reassuring direction is the classic abuse of a RAID log. Something goes wrong, and it is written up as a risk with a mitigation plan, which reads as under control and forecasts a future that has already stopped being available. The tell is the mitigation: if it describes preventing the thing, and the thing has happened, the entry is in the wrong column. Issues get resolution plans and owners; risks get probability, impact and a response.
How a log dies
RAID logs fail in one particular way: they accumulate. Entries are added as they arise and almost none are ever closed, because closing something requires a judgement and leaving it open requires nothing. Within a few months the log is forty rows, most of them stale, and people stop reading it — at which point it has become a record that the project is being managed rather than an instrument for managing it.
The habit that prevents it is reviewing for closure rather than for addition. Every item wants a date by which it either happens or stops being credible, and passing that date without either is itself the finding. A log that shrinks in a quiet month is working correctly.