Warum scheitern IT-Projekte? Ursachen und Frühwarnzeichen

Der britische National Health Service wollte ab 2002 mit dem National Programme for IT die Patientenakten in ganz England digitalisieren. 2011 kündigte die Regierung an, das Programm aufzulösen. Der Rechnungsprüfungsausschuss des Unterhauses rechnete 2013 vor, dass trotzdem Kosten von rund 9,8 Milliarden Pfund anfallen würden.

Solche Fälle prägen das Bild. Sie sind aber nicht der typische Fall. Die meisten IT-Projekte scheitern leiser: Sie werden fertig, nur später, teurer und mit weniger Nutzen als geplant. Um das zu verstehen, lohnt ein genauer Blick auf die Zahlen, auch auf ihre Schwächen.

Was die Studien zeigen und was nicht

Am häufigsten zitiert wird der CHAOS Report der Standish Group. Für 2020 kursieren daraus etwa 31 Prozent erfolgreiche Projekte, 50 Prozent mit Problemen und 19 Prozent gescheiterte. Der Bericht selbst ist kostenpflichtig, nachprüfen lassen sich diese Zahlen öffentlich kaum. Trotzdem tauchen sie in fast jeder Präsentation zum Thema auf.

Vorsicht ist angebracht. Robert Glass fragte schon 2006 in den Communications of the ACM, ob der Report die behauptete Softwarekrise überhaupt belegt, weil andere Studien zu deutlich anderen Ergebnissen kamen. Magne Jørgensen und Kjetil Moløkken-Østvold zeigten im selben Jahr, dass die im Report von 1994 genannte durchschnittliche Kostenüberschreitung von 189 Prozent vermutlich viel zu hoch war, möglicherweise weil gezielt nach Problemprojekten gefragt wurde. J. Laurenz Eveleens und Chris Verhoef kritisierten 2010 in IEEE Software die Erfolgsdefinition. Dazu kommt: Die Rohdaten sind nicht öffentlich, und die Definition von Erfolg wurde 2015 geändert. Vergleiche über die Jahre sind deshalb kaum möglich.

Belastbarer sind Studien mit offengelegter Methodik. Zwei davon:

Bent Flyvbjerg und Alexander Budzier werteten 2011 für die Harvard Business Review 1.471 IT-Projekte aus. Die durchschnittliche Kostenüberschreitung lag bei 27 Prozent. Das eigentliche Ergebnis steckte im Ausreißer: Jedes sechste Projekt überzog die Kosten im Schnitt um 200 Prozent und den Zeitplan um fast 70 Prozent. Die Autoren nannten diese Fälle Schwarze Schwäne.

Für die Praxis heißt das: Ein Puffer von 20 Prozent schützt vor dem Normalfall. Gegen den Ausreißer schützt nur, ihn früh zu erkennen und gegenzusteuern.

Die sieben häufigsten Ursachen

Aus Studien, Untersuchungsberichten wie dem zum NHS-Programm und der Literatur zum Projektmanagement lassen sich wiederkehrende Muster ableiten.

1. Kein messbares Ziel. Wer nicht weiß, woran Erfolg gemessen wird, kann nicht priorisieren. Jede Anforderung wirkt gleich wichtig.
2. Schleichend wachsender Umfang. Viele kleine Erweiterungen, keine davon formal bewertet. In der Summe ein anderes Projekt.
3. Schätzung wird Zusage. Eine frühe Zahl, unter Druck genannt, wird zum Termin. Der Kegel der Unsicherheit sagt, dass sie um Faktor vier danebenliegen kann.
4. Keine Entscheider auf Fachseite. Das Team wartet auf Antworten oder baut auf Annahmen, die später kassiert werden.
5. Zu groß geschnitten. Projekte, die erst nach zwei Jahren etwas liefern, sammeln Risiken an, ohne sie zu prüfen.
6. Unterschätzte Integration. Die Anbindung an Altsysteme und die Datenmigration werden als Nebensache behandelt und dominieren dann den Aufwand.
7. Kein Abbruchkriterium. Wer nie festgelegt hat, wann aufgehört wird, hört nicht auf. Das bereits investierte Geld verzerrt jede Entscheidung.

Bemerkenswert an der McKinsey-Zahl ist übrigens nicht die Kostenüberschreitung, sondern der fehlende Nutzen. 56 Prozent weniger Nutzen als geplant heißt: Selbst wenn ein Projekt im Budget geblieben wäre, hätte es oft nicht geliefert, wofür es gestartet wurde. Das spricht für kleinere Schritte mit früher Überprüfung, ob das Gebaute überhaupt gebraucht wird. Genau dieses Argument steckt hinter iterativen Verfahren, die im Vergleich Agil vs. Wasserfall ausführlich besprochen werden.

Auffällig ist, was fehlt: „Die Entwickler konnten nicht programmieren“ taucht in solchen Analysen selten als Hauptursache auf. Die meisten Ursachen liegen vor dem ersten Commit oder außerhalb des Entwicklungsteams.

Frühwarnzeichen, die du jede Woche prüfen kannst

Krisen kündigen sich an. Diese Signale lassen sich ohne Spezialwissen beobachten:

Zwei oder mehr dieser Punkte gleichzeitig sind ein Grund, die Lenkungsrunde einzuberufen, nicht erst beim nächsten regulären Termin.

Was gegen die häufigsten Ursachen hilft

Die gute Nachricht: Gegen fast jede Ursache gibt es eine einfache, wenig aufregende Gegenmaßnahme.

Keine dieser Maßnahmen ist neu. Sie werden trotzdem selten konsequent umgesetzt, weil sie am Anfang Zeit kosten, wenn alle loslegen wollen. Wie man sie in die Projektvorbereitung einbaut, steht im Beitrag Softwareprojekt planen. Und warum Spannen statt Punktwerte so viel ändern, erklärt der Beitrag zur Aufwandsschätzung.

Wenn das Projekt schon schiefläuft

Ein Projekt in der Krise braucht zuerst Ehrlichkeit über den Stand, nicht mehr Personal. Fred Brooks hat schon 1975 festgehalten, dass zusätzliche Leute ein verspätetes Softwareprojekt noch später machen. Sinnvoller sind drei Schritte: den tatsächlich abgenommenen Umfang feststellen, den Rest neu schätzen und dann zwischen drei Optionen wählen. Umfang kürzen, Rahmen erweitern oder abbrechen.

Abbrechen ist keine Niederlage, wenn die Fortsetzung mehr kostet als sie bringt. Das ist schwer zu akzeptieren, wenn schon viel Geld geflossen ist. Gerade deshalb gehört das Abbruchkriterium an den Anfang, als es noch niemandem wehtat.

Manchmal hilft ein Blick von außen. Ein unabhängiges technisches Review, etwa durch ein Studio wie OnlineBuilders, kann klären, ob Architektur und Code eine Fortsetzung tragen oder ob ein Neustart günstiger wäre.

Nächster Schritt: Geh die Checkliste der Frühwarnzeichen für dein laufendes Projekt durch. Wenn du bei einem Punkt zögerst, ist das schon eine Antwort.