methodatlas
Method guideDelivery

RAID Log

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityLow
Time30 min Setup, dann laufend
Participants1-3 maintaining, briefing for everyone
FormatAsync
MaturityCanonical
Plan RAID Log
01

Prerequisite

What needs to be finished first

Complete firstRAID type rules

The team distinguishes possible risks, testable assumptions, occurred issues, and external dependencies.

Without type rules, follow-up becomes wrong or unclear.
Complete firstReview owner

One person owns maintenance, review cadence, and escalation.

Without an owner, the log decays after kickoff.
02

Preparation

What needs to be ready before start

Materials

RAID table with stable IDs, initiative plan, risk register, discovery assumptions, issue list, dependency commitments, and escalation calendar.

People / roles

Delivery lead · scribe · item owners · escalation decision maker

Pre-read

Consolidate existing lists, mark duplicates, and highlight overdue items before review.

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.

03

Core question

The one question this method answers

Which open Risks, Assumptions, Issues, and Dependencies threaten the next commitment, and who will do what by when?

04

Flow

Phases with goal, actions, output and pitfall

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.

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

  1. 1

    Rules

    Define RAID types and required fields

    Goal

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

    Inputs for this step

    • Initiative scope
    • Governance and escalation rules
    • Existing lists

    Actions

    • Distinguish risk, assumption, issue, and dependency with examples.
    • Require ID, description, consequence, owner, action, date, and status.
    • Agree review cadence and escalation thresholds.

    Output

    RAID convention

    Type rules · required fields · status · cadence

    Quality check

    Can every item be assigned to exactly one type?

    Pitfall

    Risks, assumptions, issues, and dependencies are used as interchangeable labels. Apply the type definitions and rewrite every ambiguous item.

    Timing: 10–15 minutes

  2. 2

    Capture

    Write precise entries

    Goal

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

    Inputs for this step

    • Discovery, planning, and delivery findings
    • Risks, open assumptions, current problems
    • External commitments and interfaces

    Actions

    • Write risks as possible events, issues in the present, assumptions as testable claims, and dependencies as required external delivery.
    • Add consequence, source, and affected commitment.
    • Link duplicates instead of copying them.

    Output

    Qualified entries

    ID · type · statement · consequence · source

    Quality check

    Do grammar and follow-up fit the type?

    Pitfall

    Vague entries such as 'API' or 'resources' state neither condition nor consequence. Add subject, condition, date, and affected commitment.

    Timing: 15–20 minutes

  3. 3

    Control

    Assign owner and next action

    Goal

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

    Inputs for this step

    • Qualified entries
    • Responsibilities
    • Decision and escalation paths

    Actions

    • Link a risk to treatment, an assumption to validation, an issue to resolution, and a dependency to delivery evidence.
    • Set an owner and concrete next date.
    • Add status and escalation trigger.

    Output

    Controllable log

    Action · owner · date · status · escalation

    Quality check

    Does each type have the correct follow-up?

    Pitfall

    Owners are named, but next action or date is missing; the log only records stagnation. Add exactly one verifiable next action and date to each open item.

    Timing: 15–20 minutes

  4. 4

    Review

    Review changes and transitions

    Goal

    Maintain the log as the current control source and record transitions traceably.

    Inputs for this step

    • Current RAID log
    • New evidence and delivery status
    • Review decisions

    Actions

    • Review overdue and escalated items first.
    • Confirm, reject, or convert assumptions into risks or issues after testing.
    • Archive closed items with closure evidence.

    Output

    Updated RAID log

    Status · transition · decision · closure evidence

    Quality check

    Is every change dated and justified?

    Pitfall

    Closed items are deleted or assumptions remain unchanged despite counter-evidence. Retain history and log type or status changes with the trigger.

    Timing: 15–30 minutes per review

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

RAID Log · Risks, Assumptions, Issues, DependenciesRisiken, Annahmen, Issues und Abhängigkeiten in einer gepflegten Liste mit Owner, Status und nächster Aktion führen
RAID LogDas Visual zeigt ein RAID Log mit Risiken, Annahmen, Issues, Abhängigkeiten sowie Owner, Status, nächster Aktion und Pflegekadenz.Unsicherheit programmweit an einer Stelle führenRAID bündelt Risiken, Annahmen, Issues und Abhängigkeiten mit Ownern, Status und nächster Aktion für wiederkehrende Reviews.Discovery & Kick-offoffene Punkte zentral übernehmenRAID LogRiskskann eintretenAssumptionsmuss stimmenIssuesist schon daDependencieswartet aufR-07A-03I-12D-05Owner & AktionStatus und nächste Schritte jeZeileWöchentlich pflegenstale Einträge schließen oderneu sortiereneine lebendige Liste statt verstreute NotizenStatusbericht ausderselben QuelleResolved archivieren
Form

Versioned RAID log with status history, transitions, decisions, and closure evidence.

Versioning / ownership

Retain date, author, source state, and decision status for each revision; do not overwrite earlier results.

Tool alternatives
  • Filterable RAID table
  • Linked risk, issue, and delivery tickets
  • Review and escalation calendar

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

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

raid-log-beispiel.md

Concrete filled scenario, fictional example

Fictional example: D-07, Dependency. The payment provider supplies the new sandbox by 24 June. Owner: Partner Manager. Evidence is a successful API health check. If late, release scope is reconsidered on 25 June.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Define RAID types and required fieldsRisks, assumptions, issues, and dependencies are used as interchangeable labels.View in phase
  2. Write precise entriesVague entries such as 'API' or 'resources' state neither condition nor consequence.View in phase
  3. Assign owner and next actionOwners are named, but next action or date is missing; the log only records stagnation.View in phase
  4. Review changes and transitionsClosed items are deleted or assumptions remain unchanged despite counter-evidence.View in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

Every entry follows the method and links to evidence or explicitly marked uncertainty.
The next decision, owner, and review date are visible where required.

Where to go next?

Visual Management workspace showing the question, observations, and next decision.
Operations
Visual Management

Makes the log's top entries visible on the team board for daily steering.

Paper illustration of a review with planned work, actual event sequence, comparison, and assigned improvement actions.
Operations
After-Action Review

Uses closed items and closure evidence as material for an after-action review.

View in playbookSet Up Decision GovernanceMove from decision bottlenecks to roles, rights, escalation paths, and documented decisions.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods