Sieben Thesen zum agilen Projekt-Management

Immer mehr Unternehmen möchten - und müssen - agil sein, auch im Projekt-Management (PM). Doch obwohl diese Methode offenbar eine gewisse Anziehungskraft ausübt, scheuen viele Projektleiter am Ende doch den Griff in den agilen Handwerkskasten, wenn es an die konkrete Umsetzung geht. Die Bedenken sind häufig berechtigt. Denn längst nicht jedes Projekt und vor allem nicht jedes Unternehmen sind für die vermeintlich selbststeuernde Methodik geeignet.

Dazu ein Beispiel: Ein Großunternehmen setzt ein Programm zur Evaluierung, Entwicklung und Einführung eines neuen IT-Systems auf. Das Programm mit 200 beteiligten Mitarbeitern gliedert sich in zehn Projekte mit bis zu je drei Teilprojekten. In neun Projekten kommen auf oberster Ebene Methoden des klassischen PM zum Einsatz, in einzelnen Teilprojekten auch agile Methoden. Das zehnte Vorhaben mit einem Budgetrahmen von rund 30 Millionen Euro wird komplett agil gemanagt.

Eine Zwischenbilanz nach drei Jahren ergibt Folgendes: Die neun auf oberster Ebene klassisch betriebenen Projekte sind durchweg erfolgreich. Zwar sind klassische Projektplanung und iteratives, agiles Vorgehen auf Teilprojektebene im Hinblick auf Zeitplanung und einheitliches ReportingReporting nicht immer einfach unter einen Hut zu bringen, aber am Ende funktioniert es meistens doch. Alles zu Reporting auf CIO.de

Risikofaktor agiles Projekt-Management

Der eindeutige Verlierer ist das komplett agil geführte Projekt. Während der gesamten Laufzeit macht es vor allem mit unklarer Kostenplanung, ständigen Nachforderungen in Sachen Budget und intransparenter Zeitplanung von sich reden und entwickelt sich schließlich zum Risikofaktor für den gesamten Release-Plan. Im konkreten Projekt kam es dadurch am Ende zu wesentlichen Abweichungen von der ursprünglichen Zeitplanung.

Doch was lief schief und was lässt sich daraus lernen? Die folgenden sieben Thesen geben Antworten auf diese Fragen.