Warum wir dieselben Fehler wiederholen – obwohl alles dokumentiert ist

Das Projekt ist abgeschlossen, der Fehler dokumentiert. Warum trifft das nächste Team trotzdem dieselbe falsche Entscheidung? Forschung zeigt, was zwischen Erkenntnis und Anwendung fehlt.
TUTORize GmbH, Andreas Junga 22.10.2026 Lesezeit wird berechnet
Kurz zusammengefasst

Das Wichtigste in Kürze

  • Ein sauber dokumentierter Projektfehler ist noch keine Erfahrung, die ein späteres Team nutzt.
  • Forschung unterscheidet mangelnde Auffindbarkeit, fehlenden Kontext und organisatorische Hindernisse beim Übertragen von Wissen.
  • Gut durchgeführte Nachbesprechungen können wirksam sein; das ist kein Beleg für langfristigen Transfer zwischen Projekten.
  • Entscheidend ist, ob frühere Erkenntnisse rechtzeitig in neue Entscheidungen eingehen – nicht die Zahl gespeicherter Einträge.

Der Rückblick ist noch kein organisatorisches Lernen

Im Abschlussmeeting sind sich alle einig. Die Übergabe kam zu spät, zwei Abteilungen arbeiteten mit unterschiedlichen Annahmen, ein Warnsignal wurde ignoriert. Jemand schreibt die Erkenntnisse in eine Vorlage, die Projektleitung lädt das Dokument hoch. Dann wird das Projekt geschlossen.

Ein halbes Jahr später gerät ein anderes Team in eine erstaunlich ähnliche Situation. Es muss nicht einmal derselbe Fehler sein. Es reicht, dass dieselbe Entscheidung wieder unter ähnlichem Zeitdruck getroffen wird. Der Bericht aus dem alten Projekt liegt weiterhin ordentlich abgelegt im System. Nur hat niemand ihn vor der neuen Entscheidung gelesen.

Das Beispiel ist konstruiert. Das zugrunde liegende Problem ist gut dokumentiert. In einer Untersuchung von Sue Newell und Kollegen aus dem Jahr 2006 betrachteten die Forschenden 13 Projekte in sechs Organisationen. Die verbreitete Praxis, Erkenntnisse nach Projektende in Datenbanken zu speichern, führte dort gerade nicht selbstverständlich zu deren Nutzung in anderen Projekten. Entweder erschienen die Einträge wenig nützlich, oder die späteren Teams wussten nicht, dass passende Erfahrungen existierten.

Die Arbeit ist älter als moderne Unternehmenssuche und kein Beweis dafür, wie häufig das Problem heute vorkommt. Sie benennt aber eine Unterscheidung, die durch neue Software nicht verschwindet: Ein Dokument kann vorhanden sein, ohne im Moment der Entscheidung zum Wissen des Teams zu werden.

Zwei Übergänge, an denen Erfahrungen verloren gehen

Der erste Übergang führt von einem konkreten Ereignis zu einer beschriebenen Erkenntnis. Dort gehen oft die Umstände verloren. Ein Team schreibt etwa: „Stakeholder früher einbinden.“ Was fehlte tatsächlich? Eine fachliche Entscheidung? Ein Budgetverantwortlicher? Die später betroffene Betriebsgruppe? Und woran wäre früher erkennbar gewesen, dass jemand fehlt?

Der zweite Übergang ist mindestens so schwierig. Eine andere Person muss die Erkenntnis bei einer neuen Aufgabe wiederfinden, verstehen und für die aktuelle Lage richtig gewichten. Sie muss erkennen, ob die alte Erfahrung überhaupt vergleichbar ist. Manche Empfehlungen sind nur unter den damaligen Randbedingungen sinnvoll. Eine erfolgreiche Abkürzung von gestern kann in einer neuen Umgebung ein Fehler sein.

Was zwischen Ablage und Wiederverwendung liegt

Erfahrung: Was ist passiert, unter welchen Bedingungen und mit welchen Folgen?

Übertragbare Erkenntnis: Welcher Mechanismus lässt sich aus dem Fall ableiten – und wo gilt er nicht?

Neue Entscheidung: Wer braucht die Erkenntnis wann, und welche konkrete Handlung ändert sich dadurch?

Die Darstellung ist eine redaktionelle Unterscheidung, kein wissenschaftlich validiertes Reifegradmodell.

Genau diese Lücke zwischen dokumentiertem Inhalt und sozialer Anwendung betont eine 2025 veröffentlichte Interviewstudie von Oluyomi Osobajo und Kollegen. Als Hindernisse nennen die Forschenden unter anderem unterschiedlich verstandene Lessons Learned, fehlendes Mentoring, Zurückhalten von Wissen, zu geringe Beteiligung wichtiger Akteure und mangelnde Zusammenarbeit.

Das sind Beobachtungen und Interpretationen aus Interviews. Daraus lässt sich keine universelle Rangliste der Fehlerursachen ableiten. Der Befund ist dennoch unbequem für jede Organisation, die Wissensmanagement vor allem als Frage eines besseren Eingabeformulars behandelt.

Wenn eine gute Sofortlösung das eigentliche Problem versteckt

Es gibt noch einen zweiten Weg, auf dem Lernen ausbleibt: Menschen beseitigen das akute Hindernis, ohne dessen Ursache für andere sichtbar zu machen. Was lokal als Kompetenz erscheint, kann organisatorisch zur Wiederholungsschleife werden.

Anita Tucker und Amy Edmondson beschrieben diesen Mechanismus in einer Feldstudie aus neun Krankenhäusern. Pflegekräfte fanden im Alltag improvisierte Lösungen für Prozessprobleme. Dadurch konnte die konkrete Arbeit weitergehen, während die Störung auf Systemebene bestehen blieb. Nicht jedes gelöste Tagesproblem erreichte einen Prozess, der die Ursache dauerhaft beseitigte.

Krankenhäuser sind keine Softwareprojekte, und qualitative Feldforschung ist keine repräsentative Schätzung für alle Branchen. Der beobachtete Unterschied zwischen schneller Problembeseitigung und dauerhafter Problemlösung lässt sich als Prüffrage aber gut übertragen.

In Projekten kann derselbe Entscheidungskonflikt auftauchen: Ein Spezialist korrigiert nachts manuell eine fehlerhafte Schnittstellendatei. Der Termin ist gerettet, die Kundin zufrieden. Wenn niemand anschließend fragt, warum die Datei falsch war, welcher Prüfschritt fehlte und wer diese Ursache beheben kann, gilt der Vorfall schnell als erfolgreich erledigt. Beim nächsten Projekt fehlt genau diese Information.

Das heißt nicht, dass Improvisation falsch wäre. Sie ist oft notwendig. Problematisch wird sie, wenn ihr Erfolg die systemische Ursache unsichtbar macht. Eine brauchbare Lessons-Learned-Kultur muss deshalb auch die Störungen erfassen, die durch engagierte Menschen gerade noch rechtzeitig verschwunden sind.

Die Gegenposition: Nachbesprechungen können sehr wohl wirken

Es wäre voreilig, aus ungenutzten Projektdatenbanken zu schließen, dass Retrospektiven oder After-Action-Reviews kaum etwas bringen. Die Forschung zeigt ein differenzierteres Bild.

Nathanael Keiser und Winfred Arthur werteten in einer Meta-Analyse 61 Studien mit 915 Teams und 3.499 Einzelpersonen aus. Für die untersuchten Evaluationskriterien berichteten sie eine gepoolte Effektstärke von d = 0,79. Besonders relevant waren die Passung der Nachbesprechung zur untersuchten Person oder Gruppe und der Einsatz objektiver Leistungsinformationen. Andere Merkmale wirkten abhängig von ihrer Kombination.

Die Kennzahl ist eine standardisierte Effektstärke, kein Produktivitätsprozentsatz. Die Studien prüften unterschiedliche Umgebungen und Ergebnisse. Deshalb wäre auch die Behauptung unzulässig, jedes Projekt verbessere sich durch ein Debrief im selben Maß.

Der Gegenbefund ist für die Kernfrage entscheidend: Innerhalb eines Teams aus einer Erfahrung zu lernen, ist nicht dieselbe Aufgabe wie diese Erkenntnis zwischen Projekten zu übertragen. Ein gut moderierter Rückblick kann die Leistung der Beteiligten verbessern. Die nächste Projektgruppe kennt die Beteiligten möglicherweise nicht, hat andere Rahmenbedingungen und sieht keinen Anlass, im Archiv zu suchen.

Damit ergibt sich kein Widerspruch zwischen den Studien. Sie messen verschiedene Glieder einer längeren Lernkette. Eine Organisation kann wirksame Retrospektiven durchführen und trotzdem dieselben Projektfehler wiederholen. Der positive Effekt auf die Teilnehmenden belegt noch keinen dauerhaften Transfer in andere Teams.

Das Wissensproblem ist nicht allein technisch

Eine neuere systematische Literaturübersicht macht deutlich, wie viele Ebenen zusammenspielen. Luciana Viel Gomes und Kollegen sichteten 372 wissenschaftliche Artikel zum Wissenstransfer in Projekten. Die Hindernisse und förderlichen Bedingungen ordnen sie organisatorischen, verhaltensbezogenen und technologischen Dimensionen zu. Die Autoren behandeln diese Faktoren ausdrücklich als miteinander verbunden.

Eine Suchfunktion kann beispielsweise die Auffindbarkeit verbessern. Sie entscheidet aber nicht, ob die dokumentierte Erkenntnis brauchbar formuliert ist, ob jemand widersprechen darf oder ob die Projektleitung noch rechtzeitig Handlungsspielraum hat, um einen alten Fehler zu vermeiden. Ein verpflichtendes Formular erzeugt wiederum mehr Einträge, ohne den anderen Übergang zu sichern: den zum späteren Nutzer.

Umgekehrt wäre „Kultur statt Technik“ ebenfalls zu einfach. Fehlt der Zugang zu früheren Fällen, muss jedes Team auf Zufall und persönliche Kontakte hoffen. Dokumentation, Kontext und soziale Weitergabe erfüllen unterschiedliche Aufgaben. Der Fehler liegt darin, eine davon für den gesamten Prozess zu halten.

Auch die Literaturübersicht ist kein Experiment, das eine einzige optimale Lösung nachweist. Sie fasst heterogene Arbeiten zusammen. Ihre Stärke liegt darin, die rein technische Deutung des Problems zu widerlegen, nicht darin, einen allgemein gültigen Maßnahmenkatalog mit garantierter Wirkung zu liefern.

Das nächste Projekt muss die Erkenntnis brauchen können

Was würde sich konkret ändern, wenn Organisationen den Transfer als eigene Aufgabe behandeln? Zunächst würde die Dokumentation weniger nach dem Ablauf des vergangenen Meetings und stärker nach der Entscheidung des nächsten Teams aufgebaut.

Ein nützlicher Eintrag nennt den Auslöser, den beobachteten Fehler, die Folgen und die Ursache, soweit sie bekannt ist. Er beschreibt auch, unter welchen Bedingungen die Erfahrung gilt. Ein Satz wie „Kommunikation verbessern“ lässt sich kaum wiederverwenden. „Vor dem Produktionsstart muss die empfangende Fachabteilung die tatsächliche Dateistruktur an einem Testfall prüfen“ ist dagegen eine konkrete, prüfbare Entscheidung. Das Beispiel ist redaktionell konstruiert, nicht Ergebnis einer Interventionsstudie.

Im nächsten Schritt muss die Organisation den geeigneten Moment bestimmen. Erfahrungen über Ausschreibungsanforderungen gehören vor die Angebotsfreigabe. Erkenntnisse aus einer misslungenen Migration gehören in die Planung und den Test einer neuen Migration, nicht nur in den Abschlussbericht der alten. Auf einen Projektstart, eine Architekturentscheidung oder eine Freigabe kann deshalb eine kurze Prüfung relevanter früherer Fälle folgen.

Das ist etwas anderes als der Versuch, alle Beschäftigten zum regelmäßigen Lesen einer Lessons-Learned-Datenbank zu bewegen. Die Information erscheint dort, wo sie gebraucht wird. Aber auch diese Lösung darf nicht mechanisch werden. Ein Treffer muss auf Relevanz und abweichende Bedingungen geprüft werden; eine übernommene Regel ohne Nachdenken kann neue Fehler erzeugen.

Nachweis der Ablage

Eintrag vorhanden, Vorlage ausgefüllt, Review durchgeführt. Das belegt, dass dokumentiert wurde.

Nachweis der Nutzung

Relevanter Fall wurde vor einer Entscheidung geprüft; das Team hat eine Maßnahme übernommen, angepasst oder begründet verworfen. Das belegt eine Nutzungshandlung, noch nicht deren Wirksamkeit.

Eine solche Unterscheidung verhindert einen verbreiteten Kategorienfehler. Viele Einträge und viele Aufrufe sind keine direkten Beweise, dass sich das Unternehmen verändert. Selbst ein vermerkter „Lesson applied“-Status reicht nicht, wenn unklar bleibt, welche Entscheidung tatsächlich anders getroffen wurde.

Wer aus Fehlern lernen will, muss auch etwas ändern dürfen

Der entscheidende Test findet außerhalb des Wissenssystems statt. Konnte das neue Team eine riskante Annahme früher korrigieren? Wurde ein Prüfschritt ergänzt? Hat jemand eine bekannte Warnung aufgegriffen und die Planung tatsächlich geändert?

Für eine redaktionell sinnvolle Erfolgskontrolle bieten sich drei getrennte Beobachtungen an: Ist die frühere Erfahrung beim neuen Projekt angekommen? Hat sie die konkrete Entscheidung beeinflusst? Ist anschließend der erwartete Fehler vermieden worden? Nur die letzte Ebene nähert sich einer Wirkungsmessung, und auch dort bleiben andere Ursachen möglich.

Wer in diesem Prozess nur die Eintragenden verantwortlich macht, übersieht die eigentliche Organisation. Wenn Erfahrungsberichte zwar geschrieben, aber weder in Standards noch in Freigaben und Projektvorlagen berücksichtigt werden können, bleibt Lernen eine Privatleistung. Man kann etwas wissen und trotzdem gezwungen sein, weiterzumachen wie bisher.

Gute Wissensarbeit braucht zudem die Erlaubnis, eine alte Erkenntnis zu verwerfen. Vielleicht war die damalige Lösung ein Zufallsbefund, vielleicht haben sich Technik oder Kundenanforderungen verändert. Ein lebendiger Lernprozess fragt daher nicht nur, was einmal funktionierte, sondern warum – und ob der Zusammenhang heute noch trägt. Die Frage der Gültigkeit und Pflege dokumentierten Wissens ist ein verwandtes, aber eigenes Problem.

Die Forschung erlaubt keine belastbare universelle Aussage darüber, wie häufig Organisationen ihre Lessons Learned nutzen. Dazu sind die untersuchten Populationen und Methoden zu unterschiedlich. Der Ausdruck „Wir machen immer dieselben Fehler“ ist deshalb eine zugespitzte Leserfrage, keine statistisch belegte Beschreibung der gesamten Arbeitswelt.

Die Antwort bleibt trotzdem konkret. Lernen endet nicht, wenn ein Rückblick stattgefunden hat. Es beginnt auch nicht automatisch, wenn das Protokoll in einer Wissensplattform landet. Entscheidend ist der Übergang in den nächsten relevanten Entscheidungsprozess. Erst dort lässt sich beobachten, ob eine Erfahrung mehr geworden ist als ein sauber archivierter Bericht.

Quellen