RAID Log
Risks, assumptions, issues and dependencies in one place, each with an owner and a date — the artifact that makes the difference between a surprise and a decision.
Four registers people keep separately and should not. The distinction that matters most is risk versus issue: a risk might happen, an issue already has. Mixing them makes it impossible to tell what needs mitigating from what needs fixing.
The shape
| ID | Type | Description | Impact | Prob | Owner | Response | Due | Status |
|---|---|---|---|---|---|---|---|---|
| R-01 | Risk | Legacy data quality worse than sampled; migration fails validation | High | Med | Data Lead | Full-volume profiling in wave 1, not a sample | 12 Sep | Open |
| R-04 | Risk | Key mainframe SME retires in Q4 | High | High | Programme | Shadowing from Aug; record interface walkthroughs | 30 Aug | Mitigating |
| R-07 | Risk | Partner cannot test EDI before Nov | Med | High | Integration | Build a conformance simulator; contract clause | 20 Sep | Open |
| A-02 | Assumption | Legacy remains available read-only for 30 days post-cutover | — | — | Ops | Validate with infra by 05 Sep — cutover plan depends on it | 05 Sep | Unvalidated |
| A-05 | Assumption | Peak is 4× average, as in last 3 years | — | — | Product | Confirm against this year's forecast | 15 Sep | Validated |
| I-03 | Issue | Test environment unavailable 9 days; wave 2 slipping | High | — | Platform | Ephemeral environments funded; interim shared slot | 08 Sep | In progress |
| I-06 | Issue | Two systems disagree on customer count by 4% | Med | — | Data Lead | Root cause: duplicate merge rule; reconciliation running | 14 Sep | In progress |
| D-01 | Dependency | Network team must deliver the hybrid link | High | — | Network | Committed 30 Sep; blocks wave 2 | 30 Sep | On track |
| D-04 | Dependency | Security sign-off on the landing zone | High | — | Security | Review booked 22 Sep | 22 Sep | At risk |
When you produce it
At programme start, and it is reviewed weekly for the whole programme. A RAID log written once at initiation and never revisited is worse than none, because it gives the appearance of risk management.
Who reads it
The steering committee, weekly. Workstream leads, who own rows. Audit, on a programme that goes wrong — which is a good reason to keep it honest as you go.
What good looks like
- Assumptions have a validation date and an owner. An unvalidated assumption is a risk that has not been written down yet, and this is where most programmes actually fail.
- Risks have a response, not just a score. "High/High, monitor" is not a plan.
- Issues have a resolution date, and slipping dates are visible rather than quietly moved.
- Dependencies name the external party and what they block.
- Closed items stay in the log with their outcome, which is where the lessons are.
Common mistakes
- Conflating risks and issues, so the register cannot be acted on.
- Assumptions never validated, then discovered to be false at cutover.
- Scoring theatre — elaborate probability-impact arithmetic with no corresponding action.
- Owned by "the programme", which means nobody.