Lessons Learned – Projektrückschau oder Retrospektive – bezeichnet den strukturierten Prozess, nach Abschluss eines Projekts, eines Incidents oder einer Projektphase systematisch zu dokumentieren, was gut funktioniert hat, was nicht funktioniert hat und was beim nächsten Mal anders gemacht werden sollte. Das Ziel ist organisationales Lernen: Erkenntnisse sollen nicht im Kopf einer Einzelperson verschwinden, sondern als institutionalisiertes Wissen für zukünftige Projekte und Teams zugänglich gemacht werden.
Lessons Learned sind in vielen Projekten ein blinder Fleck: Im Abschluss-Stress fehlt die Zeit, nach der Einführung ist das Team bereits beim nächsten Projekt, und niemand macht sich die Mühe, Erkenntnisse strukturiert zu dokumentieren. Das Ergebnis: Dieselben Fehler werden in jedem Folgeprojekt neu gemacht. Eine Organisation, die systematisch aus ihren Projekten lernt, entwickelt einen kompoundierten Wettbewerbsvorteil, der schwer zu kopieren ist.
Was dokumentiert wird: positiv und verbesserungswürdig
Was gut funktioniert hat
Bewährte Praktiken, die beim nächsten Projekt von Anfang an eingesetzt werden sollten. Nicht selbstverständlich – explizit zu benennen und zu reproduzieren. Beispiel: Frühe Einbindung des DSB hat einen Neustart der Datenschutz-Architektur verhindert.
Was verbessert werden sollte
Fehler, Verzögerungen, Missverständnisse und Ineffizienzen – ohne Schuldzuweisungen. Systemperspektive statt Personenkritik: Was hat das System, den Prozess oder die Kommunikation anfällig gemacht?
Lessons Learned wirksam durchführen
- Zeitnah – nicht am Jahresende: Direkt nach Projektabschluss oder nach einem Incident, solange Eindrücke frisch sind. Retrospektiven nach 6 Monaten ergeben verzerrte Erinnerungen
- Psychologische Sicherheit: Blameless Retrospective – keine Schuldzuweisungen, keine Konsequenzen für offenes Feedback. Nur dann werden echte Probleme genannt
- Konkret und actionable: „Kommunikation verbessern“ ist kein Lessons-Learned. „Fachbereich ab Anforderungsphase im wöchentlichen Review einbinden“ ist eines
- Zugänglich speichern: Im Projekt-Wiki oder Knowledge-Base, so dass zukünftige Projektleiter darauf zugreifen können – nicht im persönlichen Ordner des Projektleiters
- In die Vorbereitung folgende Projekte integrieren: Lessons Learned aus ähnlichen Projekten in der Planungsphase aktiv durchlesen und berücksichtigen
Praxisbeispiel
Ein Automationsdienstleister führt nach jedem abgeschlossenen Kundenprojekt eine 90-minütige Lessons-Learned-Session durch. Format: Start / Stop / Continue (je 15 Minuten Sammlung, 30 Minuten Diskussion, 30 Minuten Maßnahmen). Top-3-Learnings aus den letzten 4 Projekten kumuliert: Start: Datenschutz-Review vor Architekturentscheidung, nicht danach (2× teurer Neustart verhindert). Stop: Scope-Änderungen per E-Mail akzeptieren – ab sofort nur noch mit schriftlichem Change-Request und Aufwandsschätzung. Continue: Wöchentliches 15-Minuten-Standup mit Kunden-Product-Owner. Diese 3 Maßnahmen sind jetzt in der Projekt-Checkliste verankert. Ergebnis über 12 Monate: Nachträgliche Sicherheits-Reworks von 3 auf 0 gesunken, Scope-Creep-Disputes von 5 auf 1 gesunken.
