Großes Erstaunen ernte ich immer wieder, wenn ich in meinen Seminaren auf einen grundlegenden Unterschied zwischen klassischem (traditionellem) Projektmanagement und agilem Projektmanagement eingehe:
Projekte können durch die drei Eckpunkte "Leistungsumfang", "Zeit" und "Budget" beschrieben werden: Um eine bestimmte Leistung zu erbringen wird ein geschätzter Zeitrahmen und ein geschätztes Budget benötigt.
Abb. 1: Stakeholder-Erwartungen klassisch-agil
Im klassischen Projektmanagement ist der Leistungsumfang mit dem Vertrag fixiert. Falls sich etwas ändert, wird zuerst an den Stellschrauben "Zeit" und "Budget" gedreht. Ganz einfach: eine Elbphilharmonie bleibt eine Elbphilharmonie, sie wird nur eventuell etwas später fertig, und sie wird eventuell etwas teurer. Im agilen Projektmanagement hingegen ist der "Leistungsumfang" die Variable, während "Zeit" und "Budget" die festen Größen bilden.
Die Kommentare, die üblicherweise sofort aus dem Publikum kommen: Wer unterschreibt einen Projektvertrag, bei dem klar ist, was es kosten wird und wann es fertig sein wird, aber man nicht weiß, was man bekommt? Ich drücke genau diesen, vollkommen korrekt zusammengefassten Sachverhalt anders aus: In einem Projekt, bei dem zwar das große Ziel beschrieben ist, aber die Details noch nicht klar sind, wähle ich einen agilen Ansatz.
Hausbau: Projekt mit agiler und klassischer Phase
Sie wollen ein eigenes Haus bauen. Die Entwurfsphase, die Sie gemeinsam mit dem Architekten durchgehen, entspricht einem agilen Prozess: Sie wissen was Sie wollen, Sie wissen aber noch nicht genau, wie es am Ende aussehen soll. So wird Ihre Vorstellung zusammen mit dem Architekten in mehreren kleinen Schritten mithilfe von Entwurfsskizzen immer deutlicher formuliert, bis der Entwurf abgeschlossen ist.
Danach geht es in die Planungsphase und danach in die Bauphase. In diesem Beispiel entspricht der Entwurf einem agilen Vorgehen, das sich schrittweise mit vielen Abstimmungsmeetings dem Ziel annähert, während die Bauphase einem vorgeplanten linearen – klassischen Prozess entspricht, bei dem alle Eventualitäten im Vorfeld so gut wie möglich vorgeplant werden.
Dieses Beispiel verdeutlicht auch, dass nicht ein Vorgehen besser ist als das andere, sondern dass es auf die Aufgabe ankommt, wann welche Methode sinnvoll ist. Es muss also nicht immer agil sein.
An dieser Stelle ist es passend, kurz auf ein weiteres Vorurteil von Agilität einzugehen: agiles Projektmanagement wurde zwar durch Softwareentwicklung geprägt, wird aber heutzutage in allen Wirtschaftssektoren angewandt.
Das ist nur ein Ausschnitt aus dem Produkt Controlling Office. Sie wollen mehr?
Jetzt kostenlos 4 Wochen testen
Anmelden und Beitrag in meinem Produkt lesen