eJournals PROJEKTMANAGEMENT AKTUELL 33/1

PROJEKTMANAGEMENT AKTUELL
0942-1017
Narr Francke Attempto Verlag GmbH + Co. KG Tübingen
10.24053/PM-2022-0013
„Projektmanagement“ als Begriff ist bestens in der Literatur definiert. Mit „Agilität“ sieht es etwas anders aus – und die beiden Begriffe im Zusammenhang zu diskutieren, birgt ein hohes Potenzial für Missverständnisse. Um dem abzuhelfen, sollte der Kontext im Unternehmen betrachtet werden: Wird ein klassisches Projekt- und Projektportfoliomanagement geführt und die Diskussion zu Agilität findet innerhalb der Projekte statt? Oder wird Agilität als Grundlage für ein ganzes Portfolio-Design vorausgesetzt, wodurch der Projektbegriff per definitionem obsolet wird? Im vorliegenden Artikel wird dieser Kontext im Unternehmen in einem Ordnungsrahmen strukturiert und beschrieben. Dadurch ergibt sich ein besserer Überblick im Dschungel der Methoden und die Diskussion zu Agilität und Projektmanagement kann versachlicht werden.
2022
331 Gesellschaft für Projektmanagement

Agilität trifft Projektmanagement

2022
Marco Liechti
Anne-Kathrin Bolender
Reto Scherrer
43 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 01/ 2022 DOI 10.24053/ PM-2022-0013 Gibt es künftig noch Projekte und Projektmanager? Agilität trifft Projektmanagement Marco Liechti, Anne-Kathrin Bolender, Reto Scherrer Für eilige Leser I „Projektmanagement“ als Begriff ist bestens in der Literatur definiert. Mit „Agilität“ sieht es etwas anders aus-- und die beiden Begriffe im Zusammenhang zu diskutieren, birgt ein hohes Potenzial für Missverständnisse. Um dem abzuhelfen, sollte der Kontext im Unternehmen betrachtet werden: Wird ein klassisches Projekt- und Projektportfoliomanagement geführt und die Diskussion zu Agilität findet innerhalb der Projekte statt? Oder wird Agilität als Grundlage für ein ganzes Portfolio-Design vorausgesetzt, wodurch der Projektbegriff per definitionem obsolet wird? Im vorliegenden Artikel wird dieser Kontext im Unternehmen in einem Ordnungsrahmen strukturiert und beschrieben. Dadurch ergibt sich ein besserer Überblick im Dschungel der Methoden und die Diskussion zu Agilität und Projektmanagement kann versachlicht werden. Schlagwörter I Ordnungsrahmen, Projektkontext, Klassisches Projektmanagement, Hybrides Projektmanagement, Agiles Projektmanagement Gibt es in der Agilität überhaupt noch Projekte und Projektmanagement? Schon nur diese Frage zu hören, empört viele- - und birgt das Potenzial, Glaubenskriege zu führen. Im vorliegenden Artikel versucht die Fachgruppe „Agile und Projektmanagement“ der Schweizerischen Gesellschaft für Projektmanagement (spm), der Frage rational auf den Grund zu gehen [1]. Sie hat dafür einen Ordnungsrahmen entwickelt, welcher dazu dienen kann, die Diskussion von Agilität in Zusammenhang mit „Projektmanagement” zu strukturieren. Projektmanagement und Agilität „Projektmanagement“ als Begriff ist bestens definiert und beschrieben. „Agilität“ hingegen ist ein jüngerer Begriff, und wird in einer großen Bandbreite mit unterschiedlichen Bedeutungen verwendet. Dazu gehören unter anderem Führungsaspekte („agile Organisationsentwicklung“ [2] „Management 3.0“ [3]), Formen der Arbeitssteuerung („Scrum“ [4], „Kanban“ [5]), ein Mindset, sowie ganze Frameworks für Zielvereinbarungen („OKR“ [6]) oder Lösungsentwicklung („Scaled Agile Framework“ [7], „LeSS“ [8]). Deshalb ist es nicht zielführend, beide Begriffe mit einem allgemeingültigen Anspruch zueinander in Beziehung zu setzen. Vielmehr würden sich hieraus fehlgeleitete Pauschalurteile ergeben, wie „Agilisten machen nur alten Wein in neuen Schläuchen“, oder „Projektmanagement hat mit Agilität ausgedient“. Bedeutung des Kontextes für die Diskussion Der vorliegende Artikel hat zum Ziel, Diskussionen rund um „Agilität“ und „Projektmanagement“ mit strukturierenden Elementen zu unterstützen. Der eingangs erwähnte Ordnungsrahmen beschreibt zu diesem Zweck mehrere mögliche Kontexte, in welchen sich ein Unternehmen oder Unternehmensteil in Bezug auf die beiden Begrifflichkeiten befinden kann (vgl. Abbildung 1). Durch die Kenntnis des Kontextes und seiner Definition kann die Diskussion an Qualität gewinnen. Es wird zum Beispiel ersichtlich, dass sich die Notwendigkeit und Aufgaben eines Projektleiters je nach Kontext unterscheiden. Auch lassen sich die vielen Formen von „hybridem“ Projektmanagement im Sinne von gemischtem Einsatz klassischer und agiler Werkzeuge besser beschreiben und einordnen (z. B. [9] oder [10]). In den folgenden Abschnitten wird der Aufbau des Ordnungsrahmens auf Basis von verschiedenen Merkmalen des Projektmanagements hergeleitet (vgl. Abbildung 1). Dieses systematische Vorgehen wird auch in anderen Disziplinen angewendet (basierend auf [11]). Danach werden die einzelnen Merkmale und deren Ausprägungen beschrieben. Abschlies- Wissen | Agilität trifft Projektmanagement 44 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 01/ 2022 DOI 10.24053/ PM-2022-0013 send wird der Frage nachgegangen, ob es neben der Agilität weiterhin Projektmanagement gibt und wie Agilität und Projektmanagement sich ggf. auch künftig ergänzen. „Agil“ und Projektmanagement in verschiedenen Kontexten Als „Kontext“ wird im vorliegenden Artikel der Bezug zwischen Agilität und Projektmanagement verstanden. Hierbei werden die organisatorischen Arbeitsbedingungen (Rahmenbedingungen) innerhalb des Unternehmens betrachtet. Sollte ein Unternehmen in Bezug auf Projekt-, Programm- und Projektportfoliomanagement größere Agilität anstreben, so ist anhand der Kontexte erkennbar, welche Voraussetzungen erfüllt sein müssen, welche Veränderungen zu realisieren sind und welche organisatorischen Implikationen dadurch entstehen. Anhand der Merkmale werden verschiedene Ausprägungen beschrieben, welche für den jeweiligen Kontext bestimmend sind. Abbildung 1 stellt die typischen Kontexte nebeneinander. Die Bandbreite reicht vom Kontext 1 „Kein Agile“ bis hin zum Kontext 4 „Agile als Grundlage für das Programm- oder Portfolio-Design“. Der Ordnungsrahmen ist rein beschreibend und dient der Orientierung. Es ist wichtig zu verstehen, dass bspw. mit der Einordnung in Kontext 1 oder 2 keine Wertung verbunden ist-- nicht jedes Unternehmen kann oder muss Kontext 3 oder 4 anstreben. Je nach Kontext wird Agilität und Projektmanagement auf eine bestimmte Weise in Zusammenhang gebracht. Hierdurch verändert sich die Bedeutung der beiden Begriffe leicht, was aus ihrer Beziehung zueinander resultiert. Zum Beispiel zeigt Kontext 4, dass das Projektportfolio eines Unternehmens dauerhaft aus agilen Umsetzungsorganisationen besteht. In diesem Kontext wird der Projektbegriff auf eine Art und Weise hinterfragt, wie es in den anderen Kontexten nicht der Fall ist: Die temporäre Organisation als grundlegendes Merkmal eines Projektes ist nicht mehr gegeben. Die Merkmale und ihre Ausprägungen, welche aus Sicht der Fachgruppe bestimmend für die Unterscheidung der Kontexte sind, können den Zeilen der Abbildung 1 entnommen werden. Es handelt sich nicht um eine Vollständige Auflistung, sondern um eine Auswahl, die für die Unterscheidung der Kontexte relevant sind. Zudem ist farblich gekennzeichnet, welche Ausprägungen weniger oder mehr mit Agilität in Verbindung gebracht werden. Die einzelnen Merkmale und Ausprägungen sind summarisch in den Tabellen 1 bis 5 beschrieben. Abbildung 1: Ordnungsrahmen: Spektrum der Kontexte für „Agilität und Projektmanagement“ (eigene Darstellung) Ausprägung Beschreibung A.1 Projektauftrag legt die drei Ecken des „Magischen Dreiecks“ fest Der Auftrag für eine Veränderung wird als Projektauftrag zwischen Auftraggeber bzw. Auftraggeberin und Projektleiter bzw. Projektleiterin vereinbart. Die Dimensionen Leistung, Zeit und Budget werden darin festgelegt (d. h. die drei Ecken des „Magischen Dreiecks“ des Projektmanagements). Die Steuerung erfolgt über das Managen von Abweichungen in den drei Dimensionen. A.2 Zeit und Budget fix, Leistung dynamisch Der Auftrag für eine Veränderung wird zwischen Auftraggeber bzw. Auftraggeberin und einer oder mehreren Rollen der Führung vereinbart. Dabei steht die Größe der umsetzenden Mannschaft und die Zeit im Vordergrund (Zeit und Budget); die Leistung wird als Backlog gesehen und in der zur Verfügung stehenden Zeit so weit wie möglich bearbeitet. Die Steuerung erfolgt über die laufende Priorisierung des Backlogs. A.3 „Fluss“ an Arbeitspaketen In Erweiterung zu A.2: Die Umsetzung besteht aus mehreren Backlogs, möglicherweise auf verschiedenen Flughöhen, und beinhaltet Arbeitspakete unterschiedlicher Größe. Die Aufträge werden selbst zu Arbeitspaketen und „durchfließen“ in einem iterativen Requirements Engineering Prozess diese Backlogs. Tabelle 1: Beschreibung der Ausprägungen des Merkmals „Form der Beauftragung“ Wissen | Agilität trifft Projektmanagement 45 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 01/ 2022 DOI 10.24053/ PM-2022-0013 Kontext 1: Kein „Agile“ Dieser Kontext ist dem traditionellen Projektmanagement am nächsten. Beim klassischen Verständnis eines Projekts liegt eine temporäre Organisation zur Erreichung eines Zieles vor, Agilität hat keine besondere Bedeutung. Verschiedene Projektmanagementstandards, z. B. das PMBOK des Project Management Institutes (PMI) [12] oder die Individual Competence Baseline (ICB4) der International Project Management Association (IPMA) [13, S. 36], definieren Projekte als einmalige, temporäre, multidisziplinäre Organisationen, um vereinbarte Lieferobjekte innerhalb der gesetzten Anforderungen und Rahmenbedingungen zu erfüllen, damit ein einmaliges Projektziel zu erreichen. Die permanente Unternehmung beauftragt Projekte unter Beachtung des magischen Dreiecks, die Werkzeuge des Projektmanagements sind bekannt und der Projektleiter bestimmt über deren Einsatz. Ausprägung Beschreibung B.1 Temporäre Organisation je Projekt Für das Projekt wird eine neue, temporäre Projektorganisation zusammengestellt, welche nach Projektende wieder aufgelöst wird. Dies wird auch „projektorientierte Organisationsform“ genannt. Dabei kann auch eine temporäre Organisation als „Agile Release Train“ organisiert sein. B.2 Permanente Organisationen Die Arbeitspakete werden durch permanente Organisationen rund um die Backlogs auf den verschiedenen Flughöhen (vgl. A.3) bearbeitet. Dies wird auch als „produktorientierte Organisationsform“ umschrieben. Tabelle 2: Beschreibung der Ausprägungen des Merkmals „Organisationsform“ Ausprägung Beschreibung C.1 Konzentrierte Führung (eine Rolle) Der Projektleiter bzw. die Projektleiterin steuert alle drei Dimensionen Leistung, Zeit und Budget. C.2 Verteilte Führung (auf verschiedene Rollen) Die Führung wird auf verschiedene Rollen verteilt. Jede erhält einen Teil der Verantwortung. Typischerweise wird unterschieden zwischen der inhaltlichen Verantwortung (Prioritäten im Backlog, inhaltlicher Beschrieb der Arbeitspakete) und der methodischen Verantwortung (Arbeitsweise, Teamproduktivität, Prozesse). Teilweise werden auch weitere Rollen definiert. Tabelle 3: Beschreibung der Ausprägungen des Merkmals „Rolle der Führung“ Ausprägung Beschreibung D.1 Phasenweise, iterativ oder adaptiv Der Projektleiter bzw. die Projektleiterin verantwortet die Strukturierung des Ablaufs. Er oder sie entscheidet, ob ein phasenweises, iteratives oder adaptives Vorgehen am besten geeignet ist. Das adaptive Vorgehen beschreibt dabei den Wechsel zwischen Vorgehensweisen je nach Projektphase. D.2 Iterativ Die iterative Strukturierung ist vorgegeben aus der permanenten Organisation (vgl. B.2) und dem „Fluss“ an Arbeitspaketen (vgl. A.3). Tabelle 4: Beschreibung der Ausprägungen des Merkmals „Strukturierung des Ablaufs“ Ausprägung Beschreibung E.1 Kein Einsatz Diese Ausprägung ist im Ordnungsrahmen aufgenommen, damit dieser das vollständige Spektrum abbildet. In Realität verantwortet der Projektleiter bzw. die Projektleiterin, ob und wie viele agile Werkzeuge zum Einsatz kommen. E.2 Teilweiser Einsatz Agile Werkzeuge werden innerhalb eines klassischen Projektvorgehens teilweise eingesetzt. Dies kann beispielsweise ein Kanban Board zur Arbeitssteuerung sein, Scrum als Arbeitsweise eines Entwicklungsteams, oder Daily Standup-Meetings im Projektteam. Der Entscheid über den Einsatz liegt beim Projektleiter bzw. der Projektleiterin. E.3 Konsequenter Einsatz Das Projekt-, Programm- oder Portfoliodesign ist auf den konsequenten Einsatz agiler Werkzeuge ausgerichtet. Tabelle 5: Beschreibung der Ausprägungen des Merkmals „Einsatz Agiler Werkzeuge“ Wissen | Agilität trifft Projektmanagement 46 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 01/ 2022 DOI 10.24053/ PM-2022-0013 Dieser Kontext zeichnet sich durch eine phasenorientierte Umsetzung aus, die linear, inkrementell oder auch iterativ sein kann. Kontext 2: Einsatz einzelner Werkzeuge aus „Agile“ In diesem Kontext ähneln fast alle Merkmale denen des Kontexts 1. Analog zu Kontext 1 beauftragt die permanente Unternehmung Projekte unter Beachtung des magischen Dreiecks. Ebenfalls analog zu Kontext 1 bestimmen die Projektleitenden über den Einsatz der Werkzeuge des Projektmanagements zur bestmöglichen Erreichung des Projektziels. Der relevante Unterschied liegt jedoch darin, dass unter diesen Werkzeugen einzelne agile Werkzeuge angewendet werden. Dies können einfache Werkzeuge sein, wie z. B. Daily Standup-Meetings oder Kanban Boards zur Arbeitssteuerung [14], oder aber auch anspruchsvollere Werkzeuge, wie z. B. bei einer Software-Entwicklung, welche im Projekt nach Scrum [15] organisiert wird. Der Kontext 2 ist in der Praxis durch etablierte Grundlagen des Projektmanagements gekennzeichnet, die mit einzelnen agilen Werkzeugen kombiniert werden. Wann der Einsatz agiler Werkzeuge sinnvoll ist und wie diese angepasst werden können, wird z. B. durch die „Agile Extension“ zum BABOK für Agiles Requirement Engineering [16] oder im „Agile Practice Guide“ der PMI als Ergänzung zum PMBOK [17] diskutiert. Wie in Kontext 1 kann z. B. die ICB 4 [13] als Referenz für eine Übersicht der benötigten Kompetenzen verwendet werden, da sie nicht an ein bestimmtes Vorgehensmodell gebunden ist. Kontext 3: „Agile“ als Grundlage des Projektdesigns Die ICB 4 beschreibt als Kompetenz des „Projektdesigns“, wie Bedürfnisse, Wünsche und Einflüsse der Organisation interpretiert, gewichtet und in die Grundprinzipien des Projekts übertragen werden, um die höchste Erfolgswahrscheinlichkeit sicherzustellen. Es entspricht folglich einer Art „groben Skizze“ für das gesamte Projekt [13, S. 116-121]. Was bedeutet es nun, wenn Agilität die Grundlage des Projektdesigns ist? Der Unterschied zwischen den Kontexten 3 und 2 ist deutlich größer als derjenige zwischen Kontext 1 und 2. Das iterative Vorgehen wird zur Grundlage der Projektabwicklung, wodurch das gesamte Projekt als Backlog von Elementen beschrieben wird und das Projektziel nicht mehr von vorneherein klar definiert ist. Daraus folgt, dass die Beauftragung nicht mehr als „magisches Dreieck” erfolgt, denn damit würden Leistung, Zeit, und Budget fixiert und als Auftrag formuliert. In einem Projekt des Kontexts 3 liegt das „umgekehrte“ magische Dreieck vor, wie es häufig mit „agilem Projektmanagement“ in Verbindung gebracht wird. Dieses besagt, dass der Aspekt der Leistung erst im Projektverlauf festgelegt wird. Weiterhin gehört zu einem agilen Projektdesign auch eine andere Organisationsform: Die Rolle der Führung wird auf oberster Ebene der Projektleitung geteilt. Scrum bspw. unterteilt die Führungsrolle in einem Entwicklungsteam in die Rollen des Product Owners (fachliche Führung) und des Scrum Masters (methodische Führung) [15]. Im Kontext 3 wird folglich die Projektleitung in mindestens eine Rolle verantwortlich für Arbeitsweise sowie eine für Inhalt aufgeteilt. Dieser Kontext ist den agilen Skalierungsframeworks nahe (z. B. das Scaled Agile Framework in der „Essential SAFe“ Konfiguration). Insbesondere in der Software-Entwicklung, aber auch in anderen Branchen, ist es oft möglich, ein Projekt so mit Ressourcen auszustatten, dass mehrere Scrum-Teams in der Form eines Projektes synchronisiert werden und auf ein gemeinsames Ziel hinarbeiten. Im Kontext 3 sind Projekte weiterhin als temporäre Organisation erkennbar und werden durch die darüber liegende Ebene des Programms oder Projektportfolios beauftragt. Dies ist ein entscheidender Unterschied zu Kontext 4. Kontext 4: „Agile“ als Grundlage des Programm- oder Portfoliodesigns Auch die Beschreibung des Kontexts 4 wird mit der Definition der Kompetenz „Portfoliodesign“ aus der ICB 4 eingeleitet: „Portfoliodesign“ beschreibt, wie Bedürfnisse, Wünsche und Einflüsse der Organisation interpretiert, gewichtet und in die Grundprinzipien des Portfolios übertragen werden, um die höchste Erfolgswahrscheinlichkeit sicherzustellen [13, S. 48-49 und S. 116-118]. Übertragen gilt dasselbe für das Programmdesign. Im vorliegenden Artikel wird von Programm- oder Projektportfoliodesign gesprochen, da die über dem Projekt als Entität des Programms oder Projektportfolios angesiedelte Strukturebene relevant ist [18, S. 30]. Wenn Agilität die Grundlage für ein Portfoliodesign ist, ist dies wiederum ein markanter Schritt gegenüber des Kontexts 3. Im Kontext 4 wird das Prinzip des „Bring work to the people“ auf das ganze Programm oder Projektportfolio skaliert. Im Gegensatz zum „Bring people to the work“ (der Personalbeschaffung für Projekte als temporäre Organisation [19]) sind hier die Ressourcen für alle Projekte im Programm oder Projektportfolio als agile Teams Teil der permanenten Umsetzungsorganisationen des Programms oder Projektportfolios. Umzusetzende Inhalte werden als Arbeitspakete identifiziert, formuliert und an die Umsetzungsorganisationen übergeben. In Summe wird die erwartete Leistung erbracht. Als Konsequenz des Kontexts 4 löst sich der Projektbegriff, wie ihn PMI, IPMA oder DIN definieren, auf. Es könnte argumentiert werden, das Projekt sei nunmehr ein eben erwähnter „umzusetzender Inhalt“, was als Arbeitshypothese hilfreich zu sein scheint. Hierbei würde jedoch eine Person, welche einen solchen „umzusetzenden Inhalt“ über mehrere Umsetzungsorganisationen hinweg verantwortet, zur Projektleitung. Das Spannungsfeld, indem sich Projektleitende bewegen würde, wäre enorm: Es können nicht alle Dimensionen des magischen Dreiecks in dem Verantwortungsbereich einer Person gebündelt werden. Die Aufgaben der Projektleitung werden vielmehr auf die permanenten Umsetzungsorganisationen in verschiedene Rollen aufgeteilt [20]. Dadurch erfolgt ein bedeutender Wechsel in der Form der Beauftragung: Es liegt kein Projektauftrag mehr vor, da die drei Dimensionen Leistung, Zeit und Budget nicht zum Projektstart ermittelt werden können. An die Stelle des Projektauftrages tritt stattdessen ein permanenter Fluss an Arbeitspaketen, respektive ein Zusammenspiel von „Backlogs“ auf verschiedenen Ebenen- - auch auf der Strukturebene oberhalb derjenigen des Projektes. Wissen | Agilität trifft Projektmanagement 47 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 01/ 2022 DOI 10.24053/ PM-2022-0013 Dieser Kontext wird in letzter Konsequenz durch die agilen Skalierungsframeworks wie SAFe (in der „Full SAFe“ oder „Portfolio SAFe“ Konfiguration) und LeSS beschrieben. Allen diesen Frameworks liegt das beschriebene Paradigma des „Bring work to the people“ zugrunde, weshalb sie alle aus Umsetzungsorganisationen und einem Fluss an Arbeitspaketen bestehen. Schlussfolgerung Mit den unterschiedlichen Kontexten kann der Kreis zur einleitend gestellten Frage geschlossen werden, ob der Projektbegriff und das Projektmanagement in Zusammenhang mit Agilität noch relevant sind. Und die Antwort ist: Ja, unbedingt. Es kommt jedoch auf den Kontext im Unternehmen an, wie sich dies äußert und was Agilität bedeutet: • Sofern ein Unternehmen in seiner Organisationsform ein Projektportfolio mit Projekten führt- - das ist in den dargestellten Kontexte 1, 2 und 3 der Fall-- gibt es weiterhin Projekte, und Projektmanagement bleibt relevant. In Kontext 3 wird sich die Rolle der Projektleitenden verändern, da die geteilte Führung durch das Unternehmen vorausgesetzt wird. • Im Kontext 4 gibt es keine Projekte mehr gemäß der Definition als temporäre Organisation, um ein Vorhaben umzusetzen. Die Begriffe „Projekt“ und „Projektmanagement“ kommen nicht mehr vor, ebenso wenig die Rolle der „Projektleitung“. Kompetenzen des Projektmanagements sind jedoch weiterhin von großer Relevanz. Sie sind jedoch auf verschiedene Rollen der permanenten Organisation aufgeteilt. Ein Unternehmen, welches sich in diesem Kontext befindet oder sich auf diesen Kontext zubewegt, wird sich mit den daraus resultierenden Implikationen auf das Projektmanagement auseinandersetzen müssen. Zudem wird klar: Ein Unternehmen kann in Bezug auf die Organisation von Veränderung systematisch vorgehen, ungeachtet des Kontexts und damit des Einsatzgrades von Agilität. Die Forschung zeigt denn auch, dass erfolgreiche, agile Projekte keine „Selbstläufer” sind, sondern eine Planung und Organisationsform erfordern [21]. Ausblick Die Mitglieder der Fachgruppe „Agile und Projektmanagement“ beobachten, dass sich im Schweizer Markt Technologieunternehmen sowie Unternehmen mit einem hohen Anteil Software-Entwicklung im Wandel befinden. Die Organisation ihres Projektportfolios wird nach und nach auf „Agile“ umgestellt, und ein Zielbild nach Kontext 4 angestrebt. Dieser Wandel wird von Fachgesellschaften und -organisationen, z. B. der IPMA (im deutschsprachigen Raum vertreten durch die Gesellschaft für Projektmanagement (GPM), den spm und der Projekt Management Austria) oder dem PMI unterstützt, indem z. B. die Einführung einer IPMA-Zertifizierung als „Agile Leader“ [22] oder der „Agile Practice Guide“ [17] aufgebaut werden. Die GPM fördert zudem den hybriden Ansatz mit einem Zusatzzertifikat hybrid+ [23], da „Reinformen” sowohl des klassischen als auch des agilen Projektmanagements in der Praxis immer weniger anzutreffen sind. Diese Publikationen und Zertifizierungen gehen jedoch weitgehend nach wie vor vom dargestellten Kontext 2 aus, indem ein hybrider Projektmanagementansatz mit einzelnen agilen Werkzeugen verfolgt wird. Die Kontexte 3 und 4, welche Agilität als Grundlage für das Projektdesign respektive das Programm- oder Projektportfoliodesign sehen, haben noch großes Potenzial zur Erkundung und Bearbeitung. Auf Basis des vorgestellten Ordnungsrahmens ergeben sich beispielsweise weitere Forschungsfragen wie: • Welches Spektrum an Organisationsformen gibt es für ein einzelnes Projekt, welches über den Einsatz von agilen Methoden nachdenkt? • Wie können Projektleitende ihre nachgewiesenen Kompetenzen weiterentwickeln- - insbesondere, wenn sie in Rollen der Kontexte 3 und 4 wechseln? • Welche Bedeutung ist der zunehmenden Ausbreitung des Kontext 4 in Unternehmen für die Berufsgattung der Projektleitenden beizumessen? Wie beeinflusst dies die Ausbildung professioneller Projektmanager, ihre Zertifizierungen und berufliche Entwicklungspfade? • Was ist bei der Synchronisation zwischen mehreren permanenten Organisationen in Kontext 4 zu beachten? • Wie können die beiden Funktionsweisen der Umsetzung von Veränderung durch „temporäre Organisationen” und durch „permanente Organisationen” koexistieren? Welche Herausforderungen ergeben sich, wenn sich in einem Projektportfolio Ressourcen sowohl in agilen Organisationsstrukturen als auch in „Projekten” wiederfinden? • Welche Steuerungsmöglichkeiten bestehen inhaltlich, terminlich und finanziell in einem vollständig „Agile“ organisierten Projektportfolio des Kontextes 4? Über die Fachgruppe „Agile und Projektmanagement” Die beiden Begriffe „Projektmanagement“ und „Agile“ werden oft als inkompatibel betrachtet. Die Fachgruppe hat bewusst bei der Benennung auf das englische Adjektiv „agile“ Bezug genommen, um nicht eine Abgrenzung zwischen Agilität und Projektmanagement herbeizuführen. Stattdessen sollen auch Konzepte des agilen Projektmanagements einbezogen werden. In der Fachgruppe „Agile und Projektmanagement“ der Schweizerischen Gesellschaft für Projektmanagement spm kommen Projekt- und Programmleitende aus verschiedenen Firmen und Branchen zusammen (u. a. von den größten Schweizer Handels-, Transport-, Finanzdienstleistungs- und Telekommunikationsunternehmen), um den Zusammenhang zwischen den zwei Begrifflichkeiten zu strukturieren und nutzbar zu machen. Die Fachgruppe will einen konstruktiven Beitrag leisten, damit sich Unternehmen bei der Organisation ihrer eigenen Veränderung besser im „Dschungel der Methoden” orientieren können. Mit Unterstützung der erarbeiteten Inhalte der Fachgruppe sollen Unternehmen in die Lage versetzt werden, sachlich und zielführend zu diskutieren. Literatur [1] spm Schweizerische Gesellschaft für Projektmanagement (Hrsg.): Agile und Projektmanagement. Glattbrugg. Online verfügbar unter: https: / / spm.ch / fachgruppen / agile-und-projektmanagement/ . Stand: 21. Oktober 2021. Wissen | Agilität trifft Projektmanagement 48 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 01/ 2022 DOI 10.24053/ PM-2022-0013 [2] Oesterreich, Bernd / Schröder, Claudia: Agile Organisationsentwicklung. Handbuch zum Aufbau anpassungsfähiger Organisationen. Verlag Franz Vahlen, München 2019. [3] Appelo, Jürgen: Management 3.0. Leading Agile Developers, Developing Agile Leaders. 3. Auflage Addison-Wesley, Boston 2011. [4] Scrum.org (Hrsg.): Welcome to the home of Scrum! TM. Online verfügbar unter: https: / / www.scrum.org/ . Stand: 21. Oktober 2021. [5] Helmold, Marc: Kaizen, Lean Management und Digitalisierung. Mit den japanischen Konzepten Wettbewerbsvorteile für das Unternehmen erzielen. Springer Fachmedien, Wiesbaden 2021. [6] Doerr, John: OKR: Objectives & Key Results. Wie Sie Ziele, auf die es wirklich ankommt, entwickeln, messen und umsetzen. Verlag Franz Vahlen, München 2018. [7] Scaled Agile (Hrsg.): SAFe 5 for Lean Enterprises. Boulder, CO. Online verfügbar unter: https: / / www.scaledagileframework.com/ . Stand: 21. Oktober 2021. [8] The LeSS Company (Hrsg.): [Why LeSS Framework? ]. Boxtel, Niederlande. Online verfügbar unter: https: / / less.works/ . Stand: 21. Oktober 2021. [9] Cooper, Roger G./ Sommer, Anita F.: Agile-Stage-Gate for manufacturers. Changing the way new products are developed. In: Research Technology Management 2 / 2018, S. 17-26. [10] Lalmia, Abdallah / Fernandes, Gabriela / Souad, Sassi Boudemagh: A conceptual hybrid project management model for construction projects. In: Procedia Computer Science 181 / 2021, S. 921-930. [11] Zwicky, Fritz: A way of thinking. Discovery, invention, research through the morphological approach. Macmillian, New York 1969. [12] Project Management Institute (Hrsg.): The standard for the project management and a guide to the project management body of knowledge (PMBOK guide). 7. Auflage Project Management Institute, Newton Square 2021. [13] Sedlmayer, Martin et al.: Individual Competence Baseline for Project Management Version 4.0.1, IPMA Publications, Zürich 2015. [14] Karlström, Daniel / Runeson, Per: Combining agile methods with Stage-Gate project management. In: IEEE Software 3 / 2005, S. 43-49. [15] Schwaber, Ken / Sutherland, Jeff: The scrum guide. 2020. Online verfügbar unter: https: / / scrumguides. org / docs / scrumguide / v2020 / 2020-Scrum-Guide-US. pdf#zoom=100. Stand: 6. Oktober 2021. [16] International Institute of Business Analysis / Agile Alliance (Hrsg.): Agile extension to the BABOK® guide (Version 2). Toronto 2017. [17] Project Management Institute (Hrsg.): Agile practice guide. Project Management Institute, Newton Square 2017. [18] Wagner, Reinhard et al.: Organisational Competence Baseline for developing competence in Managing by Projects Version 1.1. IPMA Publications, Zürich 2016. [19] Lundin, Rolf A./ Söderholm, Anders: A theory of the temporary organization. In: Scandinavian Journal of Management 4 / 1995, S. 437-455. [20] Butvina, Nikolai: Shifting from projects to products. Keynote Präsentation des 32. IPMA Weltkongresses. St. Petersburg, 21. -23. September 2021. Marco Liechti Marco Liechti ist Elektroingenieur ETH und hat zu Beginn seiner Karriere Software in der Telekom-Industrie entwickelt. Nach verschiedenen Stationen im Projektmanagement leitet er seit 2017 das Projektportfolio der Schweizerischen Mobiliar Versicherung. Er ist IPMA Level B zertifizierter Senior Portfolio Manager. eMail: marco.liechti@spm.ch Anne-Kathrin Bolender Anne-Kathrin Bolender studierte Betriebswirtschaftslehre und Supply Chain Management an der Hochschule Fulda. Nach mehrjähriger Erfahrung als Projekt- und Programmmanagerin in der Luftfahrtindustrie ist sie heute als Studiengangsleiterin an der Kalaidos Fachhochschule Schweiz tätig. Internet: https: / / www.kalaidos-fh.ch / de-CH / Kontakt / Personenverzeichnis / B/ Bolender-Anne-Kathrin eMail: anne-kathrin.bolender@kalaidos-fh.ch Reto Scherrer Reto Scherrer ist Informatik Ingenieur (FH). Seit über 20 Jahre beschäftigt sich Reto mit Projektmanagement in verschiedenen Branchen wie in der Industrie- und im Finanzsektor. Seit 2017 coacht er die Transformation in der Zürcher Kantonalbank im Bereich Vertrieb und Kanäle als Agile Coach und RTE. Er ist IPMA Level B zertifizierter Senior Portfolio Manager. eMail: rscherrer@swissonline.ch [21] Serrador, Pedro / Pinto, Jeffrey K.: Does agile work? A quantitative analysis of agile project success. In: International Journal of Project Management 5 / 2015, S. 1040-1051. [22] Haas, Thomas / Käser, Christian / Knöpfel, Hans / Widmann, Jean-Pierre: Arbeiten in agilen Organisationen. Swiss Individual Agile Competence Reference Guide IPMA Version 2.3. Glattbrugg 2019. Online verfügbar unter: https: / / www.vzpm.ch / fileadmin / dokumente / downloads / Deutsch / swiss.ICB4agile_DE.pdf. Stand: 21. Oktober 2021. [23] Gesellschaft für Projektmanagement (Hrsg.): Zusatzzertifikat hybrid+. Online verfügbar unter: https: / / www. gpm-ipma.de / zertifizierung / projektmanager / zusatzzertifikat_hybrid_gpm.html. Stand: 21. Oktober 2021. Eingangsabbildung: www.pixabay.com