Lessons Learned im Projektmanagement: Vorlage und Prozess

Lessons Learned sind die dokumentierten Erkenntnisse, die ein Projektteam darüber erfasst, was gut lief, was nicht und was es beim nächsten Mal anders machen würde. Die meisten Projekte erheben sie. Weit weniger nutzen sie tatsächlich beim nächsten Projekt.

Diese Lücke zwischen Dokumentieren und Anwenden ist der Ort, an dem die meisten organisatorischen Werte verloren gehen. Dieser Leitfaden führt durch den gesamten Prozess: wann erfassen, was erfassen, wie die Sitzung durchführen und wie sicherstellen, dass die Ergebnisse die Menschen erreichen, die sie beim nächsten Mal brauchen.

Was sind Lessons Learned?

Lessons Learned sind strukturierte Aufzeichnungen des Wissens, das während eines Projekts gewonnen wurde. Sie umfassen sowohl positive Erkenntnisse (Praktiken, die funktioniert haben und wiederholt werden sollten) als auch negative Erkenntnisse (Probleme, die aufgetreten sind und verhindert werden sollten). Das Ziel ist nicht, Schuldige zu suchen. Es geht darum, künftigen Projektteams einen Vorsprung zu verschaffen.

Ein vollständiger Lessons-Learned-Datensatz erfasst nicht nur, was passiert ist, sondern auch warum es passiert ist und was ein Team anders tun sollte. Diese Tiefe ist es, die nützliches institutionelles Wissen von einer Liste von Beschwerden unterscheidet, die beim Projektabschluss abgelegt und nie wieder geöffnet werden.

Lessons Learned unterscheiden sich von einer Sprint-Retrospektive im Umfang: Retrospektiven sind kurze, sprintspezifische Zeremonien; Lessons Learned erstrecken sich über das gesamte Projekt und fließen oft in organisatorische Prozess-Assets ein, die von Teams genutzt werden, die nicht Teil des ursprünglichen Projekts waren.

Wichtige Fakten

• PMI-Forschung ergab, dass Organisationen, die Lessons Learned konsequent erfassen und anwenden, mehr Projekte pünktlich und im Budget abschließen als jene, die das nicht tun. Dennoch hat weniger als die Hälfte der Organisationen einen formalen Prozess dafür.
• Ein weit verbreitetes Ergebnis aus der IT-Projektforschung besagt, dass etwa 70 % der Projekte Fehler aus früheren Projekten wiederholen, weil das beim Abschluss erfasste Wissen bei der Initiierung nie konsultiert wurde.
• Der Project Management Body of Knowledge (PMBOK Guide) klassifiziert Lessons-Learned-Register als organisatorische Prozess-Assets, was bedeutet, dass sie erwartet werden, in die Art und Weise zurückzufließen, wie eine Organisation künftige Arbeit plant und ausführt.

Wann Lessons Learned erfassen

Der häufigste Fehler ist, Lessons Learned als einmaliges Ereignis am Projektende zu behandeln. Wenn Sie den Abschluss erreichen, sind viele wichtige Details bereits verblasst. Effektive Teams erfassen sie kontinuierlich und konsolidieren sie dann bei wichtigen Meilensteinen.

Wenn Ihr Team agile Methoden einsetzt, fließt jede Sprint-Retrospektive direkt in das Lessons-Learned-Register ein. Sie leisten diese Arbeit bereits. Der Unterschied ist, ob dieses Wissen in einem Format erfasst wird, das über die Erinnerung des aktuellen Teams hinaus Bestand hat.

Lesen Sie den vollständigen Projektlebenszyklus, um zu verstehen, wie diese Phasen miteinander verbunden sind.

Was erfassen

Das Format eines Lessons-Learned-Eintrags ist entscheidend. Eine vage Notiz wie "Stakeholder-Kommunikation war schwierig" hat für das nächste Projekt fast keinen Wert. Ein strukturierter Eintrag schon.

Die Felder "Grundursache" und "Empfehlung" sind dort, wo die meisten Teams vage bleiben. Streben Sie nach Spezifität. "Zu Beginn der ersten Woche eine Stakeholder-Mapping-Übung mit der RACI-Vorlage durchführen" ist nützlich. "Besser kommunizieren" nicht.

Zur Strukturierung stakeholderbezogener Erkenntnisse bietet die RACI-Matrix ein konkretes Framework für Rollenklarheitsprobleme, die häufig als wiederkehrende Lessons Learned auftauchen.

Wie man eine Lessons-Learned-Sitzung durchführt

Eine 60- bis 90-minütige moderierte Sitzung beim Projektabschluss ist das Standardinstrument zur Erfassung konsolidierter Erkenntnisse. So führen Sie eine durch, die verwertbare Ergebnisse liefert.

Schritt 1: Vorbereitung

Versenden Sie zwei bis drei Tage vor der Sitzung eine kurze Umfrage. Bitten Sie die Teilnehmer, mit zwei bis drei konkreten Beispielen in jeder Kategorie zu kommen: Was gut lief, was verbessert werden sollte und was sie von Anfang an anders gemacht hätten. Das verhindert Denkpausen in der Besprechung und gibt ruhigeren Teammitgliedern Zeit, ihre Gedanken zu formulieren.

Ziehen Sie relevante Daten aus dem Projekt heran: Terminplanabweichung, Kostenabweichung, Volumen des Änderungsprotokolls, RAID-Log-Einträge und etwaige Eskalationen. Zahlen geben dem Gespräch einen Anker.

Schritt 2: Input sammeln

Eröffnen Sie die Sitzung mit Grundregeln. Dies ist keine Leistungsbeurteilung. Das Ziel ist Prozessverbesserung, keine Schuldzuweisung. Anonyme Vorab-Inputs können helfen, wenn das Team über heikle Dynamiken verfügt.

Verwenden Sie eine einfache Struktur zur Erfassung von Input: "Was sollten wir anfangen, aufhören und weiter tun?" Oder adaptieren Sie das Retro-Format: "Was lief gut / was lief nicht / was tun wir als Nächstes?" Beides funktioniert. Die Spezifität ist wichtiger als das Format.

Schritt 3: Die Diskussion moderieren

Fassen Sie ähnliche Inputs zusammen, um repetitive Diskussionen zu vermeiden. Fragen Sie bei jedem geclusterten Thema nach der Grundursache. "Der Umfang änderte sich ständig" ist ein Ausgangspunkt, keine Erkenntnis. Tiefer graben: War der Kommunikationsplan unklar, wer Änderungsbefugnis hat? Fehlte in dem Projekt-Kickoff-Meeting eine Umfangs-Einfrierungsvereinbarung?

Widmen Sie den Punkten, die das Team als hochgradig wichtig einstuft, mehr Zeit. Nicht jede Erkenntnis verdient gleich viel Aufmerksamkeit.

Schritt 4: In Echtzeit dokumentieren

Weisen Sie eine Person zu, die strukturierte Einträge während der Sitzung erfasst, nicht danach. Das spätere Warten führt zu Lücken und der natürlichen Tendenz, die Sprache abzumildern. Jeder Eintrag sollte enthalten: Kategorie, was passiert ist, Auswirkung, Grundursache und Empfehlung.

Streben Sie bei einem vollständigen Projekt 10 bis 20 substantielle Einträge an. Mehr als 30 deutet darauf hin, dass Sie Rauschen zusammen mit dem Signal erfassen.

Schritt 5: Teilen und anwenden

Ein Lessons-Learned-Dokument, das auf einem Netzlaufwerk liegt, das niemand besucht, ist kein organisatorisches Asset. Es ist ein Schuldbekenntnis.

Machen Sie Erkenntnisse auffindbar. Versehen Sie sie mit Tags nach Projekttyp, Branche, Methodik und Phase. Wenn Ihre Organisation ein Projektmanagement-Tool oder eine Wissensdatenbank verwendet, verknüpfen Sie das Register aus der Projektabschluss-Checkliste, damit der nächste Projektmanager es während der Planung findet.

Noch besser: Weisen Sie einem Verantwortlichen zu, bestehende Erkenntnisse bei der Projektinitiierung zu überprüfen und die fünf relevantesten Einträge in das Risikoregister des neuen Projekts einzuarbeiten.

Lessons-Learned-Vorlage

Nutzen Sie diese Struktur als Ausgangspunkt. Passen Sie die Kategorieliste an die häufigen Fehlerquellen Ihrer Organisation an.

Speichern Sie dies als gemeinsame Tabelle, als Seite in Ihrem Projekt-Wiki oder als dedizierten Abschnitt in Ihrer Projektmanagement-Plattform. Das Format ist weniger wichtig als die Disziplin, es zu nutzen.

Lessons-Learned-Beispiel

Hier sind drei ausgefüllte Einträge aus häufigen Projektmustern:

Jeder dieser Einträge ist spezifisch genug, dass ein Projektmanager bei einem künftigen ähnlichen Projekt sofort darauf handeln kann.

Best Practices

Vorwurfsfrei gestalten. In dem Moment, in dem Lessons-Learned-Sitzungen mit der Verantwortlichkeit für Fehler in Verbindung gebracht werden, hören die Menschen auf, ehrlich beizutragen. Rahmen Sie jede Sitzung rund um Prozesse und Systeme, nicht rund um Einzelpersonen. Wenn eine Person einen Fehler gemacht hat, lautet die Systemfrage: Welcher Prozess hätte diesen Fehler erkannt oder verhindert?

Auffindbar machen. Erkenntnisse, die in einem Projektordner gespeichert sind, der am ersten Tag des Abschlusses archiviert wird, sind nicht nützlich. Versehen Sie Einträge mit durchsuchbaren Metadaten (Projekttyp, Technologie, Abteilung, Methodik). Das Ziel ist, dass ein Projektmanager, der ein ähnliches Projekt startet, die fünf relevantesten Erkenntnisse innerhalb von fünf Minuten findet.

Tatsächlich wiederverwenden. Die Disziplin, die leistungsstarke Projektorganisationen von den anderen unterscheidet, ist einfach: Bestehende Erkenntnisse bei der Initiierung überprüfen, nicht beim Abschluss. Bauen Sie einen Überprüfungsschritt in Ihren Projektauftrag oder Ihre Kickoff-Checkliste ein. Ziehen Sie drei bis fünf relevante Erkenntnisse heraus und dokumentieren Sie sie in der Planungsphase als bekannte Risiken oder Prozesskompromisse.

Häufige Fehler

Abgelegt und vergessen. Der häufigste Fehlerfall: Ein Lessons-Learned-Dokument wird beim Abschluss erstellt, irgendwo sinnvoll abgelegt und nie wieder referenziert. Das nächste Team erfindet dieselben Räder neu. Die Lösung ist strukturell: Bauen Sie die Überprüfung von Erkenntnissen als obligatorischen Schritt, nicht als optionalen, in den Projektstart ein.

Nur Negatives erfassen. Teams neigen dazu, sich auf das zu konzentrieren, was schiefgelaufen ist. Aber positive Erkenntnisse sind ebenso wertvoll. Wenn eine bestimmte Schätztechnik, Lieferantenbeziehung oder Kommunikationskadenz ungewöhnlich gut funktioniert hat, dokumentieren Sie das, damit das nächste Team es bewusst wiederholen kann.

Bis zum Abschluss warten. Am Projektende haben sich die Menschen gedanklich bereits weiterentwickelt. Details verblassen. Das Team befindet sich möglicherweise nicht mehr im selben Raum. Das Erfassen von Erkenntnissen an Phasengrenzen und nach wichtigen Ereignissen bewahrt die Genauigkeit. Ein laufend aktualisiertes Protokoll über das gesamte Projekt hinweg erfordert fünf Minuten pro Eintrag und liefert weit reichhaltigere Ergebnisse als eine einstündige Sitzung sechs Monate später.

Allgemeine Sprache. "Kommunikation könnte besser sein" hilft niemandem. Jeder Eintrag sollte spezifisch genug sein, dass jemand, der nicht am Projekt beteiligt war, verstehen kann, was passiert ist, warum und was genau anders gemacht werden sollte.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Lessons Learned und einer Sprint-Retrospektive? Eine Sprint-Retrospektive ist eine agile Zeremonie, die am Ende jedes Sprints stattfindet, typischerweise 30 bis 90 Minuten, und sich darauf konzentriert, wie das Team während dieser spezifischen Iteration zusammengearbeitet hat. Lessons Learned sind eine umfassendere Projektmanagement-Praktik, die den gesamten Projektlebenszyklus umfasst und oft in organisatorische Wissensbasen einfließt, die von künftigen Teams genutzt werden. In der Praxis sind Sprint-Retrospektiven ein hervorragender Input für ein Lessons-Learned-Register, aber kein Ersatz für die Konsolidierungssitzung am Projektende.

Wer ist für Lessons Learned in einem Projekt verantwortlich? Der Projektmanager ist in der Regel für den Prozess verantwortlich: Die Sitzung planen, sicherstellen, dass die Dokumentation stattfindet, und das abschließende Register an den Ort weiterleiten, an dem die Organisation Projektwissen speichert. Die Verantwortung für einzelne Einträge sollte jedoch verteilt werden. Jeder Teamleiter oder Funktionsverantwortliche sollte für Einträge in seinem Bereich verantwortlich sein. Eine einzige Person, die versucht, alles für ein großes Projekt zu dokumentieren, wird unvollständige und qualitativ minderwertige Aufzeichnungen produzieren.

Wann sollten Lessons-Learned-Sitzungen stattfinden? Mindestens einmal beim Projektabschluss. Bei längeren Projekten sollten kurze Sitzungen an jedem Phasentor oder wichtigen Meilenstein stattfinden. Agile Teams sollten jede Sprint-Retrospektive als Mini-Lessons-Learned-Sitzung behandeln und die wichtigsten Erkenntnisse am Ende des Releases oder Projekts konsolidieren.

Gelten Lessons Learned für agile Projekte? Ja. Die Sprint-Retrospektive ist das agile Äquivalent einer Lessons-Learned-Sitzung. Der Unterschied liegt in Kadenz und Formalität. Agile Teams führen Retrospektiven jeden Sprint durch; traditionelle Projekte führen sie an Phasentoren und beim Abschluss durch. Für Organisationen, die sowohl agile als auch Waterfall-Projekte durchführen, ist ein gemeinsames Lessons-Learned-Repository, das Input aus beiden Formaten akzeptiert, der effizienteste Ansatz.

Wie lang sollte ein Lessons-Learned-Dokument sein? Lang genug, um nützlich zu sein, kurz genug, um gelesen zu werden. Ein typisches Projekt generiert 10 bis 25 Einträge. Ein sehr großes, komplexes Programm könnte 50 produzieren. Vermeiden Sie Auffüllung. Jeder Eintrag sollte einen Test bestehen: Würde ein Projektmanager bei einem ähnlichen künftigen Projekt das als spezifisch genug empfinden, um darauf zu handeln?

---

Lessons Learned schaffen nur dann Wert, wenn sie den Kreislauf schließen: erfasst, irgendwo auffindbar gespeichert und beim Start eines neuen ähnlichen Projekts überprüft. Die Sitzung und die Vorlage sind der einfache Teil. Die Gewohnheit aufzubauen, neue Projekte mit einer Überprüfung vergangener Erkenntnisse zu beginnen, ist der schwierige Teil und derjenige, der tatsächlich die Ergebnisse verändert.

Einen umfassenderen Blick darauf, wie Lessons Learned in die formale Projektmanagementstruktur passen, bietet das Projektmanagement-Büro (PMO), das typischerweise die organisatorische Prozess-Asset-Bibliothek besitzt, in der diese Register gespeichert werden.