Entscheidungsmethode
Premortem-Analyse für Teams
Stelle dir vor, dein Projekt ist gescheitert. Arbeite rückwärts, um die Gründe zu finden, bevor sie eintreten. Die wirksamste Technik zur Risikoprävention.
Zuletzt aktualisiert: April 2026
Was ist eine Premortem-Analyse?
Die Premortem-Analyse ist eine Technik des Psychologen Gary Klein, die die traditionelle Risikobewertung auf den Kopf stellt. Statt zu fragen "Was könnte schiefgehen?" gehst du davon aus, dass das Projekt bereits komplett gescheitert ist, und fragst "Was hat das verursacht?" Dieser Wechsel von Möglichkeit zu Gewissheit verändert, wie das Gehirn Risiken verarbeitet. Menschen, die sich ein Scheitern als bereits eingetreten vorstellen, sind 30% besser darin, dessen Ursachen zu identifizieren, als solche, die spekulieren, was schiefgehen könnte.
Premortems funktionieren aus psychologischen, nicht analytischen Gründen. Traditionelles Risiko-Brainstorming hat zwei Probleme: Optimismus-Bias (Teams unterschätzen Risiken, weil sie in den Plan investiert sind) und sozialer Druck (niemand will die Person sein, die "die Stimmung verdirbt" indem sie Probleme anspricht). Das Premortem eliminiert beides. Indem erklärt wird, das Projekt sei bereits gescheitert, ist Optimismus irrelevant. Und weil alle aufgefordert werden, das Scheitern zu erklären, wird das Äußern von Bedenken zur Aufgabe, nicht zur Ausnahme.
Das Ergebnis ist eine priorisierte Liste von Fehlerszenarien mit Wahrscheinlichkeits- und Auswirkungsbewertungen, plus konkreten Gegenmaßnahmen, die bestimmten Personen mit Fristen zugewiesen sind. Das macht Premortems deutlich handlungsrelevanter als Standard-Risikoregister, die dazu neigen, Risiken ohne Ownership oder Zeitplan aufzulisten. Die Methode wird in Projektmanagement, Produktentwicklung, Militärplanung und Gesundheitswesen eingesetzt. Gary Klein publizierte den Ansatz 2007 in seinem Artikel "Performing a Project Premortem" in der Harvard Business Review.
Wann ein Premortem durchführen?
- Zu Projektbeginn, bevor Ressourcen gebunden werden, wenn noch Zeit und Budget da ist, Fehler zu verhindern
- Vor größeren Produkt-Launches oder Feature-Releases, wo Scheitern teuer und öffentlich sichtbar ist
- Beim Start neuer Geschäftsinitiativen, Partnerschaften oder Markteintritte mit hoher Unsicherheit
- Vor bedeutenden organisatorischen Veränderungen wie Umstrukturierung, Fusionen oder Prozessumstellungen
- Immer wenn ein Team zu zuversichtlich bei einem Plan ist und niemand auch nur ein Bedenken geäußert hat
- Um Projekt-Risiken vorher zu erkennen, solange Prävention noch billiger ist als Reaktion
Schritt-für-Schritt-Anleitung
- 1
Ausgangslage festlegen
Das Projekt, seine Ziele, den Zeitplan und das Erfolgsbild beschreiben. Dann die Prämisse klar verkünden: "Stellt euch vor, es ist 6 Monate später. Dieses Projekt ist gescheitert. Kein kleiner Rückschlag. Keine Verzögerung. Ein totaler Fehlschlag. Das Produkt wurde nicht gelauncht. Die Partnerschaft wurde aufgelöst. Die Migration wurde zurückgerollt. Was ist passiert?" Die Wortwahl zählt. "Totaler Fehlschlag" entfernt die Ausrede "kleines Problem" und zwingt das Team, über katastrophale Szenarien nachzudenken.
- 2
Unabhängig brainstormen
Jedes Teammitglied schreibt still alle möglichen Gründe für das Scheitern auf. 5-10 Minuten stille Schreibzeit geben. Alle Perspektiven abdecken: Personen (Schlüsselperson geht, Teamkonflikt), Prozess (Scope Creep, unklare Anforderungen), Technologie (Integration scheitert, Performance-Probleme), Markt (Wettbewerber launcht zuerst, Nachfrage sinkt), Timing (regulatorische Verzögerung, Abhängigkeiten rutschen) und Politik (Sponsor verliert Interesse, Budget wird gekürzt). Kein Filtern. Auch unwahrscheinliche Szenarien. Das Ziel ist Menge.
- 3
Teilen und zusammenführen
Reihum geht es. Jede Person teilt pro Runde einen Fehlergrund. Der Moderator erfasst alles auf einem geteilten Board, ohne Bewertung oder Diskussion. Weiter, bis alle Gründe aufgelistet sind. Duplikate zusammenführen. Ähnliche gruppieren. Eine typische Sitzung mit 6-8 Personen ergibt 15-25 einzigartige Fehlergründe. Die Gründe, die mehrere Personen unabhängig aufgeschrieben haben, sind oft die wichtigsten.
- 4
Wahrscheinlichkeit und Auswirkung bewerten
Für jeden Fehlergrund bewertet das Team Wahrscheinlichkeit (1-5: wie wahrscheinlich?) und Auswirkung (1-5: wie schlimm wäre es?). W x A ergibt den Risikowert (1-25). Nach höchstem Wert sortieren. Die Top 5-7 Risiken bekommen die Aufmerksamkeit. Die Bewertung enthüllt etwas Wichtiges: Ein Risiko mit niedriger Wahrscheinlichkeit und hoher Auswirkung (wie "Schlüsselingenieur geht mitten im Projekt") kann höher scoren als eins mit hoher Wahrscheinlichkeit und niedriger Auswirkung (wie "Zeitplan rutscht um 2 Wochen"). Ohne Bewertung fokussieren Teams auf das, was wahrscheinlich erscheint, und ignorieren, was katastrophal wäre.
- 5
Aktionsplan erstellen
Für die Top 3-5 Risiken konkrete Gegenmaßnahmen definieren. Nicht "Risiko beobachten" sondern "Lisa schult Marco bis 15. März auf der Datenpipeline ein, damit wir Backup haben, falls eine Person ausfällt." Jede Maßnahme braucht: Wer ist verantwortlich, was wird getan, bis wann, und woran erkennt man den Erfolg. Das verwandelt abstrakte Sorgen in einen finanzierten, zugewiesenen Präventionsplan. Ein Follow-up-Premortem zur Projektmitte einplanen, um neue Risiken zu erfassen.
Praxis-Tipp: Teammitglieder 5-10 Minuten unabhängig brainstormen lassen, bevor jemand spricht. Die stille Schreibphase ist der eigentliche Wertschöpfungsmoment. Sobald jemand "Scope Creep" laut sagt, verankern sich alle auf Prozessrisiken und hören auf, über Personal-, Markt- oder politische Risiken nachzudenken. Unabhängiges Brainstorming produziert 3x mehr einzigartige Fehlergründe als Gruppendiskussion.
Praxis-Tipp: Wilde Ideen ermutigen. "Der CEO wird verhaftet" klingt absurd, deckt aber Schlüsselpersonen-Abhängigkeit auf. "Unser Büro brennt ab" deckt Disaster-Recovery-Lücken auf. Extreme Szenarien enthüllen oft reale Schwachstellen, die moderat klingende Risiken verbergen.
Praxis-Tipp: Niedrig-wahrscheinliche Punkte nicht zu schnell aussortieren. Black-Swan-Ereignisse sind einzeln unwahrscheinlich, aber in Summe häufig. Ein Projekt mit 20 Risiken bei je 5% Wahrscheinlichkeit hat eine 64%-Chance, dass mindestens eines eintritt. Das Premortem soll sie identifizieren; die Bewertungsphase entscheidet, welche Ressourcen bekommen.
Praxis-Tipp: Ein Follow-up-Premortem zur Projektmitte einplanen. Risiken ändern sich im Projektverlauf. Das Technologierisiko, das du in Monat eins abgemildert hast, wird vielleicht durch ein Marktrisiko ersetzt, das beim Kickoff nicht sichtbar war. Ein 30-Minuten-Refresh zur Projektmitte ist mehr wert als eine 2-Stunden-Sitzung am Anfang, die nie wiederholt wird.
Beispiel
Ein Team identifizierte diese Fehlerursachen für einen geplanten Produkt-Launch:
| Fehlerursache | W | A | Score |
|---|---|---|---|
| Lieferkettenverzögerungen | 4 | 4 | 16 |
| Falsches Markttiming | 3 | 5 | 15 |
| Ressourcenkonflikte | 4 | 3 | 12 |
| Budget unterschätzt | 3 | 4 | 12 |
| Wettbewerber ist schneller | 2 | 5 | 10 |
| Schlüsselperson geht | 2 | 4 | 8 |
Praxisbeispiel
Risiko #2 (Datenpipeline, Score 16): Jan führt Lasttests mit Produktionsdaten bis Woche 3 durch, bevor UI-Arbeit beginnt. Bei Performance unter Schwellenwert: Architektur-Review in Woche 4. Entscheidung: Pipeline reparieren oder Datenumfang reduzieren.
| # | Fehlerursache | W | A | Score | Kategorie |
|---|---|---|---|---|---|
| 1 | Schlüsselingenieur geht in der Crunch-Phase | 2 | 5 | 10 | Personal |
| 2 | Datenpipeline-Performance zu langsam | 4 | 4 | 16 | Technologie |
| 3 | Scope wächst nach Kickoff weiter | 4 | 3 | 12 | Prozess |
| 4 | Wettbewerber launcht ähnliches Feature | 3 | 4 | 12 | Markt |
| 5 | QA findet kritische Bugs 2 Wochen vor Launch | 3 | 4 | 12 | Technologie |
| 6 | Vertrieb überverspricht Funktionalität | 3 | 3 | 9 | Personal |
| 7 | Legal-Review verzögert API-Partnerschaft | 2 | 4 | 8 | Prozess |
| 8 | CEO fordert Designänderungen | 3 | 2 | 6 | Politik |
Das Team identifizierte 'Schlüsselingenieur geht während der Crunchphase' als Risiko #1 (Wahrscheinlichkeit 2, Auswirkung 5, Score 10). Das überraschte alle, weil Mitarbeiterbindung nicht auf dem Projekt-Risikoradar war. Der CEO hatte angenommen, das Team sei stabil. Das Premortem zwang jemanden, laut auszusprechen, worüber sich alle insgeheim Sorgen machten. Die Maßnahme war konkret: zwei Backup-Ingenieure auf den kritischen Pfadkomponenten einarbeiten, bevor das Projekt in die intensive Phase eintritt.
Premortem-Analyse vs. Risikomatrix
| Dimension | Premortem-Analyse | Risikomatrix |
|---|---|---|
| Zweck | Risiken entdecken, an die noch niemand gedacht hat | Bekannte Risiken quantifizieren und priorisieren |
| Ausgangspunkt | "Das Projekt ist gescheitert. Was hat es verursacht?" | "Welche Risiken kennen wir?" |
| Hauptstärke | Eliminiert Optimismus-Bias, deckt versteckte Risiken auf | Strukturierte Bewertung, visuelle Heatmap |
| Ergebnis | Priorisierte Fehlerliste + Aktionsplan | 5x5-Heatmap + Maßnahmen-Zuordnung |
| Am besten eingesetzt | Beim Projekt-Kickoff, bevor Ressourcen gebunden sind | Während des gesamten Projektlebenszyklus |
| Einschränkung | Einmalige Übung (Momentaufnahme, nicht kontinuierlich) | Erfasst nur Risiken, die Beteiligte bereits erkennen |
Premortem zuerst nutzen, um unbekannte Risiken durch Vorstellungskraft zu entdecken, dann die Risikomatrix, um die gefundenen Risiken zu quantifizieren und zu priorisieren. Am besten als Zwei-Schritt-Workflow: Premortem generiert die Liste, Risikomatrix bewertet und sortiert sie.
Häufige Fehler
1 Es wird zur Schuldzuweisungs-Runde für vergangene Projekte
Das Premortem ist vorausschauend. Es geht darum, Scheitern im aktuellen Projekt zu verhindern, nicht Schuld für vergangene zuzuweisen. Wenn das Gespräch zu "wisst ihr noch, als die letzte Migration gescheitert ist, weil DevOps nicht..." abdriftet, sofort umlenken. Die Fragestellung ist "Was WIRD dieses Projekt scheitern lassen", nicht "Was HAT das letzte Projekt scheitern lassen."
2 Den Aktionsplan-Schritt überspringen
Risiken identifizieren ohne Gegenmaßnahmen zu definieren ist nur organisiertes Sorgen machen. Wenn das Premortem mit einer Liste von 20 Fehlergründen ohne zugewiesene Maßnahmen endet, verlässt das Team das Meeting ängstlich statt vorbereitet. Die Sitzung ist nicht abgeschlossen, bis die Top 3-5 Risiken je einen Verantwortlichen, eine Maßnahme und eine Frist haben.
3 Nur Teamleiter einbeziehen
Teamleiter sehen strategische Risiken (Budget, Zeitplan, Scope). Teammitglieder an der Front sehen Umsetzungsrisiken (technische Schulden, Abhängigkeitsprobleme, Prozesslücken). Junior-Entwickler, QA-Ingenieure und Support-Mitarbeitende identifizieren oft die handlungsrelevantesten Fehlergründe, weil sie am nächsten an dem arbeiten, wo Dinge tatsächlich brechen. 6-10 Personen aus verschiedenen Rollen einbeziehen.
4 Das Premortem zu spät durchführen
Ein Premortem beim Kickoff-Meeting kann Fehler verhindern. Ein Premortem nach zwei Monaten Entwicklung kann nur Risiken dokumentieren, die bereits real werden. Vor der Ressourcenbindung durchführen, wenn Änderungen noch günstig sind. Wenn du ein fundamentales Architekturrisiko in Woche 1 entdeckst, kannst du pivotieren. In Woche 12 kannst du nur noch in Panik geraten.
Kostenloses interaktives Tool ausprobieren
Diese Methode direkt im Browser nutzen. Ohne Anmeldung, mit PDF-Export.
Häufig gestellte Fragen
- Ein Postmortem findet nach Projektende statt (oft nach einem Scheitern). Ein Premortem findet vorher statt: Man stellt sich das Scheitern vor und identifiziert Ursachen im Voraus, solange man sie noch verhindern kann.
- Eine Risikobewertung fragt "Was könnte schiefgehen?" Ein Premortem formuliert um: "Das Projekt ist gescheitert : warum?" Diese psychologische Umkehrung steigert die Identifikation von Fehlerursachen um 30%.
- Absolut. Das Premortem identifiziert Fehlerszenarien, die Risikomatrix quantifiziert sie. Nutze die Premortem-Ergebnisse als Input für die Risikomatrix.
- 4-8 Personen sind ideal. Weniger als 4 begrenzt die Vielfalt der Perspektiven. Mehr als 8 macht die Brainstorming-Runden langsam und repetitiv. Personen mit verschiedenen Rollen und Sichtweisen einbeziehen: den Optimisten, den Skeptiker, den technischen Experten und jemanden von außerhalb des Projekts, der frische Augen mitbringt.
- Ja. Selbst bei einem 2-Wochen-Sprint kann ein 15-minütiges Premortem überraschende Risiken aufdecken. Der Aufwand skaliert mit der Projektgröße: großes Projekt = 60-Minuten-Workshop mit dem ganzen Team. Kleines Projekt = 15 Minuten im Standup. Der Grundsatz bleibt: Scheitern vorstellen, bevor es passiert.
Verwandte Blogartikel
Verwandte Methoden
Szenarioanalyse
Best Case, Worst Case und realistisches Szenario durchdenken, bevor du dich festlegst. Reduziert Überraschungen und bereitet dein Team auf verschiedene Ausgänge vor.
SWOT-Analyse
Stärken, Schwächen, Chancen und Risiken jeder Option systematisch bewerten. Gibt dir ein vollständiges Bild, bevor du dich festlegst.
Impact/Effort-Matrix
Jede Option nach Wirkung und Aufwand bewerten, um schnelle Erfolge zu finden und keine Ressourcen an Low-Value-Arbeit zu verschwenden.