Lean-Adaptive Project Portfolio Management - Claus Hüsselmann - E-Book

Lean-Adaptive Project Portfolio Management E-Book

Claus Hüsselmann

0,0
69,99 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.
Mehr erfahren.
Beschreibung

Das Multiprojektmanagement, insbesondere das Projekt-Portfoliomanagement, ist eine relativ neue Disziplin. Aufgrund der spezifischen Anforderungen der IT-Welt und der Dynamik der Wirtschaftswelt hat sich in den letzten Jahren der Wunsch nach einer Weiterentwicklung des Multiprojektmanagements entwickelt. Es besteht ein Bedarf nach flexibleren Ansätzen, um die Steuerung von Projektlandschaften zu verbessern. Das Lean-Adaptive PPM-Konzept bietet Unternehmen eine Blaupause für das Design ihres eigenen PPM-Systems. Es generalisiert bekannte agile Ansätze zur Portfoliosteuerung und kann auf betriebliche Projekte jeglicher Art angewendet werden. Das entwickelte Konzept basiert auf Analysen von Unternehmensberichten, empirischen Studien, Fachdiskussionen, Interviews mit Expert:innen und eigenen Erfahrungen und bietet Unternehmen ein anwendbares Referenzmodell für das interne Projektmanagement.  

Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:

EPUB
MOBI

Seitenzahl: 566

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Inhaltsverzeichnis

InhaltsverzeichnisHinweis zum UrheberrechtImpressumAbbildungsverzeichnisTabellenverzeichnisGeleitwortVorwortMitwirkendeAbkürzungsverzeichnis1 Einleitung – Hintergrund und Motivation1.1 Kritik am klassischen Projektportfoliomanagement1.2 Höhere Anforderungen an die Flexibilität1.3 Lean-adaptive PPM als Konsequenz1.4 Anwendung und Zielgruppe2 Projektportfolio- und Lean Management – grundlegende Elemente2.1 Projektportfoliomanagement2.1.1 Management von Projektlandschaften2.1.2 Begriffsdefinitionen2.1.3 Kunden des PPMs2.1.4 PPM-Wertströme – High-Level-Betrachtung2.1.5 PPM als komplexes System2.1.6 Aktuelle Entwicklungen im Projektportfoliomanagement2.1.6.1 Produktentwicklung statt Projektabwicklung2.1.6.2 Kürzere Zyklen durch die VUKA-Welt2.1.6.3 Agile oder Multimodale Projektlandschaften2.2 Lean Management und Agilität2.2.1 Lean Management2.2.2 Agilität2.2.3 Zusammenführung beider Ansätze2.3 Lean Thinking im PPM2.3.1 Kunde und Wert im PPM2.3.2 Flussprinzip2.3.3 Pull-Prinzip2.3.4 Perfektion2.4 PPM als Managementsystem2.4.1 Big Picture des PPM-Systems2.4.2 Dimensionen des LAUP2-Frameworks2.4.2.1 Ziele & Kennzahlen2.4.2.2 Prozesse & Disziplinen2.4.2.3 Rollen & Aufbauorganisation2.4.2.4 Praktiken & Richtlinien2.4.2.5 Daten & Systeme2.4.2.6 Erfolgsfaktoren2.4.2.7 Grundsätze & Prinzipien2.4.3 Life Cycle & Domänen3 Projektportfoliomanagement ausrichten – das Zielsystem3.1 PPM-Vision3.2 PPM-Balanced Scorecard3.2.1 Aufbau3.2.2 Receiving System3.2.3 Processing System3.2.4 Prozesse3.2.5 Ressourcen3.3 Kennzahlen für das PPM3.3.1 Kennzahlen als Performance-Indikatoren3.3.2 PPM-Kennzahlenkanon3.3.3 Fokussierung des Kennzahlenkanons3.3.4 Durchlaufzeit im Fokus3.4 PPM-Erfolgsfaktoren3.5 »Approach follows context«4 Projektportfoliomanagement strukturieren – das prozessorientierte Referenzmodell4.1 Corporate Development4.2 PPM-Prozessmodell4.2.1 High-Level-Prozessmodell4.2.2 Geschäftsprozesse4.2.3 Prozesssteckbriefe4.2.3.1 PPM-Prozesssteckbrief PPM-System Strategy Determination4.2.3.2 PPM-Prozesssteckbrief PP Authorization4.2.3.3 PPM-Prozesssteckbrief PPM Governance4.2.3.4 PPM-Prozesssteckbrief Project Demand Management4.2.3.5 PPM-Prozesssteckbrief Performance Management4.2.3.6 PPM-Prozesssteckbrief Resource Management4.2.3.7 PPM-Prozesssteckbrief Benefits Management4.2.3.8 PPM-Prozesssteckbrief Development of PPM Methods & Tools4.2.3.9 PPM-Prozesssteckbrief PPM System Operations4.2.3.10 PPM-Prozesssteckbrief Information & Knowledge Management4.2.3.11 PPM-Prozesssteckbrief Client & Stakeholder Management4.2.3.12 PPM-Prozesssteckbrief Risk & Opportunity Management4.2.4 Arbeitsvorgänge4.2.5 Prozesse und Domänen4.3 Rollenmodell4.3.1 Identifikation der PPM-Rollen4.3.2 Rollensteckbriefe4.3.2.1 PPM-Rollensteckbrief Strategy Sponsor4.3.2.2 PPM-Rollensteckbrief PPM Sponsor4.3.2.3 PPM-Rollensteckbrief Project Portfolio Manager4.3.2.4 PPM-Rollensteckbrief Project Portfolio Analyst4.3.2.5 PPM-Rollensteckbrief Project/Program Sponsor4.3.2.6 PPM-Rollensteckbrief Program Manager4.3.2.7 PPM-Rollensteckbrief Project Manager4.3.2.8 PPM-Rollensteckbrief Project Management Expert4.3.2.9 PPM-Rollensteckbrief Project Team Member4.3.2.10 PPM-Rollensteckbrief Subject Manager4.3.2.11 PPM-Rollensteckbrief Resource Coordinator4.3.2.12 PPM-Rollensteckbrief Knowledge Manager4.3.2.13 PPM-Rollensteckbrief Domain Authority4.3.2.14 PPM-Rollensteckbrief Project Portfolio Board4.3.2.15 PPM-Rollensteckbrief Program/Project Steering Committee4.3.2.16 PPM-Rollensteckbrief Strategisches Project Management Office4.3.2.17 PPM-Rollensteckbrief Operatives Project Management Office4.3.3 Zusammenhang PPM-Rollen und -Prozesse4.3.4 Zusammenhang PPM- und Linienrollen4.4 Praktiken4.4.1 Methoden/Tools4.4.2 Regel-Meetings4.4.2.1 Herzschlag der PPM-Organisation4.4.2.2 Meeting-Struktur4.4.2.3 Gestaltung der Meetings4.5 Daten und Informationssysteme4.5.1 Datenmodell4.5.2 Anwendungssysteme4.5.2.1 Integration mit ERP-Systemen4.5.2.2 Integriertes Risikomanagement5 Projektportfoliomanagement gestalten – die Prinzipien für Lean-adaptive PPM5.1 Struktur der Lean-adaptive PPM-Philosophie5.2 Verschwendung im PPM-Kontext5.3 Kernprinzipien der Lean-adaptive PPM-Philosophie5.3.1 Strategieorientierung5.3.2 Kundenorientierung5.3.3 Prozessorientierung5.3.4 Engpassorientierung5.3.5 Minimalität5.3.6 Adaptivität5.3.7 Menschenorientierung5.4 Handlungsprinzipien der Lean-adaptive PPM-Philosophie5.4.1 Überblick5.4.2 Kurze Planungszyklen5.4.2.1 Timeboxing5.4.2.2 Rollierende Planung5.4.2.3 PPM-Planung in Sprints5.4.2.4 Planung auf mehreren Ebenen5.4.3 Klarheit und Kohärenz5.4.4 Dezentralisierung und Delegation5.4.5 Partizipation5.4.6 Pull und stabile Teams5.4.7 Lernen in Iterationen5.4.8 WiP-Limitierung5.5 Gestaltung der PPM-Wertströme5.5.1 Wertströme im PPM5.5.2 Interpretation der Kern- und Handlungsprinzipien5.5.2.1 Teilwertstrom »Von der Projektidee zum Projektstart«5.5.2.2 Teilwertstrom »Vom Projektbericht zu den Entscheidungsmaßnahmen«5.5.2.3 Teilwertstrom »Vom Projektergebnis zur Nutzenrealisierung«5.5.2.4 Teilwertstrom: »Vom Projektwissen zum Organisationswissen«5.5.2.5 Teilwertstrom »Von der Unternehmensstrategie zum strategischen PPM-Konzept«5.5.2.6 Teilwertstrom »Vom strategischen PPM-Konzept zum etablierten PPM-System«6 Projektportfoliomanagement umsetzen – Praktiken für Lean-adaptive PPM6.1 Einleitung6.2 Praktiken zur PPM-Systemkonfiguration6.2.1 SWOT-Analyse6.2.2 PESTEL-Analyse6.2.3 Capability Map6.2.4 PPM-Balanced Scorecard6.2.5 Prozesslandkarte6.2.6 »Finde die Niere«6.2.7 Lean Process Canvas6.2.8 SICAR-Matrix6.2.9 Projekt-Kategorisierung6.2.10 Project Diamond6.2.11 Agilometer (»Agil-O-Mat«)6.2.12 Standardisierungspyramide6.2.13 Retrospektive/Lessons-Learned-Workshop6.2.14 Starfish-Methode6.2.15 Italian Matrix6.2.16 PPM-Sprint Retrospective6.2.17 Projektaudit6.2.18 Fehlersammelliste6.3 Praktiken zur Projektpriorisierung6.3.1 Project Portfolio (PP) Scoring6.3.2 Monetäre Methoden6.3.3 Investitionsrechnungen6.3.4 Nutzwertanalyse/Scoring-Modell/Punktwert-/-bewertungsverfahren6.3.5 Weighted Shortest Job First6.3.6 Gesamtnutzenfunktion6.3.7 Strategieanbindungsmatrix der Projekte6.3.8 Dringlichkeitsanalyse6.3.9 Paarvergleich6.3.10 Lean Paarvergleich6.3.11 Sensitivitätsanalyse6.3.12 Pareto-Analyse6.3.13 Veto-Karte6.3.14 Portfolio-Diagramm/Bubble Charts/Mehrfeld-Matrix6.3.15 Projekt-/Programm-Roadmap6.3.16 Now-Next-Later-Roadmap6.3.17 Projektlandkarte6.3.18 Release Planning6.3.19 Product Backlog6.3.20 PPM-Objectives/Key Results6.4 Praktiken zur Anforderungs- und Auftragsklärung6.4.1 Business Case6.4.2 Lean Business Case6.4.3 Epics6.4.4 Project Canvas6.4.5 Personas6.4.6 User Stories6.4.7 Voice of Customer6.4.8 Benefits Expectation Story6.4.9 Target Value Design6.4.10 MuSCoW-Systematik6.4.11 Minimum Viable Product6.4.12 Story Points6.4.13 Planning Poker6.4.14 Magic Estimation6.4.15 Big Room Planning6.4.16 Synergiematrix6.5 Praktiken zum Performance & Benefits Management6.5.1 Ampeldarstellung6.5.2 Projektstatusbericht6.5.3 Status-Dashboard6.5.4 Cumulative-Flow-Diagramm6.5.5 Fieber-Chart6.5.6 PPM-Durchlaufdiagramm6.5.7 Burndown Chart6.5.8 Burnup Chart6.5.9 PPM-Kennzahlen6.5.10 Project Management Waste Index6.5.11 Earned-Value-Analyse (integriert)6.5.12 Sprint Review6.5.13 PPM-Sprint Review6.5.14 PPM-Andon-Cord6.5.15 Impediment Backlog6.5.16 Auswirkungsanalyse6.5.17 PPM-Spaghetti-Diagramm6.5.18 5-Why-Fragetechnik6.5.19 6W-Fragetechnik6.5.20 Ishikawa-Diagramm6.5.21 Getyptes Ishikawa-Diagramm6.5.22 8D-Report6.5.23 A3-Report6.5.24 Abschlussbericht6.5.25 Nutzenrevisionsplan6.6 Praktiken zum Ressourcen-Management6.6.1 Beyond Budgeting6.6.2 Lean Budgets6.6.3 Strategic Buckets6.6.4 Einsatzmittelgang- und -summenlinie6.6.5 Prioritätsorientierte Ressourcenallokation6.6.6 Stehende Teams6.6.7 PPM-Kanban-Board/Heijunka-Board6.7 Praktiken zum Informations-, Stakeholder- und Risikomanagement6.7.1 Kommunikationsmatrix6.7.2 Task Board6.7.3 Daily Stand-up-Meeting6.7.4 Risikomatrix/-Portfolio6.7.5 Fehlermöglichkeits- und -einflussanalyse6.7.6 Stakeholder-Register6.7.7 Personal Level Check6.7.8 Delegation Poker6.7.9 PPM-One Point Lesson6.8 Resümee7 Projektportfoliomanagement erfahren – Praxisbeispiele der Agilisierung7.1 Der Weg in die Agilität: Lean-adaptive Portfoliomanagement bei der HDI Leben7.1.1 Jede erfolgreiche Veränderung beginnt mit dem »Warum?«7.1.2 Viele Wege führen nach Rom7.1.3 Wie verbindet man das »Was« mit dem »Wie«?7.1.4 Think big – start small7.1.5 Fazit7.2 Stehende Teams als Schlüsselelement: Der Weg der DB InfraGO AG zum Lean-adaptive Portfoliomanagement7.2.1 Hintergrund7.2.1.1 Klassische Projektorientierung7.2.1.2 Problemlage7.2.2 Organisation der Umsetzungsteams7.2.2.1 Bildung stehender Teams7.2.2.2 Team- anstatt Projektfinanzierung7.2.2.3 Herausforderung bei der Transformation7.2.3 Der Weg zur teamorientierten Finanzierung bei DB InfraGO Fahrweg7.2.3.1 Budgetierungsprozess7.2.3.2 Verkleinerung und Planung der ITD-Vorhaben7.2.3.3 Ermittlung der erforderlichen Teamgrößen7.2.3.4 Verteilung des Budgets7.2.4 Fazit7.3 Planung in Unsicherheit: Top-down geführtes adaptives PPM bei Helvetia7.3.1 Multimodales Projektportfolio als Herausforderung und Startpunkt7.3.2 Erfolgsfaktor »strategische top-down Investitionsplanung«7.3.3 Erfolgsfaktor »kontinuierliche Priorisierung«7.3.4 Erfolgsfaktor »taktische, kaskadierende Quartalsplanung«7.3.5 Flankierende Maßnahme »organisatorische Einbettung der PPM-Funktion«7.3.6 Flankierende Maßnahme »Kundenfokus im PPM/PMO«7.3.7 Flankierende Maßnahme »Befähigungen«7.3.7.1 Lern- & Steuerungsgespräche mit Auftraggebenden7.3.7.2 Weiterbildung der Projektleitungen und Project Offices7.3.8 Fazit7.4 Projekt-Life-Cycle im Portfolio: Lean-adaptive ­PPM-Prozesssteuerung mit Kanban bei Migros7.4.1 Unternehmenskontext7.4.2 Der Wertstrom im PPM – Von der Projektidee zur Nutzenrealisierung7.4.2.1 Prozesstransparenz über das Portfolio-Kanban-Board7.4.2.2 Entstehen von Vorhaben7.4.2.3 Von der Projektidee zum Projektstart7.4.2.4 Vom Projektstart zum Projektergebnis7.4.2.5 Vom Projektergebnis zur Nutzenrealisierung7.4.3 Hindernisse und Stolpersteine7.4.4 Fazit7.5 Die Schwierigkeiten des Wandels: Agiles Projektportfolio-Management in einem globalen Industriekonzern7.5.1 Situation bei dormakaba7.5.2 Elemente der Portfoliosteuerung bei dormakaba7.5.3 Herausforderung beschränkter Entwicklungskapazitäten7.5.4 Weiterführung des LPM-Piloten7.5.5 Lessons Learned7.5.6 Fazit8 Projektportfoliomanagement einführen – ein evolutionärer Pfad8.1 Bildung von Teilportfolien8.1.1 Typisierung der Projekte und Initiativen8.1.2 Zentrale und dezentrale Teilportfolien8.2 Empfehlungen zum Aufbau eines Lean-adaptive PPM8.3 Vorgehensmodell zur inkrementellen Einführung von LAUP28.3.1 Abschnitt 1: Schaffung der richtigen Rahmenbedingungen8.3.2 Abschnitt 2: Mehrstufige Einführung der Prozesse inkl. Methoden und Rollen8.3.2.1 Entwicklungsstufe 0 – Inventur8.3.2.2 Entwicklungsstufe 1 – Baseline PPM8.3.2.3 Entwicklungsstufe 2 – Enhanced PPM8.3.2.4 Entwicklungsstufe 3 – Sustainable PPMQuellen und weiterführende LiteraturDer AutorStichwortverzeichnis

Buchnavigation

InhaltsubersichtCoverTextanfangImpressum
[1]

Hinweis zum Urheberrecht

Alle Inhalte dieses eBooks sind urheberrechtlich geschützt.

Bitte respektieren Sie die Rechte der Autorinnen und Autoren, indem sie keine ungenehmigten Kopien in Umlauf bringen.

Dafür vielen Dank!

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar.

Print:

ISBN 978-3-7910-5934-1

Bestell-Nr. 10966-0001

ePub:

ISBN 978-3-7910-5935-8

Bestell-Nr. 10966-0100

ePDF:

ISBN 978-3-7910-5936-5

Bestell-Nr. 10966-0150

Claus Hüsselmann

Lean-Adaptive Project Portfolio Management

1. Auflage, September 2024

© 2024 Schäffer-Poeschel Verlag für Wirtschaft · Steuern · Recht GmbH

Reinsburgstr. 27, 70178 Stuttgart

www.schaeffer-poeschel.de | [email protected]

Bildnachweis (Cover): © Stoffers Grafik-Design, Leipzig

Produktmanagement: Dr. Frank Baumgärtner

Lektorat: Traudl Kupfer, Berlin

Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte, insbesondere die der Vervielfältigung, des auszugsweisen Nachdrucks, der Übersetzung und der Einspeicherung und Verarbeitung in elektronischen Systemen, vorbehalten. Alle Angaben/Daten nach bestem Wissen, jedoch ohne Gewähr für Vollständigkeit und Richtigkeit.

Schäffer-Poeschel Verlag Stuttgart Ein Unternehmen der Haufe Group SE

Sofern diese Publikation ein ergänzendes Online-Angebot beinhaltet, stehen die Inhalte für 12 Monate nach Einstellen bzw. Abverkauf des Buches, mindestens aber für zwei Jahre nach Erscheinen des Buches, online zur Verfügung. Ein Anspruch auf Nutzung darüber hinaus besteht nicht.

Sollte dieses Buch bzw. das Online-Angebot Links auf Webseiten Dritter enthalten, so übernehmen wir für deren Inhalte und die Verfügbarkeit keine Haftung. Wir machen uns diese Inhalte nicht zu eigen und verweisen lediglich auf deren Stand zum Zeitpunkt der Erstveröffentlichung.

Abbildungsverzeichnis

Abbildung 1-1: Merkmale von Projektlandschaften

Abbildung 2-1: Warum PPM?

Abbildung 2-2: Gemeinsamkeiten Portfolio – Programm – Projekt

Abbildung 2-3: Prozesszusammenhang PPM und Einzel-PM

Abbildung 2-4: High-Level-Wertströme im PPM

Abbildung 2-5: PPM im Kreuz der Komplexität32

Abbildung 2-6: Einordnung der Agilität

Abbildung 2-7: Differenziertes Kundenverständnis

Abbildung 2-8: Einfacher Projekt-Kanban zum Wertstrom »Von der Projektidee bis zur Nutzung«

Abbildung 2-9: Der LAUP2-Würfel – das »Big Picture«

Abbildung 2-10: Perspektiven des PPM-Systems

Abbildung 3-1: PPM-Balanced Scorecard, generische Sicht

Abbildung 3-2: IPOO-Grundmodell (nach Geyer-Klingeberg & Steinmann)

Abbildung 3-3: PPM-BSC, Dimension Geschäft

Abbildung 3-4: PPM-BSC, Dimension Projekte

Abbildung 3-5: PPM-BSC, Dimension Prozesse

Abbildung 3-6: PPM-BSC, Dimension Ressourcen

Abbildung 3-7: Kriterien zur Einführung einer Kennzahl

Abbildung 3-8: Paarweiser Vergleich von Kennzahlenkriterien, Vorschlag

Abbildung 3-9: Durchlaufzeit ist nicht gleich Durchlaufzeit

Abbildung 3-10: Das PPM mithilfe des Referenzmodells lean-adaptiv ausgestalten!

Abbildung 4-1: High-Level-PPM-Prozesslandschaft

Abbildung 4-2: PPM-Prozesslandkarte, Ebene 2

Abbildung 4-3: Wesentliche Outputs im PPM-Prozess

Abbildung 4-4: SIPOC-Tabelle mit Artefakten – am Beispiel Prozess PP Authorization

Abbildung 4-5: Einordung von Prozessen – am Beispiel vom Project Demand Management

Abbildung 4-6: Summarische Übersicht der Rollennennung in den Quellen

Abbildung 4-7: LAUP2-Rollenkanon

Abbildung 4-8: »Zwiebel«-Metapher des SICAR-Modells

Abbildung 4-9: PPM-SICAR-Matrix

Abbildung 4-10: Mapping PPM-Rollen & Linien-Rollen

Abbildung 4-11: PPM-Prozess im Geschäftsjahr

Abbildung 4-12: Legende UML-Klassendiagramm

Abbildung 4-13: Klassendiagramm »Projektstruktur«

Abbildung 4-14: Klassendiagramm »Projektergebnisse«

Abbildung 4-15: Klassendiagramm »PPM-Stakeholder«

Abbildung 4-16: Klassendiagramm »Praktiken und Risiken«

Abbildung 4-17: Klassendiagramm »Bewertung«

Abbildung 4-18: Klassendiagramm »PPM-System«

Abbildung 4-19: Klassendiagramm »Dokumentation«

Abbildung 4-20: Klassendiagramm »Strategic Bucket«

Abbildung 4-21: Ausgewählte Klassen

Abbildung 4-22: Integration MPM- und ERP-Software133

Abbildung 4-23: Integriertes Risikomanagement

Abbildung 5-1: Struktur der Lean-adaptive PPM-Philosophie

Abbildung 5-2: Projekt- und projektportfoliotypische Arten der Verschwendung

Abbildung 5-3: Die Kernprinzipien der Lean-adaptive PPM-Philosophie

Abbildung 5-4: Die Anwendung des Pareto-Prinzips

Abbildung 5-5: Differenzierung in allgemeine Lean-Handlungsprinzipien und zusätzliche Handlungsprinzipien für das PPM

Abbildung 5-6: Für das PPM zusätzliche Handlungsprinzipien

Abbildung 5-7: Ad-hoc-Umfrage 2022 zu Handhabung von Projektbudgets162

Abbildung 5-8: Autonomie und Ausrichtung – auf das richtige Maß kommt es an

Abbildung 5-9: Team- statt Projektfinanzierung

Abbildung 5-10: Identifizierte Wertströme im PPM176

Abbildung 5-11: WSK »Von der Projektidee zur Nutzenrealisierung« im Überblick

Abbildung 5-12: WSK »Vom impliziten Wissen zur Anwendung« im Überblick

Abbildung 5-13: WSK »Von der Unternehmensstrategie zum PPM-System« im Überblick

Abbildung 6-1: SWOT-Analyse-Matrix

Abbildung 6-2: Kriterien(gruppen) der PEST(EL)-Analyse

Abbildung 6-3: Beispielhafte Capability Map

Abbildung 6-4: PPM-BSC, generische Sicht

Abbildung 6-5: Finde die Niere

Abbildung 6-6: Kriteriengruppen im Agilometer

Abbildung 6-7: Die Agilometer-Waage zum Projektvorhaben

Abbildung 6-8: Standards & Best Practices – die Standardisierungspyramide

Abbildung 6-9: Starfish-Methode für Lessons Learned

Abbildung 6-10: Italian Matrix

Abbildung 6-11: Statische und dynamische Investitionsrechnungsverfahren

Abbildung 6-12: Aufbau des Portfolio-Scoring-Baums am Beispiel Wien Energie212

Abbildung 6-13: Scoringmodell mit Wirkungs- und Abwicklungskriterien

Abbildung 6-14: Synthese eines ganzheitlichen Priorisierungsverfahrens35214

Abbildung 6-15: Generisches Beispiel zur WSFJ-Ermittlung

Abbildung 6-16: Beispielhafte Berechnung des SSPF

Abbildung 6-17: Visualisierung der Projektbewertung in einer Portfoliodarstellung

Abbildung 6-18: Beispiel für ein einfaches Score-Modell

Abbildung 6-19: Strategieanbindungsmatrix

Abbildung 6-20: Lean Paarvergleich

Abbildung 6-21: Portfolio-Diagramme ohne (links) und mit (rechts) zeitlichen Veränderung

Abbildung 6-22: Projekt-Roadmap (Gantt)

Abbildung 6-23: Now-Next-Later-Roadmap (Beispiel)

Abbildung 6-24: Projektlandkarte am Beispiel Six-Sigma-Projekt

Abbildung 6-25: Ableitung der Projektziele und -ergebnisse aus Unternehmenszielen

Abbildung 6-26: PPM-OKR im Authorization-Prozess

Abbildung 6-27: PPM-OKR im Budgetierungsprozess

Abbildung 6-28: PPM-OKR – Big Picture

Abbildung 6-29: Darstellung eines Project Canvas

Abbildung 6-30: Persona-Canvas

Abbildung 6-31: Schablone der kombinierten VoC/US-Methode im Beispiel

Abbildung 6-32: Kosten-Nutzen-Analyse mit Target Value Design

Abbildung 6-33: Atmender Scope mit der MuSCo(W)-Regel

Abbildung 6-34: Darstellung eines Cumulative-Flow-Diagramms

Abbildung 6-35: Portfolioübersicht im Fieber-Chart

Abbildung 6-36: PPM-Durchlaufdiagramm

Abbildung 6-37: Der Einsatz eines Burndown Charts

Abbildung 6-38: Performance-Betrachtung der Projekte mithilfe der EVA – Einzelprojektsicht

Abbildung 6-39: PPM-Andon-Cord: strukturelle Abbildung

Abbildung 6-40: Mögliches Ergebnis des PPM-Spaghetti-Diagramms

Abbildung 6-41: Darstellung des PPM-Spaghetti-Diagramms

Abbildung 6-42: Ursache-Wirkung-Diagramm für Projektmanagement

Abbildung 6-43: Getyptes Ishikawa-Diagramm

Abbildung 6-44: Die Teilportfolios bei Wien Energie

Abbildung 6-45: Beispiel einer Einsatzmittelgang- und -summenlinie

Abbildung 6-46: Prioritätsorientierte Ressourcenallokation

Abbildung 6-47: Handlungsprinzipien für Teamzusammenstellungen

Abbildung 6-48: Kanban-Board im PPM-Kontext

Abbildung 6-49: Kanban als Organisationsform des Portfolioplanungsprozesses

Abbildung 6-50: »Schlanke« Risikobewertung

Abbildung 7-1: Prozesse im Unternehmen – Soll-Vorstellung vs. Realität

Abbildung 7-2: Die Pyramide der Strategie

Abbildung 7-3: Stufen der agilen Transformation2308

Abbildung 7-4: Vorteile von Lean-adaptive Portfoliomanagement

Abbildung 7-5: Lauf eines Epics bei HDI Leben, Teil 1

Abbildung 7-6: Epic-Hypothese (Template)

Abbildung 7-7: Lean Business Case (Template)

Abbildung 7-8: Lauf eines Epics bei HDI Leben, Teil 2

Abbildung 7-9: Big Room Ranking – Aufbau

Abbildung 7-10: Big Room Ranking – Agenda (Muster)

Abbildung 7-11: Systemgestützte Bewertung in Echtzeit mit PowerBI

Abbildung 7-12: Lauf eines Epics bei HDI Leben, Teil 3

Abbildung 7-13: Zusammenwirken der verschiedenen Arbeitsebenen309

Abbildung 7-14: Beispiel eines digitalen Portfolio-Kanban-Boards310

Abbildung 7-15: Entwicklungspfad zur Einführung des Lean-adaptive PPM bei HDI Leben

Abbildung 7-16: Typisch schwankender Finanzbedarf bei einer projektorientierten IT-Vorhabenplanung

Abbildung 7-17: Umkehr des magischen Dreiecks des Projektmanagements in agilen Organisationen

Abbildung 7-18: Übergang von der Projekt- zur Prozessorganisation

Abbildung 7-19: Epic-Kanban-Workflow-System316

Abbildung 7-20: Lean Portfolio Management bei der DB InfraGO Fahrweg

Abbildung 7-21: Helvetia Investitionsplanung ist rahmengebende Grundlage für den agilen Projektportfolio­prozess

Abbildung 7-22: Grobe Kategorisierung der Personalressourcennachfragen

Abbildung 7-23: Vertikal gekoppelte Projekt-Kanban-Boards

Abbildung 7-24: Nutzenfunktion-Formel der Helvetia als Unterstützung der Freigabe- & Priorisierungsentscheide

Abbildung 7-25: Skalen der Nutzenfunktion von Helvetia321

Abbildung 7-26: Organisatorischer und funktionaler Rahmen für die Strategieumsetzung in der Helvetia

Abbildung 7-27: Organisatorische Aufstellung von PPM/PMO in der Helvetia

Abbildung 7-28: PPM bedient diverse Kundengruppen mit unterschiedlichen Bedürfnissen

Abbildung 7-29: Checkliste mit den Aufgaben der Auftraggebenden

Abbildung 7-30: Portfolio-Kanban-Board

Abbildung 7-31: Entstehung von Vorhaben

Abbildung 7-32: Übergang Funnel zu Analyse und Identifikation der Portfoliorelevanz

Abbildung 7-33: Relevante Aspekte des Ideen-Pitchs

Abbildung 7-34: Arten von Vorhaben

Abbildung 7-35: Kategorien von Vorhaben

Abbildung 7-36: Einbezug des Portfolios in den Produktlebenszyklus

Abbildung 7-37: Vorgehen zur Erarbeitung der Roadmap

Abbildung 7-38: Die Definition of Ready (DoR)

Abbildung 7-39: Aufbrechen von Epics in Features und Stories in der agilen Umsetzung

Abbildung 7-40: Definition of Done

Abbildung 7-41: Der Aufbau des Engineering Managements (Stand 15.12.2023)

Abbildung 7-42: Der (geplante) Weg in eine agile Zukunft bei dormakaba

Abbildung 7-43: Entwicklungsteams bei dormakaba

Abbildung 8-1: Charakteristik von Change-Initiativen340

Abbildung 8-2: Fokussierung und Separation von Vorhaben

Abbildung 8-3: Bildung von crossfunktionalen Value Streams am Beispiel

Abbildung 8-4: Nutzung von Synergien

Abbildung 8-5: Entwicklungspfad des Lean-adaptive PPM-Konzepts

Tabellenverzeichnis

Tabelle 1-1: Zentrale Merkmale der PPM-Ansätze

Tabelle 2-1: Gegenüberstellung von Produkt- und Projektportfolios36

Tabelle 2-2: Beispielhafte Aufgaben im PPM-Life Cycle

Tabelle 2-3: Beispielhafte Aufgaben der PPM-Disziplin »Management von Wissen & Information«

Tabelle 3-1: Beschreibungen ausgewählter PPM-Kennzahlen

Tabelle 3-2: PPM-Erfolgsfaktoren

Tabelle 4-1: PPM-Prozesssteckbrief PPM-System Strategy Determination

Tabelle 4-2: PPM-Prozesssteckbrief PP Authorization

Tabelle 4-3: PPM-Prozesssteckbrief PPM Governance

Tabelle 4-4: PPM-Prozesssteckbrief Project Demand Management

Tabelle 4-5: PPM-Prozesssteckbrief Performance Management

Tabelle 4-6: PPM-Prozesssteckbrief Resource Management

Tabelle 4-7: PPM-Prozesssteckbrief Benefits Management

Tabelle 4-8: PPM-Prozesssteckbrief Development of PPM Methods & Tools

Tabelle 4-9: PPM-Prozesssteckbrief PPM System Operations

Tabelle 4-10: PPM-Prozesssteckbrief Information & Knowledge Management

Tabelle 4-11: PPM-Prozesssteckbrief Client & Stakeholder Management

Tabelle 4-12: PPM-Prozesssteckbrief Chancen- & Risikomanagement

Tabelle 4-13: Mapping Domänen & Prozesse

Tabelle 4-14: Kurzbeschreibung der PPM-Rollen

Tabelle 4-15: PPM-Rollensteckbrief Strategy Sponsor105

Tabelle 4-16: PPM-Rollensteckbrief PPM Sponsor106

Tabelle 4-17: PPM-Rollensteckbrief Project Portfolio Manager107

Tabelle 4-18: PPM-Rollensteckbrief Project Portfolio Analyst108

Tabelle 4-19: PPM-Rollensteckbrief Project/Program Sponsor109

Tabelle 4-20: PPM-Rollensteckbrief Program Manager110

Tabelle 4-21: PPM-Rollensteckbrief Project Manager111

Tabelle 4-22: PPM-Rollensteckbrief Project Management Expert

Tabelle 4-23: PPM-Rollensteckbrief Project Team Member113

Tabelle 4-24: PPM-Rollensteckbrief Subject Manager

Tabelle 4-25: PPM-Rollensteckbrief Resource Coordinator114

Tabelle 4-26: PPM-Rollensteckbrief Knowledge Manager115

Tabelle 4-27: PPM-Rollensteckbrief Domain Authority

Tabelle 4-28: PPM-Rollensteckbrief Project Portfolio Board116

Tabelle 4-29: PPM-Rollensteckbrief Program/Project Steering Committee117

Tabelle 4-30: PPM-Rollensteckbrief Strategisches Project Management Office118

Tabelle 4-31: PPM-Rollensteckbrief Operatives Project Management Office119

Tabelle 4-32: Übersicht typischer Methoden/Tools im PPM

Tabelle 4-33: Regel-Meetings im PPM

Tabelle 5-1: Top-10-Handlungsprinzipien des Lean Managements

Tabelle 5-2: Rollierendes Ressourcenmanagement

Tabelle 5-3: Teilwertstrom »Von der Projektidee zum Projektstart«

Tabelle 5-4: Teilwertstrom »Vom Projektbericht zu den Entscheidungsmaßnahmen«

Tabelle 5-5: Teilwertstrom »Vom Projektergebnis zur Nutzenrealisierung«

Tabelle 5-6: Teilwertstrom: »Vom Projektwissen zum Organisationswissen«

Tabelle 5-7: Teilwertstrom »Von der Unternehmensstrategie zum strategischen PPM-Konzept«

Tabelle 5-8: Teilwertstrom »Vom strategischen PPM-Konzept zum etablierten PPM-System«

Tabelle 6-1: Alphabetische Auflistung der Methoden und Prozesszuordnung

Tabelle 6-2: Übersicht über mögliche Projektprioritätsklassen

Tabelle 6-3: Mögliche Klassifizierung nach Konfektionsgrößen

Tabelle 6-4: Typische Bewertungskriterien

Tabelle 6-5: Likert-Skalen für den SSPF-Index

Tabelle 6-6: Beispiel für eine spezifische Ausgestaltung der Likert-Skala für das Kriterium Dringlichkeit

Tabelle 6-7: Vom Unternehmensziel zum Arbeitspaket mit OKR – ein Vorschlag

Tabelle 6-8: Gegenüberstellung Kano-, Minimum-Viable- und MuSCoW-Ansatz

Tabelle 6-9: Schema der 6W-Fragetechnik

Tabelle 7-1: Zuordnung der Vorhaben auf Planungsebenen

Tabelle 7-2: Rahmenbedingungen für die Roadmap

Tabelle 7-3: Fachexperten in der Definition of Ready

Tabelle 7-4: Entscheidungen aufgrund von Leading Indicators

Tabelle 7-5: Aufgaben der Domain Authorities in der Definition of Done

Tabelle 8-1: Project Scope in Entwicklungsstufe 0

Tabelle 8-2: Project Scope in Entwicklungsstufe 1

Tabelle 8-3: Project Scope in Entwicklungsstufe 2

Tabelle 8-4: Project Scope in Entwicklungsstufe 3

Geleitwort

Umbruchzeiten und Innovationen sind dadurch gekennzeichnet, dass eine wachsende Vielfalt neuer Designs um die Entstehung und Durchsetzung ringen und sich dann in großer Zahl ein dominantes Design durchsetzt. Ein dominantes Design erlaubt Produktivitätsfortschritte in der Herstellung und Nutzung und stellt in der Regel auch eine Plattform für eine neue Variantenvielfalt eines Grundtypus dar – sodass sehr unterschiedliche Nutzer-, Entwickler- und Herstellerbedürfnisse gut befriedigt werden können.

Dieses Grundgesetz der Innovationsforschung lässt sich nicht nur auf technische Innovationen anwenden, sondern auch auf kulturelle, soziale und organisatorische. Im Bereich der Managementinnovationen haben die agilen Methoden zum Managen komplexer Problemstellungen sowohl auf der Ebene einzelner Vorhaben (Projekte) als auch auf der übergeordneten Ebene von Bündeln solcher Vorhaben (Projektportfolios, Programme, Multiprojektmanagement) einen wahren Siegeszug angetreten. Es zeigte sich aber, dass sowohl die herkömmlichen Managementmethoden als auch die neuen agilen ihre Stärken und Schwächen aufweisen, und auch jeweils unterschiedliche Anwendungsbedingungen, für die sie besonders geeignet sind. Daher lag es nahe, dass recht bald auf beiden Ebenen die zwei unterschiedlichen Arten von Methoden kombiniert eingesetzt wurden – was als »hybride« Methodik angesehen wird. Die erhofften Vorteile hybrider Verfahren liegen darin, dass man eine größere Menge an Problemen besser, schneller, sicherer und/oder kostengünstiger lösen kann – und/oder dass die traditionellen und neuen Methoden positive Wechselwirkungen zeigen – und nicht additiv wirken, sondern sogar multiplikativ.

Die Umbruchzeiten dieser Managementinnovationen sind jedoch längst nicht abgeschlossen – vor allem wenn die neuen hybriden Konzepte auf der Ebene des Einzelprojektmanagements und des Multiprojektmanagements gleichzeitig hybride Varianten verfolgen. Dann kann die Lage sehr schnell unübersichtlich werden – und es kann lange dauern, bis erkannt wird, welche Kombinationen als gesichert überlegen angesehen werden. Denn es muss keineswegs sein, dass die am häufigsten angewandten Kombinationen die besten sind.

Vor diesem Hintergrund ist ein modernes Referenzmodell für Multiprojektmanagement ein wirklich wichtiger Beitrag, ohne den man den Wald vor lauter Bäumen nicht mehr sehen wird. Das sehr systematisch abgeleitete und gut nachvollziehbare LAUP2-Modell von Claus Hüsselmann zeigt den Wald und die Wege, die man gehen kann. Es liefert aber nicht nur eine Landkarte und Orientierung, sondern gibt – durch die Formulierung von Gestaltungsprinzipien sowie die Bereitstellung eines Instrumentenkoffers – auch praktische Hilfen, wie die Umsetzung erfolgen kann. Insbesondere entsteht eine gemeinsam geteilte Begrifflichkeit, welche dem gegenseitigen Verstehen dient. Und gegenseitiges Verständnis ist die Basis für gegenseitiges Vertrauen und damit auch für gemeinsames Handeln, das durch gemeinsame Ziele, gemeinsam geplante Maßnahmen und gegenseitige Unterstützung geprägt ist.

Ich wünsche diesem Werk eine gute Leserschaft und eine starke Verbreitung.

Potsdam, im Januar 2024

Prof. Dr. habil. Dr. h.c. Hans Georg Gemünden, TU Berlin

Vorwort

Referenzmodelle für Projektportfoliomanagement gibt es wie Sand am Meer. Diesen Satz habe ich sinngemäß einleitend vor einigen Jahren in einem wissenschaftlichen Aufsatz gelesen. Doch meine eigenen Erfahrungen und natürlich auch eine systematische Recherche können diese Aussage nicht bestätigen. So lässt sich bspw. feststellen, dass vorhandene Prozessmodelle nicht umfassend und Rollenmodelle nicht oder nur rudimentär vorhanden sind. Dem soll das vorliegende Werk Abhilfe schaffen.

Gleichwohl ist das vorgestellte prozessorientierte Referenzmodell nur Mittel zum Zweck. Es dient als Ordnungsrahmen für die systematische Anwendung eines Prinzipienkanons, der als substanzieller Bestandteil des Konzeptes zu verstehen ist. Hierzu haben nicht zuletzt eine Vielzahl von Praxisberichten zur Agilisierung von Projektportfoliomanagement beigetragen, welche systematisch ausgewertet und durch Bezugnahmen bekannter Managementkonzepte – wie Lean Management oder der Theory of Constraints und nicht zuletzt dem agilen Management – im Sinne allgemein anwendbarer Grundsätze, aber auch konkreter Praktiken verallgemeinert wurden. So ist schlussendlich das Lean-adaptive Unified Project Portfolio Management Framework, kurz LAUP2, entstanden. Nicht zuletzt die Möglichkeiten und der Einfluss der IT als vielfacher Treiber des Business und die damit zunehmende verbundene »Fluidität« von Projektvorhaben motivierten dabei die Entwicklung.

Das LAUP2-Framework ist kein Abklatsch von Frameworks wie SAFe oder Ähnlichen. SAFe ist bspw. vielmehr ein Framework zur Skalierung kontinuierlicher agiler Produktentwicklung, insbesondere von IT-Lösungen, auf der Basis von Scrum. Es verlässt damit den Kontext von Projektarbeit im eigentlichen Sinne, nämlich der Durchführung temporärer, einmaliger Vorhaben. Demgegenüber fokussiert LAUP2 explizit den Projektgedanken, wenngleich auch hier eine Offenheit für den in bestimmten Kontexten sicherlich sinnvollen Wechsel hin zur kontinuierlichen Produktentwicklung besteht, z. B. in der Software-Entwicklung. Unter dem Strich ist das Konzept invariant gegenüber der Art und Weise, wie im Unternehmen auf operativer Ebene Projekte oder projektähnliche Vorhaben durchgeführt werden (plangetrieben, agil oder hybrid).

Ein Buch entsteht niemals im Alleingang. Mein Dank geht an meine Masteranden Janis Erbacher und Janek Hergenröder und die TH Mittelhessen für die Mittelbereitstellung für deren Arbeit. Ferner an meine geschätzten Sparringspartner Uwe Techt (VISTEM GmbH), Frank Orthey (DB Fernverkehr AG), Markus Götz (BAAINBw) und Mitglieder der Fachgruppe Multiprojektmanagement der GPM Deutsche Gesellschaft für Projektmanagement. Danke auch an Hans Georg Gemünden für das anerkennende Geleitwort und an Frank Baum­gärtner, Traudl Kupfer und Heike Münzenmaier vom Schäffer-Poeschel Verlag für das Aufgreifen des Themas und die wieder sehr angenehme Zusammenarbeit.

Insbesondere hat eine Reihe von erfahrenen Projektportfoliomanagern1 mit ihren Beiträgen aus der Praxis der Anwendung von agilem (Projekt-)Portfoliomanagement Kapitel 7 bereichert. An sie geht mein besonderer Dank für ihre Mitwirkung und den wertvollen Input.

Ich wünsche Ihnen als Leser viel Erkenntnisgewinn und hoffentlich auch ein wenig Spaß bei der Lektüre.

Bonn/Gießen, im Juli 2024

Prof. Dr. Claus Hüsselmann

1 Gender-Hinweis: Zur besseren Lesbarkeit wird in dieser Arbeit das generische Maskulinum verwendet. Die in dieser Arbeit verwendeten Rollenbezeichnungen beziehen sich stets auf alle Geschlechter. Lediglich in den Beispielen aus der Praxis werden die Gender-Richtlinien der jeweiligen Unternehmen befolgt.

Mitwirkende

Frank Willems ist Diplom-Mathematiker mit Schwerpunkten in mathematische Methoden der Physik und künstlicher Intelligenz in der Informatik. Mit über drei Jahrzehnten Erfahrung in der Versicherungsbranche hat er in verschiedenen Fachgebieten umfangreiche Führungs- und Projektleitungsaufgaben wahrgenommen, darunter die Entwicklung von Produkten und Anwendungssystemen, die Finanzsteuerung eines internen IT-Dienstleisters sowie die Koordination der Projektportfolien. Als langjähriger Leiter des Projektportfoliomanagements führte er in den Jahren 2020/2021 das agile Framework SAFe ein und transformierte die bislang klassische Portfoliosteuerung in ein Lean-Portfoliomanagement.

Robert Kahl ist Leiter des Bereiches Portfolio Management, Quality/Security Engineering und Transformation/Kommunikation des CIO/CDO Bereiches der DB Netz AG (ab 01.01.2024 DB InfraGO AG). Nach dem Studium der Betriebswirtschaftslehre und Operations Research an der RWTH Aachen arbeitete er als SAP/Geschäftsprozessberater, Programm- und Projektmanager. Während seiner weiteren Karriere war er bei einem globalen IT-Dienstleister (Atos) neben seinen Aufgaben im Projekt- und Programmmanagement komplexer, internationaler Projekte als COO von fünf Länderorganisationen und sechs Jahre als Head of Global Application Management Operations tätig. 2017 entschloss er sich, vom IT-Dienstleiter zum internen CIO-Bereich der DB Netz AG zu wechseln, und trieb neben dem IT-Portfoliomanagement die Transformation des CIO/CDO-Bereiches zu einer SAFe-orientierten, vollagilen Organisation voran. In diesem Umfeld gestaltete er entscheidend den Aufbau eines Lean Portfolio Managements.

Johannes Felchlin ist seit 2022 Head of Project & Process Management bei der Helvetia Group Asset Management. Zuvor war er Lead Projektportfolio Manager bei der Helvetia Group und Leiter Projektportfolio Management bei den Basler Versicherungen Schweiz. In beiden Unternehmen verantwortete er das unternehmensweite, zentralisierte Projektportfolio. In früheren Jahren war er Geschäftsleitungsmitglied einer IT-Dienstleistungsfirma und PMO Officer und IT Strategy Planning Officer bei Swiss Re (Rückversicherung) in Zürich. Er verfügt über 25 Jahre PPM-Erfahrung. In seiner Ausbildung erwarb einen Bachelor in Marketing (CH), einen Executive MBA (USA & NL) und ist zertifizierter Projektleiter (PMP/PMI), Certified Portfolio Director (IPMA Level A), zertifizierter LeSS Practitioner sowie SAFe 5 Lean Portfolio Manager. Daneben ist er Dozent für Projektmanagement an der Zürcher Hochschule für Angewandte Wissenschaften (zhaw) und Co-Autor des Buchs »Projektportfolio Management – Strategische Ausrichtung & Steuerung von Projektlandschaften«.

Christian Scherer blickt auf über 25 Jahre in der Informationstechnik zurück. Schwerpunktmäßig war er in Governance- und Managementfunktionen tätig. Unter anderem zeichnete er europaweit für IT Service Management, Strategie, Finance und Projektportfolio Management verantwortlich. Seit einigen Jahren beschäftigt er sich intensiv mit Agilität im skalierten Umfeld und gilt als einer der führenden deutschsprachigen Experten bei der Implementierung von Lean Portfolio Management. So hat er beim größten Schweizer Retailer mehrere Portfolios aufgebaut und die agile Journey maßgeblich mitgestaltet. Er ist heute Chapter Lead Lean Portfolio Management der Zurich Insurance in der Schweiz. Daneben ist er Experte an der Berufsakademie Lörrach und doziert an der KV Luzern Business Academy.

Jens Lippmann ist nach einem Meteorologiestudium an der Humboldt-Universität Berlin und einer Tätigkeit für den Deutschen Wetterdienst seit 1995 als Softwareentwickler und Projekt-/Programmmanager in vielfältigen Bereichen der Wirtschaft tätig. Er hat u. a. in Boulder, New York, London und Zürich Handelssysteme, Intranet-/Extranet-/Internetanwendungen und Riskmanagement-Lösungen für Unternehmen wie Axa, Firmenich, JPMorgan, Medco Health Solutions, Merrill Lynch, Swisscom, Roche Diagnostics konzipiert, implementiert, gemanagt und war u. a. für die Bereitstellung der notwendigen Entwicklungsumgebungen und Prozesse verantwortlich. Seine 20-jährige Erfahrung mit agilen Abläufen – seit seiner Begegnung mit den Unterzeichnern des agilen Manifests – bringt er in seiner Tätigkeit als Lead des Lean Agile Center of Excellence bei dormakaba ein.

Abkürzungsverzeichnis

Ø

A/K/V

Durchschnitt/durchschnittlich

Aufgaben/Kompetenzen/Verantwortlichkeiten

AG

Auftraggeber

AV

Arbeitsvorgang/Arbeitsvorgänge

BRR

Big Room Ranking

BSC

Balanced Scorecard

BSI

Baseline Solution Investments

CoD

Cost of Delay

DoR

Definition of Ready

EPM

Einzelprojektmanagement

EVA

Earned-Value-Analyse

FMEA

Fehlermöglichkeits- und Einflussanalyse

i. e. S.

im eigentlichen Sinne

i. w. S.

im weiteren Sinne

IPOO

Input – Process – Output – Outcome

ITD

Informationstechnologie und Digitalisierung

KPE

kontinuierliche Produktentwicklung

LACE

Lean Agile Center of Excellence

LAUP2

Lean-adaptive Unified Project Portfolio Management

LBC

Lean Business Case

LPM

Lean Portfolio Management

LT

Lead time

MA

Mitarbeiter

MLP

Minimum Loveable Product

MPM

Multiprojektmanagement

MuSCoW

Must have – Should have – Could have – Won’t have

MVP

Minimal Viable Product

MVProj

Minimum Viable Project

NWA

Nutzwertanalyse

OKRs

Objectives and Key Results

OPL

One Point Lesson

PDCA

Plan – Do – Check – Act

PESTEL

Political – Economic – Social – Environmental – Legal

PI

Program Increment

PMWI

Project Management Waste Index

PPB

Project Portfolio Board

PPM

Projektportfoliomanagement

PPM-BSC

Projektportfoliomanagement Balanced Scorecard

ROI

Return on Investment

SAFe

Scaled Agile Framework

SH

Stakeholder

SICAR

Served – Informed – Consulted – Accountable – Responsible

SIPOC

Supplier – Input – Process – Output – Customer

SSPF

Scored Shortest Project Fit

SWOT

Strengths – Weaknesses – Opportunities – Threats

TOC

Theory of Constraints

TP

Throughput (Durchsatz)

TPS

Toyota Production System

TVD

Target Value Design

USP

Unique Selling Point (Alleinstellungsmerkmal)

VoC

Voice of Customer

vs.

versus

VUKA

Volatilität, Unsicherheit, Komplexität und Ambiguität

WI

Waste Index

WiP

Work in Progress

WSJF

Weighted Shortest Job First

WSK

Wertschöpfungskette(n)

1 Einleitung – Hintergrund und Motivation

1.1 Kritik am klassischen Projektportfoliomanagement

In großem Umfang werden Projekte als flexible, temporäre Organisationsform zur Leistungserbringung durchgeführt. Der Anteil der Wertschöpfung, der in Form von Projekten erzielt wird, vereinnahmt in deutschen Unternehmen stabil mehr als ein Drittel der Arbeitskapazität. Viele Studien zeigen: Nahezu alle Unternehmen führen Projekte durch, i. d. R. mehr als eines. Hier zeigen empirische Erhebungen, dass – je nach Unternehmensgröße – sogar nicht selten mehr als 500 Projekte parallel laufen.2 Das Management ganzer Projektlandschaften in Organisationen wird als Projektportfoliomanagement (PPM) bezeichnet. PPM ist eine junge Managementdisziplin. So wurde z. B. erstmals 2013 mit der DIN ISO 69 909 eine Norm für diese Domäne veröffentlicht. Das hierin formulierte »klassische« PPM ist als stabilitätsorientiertes Managementsystem zu charakterisieren – nicht zuletzt mit Blick auf die Budgetallokation. Wichtiger Bestandteil ist die systematische Autorisierung von Projekten. Dies geht üblicherweise von einem Projektantrag aus, der bereits in einem frühen Stadium so weit ausgestaltet ist, dass auf dessen Basis eine quantitativ-qualitative Nutzwertanalyse durchgeführt werden kann. Das bringt vielfach einige Probleme mit sich. So erfordert die Einbindung des Antragsprozesses in den i. d. R. jährlichen Budgetierungsprozess des Unternehmens eine sehr frühzeitige Bearbeitung. Dazu ein prozessuales Praxisbeispiel:

Um für das Geschäftsjahr 2025 die Budgetierung mit Wirksamkeit zum Januar diesen Jahres verabschiedet zu haben, müssen die Projektanträge für das Jahr 2025 bereits im August 2024 gestellt, zumindest initiiert werden. Es muss dann also Mitte des Jahres 2024 schon klar sein, welche Projekte im Jahr 2025 durchgeführt werden sollen/wollen. Spätestens Ende des Q3/2024 muss der Antrag vollständig vorliegen.

Die Erfahrung zeigt, dass das Topmanagement, das die Portfolioentscheidungen fällt, vielfach von den Antragsstellern konkrete und detaillierte Entscheidungsvorlagen (d. h. Projektantrag, Projekt-Business-Case) einfordert.

Der Erstellung eines vollständigen Projektantrags ist jedoch ein Problem immanent: Entscheidungsrelevante Kenngrößen, insbesondere das Budget, müssen vor der Projektdurchführung und dem damit verbundenen Erkenntniszuwachs angegeben werden. Es ist damit vorprogrammiert, dass (im Nachhinein) falsche Zahlen als Entscheidungsgrundlage verwendet werden – und im Grunde akzeptiert dies das Management sehenden Auges (Verschwendung).

Die vielfach fällige Korrektur der zentralen Kenngrößen der Projekte (Kosten, Termine) erfordert im Verlaufe des Geschäftsjahres/der Abwicklung des Projekts ein permanentes Nachsteuern inkl. Evaluation des Business Case. Bis hin zu ggf. einer völlig neuen Situation, die vielleicht sogar den Abbruch des Projekts erfordert/erfordern würde, was eine immense Verschwendung darstellt. Auch und gerade, wenn ein Projekt wider besseres Wissen nicht abgebrochen wird, entsteht im besonderen Maße Verschwendung (Sunk-CostSunk Cost-Thematik). Einige öffentliche, aber auch privatwirtschaftliche Großprojekte (BER, SAP-Einführungen bei Lidl, Haribo, Deutsche Post etc.) zeugen plakativ davon.3

Im klassischen PPM neigen die Organisationen – nicht zuletzt die Antragssteller – dazu, ihre Projektvorhaben möglichst groß zu machen, d. h. (vermeintlich) wichtig. Budgets fungieren nicht selten als Statussymbole und fördern eine »Wagenburg-Mentalität«. Das bringt folgende Probleme mit sich:4

Die Komplexität des Vorhabens steigt und das Projektmanagement sowie die fachliche Arbeit werden dadurch schwieriger.

Das Risiko des Scheiterns oder zumindest geringeren Erfolgs steigt – große Projekte scheitern häufiger.

Mehr Mitarbeiter sind durch das Projekt gebunden,

die Projekte dauern länger

die Teams sind größer

der Abstimmungsaufwand wird (exponentiell) größer

… und stehen nicht für andere Aufgaben zur Verfügung oder schädliches Multitasking ist die Folge.

Aufgrund des größeren Scopes steigt die Wahrscheinlichkeit von Change Requests und damit der Aufwand für Scope-/Change-Request-Management.

Die psychologische, ggf. politische Hürde für einen berechtigten Abbruch wird größer, da bereits viel Geld in das Projekt geflossen ist (Sunk Cost Bias).

Die geschilderten Aspekte führen oftmals zu folgenden unvorteilhaften Situationen im klassischen, stabilitätsorientierten PPM:

Projektfreigaben werden aufgrund unrealistischer Annahmen getroffen – Nachsteuerungen sind nötig, aber oftmals schwierig oder aufwendig umzusetzen.

Der Aufwand für Projektanträge ist groß – bei gleichzeitig vorhandener Unsicherheit zum frühen Zeitpunkt.

Große Projekte »claimen« viele Ressourcen über einen verhältnismäßig langen Zeitraum – und blockieren diese damit für andere Projekte.

Schädliches Multitasking findet vermehrt statt, um personelle Engpässe zu überwinden – nicht wertschöpfende Rüstzeiten und Verzögerungen für alle sind die Folge.

Projekte liefern Ergebnisse, deren Nutzen sich ggf. im Laufe der Projektbearbeitungszeit verringert hat – weil das Umfeld oder die Technologie sich verändert haben.

Eskalationen und Konfliktsituation sind die Regel, nicht die Ausnahme – und bedeuten Stress für die Menschen in der Organisation.

Auch wenn sicherlich nicht alle PPM-Organisationen mit diesen Aspekten in gleichem Ausmaß zu kämpfen haben und dies von den Randbedingungen und dem PPM-Reifegrad abhängt, ist es insgesamt evident, dass eine Weiterentwicklung der PPM-Theorie zur Fundierung einer modernen projektorientierten Unternehmensführung geradezu zwangsläufig ist. Die diesem Buch zugrunde liegende These zur Entgegnung der hier geschilderten Kritik am klassischen PPM lautet dabei:

Die Übertragung von agilen und Lean-Management-Prinzipien und -Praktiken trägt zu einem erfolgreichen Projektportfoliomanagement bei, das den Anforderungen an die projektorientierte Unternehmensführung in einer dynamischen Geschäftswelt hinsichtlich der strategieorientierten Steuerung der Projektlandschaft gerecht wird.

2 s. GPM 2015 & 2023; GPM/Universität Bremen 2009; Gemünden et al. 2011

3 s. z. B. Kroker 2018; Brandenburg et al. 2020

4 s. Tegtmeier 2022, S. 9; Boehm/Turner 2009; Standish Group 2015

1.2 Höhere Anforderungen an die Flexibilität

Die Anforderungen, die eine Organisation an die Ausgestaltung ihres PPM-Systems hat, hängen dabei im signifikanten Maß von ihrem Umfeld, z. B. Marktumfeld, und den typischen Inhalten der durchgeführten Projekte ab. Als ausgeprägte Beispiele seien hier eine große Verwaltungsbehörde einerseits und ein Software-Start-up andererseits genannt. Auf der einen Seite ist Budgetplanungssicherheit ein wichtiger Zielfaktor, auf der anderen die flexible Reaktion auf Kundenanforderungen oder -reaktionen. Auch wenn eine Organisation sicherlich kaum diese beiden Extreme in sich vereinen wird, existieren i. d. R. in einem Unternehmen mehrere Varianten von Projekten in der gesamthaften Projektlandschaft nebeneinander. So hat auch die Behörde IT-Projekte und das IT-Start-up vielleicht ein Infrastrukturprojekt (z. B. Bezug eines neuen Gebäudes). Gegebenenfalls sind hier differenzierende Teilportfolien zu bilden (s. Kapitel 8.1).

Um zu verstehen, welche Charakteristik (und damit welche Anforderungen z. B. an die Flexibilität) die betrachtete Projektlandschaft der Organisation hat, mag die Metapher von Burgen, Tankern, Trucks und Booten dienen (s. Abb. 1-1).

Abbildung 1-1:

Merkmale von Projektlandschaften

Dabei wird in einer Vierfeldmatrix die Charakteristik über die Dimensionen »Anpassungsfähigkeit des Projektgegenstands« sowie »Dynamik des Umfelds« aufgespannt. Die erste Dimension charakterisiert ein Projekt nach der Eignung des Projektgegenstands, späte Änderungen umzusetzen. Dies ist z. B. bei einer App-Entwicklung gut ausgeprägt und die Änderungskosten sind i. d. R. recht klein. Bei Hardware- oder Bauprojekten sind die Kosten später Änderungen groß – vielleicht zu groß, um ein iterativ-inkrementelles Vorgehen zu ermöglichen. Eine umfassende Planung »up-front« ist hier angebracht.

Auf der anderen Seite steht die Frage nach dem Umfeld. Gerade im IT-Bereich ist eine große bis sehr große Dynamik zu beobachten – denkt man z. B. nur an die Ende 2022 blitzartig ins Bewusstsein gerückten Möglichkeiten der künstlichen Intelligenz »für jedermann«, die eine unmittelbare Reaktion der Unternehmen diesbzgl. erfordert. Und auch Nicht-IT-Unternehmen, z. B. Versicherungen, berichten von 80–90 % ihrer Projekte, die einen IT-Bezug haben.5 Es liegt also auf der Hand, dass die durch die Matrix charakterisierten Burgen (starres System in einem stabilen Umfeld), Tanker (fluides Umfeld, aber schwerfälliges System), Boote (fluides Umfeld und entsprechend wendiges System) und Trucks (flexible Nutzung eines stabilen Umfelds) eine unterschiedliche Ausgestaltung des PPM-Systems verlangen. (Wie ordnen Sie Ihre Organisation ein?). Generell ist festzustellen, dass aufgrund des zunehmenden Einflusses der Digitalisierung mit den Möglichkeiten der IT als Treiber, die »Fluidität« der Projektlandschaften zunimmt – in der Matrix ein Trend nach rechts oben.

Agilität in der Leistungserstellung und im Management ist demzufolge eine wichtige, generelle Anforderung an eine moderne Unternehmensführung.6

Wandel der Randbedingungen

In der Symbiose von Wissenschaft und Praxis haben sich seit Mitte der 1980er-Jahre umfassende Projektmanagement (PM)-Wissensbasen gebildet und etabliert, um Best Practices und Standards für die Projektwirtschaft verfügbar zu machen (PMBoK Guide, IPMA Competence Baseline, PM4, DIN 69900ff/ISO 21500, PRINCE2, V-Modell XT etc.). Es ist empirisch zu beobachten, dass diese sogenannten klassischen Ansätze der Projektdurchführung zunehmend durch agile ergänzt, wenn nicht durch diese verdrängt werden. Die klassischen Ansätze zeichnet aus, dass sie plangetrieben und hierarchisch gesteuert durchgeführt werden. Dagegen zeichnen sich die agilen Ansätze durch Flexibilität und Adaptivität hinsichtlich der Handhabung volatiler Anforderungen und Rahmenbedingungen aus. Bei den agilen Vorgehensweisen, die vor allem im Kontext der Software-Entwicklung zum Einsatz kommen, sind Scrum und IT-Kanban aufgrund ihrer Verbreitung herauszuheben. Andere, neue Ansätze, wie Agile PM oder Disciplined Agile, vervollständigen die konzeptionelle Basis in Richtung vollwertiger, anwendungsneutraler PM-Methoden, sind aber vielfach proprietär, d. h. nur kommerziell verfügbar.7

Ferner haben sich hybride Projektvorgehensweisen entwickelt, die das plangetriebene Vorgehen mit agilen Methoden paaren. Dadurch entstehen letztlich multimodale Projektlandschaften, die es zu managen gilt. Durch die Vermischung von Projektvorgehensweisen unterschiedlicher Planungs- und Steuerungsphilosophien in einem Portfolio ergeben sich neue Herausforderungen für die Gestaltung des PPM. Während die klassischen Methoden z. B. Meilensteine und a priori definierte Leistungsgegenstände fokussieren, postulieren die agilen Ansätze hier eine grundsätzliche Ergebnisoffenheit. Es gilt also, in der übergeordneten Steuerung des PPM beide Ansätze zu bewältigen.8

Begriffsklärung/Definition

Monomodale Projektlandschaft

In einer monomodalenmonomodale Projektlandschaft oder auch unimodalen Projektlandschaftunimodale Projektlandschaft erfolgt die Verwendung eines einzigen Vorgehensmodells für Projekte. Für die Organisation bedeutet dies, dass nur Prozesse und Methoden des verwendeten Ansatzes, z. B. rein agil oder rein plangetrieben, für Projekte ausgestaltet werden muss und das PPM sich darauf ausrichten kann. Hierunter versteht sich bspw. die Nutzung eines standardisierten Projektantrags für alle Projekte, egal welchen Typs.

Multimodale Projektlandschaft

Im Gegensatz zur monomodalen ist unter multimodaler Projektlandschaftmultimodale Projektlandschaft die alternierende Nutzung verschiedener Vorgehensmodelle für Projekte zu verstehen. Gemeint ist hiermit, dass dem Projektmanagement grundsätzlich mehrere Ansätze für ein Projekt zur Auswahl bereitstehen.

Intermodale Projektlandschaft

Intermodalitätintermodale Projektlandschaft beschreibt hingegen die Verbindung von mehreren Ansätzen im Verlaufe eines Projekts. Anders als bei der monomodalen und multimodalen Projektgestaltung bestehen hierbei für das Management während der Projektdurchführung Möglichkeiten des Wechsels des Modus Operandi.

Einen begrifflichen Analogieschluss bietet die intermodale Mobilität im Güterverkehr. Darin wird der Transport von standardisierten Frachtcontainern zwischen Verkehrsträgern und -mitteln – bspw. vom Lkw zu einem Umschlagplatz, anschließend mit dem Zug zum Seehafen und von dort aus mit dem Schiff zu einem anderen Hafen – als »inter modes« bezeichnet.

Auf der anderen Seite erfordern Volatilität, Unsicherheit, Komplexität und Ambiguität (VUKA) der Gegenwart auch, dass das PPM selbst flexibler, adaptiver, reaktionsschneller und insgesamt einfacher aufgestellt werden muss. VUKA beschreibt die schwierigen Rahmenbedingungen der modernen Unternehmensführung in einer sich schnell ändernden Geschäftswelt. Als Beispiel hierfür dient insbesondere die digitale Transformation der Unternehmen, die etwa im Bereich von Industrie 4.0 sich zu vielfach rasant entwickelnden Möglichkeiten und für die Unternehmen neuartigen Problemdomänen (IT) führt. Zu starre Vorschriften oder bspw. zu langfristige Budgetbindungen für die Durchführung von Projekten sind diesbzgl. kontraproduktiv.9

Prinzipienbasierter Lösungstransfer

Agile Vorgehensweisen in Projekten sind als spezifische Ausprägung des Lean Managements, insbesondere Lean Product Development, zu charakterisieren, bei denen Adaptivität und Flexibilität des Vorgehens einen besonderen Schwerpunkt darstellen. Auch die klassischen, also plangetriebenen Vorgehensweisen können (und sollten) unter der Prämisse des Lean Thinkings durchgeführt werden, um kundenorientiert zu arbeiten und Verschwendungen zu vermeiden. Insofern stellt sich die Aufgabe, ein umfassendes Konzept, das beide Herangehensweisen grundsätzlich ermöglicht, unter der Leitlinie des Lean Managements zu erstellen. Dies hat im Bereich des Einzelprojektmanagements bereits zur Entwicklung des Lean Project Managements (Lean PM) geführt.10

Das Lean ManagementLean Management fördert und fordert die Steigerung der Effizienz des Handelns, aber auch mit Blick auf den Kundennutzen dessen Effektivität. Im Kern postuliert Lean Management die Vermeidung von Verschwendung mithilfe der Ausrichtung auf den Kunden und die Prozesse der Wertschöpfung diesbzgl. Dabei erfolgt eine Umsetzung des Flussprinzips unter Bevorzugung von Pull-Mechanismen sowie das Streben nach Perfektion in der Ausführung.11

Die zentrale Fragestellung dieses Buches lautet daher:

»Wie können Prinzipien und Praktiken des Lean Managements auf die Prozesse, Strukturen und Methoden des Projektportfoliomanagements angewendet werden, um dessen Effizienz und Effektivität – nicht zuletzt auch im Kontext der VUKA-Anforderungen – zu verbessern?«

Eine unmittelbare, explizite Ausgestaltung des Lean Project Portfolio Managements (Lean PPM) ist nicht bekannt. Jedoch existieren Konzepte, die im Zuge der Agilisierung des Projektmanagements und der Skalierung von Projekten hinsichtlich ihres fachlichen und organisatorischen Umfangs bis in das PPM hineinreichen. An erster Stelle ist hier das SAFeSAFe-Konzept (Scaled Agile FrameworkScaled Agile Framework (SAFe)) zu nennen, das selbst auch von Lean Portfolio Management spricht – ohne dies systematisch abzuleiten. Wichtige Elemente von SAFe auf der Portfolioebene sind die Wertschöpfungsorientierung, flexible Budgetierung von Initiativen, regelmäßige Auslieferung von Ergebnissen, pull-orientierte Abarbeitung der Maßnahmen (IT-Kanban) etc. SAFe betrachtet dabei keine Projekte, sondern eine kontinuierliche Entwicklung von Lösungen, insbesondere IT-Produkten. Insgesamt unterliegt auch das PPM derzeit einem Wandel, der auch mit einer gewissen Abkehr von Projekt- hin zum Produktentwicklungsgedanken geht und der in starkem Maße aus der IT-Domäne getrieben wird.12

Bei der Erarbeitung des vorliegenden LAUP2-Konzeptes wurden die bekannten Lean-Elemente (und verwandte Ansätze, wie Agilität, Theory of Constraints u. a.) systematisch auf die Sub-Domänen des PPM, etwa Projektantragswesen, Projektpriorisierung, Portfolio-Balancierung etc., abgebildet und nach sinnvollen und nutzenstiftenden Anwendungen durchforstet. Im Ergebnis sind Handlungsempfehlungen auf strategischer, taktischer und operativer Ebene eines »Lean-adaptive PPM« entstanden.

Der methodische Ansatz ergibt sich im ersten Schritt aus der Untersuchung der Prinzipien und Praktiken des agilen und des Lean Managements auf ihre Anwendbarkeit im PPM. Generell können diese Management-Ansätze differenziert werden nach ihrem grundlegenden Paradigma und ihren Kernprinzipien (Grundsatzebene) sowie ihren operativen Handlungsprinzipien und Methoden bzw. Tools (Ebene der Praktiken). Diese wurden auf die Domäne des PPM abgebildet. Dazu gehört z. B. die Beantwortung der Frage, wie der Kundenbegriff im Kontext des PPM zu definieren ist und welchen Nutzen diese Kunden jeweils spezifisch aus dem PPM ziehen usw.13

Prozessualer Ordnungsrahmen

Um dieses tun zu können, war es zunächst nötig, einen prozessualen Ordnungsrahmen ­(Framework) für das PPM zu definieren. Die Analysen der bekannten und verfügbaren Standards/Best Practices des PPM ergibt, dass diese entweder nicht vollständig, zu allgemein bzw. zu unspezifisch formuliert oder schlichtweg nicht öffentlich zugänglich sind. Diese sind gleichwohl in die Entwicklung des LAUP2-Konzeptes eingeflossen. Auf diese Weise ist ein »Best-of« der bekannten PPM-Frameworks entstanden, das durch eigene empirische Erkenntnisse ergänzt wurde – das Lean-adaptive Unified Project Portfolio Management ­Framework, kurz LAUP2. Mit dem so konstruierten PPM-Referenzmodell liegt der Ordnungsrahmen für eine systematische Adaption der Lean-Elemente vor. In diesem Zusammenhang wurden die Lean-Elemente sukzessive auf die einzelnen Sub-Domänen (insbesondere Prozesse) des PPM-Ordnungsrahmens ausgeprägt.

Operationalisierung durch Praktiken

In der weiteren Ausgestaltung erfolgt die Betrachtung der Ebene der Praktiken. Während die Grundsatzebene des Lean Managements mehr oder weniger eindeutig zu beschreiben ist, sind die operativen Handlungsprinzipien und Methoden (Praktiken) nicht abschließend zu erfassen. Dies liegt an der Vielzahl der Anwendungen in diesem Bereich. Hier ist zu erwähnen, dass die Praktiken jeweils spezifisch für ihre Anwendungsdomäne konzipiert werden. Dazu gehört in erster Linie die Produktion als generelle Quelle des Lean Managements (Toyota Production System), aber auch eine Reihe von Derivaten wie Lean Administration, Lean Construction, Lean Start-up etc., die jeweils ihre spezifischen Anforderungen und damit Methoden mit sich bringen. Einige eher universelle Praktiken lassen sich aber offenkundig identifizieren, wie Gemba (»Gehe vor Ort«), Standardisierung oder Hoshin KanriHoshin Kanri (kaskadierende Zielgebung), die unmittelbar Potenzial für die Anwendung im Kontext von PPM aufzeigen. Eine abschließende Ausgestaltung für PPM kann jedoch letztlich nicht erreicht werden.14

5 s. Friedrich 2023

6 s. Oswald/Müller 2017

7 s. Korn 2014; Komus/Kuberg et al. 2020; Agile Business Consortium 2018; Ambler/Lines 2020

8 s. Blust 2019; Wagner 2016

9 s. T2Informatik o.J. (b); Schnichels-Fahrbach/Munz 2016

10 s. Hüsselmann 2021; Erne 2019, Hüsselmann et al. 2018, Pautsch/Steininger 2014; Seidl 2020

11 s. Poppendieck/Poppendieck 2003; Hüsselmann et al. 2018; Womack/Jones 2013; Bertagnolli 2018

12 s. Mathis 2018; Komus et al. 2020; Leffingwell 2018; Scaled Agile 2024 »Portfolio SAFe«, »Agile Product Delivery«

13 s. Lock/Wagner 2019; Hüsselmann et al. 2018; Hüsselmann 2021

14 s. Womack/Jones 2013; Womack et al. 1991

1.3 Lean-adaptive PPM als Konsequenz

In den renommierten Benchmarking-Studien der TU Berlin und der TU Darmstadt zum PPM werden regelmäßig wesentliche Erfolgsfaktoren der Gestaltung des PPM (Prozesse und Entscheidungskultur) identifiziert. Diese können vielfach als Anwendung von Lean-adaptive Management-Praktiken erkannt werden (ohne dass dies dort so bezeichnet wird, s. auch Kapitel 3.4). Als Beispiel sei genannt, dass die Top-Performer des PPM ihr Portfolio häufiger und systematischer überwachen und schneller auf veränderte Bedingungen reagieren, das Portfolio also kurzfristig anpassen, um Fehlentwicklungen zu vermeiden. Lean-adaptive PPM verspricht daher durch Lean Thinking und den Ansatz der Adaption von bewährten Lean-Management-Handlungsprinzipien und -Praktiken, nicht zuletzt aber auch unter Einbeziehung der Konzepte des Lean PM, eine hilfreiche Weiterentwicklung des PPM.15

Lean-adaptive PPM bedeutet – wie Lean PM auch – eine flexiblere, an die Rahmenbedingungen des Unternehmens angepasste Ausgestaltung des PPM-Systems, d. h. insbesondere seiner Prozesse. Starre, als Bürokratismus empfundene Prozesse erweisen sich in der Praxis als kontraproduktiv, denn sie führen regelmäßig zu Nichtbeachtung, da kein Nutzen mit ihnen verbunden wird bzw. erkennbar ist. Mit der strikten Ausrichtung auf die Prozesskunden und deren Nutzenerwartung liegt die Voraussetzung für die Vermeidung von Verschwendung bei der Durchführung vor.

Die folgenden herausragenden Elemente können als charakteristische Beiträge des Lean-adaptive PPM für ein erfolgreiches PPM identifiziert werden:16

kurze Projektportfolio-Review-Zyklen nach unternehmensweitem Takt

flexible Projektbudgetierung über sogenannte Strategic Buckets

Akzeptanz durch Transparenz, Pragmatismus, Beteiligung, kontinuierlichen Verbesserungsprozess (KVP)

Reduktion von Projekt-Scope, -dauer, -teamgröße

kapazitätsorientierte Projektabwicklung (»Bring projects to people«)

Diese Kernpunkte – sie werden im weiteren Verlauf detailliert behandelt – stellen eine signifikante Weiterentwicklung des klassischen, stabilitätsorientierten PPM dar. In diese sind nicht zuletzt zahlreiche Anwenderberichte zur Agilisierung des PPM eingeflossen. Tabelle 1-1 fasst noch einmal signifikante Unterschiede der PPM-Ansätze in einer Gegenüberstellung zusammen.

Stabilitätsorientiertes PPM

Lean-adaptive PPM

• Zentralisiertes Management

Auf organisations- und funktionsbezogener Ebene gemanagt

Top-down-Zielsetzung

Langzeitplanung und -budgetierung

Langfristige Ressourcenallokation

Projektbasierte Budgetierung

Große und komplexe Projekte

Wechselnde Projektteams

• Dezentralisiertes Management

Auf organisations- und wertstrom-/themenbezogener Ebene gemanagt

Top-down- und Bottom-up-Zielsetzung Inkrementelle/adaptive Planung und Budgetierung

Flexible und kurzfristige Ressourcenallokation

Themenbasierte Budgetierung mit inkrementeller Projektbudgetierung

Minimum Viable Projects

Möglichst stabile Teams

Tabelle 1-1: Zentrale Merkmale der PPM-Ansätze

15 s. Gemünden 2019; Gemünden et al. 2016; Erne 2019; Hüsselmann et al. 2018; Pautsch/Steininger 2014; Seidl 2020

16 s. z. B. Certa/Albayrak 2018; Gemünden et al. 2016; Liechti 2019; Scaled Agile 2024

1.4 Anwendung und Zielgruppe

LAUP2 ist – anders als z. B. SAFe – kein geschlossenes Konzept, das für jeden Sachverhalt (genau) einen Lösungsansatz vorsieht. Es ist vielmehr ein Werkzeugkasten, der es dem PPM-Gestalter ermöglicht, das eigene PPM-System zu konfigurieren. Ein zentrales Postulat diesbzgl. ist

»Approach follows contextApproach follows context!«

D. h., der Kontext der Organisation bedingt den »richtigen« Ansatz. Geht es bspw. im Projektportfolio um den Bau von Brücken, ist das inkrementelle Vorgehen natürlich anders zu bewerten als bei der Entwicklung von Apps, also Software. Insbesondere die im LAUP2-Konzept formulierten Prinzipien (s. Kapitel 5) bilden bei der zielgerichteten Ausgestaltung das universelle Leitbild!

Die Nutzung des vorliegenden Lean-adaptive PPM-Referenzmodells LAUP2 ist für alle Organisationen grundsätzlich relevant, die …

noch kein PPM gestaltet haben,

bisher nur Teile eines PPM umgesetzt haben (z. B. nur Berichtswesen oder nur Antragswesen),

den veränderten Randbedingungen der VUKA-Welt Rechnung tragen oder schlichtweg

für ihr PPM professionalisieren und dessen Nutzen erhöhen wollen.

Hinsichtlich der Branche oder Projektart (IT, Organisation, Produktentwicklung etc.) gibt es keine grundsätzlichen Einschränkungen. In diesem Sinne wurde das LAUP2-Framework mit einem generischen Anspruch entwickelt. Gleichwohl ist zu betonen, dass aufgrund der persönlichen Erfahrungs- und Ausbildungshintergründe der Autoren sowie auch der zugrunde gelegten Standards, Frameworks und Monografien typischerweise vorhandene Spezifika von Branchen oder Projektarten (z. B. Bauprojekte) nicht explizit berücksichtigt wurden bzw. werden konnten. Dies liegt aber durchaus in der Natur der Sache eines (generischen) Referenzmodells und kommt gleichsam einer Aufforderung zur Adaption gleich. Die Erfahrung zeigt gleichwohl, dass die Integration möglicher Spezifika in der Anwendung eines konzeptionellen Modells im Unternehmen i. d. R. Akzeptanz, Anwendbarkeit und Nutzen erhöhen.

Eine weitere mögliche – wenngleich auch nicht explizite – Einschränkung liegt im Aspekt der internen vs. externen Projekte (also Projekte im Kundenauftrag). Dies wird bspw. deutlich durch die Betonung der Strategieorientierung oder das Fehlen eines Vertragsmanagements. Da Kundenprojekte i. d. R. ROI-Projekte sind (d. h. der unmittelbaren Gewinnerwirtschaftung dienen), ist der Strategiebezug bei diesen nur indirekt, durch das Geschäftsfeld gegeben. Indirekt heißt, dass nicht bei jedem Kundenprojekt hinterfragt wird, ob dieses zur Strategie des Unternehmens passt. Das Vertragsmanagement andererseits ordnen wir grundsätzlich dem Einzelprojektmanagement zu.17

Hinweise zur Nutzung

Das vorliegende Buch zur Beschreibung des LAUP2-Ansatzes und -Referenzmodells kann sequenziell durchgearbeitet werden, die Kapitel sind entsprechend in ihrer Abfolge gestaltet. Gleichwohl können Leser, die z. B. bereits mit den prozessualen Elementen eines PPM vertraut sind, auch direkt mit den Prinzipien (Kapitel 5) einsteigen und dann bei Bedarf auf die verwendeten Begriffe, z. B. des Prozessmodells, im Sinne eines Nachschlagewerks zurückgreifen. Ähnlich verhält es sich mit den Praxisberichten in Kapitel 7. Diese setzen eine Reihe konzeptioneller Begriffe voraus, die zuvor im Hauptteil des Buches erklärt wurden. Durch Verweise mithilfe eines Pfeils »→« kann bei Bedarf auch hier unter Zuhilfenahme des Stichwortverzeichnisses nachgeschlagen werden.

Das Kapitel zu den Praktiken (Kapitel 6) stellt insbesondere einen generellen Kanon von Methoden und Tools dar. Mithilfe der Zuordnung zu Prozess- und Aufgabenbereichen lässt sich auch hier beim Lesen gezielt im Sinne eines Nachschlagewerks vorgehen. Bekannte Methoden werden nicht grundlegend erklärt, sondern mit einem Verweis kurz vorgestellt; hierbei wird der Fokus speziell auf Elemente gelegt, die für den Lean-adaptive-Kontext geeignet sind bzw. hierfür entwickelt wurden.

Viele Inhalte des LAUP2-Modells sind in Canvas-Form dargestellt als Steckbriefe (insbes. Rollen- und Prozessbeschreibungen). Dies dient im besonderen Maße der Strukturierung und Systematisierung und ermöglicht auch hier ein gezieltes Nachschlagen.

Insgesamt strebt das Buch auf diese Weise an, (Lean-adaptive) PPM sowohl »von Grund auf« als umfassendes Werk zu beschreiben als auch dem in Sachen PPM fortgeschrittenen Leser Impulse und Anregungen zur Weiterentwicklung des eigenen PPM-Systems zu geben.

17 s. Hüsselmann 2020, S. 24

2 Projektportfolio- und Lean Management – grundlegende Elemente

Gleichwohl viele grundlegende Begriffe der Domäne Managementsysteme der Leserschaft bereits bekannt sein dürften, soll im folgenden Kapitel zunächst einmal eine gemeinsame fachliche Ausgangsbasis für die Entwicklung eines Lean-adaptive-Project-Portfolio-Management-Konzeptes gelegt werden. In diesem Zusammenhang werden einige ausgewählte Aspekte des Projektportfolio- und des Lean Managements sowie des Konzepts der Agilität, aber auch der Komplexitätstheorie- und Systemgestaltung vorgestellt und dabei in den vorliegenden Kontext gestellt.

2.1 Projektportfoliomanagement

2.1.1 Management von Projektlandschaften

Das Management ganzer Projektlandschaften in Organisationen wird als Projektportfoliomanagement (PPM)Projektportfoliomanagement (PPM) bezeichnet. Insbesondere in großen Unternehmen ist PPM ein bewährtes Werkzeug für die Führungsebene, um die Organisation gemäß ihrer Strategie zu steuern. Ein durchschnittliches Projektportfolio, wie bspw. eine umfassende Multiprojektmanagement-Studie der TU Darmstadt und TU Berlin ergab, …

hat 50 Projekte,

verfügt über 30,5 Mio. EUR Jahresbudget,

besteht zu 40 % aus Muss-Projekten,

ist zu 65 % durch Alt-Projekte verplant,

beinhaltet 10 % absolut neuartige und 38 % Routine-Projekte.18

Eine Kernaufgabe des PPM ist es, ein Projektportfolio zu gestalten, das der strategischen Ausrichtung des Unternehmens – unter den eingesetzten Ressourcen – optimal nutzt.

Das erfordert somit die Identifikation des mit dem PPM verbundenen Nutzens für die Organisation – sprich die Beantwortung der Frage: Was will die Organisation mit PPM erreichen? Auch hierzu gibt es eine Anzahl von Ausführungen von Autoren und Studien, deren Essenz durch eine, wenngleich nicht repräsentative, PPM-Studie von Scheer treffend beschrieben werden kann (s. Abb. 2-1).19

Abbildung 2-1:

Warum PPM?

Um diesen Nutzen zu erreichen, sind eine Reihe von Aufgaben zu bearbeiten:20

Bewertung der Attraktivität geplanter und laufender Projekte (unter Berücksichtigung von Strategiebeitrag und Wirtschaftlichkeit),

Abstimmung der Vorhaben im Projektportfolio hinsichtlich Kosten, Inhalt und Zeit

Optimierung des Risikomanagements (durch Frühwarnindikatoren),

Identifikation und Berücksichtigung von Abhängigkeiten und Synergien,

optimale Ressourcenallokation sowie

Schaffung von Transparenz bzgl. des Status der Projekte.

Die Umsetzung der PPM-Aufgaben erscheint gegenwärtig deutlich schwieriger als noch vor wenigen Jahr(zehnt)en. Eine zunehmende Dynamik und Komplexität (z. B. der Digitalisierung) kennzeichnen die Rahmenbedingungen moderner Unternehmensführung, die dafür sorgen, dass die Anforderungen an das PPM instabiler geworden sind.

2.1.2 Begriffsdefinitionen

Der Begriff MultiprojektmanagementMultiprojektmanagement (MPM) ist ein Oberbegriff, der allgemein das Management einer komplexen Projektlandschaft beschreibt. In Beziehung zum Begriff Multiprojektmanagement stehen die Begriffe (Projekt-)Portfoliomanagement, Programm-Management sowie Projektmanagement (von Großprojekten).

Viele Institutionen und Autorenwerke haben jeweils eigene Definitionen für Projekte und das Projektmanagement entwickelt, in deren Synthese folgendes Verständnis des Projektbegriffs zugrunde gelegt wird:

Definition Projekt

Ein ProjektProjekt ist ein Vorhaben mit einem beschränkten Zeit- und Kostenrahmen zur Erbringung einer Reihe gewünschter Ergebnisse, die – unter Einhaltung bestimmter Qualitätsanforderungen – dazu dienen, die definierten Projektziele zu erreichen. Es ist somit eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wurde, bestimmte Ergebnisse bzw. Produkte in Übereinstimmung mit einem übergeordneten Nutzenziel zu erbringen. Ein Projekt ist im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet.21

Aus der Projektdefinition ergeben sich die folgenden Charakteristiken für Projekte: definierte Zielsetzung, strukturelle Komplexität, Einmaligkeit und Befristung des Vorhabens, Arbeiten unter Unsicherheit, fortschreitende Bearbeitung in einem Lebenszyklus und Planung des Vorgehens. Jedes dieser Merkmale tritt weniger oder stärker ausgeprägt auf – aber nie gleich Null. Damit sind Projekte genuin als (mehr oder weniger) komplexe Vorhaben mit einer (temporären) betrieblichen Organisation gekennzeichnet.22

MultiprojektmanagementMultiprojektmanagement wird definiert als »summarischer Überbegriff eines ganzheitlichen Managements einer Projektelandschaft durch entsprechende Organisationsstrukturen, Methoden, Prozesse und Anreizsysteme.«23 Das Management mehrerer Projekte als Projektleiter wird im Allgemeinen dagegen nicht als Multiprojektmanagement bezeichnet.

Für die weitere Verwendung im Rahmen der vorliegenden Arbeit werden folgende Definitionen genutzt:

Definition Projektportfolio

Ein ProjektportfolioProjektportfolio bezeichnet die Zusammenfassung aller geplanten, genehmigten und laufenden Projekte und Programme (ggf. auch weitere Projektportfolios) in einem abgegrenzten Verantwortungsbereich (Unternehmen, Organisation, Geschäftsbereich) zum Zweck der übergeordneten Planung und Steuerung.24

Es kann nach verschiedenen Kriterien strukturiert werden, so z. B. nach Produktgruppen, Marktsegmenten, nach externen oder internen Projekten oder anderen Charakteristiken. Ein Projektportfolio ist zeitlich nicht befristet.

Definition Projektportfoliomanagement

ProjektportfoliomanagementProjektportfoliomanagement (PPM) ist die strategische Ausrichtung, Planung, Steuerung und Anpassung aller Projekte innerhalb einer Organisation zur Sicherstellung eines wirksamen Ressourcenein­satzes.

Es orientiert sich an der übergeordneten Zielsetzung der Organisation und initiiert Projekte und Programme. Begrenzte Ressourcen erfordern eine zielorientierte Auswahl und eine fortlaufende Priorisierung der Projekte und Programme.

Das PPM, das somit Teil des MPM ist, wird demzufolge in Unternehmen für das Steuern einer organisatorisch zusammenhängenden Projektlandschaft genutzt. Projekte machen bei vielen Unternehmen einen Großteil der Wertschöpfung bzw. der strategischen Weiterentwicklung aus und sind somit mitentscheidend für den Unternehmenserfolg. Ein Ziel des PPM ist, dass monetäre als auch weitere Ressourcen bestmöglich auf die einzelnen Projekte verteilt werden.25 Daneben ist ein Ziel bzw. eine Aufgabe des PPM, die Bearbeitung von Projekten zu standardisieren und so das effiziente und effektive Arbeiten zu sichern.

Aus Normensicht (DIN 69909) versteht man unter PPM die »Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die übergreifende Planung und Steuerung von Projektportfolios«. Dabei besteht das Projektportfolio grundsätzlich aus allen anfallenden Projekten und Programmen eines bestimmten Umfeldes.

Das vorliegende Werk befasst sich mit der Entwicklung eines Referenzmodells für das Projektportfoliomanagement. In den Definitionen ist zu erkennen, dass ein Programm ebenfalls als befristetes (Teil-)Portfolio betrachtet werden kann, in dem die Projekte einen starken inhaltlichen Bezug und eine gemeinsame strategische Zielsetzung haben. Abbildung 2-2 ordnet die Begriffe grob schematisch ein und grenzt diese voneinander ab, wie es für das Verständnis des Buches benötigt wird.

Abbildung 2-2:

Gemeinsamkeiten Portfolio – Programm – Projekt

Es wird deutlich, dass das Programm als Komponente einer Projektlandschaft Eigenschaften eines Portfolios und eines Projekts in sich vereint. Aus diesem Grund wird in die Entwicklung des PPM-Referenzmodells auch das Programm als Multiprojektkonstrukt miteingeschlossen, wenn dies möglich ist, bzw. abgegrenzt, wenn dies nötig ist.

Abgrenzung zum Einzelprojektmanagement

Das EinzelprojektmanagementEinzelprojektmanagement (EPM) ist nicht Gegenstand der vorliegenden Betrachtung. Pauschal kann man sagen, dass es im EPM um die Effizienz der Projektdurchführung geht (»Doing the projects right«) und im PPM um die Effektivität (»Doing the right projects«),26 auch wenn dies im Detail etwas vereinfachend ist.

Abbildung 2-3 zeigt die Abgrenzung und auch das Zusammenwirken zwischen EPM und PPM schematisch in einigen wesentlichen Aspekten.

Abbildung 2-3:

Prozesszusammenhang PPM und Einzel-PM

Das EPM adressiert im Kern die Durchführung eines Projekts in den Grenzen vom Projektstart bis zum Projektende – nicht zuletzt, da außerhalb dieser Grenzen die Projektorganisation gemäß Definition typischerweise nicht oder nur eingeschränkt existiert.27 Das PPM steuert dagegen die Projektlandschaft auch über die Grenzen eines einzelnen Projekts hinaus. An den Schnittstellen werden Management-Artefakte und -Informationen ausgetauscht, von denen in Abbildung 2-3 einige typische abgebildet sind.

2.1.3 Kunden des PPMs

Die Kunden des Projektportfoliomanagements sind vielfältig und können je nach Organisation und Branche variieren. Dennoch lassen sich einige typische Kundengruppen identifizieren. Diese haben jeweils unterschiedliche Anforderungen, Prioritäten und Erwartungen an das Projektportfoliomanagement:28

• Portfolio-Entscheider:

Steuerung der Strategieumsetzung (»Doing the right projects«)

• Governance- & Involvement-­Stellen:

Inhaltliche Einbettung der Projekte in den ­Unternehmenszielkontext

• Bereichsleitungen & Ressourcen-Manager:

Demand Management, Machbarkeit der Strategie­umsetzung und Überführung in den Betrieb

• Projektsteuerung und -führung:

Strategieumsetzung über Projekte & Programme (»Doing the projects right«)

Zu den Portfolioentscheidern gehören Aufsichtsräte und das Senior Management sowie die Geschäftsführung. Als Governance- & Involvement-Stelle werden hier nichtfunktionale Bereiche wie Strategie, Finanzen, Controlling, Architektur, Sicherheit, Recht, Beschaffung, IT-Services, Qualitäts- & Risikomanagement etc. bezeichnet. Bereichs- & Teamleitende, Kos­tenstellenverantwortliche, Process & Service Owner etc. sind die Bereichsleitungen & Ressourcen-Manager. Schließlich gehören die Projekt- & Programmleitenden, Auftraggeber, Product Owner sowie PM- und Projekt-Offices zur Gruppe der Projektsteuerung und -führung.

Die erfolgreiche Erfüllung der Anforderungen dieser PPM-Kunden trägt dazu bei, die Effizienz, Effektivität und den geschäftlichen Nutzen des Portfolios zu maximieren.

2.1.4 PPM-Wertströme – High-Level-Betrachtung

Bei der Gestaltung eines PPM-Systems dienen drei zentrale Fragen als Rahmen, um die Wertschöpfung durch PPM zu konkretisieren:

Wie soll – im Einklang mit der Unternehmensstrategie – das PPM-Systems als solches gestaltet werden? D. h., was sind z. B. die typischen Merkmale und Rahmenbedingungen »unseres« Projektwesens?

Wie werden (operative) Ideen und (strategische) Initiativen in Projektvorhaben umgesetzt – unter Einhaltung der durch das PPM-System gegebenen Prämissen und nicht zuletzt vorhandenen Ressourcen und Strategien?

Wie erreichen wir, dass vorhandenes und erworbenes Wissen und Fähigkeiten effizient und effektiv im Kontext der Projektarbeit eingesetzt wird – zur Vermeidung von redundanter Arbeit und Verbesserung der Qualität?

Diese Leitfragen dienen als Trigger für die Identifikation entsprechender WertschöpfungsprozesseWertschöpfungsprozesse des PPM. Die drei daher als zentral zu bezeichnenden Wertschöpfungsprozesse des PPM werden in Abbildung 2-4 in die typische Prozesslandschaft der Organisation eingebettet.

Abbildung 2-4:

High-Level-Wertströme im PPM

Die Bedeutung der genannten Wertströme erschließt sich mithilfe der Leitfragen grundlegend. Ausgangsbasis für den Wertstrom »Von der Unternehmensstrategie zum PPM-System« ist das Vorhandensein einer übergeordneten Strategie der Organisation, die die Zielrichtung auch für das PPM vorgibt. Dazu gehört z. B. die Frage nach dem (angestrebten) Leistungsspektrum, das mithilfe von Projekten ermöglicht werden soll. Aber auch die Art und Weise, wie eine Organisation ihre Projekte organisieren/umsetzen will, ist hier zu verankern. Hier sind Aspekte wie die gesamtunternehmerische Budgetierungssystematik, Entscheidungshierarchien und -prozesse im Unternehmen oder regulatorische Rahmenbedingungen zu erwähnen.

Der Wertstrom »Von der Projektidee zur Nutzenrealisierung« betont den Outcome-orientierten Ansatz des PPM, nach dem die operativen Ziele eines Projekts (OutputOutput) »nur« der Weg zum übergeordneten Geschäftswert desselben (OutcomeOutcome) sind. Da Projekte i. d. R. mit dem Produktivstart der erarbeiteten Lösung grundsätzlich beendet, d. h. aufgelöst werden, obliegt dem PPM die Nutzenrealisierung zu bewerten, die nicht selten erst mit einem zeitlichen Verzug von etwa einem halben bis vollem Jahr sichtbar wird.

Schließlich bleibt zu erwähnen, dass der dritte zentrale Wertstrom »Vom impliziten Wissen zur Anwendung« dem Charakter von Projektarbeit als Wissensarbeit Rechnung trägt. Das Wissen, von dem hier die Rede ist, betrifft organisationelles Wissen über Projekte und Projektmanagement, aber auch fachliches Wissen, das in den Projekten erzeugt und in der Organisation nutzbar gemacht werden sollte.

Zur Einbettung des PPM in die Organisation gehören ferner die Strategie-, Leistungs- und – last but not least – die Unterstützungsprozesse des Unternehmens. Die Kernprozesse bilden dabei die »Enden« der kundenorientierten End-to-end-Sicht des primären PPM-Wertstroms. D. h., sie induzieren den Bedarf und erhalten und nutzen das Ergebnis – kurzum: Sie sind die Kunden. Während die Corporate Strategy die strategische Ausrichtung und die Corporate Finances den finanziellen Rahmen vorgeben, sicherstellen und überwachen, befähigen die Service-Prozesse auch das PPM, indem sie Infrastruktur (nicht zuletzt IT), Betriebsmittel sowie Mitarbeiter bereitstellen und Prozesse ermöglichen. Die Gestaltung des PPM-Systems sollte im Einklang mit den umgebenden Prozessen erfolgen, damit die Schnittstellen reibungslos funktionieren.

2.1.5 PPM als komplexes System

Die Projektlandschaft eines Unternehmens ist im Allgemeinen als komplexes Systemkomplexes System zu charakterisieren. Komplex ist ein System dann, wenn folgende Faktoren vorliegen:

Es gibt viele Elemente.

Die Elemente sind vernetzt.

Die Elemente haben Wechselwirkungen.

Es gibt eine Dynamik, die strukturell oder inhaltlich sein kann.

Daraus entsteht Emergenz.29

Komplexe dynamische Systeme sind sowohl durch eine Menge von Elementen mit vielfachen Wechselwirkungen als auch durch ein unklares Potenzial an Veränderungsmöglichkeiten definiert. Aufgrund dieser Ausprägung sind sie weder hinsichtlich ihres Aufbaus vollständig beschreibbar, noch können detaillierte Aussagen über ihr zukünftiges Verhalten getroffen werden.30

Das heißt, dass ein komplexes System zunächst einmal eine Vielzahl von Elementen umfassen muss, die nicht losgelöst voneinander existieren, sondern in irgendeiner Form verbunden sind. Das liegt in einer Unternehmensprojektlandschaft typischerweise vor: Die Verbindung der Projekte in einem Projektportfolio ist insbesondere der gemeinsame organisatorische Rahmen (z. B. die IT-Abteilung des Unternehmens), bei Programmen kommt noch die gemeinsame strategische Zielsetzung hinzu. Diese Faktoren verursachen insbesondere die Wechselwirkungen der Projekte (Abhängigkeiten in Form von Synergien und Konflikten, aber auch Emergenz, z. B. bei Risiken) aufeinander.

Wenn die enthaltenen Elemente Wechselwirkungen zeigen, die zu Rückkopplungsprozessen und damit zu einer Dynamik des Systems führen, dann wird aus dem (nur) komplizierten System ein komplexes. Dies ist ebenfalls i. d. R. bei Programmen und Projektlandschaften der Fall.31 Damit liegt die Aufgabe des PPM im »Kreuz der Komplexität« im oberen rechten Quadranten (s. Abb. 2-5).

Abbildung 2-5:

PPM im Kreuz der Komplexität

32