Wir haben in den letzten Jahren mehrere Projekte übernommen, die anderswo gescheitert waren. Was dabei auffällt: Die Ursachen wiederholen sich, und sie liegen fast nie in der Technik.
Die acht Ursachen
1. Es wurde nie gemessen, was der Prozess heute kostet
Ohne Ausgangswert gibt es keinen Erfolgsmassstab. Das Projekt endet, alle sind mässig zufrieden, und niemand kann sagen, ob es sich gelohnt hat. Beim nächsten Vorhaben fehlt dann das Vertrauen.
Gegenmittel: Eine Woche messen, bevor irgendetwas gebaut wird. Wie viele Vorgänge, wie viele Minuten, wie viele Fehler.
2. Die erste Version war zu gross
Die häufigste Ursache. Es wird sechs Monate gebaut, bevor jemand aus dem Betrieb die Software benutzt. Bei der Übergabe zeigt sich, dass zentrale Annahmen falsch waren — und das Budget ist weg.
Gegenmittel: Erste nutzbare Version nach vier bis acht Wochen, auch wenn sie schmal ist. Lieber ein Bereich, der funktioniert, als fünf, die halb fertig sind.
3. Der Auftraggeber hatte keine Zeit
Softwareprojekte brauchen Beteiligung. Wenn die Person, die den Prozess kennt, nur alle drei Wochen eine Stunde hat, wird geraten statt geklärt. Das rächt sich beim Test.
Gegenmittel: Vor Projektstart festlegen, wer wie viel Zeit einbringt. Für ein mittleres Projekt sind zwei bis vier Stunden pro Woche realistisch. Wer das nicht aufbringen kann, sollte das Projekt verschieben.
4. Der Prozess war nie geklärt
Software bildet ab. Wenn der Ablauf im Betrieb unklar ist, wird die Software es auch. Wir hören regelmässig in Woche drei: «Das machen wir eigentlich je nach Kunde anders.» Genau solche Sätze treiben Aufwand.
Gegenmittel: Den Ablauf aufzeichnen, bevor gebaut wird. Wo verschiedene Personen verschiedene Antworten geben, muss zuerst intern entschieden werden.
5. Die Nutzer wurden nicht gefragt
Die Geschäftsleitung bestellt, die Mitarbeitenden sollen benutzen. Wenn niemand mit ihnen gesprochen hat, entsteht Software, die am Alltag vorbeigeht — und wird umgangen.
Gegenmittel: Zwei Personen aus dem Team von Anfang an einbinden, mit echter Mitsprache, nicht nur zur Information.
6. Der Umfang wuchs unkontrolliert
Jede Woche eine kleine Ergänzung. Einzeln sind sie harmlos, zusammen sprengen sie das Budget. Ohne bewusste Entscheidung ist irgendwann das Geld weg und die Kernfunktion unfertig.
Gegenmittel: Änderungswünsche sammeln statt sofort umsetzen. Am Ende jedes Ausbauschritts gemeinsam entscheiden, was hineinkommt und was dafür wegfällt.
7. Die Datenübernahme wurde unterschätzt
Ein Klassiker. Die Anwendung ist fertig, dann stellt sich heraus, dass die Altdaten inkonsistent sind: doppelte Kunden, fehlende Pflichtfelder, drei Schreibweisen derselben Firma. Die Bereinigung dauert Wochen.
Gegenmittel: Datenqualität in Woche eins prüfen, nicht in Woche zwanzig. Und die Bereinigung als eigene Position budgetieren.
8. Niemand war für die Einführung zuständig
Die Software ist fertig, funktioniert, und wird nicht benutzt. Weil niemand geschult hat, niemand nachgefragt hat und die alten Wege weiterhin offen standen.
Gegenmittel: Eine verantwortliche Person im Betrieb benennen, mit Zeit dafür. Und die alten Wege nach der Übergangszeit tatsächlich schliessen.
Das Muster dahinter
Sechs der acht Ursachen liegen beim Auftraggeber, nicht beim Entwickler. Das ist keine Schuldzuweisung — es ist der Hinweis darauf, wo die Hebel liegen.
Ein guter Anbieter erkennt diese Risiken und spricht sie an, auch wenn es unangenehm ist. Wenn wir im Erstgespräch merken, dass der Prozess ungeklärt ist oder niemand Zeit hat, sagen wir das. Ein Projekt, das unter diesen Bedingungen startet, schadet beiden Seiten.
Die häufigste Ursache für gescheiterte Software ist nicht schlechter Code, sondern eine erste Version, die zu spät in echte Hände kommt.
Frühwarnzeichen
- Nach acht Wochen gibt es noch nichts, das man anklicken kann
- Statusmeldungen bestehen aus Prozentangaben statt aus benutzbaren Funktionen
- Sitzungen dauern länger, weil dieselben Fragen wiederkehren
- Der Entwickler hat seit vier Wochen nicht mit einem Nutzer gesprochen
- Die Liste offener Punkte wächst schneller, als sie abgearbeitet wird
- Das Wort «eigentlich» taucht in Beschreibungen häufig auf
Was man tun kann, wenn es schon brennt
- Anhalten. Weiterbauen verschärft das Problem. Zwei Wochen Pause kosten weniger als zwei Monate in die falsche Richtung.
- Bestandsaufnahme. Was läuft tatsächlich, was ist halbfertig, was existiert nur als Absicht?
- Auf die Kernfunktion zurückschneiden. Was ist das eine, das nutzbar sein muss? Alles andere zurückstellen.
- Diese eine Funktion produktiv nehmen. Auch unvollständig. Echte Nutzung bringt Klarheit, die keine Sitzung liefert.
- Danach neu entscheiden. Mit dem Wissen aus dem Einsatz, nicht mit dem alten Plan.
Wir haben mehrere solche Sanierungen begleitet. In den meisten Fällen war das bereits Gebaute brauchbarer als angenommen — es fehlte nur die Entscheidung, etwas Unfertiges tatsächlich einzusetzen.
Häufige Fragen
Was ist der häufigste Grund für gescheiterte Softwareprojekte?
Eine zu grosse erste Version. Wenn sechs Monate gebaut wird, bevor jemand aus dem Betrieb die Software benutzt, zeigen sich falsche Annahmen erst, wenn das Budget verbraucht ist.
Wie viel Zeit muss der Auftraggeber einbringen?
Für ein mittleres Projekt zwei bis vier Stunden pro Woche von der Person, die den Prozess kennt. Wer das nicht aufbringen kann, sollte das Projekt verschieben statt es scheitern zu lassen.
Was tun, wenn ein Projekt bereits aus dem Ruder läuft?
Anhalten, Bestandsaufnahme machen, auf die eine Kernfunktion zurückschneiden und diese produktiv nehmen — auch unvollständig. Echte Nutzung bringt Klarheit, die keine Sitzung liefert.
Ihr Projekt besprechen?
Das Erstgespräch ist kostenlos und unverbindlich. Wir nennen eine Bandbreite für Aufwand und Kosten — und sagen ab, wenn es sich nicht lohnt.
Kontakt aufnehmen