Gestern stiess ich auf einen wunderbaren Artikel, dessen Lektüre zu vielen Aha-Einsichten führt. Der Artikel trägt den Allerweltstitel: When bad things happen to good projects1 und ist offenbar im Web längst verbreitet, ohne dass ich ein Umdenken im Projektmanagement hätte feststellen könnte.
Er erzählt von einem ERP-Migrationsprojekt bei HP. Es ist schon das sechste dieser Art. Die ersten fünf sind vom immer gleichen Projektteam mit viel Erfolg durchgeführt worden. Diesmal betrifft es die grösste HP-Abteilung, die ISS (Industry Standard Servers). Für alle Fälle hat HP einen Vorrat an Servern angelegt, der dem üblichen Verkaufsvolumen von drei Wochen entspricht. Zusätzlich hat HP eine leere Fabrikhalle so ausgerüstet, dass sie imstande wäre, einen Überlauf an Bestellungen von kundenspezifisch konfigurierter Servern zu produzieren.
Offenbar sah das Konzept der Migration vor, dass das neue System parallel zum alten läuft, zumindest für eine gewisse Übergangsperiode. In dieser Zeit kommen die Bestellungen im alten System an und werden an das neue System übermittelt, das dann die darauf folgenden üblichen ERP-Funktionen ausführt, wie Bedarfsermittlung und Produktionsplanung. Bei der Übermittlung muss das Datenformat konvertiert werden, und da war offenbar ein klitzekleiner Fehler im Datenmapping. Dieser Fehler hat sich in den Tests kaum manifestiert. Erst, als die Sache produktiv geschaltet wurde, blieben einige Bestellungen stecken und wurden vom neuen System nicht weiter verarbeitet. Bei dem Volumen an Servern, die HP in jeder Zeitperiode produzieren muss, sind „einige“ sehr viel. Erboste Kunden riefen bei der Helpline an oder – noch schlimmer – gingen zu Dell oder IBM. HP verlor wegen dieses kleinen IT-Fehlers 160 Millionen Dollars. Ich habe mir folgende Gedanken gemacht:
1. So, wie der Kontext des Projekts – also das Business und die Unternehmenskultur – einen beträchtlichen Einfluss auf das Projekt hat, übt auch ein Projekt Einfluss auf das Business aus, wie bei Eschers zeichnenden Hände2. Offenbar hängt der Einfluss sensitiv von den Anfangsbedingungen ab, denn ein kleiner Fehler im IT-Projekt kann riesengrosse Auswirkungen auf das Business haben.
2. Koch schreibt, dass das Desaster hätte vermieden werden können,
…not by trying to eliminate every possibility for error in a major IT sysetm migration, which is virtually impossible, but by taking a much broader view of the impact that these projects can have on a company’s supply chain
In wie vielen IT-Migrations- und Integrationsprojekten wird der Fokus noch immer ausschliesslich auf technische, terminliche und finanzielle Risiken beschränkt? Natürlich kann man von einem Projektleiter nicht verlangen, dass er sich sowohl um technische Detailfragen als auch um strategische Belange des Gesamtunternehmens kümmert. Im Gegenteil: Einem Projektleiter wird kaum zugestanden, dass er sich in den Projektkontext einmischt. Dafür ist doch das Top Management zuständig. Aber wo bleibt es denn, wenn es gilt, den „broader view of the project’s impact“ zu beurteilen?
3. Das Top Management meint, wenn es seine Projektmanager PMP-zertifiziere, dann habe es seine Hände in Unschuld gewaschen, denn Koch schreibt:
That’s why IT project management has become high art while business contigency planning remains in the Dark Ages
Die Manager mögen ganz einfach ihre Hausaufgaben nicht machen, denn contingency plannig ist eindeutig ihr Bier. Je bedeutender das Projekt ist und je näher am Kunden es ist, desto mehr Engagement ist vom Top Management zu erwarten. Die übliche Abwesenheit des Top Managements in wichtigen Projekten rechtfertigt jedenfalls keine fetten Managerlöhne!
4. Es ist wahrscheinlich auf die Dauer billiger, zusätzliche Ressourcen anzustellen, die das Geschäft von Hand machen, wenn etwas schief geht, als die methodischen Fähigkeiten der Projektmanager bis zum Geht-nicht-mehr zu perfektionieren. Koch schreibt dazu:
In the end, it is riskier for companies to try to protect themselves from glitches in enterprise software projects through ever better IT project management techniques than it is to plan for manual workarounds to get products to customers in case of failures
Immerhin wurde der Rückstau der Bestellungen einige Zeit nicht entdeckt. Dazu schreibt Bill Swanton von der AMR Research (die, die das SCOR-Modell mit entwickelt haben):
It’s (about) having people who are watching what’s happening, able to detect if there’s a problem and working out some simple manual way around it until you are ready to work with the system
5. Schliesslich liegt es an uns Endverbrauchern zu akzeptieren, dass der seriöse Umgang mit Komplexität – d.h. das Verhindern von GAUs – Geld kostet und wir Geiz nicht weiterhin geil finden sollten.
1Koch Christopher. When bad things happen to good projects. 2004.
(http://www.cio.de/801687 und eine pdf-Version bei http://www.webcitation.org/5k978Ejcd)