Leseprobe Lessons learned - Aus Fehlern in Projekten lernen
von Gisela Müller
Fehler passieren immer. Um aber nicht in jedem Projekt die gleichen Fehler zu wiederholen, muss der Prozess der rückschauenden Projektanalyse institutionalisiert und eingeübt werden. Gisela Müller zeigt in ihrem Artikel, wie man Fehler schon in laufenden Projekten analysieren kann und wie Lessons-learned-Meetings durchgeführt werden.
Leseprobe Lessons learned - Aus Fehlern in Projekten lernen
von Gisela Müller
Fehler passieren immer. Um aber nicht in jedem Projekt die gleichen Fehler zu wiederholen, muss der Prozess der rückschauenden Projektanalyse institutionalisiert und eingeübt werden. Gisela Müller zeigt in ihrem Artikel, wie man Fehler schon in laufenden Projekten analysieren kann und wie Lessons-learned-Meetings durchgeführt werden.
Es gibt viele Gründe, warum Projekte scheitern. Aber nur selten sind sich alle Beteiligten über diese Gründe einig. Jeder legt sich seine eigene Version der Fehler und Schuldigen zurecht, und passieren beim nächsten Projekt die gleichen Fehler wieder, gilt das nur als Bestätigung der eigenen Bewertung. Dabei sollte es doch vielmehr darum gehen, aus erkannten Fehlern zu lernen - damit beim nächsten Mal alles besser läuft. Um diesem Anspruch gerecht zu werden, muss der Prozess der rückschauenden Projektanalyse institutionalisiert und gemeinschaftlich eingeübt werden.
Projekte sind keine Militärmanöver
Projektmanagement, wie wir es heute kennen, wurde stark vom militärischen Denken beeinflusst. Insbesondere die US-Army galt und gilt als Vorbild für professionelles Management. Auch viele moderne Unternehmen sind nach dem hierarchisch-militärischem Vorbild gestaltet. Vokabeln wie "Strategie", "Ressourcen", "Führungsstab", "Deadline", "After Action Review" oder "Manöverkritik" gehören zu unserem Alltags-Wortschatz. Wie das US-amerikanische Militär arbeitet, ist aus Kinofilmen bekannt: Wir sehen eine hocheffiziente Maschinerie, die darauf getrimmt ist, definierte Ziele zu erreichen und dabei verlustfrei zu operieren. Denn jeder Fehler kann fatale Folgen haben.
Der Projekterfolg misst sich an den erreichten Zielen
Lernen kann man hieraus eine ganze Menge, was Planungssicherheit und Effizienz angeht. Die Ziele von nicht-militärischen Projekten sind allerdings nicht so eindimensional definiert wie das kriegerische Aufspüren und Zerstören. Im Wesentlichen misst sich "ziviler" Projekterfolg an vier Faktoren:
- Der nach Plan eingehaltenen Termine,
- das Einhalten der budgetierten Kosten,
- das Erreichen des Projektziels,
- der Zufriedenheit aller Projektangehöriger.
Am Zusammenspiel dieser vier Faktoren misst sich der Projekterfolg. Leider gelten schon viele Projekte als erfolgreich, wenn nur das Zeit- oder Kostenlimit nicht überschritten wurde. Diese Parameter lassen sich auch einfach überprüfen, weil sie zahlenmäßig erfassbar sind. Schwieriger wird es schon bei den inhaltlichen Anforderungen oder der subjektiven Einschätzung des Projektes durch die Mitarbeiter und Kunden.
Fehlerquellen in Projekten
Auch die Ursachen, die zu Verfehlungen in den genannten Bereichen führen, lassen sich grob gliedern, wobei ein Fehler sich auf verschiedene Bereiche gleichzeitig auswirken kann.
- Da wären zum einen die Sach- und Fachfehler: Mangelndes Know-How, Arbeit mit neuen, vorher nicht erprobten Technologien, inhaltliche Fehleinschätzungen aufgrund unvollständiger Informationen, aber auch Vertragsfehler in rechtlichen Belangen.
- Daneben treten Fehler im Management auf: Falsche Personalbesetzungen, Planungsfehler (zu wenig Personal, zu niedriges Budget), Fehler im Projektmanagement (siehe hierzu auch "Die häufigsten Probleme im IT-Projektmanagement", Ausgabe 02/01), unklar definierte Zuständigkeiten, mangelnde Überwachung und Qualitätskontrolle sowie firmenpolitische Entscheidungen, die sich negativ auf das Projekt auswirken.
- Eine weitere Fehlerquelle sind Kommunikationsdefizite: Der Kommunikationsfluss ist nicht ausreichend oder eindeutig geregelt, es findet zu wenig Kommunikation statt, manchmal passiert das auch aus ganz banalen Gründen wie verschlampten Briefen oder verlorenen Faxen, weil z.B. kein Papier im Faxgerät war.
- Zuletzt die so genannten "Weichen Faktoren": Teammitglieder, die partout nicht miteinander klar kommen (das kann bis zum Mobbing gehen), fehlender Teamgeist, mangelnde Motivation, ungenügende Führungsqualitäten der Projektleitung oder der vermeintlich "ungeliebte" Kunde.
Institutionalisierung einer offenen Lernkultur
Fehleranalyse ist Teamarbeit
Wenn ein Projekt scheitert, ist das meist auf das Zusammentreffen mehrerer der genannten Ursachen zurückzuführen. Das Problem der Fehleranalyse beginnt jedoch bereits damit, dass es unterschiedliche Auffassungen in der Bewertung der Fehlerquellen gibt. Jedes Mitglied des Projektteams wird eine andere Sicht der Dinge liefern. Der Chefprogrammierer beschwert sich, dass man ihm nicht genug Personal zur Seite gestellt hat. Diejenigen, die für das Konzept zuständig waren, haben das Feedback innerhalb des Teams vermisst, der Projektleiter sah sich zu wenig von der Geschäftsführung unterstützt.
Ziel der Fehleranalyse muss daher die übereinstimmende Einschätzung des zurückliegenden Projektgeschehens sein. Nur wenn sich alle darüber einig sind, was tatsächlich falsch gelaufen ist, können alle gemeinsam aus den gemachten Fehlern für zukünftige Projekte lernen. Entscheidend ist daher die Schaffung eines hierarchiefreien Raums, in dem offene Kritik möglich ist. Ohne dies werden alle Maßnahmen an der Oberfläche bleiben und nicht wirklich Besserung schaffen.
Reviews als Raum für gemeinsamen Dialog
Wie sieht ein solcher "offener Gesprächsraum" aus? Empfehlenswert ist die Etablierung eines wiederkehrenden "Lessons-learned-Meetings". Üblicherweise wird dies mit dem sogenannten "After Action Review" (dt. Manöverkritik) zum Abschluss eines Projekts erledigt. Besser wäre es jedoch, bereits während des Projekts Reviews abzuhalten. So können Fehler frühzeitig angesprochen und entsprechende Maßnahmen zur Behebung eingeleitet werden. Gemeinsame Reviews können beispielsweise an bestimmte Meilensteine gekoppelt sein oder regelmäßig einmal im Monat stattfinden. Die dafür notwendige Zeit muss für jedes Projekt mit einkalkuliert werden.
Den "offenen Gesprächsraum" kennzeichnet eine bestimmte Atmosphäre. Im Inneren dieses Gesprächsraums gelten andere Regeln wie am Arbeitsplatz. Hier sollte jeder Kritik oder ungemütliche Fragen äußern dürfen, ungeachtet seiner Position. Der "offene Gesprächsraum" ist ein sicherer Raum. Was hier jemand sagt, darf "draußen" nicht gegen ihn verwendet werden. Wichtig für jedes Review: Es geht nicht darum, Schuldige zu finden! Im Vordergrund sollte nicht primär die Frage stehen, was schief gelaufen ist, sondern was man hätte besser machen können: Lessons, we have learned.
Das Lessons-learned-Meeting
Kritik muss nicht immer negativ sein
Folgende einfache Fragen liefern das Grundgerüst jedes Lessons-learned-Meetings:
- Was sollte mit dem Projekt erreicht werden? (Die Frage nach dem Ziel.)
- Was haben wir erreicht? (Die Frage nach den Zielabweichungen.)
- Warum haben wir dies erreicht? (Was lief gut?)
- Warum haben wir es nicht erreicht? (Was lief schlecht?)
Entscheidend für die richtige Atmosphäre ist vor allem, dass nicht nur Negatives geäußert wird. Es gilt schließlich herauszufinden: Was kann man in Zukunft anders machen? Aber auch, was sollte man beibehalten? Außerdem kann man ruhig gelegentlich ein Lob auszusprechen. Damit wird signalisiert, dass man die Leistungen des anderen anerkennt. Man sorgt somit zusätzlich für eine vertrauensvolle Atmosphäre und schafft ein positives Gesprächsklima.
Die Durchführung eines Lessons-learned-Meetings
Ein Lessons-learned-Meeting sollte niemals ohne Vorbereitung stattfinden. In jedem Projekt wird eine Person für die Vorbereitung und Durchführung der Meetings bestimmt. Das muss nicht zwangsläufig die Projektleitung sein. Es ist sogar besser, ein anderes Teammitglied mit dieser Aufgabe zu betrauen. Denn in vielen Projekten wird gerade die Projektleitung als kritischer Faktor empfunden; Kritik übt sich aber leichter, wenn die kritisierte Person in gleichberechtigter und nicht in leitender Funktion auftritt.
Die Vorbereitung
Der Ablauf eines Lessons-learned-Meetings ergibt sich aus den oben genannten vier Fragen. Zu den Aufgaben der Besprechungsleitung gehört das Aufstellen und später die Einhaltung des Zeitplans. Einen solchen Zeitplan können Sie mit Hilfe des nächsten Punktes "Durchführung" aufstellen.
Das Lessons-learned-Meeting findet in einem eigenen Raum statt. Die räumliche Trennung von Arbeitsplatz und Besprechungszimmer trägt mit zum Gelingen bei! Der vorgesehene Raum sollte mit Pinnwand und Flip-Chart(s) ausgestattet sein, da bei der Durchführung Kreativitätstechniken zum Einsatz kommen, wie man sie auch aus Brainstormings kennt.
Die Durchführung
Stichwort Brainstorming: Ein Lessons-learned-Meeting sollte als solches verstanden werden. Im Verlauf des Meetings werden die einzelnen Krisenpunkte zusammengetragen, deren mögliche Ursachen gemeinsam ergründet und anschließend bewertet. Die Vorgehensweise ist wie folgt:
- Jedes Teammitglied schreibt seine Kritikpunkte (positive wie negative) auf Pappkarten. Für jeden Punkt ist dabei eine eigene Karte zu verwenden. Dauer: ca. 10-15 min.
- Nacheinander erläutert jedes Teammitglied kurz seine aufgeschriebenen Punkte. Die einzelnen Karten werden an die dafür vorgesehene Wand gepinnt: Auf die linke Seite alles Positive, rechts die negativen Punkte und in einer Mittelspalte zunächst unbewertete Beobachtungen und Bemerkungen. Dauer: 15-30 min.
- Nun werden alle Karten gemeinschaftlich sortiert und in Themenblöcken gruppiert. Orientierung liefern dabei die am Anfang dieses Artikels genannten Fehlerquellen. So könnte beispielsweise ein Themenblock "Management" heißen, oder ein anderer "Kommunikation". Unter Umständen muss jedoch noch in einem zweiten Durchgang spezifischer untergliedert werden. Hierbei stellt sich oft heraus, dass unterschiedlich benannte Kritikpunkte eigentlich nur auf einen einzigen Sachverhalt abzielen. Dieser Sachverhalt sollte dann eindeutig formuliert auf eine neue Karte geschrieben und aufgehängt werden. Dauer: 30-60 min.
- Bewertung der positiven Kritik: Dies dürfte nicht allzu schwer fallen. Entscheidend ist nur, dass die Punkte explizit genannt werden und man sich darin einig ist, bestimmte Vorgehensweisen für die Zukunft beizubehalten. Dauer: ca. 10-15 min.
- Einer der diffizileren Vorgänge im Lessons-learned-Meeting ist die Priorisierung der negativen Kritikpunkte. Zur Priorisierung empfiehlt es sich, die Karten in eine Reihe von oben nach unten umzuhängen.
Je nach Position und Aufgabe der einzelnen Teammitglieder werden die Einschätzung darüber auseinanderfallen, welche Fehler nun am kritischsten für das Projekt zu bewerten sind. Bei diesem Vorgang müssen daher die übergeordneten Projektziele eine Orientierung bieten (Zeit, Kosten, Leistung, Motivation / Zufriedenheit). Übergeordnet deshalb, weil diese Ziele die Ausrichtung eines Unternehmens repräsentieren. In einem Unternehmen, das sich der langfristigen Innovationsforschung verschrieben hat, werden Fach- und Sachfragen mit höherer Priorität behandelt als in einem StartUp, wo es vor allem um die schnelle Profilierung auf dem Markt geht. Dauer: 15-30 min. - Einer der wichtigsten, aber gerne vernachlässigten Vorgänge ist, die sortierten, priorisierten Punkte mit konkreten Maßnahmen zu verbinden. Neben jede Karte der Prioritätenliste werden eine oder mehrere neue Karten mit konkreten Aufgaben gehängt. Beispiel: Im Projekt kam es zu Missstimmungen mit dem Kunden, der sich unzureichend informiert fühlte. Als Maßnahme könnte man beschließen, dem Kunden in Zukunft einen wöchentlichen Statusreport zukommen zu lassen.
Jede Maßnahmen-Karte sollte auch einen (Start-)Termin und den Namen eines Verantwortlichen beinhalten. Dauer: 30-60 min.
Und um es zu wiederholen: All diese Dinge (Themen, Prioritäten, Maßnahmen) werden gemeinsam erarbeitet!
Die Ergebnisse
Die Gesprächsleitung fasst die Ergebnisse des Meetings in einem Stichwortprotokoll zusammen und verteilt es an alle Projektmitglieder, eventuell auch an die Geschäftsleitung. Wichtiger Inhalt des Protokolls ist die Liste der konkreten Aufgaben, Termine und Zuständigkeiten. Das Protokoll stellt eine Art "Checkliste" für das nächste Lessons-learned-Meeting dar. In den Folgemeetings werden zu Beginn die vorher erarbeiteten Punkte angesprochen und die Ausführung der vereinbarten Maßnahmen überprüft.
Fazit
Ein erfolgreiches Projekt ist immer auch ein Lernerfolg. Doch selbst wenn Projekte scheitern, sollten die gemachten Fehler mehr Anlass zur kritischen Hinterfragung als zur Suche nach Sündenböcken sein. Das Lessons-learned-Meeting bietet hierfür gute Gelegenheit. Ziel jedes solchen Meetings ist die gemeinsame Erarbeitung zukunftsorientierter Handlungsanleitungen und die Schaffung von Vorlagen und Ablaufmustern für Folgeprojekte. Diese Vorlagen und Muster müssen aber immer wieder Gegenstand der Kritik bleiben und auch bei jedem Folgeeinsatz auf ihre Tauglichkeit überprüft werden.