Lessons Learned

Was sind Lessons Learned, welche Beispiele und Phasen gibt es, und wann ist der ideale Zeitpunkt?

Lessons Learned – gewonnene Erkenntnisse nutzen

„The only mistake in life is the lesson not learned“ soll Albert Einstein einmal gesagt haben. Frei übersetzt sind Fehler erlaubt, solange man aus ihnen lernt. Lessons Learned bezeichnet das Lernen aus Erfahrung, mit dem Ziel, die gewonnenen Erkenntnisse zukünftig aktiv zu nutzen. „Gewonnene Erkenntnisse“ ist die gebräuchlichste Übersetzung für den aus dem Englischen stammenden Begriff; „Lektion gelernt“ ist eine alternative und vielleicht sogar bessere Übersetzung.

Es gibt viele Beispiele, die zeigen, dass durch Handlungen Erfahrungen und idealerweise Erkenntnisse entstehen (können):

  • In Projekten kommt es zum Scope Creep; fortan werden Projektziele zum Projektstart definiert, dokumentiert und kommuniziert.
  • Beim Refactoring kommt zu es Mehraufwänden; zukünftig wird die Softwarearchitektur analysiert, bevor das Codieren beginnt.
  • Beim Requirements Engineering werden viele unnötige Anforderungen erhoben; bei jedem neuen Vorhaben wird zuerst der Systemkontext bestimmt.
  • Anwender sind mit einer Lösung unzufrieden; sie werden künftig frühzeitig und kontinuierlich in die Entwicklung einbezogen.
  • Workshops verlaufen chaotisch; sie werden fortan besser vorbereitet, zu zweit durchgeführt und moderiert und anschließend im Detail nachbereitet.

 

Lessons Learned - Erkenntnisse gewinnen in drei Phasen

Phasen bei Lessons Learned

Die Beispiele zeigen, dass sich Lessons Learned häufig auf Organisationen – Unternehmen, Gremien, Teams etc. – beziehen. Oft wird der Begriff im Kontext von Projekten, im Zuge von Entwicklungen, oder beim Treffen von Entscheidungen verwendet. Doch auch Individuen lernen aus ihren Erfahrungen. Das Lernen aus Erfahrung geschieht sowohl für Individuen als auch für Organisationen in drei Phasen:

  1. Die Identifikation der Lektion, auch als Lessons Identified bezeichnet.
  2. Die Analyse der Lektion, auch als Lessons Analyzed bezeichnet.
  3. Das Lernen der Lektion und damit das eigentliche Lessons Learned.

Bevor Individuen und Organisationen von ihren Erfahrungen profitieren können, müssen diese Erfahrungen als solche erkannt – also identifiziert – werden. Welche Probleme gab es bei einem Vorhaben? Was hat in einem Projekt gut oder weniger gut geklappt? Wo gibt es Verbesserungspotential? Sowohl aus positiven als auch aus negativen Erfahrungen können Individuen und Organisationen lernen.

Nach der Identifikation folgt die Analyse. Wieso hat etwas funktioniert oder nicht funktioniert? Welche Rahmenbedingungen gab es? Wie war das Setting im Projekt, die Kommunikation, die Motivation, das Tooling? Die Analyse der Erfahrungen ist wichtig, um als Organisation und/oder Individuum aus ihnen lernen und sie auf vergleichbare Situationen, Herausforderungen oder Projekte übertragen zu können.

Beim aktiven Lernen aus Situationen ist es wichtig, die Erkenntnisse zu dokumentieren, und sie so zu speichern, dass sie für alle Betroffenen zukünftig leicht zugänglich sind. Eine reine Ablage im Intranet wird bei einem kommenden Projekt leicht übersehen. Besser ist es bspw.

  • mit Checklisten zu arbeiten,
  • Dokumentenvorlagen zu optimieren und bereitzustellen,
  • Good Practices und Prozessschritte mit Softwaretools zu unterstützen,
  • und evtl. sogar konkrete Aktivitäten zur Auseinandersetzung mit bereits früher dokumentierten Lessons Learned im Projektplan zu berücksichtigen.

 

Der Zeitpunkt für Lessons Learned

Ein wesentliches Kriterium für Lessons Learned ist der Zeitpunkt, an dem sich die Beteiligten zusammensetzen, um wertvolle Erfahrungen zu identifizieren, sie zu analysieren und aus ihnen zu lernen. In diesem Kontext gibt es bspw.

  • das Projektreview als Nachbetrachtung eines Projekts oder einer Projektphase, und
  • das Review und die Retrospektive, die am Ende eines Sprints in Scrum durchgeführt werden.

Bei beiden Formaten geht es weniger um die erzielten Ergebnisse, sondern hauptsächlich um die Art und Weise der Zusammenarbeit, um Herausforderungen und Verbesserungsmöglichkeiten. Je nach verwendetem Format gilt es

  • Dinge, die gut gelungen sind,
  • Dinge, die weniger gut gelaufen sind,
  • Dinge, die man direkt stoppen sollte,
  • und Aspekte, die man ausprobieren könnte,

festzuhalten. Damit unterscheiden sich Retrospektiven und Projektreviews wesentlich von Code Reviews oder Sprint Reviews, bei denen es mehr um die Beurteilung der Arbeitsergebnisse als um die Zusammenarbeit geht.

Wichtig ist bei Lessons Learned – bspw. im Zuge eines Projektreviews oder in Form eines Workshops – die Vermeidung von Rückschaufehlern. Ein Vorgehen mag sich im Nachhinein als falsch erweisen, lernen können Individuen und Organisationen daraus aber nur, wenn die benötigten Informationen zum Zeitpunkt der damaligen Entscheidung bekannt waren. Je geringer die zeitliche Distanz zwischen Erfahrung und Erkenntnis, desto seltener kommt es zu einem Rückschaufehler. Darüber hinaus bieten frühzeitige Lessons Learned Sessions die Möglichkeit, die gewonnenen Erkenntnisse bereits im laufenden Projekt oder der laufenden Entwicklung zu nutzen.

Herausforderungen bei Lessons Learned

In der Praxis lässt sich immer wieder beobachten, dass es in Organisationen auch Herausforderungen im Umgang mit Lessons Learned gibt:

  • Es kann vorkommen, dass zum Ende eines Projekts „die Luft raus ist“, sprich nur noch wenige Mitarbeitende die Lust verspüren, aktiv aus der jüngeren Vergangenheit zu lernen. Interessanterweise ist dies vor allem dann zu beobachten, wenn Projekte verhältnismäßig viel Zeit in Anspruch genommen haben und/oder die gefühlte Zusammenarbeit nicht gut verlief. 
  • Gerade am Ende eines Projekts wird die Beschäftigung mit gewonnenen Erfahrungen und Erkenntnissen nicht als Vorteil empfunden. Projekte sind per Definiton temporär und einmalig, wieso sollten die Erkenntnisse also Vorteile für künftige, temporäre und einmalige Projekte bringen?
  • Die Nutzung von Erfahrungen anderer, fühlt sich für manche Mitarbeitende „ungewöhnlich“ an. In gewisser Weise haben Lessons Learned also ein Imageproblem. 
  • Es gibt Projekte, die leiden an Mitarbeitenden mit einem zu großen Selbstbewusstsein. Aus dieser Position heraus werden Erkenntnisse aus anderen Vorhaben schlicht abgelehnt.
  • Und last but not least wird der zusätzliche Aufwand – zum Ende eines Projekts oder zu Beginn eines neuen Projekts – gescheut. Am Anfang von Projekten ist dies besonders der Fall, wenn Ressourcen fehlen, der Projektstart am besten bereits gestern erfolgen sollte oder das Management wenig Wert auf die aktive Auseinandersetzung mit zuvor gewonnen Erkenntnissen legt.

 

Lessons Learned Vorlage zum Mitnehmen

Jetzt die Lessons Learned Vorlage kostenlos downloaden.

Mit der Vorlage können Sie folgende Informationen dokumentieren:

  • Welches Problem bzw. welche Probleme sind aufgetreten?
  • Welche Lösung wurde verwendet?
  • Welche Erkenntnisse und Verbesserungsvorschläge haben Sie gewonnen?

Profitieren Sie von Ihren Erfahrungen.

Impuls zum Diskutieren:

Wie schaffen Sie es in Ihrer Organisation, sich an Lessons Learned zu erinnern und sie konkret zu nutzen?

Hinweise:

Lernen aus Erfahrungen ist ein Prinzip in PRINCE2, der britischen Projektmanagementmethode. Die gesammelten Erkenntnisse, aufgetretene Risiken und Probleme, Verbesserungen und Ideen werden im sogenannten Erfahrungsprotokoll festgehalten. Im PMBOK Guide istdie Dokumentation von Erfahrungen eine Aufgabe im Prozess „Abschliessen eines Projekts oder einer Phase“. Und in der Indiviudal Competence Baseline, dem Kompetanzstandard der IPMA, findet die Dokumenation der Lessons Learned unter anderem während der Projektabschlussanalyse statt.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Wie funktioniert ein Code Review?

Wie funktioniert ein Code Review?

Wissen kompakt: Wie funktioniert ein Sprint Review?

Wie funktioniert ein Sprint Review?

Wissen kompakt: Was ist Clean Code?

Was ist Clean Code?