Gescheiterte IT-Transformationen haben selten eine einzelne Ursache im Fachbereich. Die belastbare Empirie 2023 bis 2026 verortet die Hauptursachen in Architektur, Governance, falschen Erfolgsmetriken und an der Schnittstelle zwischen IT und Business. Das verbreitete Bild vom blockierenden Fachbereich stammt überwiegend aus Selbstauskünften von IT-Verantwortlichen, nicht aus unabhängiger Messung.
- Bain 2026: 88 % der Führungskräfte halten ihre Reorganisation für erfolgreich, nur 36 % der Mitarbeitenden teilen die Einschätzung. Lücke von 52 Prozentpunkten.
- McKinsey/Oxford (n=5.400 IT-Grossprojekte): rund 50 % des Schadens entstehen in IT-Execution und Governance, nicht im Fachbereich.
- VW Cariad, HealthCare.gov und weitere, in 6 von 7 dokumentierten Post-Mortems liegen die belegten Ursachen bei Architektur, Governance, Beschaffung. Fachbereichs-„Blockade“ ist meist Symptom, nicht Ursache.
- DeLone-McLean (12.000+ Zitationen): Nutzerzufriedenheit ist Mediator, nicht Auslöser, wer Misserfolg auf Akzeptanz schiebt, dreht die Kausalität um.
- Diagnose vor Therapie: DORA Quick Check, SPACE-Framework, Spotify Health Check liegen frei verfügbar, und werden meist übersprungen.
Wenn eine Transformation scheitert, findet sich schnell ein Adressat. Der Fachbereich liefert keine sauberen Anforderungen, akzeptiert die neuen Systeme nicht, blockiert. Diese Erzählung ist bequem. Sie hält der Datenlage nur nicht stand.
Wer ist eigentlich „der Fachbereich“, und warum landet die Erklärung immer dort?
Die spannende Frage ist nicht, ob der Fachbereich Fehler macht. Die Frage ist, woher das Wissen über die Ursachen-Verteilung kommt. Und hier wird es methodisch unangenehm.
Die meisten Zahlen zum Thema „Warum scheitern IT-Transformationen“ stammen aus CIO-Surveys. Gartner berichtet in seiner CIO-Befragung, dass nur 48 Prozent digitaler Initiativen ihre Business-Ziele erreichen (n = 3.186 CIOs plus 1.126 weitere Führungskräfte). Das ist eine ehrliche Zahl. Nur: Wer IT-Verantwortliche nach den Gründen für Misserfolg fragt, bekommt eine vorhersehbare Antwort. Die Sozialpsychologie nennt das Self-Serving-Bias. Erfolge werden internen Faktoren zugeschrieben, Misserfolge externen. Bei IT-Leitern heisst „extern“ meist: Fachbereich, Change-Resistance, fehlendes Top-Management-Engagement.
Konkret zeigt sich das an einem Vergleich der Befragten-Gruppen. CEO-Studien benennen die Ursache ganz anders. Die IBM CEO Study 2025 (n = 2.000 CEOs, 33 Länder) zeigt, dass 64 Prozent der CEOs in Technologie investieren, bevor sie deren organisationalen Wert verstehen. Die Erklärung wandert hier nach oben, nicht zur Seite. Keine der grossen Studien definiert „Business Alignment Failure“ objektiv messbar. Es bleibt durchgängig die Selbstauskunft einer Partei über die andere.
Was sagen die Daten 2024 bis 2026 wirklich über gescheiterte IT-Transformationen?
Sobald man methodisch saubere Quellen priorisiert, zerfällt das einfache „Business gegen IT“-Bild. Die quantitativ stärkste Einzelquelle bleibt die McKinsey-Oxford-Studie von 2012 mit über 5.400 IT-Grossprojekten. Ihre Befunde: 45 Prozent Budget-Überschreitung, 56 Prozent weniger Nutzen als prognostiziert. McKinsey selbst ordnet rund die Hälfte der Kostenüberschreitungen dem Cluster Strategie und Stakeholder-Management zu, die andere Hälfte Skills und Projektmanagement. Business Alignment ist also geteilte Verantwortung, und der grössere Schadensanteil liegt in IT-Execution und Governance.
Die oft zitierten Standish-CHAOS-Zahlen sind methodisch fragwürdig. Magne Jörgensen wies 2006 nach, dass die berühmten Overrun-Werte massiv überzeichnet sind, weil Standish gezielt Problemprojekte auswählt. Ein verifizierbarer CHAOS Report für 2024 oder 2026 existiert öffentlich gar nicht. Die sauberste Gegenrechnung liefert Bent Flyvbjerg mit 5.392 IT-Projekten: durchschnittlich 27 Prozent Overrun, nicht 189. Aber jedes sechste Projekt explodiert (Power-Law-Verteilung). Der Treiber ist technologische Komplexität, nicht Nutzerwiderstand.
| Quelle | n | Methode | Kernbefund |
|---|---|---|---|
| McKinsey/Oxford 2012 | >5.400 Projekte | Datenbank + Survey | 56 % weniger Nutzen; rund 50 % Schaden durch Strategie/Stakeholder |
| Flyvbjerg et al. 2022 | 5.392 Projekte | Verteilungsanalyse | 27 % Ø-Overrun, Fat-Tail durch Architektur |
| McKinsey State of AI 2025 | 1.993 | Survey, 105 Länder | nur 6 % High Performer, Treiber Workflow-Redesign |
| BCG 2025 | 1.250 | Survey, 68 Länder | Erfolg zu 70 % Mensch/Prozess, 10 % Algorithmus |
| Bain Re-Org 2026 | ~1.000 | Survey | 88 % Leader optimistisch, nur 36 % der Mitarbeitenden |
Der konvergente Befund über alle methodisch starken Quellen: Was High Performer von Nachzüglern trennt, ist nicht der bessere Fachbereich. Es ist Architektur-Reife, Engineering-Kapazität und geteilte Verantwortung.
Welche vier Muster produziert die IT-Organisation selbst?
Vier Anti-Patterns tauchen in nahezu jeder Studie auf, und alle vier liegen im Verantwortungsbereich der IT.
Das erste ist Tool statt Wirkung. Technologie-Adoption ersetzt zunehmend Strategie. BCG zeigt, dass 74 Prozent der Unternehmen keinen greifbaren Wert aus ihren KI-Investitionen ziehen. Gartner prognostizierte, dass 30 Prozent der GenAI-Projekte nach dem Proof of Concept abgebrochen werden. Ein neues Tool löst kein Schnittstellen-Problem, es verschiebt es nur, die Schnittstelle, gemeint ist die Übergabekette zwischen IT und Fachbereich, wird im Glossar unter „Emails über den Zaun werfen“ ausgearbeitet.
Das zweite Muster sind falsche Erfolgsmetriken. Velocity, Lines of Code und gelöste Tickets messen Aktivität, nicht Wirkung. Das SPACE-Framework und die Forschung hinter dem Buch „Accelerate“ (über 23.000 Befragte) belegen: Die kausalen Treiber von Lieferfähigkeit sind technische und kulturelle Capabilities. Keine davon heisst „Fachbereich kooperiert besser“.
Das dritte ist Reorganisation ohne Diagnose. McKinsey zeigt, dass nur 21 bis 23 Prozent der Redesigns gelingen und 44 Prozent in der Umsetzung versanden. Die Bain-Re-Org-Studie 2026 liefert den schärfsten Beleg: 88 Prozent der Führungskräfte sind überzeugt, ihre Reorganisation werde liefern, aber nur 36 Prozent der Mitarbeitenden teilen diese Einschätzung. Eine Lücke von 52 Prozentpunkten.
Das vierte ist Agile-Theater. Werkzeuge werden eingeführt, der Kulturwandel bleibt aus. Das ist quantitativ das dominante Muster, nicht der unwillige Fachbereich.
Ist die „Blockade“ des Fachbereichs Ursache oder Symptom?
Hier liegt der eigentliche Denkfehler. Das am häufigsten validierte Modell der IT-Erfolgsforschung, das DeLone-McLean-Modell (über 12.000 Zitationen), beschreibt einen klaren kausalen Pfad: System-, Informations- und Servicequalität führen zu Nutzung und Nutzerzufriedenheit, und diese führen zum Nutzen. Nutzerzufriedenheit ist ein Mediator, kein Auslöser. Wer Misserfolg primär auf fehlende Akzeptanz im Fachbereich schiebt, dreht dieses Modell kausal um und macht die abhängige Variable zur Ursache.
Selbst die populäre Zahl, dass 56 Prozent der Projekte an Kommunikation scheitern, wird falsch zitiert. Das PMI hat 2013 (n = 742 Projektmanager plus Sponsoren und Business Owner) eine Risiko-Allokation gemessen, nicht eine Scheiterquote. Und Kommunikation zwischen IT und Business ist keine Einbahnstrasse, an deren Ende der Fachbereich steht.
In der Praxis heisst das: Wo der Fachbereich „blockiert“, reagiert er meist auf ein IT-internes Problem. Schlechte Bedienbarkeit, ungeklärte Anforderungen aufseiten der IT, ein Tool ohne erkennbaren Anwendungsfall. Forschung zu Nutzerwiderstand zeigt, dass dieser selten Sturheit ist. Er ist eine rationale Reaktion auf Wechselkosten, fehlenden erkennbaren Nutzen und mangelnde Unterstützung. Alle drei Faktoren liegen in der Hand der IT und des Managements, nicht beim Anwender.
An wie vielen Stellen verlieren Ihre Anforderungen Kontext?
Der WERT³ Quick-Check zeigt Ihnen in 10 Minuten, wo die Übergaben zwischen IT und Fachbereich Reibung erzeugen. Kostenlos, ohne Verkaufsgespräch.
→ WERT³ Quick-Check starten
Was zeigen die Post-Mortems bekannter Grossprojekte wirklich?
Die mediale Failure-Story ist fast immer eine Erzählung mit klaren Adressaten. Die offiziellen Untersuchungsberichte erzählen eine andere Geschichte, und diese Differenz ist selbst aufschlussreich.
Beim Cariad-Desaster von Volkswagen (über 14 Milliarden Euro Verlust) lautete das Narrativ jahrelang, die Marken Audi und Porsche hätten die zentrale Software blockiert. Die Insider-Analysen identifizieren stattdessen hausgemachte Geburtsfehler: tausende Stellen ohne Architektur besetzt, kein eigenes Budget, übernommene bereits gescheiterte Plattformen, 17 Status-Meetings pro Woche. Der Marken-Widerstand war real, aber Folge der fehlenden Lieferfähigkeit, nicht deren Ursache.
Bei HealthCare.gov in den USA (über 2 Milliarden Dollar) dokumentierte der Rechnungshof eindeutig ein Beschaffungs- und Projektmanagement-Versagen des Auftraggebers. 60 Verträge an 33 Anbieter, kein Generalintegrator, 18 schriftliche Warnungen vor dem Start ignoriert. Die Nutzer waren bereit. Das System war es nicht.
Über sieben grosse dokumentierte Fälle hinweg ist Fachbereichs-Beharren in genau einem (Lidl) ein klarer Mitfaktor. In sechs von sieben Fällen liegen die forensisch belegten Ursachen ausschliesslich bei Architektur, Governance, Beschaffung und Skill-Lücken auf Auftraggeber- und IT-Seite. Das Narrativ „Fachbereich blockiert“ übersteht die Obduktion nicht.
Was machen erfolgreiche IT-Organisationen anders, unabhängig vom Fachbereich?
Erfolg ist messbar, und er hängt nicht vom Verhalten des Fachbereichs ab. Der DORA-Report 2025 (rund 5.000 Fachkräfte) nennt als stärkste Treiber Nutzerzentrierung, stabile Prioritäten und tragfähige Plattformen. Die Unterschiede zwischen Spitzen- und Schlussteams sind dramatisch: um Faktoren schnellere Auslieferung, drastisch geringere Fehlerraten. Die Branche ist dabei kein Prädiktor. Schwache Teams gibt es in jedem Sektor. Erfolg ist also interne Praxis, nicht Marktlage.
Die zentrale Erkenntnis des DORA-Reports zur KI fasst das ganze Thema zusammen: Künstliche Intelligenz repariert kein Team, sie verstärkt das, was bereits da ist. Wer ohne saubere Architektur und ohne klare Abläufe KI einführt, beschleunigt das eigene Scheitern. Diese Verstärker-These, mit Faros-Telemetrie und MIT-NANDA-Befunden hinterlegt, behandeln wir vertieft im Blog „KI-Skepsis ist keine Verweigerung, sondern die Pflicht des IT-Leiters“.
Die MIT-CISR-Forschung um Jeanne Ross bringt es auf den Punkt. Erfolgreiche Transformation ist Business-Design durch die Unternehmensführung, nicht eine Vorleistung des Fachbereichs. Gartner zeigt das auch numerisch: CIOs, die digitale Verantwortung teilen („Franchisers“), erreichen 63 Prozent Erfolg, gegenüber 43 Prozent bei isoliert agierenden („Operators“). Über alle Erfolgsstudien hinweg findet sich keine einzige robuste Praktik, die „Fachbereich besser disziplinieren“ als Treiber ausweist.
Wie diagnostizieren IT-Leiter, bevor sie reorganisieren?
Die Analogie zur Medizin ist im Engineering-Diskurs explizit: Diagnose vor Therapie. Bevor eine IT-Organisation umbaut, sollte sie messen. Die Werkzeuge dafür sind reichlich vorhanden und überwiegend ungenutzt.
Der DORA Quick Check erlaubt eine strukturierte Selbsteinschätzung entlang validierter Metriken. Das SPACE-Framework schützt davor, eine einzelne Kennzahl zu optimieren und dabei Wirkung zu verlieren. Die Stakeholder-Interview-Muster von MIT CISR bringen Innovationsteams, Führung und Fachbereich an einen Tisch. Und das frei verfügbare Spotify Health Check Model gibt Teams ein einfaches Ampel-System für die eigene Gesundheit.
In meiner Beratungspraxis beobachte ich, dass dieser Schritt fast immer übersprungen wird. Bei einer staatlichen Organisation mit rund 1.000 Mitarbeitenden lag das Problem nicht in fehlendem Willen des Fachbereichs, sondern in Übergaben, die unterwegs Kontext verloren. Nach der Diagnose und der Reparatur der Schnittstelle bekam der Fachbereich schneller das, was er wirklich brauchte. Die Beschwerden gingen massiv zurück. Geändert wurde nicht das Tempo der IT, sondern die Art der Zusammenarbeit.
Zusammengefasst bedeutet das: Wer reorganisiert, ohne die eigene Baseline zu kennen, kuriert ein Symptom, das er nie diagnostiziert hat. Den übergreifenden Rahmen, warum die IT-Fachbereich-Schnittstelle das eigentliche Wirksamkeits-Thema ist und Reorganisationen sie selten reparieren, vertiefen wir unter IT-Wirksamkeit.
Wenn Sie das Schnittstellen-Problem an der Wurzel verstehen wollen, bevor Sie reorganisieren
„Emails über den Zaun werfen ist keine Kommunikation“ zeigt anhand von fünf Kräften, warum Projekte scheitern, obwohl alle ihren Job machen. Das Buch zur WERT³-Methodik. 318 Seiten, April 2026 erschienen.
→ Buch ansehen
Häufige Fragen
Liegt es nie am Fachbereich?
Doch, manchmal trägt er bei. Im dokumentierten Lidl-Fall war Beharren auf einem Sonderprozess ein Mitfaktor. Aber in sechs von sieben grossen Post-Mortems liegen die belegten Ursachen bei Architektur, Governance und Beschaffung auf der IT- und Auftraggeber-Seite, nicht beim Anwender.
Was sind die häufigsten Ursachen für gescheiterte IT-Transformationen?
Empirisch belastbar sind vier Muster: Technologie ohne Strategie, falsche Erfolgsmetriken, Reorganisation ohne Diagnose und Werkzeug-Einführung ohne Kulturwandel. Hinzu kommt geteiltes Versagen an der Schnittstelle zwischen IT und Business. Nutzerwiderstand ist meist Symptom, nicht Ursache.
Warum ist das Bild vom blockierenden Fachbereich so verbreitet?
Weil die meisten Zahlen aus CIO-Surveys stammen. Wer IT-Verantwortliche nach Misserfolgsgründen fragt, erhält durch den Self-Serving-Bias eine vorhersehbare Antwort. Unabhängige Messungen über Telemetrie oder gleichgewichtete Befragungen zeichnen ein anderes Bild.
Welche Kennzahlen sind in der IT-Transformation gefährlich?
Velocity, Lines of Code und Ticketzahlen messen Aktivität statt Wirkung. Sie erzeugen Fehlanreize und lassen sich leicht manipulieren. Aussagekräftiger sind ergebnisbezogene Metriken wie tatsächliche Nutzung, Fehlerraten und die Zufriedenheit des Fachbereichs mit der gelieferten Lösung.
Wie finden IT-Leiter heraus, wo ihre Zusammenarbeit hakt?
Vor jeder Reorganisation hilft eine strukturierte Diagnose entlang erprobter Werkzeuge wie dem DORA Quick Check oder Stakeholder-Interviews. Wer schnell einen ersten Eindruck der eigenen Schnittstelle will, findet im kostenlosen WERT³ Quick-Check einen Einstieg.
Quellen
| Quelle | n | Datum | URL |
|---|---|---|---|
| McKinsey/Oxford „Delivering large-scale IT projects on time, on budget, and on value“ | >5.400 IT-Grossprojekte | 2012 (weiterhin gültiger Klassiker) | mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value |
| Flyvbjerg et al. „Empirical Reality of IT Project Cost Overruns“ | 5.392 IT-Projekte | 2022 | bent-flyvbjerg.com |
| Standish Group CHAOS-Critique (Jörgensen 2006) | — | 2006 (methodische Standish-Korrektur) | simula.no |
| McKinsey „The State of AI 2025″ | 1.993, 105 Länder | 25. Jun – 29. Jul 2025 | mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai |
| BCG „The Widening AI Value Gap: Build for the Future 2025″ | 1.250 Senior Executives, 68 Länder | 30. Sep 2025 | media-publications.bcg.com/The-Widening-AI-Value-Gap-Sept-2025.pdf |
| DORA Report 2025, Google Cloud | ~5.000 Tech-Professionals | Sep 2025 | dora.dev/dora-report-2025/ |
| Gartner CIO Survey 2024 / 2025 | 3.186 CIOs + 1.126 Führungskräfte / 506 | Okt 2024 / Mai 2025 | gartner.com/en/newsroom/press-releases/2024-10-22-gartner-survey-reveals-that-only-48-percent-of-digital-initiatives-meet-or-exceed-their-business-outcome-targets |
| Gartner „Franchisers vs. Operators“ CIO-Studie | 2.400 CIOs | Okt 2023 | gartner.com/en/newsroom/press-releases/2023-10-17-gartner-survey-of-over-2400-cios-reveals-that-45-percent-of-cios-are-driving-a-shift-to-co-ownership-of-digital-leadership |
| Bain Re-Org Studie | ~1.000 Leader / Mitarbeitende | 2026 | bain.com/about/media-center/press-releases/2026/88-of-leaders-are-confident-their-reorganization-will-deliver–only-36-of-employees-agree-bain–co-research/ |
| IBM CEO Study 2025 | 2.000 CEOs, 33 Länder | 2025 | ibm.com/thought-leadership/institute-business-value/en-us/blog/2025-ceo-blog-article |
| PMI Pulse of the Profession. Communications | 742 Projektmanager + Sponsors + Business Owner | 2013 (oft falsch zitiert) | pmi.org/learning/library/en-2013-pulse-high-cost-low-performance-13512 |
| DeLone & McLean IS Success Model (Update 2003 + Reviews) | 12.000+ Zitationen | 2003ff | aisel.aisnet.org |
| Forsgren, Humble, Kim „Accelerate“ + SPACE-Framework | 23.000+ Befragte über DORA-Wellen | 2018 + Updates 2021/2023 | itrevolution.com/product/accelerate/ |
| MIT CISR. Jeanne Ross et al. „Designed for Digital“ | Working Papers + Sloan-Management-Review-Beiträge | 2017–2024 | cisr.mit.edu |
| Spotify Health Check Model | frei verfügbares Team-Diagnose-Modell | seit 2014, weiter gepflegt | engineering.atspotify.com/2014/09/squad-health-check-model |