Schlagwort-Archive: Projektmanagement

Der Pfad der Ungewissheit in Projekten

Sibylle Peters schrieb in Management von Ungewissheit1 einen Aufsatz zum Thema Projektorganisation und Projektmanagement unter den Bedingungen zunehmender Komplexität2

Auf Seite 154 veröffentlicht sie die Iterations-Wolken-Metapher-Grafik von Oesterreich/Weiss. Sie visualisiert die iterative Zielklärung und -annäherung. Ganz besonders gefreut hat mich, dass auch für Oesterreich/Weiss das Projektziel erst bei Projektschluss bekannt ist. Während der Projektabwicklung findet ein ständiger Projektdrift statt.

Die Grafik hat mir derart gefallen, dass ich sie übernommen und weiter entwickelt habe. Nach herkömmlicher Projektmanagementtheorie gibt es am Ende einer Projektphase immer einen Review der bisher erreichten Teilergebnisse, eine Justierung der Planung und einen Forecast der nächsten Phase. Solche Meilenstein genannten Reflektionspunkte können indess auch an beliebiger Stelle in der Projektabwicklung vorkommen, wenn immer die Verantwortlichen das Gefühl haben, das Projekt sei vom „richtigen“ Weg abgekommen.

Diese Reflektionspunkte sind in meiner Erfahrung keineswegs äquidistante Iterationszeitpunkte, wie sie das agile PM vorsieht. Neben den, in klassisch geplanten Projekten, vorgesehenen Meilensteine, gibt es weitere Momente der Besinnung, der Neuplanung und Korrektur. In jedem dieser Reflektionspunkte wird das Projektziel mehr oder weniger explizit neu definiert. Dadurch findet ein Zieledrift statt.

Der jeweilige Entscheidungsspielraum über die Marschrichtung ist nicht beliebig. Er engt sich sogar immer mehr ein, je weiter das Projekt fortgeschritten ist. Gewisse Entscheide hängen von früheren Entscheiden oder von Umweltbedingungen ab, die durch den bisherigen Projektverlauf geschaffen wurden. Das nennt sich Pfadabhängigkeit.

Geschieht etwas Unvorhergesehenes oder Unerwartetes, kann das mit einem Pfadbruch oder einer Unstetigkeit im Projektverlauf dargestellt werden. Das Projekt kann so wie bisher nicht fortgesetzt und muss neu aufgesetzt werden. Nach einem solch einschneidenden Ereignis ist sicher rasch ein Reflektionspunkt notwendig. Das Projekt muss neu geplant und berechnet werden. Die bisher erreichten Ergebnisse sind vielleicht nicht mehr viel wert. Dafür ist der Entscheidungsspielraum nach einem Pfadbruch wieder grösser, weil die historische Abhängigkeit fehlt.

Es kann aber auch passieren, dass niemand mehr weiss, was zu tun ist und alle orientierungslos vor sich hin wursteln. Das ist dann der Fall, wenn das Projekt den Planungshorizont des letzten Reflektionspunktes überschritten hat. Dann wird der Projektpfad holperig und faltig. Das Setzen eines Reflektionspunktes wird dringend notwendig. Jemand muss die Initiative ergreifen und das Projektteam zusammen rufen, um die nächsten Schritte zu definieren.

Das Modell ist effektiv brauchbar. Bisher wusste ich nicht so recht, was ich von Planung halten soll. Wozu planen, wenn es ja doch immer anders heraus kommt? In der Grafik wird aber klar, wie wichtig Planung für die nächste Periode wird. Eine Periode ist der Zeitraum zwischen zwei Reflektionspunkten. Agiles PM spricht von Iterationszyklen. Iteration bedeutet aber, stets dieselben Scheibchen von der Wurst abzuschneiden. Eine Iteration läuft stets nach demselben Programm ab, sogar dann, wenn das Programm obsolet geworden ist. Ich spreche deshalb lieber von Rekursion. Rekursion definiert die nächste Periode aufgrund des aktuellen Zustands. Rekursionszyklen sind nicht immer gleich lang, sondern passen sich an den momentanen Projektzustand an3.

1Böhle, Fritz & Busch, Sigrid (Hg): Management von Ungewissheit – Neue Ansätze jenseits von Kontrolle und Macht. transcript Verlag, Bielefeld 2012

2ebenda, S. 137-175

3 Siehe Frage 10 der Frequently asked questions über systemisches Projektmanagement

Was wäre, wenn wir Projekte ereignisgesteuert abwickeln würden?

Im letzten Beitrag habe ich eine Fallstudie eines gewöhnlichen Migrationsprojekts vorgestellt, das wegen ein paar kleinen IT-Fehlern einen Schaden von 160 Mio US-Dollar verursachte. Es ist unmöglich, alle IT-Fehler auszumerzen, weil auch bei unendlichem Aufwand immer eine Ungewissheit bleibt, was sich alles ereignen kann, auf das die Software reagieren sollte. Daher ist Risikomanagement eine Aufgabe des Business‘ und nicht der IT. Dennoch wird die Verantwortung nach wie vor auf die subsidiären Unternehmensteile abgewälzt. Was tut die IT, um diese Verantwortung wahrzunehmen? Sie zertifiziert ihre Projektmanager in klassischen Projektmanagementmethoden, die aber offensichtlich wenig taugen, wie die Fallstudie zeigt (und wie ich selber vielfach erfahren habe).

Das klassische Projektmanagement stellt das sogenannte „Goldene Dreieck“ – Budget, Termin, Qualität – in den Vordergrund. Ein Projekt muss demnach zu den vereinbarten Kosten rechtzeitig fertig werden und dabei die erwartete Qualität erreichen. Klar, wenn Ihnen der Maler einen Kostenvoranschlag zum Streichen Ihrer Küche gemacht und versprochen hat, dass Sie die Küche innert Wochenfrist wieder benutzen können, dann wären Sie bass erstaunt, wenn er die Küche während zweier Wochen belegt und dann erst noch das Doppelte des vereinbarten Preises verlangen würde. Was aber, wenn nach einer Woche alle Farbe, die der Maler verstrichen hat, plötzlich von den Wänden fällt, gerade wenn er Ihnen die frisch gestrichenen Küche übergeben will?

Termin- und budgetgetriebenes Projektmanagement ist vielleicht nicht das Richtige. Auch Scrum hilft da nicht wirklich weiter. Vielmehr sollte Projektmanagement ereignisgesteuert sein. Das ist aber nicht so einfach, wie das klassische Projektmanagement rund um das Goldene Dreieck. Die im letzten Beitrag beschriebene Fallstudie fasst das so zusammen:

Worse, a cost-and-schedule approach never holds up during a crisis… When HP saw that the order management system wasn’t working properly, it pulled out all the stops to get the code working properly—cost and schedule be damned. … when using this event-driven approach, „the project doesn’t move forward until you’ve gotten each step right.“ Yet event-driven project management has its own pitfalls. It’s not infallible, and if not carefully managed, projects can drag on forever1

Aber vielleicht hat ereignisgesteuertes Projektmanagement Potenzial. Vielleicht ist es der einzige Weg, um endlich komplexe Projekte vernünftig abwickeln zu können. Vielleicht sollten wir beginnen, unsere Projektmanager in ereignisgesteuertem anstatt in termin- und kostengesteuertem Projektmanagement auszubilden!

1CIO. When bad things happen to good projects. 2007

Herkömmliche Projektmanagementmehtodik ist noch nicht alles

Die miserablen Erfolgsquoten von IT-Projekten werden überall mit Erstaunen beobachtet. Martin Cobb hat an der von der Standish Group organisierten Chaos University 1995 das nach ihm benannte Paradoxon geprägt: We know why projects fail, we know how to prevent their failure – so why do they still fail?. Markus Körner vom Institut für Betriebswirtschaft der Universität St. Gallen sagte 2005: Project work is expanding – at a consistently high rate of failure. Peter Morris hielt in seiner Präsentation am IPMA World Congress 2003 in Moskau fest: Our understanding of the central core of generic project management has not changed very much (though it has a little) in the last 20 years or so1. Da muss ich ihm mehr als recht geben. Ich würde sogar sagen, dass der „central core of generic project management“ in den letzten hundert tausend Jahren nicht geändert hat. Ein Jagdprojekt war etwas diffiziles. Der Chef – sprich Projektleiter – musste wissen, wann welches Wild verfügbar ist und seine Männer sorgfältig nach ihren Skills auslesen. Er musste wissen, welche Waffen benötigt werden. Er musste wissen, in welcher Richtung man ziehen will, um innerhalb der gewünschten Zeit die benötigte Menge an Fleisch zu erjagen. Er musste etwas von Taktik verstehen. Etc., etc.

Wirklich im Kern gehen wir bei Projekten generisch immer noch gleich vor. Skeptischer bin ich bei Cobb. Wenn das stimmt, was er sagt, wäre es in der Tat ein Paradoxon. Aber die Misserfolgsfaktoren, die die Standish Group regelmässig aufzählt, sind meines Erachtens nicht die richtigen. Sie wurden von IT-Managern in einer Umfrage genannt. Möglicherweise gehen die Projekte ja schief, weil die IT-Manager auf die falschen Faktoren schauen.

Als „Project Challenged Factors“ nennen sie:
1. Lack of User Input
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%

Als „Project Impaired Factors“ werden genannt:
1. Incomplete Requirements 13.1%
2. Lack of User Involvement 12.4%
3. Lack of Resources 10.6%

Ich werde auf diese Faktoren später zurück kommen. Hier nur soviel: Ich glaube nicht, dass das wirklich die ultimativen Misserfolgsfaktoren sind. Wenn Cobb diese meint, dann kann ich seiner Aussage nicht beipflichten. Allen ist klar, dass die heutigen Projektmanagementkonzepte noch nicht genügen. Alle suchen entweder nach Zusätzen oder nach einem neuen Konzept. Jeder, der meint, ein neues Konzept gefunden zu haben, zitiert gerne die eingangs erwähnten Beobachtungen von Cobb, Körner und Morris. Paul Glen, ein amerikanischer IT Consultant und Computerworld Kolumnist meinte: IT project management is part science and part art. But we, as engineers, have the bias that we can engineer solutions to fundamental human problems. Look for flexible minds, and beware of people who beliefe they know the answer2. Projektmanagement ist weder Wissenschaft noch Kunst. Projektmanagement besteht aus Skills, Regeln und Erfahrungen sowie – vor allem – aus Wissen. Skills und Regeln bekommt man bei den diversen Zertifikaten des PMI und IPMA mit. Was weitgehend noch fehlt, ist Wissen. Wissen um Komplexität und systemische Zusammenhänge. Doch davon im nächsten Beitrag. Wenn Glen mit „beware of people who beliefe they know the answer“ Leute meint, die neue Konzepte vorstellen, dann bin ich ganz auf seiner Linie. Ich habe auch keine ultimativen Lösungskonzepte sondern glaube, dass erst eine grundlegende systemische Bildung eine Verbesserung bringt. Wollen Sie die Lebensverhältnisse von Slumsbewohner verbessern? Dann schicken Sie sie in die Schule! Es existiert ein nachweislicher Zusammenhang zwischen Lebensqualität und Schulbildung. Genau so existiert meines Erachtens ein Zusammenhang zwischen Projekterfolg und systemischer Bildung der Projektmanager. Ganz Grundsätzlich bin ich der Meinung, dass es zur Führung unserer Institutionen – Projekte, Unternehmen, politische Institutionen, etc. – allmählich Zeit wird, dass unsere Bildungsinstitute zu einem völlig neuen Curriculum übergehen müssen. Uns fehlen eine ganz beträchtliche Menge Wissen, um die erhöhte Komplexität zu meistern.

1Stephen Rietiker. Projektbewusstes Management. spm Frühjahrstagung. Zürich 2007. Ich glaube, Rietiker schlägt in der Präsentation genau den richtigen Weg ein. Nur habe ich den Eindruck, dass er nicht richtig aufbricht. Bei jeder Folie denke ich: „Wann kommt er denn jetzt zum Punkt?“ Und dann ist die Präsentation plötzlich fertig.
2Gary Anthes. Projects Get More Troublesome. Computerworld, December 31, 2007.

Komplexität im Projektmanagement

Projekte werden umso komplexer je abstrakter der Projektgegenstand wird. Vor allem IT Projekte haben oft eine sehr abstrakte Zielsetzung, die zu Beginn des Projekts niemals detailliert genug festgeschrieben werden kann. Erst im Verlauf der Projektarbeiten lernt man zu verstehen, was da eigentlich entsteht. Im Prinzip funktioniert ein Projekt so, dass man die Tasks abarbeitet, die man erkennt. Ist die Arbeit getan, kann man die Tasks von der Liste, der noch zu erledigenden Tasks, streichen. Während man aber arbeitet, gewinnt man neue Erkenntnisse. Das Wissen über den Projektgegenstand nimmt zu. Mit jeder Erkenntnis sieht man aber wieder neue Tasks, die man auf die Liste schreibt. Nun haben wir also zwei Feedbacks: Je mehr Tasks, desto mehr Arbeit, desto mehr Tasks kann man schliessen (also desto weniger offene Tasks sind vorhanden – daher das „-“ beim Pfeil in Loop A, der von der Work in Progress nach Tasks to do zeigt). Und Je mehr Arbeit, desto mehr Erkenntnisse, desto mehr Tasks (Loop B).

Das Wissen nimmt im Verlauf des Projekts zu, erreicht ein Maximum und nimmt dann wieder ab. Das hat verschiedene Gründe. Erstens interessieren viele Dinge bald einfach nicht mehr, weil man sie so gut verstanden hat, dass sie selbstverständlich werden. Weiter vergisst man schlichtweg auch zahlreiche Einsichten, die man hatte, so wie man Namen vergisst. Diesem Verhalten des Wissens folgt das Verhalten der Anzahl Tasks, die noch zu erledigen sind. Auch sie nehmen – Gott sei Dank – mal ab. Allerdings oszilliert diese Task- und Issuelist aufgrund von Verzögerungen, die den beiden Feedbackloops inhärent sind. Man kann also damit rechnen, dass die Anzahl Tasks wieder leicht ansteigen wird, nachdem sie in der zweiten Hälfte des Projekts den Anschein machten, abzunehmen.