Lessons Learned – gern gefordert, kaum gelebt - wie Projektmanager viel Potenzial verschenken

Wahnsinn ist, immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten. (Albert Einstein)

Albert Einstein 1947 - This image is available from the United States Library of Congress's Prints and Photographs division under the digital ID cph.3b46036

Albert Einstein (1947)

Noch wahnsinniger ist es, verschiedene Dinge zu tun und immer das gleiche zu erwarten. Aber genau das passiert landauf landab in Projekten.

Es gibt in Unternehmen extrem oft die gleichen Projektziele und trotzdem werden die Projekte immer wieder anders durchgeführt. Sei es der Bau eines Hauses oder einer Sondermaschine. Sei es die Entwicklung einer Großküche oder ein Beratungsprojekt. Nachvollziehbar ist das dann, wenn es sich um einmalige oder seltene Projekte handelt, die eben für die vorhandene Mannschaft nicht alltäglich sind. Da fehlen möglicherweise die Erfahrung und der Projektansatz. Aber selbst unter vermeintlich gleichen Bedingungen – Projektleiter, Team, Partner, Kunde, Auftrag, Ressourcen, Budget etc. – wird i. d. R. kaum der gleiche Projektprozess abgearbeitet bzw. das gleiche Ergebnis erreicht.

Eine (von mehreren!) Ursache(n) ist die fehlende Selbstreflektion, der Blick in den Rückspiegel, die Lessons Learned. Die Analyse im Projekt findet nämlich zumeist, wenn überhaupt, erst nach dem Projekt statt. Nach dem Projekt sind aber viele nur noch froh, das Ende des Projektes erreicht zu haben. Wer ist denn dann noch bereit und fähig, ein Projekt zu analysieren? Noch dazu, wenn das Projekt eine längere Laufzeit hatte und vieles längst “irgendwie” operativ geklärt wurde. Eine Analyse der Ereignisse und Entscheidungen zu diesem Zeitpunkt verfehlt also ihr Ziel schon deshalb, weil die Motivation zur Auseinandersetzung mit dem Projekt zumeist nicht mehr vorhanden ist. Zumal dann der Projektleiter die Abschlussanalyse machen soll. Genauso gut könnte auch der Arzt seinen eigenen Behandlungsfehler beurteilen.

Ein gutes Lessons Learned muss von Anfang an stattfinden. Es muss sowohl die positiven(!) als auch die negativen Ergebnisse auswerten und die Ursachen/Maßnahmen in einen Standardprozess für Projekte einfließen lassen. (Das impliziert allerdings, dass ein solcher Standardprozess vorhanden ist.)
Die positiven Aspekte sind wichtig, um den Prozess zu bestätigen und zu festigen. Die negativen Erfahrungen sind erforderlich, um die Kausalitäten zwischen Ursache und falschen Ergebnissen zu erkennen, um daraus sinnvolle Maßnahmen bzw. Handlungsvorgaben für die Zukunft abzuleiten. Maßnahmen, die dazu dienen, erlebte negative Ergebnisse nicht zu wiederholen.

Da die direkten Projektbeteiligten in der Eigenanalyse naturgemäß weitestgehend befangen sind, sollte die permanente Projektanalyse von fachlich versierten Personen durchgeführt werden, die nicht im Projekt involviert sind. Allen Beteiligten muss aber unbedingt klar sein, dass es dabei nicht um die Frage “WER hat was getan?” sondern nur um “WAS ist passiert und WARUM?” geht. Sobald die “WER“-Frage gestellt wird, wird sich die Bereitschaft zur Auskunft bei den handelnden Mitarbeitern deutlich verschlechtern. Denn dann ist die Zielrichtung der Analyse die Schuldfrage und nicht mehr die “Wie-können-wir-besser-werden?”-Frage.

Damit ist die Methode Lessons Learned auch unmittelbar mit der Firmenkultur verbunden. Dort, wo im Unternehmen die Schuldfrage an erster Stelle steht, wird es kaum möglich sein, dies aus dem Projekt herauszuhalten. Wenn aber die Lessons Learned aufgrund der suboptimalen Fragestellung nicht vernünftig durchgeführt werden können, werden sich leider die Projekte kaum verbessern. Wer also seine Projekte verbessern möchte muss zunächst überprüfen, dass die Firmenkultur dies auch zulässt.

Genauso wichtig wie die Erkenntnisse aus den Projekten ist aber dann auch das Einbringen dieser Erkenntnisse in die laufenden und zukünftigen Projekte. Das wiederum setzt eine permanente Optimierung des Projektprozesses und die Schulung der vorhandenen Projektleiter voraus. Diese müssen, um Fehlerwiederholungen zu vermeiden bzw. zu verringern, intensiv geschult und trainiert werden. Am sinnvollsten ist es allerdings, wenn alle Projektbeteiligten einen guten Schulungsstand haben. Dann haben die Lessons Learned ihr Ziel erfüllt und der Wahnsinn hat ein Ende.


Ähnliche Beiträge im GPM BLOG:

Schlagwörter: , , ,

Kommentare

  1. Sabine Rossbach

    Spannendes Thema.

    Gerade dieser lessons learned Effekt ist z.B. in Scrum Projekten systemimanent. Nach jedem Sprint wird im Rahmen der Retrospektive im Scrumteam und im Projekt gelernt. Immer öfter begegnet mir inzwischen die Retrospektive auch als adäquates Mittel für das Lernen von Teams und Abteilungen in Firmen. Eine gute Basis, um dem oben beschriebenen Wahnsinn ein Ende zu machen… wenn das Instrument richtig genutzt wird. Da gibt es auf jeden Fall noch viel zu tun.

  2. Benjamin Gauß

    Das kann ich so bestätigen. Sowohl die Beobachtungen des Blogs, als auch die von Frau Rossbach. Ich leite derzeit ein freies Projekt eines gemeinnützigen Vereins in der Jugendarbeit und führe systematisch immer öfters Lessons Learned ein um sowohl eine Retrospektive sowie Lernprozess evaluieren zu können als auch das Team voran zu bringen und sie regelmäßig aus begangenen Fehlern lernen lassen ohne jedoch eine Schuldfrage zu klären. Ich bin mittlerweile dadurch soweit, dass Fehler nicht mehr in tage- oder gar wochenlangen Schuldfragen eskalieren, sondern als Lernmittel akzeptiert werden. Dafür ist die Akzeptanz wichtig, Fehler offen zu legen und über sie Reden zu dürfen.

  3. Ja, Herr Hänßgen,

    aber da gibt es ein schwerwiegendes Problem: Die größten Probleme in meinen Projekten hatten ihre Ursachen fast immer in höheren Leitungsebenen.

    Wenn Ihnen der Prototyp beim Elchtest umfällt und alle wissen, warum der Mangel nicht schon vorher “kommuniziert” wurde, dann brauchen Sie dazu kein “Lessons learned” mehr – und machen sich nmit einem solchen lächerlich.
    Privat, klar. Auch unter vier Augen. Auch in Bezug auf die eine oder andere Einzelheit. Aber nichts, was irgendjemanden befürchten können ließe, irgendwem könnte an seiner Maske der Perfektion gekratzt werden.

    Außerdem – wann immer Gelegenheit gewesen wäre, das Projektteam dazu noch mal zusammen zu rufen, war es längst wieder involviert im nächsten oder gar übernächsten Projekt – und ich hätte Absagen bekommen mit mindestens dem Vorwand “Terminnot”.

    Natürlich haben Sie grundsätzlich Recht, aber das, was ist, das ist nicht ohne Grund so.

    Ciao
    Wolfgang Horn

  4. [...] Blog der GPM-IPMA-Seite findet sich ein Beitrag zum Thema Lessons Learned (–> Link http://gpm-blog.de/lessons-learned/ ). Interessant sind darin zwei [...]

Leave a Reply

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert. *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>