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.
The RAID log template downloads as an Excel file (.xlsx) that also opens cleanly in Google Sheets, so you run it in whichever tool your team already lives in. The conditional formatting that surfaces your top risks by severity carries across both. No macros to enable, nothing that breaks when someone opens it on a Mac, no add-ons to install.
If you would rather not open a spreadsheet at all, the same model ships as a browser-based RAID log app: add and score entries with one click, filter by owner or severity, export to CSV when you need to share. Same RAID discipline, different surface. Most people start with the Excel template because it drops straight into the tools they already report from; the web app is for teams that want a live board they keep open all week.
Here is what eight entries look like when the log is doing its job: two per letter, each with a named human, the date the program actually needs, and a next step instead of a narrative.
| Type | Entry | Owner | Needed by | Status and next step |
|---|---|---|---|---|
| Risk | Vendor SOW for the data migration is unsigned; procurement runs 6 weeks | M. Okafor | Aug 15 | Amber. Escalates to the sponsor if unsigned by Jul 25. |
| Risk | Payments workstream loses 2 engineers to the replatform in Q3 | J. Alvarez | Sep 1 | Green. Backfill approved, watching weekly. |
| Assumption | Legal review of the data-retention change lands by month end | R. Chen | Jul 31 | Untested. Confirming with counsel this week. |
| Assumption | Current API rate limits hold at 2x forecast volume | D. Novak | Aug 8 | Load test scheduled Jul 22. |
| Issue | Staging environment down 3 days; release rehearsal slipped | K. Patel | Now | Red. Fix ETA Thursday, rehearsal moved to Jul 24. |
| Issue | Two workstreams booked the same UAT window | S. Ford | Jul 28 | Amber. Re-sequenced, confirming in Friday's review. |
| Dependency | Identity service v2 from the platform org gates the SSO cutover | L. Moreau | Aug 22 | Amber. Weekly ping running, escalation path agreed. |
| Dependency | Launch copy needs final pricing from Finance | A. Reyes | Aug 1 | Green. Draft in review. |
Two things make these entries work. Every owner is a person, not a team; teams do not return calls. And every status ends in a next step with a date, not a mood. An entry that can't answer "what happens next, by when, owned by whom" isn't tracking the item. It's memorializing it.