Lessons-Learned - Wenn das Ende nahe ist

Das Durchführen von Lessons Learned Sitzungen gehört zum guten Theorieton des Projektmanagements. Aber kaum ein Prozess in der Durchführung von Projekten wird so stiefmütterlich behandelt wie die viel besungenen Lessons Learned. Woran liegt das? Ist es nur die fehlende Zeit für das vermeintliche Kaffeekränzchen oder steckt da noch mehr dahinter?

Begriffsklärung

Viel wird schon klar, wenn wir Lessons Learned einmal ausschreiben. Es heißt nämlich „Lessons which I have learned“ und nicht „Lessons which you should have learned“ 🙂

Es geht also nicht darum, am Ende auch noch die „Verwundeten zu erschießen“ (Kundenzitat), sondern wirklich Verbesserungsvorschläge für die Zukunft zu erarbeiten. Die Nähe zur Inquisition, zur Schuldzuweisung, zur Anklage ist allerdings nicht von der Hand zu weisen. Gerade, wenn das frisch beendete Projekt nicht ganz reibungslos verlief, um es einmal vorsichtig zu formulieren. Daher bedarf es einer gekonnten Moderation, dieses Meeting erfolgreich über die Bühne zu bekommen.

Die psychologische Komponente

Gehen wir grundsätzlich einmal davon aus, dass es im Projekt hoch hergegangen ist. Da wurden Kompromisse gefunden, Konflikte überwunden und wahrscheinlich auch so mancher Noteinsatz gefahren. All diese Situationen sind am Projektende abgeschlossen. Ein Grund, warum Lessons Learned Sitzungen nicht gerade die Lieblinge der Projektgruppe sind, kann auch daran liegen, dass bereits überwundene Ängste, Konflikte und Probleme erneut thematisiert werden und damit wieder auf den Tisch kommen. „War doch vor Monaten ein Thema – müssen wir nicht nochmal durchkauen“

Das brauche ich nicht unbedingt.

Sobald Lessons Learned Sitzungen wieder alte Kamellen thematisieren, wird die Teilnehmerzahl und die Motivation zu derartigen Veranstaltungen rapide abnehmen. Doch nicht nur die Sorge vor einem bereits abgeschlossenen Konflikt bzw. Problem hält die Teilnehmer davon ab, zu diesen Sitzungen zu kommen. Auch die gefühlte Nicht-Würdigung erreichter Kompromisse und Workarounds.

„Muss ich mir denn von irgend so einer QS – Nase am Ende auch noch sagen lassen, wo überall unsere Fehler und Prozessverstöße lagen?“

Nein, muss ich nicht. Da habe ich besseres zu tun.

Warum denn überhaupt Lessons Learned?

Dabei geht es bei Lessons Learned überhaupt nicht – nullkommanicht – um Schuldzuweisungen, sondern um Verbesserungspotenzial für das nächste Projekt zu identifizieren. So gesehen findet sich Lessons Learned in bester Gesellschaft mit einer Reihe anderer Managementtechniken, die ebenfalls auf eine Verbesserung oder Optimierung abzielen.

Gleiten diese Sitzungen in persönliche Schuldzuweisungen ab, bleiben nicht nur wichtige Protagonisten dieser Sitzung fern, sondern wir werden wahrscheinlich die gleichen Fehler nochmals machen. Und im Zweifelsfall dann auch gerne ein drittes Mal.

Lessons which I have learned

Wie bei den meisten Kommunikationsaspekten bzw. Interaktionen ist es günstig, auch im Bereich Lessons Learned vorrangig „Ich-Botschaften“ zu senden.

Damit ist allerdings nicht gemeint, dass die Ich-Botschaft so ausfallen sollte:

„Ich bin der Meinung, dass Sie Mist gebaut haben“.

Es geht vielmehr um den Aspekt was ich persönlich – ich – aus der Vergangenheit aus den gemachten Erfahrungen mitnehme und wie ich gedenke, künftig diese Erfahrung umzusetzen. Lernen eben. Diese Erfahrung darf kann und soll auch durchaus subjektiv sein und meine emotionale Ebene ansprechen. Es geht hier nicht ausschließlich um Prozessverbesserungen oder neue Spalten in einem Excelblatt, sondern vielmehr um den Umgang miteinander. Und ja, der Grenzgang zwischen eigener gemachter Erfahrung und Anklage meiner Team Mitglieder ist trickreich.

Übrigens nicht nur im Projekt, sondern überall wo mehr als zwei Personen zusammen sind.

Das Idealformat

Wie sieht denn das Idealformat aus? Gerade wenn das Projekt viel negative Erfahrung sammeln musste, wäre es verhängnisvoll, diese Lektionen nicht in irgendeiner Form weiterzugeben. „Kein Projekt ist ganz umsonst – es kann immer noch als schlechtes Beipiel dienen“ hat einen durchaus wahren Kern. Wie kann das allerdings gesichtswahrend erfolgen? Hier ein paar Ideen

Nehmen Sie einen Moderator zur Hilfe. Je kritischer die Vergangenheit, desto notwendiger.
Betrachten Sie keinesfalls nur einseitig die negative Seite. Auch nicht gekünstelt positiv werden. Aber jedes Projekt hatte auch gute Seiten.
Wenn die subjektiv emotionale Ebene angesprochen werden sollte, wäre es günstig, wenn das Meeting außerhalb der Büroräumen stattfinden könnte
Planen Sie auch eine gemeinsame Teamaktivität ein. Nicht nur an der Bar sitzen…
Verwenden Sie das Lessons Learned Meeting keinesfalls um schwelende Konflikte anzusprechen bzw. versuchen, diese auszuräumen. Das sollte im Vorfeld geschehen und sollte nicht während des Meetings erfolgen.
Wenn die Problemsituation so groß geworden ist, dass jede Art von Nachbetrachtung auf jeden Fall in ein Desaster münden würde, lassen Sie lieber die Finger davon und nehmen selbst als Lessons Learned mit, dass künftig nicht bis zum Schluss gewartet werden sollte. Und dass Konfliktbereinigung oder auch eine echte Auseinandersetzung nicht als „Lessons Learned“ tituliert werden sollte.
Vermeiden Sie unbedingt, dass „Lessons Learned“ negativ konotiert werden. Das ist das Gleiche wie mit dem Wort „Feedback“. Im Prinzip wahnsinnig gut, aber 9 von 10 Beteiligten zucken erst einmal zusammen und sind auf das Schlimmste gefasst, weil Feedback gerne als Synonym für eine kräftige Haarwäsche missbraucht wird.

Der kleine Bruder: Die Retrospective

Über die Punkte oben können die reinrassigen Agilisten nur müde lächeln. Dort ist dann der Satz zu hören, dass Lessons Learned total old-school sind. Besser sind auf jeden Fall Retrospectiven, abgekürzt Retros.

Stimmt das?

Ja. Wenn auch mit einem Ja, aber. Aber der Reihe nach: Retros werden üblicherweise am Sprintende gemacht und haben dann die gleiche Funktion wie die gelernten Lektionen. Da aber Sprints viel häufiger enden als Projekte, werden naturgemäß auch mehr Retros gemacht.

Ein klassisches Projekt, das sagen wir mal ein Jahr Laufzeit hat, hat dann vielleicht am Ende eine (1) einzige Lessons Learned Sitzung, während das gleiche Projekt bei 3wöchigen Sprints ungefähr 20 (!!) mal zusammengekommen ist.

Hier – und genau hier – liegt das Wunder der Retros – es ist ihre methodisch gewollte Häufigkeit. Dass bei den Retros meist auch noch lustige Spielchen gemacht werden (Seestern, Wetterlage, PlusDelta, 5S usw.) ist zwar nett, ist aber nicht der zentrale Erfolgsfaktor. Nein, es ist die Häufigkeit. Es ist so eine Art Dauer-Lessons-Learned, eine gelebter Deminzyklus der ständigen Verbesserung, eine Übung, an die sich dann alle schon gewöhnt haben und die dadurch nicht diesen inquisitorischen Charakter hat.

Natürlich können auch Retros falsch gemacht werden und die Zeit für Ringelpiez und Kaffeetrinken kann „sinnvoll“ für die Diskussion von Produkt-Features verwendet werden (Kundenzitat). Da ist es egal, was ich falsch mache. Und natürlich gelten die oben gemachten Grundregeln wie z.B. Ich-Botschaften usw. auch für Retros.

Aber grundsätzlich ist die Idee der permanenten Lessons-Learned-Schleife eine genialer Gedanke, der das Team definitiv nach vorne bringt. Und wer sagt denn, dass Retros nur in agilen Projekten gemacht werden können? Wer hält uns denn davon ab, auch in einem konventionellen Projekt Retros zu machen?

Niemand. Außer wir selbst…