Warum 70 % aller Softwareprojekte scheitern und warum 30 Jahre Innovation das Problem nicht gelöst haben

Warum Softwareprojekte immer noch scheitern: Zahlen aus 30 Jahren CHAOS Report

Die Softwareentwicklung hat sich in den letzten Jahrzehnten grundlegend verändert. Von den ersten objektorientierten Ansätzen über das Aufkommen des Internets bis hin zu Cloud-Architekturen, agiler Entwicklung, Continuous Delivery und künstlicher Intelligenz hat kaum eine Branche eine vergleichbare Innovationsgeschwindigkeit erlebt. Und doch zeigt ein Blick auf die Realität vieler Projekte ein überraschend konstantes Bild.

Der Standish Group CHAOS Report, eine der bekanntesten Langzeitstudien zu IT-Projekten, kommt seit über 30 Jahren zu einer ernüchternden Erkenntnis: Die Mehrzahl der Projekte verläuft nicht wie geplant. Zwar hat sich auf den ersten Blick einiges verbessert. Während 1994 nur rund 16 % der Projekte als erfolgreich galten, liegt dieser Anteil heute bei etwa 30 %. Gleichzeitig sank der Anteil vollständig gescheiterter Projekte von etwa 31 % auf rund 19 %.

Das klingt zunächst positiv. Doch bei genauerem Hinsehen relativiert sich dieses Bild schnell. Denn im Umkehrschluss bedeutet das auch heute noch: Rund 70 % aller Projekte sind entweder gescheitert oder mit erheblichen Problemen behaftet. Sie werden verspätet geliefert, überschreiten Budgets oder erreichen nicht den ursprünglich geplanten Funktionsumfang.

Genau hier wird es interessant. Wenn sich technologisch in den letzten 30 Jahren nahezu alles verändert hat, warum bleibt das grundlegende Ergebnis so ähnlich? Warum führen bessere Tools, moderne Architekturen und neue Methoden nicht automatisch zu besseren Projekten? Dieser Beitrag geht genau dieser Frage nach.

‍

Die wahren Ursachen gescheiterter Softwareprojekte haben sich nicht verändert

‍Der Widerspruch aus dem vorherigen Abschnitt legt eine naheliegende Vermutung nahe: Wenn sich die Ergebnisse trotz massiver technologischer Fortschritte kaum verändern, liegt die Ursache nicht primär in der Technologie selbst.

Ein Blick zurück auf die ersten Auswertungen des CHAOS Reports bestätigt genau das. Bereits 1994 wurden als zentrale Gründe für gescheiterte oder problematische Projekte Faktoren genannt wie unklare oder unvollständige Anforderungen, fehlende Einbindung der Anwender, unrealistische Erwartungen sowie mangelnde Abstimmung und Steuerung auf Managementebene. Bemerkenswert ist dabei, dass diese Ursachen bis heute nahezu unverändert relevant geblieben sind.

Auch aktuelle Analysen beschreiben im Kern dieselben Problemfelder, nur mit modernerer Sprache. Aus „unvollständigen Anforderungen“ wird „fehlendes Alignment“. Aus „fehlendem User Input“ wird „unzureichende Stakeholder-Einbindung“. Aus „schwachem Management“ wird „fehlender Sponsor“ oder „mangelnde Entscheidungsfähigkeit“. Die Begriffe haben sich verändert. Die Realität nicht.

Im Zentrum steht bis heute dasselbe Muster: Es fehlt ein gemeinsames, belastbares Verständnis dessen, was entwickelt werden soll. Erwartungen sind nicht eindeutig abgestimmt, Annahmen unterscheiden sich zwischen Beteiligten und Entscheidungen werden auf unsicheren Grundlagen getroffen. Ein typisches Beispiel: Zwei Teams arbeiten an demselben Feature, interpretieren eine Anforderung jedoch unterschiedlich. Beide liefern „korrekt“, und trotzdem passt am Ende nichts zusammen.

Hinzu kommt, dass Anforderungen sich im Laufe eines Projekts zwangsläufig verändern. Das ist weder ungewöhnlich noch grundsätzlich problematisch. Problematisch wird es erst dann, wenn Änderungen nicht sauber nachvollzogen, bewertet und gesteuert werden können. Genau daran zeigt sich, warum diese Ursachen so hartnäckig sind: Es handelt sich nicht um isolierte Einzelprobleme, sondern um strukturelle Defizite im Umgang mit Anforderungen, Abstimmung und Entscheidungsfindung. Diese lassen sich nicht allein durch bessere Technologien oder neue Methoden beheben.

‍

Warum schlechte Anforderungen kein IT-Problem sind

Wenn die zentralen Ursachen seit Jahrzehnten bestehen und offensichtlich nicht primär technischer Natur sind, liegt eine weitere Schlussfolgerung nahe: Es handelt sich nicht um ein spezifisches Problem der Softwareentwicklung.

Der CHAOS Report wird zwar häufig im Kontext von IT-Projekten diskutiert. Die zugrunde liegenden Muster finden sich jedoch in nahezu allen Arten von Entwicklungsprojekten wieder. Überall dort, wo komplexe Systeme entstehen, müssen Anforderungen verstanden, abgestimmt und in konkrete Lösungen überführt werden.

Das gilt für klassische Softwareentwicklung ebenso wie für die Produktentwicklung im Maschinenbau, für die Medizintechnik oder den Anlagenbau. Unabhängig von der Branche zeigen sich immer wieder die gleichen Schwierigkeiten: Erwartungen sind nicht eindeutig geklärt, Annahmen unterscheiden sich zwischen Beteiligten, Abstimmungen erfolgen zu spät oder nicht konsequent genug und Änderungen werden erst sichtbar, wenn ihre Auswirkungen bereits weitreichend sind.

Die Folge sind Verzögerungen, steigende Aufwände und Qualitätseinbußen. Die eingesetzten Technologien unterscheiden sich von Branche zu Branche teils erheblich. Das zugrunde liegende Problem hingegen bleibt identisch. Es geht nicht primär darum, wie etwas umgesetzt wird, sondern darum, wie klar verstanden ist, was überhaupt umgesetzt werden soll.

‍

Warum ineffiziente Softwareprojekte zur Normalität geworden sind

Ein besonders kritischer Aspekt ist, dass viele Organisationen diesen Zustand längst nicht mehr als Problem wahrnehmen. Über die Jahre hat sich in vielen Unternehmen ein Umgang etabliert, der die beschriebenen Defizite indirekt kompensiert.

Zusätzliche Iterationen, umfangreiche Abstimmungsschleifen und wiederholte Korrekturen werden nicht als Ausnahme betrachtet, sondern von vornherein eingeplant. Zeitpläne enthalten bewusst Puffer, Budgets berücksichtigen implizit Unsicherheiten und Mehraufwände werden als unvermeidlicher Bestandteil von Projekten akzeptiert. Mit anderen Worten: Ein erheblicher Teil der Ineffizienz ist bereits einkalkuliert.

Das führt zu einer trügerischen Wahrnehmung. Projekte gelten als erfolgreich, solange sie innerhalb dieser erweiterten Erwartungen bleiben. Dass ein großer Teil dieses Aufwands eigentlich vermeidbar wäre, wird oft nicht mehr hinterfragt. Genau darin liegt das eigentliche Problem. Denn wenn ein ineffizienter Zustand zur Normalität wird, verschwindet auch der Anreiz, ihn grundlegend zu verändern.

Dabei stellt sich eine entscheidende Frage: Wie viel effizienter könnten Projekte sein, wenn von Anfang an mehr Klarheit herrschen würde? Die ehrliche Antwort ist unbequem. In vielen Fällen ließe sich der Aufwand signifikant reduzieren. Nicht durch noch bessere Technologien oder zusätzliche Methoden, sondern durch eine sauberere Struktur, klarere Anforderungen und ein gemeinsames Verständnis von Beginn an.

‍

Requirements Engineering: Der wichtigste Hebel für erfolgreiche Projekte

Wie lässt sich dieses Problem systematisch lösen? Genau hier setzt Requirements Engineering an. Requirements Engineering, also der offizielle Fachbegriff für Anforderungsmanagement, beschreibt die Disziplin, Anforderungen strukturiert zu erheben, zu dokumentieren, zu prüfen, abzustimmen und über den gesamten Projektverlauf hinweg konsistent weiterzuentwickeln.

Dabei geht es nicht nur darum, Anforderungen aufzuschreiben. Es geht darum, ein gemeinsames Verständnis zu schaffen, Zusammenhänge sichtbar zu machen und Entscheidungen auf eine belastbare Grundlage zu stellen. Requirements Engineering macht sichtbar, was in vielen Projekten implizit bleibt.

In vielen Organisationen entstehen Anforderungen in Gesprächen, E-Mails oder Tickets. Entscheidungen werden getroffen, ohne dass ihre Grundlage sauber dokumentiert ist. Zusammenhänge bleiben unsichtbar und Auswirkungen von Änderungen werden erst spät erkannt. Genau hier setzt eine strukturierte Herangehensweise an.

Anforderungen werden klar formuliert, miteinander verknüpft und über den gesamten Projektverlauf hinweg nachvollziehbar gehalten. Änderungen werden nicht mehr ad hoc umgesetzt, sondern bewertet, eingeordnet und kontrolliert integriert. Damit wird aus einem schwer steuerbaren, impliziten Prozess ein bewusst gestalteter und kontrollierbarer Bestandteil der Entwicklung.

Ein häufiger Einwand lautet, dass Anforderungen sich ohnehin ständig ändern und daher nie vollständig klar sein können. Das ist richtig. Genau deshalb ist Requirements Engineering so wichtig. Es geht nicht darum, von Anfang an perfekte Anforderungen zu haben, sondern Änderungen kontrolliert und nachvollziehbar zu handhaben. Ohne diese Struktur führen Änderungen zu Chaos. Mit dieser Struktur werden sie beherrschbar.

Gleichzeitig zeigt die Praxis, dass Requirements Engineering oft nicht sein volles Potenzial entfaltet. Nicht weil der Ansatz falsch ist, sondern weil er falsch umgesetzt wird. Zu komplexe Prozesse, zu viel Dokumentation und fehlende Integration in den Arbeitsalltag führen dazu, dass der Nutzen nicht greifbar wird. Entscheidend ist daher nicht nur, ob Requirements Engineering betrieben wird, sondern wie.

‍

Warum Anforderungsmanagement in der Praxis oft unterschätzt wird

Wenn Requirements Engineering genau die Probleme adressiert, die seit Jahrzehnten Projekte ausbremsen, warum spielt es in der Praxis dann oft nur eine Nebenrolle? Die Antwort liegt weniger in fehlendem Wissen als in der Wahrnehmung des Themas.

Anforderungsmanagement gilt selten als innovativ, selten als spannend und schon gar nicht als „hip“. Während neue Technologien, Architekturen oder Methoden regelmäßig große Aufmerksamkeit erhalten, wirkt Requirements Engineering im Vergleich dazu unspektakulär. Es steht für Struktur, Disziplin und saubere Grundlagenarbeit. Genau das macht es für viele unattraktiv.

Vom Entwickler bis hin zur Führungsebene lässt sich beobachten, dass die Aufmerksamkeit stärker auf Themen gerichtet ist, die als modern und zukunftsweisend wahrgenommen werden. Neue Frameworks, Plattformen oder Trends bieten sichtbaren Fortschritt und lassen sich leichter kommunizieren. Die grundlegende Frage, ob überhaupt klar ist, was entwickelt werden soll, rückt dabei in den Hintergrund.

Hinzu kommt, dass die Auswirkungen von unzureichendem Anforderungsmanagement oft zeitverzögert auftreten. Die Ursachen liegen zu Beginn eines Projekts, während die Symptome – Verzögerungen, Mehraufwände oder Qualitätsprobleme – erst deutlich später sichtbar werden. Das führt zu einem paradoxen Verhalten: Organisationen investieren kontinuierlich in die Optimierung ihrer Umsetzung, während gleichzeitig die Grundlage dafür vernachlässigt wird.

Die Folge ist ein Muster, das sich seit Jahrzehnten wiederholt: Es wird immer effizienter umgesetzt. Aber nicht zwangsläufig das Richtige.

‍

Warum wir beim Anforderungsmanagement endlich umdenken müssen

Wenn sich die grundlegenden Probleme seit über 30 Jahren kaum verändert haben, liegt das nicht daran, dass es keine Lösungen gibt. Es liegt daran, dass der Fokus falsch gesetzt ist.

Über Jahrzehnte hinweg wurde die Umsetzung immer weiter optimiert. Doch genau diese Optimierung verstärkt heute das Problem: Unklare Anforderungen werden schneller umgesetzt, Missverständnisse verbreiten sich schneller und Fehlentscheidungen haben größere Auswirkungen.

Damit ist ein Punkt erreicht, an dem inkrementelle Verbesserungen nicht mehr ausreichen. Es braucht eine bewusste Verschiebung des Fokus. Weg von der Frage, wie wir schneller entwickeln können. Hin zu der Frage, wie wir besser verstehen, was wir entwickeln.

Das bedeutet nicht, technologische Innovationen zu ersetzen. Sondern ihnen endlich die Grundlage zu geben, die sie brauchen. Struktur, Klarheit und nachvollziehbare Entscheidungen müssen denselben Stellenwert erhalten wie Geschwindigkeit und Effizienz.

Denn die technologischen Möglichkeiten sind heute so weit entwickelt wie nie zuvor. Was fehlt, ist nicht die Fähigkeit zur Umsetzung, sondern die Klarheit davor.

Danke an Dr. Marcus Trapp für die Inspiration zu diesem Artikel bei einem netten Abendessen.