Viele Unternehmen führen Lessons-Learned-Workshops durch. Die Ergebnisse landen anschließend in einer Präsentation, auf SharePoint oder in einer Wissensdatenbank. Beim nächsten Projekt macht das Team trotzdem dieselben Fehler. Lessons Learned, die wirklich etwas bringen, funktionieren anders. Sie dokumentieren nicht nur Erfahrungen. Sie verändern Entscheidungen, Standards, Risiken und die Planung zukünftiger Projekte. Genau darin liegt der Unterschied zwischen „Erkenntnisse sammeln“ und organisationalem Lernen. Ein guter Lessons-Learned-Prozess beginnt deshalb nicht erst am Projektende. Er läuft während des gesamten Projekts und endet erst dann, wenn aus einer Erkenntnis eine konkrete Veränderung geworden ist.

Lessons Learned sind dokumentierte und bewertete Erfahrungen aus Projekten, die dazu genutzt werden, zukünftige Entscheidungen, Prozesse und Projekte zu verbessern.

Die Association for Project Management definiert sie ähnlich: Es handelt sich um dokumentierte Erfahrungen, die das zukünftige Management von Projekten, Programmen und Portfolios verbessern können. Gleichzeitig weist APM auf das Kernproblem vieler Unternehmen hin: Lessons werden zwar dokumentiert, aber nicht zuverlässig gelernt und in veränderte Arbeitsweisen übersetzt.

Eine echte Lesson Learned besteht deshalb nicht nur aus:

„Die Abstimmung mit dem Fachbereich war schwierig.“

Sie braucht mindestens:

Erst dann wird aus Erfahrung nutzbares Wissen.

Das typische Muster sieht so aus:

Am Ende des Projekts treffen sich zehn Personen.

Auf einem Whiteboard entstehen zwei Spalten:

Was lief gut?

Was lief schlecht?

Danach finden sich Aussagen wie:

Alles richtig.

Aber kaum eine Aussage beantwortet:

Was machen wir beim nächsten Projekt konkret anders?

Genau deshalb sollte zwischen einer Beobachtung und einer Lesson Learned unterschieden werden.

„Die Datenmigration hat deutlich länger gedauert.“

Die Datenqualität wurde erst während der Migration geprüft.

Datenqualität muss bei Migrationsprojekten bereits vor der finalen Terminplanung untersucht werden.

Jedes zukünftige Migrationsprojekt erhält einen verpflichtenden Data-Readiness-Check vor Freigabe der Baseline.

Jetzt entsteht organisationales Lernen.

Das klingt selbstverständlich.

In der Praxis ist es die wichtigste Regel überhaupt.

Eine Erkenntnis kann zu unterschiedlichen Veränderungen führen:

Die zentrale Frage nach jedem Lessons-Learned-Punkt lautet deshalb:

Wo wird diese Erkenntnis zukünftig sichtbar?

Wenn die Antwort nur lautet:

„In unserer Lessons-Learned-Datenbank“

ist die Organisation noch nicht fertig.

Einer der größten Fehler besteht darin, Lessons Learned ausschließlich als Abschlussaktivität zu betrachten.

PMI empfiehlt seit Langem einen anderen Ansatz:

früh und regelmäßig lernen.

Erkenntnisse sollten möglichst nah an der Situation erfasst werden, aus der sie entstanden sind. Also beispielsweise:

PMI beschreibt dafür einen einfachen Kreislauf: Erkenntnis erfassen, Verbesserungsmöglichkeit identifizieren, Änderung in den Projektprozess übernehmen und anschließend umsetzen.

Das hat einen entscheidenden Vorteil.

Das aktuelle Projekt profitiert bereits von seinem eigenen Lernen.

Ein Projekt stellt nach drei Monaten fest:

Abnahmen verzögern sich regelmäßig, weil der Fachbereich die Ergebnisse erst kurz vor dem Abnahmetermin sieht.

Eine klassische Vorgehensweise würde das am Projektende dokumentieren.

Eine lernende Organisation verändert sofort den Prozess:

Das Projekt verbessert sich bereits während der Laufzeit.

Das ist deutlich wertvoller als eine spätere PowerPoint-Folie.

Beginne nicht mit allgemeinen Meinungen.

Frage:

Was ist tatsächlich passiert?

Zum Beispiel:

Konkrete Ereignisse lassen sich analysieren.

Aussagen wie „Kommunikation war schlecht“ kaum.

Die Verspätung ist selten die eigentliche Ursache.

Nutze Fragen wie:

Mehrfaches Nachfragen hilft.

Beispiel:

Problem: Teststart verzögert.

Warum?

Testumgebung war nicht verfügbar.

Warum?

Beschaffung wurde zu spät gestartet.

Warum?

Der Vorlauf war in der Projektplanung nicht bekannt.

Dann lautet die Lesson nicht:

„Testumgebung früher bereitstellen.“

Sondern:

„Beschaffungsvorlauf für Testumgebungen muss bei vergleichbaren Projekten bereits in der Initialplanung berücksichtigt werden.“

Das ist übertragbar.

Eine Lesson darf nicht nur für dieses eine Projekt verständlich sein.

Sie sollte auch für vergleichbare Projekte funktionieren.

Schlecht:

„Peter früher informieren.“

Besser:

„Bei Änderungen an der zentralen Schnittstelle muss die verantwortliche Architekturrolle vor Freigabe des Change Requests eingebunden werden.“

Die zweite Formulierung enthält:

Damit kann ein anderes Projekt tatsächlich etwas anfangen.

Jetzt kommt der entscheidende Schritt.

Jede wichtige Lesson braucht eine Antwort auf:

Was ändern wir?

Zum Beispiel:

Damit entsteht aus einer Rückschau eine Verbesserung.

Lessons Learned ohne Verantwortlichkeit bleiben Vorschläge.

Deshalb braucht jede relevante organisationsweite Maßnahme:

Beispiel:

Lesson: Ressourcenplanung berücksichtigt Linienauslastung nicht ausreichend.

Maßnahme: Ressourcenformular um verbindliche Kapazitätsbestätigung ergänzen.

Owner: PMO-Leitung.

Termin: 30. November.

Nachweis: neue Version des Projektstart-Standards.

Jetzt kann überprüft werden, ob die Lesson tatsächlich umgesetzt wurde.

Auch eine logisch klingende Verbesserung kann wirkungslos sein.

Deshalb sollte das PMO einige Monate später prüfen:

Hat sich das Problem tatsächlich reduziert?

Beispiel:

Vor Einführung des Data-Readiness-Checks hatten vier von sechs Migrationsprojekten erhebliche ungeplante Datenprobleme.

Ein Jahr später tritt das Problem nur noch in einem von sechs Projekten auf.

Jetzt gibt es einen Hinweis darauf, dass die Lesson tatsächlich organisatorischen Wert erzeugt.

Ein praxistauglicher Eintrag braucht keine lange Dokumentation.

Sechs Felder reichen häufig:

Was ist passiert?

Was waren die Folgen?

Warum ist es passiert?

Was lernen wir daraus?

Was machen wir künftig anders?

Wer sorgt dafür, dass die Änderung umgesetzt wird?

Ein Beispiel:

Situation:
Fachliche Abnahmen verzögerten sich wiederholt.

Auswirkung:
Go-live verschob sich um drei Wochen.

Ursache:
Abnahmeverantwortliche waren nicht verbindlich eingeplant.

Lesson:
Abnahmekapazität muss bereits bei der Projektplanung zugesagt werden.

Maßnahme:
Abnahmeverantwortliche und Kapazitäten werden Bestandteil des Projektstart-Checks.

Owner:
PMO.

Das ist deutlich wertvoller als:

„Fachbereich früher einbinden.“

Lessons Learned werden häufig zu Fehlerkatalogen.

Damit geht wertvolles Wissen verloren.

Frage auch:

Eine positive Lesson könnte lauten:

„Die gemeinsame technische und fachliche Vorprüfung vor dem Steering Committee reduzierte Rückfragen und beschleunigte Entscheidungen.“

Konsequenz:

Dieses Format wird für vergleichbare Projekte übernommen.

Lernen bedeutet nicht nur:

Fehler nicht wiederholen.

Sondern auch:

Erfolgreiches Verhalten reproduzierbar machen.

Ein global tätiges Technologieunternehmen baute ein umfassendes Projektmanagement-Knowledge-Management auf.

Dabei stellte das zentrale PMO ein wesentliches Problem fest:

Einfach Dokumente in ein Repository hochzuladen, erzeugte noch keinen nutzbaren Wissensbestand.

Interne Analysen ergaben, dass bei unkontrollierten Dokumentbeiträgen lediglich etwa 15 bis 25 Prozent der Inhalte ohne Weiteres in anderen Projekten wiederverwendbar waren.

Daraufhin führte das PMO einen Moderationsprozess ein. Fachliche Experten bewerteten Inhalte, prüften ihre Qualität, entfernten kundenspezifische Informationen und entwickelten aus geeigneten Erfahrungen wiederverwendbare Best Practices.

Der Unternehmensname ist für die Erkenntnis nicht entscheidend.

Die Lektion lautet:

Ein großes Wissensarchiv ist noch kein gutes Wissensmanagement.

Qualität ist wichtiger als Menge.

Ein besonders wirksamer Schritt wird häufig vergessen:

Vor einem neuen Projekt sollten relevante Erfahrungen aus ähnlichen Projekten aktiv gesucht werden.

PMI schlägt dafür vier einfache Schritte vor:

Das schließt den Lernkreislauf.

Ohne diesen Schritt produziert das Unternehmen zwar Lessons.

Es konsumiert sie aber nicht.

Ein neues ERP-Rollout startet.

Vor der Planung analysiert das Team drei vergleichbare Rollouts.

Wiederkehrende Probleme waren:

Das neue Projekt reagiert sofort:

Das Projekt hat noch keinen eigenen Fehler gemacht.

Und trotzdem bereits gelernt.

Genau so sollte Lessons Learned funktionieren.

Eine empirische Untersuchung mit 212 IT-gestützten Veränderungsprojekten untersuchte den Zusammenhang zwischen Wissensmanagement und Projektergebnissen.

Das Ergebnis: Eine gute Abstimmung des Wissens zwischen technischer Umsetzung, Business Change und Governance hatte einen deutlichen Zusammenhang mit erreichtem Business Value. Das entwickelte Modell erklärte 38 Prozent der Varianz beim Geschäftswert der untersuchten Projekte.

Eine weitere empirische Untersuchung zu Lessons-Learned-Praktiken fand einen statistisch signifikanten Zusammenhang zwischen dem Sammeln und Anwenden von Erfahrungen und der Realisierung von Projektzielen hinsichtlich Scope, Zeit und Budget.

Solche Untersuchungen beweisen nicht, dass ein Lessons-Learned-Workshop automatisch bessere Projekte erzeugt.

Sie unterstreichen aber etwas Wesentliches:

Projektwissen ist ein Leistungsfaktor, wenn es tatsächlich genutzt wird.

Zu spät für Verbesserungen im laufenden Projekt.

Das erzeugt Beobachtungen, keine Lessons.

Dann bekämpft die Organisation Symptome.

Erkenntnisse bleiben Empfehlungen.

Niemand setzt die Maßnahmen um.

50 triviale Lessons verstecken die fünf wichtigen.

Andere Teams wissen nicht, ob die Erkenntnis auf ihr Projekt übertragbar ist.

Dann werden heikle Probleme nicht mehr offen angesprochen.

Speichern ist nicht Anwenden.

Dann bleibt der Lernkreislauf offen.

Lessons Learned funktionieren schlecht, wenn die Unternehmenskultur Fehler bestraft.

Wenn Mitarbeiter davon ausgehen müssen, dass eine offene Aussage später gegen sie verwendet wird, entstehen harmlose Workshop-Ergebnisse.

Dann heißt es:

„Kommunikation könnte noch verbessert werden.“

Obwohl das eigentliche Problem lautet:

„Der Sponsor hat drei Monate lang notwendige Entscheidungen blockiert.“

Lessons Learned benötigen deshalb:

Auch APM betont, dass organisationales Lernen eine soziale Praxis ist. Das bloße Dokumentieren reicht nicht. Menschen müssen Wissen austauschen, Wahrnehmungen hinterfragen und Erkenntnisse gemeinsam nutzbar machen.

Viele Unternehmen besitzen tausende Dokumente.

Das Problem ist nicht fehlendes Wissen.

Das Problem ist Retrieval.

Ein Projektleiter müsste beispielsweise wissen:

Das ist unrealistisch.

Genau hier verändert KI derzeit das Lessons-Learned-Management.

Eine 2026 veröffentlichte Studie untersuchte ein Lessons-Learned-System bei einem projektintensiven Industrieunternehmen.

Die Wissensbasis umfasste mehr als 1.500 dokumentierte Erfahrungen aus großen Engineering-Projekten.

Die Forscher entwickelten ein RAG-basiertes System mit:

Im Vergleich zur vorhandenen Keyword-Suche verbesserte der Ansatz die Relevanz und Rangfolge der gefundenen Erfahrungen deutlich. Die automatisch erzeugten Zusammenfassungen reduzierten zusätzlich den Aufwand für die Nutzer. Gleichzeitig zeigte die Studie eine zentrale Voraussetzung: KI kann nur so gut arbeiten wie die zugrunde liegende Dokumentation.

Das verändert die Zukunft von Lessons Learned.

Statt:

„Suche im Ordner nach einem ähnlichen Projekt.“

könnte die Frage lauten:

„Welche wiederkehrenden Risiken gab es bei unseren letzten fünf Datenmigrationen und welche Maßnahmen haben funktioniert?“

KI kann Wissen leichter zugänglich machen.

Sie ersetzt aber nicht die Qualität des Lernprozesses.

Ein funktionierendes Unternehmensmodell kann aus vier Ebenen bestehen.

Lessons laufend erfassen.

Zum Beispiel:

Wichtige Erkenntnisse:

Nicht jede Beobachtung wird organisationsweit relevant.

Das PMO prüft:

Bei Projektstart werden relevante Lessons aktiv abgerufen und in:

übernommen.

So entsteht ein echter Kreislauf:

Erfahrung → Erkenntnis → Veränderung → Anwendung → neue Erfahrung

Nicht über die Anzahl gespeicherter Lessons.

Bessere Kennzahlen sind:

Wie viele neue Projekte nutzen Erfahrungen aus früheren Projekten?

Wie viele priorisierte Lessons wurden tatsächlich in Standards oder Prozesse überführt?

Wie häufig tritt dasselbe bekannte Problem erneut auf?

Wie oft wird das Wissenssystem bei Projektstart und Planung verwendet?

Hat sich die relevante Projektkennzahl nach einer Veränderung verbessert?

Beispiel:

Ein Unternehmen identifiziert über mehrere Projekte regelmäßig zu spät gestartete Beschaffungen.

Daraufhin wird der Beschaffungs-Check Teil des Projektstarts.

Die relevante Kennzahl lautet nicht:

„Wir haben die Lesson dokumentiert.“

Sondern:

„Wie oft entstehen seit der Änderung weiterhin ungeplante Beschaffungsverzögerungen?“

Ein Lessons-Learned-Termin muss nicht drei Stunden dauern.

Für viele Projekte reicht ein klar moderiertes Format.

Was ist passiert?

Keine Bewertungen.

Warum ist es passiert?

Welche Erkenntnisse sind auf andere Situationen übertragbar?

Was ändern wir?

Wer macht was bis wann?

Danach sollten maximal fünf bis zehn hochwertige Lessons übrigbleiben.

Nicht 60 Post-its.

Die Qualität der Erkenntnisse zählt.

Während des gesamten Projekts. Besonders sinnvoll sind Meilensteine, Phasenabschlüsse, gelöste Probleme, größere Changes und der Projektabschluss. APM und PMI empfehlen ausdrücklich, nicht nur bis zum Ende zu warten.

Situation, Auswirkung, Ursache, konkrete Erkenntnis, empfohlene Veränderung und Verantwortlichkeit.

Die Projektleitung sollte den Prozess sicherstellen. Die Erkenntnisse selbst entstehen gemeinsam im Team. Für organisationsweite Veränderungen braucht es häufig das PMO, Process Owner oder andere Verantwortliche.

Eine Retrospektive ist ein regelmäßiges Reflexionsformat. Lessons Learned sind konkrete, dokumentierte Erkenntnisse, die aus solchen Reflexionen oder anderen Projektereignissen entstehen und auch für zukünftige Arbeit nutzbar gemacht werden können.

Strukturiert, durchsuchbar und mit genügend Kontext. Entscheidend ist jedoch nicht nur die Ablage. Andere Projektteams müssen relevante Erfahrungen schnell finden und in ihre Planung übernehmen können.

Ja. Besonders bei Suche, semantischer Zuordnung und Zusammenfassung großer Wissensbestände. Aktuelle Forschung aus 2026 zeigt deutliche Vorteile von RAG-basierter Suche gegenüber reiner Keyword-Suche bei industriellen Lessons-Learned-Daten.

Lessons Learned, die wirklich etwas bringen, unterscheiden sich fundamental von einem Abschlussworkshop mit bunten Post-its.

Sie beantworten nicht nur:

Was ist passiert?

Sondern:

Warum ist es passiert?

Was lernen wir daraus?

Was verändern wir konkret?

Wer setzt diese Veränderung um?

Und wird sie im nächsten Projekt tatsächlich genutzt?

Genau dieser letzte Schritt entscheidet.

APM weist zu Recht darauf hin, dass viele Organisationen Erfahrungen zwar dokumentieren, aber daraus keine zuverlässig veränderte Praxis entwickeln.

Gute Lessons Learned bilden deshalb einen geschlossenen Kreislauf:

erfassen → analysieren → verändern → anwenden → überprüfen.

Technologie kann diesen Kreislauf inzwischen erheblich unterstützen. Besonders KI-gestützte semantische Suche macht große Wissensbestände leichter zugänglich. Sie löst aber nicht das Grundproblem.

Ein Unternehmen lernt nicht dadurch, dass es mehr Wissen speichert.

Es lernt dann, wenn frühere Erfahrungen zukünftiges Verhalten verändern.

Genau daran sollte jedes Lessons-Learned-System gemessen werden.

PURE Consultant unterstützt Unternehmen dabei, Lessons Learned und Projektwissen so in PMO, Projektstart, Governance und Standards zu integrieren, dass Erfahrungen nicht archiviert werden, sondern in zukünftigen Projekten tatsächlich Wirkung entfalten.