Lessons Learned im Projekt: Was, warum und wie es richtig geht

Das Projekt ist gelaufen, sofort kommt das nächste? Im besten Fall mit einem neuen Thema, mit dem komplett bei Null begonnen wird? Klingt spannend – aber genau dieses „bei Null beginnen“ führt zu typischen Problemen: Das Rad wird nicht nur neu erfunden, sondern bereits gemachte Fehler wiederholt. Muss das so sein? Nicht unbedingt: Lessons Learned können hier Abhilfe schaffen.

Was sind Lessons Learned?

Gelernte Lektionen, gewonnene Erkenntnisse, Lernen aus Erfahrung – wir bleiben in diesem Artikel beim bewährten Begriff „Lessons Learned“. Bei der Durchführung geht es um zwei Kernbereiche:

1. Identifikation der Dinge, die gut gelaufen sind, sodass sie auch in der Zukunft angewendet werden können.
2. Identifikation der Dinge, die schlecht gelaufen sind, sodass sie nicht wiederholt werden und von besseren Ansätzen profitiert wird.

Die Ziele von beiden Ansätzen: Risiken sollen minimiert und das Projektergebnis oder die Zusammenarbeit verbessert werden. Lessons Learned sind immer Erkenntnisse, die in der Praxis gewonnen werden und die zukünftig aktiv genutzt werden sollen.

In manchen Projekten werden auch die Begriffe „Retrospektive“ und „Team Debriefs“ angewendet.

Wann sollte ein Lessons Learned-Workshop durchgeführt werden?

Deine spontane Antwort lautet vermutlich: am Ende des Projekts. Das ist auch nicht falsch – aber leider nur die halbe Wahrheit. Zusätzlich ist es ratsam, solche Workshops zur Erfahrungssicherung an wichtigen Projektterminen durchzuführen, zum Beispiel am Ende einer Phase oder beim Erreichen kritischer Meilensteine.

In agilen Projekten sind regelmäßige Reviews der Zusammenarbeit im Team bereits in den Prozessen vorgesehen, beispielsweise als Sprint-Retrospektive im Scrum.

Wer sollte an Lessons Learned beteiligt sein?

Hier gibt es keine klare Vorgabe, stattdessen die vage Aussage: „Alle, von denen ein zielführendes Feedback zu erwarten ist.“ Zu unterscheiden ist das Vorab-Ausfüllen eines Lessons Learned-Fragebogens (größere Gruppe) und die Teilnahme am eigentlichen Workshop (kleinere Gruppe). An letzterem sollten folgende Personen(gruppen) teilnehmen:

• der Projektleiter
• das Projektteam oder bei großen Teams ein überschaubarer Kern des Teams
• ein unabhängiger Moderator
• ggf. wichtige Stakeholder oder sonstige Beteiligte

Wie läuft ein Lessons Learned-Workshop ab?

Die Antwort klar und wenig eindeutig zugleich: Es kommt darauf an! Wie Lessons Learned gestaltet werden, hängt vom Umfeld, der Komplexität sowie der Größe des Projekts ab. Ein zielgerichtetes Sammeln von Lessons Learned geht in jedem Fall über eine kurze Stimmungsabfrage im Team hinaus.

Der folgende Prozess orientiert sich an der Vorgabe des PMI® (Project Management Institute):

In den folgenden Abschnitten erfährst du mehr über diese Schritte. Beginnen wir mit Schritt 1: dem Identifizieren.

1. Identifizieren der Lessons Learned

Die Basis: Die gewonnen Erkenntnisse müssen gesammelt werden. Dies geschieht in zwei Phasen: Der Vorbereitung des Workshops und der Durchführung.

Lessons Learned-Workshop vorbereiten

Bereits vor dem eigentlichen Workshop ist eine Menge zu tun:

• Es wird ein Fragebogen erstellt oder (wenn vorhanden) angepasst. Jeder Fragebogen sollte Fragen zu verschiedenen Kategorien enthalten, beispielsweise Zufriedenheit mit der Kommunikation, der Projektplanung oder dem Projektergebnis.
• Dieser Fragebogen wird mit genügend Vorlauf an alle Teilnehmer mit der Bitte um Feedback versandt.
• Die Inhalte der ausgefüllten Fragebogen werden zusammengefasst.
• Ein Moderator wird bestimmt, der mit den vorliegenden Informationen vertraut sein sollte. Idealerweise handelt es sich nicht um den Projektmanager, sondern um eine dritte Person.
• Basierend auf den Einsendungen wird eine Agenda erstellt und an alle Teilnehmer des Meetings verschickt.

Lessons Learned-Workshop durchführen

Der eigentliche Workshop hat kann je nach Projekt unterschiedlich ausfallen. Nachdem die zusammengefassten Inhalte der Fragebögen präsentiert wurden, sollten folgende Fragen diskutiert werden:

1. Welche Ursachen liegen den gemachten Fehlern zugrunde? Je nach Komplexität biete sich die Anwendung der Ishikawa– oder 5W-Methode an.
2. Wie sollte das Thema zukünftig behandelt werden, damit Probleme nicht erneut auftreten oder in zukünftigen Projekten wiederholt werden?
3. Welche konkreten Maßnahmen werden festgelegt, um positive Erkenntnisse dauerhaft zu etablieren und Fehler nicht zu wiederholen?
4. Falls sinnvoll: Mit welcher Priorität soll welche Erkenntnis behandelt werden?

Wichtig: Während des Workshops sollte nicht nur diskutiert, sondern auch protokolliert werden, um möglichst viele Erkenntnisse zu sichern. Außerdem sollte der Moderator nicht nur auf die Einhaltung der Agenda achten, sondern auch passive Teilnehmer gezielt zu Aussagen auffordern.

2. Dokumentieren der Lessons Learned

Was passiert während und besonders nach dem Workshop? Richtig: Alle Erkenntnisse werden sauber dokumentiert und für unterschiedliche Zielgruppen zusammengefasst:

• Alle Teilnehmer des Workshops sollten einen ausführlichen Bericht inklusive der Diskussionsergebnisse im Workshop erhalten. Idealerweise wird dieser Detailbericht von jedem Teilnehmer noch einmal kommentiert, bevor weitere Berichte erstellt werden.
• Alle Teammitglieder sollten diesen ausführlichen Bericht erhalten, auch wenn sie selbst nicht an der Erstellung der Lessons Learned beteiligt waren.
• Relevante Stakeholder sollten einen Bericht basierend auf ihren Interessen erhalten.
• Die Geschäftsführung oder höhere Management-Ebenen sollten einen zusammengefassten Bericht mit den wichtigsten Erkenntnissen erhalten.

Wichtig: Diese Berichte sollten nicht nur verteilt, sondern gemeinsam mit bereits bestehenden Projektdokumenten abgelegt werden.

3. Analysieren der Lessons Learned

Dieser Schritt überlagert sich häufig mit der Durchführung des Workshops, geht jedoch weiter in die Tiefe. Nach dem Workshop treffen sich Einzelne oder mehrere Verantwortliche und klären offene Fragen:

1. Gibt es eine Häufung auf bestimmten Themengebieten?
2. Wo besteht der größte Handlungsbedarf?
3. Sind bereits alle nötigen Maßnahmen definiert worden? Gibt es dafür Zieltermine und Verantwortliche?
4. Werden generelle Änderungen am Projektmanagement-Prozess benötigt?

Je nach Inhalt der gewonnen Erkenntnisse kann dieser Schritt sehr tiefgreifend sein und sowohl kleine als auch große Maßnahmen nach sich ziehen. Drei Beispiele:

• Im Projekt haben sich tägliche kurze Standup-Meetings am Morgen bewährt – diese sollen zukünftig in Projekten ähnlicher Art ebenfalls durchgeführt werden.
• Es wird eine Kompetenzlücke im Projektteam im Bereich Grafikdesign festgestellt. Ein Mitarbeiter wird für eine Weiterbildung vorgeschlagen.
• Die Kommunikation mit dem oberen Management und Auftraggeber wurde während der gesamten Projektlaufzeit vom Team als ungenügend eingeschätzt. Es wird ein Meeting mit der Geschäftsführung einberufen.

4. Speichern der Lessons Learned

Was passiert mit vielen Lessons Learned? Sie landen in Aktenordnern oder als Dateien auf Netzlaufwerken. Das ist auch ein guter Anfang – erschwert jedoch das Zugänglichmachen im nächsten Schritt. Idealweiser verfügt ein Unternehmen über eine strukturierte Lessons Learned-Datenbank, deren Nutzung aktiv vorgelebt wird.

5. Lessons Learned zugänglich machen

Die Knackpunkt und häufig die größte Herausforderung: Wie wird sichergestellt, dass die gewonnenen Erkenntnisse so zugänglich sind, dass sie von anderen Projekten genutzt werden? Hier dreht sich alles um Systeme und Prozesse: Zum einen müssen Mitarbeiter es leicht haben, Informationen zu finden, zum anderen müssen sie motiviert sein, dies auch zu tun – was häufig das größere Problem ist. Mehr zum Thema, warum Lessons Learned häufig nicht funktionieren, beschreiben wir im nächsten Artikel.

Fazit

Lessons Learned sollten zum Standard-Repertoire eines jeden Projektmanagers gehören. Warum? Weil in Projekten kein Raum für Fehler ist, die andere schon einmal gemacht haben. Stattdessen gibt es jede Menge Potenzial für Ansätze, die sich in anderen Projekten bewährt haben. Wie wir alle wissen, sind Projekte an sich bereits komplex genug – bereits gewonnen Erkenntnissen nicht zu verwerten wäre daher grob fahrlässig und dumm.

Fragen und Antworten