Schlagwort-Archive: Projektmanagementmethoden

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

Nicht-Einhalten klassischer Projektmethodiken als Grund des Scheiterns?

Stephan Schori schrieb am 22 Februar 2009 in einem Kommentar:

Ausserdem ist nach meiner Meinung auch bewiesen, dass, je komplexer und umfangreicher die Projektmethodiken und entsprechenden Dokumente sind, desto kleiner die Erfolgsquote ist, da zwar wohl alle Schritte durchgemacht und dokumentiert werden, ein Review und eine Gesamtbeurteilung aber nicht mehr stattfindet, ganz nach dem Motto: ein Haufen Backsteine macht noch kein Haus!

Nach meiner Erfahrung liegt das Hauptproblem bei gescheiterten Problemen nicht in komplexen und unverständlichen Modellen und der Fähigkeit, “positive von negativen Rückkopplungen unterscheiden zu können (!)”, sondern zu 90% darin, dass schon die klassischen Projektmethodiken nicht eingehalten werden und/oder entgegen aller Sachargumente “politisch” entschieden wird, vielfach auf Befehl des obersten Managements.1

Schori glaubt also an die Effektivität der klassischen Projektmethodiken, wenn er schreibt, dass das Scheitern zu 90% darin liegt, dass sie nicht eingehalten werden. Ich interpretiere das so, dass wenn sie eingehalten würden, dass dann die Projekte nicht scheitern würden. In der Tat wenden auch zertifizierte Projektmanager die gelernten Methoden nicht durchgängig an. Man muss sich aber fragen, was wohl der Grund dafür ist. Dass Analysetools dann nicht angewendet werden, wenn das Top Management politische Entscheide trifft, ist nachvollziehbar. Aber wie steht es in „normal“ laufenden Projekten? Warum gehen Projekt- und andere Manager lieber intuitiv als methodisch vor? Vielleicht weil sie denken, das vorliegende Problem sei zu gering, um zeitraubende Methoden anzuwenden und ihrer Effektivität nicht trauen. Daher entscheiden sie lieber mit Hilfe von Heuristiken, die wir uns vor vielen zig Tausend Jahren angeeignet haben.

Und da kommen eben die Modelle in’s Spiel, die in unseren Köpfen herum schwirren. Schori hat mich gehörig missverstanden, wenn er glaubt, dass ich „komplexe und umfangreiche Projektmethodiken und entsprechende Dokumente“ befürworte. Auch habe ich nie empfohlen, „positive von negativen Rückkopplungen [zu] unterscheiden“. Ganz im Gegenteil! Ich bin mit ihm einig, dass „ein Haufen Backsteine … noch kein Haus“ macht und wir vermehrt Projektbeurteilungen durchführen sollten, um das Ganze nicht aus den Augen zu verlieren. Dabei will ich keine Dokumente reviewen, sondern verstehen, nach welchen meinetwegen intuitiven Regeln der Projektmanager und das Top Management entschieden und gehandelt hat. Es sind mit grösster Wahrscheinlichkeit sehr archaische Regeln, die mehr schaden, als nützen. Wenn wir wissen, nach welchen Heuristiken wir im Projektmanagement entscheiden und welchen möglichen Schaden wir dadurch anrichten, können wir daraus vielleicht etwas lernen.

1http://www.goldwynreports.com/?p=1198