Helps clarify scope, sequence, and delivery flow in concrete terms. It makes work, boundaries, and order steerable. The result is captured as a RAID Log and a source for status reporting.
Delivery Planning tool
RAID Log
Manages Risks, Assumptions, Issues, and Dependencies in one living control source with clear type rules, owners, and actions.
A RAID Log combines four different control objects without confusing them: a risk is a possible event, an assumption is a provisional claim, an issue has already occurred, and a dependency is an external prerequisite. Its value comes from regular review and type-specific follow-up.
Which open Risks, Assumptions, Issues, and Dependencies threaten the next commitment, and who will do what by when?
- Participants
- 1-3 maintaining, briefing for everyone
- Time
- 30 min Setup, dann laufend
Risk, assumption, issue, and dependency use different grammar, transitions, and follow-up actions.

Rules
Define RAID types and required fields
Create a shared understanding of the four types and their follow-up.
Capture
Write precise entries
Record every item with a type-specific statement, consequence, and source.
Control
Assign owner and next action
Connect every open item to the right action, owner, date, and escalation rule.
Review
Review changes and transitions
Maintain the log as the current control source and record transitions traceably.
Update at least weekly and before gates; retain type transitions, status changes, and decisions.
A good fit when
Useful for multi-team initiatives with external dependencies and governance reviews. Detailed causal analysis and full risk management need additional artefacts.
Ideal for
- Program or multi-team initiatives
- Compliance projects
- Handovers to clients
Not good for
- Fast discovery sprints
- Pure engineering backlogs
Outputs

Current RAID log
Typed items with consequence, source, status, owner, and next action.

Escalation and transition trail
Overdue items, type changes, decisions, and closure evidence with dates.
RAID Log
Fictional worked example
A living table with type-specific statements and actions.
| RAID ID | Type | Statement and consequence | Owner and date | Next action or evidence | Status and escalation |
|---|---|---|---|---|---|
| D-07External sandbox | Dependency | Payment provider supplies the new sandbox by 24 June; without it, no end-to-end test. | Partner Manager · 24 June | Prove delivery with a successful API health check. | Open; if late, reconsider release scope on 25 June. |
1. Type
- D-07
- Dependency
2. Statement and consequence
- D-07
- Payment provider supplies the new sandbox by 24 June; without it, no end-to-end test.
3. Owner and date
- D-07
- Partner Manager · 24 June
4. Next action or evidence
- D-07
- Prove delivery with a successful API health check.
5. Status and escalation
- D-07
- Open; if late, reconsider release scope on 25 June.
Each type has a different follow-up: treat, validate, resolve, or secure delivery.
First step
Start with the core question: Which open Risks, Assumptions, Issues, and Dependencies threaten the next commitment, and who will do what by when?
Good to do first
Deep dive
Every entry carries an owner, a status, and a next move so that nothing is merely documented but also tracked. Ongoing maintenance keeps the picture current and creates a reliable source for reviews, escalations, and stakeholder updates.
The RAID Log is a project management classic that combines risks, assumptions, open issues, and dependencies in one living list. Each entry gets an owner, status, date, and next step. It works well as an asynchronous backbone artifact and briefing source for stakeholders.
Set aside a fixed 15-minute slot once a week to keep it current. Close stale items decisively or move them to a different category.
The method guide walks execution through 4 phases, timing, 4 pitfalls, and clear stop criteria.
Open method guideYour perspective
Does this method help with your work?
Your feedback helps shape the next improvements to methodatlas.
Sources and topics
RAID Log: WorksheetPlan RAID Log with real scope, suitable roles, and a clear decision objective.markdown
raid-log-working-template.md
Plan RAID Log with real scope, suitable roles, and a clear decision objective.
RAID Log: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Establish and review the practice Time: 45 minutes initially; 15–30 minutes per review
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: RAID table with stable IDs, initiative plan, risk register, discovery assumptions, issue list, dependency commitments, and escalation calendar.
- Roles: Delivery lead · scribe · item owners · escalation decision maker
- Advance information: Consolidate existing lists, mark duplicates, and highlight overdue items before review.
- Overall time needed: 45 minutes initially; 15–30 minutes per review
- Setup: Display four type definitions and required fields: ID, statement, consequence, owner, action, date, and status.
Prepare for the work steps
Rules: Define RAID types and required fields
- Initiative scope
- Governance and escalation rules
- Existing lists
Capture: Write precise entries
- Discovery, planning, and delivery findings
- Risks, open assumptions, current problems
- External commitments and interfaces
Control: Assign owner and next action
- Qualified entries
- Responsibilities
- Decision and escalation paths
Review: Review changes and transitions
- Current RAID log
- New evidence and delivery status
- Review decisions
RAID Log
| RAID ID | R/A/I/D | Statement · consequence | Owner · date | Action · evidence | Status · trigger |
|---|---|---|---|---|---|
| D-07 |
- D-07: External sandbox
Choose exactly one type per item and set a verifiable next step.
UK Government Gate 2 Review: Delivery Strategy
Rules: Define RAID types and required fields
Expected artifact: RAID convention
Type rules · required fields · status · cadence
Entry:
...
- Can every item be assigned to exactly one type?
Capture: Write precise entries
Expected artifact: Qualified entries
ID · type · statement · consequence · source
Entry:
...
- Do grammar and follow-up fit the type?
Control: Assign owner and next action
Expected artifact: Controllable log
Action · owner · date · status · escalation
Entry:
...
- Does each type have the correct follow-up?
Review: Review changes and transitions
Expected artifact: Updated RAID log
Status · transition · decision · closure evidence
Entry:
...
- Is every change dated and justified?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/raid-log/run-sheet
Alternatives and neighbors
Fitting alternatives with decision guidance, followed by other related methods.

Instead of RAID Log, choose ROAM Board when you want to discuss risks together and only need a living status of actions.

Defines audiences, channels, frequencies, and owners so relevant information reliably gets through.

Moves group input, selection, and decision toward a concrete result through "prepare the stakeholder list", "define power, legitimacy, and urgency", and "derive strategy by class".

Prioritizes requirements across must, should, could, and won't, creating a negotiable release set with clear boundaries.

Moves group input, selection, and decision toward a concrete result through "collect stakeholders individually and by group", "explain power and interest", and "derive a strategy for each quadrant".

Clarifies responsibility for tasks and deliverables, exposes gaps or overload, and improves alignment.
Constraints and origin
Profile
- Method form
- Planning tool
- Participants
- 1-3 maintaining, briefing for everyone
- Time
- 30 min Setup, dann laufend
- Maturity
- Canonical
- Origin
- Project Management Community


