Was vorher fertig sein muss
Eine konkrete Initiative, ein Projekt oder ein Launch mit Scope, Zeitrahmen und Erfolgskriterium ist beschrieben.
Team-Kultur erlaubt das Aussprechen unbequemer Wahrheiten, ohne dass Sponsoren oder Senior-Stimmen abweichende Sichten unterdrücken.
Was vor Start vorliegen muss
Whiteboard oder digitales Board (Miro, FigJam); Stickies in einer Farbe für Risiken, zweite Farbe für Mitigations; Marker; Timer; sichtbares Szenario („Es ist 6 Monate später, die Initiative ist krachend gescheitert“).
Ein Facilitator; 4-10 Teilnehmer aus Projekt-Team, gemischte Funktionen und Erfahrungen; optional ein Note-Taker; idealerweise ein neutrales externes Mitglied (Devil's Advocate).
Initiative-Beschreibung; bekannte Risiken bisher; erfahrungen aus ähnlichen Projekten; Zeitrahmen und Scope; Stakeholder-Erwartungen.
20-45 min
Szenario-Satz oben: „Stell dir vor, es ist [Zieldatum + 3 Monate]. Die Initiative ist gescheitert. Warum?“ Stickie-Zonen für „Gründe des Scheiterns“ und „Mitigation“. Timer auf 30 min.
Die eine Frage, die diese Methode beantwortet
Welche Gründe könnten dazu führen, dass die Initiative scheitert, und welche Mitigations können wir jetzt einbauen, um diese Risiken zu reduzieren?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Szenario aufrufen | 5 min | Sponsor oder Facilitator beschreibt Initiative kurz, dann Szenario-Satz: „Es ist [X Monate später], die Initiative ist gescheitert.“ Pause für 30 Sek zur Visualisierung. | Wer das Szenario nicht ernst nimmt („wird schon klappen“), liefert keine echten Risiken. Facilitator setzt Tonalität: ernsthaftes Gedankenexperiment, kein Pessimismus. |
2Phase 2: Solo-Schreiben der Risiken | 5-10 min | Jede Person schreibt still 3-5 Gründe für das Scheitern auf Stickies. Konkret formuliert („Stripe-Integration scheitert an 3DS2-Compliance“), nicht generisch („Tech-Probleme“). | Solo-Start vermeidet Gruppendenken. Lauteste Stimmen würden sonst Risiken bestimmen. Stille erzwingt Diversität. |
3Phase 3: Sammeln und Clustern | 10-15 min | Stickies an Wand. Pro Stickie kurze Beschreibung durch Verfasser. Ähnliches clustern. Duplikate konsolidieren. Cluster nach Kategorie (Tech, People, Process, Market, External). | Clustern zeigt Risiko-Schwerpunkte. Wenn alle Stickies in einer Kategorie landen (z. B. nur Tech), fehlen wahrscheinlich andere Perspektiven. |
4Phase 4: Wahrscheinlichkeit und Impact bewerten | 5-10 min | Pro Cluster oder Top-Risiken Wahrscheinlichkeit (niedrig / mittel / hoch) und Impact (gering / moderat / kritisch) bewerten. Top-5 markieren (hohe Wahrscheinlichkeit × hoher Impact). | Risiken mit niedriger Wahrscheinlichkeit aber kritischem Impact (Tail-Risk) nicht ignorieren. Show-Stopper, auch wenn unwahrscheinlich. |
5Phase 5: Mitigation pro Top-Risiko | 10-15 min | Pro Top-5-Risiko konkrete Mitigation (Aktion, die Wahrscheinlichkeit oder Impact reduziert). Owner und Termin pro Mitigation. Mitigation in Projektplan integrieren. | Mitigation muss konkret und zugeordnet sein. „Mehr Tests“ ist keine Mitigation. „Stripe-Integration als Spike vor Sprint 1, Owner @ben, KW 22“ ist eine. |
Was am Ende rauskommt
Risiko-Liste mit kategorisierten Risiken (Tech, People, Process, Market, External), Wahrscheinlichkeit, Impact und priorisierten Top-Risiken; plus Mitigation-Plan mit Owner, Termin und Integration in Projektplan; Assumption Log für unklare Annahmen.
Pre-Mortem zu Start einer Initiative, plus optional in Halbzeit als Refresh. Risiko-Status (offen, mitigiert, eingetreten, verworfen) über Lebenszeit tracken. Nach Initiative-Ende Post-Mortem-Vergleich mit Pre-Mortem-Vorhersagen für Lernen.
Kompakte Arbeitsvorlage für Pre-Mortem mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Pre-Mortem Arbeitsvorlage
## Ziel
Stellt sich ein zukünftiges Scheitern vor, um Risiken vorab zu erkennen.
## 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
- Risk List:
- Mitigation Plan:
- Assumption Log:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Pre-Mortem — Checkout v2 Launch (Q3 2026, KW 19)
**Initiative**: Neuer Checkout-Flow inkl. 3DS2-Compliance, Apple Pay, Inline-Validierung. Launch geplant 15.07.2026.
**Szenario**: „Es ist 15.10.2026. Der Launch ist gescheitert. Conversion ist um 15% gesunken, Compliance-Audit hat Lücken gefunden, Team ist demotiviert. Warum?“
### Risiko-Cluster
**Tech (8 Stickies)**
- 3DS2-Implementierung war komplexer als erwartet, Tests in Sandbox fehlten ⚠️ HOCH/KRITISCH
- Apple Pay funktioniert nicht auf älteren iOS-Versionen, 12% Traffic-Verlust ⚠️ MITTEL/MODERAT
- Performance-Regression im neuen Flow nicht erkannt, Page-Load 800ms statt 300ms ⚠️ MITTEL/KRITISCH
**People (3 Stickies)**
- Hauptentwickler @ben war 2 Wochen krank, Übergabe fehlte
- Designer-Engineering-Mismatch, Inline-Validierung-Spec war unklar
**Process (4 Stickies)**
- Migration der laufenden Orders nicht im Plan, Cleanup nach Launch chaotisch
- Stakeholder-Sign-off war pro forma, kein echtes Testing durch Sales
**Market/External (3 Stickies)**
- Stripe änderte 3DS2-API kurzfristig, Re-Work nötig
- Konkurrent launchte ähnliches Feature 1 Woche vorher, Differenzierung weg
### Top-5 Risiken (priorisiert)
1. **3DS2-Komplexität** (HOCH/KRITISCH) - Mitigation: Sandbox-Test-Spike vor Sprint 1, Owner: @ben, KW 22
2. **Performance-Regression** (MITTEL/KRITISCH) - Mitigation: Lighthouse-CI pro PR, Owner: @anna, KW 21
3. **Migration-Plan** (MITTEL/MODERAT) - Mitigation: Migration-Skript-Spike, Owner: @lisa, KW 23
4. **Stripe-API-Änderungen** (MITTEL/MODERAT) - Mitigation: Monthly Stripe-Roadmap-Check, Owner: @ben, ongoing
5. **Stakeholder-Sign-off-Pseudo** (MITTEL/MODERAT) - Mitigation: UAT-Phase mit echtem Sales-Test, Owner: @marcus, KW 26Symptome erkennen, gegensteuern
Risiken werden weichgespült, „wird schon klappen“, geschönte Liste.
Szenario-Setup ernsthaft. Facilitator fordert: „Was würde XYZ-Konkurrent oder Sicherheits-Audit kritisieren?“ Optimismus ist Pre-Mortem-Killer.
Junior-Teammitglieder schweigen, weil Sponsor abweichende Sicht abtut.
Sponsor verlässt Raum während Solo-Schreiben. Anonyme Stickies-Sammlung. Facilitator gewichtet alle Stimmen gleich.
„Technische Probleme“, „Team-Konflikte“ ohne Spezifik.
Konkretisierung erzwingen: was genau geht schief, wie zeigt es sich, woran erkennbar? Sonst keine Mitigation ableitbar.
Mitigations sind formuliert, niemand übernimmt Verantwortung.
Pro Mitigation Owner und Termin Pflicht. Ohne Owner ist Mitigation Wunschdenken. Im Projektplan oder Backlog dokumentieren.
Pre-Mortem wird durchgeführt, Ergebnisse landen im Wiki, keine Integration in Projektplan.
Mitigations werden Sprint-Items oder Spikes. Top-Risiken im Weekly-Status sichtbar. Sonst war Pre-Mortem Beschäftigung.
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.