Praktisches & Grundsätzliches zur Informatik

Warum Projekte scheitern, Requirements and Change Management, Aufwandschätzung, Testbarkeit

Warum scheitern Projekte?

Wenn Projekte scheitern, gilt meistens ...



Faktoren, die Misserfolg herbeiführen, sind demnach:

Der derzeitige Trend weg vom Wasserfallmodell hin zur sogenannten agilen Methodik (dem stärkeren Betonen spiralartiger Vorgehensweise) ist nichts anderes als die Einsicht, dass das Nachdenken über Anforderungen eben nicht mit Abnahme des Pflichtenhefts enden darf. Es muss erlaubt sein, sie während des gesamten Projektes stets neu zu überdenken — und insbesondere zu präzisieren.

Dass das bei schon vereinbartem Festpreis auf Schwierigkeiten stößt, ist klar. Notwendig ist es dennoch, da sonst Irrwege vorprogrammiert sind und die Akzeptanz des entstehenden Produktes aufs Spiel gesetzt wird.

Man erkennt:

Konsequentes Requirements Management und professionelles Change Management
müssen einander gezielt ergänzen.


Wo eines von beiden zu kurz kommt, kann man nicht davon ausgehen, dass über die gesamte Projekt­laufzeit hinweg den Interessen aller Stakeholder — Anwender, Auftraggeber, Auftragnehmer — gleich gut Rechnung getragen wird.


Interessant zu wissen ist ferner:








Quelle: The Standish Group, Chaos 2000 Suryey







Bis in die jüngste Vergangenheit hinein scheint sich daran nichts geändert zu haben, denn (siehe [1], [2] und [3]):

Statistics found in the Standish Group's annual Chaos summary suggest that in 2009 nearly one in four (24 per cent) IT projects within public and private sector organisations across the globe were considered failures, either having been cancelled before they were completed or delivered but never used.

Gartner figures from 2008 also suggest a 20 per cent failure rate on average, with 25 per cent of those applications falling down on functionality issues, 15 per cent because of cost variations, 20 per cent due to cancellation and 18 per cent because they were delivered too late to be of any use.

  • zu hohe Komplexität des Vorhabens und/oder
  • zu wenig professionelles Vorgehen selbst durch Teams die Branche anführender Unternehmen
    Noch weitere Beispiele: 10 ERP Software Project Failures in 2011
    und Software project horror stories of 2012.

    Andere noch nennt Ernest Wallmüller in Risikomanagement für IT- und Software-Projekte:






    Quelle: Standish Group (2013)


    Leider sagen uns weder die Zahlen der Standish Group noch die von Gartner, in welcher Projektphase genau die gescheiterten Projekt als gescheitert erkannt wurden. Es zu wissen wäre wichtig, da es ja durchaus richtig sein kann, ein Großprojekt abzubrechen, wenn schon früh klar wird, dass es eher nicht gelingen wird.


    Wer nicht scheitern will, muss auch über Projektmanagement nachdenken. Man beginne mit: