Was vorher fertig sein muss
Eine Initiative oder Programm hat einen klaren Auftrag, Stakeholder und Zeitrahmen, sodass Risiken, Annahmen, Issues und Abhängigkeiten überhaupt erkennbar sind.
Was vor Start vorliegen muss
Tabelle oder Datenbank mit Spalten ID, Kategorie (R/A/I/D), Beschreibung, Owner, Status, Datum-erstellt, Datum-zuletzt-aktualisiert, nächste Aktion; Wiki- oder Sheet-Link; Briefing-Template für Statusberichte.
Ein Pflege-Verantwortlicher (PM, RTE oder Programmleitung); Owner pro Eintrag aus relevanten Teams; ein Sponsor als Eskalations-Empfänger; alle Beitragenden mit Schreibrecht.
Initiativen-Charter; Stakeholder-Liste; aktuelle Discovery- oder Kickoff-Notizen; bekannte Risiken, Annahmen, Abhängigkeiten aus Pre-Mortem oder Kickoff.
30 min Setup, danach 15 min pro Woche
Tabelle anlegen, Spalten konfigurieren. Definition pro Kategorie als Header: Risk=Eintreten unsicher, Auswirkung negativ; Assumption=als wahr angenommen, prüfbar; Issue=bereits eingetreten, braucht Aktion; Dependency=externer Input nötig. Status-Werte definieren (Open, In Progress, Resolved, Closed).
Die eine Frage, die diese Methode beantwortet
Welche Risiken, Annahmen, Issues und Abhängigkeiten sind aktuell offen, wer kümmert sich, und welche brauchen jetzt Bewegung oder Eskalation?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Tabelle und Kategorien einrichten | 20 min | Spalten konfigurieren. Definition pro Kategorie schriftlich. Beispiele pro Kategorie aus Initiativen-Kontext. Schreibrechte und Pflege-Verantwortlichkeit festlegen. | Wenn Definitionen verschwimmen, mischen sich Risk und Issue. Klare Trennung: Risk noch nicht eingetreten, Issue schon. Assumption ist Hypothese, Dependency ist externer Input. |
2Phase 2: Initiale Einträge übernehmen | 30-60 min | Aus Kickoff, Pre-Mortem, Risk Storming alle bekannten Einträge übernehmen. Pro Eintrag Owner, Status, nächste Aktion, Frist. Bei externen Abhängigkeiten Empfänger-Team benennen. | Ohne Owner-Zuweisung beim Eintrag verpufft die Übersicht. Lieber Eintrag weglassen als ohne Owner aufnehmen. |
3Phase 3: Wöchentliche Pflege | 15 min pro Woche | Pflege-Verantwortlicher geht Log durch: neue Einträge erfasst, alte aktualisiert, Resolved-Einträge schließen, Stale-Einträge eskalieren. Briefing für Stakeholder generieren. | Fester Slot im Kalender (z. B. Freitag 14:00). Ohne Cadence wird Log Friedhof. Stale-Einträge >4 Wochen explizit ansprechen. |
4Phase 4: Statusbericht-Briefing | 10 min | Aus Log Wochen-Highlights ziehen: neue Top-Risiken, geschlossene Issues, eskalierte Dependencies. Als Statusbericht-Sektion für Sponsor und Stakeholder. | Log ist Quelle, Briefing ist Sicht. Briefing nicht aus Bauchgefühl, sondern aus Log-Inhalt. Stakeholder-Vertrauen wächst, wenn Briefing reproduzierbar ist. |
Was am Ende rauskommt
Tabelle in zentralem Tool mit Spalten ID, Kategorie, Beschreibung, Owner, Status, Datum, nächste Aktion. Resolved-Einträge archiviert, nicht gelöscht. Wöchentliches Briefing als abgeleitete Sicht.
Einträge mit ID und Erstellungsdatum. Änderungen mit Datum im Edit-Log. Resolved-Einträge nach Quartal in Archiv-Tab. Wöchentliche Briefings als Wiki-Seite mit Datum, nicht überschrieben.
Kompakte Arbeitsvorlage für RAID Log mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# RAID Log Arbeitsvorlage
## Ziel
Hält Risiken, Annahmen, Issues und Abhängigkeiten gemeinsam fest.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- RAID Log:
- Statusbericht-Quelle:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## RAID Log - Order-Service-Migration, Stand 2026-05-18
**Risks (5 offen)**
| ID | Beschreibung | Owner | Status | Nächste Aktion | Frist |
|----|--------------|-------|--------|----------------|-------|
| R-12 | DB-Replikation single-leader | @ben | Mitigation | Multi-Leader-Spike | 30.05. |
| R-15 | PSP-Breaking-Change Q3 | @marcus | Owned | Sandbox-Zugang | 31.05. |
| R-17 | Performance bei >1000 Mandanten | @anna | Owned | Monitoring | 22.05. |
**Assumptions (3)**
| ID | Beschreibung | Owner | Status | Nächste Aktion |
|----|--------------|-------|--------|----------------|
| A-04 | Bestehende Parser-Library passt für DATEV-Format | @anna | Open | Spike vor Sprint 24 |
| A-05 | PSP-Sandbox bis Q3 verfügbar | @marcus | Open | Klärung mit PSP |
**Issues (2 offen)**
| ID | Beschreibung | Owner | Status | Nächste Aktion | Frist |
|----|--------------|-------|--------|----------------|-------|
| I-08 | Compliance-Audit-Termin verzögert | @ben | In Progress | Eskalation an Compliance-Lead | 20.05. |
| I-09 | Test-Datensatz für Mandanten-Migration unvollständig | @lisa | Open | Datenanforderung an Sales | 25.05. |
**Dependencies (4)**
| ID | Beschreibung | Owner | Externes Team | Status | ETA |
|----|--------------|-------|---------------|--------|-----|
| D-03 | DATEV-Format-Spezifikation v2 | @anna | DATEV Partner | Pending | 30.05. |
| D-06 | Compliance-Freigabe Multi-Tenant | @ben | Compliance | Pending | 15.06. |
**Wochen-Highlight**: I-08 Compliance-Audit-Termin in Eskalation. R-12 Multi-Leader-Spike läuft planmäßig.Symptome erkennen, gegensteuern
Eintrag „Server fällt aus“ landet als Risk, obwohl er bereits eingetreten ist (Issue).
Klare Definition: Risk = noch nicht eingetreten, Issue = bereits eingetreten. Beim Eintrag prüfen: hat es passiert ja/nein. Sonst werden Folgeaktionen falsch priorisiert.
Log enthält Einträge, die seit 8 Wochen unverändert sind, niemand prüft mehr.
Wöchentliche Review-Cadence. Stale-Einträge (>4 Wochen ohne Update) markieren und eskalieren. Entweder schließen, akzeptieren oder neu in Bewegung bringen.
Owner-Spalte enthält „Team A“ oder „IT“, niemand fühlt sich verantwortlich.
Owner muss namentlich sein. Generische Owner werden ignoriert. Wenn niemand übernehmen will, Eskalation an Sponsor, nicht Eintrag mit Team-Label parken.
Log existiert, wird einmal pro Monat für Steering-Termin gepflegt, sonst leer.
Log ist Steuerinstrument, nicht Berichtsdokument. Wöchentliche Pflege im Programmrhythmus. Wenn Log nur für Steering existiert, anderen Prozess wählen.
Assumptions stehen im Log, niemand prüft sie, später fallen sie als Risk durch.
Pro Assumption Prüfdatum oder Trigger setzen: wann wird sie validiert. Falsifizierte Assumption wird Issue. Validierte wird Resolved.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.