Strukturelle Ursachen des Scheiterns von IT-Projekten: Wiederkehrende Management-Ignoranz und ihre Kosten

baeba · 2025-11-26T09:56:15+09:00

Zusammenfassender Überblick: Kernthema: Das Scheitern von IT-Projekten geht nicht auf technische Herausforderungen zurück, sondern auf die „vorsätzliche Ignoranz“ des Managements und die arrogante Weigerung, aus vergangenen Fehlschlägen zu lernen. Wichtige Zahlen: In den vergangenen 20 Jahren haben sich die globalen IT-Ausgaben verdreifacht (auf 5,6 Billionen US-Dollar), doch die Erfolgsquote stagniert; allein für die Wartung von Legacy-Systemen werden 75 % des Budgets verbraucht. Zentrale Beispiele: Das umfassende Managementversagen beim kanadischen Phoenix-System und die unethische Vertuschung im britischen Horizon-Skandal sind keine „Fehlgriffe (Blunder)“, sondern „administratives Böses (Administrative Evil)“. 1. Einleitung: Keine sinkende Ausfallquote trotz massiver Investitionen Stagnierende Effizienz trotz Investitionen: Seit 2005 sind die weltweiten IT-Ausgaben von 1,7 Billionen US-Dollar auf 5,6 Billionen US-Dollar im Jahr 2025 und damit auf mehr als das Dreifache gestiegen. Trotz dieses enormen Mitteleinsatzes zeigt die Erfolgsquote von Softwareprojekten in den vergangenen 20 Jahren keine klare Verbesserung. Warnung vor Illusionen rund um AI: Viele Führungskräfte erwarten, dass AI-Tools oder Coding-Assistenten wie Copilot große Projekte erfolgreich machen werden, doch der Autor steht dem skeptisch gegenüber. AI kann weder die Komplexität des Systems Engineerings noch finanzielle Trade-offs und vor allem nicht die „Organisationspolitik (Organizational Politics)“ innerhalb eines Projekts lösen. Universelles Scheitern: Softwareversagen tritt unterschiedslos auf – unabhängig von Land, Unternehmensgröße oder Gewinnorientierung – und beruht nicht bloß auf technischen Fehlern, sondern auf „mangelnder menschlicher Vorstellungskraft“ und „unrealistischen Zielen“. 2. Hauptteil: Vertiefte Analyse der Arten und Ursachen des Scheiterns 2.1. Sich wiederholende „Fehlgriffe (Blunder)“ und Lernverweigerung Unterscheidung zwischen Scheitern und Fehlgriff: Scheitern als Form der „schöpferischen Zerstörung (Creative Destruction)“, das beim Ausloten technischer Grenzen entsteht, sollte willkommen sein. Die meisten IT-Fehlschläge sind jedoch nichts weiter als „dumme Fehlgriffe (Blunder)“, bei denen Ursachen wiederholt werden, die seit Jahrzehnten dokumentiert sind (fehlendes Risikomanagement, Unterschätzung von Komplexität usw.). Arroganz des Managements: Projektverantwortliche behaupten oft, ihr Projekt sei „besonders und einzigartig“, und neigen dazu, frühere Fehlschläge oder Daten zu ignorieren. Das ist nicht bloß Unwissen, sondern „vorsätzliche Ignoranz (Willful Ignorance)“, also das absichtliche Wegsehen bei Warnsignalen. Die Falle der Legacy-Systeme: Organisationen in den USA geben jährlich mehr als 520 Milliarden US-Dollar allein für die Wartung von Legacy-Systemen aus, was 70 bis 75 % des gesamten IT-Budgets entspricht. Aus Angst vor dem Scheitern eines Austauschs wird die Modernisierung hinausgezögert, bis das System physisch zusammenbricht (z. B. das Mainframe-System der Kraftfahrzeugbehörde von Louisiana) oder jede Kosteneffizienz verloren geht. 2.2. Details zentraler Fehlschläge und ihre Folgewirkungen Kanadas Phoenix-Gehaltsabrechnungssystem: Ursprüngliche Fehlentscheidung: Bei der Einführung einer Standardlösung (PeopleSoft) wurde versucht, 80.000 Gehaltsregeln und 105 Tarifverträge anzupassen. Der Preis von Budgetkürzungen: Um das Projekt mit weniger als 60 % des von den Anbietern vorgeschlagenen Budgets umzusetzen, wurden zentrale Payroll-Funktionen gestrichen, Tests reduziert und notwendige Pilot-Tests ausgelassen. Ergebnis: Kurz nach dem Start im Jahr 2016 brach das System zusammen. Falsche Lohn- und Gehaltszahlungen verursachten finanzielle Notlagen bei Beschäftigten (teilweise wurde dies als Mitursache für Suizide genannt). Kosten: Das ursprüngliche Budget lag bei 310 Millionen kanadischen Dollar, doch die Wiederherstellungs- und Behebungskosten übersteigen inzwischen 5,1 Milliarden kanadische Dollar (rund 3,6 Milliarden US-Dollar). Der britische Post-Horizon-Skandal: Technischer Defekt: Ein Middleware-Bug im von Fujitsu bereitgestellten System verursachte Fehler bei finanziellen Abweichungen. Organisierte Vertuschung: Das Management wusste von den Softwarefehlern, vertuschte sie jedoch und klagte stattdessen 3.500 Poststellenleiter wegen Unterschlagung und Diebstahls an. 900 wurden schuldig gesprochen und inhaftiert. Gesellschaftliche Kosten: Es kam zu Insolvenzen, Scheidungen, Haftstrafen und Suiziden unter den Betroffenen. Der Fall gilt als schlimmstes IT-Versagen und Justizskandal der britischen Geschichte. 2.3. Automatisierte Entscheidungen und „administratives Böses“ Die Gewalt von Algorithmen: Die Systeme MiDAS in Michigan, USA (zur Aufdeckung von Betrug bei Arbeitslosenleistungen), und Robodebt in Australien (zur Aufdeckung von Sozialleistungsbetrug) trafen Entscheidungen allein auf Basis von Algorithmen – ohne menschliche Aufsicht. Zehntausende unschuldige Bürger wurden als Kriminelle behandelt, doch selbst nachdem die Systemfehler nachgewiesen waren, verweigerten Bürokratien Entschädigungen oder wichen Verantwortung aus. Risiken bei der Einführung von AI: Dieses „administrative Böse (Administrative Evil)“ wird sich verschärfen, je tiefer AI in öffentliche Infrastrukturen eingreift. Die EU hat zwar ein „Recht auf Erklärung“ eingeführt, doch weltweit besteht dringender Bedarf an Transparenz und klarer Verantwortlichkeit für Algorithmen. 3. Fazit: Lösungsansätze und Aufgaben für die IT-Community Methoden wie Agile/DevOps sind kein Generalschlüssel: Wie Berichte zeigen, wonach die Scheiterquote von Agile-Projekten bis zu 65 % erreichen kann, garantiert die Methode selbst keinen Erfolg. Ohne konsistente Führung und organisatorische Disziplin scheitert jede neue Methodik. Ehrliche Risikobewertung und ethische Verantwortung: Vor Projektbeginn sollte eine ehrliche Gap Analysis vorangestellt werden: „Was wissen wir, und was wissen wir nicht?“ Das Konzept einer „menschenzentrierten AI (Human-centered AI)“ sollte auf alle IT-Projekte ausgeweitet werden, sodass emotionale und finanzielle Schäden für Endnutzer durch Systemversagen in die Kosten-Nutzen-Analyse einfließen. Appell an einen Einstellungswandel im Management: Software ist ihrem Wesen nach fragil und komplex. Führungskräfte sollten Softwareentwicklung nicht nur als Budgetverantwortliche, sondern auch als diejenigen respektieren und unterstützen, die im Fall des Scheiterns Verantwortung tragen. Nur wenn die sich wiederholenden Fehler gestoppt werden, kann die IT-Branche aus ihrer „Krise (Crisis)“ herausfinden.

(spectrum.ieee.org)

3 Punkte von baeba 2025-11-26 | 1 Kommentare | Auf WhatsApp teilen

Zusammenfassender Überblick:
- Kernthema: Das Scheitern von IT-Projekten geht nicht auf technische Herausforderungen zurück, sondern auf die „vorsätzliche Ignoranz“ des Managements und die arrogante Weigerung, aus vergangenen Fehlschlägen zu lernen.
- Wichtige Zahlen: In den vergangenen 20 Jahren haben sich die globalen IT-Ausgaben verdreifacht (auf 5,6 Billionen US-Dollar), doch die Erfolgsquote stagniert; allein für die Wartung von Legacy-Systemen werden 75 % des Budgets verbraucht.
- Zentrale Beispiele: Das umfassende Managementversagen beim kanadischen Phoenix-System und die unethische Vertuschung im britischen Horizon-Skandal sind keine „Fehlgriffe (Blunder)“, sondern „administratives Böses (Administrative Evil)“.

1. Einleitung: Keine sinkende Ausfallquote trotz massiver Investitionen

Stagnierende Effizienz trotz Investitionen:
- Seit 2005 sind die weltweiten IT-Ausgaben von 1,7 Billionen US-Dollar auf 5,6 Billionen US-Dollar im Jahr 2025 und damit auf mehr als das Dreifache gestiegen.
- Trotz dieses enormen Mitteleinsatzes zeigt die Erfolgsquote von Softwareprojekten in den vergangenen 20 Jahren keine klare Verbesserung.
Warnung vor Illusionen rund um AI:
- Viele Führungskräfte erwarten, dass AI-Tools oder Coding-Assistenten wie Copilot große Projekte erfolgreich machen werden, doch der Autor steht dem skeptisch gegenüber.
- AI kann weder die Komplexität des Systems Engineerings noch finanzielle Trade-offs und vor allem nicht die „Organisationspolitik (Organizational Politics)“ innerhalb eines Projekts lösen.
Universelles Scheitern:
- Softwareversagen tritt unterschiedslos auf – unabhängig von Land, Unternehmensgröße oder Gewinnorientierung – und beruht nicht bloß auf technischen Fehlern, sondern auf „mangelnder menschlicher Vorstellungskraft“ und „unrealistischen Zielen“.

2. Hauptteil: Vertiefte Analyse der Arten und Ursachen des Scheiterns

2.1. Sich wiederholende „Fehlgriffe (Blunder)“ und Lernverweigerung

Unterscheidung zwischen Scheitern und Fehlgriff:
- Scheitern als Form der „schöpferischen Zerstörung (Creative Destruction)“, das beim Ausloten technischer Grenzen entsteht, sollte willkommen sein.
- Die meisten IT-Fehlschläge sind jedoch nichts weiter als „dumme Fehlgriffe (Blunder)“, bei denen Ursachen wiederholt werden, die seit Jahrzehnten dokumentiert sind (fehlendes Risikomanagement, Unterschätzung von Komplexität usw.).
Arroganz des Managements:
- Projektverantwortliche behaupten oft, ihr Projekt sei „besonders und einzigartig“, und neigen dazu, frühere Fehlschläge oder Daten zu ignorieren.
- Das ist nicht bloß Unwissen, sondern „vorsätzliche Ignoranz (Willful Ignorance)“, also das absichtliche Wegsehen bei Warnsignalen.
Die Falle der Legacy-Systeme:
- Organisationen in den USA geben jährlich mehr als 520 Milliarden US-Dollar allein für die Wartung von Legacy-Systemen aus, was 70 bis 75 % des gesamten IT-Budgets entspricht.
- Aus Angst vor dem Scheitern eines Austauschs wird die Modernisierung hinausgezögert, bis das System physisch zusammenbricht (z. B. das Mainframe-System der Kraftfahrzeugbehörde von Louisiana) oder jede Kosteneffizienz verloren geht.

2.2. Details zentraler Fehlschläge und ihre Folgewirkungen

Kanadas Phoenix-Gehaltsabrechnungssystem:
- Ursprüngliche Fehlentscheidung: Bei der Einführung einer Standardlösung (PeopleSoft) wurde versucht, 80.000 Gehaltsregeln und 105 Tarifverträge anzupassen.
- Der Preis von Budgetkürzungen: Um das Projekt mit weniger als 60 % des von den Anbietern vorgeschlagenen Budgets umzusetzen, wurden zentrale Payroll-Funktionen gestrichen, Tests reduziert und notwendige Pilot-Tests ausgelassen.
- Ergebnis: Kurz nach dem Start im Jahr 2016 brach das System zusammen. Falsche Lohn- und Gehaltszahlungen verursachten finanzielle Notlagen bei Beschäftigten (teilweise wurde dies als Mitursache für Suizide genannt).
- Kosten: Das ursprüngliche Budget lag bei 310 Millionen kanadischen Dollar, doch die Wiederherstellungs- und Behebungskosten übersteigen inzwischen 5,1 Milliarden kanadische Dollar (rund 3,6 Milliarden US-Dollar).
Der britische Post-Horizon-Skandal:
- Technischer Defekt: Ein Middleware-Bug im von Fujitsu bereitgestellten System verursachte Fehler bei finanziellen Abweichungen.
- Organisierte Vertuschung: Das Management wusste von den Softwarefehlern, vertuschte sie jedoch und klagte stattdessen 3.500 Poststellenleiter wegen Unterschlagung und Diebstahls an. 900 wurden schuldig gesprochen und inhaftiert.
- Gesellschaftliche Kosten: Es kam zu Insolvenzen, Scheidungen, Haftstrafen und Suiziden unter den Betroffenen. Der Fall gilt als schlimmstes IT-Versagen und Justizskandal der britischen Geschichte.

2.3. Automatisierte Entscheidungen und „administratives Böses“

Die Gewalt von Algorithmen:
- Die Systeme MiDAS in Michigan, USA (zur Aufdeckung von Betrug bei Arbeitslosenleistungen), und Robodebt in Australien (zur Aufdeckung von Sozialleistungsbetrug) trafen Entscheidungen allein auf Basis von Algorithmen – ohne menschliche Aufsicht.
- Zehntausende unschuldige Bürger wurden als Kriminelle behandelt, doch selbst nachdem die Systemfehler nachgewiesen waren, verweigerten Bürokratien Entschädigungen oder wichen Verantwortung aus.
Risiken bei der Einführung von AI:
- Dieses „administrative Böse (Administrative Evil)“ wird sich verschärfen, je tiefer AI in öffentliche Infrastrukturen eingreift.
- Die EU hat zwar ein „Recht auf Erklärung“ eingeführt, doch weltweit besteht dringender Bedarf an Transparenz und klarer Verantwortlichkeit für Algorithmen.

3. Fazit: Lösungsansätze und Aufgaben für die IT-Community

Methoden wie Agile/DevOps sind kein Generalschlüssel:
- Wie Berichte zeigen, wonach die Scheiterquote von Agile-Projekten bis zu 65 % erreichen kann, garantiert die Methode selbst keinen Erfolg. Ohne konsistente Führung und organisatorische Disziplin scheitert jede neue Methodik.
Ehrliche Risikobewertung und ethische Verantwortung:
- Vor Projektbeginn sollte eine ehrliche Gap Analysis vorangestellt werden: „Was wissen wir, und was wissen wir nicht?“
- Das Konzept einer „menschenzentrierten AI (Human-centered AI)“ sollte auf alle IT-Projekte ausgeweitet werden, sodass emotionale und finanzielle Schäden für Endnutzer durch Systemversagen in die Kosten-Nutzen-Analyse einfließen.
Appell an einen Einstellungswandel im Management:
- Software ist ihrem Wesen nach fragil und komplex. Führungskräfte sollten Softwareentwicklung nicht nur als Budgetverantwortliche, sondern auch als diejenigen respektieren und unterstützen, die im Fall des Scheiterns Verantwortung tragen.
- Nur wenn die sich wiederholenden Fehler gestoppt werden, kann die IT-Branche aus ihrer „Krise (Crisis)“ herausfinden.

1 Kommentare

baeba 2025-11-26

Zusammenfassung der Reaktionen in den Hacker-News-Kommentaren

1. Fehlende schrittweise Auslieferung und Skalierungsstrategie (Start Small)

Das zwangsläufige Scheitern des „Big Bang“-Ansatzes: Ein Projekt auf nationaler Ebene auf einmal auszurollen, ist ein Himmelfahrtskommando. Unverzichtbar ist eine Strategie, die in kleinen Einheiten (Dorf → Stadt → Land) sequenziell validiert und dann erweitert wird.
Unterschied zwischen Produkt und System: Anders als ein einzelnes Produkt wie WhatsApp müssen komplexe Enterprise-Systeme von Anfang an enorme Skalierung bewältigen, daher braucht es einen anderen Ansatz.
Kernlösung: Das Prinzip „klein bauen und nach der Validierung Funktionen hinzufügen“ wird ignoriert.

2. Inkompetenz des Managements und Vermeidung von Verantwortung (Management Issues)

Machtstruktur ohne Verantwortung: Kritisiert wird die widersprüchliche Struktur, in der Entwickler Projektfehler mit Überstunden ausbaden, während das Management als Entscheidungsträger keine Verantwortung übernimmt oder sogar Boni einstreicht.
Mangelndes technisches Verständnis: Unrealistische Zeitpläne, die technische Schwierigkeit ignorieren, und eine top-down geprägte Kultur, die „schlechte Nachrichten“ nicht hören will, blockieren die Problemlösung.
Politische Entscheidungen: Lösungen werden oft eher durch interne Politik oder Beziehungen zu externen Vendoren (z. B. Kickbacks) bestimmt als durch technische Eignung.

3. Unkontrollierbare Anforderungen und Komplexität (Complexity & Scope Creep)

Fehlende vorgelagerte Vereinfachung von Prozessen: Wie im Fall des Phoenix Project ist der Versuch, 80.000 Gehaltsregeln unverändert zu digitalisieren, eine grundlegende Ursache. Chaotische Offline-Prozesse erzeugen nur chaotische digitale Systeme.
Häufige Anforderungsänderungen: Scope Creep durch Launen des Managements oder der Kunden während des Projektverlaufs zieht Projekte in den Sumpf.

4. Entwicklerkultur und falsche Anreize (Developer Culture)

Resume-Driven Development (RDD): Statt auf Projekterfolg zu setzen, werden die neuesten Trendtechnologien (Frameworks), die beim nächsten Jobwechsel nützen, mit Gewalt eingeführt und erhöhen die technische Schuld.
Unterbrochener Lernprozess: Eine Kultur häufiger Jobwechsel im 2- bis 3-Jahres-Rhythmus verhindert, dass Entwickler das langfristige Scheitern ihres eigenen Codes erleben und daraus Lehren ziehen.
Fixierung auf Neuerfindung: Statt bewährte bestehende Lösungen zu nutzen, werden aus Gründen der Selbstverwirklichung ineffizient ganze Codesbasen von Grund auf neu geschrieben.

5. Die Besonderheit des Software Engineering (Engineering Nature)

Fehlende physische Beschränkungen: Anders als bei Bauwesen oder Hardware gibt es in Software keine physischen Grenzen, wodurch unbegrenzte Komplexität zugelassen wird und Kontrollverlust entsteht.
Fehlendes Lernen aus der Vergangenheit: Andere Ingenieurdisziplinen analysieren Fehlschläge (z. B. Brückeneinstürze) gründlich und ziehen Lehren daraus, während die Softwarebranche mit einer „diesmal ist es anders“-Mentalität vergangene Fehler im Stil von YOLO wiederholt.