RAID Logs: What They Are & Why You Actually Need One
So, we’ve talked about Project Risk Management – the art of keeping an eye on what could go wrong and what already has – and we mentioned this magical thing called a RAID Log.
Shall we dive in and look at what that actually is, and how to use it properly?
RAID Logs
Let me tell you what a RAID is not — it’s not a high school football team chant. (“Give me an R! R! Give me an A! A!”)
A RAID log is one of those project management tools that sounds like jargon... until you actually start using it. Properly. Then it becomes your best friend — or at the very least, your secret weapon for managing the chaos in a project.
RAID stands for:
Risks – things that might happen.
Assumptions – things you’re treating as true (but haven’t confirmed).
Issues – things that are happening and need fixing.
Dependencies – things that need to happen before something else can move. (These help you identify your blockers.)
Let’s make it real. Imagine you’re building a house:
Risk: There might be delays due to bad weather, which could push back the roofing work.
Assumption: You’re assuming the materials will be delivered on time from the supplier.
Issue: The electrician hasn’t turned up, and the wiring is already overdue.
Dependency: You can’t start plastering until the insulation and wiring are completed.
Suddenly, a RAID doesn’t feel so abstract, right?
CRAID Logs (and Other Variations)
What is a CRAID?
Some teams use CRAID logs instead, adding Constraints — things like fixed budgets, limited space, or immovable deadlines. Others might include Decisions or Actions. The format can flex to fit your project, but the core principle stays the same:
👉 Track the things that could derail your plans — before they do.
“Why should I bother? It’s just more admin.”
Whoa. I do not like that attitude. And let’s be clear:
A RAID log isn’t just a tick-box exercise
Just like tasks in a project aren’t just boxes to tick. If you believe that, then honestly... you probably haven’t seen proper project management in action. (Book a free 30-minute consultation 😉, and I’ll happily share a few stories of what happens when people ignore this stuff. Make sure you’ve got your tea ☕ready - we have a lot to spill.)
RAID logs don’t work if you just fill one in at the start of the project and forget about it. Or in your first enthusiastic week. Or worse — if you treat it like a junk drawer where you throw all your project fears, slam it shut, and hope for the best.
How to Use a RAID Log Properly
It works when you:
Start early – create it during project planning, right at the conception stage.
Keep it active – update it regularly as new items emerge or old ones get resolved (make it part of your weekly comms plan).
Review it often – go through it with your team to tackle risks, address issues, validate assumptions, and clear dependencies.
When you use a RAID log well, it brings clarity.
It helps you sleep better at night.
It keeps your team (and stakeholders) honest about what’s really going on.
Where Should You Keep It?
If you’re using a project management tool such as Asana, ClickUp, or Notion, you can build your RAID log right into your workspace. Keep it live, make it collaborative, and set notifications so updates don’t get lost in someone’s inbox.
Please — let’s move beyond spreadsheets called “RAID_Final_v2_(UseThisOne).xlsx.”
This week, I’ll break down each part of the RAID log in more detail — starting with Risks tomorrow.
Because having a solid strategy is great.
But managing the chaos around it?
That’s what actually gets things delivered.