RAID log: four lists that belong in one place

A RAID log is one table holding four kinds of thing that projects usually track separately or not at all: risks, assumptions, issues and dependencies. Keeping them together is the point. They convert into each other constantly — an assumption that turns out false becomes an issue, a dependency nobody manages becomes a risk — and separate lists hide those transitions, which is where most project surprises come from.

What goes in each part of a RAID log

• Risks: things that might happen, with a likelihood, an impact and an owner. Future tense.
• Assumptions: things you are treating as true without having confirmed them. Present tense, and the column people skip.
• Issues: things that have already happened and need action now. Past tense, and the only one most teams track.
• Dependencies: things you need from somebody else, with the date you need it and the person who owes it.
• For each entry, a named owner and a date of last review — without those two it is a list of worries rather than a log.

Why assumptions are the valuable column

Because unexamined assumptions cause more failures than unmanaged risks, and they are invisible by nature. Every plan rests on things nobody said out loud: that the data will be clean, that the client will respond within a week, that the person who knows the legacy system will still be here. Writing them down converts an invisible dependency into something testable, and the exercise of listing them usually turns two or three up that nobody is comfortable with once stated plainly.

Review the log by asking what has changed category rather than by reading it top to bottom. The useful question is which assumptions are now false and which dependencies are now late — those are the entries that became something else since last time.

Keeping it alive

1. Review it on a fixed cadence, short and often rather than thoroughly and rarely.
2. Close entries explicitly, with the outcome, instead of letting them fade — a log that only grows stops being read.
3. Give every entry an owner by name, since a risk owned by the project is owned by nobody.
4. Move entries between categories openly: an assumption proven false becomes an issue, and that transition is the most informative event in the log.
5. Keep it short enough that somebody will read all of it in one sitting; forty live entries means nobody does.

Where RAID logs die

They are created at kick-off, filled in enthusiastically, and never looked at again — which makes them worse than nothing, because the project now has a document that implies the risks are being managed. The fix is cadence rather than completeness: ten entries reviewed fortnightly beats sixty reviewed once. A log nobody has touched in a month should be declared dead rather than quietly carried.

Ettex Sheets is the honest home for a RAID log — four categories as a controlled value, an owner, a review date, and prose for the detail beside it. The risks worth escalating beyond the project belong in the organisational risk register rather than here, and the two should not be the same document.