Why every project needs a RAID log from day one, and how I keep mine alive

The problem with most RAID logs

Nearly every project I've picked up mid-flight has had a RAID log somewhere, a spreadsheet, a Confluence page, a tab nobody opens. It usually has eight rows from kickoff week and hasn't been touched since. The team didn't lack discipline; the log just wasn't built into anyone's actual rhythm, so it quietly died.

A RAID log, Risks, Assumptions, Issues, Dependencies, is only useful if it's a living document someone is accountable for reviewing on a fixed cadence. Otherwise it's just a compliance artifact nobody trusts.

"The moment a RAID log stops reflecting reality, the team starts managing the project from memory instead, and memory doesn't scale past about six people."

The cadence that actually works

On the Horizen Grocery Chain eCommerce platform launch, I reviewed the RAID log after every Daily Scrum and formally at every Sprint Review, ten sprints, twenty reviews, no exceptions. That regularity is what kept it trustworthy enough that the Steering Committee used it directly instead of asking for a separate status deck.

• Score every risk. Probability × Impact on a simple scale. Anything above a threshold (we used 15 on a 25-point scale) gets active mitigation and goes in front of the Steering Committee, no judgment calls about what's "worth mentioning."
• Name an owner for every line. A risk with no owner is a risk nobody is actually managing. Every row had a single accountable name, never a team.
• Close things. An issue log that only grows looks like chaos even when the project is healthy. We closed 5 issues over the 20-week delivery, each with a documented resolution, that closure history is what made the open items credible.

A real example: payment integration

The highest-scoring risk on that project was payment gateway integration delay, a probability of 3 and an impact of 5, for a score of 15. It gated checkout, needed external provider sign-off, and carried PCI-DSS scope that couldn't be compressed.

Because it was flagged and scored in Sprint 0, the mitigation started immediately: vendor contracts kicked off in Sprint 1, sandbox integration by Sprint 3, full PCI review by Sprint 4. By the time most teams would have started noticing the risk, we'd already spent three sprints de-risking it.

Assumptions are risks in disguise

The assumptions section gets skipped most often, but it's where the quietly dangerous stuff lives. "The Product Owner is available 60%+ for backlog and team support" doesn't sound like a risk, until it's invalid, and suddenly sprint planning quality drops and the team is blocked on decisions with no one noticing why.

I treat every assumption as a risk with an implicit probability of "unknown." Writing down what happens if it's wrong, and who owns watching for that, turns an invisible dependency into something the team can actually monitor.

What I'd tell a new PM

Don't build a RAID log to look thorough at kickoff. Build the review habit first, pick the meeting it rides on (for us, Daily Scrum and Sprint Review), and only then worry about the template. A log that's reviewed every two weeks in a five-minute slot will outperform a beautifully structured one that's opened once a month.

---

If you're setting one up for the first time, start with just Risks and Issues, Assumptions and Dependencies can follow once the review habit is real.