Die unausrottbaren Fehler des Projekt-Managements

Warum IT-Großprojekte immer wieder scheitern

14.05.2009 von Nicolas Zeitler
Projekt-Manager knausern beim Monitoring. Dabei sind die richtigen Kennzahlen, Offenheit und Erfahrung entscheidend, um IT-Projekte vor dem Scheitern zu bewahren. Warnsignale, typische Fehler, Rettungsmaßnahmen.
Dirk Möbus, Projekt-Manager, Roland Berger: "Projekt-Management wird nicht als Handwerk angesehen, sondern eher als Beiwerk."

Ob ein IT-Projekt ins Straucheln geraten wird, kann sich schon in der Anfangsphase zeigen, sagt Dirk Möbus vom Münchner Beratungsunternehmen Roland Berger Strategy Consultants. Frühwarnindikatoren sind für ihn zum Beispiel häufige Änderungswünsche nach Anlaufen eines Projekts. "Das ist ein Hinweis, dass ich vorab unsauber gearbeitet habe", erklärt Projekt-Manager Möbus. Ein weiterer Hinweis sei, wenn im Verlauf eines Projektes ein hoher Anteil von gesetzten Meilensteinen nicht erreicht wird.

Um den Verlauf von Projekten zu kontrollieren, setzen die Verantwortlichen Kennzahlen ein - doch nicht immer die richtigen. Möbus berichtet von Projekten, bei denen bestimmte Zeitziele anvisiert werden, aber nur Kosten-Kennzahlen überprüft würden. Damit seien Schwierigkeiten fast vorgezeichnet. "Das klingt ganz trivial, wird aber leider häufig falsch gemacht", sagt der Berater. Eine "stringente Planung" helfe zu ermitteln, welche Messgrößen wirklich wichtig für ein Projekt sind.

Es gibt kein "finales Dashboard"

Entscheidend sei zudem die Erfahrung der Projektverantwortlichen - auch bezogen auf das jeweilige Unternehmen. Denn: Ein Patentrezept oder gar ein "finales Dashboard" der richtigen Messgrößen gibt es nicht, wie Möbus sagt. Der Projektleiter müsse sich an vergleichbaren Vorhaben der Vergangenheit orientieren.

Doch erfahrene Projekt-Manager bleiben oft nicht lange im Projekt-Management, wie der Experte von Roland Berger beobachtet. Grundsätzlich werde dieses Arbeitsfeld nicht ausreichend wahrgenommen. "Es wird nicht als Handwerk angesehen, sondern eher als Beiwerk", sagt Möbus. Und wer einmal ein Projekt erfolgreich geleitet habe, werde oft schnell weiterbefördert auf eine Position, wo er mit dem Projekt-Management nicht mehr viel zu tun hat.

Möbus erklärt die hohe Fluktuation unter anderem mit dem rauen Wesen, das im Projekt-Management oft herrscht. "Wer darin gut ist, hat oft mit Dingen zu tun, die nicht gut laufen - was sehr frustrierend sein kann." Viele Unternehmen neigen deshalb dazu, erfolgreiche Projekt-Manager, quasi als Belohnung, auf normale, ruhigere Karrierestufen zu befördern, um sie nicht zu verlieren. "Das Wissen, das sie im Projekt-Management aufgebaut haben, ist dann für weitere Projekte verloren", so Möbus.

Kein Geld fürs Monitoring

Wo vielerorts ein breiter Erfahrungsschatz fehlt, ist es umso wichtiger, handfeste Größen zu überprüfen. Nicht immer seien dazu komplexe Überwachungsinstrumente nötig. Wichtig ist nach Ansicht des Beraters zunächst, dass Ressourcen speziell fürs Monitoring abgestellt werden. Faustformeln besagen, das zehn bis 15 Prozent des Projektvolumens für Steuerung und Reporting aufgewendet werden sollten. "Typischerweise fallen diese Kapazitäten aber viel zu gering aus, oft liegen sie nur bei zwei Prozent", sagt Möbus.

Häufig beobachtet er darüber hinaus mangelnde Transparenz. "Reporting ist nur sinnvoll, wenn der Status des Projekts ehrlich kommuniziert wird." Um festzustellen, ob niemand mogelt, sei Projektleitern und CIOs ein gesundes Misstrauen anzuraten. "Auch wenn ich zu Beginn eines Projekts nur Berichte bekomme, in denen alle Ampeln auf Grün stehen, sollte ich diese trotzdem kritisch hinterfragen", schlägt Möbus vor.

Der Abbruch darf nur die letzte Option sein, wenn ein Projekt aus dem Ruder gelaufen ist. Als Ansatz, ein angeschlagenes Vorhaben zu retten, schlägt Möbus vor, auf der Grundlage des schon Erreichten kleinere Lösungen anzupeilen. "Manchmal muss man einen großen, intransparenten und schwer steuerbaren Projekt-Moloch in kleinere Happen aufteilen", sagt Möbus.

Wenn das Projekt kippt

Die Verantwortlichen könnten das Vorhaben auf die Bereiche reduzieren, die einen schnellen Nutzen bringen. Damit ein solches "De-Scoping" gelingt, müssten sie hinterfragen, welche Teile des Projekts die entscheidenden seien. Eine andere Möglichkeit sei es, von anfangs vereinbarten Zeitzielen abzuweichen. Statt das gesamte Vorhaben bis zum Fristende umzusetzen, solle man bis dahin den Teil realisieren, der am frühesten gebraucht wird. "Besser sollte man zunächst einen ersten Teil liefern, der funktioniert, und erst einige Zeit später den zweiten Teil, der dann auch funktioniert", weiß Möbus aus Erfahrung.

Wenn ein Projekt auf den völlig falschen Weg geraten ist, kommt oft auch die Beziehung zwischen den Beteiligten in Schieflage. "Dann ist jemand gefordert, der das Ganze erst einmal wieder auf eine sprachfähige Ebene bringt", sagt Möbus. In den wenigsten Betrieben gebe es allerdings Mitarbeiter, die für diesen Fall als Mediatoren ausgebildet seien. Interne Mitarbeiter sind dafür oft nicht geschult. "Egal ob die Vermittler aus dem eigenen Haus oder von außerhalb kommen, wichtig ist, dass sie von beiden Seiten gleichermaßen anerkannt sind", sagt Möbus.

Keiner traue sich, ein Projekt anzutasten

Einen Abbruch nur als letztes Mittel zu sehen dürfe aber keinesfalls heißen, ihn kategorisch auszuschließen, erklärt der Berater. "Wir sehen allerdings oft, dass genau das geschieht", berichtet Möbus. Keiner traue sich, ein Projekt anzutasten. Auch in einer solchen Lage empfiehlt er Offenheit. Ein Vermittler müsse anschaulich machen, welche Folgen es hat, wenn ein großes Projekt über lange Zeit - oft Jahre - dahinsiecht.

In der Verantwortung, den Boden für ein fruchtbares IT-Projekt-Management zu bereiten, sieht er eindeutig den CIO: "Er hat die Enabler-Funktion, und er muss das Spielfeld bereiten."