The RAID log, minus the theatre

The RAID log is project management's most defensible artifact on paper and its most reliably dead one in practice. The instinct behind it is exactly right. The ritual around it is what kills it, and the two deserve to be separated before you either adopt one or delete one.

The instinct is correct

Risks, assumptions, issues, dependencies. Look back at any delivery that surprised you and the surprise came from one of those four: a risk nobody raised, an assumption everyone inherited as fact, an issue that aged quietly, a dependency that was logged but never confirmed. Whoever first grouped those four categories was describing the actual anatomy of delivery failure. That part survives every criticism below.

The ritual is where it dies

The standard implementation: a standalone spreadsheet or register, one per project, filled in enthusiastically at kickoff, reviewed in a monthly governance meeting, read by no one in between. Three structural failures follow from that shape, and none of them is fixable with better discipline.

It cannot distinguish "assessed, nothing found" from "nobody looked". An empty risks section is either the best news on the project or its biggest gap, and the log renders both identically — so people invent entries to look diligent, and the register becomes fiction with formatting. Invented entries are worse than blanks: they consume the scarcest resource in governance, which is review attention.

It is filed under the ceremony, not the work. The person about to commit to a demand six months later will read the demand. They will not open a register named after a project and dated last spring. A record's value is proximity to the moment of its next use, and a standalone log has none.

Its assumptions never meet their facts. An assumption in a RAID log sits in its own tab, disconnected from the request it belongs to — so when the request is estimated, the assumption gets inherited as a fact anyway, in a different document, by someone who never saw the log.

What to keep, and where to put it

Keep all four categories. Change their address and their grammar:

• Attach them to the demand, not to a document. Each demand carries its own risks, assumptions, dependencies and decisions — read exactly when someone is about to commit to it or is delivering it, which is the only moment the entries can change anything.
• Make "assessed, nothing found" a first-class answer, distinct from "not assessed". Three states per category, not two — an honest blank stops being indistinguishable from a skipped step, and the invented entries stop.
• Treat dependencies as requests, not rows. Who it is needed from, what specifically, by when, and whether they have actually agreed — "asked but not confirmed" visible as its own state.
• Give issues an owner and an exit. An issue that cannot name what decision or help it needs is a mood, and a log full of moods is why nobody reads it.

What a log cannot hold, whatever you add to it

Two things the format cannot carry. Accountability: a register records that a risk was written, not that anyone accepted it — which is why the risky commitment needs its own recorded act, an exception naming who accepts and what would change the decision. And consequence: a RAID entry has no way to stop anything. A demand with an unresolved blocking dependency should read as not-ready at commitment time — a log can only hope somebody cross-references it in the meeting.

The honest migration

If you run a RAID log today: keep running it until each category has a home on the work itself, then stop. In DeliverySheet the quartet maps onto the demand's Plan — dependencies and risks directly, each with the three-state model; assumptions split out during shaping; and an issue entering as what it operationally is once it has an owner and an exit, a decision needing to be made — and the commitment bar reads them, which is the part no standalone register can do. The log was never the point. The looking was, and the looking only happens where the work is.