Das Wichtigste in Kürze

• Jede Lesson braucht sechs Felder: was passiert ist, Auswirkung, Ursache, Bewertung, verantwortliche Person und was sich ändert.
• Die meisten Lessons-Learned-Dokumente liest nie wieder jemand, weil sie nach Projekt abgelegt werden, nicht nach Thema.
• Eine Lesson ohne verantwortliche Person und ohne geänderte Vorlage ist eine Anekdote.
• Für ein einzelnes Projekt reicht ein Word-Dokument; ein Register lohnt sich bei vielen ähnlichen Projekten.

Eine brauchbare Lessons-Learned-Vorlage hat pro Lesson sechs Felder: was passiert ist, die Auswirkung, die Ursache, eine Bewertung (beibehalten, ändern oder aufhören), eine verantwortliche Person und die Vorlage oder Checkliste, die sich dadurch ändert. Die meisten Vorlagen hören nach den ersten drei Feldern auf, und genau deshalb liest die meisten Lessons-Learned-Dokumente nie wieder jemand. Eine Lesson zählt erst, wenn jemand dafür verantwortlich ist, die Vorlage zu ändern, mit der das nächste Projekt startet. Im Folgenden finden Sie die Vorlage, den Workshop, der sie füllt, und den Schritt, der dafür sorgt, dass sie wirkt.

Was gehört in eine Lessons-Learned-Vorlage?

Halten Sie den Kopfbereich kurz: Projektname, Zeitraum, Sponsor, die Teilnehmenden des Workshops und ein Link zum abschließenden Statusbericht. Danach eine Zeile pro Lesson:

Führen Sie den Workshop mit drei Fragen in dieser Reihenfolge: Was sollten wir beibehalten, was sollten wir ändern, womit sollten wir aufhören? „Beibehalten“ ist genauso wichtig wie „ändern“. So geht gute Praxis nicht verloren, wenn das Team wechselt.

Laden Sie die Leute ein, die die Arbeit gemacht haben, dazu den Sponsor. Die übrigen Stakeholder sind Leser des Ergebnisses, keine Teilnehmenden. Sechs bis acht Personen genügen.

Warum liest die meisten Lessons-Learned-Dokumente nie wieder jemand?

Weil es darauf ankommt, wo sie abgelegt werden und für wen sie geschrieben sind.

• Nach Projekt abgelegt, nicht nach Thema. Die nächste Projektleitung öffnet nicht den Ordner eines abgeschlossenen Projekts. Sie öffnet eine Vorlage.
• Keine verantwortliche Person. „Wir sollten Fristen früher vereinbaren“ stimmt, ist aber niemandes Aufgabe.
• Kein geändertes Arbeitsmittel. Die Lesson ist dokumentiert, aber nichts, was das nächste Team nutzt, hat sich verändert.
• Aus dem Gedächtnis geschrieben. Zwei Stunden Grübeln darüber, was vor sechs Monaten schiefging, ergeben vage Lessons und ein paar Schuldzuweisungen.

Gegen den letzten Punkt hilft etwas Einfaches: laufend festhalten. Wenn Sie ohnehin einen wöchentlichen Projektstatusbericht schreiben, ergänzen Sie eine Zeile: „Was hat uns diese Woche überrascht?“ Zum Projektabschluss sortieren Sie dann diese Zeilen, statt mit einem leeren Blatt anzufangen.

Wie wird aus einer Lesson eine geänderte Vorlage?

Mit einer Regel: Eine Lesson ohne verantwortliche Person und ohne geänderte Vorlage ist eine Anekdote. Jede Bewertung „ändern“ muss konkret benennen, was sich ändert, und jemand muss es bis zu einem festen Datum umsetzen.

Hier verbinden sich die Lessons mit Ihren Projektvorlagen. Wenn neue Projekte mit einer Vorlage starten, ist die Vorlage der Ort, an dem Lessons landen. Ein fehlender Punkt im Kick-off wird zur neuen Aufgabe in der Vorlage. Ein Risiko, das Sie überrascht hat, wird zur Standardzeile in der Risikoliste. Die nächste Projektleitung übernimmt die Lesson, ohne sie je gelesen zu haben.

In monday.com sieht das so aus:

• Ein Lessons-Register als Board. Ein Element pro Lesson, mit den sechs Feldern als Spalten, dazu eine Kategorie (Scope, Freigaben, Ressourcen, Kundenkommunikation) und ein Status (offen, umgesetzt, verworfen).
• Mit den Vorlagen verknüpft. Eine Spalte „Boards verbinden“ verlinkt jede Lesson mit der Vorlage, die sie verändert hat. So ist nachvollziehbar, warum eine Vorlage so aussieht, wie sie aussieht.
• Monatlich geprüft. Ein Filter auf „offene“ Lessons ist die gesamte Agenda.

Das funktioniert nur, wenn Projekte tatsächlich mit gemeinsamen Vorlagen starten. Die Vlerick Business School ist ein gutes Beispiel für diese Grundlage: Projekte sind in Portfolios organisiert, und jeder Projekttyp hat seine eigene Vorlage. Neue Projekte setzen die Teams also aus einem vordefinierten, aber zugeschnittenen Rahmen auf. Diese Einheitlichkeit gibt einer Lesson überhaupt erst einen Ort, an dem sie landen kann.

Wann lohnt sich ein Lessons-Learned-Register statt eines Word-Dokuments?

Ganz ehrlich: Für ein einzelnes Projekt reicht ein Word-Dokument. Nutzen Sie die Tabelle oben, halten Sie den Workshop ab, benennen Sie Verantwortliche, und Sie sind den meisten Teams schon voraus.

Ein Register zahlt sich aus, wenn Sie viele Projekte parallel oder direkt hintereinander steuern und diese Projekte Vorlagen teilen. Dann zeigen sich Muster: Dieselbe Verzögerung bei Freigaben in vier Projekten ist kein Pech, sondern eine Lücke in der Vorlage. Das sehen Sie aber nur, wenn die Lessons an einem Ort liegen, sortiert nach Kategorie.

Der Haken ist die Zuständigkeit. Vorlagen verwildern: Jemand kopiert ein altes Board, eine Lesson landet in der einen Vorlage und nicht in der anderen, und nach einem Jahr weiß niemand mehr, welche Version aktuell ist. Vorlagen und Register sauber zu halten ist eine Daueraufgabe, kein Projektschritt. Genau diese Art von Arbeit passt gut zu Managed Services, bei denen ein Berater dauerhaft die Struktur Ihrer monday.com Umgebung verantwortet.

FAQ

Was gehört in eine Lessons-Learned-Vorlage?

Pro Lesson: was passiert ist, die Auswirkung, die Ursache, eine Bewertung (beibehalten, ändern oder aufhören), eine verantwortliche Person und die Vorlage oder Checkliste, die sich dadurch ändert. Dazu ein Kopfbereich mit Projektname, Zeitraum, Sponsor und Teilnehmenden.

Wann sollte ein Lessons-Learned-Workshop stattfinden?

Innerhalb von zwei Wochen nach Projektabschluss, solange die Erinnerung noch frisch ist, und idealerweise mit einem während des Projekts geführten Log, sodass im Workshop sortiert statt erinnert wird. Bei langen Projekten lohnt sich an jedem großen Meilenstein ein kurzer Workshop.

Was ist der Unterschied zwischen Lessons Learned und einer Projektretrospektive?

Eine Retrospektive ist meist ein wiederkehrender Team-Termin während der Arbeit, typisch für Scrum. Lessons Learned finden in der Regel am Ende eines Projekts oder einer Phase statt und sollen verändern, wie das nächste Projekt aufgesetzt wird. Die Vorlage funktioniert für beides.

Wie stellen Sie sicher, dass Lessons Learned tatsächlich genutzt werden?

Geben Sie jeder Lesson eine verantwortliche Person und eine Frist, und verlangen Sie bei jeder Lesson mit der Bewertung „ändern“, dass sie die Vorlage, Checkliste oder den Prozess benennt, der angepasst wird. Prüfen Sie offene Lessons dann monatlich, bis sie abgeschlossen sind.

Damit das nächste Projekt klüger startet

Starten Sie mit der Vorlage oben in Ihrem aktuellen Projekt. Wenn Sie viele ähnliche Projekte steuern und möchten, dass Ihre Lessons in den Vorlagen landen, die Ihre Teams tatsächlich nutzen, schauen wir uns Ihr Setup gern gemeinsam an. Buchen Sie ein kostenloses Erstgespräch mit Tryve.

Sprechen Sie mit Tryve

Tryve ist monday.com Platinum Partner. Jedes Projekt beginnt mit einem strukturierten Discovery-Workshop, der von Ihren tatsächlichen Prozessen ausgeht, nicht von einer generischen Vorlage. Erfahrene Berater bleiben bis zur Akzeptanz im Team dabei, nicht nur bis zum Go-live. Buchen Sie ein kostenloses Erstgespräch.

Quellen

• Tryve Case Study: Vlerick Business School
• monday.com Support: die Spalte „Boards verbinden“
• Der Scrum Guide: Sprint Retrospective