Lessons Learned
Lessons Learned ist eine strukturierte Bewertung, die beim Abschluss eines Projekts oder einer Phase durchgeführt wird und in der das Team festhält, was funktioniert hat, was gescheitert ist, die Ursachen des einen wie des anderen und Empfehlungen für die folgenden Arbeiten. Das BABOK nennt diese Technik auch eine Retrospektive, und in der Praxis spricht man von Projektnachbetrachtung. Ihr Rohstoff ist ein offenes Sprechen über das, was schiefgelaufen ist, und genau dieses Sprechen fehlt, wenn die Beteiligten fürchten, zur Verantwortung gezogen zu werden. Psychologische Sicherheit ist die Bedingung, ohne die die Technik nur Gemeinplätze hervorbringt.
Ziel
Lessons Learned dient dazu, die Erfolge, die Verbesserungsmöglichkeiten, die Fehlschläge und die Empfehlungen zusammenzutragen und zu dokumentieren, die die Leistung späterer Projekte oder Phasen steigern. Es ist eine Technik der rückblickenden Bewertung: Sie blickt auf abgeschlossene Arbeit zurück, damit die nächste besser läuft, und sie erzeugt ein Lessons-Learned-Register, das die Organisation wiederverwendet.
Ihre Besonderheit liegt in dem, wovon sie abhängt. Ein Interview oder eine Dokumentenanalyse gewinnt ihren Wert aus Fakten, die bereits vorliegen. Eine Lessons-Learned-Sitzung gewinnt ihren aus dem, was die Beteiligten zu sagen bereit sind, und dieser Stoff ist fragil. Das BABOK formuliert es unter den Grenzen der Technik: Die offene Diskussion findet nicht statt, wenn die Beteiligten eine Schuld zuweisen wollen, und sie zögern häufig, Probleme zu dokumentieren und zu erörtern. Der PMBOK Guide führt Lessons Learned unter den Wissensspeichern der Organisation, doch ein Speicher, der von zurückgehaltenem Sprechen gespeist wird, verzeichnet vor allem das, was sich ohne Risiko sagen liess.
Der Gegenstand der Technik ist ein doppelter. Sie zielt auf ein Ergebnis, das Register, und auf eine Bedingung, die Sicherheit, die dieses Ergebnis offen macht. Eine Sitzung zu führen heisst zuerst, diese Bedingung zu bewirtschaften, was sie von einem Projektabschlussbericht unterscheidet.
Anwendung
Wann einsetzen
- Abschluss eines Projekts oder Meilensteins: solange die Erinnerung frisch ist, bevor sich das Team zerstreut.
- Ende einer Iteration oder eines Sprints: Die agile Retrospektive ist dieselbe Technik, im kurzen Takt durchgeführt, um Qualität und Wirksamkeit zu steigern.
- Nach einem Vorfall oder einem schwierigen Go-live: eine kostspielige Episode in nachvollziehbare Empfehlungen verwandeln.
- Stabiles Team, das Projekt um Projekt bearbeitet: Das angesammelte Vertrauen macht das Sprechen mit jeder Sitzung offener.
- Von der Leitung getragene kontinuierliche Verbesserung: ein Rahmen, in dem das Melden eines Problems für die meldende Person folgenlos bleibt.
Wann nicht einsetzen
- Ein Klima der Schuldzuweisung, das die Moderation nicht entschärfen kann: etwa im Nachgang von Entlassungen wird das offene Sprechen ausbleiben; auf eine anonyme Erhebung, eine externe Moderation zurückgreifen oder die Sitzung verschieben.
- Kein Kanal, in dem die Empfehlungen landen: ohne Verantwortliche, ohne Verbesserungs-Backlog und ohne konsultierten Speicher bleibt das Register toter Buchstabe; zuerst den Nachverfolgungsmechanismus reparieren oder einen einfachen Zwischenstand halten.
- Eine kurze Aufgabe ohne Tragweite: Der Aufwand einer moderierten Sitzung übersteigt ihren Ertrag; eine Notiz von zwei Zeilen genügt, und die Technik bleibt den Meilensteinen vorbehalten, aus denen es etwas zu lernen gibt.
Beschreibung
Das Format ist frei, und das BABOK besteht darauf: Die Sitzung nimmt die Form an, die die wichtigsten Stakeholder akzeptieren, eine moderierte Besprechung mit Traktandenliste und zugeteilten Rollen oder eine informelle Arbeitssitzung. Sie wird beim Abschluss eines Projekts ebenso gehalten wie am Ende jedes internen Meilensteins. Die Bewertung erstreckt sich auf die Tätigkeiten und Ergebnisse der Business-Analyse, die endgültige Lösung, die eingeführten oder abgelösten Technologien, die Auswirkungen auf die Prozesse, die Abweichung zwischen erwarteter und erzielter Leistung, die Varianzen, die Grundursachen, die auf die Resultate gedrückt haben, und die Empfehlungen für das Weitere. Wenn die Arbeit nennenswerte Erfolge verzeichnet hat, hat ein Teil des Feierns seinen Platz und bringt eine Sitzung ins Gleichgewicht, die Probleme ins Negative ziehen.
Zuerst die Bedingung: ein offenes Sprechen
Die ganze Technik beruht auf einer sozialen Tatsache. Ein Beteiligter, der glaubt, ein Eingeständnis werde ihm vorgehalten, wird es nicht aussprechen, und das Register wird dieses Schweigen erben. Zwei Regeln, die die Moderation hält, öffnen das Sprechen. Die erste trennt die Person vom Prozess: Man untersucht, warum ein Schritt gescheitert ist, nicht wer ihn ausgeführt hat, und ein Satz, der beginnt, einen Schuldigen zu benennen, wird zum Mechanismus zurückgeführt. Die zweite verankert die Diskussion an vorab vorbereiteten Belegen, Kennzahlen, Varianzen und Daten aus den Ergebnissen, denn eine geteilte Zahl verschiebt die Debatte von einem Streit der Erinnerungen hin zu einer Feststellung, die niemand persönlich besitzt.
Die Rolle der Moderation
Das BABOK hält fest, dass eine proaktive Moderation oft nötig ist, damit die Diskussion auf Lösungen und Verbesserungen ausgerichtet bleibt. Das setzt eine neutrale Moderation ohne persönliches Interesse an den Feststellungen voraus, was für jemanden ausserhalb der Weisungslinie des Teams spricht, wenn das Thema heikel ist. Ihre konkrete Arbeit besteht darin, beide Hälften einzusammeln, Erfolge und Probleme, den Raum davon abzuhalten, sich auf die erste benannte Person festzulegen und jede Feststellung bis zu ihrer Grundursache zu treiben, bei Bedarf gestützt auf die Ursachenanalyse, und weiter bis zu einer Empfehlung. Eine Feststellung, die beim Symptom stehen bleibt, « die Tests haben die Langsamkeit verpasst », ist noch keine Lehre, solange die Ursache nicht benannt ist.
Wenn die Sicherheit dünn ist
Reicht das Vertrauen nicht aus, um die Offenheit zu sichern, geht die Erhebung der Sitzung voraus und erfolgt unter dem Schutz der Anonymität. Ein vor der Besprechung verteilter Fragebogen sammelt die Feststellungen, ohne sie an einen Namen zu binden, und die Sitzung arbeitet danach an einer bereits konsolidierten Liste, statt von jedem zu verlangen, sich live zu exponieren. Es ist dieselbe Wahl, die dazu führt, die Retrospektive von einer dritten Person leiten zu lassen statt von der Projektleitung, deren blosse Anwesenheit die Hälfte der Feststellungen zurückhalten kann.
Was die Sitzung hervorbringt
Das Ergebnis ist das Lessons-Learned-Register, in dem jede Feststellung ihre Grundursache, eine Empfehlung und eine verantwortliche Person trägt. Zwei Spalten machen daraus eine Lehre statt einer Klage: die Ursache, ohne die eine Feststellung nichts Umsetzbares sagt, und die verantwortliche Person, ohne die eine Empfehlung keine Adressatin hat. Ist das Sprechen einmal gesichert, verlagert sich die Falle auf die Nachverfolgung: Ein Register, das geschrieben und dann abgelegt wird, das keine Startbewertung wieder öffnet, ist die leiseste Fehlerform, denn das Dokument sieht fertig aus, während die Schleife offen geblieben ist.
KI-Überlegungen
Die Hilfe steht vor und nach der Sitzung. Davor bündelt ein Modell verstreute Beobachtungen aus Tickets, Protokollen und Iterationsberichten und schlägt Kandidaten für Feststellungen vor, die kein Beteiligter aus dem Gedächtnis formuliert hätte. Eine vorgängige anonyme Erhebung gewinnt durch diese Vorverarbeitung: Sie verdichtet die Rückmeldungen, ohne ihre Urheber zu exponieren. Danach bringt ein Modell die Empfehlungen in Form, prüft, dass jede eine verantwortliche Person und einen Termin trägt, und markiert die Zeile, die mangels Ursache oder Empfehlung eine blosse Feststellung bleibt.
Die Grenze ist die Bedingung der Technik selbst. Psychologische Sicherheit entsteht zwischen Menschen in einem Raum, und kein Werkzeug stellt sie her. Eine von einem Modell vorgeschlagene Grundursache ist plausibel und noch zu verifizieren: Sie tritt in die Sitzung als eine gegen den realen Projektkontext zu prüfende Hypothese ein. Der Stoff schliesslich ist oft namentlich oder heikel, Teambeurteilungen, Vorfälle, personalbezogene Elemente, und ihn in ein externes Werkzeug einzugeben würde die Vertraulichkeit verraten, auf der die Offenheit beruht, ausserhalb der gesetzlichen Grundlage und der Berechtigung, die der Datenschutz verlangt.
Beispiele
Zwei Fehlschlagzeilen, jene, die einen unzureichenden Test und einen schlecht gefassten Umfang eingestehen, erscheinen im Register nur, weil der Raum sicher genug war, um sie zu benennen, ohne einen Schuldigen zu suchen. Jede Zeile trägt eine Feststellung, ihre Grundursache, eine Empfehlung und eine verantwortliche Person. Sie liest sich als der Übergang von einer Beobachtung zu einer anvertrauten Handlung.
Der Rahmen: eine Abschlussbewertung nach dem Go-live eines Online-Abrechnungsportals bei einer Krankenkasse der Westschweiz.
| Feststellung | Grundursache | Empfehlung | Verantwortlich |
|---|---|---|---|
| Die im Betrieb aufgetretene Langsamkeit war in den Abnahmetests nicht erkannt worden. | Der Testdatensatz bildete das reale Volumen der Abrechnungen nicht ab. | Vor den Abnahmetests einen Datensatz im Massstab der Produktion bereitstellen. | Testverantwortliche |
| Zwei Iterationen für das Nachschärfen des Umfangs aufgewendet. | Die Abnahmekriterien waren beim Start nicht mit der Fachseite validiert worden. | Die Abnahmekriterien vor der Entwicklung durch die Auftraggeberseite validieren lassen. | Business Analyst |
| Starke Annahme des Self-Service durch die Versicherten ab der Eröffnung. | Früh gehaltene Usability-Workshops mit einem Panel von Versicherten. | Diese Nutzer-Workshops bei den kommenden Projekten früh wieder durchführen. | Product Owner |
| Das Register des vorangegangenen Projekts wurde beim Start nicht konsultiert. | Keine Auswertung früherer Erkenntnisse ist bei der Eröffnung eines Projekts vorgesehen. | Jedes Projekt mit einer Auswertung des Registers vergleichbarer Projekte eröffnen. | Projektbüro |
Visualisierungen
Das Register besteht aus Zeilen und Spalten, also wird es als Tabelle in einem Dokument geführt, die sich sortiert und beim nächsten Projekt wieder öffnet. Eine zweite Abbildung beleuchtet den Kreislauf, den die Tabelle nicht zeigt, vom Meilenstein bis zum Start des nächsten Projekts, mit seinen zwei Bruchstellen: die ohne Ursache und ohne Verantwortliche festgehaltene Feststellung und das geschriebene und dann nie wieder geöffnete Register. Diese beiden Brüche sind dieser Technik eigen, und ein generisches Rad der kontinuierlichen Verbesserung würde sie nicht markieren.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Mittel | Kennzahlen und Varianzen zusammentragen, aber auch den Sicherheitsrahmen vorbereiten: Wahl der Moderation, vorgängige anonyme Erhebung, wenn die Offenheit nicht gegeben ist. |
| Durchführung | Niedrig | Eine Sitzung von zwei Stunden genügt für ein mittelgrosses Projekt. Der Aufwand liegt in der Aufmerksamkeit der Moderation. |
| Dokumentation | Hoch | Das Register wird geschrieben, mit dem Verbesserungs-Backlog verbunden und nachverfolgt, bis jede Empfehlung bearbeitet ist. Diese Nachverfolgung ist die dauerhafte Last. |
Werkzeuge
Die Sitzung verlangt nur eine live geführte Unterlage, Flipchart, Whiteboard oder geteiltes Dokument, und aus der Ferne übernimmt ein digitales Whiteboard (Miro, Mural) die Rolle der Wand. Wenn die Sicherheit dünn ist, zählt das Werkzeug der anonymen Erhebung: Ein Online-Fragebogen sammelt die Feststellungen vor der Sitzung, ohne sie an einen Namen zu binden.
Das Register lebt in einer Tabellenkalkulation oder im Dokumentenraum der Organisation, wo die Spalten der verantwortlichen Person und des Termins zu sichtbaren Vorgaben werden. Die Nachverfolgung gewinnt, wenn sie in das gewohnte Arbeitswerkzeug übergeht, wobei jede Empfehlung zu einem Element des Verbesserungs-Backlogs oder zu einem verfolgten Ticket wird. Plattformen für das Incident-Management bieten schuldfreie Post-mortem-Vorlagen, in denen Analyse und Massnahmen strukturierte Felder sind, nützlich, wenn die Sitzung auf einen Vorfall folgt.
Quellen
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.27 Lessons Learned: der Zweck, das freie Format, die geprüften Gegenstände, die Stärken und vor allem die Grenzen, die an der offenen Diskussion und an der Moderation hängen.
- PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8. Auflage: pmi.org/standards/pmbok. Lessons Learned als einer der Wissensspeicher der Organisation.
- Schwaber und Sutherland, The Scrum Guide (2020), Sprint Retrospective: scrumguides.org. Die wiederkehrende Form der Technik, in jedem Sprint gehalten, um Qualität und Wirksamkeit zu steigern.
- Schweizerische Eidgenossenschaft, Bundeskanzlei, HERMES 2022, Phase Abschluss: hermes.admin.ch. Die Projektschlussbeurteilung und die beim Abschluss festgehaltenen Projekterfahrungen.

