Most RAID logs die within a month of being created. Someone sets one up during program kickoff, populates it dutifully for a few weeks, and then it quietly turns into a graveyard—thirty risks nobody has looked at since March, action items with no owner, issues marked “open” from a status meeting two quarters ago. The tool isn’t the problem. A RAID log fails because it’s treated as a document to maintain rather than a habit to practice. Done right, it’s one of the simplest and most effective governance tools a program has. Done wrong, it’s proof to your sponsor that governance on this program is theater.
Key Takeaways
- A RAID log only works if it’s reviewed on a fixed cadence, out loud, in a meeting where decisions actually get made.
- Every entry needs a single named owner and a real next action—”monitor” is not an action.
- Separate risks from issues clearly; conflating them is the fastest way to make the log useless for prioritization.
- Prune aggressively. A 200-line log nobody can hold in their head is worse than a 20-line log that’s actually current.
- Assumptions and dependencies are the two categories teams skip most often—and the two that cause the most downstream surprises.
Why Most RAID Logs Stop Getting Used
The typical failure pattern is predictable. A RAID log gets built as a compliance artifact—something the PMO template requires—rather than as a working tool the team actually consults to make decisions. It gets updated before steering committee meetings as a cosmetic exercise, then ignored the rest of the time. Entries pile up because adding a risk is easy and closing one requires an actual decision, so the log grows monotonically until it’s too large for anyone to meaningfully review, at which point everyone quietly stops trying.
The underlying cause is almost always the same: nobody made the RAID log a habit tied to a specific meeting with specific decision-making authority. If there’s no recurring forum where entries get triaged, owners get assigned, and old items get closed or escalated, the log has no mechanism for staying current. It just accumulates until it’s abandoned.
Keep the Four Categories Genuinely Separate
RAID stands for Risks, Assumptions, Issues, and Dependencies, and the value of the framework depends on keeping those categories distinct rather than dumping everything into one generic “things to worry about” list.
Risks are things that might happen and would hurt the program if they did—they need a likelihood, an impact, and a mitigation plan. Issues are risks that already happened, or problems that already exist; they need an owner and a resolution path, not a mitigation plan, because mitigation is no longer relevant once something has occurred. Assumptions are things the plan depends on being true that haven’t been verified—a vendor delivery date, a resource’s availability, a system’s capability—and they need to be actively validated, not just recorded. Dependencies are the specific handoffs and external inputs the program relies on, each with an owner on the providing side.
Teams most commonly skip logging assumptions and dependencies, because they feel less urgent than risks and issues. That’s exactly backwards—an unvalidated assumption is a risk you haven’t acknowledged yet, and an untracked dependency is the single most common cause of programs discovering a blocker three weeks before go-live instead of three months before.
Every Entry Needs an Owner and a Real Next Action
An entry without a named individual owner is not a managed risk—it’s a wish that someone will deal with it. “The project team” is not an owner. A specific person, by name, is an owner. Similarly, “monitor” or “keep an eye on” is not a next action; it’s the absence of one dressed up to look like progress. A real next action specifies what will happen, who will do it, and by when—for example, “confirm vendor’s revised delivery date by Friday’s call” rather than “watch vendor timeline.”
This discipline is what separates a RAID log that drives decisions from one that just documents anxiety. If you can’t write a concrete next action for an entry, that’s usually a signal the entry needs more thinking before it belongs in the log at all, or that it should be escalated because the team doesn’t have enough information or authority to act on it themselves.
Build the Review Cadence Before You Build the Log
The single highest-leverage decision in making a RAID log actually work is establishing the review cadence first, before the log even has content. A weekly 20-minute RAID review with the core program team—separate from broader status meetings—is usually enough for most programs. The agenda is simple: walk new entries since last time, check on owners’ progress against open items, close anything resolved, and flag anything that needs escalation to the steering committee.
The habit that keeps this alive is treating the review as a working session, not a status readout. People should leave with assignments, not just an updated spreadsheet. If the review consistently produces action, the team will keep showing up for it and keep feeding the log. If it consistently produces nothing but a re-read of last week’s list, attendance and engagement will drop off within a few cycles.
Prune Ruthlessly
A RAID log with 150 entries is functionally useless, even if every entry is technically valid, because nobody can hold that much in their head during a review and prioritize correctly. Set an explicit expectation that entries get closed, not just added. A risk that hasn’t materialized and whose window has passed should be closed. An issue that’s been resolved should be closed and archived, not left open “for the record.” Old assumptions that have since been validated one way or the other should be resolved out of the log.
A good target for most mid-size programs is somewhere in the 15–30 active entries range at any given time. If the count is consistently climbing past that, it’s usually a sign either the team isn’t closing things or the log is being used to capture noise—minor operational friction rather than genuine program-level risks, issues, assumptions, and dependencies. Keep a lightweight archive of closed items for institutional memory, but don’t let it clutter the active view.
Frequently Asked Questions
Who should own the RAID log itself?
The program or project manager typically owns the log as an artifact—maintaining it, running the review cadence, and making sure entries have owners. That’s different from owning every individual entry; each risk, issue, assumption, or dependency should have its own named owner responsible for acting on it.
How is a RAID log different from a general risk register?
A risk register only tracks risks. A RAID log deliberately widens the lens to include issues that have already materialized, assumptions the plan depends on, and dependencies on other teams or vendors—categories that are just as likely to derail a program but often get missed by a risk-only view.
Should every risk get escalated to the steering committee?
No. Most entries should be resolved at the working-team level. Escalate only when an item exceeds the team’s authority to resolve, requires a decision or resource only the sponsor can provide, or has program-level impact that the steering committee needs to be aware of before it becomes a surprise.
What tool should we use to track a RAID log?
The tool matters far less than the habit. A shared spreadsheet, a table in your collaboration platform, or a dedicated PPM tool can all work equally well. Pick whatever your team will actually open and update weekly without friction—an elaborate tool nobody maintains is worse than a simple one that’s genuinely kept current.