MethodenanleitungDelivery

RAID Log

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätNiedrig

Zeit30 min Setup, dann laufend

Teilnehmende1-3 Pflege, Briefing für alle

FormatAsync

ReifegradCanonical

RAID Log planen

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenRAID-Typregeln

Das Team unterscheidet mögliches Risiko, prüfbare Annahme, eingetretenes Issue und externe Dependency.

Ohne Typregeln werden Folgeschritte falsch oder unklar.

Vorher abschließenReview-Owner

Eine Person verantwortet Pflege, Reviewkadenz und Eskalation.

Ohne Owner veraltet das Log nach dem Kick-off.

Vorbereitung

Was vor Start vorliegen muss

Materialien

RAID-Tabelle mit stabilen IDs, Vorhabensplan, Risikoregister, Annahmen aus Discovery, Issue-Liste, Abhängigkeitszusagen und Eskalationskalender.

Personen / Rollen

Delivery Lead · Scribe · Item Owner · Entscheider bei Eskalationen

Vorabinfos

Bestehende Listen zusammenführen, Dubletten markieren und überfällige Items vor dem Review hervorheben.

Zeitbedarf

45 Minuten initial; 15–30 Minuten pro Review

Setup

Vier Typdefinitionen sowie Pflichtfelder ID, Aussage, Auswirkung, Owner, Aktion, Termin und Status sichtbar platzieren.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche offenen Risks, Assumptions, Issues und Dependencies gefährden die nächste Zusage, und wer tut was bis wann?

Ablauf

Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle

Ein RAID Log hält vier unterschiedliche Steuerungsobjekte zusammen, ohne sie zu vermischen: Risiko ist ein mögliches Ereignis, Annahme eine vorläufige Aussage, Issue ein eingetretenes Problem und Dependency eine externe Vorbedingung. Der Nutzen entsteht im regelmäßigen Review und in typgerechten Folgeschritten.

RAID Log

Fiktives Arbeitsbeispiel

Eine laufende Tabelle mit typgerechten Aussagen und Aktionen.

RAID Log
RAID-ID	Typ	Aussage und Auswirkung	Owner und Termin	Nächste Aktion oder Nachweis	Status und Eskalation
D-07Externe Sandbox	Dependency	Zahlungsdienst stellt neue Sandbox bis 24.06. bereit; ohne sie kein End-to-End-Test.	Partner Manager · 24.06.	Bereitstellung durch erfolgreichen API-Healthcheck nachweisen.	Open; bei Verzug Release-Scope am 25.06. neu entscheiden.

1. Typ
D-07
Dependency
2. Aussage und Auswirkung
D-07
Zahlungsdienst stellt neue Sandbox bis 24.06. bereit; ohne sie kein End-to-End-Test.
3. Owner und Termin
D-07
Partner Manager · 24.06.
4. Nächste Aktion oder Nachweis
D-07
Bereitstellung durch erfolgreichen API-Healthcheck nachweisen.
5. Status und Eskalation
D-07
Open; bei Verzug Release-Scope am 25.06. neu entscheiden.

Jeder Typ hat einen anderen Folgeschritt: behandeln, validieren, lösen oder Lieferung sichern.

UK Government Gate 2 Review: Delivery Strategy

1
Regeln
RAID-Typen und Pflichtfelder festlegen
Ziel
Ein gemeinsames Verständnis der vier Typen und ihrer Folgeschritte schaffen.
Voraussetzungen für diesen Schritt
- Vorhabensscope
- Governance- und Eskalationsregeln
- Bestehende Listen
Durchführung
- Risiko, Annahme, Issue und Dependency mit Beispielen abgrenzen.
- ID, Beschreibung, Auswirkung, Owner, Aktion, Termin und Status als Pflichtfelder definieren.
- Reviewkadenz und Eskalationsschwellen vereinbaren.
Ergebnis
RAID-Konvention
Typregeln · Pflichtfelder · Status · Kadenz
Qualitätscheck
Kann jedes Item eindeutig genau einem Typ zugeordnet werden?
Stolperfalle
Risiken, Annahmen, Issues und Abhängigkeiten werden als austauschbare Labels verwendet. Typdefinitionen mit Beispielen anwenden und jedes unklare Item neu formulieren.
Zeitlicher Rahmen: 10–15 Minuten
2
Erfassen
Einträge präzise aufnehmen
Ziel
Jedes Item mit typgerechter Aussage, Auswirkung und Quelle erfassen.
Voraussetzungen für diesen Schritt
- Discovery-, Planungs- und Deliveryerkenntnisse
- Risiken, offene Annahmen, aktuelle Probleme
- Externe Zusagen und Schnittstellen
Durchführung
- Risiken als mögliches Ereignis, Issues im Präsens, Annahmen als prüfbare Aussage und Dependencies als benötigte externe Leistung formulieren.
- Auswirkung, Quelle und betroffene Zusage ergänzen.
- Dubletten verknüpfen und nicht einfach kopieren.
Ergebnis
Qualifizierte Einträge
ID · Typ · Aussage · Auswirkung · Quelle
Qualitätscheck
Passt Grammatik und Folgeschritt zum Typ?
Stolperfalle
Vage Einträge wie 'API' oder 'Ressourcen' sagen weder Zustand noch Folge aus. Subjekt, Bedingung, Zeitpunkt und betroffene Zusage ergänzen.
Zeitlicher Rahmen: 15–20 Minuten
3
Steuern
Owner und Folgeschritt setzen
Ziel
Jedes offene Item mit passender Aktion, Owner, Termin und Eskalationsregel verbinden.
Voraussetzungen für diesen Schritt
- Qualifizierte Einträge
- Verantwortlichkeiten
- Entscheidungs- und Eskalationswege
Durchführung
- Risiko mit Behandlung, Annahme mit Validierung, Issue mit Lösung und Dependency mit Liefernachweis verbinden.
- Owner und konkreten nächsten Termin festlegen.
- Status und Eskalationsauslöser ergänzen.
Ergebnis
Steuerbares Log
Aktion · Owner · Termin · Status · Eskalation
Qualitätscheck
Hat jeder Typ den richtigen Folgeschritt?
Stolperfalle
Owner sind benannt, aber nächste Aktion oder Termin fehlen; das Log dokumentiert nur Stillstand. Pro offenem Item genau eine nächste überprüfbare Aktion und ein Datum ergänzen.
Zeitlicher Rahmen: 15–20 Minuten
4
Review
Änderungen und Übergänge prüfen
Ziel
Das Log als aktuelle Steuerungsquelle pflegen und Übergänge nachvollziehbar dokumentieren.
Voraussetzungen für diesen Schritt
- Aktuelles RAID Log
- Neue Evidenz und Lieferstände
- Entscheidungen aus Reviews
Durchführung
- Überfällige und eskalierte Items zuerst prüfen.
- Annahme nach Prüfung bestätigen, verwerfen oder in Risiko/Issue überführen.
- Geschlossene Items mit Abschlussnachweis archivieren.
Ergebnis
Aktualisiertes RAID Log
Status · Übergang · Entscheidung · Abschlussnachweis
Qualitätscheck
Ist jede Änderung datiert und begründet?
Stolperfalle
Geschlossene Einträge werden gelöscht oder Annahmen bleiben trotz Gegenbeleg unverändert bestehen. Historie erhalten und Typ- oder Statuswechsel mit Anlass protokollieren.
Zeitlicher Rahmen: 15–30 Minuten je Review

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

RAID Log · Risks, Assumptions, Issues, DependenciesRisiken, Annahmen, Issues und Abhängigkeiten in einer gepflegten Liste mit Owner, Status und nächster Aktion führen

Form

Versioniertes RAID Log mit Statushistorie, Übergängen, Entscheidungen und Abschlussnachweisen.

Versionierung / Ownership

Datum, Autor, Quellenstand und Entscheidungsstatus je Revision erhalten; frühere Ergebnisse nicht überschreiben.

Tool-Alternativen

RAID-Tabelle mit Filter je Typ
Verknüpfte Risiko-, Issue- und Deliverytickets
Review- und Eskalationskalender

raid-log-working-template.md

Plane RAID Log mit realem Scope, passenden Rollen und einem klaren Entscheidungsziel.

RAID Log: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Praxis einrichten und prüfen Zeit: 45 Minuten initial; 15–30 Minuten pro Review

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: RAID-Tabelle mit stabilen IDs, Vorhabensplan, Risikoregister, Annahmen aus Discovery, Issue-Liste, Abhängigkeitszusagen und Eskalationskalender.
Rollen: Delivery Lead · Scribe · Item Owner · Entscheider bei Eskalationen
Vorab-Infos: Bestehende Listen zusammenführen, Dubletten markieren und überfällige Items vor dem Review hervorheben.
Gesamter Zeitbedarf: 45 Minuten initial; 15–30 Minuten pro Review
Setup: Vier Typdefinitionen sowie Pflichtfelder ID, Aussage, Auswirkung, Owner, Aktion, Termin und Status sichtbar platzieren.

Für die Arbeitsschritte bereitstellen

Regeln: RAID-Typen und Pflichtfelder festlegen

Vorhabensscope
Governance- und Eskalationsregeln
Bestehende Listen

Erfassen: Einträge präzise aufnehmen

Discovery-, Planungs- und Deliveryerkenntnisse
Risiken, offene Annahmen, aktuelle Probleme
Externe Zusagen und Schnittstellen

Steuern: Owner und Folgeschritt setzen

Qualifizierte Einträge
Verantwortlichkeiten
Entscheidungs- und Eskalationswege

Review: Änderungen und Übergänge prüfen

Aktuelles RAID Log
Neue Evidenz und Lieferstände
Entscheidungen aus Reviews

RAID Log

RAID-ID	R/A/I/D	Aussage · Auswirkung	Owner · Datum	Aktion · Nachweis	Status · Trigger
D-07

D-07: Externe Sandbox

Pro Eintrag genau einen Typ wählen und einen prüfbaren nächsten Schritt setzen.

UK Government Gate 2 Review: Delivery Strategy

Regeln: RAID-Typen und Pflichtfelder festlegen

Erwartetes Artefakt: RAID-Konvention

Typregeln · Pflichtfelder · Status · Kadenz

Eintrag:

...

Kann jedes Item eindeutig genau einem Typ zugeordnet werden?

Erfassen: Einträge präzise aufnehmen

Erwartetes Artefakt: Qualifizierte Einträge

ID · Typ · Aussage · Auswirkung · Quelle

Eintrag:

...

Passt Grammatik und Folgeschritt zum Typ?

Steuern: Owner und Folgeschritt setzen

Erwartetes Artefakt: Steuerbares Log

Aktion · Owner · Termin · Status · Eskalation

Eintrag:

...

Hat jeder Typ den richtigen Folgeschritt?

Review: Änderungen und Übergänge prüfen

Erwartetes Artefakt: Aktualisiertes RAID Log

Status · Übergang · Entscheidung · Abschlussnachweis

Eintrag:

...

Ist jede Änderung datiert und begründet?

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/raid-log/run-sheet

Beispielausgabe

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.

raid-log-beispiel.md

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel: D-07, Dependency. Der Zahlungsdienst stellt die neue Sandbox bis 24.06. bereit. Owner Partner Manager; Nachweis ist ein erfolgreicher API-Healthcheck. Bei Verzug wird das Release-Scope am 25.06. neu entschieden.

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

RAID-Typen und Pflichtfelder festlegenRisiken, Annahmen, Issues und Abhängigkeiten werden als austauschbare Labels verwendet.In der Phase ansehen
Einträge präzise aufnehmenVage Einträge wie 'API' oder 'Ressourcen' sagen weder Zustand noch Folge aus.In der Phase ansehen
Owner und Folgeschritt setzenOwner sind benannt, aber nächste Aktion oder Termin fehlen; das Log dokumentiert nur Stillstand.In der Phase ansehen
Änderungen und Übergänge prüfenGeschlossene Einträge werden gelöscht oder Annahmen bleiben trotz Gegenbeleg unverändert bestehen.In der Phase ansehen