Die lernende Organisation verwirklichen

Lessons Learned (LL) umfassen die schriftliche Aufzeichnung und das systematische Sammeln, Bewerten und Verdichten von Erfahrungen, Entwicklungen, Hinweisen, Fehlern und Risiken in Projekten. Deren Beachtung und Vermeidung kann sich nützlich für zukünftige Projekte erweisen. Lessons Learned sind ein Teil der Projektabschlussdokumente, können jedoch auch für jeden anderen Vorgang in einer Organisation oder Firma genutzt werden und werden in der Regel in strukturierter, zugänglich archivierter Form zur Verfügung gestellt.

Lernen und Lessons Learned – die Gefahr der isolierten Betrachtung

Betrachtet man Lessons Learned in der Praxis, werden verschiedene Mängel und Lücken sichtbar. Folgende Situationen sind beispielsweise anzutreffen:

• Lessons Learned sind Teil des definierten Projektvorgehens, werden jedoch nur gemacht, weil es vorgeschrieben ist.
• Lessons Learned verschwinden in der Projektdokumentation und werden nicht mehr verwendet.
• Der Projektleiter erstellt die Dokumentation alleine, damit das Projekt abgeschlossen werden kann.
• Lessons Learned sind im Allgemeinen in den Produktionsprozessen nicht zu finden.
• Es besteht keine systematische Sammlung und Auswertung der Lessons Learned.
• Der Nutzen von Lessons Learned wird nicht ausgewiesen.

In den meisten Fällen werden Lessons Learned als einzelnes Ereignis verstanden und sind somit weder in der Organisation verankert noch sind sie ein Bestandteil des organisationalen Lernens. Damit ist auch die Wirkung sehr beschränkt und findet meistens nur in den entsprechenden Teams statt. Um diese Mängel und Lücken zu überwinden, darf der Fokus nicht nur auf Lessons Learned liegen, sondern muss im Kontext der lernenden Organisation gesehen werden.

Lernvorgänge in Schleifen

Eine lernende Organisation ist idealerweise ein System, dass sich permanent in Bewegung befindet. Ereignisse werden als Anregung entgegengenommen und für Entwicklungsprozesse genutzt, um die Wissensbasis und die Handlungsspielräume an die neuen Erfordernisse anzupassen. Lernen in der Organisation kann nur stattfinden, wenn die Menschen darin auch lernen wollen und die Rahmenbedingungen dafür geschaffen sind. Die Lernschleifen von Argyris und Schön sind ein gutes Modell um Lernvorgänge auf ihre Wirkung und Integration in Organisationen zu überprüfen. Die Abb. 1 zeigt diese Lernschleifen, die ineinander verschachtelt sind. Man spricht hier auch von Lernen erster, zweiter und dritter Ordnung. Lernen zweiter Ordnung kann nicht stattfinden, wenn Lernen erster Ordnung nicht vorhanden ist.

1. Single Loop: Tun wir die Dinge richtig? Diesen Loop führt jedermann laufend durch. Im Single Loop findet individuelles Lernen statt, wenn die Resultate unserer Aktionen von den Erwartungen abweichen.
2. Double Loop: Tun wir die richtigen Dinge? In diesem Loop, dem Lernen zweiter Ordnung, hinterfragen wir unsere Annahmen: a. Warum erreichen wir mit unseren bisherigen Lösungen nicht die gewünschten Resultate? b. Warum glauben wir, dass sie die erwarteten Ergebnisse bringen können? Durch die Korrektur der Annahmen entstehen ganz andere Aktionen, die dann die gewünschten Resultate bringen können.
3. Triple Loop: Wie entscheiden wir, was richtig ist? Dreifach-LoopLernen beinhaltet Grundsätze. Das Lernen geht über Einsicht und Muster zum Kontext. Das Ergebnis schafft eine Verschiebung unseres Verständnisses, unserer Sicht der Dinge. Diese Form des Lernens fordert uns heraus zu verstehen, wie Probleme und Lösungen verbunden sind. Der Zusammenhang zwischen Organisationsstruktur und Verhalten wird grundlegend geändert, weil die Organisation lernt, wie man lernt.

Anzustreben ist ein Double-LoopLernen, da hierbei die Handlung hinterfragt wird. Im Zusammenhang mit Lessons Learned heisst dies, dass nicht nur die Aktionen verbessert werden, sondern die Vorgaben und Annahmen laufend den Erfordernissen angepasst werden können.

Implementierung im IT Projektumfeld einer Bank

In der Credit Suisse IT wurde, um eine höhere Qualität und Effizienz in den IT-Projekten zu erreichen, die Entwicklung von Software nach dem Referenzmodell CMMI (Capability Maturity Model Integration; Level 3) implementiert und zertifiziert. Die in CMMI für Entwicklung enthaltenen Praktiken umfassen die Bereiche Projektmanagement, Prozessmanagement, Systementwicklung, Softwareentwicklung und andere unterstützende Prozesse. Innerhalb dieser Definition wird die Anwendung von Lessons Learned gefordert und ist daher mehrfach erwähnt. Gemäss dieser Definition sollen die Lessons in einer «Bibliothek der Prozess-Assets» gespeichert werden, um zur Verbesserung dieses Umfeldes zu dienen. Die Umsetzung dieser Vorgabe ist offen und erfolgt individuell.

Der neu erstellte Wissensprozess Lessons Learned ist mit dem Projektmanagement (PM-)Prozess verbunden. Der Auslösepunkt (Trigger) zur Erstellung von Lessons Learned ist im PM-Prozess verankert und die Lessons werden von diesem Prozess abgerufen und direkt verwendet oder an die entsprechende Disziplin weitergereicht. Die nachfolgende Abbildung zeigt schematisch den Ablauf.

Aus der Abbildung ist klar ersichtlich, welche Schritte innerhalb des PM-Prozesses ablaufen und bei welchen das Projektteam nicht oder sehr wenig beteiligt ist. Dieser Wissensprozess wurde in der Organisation und in Verbindung mit den CMMI-Vorgaben mit folgendem Ablauf implementiert:

1. Innerhalb des PM-Prozesses ist der Projektleiter aufgefordert, eine Lessons-Learned-Sitzung einzuberufen. Dazu bekommt er die Unterstützung des zentralen Wissensmanagement-Teams, das ihm einen neutralen Moderator zuweist.
2. In einem ca. dreistündigen, moderierten Meeting, werden die Lessons mit den Projektteammitgliedern erstellt (Create). Durch strukturiertes Brainstorming mit anschliessender Bewertung werden die Top-Themen herausgefiltert und mit folgenden Fragen besprochen: a. Was hätte passieren sollen? b. Was ist wirklich passiert? c. Warum ist es so gelaufen? d. Was wird beim nächsten Mal anders gemacht?
3. Der Moderator erstellt daraus einen Report, der normalerweise drei bis vier Lessons enthält (Organize). Er wird von den Teilnehmern überprüft und genehmigt.
4. Nun können die Lessons in einem zentralen Repository gespeichert werden und stehen somit allen Berechtigten zur Verfügung (Distribute).
5. Der PM-Prozess gibt vor, dass bei gewissen Phasen das Repository nach anwendbaren Lessons durchsucht werden (Apply).
6. Lessons werden von Einzelpersonen (Reuse) verwendet und auf die momentane Situation angepasst und modifiziert (Persönliches Evolve). Zusätzlich werden die gespeicherten Lessons halbjährlich ausgewertet und definierten Themenbereichen zugeordnet. Diese werden dann den Prozessmanagern der Prozessbereiche übergeben, die sie als Basis für die Prozessverbesserung nutzen (Organisationales Evolve). Dadurch sollten die gleichen Themen nicht mehr oder weniger häufig in den Lessons Learned auftauchen.

Das Design des Prozesses war darauf ausgerichtet individuelles Lernen und organisationales Lernen innerhalb der IT-Projektumgebung zu etablieren. Damit sind der Single Loop und der Double Loop in der Organisation implementiert. Begleitend wurden die notwendigen Betriebssprozesse der LL-Umgebung etabliert.

Wirkung und Nutzen

Durch den offenen Prozess, insbesondere bei der Erstellung der Lessons (Create), konnte viel auf der individuellen Ebene bewirkt werden. Die hierarchische Organisation wurde durch den Wissensprozess durchbrochen und neue Elemente wurden eingeführt. Die Folge war eine kleine Kulturveränderung. Die Teilnehmer der LLMeetings konnten in folgenden Bereichen profitieren: –

• Teambuilding und gemeinsames Verständnis
• Zusätzliche Erkenntnisse aus dem Projekt von anderen Rollen
• Erfahrung in einer offenen Gruppenreflektion mit einem neutralen Moderator
• Verbesserung der Projektergebnisse durch die Verwertung von Lessons Learned in verschiedenen Situationen
• Aufbau von Kontakten und einem Netzwerk für ähnliche Projektsituationen
• Persönliche und professionelle Weiterentwicklung

Die Akzeptanz auf der organisatorischen Ebene war um einiges geringer, obwohl eine LL-Umgebung zu den Anforderungen einer CMMI- Implementation gehört. Die Auswertungen aus den gesammelten Lessons Learned wurden dem Prozessmanager übergeben, damit sie als Verbesserungen in den entsprechenden Prozessbereich einfliessen können. Sie wurden – wenn überhaupt – nur sehr schleppend bearbeitet. Der Double Loop «Tun wir die richtigen Dinge?» war nur schwach implementiert und zeigte eine sehr niedrige Wirkung.

Die ersten Lessons Learned in dieser Umgebung wurden im Jahr 2006 erstellt. Der Rollout der CMMI-Umgebung dauerte bis November 2010, als erfolgreich der Maturity Level 3 erreicht wurde. Der Betrieb der LLUmgebung fand hauptsächlich in einer Phase statt, als die Zielumgebung immer noch verändert wurde. Bei den Projektmanagern entstand der Eindruck, sie könnten nachhaltige Veränderungen bewirken und die Arbeitsumgebung verbessern. Da dies aber über die Jahre nicht sichtbar war, entstand eine gewisse Müdigkeit. Lessons Learned wurden nach wie vor erstellt, weil es so vorgeschrieben war.

Ansätze zur Verbesserung

Die Ansätze zur Verbesserung der Wirkung von Lessons Learned hielten sich im Rahmen. Man versuchte die Struktur der Lessons zu vereinfachen, die Infrastruktur entsprechend anzupassen und die Prozessmanager besser zu involvieren. Diese Massnahmen brachten aber nur kleine Fortschritte. Daraus wurden folgende Schlüsse gezogen:

• Der LL-Prozess braucht noch Ergänzungen bezüglich Umsetzung der Empfehlungen.
• Das Wirkungsfeld der Empfehlungen ist zu gross und so können diese nicht oder nur bedingt umgesetzt werden.
• Die Umsetzung von den Lessons Learned-Resultaten benötigt in dieser Umgebung mehr und hohe Entscheidungsbefugnis.

Daher wurde das Konzept abgewandelt, sodass alles nur in einer Abteilung stattfand. Die Wirkung war um einiges besser, da die Entscheidungen über Veränderungen und Aktionen sofort und lokal gefällt werden konnten.

Chancen und Perspektiven für künftige Implementierungen

Aus den Erfahrungen und den wissenschaftlichen Erkenntnissen vom Lernen können für zukünftige LL-Umgebungen einige Lessons abgeleitet werden. Lessons Learned können in verschiedenen Umgebungen, nicht nur in IT-Projekten, angewendet werden. Daher ist die Zielumgebung einer der wichtigsten Beeinflusser bei der Im plementierung. Die nachfolgende Aufzählung erhebt keinen Anspruch auf Vollständigkeit und ist absichtlich nicht gewertet und auch die Reihenfolge ist in keiner Weise zu berücksichtigen.

• Der Einfluss der bestehenden Kultur und Organisation einer Firma darf nicht unterschätzt werden. 
• Sobald Lessons Learned an eine andere Initiative gekoppelt sind, ist die Wahrscheinlichkeit gross, dass bei deren Ableben Lessons Learned auch sterben.
• Lernprozesse sind wiederkehrende Prozesse und sollten geschlossene Kreisläufe sein.
• Lernprozesse sollten in die täglichen Abläufe integriert werden. In einer prozessgetriebenen Umgebung ist der Ansatz durch prozessorientiertes Wissensmanagement sehr zu empfehlen, weil dadurch auch die angrenzenden Prozesse aus der Perspektive von Wissensmanagement betrachtet werden.
• Die Lernschleifen von Argyris und Schön sind ein gutes Modell um zu überprüfen, ob ein Lernvorgang stattfindet und wie tief er ist.
• Es ist immer schwieriger, eine Lessons-Learned-Umgebung in einer grossen Organisation zu verankern als in einem überschaubaren Bereich wie einer Abteilung oder einem Department.
• Die Quelle (Ersteller der Lesson) und die Senke (Umsetzer der Ergebnisse aus Lessons) von Lessons Learned sind die wichtigsten Standbeine einer Implementierung. Ist eines davon schwach, so kann die ganze Umgebung nicht richtig funktionieren, denn erst auf zwei Beinen steht man sicher.
• Für Lessons Learned ist mindestens Double-Loop Learning anzustreben, um optimalen Nutzen zu gewährleisten.