Es ist gescheitert. Warum?

Sechs Monate später: Das Projekt ist gescheitert. Warum?

Wir haben uns auf die Sandbox des Zahlungsdienstleisters verlassen und nie gegen die Produktionslimits getestet. Der Traffic am Launch-Tag hat den Checkout lahmgelegt.
Nur Priya hat die Skripte für die Datenmigration verstanden. Im dritten Monat ging sie in Elternzeit, und alles stand still.
Die Rechtsabteilung hat die AGB zwei Wochen vor dem Launch geprüft, und wir mussten den Einwilligungsprozess neu bauen.
Frühwarnzeichen

Woran würden wir zuerst merken, dass das passiert?

Support-Tickets beim Dienstleister brauchen länger als zwei Tage bis zur ersten Antwort.
Bei jedem Pull Request zur Migration wird dieselbe Person als Reviewerin markiert.
Mitten im Sprint tauchen neue Tickets mit „kurze Anfrage vom Vertrieb“ in der Beschreibung auf.
So verhindern wir es

Was können wir jetzt tun, damit das nicht passiert?

In Sprint zwei einen Lasttest gegen die Produktionsumgebung des Dienstleisters fahren, bevor wir darauf aufbauen.
Jemanden mit Priya an den Migrationsskripten arbeiten lassen und das Runbook bis Monatsende dokumentieren.
Die rechtliche Prüfung des Einwilligungsprozesses schon während des Designs einplanen, nicht erst nach der Umsetzung.
Verantwortliche und nächste Schritte

Wer ist für welches Top-Risiko verantwortlich, und bis wann?

Marco ist für den Lasttest beim Dienstleister verantwortlich, fällig zum Ende von Sprint zwei.
Ich arbeite mit Priya an der Migration, und wir veröffentlichen das Runbook bis zum 15.
Dana plant die rechtliche Prüfung des Einwilligungsprozesses vor der Design-Freigabe nächsten Freitag ein.

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.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Pre-Mortem und einem Post-Mortem?
Ein Post-Mortem findet statt, nachdem ein Projekt beendet oder gescheitert ist, und blickt darauf zurück, was tatsächlich schiefgelaufen ist. Ein Pre-Mortem findet vor Beginn der Arbeit statt und stellt sich das Scheitern im Voraus vor, damit das Team es verhindern kann, solange noch Zeit zum Handeln ist.
Wer hat die Pre-Mortem-Technik entwickelt?
Der Psychologe Gary Klein hat den Begriff Pre-Mortem geprägt und die Methode 2007 in seinem Artikel „Performing a Project Premortem“ in der Harvard Business Review beschrieben. Sie stützt sich auf Forschung, die zeigt, dass Menschen konkretere Gründe für ein Ergebnis finden, wenn sie sich vorstellen, es sei bereits eingetreten.
Wie lange dauert ein Pre-Mortem?
Die meisten Pre-Mortems dauern 45–60 Minuten bei einem Team von fünf bis zehn Personen. Mit der asynchronen Variante lässt sich das Live-Meeting auf etwa 30 Minuten verkürzen, weil die Ideen schon vor dem Termin gesammelt sind.
Wann sollte man ein Pre-Mortem durchführen?
Zum Projektstart, bevor Zusagen wie Umfang, Deadlines und Budgets feststehen. Vermeidet es mitten in einer Krise, wenn sich das Team darauf konzentrieren muss, echte Probleme zu lösen.
Warum sollten Ideen im Pre-Mortem anonym sein?
Wenn Namen sichtbar sind, wiederholen die Leute oft die Bedenken der ranghöchsten Person im Raum. Anonyme Ideen bringen die Risiken ans Licht, die die Leute wirklich beschäftigen, auch solche, die Entscheidungen der Führungsebene betreffen.
Kann man ein Pre-Mortem asynchron durchführen?
Ja. Verteilte Teams können die Ideen über einen Tag hinweg in TeamRetro sammeln und sich dann nur treffen, um zu gruppieren, über die Top-Risiken abzustimmen und Verantwortliche mit Terminen festzulegen.
Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus