A RAID log holds risks, assumptions, issues and dependencies in one place. The four sit together because each is a statement about something the project does not control, and because any one of them turns into another without giving notice.
Four things in one artefact
A risk is an uncertain event that would affect an objective if it occurred, carrying a probability, an impact, an owner and a planned response.
An assumption is something the plan treats as true without having established it, and it carries no probability because nobody has looked at it hard enough to give it one.
An issue is a problem happening now, carrying an owner, an action and a date by which it has to be resolved.
A dependency is something the project needs from elsewhere, or that elsewhere needs from the project, carrying a direction, a date and a named person at the far end.
They share one artefact because they are stages of the same lifecycle far more often than they are separate categories. Splitting them across four systems is how a project loses sight of an assumption quietly becoming a risk that becomes an issue.
The columns each record needs
Every row of every kind carries an identifier, the date it was raised, who raised it, a single named owner and a status. The columns beyond that differ, because each record type is answering a different question and a row is finished only when somebody can act on it.
| Record | Columns the row carries | What a finished row lets somebody do |
|---|---|---|
| Risk | Description, cause, the objective it threatens, probability, impact, the resulting exposure, response strategy, the response actions, the reserve held against it, review date | Decide now whether the response is worth funding, and know who is watching for the trigger |
| Assumption | The statement, the part of the plan that rests on it, how it will be checked, the date it will be confirmed, what changes if it turns out to be false | Convert it into a fact or a risk by a stated date, rather than discovering it in month seven |
| Issue | Description, date raised, what it is costing right now, the agreed action, target resolution date, escalation route and the trigger for using it | Act this week, and escalate on a date that was agreed before anybody was under pressure |
| Dependency | Description, direction, the other party, a named contact there, date needed, date promised, the last responsible moment, the fallback if it slips | Chase the right person, and know the date at which the project stops waiting and does something else |
A log built to that shape can be read across a table in ten minutes, because every row already carries the decision it is asking for. A log built from a description column and a traffic light cannot, which is why the same statuses stay amber for six months.
A risk has not happened and an issue has
This is the distinction worth being pedantic about, because the two are managed by different mechanisms. A risk is handled through probability, impact, a response strategy and a reserve set aside against it. An issue is handled through an owner, an action, a resolution date and an escalation when that date passes.
Mislabelling costs money in both directions. Calling a live problem a risk leaves it in a register reviewed once a month when it needed a decision today. Calling an uncertainty an issue spends escalation and attention on something that may never occur, and turns the register into a list of worries.
The transition deserves saying out loud in the review. A risk that has materialised should be closed on the register with a note that it occurred and opened as an issue, so the record shows a project that saw it coming rather than a risk that mysteriously vanished.
Assumptions are the quiet ones
Every plan rests on assumptions and most of them are reasonable. The dangerous property of an assumption is not that it might be wrong, but that nobody has decided who would find out, or when.
An assumption with an owner and a date by which it will be confirmed is a manageable thing. An assumption sitting in the log with nothing attached is a risk with no probability, no impact and no response, which is a risk the project has agreed not to look at. The costly ones are almost always about other people. The regulator will approve inside six weeks, the data will arrive in the format the sample suggested, the supplier will have an environment ready in March. Each is testable this week and each is ruinous to discover in month seven.
Dependencies, internal and external
An internal dependency runs between parts of the same project, which makes it a scheduling problem the project manager can solve directly by resequencing, moving people or negotiating with the team involved.
An external dependency sits outside the project's authority, such as a supplier's delivery date, another project's release, a regulatory decision or a shared platform team's queue. The project manager cannot resolve any of those, which is precisely why each one needs an owner outside the project who can. A dependency logged without that name is a wish.
Each external dependency also needs a date at which the project stops waiting and does something else. The failure mode is learning about a slip too late to have a second option, which is a different problem from the slip itself and a far more expensive one.
A complete log nobody reads is not a control
The usual failure is a log that is complete rather than one that is thin. Two hundred rows sit open, almost none of them closed, produced monthly because governance asks for it, and completeness has been achieved where control has not.
A usable log is short enough to be read inside a meeting, ordered so that whatever needs a decision is at the top, and actively pruned. Closing rows is part of the discipline. A risk that can no longer occur, an assumption now confirmed and a dependency already delivered all come out, and taking them out is what keeps the rest readable.
The honest test is whether anything on the log changed what the project did this month. If nothing did, it is a record rather than a control, and the effort spent maintaining it bought a document instead of a decision.