Fast jede:r, die oder der im Mittelstand schon einmal ein Softwareprojekt verantwortet hat, kennt das Muster: Der Start ist euphorisch, der Zeitplan ambitioniert, das Budget „realistisch". Ein halbes Jahr später ist die Hälfte des Geldes weg, die Hälfte der Funktionen fehlt, und niemand ist mehr ganz sicher, was am Ende eigentlich gebaut werden sollte. Was sich anfühlt wie individuelles Pech, ist in Wahrheit der statistische Normalfall. Die Daten dazu sind seit Jahrzehnten erstaunlich stabil – und sie zeigen ziemlich präzise, wo das Problem liegt.
Scheitern ist die Regel, nicht die Ausnahme
Die bekannteste Langzeiterhebung zu IT-Projekterfolg ist der CHAOS Report der Standish Group. In der Auswertung von 2012 (veröffentlicht im CHAOS Manifesto 2013) galten nur 39 % der Projekte als erfolgreich, 43 % als „challenged" – also fertiggestellt, aber zu spät, über Budget oder mit weniger Funktionen als geplant – und 18 % als vollständig gescheitert, sprich abgebrochen oder nie genutzt.
Das ist, so ernüchternd es klingt, bereits eine Verbesserung. In der ersten großen CHAOS-Erhebung von 1994 lag die Erfolgsquote bei nur 16 %. Über fast zwei Jahrzehnte stieg sie von 29 % (2004) auf 39 % (2012) – und blieb damit hartnäckig unter der 50-Prozent-Marke. Mehr als ein Jahrzehnt Methodenverbesserung, Agile-Welle und Tooling-Fortschritt hat die Grundwahrscheinlichkeit, dass ein Softwareprojekt sauber gelingt, nicht über „etwa zwei von fünf" hinausgehoben.
Ein fairer Hinweis, weil seriöse Leser:innen ihn verdienen: Die Standish-Methodik ist in der Forschung umstritten (u. a. Eveleens & Verhoef, IEEE Software, 2010). Kritisiert wird, dass Erfolg sehr eng über die Einhaltung der ursprünglichen Schätzung definiert wird. Man sollte die Zahlen daher als Größenordnung lesen, nicht als Messwert auf zwei Nachkommastellen. An der Richtung des Befunds ändert das nichts – andere Quellen kommen unabhängig zum selben Bild.
Zu spät, zu teuer – und weniger, als versprochen war
Wer „challenged" abstrakt findet, dem helfen die konkreten Überschreitungszahlen. Im Standish-Datensatz 2012 wurden 74 % der Projekte nicht termingerecht fertig, 59 % überschritten die Kostenschätzung, und im Schnitt wurden am Ende nur 69 % der ursprünglich geplanten Funktionen tatsächlich ausgeliefert. Anders formuliert: Selbst dort, wo ein Projekt nicht offiziell scheitert, bekommt das Unternehmen im Durchschnitt rund ein Drittel dessen nicht, wofür es bezahlt hat – verspätet und teurer als kalkuliert.
Wie groß die Lücke zwischen Versprechen und Ergebnis werden kann, zeigt eine vielzitierte Großstudie von McKinsey gemeinsam mit der University of Oxford: Über mehr als 5.400 IT-Projekte hinweg lagen große Vorhaben im Schnitt 45 % über Budget, 7 % über der Zeit – und lieferten 56 % weniger Wert, als ursprünglich versprochen war (McKinsey & University of Oxford, 2012). Nicht 56 % weniger Funktionen, sondern 56 % weniger Nutzen. Das ist der eigentliche Kern des Problems: Es wird nicht nur teurer und langsamer, es wird am Ende oft schlicht das Falsche gebaut.
Diese Verschwendung hat einen Preis, der sich beziffern lässt. Das Project Management Institute (PMI) rechnet vor, dass durch schlechte Projektleistung 9,9 % jedes investierten Euros verloren gehen (PMI Pulse of the Profession, 2018). Für ein mittelständisches Unternehmen, das keine zweistelligen Millionenbudgets zum Abpuffern hat, ist genau dieser Anteil oft der Unterschied zwischen „hat sich gelohnt" und „hätten wir es mal gelassen".
Der deutsche Mittelstand: ERP, Individualsoftware – und dieselben Muster
Diese Zahlen sind international. Belastbare, rein deutsche Statistiken zum Projekterfolg sind erstaunlich dünn – aber dort, wo es sie gibt, bestätigen sie das Bild. Die archetypische Mittelstands-Softwareeinführung ist das ERP-System, und genau hier zeigt die deutsche Trovarit-Studie „ERP in der Praxis": Bei rund der Hälfte der ERP-Projekte werden Budget oder Zeitplan überschritten. Die meisten Überschreitungen bleiben moderat – aber „moderat über Budget" ist bei einer sechsstelligen Investition trotzdem viel Geld, das nicht eingeplant war.
Noch deutlicher wird der deutsche Bezug beim Thema Scope Creep – dazu gleich mehr. Vorweg die wichtigste Einordnung: Die Ursachen, die hinter all diesen Zahlen stehen, sind über Länder, Branchen und Jahrzehnte hinweg verblüffend konstant. Und es ist fast nie die Technik.
Die Ursache ist fast immer dieselbe
Das Bemerkenswerteste an den Daten ist nicht, dass so viele Projekte scheitern, sondern warum – denn die Antwort ist über Quellen hinweg konstant. Es sind die Anforderungen und die Kommunikation darüber.
Im CHAOS-Report stehen bei den „challenged" Projekten fehlender Nutzer-Input, unvollständige Anforderungen und sich ändernde Anforderungen ganz oben auf der Ursachenliste – mit nur Bruchteilen eines Prozentpunkts Abstand zueinander.
Dieselbe Geschichte erzählen die Erfolgsfaktoren, nur spiegelverkehrt: Die drei wichtigsten Gründe, warum ein Projekt gelingt, sind laut Standish Nutzereinbindung (15,9 %), Rückhalt im Management (13,9 %) und eine klare Anforderungsdefinition (13,0 %).
Das PMI quantifiziert dieselbe Wurzel noch direkter: Fast die Hälfte (47 %) der erfolglosen Projekte verfehlt ihre Ziele aufgrund von ungenauem Anforderungsmanagement (PMI, 2014). Und das PMI weist ausdrücklich darauf hin, dass unklare Anforderungen nicht eine Ursache neben anderen sind, sondern die gemeinsame Quelle gleich mehrerer Klassiker – Scope Creep, schlechte Kommunikation, fehlende Stakeholder-Einbindung, mangelnder Rückhalt.
Übersetzt aus dem Statistik-Deutsch heißt das schlicht: Der häufigste Grund, warum Software teuer, spät und enttäuschend wird, ist, dass zu Beginn niemand wirklich genau wusste – oder präzise ausgedrückt hat –, was eigentlich gebaut werden soll. Nicht aus Inkompetenz, sondern weil das Spezifizieren dessen, was man will, selbst die schwierigste Aufgabe des ganzen Projekts ist. Die Fachseite denkt in Geschäftsabläufen, die Entwicklung in Datenmodellen und Edge Cases, und zwischen beiden klafft eine Lücke, die in den ersten Wochen niemand ernst nimmt – und die dann in jeder einzelnen Folgewoche teurer wird, sie zu schließen.
Scope Creep: In Deutschland ein Mittelstands-Problem mit Ansage
Wenn am Anfang nicht klar ist, was gebaut werden soll, wird es während des Bauens „nachgeschärft" – und das ist messbar. Laut PMI erlebten 52 % aller in einem Jahr abgeschlossenen Projekte Scope Creep, also unkontrolliertes Anwachsen des Umfangs – ein deutlicher Anstieg gegenüber 43 % fünf Jahre zuvor (PMI Pulse of the Profession, 2018).
Für den deutschen Markt wird es hier besonders konkret. Eine Befragung von 100 deutschen CIOs im Auftrag des Personaldienstleisters Robert Half ergab: 76 % der deutschen IT-Verantwortlichen sorgen sich über Scope Creep – und bei mittelständischen Unternehmen steigt dieser Wert auf 87 % (Robert Half, 2013). Der Mittelstand ist von ausufernden Projekten also nicht weniger, sondern stärker betroffen als der Konzern. Als Hauptursachen nannten die CIOs fehlende personelle Kontinuität durch häufige Teamwechsel (38 %), unzureichende Projektmanagement-Kompetenz (37 %), ein verändertes regulatorisches Umfeld (36 %) und mangelhafte Planung und Vorbereitung (34 %).
Das ist die eigentlich frustrierende Erkenntnis. Scope Creep fühlt sich im Moment immer vernünftig an – jede einzelne Änderung hat eine gute Begründung. In Summe aber ist genau das der Mechanismus, der aus einem 6-Monats-Projekt ein 14-Monats-Projekt macht. Und er greift dann am stärksten, wenn die Ausgangsspezifikation vage war: Wo nichts Präzises steht, lässt sich beliebig „präzisieren".
Die gute Nachricht steht ebenfalls in den Daten – und sie gilt besonders für KMU
Bis hierhin klingt das nach einem unausweichlichen Naturgesetz. Ist es aber nicht. Derselbe Standish-Datensatz, der die ernüchternden Gesamtzahlen liefert, enthält den vielleicht wichtigsten Hebel überhaupt – und er ist für kleine und mittlere Unternehmen geradezu maßgeschneidert.
Projektgröße ist der stärkste einzelne Erfolgsfaktor. Kleine Projekte (unter rund 1 Mio. USD Aufwand) haben eine Erfolgsquote von über 70 % – 2012 konkret 76 % erfolgreich, nur 4 % gescheitert. Große Projekte (über 10 Mio. USD) kommen im selben Jahr auf gerade einmal 10 % Erfolg – und sie sind etwa zehnmal häufiger ein Totalausfall als kleine.
Das ist kein Zufall, sondern die direkte Folge des Anforderungsproblems: In einem kleinen, klar umrissenen Vorhaben lässt sich noch überblicken, was man will. Der Abstand zwischen Fachseite und Entwicklung ist kurz, Rückkopplung passiert in Tagen statt Monaten, und ein Missverständnis kostet eine Woche, nicht ein Quartal. Genau dieser Vorteil – kleine, scharf definierte, schnell überprüfbare Einheiten – ist das, worüber der Mittelstand strukturell verfügt, während Großkonzerne ihn mühsam herstellen müssen. Zur Einordnung: Auf der Ebene großer Unternehmenstransformationen liegt die Erfolgsquote laut BCG seit Jahren bei nur rund 30 %, bis zu 70 % verfehlen ihre Ziele (BCG, 2023). Die schiere Größe ist also kein Schutz, sondern ein Risiko.
Der Hebel für den Mittelstand lautet damit nicht „mehr Tooling" oder „mehr Projektmanagement-Overhead", sondern: Klarheit über das Gewünschte herstellen, bevor gebaut wird, und den Umfang klein und konkret halten.
Worauf alles hinausläuft
Fügt man die Befunde zusammen, ergibt sich ein bemerkenswert eindeutiges Bild. Über mehrere unabhängige Quellen, drei Jahrzehnte und Zehntausende Projekte hinweg ist die wichtigste Stellschraube für Erfolg oder Scheitern nicht die Wahl des Frameworks, des Dienstleisters oder der Methode. Es ist die Frage, ob zu Beginn präzise, vollständig und für alle Beteiligten verständlich feststeht, was die Software eigentlich leisten soll – und ob dieser Umfang klein genug ist, um beherrschbar zu bleiben.
Das ist zugleich die Stelle, an der heute am wenigsten investiert wird. Die Anforderungsphase ist die unbeliebteste Phase jedes Projekts: anstrengend, abstrakt, scheinbar unproduktiv, weil „noch nichts läuft". Also wird sie verkürzt – und genau dadurch entstehen die 47 % anforderungsbedingten Fehlschläge, die 52 % Scope Creep und der Mittelstands-Spitzenwert von 87 % besorgten CIOs.
Daraus folgt eine unbequeme, aber naheliegende Frage für jede:n, der oder die Softwareprojekte verantwortet: Warum überlassen wir ausgerechnet den erfolgskritischsten Schritt – das saubere, vollständige Festlegen dessen, was gebaut werden soll – nach wie vor dem Zufall freier Gespräche, Bauchgefühl und unstrukturierter Briefings? Es ist der einzige Teil des Prozesses, der nachweislich über Gelingen oder Scheitern entscheidet, und zugleich der am wenigsten strukturierte. Wer diesen Schritt so systematisch, geführt und überprüfbar gestaltet wie alles andere im Projekt – wer also das „Was genau wollen wir eigentlich?" zu einer klaren, durchdachten Entscheidung macht, bevor die erste Zeile Code entsteht –, adressiert nicht irgendeine Fehlerquelle. Er adressiert die mit Abstand häufigste.
Quellen
- Standish Group, CHAOS Manifesto 2013 (Daten 2012)
- Standish Group, CHAOS Report 1994
- McKinsey & University of Oxford, Delivering large-scale IT projects on time, on budget, and on value (2012)
- Project Management Institute, Requirements Management: A Core Competency for Project and Program Success (2014)
- Project Management Institute, Pulse of the Profession 2018
- Robert Half, Scope-Creep-Studie (u. a. 100 deutsche CIOs, 2013)
- Trovarit, ERP in der Praxis
- BCG, Five Ways to Beat the Odds on Digital Transformation (2023)
- Methodenkritik: Eveleens & Verhoef, The Rise and Fall of the Chaos Report Figures, IEEE Software (2010)
