Warum Lessons Learned selten das nächste Projekt verändern

Die meisten Teams schreiben Erkenntnisse auf, aber nur wenige wenden sie an. Was NASA-Audits ergaben, wie Pause and Learn funktioniert und ein Kreislauf, der jede Erkenntnis mit einer echten Veränderung verknüpft.

Ibrahim Elkobeissi · 2. November 2026 · 6 Min. Auswertung ·

LinkedIn X WhatsApp

Ein Stapel Projektdateien neben einem leeren Prüfungsformular auf einem Schreibtisch

Jedes Projekt endet mit einer Liste. Was gut lief, was schiefging, was wir anders machen würden. Die Liste wird abgelegt. Das nächste Projekt beginnt, und öfter als Teams zugeben möchten, werden dieselben Fehler erneut gemacht.

Das Problem ist selten die Erfassung. Es ist die Distanz zwischen einer identifizierten Erkenntnis und einer angewendeten Erkenntnis. Eines der am besten dokumentierten Lessons-Learned-Programme der Welt, das von NASA, hat diese Distanz gemessen. Seine Befunde stehen am Anfang. Ein kleiner Kreislauf, der die Distanz schließt, folgt darauf.

Identifiziert ist nicht gleich gelernt

Eine Erkenntnis wird identifiziert, wenn jemand sie aufschreibt. Sie wird gelernt, wenn die Organisation aufgrund dieser Erkenntnis anders handelt. Dazwischen liegt eine Menge Arbeit, die in den meisten Lessons-Learned-Prozessen niemandem zugewiesen wird.

Die Forschung über Projektorganisationen benennt dieses Muster direkt. Im International Journal of Project Management fanden Duffield und Whitty heraus, dass Lessons-Learned-Prozesse selten stattfinden, und wenn doch, konzentrieren sie sich auf die "Identifizierung von Erkenntnissen statt auf organisationales Lernen". Das Ergebnis ist ein Dokument. Das beabsichtigte Ziel ist eine Veränderung der Arbeitsweise des nächsten Teams. Das sind zwei verschiedene Dinge, und nur eines davon ist leicht zu erreichen.

Was die NASA-eigenen Audits ergaben

Die NASA nimmt Erkenntnisse ernst. Sie betreibt das Lessons Learned Information System (LLIS), und ihre Verfahrensvorschrift NPR 7120.6, der Lessons Learned Process, legt fest, wie Erkenntnisse gesammelt, validiert, bewertet und kodifiziert werden. Das macht ihre Audits zu einem nützlichen Testfall. Wenn Erkenntnisse dort stagnieren, liegt die Ursache nicht an mangelndem Willen.

Im Jahr 2001 befragte das U.S. General Accounting Office (heute Government Accountability Office) NASA-Programm- und Projektmanager. Von den 115 Teilnehmern:

27% wussten vor der Umfrage nichts vom LLIS.
17.5% hatten eine Erkenntnis angewendet, die sie durch das LLIS gefunden hatten.
58% gaben an, dass die aktuellen Systeme es ihnen nicht ermöglichten, die richtigen Erkenntnisse zur richtigen Zeit abzurufen.

Das GAO kam zu dem Schluss, dass "Erkenntnisse nicht routinemäßig identifiziert, gesammelt oder geteilt werden". Lernen fand zwar statt, aber meist durch Reviews und Gespräche mit Kollegen, nicht durch das dafür geschaffene System.

Im Jahr 2012 kehrte das Office of Inspector General der NASA zu dieser Frage zurück. Es befragte 28 Wissenschafts- und Raumfahrtprojekte, die zwischen 2005 und 2011 gestartet wurden. Sechzehn Projektmanager gaben an, LLIS überhaupt zu nutzen, und nur sechs von ihnen fanden es nützlich. Zwölf hatten Erkenntnisse beigetragen. Nur zehn kannten die Verpflichtung zur Abgabe. Die Manager bezeichneten das System als veraltet und schwer durchsuchbar, und viele sahen ihre eigenen Projekte als zu einzigartig an, als dass vergangene Erkenntnisse anwendbar wären. Das OIG stellte zudem fest, dass nur zwei NASA-Zentren die NPR 7120.6 bei der Durchführung ihrer eigenen Prozesse vollständig einhielten.

Das Muster zieht sich über elf Jahre hinweg durch. Erkenntnisse wurden gespeichert. Wenige wurden abgerufen. Noch weniger veränderten die Arbeit.

Warum Erkenntnisse stagnieren

Liest man die Audits genau, kehren drei Ursachen immer wieder zurück. Sie lassen sich weit über die Raumfahrt hinaus übertragen.

Erkenntnisse werden als Geschichten geschrieben, nicht als Anweisungen. Ein Absatz darüber, was passiert ist, ist schwer umsetzbar. Er sagt nicht, welches Dokument, welcher Schritt oder welche Entscheidung nun anders sein sollte.
Erkenntnisse existieren getrennt von der Arbeit. Eine separate Datenbank verlangt von vielbeschäftigten Menschen, aktiv danach zu suchen. Die meisten werden das nicht tun, besonders unter Zeitdruck. Das GAO fand heraus, dass Manager mehr von Kollegen und Reviews lernten als vom System.
Niemand prüft nach. Die Erfassung wird gezählt. Die Anwendung nicht. Wenn das einzige Maß dafür ist, wie viele Erkenntnisse protokolliert wurden, werden Teams sehr gut darin, zu protokollieren.

Keines davon ist allein ein technologisches Problem. Jedes ist ein fehlendes Bindeglied: zwischen der Erkenntnis und der Sache, die sie verändern soll, und zwischen dieser Veränderung und den Belegen, dass sie stattgefunden hat.

Pause and Learn: Lernen, während das Projekt noch läuft

Das NASA Goddard Space Flight Center beantwortete einen Teil dieser Frage mit einer Praxis namens Pause and Learn. Anstatt auf ein Abschluss-Review zu warten, hält ein Projektteam an bedeutsamen Punkten im Lebenszyklus inne und reflektiert gemeinsam.

Wie Edward Rogers und Barbara Fillip es beschreiben, bringt eine Standard-Session etwa 10 bis 20 Personen eines Projektteams für ca. 90 Minuten zusammen. Dabei werden vier oder fünf vorab gewählte Themen behandelt und drei Fragen bearbeitet: Was lief gut, was nicht und was würden wir anders machen? Bei jeder Session werden die Grundregeln vorgelesen. Die Diskussion wird als Wissenslandkarte festgehalten, mit dem Projektleiter besprochen und in späteren Workshops geteilt. Sessions werden im Lessons-Learned-Plan des Projekts eingeplant und nicht erst aufgerufen, wenn etwas schiefgeht.

Pause and Learn macht zwei Dinge richtig: Es hält Erkenntnisse fest, solange die Erinnerung noch frisch ist, und es hält den Dialog innerhalb des Teams, das die Umsetzung verantwortet. Was es allein jedoch nicht leistet, ist die Garantie, dass das nächste Projekt diese Erkenntnis auch aufgreift. Dafür ist ein weiterer Schritt nötig.

Ein Lessons-Learned-Prozess, der den Kreislauf schließt

Die internationale Norm für Wissensmanagementsysteme, ISO 30401, legt Anforderungen für die Einrichtung, Implementierung, Aufrechterhaltung, Überprüfung und Verbesserung eines Wissensmanagementsystems fest. Das NIST Baldrige Excellence Framework fragt in Punkt 4.2, wie Sie organisationales Wissen aufbauen und verwalten, wie Sie Best Practices teilen und wie Sie Ihr Wissen nutzen, um das Lernen fest in die Arbeitsweise Ihrer Organisation einzubetten. Beides zielt auf dieselbe Idee ab: Wissen hat einen Lebenszyklus, und die Erfassung ist nur die erste Phase.

In der Praxis besteht ein Arbeitskreislauf aus drei Schritten.

1. Erfassung in vier Feldern. Schreiben Sie für jede Erkenntnis auf, was Sie erwartet haben, was tatsächlich passiert ist, warum die Lücke entstanden ist und was Sie ändern werden. Das letzte Feld ist das entscheidende. Wenn ein Team keine konkrete Änderung benennen kann, handelt es sich um eine Beobachtung, nicht um eine Erkenntnis.

2. Verknüpfung der Erkenntnis mit ihrem Ziel. Jede Erkenntnis sollte auf das Verfahren, die Checkliste, die Vorlage oder die Entscheidung verweisen, die sie verändert. Aktualisieren Sie dieses Dokument und protokollieren Sie die Verknüpfung. So lebt die Erkenntnis dort, wo das nächste Team arbeitet, und nicht in einem Ordner, an dessen Öffnen man sich erst erinnern muss.

3. Überprüfung, ob das nächste Projekt sie angewendet hat. Wenn ein späteres Projekt den Schritt erreicht, den die Erkenntnis betrifft, stellen Sie sicher, dass das aktualisierte Verfahren verwendet wurde. Wenn ja, wurde die Erkenntnis angewendet. Wenn nicht, finden Sie heraus, warum. Vielleicht war die Änderung unklar oder der Schritt wurde übersprungen. Dieser Befund ist selbst eine Erkenntnis und führt zurück zu Schritt eins.

Unsere Regel bei Roadyom lautet: Beleg vor Behauptung. Für Erkenntnisse bedeutet das, dass nichts als gelernt gilt, bis eine spätere Arbeit dies beweist. Messen Sie den Kreislauf also anhand seines letzten Schritts. Ein nützlicher Indikator ist simpel: Von den im letzten Jahr erfassten Erkenntnissen, wie viele sind mit einem Verfahren verknüpft, und wie viele davon wurden von einem späteren Projekt angewendet? Diese Zahl ist schwerer zu steigern als die reine Anzahl der protokollierten Erkenntnisse. Aber sie ist auch die einzige, die Ihnen zeigt, ob Sie wirklich lernen.

Eine Erkenntnis, die keine Änderung benennt, ist eine Beobachtung. Eine Änderung, die in keinem späteren Schritt genutzt wird, ist ein Entwurf.

Wie Prism diesen Kreislauf steuert

Prism integriert die Entscheidungen und das Wissen einer Organisation direkt in die Arbeitsschritte. Ein Team kann in jedem beliebigen Schritt einen Pause-and-Learn-Eintrag öffnen, erfassen, was erwartet wurde, was passiert ist, warum dies geschah und welche Änderungen nötig sind, und jede Erkenntnis mit dem Verfahren verknüpfen, das aktualisiert werden soll. Prism zählt eine Erkenntnis erst dann als implementiert, wenn sie mit einem Verfahren verknüpft ist und ein späterer Schritt sie angewendet hat. Bis dahin bleibt sie als offen sichtbar. Menschen entscheiden, was geändert wird; Prism hält fest, ob die Änderung Bestand hatte.