methodatlas

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.

Core question
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.

Paper illustration of RAID Log with a method-specific labelled workspace.
  1. Rules

    Define RAID types and required fields

    Create a shared understanding of the four types and their follow-up.

  2. Capture

    Write precise entries

    Record every item with a type-specific statement, consequence, and source.

  3. Control

    Assign owner and next action

    Connect every open item to the right action, owner, date, and escalation rule.

  4. 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 Log
RAID IDTypeStatement and consequenceOwner and dateNext action or evidenceStatus and escalation
D-07External sandboxDependencyPayment provider supplies the new sandbox by 24 June; without it, no end-to-end test.Partner Manager · 24 JuneProve delivery with a successful API health check.Open; if late, reconsider release scope on 25 June.
  1. 1. Type

    D-07
    Dependency
  2. 2. Statement and consequence

    D-07
    Payment provider supplies the new sandbox by 24 June; without it, no end-to-end test.
  3. 3. Owner and date

    D-07
    Partner Manager · 24 June
  4. 4. Next action or evidence

    D-07
    Prove delivery with a successful API health check.
  5. 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.

UK Government Gate 2 Review: Delivery Strategy

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?

Open the method guide

Deep dive

Purpose

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.

How it works

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.

In detail

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.

Facilitation

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 guide

Your perspective

Does this method help with your work?

Your feedback helps shape the next improvements to methodatlas.

Sources and topics

Topics
Artifact templates
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 IDR/A/I/DStatement · consequenceOwner · dateAction · evidenceStatus · 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.

All methods
Constraints and origin
LowAsync30 min Setup, dann laufend

Profile

Method form
Planning tool
Participants
1-3 maintaining, briefing for everyone
Time
30 min Setup, dann laufend
Maturity
Canonical
Origin
Project Management Community
Visual Management workspace showing the question, observations, and next decision.
Next up: Visual Management