Erfolgsfaktoren bei der Auswahl von Projektmanagementmodellen im IT-Projektmanagement bei deutschen Großunternehmen der Softwarebranche

Die Forschung und die Fachliteratur sind sich einig, dass die Selektion eines optimalen Vorgehensmodells (VMs) ein wesentlicher Erfolgsfaktor für Softwareprojekte darstellt (vgl. Aichele & Schönberger 2014, S. 150; Broy & Kuhrmann 2021, S. 84; Standish Group 2001, S. 4). Dabei obliegt die Aufgabe zur Wahl eines Vorgehensmodells der Projektleitung und des Managements (vgl. Kuster et al. 2019, S. 34; Broy & Kuhrmann 2013, S. 88; Schatten et al. 2010, S. 69). Albers (2021, S. 21) führt neben diesen Rollen auch Mitarbeitende im Programm- und Produkt Management als weitere Entscheider:innen auf.

Die Aufgabe zur Auswahl eines Vorgehensmodells erweist sich jedoch aufgrund der hohen Anzahl von Vorgehensmodellen, Auswahlkriterien und den diversen Möglichkeiten zur Kombination und Tailoring als besonders komplex (vgl. Kuster et al. 2019, S. 34; Timinger 2017, S. 242; Albers 2021, S. 21).

Ein standardisiertes Verfahren zur Auswahl von Vorgehensmodellen ist allerdings nicht vorhanden. Eine Reihe von Autor:innen empfehlen zwar Hilfsmodelle zur Ermittlung der Ausrichtung des geeigneten VMs (traditionell, agil, hybrid) – beispielsweise die Stacey Matrix, das Cynefin Framework und das Diamantenmodell nach Shenhar & Dvir, betonen jedoch zugleich, dass diese Modelle zur Orientierung dienen sollen und dass zusätzlich diverse andere Faktoren aus dem Projektumfeld (Unternehmenskultur, Qualifikation des Teams, etc.) zu berücksichtigen sind (vgl. Brönimann & Bommer 2022; Dittmann & Zaeri 2023; Timinger 2021). Zum anderen besteht eine Reihe von Vergleichsansätzen, die konkrete VM nach ihren Eigenschaften bewerten und bei denen überwiegend objektive Kriterien der VM (Prozessabdeckung, Phasenabdeckung, etc.) im Fokus stehen (vgl. Albers 2016; Berg et. al. 2014, Aichele & Schönberger 2014).

Albers (2016, S. 1) weist darauf hin, dass die zahlreichen theoretischen Ansätze zur Auswahl und zum Vergleich von VM jedoch kaum Anwendung in der Praxis finden. Die Selektion des VM basiert dabei häufig auf der Meinung einer einzelnen Person (Albers (2016, ebd.). Daher plädiert Albers (2016, S. 5) für die Entwicklung eines praxisnahen und akzeptierten Auswahl- und Vergleichsansatzes. Dieser sollte alle VM-Typen (klassisch, agile und hybride) und neben objektiven Kriterien auch subjektive Aspekte (Eigenschaften des Projektteams, Unternehmenskultur, etc.) berücksichtigen (vgl. Albers 2016, S. 4). Dieses Modell ist anschließend anhand empirischer Methoden wie Expertenbefragungen zu evaluieren. Zusätzlich ist eine praktische Implementierung des Modells erforderlich, die von IT-Entscheider:innen direkt genutzt werden kann (vgl. Albers 2016, S. 5). Eine Umsetzung könnte Albers (2016, S. 5) zufolge unter dem Einsatz von einem speziellen künstlichen neuronalen Netz – dem Self-Enforcing Network (SEN) erfolgen.

In den folgenden Kapiteln wird zunächst auf die klassischen Hilfsmodelle zur Auswahl von Vorgehensmodellen näher eingegangen – die Stacey Matrix, das Cynefin Framework von Snowden und das Diamantenmodell nach Shenhar & Dvir. Im Anschluss werden zwei moderne Modelle betrachtet: das projektumfeld- und projektgegenstandsbezogene Netzdiagramm von Timinger (2021) und das Kompassmodell von Dittmann & Zaeri (2023). Letzteres stellt einen ganzheitlichen Ansatz bei der Wahl eines geeigneten hybriden Projektdesigns dar. Abschließend wird beispielhaft das Bewertungsverfahren konkreter Modelle nach ihren Eigenschaften von Berg et al. (2014) vorgestellt.

Die Bestimmung des Grads der Komplexität eines Projektes spielt eine entscheidende Rolle bei der Wahl eines geeigneten Vorgehensmodells (vgl. Brönimann & Bommer 2022, S. 123). Ein häufig eingesetztes Mittel für die Bestimmung des Komplexitätsgrades ist die Stacey-Matrix (vgl. Brönimann & Bommer 2022, Dittmann & Zaeri 2023, Timinger 2021), die auf Ralph Stacey (Professor für Management und Leiter des Zentrums Complexity and Management Center an der Universität Hertfordshire) zurückzuführen ist. Als ein renommierter Berater für führende Unternehmen und Autor mehrerer Bücher setzte sich Stacy mit den Bereichen Management und Organisation auseinander (vgl. Stacey, 1996).

Laut Zimmermann (2001, S. 1) stellt Stacey's Matrix (s. Abbildung 2.27) eine Methode zur Entscheidungsfindung im Management dar, die auf den zwei Dimensionen: den Grad der Gewissheit (the degree of certainty) und den Grad des Konsens (the level of agreement) innerhalb einer Gruppe basiert: „[a] method to select the appropriate management actions in a complex adaptive system based on the degree of certainty and level of agreement on the issue in question“.

Zimmermann (2001, S. 4) vereinfachte Stacey’s Version der Matrix und entwickelte basierend darauf Empfehlungen zu Management-Herangehensweisen in Abhängigkeit vom Komplexitätsgrad.

Abbildung 2 . 27: Stacey's Agreement & Certainty Matrix (Quelle: Zimmermann 2001, S. 4)

Abbildung 2.28: Einsatz von Zimmermanns Stacey-Matrix bei Schwaber (Quelle: Adaptiert von Schwaber 2004 S. 13)

Schwaber (2004, S. 13) verwendet die durch Zimmermann adaptierte Matrix (s. Abbildung 2.28) um die Komplexität der Software-Entwicklung zu veranschaulichen und bezeichnet es als „Complexity assessment graph“. Dabei repräsentiert die vertikale Achse die Komplexität der Anforderungen, während die horizontale Achse die Komplexität der Technologie darstellt. Die Schnittmenge dieser Komplexitäten ergibt den Komplexitätsgrad des Projektes. Die Mehrheit der aktuellen Softwareentwicklungsprojekte ist gemäß Schwaber (2004, ebd.) als komplex einzustufen. Projekte, die als chaotisch eingestuft wurden, lassen sich Schwaber (2004, ebd.) zufolge nicht durchführen. Der erste Schritt bei solchen Projekten wäre die Aspekte ihrer Komplexität zu lösen, bevor Fortschritte erzielt werden können (vgl. Schwaber 2004, S. 13).

Die drei wichtigsten Dimensionen der Komplexität in der Softwareentwicklung sind nach Schwaber (2004, S. 13): Anforderungen, Technologie und Menschen.

• Anforderungen: Kund:innen entwickeln oft erst ein klares Verständnis ihrer Bedürfnisse, wenn sie eine Implementierung ihrer Anforderungen sehen. Diese Anforderungen sind komplex, da sie nicht nur mehrdeutig sind, sondern sich auch kontinuierlich ändern. Kund:innen mit einfachen Anforderungen stellen eher die Ausnahme dar (vgl. Schwaber 2004, S. 13).

• Technologie: In der Softwareentwicklung werden in der Regel mehrere Technologien verwendet. Dies ist mit einer ansteigenden Komplexität verbunden, da Schnittstellen zwischen verschiedenen Technologien weitaus komplexer als die Komplexität der einzelnen Technologien selbst sind (vgl. Schwaber 2004, S. 13).

• Menschen: Die Zusammenarbeit der Menschen, die an der Entwicklung von Software beteiligt sind, führt aufgrund ihrer unterschiedlichen Fähigkeiten, Erfahrungen usw. zu einer erheblichen Steigerung des Komplexitätsgrads (vgl. Schwaber 2004, S. 13).

Die Stacey-Matrix wurde von diversen Autor:innen weiterentwickelt (s. Abbildung 2.29) und dient als Hilfsmodell zur Einstufung der Ausrichtung eines geeigneten Vorgehensmodells (vgl. Brönimann & Bommer 2022, S. 123). Dabei ergibt sich der Komplexitätsgrad anhand der „Kombination aus Klarheit der Anforderungen und Bekanntheit des Lösungswegs“ (Timinger 2021, S. 196).

Anhand der Bestimmung des Komplexitätsgrads des Projektes (der Aufgabenstellung) als komplex, kompliziert oder einfach, kann die Ausrichtung eines geeigneten Vorgehensmodells bestimmt werden (vgl. Brönimann & Bommer 2022, S. 124).

• Komplexe Projekte charakterisieren sich durch unbekannte Einflussfaktoren und stellen ein unvorhersagbares System dar. Sie erfordern hohe Flexibilität, da neue Erkenntnisse aus unerwarteten Situationen gewonnen werden. Der gewählte Lösungsweg wird dabei kontinuierlich überprüft (vgl. Brönimann & Bommer 2022, S. 124). Agile Vorgehensmodelle unterstützen diese Flexibilität besser als traditionelle Modelle (vgl. Brönimann & Bommer 2022, S. 125), da Pläne im Falle von Unsicherheit nicht zielführend sind. Vielmehr kann der Projektgegenstand im Rahmen einer iterativ-inkrementellen Entwicklung anhand „Feedbackzyklen mit relevanten Stakeholdern“ erarbeitet werden (Timinger 2021, S. 197).

• Komplizierte Projekte sind im Gegensatz zu komplexen Projekten vorhersehbar, jedoch unübersichtlich. Die Ausgangsbedingungen für solche Projekte bleiben bei wiederholter Durchführung konstant. Dabei können agile Modelle bei der erstmaligen Durchführung Unterstützung bieten. Mit zunehmender Routine und insbesondere für eingespielte Teams mit klarer Aufgabenverteilung ist ein strukturiertes Phasenmodell jedoch unter Umständen besser geeignet. In solchen Fällen wäre eine agile Transformation aufgrund der gleich bleibenden Aufgabenstellung nicht notwendig, da sie keine Vorteile bietet (vgl. Brönimann & Bommer 2022, S. 125). Je nach Grad der Unklarheit oder Instabilität können auch hybride Vorgehensmodelle zum Einsatz kommen (vgl. Timinger 2021, S. 197).

• Einfache Projekte kennzeichnen sich durch eine klar definierte und übersichtliche Aufgabenstellung und lassen sich mit einfachen Prozessen durchführen. Dabei sind der Einsatz von Best Practices und „Tailoring des gewählten Vorgehensmodells an die Aufgabenstellung“ relevant (vgl. Brönimann & Bommer 2022, S. 125). Aufgrund der Bekanntheit und Stabilität der Anforderungen sowie des Lösungswegs lassen sich solche Projekte gut planen. Folglich sind hierfür planbasierte Vorgehensmodelle geeignet (vgl. Timinger 2021, S. 196).

Die Auswahl des geeigneten Vorgehensmodells kann nicht allein auf den Typ der Aufgabenstellung beschränkt werden, andere Faktoren, insbesondere das Projektumfeld, sind dabei von entscheidender Bedeutung (vgl. Brönimann & Bommer 2022, S. 125). Es gilt folglich auch Einflussgroßen wie Stakeholder-Charakteristika, Unternehmenskultur oder Teamqualifikationen zu berücksichtigen (vgl. Timinger 2021, S. 197). Dennoch stellt die Stacey-Matrix eine erste Orientierung bei der Suche nach einem angemessenen Vorgehensmodell dar (vgl. Timinger, 2021, S. 197).

Das Cynefin-Framework wurde von Snowden, Boone et al. mit dem Ziel entwickelt, Führungskräften neue Perspektiven für Führung und Entscheidungsfindung zu bieten (Snowden & Boone 2007, S. 1). Dabei bezeichnet das walisische Wort Cynefin ([kə'nɛvɪn]) „die Vielfalt der Faktoren aus unserer Umgebung und Erfahrung, die uns auf einer Art und Weise beeinflussen, die wir nie begreifen können“ („the multiple factors in our environment and our experience that influence us in ways we can never understand“) (Snowden & Boone 2007, S. 2).

Gemäß Snowden & Boone (2007, S. 1) erhöht sich mit steigernder Komplexität die Wahrscheinlichkeit, dass traditionelle Herangehensweisen der Führung und der Entscheidungsfindung versagen. Dabei betrachten Snowden & Boone (2007, S. 3) Komplexität als eine Art des Denkens über die Welt („a way of thinking about the world“). Die aktuellen Erkenntnisse der Komplexitätsforschung und der kognitiven Wissenschaften können nach Snowden & Boone (2007, S. 3) die Führung dabei unterstützen, die Komplexität der heutigen Welt – fortschrittliche Technologie, Globalisierung, usw. zu verstehen (vgl. Snowden & Boone 2007, S. 3). Dabei ist ein Wandel des Denkens bei Führungsskräften erforderlich: “Leaders who want to apply the principles of complexity science to their organizations will need to think and act differently than they have in the past. This may not be easy, but it is essential in complex contexts” (vgl. Snowden & Boone 2007, S. 3).

Das auf Basis der Komplexitätswissenschaft entwickelte Cynefin-Framework (s. Abbildung 2.30) soll Führungskräfte in die Lage versetzen, den vorherrschenden Kontext, in dem sie sich befinden – einfach, kompliziert, komplex, chaotisch, unklar – zu erkennen und diesem entsprechend angemessen zu agieren. Somit können nicht nur bessere Entscheidungen getroffen werden, sondern auch Probleme vermieden werden, die aufgrund eines bevorzugten Managementstils entstehen können (vgl. Snowden & Boone 2007, S. 2). Effektives Management entsteht durch die Anpassung des Entscheidungsstils an die Veränderungen des Geschäftsumfelds, wobei jeder Kontext einer spezifischen Reihenfolge von Handlungen bedarf. Führungskräfte können in verschiedenen Situationen effektiv agieren, indem sie den aktuellen Kontext richtig erkennen, Warnsignale wahrnehmen und unangemessene Reaktionen vermeiden (vgl. Snowden & Boone 2007, S. 7).

Einfache und komplizierte Kontexte korrelieren mit faktenbasiertem (fact-based) Management. Dabei liegt ein geordnetes System vor, in dem sich Ursache-Wirkungs-Beziehungen wahrnehmen lassen. Die richtigen Antworten können anhand von Fakten ermittelt werden (vgl. Snowden & Boone 2007, S. 4).

Im Gegensatz dazu sind komplexe und chaotische Kontexte durch musterbasiertes (pattern-based) Management gekennzeichnet und stellen ungeordnete Systeme dar, da die Beziehung zwischen Ursache und Wirkung nicht unmittelbar erkannt werden kann. Die zukünftige Vorgehensweise wird durch die Identifizierung von Mustern bestimmt (vgl. Snowden & Boone 2007, S. 4).

Der fünfte Kontext – Unordnung (disorder) – ist schwer identifizierbar. In diesem Bereich konkurrieren verschiedene Perspektiven, was zu Konflikten führt. Als Lösung schlagen Snowden & Boone (2007, S. 4) vor, die Situation zu analysieren, in ihre Komponenten zu zerlegen und diese anschließend den anderen vier Bereichen zuzuordnen, damit Führungskräfte auf einer kontextuell angemessenen Weise eingreifen können (vgl. Snowden & Boone 2007, S. 4).

Im Folgenden werden die wesentlichen Aspekte der Eigenschaften des Kontexts und der Handlungsempfehlungen von Snowden & Boone (2007, S. 7) und ihre entsprechende Zuordnung zu Vorgehensmodellen gemäß Timinger (2021, S. 200-201) tabellarisch dargestellt (s. Tabelle 2.7).

Ziel von Shenhar & Dvir (2007, S. 40) ist es, die einzigartigen Merkmale von Projekten in ein Modell zu integrieren, das Managern ermöglicht, diese zu klassifizieren und einen geeigneten Ansatz auszuwählen. Projekte lassen sich Shenhar & Dvir (2007, S. 40) zufolge anhand von drei wesentlichen Faktoren systematisieren: Ziel, Aufgabe und Umfeld.

• Ziel (Goal): Das spezifische Ergebnis oder Produkt, das durch das Projekt erzielt werden soll;

• Aufgabe (Task): Die konkrete zu erledigende Aufgabenstellung, einschließlich ihrer Dimensionen: Schwierigkeit, Bekanntheit, Komplexität, verfügbare Zeit (vgl. Shenhar & Dvir 2007, S. 40);

• Umfeld (Environment): Das Projektumfeld, das das Geschäfts- und Marktumfeld, die verfügbare Technologie, die branchenspezifischen Bedingungen sowie das interne Unternehmensumfeld (Kultur, Mitarbeiter:innen, Verfahren) umfasst (vgl. Shenhar & Dvir 2007, S. 40).

Shenhar & Dvir (2007, S. 40) streben ein universelles Framework an, das ein breites Spektrum von Projekten, unabhängig von Branche, Technologie oder spezifischer Organisation, abdeckt. In Anlehnung an die Kontingenztheorie folgerten Shenhar & Dvir (2007, S. 41), dass Projekte sich durch drei Dimensionen charakterisieren lassen:

• Unsicherheit (Uncertainty): Der Kenntnisgrad über Informationen in Bezug auf das Projektziel, die Aufgabenstellung und das Umfeld, der oft am Anfang unvollständig ist;

• Komplexität (Complexity): Die Maßeinheit für den Projektumfang, einschließlich die Aufgabenanzahl und deren wechselseitige Abhängigkeiten;

• Tempo (Pace): Bezieht sich auf die zeitliche Dimension und die festgelegten Fristen (vgl. Shenhar & Dvir 2007, S. 41).

Basierend auf praktischen Erfahrungen stellten Shenhar & Dvir (2007, S. 41) fest, dass es hilfreich sein kann, zudem die Dimension der Unsicherheit (Uncertainty) auf Basis der zwei Hauptquellen von Unsicherheit in die Kategorien Marktunsicherheit (oder Zielunsicherheit) und technologische Unsicherheit (oder Unsicherheit der Aufgabe) zu unterteilen. Shenhar & Dvir (2007, S. 41) nannten die zwei daraus entstandenen neuen Dimensionen wie folgt:

• Neuheit (Novelty): Grad der Ziel- oder der Marktunsicherheit.

• Technologie (Technology): Grad der technologischen Unsicherheit.

Auf Basis der vier Dimensionen zur Charakterisierung von Projekten - Novelty, Technology, Complexity und Pace) wurde das NTCP-Diamantenmodell entwickelt (vgl. Shenhar & Dvir 2007, S. 41).

Im deutschprachigen Raum werden für die Dimensionen des Diamantenmodells von Shenhar & Dvir folgende Bezeichnungen verwendet (vgl. Timinger 2021, Dittmann & Zaeri 2023):

• Novelty = Missionsgrad

• Technology = Innovationsgrad

• Complexity = Abstraktionsgrad

• Pace = Managementgrad

Das NTCP-Diamantenmodell soll Manager:innen bei der Entscheidungsfindung in Bezug auf Projekte und ihrer Durchführung unterstützen. Solche Entscheidungen sind unter anderem wie folgt (vgl. Shenhar & Dvir 2007, S. 46):

• Auswahl der passenden Projekte und ihrer Manager:innen,

• Wahl des Projektmanagementstils,

• Strukturierung des Projekts,

• Auswahl von Werkzeugen.

Jede Dimension des Modells umfasst drei bis vier Stufen, zu denen ein Projekt zugeordnet werden kann.

Missionsgrad (Novelty): „Wie neu ist Ihr Produkt auf dem Markt?“

Diese Dimension stellt zum einen dar, in welchem Maße Kund:innen mit dem Produkt im Sinne von Produktart, Anwendung und Vorteilen vertraut sind und zum anderen repräsentiert sie die Unsicherheit des Projektziels – die Klarheit über die Anforderungen und der Kundenbedürfnisse (vgl. Shenhar & Dvir 2007, S. 46-47). Die Arten der Produkte je nach Missionsgrad sind:

• Derivative Produkte: Erweiterungen und Verbesserungen bestehender Produkte;

• Plattform-Produkte: Neue Generationen einer bestehenden Produktlinie in einem etablierten Marktsektor, die frühere Produkte ersetzen (z.B. neue Automodelle);

• Durchbruch-Produkte (Breakthrough): Neuartige auf einem neuen Konzept oder einer neuen Idee basierende Produkte (vgl. Shenhar & Dvir 2007, S. 46-47).

Innovationsgrad (Technology): Technologische Unsicherheit

Technologische Unsicherheit ist die Hauptquelle von Unsicherheit in Aufgaben. Andere mögliche Quellen sind mangelnde Teamerfahrung oder knappes Budget (vgl. Shenhar & Dvir 2007, S. 46). Technologische Unsicherheit stellt die Unsicherheit bezüglich der eingesetzten Technologie im Projekt dar. Diese Dimension hat einen Einfluss auf das Design, die Kommunikation und die technische Kompetenz des Teams (vgl. Shenhar & Dvir 2007, S. 46). Technologische Unsicherheit wird in vier Stufen untergliedert:

• Low-tech: Verwendung etablierter Technologien (z.B. Bauprojekte);

• Medium-tech: Nutzung von überwiegend bestehenden Technologien, geringe Interaktion mit neuen Technologien (z.B. Automotive Projekte);

• High-tech: Verwendung von für das Unternehmen unbekannten, jedoch bereits existierenden Technologien (z.B. Softwareprojekte);

• Super-high-tech: Technologien existieren nicht zu Projektbeginn und müssen während des Projekts entwickelt werden. Diese Projekte zeichnen sich durch eine klare Mission und durch einen unklaren Lösungsweg aus (z.B. Mondlandung) (vgl. Shenhar & Dvir 2007, S. 46-47).

Abstraktionsgrad (Complexity): Die Komplexität des Projekts (Systemumfang)

Die Projekt-Komplexität wird durch den Umfang des Systems definiert, der hierarchisch aus Systemen und Teilsystemen besteht. Die Projekt-Komplexität korreliert mit dem Systemumfang und hat Auswirkungen auf die Projektorganisation und den Grad der Formalisierung des Projektmanagements (vgl. Shenhar & Dvir 2007, S. 47). Dabei werden drei Stufen der Komplexität zur Unterscheidung der Projektmanagementpraktiken verwendet: Assembly, System und Array (vgl. Shenhar & Dvir 2007, S. 47).

• Assembly-Projekte beinhalten die Zusammenstellung von Elementen, Komponenten und Modulen zu einer einzigen Einheit, die eine spezifische Funktion erfüllt (z.B.Standalone Produkte, Aufbau eines Teilsystems von einem größeren System);

• Systemprojekte beinhalten eine komplexe Zusammenstellung von interaktiven Elementen und Teilsystemen, die zusammen verschiedene Funktionen zur Abdeckung eines bestimmten betrieblichen Bedarfs erfüllen (z.B. Autos, Computer);

• Array-Projekte beinhalten eine große, weit verteilte Sammlung von Systemen (Systeme von Systemen, Supersysteme), die zur Erreichung eines gemeinsamen Ziels zusammenarbeiten (z.B. ganze Konzerne, nationale Kommunikationsnetze) (vgl. Shenhar & Dvir 2007, S. 48-49).

Managementgrad (Pace): Wie kritisch ist der Zeitrahmen des Projekts?

Der Managementgrad eines Projekts wird durch die Dringlichkeit des Zeitrahmens und die Konsequenzen bei Nichteinhaltung der Zeitvorgaben bestimmt. Es beeinflusst die Autonomie der Projektteams, die Bürokratie, die Geschwindigkeit der Entscheidungsfindung und die Einbindung des Topmanagements (vgl. Shenhar & Dvir 2007, S. 49). Shenhar & Dvir (2007, S. 49) unterscheiden vier Stufen des Managementgrads: regulär, schnell/kompetitiv, zeitkritisch und blitzschnell.

• Reguläre Projekte: Bei diesen Projekten ist der zeitliche Faktor nicht entscheidend für den unmittelbaren Unternehmenserfolg;

• Schnelle/kompetitive Projekte: Sie dienen zur Nutzung von Marktchancen, Stärkung einer strategischen Position oder Erschließung neuer Geschäftsfelder und sind am häufigsten in profitorientierten Organisationen verbreitet;

• Zeitkritische Projekte: Diese Projekte müssen innerhalb eines definierten Zeitrahmens abgeschlossen werden. Dabei liegt eine Beschränkung aufgrund eines spezifischen Ereignisses vor. Die Nicht-Einhaltung des Abschlusstermins führt zum Scheitern des Projekts;

• Blitzprojekte sind Krisenprojekte und sind dringend und zeitkritisch. Eine schnelle Behebung der Krise stellt dabei ein Erfolgskriterium dar (vgl. Shenhar & Dvir 2007, S. 49).

Verwendung

Das Diamantenmodell bietet eine grafische Darstellung eines Projekts nach Ausprägungsgrad der Parameter: Mission (Novelty), Innovation (Technology), Abstraktion (Complexity), Management (Pace) und hat zum Ziel die Art des Projekts zu verdeutlichen (vgl. Shenhar & Dvir 2007, S. 49).

In der Abbildung 2.31 wird der Diamant eines Plattform-, hochtechnologischen, System- und zeitkritischen Projekts dargestellt. Eine bestimmte Projektzuordnung wird im Vektorformat anhand der abgekürzten Stufenbezeichnung einer Dimension kodiert – beispielswese D = (Pl, HT, Sy, TC) für das oben genannte Beispiel. Die Kodierung eines bahnbrechenden, mitteltechnischen, Array-, schnellen und kompetitiven Projekts wäre dagegen wie folgt D = (Br, MT, Ar, FC) (vgl. Shenhar & Dvir 2007, S. 50).

Während Untersuchungen erfolgloser Projekte beobachteten Shenhar & Dvir (2007, S. 14) oft eine Diskrepanz zwischen der Diamantenform der geforderten Projektmerkmale und der Diamantenform des tatsächlich angewandten Managementstils. Diese Abweichungen lieferten im Nachhinein eine Erklärung für das Scheitern des Projekts (Shenhar & Dvir 2007, S. 14).

Folglich kann das Diamantenmodell als visuelles Hilfsmittel dienen, um die Diskrepanzen zwischen dem notwendigen und dem tatsächlich angewendeten Managementstil zu verdeutlichen (s. Abbildung 2.32). Dabei symbolisiert eine durchgezogene Linie den erforderlichen Stil, während eine gestrichelte Linie den tatsächlich angewendeten Stil repräsentiert (vgl. Shenhar & Dvir 2007, S. 50-51).

Für die Auswahl von Vorgehensmodellen sind verschiedene Parameter von entscheidender Bedeutung, beispielweise „die Unternehmenskultur, die Stabilität der Anforderungen und die Art des Projektgegenstands“ (vgl. Timinger 2021, S. 224).

Konkrete Parameter, die einen Einfluss auf die Wahl von Vorgehensmodellen haben, sind von Boehm & Turner (2004) und Špundak (2014) untersucht worden (vgl. Timinger 2021, S. 202). Timinger (2021, S. 202) fasst diese Parameter in einem gemeinsamen Netzdiagramm (s. Abbildung 2.33) zusammen, dass zur Auswahl zwischen planbasierten und agilen Vorgehensmodellen verwendet werden kann.

Timinger (2021, S. 202) teilt die von Boehm & Turner (2004) und Špundak (2014) untersuchten Parameter in folgende zwei Gruppen ein:

• Parameter, die das Umfeld und die direkten Projektbeteiligten betreffen und

• Parameter, die das Projekt charakterisieren.

Die auf der linken Seite des Netzdiagramms dargestellten Parameter kennzeichnen das Projektumfeld, während die Parameter auf der rechten Seite des Diagramms das Projekt charakterisieren (vgl. Timinger 2021, S. 202).

Projektumfeld charakterisierende Parameter

Zu den Parametern, die das Umfeld und die direkten Projektbeteiligten betreffen gehören:

• Unternehmenskultur,

• Qualifikation des Teams,

• Stabilität des Teams,

• Größe des Teams,

• Verteilung des Teams (vgl. Timinger 2021, S. 202).

Unternehmenskultur: Die Umsetzung agiler Arbeitsweisen wird durch eine Unternehmenskultur mit flachen Hierarchien begünstigt. Im Gegensatz dazu erfordern viele Hierarchieebenen und die damit verbundenen Abstimmungsprozesse die Erstellung detaillierter Pläne. Eine Veränderung der Unternehmenskultur ist nicht trivial. Bei der Transformation eines stark hierarchisch strukturierten Unternehmens zu einer agilen Organisation ist in der Regel ein längerer Veränderungsprozess erforderlich. Eine „ehrliche Bestandsaufnahme“ ist dabei von entscheidender Bedeutung. Flache Hierarchien implizieren nicht nur eine geringe Anzahl an Hierarchieebenen, sondern auch „kooperative Strukturen“ sowie Mitarbeiter:innen (vgl. Timinger 2021, S. 202).

Qualifikation des Teams: Die Anwendung agiler, selbstorganisierter Arbeitsweisen bedarf eine entsprechende Qualifikation des Teams. Ist diese Voraussetzung nicht gegeben, kann die Koordination der Aufgaben besser durch ein planbasiertes Arbeiten unterstützt werden (vgl. Timinger 2021, S. 202-203).

Stabilität des Teams: Unter optimalen Gegebenheiten bleibt die Teamzusammensetzung bei agilen Vorgehensmodellen stabil, sodass dasselbe Team kontinuierlich an einem Projekt arbeitet und auch über mehrere Projekte hinweg zusammenbleibt. Ist diese Stabilität jedoch nicht gegeben, sind für die Abstimmung und die Koordination der Ressourcen Pläne erforderlich (vgl. Timinger 2021, S. 202-203).

Größe des Teams: Die Größe des Teams stellt ebenfalls einen Faktor dar, der die Effektivität agiler Arbeitsweisen und die Förderung der direkten Kommunikation beeinflusst. Kommunikation in größeren Teams erfordert einen zusätzlichen Koordinationsaufwand, der durch spezifische Pläne unterstützt werden kann. Inzwischen sind Ansätze für agile Zusammenarbeit vorhanden, die auch für größere Teams geeignet sind (vgl. Timinger 2021, S. 203). Timinger (2021, ebd.) zufolge ist die Teamgröße zwar ein relevanter Parameter bei der Auswahl des Vorgehensmodells, jedoch ist ihre Auswirkung im Vergleich zur Unternehmenskultur weniger signifikant (vgl. Timinger 2021, S. 203).

Verteilung des Teams: Teams, die an einem gemeinsamen Standort arbeiten, können effektiv kommunizieren, ohne dass umfangreiche Koordinationspläne erforderlich sind. Ist das Team jedoch über mehrere Standorte verteilt, sind Pläne erforderlich, um die Zusammenarbeit zu gewährleisten. Jedoch stehen derzeit softwarebasierte Lösungen zur Verfügung, sodass verteilte Teams kein Hindernis für agile Arbeitsweisen darstellen (vgl. Timinger 2021, S. 203).

Projektgegenstand charakterisierende Parameter

Zu den Parametern, die das Projekt charakterisieren, zählen:

• Einbeziehung der Kund:innen,

• Dokumentationsanforderungen,

• Stabilität der Anforderungen,

• Gefährdungspotenzial,

• Projektgegenstand (vgl. Timinger 2021, S. 203).

Einbeziehung der Kund:innen: Die aktive Einbindung der:des Auftraggeber:in ist für agile Arbeitsweisen unerlässlich. Sofern seitens des:der Kunden:in kein Interesse an einer gemeinsamen, iterativen oder inkrementellen Vorgehensweise besteht, sind agile Vorgehensmodelle nur begrenzt geeignet. In solchen Fällen kann die Verwendung von Plänen, die auf dem Lasten- und Pflichtenheft basieren, ein effektiveres Werkzeug für die Zusammenarbeit mit dem:der Kunden:in darstellen (vgl. Timinger 2021, S. 203).

Dokumentationsanforderungen: Dokumentationsanforderungen können aus rechtlichen Vorgaben, branchenüblichen Standards oder den Anforderungen des Auftraggebers entstehen. Während das Agile Manifest den Fokus auf die Ergebnisse legt und weniger auf ausführliche Dokumentation, ist es dennoch von Bedeutung, zu beachten, dass agile Methoden Dokumentation grundsätzlich nicht ausschließen (vgl. Timinger 2021, S. 203). Daher ist dieser Aspekt laut Timinger (2021, ebd.) lediglich ein schwacher Indikator für die Notwendigkeit von einem agilen oder planbasierten Vorgehen.

Stabilität der Anforderungen: Die Stabilität der Anforderungen stellt einen wesentlichen Indikator für agiles oder planbasiertes Vorgehen dar. Bei instabilen Anforderungen ist „ein agiles, iteratives oder inkrementelles Vorgehen“ empfehlenswert. Im Falle von stabilen Anforderungen, ist eine gute Planung und eine entsprechende Umsetzung möglich (vgl. Timinger 2021, S. 203).

Gefährdungspotenzial: Das Gefährdungspotenzial ist ebenfalls als ein Einflussfaktor bei der Auswahl des Vorgehensmodells zu berücksichtigen. In einigen Branchen existieren spezifische Vorgaben oder Richtlinien für die Entwicklung von Produkten oder Dienstleistungen, die bei der VM-Auswahl beachtet werden sollten. In Branchen, in denen sicherheitskritische Produkte (z.B. Medizintechnik) entwickelt werden, werden traditionelle Methoden der Qualitätssicherung des Wasserfall- oder V-Modells vorausgesetzt. Hybride Vorgehensmodelle können in diesem Kontext herangezogen werden, die Agilität zu unterstützen, sofern dies gewünscht ist (vgl. Timinger 2021, S. 204).

Projektgegenstand: Gemäß Timinger (2021, S. 204) ist der Projektgegenstand ein starker Indikator für die Wahl eines geeigneten Vorgehensmodells. Anhand der Stacey-Matrix und des Cynefin-Frameworks wird ersichtlich, dass agiles, iteratives oder inkrementelles Vorgehen vor allem für komplexe Projekte geeignet ist. Allerdings setzt diese Arbeitsweise eine zyklische Entwicklung des Projektgegenstands voraus. Als alternative Vorgehensweise kann bei komplexen Projektgegenständen, die für eine iterative Arbeitsweise nicht geeignet sind, Kanban gewählt werden, da dieses Modell keine Zyklen vorsieht (vgl. Timinger 2021, S. 204).

Strukturiertes Vorgehen bei der Wahl eines Vorgehensmodells

Des Weiteren schlägt Timinger (2017, S. 263) ein strukturiertes Vorgehen bei der Wahl eines unternehmensindividuellen Vorgehensmodells vor. Dieses umfasst folgende Schritte:

1. Analyse der spezifischen Unternehmenssituation und der Projekte innerhalb des Unternehmens (vgl. Timinger 2017, S. 263);

2. Ermittlung von Kriterien auf Basis der vorangegangenen Analyse, die für die Bewertung eines Vorgehensmodells relevant sind (vgl. Timinger 2017, S. 263);

3. Formulierung von Zielen, die ein neues Vorgehensmodell (traditionell, agil oder hybrid) erfüllen muss (vgl. Timinger 2017, S. 263);

4. Erarbeitung von mehreren Lösungsalternativen. Dabei sollten auch unvertraute Vorgehensmodelle berücksichtigt werden (vgl. Timinger 2017, S. 263);

5. Auswahl derjenigen Lösungsalternative, welche die Ziele und Kriterien am besten erfüllt (vgl. Timinger 2017, S. 263);

6. Nachhaltige Einführung des ausgewählten Vorgehensmodells im Unternehmen (vgl. Timinger 2017, S. 263);

Nach Dittmann & Zaeri (2023, S. 18-19) erfordern die dynamischen Anforderungen moderner Projekte ein flexibles Projektdesign, das sowohl die Integration von plangetriebenen und/oder wertgetriebenen Ansätzen als auch eine kontinuierliche Anpassung ermöglicht. Der von Dittmann & Zaeri (2023, S. 19) entwickelte Kompass soll als zentrales Modell zur Orientierung und zum Verständnis der verschiedenen Dimensionen dienen, die die Auswahl des Projektdesigns beeinflussen. Das Kompass-Modell ( Abbildung 2.34) ist ein ganzheitlicher Ansatz, der unterschiedliche Aspekte des Projektdesigns anhand von vier Dimensionen („Himmelsrichtungen“) strukturiert:

• Der Norden: Mindset und Haltung;

• Der Osten: Organisation;

• Der Westen: Technik und Methoden;

• Der Süden: Praktische Erfahrungen (vgl. Dittmann & Zaeri 2023, S. 19).

Durch die Anwendung des Kompasses soll sichergestellt werden, dass sowohl die Organisationsbedingungen als auch die spezifischen Anforderungen des Projekts reflektiert und angepasst werden, um den besten Ansatz für jede Situation zu finden. Dabei sollen stets alle Dimensionen berücksichtigt werden (vgl. Dittmann & Zaeri 2023, S. 102).

Der Norden (Mindset und Haltung)

Diese Richtung betont die Bedeutung der Einstellung und der Werte innerhalb einer Organisation für den Projektdesign-Erfolg. Sowohl das Mindset der Projektbeteiligten als auch die Organisationskultur spielen dabei eine entscheidende Rolle (vgl. Dittmann & Zaeri 2023, S. 102-103). Dabei sprechen Dittmann & Zaeri (2023) folgende Empfehlungen aus:

• Mindset: Sowohl das agile Mindset (Flexibilität und Anpassungsfähigkeit) als auch das traditionelle Mindset (Planung, Struktur und Kontrolle) sind relevant und sollen je nach spezifischen Anforderungen eines Projekts berücksichtigt werden (vgl. Dittmann & Zaeri 2023, S. 102, 117-118).

• Agilität: Vor Projektbeginn sollte festgelegt werden, wie viel Agilität benötigt wird und wie viel Aufwand und Ressourcen in die Entwicklung eines entsprechenden Mindsets investiert werden soll (vgl. Dittmann & Zaeri 2023, S. 117-118).

• Auswahl eines geeigneten Vorgehensmodells: Die Auswahl eines passenden Frameworks sollte sowohl auf den Projektanforderungen als auch auf den Führungsqualitäten der Projektmitarbeiter:innen basieren. Bei der Umstellung auf ein agiles Framework ist es wichtig, die Förderung der Selbstorganisation und die Verantwortungsdelegation im Team schrittweise vorzunehmen (vgl. Dittmann & Zaeri 2023, S. 129-130).

• Erfolgsfaktoren: Führungskräfte sollten als Partner agieren und Vertrauen aufbauen, anstatt autoritär zu handeln. Eine enge Zusammenarbeit, klare Kommunikation und die Einbindung der Mitarbeiter:innen in die Selbstorganisation sind entscheidend für den Projekterfolg (vgl. Dittmann & Zaeri 2023, S. 131-132).

Osten (Organisation)

Der Osten befasst sich mit dem Zusammenspiel zwischen Linien- und Projektorganisationen (vgl. Dittmann & Zaeri 2023, S. 19).

Die Abstimmung zwischen Linien- und Projektorganisationen ist entscheidend für den Erfolg beider Strukturen. Projekte werden oft aus der Linie heraus initiiert und nach Abschluss wieder in die Linie integriert. Eine sorgfältige Wahl der Projektorganisationsform ist essenziell um Konflikte zu vermeiden (vgl. Dittmann & Zaeri 2023, S. 150).

Die Hauptunterschiede zwischen Linien- und Projektorganisationen in projektorientierten Unternehmen betreffen ihre Ziele, Organisation und Organisationskultur:

• Ziele:

  • Linienorganisation: Fokus auf Prozesse mit gleichbleibender oder verbesserter Qualität;

  • Projektorganisation: Ziel ist es, Neues zu entwickeln, komplexe Probleme zu bewältigen und spezifische, einmalige Ergebnisse zu erzielen (vgl. Dittmann & Zaeri 2023, S. 153).

• Aufbau- und Ablauforganisationen:

  • Linienorganisation: Hierarchische Strukturen und definierte Arbeitsprozesse;

  • Projektorganisation: Flexible Strukturen, die auf Innovation und Veränderung ausgerichtet sind (vgl. Dittmann & Zaeri 2023, S. 154).

• Organisationskultur:

  • Linienorganisation: Ausgerichtet auf Effizienz und Kontinuität;

  • Projektorganisation: Fokussiert auf Innovation und Veränderung,

  • Die Unterschiedliche Ausrichtung führt oft zu zwei unterschiedlichen "Kulturen" (vgl. Dittmann & Zaeri 2023, S. 154).

Sowohl die Linienorganisation als auch die Projektorganisation sind unverzichtbar und müssen sorgfältig aufeinander abgestimmt werden. Je nach Innovationsgrad und Komplexität kann die Projektorganisation entweder klassisch oder agil gestaltet sein (vgl. Dittmann & Zaeri 2023, S. 154).

Während herkömmliche Linien- und Projektorganisationen keine umfassende "Übersetzungsarbeit" erfordern, ist bei hybriden Projekten, die sowohl klassische als auch agile Elemente integrieren, eine intensive Kommunikation und Aufklärung notwendig. Agile Rollen müssen im traditionellen Umfeld erklärt und integriert werden, und die unterschiedlichen Begriffe und Methoden müssen den Beteiligten verständlich gemacht werden. (vgl. Dittmann & Zaeri 2023, S. 154-155).

Ungeklärte Rollen und Aufgabenverteilungen führen häufig zu Konflikten. Eine klare Rollenklärung ist daher entscheidend.

Für den Erfolg hybrider Projektsituationen sind enge Zusammenarbeit, Kommunikation und das Verständnis der unterschiedlichen Systeme (Linien- und Projektorganisationen) entscheidend. Geeignete Schulungen und erfahrene Fachkräfte sind erforderlich, um die Unterschiede zwischen klassischen und agilen Ansätzen zu überbrücken (vgl. Dittmann & Zaeri 2023, S. 155).

Darüber hinaus ist eine eindeutige Rollenklärung von entscheidender Bedeutung, da unklare Rollen und Aufgaben oft Quellen für Konflikte im organisatorischen Kontext sind (vgl. Dittmann & Zaeri 2023, S. 157).

Westen (Technik und Methoden)

Der Westen befasst sich mit der Gegenüberstellung von klassischen und agilen Techniken und Methoden im Projektmanagement und ihre Anwendung in der Praxis. Diese Richtung bietet Unterstützung bei der Auswahl und Anwendung von passenden Werkzeugen und Techniken für hybride Projekte. Es wird betont, dass die Durchführung eines Projektes sowohl theoretische Kenntnisse als auch ihre korrekte praktische Anwendung erfordert (vgl. Dittmann & Zaeri 2023, S. 176).

Die Integration von klassischen und agilen Methoden ist notwendig, um den spezifischen Anforderungen eines Projekts gerecht zu werden. Dies kann bedeuten, dass verschiedene Methoden je nach Projektphase oder -anforderung kombiniert werden (vgl. Dittmann & Zaeri 2023, S. 192-193).

Süden (Praktische Erfahrungen)

Der Süden steht für die praktische Implementierung und Durchführung des Projektdesigns (vgl. Dittmann & Zaeri 2023, S. 235) und beschäftigt sich mit der Frage „was wollen wir mit der Einführung von professionalisiertem und standardisiertem Projektmanagement […] erreichen?“ (Dittmann & Zaeri 2023, S. 245).

Dabei wird ein konkretes Projekt-Beispiel im Finanzbereich aus der Perspektive des hybriden Ansatzes analysiert und der Einsatz des Kompasses in einem konkreten Beratungsprojekt für ein Start-up-Unternehmen erläutert (vgl. Dittmann & Zaeri 2023, S. 235, 244). 

Anhand des Projekts aus der Finanzbranche werden einige kritische Erfolgsfaktoren für hybride Projekte erläutert. Diese sind (vgl. Dittmann & Zaeri 2023, S. 241-243):

• Rechtliche Vorgaben: Klassische Herangehensweise und Integration in das Backlog;

• Risikoanalyse: Klassische Herangehensweise nach Grundsätzen der IPMA®; Präventive Maßnahmen – Einbindung in das Stakeholdermanagement oder Integration in das Backlog;

• Abnahmeprozesse: Klassisch definierte Abnahmeprozesse zur Sicherstellung der Compliance;

• Implementierungsphase: Agile Herangehensweise (Scrum) zur Vereinheitlichung und Umsetzung der Prozesse;

• Teamstabilisierung: Sicherstellung eines stabilen Scrum-Teams ohne häufigen Personalwechsel;

• Reviews: Reviews führten zur Steigerung der Motivation der internen Kund:innen.

Im Rahmen des Projektes aus der Finanzbranche wird auch ein konkretes Vorgehen bei der Auswahl und Implementierung des Projektdesigns vorgestellt:

• Gezielte Komplexitätsreduktion: Die initiale Entscheidung des Unternehmens, das Projekt mit Scrum umzusetzen, führte zu einer signifikanten Erhöhung des Komplexitätsgrades und der Entstehung chaotischer Zustände in der Anfangsphase. Maßnahmen zur gezielten Komplexitätsreduktion, wie die Aufteilung in klassische und agile Projektphasen sowie regelmäßige Retrospektiven stabilisierten das Projekt und förderten den „emergenten Zustand“ des Systems (vgl. Dittmann & Zaeri 2023, S. 243).

• Analyse der Systemkomplexität: Anhand des Diamantmodells (Shenhar und Dvir 2007) wurde eine dem Projektbedarf entsprechende Kombination klassischer und agiler Phasen ermittelt (vgl. Dittmann & Zaeri 2023, S. 243).

• Projekt als soziales System: Mithilfe von Scrum Master:innen wurde das Projekt als soziales System geformt. Durch intensive Kommunikation und gezielte Bewusstseinsarbeit wurde das Projekt erfolgreich auf die Projektziele ausgerichtet. Dies umfasste die Sensibilisierung des oberen Managements, die Unterstützung der:des Product Owner:in sowie die Durchführung von Reviews in den Fachabteilungen (vgl. Dittmann & Zaeri 2023, S. 243).

Berg et al. (2014, S. 40) bewerten eine Auswahl von konkreten Modellen hinsichtlich einer Reihe von modellinhärenten Eigenschaften. Bei dem Vergleich zwischen Vorgehensmodellen wird geprüft, ob ein VM die gewählten Kriterien erfüllt. Ziel der Bewertung ist die Eignung von Modellen für Festpreisprojekte zu ermitteln.

Folgende Eigenschaften wurden berücksichtigt (vgl. Berg et al. 2014, S. 40 ff.):

• Strukturierung in Phasen

• Skalierbarkeit

• Flexibilität

• Vorgehen

• Methoden

• Werkzeuge

• Unterstützende Prozesse

• Praxisnähe

• Risikosteuerung

• Qualitätssicherung

Die von Berg et al. (2014) angewandten Bewertungskriterien werden anschließend zusammenfassend erläutert (vgl. Berg et al. 2014, S. 41).

Strukturierung in Phasen

Ein Phasenmodell innerhalb eines Vorgehensmodells strukturiert das Projekt und ermöglicht dessen Realisierung „mit festem Endzeitpunkt, definiertem Funktionsumfang und vorgegebenem Budget“ (Berg et. al. 2014, S. 41).

Nach Berg et. al. (2014, S. 41) bieten Modelle wie das V-Modell und RUP eine klare Phasenstruktur, die gut für große Projekte mit festen Zielen geeignet ist. Agile Methoden wie XP und Scrum konzentrieren sich laut Berg et. al. (2014, S. 41) auf den Prozess der Softwareerstellung. Sie sind iterativ und flexibel, jedoch weniger geeignet für Festpreisprojekte wegen der Herausforderungen bei Aufwandsschätzung und Vertragsgestaltung (vgl. Berg et. al. 2014, S. 42).

Skalierbarkeit

Die Skalierbarkeit von Vorgehensmodellen hängt von folgenden Faktoren ab:

• „Produktarchitektur,

• Entwicklungsprozess,

• Unternehmensorganisation,

• Teamgröße,

• Abzuliefernde Funktionalität zu einem festen Zeitpunkt“ (Berg et. al. 2014, S. 43).

Empirische Untersuchungen von Stephens und Rosenberg (2003, zitiert in Berg et. al. 2014, S. 43) zeigen, dass agile Ansätze für Großprojekte weniger geeignet sind. Phasenorientierte Modelle wie das V-Modell sind trotz Möglichkeiten des Tailorings aufgrund der umfangreichen Dokumentation aller Prozesse und Methoden für verschiedene Projektgrößen schwierig anzupassen (vgl. Berg et. al. 2014, S. 43). Stephens und Rosenberg (2003, zitiert in Berg et. al. 2014, S. 43) sowie Henrich (2002, zitiert in Berg et. al. 2014, S. 43) empfehlen, die Wahl des Vorgehensmodells anhand der Projektgröße zu treffen. Schwaber (2004, zitiert in Berg et. al. 2014, S. 43) zeigt, dass große Projekte durch die Aufteilung in kleinere Teams handhabbar gemacht werden können, was jedoch erhebliche Koordinationsaufwände erfordert.

Vorgehen und Flexibilität

Die Flexibilität eines Vorgehensmodells wird durch sein zugrunde liegendes Vorgehen (sequentiell, iterativ, etc.) bestimmt (vgl. Berg et. al. 2014, S. 44).

Phasenorientierte Modelle reagieren weniger flexibel auf kurzfristige Veränderungen als agile Ansätze und sind besser geeignet, wenn die Stakeholder:innen definierte Anforderungen auf einer stabilen Basis bereitstellen können (vgl. Berg et. al. 2014, S. 44). Berg et al. zufolge (2014, ebd.) liegen die Einschränkungen der phasenorientierten Vorgehensmodelle weniger in ihrer Flexibilität als vielmehr in ihrem sequentiellen Charakter, der eine Reaktion auf kurzfristige Änderungen erschwert.

Darüber hinaus bieten agile Ansätze aufgrund ihres iterativen Vorgehens, Vorteile durch bessere Anpassungsfähigkeit und frühere Wertschöpfung für die Organisation. Im Gegensatz dazu setzen phasenorientierte Modelle auf langfristige Planung und formalisierte Anforderungen, was dazu führen kann, dass der Wert später realisiert wird (vgl. Berg et. al. 2014, S. 44).

Die Flexibilität von agilen Ansätzen birgt jedoch das Risiko, dass dadurch eine schlechte Architektur entstehen kann, was später zu hohen Refactoring-Aufwänden führen könnte. Aus diesem Grund sind sequenzielle Modelle für nichtfunktionale Anforderungen wie Sicherheit oder restriktive Standards besser geeignet, da sequentielles Vorgehen mit formalen Dokumentationen diese Standards zuverlässig erfüllen kann (vgl. Berg et. al. 2014, S. 44).

Methoden

Methoden in der Softwareentwicklung sind systematische Vorgehensweisen, die als Grundlage für Techniken und Werkzeuge in einem Vorgehensmodell dienen. Ihre Praktikabilität ist entscheidend und muss sorgfältig geprüft werden. Beispielsweise könnte eine Methode wie Shared Code bei XP in Großprojekten zu Chaos führen (vgl. Berg et. al. (2014, S. 46).

Folgende Methoden werden von Berg et. al. (2014, S. 46) als praxistauglich erachtet und werden als Grundlage für hybride Modelle berücksichtigt:

• Requirements Engineering

• Kosten- und Aufwandsabschätzung

• Nutzenanalyse

• Prototyping und Feedbackmechanismen

• Test-Driven Development

• Acceptance Test-driven Development

• Continuous Integration

• Continuous Delivery

Methoden, die für Festpreisprojekte wie Kosten- und Nutzenanalyse erforderlich sind, fehlen in agilen Modellen wie Scrum und XP, während das V-Modell auf klassische Projektmanagementmethoden zurückgreift (vgl. Berg et. al. (2014, S. 46).

Zusammenfassend folgern Berg et. al. (2014, S. 46), dass weder ein agiler noch ein phasenorientierter Ansatz allein einem:er industriellen Softwareentwickler:in einen vollständigen Methodenansatz für Festpreisprojekte zur Verfügung stellt.

Werkzeuge

Werkzeuge unterstützen die Anwendung von Methoden und Techniken und fungieren als Steuerungselemente. Werkzeuge sollten jedoch nur im Falle von „gesetzliche[n] oder regulatorische[n] Anforderungen eines Projekts“ fest vorgeschrieben werden, da sie sonst die kreative Freiheit einschränken können (Berg et. al. 2014, S. 47).

Die Verwendung mancher Vorgehensmodelle wie beispielweise des V-Modells ist jedoch ohne eine geeignete Computerunterstützung nicht möglich. Aus diesem Grund sollte die Auswahl von Werkzeugen für jedes Projekt individuell erfolgen (vgl. Berg et. al. 2014, S. 47).

Generell sind für moderne Projekte Werkzeuge wie das Daily Build und das Defect Reporting Tool empfehlenswert. Letzteres wird zur Erfassung und Dokumentation von Defekten der Software angewendet und im Falle von agilen Projekten auch zur Erfassung von neuen Anforderungen (vgl. Berg et. al. 2014, S. 47).

Unterstützende Prozesse

In der Betriebswirtschaftslehre stellen unterstützende Prozesse betriebliche Abläufe dar, die die Kernprozesse unterstützen, aber nicht direkt zur Wertschöpfung beitragen und aus der Organisation ausgelagert werden können (vgl. Berg et. al. 2014, S. 48).

Sowohl agile als auch phasenorientierte Modelle verwenden unterstützende Prozesse wie Qualitätssicherung, Konfigurationsmanagement und Projektmanagement. Agile Ansätze integrieren diese Prozesse eng in die Entwicklung, während phasenorientierte Modelle eine mögliche Auslagerung vorsehen (vgl. Berg et. al. 2014, S. 48).

Das V-Modell verwendet folgende unterstützende Prozesse: Qualitätssicherung, Konfigurationsmanagement und Projektmanagement. Diese können externen Partnern übertragen werden, was unter Umständen auch zur Erhöhung der Komplexität von Projekten führen kann, da beispielsweise zusätzliche Kommunikationsschnittstellen notwendig sind (vgl. Berg et. al. 2014, S. 48).

Agile Vorgehensmodelle erfordern eine enge Kollaboration zwischen Arbeitnehmer:innen und Arbeitgeber:innen. Die verschiedenen Rollen und Prozesse sind jedoch stark miteinander verbunden, sodass sich eine klare Trennung zwischen internen und externen Prozessen als schwierig erweist (vgl. Berg et. al. 2014, S. 48). Im Falle von Scrum übernimmt das agile Team sowohl das Konfigurationsmanagement als auch das Projektmanagement. Letzteres wird von der:dem Scrum Master:in und/ oder von dem:der Product Owner:in durchgeführt. Die Qualitätssicherung stellt einen inhärenten Bestandteil der agilen Softwareentwicklung dar (vgl. Berg et. al. 2014, ebd.).

Praxisnähe

Die Akzeptanz und Praxisnähe eines Vorgehensmodells werden anhand der Häufigkeit seiner Nutzung gemessen. „Je häufiger ein Modell in Projekten angewendet wird, desto praxisnäher ist es“ (Berg et. al. 2014, S. 42). In der Praxis akzeptierte Modelle sind laut Studien das Wasserfallmodell, das V-Modell, Scrum und XP, da sie wesentliche Unterstützung bei der Organisation und Arbeit bieten (vgl. Berg et. al. 2014, S. 42).

Risikomanagement

Im Risikomanagement werden Strategien zur Bewältigung von Risiken festgelegt und Maßnahmen zur Erkennung, Bewertung, Kontrolle und Prävention entwickelt (vgl. Berg et al. 2014, S. 49). Agile Ansätze, wie zum Beispiel Sprints, zielen darauf ab, Risiken in Softwareprojekten durch kurze Iterationen zu minimieren. Dabei werden jedoch nicht alle Phasen des Risikomanagements abgedeckt (vgl. Berg et al. 2014, ebd.).

Berg et al. (2014) betonen, dass sowohl in agilen als auch in phasenorientierten Projekten ein umfassendes Risikomanagement erforderlich ist, wie zahlreiche Untersuchungen belegen. Daher sollte in jedem Softwareprojekt ein strukturierter Risikomanagementprozess etabliert werden. Es wird zudem empfohlen, den klassischen Risikomanagementprozess parallel zu agilen Methoden zu integrieren, um eine umfassende Risikoanalyse sicherzustellen. Diese Analyse kann bei phasenorientierten Methoden nach Abschluss jeder Phase und bei agilen Ansätzen nach jeder Iteration vorgenommen werden (vgl. Berg et al. 2014, S. 49).

Qualitätssicherung

Die Qualitätssicherung in Softwareprojekten umfasst interne und externe Aspekte. Interne Qualitätssicherung liegt in der Verantwortung der Projektmitarbeiter:innen, während externe durch unabhängige Expert:innen erfolgt. Eine Vernachlässigung der Qualitätssicherung kann zu einer unzureichenden Umsetzung des Qualitätsmanagements führen (vgl. Berg et. al. 2014, S. 49).

Folgende Kritikpunkte werden in Bezug auf traditionelle Qualitätssicherungsverfahren aufgeführt: Sie haben einen starken Fokus auf Prozesse, der jedoch für die Sicherstellung der Produktqualität unzureichend ist. Zudem konzentriert sich die Standardisierung von Prozessen vor allem auf komplexe Szenarien, was für kleinere und mittlere Softwareprojekte oft zu umfangreich ist. Darüber hinaus erfordern externe Audits eine ausführliche Dokumentation, was oft als belastend und bürokratisch empfunden wird (vgl. Berg et. al. 2014, S. 49).

Im Gegensatz dazu liegt in agilen Projekten der Schwerpunkt weniger auf der Dokumentation, sondern vielmehr auf der Erzielung von "funktionalen und schnellen Ergebnissen" (Berg et al., 2014, S. 50). Dennoch sind Spezifikationen für die Qualitätssicherung und „die langfristige Dokumentation von Designentscheidungen“ wichtig " (Berg et al., 2014, S. 50). In agilen Projekten stellt die Qualitätssicherung kein separater Prozess dar. Stattdessen werden Tests von den Entwicklern durchgeführt. Die Dokumentation des Designs erfolgt in Form von Code-Kommentaren. Durch ein spezielles Qualitätssicherungsteam kann eine Reduktion potenzieller Fehler und eine Optimierung des Entwicklungsprozesses erreicht werden (Berg et al., 2014, S. 50).

Übersicht der bewerteten Modelle

Abschließend wird die von Berg et al. (2014) durchgeführte Bewertung für das Wasserfallmodell, V-Modell, XP und Scrum tabellarisch dargestellt (s. Tabelle 2.8).

Basis für das theoretische Modell

Ausgehend vom grundlegenden Denkmodell der Erfolgsfaktorenforschung, das besagt, dass „einige wenige Erfolgsfaktoren existieren, die den langfristigen Erfolg maßgeblich beeinflussen“ (Baumgarth & Evanschitzky 2009, S. 237), wird in der vorliegenden Arbeit angenommen, dass es eine Anzahl von Auswahlkriterien gibt, die erfolgskritisch bei der Entscheidung für ein geeignetes Vorgehensmodells sind. Eine Nichtberücksichtigung dieser Erfolgsfaktoren würde zur Auswahl eines nicht geeigneten Vorgehensmodells führen und somit nicht zum „richtigen“ Projektmanagement-Modell für ein IT-Projekt.

Dem Forschungsprozess der Erfolgsfaktorenforschung folgend, soll im ersten Schritt ein theoretisches Erfolgsfaktorenmodell abgeleitet werden, das auf bestehenden Theorien und bisherigen Forschungsergebnissen in der wissenschaftlichen Literatur basiert (vgl. Baumgarth & Evanschitzky 2009, S. 241).

In der wissenschaftlichen Literatur werden häufig verschiedene entscheidende Faktoren bei der Auswahl eines geeigneten Vorgehensmodells aufgeführt. Beispielsweise betonen Hansen et al. (2019, S. 367) die Projektgröße und -dauer, das Ausmaß der Präzision der Anforderungen sowie die Anzahl der erforderlichen Mitarbeitenden als wesentliche Faktoren, während (Tiemeyer 2018, S. 291) neben der Projektgröße auch die Komplexität des Projekts und dessen spezifische Ziele und Anforderungen hervorhebt.

Während in der Fachliteratur Einigkeit darüber besteht, dass ein VM nicht als allgemeingültig angesehen werden kann (vgl. Hansen et al. 2019, S. 367, Lemétayer 2010, S. 1), gibt es keinen Konsens über die relative Bedeutung dieser Faktoren, darüber, wie diese zu messen sind, und über die Intensität ihrer Auswirkungen auf den Projekterfolg (vgl. Lemétayer 2010, S. 34).

Um eine möglichst umfassende Zusammenstellung der potenziellen Erfolgsfaktoren zu erzielen und somit dem Denkmodell der Erfolgsfaktorenforschung gerecht zu werden (vgl. Baumgarth & Evanschitzky 2009, ebd.), soll daher zunächst eine quantitative Inhaltsanalyse durchgeführt werden.

Im Rahmen der vorliegenden Arbeit wird eine Häufigkeitsanalyse zur Ermittlung des theoretischen Erfolgsmodells gewählt. Anhand der Häufigkeitsanalyse sollen die potenziellen Top-10-Erfolgsfaktoren aus theoretischer Sicht identifiziert werden, um die theoretische Grundlage für die Beantwortung der ersten Forschungsfrage dieser Arbeit zu schaffen:

• FF01: Welche in der wissenschaftlichen Literatur diskutierten Erfolgsfaktoren bei der Auswahl von Projektmanagementmodellen sind im Kontext des IT-Projektmanagements in deutschen Großunternehmen der Softwarebranche besonders relevant?

Häufigkeitsanalyse

Bei einer Häufigkeitsanalyse wird ein Kategoriensystem ausgewertet, indem im einfachsten Fall ein Merkmal mit entsprechenden Ausprägungen pro Text einzeln ausgezählt werden. Dabei werden die Zählergebnisse in einer Tabelle eingetragen (vgl. Bortz & Döring 2007, S. 151). Im Falle der Auswahl eines geeigneten Vorgehensmodells wäre es sinnvoll auszuzählen, wie oft verschiedene Autor:innen ein bestimmtes Auswahlkriterium nennen. Die Häufigkeit der Nennung in der analysierten Literatur kann dabei als Indikator für die Intensität der Auseinandersetzung der wissenschaftlichen Literatur mit einem bestimmten Erfolgsfaktor bei der Auswahl eines geeigneten Vorgehensmodells interpretiert werden (vgl. Bortz & Döring 2007, S. 152).

Die für die Häufigkeitsanalyse relevante Literatur wurde anhand einer systematischen Literaturanalyse identifiziert, die im Folgenden näher erläutert wird.

Systematische Literaturanalyse

Um die relevanten Quellen für die deutsche Softwarebranche zu identifizieren, wurde dabei eine umfassende Literaturrecherche in der Datenbank Google Scholar mit diversen Keyword-Kombinationen wie z.B. „Auswahlkriterien AND Vorgehensmodelle AND Softwareentwicklung“, „IT-Projektmanagement“, „Vorgehensmodelle AND Softwareentwicklung“ und „Auswahlkriterien AND Vorgehensmodelle AND Softwareentwicklung“ usw. durchgeführt.

Da es angestrebt wurde, den aktuellen Forschungsstand widerzugeben, wurde zu jeder Keyword-Kombination in Google Scholar nach deutschsprachigen Quellen ab Jahre 2000 nach Relevanz sortiert gesucht. Um die Suche pro Keyword-Kombination etwas einzuschränken wurden nur die Abstracts der ersten 70 Treffer sortiert nach Relevanz reviewt. Dabei wurden Bachelor- und Masterarbeiten ausgeschlossen.

Die ausgewählten Ergebnisse nach Abstract-Review wurden dann in digitaler oder gedruckter Form besorgt. Ein Teil der Quellen konnte jedoch nicht gefunden werden und konnte somit nicht für die weitere Analyse herangezogen werden.

Im Rahmen des Inhaltsreviews stellten sich weitere Ergebnisse als ungeeignet heraus und wurden aussortiert. Die ausgewählten Ergebnisse nach dem Inhaltsreview wurden schließlich als Quellen für die Häufigkeitsanalyse berücksichtigt.

Tabelle 2.9 fasst die Ergebnisse der systematischen Literaturanalyse zusammen.

Insgesamt wurden 52 Quellen identifiziert, die sich mit den Auswahlkriterien von Vorgehensmodellen in der Softwarebranche befassen. Die vollständige Liste der im Rahmen der systematischen Literaturanalyse ermittelten Quellen ist in Anhang 1 aufgeführt.

Die ermittelten 52 Quellen bildeten die Grundlage für die Identifizierung der Erfolgsfaktoren bei der Auswahl von Projektmanagementmodellen im Kontext des IT-Projektmanagements in deutschen Großunternehmen der Softwarebranche.

Aus den 52 Quellen konnten 97 Auswahlkriterien identifiziert werden, die jeweils zu folgenden 3 Hauptkategorien zugeordnet werden können: Projekt, Projektumfeld und Vorgehensmodell. Basierend auf der absoluten Häufigkeit des Kriteriums in den analysierten Quellen konnte ein Ranking vorgenommen werden (vgl. Tabelle 2.10).

Die vollständige Tabelle zur Häufigkeitsanalyse kann im Anhang 2 der vorliegenden Arbeit eingesehen werden.

Das Ranking spiegelt die Intensität der Auseinandersetzung mit dem jeweiligen Faktor wider und dient als Indikator seiner Relevanz im theoretischen Kontext. Anhand des Rankings konnten die Top-10-Erfolgsfaktoren bei der Auswahl eines geeigneten Vorgehensmodells in der Softwarebranche identifiziert werden.

Dabei handelt es sich um 2 vorgehensmodell-spezifische, 5 projekt-spezifische und 3 projektumfeld-spezifische Faktoren.

• Vorgehensmodell-spezifische Erfolgsfaktoren:

  • EF01 Vorgehensmodell: Flexibilität & Anpassbarkeit

  • EF05 Vorgehensmodell: Projektspezifisches Tailoring

• Projekt-spezifische Erfolgsfaktoren:

  • EF02 Projekt: Komplexität des Projekts

  • EF03 Projekt: Projektgröße - Anzahl der Mitarbeiter:innen

  • EF04 Projekt: Dynamik der Anforderungen

  • EF07 Projekt: Projekttyp

  • EF08 Projekt: Projektgröße – Projektdauer

• Projektumfeld-spezifische Erfolgsfaktoren:

  • EF06 Projektumfeld: Unternehmenskultur & -mindset des:der Auftragnehmer:in

  • EF09 Projektumfeld: Qualifikationsgrad der Teammitglieder

  • EF10 Projektumfeld: Erwartete Beteiligung der Kund:innen.

Die Zuordnung der Faktoren zu den Kategorien Projekt und Projektumfeld erfolgte in Anlehnung an Paukner et al. (2018, S. 168), die projektspezifischen Parameter als durch den jeweiligen Projektauftrag festgelegt betrachten und Umgebungsfaktoren als von der Organisation vorgegeben ansehen. Unter vorgehensmodellspezifischen Parametern werden in der vorliegenden Arbeit Faktoren verstanden, die Charakteristika und Anforderungen eines Vorgehensmodells betreffen.

Die prozentuale Verteilung der Auswahlkriterien pro Häufigkeitsbereich wird in Abbildung 2.35 dargestellt.

Die Ergebnisse zeigen, dass die Mehrheit der identifizierten Erfolgsfaktoren nur selten erwähnt wurde. Insgesamt 63 Faktoren wurden lediglich zwischen 1 und 4 Mal genannt (Häufigkeitsbereich HR04), was darauf hindeutet, dass diese Faktoren als weniger relevant angesehen werden.

16 Faktoren wurden etwas häufiger genannt, nämlich zwischen 5 und 9 Erwähnungen (Häufigkeitsrange HR03), was auf eine moderate Relevanz hinweist. 13 Faktoren wurden noch häufiger erwähnt, nämlich zwischen 10 und 19 Mal (Häufigkeitsrange HR02), was auf eine höhere Bedeutung dieser Faktoren schließen lässt.

Die höchste Erwähnungsfrequenz – zwischen 20 und 28 Erwähnungen (HR01) – wurde bei lediglich 5 Faktoren festgestellt. Diese Faktoren sind vermutlich von größter Bedeutung und werden als die wichtigsten Erfolgsfaktoren angesehen.

Insgesamt deutet die Verteilung der Erwähnungen darauf hin, dass es eine kleine Gruppe von Faktoren gibt, die als besonders entscheidend für den Projekterfolg betrachtet werden.

Die Häufigkeitsanalyse ergab folgendes, in der Abbildung dargestelltes, theoretisches Erfolgsfaktoren-Modell zur Auswahl von geeigneten Vorgehensmodellen für IT-Projekte in der Softwarebranche.

Die Ergebnisse zeigen eine signifikante Übereinstimmung zwischen den in dieser Arbeit ermittelten Erfolgsfaktoren und den bestehenden Modellen von Böhm und Turner (2009) sowie Timinger (2021). Fünf der hier identifizierten Erfolgsfaktoren (Teamgröße, Dynamik der Anforderungen, Qualifikationsgrad des Personals, Unternehmenskultur und Gefährdungspotenzial) sind sowohl im 5-Dimensionen-Erfolgsfaktorenmodell von Böhm & Turner (2009) als auch in Timingers (2021) Netzdiagramm-Modell enthalten, wobei der Faktor "Gefährdungspotenzial" in der vorliegenden Arbeit basierend auf den Ergebnissen der Kontingentanalyse eine geringere Bedeutung hat (Platz 16 im Ranking s. auch Anhang 2). Darüber hinaus stimmen auch die folgenden zwei weiteren Faktoren im theoretischen Erfolgsfaktorenmodell zur Auswahl von Vorgehensmodellen in der vorliegenden Arbeit mit Timingers Parametern überein: die Komplexität des Projekts und die Einbeziehung der Kund:innen.

Diese Übereinstimmungen unterstreichen die Relevanz der identifizierten Erfolgsfaktoren und bestätigen ihre Bedeutung für die Wahl eines geeigneten Vorgehensmodells in verschiedenen Projektsituationen.

Die gemäß der Theorie ermittelten Erfolgsfaktoren sollen als Basis für den empirischen Teil der vorliegenden Arbeit dienen. Anhand eines Online-Fragebogens soll dann ermittelt werden, inwieweit diese Faktoren von Projektmanager:innen bei der Auswahl von Projektmanagementmodellen für IT-Projekte in deutschen Großunternehmen der Softwarebranche in der Praxis angewendet werden.

Im Folgenden werden die im Rahmen dieser Arbeit anhand der Häufigkeitsanalyse ermittelten Top-10-Erfolgsfaktoren näher erläutert:

EF01 Vorgehensmodell: Flexibilität & Anpassbarkeit

Der primäre Erfolgsfaktor ist die für das Projekt erforderliche Flexibilität und Anpassbarkeit des Vorgehensmodells. Dies bezieht sich auf die Anforderungen des spezifischen Projektkontexts hinsichtlich der inhärenten Flexibilität und Anpassungsfähigkeit des Modells bzw. auf den Grad an Flexibilität und Anpassbarkeit, den das Vorgehensmodell für diesen Kontext erfüllen muss.

Anpassbarkeit wird von Fritzsche & Keil (2007, S. 7) als die Fähigkeit eines Vorgehensmodells zur Anpassung an den Projektkontext definiert. Dabei ist die Möglichkeit des Tailorings, sowie die Fähigkeit, auf Änderungen im Projekt zu reagieren besonders relevant (Fritzsche & Keil 2007, ebd.).

Die Flexibilität eines Vorgehensmodells wird durch seine zugrunde liegende Vorgehensstrategie (sequentiell, iterativ, etc.) definiert (vgl. Berg et. al. 2014, S. 44).

Agile Vorgehensmodelle zeichnen sich aufgrund ihres iterativ-inkrementellen Vorgehens durch höhere Flexibilität aus und erlauben kontinuierliche Anpassungen (vgl. Berg et. al. 2014, ebd., Brönimann & Bommer 2022, S. 124). Sie ermöglichen eine schnellere Reaktion auf Veränderungen, können jedoch schlechte Architektur und hohe Refactoring-Aufwände zur Folge haben (vgl. Berg et. al. 2014, ebd.).

Sequenzielle Modelle zeichnen sich durch eine starre Strukturierung aus und sind daher weniger flexibel gegenüber kurzfristigen Veränderungen (vgl. Berg et. al. 2014, S. 44, Brönimann & Bommer 2022, S. 124). Diese Modelle basieren auf langfristiger Planung und formalen Anforderungen und sind daher besser für nichtfunktionale Anforderungen wie Sicherheit und restriktive Standards geeignet, da sie diese Standards durch formale Dokumentationen zuverlässig erfüllen können (vgl. Berg et. al. 2014, ebd.).

EF02 Projekt: Komplexität des Projekts

Die Wahl eines Vorgehensmodells hängt maßgeblich auch vom Komplexitätsgrad des Projekts ab:

Planbasierte Vorgehensmodelle sind besonders für einfache Projekte geeignet, die sich durch klar definierte und übersichtliche Aufgabenstellungen auszeichnen. Da die Anforderungen und der Lösungsweg gut bekannt und stabil sind, ermöglichen diese Modelle eine präzise Planung und Ausführung. Dabei spielen Best Practices und maßgeschneiderte Anpassungen (Tailoring) eine wesentliche Rolle zur Steigerung des Projekterfolgs. (vgl. Brönimann & Bommer 2022, S. 125, Timinger 2021, S. 196).

Agile Vorgehensmodelle sind besonders vorteilhaft für komplexe Projekte, die durch unbekannte Einflussfaktoren und ein unvorhersagbares System gekennzeichnet sind. Durch das kontinuierliche Feedback von Stakeholdern, das durch die iterativ-inkrementelle Entwicklung ermöglicht wird, kann effektiv auf neue Erkenntnisse und Veränderungen reagiert und der Lösungsweg dynamisch angepasst werden (vgl. Brönimann & Bommer 2022, S. 124-125, Timinger 2021, S. 197).

Hybride Vorgehensmodelle bzw. gezielte Kombinationen aus planbasierten und agilen Vorgehensmodellen sind optimal für komplizierte Projekte, die zwar vorhersehbar, aber komplex in der Handhabung sind. Diese Projekte können zunächst von den Vorteilen agiler Modelle bei der erstmaligen Durchführung profitieren. Mit zunehmender Routine und klaren Aufgabenverteilungen kann jedoch ein strukturiertes planbasiertes Vorgehensmodell vorteilhaft sein. Hybride Modelle kombinieren die Stärken beider Ansätze und passen sich den unterschiedlichen Anforderungen des Projektes an (vgl. Brönimann & Bommer 2022, S. 125, Timinger 2021, S. 197).

Bei als chaotisch eingestuften Projekten sollen zunächst die Aspekte ihrer Komplexität bewältigt werden, indem komplexitätsreduzierende Maßnahmen ergriffen werden (vgl. Schwaber 2004, S. 13, Dittmann & Zaeri 2023, S. 243).

EP03 Projekt: Projektgröße - Anzahl der Mitarbeiter:innen

Die Anzahl der Mitarbeiter:innen im Projekt bzw. die Größe des Teams stellt ebenfalls einen Erfolgsfaktor bei der Auswahl von Vorgehensmodellen dar. Agile Vorgehensmodelle sind am effektivsten für kleine Teams und lassen sich weniger gut auf größere Teams skalieren (vgl. Wysocki 2014, S. 48-49). Größere Teams erfordern einen zusätzlichen Koordinationsaufwand, der durch spezifische Pläne im Rahmen eines planbasierten Vorgehensmodells gut unterstützt werden kann (vgl. Timinger 2021, S. 203).

EP04 Projekt: Dynamik der Anforderungen

Ein planbasiertes Vorgehensmodell sollte gewählt werden, wenn die Anforderungen an das Projekt ausreichend definiert und die Methoden bzw. Technologien zur Umsetzung bekannt sind. In solchen Fällen ist die Zukunft des Projekts planbar, und der Erfolg wird an der Einhaltung und Umsetzung des Plans gemessen. Planbasierte Modelle sind jedoch weniger flexibel und können bei Änderungen zeit- und ressourcenintensiv sein, da sie eine Überarbeitung der Pläne erfordern (vgl. Timinger 2021, S. 13; Wysocki 2014, S. 45, 48).

Im Gegensatz dazu eignen sich agile Vorgehensmodelle besser für Projekte mit unklaren Anforderungen und unbekannten Methoden zur Umsetzung. Diese Modelle sind darauf ausgelegt, mit Unsicherheiten und Veränderungen umzugehen, indem sie Just-in-Time-Planung nutzen und Ressourcenverschwendung vermeiden. Agile Modelle sind darauf angewiesen, kontinuierlich Anpassungen vorzunehmen, um effizient und flexibel auf sich verändernde Bedingungen zu reagieren (vgl. Timinger 2021, S. 13; Wysocki 2014, S. 48).

EP05 Vorgehensmodell: Projektspezifisches Tailoring

Im Rahmen des Tailoring-Prozesses sollen die Aktivitäten und Ergebnisse eines Vorgehensmodells an die spezifischen Anforderungen und Rahmenbedingungen des jeweiligen Projekts gezielt angepasst werden, sodass eine effektive Anwendung des Modells gewährleistet werden kann (vgl. Fischer et al. 1998, S. 29-30).

Tailoring umfasst sowohl vertragsrelevantes als auch technisches Tailoring. Das Modell wird an die spezifischen Bedingungen angepasst, indem z. B. bestimmte Vorgehensbausteine und Strategien ausgewählt oder nicht benötigte Teile des Modells ausgeschlossen werden. Durch Tailoring soll auch eine dynamische Anpassung an neue Erkenntnisse oder Projektgegebenheiten vorgenommen werden (vgl. Fischer et al. 1998, S. 29-30; Broy & Rausch 2005, S. 222-223).

EP06 Projektumfeld: Unternehmenskultur & -mindset des:der Auftragnehmer:in

Die Auswahl eines Vorgehensmodells sollte maßgeblich durch die bestehende Unternehmenskultur sowie das Mindset des:der Auftragnehmer:in bestimmt werden. Planbasierte Vorgehensmodelle eignen sich für strukturierte und hierarchisch organisierte Organisationen, während agile Modelle besser für flexible und kooperative Umgebungen geeignet sind. Hybride Modelle bieten einen Mittelweg für Organisationen, die sowohl planbasierte als auch agile Elemente integrieren möchten.

Planbasierte Vorgehensmodelle sind insbesondere für Organisationen mit komplexen Hierarchien und umfassenden Abstimmungsprozessen geeignet. Sie erfordern detaillierte Planung und Kontrolle, um die Koordination und Umsetzung von Projekten zu gewährleisten. In Unternehmen, die durch zahlreiche Hierarchieebenen und eine auf strukturierte Planung und Kontrolle ausgerichtete Kultur geprägt sind, bieten planbasierte Modelle die notwendige Struktur und Klarheit. Sie sind optimal für Situationen, in denen die Anforderungen an das Projekt klar definiert und die Methoden zu deren Umsetzung bereits bekannt sind. Planbasierte Modelle erfordern keine grundlegende Veränderung der Unternehmenskultur (vgl. Timinger 2021, S. 202).

Agile Vorgehensmodelle lassen sich besonders gut in Organisationen mit flachen Hierarchien und kooperativen Strukturen einsetzen. Sie fördern Flexibilität, Anpassungsfähigkeit und kontinuierliches Feedback, was in Umfeldern mit offenen Kommunikationswegen und enger Zusammenarbeit von Vorteil ist. Der Einsatz agiler Modelle erfordert eine Anpassung der Unternehmenskultur hin zu mehr Selbstorganisation und Flexibilität. Unternehmen, die eine agile Denkweise bereits besitzen oder bereit sind, diese zu entwickeln, profitieren besonders von agilen Ansätzen. Die Einführung agiler Modelle kann jedoch signifikante organisatorische Veränderungen und eine Anpassung der Unternehmenskultur mit sich bringen, insbesondere bei großen Projekten oder komplexen Teamstrukturen (vgl. Berg et al. 2014, S. 45-46, 51).

Hybride Vorgehensmodelle kombinieren Elemente aus sowohl planbasierten als auch agilen Ansätzen und bieten eine sinnvolle Option, wenn eine vollständige Umstellung der Unternehmenskultur nicht möglich oder wünschenswert ist. Hybride Modelle ermöglichen es, agile Methoden innerhalb eines traditionellen Rahmens zu integrieren, wodurch die Notwendigkeit einer umfassenden kulturellen Anpassung reduziert wird. Sie bieten die erforderliche Flexibilität für sich ändernde Anforderungen, ohne die bestehende Organisationsstruktur vollständig umzugestalten (vgl. Berg et al. 2014, S. 51).

EF07 Projekt: Projekttyp

Die Auswahl eines geeigneten Vorgehensmodells setzt unter anderem die Zuordnung des IT-Projektes zum Projekttyp voraus (vgl. Wieczorrek & Mertens 2008, S. 9). Die Klassifizierung erfolgt dabei je nach geplantem Vorhaben – wie z.B. Integration, Weiterentwicklung, etc. (vgl. Tiemeyer 2018, S. 291).

Jeder IT-Projekttyp erfordert einen spezifischen methodischen Ansatz, um adäquat adressiert zu werden (vgl. Tiemeyer 2018, S. 296). Beispielsweise sind laut Tiemeyer (2018, ebd.) agile Vorgehensmodelle für Migrationsprojekte ungeeignet, da sie durch starre, festpreisgebundene Anforderungen gekennzeichnet sind. Darüber hinaus sind auch je nach Projekttyp unterschiedliche Schätzmethoden erforderlich. Während bei Wartungsprojekten der gegenwärtige Ist-Zustand als Grundlage dient, orientieren sich die Schätzmethoden bei Entwicklungsprojekten am vorgesehenen Soll-Zustand. Folglich ist es von zentraler Bedeutung, das geeignete Vorgehensmodell für jedes Projekt sorgfältig zu identifizieren und anzuwenden (vgl. Tiemeyer 2018, S. 297).

Prototypprojekte haben zu Beginn ein unklar definiertes Ziel, das im Verlauf des Projekts entdeckt wird. Der Ansatz ist iterativ und agil, wobei mehrere Entwicklungszyklen durchlaufen werden, um einen funktionalen Prototyp zu erstellen (vgl. Tiemeyer 2018, S. 294).

Entwicklungsprojekte haben ein klar spezifiziertes Ziel, das im Voraus detailliert definiert wird. Der:die Anwender:in formuliert im Vorfeld präzise die Anforderungen an das gewünschte IT-Produkt. Dem Entwicklungsprozess geht ein Analyseprojekt voraus, in dessen Rahmen die Anforderungen systematisch erfasst, analysiert und spezifiziert werden. Die Anforderungsanalyse und Dokumentation erfolgen vor der eigentlichen Entwicklung, und der Aufwand wird auf Basis von Lasten- und Pflichtenheften geschätzt (vgl. Tiemeyer 2018, S. 294).

Weiterentwicklungsprojekte bauen auf einem bestehenden IT-System auf, indem neue Komponenten, Schnittstellen oder Datenbanktabellen, in die vorhandene Systemarchitektur eingefügt werden und sind daher oft überschaubar. Die Kosten für die Weiterentwicklung können anhand der bisherigen Entwicklungskosten ermittelt werden (vgl. Tiemeyer 2018, S. 295).

Wartungsprojekte zielen darauf ab, bestehende IT-Systeme durch Fehlerbehebungen, Anpassungen an Funktionen und Datenstrukturen sowie kleinere Erweiterungen zu verbessern. Sie werden häufig durch Systemaktualisierungen oder gesetzliche Anforderungen ausgelöst und verursachen signifikante Kosten. Die Aufwandschätzung ist komplex, da sowohl die Anzahl der Fehler als auch die Auswirkungen der erforderlichen Änderungen berücksichtigt werden müssen. Wartungsaufgaben sind typischerweise kurzfristig und wiederkehrend und erfordern eine jährliche Budgetierung (vgl. Tiemeyer 2018, S. 295).

Sanierungsprojekte zielen darauf ab, die Qualität bestehender Systeme zu verbessern, ohne deren Funktionalität zu ändern. Die Qualitätssteigerung erfolgt durch Refactoring des Codes, wobei das Budget fixiert ist und die Zielsetzung flexibel bleibt (vgl. Tiemeyer 2018, S. 296).

Migrationsprojekte haben das Ziel, ein System in eine andere technische Umgebung zu verschieben, z. B. durch Austausch der Programmiersprache oder Hardware. Die funktionale Äquivalenz ist das Hauptziel, wobei oft Kompromisse bei der Qualität gemacht werden (vgl. Tiemeyer 2018, S. 296).

Bei Integrationsprojekten werden bestehende Systeme miteinander verknüpft oder neue Systeme in ein bestehendes Netzwerk integriert. Diese Projekte erfordern hohes technisches Know-how und einen umfangreichen Testaufwand und zeichnen sich durch eine Vielfalt von Technologien und hohe Komplexität aus (vgl. Tiemeyer 2018, S. 296).

Installationsprojekte beinhalten die Einführung von Standard-IT-Produkten in bestehende Umgebungen. Sie erfordern Kenntnisse der Produkte und deren Anpassung an die Umgebung sowie Installation, Prozessanpassungen und Tests. Die Kosten werden auf Basis von Erfahrungen mit ähnlichen Installationen geschätzt und oft durch Produktlieferanten unterstützt (vgl. Tiemeyer 2018, S. 297).

EF08 Projekt: Projektgröße – Projektdauer

Die Projektdauer ist grundsätzlich etwa über die Anzahl der eingesetzten Projektmitarbeiter:innen beeinflussbar. In der Praxis reicht die Projektdauer von wenigen Personenmonaten bis zu mehreren Personenjahren (vgl. Tiemeyer 2018, S. 4).

Eine längere Projektdauer in Personenmonaten korreliert mit einer erhöhten Komplexität des Projekts und erfordert die Implementierung eines Vorgehensmodells, das spezialisierte Konzepte zur Bewältigung von Komplexität umfasst (vgl. Bunse & Knethen 2008, S. 159-160). Laut Bunse und Knethen (2008, S. 160, 172) sind bei einer Projektdauer ab 13 Personenmonaten skalierbare iterativ-inkrementelle Vorgehensmodelle besonders empfehlenswert. Diese Modelle bieten die Flexibilität zur Anpassung und ermöglichen die Zerlegung eines Systems in Inkremente, die aufeinander aufbauend entwickelt werden können, wodurch Risiken effektiv minimiert werden können. (vgl. Bunse & Knethen 2008, ebd.).

EF09 Projekt: Qualifikationsgrad der Teammitglieder

Die Auswahl des Vorgehensmodells sollte auf dem Qualifikationsgrad der Teammitglieder basieren:

Agile Vorgehensmodelle sind optimal, wenn das Team über die Fähigkeit zur selbstorganisierten Arbeitsweise verfügt. Die Implementierung eines agilen Frameworks sollte jedoch schrittweise erfolgen, um die Selbstorganisation und Verantwortungsdelegation innerhalb des Teams systematisch zu fördern (vgl. Dittmann & Zaeri 2023, S. 129-130).

Planbasierte Vorgehensmodelle sind besonders geeignet, wenn das Team nicht über die notwendige Qualifikation für agile und selbstorganisierte Arbeitsweisen verfügt. In solchen Fällen kann eine strukturierte Planung und präzise Koordination der Aufgaben durch planbasierte Modelle eine effektivere Unterstützung bieten (vgl. Timinger 2021, S. 202-203).

EF10 Projektumfeld: Erwartete Beteiligung der Kund:innen

Agil durchgeführte Projekte werden als erfolgreich betrachtet, wenn eine hohe Beteiligung und enge Zusammenarbeit zwischen Kund:innen und Entwicklungsteams gewährleistet ist. Die Entdeckung effektiver Lösungen setzt voraus, dass Kund:innen und Entwicklungsteams in einem offenen und ehrlichen Umfeld kooperativ zusammenarbeiten. Demnach ist eine intensive und konstruktive Interaktion zwischen Kund:innen und Entwicklungsteams ein wesentlicher Erfolgsfaktor für agile Vorgehensmodelle (vgl. Wysocki 2014, S. 48-49).

Bei sequenziellen Vorgehensmodellen wie dem Wasserfallmodell werden Kund:innen ausschließlich zu Beginn des Projekts sowie bei der Produktübergabe eingebunden und besitzen während des Projektverlaufs keinen Einfluss auf die fortlaufende Entwicklung. Diese Vorgehensweise birgt jedoch die Gefahr, dass Fehler oder Unzulänglichkeiten erst während der Nutzung des Produkts identifiziert werden (vgl. Fritzsche & Keil 2007, S. 11).