Praktisches & Grundsätzliches zur Informatik

Warum scheitern Projekte?

Wenn Projekte scheitern, gilt meistens ...

  • Niemand nimmt ganz bewusst die Rolle Requirements Manager wahr (d.h. es gibt kein stets aktuelles, nach jedem Meeting mit dem Kunden fortgeschriebenes Papier "Anforderungen an die Lösung".
  • Zu wenig Sorgfalt bei der Aufwandschätzung (d.h. es gab keine 3 Personen, die unabhängig voneinander den wahrscheinlichen Projektaufwand abgeschätzt haben).
  • Kein passendes Change Management ("passend" ist es nur dann, wenn man nicht voraussetzen muss, dass dem Kunden von Anfang an all seine Anforderungen wirklich bis ins Detail hinein präsent waren – "passend" bedeutet, mit Changes leben zu können, ihre Kosten aber stets SOFORT kommunizieren zu können).
  • Zu wenig Verständnis für Änderungswünsche des Kunden (was aber i.A. erst dann eintritt, wenn das Team – weil es gegen einen oder mehrere der oben genannten Punkte verstoßen hat – in eine zunehmend schwieriger werdende Projektsituation gerät und dann Änderungswünsche des Kunden zunehmend – bewusst, oft aber auch nur unbewusst – abzublocken versucht.
  • Treten in einer solchen Situation dann noch massiv Wartungsprobleme auf, ist das Projekt mit großer Sicherheit zum Scheitern verurteilt. Wartungsprobleme sind stets Folge von

    • wenig durchdachten Anforderungen (sprich: zu wenig Requirements Management) und/oder
    • wenig durchdachter Implementierungsmethodik (als Folge davon, dass es keinen Systemarchitekten gab, der zugleich auch für Systemtest verantwortlich zeichnete — und zwar wirklich bis hin zum Projektende).


Faktoren, die Misserfolg herbeiführen, sind demnach:

  • ungeeignetes Requirements Management
  • ungeeignetes Vorgehen zur Aufwandschätzung
  • ungeeignetes Change Management
  • zu wenig durchdachte Implementierungsmethodik
  • Systemarchitekt kümmert sich zu wenig um Testbarkeit

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: