Warum Projekte wirklich scheitern (Es ist fast nie der Code)

Wenn ein Projekt stirbt, beschuldigt die Obduktion meist dieselben drei Verdächtigen: den Code, das Team oder die Deadline. Selten geht jemand zurück zu den Wochen vor dem Programmieren — und genau dort wurde die fatale Entscheidung getroffen.

Dieser Beitrag handelt von der am wenigsten glamourösen Wahrheit des Engineerings: Die meisten Projekte scheitern nicht, weil sie schlecht gebaut wurden. Sie scheitern, weil das Falsche gebaut wurde — und niemand es bemerkte, bis das Falsche bereits fertig war.

Die Entscheidung fällt, bevor jemand programmiert

Eine Anforderung ist eine Wette darauf, was die Welt braucht. Jede Codezeile, jeder Test, jede Entwurfsentscheidung ist eine Folge dieser Wette. Geht die Wette daneben, ist alles, was darauf aufbaut, falsch — egal wie gut es gebaut ist.

Deshalb ist der günstigste Ort zum Scheitern der Anfang. Eine falsche Anforderung, die am ersten Tag auffällt, kostet ein Gespräch. Dieselbe falsche Anforderung nach dem Launch kostet ein Team, ein Produkt oder ein Unternehmen.

Die Nacharbeits-Kostenkurve

Barry Boehms klassische Arbeiten zur Ökonomie des Software-Engineerings haben quantifiziert, was jeder Ingenieur ohnehin spürt: Die Kosten zur Behebung eines Fehlers steigen stark, je später man ihn findet. Ein Anforderungsfehler beim Schreiben kostet etwa 1x. Beim Entwurf 3–6x. Beim Programmieren 10x. Beim Testen 15–40x. Und nach der Auslieferung oft 100x oder mehr.

Über die genauen Multiplikatoren streitet man, über die Form nicht. Mit jedem Schritt weg vom Moment des Schreibens wird der Fehler teurer — denn er hat mehr Arbeit hervorgebracht, und all diese Arbeit muss wieder rückgängig gemacht werden.

Wo die Fehler entstehen

Studien zur Fehlerherkunft kommen immer wieder zum selben Schluss: Die meisten Fehler werden nicht im Code verursacht — sie entstehen in den Anforderungen und werden im Code nur entdeckt. Der Code ist der Tatort, nicht der Täter.

Ein im Test gefundener Fehler ist meist eine Anforderung, die von Anfang an mehrdeutig, fehlend oder falsch war. Es brauchte nur die gesamte Pipeline, um ihn sichtbar zu machen.

Drei Wege, wie schlechte Anforderungen Projekte töten

• Das Falsche bauen — das Team setzt perfekt das falsche Ziel um, und der Erfolg wird zum Scheitern.
• Mehrdeutigkeit als Nacharbeit — jede unausgesprochene Annahme wird zu einem entdeckten Dissens, bezahlt nachdem der Code existiert.
• Spätes Entdecken — je später eine falsche Anforderung auftaucht, desto mehr versenkte Kosten zieht sie mit sich.

Die Lösung ist langweilig

Die Lösung ist kein Werkzeug, kein Framework und keine Methodik. Es ist die unglamouröse Disziplin, aufzuschreiben, was wahr sein muss, bevor irgendjemand etwas baut — und sich darauf zu einigen. Diese eine Gewohnheit ist der wirksamste Hebel in einem Projekt, denn sie verschiebt den Punkt des Scheiterns dorthin, wo er am günstigsten ist.

Sie brauchen keine 200-seitige Spezifikation. Sie müssen nur die falschen Annahmen finden, bevor sie zum falschen System werden.