Warum IT-Projekte scheitern: Die Zahlen und die wahren Ursachen

Wer wissen will, warum IT-Projekte scheitern, findet zuerst Prozentzahlen und selten den Kontext dazu. Die Studien widersprechen sich nur scheinbar, denn jede definiert Scheitern anders. Wichtiger als die Quote ist die Ursache dahinter, und die fällt über alle Erhebungen hinweg auffallend gleich aus.

Wie oft IT-Projekte scheitern: die Zahlen

Der Standish CHAOS Report 2024 zählt 31 Prozent der untersuchten Projekte als erfolgreich, 50 Prozent als mit Problemen abgeschlossen und 19 Prozent als gescheitert (Standish Group). Die PMI-Studie für Deutschland aus demselben Jahr kommt auf eine niedrigere Misserfolgsquote von 17 Prozent. Allerdings erreichen dort nur 68 Prozent der Projekte am Ende tatsächlich ihre Geschäftsziele (PMI-Daten via Haufe, 2024).

Diese Differenz ist kein Widerspruch. Sie zeigt ein Definitionsproblem. Standish zählt Projekte als gescheitert, die abgebrochen wurden, bevor überhaupt etwas ausgeliefert wurde. PMI misst dagegen, ob am Ende die ursprünglichen Geschäftsziele erreicht wurden. Das ist eine deutlich strengere Latte. Ein Projekt kann pünktlich und im Budget abgeliefert werden und trotzdem als Fehlschlag gelten, wenn es am eigentlichen Bedarf vorbeigebaut wurde.

Was Überschreitung in der Praxis bedeutet

Bei SAP S/4HANA-Einführungen zeigt sich das Muster noch schärfer. 60 Prozent der Projekte reißen sowohl Budget als auch Zeitplan, 30 Prozent dauern länger als vorgesehen (Horváth-Studie via WirtschaftsWoche, 2025).

S/4HANA-Projekte sind komplexe Migrationen mit vielen Abhängigkeiten zu Altsystemen. Die Zahl lässt sich deshalb nicht eins zu eins auf jedes Softwareprojekt übertragen. Sie zeigt aber, wie stark Umfang und Systemkomplexität die Erfolgsaussichten drücken, selbst bei Anbietern mit etabliertem Vorgehensmodell und großem Partnernetzwerk.

Für Unternehmen in Industrie und Handel ist die S/4HANA-Zahl deshalb relevant, weil ERP-Migrationen dort seit Jahren zu den größten IT-Vorhaben zählen. Ein Produktionsbetrieb, der Lager, Fertigungssteuerung und Finanzbuchhaltung gleichzeitig auf ein neues System hebt, hat ein anderes Risikoprofil als ein reines Softwarehaus, das eine einzelne Anwendung baut. Die Abhängigkeiten zwischen Modulen, Schnittstellen zu Maschinensteuerungen und historisch gewachsenen Sonderlösungen summieren sich. Wer ein solches Projekt startet, sollte die 60-Prozent-Zahl als realistische Grundannahme für die eigene Planung behandeln.

Warum IT-Projekte scheitern in der Praxis

Hinter den Prozentzahlen steht meist eine Ursache öfter als jede andere.

Das deckt sich mit einer Beobachtung aus vielen laufenden Projekten. Am Anfang fehlt eine belastbare Definition, was das System leisten soll. Jede spätere Anforderung wird dann zur Ausnahme erklärt, bis aus vielen Ausnahmen ein zweites, ungeplantes Projekt geworden ist. Wie sich dieser Verlauf stoppen lässt, steht im Beitrag zu Scope Creep, und die Vorarbeit dagegen leistet ein sauberes Pflichtenheft.

Trotz zehn Jahren agiler Methoden hat sich an der grundsätzlichen Erfolgsquote wenig geändert. Sie stagniert seit 2017 auf einem ähnlichen Niveau (PM World Journal, 01/2026). Das ist unbequem für alle, die glaubten, Sprints und Retrospektiven würden das Grundproblem lösen. Agile Prozesse machen Probleme früher sichtbar. Eine klare Auftragsklärung und eine entscheidungsfähige Führung ersetzen sie nicht.

Die Grenzen der CHAOS-Methodik

Der CHAOS Report wird seit Jahren kritisiert. Standish legt die genaue Stichprobe und Erhebungsmethode nicht vollständig offen, und die Kategorien erfolgreich, herausgefordert und gescheitert wurden im Zeitverlauf mehrfach angepasst. Wer die Zahl 19 Prozent zitiert, sollte wissen, dass sie mit früheren CHAOS-Ausgaben aus den 1990er- und 2000er-Jahren nur eingeschränkt vergleichbar ist, in denen die Scheiternsquote deutlich höher lag. Das entwertet die aktuelle Zahl nicht. Es begrenzt nur, was sich daraus für den eigenen Fall ableiten lässt.

Was diese Zahlen für Ihr Projekt bedeuten

Für Geschäftsführung und IT-Verantwortliche in Industrie und Handel ist die praktische Frage weniger, welche Studie recht hat. Wichtiger ist, wann die eigenen Warnsignale ernst zu nehmen sind. Ein durchbrochener Meilenstein ist noch kein Alarm. Zwei durchbrochene Meilensteine in Folge, dazu eine Anforderungsliste, die jede Woche wächst, sind ein Muster, das die zitierten Studien exakt beschreiben. Wer wartet, bis das Budget bereits um 75 Prozent überschritten ist, hat den günstigsten Zeitpunkt für eine Kurskorrektur bereits verpasst. Details zur Ursachenanalyse bei einer laufenden Überschreitung stehen im Beitrag zur Budgetüberschreitung im IT-Projekt.

Häufige Fragen

Wie viele IT-Projekte scheitern wirklich?

Je nach Definition zwischen 17 und 19 Prozent vollständig, weitere rund 50 Prozent laufen mit deutlichen Problemen bei Budget, Zeitplan oder Umfang (Standish Group 2024, PMI-Daten via Haufe 2024). Die genaue Zahl hängt davon ab, ob ein abgebrochenes Projekt oder ein ausgeliefertes, aber zielverfehlendes Projekt als gescheitert zählt.

Was kostet ein gescheitertes IT-Projekt?

Die reinen Projektkosten sind meist nur ein Teil der Rechnung. McKinsey beziffert die durchschnittliche Budgetüberschreitung 2024 auf 75 Prozent des Ausgangsbudgets, dazu kommt entgangener Nutzen durch verspätete oder ausbleibende Auslieferung. Bei größeren Vorhaben wie SAP S/4HANA-Einführungen liegt die Überschreitungsquote bei 60 Prozent der Projekte (Horváth via WirtschaftsWoche, 2025).

Wann sollte man externe Hilfe holen?

Sobald zwei Meilensteine in Folge gerissen werden oder die Anforderungsliste sich deutlich über den ursprünglichen Rahmen hinaus ausdehnt, lohnt sich eine externe Einschätzung. Zu diesem Zeitpunkt sind die Ursachen meist noch klar erkennbar und die Handlungsoptionen breiter als drei Monate später. Wie ein Interim CTO in einer solchen Phase konkret vorgeht, beschreiben wir auf unserer Leistungsseite.

Der nächste Schritt

torck sieht diese Muster regelmäßig in eigenen IT-Projekten für Industrie und Handel. Bei den ersten Anzeichen einer Schieflage übernehmen wir technische Führung und Umsetzung aus einer Hand, gestützt auf eigene Entwicklungsteams in Maxhütte-Haidhof, Wien und Rabat. Vereinbaren Sie ein unverbindliches Erstgespräch, um Ihr Projekt einzuordnen.