Raising a Risk Isn’t Being Negative. It’s Being Responsible.
The RAID log is one of the simplest project management tools available, and one of the most consistently overlooked.
Think about it this way.
If a delivery company keeps promising dates knowing full well that factors outside their control could impact the schedule — that’s not confidence. That’s irresponsible.
Smart operators do it differently. When a real risk emerges — supply constraints, resource availability, external dependencies — they name it, plan around it, and manage expectations before it becomes a crisis.
That is exactly what a RAID Log does for your project.
What RAID Actually Stands For
RAID stands for Risks, Actions, Issues, and Dependencies.
Four categories. Four types of things that can quietly derail a project when nobody is paying attention to them.
Risks — Things that could go wrong. Not things that have gone wrong yet — things that might. Resource availability. External vendor delays. Regulatory changes. Technology constraints. Every project has them. The question is whether your team has named them, assessed their probability and impact, and has a plan for if they materialize.
Actions — Things that need to happen to keep the project moving. Not tasks on the project plan — specific actions that need to be taken to address a risk, resolve an issue, or clear a dependency. With an owner. With a due date. With accountability.
Issues — Things that have already gone wrong. Problems that are active right now. Issues without owners don’t get resolved — they escalate. The RAID Log makes sure every active issue has someone responsible for driving it to resolution.
Dependencies — Things your project is waiting on, or that are waiting on your project. Internal teams. External vendors. Regulatory approvals. Data availability. System readiness. Dependencies are the single biggest source of surprise delays — and they’re almost always knowable in advance if someone does the work to map them.
What Happens When You Take Dependencies Seriously
I’ve seen what rigorous dependency thinking looks like at its best.
During the divestiture of IBM’s PC division to Lenovo — a $2.3 billion transaction with a fixed closing date and enormous technical complexity — the team I was part of mapped every possible scenario from a technology perspective. Pages of dependencies. Stack ranked. Categorized. Assigned to owners. Each one stress-tested with a what-if scenario: if this goes wrong, what happens, and what do we do?
That level of preparation wasn’t paranoia. It was professionalism.
Because we had done the work up front — because we knew what could go wrong and had the resources and knowledge positioned to react fast — we were able to stay on track and be ready for the final signing.
The limited timeline didn’t break us. It focused us. And the dependency work is a significant part of why.
What Happens When You Don’t
I’ve also seen what happens on the other end of that spectrum.
When teams take what I call the Pollyanna view — “we can deliver X points per sprint, therefore we can hit this schedule” — without accounting for resource availability, testing time, customer validation cycles, or external dependencies, the estimates are best-case scenarios presented as commitments.
And best-case scenarios almost never happen.
I’ve watched delivery teams refuse to think through actuals or use historical trends to call out dependencies and risks — not because they didn’t know better, but because middle management didn’t want to hear it. Because naming a risk felt like pessimism. Because identifying a dependency felt like making excuses.
The result? Scope, schedule, and budget all suffered. Repeatedly. Predictably. Expensively.
Not because the problems were unforeseeable. Because nobody was willing to foresee them.
What a RAID Log Really Is
It’s not a doomsday document. It’s a readiness document.
It’s your team saying: we’ve thought about what could go wrong. We know who needs to be on standby. We know who owns what. We know who to call when things start to go sideways.
The experts and teams who may need to react quickly — they need to know they might be needed. Dependencies need to be mapped before they become blockers. Issues need owners before they become crises. Risks need plans before they become surprises.
It doesn’t have to be fancy. But it does have to exist.
And it has to be maintained — updated regularly, reviewed in team meetings, and treated as a living part of the delivery process rather than a document created once and forgotten.
The Projects That Fail
Aren’t always the ones with the biggest problems.
They’re the ones where nobody had a plan for the what-ifs. Where the dependency was always there but nobody documented it. Where the risk was always known but nobody wanted to say it out loud. Where the issue sat unowned for weeks because it wasn’t technically anyone’s job.
Naming these things isn’t pessimism. It isn’t creating problems that don’t exist.
It’s the most responsible thing a delivery team can do.
—
The RAID Log is part of every HQ Partners Build & Transform engagement. It stays with your team when we leave — because the discipline of thinking through what could go wrong doesn’t stop when a consultant walks out the door.
If you want to see how it works in practice — let’s talk.
Learn more about our Build & Transform Phase here:
Not sure about your next steps?
Start with our free Pre-Engagement Alignment Assessment — a quick diagnostic tool that helps you identify where your business needs to focus before any engagement begins.
Ready to talk? Book a 30-minute discovery call.