Projekt-Post-Mortem-Vorlage

Post-Mortem-Retrospektive: Ablauf und Format

Projektüberblick, Ziele und Umfang

Was sollte das Projekt erreichen, und bis wann?

Dieses Thema steckt den Rahmen ab, bevor irgendetwas bewertet wird. Frag nach dem ursprünglichen Ziel, dem vereinbarten Umfang, dem Zeitplan und den Erfolgskriterien und danach, was tatsächlich im Vergleich dazu geliefert wurde. Bei einem Incident-Review nutzt du die Spalte stattdessen für die Zeitachse: Was ist ausgefallen, wann wurde es bemerkt, wer war beteiligt und wie wurde es behoben? Halte Interpretationen aus dieser Spalte heraus und heb Meinungen für die folgenden Themen auf. Wenn sich die Leute nicht einmal einig sind, was die Ziele oder Erfolgskriterien waren, ist genau diese Uneinigkeit eine Erkenntnis, die ihr festhalten solltet.

Was lief gut?

Welche Erfolge und Abläufe sollten wir wiederholen?

Über dieses Thema gehen Teams gern schnell hinweg, besonders nach einem schwierigen Projekt oder einem stressigen Incident. Nimm dir also bewusst Zeit dafür. Gesucht sind Praktiken, die sich wiederholen lassen, keine Komplimente; für Kudos gibt es später ein eigenes Thema. Wenn jemand Lob schreibt, frag nach, was genau den Erfolg ausgemacht hat, damit die Antwort wiederverwendbar wird. Achte auf Erfolge, die nur durch den Einsatz Einzelner zustande kamen, und benenne sie als Risiko.

Was lief nicht gut?

Wo sind wir hängengeblieben, gescheitert oder haben Ziele verfehlt?

Hier steckt der Großteil der Erkenntnisse, also sprich die Grundregel vor dem Start laut aus: Ihr untersucht Systeme und Entscheidungen, keine Personen, und es gibt keine Schuldzuweisungen. Frag nach konkreten Beispielen statt vager Klagen. Mit „Die Kommunikation war schlecht“ kann niemand etwas anfangen, mit „Von der Terminänderung haben wir zufällig auf dem Flur erfahren“ schon. Lasst abstimmen, damit sich die Diskussion nicht über jedes Ärgernis der letzten drei Monate ausbreitet.

Ursachenanalyse

Warum ist es schiefgelaufen, nicht nur dass es schiefging?

Bei einem unkomplizierten Projektreview optional, bei einem Incident unverzichtbar. Nimm die Probleme mit den meisten Stimmen aus dem vorigen Thema und frag so lange nach dem Warum, bis ihr bei einer Bedingung ankommt, nicht bei einer Person: eine fehlende Absicherung, eine unklare Zuständigkeit, Termindruck, eine Annahme, die niemand überprüft hat. Die 5-Why-Methode funktioniert hier gut, ebenso die Frage, warum die falsche Handlung damals vernünftig erschien. Hör auf, sobald ihr bei etwas angekommen seid, das ihr tatsächlich ändern könnt, und haltet begünstigende Faktoren getrennt vom eigentlichen Auslöser fest.

Lessons Learned

Welche Lehren nehmen wir mit?

Hier geht es um das „Und was folgt daraus?“, das Beobachtungen in wiederverwendbares Wissen verwandelt. Hak bei jeder Idee nach, bis sie ein Verhalten, einen Auslöser oder eine Absicherung benennt, die auch beim nächsten Projekt noch Sinn ergibt. Trenn, was das Team selbst ändern kann, von dem, was an eine Führungskraft oder eine andere Gruppe gehen muss, und sei bei der zweiten Liste ehrlich. Formuliere jede Lektion so, dass jemand, der nicht dabei war, sie im exportierten Bericht lesen und verstehen kann, ohne dass du sie erklären musst.

Maßnahmen, Verantwortliche und Fristen

Wer macht was, und bis wann?

Ein Post-Mortem ohne zugewiesene Maßnahmen zählt nicht, also plane echte Zeit dafür ein, statt es in die letzten zwei Minuten zu quetschen. Macht aus den Lessons Learned mit den meisten Stimmen eine kleine Zahl konkreter Maßnahmen, jeweils mit namentlich Verantwortlichen und einem Fälligkeitsdatum, und haltet sie in TeamRetro fest, damit sie in der nächsten Session wieder auftauchen. Zwei oder drei Maßnahmen mit klarer Zuständigkeit sind besser als zehn gut gemeinte. Wenn eine Maßnahme jemandem außerhalb der Runde gehört, vereinbart, wer sie bis wann an diese Person heranträgt.

Wertschätzung und Kudos

Wer verdient Anerkennung, bevor wir abschließen?

Schließt mit den Menschen ab, nicht mit den Problemen. Bitte alle, eine bestimmte Person und eine bestimmte Sache zu nennen, die sie getan hat; das bedeutet viel mehr als ein allgemeines Dankeschön und funktioniert auch nach einem schwierigen Projekt. Am wichtigsten ist es, wenn das Review anstrengend war, denn es erinnert das Team daran, dass das Untersuchen eines Fehlschlags nicht dasselbe ist, wie sich gegenseitig die Schuld zu geben. Halte es kurz, lies ein paar Beiträge laut vor und überlass den Rest dem exportierten Bericht.

Wann sollte diese Retrospektive durchgeführt werden?

• Ein Projekt, eine Lieferung, eine Migration oder eine Kampagne ist gerade abgeschlossen, und ihr wollt eine strukturierte Auswertung statt eines lockeren Gesprächs, das im Sand verläuft
• Ein Incident, ein Ausfall oder ein gescheitertes Release braucht ein Post-Mortem ohne Schuldzuweisungen, das Ablauf, Ursachen und vorbeugende Maßnahmen abdeckt
• Ein langlaufendes Programm hat eine Phase abgeschlossen, und ihr wollt die Lessons Learned festhalten, solange die Details noch frisch sind
• Ein funktionsübergreifendes Team löst sich auf, und das ist eure letzte Gelegenheit für ein Debriefing und um die Beteiligten zu würdigen, bevor alle zu neuen Aufgaben wechseln
• Etwas lief unerwartet gut, und ihr wollt verstehen, warum, damit ihr es wiederholen könnt, statt es als Glück abzutun

Vorschläge für Fragen zum Icebreaker

• Wie hat sich dieses Projekt oder dieser Incident mittendrin angefühlt, in einem Wort?
• Wenn du deinem Ich am ersten Tag einen einzigen Satz als Rat schicken könntest, wie würde er lauten?

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 Post-Mortem innerhalb von ein, zwei Wochen nach Projektabschluss oder nach Behebung des Incidents durch. Erinnerungen verblassen schnell, und mit ihnen die nützlichen Details
• Sprecht die Regel „keine Schuldzuweisungen“ gleich zu Beginn aus. Ihr schaut auf Entscheidungen, Systeme und Druck, nicht auf die Suche nach jemandem, der verantwortlich gemacht werden kann
• Nehmt euch ein paar Minuten, um euch auf den Projektüberblick zu einigen, bevor Meinungen ins Spiel kommen. Ein gemeinsamer Rahmen verhindert, dass die Session zur Debatte darüber wird, was eigentlich das Ziel war
• Lasst die Ursachenanalyse bei einem reibungslosen Projektreview weg oder kürzt sie, und nehmt euch bei Incidents, bei denen es um Vorbeugung geht, mehr Zeit dafür
• Priorisiert per Abstimmung und beendet das Meeting nicht, bevor die wichtigsten Maßnahmen Verantwortliche und Fristen haben, sonst bleiben eure Lessons Learned graue Theorie
• Bringt die Maßnahmen aus dem letzten Post-Mortem mit und geht sie als Erstes durch. Nichts verbessert die Umsetzung so sehr wie das Wissen, dass nachgefragt wird

Häufig gestellte Fragen