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
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:
müssen einander gezielt ergänzen.
Wo eines von beiden zu kurz kommt, kann man nicht davon ausgehen, dass über die gesamte Projektlaufzeit 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.
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: