RAID logs that people actually read
Most RAID logs are written for an audit that never comes. A few simple habits turn them into the most useful document on the programme.
Every programme has a RAID log. Few programmes use one. The usual symptoms are familiar: two hundred rows, half of them closed but never marked, risks with no owner, and a board pack that copies the top ten without anyone asking what has changed.
Here is what I do to keep a RAID log alive.
Keep the four lists separate
Risks, assumptions, issues and dependencies behave differently, so track them differently.
- Risks might happen. They need a likelihood, an impact, an owner and a response.
- Issues have happened. They need an owner, an action and a date.
- Assumptions are things we’re treating as true. Each one needs a date by which it will be confirmed, and a risk if it turns out to be false.
- Dependencies are things we need from someone else. They need the other party’s name and the date we need it by.
Put them in one list and the issues get lost among the risks.
Make every row someone’s job
An owner is one named person who will be asked about the item at the next review. “Supplier” or “IT” is not an owner. If nobody will accept an item, that is itself an issue for the board.
Write risks as cause, event and effect
“Data migration” is a topic, not a risk. “Because the legacy system holds duplicate patient records, the migration may fail reconciliation, delaying go-live by up to four weeks” tells the reader what to watch and what it would cost.
Report what has changed since the last review
At each review, ask three questions: what is new, what has changed score, and what can be closed. Reporting the movement keeps the board’s attention on what matters this month.
Close items that no longer apply
A risk that has passed, or an assumption that has been confirmed, should be closed with a note saying why. A log that only grows stops being read.
My RAID log template, with a summary tab built for board packs, is on the resources page.