Pre-Mortem Workshop: Ein Leitfaden für Facilitatoren

Jedes Projekt-Debriefing fördert dieselbe unbequeme Wahrheit zutage: Die Warnsignale waren die ganze Zeit da — nur hat sie niemand laut ausgesprochen. Der Pre-Mortem Workshop ist die Methode, die das ändert, bevor es zu spät ist, um zu handeln.

Was ein Pre-Mortem ist und warum er funktioniert

Der Pre-Mortem geht auf den Forschungspsychologen Gary Klein zurück, der die Methode in seinem Harvard Business Review-Artikel von 2007 beschrieben hat. Die Idee ist denkbar einfach: Bevor ein Projekt startet, versetzt sich das Team gedanklich in die Zukunft — und stellt sich vor, das Projekt ist bereits gescheitert. Dann arbeitet die Gruppe rückwärts und fragt: Warum?

Diese Technik nennt Klein „prospektive Hindsight". Sie nutzt eine kognitive Eigenschaft des menschlichen Gehirns: Wir erklären vergangene Ereignisse besser, als wir zukünftige vorhersagen. Kleins Forschung zeigt, dass diese mentale Simulation die Fähigkeit, richtige Ursachen für ein Ergebnis zu identifizieren, um etwa 30 Prozent steigert — verglichen mit konventionellen Planungsübungen.

Der tiefere Effekt ist psychologischer Natur. In normalen Planungsmeetings unterdrücken Projektbeteiligte ihre Zweifel, weil Skepsis als Illoyalität gegenüber dem Projekt wirkt. Der Pre-Mortem dreht diesen Druck um: Pessimismus ist hier nicht nur erlaubt, er ist die Aufgabe. Das öffnet den Raum für genau die Bedenken, die sonst im Flur geäußert werden — aber nie im Meeting.

Klein beschreibt ein konkretes Beispiel: Ein Produktteam bereitete den Launch einer Software-Plattform vor. Während des Pre-Mortems meldete sich ein junger Ingenieur zu Wort und nannte die Abhängigkeit von einer externen API, die niemand unter Stress getestet hatte. Das Team hatte die Stabilität dieser Schnittstelle als selbstverständlich vorausgesetzt. Sie bauten einen Fallback ein — und die API fiel tatsächlich in der zweiten Woche nach dem Launch aus.

Der richtige Zeitpunkt für einen Pre-Mortem

Das Timing ist nicht trivial. Zu früh im Prozess — bevor ein konkreter Plan existiert — produziert ein Pre-Mortem nur vage Sorgen ohne Substanz. Zu spät — wenn Budgets bereits freigegeben und Teams voll eingespannt sind — löst er Defensivität aus, weil Sunk-Cost-Psychologie bereits greift.

Das optimale Fenster liegt nach der Genehmigung eines Projektauftrags oder Business Cases, aber vor dem offiziellen Kick-off oder der Budgetfreigabe. Der Plan ist dann konkret genug, um kritisiert zu werden — aber noch flexibel genug, um verändert zu werden.

Pre-Mortems eignen sich auch als Phase-Gate-Instrument in längeren Programmen. Zum Beispiel an der Schwelle von Discovery zu Delivery: Was würde dazu führen, dass die nächste Phase scheitert, obwohl die erste erfolgreich war? Das ist eine andere Frage als die zum Projektstart — und sie produziert andere, spezifischere Risiken.

Bestimmte Konstellationen machen einen Pre-Mortem besonders wertvoll: enge Deadlines ohne Puffer, Teams, die zum ersten Mal zusammenarbeiten, hohe Abhängigkeiten von externen Partnern, politisch sensible Launches, und Projekte, die auf Annahmen beruhen, die noch nie empirisch geprüft wurden. Diese Kriterien können als Checkliste in das Facilitator-Briefing einfließen.

Amazon nutzt mit seinem „Working Backwards"-Prozess eine strukturell verwandte Methode: Teams schreiben vor dem Bau einer Lösung eine hypothetische Pressemitteilung und FAQ. Die kognitive Inversion ist dieselbe — wie AWS in ihrem Enterprise Strategy Blog beschreibt.

Die richtige Zusammensetzung der Gruppe

Sechs bis zwölf Personen sind ideal. Die Zusammensetzung sollte drei Schichten abdecken: das Kernteam mit detailliertem Planungswissen, angrenzende Stakeholder, die vom Projekt betroffen sind, aber nicht darin arbeiten, und mindestens eine kritische Außenperspektive — jemand ohne Interesse am Gelingen des Plans. Das kann ein Kollege aus einer anderen Funktion sein, eine kürzlich ins Unternehmen eingestiegene Person oder eine Kundenvertretung.

Die Außenperspektive ist oft die wertvollste Stimme im Raum. Ein britisches Government Digital Service-Team bereitete den Launch eines Bürgerportals vor. Zwei Mitglieder eines Bürger-Beratungsgremiums identifizierten das einzige wirklich kritische Risiko: Das Portal setzte voraus, dass alle Nutzer eine E-Mail-Adresse besitzen — aber die Zielgruppe (ältere Leistungsempfänger) hatte eine deutlich niedrigere E-Mail-Nutzungsrate. Kein technisches Risikoregister hatte das erfasst.

Hierarchie ist der größte Feind eines ehrlichen Pre-Mortems. Wenn der Projektsponsor im Raum sitzt und sichtbar an den Plan gebunden ist, zensieren sich Junior-Teammitglieder. Die einfachste Lösung: Die Phase der Risikoidentifikation von der Synthesephase trennen und den Sponsor erst zu Letzterem hinzuziehen. Alternativ Senior-Teilnehmer explizit briefen, Widerspruch aktiv zu belohnen — nicht zu bestrafen.

Eine funktional diverse Gruppe deckt systematisch mehr Risikobereiche ab. Ein rein technisches Team sieht technische Risiken. Wer zusätzlich eine Person aus dem Finanzbereich einbindet, sieht Budgetrisiken; wer jemanden aus dem Customer Success holt, sieht Adoptionsrisiken. Forschung zu diversen Teams in der Entscheidungsfindung bestätigt das konsistent.

Eine Agenda in fünf Phasen

Ein gut strukturierter Pre-Mortem Workshop läuft in fünf Phasen ab. 90 Minuten reichen für eine Gruppe von acht Personen — vorausgesetzt, die Phasen werden diszipliniert gehalten.

Phase 1 — Briefing (10 Minuten): Der Facilitator stellt den Plan vor und setzt den gedanklichen Rahmen. Nicht abstrakt: „Es ist jetzt 12 Monate später, das Projekt ist katastrophal gescheitert. Der Launch war ein Desaster, die Presse schreibt darüber, das Führungsteam stellt Fragen." Atlassian empfiehlt in seinem Team Playbook explizit konkrete, lebendige Failure-Szenarien — je spezifischer der Rahmen, desto spezifischer die Risiken, die er auslöst.

Phase 2 — Stille Einzelarbeit (5 bis 8 Minuten): Jede Person schreibt ihre Versagensursachen allein und ohne Austausch mit anderen auf. Diese Phase ist die am häufigsten übersprungene — und die wichtigste. Die Forschung zur Nominal Group Technique zeigt, dass unabhängiges Ideengenerieren vor der Gruppenarbeit mehr und diversere Ideen produziert als offene Gruppenbrainstormings, weil es verhindert, dass eine laute erste Stimme den Raum verankert.

Phase 3 — Round-Robin-Harvest (20 bis 25 Minuten): Jede Person nennt einen Punkt, reihum, bis alle einzigartigen Punkte auf dem Board sind. Keine Diskussion, keine Bewertung — nur Erfassung. Doppelungen werden zusammengeführt, aber nicht gelöscht.

Phase 4 — Clustern und Priorisieren (15 Minuten): Die Gruppe ordnet Risiken nach Schwere und Wahrscheinlichkeit, zum Beispiel per Dot-Voting. Wichtig: Die Wahrscheinlichkeitsbewertung erfolgt individuell, bevor sie geteilt wird — das verhindert den „False Comfort Pre-Mortem", bei dem Risiken durch Gruppenkonsens als harmlos eingestuft werden, um Unbehagen zu vermeiden.

Phase 5 — Eigentumsübertragung (15 Minuten): Jedes priorisierte Risiko bekommt eine namentliche Verantwortlichkeit, eine konkrete Gegenmaßnahme und ein Folgetermin-Datum. Kein Risiko verlässt den Raum ohne Eigentümer.

Optionale Erweiterung: Nach der Failure-Übung arbeitet eine kleine Gruppe am „Pre-Parade" — der Inversion. Was hat das Projekt außergewöhnlich erfolgreich gemacht? Das klingt nach einer Aufheiterungsrunde, ist aber analytisch wertvoll: Es legt unausgesprochene Erfolgsannahmen offen, die oft genauso ungeprüft sind wie die Risikofelder.

Risiken in konkrete Maßnahmen überführen

Das häufigste Scheitern eines Pre-Mortems passiert nicht im Workshop — es passiert danach. Eine lange Risikoliste landet in einem geteilten Dokument, niemand schaut mehr drauf, und beim nächsten Projektmeeting ist das Ergebnis vergessen. Das führt dazu, dass Teilnehmer Pre-Mortems als beschäftigungstherapeutische Übung abschreiben.

Ein Produktteam einer europäischen Fintech-Firma hat das Problem strukturell gelöst: Der Facilitator bestand darauf, dass alle Risiken noch während des Workshops — auf einem geteilten Bildschirm — direkt in das RAID-Log (Risks, Assumptions, Issues, Dependencies) des Projekts eingetragen wurden. Jeder Eintrag hatte einen Eigentümer und ein Fälligkeitsdatum. Beim nächsten Weekly Stand-up war das RAID-Log der erste Agendapunkt. Drei der fünf Top-Risiken aus dem Pre-Mortem traten tatsächlich ein — keines wurde zum kritischen Vorfall, weil Verantwortung und Gegenmaßnahmen schon vorab definiert waren.

Das Ownership-Prinzip lautet: Wer am nächsten am Versagensbereich sitzt, übernimmt die Mitigation. Ein technisches Risiko gehört dem technischen Lead, nicht dem Projektmanager. Wenn Verantwortung immer der ranghöchsten Person im Raum zugewiesen wird, diffundiert sie — und Maßnahmen versanden.

Die Integration in bestehende Projektartefakte ist entscheidend für die Wirksamkeit. Pre-Mortem-Outputs, die separat in einem Workshop-Protokoll leben, haben eine kurze Halbwertszeit. Outputs, die ins RAID-Log, den Projektbrief oder die Team Charter einfließen, bleiben Teil des operativen Rhythmus.

Typische Facilitationsfehler

Der häufigste Fehler: Die stille Einzelarbeit weglassen und direkt in die Gruppendiskussion gehen. Das klingt effizienter. Es ist es nicht. Die erste laut geäußerte Meinung verankert die gesamte Gruppe — danach wird variiert, nicht neu gedacht.

Zweiter Fehler: Die Failure-Identifikation driftet in Lösungsmodus. Sobald jemand anfängt, Gegenmaßnahmen vorzuschlagen, hört die Gruppe auf, Risiken zu suchen. Die Facilitatoraufgabe ist, diesen Wechsel zu unterbrechen: „Das ist eine gute Idee für Phase fünf. Jetzt bleiben wir beim Sammeln."

Dritter Fehler: Fehlende psychologische Sicherheit. Amy Edmondsons Forschung an der Harvard Business School zeigt, dass Teams mit höherer psychologischer Sicherheit mehr Fehler und Beinahe-Unfälle melden — nicht weil sie mehr Fehler machen, sondern weil sie ehrlicher sind. Sie haben bessere Ergebnisse, weil Probleme angesprochen statt vertuscht werden. Für Pre-Mortems gilt dasselbe: Ein sicherer Raum produziert ehrlichere Risikolisten. Wenn Bedenken implizit die Lieblingsannahme einer Führungskraft angreifen, braucht es explizite Sicherheitssignale vom Facilitator — und idealerweise von der Führungskraft selbst.

Workshop Weaver bietet für diesen Prozess strukturierte Vorlagen, die den Ablauf von der stillen Einzelarbeit bis zur Eigentumsübertragung durchgängig abbilden — ohne dass der Facilitator das Rahmenwerk jedes Mal neu bauen muss.

Pre-Mortem, Szenarioplanung und Three Horizons kombinieren

Ein Pre-Mortem untersucht ein einzelnes Szenario in der Tiefe. Szenarioplanung erweitert den Rahmen auf zwei bis vier plausible Zukünfte, jede mit anderen Unsicherheitskombinationen. Die stärkste Sequenz: Erst Szenarioplanung, um die zentralen Unsicherheiten zu identifizieren, dann ein Pre-Mortem pro Hochrisiko-Szenario.

Shells Strategic Planning-Team hat diesen kombinierten Ansatz in den 1970er Jahren mitentwickelt. Die damaligen Szenarien-Methodiken enthielten explizit Failure-Mode-Analysen pro Szenario — strukturell identisch mit einem Pre-Mortem.

Das Three-Horizons-Framework — ursprünglich bei McKinsey entwickelt, von Bill Sharpe und dem International Futures Forum weiterentwickelt — liefert eine nützliche Ergänzung: Horizon-1-Risiken (operativ, kurzfristig) sehen anders aus als Horizon-2-Risiken (Fähigkeitslücken, Transitionskosten) oder Horizon-3-Risiken (Annahmen über die langfristige Zukunft). Risiken während eines Pre-Mortems mit Horizont-Tags zu versehen, kostet zwei Minuten und erhöht die strategische Nutzbarkeit des Outputs erheblich.

Einen Pre-Mortem jetzt planen

Identifizieren Sie ein anstehendes Projekt — einen Produkt-Launch, einen Strategie-Pivot, eine neue Teamformation — und planen Sie vor dem Kick-off einen 90-minütigen Pre-Mortem Workshop ein. Die fünf Phasen in einer Zeile: Briefen, schweigend generieren, round-robin sammeln, clustern und priorisieren, Eigentümerschaft zuweisen.

Die Methode ist kein pessimistisches Ritual. Sie ist das Optimistischste, was ein Team tun kann: die Probleme benennen, die man noch beheben kann.