IT-Modernisierung scheitert selten an der Technik – vier Zahlen, die jeder Projektleiter kennt

Was tatsächlich passiert ist

Am 25. Oktober veröffentlichte Global Views World eine Auswertung, die sich auf Accentures Ausblick „Future of Enterprise IT" für 2026 beruft: 85 Prozent der Modernisierungsvorhaben in Unternehmen verfehlen demnach ihre selbst gesteckten Ziele, nur rund 15 Prozent gelingen vollständig. Dazu kommen Zahlen, die erfahrenen Projektverantwortlichen bekannt vorkommen. Rund 30 Prozent des IT-Budgets fließen nach einer Gartner-Prognose weiter in den Betrieb von Altsystemen; nach einer Deloitte-Umfrage ist die Datenmigration für 40 Prozent der Projektverzögerungen verantwortlich; und laut Prosci nutzt nur etwa ein Viertel der Unternehmen eine strukturierte Change-Management-Strategie. Die Natuvion-Transformationsstudie 2026 (13. Oktober), gestützt auf über 1.100 IT-Entscheider, liefert für dasselbe Bild harte Zahlen: 82 Prozent der Projekte überschreiten ihr Budget, knapp 80 Prozent ihren Zeitplan, und 71 Prozent mussten ihre Migrationsmethodik im Verlauf grundlegend anpassen.

Meine Einordnung

Über die 85 Prozent streiten sich die Erhebungen seit Jahren – je nachdem, was man „Scheitern" nennt, kommt man auf 70, 80 oder 85 Prozent. Ich halte die Debatte um die genaue Prozentzahl für eine Ablenkung. Die eigentliche Aussage steckt in einer Nebenbemerkung: Projekte scheitern nicht an fehlender Technik, sondern an Dingen, die man vor dem Start festlegen könnte und dann vergisst. Wer keine Ziele aufschreibt, kann sie nicht verfehlen – er merkt es nur später, und teurer.

In meinen Mandaten zeigt sich ein Muster, das keine Studie so deutlich formuliert. Der teuerste Fehler ist selten die falsche Software, sondern die ungeklärte Zuständigkeit an der Schnittstelle zweier Dienstleister. Als CISO einer Behörde mit rund 1.500 Mitarbeitenden habe ich erlebt, wie ein Projekt monatelang „fast fertig" war: Jeder Beteiligte war beschäftigt, niemand war verantwortlich, und der einzige verbindliche Status war der Termin im Lenkungskreis. Datenmigration ist dabei kein technischer Vorgang, den man einmal im Wartungsfenster erledigt; sie ist die Frage, ob Ihr Altsystem überhaupt die Wahrheit enthält, die das neue System fortführen soll. Wer das nicht vorher prüft, verschiebt einen Konflikt in die heiße Phase.

Und einem zweiten Reflex widerspreche ich: Der Ruf nach dem „großen Wurf", alles auf einmal zu ersetzen, ist selten der mutige Weg und meistens der bequeme. Ein „Big Bang" spart die unbequeme Arbeit, den Altbestand wirklich zu verstehen, und verwandelt sie in Risiko. Deshalb plädiere ich für den schrittweisen Weg: erst verstehen, dann ein Teilprojekt nach dem anderen umstellen, zwischendurch den Nutzen belegen. In Fürstenfeldbruck, Augsburg und im Münchener Umland gibt es dafür keinen strukturellen Nachteil – nur die kleinere Organisation, die einen Ausfall nicht kompensiert. Man kann ein ERP in Funktionsblöcken modernisieren oder eine einzelne Anwendung zuerst. Das ist weniger heldenhaft und deutlich wahrscheinlicher erfolgreich.

Was Sie jetzt konkret tun können

1. Ziel in einem Satz, messbar. Nicht „moderne IT", sondern „Auftragsbestätigung in unter 24 Stunden" oder „Monatsabschluss zwei Tage früher". Wenn Sie das Ergebnis nicht in einem Satz sagen können, ist es kein Projekt, sondern ein Wunsch.

2. Zuständigkeit vor Technik. Benennen Sie eine Projektleitung mit Entscheidungsbefugnis und eine Vertretung. „Das macht die IT nebenbei" ist die häufigste Ursache für das, was später Verspätung heißt.

3. Datenlage prüfen, bevor Sie migrieren. Eine Inventur: Was ist doppelt, was veraltet, was existiert nur im Kopf eines Kollegen? Diese zwei Tage sind billiger als vier Wochen Nacharbeit.

4. Zwischenstand statt Endtermin. Legen Sie einen überprüfbaren ersten Baustein fest, der in acht Wochen sichtbar ist. Momentum schlägt Hoffnung.

5. Change Management ist keine Kür. Planen Sie Schulung und Kommunikation von Anfang an ein, nicht als Nachtrag, wenn die Stimmung bereits gekippt ist.

Wenn drei Dienstleister, ein unklarer Datenbestand und ein unterschriebener Vertrag ohne definiertes Ergebnis zusammenkommen, hilft kein Werkzeug. Dann braucht es jemanden, der das Projekt von außen führt.