The tab nobody has opened since April
You know the one. It lives in a workbook called `Project_Tracker_FINAL_v3.xlsx`, on a tab labeled RAID, and the last edit date says April 14. It is now October.
Someone created it with real enthusiasm at kickoff. There are twelve risks in there, color coded, beautifully formatted. Every single one is still marked "Open, Medium, monitor." Nobody has looked at it since the person who made it went on leave.
That is a graveyard spreadsheet. It exists so that when something goes wrong, you can point at a cell and say the risk was logged. It does not actually help you steer.
A RAID log is supposed to be a working tool, not an alibi. Let us fix that.
What RAID means, and where it usually rots
Quick definition, because people stretch these words. RAID stands for Risks, Assumptions, Issues, and Dependencies. I want to be precise about two of them, because they get muddled.
- Risk: something that might happen and would hurt (or help) the project if it did. It has not happened yet. It carries a probability.
- Issue: something that has already happened and is hurting you right now. No probability. It is real.
- Assumption: something you are treating as true without proof, and that would change your plan if it turned out false.
- Dependency: something you need from someone else, or something they need from you, before work can move.
The rot usually starts because the log tries to do too much. People dump anything vaguely worrying into it, so it swells to sixty rows. Nobody can scan sixty rows in a status meeting, so nobody reads it. Once it is unread, it stops being updated. Once it stops being updated, it is a museum.
The fix is not a better template. It is a smaller log with sharper habits.
Every row needs an owner and a date, or it does not belong
Here is the single rule that separates a live RAID log from a dead one.
Every entry has a named owner and a next review date.
Not a team. A person. "The vendor team" cannot lose sleep over a risk. Priya can. And not "ongoing" as a review date, because ongoing means never. A real date forces a decision the next time it comes around.
When a row has no owner, it belongs to everyone, which means it belongs to no one. When a row has no date, it never gets revisited, so it drifts into the graveyard.
The other quiet killer is vagueness. "Resourcing risk" tells you nothing. Compare these two entries:
- Bad: "Risk: resourcing. Medium. Monitor."
- Better: "Risk: our only Salesforce integration developer, Dan, is booked on the Billing project through November. If the migration slips into November, we have no one to build the connector. Owner: Priya. Review: Nov 3."
The second one is longer, and that is fine. You can act on it. You can see the tradeoff, the person, and the deadline. A skeptical reader nods instead of shrugging.
A worked example: the Thursday five-minute pass
Let me show you how this plays out in real life, because a rule you cannot sustain is just guilt.
Picture a program manager, Marcus, running two projects that share people: a CRM migration and a customer portal rebuild. Every Thursday morning, before his team standup, he does a five-minute RAID pass. Not an hour. Five minutes.
He opens the log and looks only at rows whose review date is today or overdue. This week there are three.
- Dependency: portal team needs the CRM data model finalized before they build the account screen. Owner is Marcus. Review was due today. He checks: the data model got signed off Tuesday. He marks the dependency closed and moves the portal build note into next week's plan. One row gone.
- Risk: Dan is the only integration developer and he is double booked. Owner is Priya. Still open. Priya has not found cover. Marcus escalates this one, because it now threatens both projects, not just the migration. He raises the review importance and books a fifteen-minute call with the resourcing lead for Friday.
- Assumption: the finance team will provide test data by month end. Owner is a finance analyst who just left the company. Dead owner, dead row. Marcus reassigns it to the finance analyst's manager and pushes the review to next Thursday.
That is the whole pass. Three rows touched, one closed, one escalated, one reassigned. He did not read the other forty rows, because their review dates are in the future.
Here is the honest tradeoff. This works only if you are disciplined about setting realistic review dates in the first place. If you set every date to "next week" out of anxiety, Thursday becomes a slog again and you are back where you started. Spacing the dates is a skill, and you will get it wrong at first. That is normal.
Notice also what Marcus did with the Dan risk. He did not solve it. He surfaced it to someone who could. A RAID log's job is often just to route a problem to the right person before it becomes an issue. It rarely fixes anything on its own.
Where a tool helps, and where it does not
Most of what I have described works in a shared spreadsheet. A filter on the review date column gives you the Thursday pass. Honestly, if you build that habit, you have won most of the battle.
Where a tool starts to earn its keep is when RAID entries connect to the rest of your world. A dependency should link to the task it blocks. A resource risk should show you the actual capacity clash behind it. When a risk becomes an issue, you want it to nudge the health status your executives see, rather than hiding on a tab they never open.
A portfolio tool can do that linking for you, so a risk on one project is visible to the program that depends on it.
Perspective keeps RAID registers next to tasks, dependencies, and capacity, so a resourcing risk like Dan's is not just words but a visible contention you can plan around. That said, the discipline is what matters. A shared sheet with owners, dates, and a weekly pass beats the fanciest register that nobody reviews.
How to revive your log this week
You do not need a reset. You need a pruning and a habit.
- Delete or close half of it. Open the log and be ruthless. Anything stale, vague, or already resolved gets closed or deleted. A log of eight live rows is worth more than forty dead ones.
- Give every surviving row an owner and a next review date. A person, not a team. A date, not "ongoing." If you cannot name an owner, question whether the row is real.
- Split muddled entries. If a "risk" has already happened, move it to issues. If a dependency is buried inside a risk, pull it out. Clarity now saves arguments later.
- Book a recurring five-minute slot on the same day each week, tied to a meeting you already attend so you do not forget it.
- Each week, review only the rows due. Close what is done, escalate what is stuck, reschedule what needs more time. Then stop.
Give it a month. It will feel light, because it is meant to.
A RAID log is not a record of your good intentions. It is a list of the next few things you are actually going to do something about.