Projekt-Post-Mortem-Vorlage

Format der Post-Mortem-Retrospektive

Projektüberblick, Ziele und Umfang

Was sollte das Projekt erreichen, und bis wann?

Dieses Thema setzt den Rahmen, bevor jemand etwas bewertet. Frage nach dem ursprünglichen Ziel, dem vereinbarten Umfang, dem Zeitplan und den Erfolgskriterien sowie danach, was im Vergleich dazu tatsächlich geliefert wurde. Nutze es bei einem Vorfall-Review stattdessen für die Fakten des Zeitverlaufs: Was ist ausgefallen, wann wurde es entdeckt, wer war beteiligt und wie wurde es behoben. Halte Interpretationen aus dieser Spalte heraus und parke Meinungen für die folgenden Themen. Wenn sich Menschen nicht einig sind, was die Ziele oder Erfolgskriterien überhaupt waren, ist diese Uneinigkeit selbst eine Erkenntnis, die es wert ist, festgehalten zu werden.

Was gut lief

Welche Erfolge und Abläufe sind es wert, wiederholt zu werden?

Teams hetzen über dieses Thema hinweg, besonders nach einem schwierigen Projekt oder einem stressigen Vorfall – schütze also die Zeit dafür. Du suchst nach wiederholbaren Praktiken, nicht nach Komplimenten; Kudos haben später ihr eigenes Thema. Wenn jemand Lob postet, frage nach, was genau es funktionieren ließ, damit die Antwort wiederverwendbar ist. Achte auf Erfolge, die aus individuellem Heldentum entstanden sind, und benenne sie als Risiken statt als Erfolge.

Was nicht gut lief

Wo haben wir gestockt, versagt oder Ziele verfehlt?

Hier liegt der eigentliche Wert, also formuliere die Regel der Schuldfreiheit vorab laut: Ihr untersucht Systeme und Entscheidungen, nicht Personen. Fördere Konkretes statt vager Beschwerden, denn „die Kommunikation war schlecht“ lässt sich nicht in Maßnahmen übersetzen, „wir haben von der Terminänderung in einem Flurgespräch erfahren“ schon. Nutze hier das Voting, damit die Diskussion nicht über jedes Ärgernis der letzten drei Monate ausufert.

Ursachenanalyse

Warum ging es schief, nicht nur dass es schiefging?

Optional für ein einfaches Projektreview, essenziell für einen Vorfall. Nimm die am höchsten bewerteten Probleme aus dem vorherigen Thema und frage weiter nach dem Warum, bis du bei einer Bedingung statt bei einer Person landest: ein fehlendes Sicherheitsnetz, eine unklare Verantwortlichkeit, Terminsdruck, eine ungeprüfte Annahme. Five Whys funktioniert hier gut, ebenso die Frage, was die falsche Handlung damals vernünftig erscheinen ließ. Höre auf, wenn du bei etwas ankommst, das du tatsächlich ändern kannst, und notiere begleitende Faktoren getrennt vom Auslöser.

Lessons Learned

Welche zentralen Erkenntnisse nehmen wir mit?

Das ist das „Und was jetzt?“, das Beobachtungen in wiederverwendbares Wissen verwandelt. Treibe jede Idee so weit, dass sie ein Verhalten, einen Auslöser oder ein Sicherheitsnetz benennt, damit sie den Kontakt mit dem nächsten Projekt übersteht. Unterscheide zwischen Dingen, die dieses Team selbst ändern kann, und Dingen, die an eine Führungskraft oder eine andere Gruppe gehen müssen, und sei bei der zweiten Kategorie ehrlich. Formuliere die Erkenntnisse so, dass jemand außerhalb des Raums sie im exportierten Report lesen und verstehen kann, ohne dass du sie erklärst.

Maßnahmen, Verantwortliche und Fristen

Wer macht was, und bis wann?

Ein Post-Mortem ohne zugewiesene Maßnahmen zählt nicht, also lass dafür echte Zeit statt es in die letzten zwei Minuten zu quetschen. Wandle die am höchsten bewerteten Lessons Learned in eine kleine Anzahl konkreter Maßnahmen um, jede mit benannter Verantwortlichkeit und einem in TeamRetro erfassten Fälligkeitsdatum, damit sie in der nächsten Session auftauchen. Zwei oder drei gut verantwortete Maßnahmen sind besser als zehn ambitionierte. Wenn eine Maßnahme zu jemandem außerhalb des Raums gehört, klärt, wer sie wann dorthin bringt.

Anerkennung und Kudos im Team

Wer verdient Anerkennung, bevor wir abschließen?

Schließe mit den Menschen ab, nicht mit den Problemen. Lade alle ein, eine konkrete Person und eine konkrete Handlung zu benennen – das ist viel bedeutungsvoller als allgemeiner Dank und funktioniert auch nach einem schwierigen Projekt gut. Das zählt besonders, wenn das Review anstrengend war, denn es erinnert das Team daran, dass das Untersuchen eines Fehlers nicht dasselbe ist wie sich gegenseitig Schuld zuzuweisen. Halte es kurz, lies ein paar Beiträge vor und lass den exportierten Report den Rest tragen.

Wann sollte diese Retrospektive durchgeführt werden?

• Ein Projekt, eine Lieferung, eine Migration oder eine Kampagne ist gerade abgeschlossen und du willst ein strukturiertes Projektreview statt eines informellen Gesprächs, das verpufft.
• Ein Vorfall, ein Ausfall oder ein fehlgeschlagenes Release braucht ein schuldfreies Post-Mortem mit Zeitverlauf, Grundursachen und vorbeugenden Maßnahmen.
• Ein langlaufendes Programm hat eine Phase abgeschlossen und du willst die Lessons Learned festhalten, solange die Details noch frisch sind.
• Eine cross-funktionale Gruppe löst sich auf, und das ist deine letzte Chance für ein Team-Debriefing und die Anerkennung der Beteiligten, bevor sich alle in neue Arbeit verstreuen.
• Etwas ist unerwartet gut gelaufen und du willst verstehen, warum, damit die Praxis wiederholt und nicht als Glück abgetan wird.

Vorschläge für Fragen zum Icebreaker

• Wie hat sich dieses Projekt oder dieser Vorfall in einem Wort angefühlt, als du mitten drin warst?
• Wenn du dir selbst an Tag eins einen Satz Rat zurückschicken könntest, was würde darin stehen?

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers entdecken →

Ideen und Tipps für Ihre Retrospektive

• Führe es innerhalb von einer oder zwei Wochen nach Projektabschluss oder Behebung des Vorfalls durch. Erinnerungen verblassen schnell, und die nützlichen Details gehen mit ihnen.
• Nenne die Regel der Schuldfreiheit zu Beginn. Ihr schaut auf Entscheidungen, Systeme und Druck, nicht auf die Suche nach einer verantwortlichen Person.
• Nimm dir ein paar Minuten, um den Projektüberblick abzustimmen, bevor Meinungen beginnen. Ein gemeinsamer Rahmen verhindert, dass die Session zur Debatte darüber wird, was das Ziel überhaupt war.
• Lass die Ursachenanalyse bei einem sauberen Projektreview aus oder kürze sie, und geh bei Vorfällen, bei denen Prävention der Punkt ist, in die Tiefe.
• Priorisiere mit Voting und lass das Meeting nicht enden, ohne Verantwortliche und Fälligkeitstermine für die wichtigsten Maßnahmen – sonst bleiben deine Lessons Learned theoretisch.
• Bring die Maßnahmen des letzten Post-Mortems mit in den Raum und überprüfe sie zuerst. Nichts verbessert die Umsetzung so wie das Wissen, dass sie geprüft wird.

Häufig gestellte Fragen