Wie man IT-Projekte zum Scheitern bringt: Ändernde Anforderungen

golem.de: »Gesundheitskarte steht vor dem endgültigen Aus«
(Stand 07.07.2017)

Die Einführung der elektronischen Gesundheitskarte soll bisher an die 1,7 Milliarden Euro gekostet haben. Dabei soll sie kaum etwas von dem geforderten Funktionsumfang können. Ebenso handle es sich um eine überholte Technik. Natürlich werden Schuldige gesucht und auf der jeweils anderen Seite gefunden. Für mich ist dies die interessanteste Stelle im Artikel von golem.de, denn sie gibt eine Erklärung wieder, die ich aus meiner eigenen Erfahrung kenne:

»Der Sprecher der Telekom-Tochter T-Systems, Rainer Knirsch, weist darauf hin, dass die technischen Anforderungen etwa 150 Mal verändert worden seien.«

Die absolute Zahl von 150 beeindruckt mich, auch wenn mir unklar ist, welchen prozentualen Anteil es an der Gesamtanforderung hat und um was für Änderungen es sich im Konkreten handelt. Denn bereits eine wichtige Änderung zum falschen Zeitpunkt reicht aus, um ein Projekt zum Scheitern zu bringen. Ebenso gut können viele unwichtige Änderungen dem Projekt nicht wirklich etwas anhaben.

Du bist schuld!

Auch die Frage nach dem Schuldigen ist nicht einfach. Zum einen kann durch eine lange Dauer eines Projekts die genutzte Technik überholt sein. Zum anderen können sich in der Zwischenzeit Gesetzte verändert haben, z. B. Datenschutz, und damit ändern sich auch die Anforderungen.

Aber auch hier könnte man sich die Frage zu Risikomanagement, Projektsteuerung etc. stellen.

Einblick in Auto mit getönten Scheiben

Da ich keinen Einblick in das Projekt habe, stelle ich hier drei Szenarien vor, die mir in meinen IT-Projekten mit Software-Programmierung / -Einführung aufgefallen sind.

Um die Sache verständlicher und anschaulicher (und vielleicht auch lustiger) zu machen, tue ich so, als handle es sich nicht um die Erstellung einer Software, sondern den Bau eines Autos.

Es gibt allerdings einen wichtigen Unterschied: Mit Autos kennen wir uns alle mehr oder weniger aus und können uns das Endergebnis vorstellen, bei Software funktioniert das meistens nicht.

Wir wissen nicht was wir wollen, bis wir sehen, was wir bekommen und genau das wollen wir nicht.

Der Klassiker. Die Anforderungen sind häufig sehr ungenau oder nicht detailliert genug. Im Prinzip wird ein Auto mit vier Rädern gefordert, mit dem der Kunde im Stadtverkehr fahren will.

Wenn das fertige Auto präsentiert wird, dann fällt der Kunde erschrocken aus allen Wolken: Er hatte etwas wie einen Porsche oder Mercedes oder BMW oder… (füge hier deinen Traumwagen ein) erwartet. Das Budget allerdings lag auf dem Niveau eines Tata Nanos.

Wir wollen alles und zwar sofort und ganz billig!

So ähnlich wie der Klassiker, nur dass der Kunde hier viel konkretere Vorstellungen hat. In diesem Fall ist das Auto ein Fabelwesen, eine Art eierlegende Wollmilchsau: Eine Kreuzung aus Sportwagen, Bus, LKW, Schiff und Flugzeug zum Preis für ´nen Appel und ’n Ei.

Unsere Anforderungen wachsen mit unserem Wissen.

Dieses Szenario ist das häufigste und vermutlich das bekannteste.

Kunde und Unternehmer durchlaufen während der Projektlaufzeit beide einen Lernprozess, der im Idealfall das Produkt zu einer Marktreife führt, die zur Zufriedenheit aller Seiten führt.

Im Nicht-Idealfall verwächst sich etwas, um nicht zu sagen, es wuchert üppig.

Hier ein nicht ganz unrealistisches Beispiel.

Der Kunde sieht das fertige Auto und stellt fest, der Kofferraum ist zu klein.

IT-Unternehmen: »Wir können den Kofferraum vergrößern, das wird soundsoviel mehr Kosten und x Tage dauern.«

Kunde: »Zu teuer und dauert zu lange.«

IT-Unternehmen: »Wie wäre es mit einem Dachgepäckträger?«

Kunde: »Ok, machen!«

Der Kunde schaut sich den fertigen Dachgepäckträger an und wirkt nicht 100%ig zufrieden. »Passt da ein Pferd drauf?«

IT-Unternehmen: »Wenn es klein genug und bewegungslos ist, dann ja.«

Kunde: »Nein, das geht nicht. Wir brauchen eine andere Lösung.«

IT-Unternehmen: »Wie wäre es mit einer Anhängerkupplung?«

Kunde: »Machen.«

Kunde setzt sich in den fertigen Wagen und stellt fest: »Das ist ja Gangschaltung drin. So können wir das Auto nicht in unserer amerikanischen Niederlassung einführen.«

Das geht manchmal soweit, bis von dem ursprünglichen Auto nur noch die Karosserie unverändert bleibt.


2 Gedanken zu “Wie man IT-Projekte zum Scheitern bringt: Ändernde Anforderungen

Schreibe einen Kommentar

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