In den letzten Jahren habe ich immer wieder gesehen, dass das Thema Agilität in aller Munde ist und in vielen Großkonzernen sehr stark gepusht wird. Viele Mitarbeiter, welche nun agil sein und arbeiten sollen sind allerdings bzgl. der neuen agilen Welt irritiert und unsicher.
Was also bedeutet agiles Projektmanagement und Agilität wirklich?
Ist es tatsächlich immer bzw. soviel besser als das traditionelle Projektmanagement und war wirklich bis vor kurzem alles schlecht?
Was sind die Unterschiede gegenüber traditionellem Vorgehen und wie können ggf. beide Ansätze gemeinsam zum Projekterfolg beitragen?
Dies und weiteres soll im Folgenden erläutert werden.
Agiles Projektmanagement stammt aus der Softwareentwicklung, findet dort heute noch zum größten Teil Anwendung ist aber auch in anderen Projektarten anwendbar.
Entwickler in der Softwareentwicklung stellten bereits Anfang der neunziger Jahre fest, dass traditionelle Projektmanagementmethoden nicht für Ihre komplexen Projekte geeignet waren. Sie benötigten flexiblere Prozesse und Tools, um den Projekterfolg sicherzustellen.
Die Grundsätze des agilen Projektmanagements wurden im Februar 2001 im agilen Manifest durch 17 führende Vertreter der Agilen Softwareentwicklungs-Bewegung festgelegt. Das agile Manifest besagt folgendes:
Wir zeigen bessere Wege auf, Produkte1 zu entwickeln, indem wir es selbst tun und anderen dabei helfen, es zu tun. Durch unsere Arbeit sind wir zu folgender Erkenntnis gekommen:
- Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen
- Funktionsfähige Produkte2 haben Vorrang vor ausgedehnter Dokumentation
- Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen
- Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.
Wir erkennen dabei sehr wohl den Wert der Dinge auf der rechten Seite an, wertschätzen jedoch die auf der linken Seite noch mehr.
In dieser Übersetzung des Agilen Manifests wurden folgende Verallgemeinerungen vorgenommen, um zu verdeutlichen, dass die agilen Prinzipien auch in Projekten außerhalb der Softwareentwicklung anzuwenden sind.
- 1 Produkte hieß ursprünglich nur Software
- 2 „Funktionsfähige Produkte“ hieß ursprünglich nur „lauffähige Software“.
Wie im agilen Manifest dargelegt ist es das Ziel, die Produktentwicklung durch agile Methoden effizienter und das Projektmanagement flexibler und schlanker zu machen. SCRUM steht heute für den am weitesten verbreiteten agilen IT-Projektmanagementansatz.
Traditionelles Projektmanagement zeigt auf, mit welchen Tools und Prozessen gearbeitet werden soll. Agiles Projektmanagement zeigt demgegenüber auf wie man arbeiten soll.
In traditionellen Projektmanagementansätzen stehen Prozesse und Tools im Fokus, mit denen aufgezeigt werden soll was getan werden muss, um Projekte erfolgreich umzusetzen. Dem gegenüber zeigt agiles Projektmanagement auf wie vorzugehen ist. Dabei gibt agiles Projektmanagement den Teams mehr Freiheiten in Ihrer Arbeit und stellt das Ergebnis in den Mittelpunkt und nicht den Weg dorthin.
Traditionelles Projektmanagement ist statischer, agiles Projektmanagement reagiert flexibel auf Änderungen.
Im traditionellen Projektmanagement verfolgt man unter anderem das Ziel den gesamten Projektverlauf bestmöglich im Vorfeld zu planen, um so auch zeitliche und budgetäre Risiken zu reduzieren. Zu vermerken ist hier, dass dies in der Regel bei komplexen Projekten mit vielen Unsicherheiten kaum möglich ist und dementsprechend die Planung nicht aufgeht.
Im agilen Projektmanagement verfolgt man demgegenüber die Philosophie, dass komplexe Projekte immer Änderungen mit sich bringen, welche man nicht voraussehen kann und man deshalb diesen „Changes“ positiv und offen begegnen sollte.
Als „agiler“ Leitsatz, welcher die Sinnhaftigkeit des agilen Vorgehens unterstreicht, gilt in diesem Zusammenhang:
Je mehr du nach Plan arbeitest desto mehr bekommst du das, was du geplant hast aber nicht das, was du brauchst.
Um dem zu begegnen stellt agiles Projektmanagement den Kundenmehrwert in den Fokus und passt sich ändernden Anforderungen flexibel an.
Weitere Unterschiede zwischen dem traditionellen und agilen Vorgehen sind folgende:
Wie die Übersicht verdeutlicht verfolgen traditionelles und agiles Projektmanagement unterschiedliche Ansätze. Während sehr strukturiertes und prozessorientiertes Vorgehen im traditionellen Ansatz verfolgt wird, stehen unter anderem die Bereitstellung von schnellem Kundennutzen durch rasche „Produktauslieferung“ und der Glaube an das Team, statt an Prozesse, beim agilen Projektmanagement im Fokus.
Agiles Projektmanagement bedient sich des Weiteren folgender Kernattribute:
Wie bereits erwähnt, konzentriert sich agiles Projektmanagement mehr auf den Umsetzungs- als auf dem Planungsaspekt. Projektdokumentation wird dementsprechend auch so schlank wie möglich gehalten, um nicht unnötig Ressourcen zu verschwenden. Schnelle Auslieferung funktionierender Software bzw. allgemein die „Produktauslieferung“ ist das Ziel und soll beim agilem Vorgehen für sich selbst sprechen.
Agiles Projektmanagement ist für komplexe Projekte zu empfehlen, welche Unsicherheiten mit sich bringen.
Traditionelle Entwicklung ist riskant, wenn Unsicherheit im Raum steht, d.h. wenn Sie und der Auftraggeber noch gar nicht genau wissen was Sie umsetzen wollen und wie lange das Projekt vermutlich dauern wird.
Um eine Abschätzung vor Beginn eines Projekts treffen zu können, ob Sie agil oder traditionell vorgehen sollten, bietet sich eine Einordnung Ihres Projekts in ein Stacey Diagramm an.
Sollten am Anfang des Projekts noch nicht alle Anforderungen sowie die Art des Vorgehens bzgl. der anzuwendenden Technik bzw. Methode klar sein, so ist ein agiles Vorgehen zu empfehlen. Beispielhaft wäre hier ein komplexes IT-Projekt zu nennen, welches viele Abhängigkeiten mit sich bringt. Ein solches Projekt würde sich abhängig vom Grad der Unklarheiten oben rechts im Stacey Diagramm wiederfinden. Als Leitsatz gilt hier:
Je komplexer und „unklarer“ ein Projekt ist, desto agiler sollte es gemanaged werden.
Dem gegenüber sind traditionelle Projektmanagementmethoden für Projekte zu empfehlen, die nur von kurzer Dauer sind und/oder gut abgeschätzt werden können.
Beispielhaft wäre für ein Projekt, welches mit traditionellen Projektmanagementansätzen gut geleitet werden könnte, die Erstellung einer „einfachen“ Webseite mit einem WordPress Theme zu nennen. Ein solches Projekt würde sich unten Links im Stacey Diagramm wiederfinden.
Lessons learned aus Theorie und Praxis:
Ganz ohne Strukturen, Prozesse und Tools aus dem traditionellen Projektmanagement geht es nicht aber zu viel des Ganzen hemmt die Produktivität.
Agiles Projektmanagement und die damit einhergehenden Methoden lassen sich in vielen Bereichen erfolgreich einsetzen und mit den traditionellen Vorgehensweisen kombinieren!
Aus meiner Erfahrung heraus sind demnach in Abhängigkeit vom Projektumfeld, d.h. der Organisationsform, Kultur und der Art des Projekts, die am besten passendsten Methoden und Werkzeuge aus beiden Ansätzen zu verwenden und zu kombinieren.
Hybrides Projektmanagement ist somit oft der beste Weg.
Ein Water- Scrum-Fall Vorgehen kann z.B. gut helfen Ihr Umfeld auf den Weg hin zu mehr Agilität zu bringen und beide Welten zu kombinieren. Sie planen Ihr Projekt „grob“ langfristig und erfüllen damit Ihre Unternehmensvorgaben für die Budgetfreigabe aber setzen es dann iterativ um.
Entwickeln Sie Ihr Unternehmen/Ihren Bereich dem entsprechend auch ruhig einfach iterativ im Projektmanagement weiter.
Sollten Sie Unterstützung bei der Optimierung Ihres Projektmanagements benötigen melden Sie sich sehr gerne bei uns. Wir würden uns freuen Ihnen bei Ihren Herausforderungen zur Seite zu stehen.
Ich hoffe Ihnen die beiden, doch sehr umfangreichen, Welten des traditionellen und agilen Projektmanagements etwas näher gebracht zu haben.
Was sind Ihre Erfahrungen? Haben Sie Fragen? Wir freuen uns auf Ihre Nachricht an info@rpma.de und über Ihre Kommentare.
Ich wünsche Ihnen allen viel Erfolg bei Ihren Projekten.
Mit besten Grüßen Ihr,
Xavier Reckers
PMP; MSP; PSM; PSPO; PMI-ACP; Diplom Volkswirt
Dieser Artikel ist bereits 2014 verfasst und auf venit.com publiziert worden. Die hier publizierte Version wurde fünf Jahre später, d.h. in 2019 nur geringfügig angepasst.
Neueste Kommentare