The RAID Log Nobody Updates: Common Failures and How to Avoid Them
A RAID log — risks, assumptions, issues, dependencies — is one of the simplest project tools there is, and one of the most frequently abandoned. It gets set up with good intentions at kickoff, populated heavily for a week, and then quietly dies. By the time something goes wrong, the log shows a risk that was open six months ago and an issue that was actually closed in March. When teams went remote and hybrid through 2021, this got worse: the corridor conversations that used to keep everyone informally aware of the live risks disappeared, and a stale log was suddenly the only shared memory. Here is where these logs fail, and what to do instead.
Why RAID logs go stale
Confusing the four categories. A risk is something that might happen; an issue is something that already has. An assumption is something you are treating as true without proof; a dependency is something you need from elsewhere. When teams dump everything into one bucket labelled "stuff to watch," the log loses the precision that makes it useful.
No owner per line. An entry without a named person is an entry nobody updates. "The team" owning a risk means no one does. Every line needs one name.
Logging without rating. A risk with no probability and no impact cannot be prioritized, so everything looks equally urgent, which means nothing does. Without a score, the log becomes a flat list you scroll past.
Treating it as documentation, not a working tool. If the log only gets opened to satisfy a governance checkbox, it will always be out of date. It has to be the thing you actually run the conversation from.
Never closing anything. A log that only grows becomes unreadable. Risks that have passed and issues that are resolved need to be marked closed, with a date, so the live items stand out.
Making it a log the team keeps current
The fix is less about the template and more about the rhythm. A RAID log stays alive when reviewing it is a small, regular, visible act rather than a quarterly archaeology dig.
Put a short RAID review on a recurring agenda — a few minutes in the weekly project meeting, not a separate ceremony nobody attends.
Keep it where the team already works, not in a buried file. For a remote team, a shared, always-open view beats a document someone has to remember to send.
Score risks simply — high/medium/low probability against high/medium/low impact is enough to sort the list.
Give every entry an owner, a status, and a last-reviewed date, so a glance tells you what is live and what is fossilized.
Close items out loud. Marking a risk closed and saying why is as important as raising it.
A good RAID log is not a thick artifact; it is a short, honest, current picture of what could derail the work and who is watching each thing. When it is genuinely kept up, it does the quiet job it was meant to do — it lets the team see trouble early enough to act, rather than explain it afterward.
If your risk and issue tracking has drifted into a document nobody trusts, XNM's program & project delivery advisory can help you rebuild a RAID discipline your team will actually use.