Schlagwort-Archive: Verlust

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.

Die törichte Sonne und der hochmütige Mond

Als Beispiel für eine Learning Story möchte ich das Problem eines kleinen, handlichen Projekts in eine Fabel fassen. Ich kann hier leider nicht näher auf die Projektumstände eingehen, weil es möglicherweise nicht im Sinne der Parteien sein könnte, wenn ich das noch nicht ganz beendete Projekt in die Öffentlichkeit trage. Das ist aber weiter auch nicht nötig, denn eine Learning Story soll ja eben eine Lehre enthalten, die immer wieder auf Projekte angewendet werden kann.

Als die aufsteigende Sonne einmal auf den Mond traf, der sich ebenfalls (noch) am Morgenhimmel tummelte, da dachte sie, wie angenehm es sein müsse, so cool und ruhig zu sein, wie es der Mond ist. Sie war ja ständig am brodeln und litt manchmal etwas unter ihrem inneren Feuer. Da begann sie, den Mond zu loben, wie schön sein Silberschein sei, und dass sie viel darum gäbe, wenn sie dieses Silber einmal für eine kurze Zeit ausprobieren dürfte. Der Mond war geschmeichelt und überlegte sich, dass vielleicht ein wenig vom Glanz und der Grösse der Sonne an ihn abfallen möge, wenn er der Sonne den Gefallen tut und ihr vorübergehend einen Teil seines Silberscheins gibt. Also beredete er mit der Sonne die Einzelheiten der Übergabe. Doch kaum war das bisschen kühlen Silberscheins, das der Mond abtreten konnte, auf der Sonne angekommen, verpuffte er und wurde von der Hitze und dem gleissenden Licht aufgezehrt. Die Sonne verlor nichts. Der Mond jedoch hat seinen noblen Silberschein eingebüsst und zeigt sich von da an mit vielen Flecken.

Wenn Du etwas a fonds perdu investierst in der Hoffnung, dass es Früchte tragen mag, dann solltest Du genau abklären, welche Möglichkeiten überhaupt bestehen (sollte eigentlich klar sein….). Nicht nur der Mond musste an der Abklärung interessiert sein. Die Sonne hätte sich ebenfalls fragen müssen, ob ihr Wunsch nach Kühle – auch nur probehalber – erfüllbar sein kann. Denn auch die Sonne hatte natürlich Aufwand. Und so schnell muss sie vom Mond nichts mehr erwarten. Zudem werden sich der törichte Wunsch der Sonne und die hochmütigen Gedanken des Mondes am Himmel schnell herum sprechen und nicht gerade zu ihrem Image beitragen.

Die Reduktion des Hauptproblems des Projekts auf das Allerwesentlichtste und das Finden einer passenden Geschichte, welche kurz und einprägsam das Problem chiffriert, sind zwei Schwierigkeiten, die nicht zu unterschätzen sind. Obwohl das Hauptproblem offenkundig war, war es noch lange nicht klar, welche Elemente wie in einer Geschichte abgebildet werden können. Z. B. lassen die Archetypen, aus denen Geschichten aufgebaut sind, kaum einen Zugang zum Begriff „Unternehmensstruktur“. Natürlich kann man mit König, Prinz, Grafen und Lakaien eine Hirarchie abbilden, aber dennoch lassen sich nicht alle Aspekte einer Unternehmensstruktur ausleuchten. Die Transformation „Projektgeschichten, wie sie die Projektmitarbeiter erzählen —> Integration —> Reduktion auf das Wesentliche —> Learning Story (Fabel, Metapher, Allegorie, Märchen, Witz)“ erfordert Kreativität und Talent.