Drei echte Spezifikationen, die ein Projekt getötet haben (und was sie kosteten)

Der Sinn dieser drei Geschichten ist nicht, über berühmte Katastrophen zu staunen. Es ist zu sehen, dass alle drei aus demselben Grund scheiterten: Eine Anforderung war mehrdeutig, fehlend oder nie eingefroren — und die Rechnung kam Monate oder Jahre später, vervielfacht.

Jeder Fall hat eine Lektion. Wer alle drei versteht, beherrscht den größten Teil des Anforderungsmanagements.

Mars Climate Orbiter — die Einheit, die nie aufgeschrieben wurde

1999 verlor die NASA den Mars Climate Orbiter, eine Raumsonde im Wert von über hundert Millionen Dollar, beim Einschwenken in die Umlaufbahn. Die Untersuchung fand eine Ursache, die zu klein klingt, um wahr zu sein: Die Software des einen Teams meldete Schubimpulse in Pfund-Kraft-Sekunden, während die Navigationssoftware auf der anderen Seite Newton-Sekunden erwartete.

Zwei Teams, eine Schnittstelle, zwei Einheitensysteme — und niemand hatte aufgeschrieben, welches die Schnittstelle verwendet. Das war kein Programmierfehler. Es war eine Schnittstellenspezifikation, die nie vereinbart wurde, sodass jede Seite eine andere, vernünftige Annahme traf.

Die Lektion: Eine Schnittstelle ist eine Anforderung wie jede andere. Legen Sie Einheiten, Formate und Verträge schriftlich fest, denn „das weiß doch jeder“ ist genau der Weg, wie zwei Teams am Ende uneins sind.

Das Gepäcksystem von Denver — Komplexität, der niemand zugestimmt hat

In den 1990er-Jahren verpflichtete sich der neue Flughafen von Denver zu einem vollautomatischen Gepäcksystem — tausende Wagen auf einem Schienennetz, die jedes Gepäckstück durch den Flughafen sortieren und transportieren. Das System sollte am ersten Tag funktionieren. Das tat es nicht. Gepäck ging verloren, verklemmte sich und wurde zerrissen. Die Eröffnung verzögerte sich um 16 Monate, und der Fehlschlag kostete Hunderte Millionen Dollar, bevor große Teile des Systems zugunsten manueller Abfertigung aufgegeben wurden.

Das Anforderungsproblem war keine einzelne schlechte Zeile. Es war ein Umfang, der nie realistisch spezifiziert oder eingefroren wurde: Die Anforderungen wuchsen weiter, die Komplexität wurde unterschätzt, und es gab vor Baubeginn keine vereinbarte Baseline dessen, was „fertig“ bedeutet.

Die Lektion: Komplexität vervielfacht sich. Ein System, das nicht durch einen schriftlich vereinbarten Umfang begrenzt ist, wächst, bis es übersteigt, was irgendjemand liefern kann.

FBI Virtual Case File — die Spezifikation, die nie einfror

Anfang der 2000er-Jahre versuchte das FBI, Papierakten durch ein digitales Fallverwaltungssystem zu ersetzen. Nach Jahren der Arbeit und rund 170 Millionen Dollar wurde das Projekt eingestellt — es erreichte nie einen nutzbaren Zustand.

Die wiederkehrende Ursache in jedem Post-Mortem war dieselbe: Die Anforderungen hörten nie auf, sich zu ändern. Es gab keine Instanz, die sagen konnte „das ist die Spezifikation, und danach bauen wir“. Der Entwurf jagte ein bewegliches Ziel, bis das Projekt unter seiner eigenen Unruhe zusammenbrach.

Die Lektion: Eine Anforderung, die sich ständig ändert, ist keine Anforderung, sondern ein Vorschlag. Ein Projekt braucht eine eingefrorene Baseline — und einen kontrollierten Prozess für Änderungen — oder es wird nie ausgeliefert.

Dieselben drei Fehler, in jedem Projekt

Nehmen Sie die Raumsonde, den Flughafen und die Behörde weg — übrig bleiben drei Fehler, die in gewöhnlichen Teams jede Woche passieren:

• Eine Schnittstelle oder Einheit, die angenommen statt aufgeschrieben wurde.
• Ein Umfang, der wuchs, weil sich niemand auf eine Grenze einigte.
• Anforderungen, die sich ohne kontrollierten, dokumentierten Prozess änderten.