Lessons Learned im Projektmanagement: Methoden, Prozess und Praxistipps

Was sind Lessons Learned?

Lessons Learned bezeichnen das strukturierte Sammeln, Bewerten und Anwenden von Erfahrungen aus einem Projekt. Der Begriff lässt sich mit „gewonnene Erkenntnisse” oder „gelernte Lektionen” übersetzen – gemeint ist immer dasselbe: Aus dem, was im Projekt passiert ist, soll systematisch gelernt werden.

Dabei geht es ausdrücklich um beide Seiten: Was hat gut funktioniert und sollte beibehalten werden? Und was ist schiefgelaufen und darf sich nicht wiederholen? Beides liefert wertvolle Hinweise für zukünftige Projekte – vorausgesetzt, die Erkenntnisse werden nicht nur gesammelt, sondern tatsächlich angewendet.

In agilen Projekten ist die Retrospektive das Pendant zu Lessons Learned. Sie verfolgt dieselbe Idee, findet aber regelmäßig am Ende jedes Sprints statt, statt erst am Projektende. Unabhängig vom methodischen Rahmen ist der Grundgedanke identisch: Wer nicht aus Erfahrungen lernt, wiederholt seine Fehler.

Warum sind Lessons Learned wichtig?

Projekte sind komplex. Selbst bei sorgfältiger Projektplanung treten unerwartete Situationen auf – Kommunikationsprobleme, unterschätzte Risiken, technische Hürden oder organisatorische Reibungsverluste. Diese Erfahrungen sind wertvoll, aber nur dann, wenn sie über das einzelne Projekt hinaus genutzt werden.

Lessons Learned leisten dafür einen konkreten Beitrag:

• Fehler nicht wiederholen. Was in einem Projekt schiefgelaufen ist, muss im nächsten nicht erneut passieren. Dokumentierte Erkenntnisse geben dem neuen Projektteam einen Wissensvorsprung.
• Bewährtes fortführen. Erfolgreiche Ansätze – eine bestimmte Meeting-Struktur, ein bewährtes Tool, eine funktionierende Rollenverteilung – können gezielt auf Folgeprojekte übertragen werden.
• Wissenstransfer sicherstellen. In vielen Unternehmen steckt Projektwissen in den Köpfen einzelner Personen. Lessons Learned machen dieses Wissen explizit und unabhängig von einzelnen Mitarbeitern verfügbar.
• Risiken frühzeitig erkennen. Wer die dokumentierten Erkenntnisse vergangener Projekte kennt, kann typische Risiken bereits in der Planungsphase identifizieren und gegensteuern.
• Fehlerkultur fördern. Ein offener Umgang mit Fehlern ist die Grundlage für organisationales Lernen. Lessons Learned schaffen den Rahmen dafür – wenn sie richtig durchgeführt werden.

Wann sollten Lessons Learned durchgeführt werden?

Die naheliegende Antwort: am Projektende, als Teil des Projektabschlusses. Das ist richtig, aber nicht ausreichend.

Am Projektende sind Lessons Learned Pflicht. Das Projekt wird als Ganzes reflektiert, die wichtigsten Erkenntnisse werden gesichert. Der Nachteil: Liegt das Projekt Monate zurück, sind viele Details bereits verblasst.

Nach Meilensteinen oder Phasenübergängen sind kurze Reflexionsrunden deutlich wirkungsvoller. Die Erinnerungen sind frisch, und Verbesserungen können noch im laufenden Projekt umgesetzt werden. Schon eine halbe Stunde nach jedem größeren Meilenstein reicht aus.

Laufend empfiehlt sich ein einfaches Erkenntnisprotokoll – ein Log-Buch, eine geteilte Liste oder ein Kanal im Projektmanagement-Tool. Teammitglieder halten bemerkenswerte Situationen kurz fest, sobald sie auftreten. Das kostet wenig Aufwand und liefert eine solide Grundlage für den späteren Workshop.

In agilen Projekten sind regelmäßige Retrospektiven bereits im Prozess verankert – etwa als Sprint-Retrospektive in Scrum. Hier findet der Lernzyklus kontinuierlich statt, was einer der großen Vorteile agiler Methoden ist.

Wer sollte beteiligt sein?

An einem Lessons-Learned-Workshop sollten die Personen teilnehmen, die zum Projektverlauf relevante Aussagen treffen können. Das sind typischerweise:

• Der Projektleiter – verantwortlich für die Durchführung und die Umsetzung der Ergebnisse.
• Das Kernteam – idealerweise drei bis zehn Personen aus verschiedenen Projektbereichen, um unterschiedliche Perspektiven einzufangen.
• Ein neutraler Moderator – keine Pflicht, aber empfehlenswert. Eine projektfremde Person kann offener moderieren und verhindert, dass Hierarchien die Diskussion verzerren.
• Relevante Stakeholder – optional, aber hilfreich, wenn Außenperspektiven für die Reflexion wichtig sind.

Bei größeren Projekten bewährt sich ein zweistufiges Vorgehen: Ein breiterer Kreis füllt vorab einen Fragebogen aus, die eigentliche Workshop-Diskussion findet in einer fokussierten Gruppe statt. So werden viele Perspektiven erfasst, ohne den Workshop zu überladen.

Der Lessons-Learned-Prozess in 5 Schritten

Ein strukturierter Prozess stellt sicher, dass Lessons Learned nicht beim Sammeln stehen bleiben, sondern tatsächlich in die Organisation zurückfließen. Der folgende Ablauf orientiert sich am Modell des PMI (Project Management Institute).

1. Identifizieren

Im ersten Schritt werden die Erkenntnisse gesammelt. Das geschieht idealerweise in einem Workshop, kann aber auch über Fragebögen, Einzelgespräche oder ein projektbegleitendes Log-Buch erfolgen.

Entscheidend ist die Fragestellung. „Was war gut, was war schlecht?” klingt naheliegend, liefert aber oft oberflächliche Antworten. Bessere Ergebnisse erzielen Sie mit strukturierten Methoden, die gezielte Reflexion ermöglichen (siehe Abschnitt Bewährte Methoden).

Wichtig: Trennen Sie Fakten von Bewertungen. Erst wird gesammelt, was passiert ist – die Analyse folgt im dritten Schritt.

2. Dokumentieren

Alle Erkenntnisse werden strukturiert festgehalten und zielgruppengerecht aufbereitet. Ein ausführliches Workshop-Protokoll für das Projektteam hat einen anderen Detailgrad als eine Zusammenfassung für die Geschäftsführung.

Achten Sie auf eine klare Struktur: Welches Thema wurde besprochen? Was war die Erkenntnis? Welche Maßnahme wurde abgeleitet? Wer ist verantwortlich? Bis wann? Je konkreter die Dokumentation, desto höher die Wahrscheinlichkeit, dass die Erkenntnisse tatsächlich umgesetzt werden.

3. Analysieren

Die gesammelten Erkenntnisse werden auf Muster und Ursachen untersucht. Gibt es Themen, die besonders häufig genannt wurden? Wo besteht der größte Handlungsbedarf? Sind die identifizierten Probleme projektspezifisch oder systemisch?

Für komplexere Themen bieten sich Methoden wie die 5-Why-Analyse an, um den eigentlichen Ursachen auf den Grund zu gehen. Aus der Analyse werden konkrete Maßnahmen abgeleitet – mit Verantwortlichen, Terminen und messbaren Ergebnissen.

4. Speichern

Erkenntnisse, die nur auf einem Flipchart oder in einer E-Mail existieren, sind für die Organisation verloren. Lessons Learned müssen zentral und durchsuchbar abgelegt werden – in einer Wissensdatenbank, einem Projektmanagement-Tool oder zumindest in einer strukturierten Ablage.

Entscheidend ist nicht das Format, sondern die Auffindbarkeit: Kann ein Projektleiter, der ein ähnliches Projekt startet, die relevanten Erkenntnisse mit wenigen Klicks finden?

5. Zugänglich machen

Der letzte Schritt ist der schwierigste – und der wichtigste. Gespeichertes Wissen nützt nichts, wenn es niemand findet oder nutzt. Zwei Voraussetzungen müssen erfüllt sein:

Systeme: Die Informationen müssen leicht zugänglich und durchsuchbar sein. Idealerweise sind Lessons Learned direkt in die Tools integriert, die das Team ohnehin nutzt.

Prozesse: Es muss zur Routine werden, bei neuen Projekten die Erkenntnisse früherer Vorhaben zu prüfen. Das lässt sich zum Beispiel als fester Punkt in der Projektstart-Checkliste verankern.

Bewährte Methoden für Lessons Learned

Je nach Teamgröße, verfügbarer Zeit und Reflexionsziel eignen sich unterschiedliche Methoden. Die folgenden fünf haben sich in der Praxis bewährt.

5-Finger-Methode

Jeder Finger steht für eine Reflexionsfrage:

• Daumen: Was lief gut?
• Zeigefinger: Was sollten wir beibehalten?
• Mittelfinger: Was hat nicht funktioniert?
• Ringfinger: Was nehme ich mit?
• Kleiner Finger: Was kam zu kurz?

Die Methode eignet sich besonders für schnelle Reviews nach einzelnen Phasen oder Meetings. Sie ist intuitiv, braucht keine Vorbereitung und liefert dennoch differenziertere Ergebnisse als eine einfache Gut/Schlecht-Abfrage.

Starfish-Methode

Die Starfish-Methode unterteilt Erkenntnisse in fünf Kategorien:

• Start doing: Was sollten wir neu einführen?
• More of: Was hat sich bewährt und sollte verstärkt werden?
• Less of: Was sollten wir reduzieren?
• Stop doing: Was hat sich als ineffektiv erwiesen?
• Keep doing: Was sollten wir unverändert fortführen?

Diese Struktur zwingt dazu, nicht nur Probleme zu benennen, sondern auch konkrete Handlungsrichtungen abzuleiten. Die Methode lässt sich gut auf einem Whiteboard oder in einem digitalen Kollaborationstool visualisieren.

4L-Methode

Die 4L-Methode gliedert die Reflexion in vier persönliche Perspektiven:

• Liked: Was hat gut funktioniert?
• Learned: Welche neuen Erkenntnisse habe ich gewonnen?
• Lacked: Was hat gefehlt?
• Longed for: Was hätte das Projekt verbessert?

Besonders für kleinere Teams oder individuelle Reflexionen geeignet, weil sie eine persönliche Perspektive ermöglicht und zum Nachdenken über den eigenen Beitrag anregt.

Mad-Sad-Glad

Diese Methode erfasst die emotionale Dimension eines Projekts:

• Mad: Was hat zu Frustration geführt?
• Sad: Was war enttäuschend?
• Glad: Was war positiv und motivierend?

Emotionen werden im Projektmanagement häufig ausgeklammert. Dabei liefern sie wichtige Signale: Wo das Team frustriert war, liegen fast immer strukturelle Probleme. Mad-Sad-Glad macht diese Signale sichtbar und besprechbar.

After-Action-Review (AAR)

Der After-Action-Review stammt aus dem US-Militär und folgt vier Leitfragen:

1. Was war geplant?
2. Was ist tatsächlich passiert?
3. Warum gab es Abweichungen?
4. Was lernen wir daraus?

Der strukturierte Abgleich von Plan und Realität macht den AAR besonders wertvoll für Projekte mit klar definierten Zielen und messbaren Ergebnissen. In Kombination mit einem Soll-Ist-Vergleich entsteht ein faktenbasiertes Bild des Projektverlaufs.

Typische Fehler und wie Sie sie vermeiden

Fünf Fehler begegnen in der Praxis immer wieder:

Lessons Learned nur am Projektende. Wenn seit dem kritischen Vorfall Monate vergangen sind, erinnert sich niemand mehr an die Details. Führen Sie kurze Reflexionsrunden auch während des Projekts durch – nach Meilensteinen, nach schwierigen Phasen, nach erfolgreichen Lieferungen.

Oberflächliche Fragestellung. „Was war gut, was war schlecht?” erzeugt oberflächliche Antworten. Verwenden Sie stattdessen eine der strukturierten Methoden aus dem vorherigen Abschnitt. Sie führen zu konkreteren und handlungsrelevanteren Erkenntnissen.

Fehlende psychologische Sicherheit. Wenn Teammitglieder befürchten, für offene Aussagen abgestraft zu werden, sagen sie nur, was gehört werden möchte. Vereinbaren Sie klare Regeln: keine Schuldzuweisungen, keine Konsequenzen für ehrliches Feedback. Ein neutraler Moderator hilft dabei, den Rahmen zu schützen.

Ergebnisse ohne Umsetzung. Die häufigste Schwachstelle: Erkenntnisse werden sauber dokumentiert – und dann vergessen. Jede Erkenntnis braucht eine konkrete Maßnahme mit Verantwortlichem und Zieltermin. Nur so wird aus einer Beobachtung eine Veränderung.

Kein zentraler Speicherort. Lessons Learned in E-Mails, auf Flipcharts oder in lokalen Dateien sind für die Organisation verloren. Nutzen Sie ein zentrales System, in dem Erkenntnisse gespeichert, durchsucht und mit Projekten verknüpft werden können.

Lessons Learned mit Software unterstützen

Der Lessons-Learned-Prozess lebt von Struktur und Nachverfolgbarkeit. Beides lässt sich mit einer Projektmanagement-Software deutlich besser umsetzen als mit Tabellen oder Textdokumenten.

Konkret hilft ein PM-Tool bei folgenden Aufgaben:

• Erkenntnisse erfassen: Teammitglieder können Beobachtungen direkt im Projekt festhalten – als Aufgabe, Kommentar oder in einem dedizierten Bereich.
• Maßnahmen nachverfolgen: Abgeleitete Aufgaben werden mit Verantwortlichen, Fristen und Status versehen. Nichts bleibt liegen.
• Wissen verknüpfen: Lessons Learned lassen sich mit konkreten Projekten, Phasen oder Arbeitspaketen verbinden – und sind so im Kontext auffindbar.
• Vorlagen nutzen: Wiederkehrende Workshop-Formate und Checklisten können als Vorlagen hinterlegt und bei jedem neuen Projekt wiederverwendet werden.

Häufig gestellte Fragen

Was bedeutet Lessons Learned?

Lessons Learned bedeutet „gewonnene Erkenntnisse” und bezeichnet das systematische Erfassen und Anwenden von Erfahrungen aus Projekten. Ziel ist es, aus positiven wie negativen Erlebnissen zu lernen und dieses Wissen für zukünftige Projekte nutzbar zu machen.

Was ist das Ziel von Lessons Learned?

Das Ziel ist die kontinuierliche Verbesserung der Projektarbeit. Konkret geht es darum, bereits gemachte Fehler nicht zu wiederholen, bewährte Ansätze gezielt fortzuführen und den Wissenstransfer zwischen Projekten und Teams sicherzustellen.

Wann sollte man Lessons Learned durchführen?

Idealerweise nicht nur am Projektende, sondern auch nach wichtigen Meilensteinen und Phasenübergängen. In agilen Projekten übernimmt die Sprint-Retrospektive diese Funktion. Zusätzlich empfiehlt sich ein laufendes Erkenntnisprotokoll während des gesamten Projekts.

Welche Methoden gibt es für Lessons Learned?

Bewährte Methoden sind die 5-Finger-Methode, die Starfish-Methode (Start/Stop/More/Less/Keep), die 4L-Methode (Liked/Learned/Lacked/Longed for), Mad-Sad-Glad und der After-Action-Review. Die Wahl der Methode hängt von Teamgröße, verfügbarer Zeit und Reflexionsziel ab.

Was ist der Unterschied zwischen Lessons Learned und Retrospektive?

Beide verfolgen dasselbe Ziel – aus Erfahrungen lernen und die Zusammenarbeit verbessern. Der Unterschied liegt im Kontext: Lessons Learned ist im klassischen Projektmanagement angesiedelt und findet typischerweise am Projektende statt. Die Retrospektive ist ein fester Bestandteil agiler Frameworks wie Scrum und wird regelmäßig am Ende jedes Sprints durchgeführt.