A RAID log holds risks, assumptions, issues and dependencies in one place. It is the working register of everything a project does not control, and PMI's issue log and assumption log are the pieces of it the examination names. The four sit together because each is a statement about something outside the project's control, and because any one of them turns into another without giving notice.
The sections below define the four records, set out the columns each one needs, draw the line between a risk and an issue, explain why assumptions are the dangerous ones, separate internal from external dependencies and end with what keeps the log usable.
The four records
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, and a plan that treated the regulator's approval as an assumption in January is holding it as a risk by March and as an issue by June. 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, before it is discovered 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.
How a risk differs from an issue
Of the four records, the boundary between risk and issue is the one worth being pedantic about, because the two are managed by different mechanisms. A risk has not happened and an issue has. 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 is 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, with no risk mysteriously vanishing.
Assumptions and who checks them
Every plan rests on assumptions. Most of them are reasonable. The dangerous property of an assumption is that nobody has decided who would find out whether it is wrong, 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
Most of those assumptions are about dependencies, and dependencies are of two kinds. 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.
Keeping the log usable
The usual failure is a log that is complete. Completeness has been achieved where control has not. Two hundred rows sit open, almost none of them closed, produced monthly because governance asks for it, and nobody opens the document between reviews.
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. The effort spent maintaining it bought a document where a decision was wanted.