Schlagwort-Archive: Lessons Learned

Erfahrungen aus Projekten und daraus abgeleitete Forderungen

Erfahrung 1: Je mehr ein Projekt „ab Fliessband“ gemacht wird, desto weniger Aufmerksamkeit kommt ihm zu. Gemeint sind z.B. lange Projekte, im Verlauf derer die Mitarbeiter anfangen, alles routinemässig zu erledigen, oder Projekte, die zum Tages- und Kerngeschäft eines Unternehmens gehören.
Konsequenz: Die Erstmaligkeit eines Projekts herausstreichen. Projekte kurz halten, in Teilprojekte aufsplitten. Wechselnde Projektleiter, Berater, Mitarbeiter.

Erfahrung 2: Verminderte Aufmerksamkeit äussert sich dann z.B. dadurch, dass Anfragen und Anforderungen („Requests“) überhört und ignoriert werden.
Beispiele:

  • In einer Krisensituation bat ich einen Projektmitarbeiter, mir die verabredeten Zeiten der Konferenzgespräche zu mailen. Ich erhielt sie nie.
  • Der Kunde bat immer wieder, dass ein Vertreter des Projektmanagements, das aus Globalisierungsgründen weit ab vom Geschehen war, vor Ort sein soll. Der Lieferant hat sich nicht einmal die Mühe gemacht, die Forderung zu diskutieren.
  • Der Kunde bat, das System durch einen Sicherheitsspezialisten überprüfen zu lassen. Auch das hat der Lieferant nicht einmal zur Kenntnis genommen. Als das System gehackt wurde, war es leider zu spät.

Vieles wird natürlich „überhört“, weil es unangenehm ist und Kosten verursachen würde. Bei der Vertragsverhandlung war dem Kunden noch nicht klar, wie wackelig ihm das System erscheinen wird, so dass er das Bedürfnis nach einem Sicherheitscheck haben könnte. Der Lieferant will sich die diesbezüglichen Kosten sparen.

Konsequenz: Mehr Sorgfalt während den Vertragsverhandlungen! Haftung und Verantwortung explizit ansprechen. Projektführerschaft klären. Ist der Lieferant Projektführer, muss der Kunde den Projektprozessen des Lieferanten folgen. Andernfalls muss der Lieferant „Regiearbeiten“ („Time & Material“) abrechnen können.

Erfahrung 3: Man macht sich zu lange vor, alles im Griff zu haben. In oben erwähnten Fall, wo ein System gehackt wurde, noch bevor das entsprechende Integrationsprojekt abgeschlossen war, nahm das Management des Lieferanten erst nach dieser Krise an den Konferenzgesprächen teil.
Dass sich das Management kaum um Projekte kümmert hat seinen Grund auch darin, dass Eskalationen, die vom Projektleiter ausgehen, vom Management nur punktuell aufgenommen werden, während sie sich im Projekt hochschrauben. In einer Serie von Eskalationen ist jede eine Folge der Vorgängereskalation. Die Dringlichkeit und Schwere der Projektsituationen nehmen zu. Beim Management kommen aber alle Eskalationen gleich dringlich an, weil sich das Management zwischen zwei Eskalationen mit anderen wichtigen Geschäften befasst. So denkt sich das Management wohl bei jeder Eskalation (ausser der ersten):

Ach, jetzt eskaliert dieser weinerliche Typ von Projektleiter schon wieder. Kann der denn nicht endlich Ruhe geben?

Konsequenz: Der Projektmanager muss sich immer auch um das Projektumfeld kümmern. Das Projektumfeld ist alles im Unternehmen, das nicht zum Projekt gehört. Wenn das Umfeld nicht zum Projekt passt, funktioniert das Projekt nicht. Ein guter Projektmanager versucht daher, das ganze Unternehmen zu führen und nicht nur das Projekt. Das muss er sich bei der Übernahme des Projekts vor Augen halten. Gibt es mehrere Projektmanager im Unternehmen, kann es zu Kollisionen kommen. Der CEO muss Schiedsrichterfunktion übernehmen und wird so in die Projekte eingebunden.

Erfahrung 4: Oft sind die Prozesse beim Kunden und beim Lieferanten nicht aufeinander abgestimmt, was zu Verzögerungen im Projekt führen kann. Beispielsweise verlangte der Lieferant, dass Produktefehler via Hotline kommuniziert werden. Von dort gehen sie direkt zu der Entwicklung. Beim Kunden kann aber nur das Backoffice die Hotline des Lieferanten erreichen, nicht aber das Engineering, das für die Projekte zuständig ist. Resultat: Der Projektleiter des Kunden kommuniziert zum Projektleiter des Lieferanten. Dieser hat nur einen informellen Draht zu der Entwicklung, so dass die Fehlerberichte des Kunden möglicherweise versanden.
Konsequenz: Im Projektkickoff müssen die Prozesse über das Projekt hinaus diskutiert werden. Sie gehören zum Projektkontext. In Projekten mit mehreren Lieferanten und Unterlieferanten wird es immer Schnittstellenprobleme zwischen den vielen Unternehmen geben. Ein Projekt ist eine Supply Chain, nur gibt es noch keine Softwarelösungen dafür. Bis es soweit ist, müssen Multiparteienprojekte unbedingt Personen beschäftigen, die Koordinationsfunktionen haben und von allen Parteien gleichmässig bezahlt werden.

Das sind zum Teil schmerzhafte Forderungen, die ich da stelle, daher werden sie wohl auch überhört und ignoriert. Sie könnten ja noch Kosten verursachen! Solange diese Forderungen jedoch nicht umgesetzt werden, werden Projekte weiterhin schlechte Resultate liefern und Milliarden Zusatzkosten verursachen.

Lessons Learned ist tot, es leben die Learning Stories

Wie kommt es, dass Sie beim Kaffeeautomaten dem Kollegen mühelos zuhören und ihn verstehen, wenn er von seinen Projekterlebnissen erzählt, dass Sie sich aber mühsam durch die nüchterne Sprache eines Protokolls und durch abstrakte Grafiken quälen, die von genau demselben Projekt handeln? Es kommt daher, dass der Kollege Ihnen eine Geschichte erzählt, in der er der Protagonist und manchmal auch der Held ist. Wenn seine Geschichte wirklich aus dem Projektleben gegriffen und authentisch ist, dann leben Sie mit und sind gierig darauf zu vernehmen, wie die Geschichte ausging. Der Vorteil von Geschichten liegt auf der Hand, wenn es darum geht, komplexe Botschaften zu vermitteln und nachhaltige Veränderungen anzustoßen. Geschichten füllen Fakten mit Leben und beantworten die Frage nach den Gründen. Geschichten helfen uns somit, Komplexität zu verstehen, weil sie unmittelbar anschaulich sind und eine eigene Ästhetik haben. Dadurch rufen sie in uns konkrete Vorstellungen hervor und sprechen nicht nur den Verstand an, sondern auch das Gefühl.
Gestern besuchte ich in München eine Einführung in Storytelling1. Sigrid Hauser von Consulting4quality ist nicht eine Märchentante, sondern weiss, wovon sie spricht. Sie hat viel Erfahrung mit IT-Projekten und kennt sogar den Zusammenhang zwischen dem kartesischen Produkt zweier Mengen und relationalen Datenbanken, was mich als Mathematiker natürlich besonders freute. Sigrid Hauer zeigte auf, welche Kraft in Geschichten stecken und wie sie als Mittel zur Weitergabe von erfahrenem Wissen genutzt werden können. Natürlich sind die Projektgeschichten des Projektleiters und diejenige des Engineers subjektiv gefärbt. Der Projektleiter des Kunden wird auch kaum dieselbe Geschichte erzählen, wie der Projektleiter des Lieferanten. Aber gerade das macht die Methode wertvoll und griffig. Die verschiedenen Perspektiven werden integriert und ergeben damit eine ganzheitliche aber dennoch lebensnahe Sicht der Ereignisse.
Auf der Arbeit von George Roth zum Thema „Learning Histories“2 basierend, habe ich für die Aufarbeitung von Projekterfahrungen folgende sechs Schritte entworfen:

  • In Interviews lässt man alle Beteiligte des Projekts ihre ureigenste Geschichte erzählen, um so die verschiedenen Perspektiven zu erfassen.
  • Die Interviewer dokumentieren die Geschichten und stellen verschiedene Perspektiven derselben Situation zusammen.
  • Das Dokument wird unter den Teilnehmern verbreitet.
  • In einem Workshop sucht man gemeinsam nach den archetypischen Handlungsmustern, den vorgeherrschten sozialen Dilemmata und den kognitiven Denkfallen und fragt sich, wann und bei welcher Gelegenheit Schwierigkeiten zum ersten Mal ihre Schatten voraus warfen.
  • Die Teilnehmer verarbeiten die Erkenntnisse aus dem Workshop in Metaphern, Gleichnisse oder Fabeln
  • An einem Verbreitungsworkshop erzählen die Projektmitarbeiter die neuen Geschichten, die nun die verschiedenen Perspektiven und die daraus gelernten Lektionen in unterhaltender und deshalb einprägsamer Weise integrieren

Die Vorträge können im Intranet in einer unternehmensinternen Clip-Datenbank zugänglich gemacht werden, ähnlich Youtube. Mit der Zeit werden im Unternehmen eine Menge geflügelte Worte und Geschichten kursieren, die das Wissen und die Projekterfahrungen nicht nur konservieren, sondern immer wieder weitertragen und verbreiten.
1http://www.consulting4quality.de/seminare.htm
2Art Kleiner & George Roth. Field manual for a learning historian. MIT-COL and Reflection Learning Associates, Boston 1996.