Lessons learned – aus Fehlern in Projekten lernen

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.

 

Lessons learned – aus Fehlern in Projekten lernen

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,…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 13
Kommentare 2

Alle Kommentare (2)

Beate
Friedrich

Vielen Dank für diesen tollen Artikel! Eine kurze, prägnante, praktische Anleitung für Lessons Learned während eines Projekts. So ein einfaches Instrument mit so viel Wirkung. In Deutschland müssen wir diese offene Fehkerkultur noch üben. Aber ich bin davon überzeugt, dass ein Team in einem gemeinschaftlichen Umgang mit seinen Zielen mehr Verbesserungspotenzial entwickelt als durch das Lernen von theoretischen, "weichen" Faktoren in PM-Seminaren. Ausprobieren! Es kostet nicht viel!

 

Bernhard
Willig

Sehr guter Beitrag, hat meinen letzten LL-WS sehr verbessert. Danke!