Warum IT-Projekte scheitern – wir könnten auch anders

Trotz agiler Methoden, moderner Tools und Frameworks hält sich ein altes Problem in der Softwareentwicklung hartnäckig: Projekte werden zu spät, zu teuer oder gar nicht geliefert. Zahlreiche Studien bestätigen das – und die Ursachen sind selten technischer Natur. Sie sind strukturell.

Laut dem CHAOS Report 2020 der Standish Group gelten nur 31 % der IT-Projekte als erfolgreich (pünktlich, im Budget und mit den erwarteten Funktionen geliefert). Über die Hälfte sind „herausgefordert“, und 17 % scheitern komplett. Noch alarmierender sind die Ergebnisse einer gemeinsamen Studie von McKinsey und der Universität Oxford: Große IT-Projekte (ab 15 Millionen US-Dollar Budget) überschreiten im Schnitt ihr Budget um 45 % und liefern 56 % weniger Wert als geplant. Bei 17 % der Projekte gefährdet das Scheitern sogar die Existenz des Unternehmens.

Doch woran liegt das?

Schätzfehler sind ein Symptom – nicht die Ursache

Falsche Schätzungen sind ein Problem – aber selten das eigentliche. Meist sind sie das Ergebnis tieferliegender struktureller Defizite. Wenn IT-Initiativen scheitern, sind vier Ursachen besonders häufig:

1. Stakeholder-Missmanagement – Wenn jeder in eine andere Richtung zieht

In 70 % der gescheiterten Projekte wurden Entscheidungen von Stakeholdern außerhalb des Teams getroffen, die die Planungsgrundlage massiv verändert haben (Quelle: Mittelstandcafe.de). Fehlende Zielklarheit, unklare Kommunikation zwischen Business, IT und Nutzern führen zu Schätzungen auf falscher Basis.

Was hilft: Strukturierte Stakeholder-Einbindung – frühzeitig und kontinuierlich. Entscheidungen transparent machen, Prioritäten regelmäßig abgleichen und Stakeholder-Management als strategische Aufgabe ernst nehmen.

2. Fehlendes Risikomanagement – Wenn Überraschungen den Plan kippen

Nicht die Risiken an sich bringen Projekte zu Fall – sondern die Tatsache, dass sie niemand kommen sah. Proaktives Risikomanagement fehlt in vielen Organisationen. Notfallpläne werden selten mitgedacht, Teams sind unvorbereitet auf Personalwechsel, rechtliche Hürden oder technische Probleme.

Was hilft: Echte Risikoanalyse betreiben. Risiken regelmäßig bewerten, ein lebendes Risikoregister pflegen und Maßnahmen zur Abfederung fest einplanen.

3. Schlechtes Requirements Engineering – Bauen auf Sand

Unklare, lückenhafte oder instabile Anforderungen sind eine der Hauptursachen für gescheiterte Projekte. Dennoch starten viele Teams mit der Umsetzung, obwohl Ziele unklar oder wandelbar sind. Die Folge: Nacharbeit, Scope Creep, enttäuschte Erwartungen.

Was hilft: Requirements Engineering als zentrale Disziplin begreifen. Anforderungen iterativ mit cross-funktionalen Teams definieren, priorisieren und validieren. Strukturiert vorgehen – mit User Stories, Akzeptanzkriterien und Traceability-Matrizen.

4. Fehlende oder ungeeignete Schätzmethoden – Bauchgefühl ist keine Strategie

Viele Organisationen schätzen Projekte weiterhin „aus dem Bauch heraus“ oder auf Basis alter Excel-Tabellen. Das ist riskant – vor allem bei komplexen Vorhaben. Die McKinsey-Studie zeigt: Schlechte Prognosen kosten nicht nur Geld, sondern auch Unternehmenswert.

Was hilft: Strukturierte Schätzmethoden wie Planning Poker, Wideband Delphi, Drei-Punkt-Schätzung oder Monte-Carlo-Simulation nutzen. Historische Daten heranziehen, moderne Tools einsetzen – inklusive KI-gestützter Systeme, die laut PMI bereits 86 % der deutschen Projektmanager verwenden (Quelle: Haufe.de).

Warum Produktentwicklung nachhaltiger werden muss

Softwareentwicklung ist heute komplexer denn je: verteilte Systeme, schnelllebige Märkte, regulatorische Anforderungen, globale Teams, KI. Diese zunehmende Komplexität lässt sich nicht mit Ad-hoc-Planung und Projekt-Feuerwehraktionen beherrschen.

Was es braucht, ist ein Wandel hin zu nachhaltiger Produktentwicklung, basierend auf:

• effizientes Stakeholder Management
• modularem und auf Wiederverwendbarkeit ausgelegtem Requirements Engineering
  
• Systemischem Denken statt linearem Task-Tracking
• stabile und nachhaltige Abschätzmethodiken 
• Einer Kultur der Verantwortung, in der Qualität wichtiger ist als Tempo

Fazit: Kein Schätzproblem – ein Strukturproblem

Falsche Schätzungen sind kein Zeichen mangelnder technischer Kompetenz – sondern oft ein Symptom organisationaler Dysfunktion. Wer bessere Software bauen will, muss zuerst bessere Systeme für Zusammenarbeit, Planung und Lernen schaffen.

Nachhaltige Produktentwicklung ist kein Luxus. Sie ist die einzige logische Antwort auf die wachsende Komplexität unserer digitalen Welt.