Den Absturz verhindern

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 ProjekteProjekte. 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 ProjektmanagementProjektmanagement (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. Alles zu Projekte auf CIO.de Alles zu Projektmanagement auf CIO.de

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."