Lessons Learned

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.

Impuls zum Diskutieren:

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

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

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 ist die Dokumentation von Erfahrungen eine Aufgabe im Prozess “Abschließen eines Projekts oder einer Phase”. Und in der Individual Competence Baseline, dem Kompetenzstandard der IPMA, findet die Dokumentation der Lessons Learned unter anderem während der Projektabschlussanalyse statt.

Hier finden Sie ein Video zu den Unterschieden zwischen Lessons Learned und Retrospektiven.

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

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.