How Do You Run a RAID Log That Delivery Teams Actually Use?

A RAID log is a single register that captures the four things most likely to knock a project off course: **R**isks, **A**ssumptions, **I**ssues and **D**ependencies. Each entry records what it is, who owns it, what is being done about it and its current status. The purpose is not documentation for its own sake; it is to surface uncertainty early so the team and its governance can act before problems become expensive. A good RAID log is the working memory of a delivery; a bad one is a spreadsheet nobody opens after week three.

## What each letter really means

Teams often blur the categories, which weakens the log. Keep the definitions crisp:

- **Risk:** Something that might happen and would have an impact if it did. Risks are about the future and are managed by reducing likelihood or impact.

- **Assumption:** Something you are treating as true in order to plan, but which is not yet confirmed. Assumptions are management debt; each one should have a plan to validate it.

- **Issue:** Something that has already happened or is happening now and needs resolving. An issue is a risk that materialised, or a problem discovered in delivery.

- **Dependency:** Something you need from someone else, or something they need from you, by a certain date for the plan to hold.

The discipline of placing an item in the right category changes what you do with it. A risk needs mitigation; an issue needs resolution; an assumption needs validation; a dependency needs coordination.

## Fields that make a log usable

A RAID log with too many columns is abandoned; one with too few is useless. Aim for the minimum that supports a decision:

1. **Unique ID** so items can be referenced in meetings and reports.

2. **Clear description** written as a cause-and-effect statement, for example "Because the data migration window is unconfirmed, there is a risk we miss the cutover date."

3. **Owner** — a named person, never a team or "TBC".

4. **Impact and likelihood** (for risks) on a simple, consistent scale.

5. **Response and next action** with a date.

6. **Status and review date** so stale items are obvious.

## How to keep it alive

The failure mode is always the same: the log is created with great enthusiasm, then ossifies. To prevent that:

- **Review it in the rhythm of delivery.** RAID review should be a standing part of the weekly delivery meeting, not a quarterly clean-up. Five minutes on the top items beats an hour once a quarter.

- **Close things visibly.** A log that only grows is demoralising. Mark issues resolved and risks closed; this shows the log is working.

- **Escalate by exception.** The top few risks and any blocking dependencies should feed your status report and your governance pack automatically, not be re-typed.

- **Quantify where you can.** "High" is subjective. A rough cost or time impact makes prioritisation and escalation far easier.

- **Distinguish ownership from action.** The owner is accountable for the item; the next action may sit with someone else. Make both visible.

## Connecting RAID across the portfolio

At programme and portfolio level, a single project's RAID log is not enough. Dependencies in particular are inherently cross-project: one team's deliverable is another team's prerequisite. When RAID lives in disconnected spreadsheets, these cross-cutting dependencies fall through the gaps, and the same systemic risk appears in five separate logs with no one seeing the pattern.

The value of a connected delivery platform is that risks, issues and dependencies can be linked to the objectives, requirements and milestones they affect, and rolled up so a PMO can see aggregate exposure. Enterprise tooling such as that built by neart.ai is designed to preserve this thread, so a dependency logged by a delivery team is visible to the programme and to governance without manual re-keying.

## Signs your RAID log is failing

- Items have no owner, or the same person owns everything.

- Nothing has been closed in weeks.

- The log used in governance differs from the one the team uses.

- Risks are vague ("resourcing") rather than specific cause-effect statements.

- Dependencies are tracked only inside individual teams, never across them.

## Practical takeaway

Keep your RAID categories crisp, write entries as cause-and-effect statements with a named owner and a dated next action, and review the top items in your normal delivery rhythm rather than as a periodic clean-up. Close items visibly, escalate by exception, and wherever possible link risks, issues and dependencies to the objectives and milestones they threaten so the whole programme can see the pattern, not just the symptom.