The RAID Log That Survives Contact With a Real Project
A RAID log is one of the cheapest project-control tools you own, and one of the most neglected. The acronym stands for Risks, Assumptions, Issues, and Dependencies. Done well, it is the single place where your team writes down what might hurt the project, what you are taking on faith, what has already gone wrong, and what you are waiting on from someone else. Done badly, it is a spreadsheet someone built at kickoff and nobody has opened since.
In early 2022, with inflation climbing, materials and labour in short supply, and return-to-office plans shifting week to week, the gap between a live RAID log and a dead one is the gap between a team that sees trouble coming and one that gets surprised. Here is a checklist you can put to work this week.
Get the four categories straight
The most common failure is mixing the columns. People log a risk as an issue, or bury a dependency inside an assumption, and the log loses its teeth. Keep the distinctions sharp:
Risks. Things that might happen and would hurt if they did. They have not happened yet. Each one needs an owner, a likelihood, an impact, and a response (avoid, reduce, transfer, or accept).
Assumptions. Things you are treating as true without proof, because the plan depends on them. "The precast supplier can still hit the March slot" is an assumption — and in 2022, an aggressive one. Assumptions that fail become risks or issues.
Issues. Things that have already gone wrong and need action now. An issue is a risk that came true, or a problem nobody saw coming. It needs an owner and a target resolution date.
Dependencies. Things you need from another team, vendor, or approval body before you can proceed. Track who owes what to whom, and by when.
The build checklist
Give every entry a single named owner — not a team, a person. Shared ownership is no ownership.
Date every entry when it is raised and every time it is updated, so you can see what is going stale.
Rate risks on likelihood and impact using the same simple scale across the project (a 1–5 grid is plenty).
Write the response, not just the rating. "High risk" with no plan is just anxiety in a cell.
Add a status column with a tiny set of values: open, in progress, closed, escalated. Resist the urge to invent twelve.
Keep one log per project, in one place everyone can reach. Three copies in three inboxes means zero reliable copies.
Keep it alive
A RAID log is a living document or it is nothing. The habit that keeps it breathing is a short, recurring review — ten minutes at the top of your weekly project meeting is enough. Walk the open issues first, then the top risks, then any dependency that is slipping. Close what is done so the list stays honest, and promote any assumption that has quietly turned shaky into a risk before it becomes an issue.
Two more habits separate the logs that last. First, escalate on a clock, not a feeling: agree up front that any issue open past its target date, or any high risk without a response, goes to the steering committee automatically. Second, write entries a stranger could understand. The person who reads this log in six months — maybe during an audit, maybe after you have moved on — should be able to follow the story without you in the room. A RAID log that survives contact with a real project is not the fanciest one. It is the one the team trusts enough to update on a bad Tuesday.
If you want help standing up project controls that hold up under real pressure, XNM's program & project delivery advisory can help you build and embed them.