Teil 9: Agiles Projektmanagement – die Ermittlung der passenden Vorgehensweise

Teil 9: Entscheidungsfindung – die Ermittlung der passenden Vorgehensweise

In den beiden letzten Teilen der RFC Blogreihe zum agilen Projektmanagement, haben wir uns mit dem Thema skalierte agile Methoden beschäftigt. Wann ist es aber überhaupt sinnvoll, sich für ein agiles Vorgehen zu entscheiden? Diese Frage wollen wir in diesem Blog beantworten. Außerdem wollen wir ein RFC Excel-Tool vorstellen, dass den Entscheidungsprozess unterstützt.

Entscheidungskriterien

Agiles Vorgehen hat sich mittlerweile etabliert und teilweise bereits das klassische Vorgehensmodell verdrängt. In vielen Unternehmen ist es möglich, ein Projekt je nach Rahmenbedingungen agil, klassisch oder hybrid durchzuführen. Alle Ansätze haben ihre Vorteile und Daseinsberechtigung. Theoretisches Wissen und praktische Erfahrung ermöglichen es heutzutage, bedarfs- und fallorientiert zwischen diesen beiden grundlegenden Vorgehensweisen zu unterscheiden und die für das Vorhaben sinnvollste Projektmanagement-Methode zu nutzen. Wichtig ist, dass die die Entscheidung nach möglichst objektiven Kriterien und nicht nach persönlichen Vorlieben einzelner Personen getroffen wird.

Als Entscheidungshilfe für eine nachvollziehbare Empfehlung zur Vorgehensweise kann der nachfolgend definierte Kriterienkatalog eingesetzt werden, um die grundlegende Wahl zwischen agilem und klassischem Vorgehen zu unterstützen:

• Unternehmensstruktur
  • Das Projektumfeld ist für agile Methoden geeignet
  • Erfahrung im Umgang bzw. Steuerung agiler Projekte
  • Flache Hierarien und Selbstkontrolle
• Projektorganisation
  • Projektleitung und Projektmitarbeiter sind (mehrheitlich) mit agilen Methoden vertraut
  • Agiles Projektmanagement soll erstmals genutzt bzw. erprobt werden, um damit Erfahrungen zu sammeln
  • Projektlaufzeit länger als 18 Monate
  • Teams bzw. Teilprojekte ≤ 12 Mitarbeiter
  • Projektgröße möglichst ≤ 50 Mitarbeiter
• Projektkomplexität
  • Anforderungen und Ziele sind unklar und unterliegen (wahrscheinlich) signifikanten Änderungen
  • Es handelt sich im Rahmen des CYNEFIN-Modells um komplexe (nicht aber um einfache oder komplizierte) Anforderungen und Ziele

Einige Kriterien lassen sich – wie z.B. die Projektdauer oder -größe – leicht bestimmen. Für andere Kriterien ist es nicht ganz so trivial, z.B. für die Bestimmung der Wahrscheinlichkeit signifikanter Änderungen oder auch die Einschätzung der Erfahrung mit agilen Methoden. Die folgende Checkliste dient dazu, die Diskussionen bei einigen Kriterien zu verkürzen und mögliche Entscheidungsverzögerungen zu verhindern. Sie bietet eine einfache und nachvollziehbare Möglichkeit der objektiven Situationsanalyse:

Organisatorisches Umfeld

• Projekt-Controlling und Lenkungsausschuss sind im Umgang mit agilem Vorgehen erfahren
• Es herrscht keine übertriebene Hierarchie-Gläubigkeit
• Die übergeordneten Manager sind nicht für Micro-Management bekannt

Erfahrungen mit agilen Projektvorgehen (z. B. Scrum)

• Der Projektleiter bzw. Product Owner besitzt agile Projekterfahrung und idealerweise Zertifizierungen
• Es besteht die Möglichkeit bzw. Zusage, einen erfahrenen agilen Coach (z.B. einen Scrum-Master) ins Team aufzunehmen
• Pro Team hat mehr als die Hälfte der Teammitglieder Erfahrung mit agilen Methoden

Projektlaufzeit

• Eine kurze Projektdauer ist als „neutral“ einzuschätzen und kein Argument für ein klassisches Vorgehen
• Bei Projekten über 18 Monaten ist die Dauer ein wichtiger Indikator für ein agiles Projektvorgehen, da die Wahrscheinlichkeit von grundlegenden technischen / prozessualen Veränderungen, oder von organisatorisch / strategischen Neuausrichtungen und den damit verbundenen Änderungen, während der Projektlaufzeit steigt

Projektgröße

• Große Projekte mit über 50 Mitarbeitern sollten – insbesondere, wenn wenig Erfahrung mit agilem Vorgehen vorhanden ist – eher klassisch durchgeführt werden, da aufgrund der erforderlichen Skalierung (z.B. Large Scale Scrum LeSS) deutlich mehr Erfahrung mit agilen Methoden erforderlich ist. Prinzipiell können aber auch große Projekte agil umgesetzt werden

Signifikante, unbekannte bzw. mit hoher Wahrscheinlichkeit sich ändernde Anforderungen

• Der Auftraggeber (Sponsor/Kunde) gesteht offen, dass wichtige Anforderungen zu einem späteren Zeitpunkt noch „nachgeschärft“ werden müssen und/oder ist bekannt dafür, auch im fortgeschrittenen Projektverlauf noch wichtige/umfangreiche Anforderungsanpassungen an das Projekt zu adressieren
• Die Anforderungsspezifikation zeigt noch erhebliche Lücken, die auch durch Rückfragen nicht vollständig geklärt werden konnten, so dass Interpretationsspielraum vorhanden ist
• Es gibt keine validierbaren Erfahrungswerte zur Einschätzung der Wahrscheinlichkeit von signifikanten Anforderungsanpassungen

Das CYNEFIN-Framework

Das Kriterium Projektkomplexität ist ein kritischer Punkt im Rahmen der Entscheidungsfindung. Komplizierte Projekte werden zu oft und zu schnell, aufgrund unzureichenden Fachwissens der Entscheider, als komplex eingestuft. Deshalb sollte die Einstufung immer kritisch hinterfragt werden – gerade dann, wenn diese als einziges Kriterium für oder gegen ein agiles Projektvorgehen angeführt wird. Hier ist der sogenannte CYNEFIN-Ansatz (Framework von Dave Snowden) hilfreich. Er untergliedert eine Situation, ein System, oder eben auch ein (Projekt-)Vorhaben in fünf abgrenzbare Bereiche. Dabei sind für die Fragestellung „agil oder klassisch“ die folgenden vier (5. Bereich: Disorder, Zustand des Nicht-Wissens) Bereiche relevant:

Einfache Projektvorhaben

• Geringe Volatilität/Dynamik und kleine Anzahl von Systemkomponenten
• Es ist klar, was wie zu tun ist
• Ursache-Wirkungs-Zusammenhänge sind bekannt und führen zu vorhersehbarem Verhalten
• Ähnliche Vorhaben wurden bereits erfolgreich durchgeführt
• Vorgehen kopierbar: Einsatz „Best Practices“

Komplizierte Projektvorhaben

• Geringe Volatilität/Dynamik und große Anzahl von Systemkomponenten
• Es ist nicht sofort für „jedermann“, sondern nur von Experten ersichtlich, was zu tun ist
• Ursache-Wirkungs-Zusammenhänge müssen analysiert werden, Abhängigkeiten sind linear
• Es gab bereits vergleichbare Vorhaben, an denen man sich orientieren kann
• Auswahl „Good Practices“

Komplexe Projektvorhaben

• Hohe Volatilität/Dynamik und große Anzahl von Systemkomponenten
• Maxime: „Probieren geht über Studieren“
• Ursache/Wirkung werden erst im Nachhinein verstanden, Abhängigkeiten sind wechselseitig
• Es gibt keine hinreichenden Erfahrungswerte aus der Vergangenheit, auf die referenziert werden kann

Chaotische Projektvorhaben

• Niemand weiß – weder vorher noch nachher – was das beste Vorgehen ist bzw. war
• Ursache/Wirkung können nicht bestimmt werden, eine wirklich richtige Lösung gibt es nicht
• Es geht in erster Linie um Schadensbegrenzung bzw. Stabilisierung. (z.B. in Krisensituationen)

Der Unterschied zwischen kompliziert und komplex klingt zwar auf den ersten Blick eher akademisch, hat in der Praxis aber große Auswirkungen darauf, welche Vorgehensweise funktioniert.

Bei der Einschätzung der Komplexität von Projekten geht es nicht so sehr um die 100%-ige präzise Positionierung. Ziel ist es, ein Gefühl dafür zu entwickeln, ob es sich eher um eine simple, komplizierte, oder doch eine komplexe Aufgabenstellung handelt und durch welche Parameter – vor allem Klarheit der Anforderungen oder Beherrschbarkeit der Methode/Technik – sich die Komplexität ergibt. Wichtiger als den Komplexitätsgrad anhand eines mühsam erarbeiteten Fragenkatalogs ganz genau festzulegen, ist es daher, die Meinungen aller relevanten Stakeholder mit in die Entscheidung einzubeziehen und die Ergebnisse gemeinsam zu diskutieren.

Die Stacey-Matrix

Inhaltlich sehr ähnlich zum CYNEFIN-Framework ist die sogenannte Stacey-Matrix (benannt nach Ralph D. Stacey), die die Komplexität von Projekten veranschaulicht und eine einfache Nutzung im Projektalltag ermöglicht.

Abbildung 1: Darstellung Stacey-Matrix mit Anwendungsbereichen agiler und klassischer Projektmanagement-Methoden

Grundsätzlich lässt sich die dargestellte Einteilung (von einfach bis chaotisch) in die drei Anwendungsbereiche „Klassisch“, „Agil“ und „Chaos“ weiter ausdifferenzieren. So kann auch für die unterschiedlichen agilen Methoden eine jeweils tendenziell optimale Konstellation abgeleitet werden.

Die RFC-Bewertungsmatrix

Damit die Entscheidung für oder gegen ein agiles Vorgehen nicht von einem einzigen Kriterium abhängt, kann diese durch Gewichtung der Kriterien auch differenzierter mit der folgenden RFC Bewertungsmatrix erfolgen:

Abbildung 2: Beispiel für die gewichtete Bewertung der einzelnen Kriterien

Hinweise zur RFC Bewertungsmatrix :

• Die Gewichtung der einzelnen Kriterien beruht auf Erfahrungswerten. Diese kann bei Bedarf aber angepasst werden. Auch die Erweiterung der Matrix um zusätzliche Kriterien ist möglich
• Die Bewertung mit „Ja“ führt zur Berücksichtigung des Kriteriums mit der jeweiligen Gewichtung
• Besonderes Gewicht wird auf das CYNEFIN-Modell (Untergliederung in einfache, komplizierte, komplexe und chaotische Projekte) und die Erfahrung des Projektteams mit agilen Methoden gelegt
• Bei den projektinternen Kriterien ist die Teamgröße bewusst etwas stärker gewichtet, da dieser Faktor gegenüber der Projektlaufzeit und Projektgröße meist größeren Einfluss hat
• Die Teilergebnisse werden addiert und bei einem Wert ≥ 0,5 wird eine agile PM-Vorgehensweise empfohlen. Da die Bewertung für einzelne Teilprojekte oder Aufgabenpakete aber unterschiedliche ausfallen kann, ist in solchen Situationen ggf. ein hybrides Vorgehen von Vorteil
• Soll agiles Projektmanagement erstmalig eingesetzt werden, so erfolgt die Empfehlung nur dann, wenn die Fragen nach Projektgröße sowie Team- bzw. Teilprojektgröße mit „Ja“ beantwortet werden. Die Vorteile einer agilen Vorgehensweise können nur dann zum Projekterfolg beitragen, wenn die bekannten generellen Nachteile bzw. Gefahren bei erstmaligem Einsatz von agilem Projektmanagement nach Möglichkeit reduziert werden

Fazit:

Die Festlegung der Vorgehensweise – agil oder klassisch – für ein Projekt sollte immer nach objektiven Bewertungskriterien erfolgen. Die persönlichen Vorlieben einzelner Personen dürfen dabei keine Rolle spielen. Nur eine passend gewählte Vorgehensweise für ein Projekt ist auch effizient und effektiv. Deshalb ist es wichtig, einen objektiven Entscheidungsprozess im Unternehmen zu etablieren, um für geplante Projekte die jeweils am besten passende Projektmanagement-Vorgehensweise auszuwählen. Der Entscheidungsprozess ist dabei transparent zu gestalten und muss für alle Stakeholder im Wesentlichen nachvollziehbar sein.

Die RFC-Bewertungsmatrix erlaubt es, nach definierten Kriterien die grundlegende Vorgehensweise eines Projektvorhabens zu bestimmen: agil oder klassisch. Die beschriebenen Bewertungskriterien dienen dabei als Grundlage für die Diskussion mit dem Projektteam bzw. den Projekt-Stakeholdern. Da aber nicht immer eine eindeutige Entscheidung bzgl. der Vorgehensweise getroffen werden kann, ist gegebenenfalls auch ein hybrides Vorgehen in Projekten sinnvoll.

Ausblick:

Im zehnten Teil der RFC Blogreihe zum agilen Projektmanagement geht es um die Kombination der agilen und der klassischen Vorgehensweise: Hybrides Projektmanagement.