Laut der berüchtigten “Chaos-Studie” der Gesellschaft Standish Group scheiterten 2008 ca. 28% aller IT-Projekte. Obwohl die Ergebnisse der Studie etwas zweifelhaft sind (siehe beispielsweise den Artikel: “In die Tonne mit dem Chaos Report”), gibt es dennoch genügend Beispiele für gescheiterte Projekte; auch, oder gerade in den eigenen Reihen. Es stellen sich daher zwei Fragen. Erstens was heisst eigentlich: “ein Projekt ist gescheitert” und zweitens warum kommt es überhaupt so weit?
Der Begriff des Scheiterns
Die erste Frage ist meistens eine reine Definitionssache. Ein Unternehmen muss für sich selbst entscheiden, ab wann es ein Projekt als gescheitert betrachtet. Während im einen Unternehmen die Ueberschreitung eines Budgets um mehr als die Hälfte als Hinweis für ein Scheitern gilt, so sind die Grenzen in einem anderen Unternehmen wohlmöglich niedriger oder gar höher. Gemein sind ihnen allerdings die Faktoren, unabhängig davon, wie hoch diese über- bzw. unterschritten wurden. Folgende Faktoren können beispielsweise ein Projekt zum scheitern bringen:
- Starke zeitliche Verzögerung
- Nennenswerte budgetäre Ueberschreitung
- On Hold stellen eines Projektes auf unbestimmt Zeit
- Generell: Projektabbruch
Es kommt nicht selten vor, dass “tote Projekte” oft mehrere Jahre in einem Unternehmen umhergeschleppt werden. Solche verschleppten Projekte entstehen zum Beispiel, wenn sich Projektleiter nicht trauen, die Statusampel eines Projektes auf rot zu stellen. Oder, wenn an einem Projekt, das sich de facto nicht umsetzen lässt, verkrampft festgehalten wird. Solche “Projektleichen” verschwenden Ressourcen und kosten unnötig Geld. Um die Entstehung von “Projektleichen” zu verhindern, sollte ein Unternehmen Kriterien ausarbeiten, mit Hilfe derer sich verschleppte Projekte erkennen, von “gesunden” Projekten isolieren uns schlussendlich stoppen lassen.
Gründe für das Scheitern von Projekten
Die zweite Frage befasst sich mit den Ursachen. Warum kommt es überhaupt dazu, dass Projekte scheitern. Diese Frage kann nicht pauschal beantwortet werden. Die Faktoren variieren von Unternehmen zu Unternehmen. Es fällt jedoch auf, dass gewisse Muster immer wieder auftauchen. Der Projektmanagement-Experte Stefan Hagen hat vor einigen Monaten auf seinem Blog “PM-Blog” eine Umfrage zu diesem Thema gestartet [1]. Folgende fünf Gründe führen dabei die Skala an:
- Mangelhafte Kommunikation (ca. 70 Votes)
- Schlechte Projektvorbereitung und -planung (ca. 65 Votes)
- Mangelnde Ressourcenverfügbarkeit (ca. 53 Votes)
- Zu optimistische Annahmen (ca. 52 Votes)
- Unklare Rollenverteilung (ca. 51 Votes)
Bei näherer Betrachtung fällt auf, dass die angegebenen Gründe nicht ungewöhnlich bzw. unbekannt sind. Im Gegenteil! Mit den ersten beiden angeführten Punkten befasst sich jedes seriöse Lehrbuch über Projektmanagement. Die Punkte drei und vier sind Dauerbrenner; Ressourcen sind immer knapp und die Annahmen (v.a. von Oben) bezüglich einer, beinahe selbstverständlichen, raschen und problemlosen Projektumsetzung – oft fälschlich als Motivator eingesetzt – meist sehr hoch. Der fünfte und letzte hier erwähnte Punkt – die unklare Rollenverteilung – ist schlussendlich ein Ergebnis der schlechten Projektvorbereitung bzw. Projektplanung; also ein unmittelbares Resultat des zweiten Punktes.
Die aufgeführten Ursachen sind alles andere als unbekannt. Natürlich überwiegt je nach Unternehmen der ein oder andere Faktor. Letztendendes sind jedoch immer ein oder zwei der aufgelisteten Punkte, vorne mit dabei. Die (zumindest üblichen) Problemerzeuger sind also bekannt. Es wird recht bald klar, dass es sich “nicht um ein Wissensproblem, sondern um ein Umsetzungsproblem handelt”! (Stefan Hagen, [2])
Ein Bewusstsein für PM-Basics als mögliche Gegenmassnahme?
Was kann nun unternommen werden, um einem Scheitern vorzubeugen? Wie wir oben feststellen konnten, haben wir im Projektmanagement weniger ein Wissens- als ein Umsetzungsproblem. Im Klartext: man kennt die Probleme und auch die Mittel zu deren Lösung, kommt aber im Endeffekt nicht dagegen an. Woran liegt das?
Ich stelle oft fest, dass gewisse PM-Basics zwar vorhanden sind, aber nicht angewendet werden. Die Gründe für den Verzicht der Umsetzung vorhandenen Wissens sind verschieden. Sie reichen von “keine Zeit” bis hin zu “für diese Projektgrösse nicht notwendig”. Dabei beisst sich die Katze oft selbst in den Schwanz. Faktoren wie beispielsweise die eingangs erwähnte Projektgrösse, lassen sich oftmals ohne vorherige Recherche und der Anwendung einiger PM-Basics, gar nicht seriös einschätzen. Im Falle des Arguments der Projektgrösse haben wir also eine Begründung für das Weglassen von PM-Elementen, die auf einer reinen Annahme beruht. Manchmal wird im Uebereifer aber auch einfach mit der Projektumsetzung begonnen, bevor das Projekt überhaupt korrekt geplant wurde, oder bevor festgestellt werden konnte, wer ein Interesse an der Projektumsetzung hat und/oder wer eine Projektumsetzung vielleicht sogar vermeiden möchte (Stakeholderanalyse). Auch der umgekehrte Fall ist mir bereits begegnet. Es werden haufenweise PM-Methoden eingesetzt, die zwar nicht falsch angewendet werden, aber im Verhältnis zur geringen Projektgrösse zu einer Ueberregulierung führen.
Der Abbruch mancher Projekte hätte sich unter Umständen vermeiden lassen, wenn einige wenige PM-Basics eingehalten worden wären. Dazu zählen für den Projektleiter unter Anderem (die folgende Liste ist exemplarisch und hat natürlich keinen Anspruch auf Vollständigkeit / sie beruht nicht auf wissenschaftlichen Erhebungen sondern auf persönlichen Erfahrugnswerten):
- eine offene und transparente Kommunikation,
- den Einsatz von grundlegenden PM-Elementen (Projektauftrag, Pflichtenheft, Open Issue List, Status Report und Abnahmeprotokoll),
- das offene Aufzeigen und Ansprechen von Projektrisiken,
- eine frühzeitige Eskalation kritischer Situationen und
- keine Angst davor, die Statusampel auch mal auf rot zu stellen.
Aber nicht nur der Projektleiter ist in solchen Situationen gefragt. Auch für das Management sollten grundlegende “Richtlinien” gelten (zur folgenden Liste, siehe oben):
- Klare, eindeutige Definition von Rollen und Kompetenzen.
- Das ausreichende Zurverfügungstellen von Ressourcen.
- Und der Grundsatz: “management by exception”. Das heisst, ein Eingriff des Managements sollte nur in Ausnahmesituationen erfolgen (und das nur über eigens dafür eingerichtete Kommunikationskanäle – beispielsweise einem Steering Committee).
Fazit
Ein Bewusstsein für die oben genannten grundlegenden Elemente des Projektmanagements würde meines Erachtens in vielen Fällen das Scheitern von Projekten verhindern und schlussendlich bares Geld und oft auch Nerven sparen. Roland Sakel, CIO von Conergy, antwortete nach dem erfolgreichen Abschluss eines grossen und kritischen Projekts auf die Frage, warum er denn Erfolg hatte: “Ich könnte alle Grundsätze aus einem Lehrbuch für Projektmanagement zitieren, wenn ich den Erfolg erklären sollte” (“5 Erfolgsfaktoren fürs PM” auf http://www.cio.de). Dieses elementare Wissen wird aber nicht erst durch die reine Kenntnis, sondern erst durch eine aktive Anwendung zum Erfolgsfaktor!
