Ten years of agency project management has convinced me of exactly one universal truth: the project that hurts you is never the one with the visible fire. It is the one where a risk was mentioned once, verbally, in a status meeting in March, and by June it is an issue, and by July it is a scope dispute, and by August it is a conversation about the invoice.
The RAID log exists to prevent that project. And yet most RAID logs are dead on arrival: created during kickoff because the methodology said so, updated twice, then abandoned in a folder nobody opens. The client never reads it. Half the delivery team never reads it. It becomes compliance theater.
This post is about the difference between that RAID log and one that clients actually read, reference, and, crucially, cannot later pretend they never saw.
RAID in thirty seconds
For anyone newer to the acronym: Risks, Assumptions, Issues, Dependencies. Some shops swap Assumptions for Actions or add Decisions, and I will argue below that Decisions is the single most valuable letter you can add. In practice it is one log with a type column:
- Risk: something bad that might happen. Has a probability and an impact.
- Assumption: something we are treating as true without proof. “Client will provide product copy by the 15th.”
- Issue: something bad that is happening now. A risk that graduated.
- Dependency: something we cannot start until someone else finishes.
- Decision: a choice that was made, by whom, on what date, with what context.
Nothing exotic. The value is not in the taxonomy. It is in the discipline around it.
Why RAID logs die
Every dead RAID log I have audited (and cleaning up other agencies’ engagements means I have audited plenty) died of one of three causes.
It was written for auditors, not readers. Forty rows of boilerplate risks copied from the last project. “Resource availability may impact timeline.” No client reads that, because it says nothing. A real risk entry names names: “Sarah is the only developer who knows the checkout integration, and she is on leave the last two weeks of October.”
It had no rhythm. A log updated “when things come up” is a log updated never, because the person who notices a risk mid-sprint is busy. The log needs a standing appointment.
Everything was priority high. When twelve risks are all critical, the client’s eyes glaze and the one genuinely critical risk drowns. Severity inflation is how PMs signal diligence, and it is how logs lose their audience.
The one-page rule
Here is the discipline that changed my logs from theater to tool: the client-facing view is never more than one page. Ten to fifteen live rows, maximum. Everything closed or dormant moves to an archive view.
This sounds cosmetic. It is not. The one-page rule forces triage. If a new risk deserves the page, something else has to be resolved, downgraded, or archived, which means every addition triggers a review of what is already there. The log stays alive because the page has scarcity.
It also changes the client conversation. “Here is the one page of things that could hurt your project” gets read. A 60-row export does not.
Owners and dates or it did not happen
Every row gets three things or it does not get entered: a named owner (a person, never “client team”), a review date, and a next action. Not a mitigation paragraph. A next action, with a verb.
The named owner matters most on the client side. “Dependency: final brand assets from Dana by Nov 4” does something subtle and powerful: it puts the client’s own commitments in the same log as your risks. Scope creep rarely announces itself; it arrives as a slow accumulation of “small asks” and slipped client-side deliverables. When those live in the log with names and dates, the mid-project conversation about a slipping timeline stops being your word against their memory. The log remembers.
The Decisions column is your scope armor
If you add one thing to a classic RAID log, add Decisions. Date, decision, who made it, and one line of context. “Oct 12: client chose Option B homepage layout, revisiting after launch. Decided by M. Torres on the status call.”
Two months later, when a stakeholder who missed that call asks why the homepage looks like Option B and suggests this was never agreed, you do not argue. You scroll. I have watched a decisions log turn what would have been a two-week unpaid rework battle into a ninety-second conversation. It is the cheapest professional liability insurance an agency can buy, and it costs one row per decision.
This applies even if you are a one-person shop. Solo consultants and lean digital operators arguably need the paper trail more, since there is no account director to back you up; the operators writing at El Oro Digital make a similar case about lightweight systems being what lets a small shop punch above its weight.
Give it a rhythm: the status meeting merge
The single best structural decision I made: the RAID log IS the status meeting agenda. Not an appendix to it. We walk the one-page view top to bottom, newest first. Each row gets thirty seconds: owner speaks, status changes or it does not, review date moves.
This kills two birds. The log gets its standing appointment, so it never goes stale. And the status meeting gets a spine, so it stops being a vibes-based recap of the week. Clients notice the difference immediately. Meetings got shorter and complaints about “not knowing where things stand” went to zero, because where things stand is literally a shared page with dates on it.
One mechanical note: walk it live, on screen, and edit during the meeting. A log updated in front of the client is a log the client trusts. A log updated the night before reads like a report. A log updated after reads like a cover story.
The template question
People always ask what tool this needs. Honestly: fewer than you think. A grid with type, description, owner, severity, next action, and review date columns covers ninety percent of it. The mistakes are usually structural, not technological: no severity scale defined, no archive view, free-text owners.
If you want a starting structure instead of building one, the free RAID log template is the one I point junior PMs at. It has the type and severity discipline baked in, the one-page live view versus archive split, and a decisions section, and since viewers cost nothing you can share it with clients read-only without touching your seat count. Strip it down rather than building it up; every column you add is a column someone will stop filling in by week three.
Start with the next meeting
You do not need to retrofit your whole portfolio. Pick the one project where you feel that low hum of unlogged risk. Before its next status call, write the one-page view: real risks with real names, the client’s dependencies with dates, and every decision you can reconstruct from the last month.
Then open the call with it. Watch how differently the meeting runs when there is a page everyone is looking at. That feeling is the entire case for RAID discipline, and no methodology deck can give it to you. The next meeting can.