Es gibt kein agiles Projektmanagement! – Oder doch?

„… ‘Agiles Projektmanagement‘. Das geht gar nicht!“ Dieser Kommentar als Reaktion auf einen Post auf LinkedIn von Ayelt Komus bezüglich meines Buches zum Unified Project Management Framework, UPMF, hat mich angeregt, diesen Blogbeitrag zu verfassen. Agiles Projektmanagement geht nicht … das würde ich gerne mal systematisch reflektieren.

Dazu schaue ich mir zunächst einmal die Definition bzw. die charakterisierenden Eigenschaften von Projekten an. Aus den vielfältigen Definitionen des Begriffs Projekt (DIN 69901-5, PMBoK Guide, PRINCE2 etc.), die ich an dieser Stelle nicht wieder alle zum x-ten Male aufführen will, lassen sich folgende typische Charakteristiken für organisatorisch-technische Maßnahmen in Form eines Projekts ableiten:

Schaut man sich diese Merkmale an, werden einige prägende Dinge klar − z.B. dass ein Projekt ein definiertes Ende hat. Umgekehrt bedeutet es, dass z.B. eine kontinuierliche Software-Entwicklung kein Projekt im klassischen Sinne darstellt. (Das definierte Ende einer Maßnahme ist als motivierender Faktor für das Team m.E. nicht zu unterschätzen. Meine Teams und mich jedenfalls hat diese Zielerreichung stets angespornt. Ich bin überzeugt, dass die DevOps-Teams langfristig unter dieser fehlenden abschließenden Zielerreichung leiden werden.)

Die Rahmenbedingungen eines Projekts werden typischer Weise in Form des sogenannten Magischen Dreiecks, bestehend aus Leistung/Scope, Budget/Kosten sowie Zeit/Terminen, ausgedrückt. Genauer gesagt drückt das Magische Dreieck die Rahmenbedingungen der Projektierung bzw. Projektdurchführung aus: Das Projektteam soll nach Möglichkeit die Projektziele im durch das Magische Dreieck gesetzten Rahmen erreichen.

Das zentrale Paradigma der Agilität ist die Gewährleitung von Flexibilität und Adaptivität im Verlaufe einer Maßnahme … auf dem Weg zum übergeordneten Ziel, welches z.B. durch eine Produkt- oder Projektvision festgelegt sein kann. Es stellt sich die Frage, unter welchen Umständen Flexibilität und Adaptivität dabei das prägende Element sein sollten.

In Anlehnung an Cynefin-Framework von Snowden lassen sich dazu grob drei relevante Problemsituationen ausmachen:

Ideal: Der Projektkontext ist einfach. Die Dimensionen des Magischen Dreiecks sind a priori zu ermitteln und im Allgemeinen auch gut einzuhalten im Verlaufe des Projekts. Im Grunde ist das Projekt mit Routine abzuarbeiten (was natürlich relativ selten vorkommt). Beispiel: Kleineres Umzugsprojekt.

Klassisch: Der Projektkontext ist kompliziert. Die Dimensionen des Magischen Dreiecks sind a priori zu analysieren und als Grundlage für die Projektdurchführung zu beplanen. Hierfür wird in der Regel Expertenwissen benötigt, mit dem das Problem gehandhabt werden kann. Plan & Control ist der zielführende Ansatz, d.h. ggf. wird Projektplan im Laufe der Durchführung im Rahmen der Projektsteuerung angepasst. Beispiel: Einführung einer Standardsoftware (im Standard!).

Instabil: Der Projektkontext ist unsicher, instabil. D.h. die Bedingungen des Projekts sind gekennzeichnet durch eine strukturelle oder zeitliche Volatilität (Dynamik). Das bedeutet, dass die Entwicklungen und Abhängigkeiten im Projekt kaum handhabbar bzw. vorhersehbar sind. Inspect & Adapt, d.h. empirische Prozesskontrolle, ist der zielführende Ansatz. Beispiel: Digitale Transformation eines Unternehmensbereichs.

Im instabilen Kontext ist also sinnvoller Weise ein Vorgehen zu wählen, das Flexibilität und Adaptierbarkeit genuin ermöglicht. Das Vorgehen und die Steuerung sollten agil gewählt werden, die Maßnahme bleibt aber ein Projekt!

Die Forderung nach Flexibilität und Adaptivität im Vorgehen bedeutet keinesfalls, dass das Magische Dreieck nicht mehr von Bedeutung ist. Wie z.B. von Opelt/Gloger/Pfarl/Mittermayr (Der agile Festpreis) oder Timinger (Modernes Projektmanagement) dargelegt, verändern sich „lediglich“ die Ecken des Magischen Dreiecks, die festgezurrt bzw. flexibel sind. Die folgende Abbildung veranschaulicht dies schematisch.

D.h. im agilen Vorgehen halten wir den Scope, also den avisierten Leistungsumfang, flexibel und führen im Projektverlauf ein Design-to-Budget durch, dass durch das verfügbare Budget (z.B. die personelle Kapazität) und die Terminsetzung (z.B. durch die Anzahl der durchgeführten Iterationen) festgelegt sind. Sind letztere nicht festgelegt, das Ende also per se offen, dann können wir in der Tat nicht von einem Projekt sprechen, s.o.

Anmerkung: Je nach Dimension der Unsicherheit sind einzelne oder auch alle „Ecken“ des Dreiecks betroffen. Wenn alles völlig unsicher ist, dann sind wir in einem chaotischen Umfeld, in dem andere Vorgehensweisen adäquat sind (oder, dass man besser vermeiden sollte).

Wie schon gesagt: Agilität bedeutet im Kern, die Umsetzung von Flexibilität und Adaptivität. Andere typische Elemente, wie selbstorganisierte Teams, Kundenbeteiligung, Daily Stand Ups etc., haben genuin nichts mit Agilität zu tun! Sie sind vielmehr als Gestaltungsprinzipien oder Praktiken agilen Vorgehens und Management zu identifizieren, dienen also aufgrund ihrer Eigenschaften und ihres Wertbeitrags dazu, agil arbeiten zu können.

Niemand hindert uns daran, diese Prinzipien und Praktiken auch im plangetriebenen Kontext anzuwenden! Vielfach – nicht immer – helfen sie, das Projekt erfolgreich durchzuführen. Dabei sollten sinnvoller Weise ggf. auch Abstufungen zum Einsatz kommen. Z.B. ein partizipativer Führungsansatz, wöchentliche strukturierte Abstimmrunden oder Lessons Learned (Retros) nach jeder Projektphase etc.

Das Unified Project Management Framework ist ein kompaktes Referenzmodell für Projektmanagement – unabhängig von der Art des Ansatzes und nur den genuinen Aspekten von Projekten verpflichtet (s.o.). Je nach Kontext sollte und kann das Modell mit den Elementen der klassischen oder agilen Vorgehensweisen ausgestaltet bzw. umgesetzt werden. In jedem Fall dient es als Checkliste für ein professionelles Projektmanagement.