Free template
A RAID log is only useful if it changes what people do this week. This free template keeps the four registers simple, forces an owner and a date on every line and separates the risks you can still influence from the issues that have already happened.
By Christopher Fagan, Managing Partner, PEF Consulting Partners
A note before you start
A RAID log tells you very quickly how healthy a programme really is. If it is long, old and nobody can remember the last time a line was closed, the programme is usually in more trouble than the status report says. This version is deliberately plain. Look at it every week, spend the meeting on the actions rather than the scores, and move a risk to the issues tab the day it happens, not the day someone admits it.
Christopher Fagan, Managing Partner, PEF Consulting Partners
Keep one log per programme and review it weekly at the delivery meeting, not monthly at the board. Score risks on likelihood and impact, but spend the meeting on the mitigation column rather than the score. Move a risk to the issues register the day it materialises. Validate assumptions by a date; an assumption with no validation date is a risk in disguise. Dependencies belong to the person who needs them, not the person who provides them.
[Organisation name] | Version 0.1 | [Date] | Owner: [Name, role]
Something that has not happened yet and would hurt the programme if it did.
| ID | Risk (if X happens, then Y) | Cause | Likelihood (1 to 5) | Impact (1 to 5) | Score | Mitigation and contingency | Owner | Status | Review date |
|---|---|---|---|---|---|---|---|---|---|
Something the plan treats as true that has not been confirmed.
| ID | Assumption | Why it matters | How it will be validated | Validate by | Owner | Status |
|---|---|---|---|---|---|---|
Something that has happened and needs resolving.
| ID | Issue | Impact | Priority | Action | Owner | Due | Status |
|---|---|---|---|---|---|---|---|
Something the programme needs from outside itself, or something others need from it.
| ID | Dependency | Direction (we need, they need) | Counterparty | Needed by | Status | Owner |
|---|---|---|---|---|---|---|
Likelihood and impact scored 1 (very low) to 5 (very high). Score of 15 or more is escalated to the sponsor within one working day. Issues with priority high are reviewed daily until closed. Record escalations here.
| Date | Item ID | Escalated to | Decision | Date closed |
|---|---|---|---|---|
Template by PEF Consulting Partners, pefconsultingpartners.co.uk. Free to use and adapt.
Related reading: programme management consultancy, independent programme assurance, the free project health check, the lessons learned template.
A RAID log is a single register of a project’s risks, assumptions, issues and dependencies, with an owner, a status and an action against each entry. It gives the project board one place to see what could go wrong, what is being taken for granted, what has already gone wrong and what the project relies on.
Risks, assumptions, issues and dependencies: the four things a programme tracks that are not tasks. Some teams use actions or decisions for the A and D; the template above uses the original and keeps decisions in the governance minutes.
Weekly at the delivery meeting, with high scoring risks and high priority issues looked at more often. A RAID log reviewed monthly at a steering group is a record, not a management tool.
A risk has not happened yet and can still be reduced or avoided. An issue has happened and has to be dealt with. The day a risk materialises it moves registers, and the mitigation becomes the action.
If your RAID log is long, old and ignored, that is usually a governance problem rather than a template problem, and a short confidential conversation will tell you which.