Große Softwareprojekte scheitern trotz Billioneninvestitionen weiterhin
(spectrum.ieee.org)- Obwohl sich die weltweiten IT-Ausgaben seit 2005 mehr als verdreifacht haben, hat sich die Erfolgsquote großer Softwareprojekte kaum verbessert
- Beim kanadischen Phoenix-Gehaltsabrechnungssystem, beim britischen Post Office Horizon sowie bei Sozial- und Verwaltungssystemen in den USA und Australien wiederholen sich Management-, Organisations- und ethische Fehlleistungen
- AI-Tools oder Copilots können diese Probleme nicht lösen; mangelnde menschliche Vorstellungskraft, unrealistische Ziele und gescheitertes Risikomanagement bleiben die Hauptursachen
- Kosten für die Wartung von Legacy-Systemen verschlingen 70–75 % der IT-Budgets, und auch die Einführung von Agile und DevOps scheitert ohne organisatorische Führung und Kulturwandel häufig
- Wiederholte Managementfehler und Verantwortungsvermeidung treiben die gesellschaftlichen Kosten in die Höhe; Transparenz, Ethik und menschenzentriertes Systemdesign werden als zentrale Aufgaben genannt
Das anhaltende Problem des Softwareversagens
- In den vergangenen 20 Jahren stiegen die IT-Ausgaben von 1,7 Billionen US-Dollar auf 5,6 Billionen US-Dollar, doch die Erfolgsquote von Software stagniert
- Scheitern tritt unabhängig von Land, Branche oder Organisationsform auf
- Die gesellschaftlichen und wirtschaftlichen Kosten des Scheiterns steigen kontinuierlich
- Es wird ausdrücklich auf die Grenzen von AI bei der Lösung von Managementproblemen hingewiesen
- Die komplexen Stakeholder-Strukturen und politischen Faktoren großer Projekte lassen sich von AI nur schwer steuern
- IT-Projekte sind bereits heute von vielen irrationalen Entscheidungen geprägt, sodass es AI an geeigneten Beispielen zum Lernen fehlt
- Ursachen des Scheiterns sind mangelnde menschliche Vorstellungskraft, unklare Ziele, fehlendes Komplexitätsmanagement und mangelnde Risikokontrolle
- Seit Jahrzehnten wiederholen sich dieselben Faktoren, wodurch ein Zustand des „failure déjà vu“ anhält
Kanadas Phoenix-Gehaltsabrechnungssystem
- Das 2016 eingeführte Phoenix-System im Umfang von 310 Millionen CA$ scheiterte beim Versuch, 80.000 Gehaltsregeln und 105 Tarifverträge zu integrieren
- Um Budget zu sparen, wurden Tests und Pilotverfahren gekürzt und zentrale Funktionen entfernt; das Verfahren wurde überhastet vorangetrieben
- In der Folge erlebten innerhalb von 9 Jahren 70 % von 430.000 Beschäftigten Gehaltsfehler
- Stand März 2025 waren 349.000 Fehlerfälle ungelöst, mehr als die Hälfte davon mit über einem Jahr Verzögerung
- Es wurden sogar Suizidfälle unter Beschäftigten gemeldet
- Die Gesamtkosten liegen bei mehr als 5,1 Milliarden CA$; der Rechnungshof sprach von einem „unerklärlichen Versagen bei Projektmanagement und Aufsicht“
Das britische Post Office Horizon-System
- Das 1999 eingeführte Horizon-POS-System von Fujitsu verbarg interne Fehler und führte dazu, dass 3.500 Filialleiter:innen wegen falscher Buchführung und Betrugs angeklagt wurden
- 900 Schuldsprüche, 236 Inhaftierungen, mehr als 13 Suizide
- Technische, managementbezogene, rechtliche und ethische Fehlleistungen wirkten hier zusammen
- Fehleranfällige Middleware, unkontrollierte Scope-Erweiterungen, unzureichende Tests und Personalmangel
- Das Management begegnete Hinweisgebern feindselig, hielt Beweise zurück und betrieb systematische Vertuschung
- Auch Austauschversuche in den Jahren 2016 und 2021 scheiterten; Horizon ist weiterhin im Einsatz
- Das Budget für ein neues System liegt bei 410 Millionen £, eine Entscheidung ist für Juli 2026 vorgesehen
Weitere große Fehlschläge
- Minnesota MNLARS: 2016 gestartet, 2019 eingestellt, Kosten 100 Millionen US-Dollar
- Australien Modernising Business Registers: Budget von 480 Millionen AU$ auf 2,8 Milliarden AU$ gestiegen, 2022 eingestellt
- Fahrzeugzulassungssystem in Louisiana: Wiederholte Ausfälle eines 50 Jahre alten Mainframes führten 2025 zur Ausrufung des Notstands
- Jaguar Land Rover: 2025 legte ein Cyberangriff den weltweiten Betrieb für mehr als einen Monat lahm, Schaden 1,2–1,9 Milliarden US-Dollar
- Lidl ERP: Nach dem Scheitern eines SAP-basierten ERP-Projekts im Wert von 500 Millionen € Rückkehr zu einem eigenen System (2017)
- Boeing 737 Max: 346 Todesopfer durch Konstruktionsfehler im MCAS, Gesamtkosten auf 74 Milliarden US-Dollar geschätzt
- F-35 Block-4-Upgrade: Zeitplan 5 Jahre verspätet, Kosten von 10,5 auf 16,5 Milliarden US-Dollar gestiegen
Die wirtschaftlichen Kosten des Scheiterns
- In den USA beliefen sich die Kosten von Softwarefehlschlägen 2022 auf 1,81 Billionen US-Dollar, davon 260 Milliarden US-Dollar für gescheiterte Entwicklung
- Die Gesamtsumme ist höher als das Verteidigungsbudget (778 Milliarden US-Dollar)
- Wartungskosten für Legacy-Systeme betragen jährlich 520 Milliarden US-Dollar und machen 70–75 % der IT-Budgets aus
- Hohe Austauschkosten und hohe Ausfallrisiken verzögern die Erneuerung
- NTT-DATA-Report 2024: 80 % der Organisationen sagen, dass veraltete Technologie Innovationen behindert
- Die meisten Führungskräfte sehen Legacy-Infrastruktur als Hindernis für schnelle Marktreaktionen
Die Grenzen von Agile und DevOps
- Trotz der Verbreitung iterativer und inkrementeller Entwicklung bleibt die Fehlerrate hoch
- Einige Berichte nennen Ausfallquoten von 65 % bei Agile-Projekten und bis zu 90 % bei DevOps
- Für eine erfolgreiche Einführung braucht es Führung, organisatorische Disziplin, Training und kulturellen Wandel
- Doch die meisten Organisationen schaffen es nicht, dies dauerhaft aufrechtzuerhalten
Wiederkehrende Managementfehler und fehlendes Lernen
- IT-Projektmanager sagen oft: „Unser Projekt ist anders“ und ignorieren damit die Lehren aus früheren Fehlschlägen
- Die kanadische Regierung wiederholte im Phoenix-Projekt die Lehren aus dem ersten Scheitern eines Gehaltsabrechnungssystems von 1995
- Die meisten Fehlschläge entstehen nicht aus innovativen Experimenten, sondern aus gewöhnlichen Managementfehlern
- Es ist weniger „schöpferische Zerstörung“ als vielmehr „finanzielle Zerstörung“
- Beispiele für gescheiterte AI-basierte Verwaltungssysteme
- Das US-amerikanische MiDAS-Arbeitslosengeldsystem und Australiens Centrelink Robodebt beschuldigten mit fehlerhaften Algorithmen Hunderttausende zu Unrecht
- Regierungen zeigten sich zurückhaltend bei Fehleranerkennung und Entschädigung
Verantwortung, Ethik und Transparenz sind notwendig
- Intransparente Entscheidungen in AI-gestützten Systemen wecken Sorgen über Eingriffe in die Rechte von Bürger:innen
- Die EU garantiert rechtlich ein „Recht auf Erklärung bei algorithmischen Entscheidungen“
- Weltweit wird gefordert, Transparenz und Rechenschaftspflicht automatisierter Systeme als Menschenrecht zu etablieren
- Es gibt Diskussionen über Softwarehaftungsgesetze und Berufslizenzen für Fachleute, doch ihre Umsetzbarkeit gilt als gering
- Eine realistische Alternative ist die Stärkung von Ehrlichkeit, skeptischem Denken und ethischem Urteilsvermögen im Management
- Risiken müssen klar erkannt und überzogene Versprechen von Anbietern kritisch hinterfragt werden
- Es wird betont, auf alle IT-Systeme einschließlich AI die Prinzipien menschenzentrierten Designs anzuwenden
Fazit: Zeit, die Wiederholung derselben Fehler zu beenden
- Softwareentwicklung ist ihrem Wesen nach komplex und anfällig, und kleine Fehler können große Folgen haben
- Für erfolgreiche Projekte sind ausreichende Ressourcen, Führung und Verantwortlichkeit unverzichtbar
- Bei der Kostenbewertung müssen auch die emotionalen und wirtschaftlichen Schäden für Nutzer:innen berücksichtigt werden
- Seit der „Softwarekrise“ von 1968 werden seit mehr als 50 Jahren dieselben Fehler wiederholt
- „Macht neue Fehler.“
„Jeder kann irren, aber nur ein Narr beharrt auf seinem Irrtum.“ – der römische Redner Cicero
5 Kommentare
Hacker-News-Kommentare
Ich fand die am Ende des Artikels vorgeschlagene Lösung etwas unbefriedigend.
Die eigentliche Lösung ist meiner Meinung nach, klein anzufangen und unter realen Betriebsbedingungen zu validieren.
Wenn man zum Beispiel ein landesweites Gehaltssystem bauen will, sollte man es zuerst in einer kleinen Stadt mit 50 Beschäftigten testen, Bugs beheben und es dann schrittweise auf größere Städte ausweiten.
Es gibt keinen Softwareentwicklungsprozess, bei dem man Probleme im kleinen Maßstab nicht löst und dann direkt auf einmal landesweit ausrollt.
Das Transaktionsvolumen war gering, sodass wir Probleme notfalls manuell ausgleichen konnten, und wir konnten PCI-Vorgaben vermeiden.
Weil wir vor dem Rollout in echten Filialen auf diese Weise getestet haben, konnten wir den Termin ohne größere Zwischenfälle einhalten.
Hätten wir es von Anfang an in Kundenfilialen ausgerollt, hätte es wegen Fehlern bei der Steuerberechnung oder Performance-Problemen großes Chaos gegeben.
Schrittweises Skalieren führt zum Aufbau technischer Schulden, und irgendwann ist niemand mehr vom Kern der Codebasis wirklich überzeugt, sodass eine Angst vor dem Rewrite entsteht.
Selbst bei einem einfachen Produkt wie WhatsApp braucht es von Anfang an ein Engineering-Design, das große Skalierbarkeit berücksichtigt.
In kleinen erfolgreichen Systemen entsteht so jemand leichter, und dadurch kann das System mit dem Vertrauen von Nutzern und Entwicklern schrittweise wachsen.
Da große Projekte eine hohe Ausfallwahrscheinlichkeit haben, sollte man nach dem Vorsorgeprinzip (Precautionary Principle) klein anfangen.
Dieser Zyklus ist die Grundlage jedes Projekts.
Man soll klein anfangen und nach der Modularisierung skalieren. Das Beispiel von Teslas Megafactory fand ich besonders eindrucksvoll.
Was ich beim Studium der Technikgeschichte gespürt habe: Die Hardware-Branche lernt aus früheren Erfolgen und Misserfolgen, aber die Software-Branche tut das nicht.
Die meisten Entwickler lernen nicht, indem sie alte Systeme zerlegen, und jede Generation durchlebt dieselben Probleme erneut.
In Retrospektiven wird dann ständig nur gefragt: „Was sollten die Entwickler nächstes Mal anders machen?“, während Manager keinerlei Verantwortung übernehmen.
Am Ende wiederholen sich dieselben Probleme, und die Last wird auf die Entwickler abgewälzt.
Frühere Generationen lösten Probleme im unteren Teil des Stacks, heute will man sie nur noch oben lösen.
Dadurch wächst ein Turm der Abstraktionen, Ressourcenverbrauch steigt, aber die Funktionalität bleibt ähnlich.
Jetzt beginnt eine Zeit, in der noch eine weitere Softwareschicht auf AI-Modelle gesetzt wird.
Erfahrung und Persönlichkeit sind beide wichtig, und ein kleines Ego sowie lösungsorientiertes Denken sind unverzichtbar.
Die meisten unterschätzen die Komplexität von Projekten.
Während meines Masterstudiums habe ich eine Woche lang den TinyOS-Quellcode gelesen, um seine Struktur zu verstehen, und diese Erfahrung war äußerst hilfreich.
Die Fähigkeit, sich schnell in eine unbekannte Codebasis einzuarbeiten, ist sehr nützlich.
Wenn regelmäßig neue Sprachen und Frameworks auftauchen, können Unternehmen immer weiter günstige Berufseinsteiger einstellen.
Ich denke, dass dies einer der Gründe ist, warum Software nicht wie andere Ingenieurdisziplinen behandelt wird.
Im Kern ist das kein Programmierproblem, sondern ein Problem managementbedingter Inkompetenz.
In den meisten Projekten werden geschäftliche Anforderungen nicht klar definiert, und alles läuft auf Vermutungsbasis.
Das Scheitern großer öffentlicher IT-Projekte versteht man sofort, wenn man sich Vertragsstrukturen und Anreize ansieht.
Das Problem ist eine Struktur, die weniger auf Kompetenz als auf zeitbasierte Beratungsabrechnung setzt.
Bei erfolgreichen Projekten sind weniger die Technik als vielmehr Alignment zwischen Organisationen und Kompetenz entscheidend.
Ich halte Altersdiskriminierung im Silicon Valley für das eigentliche Problem.
Erfahrung wird ignoriert, und Lehren aus der Vergangenheit fließen überhaupt nicht ein.
Die Hardware-Branche hat ihr Erbe respektiert und zugleich Innovation angestrebt.
Dahinter steht die Sichtweise, dass Menschen, die aus früheren Fehlschlägen gelernt haben, keine neuen Versuche mehr wagen.
Softwareprojekte scheitern letztlich wegen menschlichen Versagens.
Wichtiger als perfekte Prozesse oder Werkzeuge sind motivierte und verantwortungsbewusste Menschen.
Es braucht rechtliche Konsequenzen (Consequences), damit Menschen ihre Arbeit ordentlich machen.
Wie bei physischen Bauprojekten sollte jede Phase unabhängige Prüfung und Verantwortlichkeit haben.
Deshalb ist es realistischer, mit einem gewissen Maß an Risiko weiterzuarbeiten.
Erfolgreiche Projekte verdankten sich einigen wenigen Personen mit emotionaler Intelligenz und Führungsstärke.
Letztlich ist Software Engineering ein Menschenproblem.
Die Branche steckt jedoch weiterhin in Verantwortungsvermeidung und dem Hinterherlaufen von Trends fest.
Diese Probleme betreffen nicht nur Software.
Auch große Tiefbauprojekte wie Auburn Dam, Columbia River Crossing und Big Dig sind für Budgetüberschreitungen berüchtigt.
Wenn das ursprüngliche Budget unrealistisch war, sind das womöglich einfach nur realistisch gewordene Kosten.
Deshalb ist ein Ansatz wichtig, bei dem man mit kleinen Projekten beginnt und schrittweise skaliert.
Ich bin weder Entwickler noch PM, aber mich haben große Erfolgsgeschichten interessiert.
Da ich in einem Krankenhaus arbeite, wären Erfolgsfälle im Gesundheitswesen noch besser.
Ich habe The Phoenix Project gelesen und dadurch die Denkweise hinter Agile und DevOps ein wenig verstanden, aber die Anwendung in der Praxis ist schwierig.
Ich möchte in kleinen Projekten die Saat für Erfolg legen.
Ausgangspunkt war die Reflexion über die Komplexität von Multics und dass Ken Thompson Unix in drei Wochen selbst schrieb.
Siehe diesen Beitrag.
Auch Conway’s Law, Risiken durch Schlüsselpersonen, klare Ownership und eine Testkultur sind unverzichtbar.
Vor allem braucht man den Mut, „Nein“ zu sagen.
Es gibt auch Fälle wie healthcare.gov, die nach einem Fehlschlag verbessert wurden.
Bevor man die IT-Community beschuldigt, sollte man sich die auf kurzfristige Gewinne ausgerichtete Unternehmenskultur ansehen.
Sicherheit und Stabilität sind immer die erste Position bei Budgetkürzungen.
Führungskräfte gehen selbst nach Misserfolgen mit goldenen Fallschirmen, und die Verantwortung bleibt bei den Entwicklern.
Auch der Staat sanktioniert mangelhafte Sicherheitsvorfälle von Unternehmen nicht angemessen.
Am Ende wiederholt sich die zynische Realität, alles mit „AI, Beratern und Outsourcing“ lösen zu wollen.
Auch wenn man Billionen in AI steckt, wird die Lage nicht besser — eher schlimmer.
Die westlichen Gesellschaften sind bereits instabil und driften nach rechts außen.
Die nächste Krise könnte nicht nur ein finanzieller Kollaps sein, sondern in einen gesellschaftlichen Zusammenbruch münden.
Die Menschheit sollte statt über Krisen lieber durch Verständnis zu Fortschritt gelangen.
Mit guten Prozessen liefert sie Ergebnisse, mit schlechten Prozessen beschleunigt sie Probleme.
Letztlich bleibt die Richtung dieselbe, nur das Tempo nimmt zu.
Wenn das über so lange Zeit nicht behoben wurde, ist das dann nicht eher ein Problem auf Seiten des Betriebs, der es übernehmen soll, als eines der Entwicklungstechnik oder der Entwicklungsprinzipien ...
Zum Skandal um die britische Post gibt es auch ein Drama dazu.
Bis heute wurden die Opfer noch nicht entschädigt, daher dauert die Sache weiter an.
Als aktuelles inländisches Beispiel fällt mir der gescheiterte Aufbau des Next-Generation-IT-Systems der Gyeonggi Credit Guarantee Foundation ein
https://v.daum.net/v/20251111165048155
Führen auch andere Länder derart riesige SI-Projekte durch?