Projects
The RAID log: the project board's memory
Six months into any real project, someone asks: "why on earth did we agree to do it that way?" If the answer lives in a long-departed contractor's inbox, the project has no memory - and a project with no memory relitigates its own past at every board meeting. The RAID log exists to be that memory: one place holding what might hurt us (Risks), what we said we would do (Actions), what is hurting us now (Issues) and what we decided, when, and why (Decisions).
Most RAID templates get the acronym right and the design wrong. They offer one flat sheet with a Type column - risk or action or issue or decision - and the same six generic fields for all four. That design fails quietly, because the four registers do different jobs and need different machinery. A risk needs scoring; a decision needs none. An action needs a due date and an overdue alarm; a decision is never overdue. Cram them into one grid and each register loses the fields that make it work.
Four registers, four different machines
- Risks are things that have not happened yet. Each needs likelihood and impact scores, a computed rating (Critical / High / Medium / Low, with band colours), an owner and a mitigation. If your project sits inside a wider risk-managed business, the same logic scales up to a full risk register with inherent and residual scoring; inside a project, one L x I score kept honest is usually enough.
- Actions are promises with dates. The register's whole job is making broken promises visible: status should compute from the dates - Open, Overdue, Done - and an overdue action should turn red by itself. The moment "Overdue" depends on someone choosing to type it, the register starts flattering the people it is supposed to chase.
- Issues are risks that landed. They need severity, an owner, and a resolution trail - what was done, when, with an automatic Open / Resolved status. The common failure is treating the issues register as a complaints wall; every issue row should read as "problem, owner, plan", not "grievance".
- Decisions are the memory itself: what was decided, the options considered, who made the call, on what date. Two design rules keep this register honest. Decisions are never deleted - a reversed decision gets a new row and the old one is marked Superseded, preserving the trail. And the "why" field is compulsory, because the rationale is the part everyone forgets and the part the six-month question needs.
Two quieter registers earn their place alongside: Assumptions - things you are treating as true without proof, each with a validation status, because unvalidated assumptions are just risks wearing a disguise - and Dependencies - things you are waiting on from outside, each with an On track / At risk / Late status, because the dependency that slips silently is the one that reschedules your project for you.
The board meeting is the operating rhythm
A RAID log is not documentation. It is the agenda: open the dashboard, walk the reds, assign the owners, record the decisions. Ten minutes of preparation replaced by none.
The log pays for itself at the monthly project board - if there is one view across all the registers. Open risks by rating. Overdue actions, with aging, by owner. Open issues by severity. Decisions pending approval. Late dependencies. That single page turns the board from a status-reading exercise into a steering one: the reds are the agenda, and everything discussed lands back in the registers as a new action or decision before the meeting ends. Boards that run this loop stop having the "what happened to that thing from March?" conversation, because nothing can leave the registers without a status saying how.
One caution from the quality world: the RAID log records that something is being managed, not how. When an issue needs real root-cause work, take it to the proper tools - a 5 Whys for the quick ones, an 8D when a customer is watching - and link the reference back to the issue row. And if responsibilities across the project team are themselves the confusion, that is a RACI matrix problem; the two documents work well stapled together at kick-off.
The RAID log where all four registers actually work
Risks with L x I scoring and automatic ratings, actions with self-computing Open / Overdue / Done, issues with severity and resolution trail, decisions with a Superseded audit trail - plus assumptions, dependencies and one dashboard across the lot.