Nach dem Projektabsturz wissen es alle besser: Der Vorstand sagt: "Die IT-Berater waren unqualifiziert." Der IT-Leiter behauptet: "Anwender und Vorstand haben mich im Stich gelassen." Die Anwender monieren: "Unser IT-Leiter hat, ohne uns zu fragen, nur das Neueste und Teuerste gekauft." Und die externen Berater kritisieren: "Es gab weder eine Ist-Analyse noch ein Soll-Konzept." Aussagen, die Rolf-Dieter Kempis und Jürgen Ringbeck von McKinsey bei der Einführung eines Auftragsabwicklungssystems gesammelt haben.
Die Klagen der vier beteiligten Parteien sind typisch für gescheiterte Projekte. Vorstand, CIO, Anwender und Berater schieben die Schuld hin und her. Einig ist man sich allein in der Trauer um das verlorene Geld. Was die Standish Group 1995 in ihrer "Chaos"-Studie erstmals veröffentlichte und in allen Nachfolge-Untersuchungen bestätigt fand, ist auch in der KPMG-Studie "What went wrong?" von 1997, in einer Befragung der Computerwoche aus demselben Jahr und in der "Tech Republic"-Studie der Gartner Group von 2000 zu lesen. Es wird sich wohl auch mit den Zahlen decken, welche die Deutsche Gesellschaft für Projektmanagement (GPM) auf der Jahrestagung der International Project Management Association (IPMA) vom 4. bis 6. Juni in Berlin präsentieren will. Auch danach scheitern die meisten Projekte. Die Zahlen schwanken leicht, da Forscher Misserfolg unterschiedlich definieren und Befragte sich variantenreich aus der Affäre ziehen.
Als Faustformel kann jedoch gelten: Ein Viertel aller IT-Projekte scheitert total, die Hälfte hält Zeit- und Budget-Rahmen nicht ein. Trotz verbesserter Lehre und Forschung ändert sich an diesen Zahlen im Großen und Ganzen nichts, wie Heidi Heilmann aus der Fachgruppe "Projektmanagement" der Gesellschaft für Informatik bestätigt. Die scheinbar immanent bedingte Fehlerquote schiebt die Professorin auf die zunehmende Internationalisierung der IT-Sondereinsätze, mit der auch Komplexität und Ansprüche enorm steigen würden. Wider besseres Wissen tappen die Verantwortlichen in die immer gleichen Fallen: Sie wehren sich nicht rechtzeitig, wenn die Anforderungen an ihre Projekte nicht mehr zu erfüllen sind; sie schaffen es nicht, Vorstand und Benutzer hinreichend einzubinden; sie unterteilen die komplexen Aufgaben nicht und glauben, auf eine fortlaufende Bewertung der Risiken verzichten zu können.
Heidi Heilmann, Universität Stuttgart: "Gibt man Menschen zu lockere Termine, neigen sie dazu, unnötig perfektionistisch oder weniger intensiv zu arbeiten."
Dass dies nicht so sein muss, zeigt das Beispiel der Basler Versicherung, wo die Zahl der Projektkrepierer inzwischen auf acht Prozent gesunken ist. Seit drei Jahren praktiziert Informatikleiter Martin Strobel, was er zuvor als Berater bei der Boston Consulting Group gepredigt hat. Sein Projektmanagement fußt auf einer Risikoeinstufung der rund 200 Sondereinsätze, die seine Abteilung pro Jahr durchführt. Davon landen etwa 10 in der Kategorie "High Risk", 60 bis 70 im Bereich "Middle Risk" und rund 120 in der Schublade "Low Risk".
Die Kategorisierung klärt bei der Basler, auf welcher Ebene der Projektverantwortliche angesiedelt sein muss. Low Risks darf schon ein Abteilungsleiter abwickeln, Middle Risks gehen an Hauptabteilungsleiter, und für die High Risks ist immer ein Vorstand zuständig. Die Zahl der brenzligen IT-Einsätze kann also schon deshalb nicht beliebig wachsen: "Mehr als zwei Projekte schafft kein Vorstand", sagt Strobel. Wann immer seine Abteilung zu einer Aktion mit geschäftskritischem Effekt gerufen wird, kann er darauf bauen, dass auch ein Mitarbeiter aus dem höheren Management ein klares Commitment dazu abgegeben hat. Heilmann betont: "Generell ist für den Erfolg wichtig, dass das Management im Lenkungsausschuss, in der Instanz, die ihn einrichtet, und in den Fachbereichen das Projekt erkennbar unterstützt."
Weniger Führungskräfte, mehr Erfolg
Die Erklärung für diese empirisch ermittelte Erkenntnis lässt sich auch auf ein anderes Gesetz zurückführen, das den Namen des IBM-Entwicklers Frederick Brooks trägt: Mit zunehmender Größe eines Projektteams steigt danach der Koordinations- und Kommunikationsaufwand überproportional an. Brooks fand dies in den 60erJahren heraus, als er bei IBM für die Entwicklung der Großrechnersysteme vom Typ 360 zuständig war. Heilmann empfiehlt den Betroffenen, sich an dieses Gesetz zu erinnern, wenn sie in der Endphase eines Projekts das Team vergrößern wollen, um den Zeitplan noch einzuhalten: "Der Fortschritt tendiert gegen null, wenn die bisherigen Projektbeteiligten die neuen ein-arbeiten und dazu ihre Tätigkeit unterbrechen müssen."
Und noch ein Grundsatz hält die Stuttgarter Professorin (im Ruhestand) für Projektleiter parat: Nach C. Northcote Parkinson nimmt sich jeder Mensch für eine Arbeit so viel Zeit, wie er zur Verfügung hat. Der britische Beamte Parkinson formulierte diese Erkenntnis, nachdem er eine Weile den Niedergang des British Empire beobachtet hatte und gleichzeitig die Zahl der Angestellten in der Kolonialbehörde wachsen sah. Laut Heilmann trifft Parkinson’s Law auch auf die Arbeit an IT-Projekten zu: "Gibt man Menschen zu lockere Termine, neigen sie dazu, unnötig perfektionistisch oder weniger intensiv zu arbeiten." Zugleich warnt sie: "Regelmäßige Überstunden über einen längeren Zeitraum reduzieren die Mitarbeitermotivation. Unter keinen Umständen dürfen sie von vornherein in die Terminplanung einbezogen werden."
Neun von zehn Projekten verändern sich
Zwar fehlt hier noch ein schöner Name, aber in der Welt der IT-Projekte könnte noch ein anderes Gesetz postuliert werden: Caper Jones, Chef-Forscher beim PM-Software-Anbieter Artemis, hat herausgefunden, dass sich in 90 Prozent aller Fälle die Anforderungen während der Projektlaufzeit verändern. Um dieses Problem zu begrenzen, rät er, IT-Lösungen gemeinsam mit den End-benutzern zu entwickeln, wodurch sich die Hälfte der Änderungswünsche eliminieren lasse. Prototypen könnten weitere 10 bis 25 Prozent der Änderungen in eine frühe Phase verlagern. Für große Projekte empfiehlt Jones so genannte Change Control Boards aus Management, Benutzerrepräsentanten und Entwicklern.
Letztlich ist es also die Kommunikation der beteiligten Parteien, die über den Erfolg eines Projekts entscheidet. "Sie müssen Zwischentöne hören können", sagt Karin-Beate Elbrechter, die fünf Jahre Projekt-Controlling bei der Commerzbank betrieben hat. "Es liegt nicht an Beratern oder Werkzeugen. Da können sie MS-Projects, Excel oder ein Schmierblatt nehmen." Wichtiger sei, dass sich alle Beteiligten immer wieder über die Ziele abstimmen, über Projektrisiken offen sprechen und konkrete Maßnahmen einleiten. Nur so lasse sich verhindern, was Elbrechter ihre wichtigste Erfahrung in puncto Kostentreiber nennt und was in vielen Unternehmen gängige Praxis ist: "Projekte werden grün geredet. Sie scheitern per Definition nicht, weil die Budgets immer angepasst werden."