© saicle/Shutterstock.com
Kolumne: Zeit für PHP

Von gescheiterten IT-Projekten lernen


Laut einem Report des Project Management Institute (PMI) aus dem Jahr 2017 scheitern 14 Prozent aller IT-Projekte. Und zwar komplett. Von den übrigen Projekten, die nicht komplett scheitern, erreichen 31 Prozent nicht (alle) ihre Ziele, 43 Prozent überschreiten das geplante Budget und 49 Prozent liefern zu spät. Was in einem gescheiterten Projekt schlecht (oder was in einem erfolgreichen Projekt gut) lief, bleibt meist im Verborgenen, beziehungsweise das Wissen darum nur den Projektbeteiligten vorbehalten.

Damit nicht nur der individuelle Entwickler, das beteiligte Entwicklungsteam oder das betroffene Unternehmen aus der Projekterfahrung lernen kann, sondern auch unsere Industrie als Ganzes, bedarf es einer öffentlichen Diskussion von IT-Projekten. Das ist jedoch die Ausnahme und passiert viel zu selten. Beispielsweise dann, wenn eine 655 Millionen US-Dollar teure Raumsonde verloren geht. Oder wenn eine Fortune 500 Company (Hertz) eine andere Fortune 500 Company (Accenture) wegen eines gescheiterten IT-Projekts verklagt. Die Mars-Climate-Orbiter-(MCO-)Mission der NASA ist ein Beispiel für ein IT-Projekt, dessen Scheitern gut dokumentiert ist. Hierbei ging eine Sonde, die das Klima des Planeten Mars erforschen sollte, am 23. September 1999 aufgrund eines Einheitenfehlers im Navigationssystem verloren. Nur eine Woche später, am 30. September 1999, machte die NASA die Fehlerursache öffentlich: ein Teil des Teams hatte mit Inches, Feet und Pounds gerechnet, während der Rest des Teams mit metrischen Einheiten gerechnet hatte. Bemerkenswert ist folgende Aussage: „The problem here was not the error, it was the failure of NASA’s systems engineering, and the checks and balances in our processes to detect the error” [1]. Der technische Fehler, der zum Verlust der Sonde führte, wird also nicht als zugrunde liegende Ursache angesehen, sondern als Folgefehler von Unzulänglichkeiten im Entwicklungsprozess: zu wenig Kommunikation zwischen den Teams und fehlende Integrationstests.

Ist immer die Software schuld?

Im Oktober 2018 verunglückte ein Flugzeug des Typs Boeing 737 MAX 8 kurz nach dem Start in Indonesien (Lion Air Flug 610). Im März 2019 stürzte ein Flugzeug desselben Typs ebenfalls nur Minuten nach dem Start in Äthiopien ab (Ethiopian Airlines Flug 302). In beiden Fällen kamen alle Menschen an Bord ums Leben. In beiden Fällen war Software, das Maneuvering Characteristics Augmentation System (MCAS), die Ursache für den Absturz. Robert C. Martin, Softwareentwickler...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang