Warum Projekte scheitern

Hier gesammelt ein paar Beispiele, warum auch in großen Teams Projekte scheitern können:

• Ariane 5 (1996): Die neue Rakete benutzte ein Programm der Ariane 4. Es speicherte einen aus der Geschwindigkeit berechneten Wert in einer 16-Bit-Ganzzahl mit Vorzeichen (−32 768 bis 32 767). Die schnellere Ariane 5 erreichte größere Werte. Die Lenkung fiel aus, die Rakete zerstörte sich etwa eine halbe Minute nach dem Start selbst. Was vorher fehlte: Niemand hatte das Programm mit den Werten der neuen Rakete getestet.
• Mars Climate Orbiter (1999): Ein Programm lieferte Pfund-Kraft-Sekunden (etwa 4,45 Newtonsekunden), die Schnittstelle verlangte Newtonsekunden. Die Sonde ging beim Anflug auf den Mars verloren. Was vorher fehlte: Die Vorgabe der Schnittstelle wurde nicht befolgt, ihr Test blieb unvollständig.
• CrowdStrike (2024): Ein fehlerhaftes Update eines Sicherheitsprogramms war 78 Minuten lang abrufbar. Rund 8,5 Millionen Rechner fielen aus (Schätzung des Herstellers des Betriebssystems). Was vorher fehlte: Das Update war nicht ausreichend getestet und ging gleich an alle Rechner statt zuerst an wenige.
• Mein Bildungsraum (seit 2020): Die Nationale Bildungsplattform sollte Bildungsangebote bündeln. 630 Millionen Euro standen bereit, 236 Millionen sind ausgegeben. Übrig geblieben ist im Wesentlichen eine digitale Zeugnismappe, ein Pilotbetrieb ist für April 2027 geplant. Was vorher fehlte: Ein klares Ziel und klare Verantwortung. Lehrende und Schüler:innen wurden kaum einbezogen.
• DIPSY (2005 bis etwa 2025): Bei der Datenübernahme in die Schulverwaltungssoftware in Baden-Württemberg entstand ein Fehler. Über 1.400 Lehrerstellen galten jahrelang als besetzt, obwohl sie es nie waren. Entdeckt wurde das erst rund 20 Jahre später. Was vorher fehlte: Eine Prüfung der Daten nach der Übernahme. Die Schul-IT war auf drei Ministerien verteilt.

Sechs typische Gründe

1. Ziel und Anforderungen sind unklar. Die Kund:in findet die Spielfigur zu langsam, in den Anforderungen steht nichts über ihre Geschwindigkeit.
2. Die Arbeit wird zu optimistisch geschätzt. Ein Team schätzt ein Level auf 8 Stunden und braucht 18.
3. Das Programm lässt sich nicht mehr ändern, ohne dass etwas kaputtgeht. Ein Gang im Level ist genau ein Feld (32 Pixel) breit, die Figur kommt nur hinein, wenn sie auf einer Feldgrenze steht. Bei einer Schrittweite von 4 Pixeln klappt das. Jemand ändert sie auf 5, und die Figur kommt nicht mehr hinein. Die Regel stand nirgends.
4. Es wird zu wenig geprüft, bevor Menschen das Programm benutzen. Ariane 5, Mars Climate Orbiter, CrowdStrike.
5. Es gibt keine technische Absicherung, die den Schaden eines Fehlers begrenzt. CrowdStrike. Ein Beispiel ist ein Zugriffsrecht, das festlegt, ob ein Programm Daten nur lesen oder auch ändern und löschen darf: Es schützt auch dann, wenn jemand eine Anweisung vergisst.
6. Niemand ist eindeutig verantwortlich. Mein Bildungsraum, DIPSY. Wer nicht weiß, wer entscheidet und wer prüft, bemerkt Fehler spät oder gar nicht.