A RAID log built to survive past kickoff and get opened every week. Risks, Assumptions, Issues, Dependencies, on one sheet with a weekly review cadence and named owners on every line.
Pre-built tabs for Risks, Assumptions, Issues, Dependencies. Probability/impact scoring, owner fields, due dates. Conditional formatting for severity.
One-page PDF you can pin to a Slack channel or print. Covers the review cadence, escalation thresholds, and what NOT to put in the log.
The actual rhythm I use to keep RAIDs alive: weekly 15-min review, monthly cleanup, quarterly retrospective. The cheat sheet walks through it.
One purchase, yours to keep. Use it on every program, customize for your team. Works in Excel and Google Sheets.
I've inherited dozens of programs over 20 years across enterprise programs. Almost every one of them had a RAID log. Almost none of them were being used.
The pattern: someone sets it up at kickoff. It gets a few entries in the first month. By month three, it's a tab nobody opens. When something blows up, the post-mortem says "we should have flagged this risk." It's right there in the log, last updated 90 days ago.
"A RAID log isn't a document. It's a meeting agenda. If you're not reviewing it, you don't have one."
This template forces the cadence by structure. The cheat sheet gives you the script. The result is a RAID log that drives the conversation in your weekly program review, instead of sitting in a SharePoint nobody bookmarks.
The whole reason most logs die is that nobody schedules the time to review them. The cheat sheet gives you the script. Here's the short version, the rhythm I run on every program:
Fifteen minutes, every week, named owner running it. That's the difference between a living RAID log and a tab nobody opens.
The two get conflated all the time. They serve different jobs.
A RAID log is a working document. It's the weekly meeting artifact. Risks, Assumptions, Issues, Dependencies in one place, scored simply, owned by name, reviewed in 15 minutes. Most program teams need exactly this.
A risk register is a governance artifact. It's risks only, scored deeply (probability x impact, mitigation costs, residual risk after mitigation), owned at the program-leader level, reviewed quarterly. Useful for high-stakes programs with regulatory or financial exposure where you need defensible risk math, less useful for the weekly grind.
Most enterprise programs need both: the RAID log as the working tool, the risk register as the quarterly governance layer that the program board reviews. They're not competitors, they're different cadences. The RAID log feeds your weekly status report; the risk register feeds your quarterly QBR.