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.

2 Antworten auf „Unmündigkeit ist ja so bequem!“

  1. Ich glaube erstens, dass das Business in vielen Fällen randvoll mit operativen Aufgaben ist und sich gar nicht ausreichend um die Projekte kümmern kann. Ideal ist das aber sicherlich nicht. Zweitens glaube ich, dass testen auch bestimmte Fähigkeiten voraussetzt die nicht notwendigerweise im Skillset des Business liegen.
    Wahrscheinlich ist also eine Zusammenarbeit zwischen Projekt und Business am Besten.
    Und mir ist bewussst, dass ich hier die extra Komplikation ‚externer Auftragnehmer‘ ausgeblendet habe.

    Schönen Gruß aus Amsterdam,
    Johan Steunenberg

  2. Schon klar, aber dennoch: den Schaden hat das Business, und wenn es meint, sich um die Verantwortung zu drücken, dann ist es selber schuld. Wenn es keine Zeit hat, soll es nicht solche Projekte in Auftrag geben, es sei denn, es hat grad mal 160 Mio übrig.

    Hast Du den Artikel gelesen? Ich kann ihn hier unmöglich vollständig zitieren. Er gefällt mir so, weil es exakt diese Projekte sind, von denen ich immer spreche und die ich selbst so oft erfahren habe. A propos „externer Kunde“: in einem Migrationsprojekt mit einem externen Kunden machte ich den CEO des Projektführers („LIeferanten“) darauf aufmerksam, dass er sich aus der Sicht des Business‘ um das Projekt kümmern muss. Er schob zu viel Arbeit vor. Resultat: ein Jahr später wurde er gefeuert, exakt wegen diesem Projekt!

    Die Contingency Plans des Business müssen Testen überhaupt nicht be-inhalten. Das ist in der Tat keine Businessangelegenheit. Aber an der Tatsache, dass die Verantwortung letzendlich beim Business/Auftraggeber hängen bleibt, führt kein Weg vorbei.

    Gruss,
    Peter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.