The RAID Log: The Most Underused Tool in Infrastructure Projects

On large infrastructure programmes, the RAID log is where projects quietly succeed or fail. Teams create one at kickoff, fill it with generic entries, and then stop looking at it. When it's used properly, it's the single best early-warning system a project manager has.

What RAID stands for

• Risks — things that might happen and would affect the project
• Assumptions — things we're treating as true without proof
• Issues — things that have happened and need action
• Dependencies — things we need from others (or others need from us)

Writing risks that are useful

A weak risk: "Vendor delays."

A useful risk: "If the hardware vendor misses the 15 March delivery date, wave 2 cutovers (40 sites) slip by at least three weeks, because change windows are booked four weeks in advance."

The second version has a cause, an event and a consequence. It tells everyone why it matters and points directly at mitigations — confirm dates in writing, identify alternative stock, pre-book backup change windows.

Scoring that people actually use

Keep scoring simple: probability × impact on a 1–5 scale, with clear definitions for each number. The goal isn't precision — it's consistent conversations about what to worry about first.

Assumptions are risks in disguise

Every assumption should have an owner and a date by which it will be validated. "Site access will be available out of hours" is fine on day one. On day sixty, an unvalidated assumption is just a risk nobody has scored.

Dependencies are where infrastructure projects break

In network and data-centre work, most delays come from outside the project team: circuit delivery, firewall rule approvals, application owners for testing, facilities access. Track each dependency with:

• who provides it
• who needs it
• the date it's needed
• the date it's committed

The gap between "needed" and "committed" is where you'll find next month's issues.

Making it a habit

1. Review the RAID log in every weekly project meeting — top risks and overdue items only
2. Escalate anything above an agreed score to the steering group automatically
3. Close items explicitly; a RAID log that only grows is a RAID log nobody trusts

Free template

I've shared the RAID log template I use — with scoring, owners and an escalation view — in the Resources section.