Agile Vorgehensweisen für Projekte liegen gerade im Trend – aber sie sind nicht immer auf ein bestimmtes Projekt anwendbar oder optimal dafür geeignet. Viele Projektverantwortliche stehen daher vor der Frage, welches Vorgehensmodell ihrem Projekt den größten Nutzen bringt. In diesem Artikel erfahren Sie, wie Sie mithilfe eines an der TH Mittelhessen entwickelten Kriterienkatalogs eine systematische Analyse durchführen können und welche Vorgehensweise sich am ehesten für Ihr Projekt eignet. Der sogenannte Agil-O-Mat gibt insbesondere Projektleitenden und Mitarbeitenden im PMO konkrete Hinweise für ihren Projektalltag. Der vorliegende Beitrag beschreibt die Hintergründe, den Aufbau und die Anwendung des Agil-O-Mats. Der Agil-O-Mat steht Ihnen auch unter "Agil-O-Mat: Klassisch oder agil - Entscheidungsanalyse | Tool Excel" zum Herunterladen im projektmagazin zur Verfügung.

Auf ein passgenaues Projektvorgehen kommt es an!

Im modernen Projektmanagement geht es vermehrt um eine Abwägung zwischen agilen und plangetriebenen (oft "klassisch" genannten) Vorgehensweisen (Timinger, 2017; Seel/Timinger, 2017). Das betrifft nicht nur das Vorgehensmodell im Sinn des Projektablaufs, sondern insbesondere auch den Führungsstil und die generelle Unternehmenskultur. Unabhängig von der unmittelbaren Charakteristik eines Projekts sind auch die entsprechenden Umfeldfaktoren für die Wahl des Ansatzes relevant: Agiles Vorgehen wird eine bürokratisch-hierarchische Organisation nicht zum Erfolg führen. Eine dynamisch-kreative Organisation wird grundsätzlich mit der Einhaltung von Plänen Schwierigkeiten haben.

Die Managementerfordernisse von Projekten schwanken letztlich einzelfallbezogen entsprechend ihrer Rahmenbedingungen. Dies sollte sich in einer adaptiven Ausgestaltung widerspiegeln (Gessler, 2012, S. 51, sowie GPM, 2017, S. 106). Entscheidend für einen erfolgreichen Projektverlauf kann eine Typisierung des Projekts in der frühen Planungs- oder Initiierungsphase sein, da so für das Projektmanagement die ersten grundlegenden Informationen zur Ausarbeitung des Projektdesigns gegeben sind (Frick et al., 2019, S. 1006).

Agil, klassisch oder hybrid?

Aus der bitteren Erkenntnis nach wie vor schlechter allgemeiner Erfolgsquoten von Projekten haben sich diese "Pole" des Projektmanagements gebildet, gekennzeichnet durch agile versus sog. klassische Vorgehensweisen. Verschiedene Studien und Praxiserfahrungen zeigen, dass häufig unternehmens- und kontextbezogen ein hybrider Methodenmix eingesetzt wird, also standardisierte Vorgehensweisen nicht in ihrer ursprünglich erdachten Reinform angewendet werden (Blust, 2019). Einige Autor:innen bezeichnen Projektmanagementmethoden als hybrid, wenn sie agile und klassische Techniken kombinieren (z.B. Kurtz/Sauer, 2018). Andere wiederum fokussieren die sequenzielle Kombination klassischer Phasenmodelle (z.B. Wasserfall) mit agilen Methoden, wie sie z.B. in Scrum verwendet werden (z.B. Sandhaus et al., 2014).

Seit einigen Jahren beschäftigen sich Wissenschaftler:innen und Praktiker:innen damit, welche charakteristischen Merkmale eines Projekts und seines Umfelds explizit die Frage beantworten können, ob ein plangetrieben-hierarchischer (aka traditionell/klassisch) oder ein regelbasiert-iterativer (aka agil) Ansatz möglich und sinnvoll ist. Als Entscheidungshilfe zur Klärung der Frage, welche Vorgehensweise – agil oder plangetrieben – mit Blick auf ein konkretes Projekt die beste sei, wird vielfach die sog. Stacey-Matrix ins Spiel gebracht. In der aktuellen Fassung führt die Stacey-Matrix in der Regel die Dimensionen Unsicherheit bzgl. der Anforderungen versus Unsicherheit bzgl. des Vorgehens auf. Die Stacey-Matrix ist jedoch vielmehr ein Diagramm, das eine Einordnung vorliegender Probleme nach den o.g. zwei Dimensionen ermöglicht (Stacey, 2007). Komplexität lässt sich jedoch nicht alleine mit den Kriterien Unsicherheit bzgl. der Anforderungen sowie des Vorgehens aufspannen (Hüsselmann, 2021, S. 64-76).

Komplexität versus Kompliziertheit

Besteht der Projektgegenstand aus einer Vielzahl von Komponenten, die zudem vernetzt sind und über die Zeit gesehen ein dynamisches Verhalten und Emergenz zeigen, handelt es sich um ein komplexes Projekt. Dieses zeichnet sich dadurch aus, dass in einem Projekt viele Wechselwirkungen zwischen verschiedenen Elementen bestehen. Im Gegensatz zu einem komplizierten Projekt, das sich trotz der vielschichtigen Elemente strukturieren und planen lässt, verhindern die Wechselwirkungen und Abhängigkeiten in komplexen Projekten eine für ein klassisches Vorgehen nötige Planung. Gleichzeitig gelten die Einschränkungen, die ein kompliziertes Projekt wenig geeignet für agile Vorgehensweisen machen, auch für komplexe Projekte. Im Kontext von Lean Project Management werden Ansätze ausgeführt, komplexe Projekte zu vereinfachen und zu zerlegen, um entweder die Wechselwirkungen zu eliminieren oder die Anzahl der Elemente zu reduzieren und so das Projekt aus dem Bereich der komplexen Projekte herauszubewegen (Hüsselmann, 2021, S. 59-67).

Möglichkeit, Sinnhaftigkeit und Notwendigkeit von Methoden

Hinsichtlich der Wahl eines methodischen Ansatzes muss zwischen der Möglichkeit und der Sinnhaftigkeit eines Einsatzes unterschieden werden (Boehm/Turner, 2003; Feldmüller, 2018). D.h., es muss schlussendlich bewertet werden, ob ein methodischer Ansatz in einem Umfeld möglich ist, ob dieser Nutzen bringt und daher angewendet werden sollte oder ob dies aufgrund der Konstellation sogar geboten, also nötig ist (siehe Bild 1).

Möglich wird der Einsatz einer Methode, wenn die fachlich-technischen sowie die organisationellen Voraussetzungen gegeben sind. Letztere können im Sinn der Anwendung des Verhaltensmodells menschlichen Handelns als wollen, können und dürfen beschrieben werden (Diebold/Simon, 2019). Diese drei Aspekte müssen demnach in Einklang stehen, damit ein Vorhaben möglich wird − etwa die Anwendung von Agilität.

Das Wollen bewertet z.B. die Anforderung des Managements, agiles Vorgehen zu praktizieren. Das Dürfen umfasst nicht zuletzt Compliance-Anforderungen, die etwa die Trennung von Erstellenden und Prüfenden einer Lösung fordern, was eine enge Zusammenarbeit unmöglich macht. So gibt es z.B. gesetzliche Regelungen, die agile Elemente, z.B. DevOps, verhindern (siehe auch "Softwareprojekte: Mit DevOps auf die Überholspur") − etwa im Bereich des Personalwesens. Dort ist die Trennung von Entwicklung und Betrieb aus Datenschutzgründen obligatorisch. Das Können schließlich beschreibt z.B. die organisatorischen Voraussetzungen, die für einen agilen Ansatz gegeben sein müssen, etwa die räumliche Nähe der Projektteams inkl. Kunden. Diese Beispiele können natürlich noch vielseitig erweitert werden.

Aufbau des Agil-O-Mats

Der in meiner Arbeitsgruppe an der TH Mittelhessen entwickelte Agil-O-Mat kombiniert die aus der Literatur bekannten Einflussfaktoren mit einer Reihe weiterer Faktoren aus empirischen Erkenntnissen (Boehm/Turner, 2009; Seel/Timinger, 2017; Brehm et al., 2017; Feldmüller, 2018; Blust, 2019). Dies führte in der detaillierten Ausgestaltung schließlich zu einem spezifischen Kriterienkatalog zur Beantwortung der Frage "Agile oder traditionelle Vorgehensweise?". Diese Frage kann mit verschiedenen Kriterien und Merkmalen aus dem fachlich-taktischen, dem organisatorischen und dem unternehmenskulturellen Kontext beantwortet werden.

Kriteriengruppen

Mit dem Agil-O-Mat liegt somit ein umfassendes Kriteriensystem vor. Dieses wird in drei Kategorien unterteilt, basierend auf der Ebene in der projektdurchführenden Organisation, in der das Kriterium oder Merkmal anzutreffen ist. Auf der einen Seite stehen die Kriterien, die das Projekt bzw. den Projektgegenstand direkt betreffen. Auf der anderen Seite stehen die Kriterien, die durch die durchführende Unternehmung gebildet werden. Zwischen diesen Ebenen haben wir die durch das Projektteam beeinflussten Kriterien angesiedelt, die partiell auch als Schnittmenge zwischen den projektspezifischen und den unternehmensspezifischen Eigenschaften angesehen werden können.

Die Einteilung in die Ebenen trifft keine Aussage über die Gewichtung der Kriterien im Hinblick auf das einzelne Projekt. Jedoch kann anhand der Kriterienkategorien abgeleitet werden, wie langlebig die jeweilige Ausprägung sein kann. So sind unternehmensspezifische Kriterien im Wesentlichen über alle Projekte des Unternehmens identisch, während sich projektspezifische Kriterien von Projekt zu Projekt verändern können und individuell für jedes Projekt geprüft werden müssen. Wenn Projektteams beziehungsweise der Kern der Projektteams über mehrere Projekte bestehen bleibt, so bleiben auch die projektteamspezifischen Kriterien überwiegend konstant. Durch die bewusste Zusammenstellung des Projektteams lassen sich diese Kriterien kurzfristig beeinflussen.

Unternehmensspezifische Kriterien

Unternehmensspezifische Kriterien werden von der Struktur und den Prozessen des Unternehmens geprägt. Unabhängig vom einzelnen Projekt bilden sie die Basis dafür, inwiefern sich agile und klassische Ansätze in die übergeordneten Strukturen des Unternehmens einbinden lassen. Eine Änderung dieser Merkmale erfordert Zeit und umfasst weite Teile des Unternehmens. Hierzu gehört z.B. die Affinität des Topmanagements für Agilität.

Projektteamspezifische Kriterien

Projektteamspezifische Kriterien werden v.a. durch die Zusammenstellung des Teams und die mit dem Projekt befassten Personen definiert. Einzelne Merkmale lassen sich repräsentativ bzw. durchschnittlich für ein Team bewerten, um ein einheitlicheres Bild der Eignung zu schaffen. Ob diese Anpassung nicht nur theoretisch, sondern auch praktisch möglich ist, hängt von den verfügbaren Ressourcen der Organisation ab. So ist z.B. die Qualifikation der Teammitglieder ein wichtiger Einflussfaktor.

Projektspezifische Kriterien

Projektspezifische Kriterien werden im Wesentlichen durch den Gegenstand des Projekts sowie durch die Auftraggebenden und weitere Stakeholder:innen bestimmt. Diese lassen sich in gewissen Grenzen in Zusammenarbeit mit diesen beeinflussen. Prominentes Beispiel dafür ist die Unsicherheit bzgl. der konkreten Lösungsanforderungen. Dies tritt z.B. auf, wenn die Nutzenden eine gewisse Ergebnisoffenheit wünschen oder schlichtweg zum Zeitpunkt der Beauftragung fachlich nicht in der Lage sind, die gewünschte Lösung zu konkretisieren, etwa weil das Metier für sie neu ist.