Warum 9 von 10 Software-Projekten zu spät kommen
Eine ehrliche Analyse der Gründe — und unsere drei harten Regeln dagegen.
Die Statistik ist düster: nur ~30% aller Software-Projekte werden in time und in budget geliefert (Standish Group, CHAOS Report). Bei Custom-Software ist die Quote noch schlechter. Wir haben uns vorgenommen, dauerhaft auf der „guten" Seite zu sein. Hier ist, wie.
Die drei echten Gründe, warum Projekte kippen
1. Scope wird im Verlauf erfunden, nicht festgelegt
Der Klassiker. Das Projekt startet mit „eine App für Reservierungen" und wird unterwegs zu „eine App für Reservierungen, plus Loyalty, plus Kassenintegration, plus Lieferservice, plus, plus, plus". Jede einzelne Erweiterung klingt sinnvoll. In Summe schlucken sie das Projekt.
Unsere Regel: Scope wird in einem 1-Tages-Workshop festgenagelt. Was danach dazu kommt, ist Phase 2 — schriftlich, mit eigenem Preis und eigenem Datum. Kein Schmuggel.
2. Keine echte Discovery — direkt ins Designen
„Wir machen mal ein Figma" ist verlockend. Es sieht schnell schön aus. Aber Figma kann lügen — Edge Cases, Daten-Modelle, Integrationen, Rechtliches. Das alles taucht erst auf, wenn der Entwickler in Woche 3 plötzlich „wir müssen reden" sagt.
Unsere Regel: Discovery vor Design. Wir bauen erst ein technisches Skelett (Datenmodell, Auth, kritische Integrationen), dann legen wir UI drüber. Dauert 2-3 Tage länger am Anfang, spart 2-3 Wochen am Ende.
3. Zu viele Stakeholder, kein Entscheider
Vier Personen müssen das Logo absegnen. Drei davon haben verschiedene Meinungen. Niemand sagt das Logo final. Eine Woche tot.
Unsere Regel: Im Kick-off einigen wir uns auf genau eine Person als Entscheider. Die hat das letzte Wort. Andere Stimmen werden gehört, aber binden nicht. Wenn wir das nicht hinkriegen, fangen wir nicht an.
Was bei uns funktioniert hat
Beispiel Helia Health (Tele-Health-Plattform, 11 Wochen, on time, on budget):
- Workshop am Tag 1, Scope schriftlich am Tag 3.
- Technisches Skelett (Patient-Auth, Triage-API, PVS-Schnittstelle) bis Tag 14.
- UI obendrauf ab Tag 15, Demo wöchentlich.
- Entscheider: der CTO. Andere Stimmen wurden gehört, gebunden hat nur er.
- Phase 2 (mehrere Praxen, White-Label) wurde während Phase 1 nicht angefasst — kein einziger Mal.
Was du daraus mitnimmst
Wenn dein nächstes Projekt zu spät kommt, liegt es selten am Code. Es liegt fast immer an einem dieser drei Fehler — die alle vor dem ersten Code passieren. Wenn du sie vermeidest, gehst du in eine andere Liga.
Termine halten ist ein Prozess, kein Glücksspiel. Wer das verinnerlicht hat, liefert ab.
Neue Insights direkt im Postfach
Ehrliche Notes aus Engineering, AI und echten Cases. Etwa 1× im Monat, jederzeit abbestellbar.
Hilft das deinem Vorhaben weiter?
Lass uns 30 Min sprechen — konkret zu deinem Case.
Auch lesenswert
Wie wir aus einem Chat-Widget einen Conversion-Funnel gemacht haben
Ein Floating-Chat-Widget allein konvertiert nicht. Das mussten wir lernen — und sechs Pattern nachbauen, damit aus klick-scroll-schließ ein messbarer Funnel von Open bis Erstgespräch wurde.
Wenn der eigene Bot-Schutz dich aussperrt
Wir haben heute BotID auf /api/chat aktiviert. Erste echte Lektion kam nicht von einem Angreifer — sondern von unserem eigenen Verifikations-Script, das prompt 403'te. Was wir daraus mitgenommen haben.
Kein Funnel, kein Sales-Rep. Du redest mit mir.
Ich höre dir 30 Minuten zu, stelle ein paar gezielte Fragen und sage dir am Ende ehrlich, ob — und wie — wir dir helfen können. Wenn nicht, bekommst du mindestens zwei Empfehlungen, wer's könnte.
- 30 Min, kein Sales-Pitch
- Konkrete Einschätzung deines Cases
- Fixpreis-Indikation am Ende des Calls