Glossary
RAID Log
A RAID log is a simple project-management tool that tracks four things in one place: Risks (what might go wrong), Assumptions (what you're taking as true), Issues (what has already gone wrong), and Dependencies (what you're relying on others for). It keeps the sources of drift visible and owned.
A RAID log is one of the most useful low-effort tools in project management. It is a single living list that captures four categories. The acronym is a standard project-management convention, used in structured methods such as PRINCE2 to keep the moving parts of a project visible in one register:
- Risks — things that might go wrong, with a likelihood and an owner.
- Assumptions — things you are currently treating as true. If an assumption turns out to be false, it usually becomes a risk or an issue.
- Issues — things that have already gone wrong and need active management.
- Dependencies — things you are relying on from other people, teams or suppliers, and the dates they're needed by.
Why it works
A RAID log earns its keep because it makes the usual sources of drift visible and assignable. Risks that live only in someone's head don't get managed; dependencies that aren't written down go silent until they bite. Putting all four in one place — each with an owner and a date — turns vague worry into trackable work.
Keeping one usefully
A RAID log is only valuable if it is reviewed on a cadence and each line has a named owner and a next date. A log that nobody opens is just a graveyard of old worries. The discipline is to walk it regularly and ask, for each line, "what's the next step, and who owns it?" — which is the same question that keeps any work under control.
Frequently asked
What does RAID stand for in a RAID log?
What is the difference between a risk and an issue in a RAID log?
How often should you review a RAID log?
Related
What Does It Mean for Work to Be 'Under Control'?
Work is under control when uncertainty has been converted into a usable control point: a clear owner, a dated next step, a decision or escalation date, and a fallback. Control is about predictability, not busyness — a controlled piece of work can still go wrong, but it can no longer surprise you.
TermControl Point
A control point is the unit of being in control: a piece of work that has a clear owner, a dated next step, a decision or escalation date, and a fallback. When uncertainty is converted into a control point, work can still go wrong — but it can no longer drift quietly.
TermCritical Path
The critical path is the longest sequence of dependent tasks that determines the shortest possible time to finish a project. A delay to any task on the critical path delays the whole project; tasks off it have slack. Knowing yours tells you where a slip actually costs you time.
TermManage by Exception
Manage by exception is a control principle, formalised in PRINCE2, where a manager agrees tolerances — the limits within which work can run without sign-off — and is only alerted when a forecast breaches them. It lets senior people delegate the routine and reserve their attention for the genuine exceptions.