Lessons Learned: Bedeutung, Methode in 5 Schritten und Vorlage

Am Ende eines Projekts sitzt das Team zusammen, klebt Zettel an die Wand und ist sich einig: Beim nächsten Mal reden wir früher mit der IT. Ein halbes Jahr später startet das nächste Projekt, und an den Zettel erinnert sich niemand mehr. Dieser Ratgeber erklärt Begriff und Abgrenzung, zeigt fünf Schritte zu Erkenntnissen, die wirklich genutzt werden, und gibt dir Fragen und eine Vorlage zum Kopieren.

Was bedeutet Lessons Learned?

Lessons Learned (britisch Lessons Learnt) heißt wörtlich „gelernte Lektionen“. Die deutsche Wikipedia übersetzt den Begriff mit „gewonnene Erkenntnisse“ und ordnet ihn dem Projektmanagement und dem Wissensmanagement zu. Gemeint ist das systematische Sammeln, Bewerten und Verdichten von Erfahrungen, Hinweisen, Fehlern und Risiken aus Projekten, damit ähnliche Vorhaben davon profitieren. Das Wort steht für die einzelne Erkenntnis, die Methode und das Treffen, in dem sie entsteht.

Eine strengere Definition nutzen die Raumfahrtagenturen NASA, ESA und JAXA: Eine Lesson Learned ist Wissen oder Verständnis, das durch Erfahrung gewonnen wurde, durch einen Erfolg ebenso wie durch einen Fehlschlag. Damit sie zählt, muss sie drei Bedingungen erfüllen:

• Bedeutsam: Sie hat tatsächliche oder absehbare Auswirkungen auf die Arbeit.
• Zutreffend: Sie ist sachlich und fachlich richtig.
• Anwendbar: Sie benennt eine konkrete Entscheidung, einen Ablauf oder eine Gestaltung, die einen Fehler künftig verhindert oder einen Erfolg wiederholbar macht.

Diese drei Prüffragen helfen später beim Auswerten. Und sie zeigen den Unterschied zur Projektdokumentation: Die Dokumentation beschreibt, was passiert ist. Die Lesson Learned sagt, was man daraus beim nächsten Mal macht. Lessons Learned sind damit eine der einfachsten Methoden im Wissensmanagement, weil sie an einen Termin gebunden sind, den es ohnehin gibt: das Projektende.

Lessons Learned, Retrospektive, After Action Review und Post Mortem

Viele Teams machen Lessons Learned, ohne es so zu nennen. Die Formate ähneln sich, unterscheiden sich aber in Zeitpunkt, Teilnehmenden und Ziel.

Retrospektive: Der Scrum Guide beschreibt die Sprint-Retrospektive als Abschluss jedes Sprints. Das Team prüft, wie es mit Personen, Zusammenarbeit, Prozessen und Werkzeugen lief, was gut ging, welche Probleme auftraten und ob sie gelöst wurden. Bei einem Sprint von einem Monat dauert sie höchstens drei Stunden, die wirksamsten Verbesserungen werden so bald wie möglich umgesetzt.

After Action Review: Das Format wurde von der US Armee entwickelt und verläuft in vier Schritten: Ziel klären, Ablauf rekonstruieren, Soll und Ist vergleichen, Lehren zusammenfassen. Schuldzuweisungen widersprechen dem Zweck, jede Person schaut auf ihr eigenes Handeln.

Post Mortem: Es sucht die Ursachen eines Fehlschlags oder Ausfalls, während eine Retrospektive laut englischer Wikipedia Positives und Negatives bespricht.

Der wichtigste Unterschied: Eine Retrospektive verbessert die Arbeit desselben Teams im nächsten Sprint. Lessons Learned sollen auch Menschen nützen, die beim Projekt nicht dabei waren. Deshalb sind Aufschreiben und Ablegen hier so entscheidend.

Wann du Lessons Learned erheben solltest

• Am Projektende: der klassische Zeitpunkt. Laut Wikipedia können Lessons Learned Teil der Projektabschlussdokumentation sein.
• Nach Phasen und Meilensteinen: bei längeren Projekten. Asana empfiehlt, die Umfrage direkt nach dem Abschluss oder am Ende einer wichtigen Phase zu verschicken, solange die Erinnerung frisch ist.
• Zu Beginn eines neuen Projekts: Hier werden Lessons Learned genutzt, nicht gesammelt. Wikipedia hält es für vorteilhaft, das Beachten der Lessons Learned früherer Projekte verbindlich vorzuschreiben.
• Bevor eine Schlüsselperson das Projekt verlässt: der Zeitpunkt, der am häufigsten fehlt. Wer mitten im Projekt geht, nimmt die eigene Sicht mit, und beim Abschlusstermin fehlt sie.

Lessons Learned in 5 Schritten

Die Schritte folgen dem Ablauf, den auch Asana beschreibt: identifizieren, dokumentieren, analysieren, speichern und abrufen.

1. Erfahrungen sammeln

Bewährt hat sich eine Kombination aus kurzer Umfrage vorab und gemeinsamem Treffen. Die Umfrage holt auch stille Stimmen ab, das Treffen vertieft. Asana rät, die Moderation nicht der Projektleitung zu geben, damit alle offen sprechen. Für die Planung hilft die Anleitung von Atlassian zur Retrospektive als Richtwert: etwa 15 Minuten Vorbereitung, 60 Minuten Treffen, 4 bis 8 Personen.

2. Konkret aufschreiben

„Kommunikation verbessern“ ist keine Lesson Learned, sondern ein Wunsch. Eine brauchbare Erkenntnis beschreibt die Situation, was passiert ist, warum es passiert ist und was beim nächsten Mal anders läuft. Zum Beispiel: „Bei Projekten mit neuer Software die IT in der ersten Woche einbinden, weil die Freigabe der Zugänge sonst den Start verzögert.“ Notiere auch, was gut lief. Nach der Definition von NASA, ESA und JAXA zählen Erfolge genauso wie Fehler.

3. Auswerten und verdichten

Fasse doppelte Punkte zusammen und prüfe jeden mit den drei Fragen: bedeutsam, zutreffend, anwendbar? Atlassian rät, sich nicht an einmaligen Fehlern oder Glücksfällen festzubeißen, die auf künftige Arbeit keinen Einfluss haben. Wenige Erkenntnisse, die etwas verändern, sind das Ziel.

4. Ablegen, wo andere suchen

Eine Erkenntnis, die in einem persönlichen Ordner liegt, ist für das nächste Team verloren. Lege Lessons Learned an einem festen Ort ab, zum Beispiel in einer Projektdatenbank oder im Teamlaufwerk, und versieh sie mit Stichworten wie Projektart, Thema und Abteilung. Überlege, was dort hineingehört: Kritische Anmerkungen auf der Beziehungsebene sind für Folgeprojekte wertvoll, finden laut Wikipedia aber kaum den Weg in eine Datenbank, auf die das ganze Unternehmen zugreift.

5. Im nächsten Projekt anwenden

Der Schritt, der am häufigsten fehlt. Jede Erkenntnis braucht eine zuständige Person und einen Ort, an dem sie etwas ändert: eine Checkliste, eine Projektvorlage, eine Arbeitsanweisung oder eine Prozessbeschreibung. Erst wenn die Erkenntnis dort steht, wo die Arbeit passiert, wird aus einer Lesson Learned eine bessere Arbeitsweise.

Fragen für den Lessons-Learned-Workshop

Den Kern bilden drei Fragen, die auch Asana nennt: Was ist gut gelaufen? Was ist schlecht gelaufen? Wo gibt es Verbesserungspotenzial? Eine Variante aus der Retrospektive ist die 4L-Methode: Was hat das Team gemocht, was nicht gemocht, was gelernt und was hätte es sich gewünscht? Für ein Projekt lohnt es sich, tiefer zu fragen:

• Haben wir das Ziel erreicht? Wo weicht das Ergebnis vom Plan ab, und warum?
• Welche Entscheidung würden wir heute anders treffen?
• Wo haben wir auf etwas gewartet, und auf wen?
• Welche Annahme zu Beginn hat sich als falsch erwiesen?
• Welches Werkzeug oder welche Vorlage hat geholfen, welche hat gestört?
• Welches Wissen hatte nur eine Person, und wo steht es jetzt?
• Was sollte das nächste Team als Erstes wissen?
• Was davon übernehmen wir in Vorlagen, Checklisten oder Abläufe, und wer kümmert sich darum?

Lessons-Learned-Vorlage

Kopiere die Tabelle in dein Dokument oder deine Tabellenkalkulation. Über die Tabelle gehören Projektname, Zeitraum, Teilnehmende, Datum und Moderation. Die beiden Zeilen sind frei erfundene Beispiele und zeigen, wie konkret ein Eintrag sein sollte.

Die letzte Spalte ist die wichtigste. Bleibt sie leer, ist die Erkenntnis zwar aufgeschrieben, aber noch nicht gelernt.

Typische Fehler bei Lessons Learned

• Schuldige suchen: Sobald es um Schuld geht, sagen die Leute nur noch das Nötigste. Beim After Action Review widersprechen Schuldzuweisungen ausdrücklich dem Zweck.
• Zu allgemein bleiben: „Besser planen“ ändert nichts. Jede Erkenntnis braucht eine konkrete Empfehlung.
• Ablegen ohne Anwenden: Ohne Schritt 5 ist das Archiv ein Friedhof guter Absichten.
• Die wichtigsten Leute fehlen: Wer das Projekt früher verlassen hat, fehlt im Workshop, und mit ihm genau die Erfahrungen aus den schwierigsten Phasen.

Wenn die Erfahrung mit der Person geht

Lessons Learned halten fest, was ein Team gemeinsam aus einem Projekt gelernt hat. Was sie nicht erfassen, ist, wie eine einzelne Person ihre Arbeit macht: der Kniff bei der Abrechnung, welcher Lieferant auf welchem Weg zurückruft, welche Ausnahmen es gibt. Dieses Wissen ist oft implizites Wissen, das in keinem Workshop von selbst zur Sprache kommt.

Verlässt eine Schlüsselperson das Unternehmen, reicht ein Lessons-Learned-Termin deshalb nicht. Dann geht es um einen geordneten Wissenstransfer und ein Übergabedokument für die Nachfolge. Geht jemand mitten im Projekt, lohnt sich vor dem letzten Arbeitstag zusätzlich ein kurzes Einzelgespräch im Stil von Lessons Learned: Was würdest du deiner Nachfolge im Projekt raten? Welche Entscheidungen sind offen? Wen muss man kennen? Das ist etwas anderes als das Austrittsgespräch, in dem es um die Gründe für den Weggang geht.

Fazit

Lessons Learned sind schnell gesammelt und schnell vergessen. Damit sie wirken, brauchen sie konkrete Formulierungen, einen festen Ablageort und vor allem Schritt 5: eine Person, die die Erkenntnis dorthin bringt, wo die Arbeit passiert. Plane den Termin, solange alle noch da sind, frag nach Gutem und Schlechtem, und denk an die Menschen, die das Projekt vorher verlassen. Ihre Erfahrung kommt im Abschlussworkshop sonst nicht mehr vor.