The OTR GroupMost projects are undone not by one big surprise but by small things nobody wrote down: an assumption that was never tested, a dependency on another team that nobody owned. A RAID log is a simple way to keep those things visible. This short guide explains the four terms, offers a checklist for keeping the log useful, and shows an example.
What RAID stands for
RAID stands for Risks, Assumptions, Issues and Dependencies. UK government gateway guidance refers to a project's "Risk, Assumptions, Issues and Dependencies (RAID) log" and lists it among the documents a project should have ready for review. The log can hold all four in one document, or the guidance notes it can include a risk register alongside separate issues, dependencies and assumptions registers.
Risks
Something that might happen and, if it does, would affect the project. The Government Functional Standard for project delivery (GovS 002) says risks should be identified, assigned an owner and assessed, "taking into account the impact, likelihood and proximity", then monitored to resolution and closed when no longer valid. (For a step-by-step guide to the risk register itself, see our earlier article.)
Assumptions
Something you are treating as true, without proof, in order to plan. GovS 002 refers to assumptions being documented in a project brief and to forecasts taking "prevailing assumptions and risks" into account. An untested assumption is a risk waiting to happen, so each one needs a way to be checked.
Issues
Something that has already happened and needs managing now. A risk that materialises becomes an issue. GovS 002 says risks and issues an owner cannot resolve "should be escalated or reassigned as necessary".
Dependencies
Something your work relies on from someone or something else, or that others rely on from you. GovS 002 says dependencies between activities and other work components "should be defined", and that they should be minimised so each component is as self-contained as possible.
Checklist: keeping a RAID log useful
- One owner per entry. A named person, not a team or "TBC".
- One log, one place. Everyone should know where it lives and which version is current.
- Write entries as clear sentences. "Supplier delivers cladding late, delaying the envelope" beats "supply chain".
- Add a date and a next action. Every entry needs a "what happens next" and "by when".
- Test assumptions. Record who will confirm each one, and by when.
- Convert, do not delete. When a risk happens, move it to issues and keep the history.
- Name the other party for dependencies. Record what you need, from whom, and the date you need it.
- Review on a rhythm. Put the log on the agenda of your regular project meeting, and close entries that are no longer valid.
- Escalate what you cannot resolve. Do not let stuck items sit.
- Keep it short. A log nobody reads is no use; prune it.
A simple example
| Type | Entry | Owner | Next action | Due |
|---|---|---|---|---|
| Risk | Key approval takes longer than planned, delaying start of works | Project manager | Agree decision date with approver | Next review |
| Assumption | Existing site access is available from week 1 | Site lead | Confirm in writing with site owner | Before mobilisation |
| Issue | Drawings issued with a clash that must be resolved before ordering | Design lead | Hold coordination meeting and reissue | This week |
| Dependency | Our programme needs the utility connection completed by another party | Project manager | Agree completion date and check progress fortnightly | Fortnightly |
The example is illustrative only. Your columns can be fewer or more; what matters is that every line has an owner, a next step and a date.
In short
A RAID log works when it is short, current and owned. If people use it to decide what to do next, it is doing its job.
Sources
- GOV.UK, Gate 2 Review: Delivery Strategy (RAID log definition and related registers)
- Government Project Delivery, Government Functional Standard GovS 002: Project delivery (risks, issues, assumptions and dependencies wording)