Gescheiterte Software-Projekte sehen lange wie Fortschritt aus. Die Muster dahinter wiederholen sich, und man erkennt sie früher, als die meisten glauben.
Ein gescheitertes Software-Projekt sieht selten aus wie ein Crash. Es sieht lange aus wie Fortschritt: Termine finden statt, Konzepte werden dicker, das Budget läuft. Nur Software, die jemand benutzen kann, gibt es nicht.
Offiziell gescheitert ist ein Projekt erst, wenn es abgebrochen wird. Real gescheitert ist es oft Monate vorher. Die Entscheidungen, die es kippen, fallen am Anfang, nicht am Ende.
Wir bauen Software für Fälle, in denen Fehler echte Konsequenzen haben. Die Muster, an denen Projekte kippen, wiederholen sich dabei erstaunlich zuverlässig. Drei davon siehst du hier, dazu die Frühwarnzeichen und was ehrlich dagegen hilft.
Muster 1: Niemand hat entschieden, was die erste Version können muss
Unklarer Scope ist die häufigste Ursache. Nicht, weil niemand nachgedacht hätte. Sondern weil alle gleichzeitig alles wollen und niemand entscheidet, was zuerst kommt.
Ein hundertseitiges Konzept löst das nicht. Es verschiebt die Entscheidungen nur in ein Dokument, das niemand liest. Klarheit entsteht nicht auf Papier, sondern an einem Stand, den man anklicken kann.
Dasselbe gilt für den Festpreis auf unbekannten Scope. Er fühlt sich sicher an, ist aber Illusionssicherheit: Irgendjemand zahlt die Differenz zwischen Annahme und Realität. Meist über Abstriche an genau den Stellen, die man nicht sieht.
Muster 2: Der Prototyp, der plötzlich ein System sein soll
Mit KI entsteht heute in Tagen ein Prototyp, der aussieht wie das fertige Produkt. Das ist echter Fortschritt, und intern etwas zu bauen ist ein guter Instinkt.
Für Prozesse, bei denen Fehler zählen, ist ein gepromptetes Tool aber noch kein System. Echte Softwareentwicklung beantwortet Fragen, die ein gepromptetes Tool nie stellt:
Projekte scheitern an dieser Stelle, wenn der Prototyp diese Fragen überspringen soll. Der Unterschied ist nicht KI oder keine KI. Der Unterschied ist die Ingenieursarbeit dahinter: Architektur, Sicherheit, Tests, Betrieb.
- Welche Technologie ist die richtige für dein Projekt, und trägt sie auch in drei Jahren?
- Wie stellst du sicher, dass Daten nur die sehen, die sie sehen dürfen?
- Woher weißt du, dass das System auch im Grenzfall das Richtige tut?
- Wenn es nachts um 3 kracht: Merkt es jemand, und weiß man, warum?
Muster 3: Architektur, die nur bis zum Go-Live denkt
Der Launch ist nicht das Ziel. Er ist der Anfang des teuren Teils. Eine Technologiewahl, die nur bis zum Go-Live gedacht ist, wird danach zur Hypothek: Jede Erweiterung wird teurer, jede Integration ein Risiko.
Die kritischste Stelle sind die Nähte: ERP, Identity, Legacy-APIs, Bestandssysteme. An diesen Integrationen sterben Projekte häufiger als an der Software selbst.
Am teuersten wird es beim Komplettneubau auf einen Schlag. Große Rewrites scheitern, weil in gewachsenen Systemen Regeln und Sonderfälle stecken, die in keiner Doku stehen, sondern nur im Code. Ein Big-Bang wirft dieses Wissen weg und baut es teuer neu.
Woran du es früh erkennst
Kein Projekt meldet sein Scheitern an. Aber es sendet Signale, meist schon in den ersten Wochen:
Jedes einzelne Signal ist behebbar. Gefährlich wird es, wenn mehrere zusammenkommen und niemand sie ausspricht.
- Es gibt Dokumente und Folien, aber nach Wochen nichts, das im Browser läuft.
- Niemand kann in einem Satz sagen, was die erste Version können muss.
- Der Festpreis stand fest, bevor jemand den Scope verstanden hat.
- Tests, Monitoring und Betrieb werden auf „nach dem Launch“ verschoben.
- Deine interne IT sitzt nicht mit am Tisch.
Was ehrlich dagegen hilft
Früh bauen statt lange konzipieren. Ein kleiner Slice, der in wenigen Wochen im Browser lebt, beantwortet mehr Fragen als jedes Konzept. Du siehst früh, ob die Richtung stimmt, und kannst korrigieren, solange es billig ist.
Mit der internen IT arbeiten, nicht an ihr vorbei. Sie kennt das Haus, die Systeme und die Sonderfälle. Ein externes Team bringt Tempo und Umsetzungskraft dazu. Gegeneinander verliert man beides.
Die unangenehmen Fragen zuerst stellen: Was passiert unter Last? Wer sieht welche Daten? Wer merkt es, wenn etwas ausfällt? Ein Team, das diese Fragen von sich aus stellt, ist ein gutes Zeichen. Eines, das sie auf später verschiebt, ist das Frühwarnzeichen schlechthin.
Software-Projekte scheitern selten an einer einzelnen falschen Entscheidung. Sie scheitern daran, dass zu lange niemand fragt, ob das Ding schon trägt. Diese Frage kostet nichts. Sie früh zu stellen, ist der billigste Teil des ganzen Projekts.