Was ist billiger? Ein Mitarbeiter oder eine Zertifizierung?

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)

2http://www.123-zwischenraum.de/escher.html

Welchen Hypothesen geben Sie den Vorzug?

Welcher Hypothese (Modell, Theorie) würden Sie eher zustimmen?

  • Derjenigen, deren Voraussetzungen (Prämissen) auf wackeligen Füssen steht, aber deren Vorhersagen erstaunlich gut mit den Beobachtungen überein stimmen.
  • Oder derjenigen, deren Voraussetzungen (Prämissen) die Situation gut beschreiben, aber deren Vorhersagen höchstens mittelprächtig zutreffen, wenn überhaupt?

Ihre Antwort kann für das Management wichtig sein, denn Sie planen, entscheiden und handeln meist aufgrund einer Hypothese oder Annahme.

Bisher gab ich der Hypothese, deren Voraussagen zutreffen, den Vorzug. Ich gelange aber immer mehr zur Überzeugung, dass es wichtiger ist, wenn die Prämissen stimmen. Das Modell von Hotelling basiert zwar auf eher realitätsfernen Prämissen (siehe Wo würden Sie sich auf der Costa del Sol als Eisverkäufer platzieren? ) sagt aber richtig voraus, dass Anbieter geographisch nahe beieinander sind, was sich z.B. in Einkaufszentren manifestiert. Das Modell erklärt dieses Verhalten von Anbietern dadurch, dass jeder hofft, durch die Nähe zum Konkurrenten von dessen Kundenbasis profitieren zu können. Da ein allfälliger Effekt dieser Art aber völlig symmetrisch ist, hätte am Ende kein Anbieter tatsächlich etwas gewonnen.

Vielmehr geht es darum, den Kundenwunsch zu respektieren. Wenn ich mir als Konsument vornehme, etwas zu kaufen, dann gehe ich dorthin, wo sich Shops häufen, die meinen Wunschartikel anbieten. Dann kann ich nämlich gemütlich durch alle Läden spazieren und die Angebote und Preise vergleichen. Habe ich mich entschieden, brauche ich nicht weit zu gehen. Ein Anbieter, der seinen Laden weit ab hat, berücksichtige ich schon gar nicht. Das ist doch der Grund für die Ballung von Anbietern gleicher Produkte.

Das Modell von Hotelling ist also falsch, weil seine Prämissen falsch sind. Dennoch kommt es zum richtigen Ergebnis. Das bedeutet: Traue keinem Modell, dessen Prämissen falsch sind, auch wenn die Voraussagen in einem gewissen Bereich und zu einer gewissen Zeit stimmen.

Diese Regel hat noch einen grossen Vorteil: Die Prämissen eines Modells können Sie sofort überprüfen, noch bevor Sie mit dem Modell arbeiten. Um die Voraussagen zu überprüfen, müssen Sie jedoch zuerst einige Zeit mit dem Modell gearbeitet haben. Bis dahin könnten Sie aber schon in der Bedrouille gelandet sein.

Am Anfang steht der Glaube

Am Anfang eines Projekts steht eine Hypothese, wie sich das Projekt ungefähr abwickeln lässt. Die Hypothese betrifft hauptsächlich den Bau des Projektgegenstandes. Aufgrund der Hypothese entwirft man einen Vorgehensplan. Hypothesen können reduktiv, ballistisch, magisch oder einfach kreuzfalsch sein1.

In den seltensten Fällen versucht man, die Hypothese zu widerlegen. Allenfalls wird man sie mit Machbarkeitsüberlegungen und Piloten zu stützen versuchen. Den meisten Menschen sind ihre Hypothesen (über das Leben und die Welt) jedoch „Wahrheiten“. Ganz wichtige Leute – und wer wichtig ist bestimmen die wichtigen Leute – können ihre Hypothesen sogar als Theorien verkaufen und damit bewirken, dass auch andere Leute die Hypothese übernehmen. Das geschah z.B. mit einer ziemlich windigen Hypothese, die sogar einen Namen hat: Capital Asset Pricing Model (CAPM). Für den US-Notenbankchef Greenspan war CAPM die Wahrheit. Er weigerte sich noch im Sommer 2008, die immer grösser werdende Spekulationsblase wahrzunehmen, weil sie gemäss CAPM gar nicht existieren konnte. 2004 behauptete Greenspan, dass eine Preisverzerrung im Häusermarkt sehr unwahrscheinlich sei2.

Trifft man während der Projektabwicklung auf Widerwärtigkeiten, wird man die Hypothese nicht gleich verwerfen, weil ja sonst alles, was bisher geleistet wurde obsolet würde und ein neuer Plan erstellt werden müsste, der Kosten und Termine in Frage stellt. Hypothesen werden wegen ihrer unsicherheitsreduzierenden Funktion ungern aufgegeben.

Also wird man versuchen, die Hypothese zu retten, indem man Ausnahmen beschreibt, unter der die Hypothese in modifizierter oder ergänzter Form immer noch zutrifft. Man erfindet z.B. eine zweite Hypothese, die die erste unterstützt. Dieser Prozess kann ad infinitum verlängert werden (sog. „verlängerte Hypothesenbildungen“). Dörner nennt das „progressive Hypothesenbildung“ 1.

Progressive Hypothesenbildung führt leicht zu Ritualisierungen und damit zu einer Pfadabhängigkeit. Aufgrund der Hypothese meint man im Voraus zu wissen, was in einer bestimmten Situation passiert. Man erfindet dann ein Ritual, mit dem man glaubt, das erwartete Verhalten durchbrechen zu können. Ein typisches Beispiel beobachtet man in der Offertphase eines Projekts. Der Projektleiter muss Aufwand und Preis berechnen. Der Verkäufer korrigiert die Zahlen des Projektleiters nach unten und bietet dem Kunden das Projekt weit unterhalb der Schätzungen des Projektleiters an. Oft feilscht der Kunde den Preis noch weiter hinunter (Unternehmen und Marktteilnehmer verhalten sich wie auf einem grossen Bazar). Dadurch ist es üblich geworden, dass Projektleiter auf den berechneten Preis einen gewissen Betrag (z.B. 10%) schlagen, von dem sie erwarten, dass ihn der Verkäufer wieder entfernt und dann beim realistischen Preis landet. Das wissen mittlerweile auch die Verkäufer und bieten das Projekt immer billiger an. Das ist ein (dynamisches) Ritual, das Unternehmen in den Ruin treiben kann.

1Dörner D. Die Logik des Misslingens. ro ro ro Taschenbuch. 2002
2Krugman P. Wie konnten die Oekonomen sich nur so irren? Tagesanzeiger-Magazin 38/2009 (Auszug aus einem Artikel in der New York Times)