Was ist eine Pre-Mortem-Retrospektive?
Ein Pre-Mortem ist eine Risikositzung zum Projektstart, bevor Umfang, Termine und Budgets festgezurrt sind. Das Team stellt sich eine konkrete Zukunft vor: Es ist sechs Monate später, und das Projekt ist gescheitert. Dann schreibt jede Person auf, warum es gescheitert ist, so als wäre das Scheitern bereits passiert. Der Psychologe Gary Klein hat die Technik entwickelt und sie 2007 in seinem Artikel „Performing a Project Premortem“ in der Harvard Business Review beschrieben. Sie stützt sich auf Forschung zum sogenannten „prospective hindsight“ (vorausschauender Rückblick). Diese hat gezeigt, dass Menschen konkretere Gründe für ein Ereignis finden, wenn sie sich vorstellen, es sei bereits eingetreten. Entscheidend ist die Fragestellung. Fragt man ein Team „Was könnte schiefgehen?“, bekommt man höfliche, allgemeine Antworten wie „Scope Creep“ oder „Kommunikationsprobleme“. Fragt man „Warum ist es gescheitert?“, nennen die Leute echte Ursachen: die API des Dienstleisters, die nie unter Last getestet wurde, die Stakeholderin, die nie einbezogen wurde, den einen Entwickler, bei dem das ganze Wissen liegt. Wenn das Scheitern als gegeben gilt, ist es außerdem leichter, Zweifel auszusprechen, die bei einem optimistischen Kickoff sonst negativ oder illoyal klingen würden. Diese Pre-Mortem-Vorlage führt in TeamRetro durch vier Schritte. Zuerst sammelt ihr die Gründe, warum das Projekt gescheitert ist. Dann identifiziert ihr die Frühwarnzeichen, einigt euch auf Präventionsschritte und gebt zum Schluss jedem Top-Risiko eine verantwortliche Person und ein Datum. Der letzte Schritt ist der wichtigste. Ein Risiko ohne Verantwortliche und Frist ist meist schon am Ende der ersten Woche vergessen. Nutzt anonyme Ideen, damit die Hierarchie nicht beeinflusst, was die Leute schreiben. Verteilte Teams sammeln die Ideen am besten asynchron über einen Tag und treffen sich dann nur noch, um abzustimmen und Verantwortliche festzulegen.
Pre-Mortem-Retrospektive: Ablauf
Es ist gescheitert. Warum?
Sechs Monate später: Das Projekt ist gescheitert. Warum?
Diese Spalte ist der Kern des Pre-Mortems. Beschreibe die Ausgangslage klar: Das Projekt ist vorbei, es ist gescheitert, und alle wissen es. Bitte die Teilnehmenden, in der Vergangenheitsform zu schreiben („Wir haben den Launch verpasst, weil …“), denn diese Formulierung bringt konkretere Ursachen hervor als Spekulationen darüber, was schiefgehen könnte. Halte die Ideen anonym, damit sich nicht alle an den Stimmen der Erfahrensten orientieren. Gib 8–10 Minuten Zeit zum stillen Schreiben, ermutige zu einem Grund pro Idee, gruppiere dann ähnliche Ideen und lass abstimmen, um die Top-Risiken für die nächsten Schritte zu finden.
Frühwarnzeichen
Woran würden wir zuerst merken, dass das passiert?
Frühwarnzeichen machen aus vagen Befürchtungen etwas, das das Team beobachten kann. Frag bei jedem Top-Risiko aus der ersten Spalte, was das erste beobachtbare Signal wäre: eine Kennzahl, ein verpasster Meilenstein, ein Muster in den Daily Standups. Dränge auf Signale, die konkret und messbar sind. „Die Stimmung sinkt“ lässt sich schwer verfolgen. „Zwei Sprints in Folge mit mehr als 30 % übertragener Arbeit“ fällt sofort auf. Diese Signale werden zu den Auslösern, die die Risikoverantwortlichen im Blick behalten.
So verhindern wir es
Was können wir jetzt tun, damit das nicht passiert?
Hier kommt das Team von der Sorge ins Handeln. Konzentriere dich nur auf die Risiken mit den meisten Stimmen, meist drei bis fünf. Frag bei jedem, was das Team diese Woche oder diesen Monat tun kann, um die Wahrscheinlichkeit oder die Auswirkungen zu verringern. Bevorzuge kleine, konkrete Schritte gegenüber großen Prozessänderungen. Wenn eine Präventionsidee eine Freigabe oder Budget braucht, notiere, wer gefragt werden muss. Bleib praktisch: Ziel ist eine kürzere Liste von Maßnahmen, die die Leute auch wirklich umsetzen.
Verantwortliche und nächste Schritte
Wer ist für welches Top-Risiko verantwortlich, und bis wann?
Um diese Spalte geht es in der ganzen Sitzung. Jedes Top-Risiko braucht eine namentlich genannte verantwortliche Person und ein Datum, sonst sind die heute gesammelten Befürchtungen verblasst, bevor die erste Woche um ist. Die Verantwortlichen müssen das Risiko nicht allein beheben. Sie sind dafür zuständig, die Frühwarnzeichen im Blick zu behalten und dafür zu sorgen, dass der Präventionsschritt umgesetzt wird. Erfasse jeden Punkt als Maßnahme in TeamRetro, damit er in künftige Retrospektiven mitgenommen wird, und plane beim ersten Meilenstein einen kurzen Check-in, um den Fortschritt zu prüfen.
Wann sollte diese Retrospektive durchgeführt werden?
- Zum Start eines neuen Projekts, Produktlaunches oder größeren Vorhabens, bevor Umfang, Termine und Budget endgültig feststehen.
- Vor einem kritischen Meilenstein wie einer Migration, einem Go-live oder einer Vertragsunterzeichnung, bei dem eine späte Überraschung teuer würde.
- Wenn ein Team ungewöhnlich optimistisch auf einen Plan blickt und stillere Teammitglieder ihre Zweifel womöglich zurückhalten.
- Zu Beginn der Zusammenarbeit mit einem neuen Dienstleister, Partner oder bereichsübergreifenden Team, dessen Abhängigkeiten noch nicht gut verstanden sind.
- Zu Beginn eines neuen Quartals oder Program Increments, um den Plan auf die Probe zu stellen, bevor sich das Team darauf festlegt.
Vorschläge für Fragen zum Icebreaker
- Welcher Plan, der schiefgegangen ist, ist dir am meisten in Erinnerung geblieben, ob im Job oder privat, und was war das erste Warnzeichen?
- Wenn dieses Projekt ein Film wäre, welches Genre hätte die Version, in der es scheitert?
Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →
Ideen und Tipps für Ihre Retrospektive
- Führt das Pre-Mortem zum Projektstart durch, bevor Zusagen feststehen. Niemals mitten in einer Krise: Dann muss das Team Probleme lösen, und sich das Scheitern vorzustellen, macht nur zusätzlich Angst.
- Haltet die Ideen anonym. Sind Namen sichtbar, prägen die Befürchtungen der ranghöchsten Person die Runde, und alle anderen schreiben nur noch dünne Zustimmung.
- Besteht in der ersten Spalte auf der Vergangenheitsform. „Warum ist es gescheitert?“ liefert konkretere, realistischere Risiken als „Was könnte schiefgehen?“. Formuliert Ideen, die wieder ins Hypothetische rutschen, also behutsam um.
- Grenzt die Liste per Abstimmung auf drei bis fünf Top-Risiken ein, bevor ihr über Prävention sprecht. Wer jede Idee angehen will, verzettelt sich, und am Ende passiert nichts.
- Beendet die Sitzung erst, wenn jedes Top-Risiko eine verantwortliche Person und ein Datum hat. Ohne diese sind die gesammelten Risiken vor Ende der ersten Woche vergessen.
- Verteilte Teams arbeiten am besten asynchron: Sammelt die Ideen über einen Tag hinweg in allen Zeitzonen und trefft euch dann nur 30 Minuten, um zu gruppieren, abzustimmen und Verantwortliche festzulegen.