A RAID log that does the boring bits for you

A RAID log is the project management record of four things every PM must track:

• Risks — things that might happen and would hurt the project if they did.
• Assumptions — things you've decided to treat as true because you have to move on.
• Issues — things that have happened and are actively hurting the project now.
• Dependencies — things another team, supplier or project must do before you can progress.

The RAID log is the single most important living document on a project. It's where governance lives, where escalation starts, and where board packs come from. If your RAID log is out of date, your project reporting is fiction.

1. They're spreadsheets. Excel is a great tool but a terrible RAID log — no audit trail, no owner, no linkage to plan or reports.
2. They get stale. PMs forget to log new risks in the heat of delivery. By month three the log has aged out of usefulness.
3. Risks and issues get muddled. "Might happen" and "is happening" are very different — mixing them destroys prioritisation.
4. No linkage to reports. A RAID log that doesn't flow into the status report is just admin.

Pocket PMO fixes all four. Morgan continuously scans live project signals — quiet workstreams, slipping milestones, overdue tasks, budget variance — and proposes new RAID items for your approval. Every accepted item flows straight into the next status report and Snapshot.

• Log a risk the moment you feel a wobble. If it doesn't materialise, close it as "not realised" — that's still a signal.
• Score every risk on probability (1–5) and impact (1–5) — the product is your exposure, and it's what your dashboard should sort by.
• Every item has an owner and a review date. A RAID item without an owner is a wish.
• Review the log weekly, at minimum, and at every stage gate.
• Distinguish "issues awaiting action" from "issues in mitigation" — different reporting story.
• Keep dependencies visible in the plan, not just in RAID. A dependency invisible to the schedule is a dependency about to slip.

For a deep dive on what belongs in a board-ready RAID report, see our guide to RAID reporting.

This is what a live RAID log looks like three months into a finance system implementation. Note that every row has an owner, a next review date and a response — not just a description.

Two things make this log useful rather than decorative. First, the responses are decisions, not restatements of the problem. Second, the slipped dependency (D-003) carries its escalation history, so the sponsor conversation writes itself.

Score probability and impact from 1 to 5, multiply them, and sort your register by the result. That single number is what stops a log of 60 risks becoming unreadable.

Agree the bands with your sponsor before you need them. Arguing about whether something is "high" during a crisis wastes the only hour that mattered. Pocket PMO applies the bands automatically and sorts the register worst-first, so the top of the page is always the conversation you need to have.

These three terms get used interchangeably, which causes real governance gaps. They are not the same thing.

The gap a risk register alone leaves is assumptions and dependencies — and in our experience those cause more slipped dates than risks do. An unvalidated assumption is simply a risk nobody has agreed to own yet.

Escalation fails when it depends on someone feeling brave. Write the triggers down, and escalation becomes administration rather than confrontation:

• Any risk scoring 15 or above goes to the sponsor within one working day of being raised.
• Any issue open for more than 10 working days without a dated mitigation goes on the board agenda.
• Any dependency whose commitment date slips twice is escalated to the dependency owner's manager.
• Any assumption still unvalidated 30 days before it matters is converted to a risk.
• Any item past its review date for two consecutive weeks is flagged as unmanaged in the status report.

Pocket PMO watches those thresholds for you: Morgan flags breaches, drafts the escalation wording, and waits for your approval before anything is sent. Nothing leaves the system without a person agreeing to it.