The RAID Log
You already know what a RAID log is. That has never been the problem. There is no shortage of templates and a considerable shortage of RAID logs still true in week ten. This one is built around the diagnostics — including the one number that says whether the thing predicts anything or is just being maintained.
Excel (.xlsx), nine sheets, and a 13-page PDF. No email, no signup, no drip sequence.
The one number that matters
When you log an issue, the workbook asks which risk it came from. If it did not come from one, you write No. Over a quarter that produces the share of your open issues that were on the risk register before they happened — and that is the only honest measure of whether your risk register is doing any work.
Every other signal in the file measures whether you are maintaining the log. That one measures whether the log is any good. A log where nothing that went wrong was ever predicted is not a risk register. It is a diary with a governance function. There is no shame in finding that out — most of them are — but there is not much point continuing to maintain it either.
Four ways a RAID log dies
Not one of these is a comprehension problem. Nobody abandons a RAID log because they were unclear what R stood for.
The register only grows
Nothing gets closed, because most entries were written in a form that cannot be closed. Add twenty a month, close none, and by month three nobody opens the file.
It becomes a compliance artifact
Maintained because a steering committee asks for it, read by nobody, updated in the fifteen minutes before the meeting. Technically current. Functionally decorative.
Everything drifts into Risks
Assumptions and dependencies get logged as risks because that tab already exists, and then they inherit the risk review cadence — which is to say, none.
The review produces words
Forty minutes of genuine engagement, nothing assigned. Next month the same four items get discussed with the same energy by the same people.
The four fields that do the work
Every template gives you a description, an owner and a status. Those are necessary and they change nothing. These four are what make each category behave differently from the others, and most templates have none of them.
| Category | The field | Why it changes everything |
|---|---|---|
| Risks | Trigger date | The day you would know either way — not a due date. Without it a risk cannot be closed, so the register only ever grows. With it, every risk eventually forces a decision: it became an issue, or it did not happen and you were right to watch it. |
| Assumptions | How we would know it is wrong | A concrete observable, not a confidence rating. “Their first sample file has more than 5% null keys.” If you cannot write that sentence, what you have is a belief, and beliefs are only ever disproved by delivery. |
| Dependencies | Have they confirmed? | In writing, verbally, or not at all. A written yes survives the other person being reassigned. A verbal one survives until they are. An assumed dependency is not a dependency — it is a hope with a due date. |
| Issues | Was it on the risk register? | The risk ID it came from, or “No”. Four seconds per issue, and over a quarter it produces the only honest measure of whether your risk register does anything. Writing “No” repeatedly changes behaviour faster than any process guidance. |
A note on what A and D stand for
Most people learn RAID as Risks, Assumptions, Issues, Dependencies. RAIDLOG, who have thought about this harder than most in public, use Risks, Actions, Issues, Decisions — on the grounds that assumptions and dependencies get set at kickoff and monitored, while actions and decisions have to be actively managed every week. A log is a tool for active management, so it should hold the things that need managing. They fold assumptions and dependencies into Risks rather than dropping them.
That is a coherent position built on a real observation, and we have taken half of it: this workbook has an Actions sheet, because a review that produces nothing is a reading group.
We keep assumptions and dependencies as their own categories, though, and the reason is practical rather than doctrinal. Folding them into Risks does not raise the attention they get — it lowers it, because they now compete with things that are on fire and lose that competition every week. The two categories that rot most quietly are exactly the two being folded away. There is also a difference in what you do about them: a risk gets a response, an assumption gets a test and a date, a dependency gets a confirmation from another human being. Merging the categories tends to merge the actions into the vaguest of the three.
Twenty minutes a week, and not in alphabetical order
RAID is alphabetical for the same reason acronyms usually are. Reviewing in that order means spending your freshest attention on things that have not happened yet while something is actively on fire. Reviewing out of acronym order is RAIDLOG’s idea and it is a good one — ours ends with the two categories we kept, so the quietest things get a slot rather than the leftovers.
| Order | What you ask | The failure it catches |
|---|---|---|
| 1. Issues | What is open, what is overdue, and for each one — was it on the risk register? | Issues that quietly become conditions of the project rather than problems with it. No fix-by date means nobody has agreed when it stops being true. |
| 2. Risks | Whose trigger date has passed? What scores high with nothing written down? | A passed trigger is either an unlogged issue or a risk that never existed. Both need a decision that day, and both are invisible without the date. |
| 3. Dependencies | What is due soon and only verbally agreed? What has nobody confirmed at all? | The plan being wrong while everybody is honest. Caught three weeks out it is an email. Caught on the day it is a slipped delivery. |
| 4. Assumptions | What is past its validate-by date and still untested? | Risks you decided not to look at. This slot exists because assumptions never win attention against anything urgent. |
Two rules worth borrowing, both RAIDLOG’s: anything that takes under two minutes gets done inside the review, and an action open past two weeks gets flagged — because an action that old is not being worked on, it is being carried. And one of ours: the review must produce actions or it did not happen. The workbook counts them.
What is in the workbook
- Start Here
- The legend, the colour convention, and the four fields that do the work.
- Issues
- Already happened. One column asks whether it was on the risk register first — the field that grades the whole file.
- Risks
- Not yet happened. Probability and impact score themselves; a trigger date makes each one closeable.
- Dependencies
- Someone else's to deliver. Confirmed in writing, verbally, or not at all — with the days until you need it.
- Assumptions
- Treated as true without checking. Needs a written test and a date to run it, or it is a belief.
- Actions
- What the review produced. Time-boxed at two weeks, because an older action is being carried rather than worked on.
- The Review
- Sixteen signals across all five registers, ordered issues first. This is the agenda, computed rather than remembered.
- Thresholds
- What counts as neglected, each with the reasoning beside it.
- Snapshot
- The one you send back. Eight numbers fill themselves in.
It ships with an invented project across all five registers, deliberately a bit of a mess, so The Review has something to chew on and you can see what a flag looks like before your own numbers start doing it to you. Delete it all before you use this for real — and do not migrate your old RAID log across, because most of what is in there is exactly the material that made the old one unreadable.
After four reviews, send it back
The last sheet is Snapshot. Eight numbers fill themselves in, including the share of issues you saw coming. Three boxes ask what no spreadsheet can work out: who runs the review, which category you found hardest to fill in honestly, and what went wrong that was not on any of these sheets.
Fill those in and email the file to connect@cnnctd.work. That third question is the one we care most about — every RAID log has a blind spot, and it is usually the same shape as the person maintaining it.
One overlap worth naming: if your RAID log keeps going stale, the cause is usually coordination rather than diligence — the review is not happening because no rhythm holds it. That is a different tool, below. The reasoning behind keeping any record current in the same pass as the work is Closed-Loop PM, and all of this is the operating half of Discipline Stacking.
The other two
Three tools, three failures that feel identical from the inside — the vague sense that everything takes longer than it should. Worth knowing which one you actually have, because the fixes have nothing in common.
The Operating Cadence
Whether the record keeps up with reality, or the board is a description of last Tuesday.
Workbook and field guide →
Measures ConcentrationThe Founder Dependency Audit
How much of the business runs through one person, and how long you could vanish before anybody outside noticed.
Workbook and field guide →
All three are free, ungated, and listed at the toolkit index.
Imposed RAID logs are compliance artifacts. That reputation is deserved.
A log kept by the person who has to deliver the thing, reviewed for twenty minutes a week, producing three actions, is a completely different object that happens to share a name. If you want somebody in the room while that becomes normal, this is where to start.