Bald ist es wieder so weit: Die Standish Group verteilt Zeugnisse im Fach Projekt-Management. Der viel zitierte "Chaos Report" konstatiert jedes Jahr aufs Neue, dass nur ein Bruchteil der IT-Projekte erfolgreich abgeschlossen wird. Die Ursachen des Scheiterns sind immer wieder Gegenstand hitziger Diskussionen.

Zu den "üblichen Verdächtigen" gehört das Projekt-Management. Der allgemeine Tenor lautet: Projekt-Management-Methoden, die überall sonst gute Ergebnisse liefern, werden in der IT nicht richtig angewendet. Wäre dies wirklich die Problemquelle, so müssten IT-Organisationen, die diese Methoden "richtig" anwenden, erfolgreicher operieren als andere.

Diesen Zusammenhang untersuchten C.William Ibbs und Young-Hoon Kwak in ihrer Studie über den Return on Investment im Projekt-Management. Die Ergebnisse veröffentlichten sie zuletzt im Juni 2000 unter dem Titel "Calculating Project Management''s Return on Investment" im "Project Management Journal". Für die Bestimmung, was "rich-tiges" Projekt-Management ist, zogen sie den vom Project Management Institute (PMI) definierten Ansi-Standard "Project Management Body of Knowledge" (PMBoK) heran.

Überraschende Erkenntnis

In ihrer Studie untersuchten die beiden führenden Projekt-Management-Spezialisten 52 Organisationen auf den "Reifegrad" ihres Projekt-Managements. Dabei stellten sie - auch für Experten überraschend - fest: Ein Zusammenhang zwischen der Projekt-Performance und dem Reifegrad des Projekt-Managements ließ sich genauso wenig belegen wie eine Entsprechung zwischen dem Projekterfolg und dem für das Projekt-Management getätigten Aufwand oder der Zahl professionell ausgebildeter Projekt-Manager.

Wenn nun aber die Probleme nicht durch die falsche Anwendung einer Methode verursacht werden, dann liegt die Frage nahe, ob sie aus der Verwendung der falschen Methode resultieren. Gibt es eine Alternative zum herkömmlichen "Projekt-Management"?

Unsere heutigen, im PMBoK beschriebenen Projekt-Management-Methoden wurden vor allem von der Nasa entwickelt - im Zusammenhang mit Luft-und Raumfahrtprogrammen. Eine Studie der US-Behörde kam 1971 zu dem Ergebnis, dass sich diese Methodik auch auf andere Bereiche übertragen ließe. Allerdings sei eine sorgfältige Anpassung dringend erforderlich.

Zudem seien, so die Untersuchung weiter, den Einsatzbedingungen bei der Nasa vergleichbare Konditionen zu schaffen. Dazu zählten unter anderem eine straffe Management-Disziplin und eine konsequente Einhaltung der vorgesehenen Planungslogik. Solche Bedingungen sind aber nicht gerade charakteristisch für die meisten IT-Organisationen.

Misslungene Übertragung

IT-Vorhaben unterscheiden sich in mindestens drei Bereichen erheblich von einem Raumfahrtprojekt:

- Raumfahrtprojekte haben ein klar definiertes Ziel. Das macht es möglich, die zur Zielerreichung notwendigen Schritte festzulegen. Und für jeden dieser Schritte lässt sich der Aufwand relativ gut schätzen. In vielen IT-Projekten hingegen fehlt diese klare Zieldefinition.

- Organisationsbedingt sind die IT-Mitarbeiter meist gleichzeitig in mehrere Projekte involviert oder haben nebenher Routine-Aufgaben zu erledigen. So kommt es zu Ressourcenkonflikten.

- Die IT-Welt ist vergleichsweise dynamisch. Deshalb können sich die Ziele im Laufe eines Projekts ändern. Während einer Fahrt zum Mond wurde vermutlich nicht darüber diskutiert, ob vielleicht der Mars das bessere Ziel wäre.

Alternativen in Sicht

Sowohl der Aufwand als auch die zur Verfügung stehenden Ressourcen sind in der IT im Grunde "Unbekannte". Deshalb lässt sich die Projektdauer hier nicht einfach aus der Beziehung "Dauer gleich Aufwand dividiert durch Ressourcen" errechnen. Obwohl wir das wissen, steuern wir IT-Projekte größtenteils immer noch mit Luft- und Raumfahrtmethoden - und wundern uns, wenn das Projekt nicht "abhebt".

In den vergangenen Jahren gab es jedoch Fortschritte: Neue Projekt-Management-Methoden berücksichtigen die Besonderheiten von IT-Projekten. Interessant sind hier die "Critical-Chain"-Methode und die "agilen" Methoden in Verbindung mit Techniken des Risiko-Managements.

"Für die Erledigung einer Aufgabe benötigt man mindestens die zur Verfügung stehende Zeit." Dieses "Parkinsonsche Gesetz" hat fatale Konsequenzen: Ist der Aufwand für eine Aufgabe zu hoch eingeschätzt, so wird sie trotzdem nicht früher erledigt als geplant, sondern "rechtzeitig". Denn eine vorzeitige Fertigstellung hätte ja zur Folge, dass für ähnliche Aufgaben künftig weniger Zeit zur Verfügung stünde. Stattdessen wird die nicht benötigte Zeit für Aufgaben aus anderen Bereichen genutzt. Die Mitarbeiter betreiben also Multitasking.

In ihrem Zeitbedarf zu gering eingeschätzte Aufgaben werden aber selbstverständlich später beendet als geplant. Da sich die über- und die unterschätzen Aufgaben nicht ausgleichen können, sind Verzögerungen des Gesamtprojekts unvermeidlich. Erfahrene Projektmitarbeiter werden also in ihre Schätzungen immer eine Reserve einbauen. Und die wird "verbraucht" - auch wenn sie eigentlich nicht nötig gewesen wäre. Auf der Basis von Fälligkeitsterminen geplante Projekte dauern deshalb immer länger als notwendig. Außerdem reduziert das Multitasking der Projektmitarbeiter die Effizienz.

Die kritische Kette

Einen Ausweg bietet die Critical-Chain-Methode von Eliyahu Goldratt. Hier werden zeitliche Reserven auf der Aufgabenebene weitgehend eliminiert beziehungsweise durch einen Puffer auf Projektebene ersetzt. Zudem wirkt das Werkzeug der rekursiven Zeitplanung ("Backwards Scheduling") dem Multitasking entgegen. Damit hat Goldratt einen Lösungsansatz für ein Problem gefunden, das immer dann auftritt, wenn zeitliche und/oder finanzielle Budgets festgeschrieben sind.

Zu diskutieren ist eine solche "Beyond-Budgeting"-Lösung insbesondere im Controlling-Bereich. Eine Änderung der Planungslogik reicht nicht aus; sie muss mit einer Änderung des Führungsverhaltens einhergehen. Denn schließlich lassen sich die oben beschriebenen Effekte auch auf einen bestimmten Führungsstil zurückführen.

Agiles Projekt-Management

Für ein klassisch geführtes Projekt ist nichts so fatal wie eine Änderung der Planungsgrundlage. Sie bedeutet nicht nur, dass die Planung "umsonst" war, sondern auch, dass fast alle Kontrollmöglichkeiten verloren gehen. Im traditionellen Projekt-Management dienen sämtliche Steuerungsinstrumente der Planeinhaltung. Ändert sich die Planungsgrundlage, gerät folglich das Projekt "aus dem Ruder." Damit ist eine flexible Reaktion auf veränderte Kundenbedürfnisse in diesem Kontext beinahe ausgeschlossen.

Nun sind aber viele IT-Projekte zu Beginn überhaupt nicht detailliert planbar. Dies gilt nicht nur für Software-Entwicklungs-Vorhaben mit "unscharfen" Zielvorgaben, sondern für alle Projekte, bei denen die Ergebnisse rekursiv den Projektrahmen bestimmen. Ein Beispiel hierfür sind Kostensenkungsprojekte. Hier wird das Einsparpotenzial meist erst im Projektverlauf sichtbar, weshalb sich auch der Projektrahmen nur nach und nach definieren lässt.

Solche Projekte waren der Anlass für die Entwicklung "iterativer" Projektmodelle. Hier werden die Vorhaben in mehrere Teilprojekte zerlegt, von denen jedes in sich klassisch gesteuert wird. Eine konsequente Weiterentwicklung dieser Modelle sind die "agilen" Methoden, auch bekannt als "Extreme Programming", "Lean Development", "Scrum" etc. Dabei handelt es sich nicht - wie oft irrtümlich angenommen - um einen neuen "Programmierstil", sondern um einen neuen Projekt-Management-Ansatz. Er versucht, mehr Flexibilität zuzulassen, indem er weitgehend ohne Planung auskommt. Die Iterationszyklen dauern hier oft nicht länger als ein paar Tage, weshalb sie sich nicht mehr wie Teilprojekte behandeln lassen. Der Aufwand für die Planung eines so kleinen "Projekts" stünde in keinem Verhältnis zum Nutzen.

Gefahr der Spielwiese

Eine formale Methode zur Steuerung agiler Projekte gibt es nicht. Grundsätzlich widerspricht die Formalisierung dem agilen Ansatz. Stattdessen wird primär auf die "weichen Faktoren" vertraut. Damit droht jedoch die Gefahr, dass diese Methoden eine "Spielwiese" für IT-Mitarbeiter bleiben. Dem lässt sich mit geeigneten Steuerungsmechanismen entgegenwirken.

Da eine reduzierte Planung mehr Unsicherheit bedeutet, kommen hier quasi automatisch Methoden des Risiko-Managements ins Spiel. Mit dessen Mitteln lassen sich die Unsicherheiten transparent machen und eingrenzen. Das erleichtert die Entscheidung darüber, ob ein Projekt vielleicht doch eher klassisch gesteuert und damit detaillierter geplant werden muss. Zudem ermöglicht es die wirtschaftliche Steuerung agiler Projekte: Die Risiken werden quantifizierbar und die damit verbundenen Kapitalkosten im Verhältnis zum Nutzen berechenbar.

Prioritäten setzen!

Welche Methode ist aber nun die "richtige"? Auf diese Frage gibt es keine Standardantwort. Die Entscheidung hängt von der Unternehmenskultur und vom Arbeitsumfeld ab. Ein turbulentes Umfeld erfordert Flexibilität und Effizienz; "disziplinierte" Kunden werden hingegen mehr Sicherheit verlangen. Allerdings lassen sich Effizienz, Flexibilität und Sicherheit nicht gleichzeitig steigern.

Die oben dargestellten Ansätze sind auf vielfältige Weise zu maßgeschneiderten Systemen kombinierbar. Dadurch kann das Projekt-Management flexibler, sicherer oder auch effizienter gemacht werden. Die Konflikte zwischen den unterschiedlichen Stakeholder-Gruppen dürften mit einiger Sicherheit verschwinden, wenn das System zu den Bedürfnissen der Anwender passt und den Mitarbeitern gleichzeitig Luft zum Atmen lässt. (qua)

*Ulrich Conzelmann ist IT- und Management-Berater in Dettenhausen.

Hier lesen Sie ...

- weshalb sich die traditionellen Management-Methoden so schlecht auf IT-Projekte anwenden lassen,

- woran es liegt, dass IT-Projekte zwangsläufig länger dauern als geplant,

- welche alternativen Projekt-Management-Methoden es heute gibt,

- welche Rolle das Risiko-Management dabei spielt und

- warum sich die Frage nach der richtigen Methode nur individuell beantworten lässt.