Unmündigkeit ist ja so bequem!

In Man schlägt den Esel und meint den Sack habe ich ein typisches Migrationsprojekt vorgestellt, das dem Computerhersteller Hewlett-Packard HP mindestens 160 Millionen US-Dollar Verlust verursachte. Kleine unvermeidliche Programmierfehlerchen führten dazu, dass Bestellungen stecken blieben, ohne dass es jemand merkte. Einige der erzürnten Kunden erkundigten sich nach dem Liefertermin. Deren Bestellungen konnten gesucht und nachträglich erfüllt werden. Schlimmer war die Situation mit denjenigen Kunden, die gar nicht erst reklamierten, sondern gleich zu der Konkurrenz – z.B. Dell oder IBM – abwanderten.

Warum sind kleine Programmierfehler unvermeidlich? Weil der Entwickler niemals alle Eventualitäten voraussehen kann, auf die seine Software reagieren muss. Unerwartete Situationen sind unvorhersehbar, andernfalls wären sie nicht unerwartet. In solchen Fällen wird eine Software meistens eine Fehlermeldung ausgeben. Ganz selten – und hier war es der Fall – gibt es keine Fehlermeldung, und die Anwender merken zu spät, dass etwas schief gelaufen ist. Bei der europäischen Trägerrakete Ariane V wurde die Navigationssoftware der Vorgängerrakete Ariane IV angepasst. Dabei wurde eine Kleinigkeit übersehen, was zum Absturz der Rakete führte. In der Software eines Marslandungsgerätes wurde an einer Stelle metrische mit US- Masseinheiten verwechselt, was ebenfalls zum Verlust des Geräts und zum Abbruch der Mission führte.

Der Autor der HP-Fallstudie betont, dass das Risikomanagement in den meisten IT-Projekten Sache des Business und Auftraggebers sein müsse. Stattdessen wird das Risikomanagement einfach auf die IT abgewälzt: „Seht zu, dass Ihr keine Fehler macht!“. Wie wir gesehen haben, können unscheinbare Programmierfehler riesige kommerzielle Konsequenzen haben. Das ist eine Art Schmetterlingseffekt. Das Business schneidet sich also selber ins Fleisch, wenn es die Risikoverantwortung einfach an die IT delegiert.

Die Grafik zeigt die Situation als Systemarchetypus der Problemverschiebung. Es gibt grundsätzlich zwei „Lösungen“, eine symptomatische und eine fundamentale. In unserem Fall ist die symptomatische „Lösung“ die Delegation der Risikoverantwortung an die IT. Was kann sie tun? Sie schickt ihre Leute – Entwickler und Projektmanager – in die Ausbildung und delegiert ihre Verantwortung gerade noch einmal. Immerhin: wenn die Projektmanager ein Zertifikat als „Project Management Professional“ vorweisen können, dann muss doch einfach alles gut gehen….

Wie immer ist der Weg zu der fundamentalen Lösung steiniger und mühsamer, als derjenige zu der symptomatischen. Daher wird dieser bevorzugt. Mit der Delegation der Verantwortung an die IT, entmündigt sich der Auftraggeber selbst, denn je mehr die symptomatische Lösung präferenziert wird, desto unwahrscheinlicher wird es, dass der Auftraggeber die fundamentale Lösung überhaupt versucht. Der Pfeil, der von der “Qualität der Projektführung” zum “Veranwortungsdruck auf das Business” führt, verringert letzeren Parameter. Je besser und kompetenter die Projektführung, desto unnötiger erscheint es, dass sich das Business zusätzliche Gedanken zum Risikomanagement macht. Was kann denn bei zertifizierten Projektmanagern noch schief gehen?

Dennoch sollte die fundamentale Lösung begangen werden, nämlich dass der Auftraggeber das Risikomanagement übernimmt.  Wenn ich diese Aufgabe erhielte, würde ich sämtliche Bestellungen, die in das alte Order Entry System (ERP) hinein gegangen sind, in den Produktions- und Speditionsaufträgen suchen. Wenn ich keine eindeutige Zuordnung machen könnte, würde ich die Alarmglocken läuten (siehe die beiden Abbildungen in Man schlägt den Esel und meint den Sack).

Es ist nicht Sache der IT diese Kontrolle durchzuführen, es sei denn, sie erhält einen Auftrag zur Entwicklung einer Software, die Eingänge und Ausgänge vergleicht. Das wäre ein anderes Projekt als das ursprüngliche Migrationsprojekt, welches in seinem Budget solche Kontrollen nicht vorgesehen hat. Zudem muss damit gerechnet werden, dass auch die Vergleichssoftware fehlerbehaftet ist. Daher müssen zusätzliche (menschliche) Kontrolleure eingesetzt werden.

Doch welcher Manager wagte es, solche Entscheidungen zu treffen? Wie oft hört man: “Nur keine schlafenden Hunde wecken”, bis dann einer der Hunde eben doch zubeisst.

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

Man schlägt den Sack und meint den Esel

Auch wenn es vielleicht manchmal nicht offensichtlich ist, aber bei all meinen Beiträgen geht es mir um den Praxisbezug. Es gibt zwar nichts Praktischeres, als eine gute Theorie, aber wenn daraus nicht hervor geht, was ein Manager machen muss, um bessere Ergebnisse zu erzielen, dann ist die Theorie noch unausgereift.

Obwohl ich hier schon einmal auf den Artikel When Bad Things Happen to Good Projects1 aufmerksam gemacht habe (Was ist billiger? Ein Mitarbeiter oder eine Zertifizierung? in diesem Blog, 29. September 2009), möchte ich nochmals mit Nachdruck darauf hinweisen. Die Lessons Learned, die man aus diesem Artikel ziehen kann, weisen eindeutig in die richtige Richtung.

Ein typisches Migrationsprojekt

Es handelt sich um eine Fallstudie eines typischen Migrationsprojekts. Nachdem HP einige Unternehmen inklusive ihren Prozessen und IT-Systemen akquiriert hat – z.B. Compaq – sah sie sich vor das Problem gestellt, die verschiedenen IT-Systeme, die dieselbe Funktionen haben, zusammen zu führen. Beispielsweise hat jede Unternehmung ein sog. Order Entry System, also eine IT-Einrichtung, die Bestellungen entgegen nimmt und in Produktions- und Speditionsanweisungen umwandelt. Die Bestellungen geben die Kunden über das Internet (bzw. das Web) direkt in das Order Entry System ein. Kleinere Kunden können ev. auch einen Support Mitarbeiter anrufen und die Bestellung mündlich durchgeben.

Bei HP ist das Order Entry System ein Teilsystem ihres SAP. Einige Unternehmen, die HP akquiriert hat, haben allerdings kein SAP eingesetzt. HP wollte nun alle Order Entry Systeme in ihrem Unternehmen auf SAP konsolidieren.

Umleiten des Outputs des einen Systems in das andere System

Das machte sie in mehreren Etappen und stets auf dieselbe Weise: Der Output eines Order Entry Systems R wurde in das SAP-System umgeleitet. Für das SAP-System waren dann die Bestellungen, die via R herein gekommen sind, gleichbedeutend, wie Bestellungen, die von einem externen Kunden kamen. Haben die Kunden, die via R bestellten, einmal begriffen, dass sie jetzt via das SAP-System bei HP bestellen müssen, kann R abgeschaltet werden.

Dazu müssen die Produktions- und Speditionsanweisungen, die das System R verlassen, in Bestellungen für das SAP-System übersetzt werden. Es braucht also zwischen dem R-System und dem SAP-System ein kleines Stück Software, das diese Übersetzung macht. HP hat diese Übersetzungssoftware für das Order Entry System einer jedem akquirierten Unternehmung geschrieben. Jedes Mal ging das gut und jedes Mal erhöhte sich die Erfahrung von HP für dieses Vorgehen bei der Übernahme einer neuen Unternehmung….bis sie die fremden Order Entry Systeme für das Servergeschäft migrieren wollten. Das Servergeschäft ist der grösste Geschäftszweig von HP.

Der Krug geht zum Brunnen bis er bricht

Die letzte und umfangreichste Migration ging schief! Die Übersetzungssoftware enthielt kleine Fehler, die dazu führten, dass viele Bestellungen im SAP-System stecken blieben und gar nie in die Produktion kamen, bzw. die bestellte Ware gar nie spediert wurde. Kunden beschwerten sich oder – noch schlimmer – wanderten ohne Kommentar ab. Der Schaden betrug 160 Millionen US-Dollar!

HP hat die Übersetzungssoftware auf Herz und Nieren getestet. Dennoch enthielt sie Fehler, denn man konnte nicht alle möglichen Bestellformate voraussehen, die die Kunden anliefern. Es gab Bestellungen, die enthielten unvorhergesehene Elemente oder Zeichen, die die Übersetzungssoftware nicht richtig interpretieren konnte. Das kann man mit den umfangreichsten und sorgfältigsten Tests nicht verhindern.

Lehren

Es gibt viele Lehren, die wir daraus ziehen können, und ich möchte in einem oder zwei Folgebeiträgen auf ein paar Lehren hinweisen, die der Autor des Artikels nicht erwähnt hat. Er betont vor allem, dass das Risikomanagement vom Business wahrgenommen werden muss und nicht auf die IT abgeschoben werden darf. Oft wird nämlich die IT “geschlagen”, obwohl man das Business meint.

Die IT versucht, durch Zertifizierung die Projektmanagement-Fähigkeiten zu erhöhen, was zwar machbar ist, aber offensichtlichs nichts taugt. Gegen die Unvorhersehbarkeit der Bestellformate hilft eben z.B. ein Gantt-Diagramm oder eine Earned Value Analysis nichts. Risikomanagement auf der Businessebene ist hingegen viel schwieriger und unangenehmer, weshalb es gerne auf die IT abgewälzt wird. Das ist der Systemarchetypus der Problemverschiebung, auf den ich im nächsten Beitrag zu sprechen komme.
Schliesslich forderte der Autor bereits 2004, dass man im Projektmanagement endlich vom Kost-Termin-Denken wegkommen sollte. Was nützt einem ein Projekt, dass kosten- und terminmässig erfolgreich abgeschlossen wurde, nachträglich dem Business aber 160 Mio Dollar Verlust bringt? Sagen Sie nicht, dass das Projekt in dem Fall nicht erfolgreich war! Es wurde vom Auftraggeber zufriedenstellend abgenommen, nachdem er sogenannte Akzeptanztests gemacht hatte, denn auch er hatte sich nicht abschliessend vorstellen können, was für Bestellungen eintreffen werden.

1Koch, Christopher. When Bad Things Happen to Good Projects, in CIO.com, 2. April 2007