Project RAID Log Template

Why a risk list alone misses half of what goes wrong

A RAID log is a risk register with three more lists added to it. If a project only needs to track what could go wrong, a plain risk register is enough on its own. RAID exists for projects where the plan also leans on assumptions worth checking, and where issues and decisions need a written record too, all four kept on one page instead of scattered across a spreadsheet, a chat thread and nobody's memory. Larger or longer-running projects tend to need the fuller version sooner than they expect.

An assumption nobody wrote down is a risk nobody knows about yet. Plans are full of things taken for granted: a vendor will deliver on time, a client will provide data by a date, that never get stated, so nobody notices when one turns out false until it's already causing a problem downstream.

A risk that already happened isn't a risk anymore. It's an issue, and it needs a different kind of entry: what happened, what it's costing, and what's being done right now, not a likelihood rating for something that's no longer hypothetical.

A decision made in a meeting and never written down gets re-litigated in the next meeting. Without a record, "why did we choose this" has no answer six weeks later, and the same debate happens twice, usually with different people arriving at a different answer.

The four lists interact, and separate documents hide that. An assumption breaking is often exactly what turns a risk from Low to High, but that connection only shows up if both lists are on the same page, updated by the same review.

Issues get logged in chat instead of in the project record. The staging database going down for six hours gets handled in the moment, in a thread, and then nothing is left once the thread scrolls past. No record that it happened, what it cost, or what changed afterward.

Old decisions get second-guessed by people who weren't there. Without a note explaining why polling was rejected in favour of a webhook, someone new to the project proposes polling again in month four, and the team either re-runs the whole discussion or quietly overrules them without explaining why.

How to use it

1. 01Put all four sections on one page, not four separate files that drift out of sync with each other within a couple of weeks.
2. 02Log every assumption the plan depends on, with a rough date to revisit it, not just the risks that were obvious enough to worry about at kickoff.
3. 03When an assumption turns out false, move it. Write it as a risk if it hasn't caused damage yet, or as an issue if it already has. Don't leave it sitting in assumptions as something everyone now knows is wrong.
4. 04Log decisions as they're made, in the same place, so the reasoning has a home next to the work it affects. Page history keeps the "why," not just the "what."
5. 05Review the whole log at each status point, not just the risk section. A stale assumption is as costly as an unmanaged risk, it's just quieter about it.
6. 06Keep entries short. A RAID log is meant to be scanned in a couple of minutes before a status update, not read like a report: a sentence per entry, with a task or a page linked for the detail.
7. 07Assign an owner to assumptions too, not only risks and issues. Someone has to be the one who actually checks whether an assumption held, or it just sits there unverified until it quietly breaks.

A project that starts with a risk register and later needs assumptions and decisions tracked too doesn't need a new tool for it. The same page just grows the other three sections, and nothing already logged as a risk has to move. That's the real point of keeping it on one wiki page with history in ShipSprint rather than four documents: the log grows with the project instead of the project outgrowing the log.