RAID logs go stale. Here’s how to keep them alive.

Open most RAID logs — Risks, Actions, Issues, Decisions — and you’ll find a tidy spreadsheet that was clearly updated right before the last audit and not touched since. It exists to be shown, not used. Which is a shame, because a living RAID log is the closest thing a project has to a smoke detector; a stale one is a smoke detector with the battery removed for being annoying.

A log without owners is a wish list

The fastest way to tell if a RAID log is alive: pick three risks and ask who owns each and when the mitigation is due. If the answers are blank or “the team,” the log is decorative. A risk without an owner and a date isn’t being managed — it’s being hoped about. Owners and due dates are what turn a list into a set of commitments.

Rank by exposure, not by vibes

Not all risks deserve equal attention, so stop treating them equally. Weight each by its dollar exposure and its probability — expected monetary value — and the log sorts itself into the handful that actually matter. Now your risk review is ten focused minutes on the top five, not an hour pretending to care equally about twenty.

Close the loop when a risk comes true

A risk that materializes isn’t a risk anymore — it’s an issue, and it needs to move. Logs go stale precisely here: the risk stays open, a near-duplicate issue gets created somewhere else, and the traceability is lost. Convert it, carry the history, and your log tells a clean story: we saw this coming, here’s when it hit, here’s what we did. That narrative is gold in a post-mortem and worth everything in the moment.

Don’t forget the D

The Decisions half of RAID is the most neglected and the most valuable. Record what was decided, by whom, and why, and you stop re-litigating the same question every six weeks when someone new asks “wait, why did we do it this way?” A decision register is institutional memory that pays for itself the first time it ends a circular argument.