© saicle/Shutterstock.com
PHP Magazin
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....

PHP Magazin
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.

Sebastian Bergmann


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....

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