Immer mehr gewinnt die Agile Projektmanagement-Bewegung an Fahrt. Viele meiner Kunden sehen Agile nicht mehr nur als reines Softwareentwicklung-Thema, sondern weiten den Gedanken auf immer mehr Felder aus. So wollen nun auch Hardware-Entwickler, klassische Maschinenbauer oder auch einfach administrative Bereiche die Vorteile agiler Methoden anwenden und ausprobieren. Dabei wird das Thema oft als Glaubenskrieg oder Lagerkampf angelegt. Langjährige Projektmanager schwören auf klassische Wasserfall-Methoden oder lineare Vorgehensmodelle, jüngere Generationen kennen diese gar nicht mehr und propagieren Agile Ansätze.

Ich möchte heute inspiriert von D. Snowden, Cognitive Edge und R. Stacey das Thema Projektmanagement vor dem Hintergrund des Managements unter Komplexität ein wenig näher aufgreifen und ein versöhnliches “Beides” vorschlagen.

Vorgehensweisen in Projekten

Generell möchte ich folgende Vorgehensweisen in Projekten für meine Betrachtung unterscheiden:

  • Traditionell/ “Wasserfall”: Idee dieses Ansatzes ist es, vor Beginn der Ausführung das komplette Projekt zu planen und dann nach Plan umzusetzen. Dabei geht es vor allem um viel Erfahrung und ein gutes, bekanntes Ziel, um einen möglichst guten Plan zu erstellen. Bei der Umsetzung werden vorrangig Abweichungen zum Plan gemessen und versucht, diese ggf. durch Gegensteuern zu beheben.
  • Time-boxing/ Rollierende Meilensteine: Im Rahmen dieses Vorgehens wird anerkannt, dass eine detaillierte Planung zu Beginn des Projektes nicht möglich ist. Vielmehr wird das Projekt in einzelne Phase unterteilt. Dabei werden diese durch Meilensteine getrennt und das Projekt immer (nur) bis zum nächsten Meilenstein detailliert ausgeplant. Die Sprints in SCRUM stellen eine Extremvariante dieses Vorgehens dar, bei dem die Zeitfenster immer gleich bleiben und recht kurz sind und die Meilensteine unabhängig von der inhaltlichen Fertigstellung (time-boxing).
  • Iterativ/ Experimentell: Gelingt auch ein time-boxing nicht mehr, tastet man sich in diesem Vorgehen eher schrittweise voran. Dabei können auch mehrere “save-to-fail” Experimente gestartet werden, um zu sehen, welcher Weg der beste ist, da dies nicht wirklich offensichtlich ist. Es geht somit mehr um soziale Interaktion, gemeinsames Nachdenken und gemeinsames Vortasten. Eine typische Methodik hierzu ist das Pair Programming in der Softwareentwicklung oder auch ein stark Team- und Workshop-orientiertes Vorgehen generell.
  • Action: Diese Vorgehensweise zielt im Projekt darauf ab, zunächst zu handeln und dann zu sehen, ob die Handlung in eine richtige Richtung führt. Dies ist der Krisenmodus von Projekten, bei dem es darum geht unerwartete Situationen zu meistern und kurzfristige Krisen zu lösen.

Diese Vorgehensweisen können wir unschwer zu erkennen, den Domänen des Cynefin-Frameworks zugeordnet werden. Auch kann man sie gut mit den von mir bereits vorgestellten Projekttypen verknüpfen.

Unterschiedliche Situation unterschiedliches Vorgehen

Eine nützliche Differenzierung bietet auch die Verknüpfung mit der Stacey-Matrix (Zimmerman, 2001). Dabei erfolgt in einer Matrixdarstellung eine Differenzierung nach zwei Dimensionen:

  • Agreement: Gemeinsame Einigkeit und ein gemeinsames Verständnis der Beteiligten zu einer Situation/ Problemstellung. Je uneiniger die Stakeholder und/ oder das Projektteam zu einer Fragestellung sind, desto schwächer bis gar nicht vorhanden ist ein gemeinsames Mind-Model der Beteiligten. je höher die Übereinstimmung, desto klarer ist ein gemeinsames Bild der Situation.
  • Objectives/ Results: Ziele und und gewünscht Ergebnisse sowie der Weg dorthin kann unterschiedlich klar ausgeprägt sein. Bei Projekten, die bereits in ähnlicher oder gleicher Weise in der Vergangenheit abgewickelt wurden, weisen einen hohen Grad an Klarheit auf. Neuartige Projekte hingegen weisen eher einen geringen Grad an Klarheit auf.

Anhand der beiden Dimensionen lassen sich nun die vorgestellten Vorgehensweise von Projekten zuordnen. Je höher der Grad an Unklarheit und je geringer das gemeinsame Verständnis der Stakeholder, desto mehr macht es Sinne weg von der Wasserfall-Methode, hin zu eher interaktiven Methoden zu wandern.

 

230_1

Das Schema macht folgende Aspekte deutlich:

  • Je nach Projektart und Stakeholder-Situation können unterschiedliche Planungs- und Steuerungsmethoden im Projekt angebracht sein.
  • Projekte können im Projektverlauf über die Zeit im Portfolio “wandern” und so kann es vorkommen, dass man Teile zu bestimmten Zeiten eher traditionell plant, zeitweise eher mit vielen Meetings arbeiten muss und manchmal auch einfach “firefighting” betreibt. Und dass dies auch so ok ist.

Leider lassen aktuelle Projektmanagement-Standards in Großkonzernen dies oft noch nicht zu. Einige meiner Kunden, die ich in “Entschlackungsprozessen” und “Entwicklungsprozessen” ihrer PM Standards unterstützt habe, sehen inzwischen bereits erste Wirkungen bei ihren Projektleitern und in ihren Projekten, so dass dieser Gedanke nützlich scheint.

Sources:

Zimmerman, B. (2001). Ralph Stacey’s agreement & certainty matrix. Schulich School of Business, York University, Toronto, Canada, available on http://www. plexusinstitute. org/edgeware/archive/think/main_aides3. html.