Ausgangslage
Besprochen wurde viel, aber nicht koordiniert. Technische Fragen landeten im Lenkungskreis, Grundsatzentscheidungen wurden auf dem Shopfloor diskutiert, und Lessons Learned existierten als Dokument statt als Praxis: gesammelt am Projektende, abgelegt, nie wieder geöffnet. Dieselben Fehler traten in den Folgeprojekten erneut auf — nicht aus Nachlässigkeit, sondern weil niemand zum richtigen Zeitpunkt danach gefragt wurde.
Einen Lessons-Learned-Prozess einführen, der in Standards einfließt statt in der Ablage zu verschwinden
Aufbau einer durchgängigen Review-Struktur, in der jede Ebene ihre eigene Frage beantwortet und ihren eigenen Takt hat. Shopfloor-Meetings für das, was heute hakt. Design-Reviews für die technische Lösung, am Objekt und mit denen, die sie bauen. Projekt-Reviews für Fortschritt, Risiken und Abweichungen. Lenkungskreis für Entscheidungen oberhalb der Projektleitung — und nur für diese. Jede Ebene bekam ein Format, das in der vorgesehenen Zeit durchführbar ist; alles andere wird beim ersten Terminkonflikt gestrichen.
Darüber die Lernschleife: Einen Lessons-Learned-Prozess einführen heißt nicht, ein Dokument anzulegen. Erkenntnisse wurden nicht archiviert, sondern in die Vorlagen und Checklisten eingearbeitet, mit denen das nächste Projekt startet. Entscheidend war die Regel, dass ein Review keine Schuldfrage klärt — wo Schuld verhandelt wird, wird nichts berichtet, was zählt.
Ergebnis
Themen wurden dort entschieden, wo sie hingehören, statt dort, wo gerade jemand zuhörte. Erfahrung wanderte in den Standard statt in die Ablage — daran misst sich, ob man einen Lessons-Learned-Prozess einführen konnte oder nur ein Formular. Und Probleme wurden früher gemeldet, weil eine Meldung den Prozess in Bewegung setzte, ohne der meldenden Person zum Nachteil zu geraten — früh gemeldete Probleme sind die billigen.
Weiterführend: Projektqualität durch Lessons Learned steigern · Alle Projekterfahrungen im Überblick