<?page no="0"?> ISBN 978-3-381-14261-3 Prof. Dr. rer. oec. Claus Hüsselmann ist Leiter der PPM Labors im FB Wirtschaftsingenieurwesen an der TH Mittelhessen. Seine Schwerpunkte und Publikationen umfassen u. a. das Multiprojektmanagement (Ko-Leitung der GPM-Fachgruppe) sowie hybride PM-Ansätze (Lean PM). Projekte sind komplex und erfordern zielgerichtete Planung und Steuerung - besonders für Führungskräfte, die Projekte leiten oder begleiten. Das Buch vermittelt in kompakter und praxisnaher Form die wichtigsten Methoden und Vorgehensweisen, um Projekte erfolgreich zu planen und durchzuführen. Es bietet einen strukturierten Einstieg ins Projektmanagement und unterstützt Sie dabei, die Qualität der Projektergebnisse zu sichern, Kosten und Termine einzuhalten und Projekte souverän zum Erfolg zu führen. Praktische Übungen und hilfreiche Tools fördern Ihr Lernen, sodass Sie das Gelernte direkt in die Praxis umsetzen können. Ein Schwerpunkt liegt dabei auf IT-Projekten. Das Buch richtet sich an Fach- und Führungskräfte mit Projektverantwortung in der Praxis sowie Studierende, die einen Berufsweg im Projektmanagement anstreben. Hüsselmann Projektmanagement für Führungskräfte Claus Hüsselmann Projektmanagement für Führungskräfte Ein Grundlagenkurs in 5 Takten <?page no="1"?> Projektmanagement für Führungskräfte <?page no="2"?> Prof. Dr. rer. oec. Claus Hüsselmann ist Leiter der PPM-Labors im FB Wirtschaftsingenieurwesen an der TH Mittelhessen. Er wirkte nach Studium der Technomathematik zunächst als leitender Entwickler in einem SAP-Systemhaus. Bei Scheer verantwortete er anschließend zwanzig Jahre lang mehrere (Groß-)Projekte, den Bereich Project Operations & Risk Control für das Consulting-Geschäft sowie als Partner den Beratungsgeschäftsbereich Project Performance Management. 2012 bis 2015 war er als Vorstand der Deutschen Gesellschaft für Projektmanagement GPM engagiert. Seine Schwerpunkte und Publikationen umfassen u.a. das Multiprojektmanagement (Ko-Leitung der GPM-Fachgruppe) sowie hybride PM-Ansätze (Lean PM). <?page no="3"?> Claus Hüsselmann Projektmanagement für Führungskräfte Ein Grundlagenkurs in 5 Takten Unter Mitwirkung von Philipp Diehl <?page no="4"?> Umschlagmotiv: © zakokor · iStockphoto 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. DOI: https: / / doi.org/ 10.24053/ 9783381142620 © UVK Verlag 2025 ‒ Ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KG Dischingerweg 5 · D-72070 Tübingen Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Alle Informationen in diesem Buch wurden mit großer Sorgfalt erstellt. Fehler können dennoch nicht völlig ausgeschlossen werden. Weder Verlag noch Autor: innen oder Herausgeber: innen übernehmen deshalb eine Gewährleistung für die Korrektheit des Inhaltes und haften nicht für fehlerhafte Angaben und deren Folgen. Diese Publikation enthält gegebenenfalls Links zu externen Inhalten Dritter, auf die weder Verlag noch Autor: innen oder Herausgeber: innen Einfluss haben. Für die Inhalte der verlinkten Seiten sind stets die jeweiligen Anbieter oder Betreibenden der Seiten verantwortlich. Internet: www.narr.de eMail: info@narr.de Einbandgestaltung: siegel konzeption ⅼ gestaltung Druck: Elanders Waiblingen GmbH ISBN 978-3-381-14261-3 (Print) ISBN 978-3-381-14262-0 (ePDF) ISBN 978-3-381-14263-7 (ePub) <?page no="5"?> Geleitwort Es hat mir als Dozent des Online-Seminars ‚IT-Projektmanagement‘ große Freude bereitet, das umfangreiche Wissen, das im Buch ‚Projektmanagement für Führungskräfte ‒ Ein Grundlagenkurs in 5 Takten‘ von Claus Hüsselmann enthalten ist, mehrfach in Online-Seminaren an Führungskräfte aus mittelständischen Unternehmen weitergeben zu dürfen. Das auf dem Buch basierende Seminar hat nicht nur die Teilnehmer befähigt, ihre IT-Projekte erfolgreich zu initiieren und umzusetzen, sondern auch gezeigt, wie komplexe Theorie mit außergewöhnlicher Klarheit und Praxisnähe in den Unternehmensalltag übertragen werden kann. Besonders beeindruckend ist die Fähigkeit von Claus Hüsselmann, Wissen nicht nur zu vermitteln, sondern echte Transformation zu ermöglichen - ein Verdienst, der sich in den begeisterten Rückmeldungen der Teilnehmer widerspiegelt. Dank innovativen Methoden, wegweisenden Tools wie dem Agilometer oder dem Unified Project Management Framework (UPMF), sowie dem durchdachten Konzept der Transferaufgaben konnten selbst Skeptiker praxisnahe Lösungen für ihre Herausforderungen finden. Das Buch ‚Projektmanagement für Führungskräfte‘ ist weit mehr als ein Fachbuch - es ist ein wertvoller Kompass für alle, die insbesondere IT-Projekte erfolgreich gestalten wollen. Dr. Michael Schulz, PM-Berater und -Trainer Vorworte Projektmanagement - ein Begriff, der in vielen Führungsetagen entweder für bewunderndes Kopfnicken oder für leichtes Stirnrunzeln sorgt. Denn so manches Projekt scheint sich zu entwickeln wie ein freilaufender Gartenschlauch: Es sprudelt, es windet sich, es trifft selten das Ziel - aber irgendjemand wird schon nass. In meiner langjährigen Praxis als Projektmanager, Leiter eines Project Management Offices und Berater ist mir wiederholt vor Augen geführt worden: Viele Führungskräfte stehen ihren Projekt-Teams mit großer Verantwortung - aber manchmal eben auch mit leichtem Fragezeichen gegenüber. Nicht unbedingt aus Unwillen, sondern weil Zeit, Problembewusstsein oder schlichtweg das passende Grundlagenwissen fehlen. Genau hier setzt dieses Buch an. Fünf kompakte Takte, praxisnah, strukturiert und direkt auf den Führungsalltag zugeschnitten, sollen helfen, das Projektgeschehen nicht nur zu verstehen, sondern es aktiv und souverän zu gestalten. Dabei geht es nicht darum, Projektmanagement zum neuen Lebenszweck zu machen. Vielmehr möchte dieses Buch zeigen, wie Sie mit dem richtigen Maß an Struktur, Methodik und Empathie Ihre Projekte möglichst sicher auf Kurs halten - auch wenn der Wind mal von vorn kommt. Das Buch basiert auf einem mehrtägigen Grundlagenkurs, den ich für die ADG Akademie Deutscher Genossenschaften entwickeln durfte - mein herzlichster Dank gilt Philipp Diel und dem gesamten Team für die inspirierende Zusammenarbeit und die großzügige Freigabe der Inhalte. Ergänzt wird das Ganze durch zahlreiche bewährte Impulse aus meiner Projektmanagement- Vorlesung an der TH Mittelhessen, wo Theorie und Praxis regelmäßig aufeinandertreffen - manchmal mit überraschenden, oftmals aber sehr lehrreichen Ergebnissen. Ich lade Sie ein, dieses Buch nicht einfach nur zu lesen, sondern es als Werkzeugkasten zu verstehen. Mit Übungen, Aufgaben und praxistauglichen Tools - für mehr Klarheit, bessere Kommunikation und erfolgreichere Projekte. <?page no="6"?> 6 Vorworte Viel Freude beim Lesen, Lernen und Umsetzen - und vielleicht beim nächsten Projekt auch ein bisschen weniger Gartenschlauch-Gefühl. Ihr Claus Hüsselmann Das vorliegende Projektmanagement-Grundlagenbuch für Führungskräfte basiert auf der langjährigen praktischen Erfahrung und wissenschaftlichen Expertise von Prof. Dr. Claus Hüsselmann. Sein klar strukturierter, praxisorientierter Ansatz zieht sich wie ein roter Faden durch alle Kapitel. Gerade Führungskräfte erhalten so ein zuverlässiges Navigationsinstrument für ihre Projektarbeit - unabhängig davon, ob es sich um klassische, agile oder hybride Vorhaben handelt. Die Inhalte des Buches sind über mehrere Jahre hinweg gereift - nicht nur in der Theorie, sondern auch in der erfolgreichen didaktischen Umsetzung. In Form eines Web Based Trainings zum Thema IT-Projektmanagement wurden sie bereits zahlreichen Lernenden zur Verfügung gestellt. Ob als Teilnehmende in einem begleiteten Online-Kurs oder im Selbststudium - das Feedback war durchweg positiv. Die hohe Akzeptanz unterstreicht die Relevanz und Qualität des vorliegenden Materials. Einen besonderen Mehrwert bieten die begleitenden Lernvideos: Sie fassen zentrale Inhalte prägnant zusammen, visualisieren komplexe Sachverhalte und helfen, das Gelernte in den individuellen Arbeitsalltag zu übertragen. Damit wird das Buch zu einem multimedialen Werkzeugkasten, der weit über reines Fachwissen hinausgeht. Die Zusammenarbeit mit Prof. Hüsselmann bei der didaktischen Aufbereitung der Inhalte war für mich nicht nur inspirierend, sondern auch ausgesprochen produktiv. Der gemeinsame Austausch war geprägt von gegenseitigem Respekt, Ideenvielfalt und einem tiefen Verständnis für die Bedürfnisse unserer Zielgruppe. Dieses Buch ist ein wertvoller Begleiter für alle, die IT-Projekte mit strategischem Weitblick, methodischer Klarheit und einem Gespür für die Realität im Unternehmensalltag gestalten wollen. Wer es nutzt, wird schnell feststellen: Die Praxiserfahrung des Autors ist auf jeder Seite spürbar - und das macht den Unterschied. Philipp Diel, Produktmanager, Akademie Deutscher Genossenschaften e.V., Montabaur <?page no="7"?> Inhaltsverzeichnis Geleitwort.......................................................................................................................................................... 5 Vorworte ............................................................................................................................................................ 5 Hinweise .......................................................................................................................................................... 10 Zusammenfassung......................................................................................................................................... 11 Abstract ............................................................................................................................................................ 12 1 Takt 1: Projekt-Setup .....................................................................................................15 1.1 Einleitung ............................................................................................................................................ 15 1.2 Definitionen........................................................................................................................................ 17 1.3 Überblick Projektvorbereitung ...................................................................................................... 21 1.4 Das Projektumfeld ............................................................................................................................ 21 1.4.1 Umfeldanalyse.................................................................................................................................... 21 1.4.2 Stakeholder-Management ............................................................................................................... 24 1.4.3 Lösungen ............................................................................................................................................. 30 1.5 Projektauftrag .................................................................................................................................... 30 1.5.1 Vom Antrag zum Auftrag ............................................................................................................... 30 1.5.2 Ziele ...................................................................................................................................................... 31 1.5.3 Lösungen ............................................................................................................................................. 40 1.6 Der Projekterfolg............................................................................................................................... 40 1.6.1 Das erweiterte Magische Dreieck ................................................................................................. 40 1.6.2 Erfolgsmessung.................................................................................................................................. 42 1.6.3 Business Case ..................................................................................................................................... 43 1.6.4 Erweiterte Wirtschaftlichkeitsbetrachtung ................................................................................ 45 1.7 Projektbeschreibung − Project Canvas & Co. ............................................................................ 47 1.8 Erfolgsfaktoren − Wie gelingt erfolgreiches Projektmanagement? ..................................... 49 1.9 Das PM-Framework.......................................................................................................................... 50 1.9.1 Überblick ............................................................................................................................................. 50 1.9.2 Inhalte des UPMF .............................................................................................................................. 51 1.10 Transferaufgaben Takt 1 ................................................................................................................. 55 1.10.1 Prozesse ............................................................................................................................................... 55 1.10.2 Erfolgsfaktoren .................................................................................................................................. 55 2 Takt 2: Projektplanung ..................................................................................................57 2.1 Requirements Management............................................................................................................ 57 2.1.1 Grundlagen ......................................................................................................................................... 57 2.1.2 Minimum Viable Product ................................................................................................................ 66 2.1.3 Produktvision ..................................................................................................................................... 66 <?page no="8"?> 8 Inhaltsverzeichnis 2.1.4 User Stories ........................................................................................................................................ 68 2.1.5 Atmender Scope − Neues Verständnis der Scope-Festlegung............................................... 69 2.1.6 Lösungen............................................................................................................................................. 76 2.2 Projektstrukturplanung................................................................................................................... 76 2.2.1 Projektstrukturplan.......................................................................................................................... 77 2.2.2 Arbeitspakete ..................................................................................................................................... 80 2.2.3 Vorgehen zur Aufstellung eines Projektstrukturplans ........................................................... 81 2.2.4 Aufwandsermittlung........................................................................................................................ 82 2.3 Projektablaufplanung ...................................................................................................................... 87 2.3.1 Projektlebenszyklus ......................................................................................................................... 87 2.3.2 Projektphasen .................................................................................................................................... 87 2.3.3 Meilensteine ....................................................................................................................................... 91 2.3.4 Projektabschnitte .............................................................................................................................. 92 2.3.5 (Operative) Projektablaufplanung ................................................................................................ 95 2.3.6 Rollierende Planung ......................................................................................................................... 98 2.4 Transferaufgaben Takt 2............................................................................................................... 100 2.4.1 Ihr Projekt......................................................................................................................................... 100 2.4.2 User Requirements ......................................................................................................................... 100 3 Takt 3: Projektorganisation........................................................................................ 101 3.1 Projektaufbauorganisation ........................................................................................................... 101 3.1.1 Rollen im Projekt ............................................................................................................................ 111 3.1.2 Projektgremien................................................................................................................................ 118 3.1.3 RACI-Matrix..................................................................................................................................... 120 3.1.4 Lösungen........................................................................................................................................... 121 3.2 Projekt-Vorgehensmodelle........................................................................................................... 122 3.2.1 Klassische Vorgehensmodelle ..................................................................................................... 122 3.2.2 Agile Vorgehensmodelle............................................................................................................... 124 3.2.3 Hybrides Vorgehen ........................................................................................................................ 137 3.3 Projekttypisierung.......................................................................................................................... 139 3.3.1 Typen von IT-Projekten................................................................................................................ 140 3.3.2 Adaption PM-System ..................................................................................................................... 143 3.3.3 Agilometer........................................................................................................................................ 144 3.3.4 Fazit .................................................................................................................................................... 150 3.4 Transferaufgaben Takt 3............................................................................................................... 151 3.4.1 Vorgehensmodell ............................................................................................................................ 151 3.4.2 Projektorganisation........................................................................................................................ 152 <?page no="9"?> Inhaltsverzeichnis 9 4 Takt 4: Projektsteuerung ............................................................................................153 4.1 Vertragsmanagement ..................................................................................................................... 153 4.1.1 Vertragsarten.................................................................................................................................... 154 4.1.2 Change Requests ............................................................................................................................. 156 4.1.3 Claims ................................................................................................................................................ 157 4.1.4 Agiler Festpreisvertrag .................................................................................................................. 158 4.1.5 Relationaler Vertrag ....................................................................................................................... 160 4.2 Qualitätsmanagement .................................................................................................................... 161 4.2.1 Qualitätssicherung .......................................................................................................................... 162 4.2.2 Qualitätsplanung ............................................................................................................................. 164 4.2.3 Abnahmen......................................................................................................................................... 168 4.3 Risikomanagement ......................................................................................................................... 169 4.3.1 Projektrisiken ................................................................................................................................... 169 4.3.2 Der Regelkreis des Risikomanagements.................................................................................... 171 4.3.3 Normstrategien ................................................................................................................................ 174 4.3.4 Lösungen ........................................................................................................................................... 176 4.4 Projektcontrolling ........................................................................................................................... 176 4.4.1 Grundlagen ....................................................................................................................................... 176 4.4.2 Plan-Ist-Vergleich ........................................................................................................................... 182 4.4.3 Der Statusbericht............................................................................................................................. 183 4.4.4 Fortschrittsfeststellung .................................................................................................................. 187 4.4.5 Earned Value Analyse .................................................................................................................... 191 4.4.6 Meilenstein-Trend-Analyse.......................................................................................................... 194 4.4.7 Open Issue Management ............................................................................................................... 196 4.4.8 Projekt-Kanban................................................................................................................................ 198 4.4.9 Critical Chain Project Management ........................................................................................... 200 4.5 Transferaufgaben Takt 4 ............................................................................................................... 204 4.5.1 Vertrag ............................................................................................................................................... 204 4.5.2 Risiken................................................................................................................................................ 204 5 Takt 5: Das Projekt in der Organisation ...................................................................207 5.1 Lernen in und mit Projekten ........................................................................................................ 207 5.1.1 Einordnung ....................................................................................................................................... 207 5.1.2 Lessons Learned im Projekt.......................................................................................................... 208 5.1.3 Starfish-Methode ............................................................................................................................. 211 5.1.4 Multiprojekt-Wissensmanagement ............................................................................................ 212 5.1.5 Kommunikation............................................................................................................................... 213 5.1.6 Eskalation.......................................................................................................................................... 218 5.1.7 Projektmarketing ............................................................................................................................ 220 <?page no="10"?> 10 Inhaltsverzeichnis 5.2 Überleitung in den Betrieb ........................................................................................................... 221 5.2.1 Cut-over-Planung ........................................................................................................................... 221 5.2.2 Betriebsübergabe............................................................................................................................. 222 5.2.3 Einführungskonzept....................................................................................................................... 223 5.2.4 Hypercare ......................................................................................................................................... 223 5.3 Projektabschluss.............................................................................................................................. 224 5.3.1 Kundenzufriedenheit ..................................................................................................................... 225 5.3.2 Abschlussbericht............................................................................................................................. 225 5.3.3 Nutzenrevision ................................................................................................................................ 227 5.3.4 Auflösung des Projekts ................................................................................................................. 227 5.4 Management der Projektlandschaft ‒ speziell der IT ............................................................ 228 5.4.1 Ausgangsbasis IT-Strategie .......................................................................................................... 229 5.4.2 Nutzen von Strategieprojekten ................................................................................................... 232 5.4.3 Projektportfoliomanagement....................................................................................................... 234 5.4.4 Nutzwertanalyse ............................................................................................................................. 236 5.4.5 Prozessmodell PPM ........................................................................................................................ 238 5.4.6 Überblick IT-PM-Software ........................................................................................................... 245 5.4.7 Einsatz von Künstlicher Intelligenz ........................................................................................... 251 5.5 Transferaufgaben Takt 5............................................................................................................... 253 5.5.1 Lessons Learned .............................................................................................................................. 253 5.5.2 Lösungen........................................................................................................................................... 253 5.5.3 Projektportfolio ............................................................................................................................... 253 5.6 Zum Abschluss des Buches …...................................................................................................... 254 Quellen und weiterführende Literatur .................................................................................................. 257 Abbildungsverzeichnis............................................................................................................................... 263 Stichwortverzeichnis .................................................................................................................................. 271 Hinweise Alle Videos zum Buch finden Sie auf dem Youtube-Kanal des Autors: https: / / youtube.com/ playlist? list=PLfISeyo-_J8kcdquIJYw8kxUpWToVmq_W&si=nBi3Tl7o DIw8pHUy Zudem werden als Zusatzmaterial zum Buch Tools bereitgestellt. Sie können unter folgendem Link aufgerufen werden: https: / / files.narr.digital/ 9783381142613/ tools.zip <?page no="11"?> Zusammenfassung Das Buch „Projektmanagement für Führungskräfte - Ein Grundlagenkurs in 5 Takten“ vermittelt praxisnah und systematisch die wesentlichen Grundlagen des Projektmanagements, zugeschnitten auf die Bedürfnisse von Führungskräften. Der Aufbau in fünf klar gegliederte „Takte“ ermöglicht eine schrittweise, didaktisch durchdachte Einführung in das Thema - vom Projektstart bis zur strategischen Verankerung in der Organisation. Im ersten Takt steht das Projekt-Setup im Vordergrund. Neben einer grundlegenden Einführung in Begriffe und Definitionen werden hier die Vorbereitung und das Umfeld eines Projekts analysiert, inklusive Stakeholder-Management und Umfeldanalyse. Ein zentrales Element ist die Entwicklung eines fundierten Projektauftrags mit klarer Zieldefinition und Erfolgsfaktoren. Themen wie das „erweiterte magische Dreieck“, Business Case-Betrachtungen sowie moderne Werkzeuge wie der Project Canvas runden diesen Einstieg ab. Ergänzend wird ein eigenes Projektmanagement-Framework (UPMF) vorgestellt, das als roter Faden durch das Buch dient. Takt zwei widmet sich der detaillierten Projektplanung. Der Fokus liegt auf dem Requirements Management - von der Erhebung von Anforderungen bis hin zur Formulierung von User Stories und einer greifbaren Produktvision. Die Projektstrukturplanung wird anhand klassischer Methoden wie Arbeitspaketen und Projektstrukturplänen vermittelt, ergänzt durch praxisnahe Aspekte wie Aufwandsschätzung, Ablaufplanung, rollierende Planung und Meilensteinsetzung. Dabei werden moderne Konzepte wie das „atmende Scope“ und das Minimum Viable Product (MVP) integriert. Der dritte Takt behandelt die Projektorganisation. Hier geht es um die Aufbauorganisation innerhalb des Projekts, Rollenverteilungen, Gremienstrukturen und Instrumente wie die RACI- Matrix. Besonders praxisrelevant ist die Gegenüberstellung klassischer, agiler und hybrider Vorgehensmodelle sowie die Adaption des PM-Systems an unterschiedliche Projekttypen. Unterstützt wird dies durch das sogenannte „Agilometer“, das den Reifegrad agiler Praktiken einschätzbar macht. Im vierten Takt liegt der Fokus auf ausgewählten Steuerungsdisziplinen. Vertragsmanagement, Qualitäts- und Risikomanagement sowie Projektcontrolling werden systematisch aufbereitet. Wichtige Werkzeuge wie Earned Value Analyse, Meilenstein-Trendanalysen, Projekt- Kanban oder Critical Chain Project Management (CCPM) ermöglichen eine belastbare Projektsteuerung. Ergänzend werden moderne Vertragsformen wie agile Festpreisverträge oder relationale Verträge vorgestellt, die speziell in dynamischen Projektumfeldern an Bedeutung gewinnen. Der fünfte und letzte Takt beleuchtet das Projekt in seiner organisationalen Einbettung. Themen wie Lernen aus Projekten, Wissensmanagement, Kommunikation, Eskalation und Projektmarketing stehen hier im Vordergrund. Der Übergang in den Betrieb wird detailliert betrachtet - inklusive Cut-over-Planung, Betriebsübergabe, Einführungskonzept und Hypercare-Phase. Der Projektabschluss wird nicht nur dokumentarisch, sondern auch im Hinblick auf Kundenzufriedenheit und Nutzenrevision behandelt. Abschließend wird der Blick auf das strategische Projektmanagement erweitert, etwa durch Projektportfoliomanagement, IT-Strategie und eine Übersicht relevanter PM-Softwarelösungen. Jeder Takt schließt mit praxisorientierten Transferaufgaben ab, die Führungskräfte dabei unterstützen sollen, das Gelernte direkt auf ihre Projekte zu übertragen. Das Buch bietet damit nicht nur theoretisches Wissen, sondern eine anwendungsorientierte Grundlage für wirksames und modernes Projektmanagement im Führungskontext. <?page no="12"?> 12 Abstract Schlüsselbegriffe: Projekt-Setup, Projektumfeld, Stakeholder-Management, Projektauftrag, Zieldefinition, Projekterfolg, Erfolgsfaktoren, PM-Framework, Projektplanung, Requirements Management, Projektstrukturplan, Aufwandsschätzungen, Ablaufplanung, Projektorganisation, klassische, agile und hybride Vorgehensmodelle, Projekttypisierung, Projektsteuerung, Vertrags-, Qualitäts- und Risikomanagement, Earned Value Analyse, Trendanalysen, Kanban und CCPM, Change Requests, Claims und Vertragsformen, Wissensmanagement, Projektkommunikation, Überleitung in den Betrieb, Nutzenrevision, Projektportfoliomanagement, IT-Strategie, PM-Software Abstract The book "Project Management for Executives - A Basic Course in 5 Acts" provides a practical and structured introduction to the essentials of project management, tailored specifically for executives. Organized into five clearly defined "movements," the book offers a step-by-step, didactic approach to project work—from initial setup to strategic integration within the organization. The first act focuses on project setup. In addition to key definitions and terminology, this section covers project preparation and environmental analysis, including stakeholder management. A major element is the development of a solid project charter with clearly defined objectives and success factors. Topics such as the "extended magic triangle", business case considerations, and modern tools like the Project Canvas are also addressed. A proprietary project management framework (UPMF) is introduced as a guiding structure throughout the book. The second act delves into detailed project planning. Central here is requirements management, covering the collection and formulation of user requirements, user stories, and a concrete product vision. Project structure planning is discussed through methods such as work breakdown structures and work packages, along with practical topics like effort estimation, scheduling, rolling wave planning, and milestone setting. Contemporary concepts such as the "breathing scope" and the Minimum Viable Product (MVP) are also incorporated. The third act deals with project organization. This includes project organizational structure, role definitions, committee structures, and tools like the RACI matrix. Particularly useful for practice is the comparison between classical, agile, and hybrid project approaches, as well as the adaptation of the PM system to different project types. This section is supported by the "Agilometer", a tool to assess the maturity of agile practices. The fourth act highlights selected disciplines of project control. It covers contract management, quality management, risk management, and project controlling in a structured manner. Important tools such as earned value analysis, milestone trend analysis, project Kanban, and Critical Chain Project Management (CCPM) provide a robust foundation for effective project control. Additionally, modern contract models—such as agile fixed-price and relational contracts—are introduced, especially relevant in dynamic project environments. The fifth and final act looks at projects within the broader organizational context. Topics include organizational learning from projects, knowledge management, communication, escalation, and project marketing. Transitioning the project into operational use is explored in detail, including cut-over planning, operational handover, implementation strategies, and the hypercare phase. Project closure is addressed not only in terms of documentation but also customer satisfaction and benefits realization. The book concludes by expanding the perspective toward strategic project management, including project portfolio management, IT strategy, and an overview of relevant project management software solutions. <?page no="13"?> Abstract 13 Each movement ends with practice-oriented transfer tasks, encouraging readers to immediately apply what they’ve learned to their own projects. As such, the book offers not just theoretical foundations, but a hands-on guide to effective and modern project management in an executive context. Keywords: Project set-up, project environment, stakeholder management, project charter, goal definition, project success, success factors, PM framework, project planning, requirements management, work breakdown structure, effort estimation, scheduling, project organisation, classic, agile and hybrid process models, project classification, project control, contract, quality and risk management, Earned Value Analysis, trend analyses, Kanban and CCPM, change requests, claims and contract forms, knowledge management, project communication, transfer to operations, benefit audit, project portfolio management, IT strategy, PM software <?page no="15"?> 1 Takt 1: Projekt-Setup In den ersten beiden Videos sehen Sie zum Auftakt die Begrüßung und den Überblick über Takt 1. ► Video 1.0 (Einleitung), URL: https: / / youtu.be/ xFt8Clq-1dg ► Video 1.1 (Übersicht Takt 1), URL: https: / / youtu.be/ cZts7SwX3NY 1.1 Einleitung Die betriebliche Wertschöpfung in Form von Projekten umfasst einen signifikanten und immer größer werdenden Anteil. So ermittelte die GPM Deutsche Gesellschaft für Projektmanagement e.V. vor einigen Jahren (Erhebungsjahr 2022) in einer repräsentativen Studie einen Anteil in Höhe von 34,5% der wirtschaftlichen Gesamtleistung, was einem Volumen von 1.204 Mrd. Euro entspricht. Dieser Anteil wurde gemessen in Form des Inputs von Arbeitsleistung, da der Output aufgrund der Heterogenität der Leistungen - z.B. Organisationsprojekte oder Anlagenbauprojekte - nicht einheitlich messbar erscheint. Für den Wirtschaftsbereich der Finanz- & Versicherungsdienstleister ermittelte die GPM einen Anteil des Personaleinsatzes (gemessen in Arbeitszeit) in Höhe von 19,2%, für das Baugewerbe sogar von 55,0%. Die Arbeitsform „Projekt“ ist also allgegenwärtig. Dabei werden z.B. im Finanzsektor überwiegend (interne) IT-Projekte (26% alle Projekte) sowie Organisationsbzw. HR-Projekte (20%) durchgeführt. Im Baubzw. produzierendem Gewerbe dominieren hingegen Kunden- und Auftragsprojekte (35% bzw. 24%). Im Handelssektor liegen die Marketing-/ Vertriebsprojekte mit 22% gleichauf mit den IT-Projekten. Letztere spielen insgesamt mit 19% Anteil die zweitgrößte Rolle nach den Kundenbzw. Auftragsprojekten (22%). 1 Eine Universalmethodik ist nicht mehr für alle Projekte hilfreich. Die Klassifizierung von Projekten z.B. nach Projektgegenstand hilft, im Projektmanagement die richtigen Schwerpunkte zu setzen, um die verschiedenen Anforderungen handhaben zu können. 2 Folgende Projektarten unterscheidet man typischerweise in Unternehmen: (1) Intern: Organisations- / HR-Projekte (2) Intern: IT-Projekte (3) Intern: F & E- / Neuproduktionsentwicklungsprojekte Projekte, zur Veränderung der Organisation, z.B. • Prozessoptimierung • Zertifizierung nach ISO 9000 • Einführung neues Tarifwerk • Zentralisierung des Beschaffungswesens Projekte zur Entwicklung der IT im Unternehmen, z.B. • Einführung ERP-System • Entwicklung Fachanwendung • Migration des Betriebssystems Projekte zur Entwicklung neuer Produkte oder Leistungen, z.B. • Einführung einer neuen Karte • Entwicklung eines neuen Geräts • Entwicklung eines neuen Verfahrens 1 GPM, 2023 2 Kuster et al., 2011 <?page no="16"?> 16 Takt 1: Projekt-Setup (4) Intern: Marketing-/ Vertriebsprojekte (5) Intern: Infrastrukturprojekte (6) Extern: Kunden- / Auftragsprojekte Projekte, die unmittelbar den Markt betreffen, z.B. • Durchführung einer Inhouse-Messe • Durchführung einer Marketing-Kampagne • Einführung eines neuen Vertriebskanals Projekte, die eine große materielle Investition bedeuten, z.B. • Einführung von Terminals • Bau einer Filiale • Errichtung eines neuen Gebäudes • Beschaffung von Hardware Projekte, deren Auftraggeber ein Projektkunde ist, z.B. • Errichtung eines Leitstands für eine Organisation • Bau einer Anlage • Durchführung eines Beratungsprojekts ▲ Welche Projektarten kommen in Ihrem Unternehmen vor? Zur weiteren Differenzierung etwa von IT-Projekten kann der „Würfel“ in Abbildung 1 verwendet werden. 3 ERP: Enterprise Resource Planning EDV: Elektronische Datenverarbeitung Abbildung 1: Differenzierung von IT-Projekten In der Praxis lässt sich oftmals ein Projekt nicht eindeutig einer der o.g. Projektarten zuordnen, es enthält verschiedene Charakteristiken. Dies drückt sich dann meistens in verschiedenen artigen Teilprojekten aus. Weitere Differenzierungen, etwa nach Größe und Innovation besprechen wir im Verlaufe des Kurses. Hinsichtlich der Erfolgsfaktoren zeigen diverse Studien, dass weiterhin Verbesserungspotenzial besteht. So zeigte bspwder CHAOS Report der Standish Group 2015: • Nur 29% der IT-Projekte sind erfolgreich (im Sinne von Plantreue)! • 2% der erfolgreichen IT-Projekte sind Großprojekte − jedoch 62% Kleinprojekte. • Der Projektgegenstand spielt eine große Rolle bei der Erfolgsquote (z.B. Einführung von Standard-Software oder Eigenentwicklung). • Agile Vorgehensweisen sind ca. 3-mal so häufig erfolgreich wie das Wasserfallvorgehen. 3 In Anlehnung an Ruf & Fittkau, 2008, zitiert nach Wendler, 2009, S. 14 <?page no="17"?> 1.2 Definitionen 17 Hieraus lässt sich auch gleich ein Leitmotiv für das Buch zum modernen Projektmanagement ableiten, das vor Ihnen liegt: Welche Herangehensweisen für IT-Projekte gibt es und wann sind welche Methoden wertschöpfend einzusetzen? Bevor wir uns weiter mit der Ausführung von Projekten beschäftigen, sollen im Folgenden nun zunächst einmal einige grundlegende Definitionen besprochen werden. 1.2 Definitionen Sucht man nach einer verbindlichen Definition des Begriffs „Projekt“, so wird man nicht fündig. Zu viele Organisationen, Verbände und Autoren haben Projekte definiert, wobei im Detail unterschiedliche Formulierungen benutzt werden, die aber in der Regel eine gemeinsame Kernsubstanz haben. Für das vorliegende Modul soll folgende Definition eines Projekts gelten: „Ein Projekt 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 (angelehnt an PRINCE2). Es ist somit eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wurde, bestimmte Ergebnisse beziehungsweise Produkte in Übereinstimmung mit einem übergeordneten Nutzenziel zu erbringen (angelehnt an IPMA ICB). Ein Projekt ist im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet (angelehnt an DIN 69 901).“ Damit sind auch gleich einmal einige wichtige Organisationen genannt, die sich mit der Standardisierung von Projektmanagement befassen: Die International Project Management Association ist ein internationaler PM- Verband, der in Europa entstanden ist. Die deutsche Landesgesellschaft ist die GPM Deutsche Gesellschaft für Projektmanagement. Das Standardwerk ist die IPMA Competence Baseline , ICB, das Kompetenzen für erfolgreiches PM definiert, die auch zur Zertifizierung dienen. Das Project Management Institute ist weltweit der größte PM-Verband und wurde in den USA gegründet. Das Chapter Germany vertritt das PMI in Deutschland. Der PM BoK Guide , Project Management Body of Knowledge, ist das Standardwerk des PMI. Dieser hat einen starken Fokus auf Prozessen. In Deutschland existiert mit der DIN 69 900 bzw. der 69 901 er Reihe eine Sammlung von Normen zum PM. Das internationale Pendant ist die ISO 21 500. Die Normen zum PM dienen z.B. vor allem zur einheitlichen Begriffsverwendung. AXELOS ist das Unternehmen, dass mittelweile den britischen Standard PRINCE2 herausbringt. Dieser wurde ursprünglich für IT- Projekte von der britischen Regierung entwickelt. Im Fokus stehen Grundprinzipien, Themen und Prozesse, die auch projektneutral eingesetzt werden können. Wir kommen später darauf zurück. <?page no="18"?> 18 Takt 1: Projekt-Setup Aus der Definition für Projekte ergibt sich unmittelbar deren typische Charakteristik, die sich mit typischen Merkmalen erfassen lässt: Abbildung 2: Charakteristik von Projekten ▲ Handelt es sich um Projekte? „In diesem Projekt sollen bis Mitte nächsten Jahres neue unternehmenseinheitliche IT-Arbeitsplätze eingeführt werden. Mit dem Projekt soll erreicht werden, dass alle Mitarbeiter bequem, einfach und sicher Daten, Informationen und Dokumente austauschen können.“ → Projekt, denn Ziel und Zeit vorgegeben (andere Begrenzungen fehlen). „In diesem Projekt geht es darum, zusätzliche Kunden zu gewinnen. Dafür werden wir die Mitarbeiter im Vertrieb schulen. Und unsere Produkte besser präsentieren.“ → Kein Projekt, da keine Einmaligkeit der Bedingungen (Regelaktivität). „Ziel des Projekts ist die Verbesserung der Mitarbeiterzufriedenheit. Dazu werden wir in den nächsten 2 Monaten eine Befragung durchführen. Aus den Ergebnissen werden wir konkrete Maßnahmen ableiten und diese in Unterprojekten umsetzen. Das Projekt wird dann mit einer weiteren Befragung der Mitarbeiter/ innen nach einem Jahr abgeschlossen.“ → Projekt, da Ziel und Zeit genau vorgegeben (beste Abgrenzung) ▲ Analysieren Sie doch einmal ein Vorhaben, das aktuell bei Ihnen „auf dem Tisch liegt“ oder an dem Sie beteiligt sind. Wie viele der in der Checkliste enthaltenen Fragen können Sie mit „ja“ beantworten? ▼ Checkliste [Projekt] Eng verbunden mit der Definition und Charakteristik von Projekten ist die Definition von Projektmanagement: „Projektmanagement (PM) ist die Anwendung von Wissen, Fertigkeiten, Werkzeugen und Methoden auf Projektvorgänge, um die Projektanforderungen zu erfüllen. PM ist ein disziplinierter Prozess zur Identifikation, Koordination und kontinuierlichen Bündelung von Ressourcen (Personen, Material, Fähigkeiten etc.) Aus der Projektdefinition ergeben sich typische Charakteristiken von Projekten: Zielsetzung - üblicherweise ein eindeutig definiertes Endziel Kompliziertheit - organisatorische und technische Elemente aus mehreren Bereichen Einmaligkeit - keine exakte Wiederholung von Dagewesenem Unsicherheit - charakterisiert durch unvollständige Information und unbestimmte Entwicklungen Befristung - am Projektende werden die Aktivitäten geschlossen Lebenszyklus - ein Projekt hat unterschiedliche Phasen und ein definiertes Ende Planung - wirtschaftliche und fachliche Rahmenbedingungen, Disposition, Design <?page no="19"?> 1.2 Definitionen 19 zur Erfüllung von Projekt-/ Vertragszielen innerhalb von - Zeit-, Kosten-, Ressourcen- und Qualitätsbeschränkungen.“ (nach PMI) Der Abschluss eines Projektes ist gleichzusetzen mit dem Erreichen des Projektziels. Dabei steht das Zusammenspiel zwischen Organisation, Mensch und Methoden und dem Projektumfeld im Vordergrund. Abbildung 3: Einordnung Projektmanagement Zu den unmittelbaren Aufgaben des PM gehören demzufolge allgemein gesprochen: Abbildung 4: Aufgaben des Projektmanagements Die Aufgaben des PM werden im Abschnitt zum Unified Project Management Framework, UPMF, systematisch aufgefächert. Projektmanagement erfolgt durch entsprechende Prozesse, welche Eingangswerte (Inputs) erhalten und Ausgangswerte (Outputs) erzeugen. Das generelle Konzept, das der Interaktion zwischen den PM-Prozessen zugrunde liegt, ist der Deming-Kreis bzw. PDCA-Zyklus „Plan-Do- Check-Act“, d.h. „Planen - Ausführen - Prüfen - Handeln“. <?page no="20"?> 20 Takt 1: Projekt-Setup Die verschiedenen PM-Frameworks definieren abweichende PM-Prozesse, in deren Synthese folgende 4 PM-Prozesse zu identifizieren sind: Abbildung 5: Projektmanagement-Prozesse Eng verbunden mit dem Begriff bzw. Konstrukt des Projekts sind die Begriffe Projektportfolio und Projektprogramm, die abschließend in diesem Abschnitt ebenfalls definiert werden sollen (nach DIN 69 909 sowie Seidl, 2011). Definitionen im Multiprojektmanagement Projektportfolio 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. 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. Das Projektportfolio orientiert sich an der übergeordneten Zielsetzung und initiiert Projekte und Programme. Begrenzte Ressourcen erfordern eine zielorientierte Auswahl und eine fortlaufende Priorisierung der Projekte und Programme. Portfolio-Management ist die strategische Ausrichtung, Planung, Steuerung und Anpassung aller Projekte innerhalb einer Organisation. Definition „Programm“ Ein Programm ist definiert als eine Menge zusammenhängender Projekte und organisatorischer Veränderungsprozesse, die mit dem Ziel aufgesetzt wurden, eine strategische Zielsetzung zu erreichen und einen erwarteten Nutzen für die Organisation zu erreichen. Die Projekte eines Programms liefern jeweils autark verwendbare Ergebnisse, deren Gesamtnutzen aber erst im Zusammenwirken erzielt werden kann. Ein Programm ist ein Multi-Projekt und weist typische Projektcharakteristika auf, wie zeitliche Befristung, definierte Zielsetzung, definiertes Budget sowie in besonderem Maße hohe fachliche und organisatorische Komplexität. Programm-Management ist die Koordination und das Management voneinander inhaltlich abhängiger Projekte zur Sicherstellung der effizienten Durchführung dieser Projekte.“ Programme und Portfolien sind also Multiprojektlandschaften , die nach unterschiedlichen Kriterien gebildet werden und die ein differenziertes Management erfordern. Ein Projektportfolio kann Teilportfolien (z.B. die Menge aller IT-Projekte) enthalten, Programme (z.B. zur Digitalen Transformation der Organisation) sowie einzelne Projekte (z.B. die Migration auf ein neues Betriebssystem). Idee Auftrag Plan Fortschritt Ergebnis Initiierung & Vorbereitung Ausplanung & Operationalisierung Überwachung & Steuerung Überleitung & Abschluss Rücksprung/ Wiederholung <?page no="21"?> 1.3 Überblick Projektvorbereitung 21 1.3 Überblick Projektvorbereitung Bevor ein Projekt gestartet wird, sind einige Dinge zu analysieren, zu klären, zu erarbeiten und festzulegen. Diese Elemente werden wir im Laufe des folgenden Modulabschnitts näher kennenlernen. Doch schauen wir zunächst mal auf die typischen Aktivitäten in der der Übersicht. Von vielen Begriffen werden Sie eine intuitive Vorstellung haben und haben vermutlich auch schon damit gearbeitet: ► Projektziele definieren ► Prüfung, ob Projekt vorliegt ► Vorhandene Erfahrungen zu Prozessen, Prozeduren und vergangenen Projekten erfassen ► Business Case erstellen, inkl. Wirtschaftlichkeitsbetrachtung ► Projektbegründung & Annahmen dokumentieren ► Auftraggeber und Projektmanager definieren ► PM-Team & Kernteam benennen ► Projektlösungsansatz auswählen ► Machbarkeitsbewertung ► Projektbeschreibung zusammenstellen ► Projektauftrag erstellen ► Beschreibung des Inhalts und Umfangs ► Anforderungen an Lieferungen & Leistungen definieren ► Unternehmenskultur und -systeme identifizieren ► Identifikation der wichtigsten Stakeholder und ihrer Erwartungen ► Projektumfeld- und Stakeholder-Analyse ► Benötigte Hauptmeilensteine festlegen ► Begrenzungen (Kosten, Zeit, Ressourcen …) dokumentieren ► Projektcharakteristik analysieren und -strategie festlegen ► (grobe) Aufwandsschätzung und Planung erstellen Schauen Sie sich zur Erläuterung der Aktivitäten gerne das verfügbare Video an. ► Video 1.2 (Projektvorbereitung), URL: https: / / youtu.be/ cwXXi5FLjsI Im Sinne einer kontinuierlichen Weiterentwicklung der Themen im Lebenszyklus eines Projekts, werden viele dieser Themen aber auch immer wieder aufgegriffen, überprüft, ggf. weiterentwickelt und detailliert. 1.4 Das Projektumfeld 1.4.1 Umfeldanalyse Das Projektumfeld beeinflusst das Projekt und wird seinerseits vom Projekt beeinflusst, wie in Abbildung 6 dargestellt. Es ist die Umgebung, in der das Projekt formuliert, bewertet und durchgeführt wird, die das Projekt direkt oder indirekt beeinflusst und die ggf. von dessen Auswirkungen betroffen ist. Ziele der Projektumfeldanalyse ist die Identifikation und Bewertung der wichtigsten Einflussfaktoren auf das Projekt. <?page no="22"?> 22 Takt 1: Projekt-Setup Abbildung 6: Das Projektumfeld Die Projektumfeldfaktoren lassen sich wie folgt klassifizieren: − internes Umfeld: innerhalb der Unternehmensorganisation − externes Umfeld: außerhalb der Unternehmensorganisation − Sachfaktoren: natürliches Umfeld / technisches Umfeld / ökonomisches Umfeld − Sozialfaktoren: rechtlich-politisches Umfeld / soziokulturelles Umfeld Die folgende Matrix ordnet typische Umfeldfaktoren nach dieser Klassifizierung ein: Abbildung 7: Klassifizierung der Projektumfeldfaktoren Sachlich-interne Projektumfeldfaktoren umfassen z.B. die vorhandenen Richtlinien, die einzuhalten sind. Nicht zuletzt die sachlich-externen Projektumfeldfaktoren haben einen hohen Einfluss auf den Projekterfolg. Für ein IT-Projekt ergibt sich daraus oftmals folgende konkrete Ausgestaltung (Abb. 8): 4 ▲ Ordnen Sie die IT-projekttypischen Begriffe den Feldern zu. 4 Wehnes, 2014 <?page no="23"?> 1.4 Das Projektumfeld 23 Abbildung 8: Klassifizierung der Projektumfeldfaktoren (Template) ▲ Passen diese Einflussfaktoren in das Umfeld Ihrer Projekte in Ihrem Unternehmen? Finden Sie ggf. weitere, die Sie in der Matrix verorten können? Die wichtigsten sachlichen Projektumfeldfaktoren werden in einem Umfeldregister dargestellt: Beispiel 5 Abbildung 9: Umfeldregister (Beispiel) ▲ Tragen Sie doch einmal 2…3 Faktoren aus Ihrem Umfeld in ein solches Register ein: Abbildung 10: Umfeldregister (Template) In der Umfeldanalyse werden insbesondere die „interessierten Parteien“, also die Stakeholder des Projektes betrachtet. Wenden wir ihnen uns einmal etwas detaillierter zu. 5 Wehnes, 2014 Arbeitszeitregelung Auftraggeber Bundesdatenschutzgesetz Datenschutzbeauftragter Entwicklungsabteilung Geschäftsführung Hardwarelieferant Kundenspezifische Randbedingungen (z.B. Tests in der Vorproduktionsumgebung) Nutzer des SW- Produktes PM-Handbuch Richtlinien SW- Entwicklung Sachlicher Projektumfeldfaktor Beschreibung Maßnahme <?page no="24"?> 24 Takt 1: Projekt-Setup 1.4.2 Stakeholder-Management 1.4.2.1 Begriff Der Begriff „Stakeholder“ bezeichnet jemanden, der ein Interesse an einer Sache hat (engl.: „to have a stake in s.th.“). Stakeholder sind also im allgemeinen Personen oder Institutionen, die ein begründetes Interesse am Verlauf oder am Projekterfolg und am Nutzen für das Projektumfeld haben. Es gibt Stakeholder, die positiv oder negativ zu dem Projekt eingestellt sind. Bei der Stakeholder-Analyse geht es darum, die einzelnen Personen oder Personengruppen zu identifizieren und die Risiken und Chancen darzustellen und zu bewerten, die von diesen Personengruppen ausgehen. Ausgehend von diesen Ergebnissen können Maßnahmen für eine Stakeholder-Politik abgeleitet werden. Projektbefürworter und -gegner werden ermittelt, ihr Einfluss gewertet und der nötige Maßnahmenkatalog erstellt. Stakeholder können in externe und interne Stakeholder klassifiziert werden, z.B.: interne Stakeholder externe Stakeholder • Vorstand • Anteilseigner • Mitarbeiter • Betriebsrat • Projektleitung/ Projektgremium • Abteilungsleiter • … • Lieferanten • Kunden • Behörden • Vereine • Verbände • Gewerkschaften • Anwohner • Politik • … ▲ Wer sind die typischen Stakeholder für Ihre (IT-) Projekte? ��� Achtung: Es gibt ggf. auch Personen oder Personengruppen, die es als Erfolg oder Nutzen ansehen, das Projekt zum Scheitern zu bringen! Stakeholder beeinflussen das Projekt! Folgende Beispiele verdeutlichen die Relevanz für eine Analyse der Stakeholder: • Eine Umweltorganisation versucht mit allen zur Verfügung stehenden Mitteln den Bau des projektierten Rechenzentrums „auf der freien Wiese“ zu verhindern. • Der bisherige Marktführer und Wettbewerber xy wird versuchen, das aufstrebende Start-up mit Dumpingpreisen an der Inmarktbringung der neuen Produktlinie zu hindern. • Das neue Bürogebäude soll auf einer ehemals historischen Stätte errichtet werden. Denkmalschützer und Bürgerinitiativen wollen dies verhindern. • Ein Mitarbeiter wird durch die geplante Umstrukturierung der IT-Abteilung einige Rechte verlieren. z.B. wird er wird nicht mehr in der Nähe parken können (persönliche Rechte wiegen oft besonders schwer! ). • Durch den Bau des neuen Bürogebäudes werden einige Mitarbeiter weiter fahren müssen. Bei diesen Mitarbeitern sind auch einige Hauptabteilungsleiter, die dies nicht wollen. <?page no="25"?> 1.4 Das Projektumfeld 25 Risiken, die von Stakeholdern ausgehen können: interne Stakeholder externe Stakeholder • Emotionale Erwartungen und Einstellungen werden nicht offen ausgesprochen • Projektwiderstände werden nur verdeckt ausgeübt • Entscheidungsträger fehlen in wichtigen Sitzungen • Unmotivierte und leistungsschwache Mitarbeiter werden in das Projekt „abkommandiert“ • Dienst nach Vorschrift • Wertvolle Zeit wird in Sitzungen durch endlose Diskussionen über unwichtige Details vergeudet • Gute Vorschläge werden zerredet • … • Die Bevölkerung wehrt sich mit Demonstrationen gegen das Abholzen der Bäume, um den nötigen Baugrund frei zu machen • Der externe Auftraggeber verfügt nicht mehr über die nötige Kapitaldecke • Die Behörden verlangen höhere Auflagen als erwartet • … 1.4.2.2 Stakeholder-Management-Prozess Ziel des Stakeholder Managements ist es alle Stakeholder mit ihren Interessen, Einstellungen und Einflussmöglichkeiten zu kennen … und daraus geeignete Maßnahmen zur Akzeptanz des Projekts ableiten. Stakeholder-Management heißt, Stakeholder zu … Abbildung 11: Stakeholder-Management-Prozess Folgende Aktivitäten/ Aufgaben sind damit verbunden: ► Ermittlung der Anforderungen und Erwartungen der Stakeholder. ► Berücksichtigung dieser Anforderungen bei der Zielsetzung, Projektplanung und -durchführung. ► Entwicklung von Strategien und Maßnahmen. ► (Pro-)Aktive Betreuung der Projekt-Stakeholder, insbesondere der einflussstarken Entscheider. ► Steuern und Überwachen der Stakeholder-Maßnahmen. 1.4.2.3 Stakeholder-Identifikation Die Stakeholder-Identifikation ist „der Prozess zur Ermittlung aller Personen und Organisationen, auf die sich das Projekt auswirkt, sowie die Dokumentation entsprechender Informationen bezüglich ihrer Interessen, Beteiligung und Auswirkung auf den Projekterfolg“ (nach PMI). Vorgehen: Workshop durchführen mit folgenden Kernfragen: - Welche Prozesse werden durch das Projekt wesentlich verändert? - Welcher Personenkreis ist durch das Projekt betroffen? - Wer muss bzw. sollte am Projekt beteiligt werden? <?page no="26"?> 26 Takt 1: Projekt-Setup - Wer könnte das Projekt - mit welchen Erwartungen - unterstützen? - Wer könnte Widerstände (Ängste, Befürchtungen) gegen das Projekt haben? - Wer könnte noch Informationen für das Projekt liefern? - Wer arbeitet an ähnlichen Themen? Ergebnis ist eine Stakeholder-Liste. 1.4.2.4 Stakeholder-Analyse Die Analyse der Projektbeteiligten hinsichtlich deren Einfluss auf das Projekt und deren Einstellungen (positiv oder negativ) zum Projekt wird als Stakeholder-Analyse bezeichnet. Vorgehen - Ausgangsbasis: Stakeholder-Liste - Analyse für jeden Stakeholder: • Einstellung zum Projekt: positiv (+), neutral (o), negativ (-) • Erwartungen/ Unterstützung (+) bzw. Befürchtungen/ Widerstände (-) • Betroffenheit: hoch, mittel, gering • Macht/ Einfluss auf das Projekt: hoch, mittel, gering Projektverantwortliche sollten sich dabei in die Situation der Stakeholder versetzen. Ergebnis ist das Stakeholder-Register (Interessenmatrix): Abbildung 12: Stakeholder-Register Probleme bei der Stakeholder-Analyse - Das Verhalten der Stakeholder oft nicht leicht vorhersehbar. - Die Stakeholder-Analyse ist immer nur eine Momentaufnahme! • Es können im Projektverlauf Stakeholder(gruppen) entstehen, an die bei Projektstart noch nicht absehbar waren. • Es kann eine gewisse Dynamik in der Stakeholder-Landschaft geben. Aus dem Stakeholder-Register lässt sich unmittelbar ein Stakeholder-Portfolio zur visuellen Darstellung der Analyse ableiten (siehe Abbildung 13). <?page no="27"?> 1.4 Das Projektumfeld 27 Abbildung 13: Stakeholder-Portfolio ��� Das Register sowie das Portfolio wird im Regelfall nicht veröffentlicht, sondern verbleibt beim Projektmanager! 1.4.2.5 Normstrategien Das Stakeholder Management umfasst weiterhin die Strategie und die Maßnahmen , die für den individuellen Stakeholder vorgesehen sind. Mit Hilfe der Stakeholder-Analyse können typische Normstrategien zur Ableitung von Maßnahmen genutzt werden. Nach PMI sehen diese wie folgt aus: Abbildung 14: Stakeholder Management-Strategie ��� Stakeholder und deren Interessen sind über den Projektverlauf nicht konstant und müssen daher kontinuierlich identifiziert/ beobachtet werden! Die Maßnahmen werden daher mit den Vokabeln „wöchentlich“, „ständig“, „regelmäßig“ etc. begleitet. Dies unterstreicht die Wichtigkeit des kontinuierlichen Kontakts, um die Stakeholder positiv zu beeinflussen, mögliche negative Einflüsse früh zu erkennen und gegensteuern zu können. Maßnahmenplanung Ziele der Maßnahmen sind die Verringerung von Widerständen (Ängste, Befürchtungen) bzw. die Verstärkung der Unterstützung. Dabei können grundsätzlich folgende Formen angewendet werden: Partizipativ: Stakeholder als Partner behandeln - Beteiligung im Lenkungsausschuss/ Mitentscheidung - Beteiligung Projekt/ Mitarbeit Einfluss auf das Projekt hoch niedrig Einstellung zum Projekt negativ positiv Betriebsrat Behörden Mitarbeiter Vorstand Kunden Lieferanten Umliegender Einzelhandel/ Restaurants Anwohner Einfluss hoch gering gering hoch Interesse zufriedenstellen eng betreuen beobachten (minimaler Aufwand) informiert halten <?page no="28"?> 28 Takt 1: Projekt-Setup Diskursiv: Stakeholder informieren - Information/ Kommunikation - Ausgleich der verschiedenen Stakeholder-Interessen durch Verhandlungen und Konfliktmanagement Repressiv: Auf Stakeholder Druck ausüben ethisch i.A. nicht vertretbar! ▲ Finden Sie eine repressive Form der Stakeholder-Beeinflussung, die gar nicht so selten vorkommt? Ggf. sind Kombination der Strategien für einzelne Stakeholder angebracht. Das Stakeholder-Register wird um Maßnahmen ergänzt: Maßnahmen zur Verringerung der Widerstände Maßnahmen zur Stärkung der Förderer (z.B. Abbau von Ängsten und Befürchtungen) • Win-Win-Situationen anstreben • Pro-Kontra-Argumente herausarbeiten • „Botschaften“ für Zielgruppen erarbeiten • Vertrauensbasis schaffen • ehrliche und klare Kommunikation • evtl. Partizipation in der Projektarbeit • … • lückenlose Information der Förderer • persönlichen Draht aufbauen • Einbeziehung von Meinungsbildnern und Multiplikatoren • … ▲ Finden Sie mögliche Maßnahmen in der Stakeholder-Politik? Sonst schauen Sie doch mal in folgenden Auszug eines vollständigen Stakeholder-Registers: 6 Abbildung 15: Stakeholder-Register 6 Schelle et al., 2008 Stakeholdergruppe Klima/ Stimmung Bedeutung/ Macht Erwartungen (+)/ Befürchtungen (−) Maßnahmen +/ o/ − Geschäftsführung + 5 + Wöchentliche Statusberichte Vier-Augen-Gspräche Projektleiter + 3 + Projektteam + 3 + Statusmeetings, Kummerkasten Gemeinsame Unternehmungen etc. Vom Projekt betroffene Abteilungen +/ − 4 +/ − Regelmäßige Kommunikation Betriebsrat − 4 − Statusberichte nach Berichtsplan Vier-Augen-Gspräche Kunden in verschiedenen Rollen - Auftraggeber - Nutzer - Vertreter des Kunden im Team etc. +++ 433 +++ Statusberichte nach Berichtsplan Regelmäßiger persönlicher Kontakt … + 2 + Regelmäßige … 1−5 (sehr niedrig − sehr hoch) <?page no="29"?> 1.4 Das Projektumfeld 29 Wie schon erwähnt, darf es nicht bei einer einmaligen Analyse der Stakeholder-Situation bleiben (auch wenn das auf jeden Fall bereits ein guter Schritt und besser als nichts ist). Der vollständige Stakeholder-Management-Prozess folgt der bekannten „Plan → Do → Check → Act“-Systematik: Abbildung 16: Der Stakeholder-Management-Prozess Wichtige Controlling-Fragen sind dabei: 1. Gibt es neue Stakeholder? 2. Waren die durchgeführten Maßnahmen erfolgreich? 3. Haben sich bisherige Stakeholder-Positionen wesentlich verändert? 4. Welche neuen Maßnahmen sind zu veranlassen? Im Rahmen der Projektvorbereitung wird das Stakeholder-Management natürlich noch nicht in Gänze durchgeführt. Vielmehr geht es zu diesem Zeitpunkt darum, die Stakeholder (erstmalig) zu identifizieren und zu analysieren und auf Basis dieser Erkenntnisse ggf. bereits in die Gestaltung des Projektauftrags und in frühe Kommunikationsmaßnahmen einzubeziehen. Im weiteren Verlauf des Projekts erfolgt dann der systematische Schluss des genannten Regelkreises durch Ausführung aller Maßnahmen und fortlaufendes Controlling. Gleichwohl ist im oftmals festzustellen, dass die Stakeholder-Situation nicht so volatil ist, dass es hier ständig einer Veränderung bedarf oder veränderter Erkenntnisse erscheinen. Eine weitere wichtige Disziplin des Projektmanagements, mit der man auch bereits in der Projektvorbereitung beginnt, ist das Risikomanagement. Auch hier ist es angebracht, bereits in der Vorbereitungsphase die (grundsätzlichen, strategischen) Risiken zu identifizieren und entsprechen der Bewertung Konsequenzen, nicht zuletzt Maßnahmen zur Handhabung der Risiken, im Projekt-Design einzuplanen. Die Praxis zeigt, dass das Management der Risiken eine zentrale Aufgabe insbesondere auch im Verlauf des Projekts ist, da sich die Risiken ändern und entwickeln. Daher gehen wir erst zu einem späteren Zeitpunkt im Verlauf des Moduls, dass sich ja grob am Lebenszyklus eines Projekts orientiert, detaillierter ein. Schauen wir an dieser Stelle zunächst etwas genauer auf die Erfolgsfaktoren eines (IT-)Projektes. 1. Identifikation 2. Analyse 3. Maßnahmenplanung 4. Controlling 0. Stakeholdermanagementplanung <?page no="30"?> 30 Takt 1: Projekt-Setup 1.4.3 Lösungen ▲ Handelt es sich um Projekte? 1. Projekt, denn Ziel und Zeit vorgegeben (andere Begrenzungen fehlen). 2. Kein Projekt, da keine Einmaligkeit der Bedingungen (Regelaktivität). 3. Projekt, da Ziel und Zeit genau vorgegeben (beste Abgrenzung) ▲ Ordnen Sie die IT-Projekt-typischen Begriffe den Feldern zu. Abbildung 17: Projektumfeldanalyse (Beispiel IT-Projekt) ▲ Finden Sie eine repressive Form der Stakeholder-Beeinflussung, die gar nicht so selten vorkommt? Z.B. juristische Schritte wie Unterlassungsklage oder vertragliche Vereinbarungen wie Malus-Regelung. 1.5 Projektauftrag 1.5.1 Vom Antrag zum Auftrag Das Vorgehen zur Initiierung eines Projektes sollte stets über einen formal genehmigten Projektantrag erfolgen. Andernfalls sind Konflikte vorprogrammiert, da bei informell gestarteten Projekten in der Regel die Auswirkungen, Abhängigkeiten, Ziele, Ressourcen etc. nicht klar bestimmt und auch gegenüber anderen Maßnahmen im Unternehmen nicht abgegrenzt sind. Im Idealfall wird aus dem Projektantrag gleichsam 1-zu-1 der Projektauftrag - in der Praxis gibt es typischerweise einen Prozess zur Feinjustierung des Projektauftrags, der mehr oder wenige umfangreich sein kann. Folgenden Aktivitäten können für die Prozesse der Projektbeantragung und Projektbeauftragung identifiziert werden: <?page no="31"?> 1.5 Projektauftrag 31 1) Projektbeantragung 2) Projektbeauftragung ► Projektziele definieren ► Projektumfeldanalyse mit Interessenmatrix ► Aufbau der Projekt-Organisation:  Leiter, Team, Teilprojekte? Kernteam? Lenkungsausschuss? ► Grobplanung erstellen:  Phasen und Meilensteine  Erforderliche Ressourcen → Projekt- Budget  Aufwände/ Nutzen, Wirtschaftlichkeit  grobe Terminplanung  Projektrisiken  Qualitätsplanung  Kommunikationsplanung ► Ziele und Inhalte werden zwischen Auftraggeber (z.B. Vorstand oder Verantwortlicher eines Geschäftsbereichs) und Auftragnehmer (Projektleiter) abgestimmt. ► Projektantrag geht zur Genehmigung an „Priorisierungsgremium“. Nach Zustimmung zum Projektantrag und Freigabe der Mittel/ Ressourcen wird dieser zum Projektauftrag. ► Unterzeichnung durch Auftraggeber und Auftragnehmer (= Projektleiter). Der Projektauftrag ist die vertragliche Basis des Projekts. Der Prozess der Projektbeantragung umfasst im Rahmen der Projektvorbereitung das Verfassen eines Dokuments, mit dem ein Projekt (oder eine Projektphase) formell genehmigt wird und enthält die Dokumentation der Anfangsanforderungen, mit denen die Bedürfnisse und Erwartungen der Stakeholder − insbesondere Auftraggeber − erfüllt werden: Abbildung 18: Prozess der Projektbeantragung Der Ablauf von Kundenprojekten (extern) und internen Projekten ist dabei in gewisser Weise gleich. Natürlich sind die zu erstellenden Dokumente im Detail unterschiedlich - am Ende sollte jedoch immer ein formeller Projektauftrag stehen. Im Falle des externen Projektes hat dieser Vertragscharakter und es gelten die entsprechenden gesetzlichen Rahmenbedingungen, z.B. des BGB. Auch der interne Projektauftrag hat gewissermaßen Vertragscharakter, denn er definiert den Handlungsspielraum der Projektleitung und ist auch Verpflichtung für den Projektauftraggeber. 1.5.2 Ziele Eine von Lechler gemachte Metaanalyse von 5.700 Projekten in 44 Studien hat die wichtigsten Erfolgsfaktoren von Projekten identifiziert. 7 Die Definition der Projektziele steht dabei an erster 7 zitiert nach Schelle et al., 2008, S. 93 <?page no="32"?> 32 Takt 1: Projekt-Setup Stelle, im Grunde gemeinsam mit der Kommunikation im Projekt und darüber hinaus. Lassen Sie uns zunächst auf das Thema „Ziele“ schauen, denn die Zieldefinition sollte natürlich im Kontext der Projektbeauftragung erfolgen. ��� Projekte brauchen Ziele! Ein Ziel ist ein geistig vorweggenommener zukünftiger Zustand. Definition Projektziel (DIN 69901-5: 2009) Projektziel ist die „Gesamtheit von Einzelzielen, die durch das Projekt erreicht werden sollen, bezogen auf Projektgegenstand und Projektablauf.“ Die Zieldefinition ist die „quantitative und qualitative Festlegung des Projektinhalts und der einzuhaltenden Realisierungsbedingungen, z.B. Kosten und Dauer, in Zielmerkmalen mit meist unterschiedlichen Zielgewichten (z.B. Muss- und Kann-Ziele).“ ��� Eine Zielformulierung sollte immer schriftlich erfolgen. Ein Gedanke, der nicht aufgeschrieben werden kann, ist nicht zu Ende gedacht. Schauen Sie im vorliegenden Video eine Einführung zum Thema „Ziele“. ► Video 1.3 (Ziele), URL: https: / / youtu.be/ 2WxWg3Lx-_8 Gutes Projektmanagement hat als übergeordnetes Ziel die Zufriedenheit der Stakeholder, insbes. des Auftraggebers. Dazu später mehr. Ziele im „Magischen Dreieck“ Bei Projekt(abwicklungs)zielen lassen sich drei Dimensionen unterscheiden: Diese drei Dimensionen bilden das klassische Magische Dreieck des Projektmanagements und fokussieren besonders die Ziele der operativen Abwicklung des Projektes. Die folgende Abbildung zeigt zudem, welche Teilziele typischerweise in der jeweiligen Dimension subsummiert werden können. Die „Magie“ liegt darin, dass in der Regel eine Dimension nicht verändert werden kann, ohne zumindest eine andere zu beeinflussen: In der Regel hat die Veränderung eines Ziels Auswirkungen auf ein (Teil-)Ziel einer anderen „Ecke“. Verschieben sich beispielsweise Termine nach hinten, hat dies z.B. wegen der damit verbundenen Mehrarbeit Auswirkungen auf die Kostensituation. Unsicherheiten und Risiken, die Projekten ja immanent sind, bewirken schlussendlich ein Engerziehen oder Ausweiten der Dimensionen des Dreiecks. Soll z.B. die Bearbeitungszeit verkürzt werden, indem Wochenendarbeit durchgeführt wird, wird dies üblicherweise aufgrund von Wochenendzuschlägen oder ganz einfach ungeplanter Zusatzarbeit das Projekt teurer machen. <?page no="33"?> 1.5 Projektauftrag 33 Abbildung 19: Ziele im Magischen Dreieck 8 Beispiele Leistung zu Kosten Kosten zu Terminen Termine zu Leistung Da die Kosten bei einem Projekt „aus dem Ruder laufen“, werden Leistungen gekürzt. Auf eine ursprünglich geplante automatisierte Schnittstelle wird verzichtet. Der Termindruck kurz vor geplanten Produktivstart in einem Projekt erfordert Wochenendarbeit in der Entwicklung sowie Überstunden. Die Aufschläge für die Mehrarbeit erhöhen die Kosten. Die Anforderungen des Auftraggebers sind gestiegen. Anstatt klassischer Desktop- PC sollen die Anwender nun durchgängig mit portablen Laptops ausgestattet werden. ▲ Finden Sie weitere Beispiele für Abhängigkeiten bzw. Auswirkungen? Messbarkeit der Ziele Ziele sollten quantitativ messbar sein, damit am Ende des Projektes eine objektive Überprüfung stattfinden kann, ob das Projekt „erfolgreich“ war. Dazu folgende eingängige Beispiele: 8 Schelle et al., 2008 Erwartungen der Auftraggeber  Die Spezifikationen sind erfüllt oder übererfüllt  Die Terminvorgaben sind erreicht oder unterschritten  Die geplanten Kosten wurden eingehalten oder unterschritten Zieldimension „Leistung“ mit dem Auftraggeber verbindlich vereinbarter Inhalt und Umfang der Leistung aus Produktsicht: • Funktionsziele • Wirkziele • Fertigungs- & Qualitätsziele • Auslegungsziele • Betriebsziele Zieldimension „Kosten“ in der Regel vor Projektbeginn budgetiert: • Personalkosten • Sachkosten • Investitionen • Kosten für Leistungen Dritter • … Zieldimension „Termine“ vor Projektbeginn verbindlich vereinbart: • Start- & Endtermine • Quality-Gate- Termine • Meilensteintermine • Berichtstermine • Abnahmetermine <?page no="34"?> 34 Takt 1: Projekt-Setup Abbildung 20: Messbarkeit der Ziele Etwas überspitzt gesagt, lässt sich postulieren: „Miss es − oder vergiss es! “ Natürlich wird dies - das Messbarmachen von Projektergebnissen - in der Praxis nicht immer funktionieren oder in einer sinnvollen Aufwands-Nutzen-Relation stehen. Aber zumindest als anstrebenswerter Zustand sollte es immer im Hinterkopf sein bei der Formulierung von Zielen. Merkmale gut formulierter Ziele Bei der Definition und Formulierung von Projektzielen sind folgende Merkmale zu berücksichtigen, um Missverständnisse zu vermeiden sowie im Projektverlauf und beim Projektabschluss den Zielerreichungsgrad genau bestimmen zu können. Folgende Merkmale gut formulierter Projektziele haben sich etabliert: Abbildung 21: Merkmale gut formulierter Ziele ▲ Überlegen Sie sich doch einmal je ein Beispiel für ein Merkmal. Finden Sie Beispiele aus realen Projekten in Ihrer Organisation? Oder entdecken Sie diesbzgl. eher Lücken? Falsche Zieldefinition Richtige Zieldefinition Die Rationalisierung der Büro-Organisation ist abgeschlossen. Durch die neue Büro-Organisation werden 4.000 €/ Monat eingespart. Die Anwender sind mit dem neuen Programm zufrieden. Die Anwender haben das Programm in einer Zufriedenheitsumfrage mindestens mit der Note „gut“ bewertet. Die Fehlerhäufigkeit wird deutlich verringert. Die Fehlerhäufigkeit wird von 42 Stk./ Monat auf 28 Stk./ Monat verringert. Die Durchlaufzeit wird erheblich verkürzt. Die Durchlaufzeit wird von bisher 6 Tagen auf zukünftig 4 Tage verkürzt. Akzeptiert ehrgeizig, aber Realistisch Terminiert konsistent lösungsneutral hochwertiger als Ist-Zustand Spezifisch Messbar Projektziele <?page no="35"?> 1.5 Projektauftrag 35 Vielleicht lassen Sie sich von folgenden Beispielen inspirieren: Beispiele  Eine detaillierte Rolloutplanung für die Einführung des SAP-Systems ist bis 31.05.2021 erstellt.  Budget von 3,15 Mio. Euro ist eingehalten.  Output-Lösungen für Textsysteme sind, soweit notwendig, angepasst und funktionsfähig.  Die im Vorprojekt ermittelten Anwendungen sind für die Materialwirtschaft bis 05.08.2021 und für Beschaffung bis 07.10.2021 angepasst und getestet.  Die Anwender sind bis 31.08.2021 in Office 2010 qualifiziert. Unterstützungsmaßnahmen sind eingerichtet. Abbildung 22: Zielfindung − Beispiele Zielhierarchie mit Muss-, Soll- & Kann-Zielen In der Regel wird es für ein Projekt mehr als ein Ziel geben. In dem Fall ist es sinnvoll, die Ziele zu klassifizieren und damit zu strukturieren. Neben der Einordnung in das Magische Dreieck hat sich eine Einteilung nach Muss-, Soll- und Kann-Zielen bewährt. Die (mehr oder weniger klare) Erreichung der Ziele impliziert schließlich, ob das Projekt diesbezüglich als Erfolg gewertet werden kann oder nicht. Ergänzt werden die Kosten-, Leistungs- und Terminziele oftmals um soziale Ziele, die beispielsweise die Belastung der Mitarbeiter thematisieren. Die folgende Abbildung 23 zeigt ein Beispiel. <?page no="36"?> 36 Takt 1: Projekt-Setup Abbildung 23: Zielhierarchie mit Muss-, Soll- & Kann-Zielen Eine alternative Darstellung, mit der man in der Praxis sehr gut arbeiten kann, ist in Form eines sogenannten Zielregisters, also einer Tabelle. Auch hier ein Beispiel aus einem IT-Projekt: 9 Abbildung 24: Zieltabelle mit Muss-, Soll- & Kann-Zielen Erkennen und Sammeln von Projektzielen Folgende Leitfragen haben sich im Findungsprozess für die Projektziele bewährt: - Was erwartet der Auftraggeber vom Projekt? - Was will der AG mit dem Projekt erreichen? 9 Wehnes, 2014 Projektziele T1 Projektstart erfolgt zum 02.01. T2 Fertigstellung Pflichtenheft zum 11.01. T3 Entwicklung der Anwendung abgeschlossen zum 05.04. T4 Anwenderumfrage ist erfolgt zum 30.05. K1 Einhaltung Budget von 255.000 € K2 Keine neuen Infrastrukturkosten L1 10 Tage vor Produktivsetzung keine produktivsetzungsverhindernden Fehler L2 Die Anwendung wurde nach internen Entwicklungsstandards programmiert L3 Die Software steht laut Kundenspezifikation aus dem Lastenheft zur Verfügung L4 Umfrageergebnisse sind gut, Durchschnittsnote ≤ 2,0 S1 Keine Überstunden bei den Projektmitarbeitern am Projektende Terminziele Kostenziele Leistungsziele Soziale Ziele Legende: Muss-Ziel Soll-Ziel Kann-Ziel Nr. Zielformulierung Klassifizierung Prio Messkriterium T1 Der Projektstart erfolgt wie geplant Terminziel Muss am 02.01. T2 Das Pflichtenheft ist fertiggestellt Terminziel Muss am 11.01. T3 Entwicklung der Anwendung abgeschlossen Terminziel Muss am 05.04. T4 Anwenderumfrage ist erfolgt Terminziel Kann bis zum 30.05. K1 Einhaltung Budget Kostenziel Muss 255.000 € K2 Keine neuen Infrastrukturkosten Kostenziel Soll 0 € L1 keine produktivsetzungsverhindernden Fehler Leistungsziel Muss 10 Tage vor Produktivsetzung L2 Anwendung nach internen Entwicklungsstandards programmiert Leistungsziel Soll Nach Code-Review am 30.04. alle Auffälligkeiten innerhalb 1 Woche beseitigt L4 Anwenderzufriedenheit ist hoch Leistungsziel Kann Durchschnittsnote Umfrageergebnisse ≤ 2,0 S1 Keine Überstunden bei den Projektmitarbeitern Soziales Ziel Kann Am Projektende sind alle Arbeitszeitkonten ausgeglichen <?page no="37"?> 1.5 Projektauftrag 37 - Was erwarten andere Personen von dem Projekt? o Mitarbeiter o Andere Abteilungen o Führungsmannschaft - Was denken die relevanten Führungskräfte über das Projekt? - Welche Ziele verbindet die eigene Organisation mit dem Projekt? o Generieren von Profit o Einstieg in ein neues Themengebiet o Einstieg bei einem neuen Kunden, ... - Was soll das Produkt/ die Dienstleistung können? - Welchen Nutzen hat der Anwender / der Kunde? - Was muss das Produkt / die Dienstleistung unbedingt können (Muss-Ziele)? - Wie lange darf das Projekt dauern? - Was darf das Projekt / die Produktentwicklung kosten? - Welches sind die kritischen Erfolgskriterien? - Woran kann man die Zielerreichung überprüfen/ messen? - Mit welcher Argumentation/ Erfahrung wurde der Auftrag gewonnen? Zielkreuz von Coverdale Da die Festlegung von Zielen für das Projekt von tiefgreifender Bedeutung für den späteren Erfolg ist, bietet es sich an, die Zieldefinition in Form eines Workshops mit dem Team, der Auftraggeberschaft und der Projektleitung zu machen - oder wenigstens Teilen dieser Beteiligten. Hier hat sich ein Canvas bewährt, mit dem strukturiert die einzelnen Ziele in einem kreativen Prozess entwickelt werden - das Zielkreuz von Coverdale: Abbildung 25: Zielkreuz nach Coverdale Die einzelnen Quadranten sprechen sicherlich in ihrer Bedeutung für sich. Es wird klar, dass auf diese Weise das Fundament einer Zielfestlegung noch einmal gestärkt wird, in dem stark auf den zugrundeliegenden Nutzen für den Kunden abgezielt wird. Dieses Canvas steht Ihnen als Tool zur Verfügung - gestalten Sie doch einmal ein beliebiges Ziel aus den vorherigen Überlegungen mit Hilfe des Zielkreuzes aus. ▼ Tool [Canvas „Zielkreuz“] Sinn/ Zweck („Wozu? ) Kunde („Für wen? “) Erfolgskriterium („Woran gemessen? “) Endergebnis („Was? “) Ziel <?page no="38"?> 38 Takt 1: Projekt-Setup Zielbeziehungen und -verträglichkeit Bei mehr als einem Ziel besteht die Gefahr, dass diese nicht „zueinander passen“ - dann müssen sie priorisiert oder ggf. sogar eliminiert werden. Insbesondere, wenn die Auftraggeberschaft nicht nur aus einer Person besteht, also z.B. mehrere Top-Manager Einfluss auf die Zielfestlegung nehmen, kann dies der Fall sein. Dann sollten die identifizierten Ziele einer Analyse hinsichtlich ihrer Verträglichkeit untereinander unterzogen werden, um nicht im späteren Verlauf (oder am Ende) des Projekts in Konflikte zu geraten. In dem Zusammenhang können folgende Zielbeziehungen identifiziert werden: Abbildung 26: Zielbeziehungen und -verträglichkeit ▲ Welche Maßnahmen (Normstrategien) sollte man anwenden? Ideen? (Sehen Sie die freien Felder bei den Lösungen am Ende des Kapitels nach.) Im Rahmen eines paarweisen Vergleichs der Ziele können die Zielbeziehungen somit verträglich, eindeutig und konfliktfrei gestaltet und priorisiert werden Nicht-Ziele Zur Abgrenzung des Projektumfangs (Scope) sollten auch die „Nicht-Ziele“ festgelegt werden: Was ist NICHT Bestandteil des Projekts? Diese Abgrenzung erhöht die Entscheidungssicherheit für alle Beteiligten. Sie schafft Klarheit und vermeidet unnötige Konflikte (aufgrund unausgesprochener Erwartungen). Beispiel für ein Nicht-Ziel: „Die wiederverwendbaren Module werden NICHT weiterentwickelt und auch NICHT gepflegt.“ ▲ Finden Sie weitere aus Ihrem Projektumfeld? Mittelbare und unmittelbare Ziele Eine fundierte Zielanalyse ist Voraussetzung zum Erkennen der wesentlichen Ziele. Erreichung der offiziellen Projektziele ist aber eine Bedingung für die weiteren Ziele. <?page no="39"?> 1.5 Projektauftrag 39 Beispiel Abbildung 27: Mittelbare und unmittelbare Ziele Die offiziellen Projektziele stellen also nicht zwingend das Hauptziel dar − oftmals ist dieses „höherwertiger“ bzw. strategischer: Abbildung 28: Fundierte Zielanalyse Prozess der Zielentwicklung Zusammenfassend ergibt sich folgende Vorgehen für das Erkennen, Formulieren, Bewerten, Priorisieren und Vereinbaren von Zielen vor Projektstart: 1. Ziele sammeln und formulieren 2. Ziele clustern bzw. priorisieren: Zieltabelle, Zielhierarchie 3. Gegenseitige Beeinflussung von Zielen analysieren und mögliche Zielkonflikte erkennen: Zielbeziehungsmatrix 4. Nicht-Ziele benennen 5. Ziele messbar machen 6. Ziele mit Team und Auftraggeber abstimmen 7. Ziele in den Projektantrag als Projektziele aufnehmen 8. Ggf. weitere Schärfung der Ziele vornehmen Bei größeren Projekten bietet sich ein Zieldefinitionsworkshop an. <?page no="40"?> 40 Takt 1: Projekt-Setup 1.5.3 Lösungen ▲ Welche Maßnahmen (Normstrategien) sollte man anwenden? Abbildung 29: Zielbeziehungen und -verträglichkeit (Maßnahmen) 1.6 Der Projekterfolg 1.6.1 Das erweiterte Magische Dreieck Projekte werden mit dem Ziel durchgeführt, die Anforderungen, Ziele, Interessen und Erwartungen der Stakeholder - insbesondere der Auftraggeber − umfassend und optimal zu erfüllen. Um dieses Ziel zu erreichen, bewegt sich das operative Projektmanagement zwischen den drei Größen Termine, Kosten und Leistung. Erfolg oder Misserfolg bemessen sich entsprechend in der Einhaltung der Budgetvorgaben , der Terminvorgaben und der Leistungsvorgaben − den Dimensionen des klassischen Magischen Dreiecks für Projekte. Entgegen früheren Ansätzen reicht es aber nicht mehr aus, das Projekt in der richtigen Qualität zu den richtigen Kosten und der richtigen Zeit abzuschließen. Die Zufriedenheit der Stakeholder auch ist ebenfalls ein entscheidendes Kriterium! Abbildung 30: Erweitertes Magisches Dreieck des Projektmanagements 10 10 Hüsselmann, 2020, S. 61 Zielbeziehung neutral identisch komplementär konkurrierend antinom Maßnahme → ggf. priorisieren → eines der Ziele entfernen → ggf. priorisieren oder hierarchisieren → Zielkonflikt auflösen, priorisieren → Bereinigung vornehmen Termine Kosten Leistung Toleranz Chancen & Risiken Stakeholder- Erwartungen <?page no="41"?> 1.6 Der Projekterfolg 41 Das „Magische Dreieck“ wird erweitert (siehe Abbildung 30): „Ein Projekt ist erfolgreich, wenn die Beteiligten (Stakeholder) die Qualität der technischen Lösung und die Termin- und Kostenziele insgesamt positiv bewerten und zufrieden sind.“ 11 Mit dem klassischen Magischen Dreieck lassen sich die unmittelbaren Ziele eines Projekts erfassen. Es wird um die Kundenbzw. Stakeholder-Zufriedenheit als zusätzlichen Bewertungsfaktor für den Erfolg der Projektabwicklung. Dabei gilt es, innerhalb vorgegebener Toleranzen unter Wahrung von Chancen und Handhabung von Risiken die Erwartungen der Stakeholder, insbesondere Kunden und Auftraggeber, zu erfüllen. Die Rahmenbedingungen dafür ergeben sich aus dem Kontext der Organisation sowie der verbundenen Nutzenerwartung, die im Business Case zum Projekt ausgedrückt sein sollte. Insofern ergibt sich das erweiterte Magische Dreieck im Sinne der vorigen Abbildung. Die Chancen und Risiken bewirken dabei als ungeplante Ereignisse mit positiver oder insbesondere negativer Beeinflussung des Projektverlaufs und (damit) des Projekterfolgs, dass sich die ursprünglich geplante Zielerreichung des Projekts ändern kann. Bei Eintreten von Risiken etwa muss ggf. der Kreis, der die Rahmenbedingungen symbolisiert, erweitert werden. Die Toleranzen in diesem in einem ersten Schritt erweiterten Magischen Dreieck (später mehr dazu im Zusammenhang mit dem Lean Project Management) setzen den Spielraum, den das Projektmanagement bei der Durchführung des Projektes hat. Innerhalb der gesetzten Toleranzen kann das Projekt aus sich heraus den Umgang mit eingetretenen Entwicklungen, z.B. Änderungsanforderungen, entscheiden, ohne dafür eskalieren zu müssen und bspw. ein OK für zusätzliches Budget vom Auftraggeber einholen zu müssen. Damit werden nicht zuletzt schnellere Entscheidungen und die Kompetenz der Projektleitung gestärkt. In der Praxis ist zu beobachten, dass Organisationen eine unterschiedliche Aversion bei der Akzeptanz von Toleranzen mit Blick auf die Dimensionen des Magischen Dreiecks zeigen - der gesetzte Rahmen ist enger oder weiter: Budget-fokussierte Organisationen … zeigen wenig Toleranz bei der Einhaltung des Projektbudgets. Es werden hier sehr enge Grenzen gesetzt und der Spielraum des Projekts ist gering. So könnte z.B eine Überziehung des Budgets in Höhe von 2% bereits als maximal akzeptabel angesehen werden. Solche Organisationen hantieren bspw. mit einem von außen zugewiesenen, festen und genehmigten Budget, das strikt einzuhalten ist. Zeit-fokussierte Organisationen oder Projekte … setzen einen Endtermin für das Projekt, der nicht oder nur unter Verlust verschiebbar ist. Grund hierfür sind z.B. regulatorische oder gesetzliche Vorgaben oder auch die Time-to-Market, also etwa der angekündigte oder zugesagte Termin der Verfügbarkeit der geschaffenen Lösung. Leistungs-fokussierte Projekte schließlich … tolerieren keine Abweichung von der vereinbarten Leistung. Das können etwa technische Projekte sein, deren Produkte aufgrund sicherheitstechnischer Aspekte eine Null-Fehler-Toleranz verlangen. Ein Flugzeug, dessen Bauteile eine Fehlertoleranz von nur 0,01% aufweisen, stürzt unter Umständen bei jedem 10.000sten Flug ab - inakzeptabel. Ganz allgemein gesprochen, setzt der mit dem Projekt verbundene Nutzen, der in Form eines Business Case formuliert sein sollte, den Rahmen für die Frage, ob ein Projekt erfolgreich ist, oder nicht. Somit lässt sich also der Abwicklungserfolg (=Einhaltung von Zeit, Leistung und Budget) von Anwendungserfolg (=Erzielung des angestrebten Nutzens) unterscheiden. Für 11 Lechler, 2005, S. 44 <?page no="42"?> 42 Takt 1: Projekt-Setup Letzteres ist nicht zuletzt die Zufriedenheit der Stakeholder mit Projektverlauf und -ergebnis ausschlaggebend. Mit der Formulierung des Projektauftrags hängt daher die Frage, wann denn das Projekt schlussendlich als erfolgreich zu bezeichnen ist, eng zusammen. Was ist Projekterfolg? Bereits bei Projektstart sollte der Auftraggeber festlegen, was später als Projekterfolg zu werten ist! Sollte das nicht geschehen, kann es sein, dass das Projekt später „schöngeredet“ oder „schöngerechnet“ wird. 1.6.2 Erfolgsmessung Der Projektmanager sollte auf Änderungen der Rahmenbedingungen achten. Tut er es nicht, kann es sein, dass das Projekt zwar pünktlich, zu den vereinbarten Kosten und mit der richtigen Leistung abgeschlossen wurde, aber in der Anwendung nicht die Erwartungen erfüllt. Wir unterscheiden also zwischen Abwicklungserfolg und Anwendungserfolg: Abbildung 31: Abwicklungserfolg und Anwendungserfolg Was ist Abwicklungserfolg? Der Abwicklungserfolg ist eingetreten, wenn das Projekt: die Spezifikationen des Auftraggebers erfüllt wurden, die Terminvorgabe erreicht wurde, und die geplanten Kosten eingehalten wurden. Was ist Anwendungserfolg? Der Anwendungserfolg ist erreicht, wenn der Auftraggeber mit dem Ergebnis zufrieden ist und die Anwendung des Projektergebnisses seinen Vorstellungen entspricht. ��� Der Zeitpunkt der Erfolgsmessung ist sehr ausschlaggebend für die Messung des Projekterfolgs. Die Unterscheidung zwischen Anwendungs- und Abwicklungserfolg kann gravierende Auswirkung hinsichtlich der Bewertung des Projektergebnisses haben. Dazu ein paar Beispiele: Abwicklungserfolg Anwendungserfolg Abwicklungserfolg: Hoch Anwendungserfolg: Hoch Mögliche Gründe Ein Hersteller von MTBs hatte zum 01.01.2015 die Markteinführung von E- Bikes geplant. Kosten, Zeit und Leistung sind wie geplant verlaufen. Die E-Bikes erfreuen sich noch größerer Beliebtheit als angenommen. Die Markteinführung war ein großer Erfolg, es können 20 % mehr verkauft werden als geplant. Rahmenbedingungen haben sich geändert. (Die Nachfrage nach E-Bikes steigt allgemein). Die E-Bikes sind aufgrund besserer Technik beliebter als die des Wettbewerbes Abwicklungserfolg: Hoch Anwendungserfolg: Niedrig Mögliche Gründe Ein Immobilieninvestor hat ein Seniorenheim geplant, was er auch betreiben will. Das Haus wurde rechtzeitig und gemäß den Vorgaben fertiggestellt, Kosten wurden eingehalten. Während der Bauzeit sind noch weitere Seniorenheime in unmittelbarer Nähe entstanden. Die Auslastung bleibt weit hinter den Erwartungen zurück und liegt bei ca. 60%. Der break-even Point wird aber erst bei 85% erreicht. Fehlende Wettbewerbsbeobachtung <?page no="43"?> 1.6 Der Projekterfolg 43 Abbildung 32: Abwicklungsvs. Anwendungserfolg Zur Erfolgsbeurteilung gilt es, die einzelnen Punkte zu priorisieren und die Zufriedenheit der einzelnen Stakeholder zu diesen Punkten zu gewichten. Beispiele - Wiegt die Zufriedenheit des Vorstandes bei einem großen Bauprojekt hinsichtlich der Kosten genauso schwer wie die Meinung einer einzigen Anwohnerin, der die Fassade nicht gefällt? - Kann der Projektmanager bei einem IT-Projekt verantworten, den Abschluss des Projekts 2 Wochen nach hinten zu schieben − was hohe Ausfallkosten verursacht −, um die Bedienerfreundlichkeit stark zu erhöhen? - Der Preis für das geplante Produkt in einem Unternehmen für Elektroniksysteme sinkt viel stärker als geplant. Das neue Produkt muss 4 Wochen vor dem eigentlichen Termin marktreif sein, um die benötigten Deckungsbeiträge noch abzuschöpfen. Hier gilt es das Verhältnis zwischen eigenen Kosten und Nutzen abzuwägen. Der Nutzen eines zufriedenen Stakeholders ist z.B. ein Folgeauftrag (Kunde) oder auch die Zufriedenheit und die Verringerung der Widerstände, z.B. bei Mitarbeitern oder Anwohnern. Die Priorisierung der Ziele und die Gewichtung der einzelnen Stakeholder obliegen der Projektleitung. Fasst man all diese Überlegungen zusammen, dann kommt man zu einer wertorientierten Neu-Interpretation des Magischen Dreiecks. Schauen Sie sich dazu doch einmal das folgende Video an: ► Video 1.4 (Magisches Dreieck), URL: https: / / youtu.be/ 1AKG97nDLLw 1.6.3 Business Case Projekte sind Investitionsvorhaben! Es sollten grundsätzlich nur solche Projekte durchgeführt werden, die sich wirtschaftlich rechnen. Bei konkurrierenden Projekten werden - aufgrund knapper Ressourcen - die mit der besten Wirtschaftlichkeit priorisiert. Typische Nutzenkategorien von IT-Projekten sind: 12 12 vgl. Okujava, S., 2006, S. 98f g Abwicklungserfolg: Niedrig Anwendungserfolg: Hoch Mögliche Gründe Ein Hersteller für elektronisches Spielzeug will eine neue Konsole auf den Markt bringen. Durch eine Fehleinschätzung der F&E Kosten sind die geplanten Kosten um 50% höher als geplant. Des Weiteren ist der Zeitpunkt der Markteinführung ein Jahr später als geplant. Das neue Produkt ist durch die plötzliche Insolvenz eines Wettbewerbers die einzige Spielkonsole in diesem Marktbereich. Die Verkaufszahlen sind um 35% höher als geplant. Neue Marktsituation Abwicklungserfolg: Niedrig Anwendungserfolg: Niedrig Mögliche Gründe Die Einführung eines neuen ERP-Systems bei einem Maschinenbauer ist komplett außerhalb der geplanten Kosten und Zeit. Das neue System hat keine Renner-Penner-Analysemöglichkeit, es kann den Lagerbestand nicht überwachen, es ist sehr bedienerunfreundlich. Unzureichender Kontakt mit den späteren Benutzern. Schlechte Zielvorgaben Kategorie Beschreibung Strategie Beitrag um das „langfristige, erfolgreiche Bestehen im Markt zu sichern“ Finanzen Direkte Kosteneinsparungen und Verbesserungen bei monetären und finanziellen Kennzahlen (keine Umsatzzuwächse) <?page no="44"?> 44 Takt 1: Projekt-Setup Abbildung 33: Typische Nutzenkategorien von IT-Projekten Die Wirtschaftlichkeitsbetrachtung von Projekten stellt Nutzenaspekte den Kosten gegenüber: Abbildung 34: Wirtschaftlichkeitsbetrachtung Dabei ist zu beachten: - Die Lebensdauer realistisch einschätzen! - Der Nutzen tritt häufig erst mit zeitlicher Verzögerung ein: Umstellungs-/ Einführungsaufwand, geringere Produktivität/ Mehraufwand in der Startphase u.ä. - Einsparungs-/ Nutzenpotenziale müssen auch realisiert werden! Der Business Case beschreibt das Szenario zur betriebswirtschaftlichen Beurteilung eines Projektes als Investition. Definition 13 „Ein Business Case ist die Rechtfertigung für eine Aktivität einer Organisation (Projekt), die üblicherweise Kosten, Nutzen, Risiken und Zeitaufwand umfasst und anhand der wiederholt geprüft wird, ob das Projekt sich weiterhin lohnt.“ „Der Nutzen ist messbare Verbesserung, die aus einem Projektergebnis resultiert und von einem oder mehreren Stakeholdern als Vorteil betrachtet wird.“ (nach PRINCE2) Das Projektergebnis, z.B. die neue IT-Applikation entfaltet über die Anwendung den erwarteten (erhofften) Nutzen: Abbildung 35: Über die Anwendung zum Nutzen 13 vgl. Ebel, 2011 Nutzen  Quantifizierbarer Nutzen (€)  Nicht-quantifizierbarer Nutzen Kosten • Reine Projektkosten • Investitionskosten • Betriebskosten Prozesse Verbesserung des Umwandlungseffekts eines Prozesses (z.B. Erhöhung der Prozessgeschwindigkeit) Organisation Verbesserung der Organisationsstrukturen und der organisatorischen Fähigkeiten (z.B. kürzere Reaktionszeiten) Technologie und Technik Verbesserung der Technikausstattung (z.B. Erhöhung der Sicherheit) Beziehungen zur Umwelt Verbesserung des Beziehungsmanagements zu Kunden, Lieferanten und anderen Stakeholdern Informationsversorgung Nutzeneffekte durch verbesserte Informationsversorgung (z.B. mehr Eigeninitiative der Mitarbeiter) Flexibilität Vergrößerung des Handlungsspielraums bei Entscheidungen und schnellere Entscheidungen Produkte und Dienstleistungen Verbesserung der Qualität von Produkten und Dienstleistungen, sowie der Wettbewerbsposition Persönliche Faktoren Mitarbeiterbezogene bzw. weitere Stakeholder-bezogene Effekte (z.B. Erhöhung der Motivation) Produkt • Spezialistenprodukte • Organisationsänderung Anwendung • z.B. einfachere oder schnellere Tätigkeiten für Mitarbeiter Nutzen • messbare Veränderung • Vorteil für Auftraggeber • Verfolgung strategischer Ziele <?page no="45"?> 1.6 Der Projekterfolg 45 Die folgende Abbildung zeigt beispielhaft den inhaltlichen Aufbau eines Business Case anhand eines Projekts zum Aufbau eines Leitstandsystems: 1 Referenzierte Dokumente 2 Zusammenfassung 3 Hintergrund / Ausgangslage 3.1 Gründe 3.2 Vorgehensweise 4 Detailbeschreibung der gewählten Option 4.1 Erwarteter Nutzen 4.2 Erwartete Nebeneffekte 4.3 Zeitrahmen 4.4 Kosten 5 Hauptrisiken 5.1 Fertigstellung Baumaßnahme 5.2 Implementierung 5.3 Akzeptanz 5.4 Geodateninfrastruktur 5.5 Komplexität Abbildung 36: Aufbau eines Business Case 1.6.4 Erweiterte Wirtschaftlichkeitsbetrachtung Eine rein monetäre Kosten-/ Nutzenbetrachtung lässt wesentliche qualitative Faktoren außer Acht. Sie wird in der Anfangsphase von umfangreichen Maßnahmen häufig nicht ausreichen, um deren Wirtschaftlichkeit nachzuweisen. Der Anteil der nicht quantifizierbaren Nutzenkriterien hat z.T. erhebliches Gewicht. Daraus folgt für die Wirtschaftlichkeitsbetrachtung (WiBe) von IT-Maßnahmen:  Alle monetär bewertbaren Kosten und Nutzen der vorgesehenen Maßnahme sind einander gegenüberzustellen; dabei sind Verfahren der Investitionsrechnung anzuwenden,  Alle weiteren qualitativen Entscheidungstatbestände müssen in einer Nutzwertanalyse angemessen und vollständig berücksichtigt werden. Der Nutzen ist das „Maß an Befriedigung, das ein Entscheidungsträger erreicht, wenn er mit Hilfe von Handlungsalternativen einzelne Zielsetzungen anstrebt und verwirklicht (…)“ 14 Daraus folgt, dass das Nutzenmaß durchaus subjektiv ist, d.h. Stakeholder-spezifisch. Zudem ist der Nutzen ist nicht immer quantifizierbar, geschweige denn monetär zu bemessen. Der Nutzen ist der „ wirtschaftliche Wert. (…) Fähigkeit eines Gutes, ein bestimmtes Bedürfnis (…) befriedigen zu können (…)“ 15 Die Nutzenbetrachtung richtet sich i.A. nach dem Kontext des Projektportfolios, z.B. ist der Nutzenbeitrag der IT der „(…) Beitrag von IT für die Leistungsfähigkeit von Unternehmen (…)“ 14 Abbildung 37: Nutzenbetrachtung 14 Kammerer, 2012, S. 62f 15 Gabler, „Nutzen“ Klassifizierung des Nutzenbeitrags z.B. nach strategische Vorteile Wettbewerbsvorteil, Kundenbindung, usw. informationsorientierter Nutzen Zugang zur Information, Qualität der Information, usw. transaktionsorientierter Nutzen Effizienz der Kommunikation, der Systementwicklung, usw. <?page no="46"?> 46 Takt 1: Projekt-Setup Die vom Beauftragten der Bundesregierung für Informationstechnik (CIO Bund) bereitgestellte WiBe 5.0 ist ein Verfahren zur Beurteilung der Wirtschaftlichkeit von Investitionen (primär IT- Investitionen). Die IT-WiBe … ist ein für die Wirtschaftlichkeitsbetrachtung branchenübergreifend anerkanntes Muster. ist eine methodische und inhaltliche Hilfe für den Verantwortlichen und soll begründete und nachvollziehbare Aussagen über die Wirtschaftlichkeit von (IT-) Investitionen geben. gibt einen einheitlichen methodischen Rahmen für die Ermittlung der Wirtschaftlichkeiten in Investitionen vor. Sie enthält einen umfangreichen Kriterienkatalog, die in vier Gruppen die verschiedenen Kosten und Nutzenaspekte einer IT-Maßnahme erfasst (BMI). <?page no="47"?> 1.7 Projektbeschreibung − Project Canvas & Co. 47 Abbildung 38: Kataloge der IT-WiBe 1.7 Projektbeschreibung − Project Canvas & Co. Die Ergebnisse der Projektvorbereitung, die im Projektauftrag mündet, sollten in einer kompakten Projektbeschreibung festgehalten werden. Diese dient als wichtiges Kommunikationsmittel zur übersichtlichen und kurzen Darstellung des Projektes für alle Projektbeteiligte und -Stakeholder. Definition Projektauftrag 16 „Darstellung des Zwecks, des Kosten- und Zeitaufwands sowie der Leistungsanforderungen & Einschränkungen eines Projekts. Die Beschreibung wird im Vorfeld des Projekts bei Vorbereiten eines Projekts erstellt (Projektbeantragung) und liefert bei Initiieren eines Projekts (Projektbeauftragung) die Vorlage für das Projekthandbuch und deren Bestandteile. Sie wird während des Projekts ggf. (nur) über einen systematischen Änderungsprozess fortgeführt. Die Projektbeschreibung enthält den Projektlösungsansatz.“ Input für die Projektbeschreibung sind die Leistungsbeschreibung/ das Lastenheft (Statement of Work) bzw. die Projektskizze/ Projektidee, der Business Case sowie Umweltfaktoren und das Prozessvermögen der Organisation. Inhalt der Projektbeschreibung sind typischerweise folgende Aspekte: - Projektbezeichnung - Projektstart/ -ende - Projektziele/ -aufgaben/ -abgrenzung - Projektorganisation (mind. AG & PL) - Projektkosten bzw. -budget - Voraussetzungen/ Rahmenbedingungen - Wirtschaftlichkeits-/ Nutzenbetrachtung potenzielle Risiken & Chancen 16 angelehnt an PRINCE2 <?page no="48"?> 48 Takt 1: Projekt-Setup ��� Tipp: Wählen Sie einen markanten Namen für Ihr Projekt! z.B. ein Akronym, dass einen thematischen Zusammenhang assoziiert und damit auch als Projektmarketing-Element dient. Als Hilfsmittel haben sich verschiedene „Formulare“ bewährt, die als One-Pager die Projektbeschreibung in der gewünschten kompakten Form ermöglichen. Ein Beispiel könnte so aussehen: Abbildung 39: Projektsteckbrief Abbildung 40: Project Canvas <?page no="49"?> 1.8 Erfolgsfaktoren − Wie gelingt erfolgreiches Projektmanagement? 49 Setzt man solche strukturierten Dokumente im Rahmen eines Workshops und in Postergröße ein, dann spricht man auch vom „Project Canvas“. Im Internet finden Sie eine Fülle von Beispielen, die sicherlich auch für Ihre Anforderungen passen. Bei einem solchen Startup-Workshop werden die Grundlagen für die Projektbeschreibung bzw. -beantragung gelegt. Teilnehmer sind repräsentative Vertreter des Kernteams, des Fachbereichs bzw. des Managements. Voriges in Abbildung 40 gezeigte Beispiel entstammt aus einem Umzugsprojekt eines Archivs einer Non-Profit-Organisation. Projekt-Kick-Off Der Projekt-Kick-Off ist der formale Projektstart und im Allgemeinen das erste Treffen des Projektleiters mit dem gesamten Projekt-Team. Hauptziel: Klarheit schaffen • Jeder kennt die Projektziele und damit die Kriterien, an denen der Projekterfolg gemessen wird. • Jeder kennt das geplante Vorgehen mit Zwischenterminen und Meilensteinen. • Jeder hat das Projekt als Ganzes verstanden. • Jeder kennt seine Rolle im Projekt. Vorstellung/ Kennenlernen der Teammitglieder Vorstellung des Projektauftrags und der Projektprozesse • Projektziele, -inhalte und -termine. • Commitment zu den Zielen. • Rahmenbedingungen. • Spielregeln der Zusammenarbeit. 1.8 Erfolgsfaktoren 17 − Wie gelingt erfolgreiches Projektmanagement? Die Charakteristik von Projekten macht es inhärent, dass mit einer gewissen Misserfolgsquote gerechnet werden muss. Es existieren eine Vielzahl von Studien zum Thema Projekterfolg mit unterschiedlichen Schwerpunktsetzungen. Dabei gibt es immer wieder verschiedene Aufzählungen von Erfolgsfaktoren im Projektmanagement. Welche allgemein für den Projekterfolg betrachtet werden können, sind die folgenden aus einer gemeinsamen Studie der Hochschule Koblenz und der GPM aus dem Jahre 2015, in der es um die Erfolgsfaktoren im Projektmanagement ging. An dieser Studie hatten 162 Praktiker des Projektmanagements teilgenommen und identifiziert, dass „Projekt-Teamwork“, „Projektsteuerung und Entscheidung“ sowie „Teammotivation“ die wesentlichen Erfolgsfaktoren sind. 18 Insgesamt wurden folgende Erfolgsfaktoren identifiziert: 17 siehe auch Hüsselmann, 2020, S. 61-71 18 GPM, 2015, S.132 <?page no="50"?> 50 Takt 1: Projekt-Setup Abbildung 41: Hauptgründe für Projekterfolg Im Detail ergeben sich eine Fülle von operativen Erfolgsfaktoren für die Projektarbeit. 19 Die in diversen Studien identifizierten Erfolgsfaktoren sind in einer umfangreichen Checkliste aufgeführt. ▼ Checkliste [Erfolgsfaktoren] ▲ Schauen Sie diese doch einmal durch und überlegen dabei, welche Aspekte in Ihrer Organisation oder Ihren Projekten erfüllt sind oder wo noch „Luft nach oben ist“. Nutzen Sie die Checkliste(n) als Hilfsmittel für Ihr nächstes Projekt. → siehe Transferaufgabe Damit haben Sie auch schon die zehn PM-Disziplinen kennengelernt, die im Unified Project Management Framework definiert sind. Dazu nun mehr. 1.9 Das PM-Framework 1.9.1 Überblick Wie schon zu Beginn erwähnt, haben sich in den vergangenen Jahrzehnten eine Reihe von Organisationen um die Entwicklung des PM als Managementdisziplin verdient gemacht. Die in diesem Zusammenhang veröffentlichten Frameworks haben Referenzcharakter für das PM in vielen Unternehmen in den unterschiedlichsten Branchen. In der Praxis werden sie oftmals als Standards bezeichnet, obwohl sie dies methodisch und formell betrachtet in der Regel nicht sind; wir greifen aber den Begriff teilweise auch auf. Jedenfalls festzustellen ist der unterschiedliche Charakter dieser „Standards“, der sich u.a. im Umfang und Detaillierungsgrad festmachen lässt. Bei den PM-Frameworks (Rahmenwerke) sind a) Projektmanagement- und b) Projektvorgehens- Modelle zu unterscheiden: 19 Komus, 2016, S. 12 ff <?page no="51"?> 1.9 Das PM-Framework 51 a) Prozesse und Teildisziplinen des Projektmanagements im Allgemeinen (Risiken, Anforderungen, Terminplanung, …), d.h. ohne Fokussierung einer bestimmten Projektart. Zu den sogenannten „Bodies of Knowledge“ gehören dabei der PMBoK Guide ® des PMI sowie die ICB® der IPMA. Sie umfassen das gesammelte Wissen zum PM und erfordern eine gezielte Operationalisierung zur Anwendung im Unternehmen. Im Gegensatz dazu bieten PM-Methode wie z.B. PRINCE2 konkrete Handlungsstränge und Tools, wobei sie eine spezifische Anpassung in der Regel erlauben oder empfehlen. b) Abfolge der Tätigkeiten, also der Prozesse für das Projekt und das PM einer bestimmten Projektart, z.B. IT-Projekte. Hierzu zählen z.B. das V-Modell XT zur Planung und Durchführung von IT-Systementwicklungsprojekten oder HERMES aus der Schweiz für den gleichen Zweck. Auch Scrum als agiles Vorgehensmodell zur (Software-)Produktentwicklung sei an dieser Stelle erwähnt, wenngleich kein vollständiges PM-Modell. Dazu später mehr. Eine gewisse regionale, aber auch branchenbezogene Verteilung der Nutzung der verschiedenen Frameworks ist zu beobachten. So findet im Finanzsektor relativ häufig PRINCE2 Anwendung. Dieses Framework wird fälschlicherweise oftmals (nur) IT-Projekten zugeordnet, ist aber allgemeinerer Natur. Die geschilderten PM-Frameworks sind proprietärer Art des jeweiligen Anbieters. Daher wird in diesem Modul ein vereinheitlichtes, neutrales PM-Referenzmodell verwendet - das Unified Project Management Framework (UPMF). Dieses stellt gewissermaßen ein Best-of dar, das an der TH Mittelhessen entwickelt und veröffentlicht wurde. In seiner Kompaktheit ist es für die praktische Anwendung in Projekten - nicht nur IT-Projekten - gedacht, wenngleich es insofern kein Lehrbuch ersetzt. In den folgenden drei Videos erläutere ich den Aufbau des UPMF. ► Video 1.5a-c (UPMF, Teil 1 bis 3), URL: https: / / youtu.be/ fDFmPhfFKac URL: https: / / youtu.be/ kS-a0Yx0GNk URL: https: / / youtu.be/ BLnnlw-B7_0 1.9.2 Inhalte des UPMF Das UPMF ist eine Disziplinenmatrix und versteht sich als prozessorientiertes Referenzmodell mit einem zyklischen Ansatz. Die Einordnung der Prozesse erfolgt dabei in die folgenden fünf Prozessgruppen:  Initiierung & Vorbereitung des Projekts beziehungsweise der Projektphasen  Ausplanung & Operationalisierung des Projekts beziehungsweise der Projektphasen  Überwachung & Steuerung des Projekts beziehungsweise der Projektphasen  Überleitung & Abschluss des Projekts beziehungsweise der Projektphasen sowie als generische Prozessgruppe für die fachliche Projektbearbeitung  Fachliche Ausführung des Projekts beziehungsweise der Projektphasen Dazu orthogonal werden die Prozesse in zehn PM-Disziplinen beziehungsweise in die dazugehörigen PM-Domänen eingeordnet. Im Kontext des UPMF wird eine PM-Domäne als ein Fachgebiet des Projektmanagements definiert. Eine PM-Disziplin hingegen wird als das Management von einer PM-Domäne definiert. Die folgende Abbildung zeigt die grundlegende, aus PM-Prozessgruppen, PM-Domänen und PM-Disziplinen bestehende Aufbaustruktur des UPMF. <?page no="52"?> 52 Takt 1: Projekt-Setup Abbildung 42: Aufbaustruktur des UPMF Die PM-Domänen können wie folgt beschrieben werden: Management von Auftrag & Business Case Die PM-Disziplin Management von Auftrag & Business Case beschäftigt sich im Wesentlichen mit zwei Objekten: dem Business Case und dem Projektauftrag . Diese werden folgendermaßen definiert: Business Case: „Legt Kosten, Nutzen, erwartete negative Nebeneffekte, Risiken und Zeitaufwand dar, anhand derer gerechtfertigt und geprüft wird, ob sich das Projekt weiterhin lohnt. Die Verwendung eines alternativen Dokuments, zum Beispiel eines Geschäftsplans [oder eines Canvas] anstelle des Business Case, ist für einen Takt des Projektlebenszyklus ist zulässig.“ (PRINCE2). Projektauftrag: Der Projektauftrag ist ein Dokument, mit dem der Auftraggeber formal die Existenz des Projekts autorisiert und den Projektmanager berechtigt, den Projektaktivitäten Ressourcen zuzuteilen (nach PMI). Management von Auftraggeber & Stakeholder Die PM-Disziplin Management von Auftraggeber & Stakeholder beschäftigt sich im Wesentlichen mit den folgenden Objekten beziehungsweise Personen: Stakeholder , Auftraggeber und Verträge . Diese werden folgendermaßen definiert: Stakeholder: Als Stakeholder bezeichnet man „alle Einzelnen, Gruppen oder Organisationen, die an dem Projekt beteiligt sind, dieses beeinflussen, davon beeinflusst werden oder an der Durchführung beziehungsweise dem Ergebnis desselben interessiert sind.“ (GPM, 2017, S. 155) Auftraggeber: Der Auftraggeber ist derjenige Stakeholder, der den Projektauftrag erteilt und die Hauptverantwortung für den Projekterfolg trägt. Er stellt die Projektfinanzierung sicher und ist für den Business Case verantwortlich (nach PRINCE2). Vertrag: Ein Vertrag ist eine „rechtsgültige Abmachung zwischen zwei oder mehreren Partnern.“ (Duden). Im Projektmanagement umfasst das Thema Verträge sowohl Verträge mit dem Kunden als auch mit Lieferanten. Es können hier auch verbindliche Vereinbarungen außerhalb formeller Verträge subsummiert werden. Management von Chancen & Risiken Die PM-Disziplin Management von Chancen & Risiken beschäftigt sich im Wesentlichen mit dem Risikomanagement in Projekten. <?page no="53"?> 1.9 Das PM-Framework 53 Die GPM definiert Chancen & Risiken folgendermaßen: „Chancen sind möglicherweise eintretende (oder ausbleibende) Umstände oder Ereignisse mit positiver Auswirkung auf die Projektziele, bei Risiken ist die mögliche Auswirkung dagegen negativ.“ Das im Weiteren angewendete Verständnis verwendet übergreifend den Begriff Risiken sowohl als Chancen (positive Auswirkung) als auch als Gefährdungen (negative Auswirkungen). Management der Inhaltlichen Breite & Tiefe Die PM-Disziplin Management der Inhaltlichen Breite & Tiefe beschäftigt sich im Wesentlichen mit dem Scope von Projekten. Der Scope wird folgendermaßen definiert: Scope: Der Inhalt und der Umfang eines Projekts werden auch als Scope bezeichnet (nach PMI). Management der Arbeits- und Organisationsstruktur Die PM-Disziplin Management von Arbeits- & Organisationsstruktur beschäftigt sich im Wesentlichen mit der Projektstruktur und damit mit den Objekten Projektstrukturplan und A rbeitspaketen . Diese werden folgendermaßen definiert: Projektstrukturplan: Der Projektstrukturplan ist die (grafische) Darstellung der Projekt(arbeits)struktur. Er strukturiert den Leistungsumfang, indem er den gesamten Projektinhalt in Teilaufgaben und Arbeitselemente aufteilt. Typischerweise wird der Projektstrukturplan in einer Baumstruktur, die, je nach gewünschter Detailtiefe, in eine Anzahl von Unterebenen gegliedert wird, dargestellt (nach GPM). Arbeitspaket: „Das Arbeitspaket enthält eine Beschreibung der durchzuführenden Arbeiten, die Produktbeschreibung(en), genaue Einzelheiten aller Rahmenbedingungen, die bei der Produktion zu beachten sind, und dokumentiert die Vereinbarung zwischen dem Projektmanager und der Person […], die […] für die Durchführung des Arbeitspakets zuständig ist, dass die Arbeiten innerhalb der gesetzten Rahmenbedingungen erledigt werden können.“ (PRINCE2). Management der Prozesse & des Projektablaufs Die PM-Disziplin Management der Prozesse & Projektablauf beschäftigt sich im Wesentlichen mit den folgenden Objekten: Projektablaufplan , Projektplan und Projektstatusbericht . Diese werden wie folgt definiert: Projektablaufplan: „Bei dem Ablaufplan handelt es sich um die sachlogische Anordnung der Arbeitspakete und Meilensteine eines Projekts. Er resultiert aus dem Projektstrukturplan […] durch Hinzufügen der ermittelten Dauern, der technologisch erforderlichen Vorgänger und der Art der Anordnungsbeziehungen.“ (GPM). Somit werden mit dem Projektablaufplan letztlich insbesondere auch die Termine des Projekts geplant und dokumentiert. Projektplan: Im Projektplan werden alle Einzelpläne zusammengeführt. Der Projektplan dient als zentrales Steuerelement in der Projektabwicklung (nach DIN). Projektstatusbericht: Der Projektstatusbericht „vermittelt dem Lenkungsausschuss Einzelheiten über den Fortschritt des gesamten Projekts.“ (PRINCE2). Management von Team & Kommunikation Die PM-Disziplin Management von Team & Kommunikation beschäftigt sich im Wesentlichen mit der Kommunikation in Projekten, Change und dem Projekt-Team. Das Projekt-Team und der Begriff Change werden wie folgt definiert: Projekt-Team: „Alle Personen, die einem Projekt zugeordnet sind und zur Erreichung des Projektzieles Verantwortung für eine oder mehrere Aufgaben übernehmen.“ (DIN). Change: „Unter Change wird die kontinuierliche oder diskontinuierliche Entwicklung einer Organisation verstanden, in der eine oder mehrere Dimensionen der Organisation verändert werden. Es wird davon ausgegangen, dass bei einem Change die sozialen Strukturen und Stakeholder-Beziehungen verändert werden. Es handelt sich daher um einen „sozialen“ Change.“ (GPM). <?page no="54"?> 54 Takt 1: Projekt-Setup Management von Anforderungen & Qualität Die PM-Disziplin Management von Anforderungen & Qualität beschäftigt sich im Wesentlichen mit einem Objekt: dem Qualitätsmanagement-Ansatz. Dieser wird wie folgt definiert: Qualitätsmanagement-Ansatz: „Im Qualitätsmanagement-Ansatz wird beschrieben, wie die Qualität im Projekt gemanagt wird. Dazu gehören die spezifischen Prozesse, Verfahren, Techniken, Standards und Verantwortlichkeiten, die anzuwenden sind.“ (PRINCE2). Management von Beschaffungen & Ressourcen Die PM-Disziplin Management von Beschaffung & Ressourcen beschäftigt sich im Wesentlichen mit den Objekten Kosten- und Finanzmittelplan und Ressourcenplan . Diese werden wie folgt definiert: Kostenplan: „Darstellung der voraussichtlich für das Projekt anfallenden Kosten, welche auch den Kostenverlauf enthalten kann.“ (DIN). Finanzmittelplan: „Übersicht über die für ein oder mehrere Projekte voraussichtlich benötigten Finanzmittel, welche auch den zeitlichen Verlauf des finanziellen Bedarfs ausweisen kann.“ (DIN). Ressourcen/ -plan: „Übersicht über die für ein oder mehrere Projekte eingeplanten Ressourcen.“ (DIN) Dazu zählt neben den in der fachlichen Projektarbeit zu nutzenden beziehungsweise zu verarbeitenden materiellen und immateriellen Mittel auch die Projektinfrastruktur wie Räume, Workshop-Ausstattung oder IT-Systeme. Management von Wissen & Konfiguration Die PM-Disziplin Management von Wissen & Konfiguration beschäftigt sich im Wesentlichen mit den Objekten Projekthandbuch und Änderungssteuerungsansatz . Diese werden wie folgt definiert: Projekthandbuch: „Das Projekthandbuch verkörpert die Gesamtheit der in einem Projekt anfallenden beziehungsweise zugehörenden Dokumente in Form einer Zentralablage in Papier- oder elektronischer Form mit geregelter Zugriffsberechtigung.“ (Motzel). „Es beinhaltet eine Zusammenstellung der Informationen, Regelungen, verwendeten Standards und Arbeitsmittel für die Planung, Durchführung, Überwachung und Steuerung eines bestimmten Projekts.“ (Motzel). Änderungssteuerungsansatz: „Eine Beschreibung, wie und von wem die Produkte eines Projekts … (kontrolliert) und geschützt werden.“ (PRINCE2). Im UPMF-Navigator können Sie durch das UPMF „surfen“ und dieses für Ihre eigenen Projekte nutzen. ▼ Tool [UPMF-Navigator] Das UPMF mit seinen Prozessen, Rollen, Erfolgsfaktoren und Praktiken wird Sie durch das Modul begleiten. In unserem Projekt-Lebenszyklus haben wir uns im ersten Takt des Moduls mit dem Aufsetzen des Projektes befasst. Dies umfasste im Wesentlichen den Projektauftrag mit der Klärung der Ziele, der Inhalte und der Rahmenbedingungen des Projekts sowie mit dessen Wirtschaftlichkeit, die besonders im Business Case behandelt wird. Nach Erteilung des Projektauftrags können wir mit der Operationalisierung des Projekts beginnen, sprich der Ausgestaltung der Vorgehensweise. Hierbei gilt es, verschiedene Aspekte des Projekts planerisch zu gestalten. <?page no="55"?> 1.10 Transferaufgaben Takt 1 55 1.10 Transferaufgaben Takt 1 ▲ Bewerten Sie doch einmal - grob - das Projektmanagement in Ihrer Organisation. ▼ Nutzen Sie dazu das MS Excel-Tool, das zum UPMF-Referenzmodell bereitsteht - den UPMF-Navigator. Wenn Sie das Tool öffnen, gelangen Sie auf die Landing Page, auf der Sie das „Big Picture“ des UPMF sehen. Klicken Sie auf dieses Visual und Sie gelangen in die Übersicht. 1.10.1 Prozesse In der Übersicht sehen Sie insbesondere die Prozesse des UPMF. Wenn Sie einen Prozess anklicken, z.B. „Business Case entwickeln“, gelangen Sie auf die entsprechende Prozessseite. Im ersten Schritt geht es nun darum, zu identifizieren, ob die Prozesse in Ihrer Organisation etabliert sind. Wählen Sie dazu die zugehörigen Aktivitäten aus durch Aktivieren der Checkbox („1“). Wenn die Aktivität für Sie nicht relevant ist, negieren diese („-1“). Wenn Sie sich nicht sicher sind, lassen Sie die Checkbox leer. Mit Klick auf „ ← UPMF-Übersicht“ gelangen Sie zurück auf die UPMF-Übersichtsseite und können von dort aus leicht den nächsten Prozess auswählen. 1.10.2 Erfolgsfaktoren Wenn Sie auf der Übersichtsseite auf die jeweilige PM-Domäne bzw. -Disziplin klicken, z.B. Auftrag & Business Case“, gelangen Sie auf die Seite mit den Erfolgsfaktoren zu dieser Domäne. ▲ Schauen Sie sich die hier aufgeführten Erfolgsfaktoren an und dokumentieren Sie wiederum durch Aktivieren der Checkbox, ob dieser Erfolgsfaktor in Ihrer Organisation oder in Ihrem Projekt bereits umgesetzt wird. ��� Wenn Sie diese Übung vollständig durchspielen, haben Sie bereits viele Hinweise für den Reifegrad und die offenen Handlungsfelder im Projektmanagement Ihrer Organisation! Bei allen Übungen im Rahmen dieses Moduls gilt: Vollständigkeit ist aufgrund Ihrer Zeitrestriktion in der Regel nicht das Ziel. Es geht immer darum, dass Sie durch aktives Tun die Methoden und Inhalte verinnerlichen, Erkenntnisse gewinnen und ggf. Fragen identifizieren. Aber vielleicht sind Sie ja richtig schnell … Viel Spaß! <?page no="57"?> 2 Takt 2: Projektplanung Auch den zweiten Takt können Sie mit einem Video zum Überblick über den 2. Takt und zur Motivation und Einordnung des Themas beginnen. ► Video 2.1 (Überblick über den 2. Takt), URL: https: / / youtu.be/ 5X_pY4EQsN8 2.1 Requirements Management 2.1.1 Grundlagen Ein wesentlicher Baustein (nicht nur) für den Erfolg von IT-Projekten ist ein systematisches Anforderungsmanagement (engl. Requirements Management). Dieser Cartoon aus der 1960er- Jahren zeigt die vielfach immer noch gültigen Probleme der Produktentwicklung auf. 20 Abbildung 43: Typische Produktentwicklung? Das Zusammenspiel zwischen Anwender/ Kunde, Konstrukteur, Programmierer, Vertrieb etc. impliziert die typische Komplexität. Eine systematische Anforderungserhebung, -analyse und -management hilft, Fehler zu vermeiden, sie ggf. in einem frühen Stadium zu erkennen und zu beheben. 20 https: / / de.wikipedia.org/ wiki/ Tree_swing_cartoon <?page no="58"?> 58 Takt 2: Projektplanung Für die unterschätzte Rolle des Requirements Engineering in vielen Software-Projekten liefern verschiedenen Studien (CHAOS Report der Standish Group, SwissQ etc.) Zahlen: 21 Abbildung 44: Rolle des Requirements Engineerings in Software-Projekten Lassen Sie uns zunächst einige zentrale Begriffe definieren: Anforderung Requirements Engineering (RE) Eine Anforderung ist eine (dokumentierte) Bedingung oder Fähigkeit, die … 1. von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird; 2. ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen. nach IEEE Std 610-12-1990 22 Das RE ist ein systematischer und disziplinierter Prozess der Spezifikation und des Managements von Anforderungen mit den Zielen: 1. Die Wünsche und Bedürfnisse des Stakeholders zu verstehen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen des Stakeholders entspricht. 2. Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und systematisch zu managen. nach IREB-Standard 23 Ein Requirement ist also eine Bedingung oder Fähigkeit, die ein System, ein Produkt, eine Dienstleistung, ein Ergebnis oder eine Komponente erfüllen oder besitzen muss, um einem Vertrag, einem Standard, einer Spezifikation oder sonstigen formal vorgeschriebenen Dokumenten zu genügen. Zu Anforderungen gehören die quantifizierten und dokumentierten Bedürfnisse, Wünsche und Erwartungen der Sponsoren, Kunden und der anderen Stakeholder. 24 21 zitiert nach Schillinger, 2018, S. 7 22 IEEE ist eine von ANSI akkreditierte Organisation zur Entwicklung von Standards. IEEE Std 610.12-1990 ist das IEEE-Standardglossar für die Terminologie der Softwaretechnik. 23 Das International Requirements Engineering Board e.V verfolgt das Ziel, professionelle Standards durch Aus- und Weiterbildung im Requirements Engineering zu etablieren. 24 angelehnt an PMI, 2004 <?page no="59"?> 2.1 Requirements Management 59 Arten von Anforderungen  Im Mittelpunkt des RE stehen die funktionalen und nicht-funktionalen Anforderungen.  Funktionale Anforderungen legen die Funktionalitäten fest, die das System zur Verfügung stellen soll und werden typischerweise in Funktions-, Verhaltens- und Strukturanforderungen unterteilt. Abbildung 45: Arten von Anforderungen Abbildung 46: Das Kano-Modell Funktionale Anforderungen eigenständige Systemaktion Interaktion zwischen System und User/ anderem System prozessuale Funktionen Einschränkungen Nicht-funktionale Anforderungen organisatorische, rechtliche, vertragliche Bedingungen Qualität Ergonomie Technologie, Standards <?page no="60"?> 60 Takt 2: Projektplanung Mit Blick auf die Zufriedenheit der Stakeholder können Anforderungen in drei Kategorien unterteilt werden:  Basisfaktoren sind als selbstverständlich vorausgesetzte Features. Sind sie in einem Produkt nicht umgesetzt, führt das zu massiver Unzufriedenheit beim Kunden.  Leistungsfaktoren sind die bewusst verlangten Systemmerkmale. Je mehr Leistungsfaktoren umgesetzt sind, desto zufriedener ist der Kunde mit dem Produkt.  Begeisterungsfaktoren sind die Features eines Produkts, die ein Kunde noch nicht kennt und erst während der Benutzung als angenehme Überraschung entdeckt und überdurchschnittliche Begeisterung hervorrufen. Das hier beschriebene sogenannte Kano-Modell lässt sich wie in Abbildung 46 gezeigt anschaulich darstellen. 25 Die Dokumentation von Anforderungen kann sowohl natürlich-sprachlich als auch Form von Modellen erfolgen: 26 Abbildung 47: Dokumentation von Anforderungen Gerade auch im Zusammenwirken zwischen Fach- und IT-Abteilung hat sich die Nutzung von Satzschablonen für die Anforderungsdokumentation bewährt. Daher schauen wir hier einmal genauer hin. Die Nutzung von Satzschablonen trägt dazu bei, dass Anforderungssätze einheitlich strukturiert sind und so Defekte (wie z. B. das Fehlen des Akteurs) von vornherein vermieden werden: ��� Eine Anforderungsschablone ist eine syntaktische Struktur, die den Aufbau eines einzelnen Anforderungssatzes festlegt. 25 SOPHIST, 2016, S. 21f sowie Schillinger, 2018, S. 32 26 Die Unified Modeling Language ist eine grafische Modellierungssprache zur Spezifikation, Konstruktion, Dokumentation und Visualisierung von Software-Teilen und anderen Systemen. <?page no="61"?> 2.1 Requirements Management 61 Muster für eine funktionale Anforderung: Abbildung 48: Satzschablone für funktionale Anforderungen Beispiel „Bei einem Personalengpass muss das Dispo-System dem Arbeitsvorbereiter die Möglichkeit bieten, den derzeit gültigen Schichtplan zu drucken.“ ▲ Finden Sie eigene Beispiele? Schauen wir uns weiter einige zentrale Begriffe des RE an; starten Sie gerne mit dem Video: ► Video 2.2 (Requirements), URL: https: / / youtu.be/ oBcZqiIKHCc Das Lastenheft … Das Pflichtenheft … beschreibt die vom Auftraggeber festgelegte Gesamtheit der Anforderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags. In der Regel werden zudem die Anforderungen aus Anwendersicht an das System und den Entwicklungsprozess einschließlich aller Randbedingungen dokumentiert. Was soll wofür erreicht werden! nach DIN 69905 sowie V-Modell XT 27 baut auf den Vorgaben des Lastenhefts auf und enthält die von Auftragnehmer erarbeiteten Realisierungsvorgaben zur Umsetzung des vorgegebenen Lastenheftes. Es kann somit als Konkretisierung der Anforderungen und Randbedingungen des Lastenheftes verstanden werden. Wie soll etwas in welcher Form erreicht werden! nach DIN 69905 sowie V-Modell XT Anmerkung: Im englischsprachigen Raum werden die Begriffe Lasten- und Pflichtenheft weniger unterschieden und allgemein von „Requirements Specifications“ gesprochen. 27 Die DIN-Normenreihe DIN 69901 beschreibt Grundlagen, Prozesse, Prozessmodell, Methoden, Daten, Datenmodell und Begriffe im Projektmanagement. Der Teil 5 enthält Begriffe. Das V-Modell XT ist ein Vorgehensmodell für IT-Entwicklungsprojekte der Bundesrepublik Deutschland. Wir gehen später noch näher darauf ein. <Bedingung> muss wird … <Akteur> die Möglichkeit bieten <Objekt & Ergänzung> <Prozesswort> fähig sein sollte kann <System> <?page no="62"?> 62 Takt 2: Projektplanung Das Lastenheft - ein Gestaltungsvorschlag nach Balzert: 28 Abbildung 49: Lastenheft - ein Gestaltungsvorschlag nach Balzert Zur Ermittlung der Anforderungen ist folgende Vorgehen geeignet: 29 Abbildung 50: Projektvorgehen im Bereich der Voruntersuchung Zur Ermittlung der Anforderungen an das zu erarbeitende System haben sich eine Reihe von Techniken im Rahmen des RE herauskristallisiert: 28 nach Balzert, 2010, zitiert nach Krypczyk, 2016a 29 in Anlehnung an Krypczyk, 2016b <?page no="63"?> 2.1 Requirements Management 63 Abbildung 51: Methodische Erhebung von Anforderungen Brainstorming ist eine Methode zur Ideenfindung, die die Erzeugung von neuen, ungewöhnlichen Ideen in einer Gruppe von Menschen fördern soll. Interviews sind persönliche Befragungen, die systematisch und zielgerichtet durchgeführt werden. Die Feldbeobachtung ermittelt Erkenntnisse über Verhaltensweisen, Aktivitäten und Abläufe, indem sie Zielpersonen in ihrem Arbeitsumfeld beobachtet. Bei der Systemarchäologie werden für die Anforderungsermittlung das Altsystem bzw. die dazu vorhandenen Benutzerhandbücher zu Rate gezogen. Die 6-3-5-Methode ist eine Brainwriting- Technik, die ein Problemlösungsverfahren zur Erzeugung von neuen, ungewöhnlichen Ideen in einer Gruppe von Menschen fördert. 6 Teilnehmer formulieren dabei 3 Ideen in max. 5 Minuten. Ein Fragebogen ist ein Instrument zur Datenerhebung, dass relativ leicht einer großen Anzahl an Personen zugänglich gemacht werden kann. Das Apprenticing ist eine Variante der Feldforschung, bei der ein Lehrling - ein Apprentice - bei einem Anwender dessen Tätigkeit ausführt, um so mehr Wissen darüber zu sammeln. Code-Reuse, auch Software-Wiederverwendung genannt, ist die Verwendung vorhandener Software oder von Software- Wissen zur Erstellung neuer Software. Wichtigste Quellen sind Stakeholder, Dokumente und die Systeme in Betrieb. Requirements Engineering im Projektvorgehen In jedem Projekt steht die Anforderungsspezifikation am Anfang der Realisierung eines (Teil-)Produkts! Projektvorgehensweisen unterscheiden sich jedoch in der Intensität und im Umfang des initialen RE. Klassische plangetriebene Vorgehensweisen 30 postulieren, alle Anforderungen in einer frühen Projektphase vollständig zu erheben. Auf Basis dieses erzeugten geschlossenen Bilds werden anschließend Entwurfs- und Realisierungsentscheidungen getroffen. Andere, agilere Vorgehensmodelle 31 integrieren das RE als kontinuierlichen, phasenübergreifenden Prozess in die Systementwicklung. Agile Vorgehensweisen erlauben eine fortlaufende Konkretisierung und Priorisierung von Anforderungen. 30 am Wasserfall orientierte Vorgehensweisen oder das V-Modell; wir kommen später im Detail dazu. 31 wie z.B. eXtreme Programming; wir kommen später im Detail dazu. Kreativitätstechniken Brainstorming 6-3-5 Methode Befragungstechniken Interviews Fragebogen Beobachtungstechniken Feldbeobachtung Apprenticing Artefakttechniken Systemarchäologie Reuse Abbildung 52: Requirements Engineering im Projektvorgehen <?page no="64"?> 64 Takt 2: Projektplanung Anforderungen nicht initial zu klären kann den Projektverlauf massiv verändern. Oft ist eine fragmentierte Durchführung des RE ein Grund für das Scheitern von Projekten. Die vermeintliche Verschlankung von Prozessen führt hier zu einem erhöhten Risiko. Abbildung 53: Fragmentierung des RE Dabei ist jedoch zwischen einer systematischen Fragmentierung und einer unbeabsichtigten zu unterscheiden. Merkmale von IT-Projekten IT-Projekte zeichnen sich typischerweise durch folgende Merkmale aus, die auch den Umgang mit dem Requirements Engineering beeinflussen:  Innovationscharakter, Neuartigkeit, Entwicklung oder Einführung neuer Technologien (Unbekanntes kann schlecht spezifiziert werden)  hohe Dynamik des Umfeldes, Schnelllebigkeit  sprachliche Barrieren zw. Entwicklungs- und Fachabteilung, mangelndes Wissen über die IT-Lösungen  Einflussfaktoren, Anforderungsdetails sind von stetigen Veränderungen geprägt, vielfach Moving Targets  in der Regel viele Abhängigkeiten  oft Entscheidung zwischen mehreren alternativen Technologien, unterschiedliche und nicht direkt vergleichbare Anforderungen  Investitionscharakter mit vielfach schwieriger Quantifizierung des Nutzens  komplexes Zusammenspiel der betriebswirtschaftlichen, technischen und menschlichen Komponenten …aber auch  Möglichkeit der Iteration [anders als etwa beim Hausbau] vielfach gegeben Je nach Projektschwerpunkt sind diese Merkmale stärker oder weniger stark ausgeprägt. Allgemein lässt sich feststellen: In IT-Projekten ist eine Mikro-Spezifikation ist (vielfach) nicht wertschöpfend! Bei der Durchführung des RE stellt sich also die Frage des Umfangs und des Detaillierungsgrads der Anforderungsspezifikationen. Auf das richtige Maß kommt es an: <?page no="65"?> 2.1 Requirements Management 65 Abbildung 54: Mikro-Spezifikation ist (vielfach) nicht wertschöpfend Wann ist welche Vorgehensweise angemessen? Wenn der Kontext des Projekts dadurch gekennzeichnet ist, dass die Anforderungen oder die Lösung unsicher sind, dann ist ein wasserfallartiges Vorgehen, bei dem initial ein vollständiges RE erfolgt, nicht zielführend. Es besteht die Gefahr von Über- und Fehlspezifikation. Vielmehr sollten dann ein iterativ-inkrementelles Vorgehen gewählt werden, das adaptiv und flexibel ist (Agilität). Aufgrund ihrer Abstraktheit, Komplexität und Neuartigkeit fallen IT-Produktentwicklungen häufig in diese Kategorie. Abbildung 55: Einordung des Projekt-Kontextes Iterativ-inkrementelle Vorgehensmodelle … − beschreiben eine Produktentwicklung der kontinuierlichen Verbesserung, bei denen häufig in kleinen Schritten vorgegangen wird. − sind die Basis für die agile Softwareentwicklung. − definieren den Endzustand in der Regel nicht à priori, das Produkt wächst organisch. − sind ein zyklischer Entwicklungsprozess. Begriffe: − Iterativ: Zeit für laufende Revision und Verbesserung der Teile des Systems ist vorgesehen, Lernen aus Erfahrungen. − Inkrementell: Teile des Systems werden zu unterschiedlichen Zeiten entwickelt und sind grundsätzlich produktiv nutzbar. <?page no="66"?> 66 Takt 2: Projektplanung Abbildung 56: Das Spiralmodell Typische Vertreter sind das Spiralmodell, Scrum, eXtreme Programming, Prototyping etc. Dazu später mehr … und jetzt ein kleines Quiz: ▲ Quiz ‒ Richtig oder falsch? „Das iterativ-inkrementelle Vorgehen ermöglicht eine möglichst effiziente Produktentwicklung.“ „Das iterativ-inkrementelle Vorgehen ermöglicht eine effektive Produktentwicklung um unsicheren Kontext.“ 2.1.2 Minimum Viable Product Die Idee des MVP bedeutet, dass vermieden werden soll, dass ein Produkt aufwendig realisiert wird, dann aber keinen Markt findet bzw. keinen Nutzen erzeugt. Es sollen hingegen Zeit, Arbeit und Geld gespart werden. Durch den iterativen Prozess des Validierens und des Lernens (engl. „validate and learn“) wird zu einem möglichst frühen Zeitpunkt das richtige Produkt Stück für Stück gefunden. Es wird vermieden, „den Goldrand“ der Lösung bereits mit der (ersten) Spezifikation einzubauen. Abbildung 57: Minimum Viable Product 32 2.1.3 Produktvision  In einem agilen Umfeld braucht jedes Produkt oder Projekt eine Vision, denn sie ist das Einzige, was stabil bleibt und damit Halt und Orientierung im kontinuierlichen Wandel bietet. 32 nach Voorhorst, 2023 Analyse Entwurf Implementierung Betrieb <?page no="67"?> 2.1 Requirements Management 67  Die Produktvision dient insbesondere der Orientierung des Teams und der gemeinsamen Ausrichtung auf ein Ziel.  Bevor das Produkt in die Entwicklungsphase geht, sollte die Produktvision klar und akzeptiert sein. Bei der Erarbeitung der Produktvision ist es hilfreich, sich an folgenden Fragen zu orientieren: Abbildung 58: Fragen zur Produktvision Satzschablone für die Produktvision Um natürlich-sprachliche Ungenauigkeiten zu verringern, bietet sich die Verwendung einer systematischen Satzschablone nach Moore an: 33 Für <Zielkunde/ Nutzer>) der <Bedürfnis oder Gelegenheit> ist das <Produktname> ein <Produkt-Kategorie> das <Hauptvorteile, Grund der Kauf-/ Nutzenentscheidung>. Anders als <Konkurrenz-/ Alternativprodukte> bietet unser Produkt <Hauptunterschiede zur Konkurrenz/ bisherigen Lösung>. Abbildung 59: Satzschablone für die Produktvision Beispiel für ein internes IT-Projekt: 34 Für den Kundendienst der ABC GmbH, der wegen ineffizienter Prozesse zu langsam auf Kundenanfragen reagiert, 33 nach Online Projektmanagement, o.J., angepasst 34 nach Grave, 2012, angepasst Wer ist die Zielgruppe? Warum sollte diese Zielgruppe das Produkt nutzen wollen? Welche Nutzerbedürfnisse sollen mit dem Produkt befriedigt werden? Was sind die Mindestkriterien, die erfüllt sein müssen, damit das Produkt erfolgreich bei der Zielgruppe platziert werden kann? Was unterscheidet das Produkt von den Produkten im Markt? Was sind wesentliche Eigenschaften, die sich unterscheiden und die Kunden vom Kauf überzeugen können? Wie sehen Zeit und Budgetrahmen für das Projekt aus? Gibt es kritische Meilensteine, die zu erreichen sind? Für <Zielkunde/ Nutzer> der <Bedürfnis/ Gelegenheit > ist das <Produkt> ein <Produkt- Kategorie> das <Vorteile/ Grund> Anders als <Alternativprodukt> bietet unser Produkt <Hauptunterschiede> <?page no="68"?> 68 Takt 2: Projektplanung ist XYZ eine CRM-Lösung, mit der Kundenanfragen zukünftig innerhalb garantierter Antwortzeiten erledigt werden. Anders als Standardlösungen wie Salesforce oder Siebel ist unsere Eigenentwicklung in alle relevanten Backend-Systeme integriert. ▲ Formulieren Sie doch einmal eine Produktvision aus Ihrem Hause mithilfe dieser Satzschablone. Vielfach wird auch alternativ ein Produktvisions-Tableau (Product Vision Board) eingesetzt: 35 Abbildung 60: Satzschablone für die Produktvision 2.1.4 User Stories User Stories dienen zur Operationalisierung der Produktvision. Sie … … sind leichtgewichtige Formulierungen von Anforderungen, … betonen besonders den Nutzen des Anwenders, … sind in agilen Vorgehensmodellen (Scrum) entstanden, … sind im Allgemeinen nicht detailliert genug für eine unmittelbare Umsetzung → ergänzende Engineering-Elemente, wie Use Case-Diagramme o.ä. sind nötig. Satzschablone für eine User Story: Als <Rolle> möchte ich <Ziel/ Wunsch>, um <Nutzen> Abbildung 61: Satzschablone für eine User Story ▲ Formulieren Sie doch einmal eine Anforderung aus Ihrem Umfeld in Form einer User Story! 35 nach Pichler, o.J., angepasst Vision Was ist der Zweck dahinter, dieses Produkt zu entwickeln? Welche positive Veränderung sollte es mit sich bringen? Zielgruppe Welchen Markt oder Marktsegment adressiert das Produkt? Wer sind die Zielkunden und -nutzer? Bedürfnisse Welches Problem löst das Produkt? Welchen Nutzen stellt es bereit? Produkt Welches Produkt ist es? Was macht es besonders? Ist es machbar, das Produkt zu entwickeln? Geschäftsziele Wie wird das Produkt Nutzen für das Unternehmen generieren? Was sind die Geschäftsziele? Wettbewerb Wer sind die größten Wettbewerber für das Produkt? Was sind ihre Stärken und Schwächen? Als <Rolle> möchte ich <Ziel/ Wunsch> um <Nutzen> <?page no="69"?> 2.1 Requirements Management 69 Systematische Requirements Management - Fazit Für die Abwicklung komplexer Projekte ist ein koordiniertes Vorgehen unumgänglich. Das RE schafft dabei eine gemeinsame Basis der relevanten Stakeholder bzgl. der Anforderungen an eine Lösung: Abbildung 62: Prozess des Requirements Management Bei linearen Vorgehensweisen wird angestrebt, zu Beginn alle Anforderungen vollständig zu beschreiben. Bei iterativ-inkrementeller bzw. agiler Vorgehensart ist das RE ein kontinuierlicher, phasenübergreifender Prozess. Die Produktvision tritt gegenüber einer detaillierten Dokumentation in den Vordergrund. Die Wahl des Vorgehens sollte sich am Projektkontext orientieren und dabei die Unsicherheit bezüglich des Vorgehens und der Lösung berücksichtigen. 2.1.5 Atmender Scope − Neues Verständnis der Scope-Festlegung Die Flexibilisierung der beauftragten Leistung erfordert nicht zuletzt auch die Flexibilisierung des vereinbarten Umfangs des Projekts. Anstatt eines starren, bereits durch den Projektauftrag final festgelegten Scope sollte hier ein dynamischer sog. Backlog von Anforderungen genutzt werden, d.h. ein in Grenzen veränderbarer atmender Scope . Der Begriff wird im Folgenden erläutert, wozu auch die MuSCoW-Regel und das Target Value Design/ Engineering Eingang finden. Die Festlegung des Scope eines Projekts, also des Umfangs in Tiefe und Breite, ist eine zentrale Aufgabe innerhalb der Projektinitialisierung und damit des Projektauftrags. Hier wird festgelegt, welche Funktionalitäten (z.B. Einführung eines ERP-Logistik-Moduls) in welchem organisatorischen Kontext (z.B. alle produzierenden Landesgesellschaften) in ggf. welcher Ausgestaltung (z.B. automatisierte Lieferantenintegration) Gegenstand des Projekts sind. Je einfacher der Projektkontext ist und je stabiler dessen Bedingungen sind, desto fixer kann der Scope gestaltet werden. Je komplexer und damit zeitlich unvorhersehbarer der Projektgegenstand ist, desto stärker wird ein starrer Scope die positive, nutzen- und kostengerechte Entwicklung des Projekts behindern. Die folgende Abbildung zeigt eine nicht selten anzutreffende Projektentwicklung hinsichtlich der Kosten auf, die es zu vermeiden gilt. Abbildung 63: Häufiger Verlauf der Entwicklung eines Projekts Anforderungen ermitteln Anforderungen dokumentieren Anforderungen freigeben Anforderungen verwalten Produkt- Vision Anforderungs- Dokument <?page no="70"?> 70 Takt 2: Projektplanung Es stellt sich daher die Aufgabe, das Scope-Management - nicht zuletzt auch in Kundenprojekten - so zu gestalten, dass sich für das Projektmanagement sinnvolle Gestaltungsfreiräume ergeben, die es ermöglichen, das Projekt erfolgreich zum Ziel zu führen. Dies motiviert die Idee eines atmenden Scope im Stile eines Girokontos, zu dessen Realisierung im Folgenden zwei wichtige Methoden vorgestellt werden. Die MuSCoW-Systematik zur überwiegend fachlichtechnischer Priorisierung der Anforderung wird ergänzt um das Target Value Design, das die Priorisierung um den Blickwinkel des Nutzen-Kosten-Verhältnisses erweitert. Kombiniert man diese beiden Methoden, erhält man ein innovatives Management des Scope im Sinne des wertschöpfungsorientierten Lean PM. Agile Vorgehensweisen postulieren eine fortlaufende (Re-)Priorisierung und Konkretisierung der Requirements. Zur Erhöhung der Flexibilität in der Umsetzung sollten Anforderungen durch entsprechende Formulierung hinsichtlich ihrer Verbindlichkeit klassifiziert werden. Abbildung 64: Klassifizierung von Anforderungen Die MuSCoW-Systematik Um Flexibilität in der Abarbeitung des Projekt-Scope zu erreichen, ist es wichtig, dass der entsprechende Leistungskatalog der Funktionalitäten (Pflichtenheft) oder Anforderungen (Lastenheft), die in großen Projekten mehrere Tausend Positionen beinhalten können, priorisiert wird. Vielfach ist jedoch zu beobachten, dass solche Leistungskataloge ein solche Priorisierung vermissen lassen, was z.B. in Kundenprojekten, die als Werkverträge zum Festpreis abgewickelt werden, regelmäßig dazu führt, dass umfangreiche Change Request die Kosten erhöhen, die Fertigstellungstermine schieben und nicht zuletzt Management-Kapazität im Vertrags- oder Claim- Management binden, die im Projekt anders zielführender eingesetzt werden könnte. Vielfach sind solche unpriorisierten Leistungskataloge in öffentlichen Ausschreibungen zu beobachten. Die MuSCoW-Systematik liefert eine praktikable Regel der Priorisierung der Positionen des Projekt-Scopes. MuSCoW steht für Must-Have , Should-Have , Could-Have und Won’t-Have , womit die einzelnen Positionen des Leistungskatalogs klassifiziert werden. Must-Have-Anforderungen … sind für die Lösung fachlich-technisch unabdingbar. Ohne ihre Umsetzung bringt die Lösung keinen Nutzen, sie funktioniert schlichtweg nicht. Sie definieren MUSS • verpflichtend umzusetzen • kritisch für Funktionsfähigkeit • abnahmeverhindernd WIRD • verpflichtend umzusetzen • ggf. in Folgeiteration SOLLTE • kritisch für die Zufriedenheit der Stakeholder • nicht verpflichtend • in der Regel einkalkuliert • nicht unmittelbar abnahmerelevant KANN • optional • erhöht die Zufriedenheit der Stakeholder • nicht abnahmerelevant Stakeholder-Zufriedenheit <?page no="71"?> 2.1 Requirements Management 71 also die Minimalanforderungen an die Lösung, etwa das Produkt, was auch mit Minimal Usable SubSeT, MUST, eingänglich beschrieben wird. 36 Die produktbezogene Teilmenge hiervon ist auch als Minimum Viable Product , MVP, bekannt. Ihre Umsetzung ist im Grunde nicht verhandelbar. Beispiel: die Bremsen eines Autos. Should-Have-Anforderungen … sind nicht unmittelbar notwendig für die Funktionsfähigkeit der Lösung, haben aber eine signifikante Relevanz für die Erzielung des Projektnutzens. Ggf. gibt es bei Fehlen kurzzeitige Abhilfemaßnahmen. Bei entsprechend verfügbaren Mitteln (Zeit, Geld, Kapazität) sollten sie Sicherstellung der Kundenzufriedenheit umgesetzt werden. Beispiel: das Automatikgetriebe eines Autos. Could-Have-Anforderungen … können einfacher ausgeschlossen werden, da sie eine geringe Relevanz für die generelle Funktionsfähigkeit der Lösung haben. Sie werden auch als Nice-to- Have bezeichnet. Ggf. gibt es bei Fehlen einfache und auch dauerhafte Abhilfemaßnahmen. Sie stellen im Verlaufe des Projekts die nahestliegende Verhandlungsmasse im Management des Scope dar und dienen insbesondere als Tauschpositionen bei der Bewertung und Einplanung von Change Requests. Allerdings sollte hierbei nicht ganz außer Acht gelassen werden, dass gerade diese Nice-to-Have-Elemente als Begeisterungsfaktoren einen wichtigen Beitrag zur Kundenzufriedenheit leisten können, wie das Kano-Modell aufzeigt. 37 (Diesbezüglich sind grob die Must-Have-Elemente mit den sog. Basisfaktoren und die Should-Have-Elemente mit den Leistungsfaktoren in Sachen Kundenzufriedenheit zu vergleichen.) Won’t-Have-Anforderungen … werden in der konkreten Projektplanung nicht umgesetzt. Sie dennoch im Leistungskatalog aufzuführen ist optional und bietet zumindest den Vorteil, dass bei möglichen Verschiebungen der Prioritäten und/ oder Möglichkeiten auf sie zurückgegriffen werden kann. Ferner dienen sie beim Management der Erwartungen zur aktiven Abgrenzung dessen, was im Projekt umgesetzt wird und was nicht. Die folgende Abbildung fasst die Logik der MuSCoW-Systematik mit Blick auf den aktiven Scope grafisch zusammen. Abbildung 65: Atmender Scope mit der MuSCo(W)-Regel Dabei kann das MVP im Allgemeinen nicht mit dem MUST gleichgesetzt werden, da im Leistungskatalog eines Projekts auch Positionen aufzunehmen sind, die nicht mit dem reinen Produkt zu tun haben - etwa Services. Dies gilt natürlich insbesondere für Projekte, die nicht der Produktentwicklung dienen, wie z.B. Organisationsprojekte. 36 s. Agile Business Consortium 2019, S. 70 37 s. z.B. Jochem 2019, S. 57-61 <?page no="72"?> 72 Takt 2: Projektplanung Es entsteht ein Scope in der Logik eines Girokontos, d.h. die Entwicklungen im Projekt, insbesondere Changes, können zu Gunsten oder Lasten des Scope-Kontos verbucht werden. Mit der Definition entsprechender Toleranzen (vgl. Überziehungsrahmen) ergeben sich für das operative Projektmanagement Handlungsspielräume. In agilen Vorgehensweisen erfolgt sogar eine fortlaufende Priorisierung und Gestaltung des sog. Project Backlogs (also des Leistungskatalogs) und der Change wird als immanenter Bestandteil der Projektsteuerung eingeplant. Dies erscheint zumindest in externen Kundenprojekten, die über einen Vertrag begründet werden, schwierig, insbesondere, wenn es sich um einen Festpreisvertrag handelt. 38 Hier bietet vielmehr die MuSCoW-Systematik einen praktikablen Rahmen … und ist damit unabhängig von der Frage, ob es sich um ein (internes) Investitions- oder ein (externes) Kundenprojekt handelt. Insbesondere in letzter Konstellation erweist sich die MuSCoW-Systematik als praktikabel und hilfreich. ��� Die Klassifizierung der Requirements verschafft auch im plangetriebenen Ansatz Freiheiten im Management - ein „atmender Scope“ entsteht. Die Veränderung der Scope-Definition für Projekte durch Klassifizierung der Requirements dient als Voraussetzung für Flexibilität, Nutzen-Optimierung und Timeboxing im Sinne einer agilen (Projekt-)Organisation. Target Value Design Target Value Design (TVD, Zielwertgestaltung) wurde vor einigen Jahren für Bauprojekte entwickelt. 39 Es ist die Adaption des Target Costing-/ Zielkostenrechnung-Ansatzes der stationären Industrie auf Projekte. Die Zielkostenrechnung stellt den gewünschten Marktpreis und damit die Kunden in den Mittelpunkt der Entwicklung. Sie beantwortet anhand einer retrograden Kalkulation die Frage, wieviel ein Produkt kosten darf. Dadurch unterscheidet sie sich von der traditionellen Kostenkalkulation, der Kosten-Plus-Rechnung − also Kosten + Margenvorgabe = Angebotspreis . Durch die Zielkostenrechnung wird insbesondere versucht, Kundenorientierung hinsichtlich kundenspezifisch geforderter Produkteigenschaften bzw. -funktionen zu verwirklichen. Sie eignet sich damit besonders für die Entwicklung komplexer Produkte, die in mittleren Losgrößen gefertigt werden. Diesen Gedanken greift das TVD auf. Es erweitert das klassische Magische Dreieck um den Aspekt des Wertes von Lösungselementen für den Kunden. Dazu folgendes Beispiel zur Verdeutlichung des Unterschieds zwischen Zweck (Sinn/ Nutzen) und Projektauftrag (/ -gegenstand): • Zweck: Reduktion der Zeit für die Fahrt von Punkt A nach Punkt B • Projektauftrag: Bau einer Brücke (… Seilbahn, … Fähre etc.) Im Folgenden werden die Kernelemente und die Anwendung des TVD erläutert und dabei auf beliebige Arten von Projekten übertragen. Wert und Nutzen - eine Begriffsklärung In der Literatur ist ein einheitliches Begriffsverständnis nicht zu finden. Der vielfach englischsprachige Ursprung relevanter Veröffentlichungen erschwert zudem durch die vorwiegende Verwendung des Begriffs Value die Differenzierung. An dieser Stelle wird ein Versuch dazu mit Blick auf die Projektdomäne unternommen: Eine Wirkung beschreibt grundlegend eine tatsächliche oder erwartete Veränderung durch ein neues oder verändertes System im Vergleich zur Ausgangssituation. Der Wertbeitrag bezeichnet die monetäre Bewertung einer erfassten Wirkung. 40 38 vgl. Opelt et al., 2014 39 s. Ballard, 2012 40 vgl. Schütte et al., 2019, S. 116 <?page no="73"?> 2.1 Requirements Management 73 Der Nutzen beschreibt dagegen allgemein die Fähigkeit eines Projektergebnisses, bestimmte Bedürfnisse eines oder mehrerer Stakeholder zu befriedigen, 41 z.B. den sog. Job-to-be-done . Er ist damit eine nicht nur monetär zu erfassende, als Vorteil betrachtete Wirkung des Projekts. Als Nutzwert bezeichnen wir das Maß, in dem der (ideale) Nutzen für einen Stakeholder erreicht wird. Er ist damit der durch die Tauglichkeit zur Bedürfnisbefriedigung (den Nutzen) bestimmte subjektive, monetär oder nicht-monetäre quantifizierte Wert eines Projektergebnisses. In einer weiten Auslegung des Begriffs Wert-Schöpfung im Kontext des Lean PM beziehen wir uns damit auf den Nutzwert, in einer engeren auf den (monetären) Wertbeitrag. TVD beginnt in der Initiierungs- und Vorbereitungsphase eines Projektes, in der die Rahmenbedingungen für das Projekt festgelegt werden und in den Projektauftrag münden. Dabei wird - basierend auf dem Zweck des Vorhabens − zunächst der Wert für den Kunden identifiziert, also der Nutzen, den der Kunden aus der Lösung ziehen will und der hinter der konkreten Lösung ersteht. So kann z.B. bei einem Infrastrukturprojekt ermittelt werden, ob für den Kunden eher Kostenoptimierung, Prestige (Leuchtturmprojekt), Nachhaltigkeit, Funktionalität, Rendite oder Mitarbeiterbindung im Vordergrund steht, also einen primären Wert darstellt. Beispielsweise hat der Bau der Elbphilharmonie gezeigt, dass die Kosten sich zwar verzehnfacht haben (Abwicklungsproblem), aber das Resultat aufgrund seiner Strahlkraft für die Auftraggeber als Erfolg bewertet wird (Anwendungserfolg). Die Werte werden nun auf Funktionen des Lösungsspektrums übertragen. In der Wertanalyse werden die Funktionen durch den Auftraggeber priorisiert (z.B. durch Paarvergleich). Auf die Wertanalyse folgt die (grobe) Kostenermittlung für Elemente, z.B. Funktionalitäten, verschiedener Lösungsmöglichkeiten. Hier sollte keine zu frühe Einschränkung alternativer Lösungsmöglichkeiten erfolgen. Die Kosten werden ermittelt und wieder die damit verbundenen Lösungen priorisiert. Es entsteht eine Kosten-Nutzwert-Matrix: Abbildung 66: Kosten-Nutzenwert-Matrix Mit der dieser Matrix zu entnehmenden Priorisierung ist die Basis für ein reales Werte-Engineering gelegt: Es liegen also bereits zu Beginn des Projekts in der Produktentwicklungsphase für das Team bindende Kostenvorgaben mit steuerndem Charakter vor, die in jeder Stufe des 41 vgl. Hedemann/ Segers 2012, S. 196 <?page no="74"?> 74 Takt 2: Projektplanung Projekts maßgeblich beeinflusst werden können. Über die Ermittlung der Präferenzen liegt eine Gewichtung der Kosten gegenüber der Wichtigkeit der verschiedenen Produkteigenschaften vor und es kann im Verlauf des Projekts ermittelt werden, ob eine Produktkomponente oder -funktion ggf. überentwickelt wird oder noch Wertsteigerungspotenzial besteht. Die Kardinalregel des TVD lautet: Die Zielkosten der Lösung können niemals überschritten werden! Das bedeutet in der Umsetzung: - Sicherstellen, dass unabhängig davon, welche Zielkosten irgendwo in der Lösung steigen, die Kosten an anderer Stelle um einen entsprechenden Betrag gesenkt werden, ohne dass Anwendung und Qualität beeinträchtigt werden. - Die Weigerung, einem Projekt, das die Zielkosten überschreitet, zusätzlichen Umfang (Scope) zu geben. - Management des Übergangs von der Planung zur Realisierung, um sicherzustellen, dass die Zielkosten niemals überschritten werden. Prozess des Target Value Design: ► Entwickeln Sie Entwurfskriterien aus Werten und Werte aus Zwecken. ► Klären Sie, wie die Lösung genutzt werden soll, bevor Sie die Lösung entwerfen. ► Engagieren Sie wichtige Mitglieder des Projektabwicklungsteams, um bei der Validierung und Verbesserung von Projektgeschäftsplänen (Business Case) zu helfen. ► Geben Sie an, was Sie ausgeben können und wollen, um zu bekommen, was Sie wollen. ► Zielwerte und Einschränkungen werden als Streckziele festgelegt, um die Innovation zu fördern. ► Der Entwurf wird auf Ziele hingelenkt, indem ein Set-based Design-Ansatz verwendet wird, bei dem Alternativen anhand von Zielen bewertet werden und Entscheidungen im letzten verantwortlichen Moment getroffen werden. ► Benutzer erstellen anhand eines integrierten Modells Anweisungen für die Verwendung des Entwurfs (Kauf, Genehmigung, Herstellung, Installation, Inbetriebnahme). Zusammenfassend lässt sich nach Ballard sagen: 42 Target Value Design ... ist eine Managementpraxis, die das Projekt so steuert, dass es Werte für den Kunden liefert und die Lösungen innerhalb der Projektbeschränkungen entwickelt. erfordert ein grundlegendes Umdenken von erwarteten Kosten zu Zielkosten. erfordert notwendigerweise funktionsübergreifende Teams. Keine einzelne Person verfügt über das gesamte Wissen. verlangt nach einem integrierten Produkt-/ Prozess-/ Kostenmodell. Mit dem TVD lässt sich nicht zuletzt das wertorientierte Magische Dreieck des Projektmanagements operationalisieren. Weighted shortest Job first Die Regel des Weighted shortest Job first , WSJF, ist eine Variante der Ermittlung eines vergleichenden Kosten-Nutzen-Verhältnisses einer Aufgabe. Die Kennzahl WSJF wird vielfach im Rahmen der Priorisierung von Backlog-Positionen eingesetzt, nicht zuletzt auch auf der Ebene der Features einer angestrebten oder weiterzuentwickelnden Lösung. Sie setzt die Opportunitätskosten mit dem Aufwand der Erstellung in Beziehung und berechnet sich wie folgt: WSFJ = Opportunitätskosten / Job-Dauer 42 s. Ballard 2012, S. 3 <?page no="75"?> 2.1 Requirements Management 75 Abbildung 67: Weighted Shortest Job First (WSJF) Mit den Opportunitätskosten geht die WSJF-Kennzahl damit den Weg, die Kosten einer Verzögerung, also des Unterlassens der Entwicklung, einzubeziehen. Diese berechnen sich als Summe aus Nutzwert für den Kunden plus Zeitkritikalität plus Risikoreduzierung (Wert neuer Erkenntnisse): Nutzwert (Im Original) Geschäftswert, z.B. Steigerung von Umsatz oder Reduzierung von Kosten. Zeitkritikalität Einfluss einer bestimmten Deadline auf den Wert, z.B. das Abspringen von Kunden, wodurch das Erledigen der Aufgabe ggf. wertlos wird. Risikowert Möglichkeit für Risikoreduzierung und Chancen. Riskantere Aufgaben sollten nach Reinertsen früher angegangen werden als weniger riskante. Diese Größen werden jeweils in einer zu wählenden Likert-Skala, etwa von 1−10, ausgedrückt, ebenso wie die Dauer, die ermittelt wird, um den Job zu erledigen (in der Regel mit Personalaufwand zusammenhängend). Dadurch wird für die verschiedenen zur Auswahl stehenden Aufgaben im Backlog der WSJF-Wert ermittelt, der zu einer Rangfolge der Aufgabenerledigung führt. Für den Prozess der Anwendung ergibt sich dann folgendes Schema: 1. Schätzen Sie die Größe der Backlog-Positionen ab. 2. Die Werte der Backlog-Positionen schätzen. 3. Berechnen Sie die WSJF-Indexwerte. 4. Planen und steuern Sie Ihren Arbeitsvorrat gemäß der WSJF-Priorisierung. Aufgrund der Konstruktion der WSJF-Kennzahl lässt sich leicht ein Zusammenhang mit dem TVD herstellen. Beide Verfahren nutzen im Kern den Nutzwert, den ein Feature für den Kunden darstellt. In diesem Sinne könnte man das Kosten-Nutzen-Verhältnis, dass sich im Rahmen des TVD ergibt und die daraus abzuleitende Priorisierung der Positionen als Valued cheapest Job first (VCJF) bezeichnen lassen - der Nutzwert für den Kunden wird hier durch die erwarteten Kosten eines Features geteilt. Wie diese Namenabwandlung erkennen lässt, macht die Unterscheidung insbesondere auch der Fokus auf die Kosten einerseits (VCJF) und die Dauer der Realisierung anderseits (WSJF) aus. Welche Variante letztlich im Projekt zum Einsatz kommen sollte, hängt daher von dessen Gegenstand ab. So verlangt die Markteinführung eines neuen Produktes sicherlich eine starke Fokussierung auf die Zeitkomponente, während ein internes Organisationprojekt wohl primär die Kosten im Auge hat (auch wenn das ggf. eine zu starke Verkürzung der Sachverhalte darstellt). <?page no="76"?> 76 Takt 2: Projektplanung 2.1.6 Lösungen ▲ Quiz ‒ falsch oder richtig? „Das iterativ-inkrementelle Vorgehen ermöglicht eine möglichst effiziente Produktentwicklung.“ → Falsch! Das iterativ-inkrementelle, agile Vorgehen ist nicht auf maximale Effizienz ausgerichtet. Im schlechtesten Fall kann es auch als „Trial & Error“ angesehen werden. „Das iterativ-inkrementelle Vorgehen ermöglicht eine effektive Produktentwicklung um unsicheren Kontext.“ → Richtig! Vielmehr ist hier im Fokus, möglichst gut die Kundenanforderungen zu treffen. Damit ist das Vorgehen primär auf Effektivität ausgerichtet. 2.2 Projektstrukturplanung Zur Einführung in das Thema steht Ihnen wieder ein Video zur Verfügung. ► Video 2.3 (Projektstrukturplanung), URL: https: / / youtu.be/ tEmX_Z1YNVI „Ja, mach nur einen Plan und sei ein großes Licht, Und mach dann noch 'nen zweiten Plan; Geh´n tun sie beide nicht.“ Dieses Zitat aus der Dreigroschenoper von Bert Brecht (Peachums Drehorgellied) bringt es auf den Punkt: Jeder Plan ist dazu „verurteilt“, im Laufe seiner Umsetzung angepasst zu werden. Im Sinne des Durchdenkens der Aufgabe lässt sich aber feststellen: Der Plan ist nichts - Planung ist alles! “. Bedeutung der Planung  Systematisierung: mit der Zukunft auseinandersetzen; analysieren, auch bei unvollständiger Information  Prognose zukünftiger Entwicklungen: Risiken und Chancen rechtzeitig erkennen  Machbarkeit?  Umsetzbarkeit? Sie dient damit der Identifikation einer möglichen Route auf dem Weg durch das Projekt. Und damit im Rahmen der späteren Steuerung des Projekts als Orientierung und Maßstab: Abbildung 68: Planung als Ausgangsbasis für die Projektsteuerung <?page no="77"?> 2.2 Projektstrukturplanung 77 Steht man vor der Aufgabe, ein Projekt auf dem Papier quasi aus dem Nichts zu planen, so erscheint dies nicht selten als gigantische Aufgabe. Es besteht die Notwendigkeit der Projektstrukturierung: Mit dem Projektstrukturplan wird das Ziel der Verminderung der Komplexität durch Aufteilung verfolgt. 2.2.1 Projektstrukturplan Laut ICB versteht man unter Projektstrukturierung die Gliederung eines Projektes nach seinen Arbeitsinhalten und -aufgaben. Der Projektstrukturplan (PSP) ist die grafische oder tabellarische Darstellung der Projektstrukturierung. Ein PSP besteht im Wesentlichen aus: • Arbeitspaketen • Teilaufgaben Abbildung 69: Aufbau eines Projektstrukturplans 43 43 Schlick, 2015 benötigt ist gegliedert in zuständig kann gegliedert sein in leitet OE 1 OE 2 OE m Projekt Teilaufgabe 1 Teilaufgabe 1.1 … … Teilaufgabe n Arbeitspaket 1 Arbeitspaket 2 … Arbeitspaket m Personal Sachmittel Betriebsmittel Material … Projektleiter mitwirkend ist gegliedert in Einsatzmittel OE: Organisationseinheit <?page no="78"?> 78 Takt 2: Projektplanung Definition Projektstrukturplan (DIN 69901-5: 2009) Der Projektstrukturplan ist die „vollständige, hierarchische Darstellung aller Elemente (Teilprojekte, Arbeitspakete) der Projektstruktur als Diagramm oder Liste.“ Ziele des PSP (engl. Work Breakdown Structure): − Gesamtüberblick über alle Aufgaben (Arbeitspakete) des Projekts zur Schaffung eines gemeinsamen Verständnisses − Reduktion der Komplexität − Schaffung von Transparenz ��� PSP = „Mutter der Projektplanung“: − Grundlage für sämtliche nachgelagerten Planungen (Ablauf/ Termine, Ressourcen, Kosten usw.) − Grundlage für die Steuerung der Projektdurchführung Auch die Projektmanagementaufgaben werden im PSP definiert … schließlich benötigen sie Kapazität und kosten auch Geld. Die folgende Abbildung zeigt einen typischen PSP für ein Software-Projekt: 44 Abbildung 70: PSP für ein Software-Projekt 44 Wehnes, 2014 <?page no="79"?> 2.2 Projektstrukturplanung 79 Ein weiteres Beispiel zeigt das Projekt eines Webseiten-Relaunches: 45 Abbildung 71: PSP eines Webseiten-Relaunches ▲ Fällt Ihnen auf, was fehlt? Aufgaben, die den PSP untergliedern, nennt man Teilaufgaben (TA). Die Projektstrukturplanung hängt wesentlich von der Größe des Projekts ab. Typische Merkmale sind dabei: Kleine Projekte • Einfache Arbeitspaketstruktur Mittlere Projekte • Phasenorientierung • Mehrstufige MA-Struktur Große Projekte • Projektorganigramm (Teilprojekte etc.) • Stabsstellen • Planungsarchitektur 45 http: / / inf-schule.de/ vernetzung/ projektemercatus/ projekte/ website_relaunchT2/ soll-k, online 06.10.2015 <?page no="80"?> 80 Takt 2: Projektplanung 2.2.2 Arbeitspakete Die hierarchisch niedrigsten Positionen in einem PSP heißen Arbeitspakete (AP). Sie bilden traditionell die fachlich-organisatorischen Aufgabenbündel zur Abarbeitung der Projektinhalte und sind typischerweise die Blätter im baumartigen Projektstrukturplan. 46 Definition Arbeitspaket „Ein AP ist der Teil eines Projektes, der im PSP nicht weiter aufgegliedert ist und auf einer beliebigen Gliederungsebene liegen kann.“ (DIN 69 901) „Das Arbeitspaket dient zur Operationalisierung der Erstellung eines oder mehrerer Produkte/ Projektergebnisse. Es enthält eine Beschreibung der durchzuführenden Arbeiten, erwarteten Ergebnissen, Einzelheiten aller Einschränkungen, die bei der Produktion zu beachten sind. Es dokumentiert die Vereinbarung zwischen der Projektleitung und der Person bzw. dem Team-Manager, die/ der für die Durchführung des Arbeitspakets zuständig ist, dass die Arbeiten innerhalb der gesetzten Einschränkungen erledigt werden können.“ (nach PRINCE2) Auf Ebene der Arbeitspakete erfolgt die Budget- und Kapazitätsschätzung und -zuweisung sowie das Fortschritts-Controlling. Jedes Arbeitspaket (AP) ist eine klar abgegrenzte und in sich geschlossene Einheit. Zur Definition eines AP ist folgendes unbedingt notwendig: • Ziel des AP (notwendige Ergebnisse) • Verantwortlicher für das AP • Voraussetzungen zum Start des AP • Rahmenbedingungen (Termine, Kosten, beteiligte Mitarbeiter, …) Die Bildung von AP orientiert sich insbesondere an den vertraglichen Liefergegenständen (Produkten) des Projektes, sowie ergänzend weiterer relevanter (Zwischen-)Ergebnisse. Beispiele • AP x: „Erstellung Fachkonzept ‚Zentrale Beschaffung‘“ • AP y: „Zulieferung Prozess Beschaffung zum Berechtigungskonzept“ Sinnvolle Dimensionierung (am Beispiel Org./ IT-Projekte): Arbeitspakete … • … haben ca. eine Größe von ca. 15 - 25 Personentagen (PT), • … werden (im Rahmen der Projektablaufplanung) untergliedert in Einzelvorgänge/ Aktivitäten im Umfang von 1-2 Kalenderwochen, • … umfassen max. 10% des Gesamtprojekts (zeitlich, budgetmäßig). ��� Der Projektleiter und der AP-Verantwortliche definieren das AP . Bei einer phasenorientierten Planung muss ein AP innerhalb einer Phase liegen (Ausnahme: phasenübergreifende Aufgaben wie z.B. Controlling). 46 s. Ottmann et al., 2008, S. 163-174 <?page no="81"?> 2.2 Projektstrukturplanung 81 Abbildung 72: Arbeitspakete in der phasenorientierten Planung Detaillierungsgrad der Arbeitspakete (APs) • eindeutig beschriebenes Ergebnis/ Verantwortung • Handhabbar in der Steuerung/ Kontrolle • i.d.R. Darstellung als Baumstruktur mit überschaubarer Anzahl von Ebenen • Kompetenz der Verantwortlichen Die Ausplanung von AP sollte in drei Schritten geschehen: 1. Identifikation und Definition 2. Inhaltliche Ausgestaltung (inkl. Abhängigkeiten) und 3. Aufwandsermittlung und -abstimmung. Dies alles im zyklischen Zusammenwirken von Projektleitung und Ausführungsverantwortlichen, ggf. in 2…3 Iterationsschleifen. Dabei werden nicht zuletzt die durchzuführenden Aktivitäten (Tasks) identifiziert und geplant. Eine Faustregel besagt, dass es jedenfalls hilfreich wäre, wenn die Dauer von AP 1 bis 2 Wochen nicht überschreiten sollte. Damit können in agilen Vorgehensweisen auch Sprint-Inhalte und AP übereinstimmen. 2.2.3 Vorgehen zur Aufstellung eines Projektstrukturplans Grundsätzlich kann bei der Aufstellung eines PSP Top-Down oder Bottom-Up vorgegangen werden: Abbildung 73: Vorgehen bei der PSP-Erstellung Mit der jeweiligen Stoßrichtung lassen sich verschiedene Vor- und Nachteile verbinden: <?page no="82"?> 82 Takt 2: Projektplanung Abbildung 74: Vorgehen der Projektstrukturierung In der Praxis hat es sich daher bewährt, im Gegenstromverfahren beide Stoßrichtungen zu kombinieren − solange, bis ein qualitativ ansprechender PSP erarbeitet ist. ��� Abschließend einige Tipps zur Projektstrukturplanung: ► Projektstrukturplanung im Team durchführen. ► Einheitliche Terminologie und gemeinsames Verständnis finden. ► Verantwortung für AP an Einzelpersonen vergeben. ► Nur so detailliert planen, bis überschaubare und kontrollierbare Arbeitspakete vorliegen. ► Vollständigkeitsprüfung durchführen! ► Kontrollfrage: „Wenn alle APs abgearbeitet sind, sind damit auch alle geplanten Projektergebnisse erreicht? “ ► Projektmanagement-APs nicht vergessen! 2.2.4 Aufwandsermittlung Die Arbeitspakete sind die Träger des Arbeitsaufwands im Projekt. Der Aufwandsschätzung kommt bei der Ausgestaltung der Arbeitspakete daher eine große Bedeutung zu. Arbeitspakete sind die Projektpositionen für Ressourcenallokationen:  Aufwände → Einsatz Mitarbeiter und Externe  Dauern (ggf.)  Sachmittel → z.B. Hardware, Software/ Lizenzen, Material, Anlagen, Schulungen, Externe Zusatzlieferungen, Reise- und Nebenkosten  Kosten Zuverlässige Schätzungen sind eine wichtige Voraussetzung für erfolgreiche Projekte:  Aufwandschätzung zu gering → hoher Stress der Mitarbeiter, Qualitätsprobleme  Aufwandsschätzung zu hoch → hoher Projekt-/ Angebotspreis → kein Auftrag Top-Down: Gegenstromverfahren: Iterativer Mix aus Top und Down. Bottom-Up: <?page no="83"?> 2.2 Projektstrukturplanung 83 Aufwand vs. Dauer:  Dauer: Zeitraum (brutto), den die Erledigung einer bestimmten Aufgabe erfordert.  Aufwand: Netto-Arbeitszeit, die zur Erledigung einer bestimmten Aufgabe erforderlich ist (d.h. Fulltime-Mitarbeiter kann seine gesamte Arbeitszeit einsetzen). Abbildung 75: Aufwand vs. Dauer Bottom-Up-Schätzungen berücksichtigen vielfach keine Synergieeffekte und geraten dadurch zu hoch. Top-Down-Schätzungen wiederum vernachlässigen nicht selten aufwändige Detailarbeit. Eine valide Aufwandschätzung erfordert daher im Allgemeinen eine Betrachtung von mehreren Seiten: Abbildung 76: Perspektiven für eine valide Aufwandschätzung Die ermittelte Aufwandsverteilung (bottom-up) der Arbeitspakete wird einer aus dem Gesamtaufwand (top-down) abgeleiteten Verteilung (z.B. „25% für die Konzeption“) gegenübergestellt. Eine Analyse der Aufwandstreiber (z.B. die Anzahl der zu programmierenden Reports) mit einer 3-Punkt-Schätzung (Best Case, Worst Case, Realistic Case) validiert die Schätzungen. Schauen Sie dazu doch auch einmal in das folgende Video: ► Video 2.4 (Aufwandschätzung), URL: https: / / youtu.be/ nribpx7NG_M Im Detail gibt es eine Vielzahl von Schätzmethoden, die hier im Überblick auszugsweise dargestellt werden: <?page no="84"?> 84 Takt 2: Projektplanung Abbildung 77: Schätzmethoden im Überblick Im Folgenden werden einige ausgewählte Schätzmethoden etwas detaillierter vorgestellt. Expertenschätzung: Einzelschätzung Expertenschätzung: Schätzen im Team Vorgehen • Eine Einzelperson (Experte), in der Regel der Projektleiter, Teilprojektleiter oder AP-Verantwortliche, führt die Aufwandschätzung durch. Vorteile • schnelle Schätzwerte • wenig Aufwand Nachteile • einsame Entscheidungen • fehlende Kontrolle der Schätzwerte durch andere Personen • Team steht ggf. nicht hinter den Schätzwerten. Vorgehen (Schätzklausur) • Mehrere Einzelpersonen (Experten, Projekt-Team) nehmen Schätzungen vor. • Die Mittelwerte bilden die Schätzwerte. • Liegen die Werte weit auseinander, müssen die Extrema begründet werden. • Weitere Schätzrunde nach Austausch der Argumente. • Teilnehmer können ihre Beurteilung korrigieren. Vorteile • Höhere Schätzgenauigkeit, da unterschiedliche Aspekte und Erfahrungen einfließen. • höhere Akzeptanzwahrscheinlichkeit Nachteile • aufwändiger als Einzelschätzung Expertenschätzung: Delphi-Methode 3-Punkt-Schätzung mit Wahrscheinlichkeiten Vorgehen • strukturierte anonyme Gruppenbefragung des Teams • Auswahl von zu befragenden Experten Vorgehen • Aufwandsschätzungen werden mit Wahrscheinlichkeiten belegt. • optimistischer Wert: oW - alles läuft glatt. Schätzmethoden Expertenschätzungen Einzelschätzung Teamschätzung Delphi-Methode Analogiemethoden Kennzahlenmethoden Prozentsatzmethode Parametrische Methoden Function Point- Methode Constructive Cost Model (CoCoMo) Cost Driver Sonstige Planning Poker (Scrum) 3-Punkt- Schätzung … Analogiemethoden Prozentsatzmethode Function Point- Methode Constructive Cost Model (CoCoMo) Cost Driver Planning Poker (Scrum) 3-Punkt- Schätzung Bottom Up Top Down Aufwandstreiber <?page no="85"?> 2.2 Projektstrukturplanung 85 • Jeder Experte gibt anonym eine Schätzung ab. • Bekanntgabe der Ergebnisse der ersten Runde • Durchführung einer 2. und ggf. 3. Runde Vorteile • Einbeziehung eines breiten Erfahrungswissen mit vielen Faktoren • Unsicherheiten werden deutlich. • Keine Dominanz durch einen Teilnehmer der Gruppe • Trend zur Gruppenkonformität wird durch die Anonymität vermieden. • realistischer Wert: rW - normaler Verlauf. • pessimistischer Wert: pW - vieles läuft schief. • Berechnung des Schätzwerts W: 1 W = (oW + 4 * rW + pW) / 6 Vorteil • Durch die differenziertere Betrachtung ist eine noch höhere Schätzgenauigkeit zu erwarten. Nachteil • Zusätzliche Aufwände für weitere Schätzwertermittlungen. Planning Poker (Scrum) − Die Größen der User Stories (Backlog Items) werden vom Team geschätzt. − Jede User Story erhält Story Points, die die relative Größe (Funktionsumfang und Komplexität) im Vergleich zu den anderen widerspiegelt. − Story Points sind relative Vergleichsgrößen der einzelnen Backlog Items untereinander - keine absoluten Schätzgrößen, wie Personentage. − Planning Poker-Karten Kartenwerte z.B.: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (steht für unsicher) Abbildung 78: Planning Poker Vielfach werden auch sogenannte „T-Shirt-Sizes“ verwendet: XS, S, M, L, XL, … wobei die Größenangaben die Zahlen ersetzen. Weitere Schätzmethoden kurz und knapp Kennzahlenmethoden Basis: Kennzahlen von abgeschlossenen Projekten, die mit denen des Projektes verglichen werden. Voraussetzung: Daten vergleichbarer Projekte liegen vor. z.B. Analogieschluss  Basis: Erfahrungen von abgeschlossenen Projekten mit entsprechender Ähnlichkeit  Für Projekte mit einem gewissen Wiederholungsfaktor geeignet z.B. Prozentsatzmethode  Mit dem durchschnittlichen prozentualen Aufwand/ Laufzeit pro Phase von alten Projekten und den Aufwänden der bisherigen Phase(n) wird eine Hochrechnung durchgeführt.  Beispiel: durchschnittliche Laufzeit für Definitionsphase von 5% und Dauer von 2 Wochen hierfür im vorliegenden Projekt → Projektlaufzeit: ca. 40 Wochen <?page no="86"?> 86 Takt 2: Projektplanung Parametrische oder algorithmische Methoden  Schätzung des Aufwands für APs anhand mathematischer Formeln.  Beispiele: CoCoMo, Function-Point-Verfahren. ��� Typische Probleme der Aufwandsschätzung - Projektphasen oder Teilprojekte werden geschätzt, anstatt notwendiger Arbeitspakete. - Die erforderlichen Aktivitäten zur Erreichung der Ergebnisse sind nicht bekannt. - „Seriöse“ Aufwandsschätzung muss mit den zuständigen Ressourcen erfolgen und sollte durch einen zweiten Experten qualitätsgesichert werden. - Man muss zwischen Dauer und Aufwand unterscheiden. - Aufwand für Projektmanagement, Qualitätsmanagement und Knowledge Management (Dokumentation) wird vergessen. - Bekannte Risikofaktoren - wie z.B. die Neuartigkeit einer Lösung - werden nicht berücksichtigt. ▲ Bewerten Sie doch mal mit Hilfe der folgenden Checkliste eine Projektschätzung, die Ihnen in den Sinn kommt: Abbildung 79: Checkliste Aufwandsplanung Checkliste Aufwandsplanung Ja Nein Bei der Aufwandsschätzung wurde zwischen Dauer und Aufwand unterschieden.   Die Aufwandsschätzung ist soweit wie möglich realistisch.   (Wie würde die Aufwandsschätzung aussehen, wenn es den Termindruck und die eingeschränkte Ressourcenverfügbarkeit nicht gäbe? )   Die Basis für die Aufwandsschätzung ist der Arbeitsumfang der vorher definierten Arbeitspakete.   Die Schätzungen wurden durch kompetente Fachleute (oder den Einsatz anderer Methoden) bestätigt.   Die Schätzungen wurden im Bewusstsein, dass die lineare Aufwandsbeurteilung (Aufwand = Dauer * Personaleinsatz) nur eingeschränkt gültig ist, durchgeführt.   Der Aufwand für Projektmanagement wurde bei der Aufwandsschätzung mitberücksichtigt.   Der Aufwand für Qualitätssicherung wurde bei der Aufwandsschätzung mitberücksichtigt.   <?page no="87"?> 2.3 Projektablaufplanung 87 2.3 Projektablaufplanung 2.3.1 Projektlebenszyklus Für ein erfolgreiches Projekt sind zwei Lebenszyklen entscheidend − der Projektlebenszyklus (des Projektfortgangs) und der Projektmanagementlebenszyklus (der PM-Prozesse, siehe UPMF). Ein Merkmal von Projekten ist die voranschreitende Ausarbeitung. Beispielsweise ist der Projektumfang („Scope“) ‒ die zu leistende Arbeit ‒ zu Beginn des Projekts nur allgemein beschrieben und wird mit Zunahme des Verständnisses durch das Projekt-Team immer detaillierter ausgearbeitet. Zur Verbesserung des Managements werden im Projektlebenszyklus zumeist verschiedene Phasen gebildet. Im Software-Projekt bspw.: Fachkonzept → DV-Konzept → Realisierung → Test → Integration. Diese Phasen sind natürlich nicht allgemeingültig, sondern abhängig vom Projektgegenstand und der Branche. Zur Verifizierung von Liefergegenständen existieren Übergabepunkte („phase-“ oder „stagegates“), Meilensteine, die zudem eine ständige Reflexion des Fortschritts ermöglichen. 2.3.2 Projektphasen Der Phasenplan ist häufig der erste Planungsschritt der Ablaufplanung zusammen mit dem Meilensteinplan. Ziele des Phasenplans:  Reduktion der Komplexität  Basis für weitere Planungen  Beschränkung des Risikos: „Go“- oder „No Go“-Entscheidungen Darstellungen:  tabellarisch: Phasentabelle  grafisch: Balkenplan Abbildung 80: Grafischer Phasenplan Eine Projektphase ist ein zeitlich-logische Aufteilung langläufiger Projekte. <?page no="88"?> 88 Takt 2: Projektplanung Definition „Phase“ Eine Projektphase ist ein „zeitlicher Abschnitt eines Projektablaufs, der sachlich gegenüber anderen Abschnitten getrennt ist“. (DIN 69900) „Sie endet mit einem Meilenstein, der gewöhnlich einen wesentlichen Liefergegenstand umfasst. Die zeitliche und inhaltliche Überlappung von Projektphasen ist möglich.“ (PMI, 2004) • Phase endet mit Meilenstein • Phasenergebnis ist dokumentiert • Abnahme/ Freigabe • ggf. Wechsel der Verantwortung • ggf. Entscheidung, ob Projekt weiterläuft • Phasenablauf: Anstoß, Organisation, Zielplanung, Projektsteuerung- und Abschluss • Projektgegenstandsphasen sachbezogen, ggf. branchenbezogen (z.B. HOAI) • Es gibt gemischte Phasensysteme Der (fachliche) Projektablauf folgt im Allgemeinen folgendem generischen Phasenmodell: Abbildung 81: Generisches Phasenmodell Folgende Inhalte können mit den fachlichen Phasen verbunden werden: 1) Analysephase 2) Konzeptionsphase ► Aufgabenstellung analysieren & abgrenzen ► Lösungsalternativen erarbeiten ► Durchführbarkeit untersuchen ► Lösungsalternative auswählen ► vorgeschlagenes Konzept ausarbeiten ► … und bezüglich Sachaufgaben optimieren ► Realisierungsrisiko minimieren ► Projektplan validieren (Lieferobjekte, Termine, Kosten, Team, …) 3) Realisierungsphase 4) Einführungs- & Verwendungsphase ► das ausgewählte Konzept umsetzen/ realisieren ► … und erproben ► Migration planen ► den „Go Live“ ausplanen ► die Betroffenen schulen ► … und die Stakeholder informieren ► umgesetztes Konzept einführen ► Anlaufphase betreuen Je nach Vorgehensmodell können dies die sequenziellen Phasen einer wasserfallähnlichen oder die zyklischen Sprints einer iterativen Vorgehensweise sein … oder deren Mischformen, wie etwa mit dem Spiralmodell beschrieben. Phasen sind gekennzeichnet durch Meilensteine, die mindestens das Ende der Phase zeitlich und inhaltlich definieren. <?page no="89"?> 2.3 Projektablaufplanung 89 Beziehungen zwischen Phasen sequentiell überlappend / konkurrierend iterativ Die nächste Phase kann erst beginnen, wenn die vorherige Phase abgeschlossen ist → „Phase Gates“, „Decision Points“. Die nächste Phase beginnt, während die vorherige Phase noch läuft → „Fast-tracking“, Risiko der Nacharbeit. Die nächste Phase wird erst geplant, wenn die Lieferobjekte der vorherigen Phase weitgehend fertiggestellt sind, z.B. zunächst „Proof of Concept“, erst danach wird die Umsetzung der Lösung geplant. ▲ Welche Vorteile bringt die Aufteilung in Phasen generell mit sich? Können Sie Vor- und Nachteile der verschiedenen Ansätze identifizieren? Praxistipp: Goldener Schnitt Frei nach Leonardo da Vinci teilt der Goldene Schnitt die Phasen zeitlich und fachlich etwa in Fünftel ein. Nach ca. 1/ 3 sollte ein Zwischenmeilenstein eingeplant werden, bei dem grundlegende und richtungsweisende Ergebnisse vorliegen und für die weitere Bearbeitung evaluiert werden. Abbildung 82: „Goldener Schnitt“ von Projektphasen Ein Beispiel hierfür ist der detaillierte Entwurf eines zu erstellenden Dokuments, etwa eines Konzeptes oder das Grund-Customizing einer Standard-Software-Lösung. Spätestens zu diesem Zwischenmeilenstein sollte die Entwicklung der Ergebnisse mit den späteren Abnehmern, das heißt den Kunden der Projektphase, vorabgestimmt werden. Die folgende Abbildung 83 zeigt das Beispiel einer SAP-Einführungsprojekts unter Anwendung des Goldenen Schnitts: <?page no="90"?> 90 Takt 2: Projektplanung Abbildung 83: Goldener Schnitt − Beispiel SAP-Einführung <?page no="91"?> 2.3 Projektablaufplanung 91 Zusammenfassend: Jede Phase wird terminlich so geschnitten, dass nach ca. 1/ 3 der Zeit zentrale, richtungsweisende Ergebnisse vorliegen. Damit kann der folgende Nutzen identifiziert werden:  Frühzeitige Identifikation und Klärung grundlegender Elemente!  Stabilität für die Detailarbeiten einer Phase!  Vermeidung von Doppelarbeiten durch Klarheit für alle!  Erhöhung der Abstimmung mit dem Auftraggeber!  Quick Wins! 2.3.3 Meilensteine Meilensteine sind wesentliche Schlüsselereignisse oder wichtige Zwischenergebnisse des Projekts, die zu einem bestimmten (Meilenstein-)Termin mit geplanten (Meilenstein-)Kosten vorliegen müssen. Definition Meilenstein 47 „Meilensteine (MS) sind herausgehobene, zeitlich-inhaltlich terminierte Punkte im Projektverlauf, die das Erreichen eines bestimmten (Ergebnis-)Status repräsentieren. Sie lassen sich terminlich planen und überwachen sowie zur Bewertung des Projektfortschritts einsetzen. Ein MS hat die Dauer Null.“ Auf der Grundlage der Meilensteinresultate werden (i.a. vom Auftraggeber oder Lenkungsausschuss) Entscheidungen über die Freigabe der nachfolgenden Phase, Wiederholung von Phasen oder Abbruch des Projektes getroffen. Beispiel Meilenstein • Grobkonzept erstellt, qualitätsgesichert und abgenommen • Meilensteintermin: 31.05.2022 • Meilensteinkosten (kumuliert): 120.000 € ��� Meilensteine sind die wichtigsten Kontrollpunkte auf dem Weg zu Projekterfolg! Quality Gates (QG) sind eine ergänzende Methode des Projektmanagements zur Sicherung und Verbesserung der Qualität im Projekt und zur Messung des Projektfortschritts. Sie sind herausgehobene Meilensteine und kommen insbesondere bei standardisierten Projektvorgehensweisen, etwa der Produktentwicklung, zum Tragen. Abbildung 84: Quality Gates ‒ Aufbau 47 eigene Formulierung, angelehnt an PMI, 2009 sowie V-Modell XT, 1997 Abgeschlossene Projektphase nächste Projektphase Bedingung, Ergebnisse Entscheidungssitzung Anforderungen, Ziele Quality - Gate Meilensteine Entscheidungen:  Freigabe (mit oder ohne Auflagen)  Keine Freigabe <?page no="92"?> 92 Takt 2: Projektplanung Im Allgemeinen werden wenige Quality Gates innerhalb eines Projektes vorgesehen (z.B. Phasenabschluss), aber viele Meilensteine. Sie dienen zur grundsätzlichen Beurteilung des Fortschritts gemäß vordefinierter Anforderungen und zur übergeordneten Freigabe des weiteren Projektverlaufs. 2.3.4 Projektabschnitte Die Planung von Projektabschnitten ist die strategische Projektplanung. Großprojekte werden in Abschnitte geteilt, um die Komplexität zu handhaben. Projektabschnitte fassen bestimmte Projektphasen zeitlich-logisch zusammen. Projektabschnitte produzieren grundsätzlich ein autark verwendbares Ergebnis, dass im Allgemeinen Input für einen Folgeabschnitt ist und selber Projektcharakter hat. Definition Projektabschnitt „Als Projektabschnitt wird hier ein Phasenbündel definiert, das im Ergebnis ein autark verwendbares Ergebnis erzeugt.“ Das kann z.B. die Implementierung einer Pilotanwendung sein. Ein solcher Abschnitt umfasst z.B. eine definierte Menge von Funktionalitäten eines IT-Systems - ein sogenanntes Release der Lösung. Abbildung 85: Projektabschnitte ‒ Aufbau Sehen Sie dazu auch ein kurzes einführendes Video: ► Video 2.5 (Phasen & Abschnitte), URL: https: / / youtu.be/ 0n6X1vLYZTo Charakterisierend für einen Projektabschnitt ist, dass er in der Regel aus mehreren Projektphasen besteht, z.B. Konzeption, Realisierung, Produktionsvorbereitung etc. (oder auch Sprints in Scrum-Projekten), und damit auch wesentliche Merkmale eines eigenständigen Projekts zeigt. Eine Dauer von bis zu maximal 9 Monaten ist hier zu empfehlen, was Vorteile wie Erhöhung der Flexibilität und Steuerbarkeit nicht zuletzt hinsichtlich der Budgetallokation innerhalb eines Geschäftsjahres, schnellere Ergebnisbereitstellung, Erhöhung des Flusses etc. mit sich bringt. z.B. • Implementierung • Pilotierung • Rollout z.B. • Konzeption • Realisierung • Testing • Migration z.B. • AP Sollprozess XY • AP Projektmanagement • MS Konzeption freigegeben • MS Implementierung abgeschlossen Arbeitspaket Arbeitspaket Projektphase Projektabschnitt Projektphase Arbeitspaket(e) MS Meilenstein(e) Projektphase(n) <?page no="93"?> 2.3 Projektablaufplanung 93 Typische Anwendung: Durchführung eines Vorprojekts Das Vorgehen in komplexen Projekten wird in verschiedene Abschnitte unterteilt. Optional erfolgt zur Beurteilung und Vorbereitung der richtigen Vorgehensweise eine Vorstudie. Abbildung 86: Projektablauf mit Vorstudie Je nach Komplexität und Gesamtdauer wird das Hauptprojekt wiederum in überschaubare Projektabschnitte unterteilt (z.B. Pilotierung, Rollout). Die Projektabschnitte durchlaufen die für den Projektgegenstand passenden Projektphasen. Der Ablauf eines Projekts mit Vorstudie stellt sich etwa wie folgt dar: Abbildung 87: Ablauf mit Vorstudie Typische Anwendung: Releases Die Bildung von Realisierungseinheiten („Releases“) ist eine zielführende Strategie zum Management großer, komplexer und langwieriger IT-Projektvorhaben. Das könnte z.B. so aussehen: Projektvorbereitung Vorstudie Ziel: Das Vorhaben ist in der Tiefe so vorbereitet, dass die vorhandenen Informationen im Rahmen einer Vorstudie (oder direkt des Hauptprojekts) weiter detailliert und geplant kann. Die Auftraggeber können über das weitere Vorgehen entscheiden Dazu gehört u.a.: • Projektinhalt / Scope ist grob geklärt • Ablauf und Aufwände der Vorstudie sind beschrieben und geplant • Entscheidung, ob die Vorstudie benötigt wird Umsetzungsprojekt Ziele: Das Projekt hat durch fachliche und technische Detaillierungen die Inhalte, das Vorgehen, die Terminplanung, den Ressourceneinsatz für ein Umsetzungsprojekt spezifiziert. Die Auftraggeber können über das weitere Vorgehen entscheiden. Dazu gehört u.a. : • Konkrete Projektinhalte / Scope klären • Notwendige Analysen durchführen • Business Case konkretisieren • Entscheidungen / Empfehlungen für Umsetzungsprojekt • Detailplanung für Umsetzungsprojekt Ziel: Weitere fachliche und technische Spezifikationen sind vorgenommen. Das Vorhaben ist realisiert, getestet, eingeführt und in die Linienorganisation übergeben Dazu gehört: • Detailanforderungen • DV-Konzept • Realisierung • Test • Einführung Gate Gate <?page no="94"?> 94 Takt 2: Projektplanung Abbildung 88: Projektabschnitte − beispielhafte Anwendung Releases Als „Blueprint“ wird hier die betriebswirtschaftliche „Blaupause“, also das Fachkonzept, bezeichnet. Abbildung 89: Projektabschnitte − beispielhafte Anwendung Rollout (RO) <?page no="95"?> 2.3 Projektablaufplanung 95 Typische Anwendung: Rollout-Strategie Das vorangegangene Schema (Abbildung 89) zeigt die Rollout-Strategie am Beispiel der Realisierung und Einführung von SAP in einer Konzernstruktur. Hier wird deutlich, dass auch hier im Sinne einer Release-Planung vorgegangen wird. Das Bedeutet, dass nach der Produktivsetzung der Pilotbereiche fortan Projekt und Betrieb parallel zu koordinieren sind. Die eingezeichnete Lernkurve zeigt plakativ, dass die Erfahrungen des jeweiligen Projektabschnitts zur Effizienzsteigerung im Folgeabschnitt genutzt werden, aber auch notwendig sind, da sich die Anzahl der betroffenen Organisationseinheiten erhöht. 2.3.5 (Operative) Projektablaufplanung Wie auch schon in der Projektstrukturplanung erfordert die Projektablaufplanung vergleichbar eine weitere Detaillierung, etwa auf der Ebene einzelner Teilprojekte. Der Projektstrukturplan (PSP) ist wichtig, um das Projekt in Arbeitspakete und Teilaufgaben zu zerlegen; er liefert aber keine Aussagen über: die Reihenfolge, in der die einzelnen APs bearbeitet werden sollen, die Schnittstellen zwischen den TAs / APs, die zeitliche Abfolge und Durchführungszeitpunkte. Die Projektablaufplanung (PAP) ist das zentrale Organ der - Termin-, - Kostenverlaufs- und - Leistungsplanung und -verfolgung. Der PAP erlaubt es, vorausschauend zu planen und Alternativen durchzuspielen. Schwerpunkt in der Anwendung des PAP im Verlauf des Projektes ist der Soll-Ist-Vergleich der Termine. Wie kommen wir vom Projektstrukturplan zum (operativen) Projektablaufplan? Dazu mehr im folgenden Video. ► Video 2.6 (Vom PSP zum PAP), URL: https: / / youtu.be/ 1zGKnDRywjM Aus der Abhängigkeit der Vorgänge untereinander können - auch ohne Kenntnis von Dauer und Aufwänden - sachlogische Ablaufpläne abgeleitet werden. Die Ablaufplanung sequenzialisiert den PSP im Hinblick auf Vorgänger-Nachfolger-Beziehungen von Arbeitspaketen und zerlegt sie bei Bedarf in kleinere Einheiten (Tätigkeiten/ Aktivitäten). Abbildung 90: Projektablaufplan Der Projektablaufplan (PAP) bildet somit die Grundlage für die sequenzielle oder parallele Bearbeitung der Arbeitspakete in einem Projekt. Er beschreibt die logisch-zeitliche Reihenfolge der Bearbeitung der Vorgänge. AP 2 AP 3 AP 4 AP 5 AP 1 <?page no="96"?> 96 Takt 2: Projektplanung Abbildung 91: Sequenzielle oder parallele Bearbeitung Definition Vorgang 48 „Eine einzelne geplante Komponente der Arbeit, die im Verlauf eines Projekts durchgeführt werden muss. Anforderungen an einen Vorgang sind normalerweise eine Schätzung von Dauer, Kosten und Einsatzmitteln. Vorgänge sind mit anderen Vorgängen oder terminlichen Meilensteinen über Anordnungsbeziehungen verknüpft und ergeben sich aus der Aufgliederung von Arbeitspaketen [→ Aktivität/ Tätigkeit].“ Termin-/ Zeitplan Durch die Terminierung der Vorgänge wird der PAP zum Terminplan des Projekts. Dieser liefert die Sollvorgaben für die Projektsteuerung und -überwachung. → Der Parameter „Zeit“ (Termine, Dauer) wird der festgelegten Reihenfolge zugeordnet. Abbildung 92: Zeitplan Netzplantechnik Die Netzplantechnik ist eine formale Methode zur Erzeugung und Optimierung von Ablaufplänen auf Basis der Graphentheorie. Netzpläne sind ein wichtiges Informationsmedium für die Kommunikation zwischen Projektmanagement und Linienorganisation. Abbildung 93: PAP ‒ Netzplan 48 nach PMI, 2009 Vorgang 2 Vorgang 3 Vorgang 4 Vorgang 5 Vorgang 1 Vorgang 2 Vorgang 3 Vorgang 1 Serieller Ablauf: Paralleler Ablauf: AP 2 AP 3 AP 4 AP 5 AP 1 Zeit <?page no="97"?> 2.3 Projektablaufplanung 97 Gantt-Chart (Balkenplan) Auftraggeber oder die Unternehmensleitung empfinden Netzpläne mitunter als unübersichtlich. Der Wunsch nach ergonomischer Visualisierung der Abläufe und Termine führt zur Zeitbanddarstellung. Abbildung 94: PAP ‒ Gantt-Chart Die folgende Abbildung zeigt das Beispiel eines Gantt-Charts der Einführung einer Standardsoftware. 49 Abbildung 95: PAP − Beispiel Auswahl Standard-Software Heuristik für Zeitplanungen Um die Treffsicherheit der Schätzungen von Dauern zu erhöhen, kann die „Worst Case-Abschätzung“ genutzt werden. Diese Methode nutzt die These, dass die wahre Projektlaufzeit mit einer 87,5%-igen Wahrscheinlichkeit vom mittleren Schätzwert in Richtung Worst Case abweicht. Um die wahrscheinlichste Projektlaufzeit zu bestimmen, braucht man den Mittelwert aller Schätzungen für die Laufzeit eines Arbeitspakets und die Worst Case-Schätzung, die alle rational 49 http: / / www.veitshoechheim-blog.de/ article-mainsteg-veitshochheimer-gemeinderat-billigt-rampenfuhrunggeplanter-baubeginn-oktober-2014-105144117.html <?page no="98"?> 98 Takt 2: Projektplanung kalkulierbaren Probleme und Verzögerungen enthält. Die Formel zur Berechnung der Abweichung vom Mittelwert lautet: (Worst Case minus Mittelwert) geteilt durch drei Beispiel Mittelwert der Schätzungen beträgt 10 Monate, Worst Case beträgt 16 Monate. Dann beträgt die Projektlaufzeit mit 87,5%-iger Wahrscheinlichkeit 10 + (16 - 10) / 3 = 12 Monate. In der Projektpraxis von Projekten ist das Gantt-Chart weit verbreitet. Damit sind folgende Vor- und Nachteile verbunden: Abbildung 96: Gantt-Chart − Bewertung 2.3.6 Rollierende Planung 50 Planung ist schwierig - besonders, wenn sie die Zukunft betrifft! Das Vorliegen einer detaillierten Planung, auch über einen recht langen Zeithorizont gesehen, wird teilweise vom Management von der Projektleitung eingefordert. Nach dem Motto „Ein guter (Projekt-)Manager muss doch wissen, was gemacht werden soll und was dafür benötigt wird! “ Insbesondere bei der Planung und Allokation der personellen Ressourcen führt dies vermehrt zu laufenden Anpassungen und Neuplanung. Leider verkennt diese Überplanung, dass Projekte eben mit einer immanenten, mal mehr und mal weniger ausgeprägten Unsicherheit behaftet sind, mit der umzugehen ist. Um dennoch dem menschlichen Bestreben nach Planungssicherheit, der Erfordernis einer planerischen Leitlinie und der Ausrichtung des Projekt-Teams auf einen gemeinsamen Plan Rechnung zu tragen, sollte die Planung als rollierende Erarbeitung vorgenommen werden. Dabei gilt die einfache Regel: ��� Je weiter entfernt zeitlich gesehen der Planungsgegenstand liegt, desto gröber wird er geplant und je näher dieser liegt, desto detaillierter geschieht dies. D.h. die Granularität der Planung wird feiner, je näher die beplanten Ereignisse, z.B. Aktivitäten, rücken. Um diesen Ansatz umzusetzen, bedarf es einer entsprechenden Planungsarchitektur, wie sie schematisch in der folgenden Abbildung dargestellt ist. 50 siehe Hüsselmann, 2021, S. 128ff <?page no="99"?> 2.3 Projektablaufplanung 99 Abbildung 97: Rollierende Planung Auf der obersten Ebene sollten dabei die Projektabschnitte geplant werden, die häufig auch Releases der Lösung hervorbringen, welche produktiv gesetzt werden können. Taktisch heruntergebrochen wird diese Planung in der Projektphasenplanung . Hier werden also die Phasen eines Projektabschnitts oder entsprechend dimensionierten Projekts definiert. Im Sinne einer rollierenden Planung gilt: Für weit entfernt liegende AP erfolgt eine (vorläufige) Identifikation und Definition (Schritt 1) und ggf. grob abschätzend eine Aufwandermittlung und -abstimmung (Schritt 3). Dadurch kann die Projektleitung und das Projekt-Team wertvolle Indikationen für die Fülle der anstehenden Aufgaben bekommen. Für die anstehende Projektphase muss dann natürlich die Konkretisierung der AP durch die inhaltliche Ausgestaltung im Detail (Schritt 2) und die Finalisierung von Schritt 3 erfolgen. ��� Die rollierende Planung lässt sich also wie folgt zusammenfassen: High-Level-Planung auf Ziel − Detailplanung auf Sicht! Ein sinnvolles Anwendungsfeld für die rollierende Planung ist nicht zuletzt die personelle Ressourcenplanung. Eine mögliche und bewährte Ausgestaltung lautet hier wie folgt: Planen Sie die Ressourcen … 1. … für den nächsten Monat personen- und aufgabengenau ein - also z.B. „Mitarbeiter Max Mustermann arbeitet im anstehenden Monat Mai mit 30% seiner Kapazität am Arbeitspaket Konzeption.“ 2. … für die darauffolgenden drei Monate rollengenau ein - also z.B. „In den Monaten Juni bis August wird ein Senior-Java-Entwickler im Projekt Web-Relaunch zu 80% eingesetzt.“ 3. … für die weiteren 8 Monate nur grob, auf Ebene von Abteilungen - etwa „Für die Monate September bis April benötigt die Entwicklungsabteilung Web-Entwickler im Umfang von vier Vollzeitäquivalenzen.“ 4. Wiederholen Sie rollierend Schritt 1 bis 3 im angemessenen Zyklus, etwa einmal pro Monat, sodass der Gesamtplanungshorizont (in unterschiedlicher Detaillierung) stets 12 Monate im Voraus beträgt. Mit diesem Vorgehen wird also der konkrete Mitarbeiter in der Vereinbarung zwischen Projektleitung (Bedarfsträger) und Abteilungsleitung (Bedarfsdecker) immer für die nächsten 4 Wochen Detaillierung ztl. Perspektive nah fern hoch niedrig Aktivitäten Releases, Projektabschnitte Projektphasen Arbeitspakete <?page no="100"?> 100 Takt 2: Projektplanung gebunden. Auf der anderen Seite bleibt für die Bedarfsdeckung ausreichend Zeit, ggf. Ressourcenanpassungen, etwa Personalaufbau, vorzunehmen. In dem Vorgehen sollten auch die Erkenntnisse der Engpasstheorie ( Theory of Constraints ) umgesetzt werden. Dazu müssen die personellen Engpassressourcen identifiziert und mit besonderem Augenmerk beplant werden (dazu mehr in Takt 4). So reicht es nicht aus, wenn es im Unternehmen beispielsweise nur einen einzigen Mitarbeiter gibt, der noch die alte Programmiersprache beherrscht, mit der die kritische laufende Anwendung erstellt wurde, hier nur auf Rollenebene zu planen. In diesem Fall ist eine längerfristige konkrete Allokation dieser Person, etwa in dem Zeithorizont wie in Schritt 2, zu empfehlen. Natürlich sollte der zweite Teil der engpassorientierten Planung, nämlich das Beheben des Engpasses nicht außer Acht gelassen werden. Nur so können letztlich der Flaschenhals entzerrt und auch das Risiko eines Ausfalls verringert werden. Mit der charakterisierenden Profilbildung eines Projekts (siehe Abschnitt zur Projekttypisierung) entsteht eine wesentliche Indikation für die Möglichkeit und Sinnhaftigkeit der Projektplanung, nicht zuletzt der Ablaufplanung. Je unsicherer der Kontext ist, desto verschwenderischer ist eine langfristige Planung im Detail. Hier gilt es, das richtige Maß zu finden. Die rollierende Planung stellt in jedem Fall eine adäquate Vorgehensweise dar, denn den Grad der Unsicherheit, also Instabilität des Plans, schlägt sich dann letztlich in den Zeithorizonten nieder, mit denen im entsprechenden Detaillierungsgrad geplant werden sollte. Je unsicher die Situation ist, desto mehr ist „auf Sicht“ zu planen. Ganz ohne Planung wird es in keinem Fall gehen; dabei gilt die Erkenntnis: Der Plan ist nichts - Planung ist alles! D.h. der Planungsvorgang selber - am besten mit allen Beteiligten - schafft im Sinne eines Findungsprozesses Klarheit und Abstimmung für die Beteiligten. Zum Abschluss des zweiten Taktes liefert das folgende Video noch einmal eine Zusammenfassung. ► Video 2.7 (Wrap-up), URL: https: / / youtu.be/ GW6t-bpAGy4 2.4 Transferaufgaben Takt 2 2.4.1 Ihr Projekt Für den weiteren Verlauf des Moduls wählen Sie bitte ein Projekt aus - real oder gegebenenfalls fiktiv, das Sie bearbeiten möchten. ▲ Als Ausgangsbasis soll das Projekt Canvas für dieses Projekt ausgefüllt werden. Sie finden dazu eine MS-PowerPoint-Vorlage. 2.4.2 User Requirements Im Kurs haben Sie die Methode der User Stories kennengelernt, um leichtgewichtig insbesondere fachliche Anforderungen zu beschreiben. ▲ Formulieren Sie für einen ausgewählten Aspekt Ihres Projektes doch einmal eine oder mehrere User Stories mit der bekannten Satzschablone aus. ▲ Identifizieren Sie im zweiten Schritt den oder die Aufwandstreiber, die bei der Umsetzung der Anforderung zu erwarten sind. ▲ Können Sie den mit den identifizierten Aufwandstreibern einhergehenden Aufwand abschätzen? (Bilden Sie dazu gegebenfalls Kategorien, z.B. je nach Komplexität.) Viel Spaß! <?page no="101"?> Takt 3: Projektorganisation 101 3 Takt 3: Projektorganisation Sie kennen es nun schon: Als Einleitung zum nächsten Takt finden Sie im folgenden Video einen Überblick über den 3. Takt und eine Motivation und Einordnung des Themas. ► Video 3.1 (Einleitung), URL: https: / / youtu.be/ k9Z2Y9hXNRo 3.1 Projektaufbauorganisation In diesem Abschnitt befassen wir uns mit der Frage, wie ein Projekt organisiert werden sollte. Dazu ist zunächst einmal festzustellen, dass im Allgemeinen ein Projekt komplementär zur sogenannten Linienorganisation des Unternehmens steht. Abbildung 98: Zwei Welten: Linie - Projekte Schauen Sie einleitend doch mal in das folgende Video. ► Video 3.2 (Zusammenhang PSP-PAP-Organigramm; Team), URL: https: / / youtu.be/ cpfAz0ZJpB8 Es ist also gewissermaßen eine (temporäre) Organisation in der Organisation. Dies ruft einige Herausforderungen hervor. Definition Projektorganisation Unter Projektorganisation versteht man die „Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projekts.“ (DIN 69 901) Die Projektorganisation beinhaltet: • Organisationseinheiten (Teilprojekte) und die Arbeitsteilung im Projekt, • Aufbau- und Ablauflauf-organisatorische Regelungen, • Rollen und Schnittstellen, • Verantwortlichkeiten und Zuständigkeiten, • Weisungsbefugnisse. Problemstellung Linie Projekt Routine komplex, neuartig Hierarchische Struktur mit festem Regelwerk Teamarbeit: Team legt passende Regeln fest <?page no="102"?> 102 Takt 3: Projektorganisation Der Begriff Projektorganisation muss in zweifacher Hinsicht ausgelegt werden: 1. Innere Struktur eines Projekts für die Dauer des Projekts: Zusammenstellung der Rollen, Verantwortlichkeiten, Befugnisse, Berichtslinien, Schnittstellen und Infrastruktur des Projekts. 2. Organisatorische Einbettung des Projekts in die Organisation des Unternehmens: Projekte ergänzen die Stammorganisation. Alle am Projekt beteiligten Personen müssen wissen, welche Aufgaben, Befugnisse und Verantwortungen sie bzw. die anderen Personen haben. Schauen wir zunächst einmal auf die innere Struktur eines Projektes. Eine typische Projektorganisation umfasst verschiedene Rollen, insbesondere: • Auftraggeber • Lenkungsausschuss • Projektleitung • Teilprojektleitung • Projektmitarbeiter • Projektassistenz • Qualitätsverantwortlicher Umgekehrt gibt es auch Aufgaben, die keine spezielle Organisation benötigen. Diese Projekte werden von einem „Nebenher-Projektleiter“ gemanagt. Kriterien, die nur zu geringen organisatorischen Eingriffen führen sind z.B.: Abbildung 99: „Nebenher“-Projektorganisation Beispiele „Umzug der Registratur in den 2. Stock“ „Einscannen der alten Zeichnungen (vor 1995)“ „Bearbeitung eines Change Request eines Anwenders“ Definition Projekt-Team Als Projekt-Team werden „alle Personen, die einem Projekt zugeordnet sind und zur Erreichung des Projektzieles Verantwortung für eine oder mehrere Aufgaben übernehmen“ bezeichnet. (DIN 69 901) <?page no="103"?> 3.1 Projektaufbauorganisation 103 Ein Projekt-Team wird temporär zur kooperativen Bearbeitung einer komplexen Aufgabenstellung gebildet und ist meist aus Experten verschiedener Arbeitsbereiche zusammengesetzt. Die Dauer der Zusammenarbeit ist durch die Erreichung vorgegebener Ziele für Teilaufgaben oder maximaler Zeitspannen befristet, die aus der Projektstruktursowie Terminplanung abgeleitet sind. 51 Projektorganigramm Das Projektorganigramm beschreibt die Aufbauorganisation des Projekts im Rahmen der (organisatorischen) Projektstrukturplanung (PSP). Je nach Komplexität des Projektes stellen sich Projektorganigramm unterschiedlich umfangreich dar. Bei kleinen Projekten z.B. wie folgt: Abbildung 100: Typische Projektorganisation ‒ kleine Projekte Das Kernteam bezeichnet dabei diejenigen Projektmitarbeiter, die fix und meist für die gesamte Dauer dem Projekt zugeordnet sind. Im Gegensatz dazu werden im erweiterten Projekt-Team situativ Experten aus den Fachabteilungen hinzugezogen. z.B. d Juristin aus der Legal-Abteilung für einen Workshop zur Abstimmung der Haftungsregelung für die für den Kunden erstellte Software. Wichtig und oft herausfordernd ist hierbei die möglichst frühzeitige Einbindung dieser Personengruppe, die ja regulär nicht der Terminplanung des Projektes unterliegt. Für das Projekt sollte ein eindeutig benannter Projektsponsor die Auftraggeberschaft repräsentieren. Dies ist oftmals die entsprechende Abteilungsleitung. Bei externen Projekten ist der Auftraggeber ja ein Kunde. Aber auch hier empfiehlt es sich, einen internen Sponsor zu benennen. Bei großen Projekten bzw. bei mehreren Projekten parallel übernehmen PM-Teams (teilweise übergeordnet) Planungs-, Steuerungs- und Überwachungsaufgaben und koordinieren die (Teil-) Projekte. 51 nach Schlick, 2015 Projekt-Auftraggeberschaft Projekt- Sponsor Projekt- Leitung Projekt- Kernteam Erweitertes Projekt-Team Projekt- Auftraggeber Abbildung 101: Erweiterte Projektleitung <?page no="104"?> 104 Takt 3: Projektorganisation Das Projektorganigramm erweitert sich dann typischerweise wie folgt: Abbildung 102: Typische Projektorganisation ‒ große Projekte Entsprechend der im PSP gebildeten Teilaufgaben werden aufgrund der Begrenzung der Lenkungsspanne in größeren Projekten Teilprojekte gebildet. D.h. eine Teilprojektleitung koordiniert sodann die zugehörigen Arbeitspakete. In großen Projekten ist oftmals ferner eine Projektunterstützung, etwa in administrativen Aufgaben, im Einsatz, um die Projektleitung diesbzgl. zu entlasten. Im nachfolgenden Abschnitt „Rollen“ werden die verschiedenen Rollen in Projekten systematisch beschrieben. Das folgende Bild zeigt beispielhaft das Organigramm eines großen IT-Projekts, bei dem es um die landesweite Erneuerung der IT-Infrastruktur ging: 52 Beispiel Projekt Erneuerung IT-Infrastruktur Projektabschnitt I − Entwicklung Kernteam: Projektleitung, Teilprojektleiter, Projektcontroller, Projektkoordinator Projektmitarbeiter: Kernteam und alle Mitarbeiter der Teilprojekte Projektbeteiligte: Alle sonstigen Mitarbeiter, die zeitweise Projektaufgaben übernehmen Abbildung 103: Organigramm eines großen IT-Projekts 52 Wehnes, 2014 Projekt-Auftraggeberschaft Kernteam Projektmanagement-Team Lenkungsausschuss Projekt- Leitung Teilprojekt- Leitung 2 Teilprojekt- Leitung 1 Teilprojekt- Leitung 3 Führungskräfte Projekt-Sponsor Projektunterstützung TP-Team 1 Erweitertes Projekt-Team TP-Team 2 TP-Team 3 <?page no="105"?> 3.1 Projektaufbauorganisation 105 Das Projekt wurde aufgrund seiner Komplexität in Projektabschnitte aufgeteilt. Im zweiten Abschnitt wurde das Organigramm entsprechend der veränderten Aufgabenstellung im Rollout angepasst: Projektabschnitt II − Rollout Neu: 7 Regionale Rollout- Teams, Zentrales Migrationsteam Kernteam: Projektleitung, Teilprojektleiter, Projektcontroller, Projektkoordinator, Migrationsleiter, Technischer Migrationsleiter Abbildung 104: Organigramm eines großen IT-Projektes ‒ Abschnitt Rollout Allgemeine Systematik Der Aufbau des Projektorganigramms differenziert zwischen steuernden, fachlichen und unterstützenden Aufgaben, wobei die fachlichen Teilprojekte prozessorientiert gegliedert werden sollten. Je nach Projektumfeld (z.B. Projekt-Erfahrung der Fachabteilungen) wird das Projektorganigramm durch • Teilprojektsteckbriefe, • Aufgaben- und Rollenbeschreibungen sowie ein • RACI-Chart konkretisiert. Das Projektorganigramm wird im Projekthandbuch dokumentiert. Die Projektaufbauorganisation muss integrativ betrachtet werden mit der Work Breakdown Structure (WBS/ PSP), welches das Projekt bis auf Arbeitspaketebene detailliert. In diesem Sinne ist sie ein organisationeller Projektstrukturplan. Inhalte & Elemente der organisatorischen Projektstrukturplanung sind: • Teilprojekte (TP) • Arbeitspakete (AP, siehe auch WBS/ PSP) • Rollen o Bezeichnung o Definition / Beschreibung o Name / Besetzung <?page no="106"?> 106 Takt 3: Projektorganisation • Kommunikation o Berichtsweg o Zusammenarbeit o Boards Systematik zur Projektstrukturbildung Abbildung 105: Projektorganigramm − Systematik Im folgenden Video erläutere ich die gezeigte Struktur und zeige Ihnen, wie Sie Ihr (komplexes) Projekt systematisch aufsetzen können. ► Video 3.3 (St.Galler Modell), URL: https: / / youtu.be/ 1AAajGihfMI Wenden wir uns nun einmal der zweiten Aufgabe der Projektorganisation zu - der Eingliederung des Projektes in die (Linien-) Organisation des Unternehmens. Generell lassen sich folgenden Organisationsformen unterscheiden: Projekt in der Linie „Silo“: Die Projektarbeit wird durch Mitarbeiter in den Abteilungen (zusätzlich) durchgeführt. Die betroffenen Linienmanager teilen sich die Projektleitung. Abbildung 106: Funktionale Organisation Geschäftsführung Linienmanager Mitarbeiter Mitarbeiter Mitarbeiter Linienmanager Mitarbeiter Mitarbeiter Mitarbeiter Linienmanager Mitarbeiter Mitarbeiter Mitarbeiter Projektkoordination <?page no="107"?> 3.1 Projektaufbauorganisation 107 ▲ Können Sie einige typische Vor- und Nachteile erkennen? Vorteile Nachteile  vereinfachte Kosten- und Personalsteuerung  Flexibilität Personaleinsatz  Kontinuität in den Fachgebieten  Kommunikationskanäle gut etabliert  Konzentration von Fachwissen  keine Verantwortlichkeit der Projektziele  umständliche Entscheidungswege  Single point of contact nicht existent  hohe Koordination bedingt Vorlauf  Ideen sind auf Abteilungen ausgerichtet Matrix „2 Bosses“: Die Projektarbeit wird durch Mitarbeiter in den Abteilungen (oftmals zusätzlich) durchgeführt. Die Projektleitung ist eindeutig definiert, kommt in der Regel aus der am stärksten involvierten oder betroffenen Abteilung. Abbildung 107: Matrix-Organisation ▲ Können Sie einige typische Vor- und Nachteile erkennen? Vorteile Nachteile  Mitarbeiterverantwortung des PM‘s  funktionale Weisungsbefugnis  Linie muss Projekt unterstützen  gute Auslastung  zwei Vorgesetzte für Mitarbeiter  hohes Konfliktpotenzial (PM − LM)  Mitarbeiter behalten „fachliche Heimat“  2-fache Berichterstattung  hoher Koordinationsaufwand Projektbasierte Organisation „No Home“: Das Projekt ist als Organisationseinheit autark in die Linienorganisation integriert - oder das Unternehmen besteht sogar vollständig aus Projek- Geschäftsführung Linienmanager Mitarbeiter Mitarbeiter Projektleitung Linienmanager Mitarbeiter Mitarbeiter Mitarbeiter Linienmanager Mitarbeiter Mitarbeiter Mitarbeiter Projektkoordination <?page no="108"?> 108 Takt 3: Projektorganisation ten. Die Mitarbeiter sind vollständig dem Projekt zugeordnet, die Projektleitung übt die fachliche und disziplinarische Führung aus. Abbildung 108: Projektbasierte Organisation ▲ Können Sie einige typische Vor- und Nachteile erkennen? Vorteile Nachteile  PL besitzt höchste Autorität  effiziente Projektorganisation  optimale Kommunikationswege  SPOC − Single Point of Contact  hohe Flexibilität  Personal verbleibt länger im Projekt  Integrationsängste der Mitarbeiter (Team wird am Ende des Projektes aufgelöst)  hohe Kostenintensität  gleichmäßige Auslastung des Teams schwierig  wenige Karrieremöglichkeiten Projektleitung im Stab „Einflussorganisation“: Die Projektleitung ist außerhalb der Linie in einer Stabsstelle, oftmals anhängig an die Geschäftsführung, angesiedelt. Dies kann auch aus einer zentralen Projektorganisation, dem Project Management Office, heraus gestaltet sein. <?page no="109"?> 3.1 Projektaufbauorganisation 109 Abbildung 109: Projektleitung im Stab ▲ Können Sie einige typische Vor- und Nachteile erkennen? Vorteile Nachteile  unabhängige Zielvorgaben  Bestimmung der Projektschwerpunkte  Überwachung des Projektablaufes (Zeit, Kosten, Leistung)  keine organisatorische Veränderung  hohe Flexibilität bzgl. Personaleinsatz  Stab: nur Beratungs- und Informationsfunktion  keine Weisungsbefugnis; ggf. geringe Akzeptanz  selbstständige Konflikt- und Problemlösung nicht möglich  wenn keine starke Persönlichkeit: sehr ineffiziente Organisationsform In der Praxis existieren natürlich oftmals Mischformen oder Varianten dieser vorgestellten typisierten Organisationsformen: Abbildung 110: Befugnisse der Projektleitung <?page no="110"?> 110 Takt 3: Projektorganisation Die gewählte Organisationsstruktur nimmt Einfluss auf: • die Befugnisse der Projektleitung (PL) • die Einsatzmittelverfügbarkeit • die Steuerung des Projektbudgets • die Projektleiter- und Mitarbeiterrolle Folgenden Abbildung zeigt eindrucksvoll den Zusammenhang zwischen Organisationsform und Weisungs- und Entscheidungsbefugnissen: 53 Abbildung 111: Organisationsformen und Weisungsbefugnisse ▲ Wo findet sich Ihr Projekt oder ein Vergleichsprojekt in Ihrer Organisation in dieser Systematik wieder? ▲ Ist Ihnen die Konsequenz dieser Einordnung klar? Der Vergleich der Organisationsformen bringt typischerweise folgende Konsequenzen zum Vorschein: 53 Schlick, 2015, zitiert nach Burghardt, 2008, modifiziert <?page no="111"?> 3.1 Projektaufbauorganisation 111 Abbildung 112: Vergleich der Organisationsformen Schauen Sie zum Abschluss dieses Kapitels noch im folgenden Video, wann sich typischerweise welche Organisationsform anbietet. ► Video 3.4 (Einordnung), URL: https: / / youtu.be/ Z9XnY9VVwvQ 3.1.1 Rollen im Projekt Wir starten diesen Abschnitt ebenfalls mit einem Video: ► Video 3.5 (Rollenübersichten), URL: https: / / youtu.be/ bphL_UMZ4B4 Der Ausgestaltung der Projektrollen kommt also für die Durchsetzungskraft und auch andere Aspekte der Projektorganisation eine zentrale Rolle zu. Befassen wir uns daher einmal damit methodisch. Vorab: ��� Die reine Benennung einer Rolle reicht in der Regel nicht aus! Es bedarf einer klaren Rollendefinition, um Missverständnisse und Konflikte zu vermeiden. Definition Rolle 54 „Eine Rolle ist eine Zusammenfassung von Aufgaben, welche von einer qualifizierten Person unter normalen Umständen bewältigt werden können. (Synonym: Funktionsstelle) Eine Rolle wird grundsätzlich/ in der Regel unabhängig von einem potenziellen Inhaber gebildet. Dabei ist jede Rolle mit Rechten und Pflichten verbunden.“ Aufgaben − Befugnisse − Verantwortung • Rechte bzw. Kompetenzen werden auch als Befugnisse bezeichnet. Beispiel : Beschaffung von Material bis zu einer Höhe von 10.000 EUR. • Pflichten bzw. Ziele werden auch als Verantwortung bezeichnet. Beispiel : Sicherstellung der termingerechten Abgabe des Fachkonzepts. • Darüber hinaus werden einer Rolle Aufgaben zugeordnet. Beispiel : Erstellung von Statusberichten. 54 1 angelehnt an Capaul/ Steingruber, 2010 <?page no="112"?> 112 Takt 3: Projektorganisation Abbildung 113: Aufgaben − Befugnisse - Verantwortung von Rollen Beispiel Abbildung 114: Strukturierte Rollenbeschreibung ‒ Beispiel ▲ Beschreiben Sie doch einmal eine Rolle aus Ihrem Umfeld mit Hilfe des Schemas: Abbildung 115: Strukturierte Rollenbeschreibung ‒ Template Aufgaben, Befugnisse und Verantwortung (A/ B/ V) werden in einer Rollenschreibung festgehalten. Die Rollenbeschreibung erfordert ein stimmiges Zusammenwirken der drei Komponenten. Aufgaben Befugnisse Verantwortung  Welche Befugnisse werden benötigt, um das Ergebnis zu erreichen? Beispiel: Zeichnungsberechtigungen, Weisungsbefugnisse  Welche Ressourcen werden benötigt, um das Ergebnis zu erreichen? Beispiel: Projektmitarbeiter  Welche Verantwortung ist mit der Erfüllung der Rolle verbunden? Beispiel: Budget- oder Ergebnisverantwortung  Welche Ziele sind mit der Rolle verbunden? Beispiel: Termineinhaltung  Welche Aktivitäten sind zur Wahrnehmung der Rolle nötig? <?page no="113"?> 3.1 Projektaufbauorganisation 113 Kongruenzprinzip Aufgaben, Befugnisse und Verantwortung müssen stimmig sein (Kongruenzprinzip): Abbildung 116: Kongruenzprinzip der Rollendefinition ▲ Bitte überlegen Sie doch einmal, was die jeweiligen Konsequenzen sind, wenn das Kongruenzprinzip nicht gewährleistet ist. Bei der Ausgestaltung und Besetzung der Rollen im Projekt gilt: • Alle Projektmitarbeiter müssen das gleiche Bild von jeder Teamrolle haben. • Rolleninhaber müssen mit der zugedachten Rolle einverstanden sein und sich mit dieser identifizieren. • Diese sollten bedarfs-, nicht verfügbarkeitsorientiert besetzt werden. Personen können mehrere Rollen innehaben. • Rollenkonflikte müssen vermieden werden, z.B. Qualitätsprüfer ≠ Produktersteller. 3.1.1.1 Kernrollen im Projekt Mit Hilfe des A/ B/ V-Schemas lassen sich Rollen systematisch beschreiben. Bewährt hat sich dazu neben der tabellarischen Form auch ein „One Pager“. Schauen Sie sich die Rollenbeschreibungen für die Kernrollen aus einem Projekt doch mal an. Ergänzt werden diese um den sogenannten Berichtsweg, d.h. die Frage, wie die hierarchische Situation definiert ist. Abbildung 117: Rollenbeschreibung: Projektleitung <?page no="114"?> 114 Takt 3: Projektorganisation Im Unified Project Management Framework (UPMF) wird die Projektleitungsrolle in zwei Ausprägungen ausgestaltet: Projektmanager (Prozesse) Der/ die Projektmanager/ in (Prozesse) trägt die Prozessverantwortung auf der PM-Ebene. Er kann, nach Beauftragung durch den Lenkungsausschuss, die Projektabwicklung durchführen. Zu seinen Aufgaben zählen die Sicherstellung, dass alle PM-Prozesse fachlich korrekt ausgeführt werden und dass die PM-Prozessgruppen in korrekter Reihenfolge zyklisch durchlaufen werden. Projektmanager (Leistungen) Der/ die Projektmanager/ in (Leistungen) trägt die Verantwortung für die Projektprodukte beziehungsweise -leistungen und damit für die Prozesse der fachlichen Leistungserstellungsebene, zum Beispiel der Systementwicklung. Er stellt sicher, dass die Anforderungen an die Projektergebnisse erfüllt werden, priorisiert diese gegebenenfalls und leitet bei Abweichungen Korrekturmaßnahmen ein. Die Differenzierung der Rolle der Projektleitung unterstreicht die Kompatibilität des UPMF auch zu agilen Vorgehensweisen (vgl. Scrum Master beziehungsweise Product Owner) sowie auch die in der Praxis vielfach anzutreffende Aufteilung eines Projektleiters versus Projektmanagers. Abbildung 118: Rollenbeschreibung: Projektmitarbeiter Abbildung 119: Rollenbeschreibung: Auftraggeber Der Auftraggeber wird auch als Projektsponsor bezeichnet.  Erreichung der definierten Projektziele zur  Erzielung des geplanten Nutzens (Business Case) Verantwortung  In Projekten mit Lenkungsausschuss in der Regel dessen Vorsitzender  Unterstützung des Projektleiters zur Erreichung der Projektziele auf der Ebenen der Geschäftsleitung  Oberste Repräsentanz des Projekts in der Organisation  i.A. Bereitstellung des Projektbudgets  De-Eskalation bei Problemen Aufgaben  Verabschiedung und ggf. Veränderung des Projektauftrags/ Beauftragung des Projekts  Entscheidung über Projektabbruch  Entscheidung über Austausch der Projektleitung  Entlastung der Projektleitung und des Projektteams  Abnahme des Projektergebnisses Befugnisse  ggf. Geschäftsführung Berichtsweg Auftraggeber  Produkte stehen rechtzeitig zur Verfügung  ggf. Meldung/ Eskalation an die PL/ TPL  Zeitnahe Meldung von Fehlentwicklungen/ Störungen an die PL/ TPL Verantwortung  Termingerechte Abarbeitung der delegierten Aufgaben  Regelmäßige Rückmeldungen über Fortschritt der Arbeiten, Zeitaufwände und Prognosen  Unterstützung der Projektleitung, z.B. bei der Projektplanung Aufgaben  Vorbereiten / Einfordern von Entscheidungen bei der Projektleitung Befugnisse  Bericht an die Projektleitung Berichtsweg Projektmitarbeiter <?page no="115"?> 3.1 Projektaufbauorganisation 115 Abbildung 120: Rollenbeschreibung: Teilprojektleitung Die Teilprojektleitung wird auch als Teamleitung bezeichnet (vgl. PRINCE 2). Schauen wir uns die Rolle des Projektleiters noch einmal genauer an. Folgende Anforderungen an Projektmanager zeigen die ganze Breite eines Anforderungsprofils. Die erforderliche Fachkompetenz nimmt nur einen relativ kleinen Teil ein und hängt vom jeweiligen Projekt ab. Führungs- & Sozialkompetenz  klare Visionen und Ziele  Kkooperativer Arbeitsstil mit hoher Delegationsfähigkeit  Verhandlungsgeschick und Durchsetzungsfähigkeit  überzeugendes, sicheres Auftreten  vertrauenswürdig Methodenkompetenz  fundiertes Methodenwissen  Methoden-Know-how im PM  Kreativitätstechniken, Problemlösungstechniken  Organisationstalent Fachwissen & Betriebswirtschaft  fachlicher Überblick erforderlich; Detailwissen weniger wichtig  Unternehmenskenntnisse  betriebswirtschaftliche Kenntnisse Der Projektleiter ist eine herausgehobene Projektrolle mit Führungsverantwortung. Mitarbeiterführung kann definiert werden als die „ Einwirkung auf die Mitarbeiter, so dass sie ein bestimmtes Ziel erreichen. “ 55 Dies stellt also besondere Anforderungen an die Fähigkeiten diesbezüglich. Erfolgreiche Führungsprinzipien eines Projektleiters sind: 55 Litke, 2012 Fachkompetenz Führungs-/ Sozialkompetenz PM- Methodenkompetenz Abbildung 121: PM-Anforderungen <?page no="116"?> 116 Takt 3: Projektorganisation - Mensch steht im Mittelpunkt o Probleme der Mitarbeiter haben Priorität o Feedback geben - Voraussetzungen für gute Arbeitsergebnisse schaffen und pflegen - Führung durch Überzeugung und Argumentation - Prinzip der „offenen Tür“ für alle Teammitglieder o Offene und direkte Kommunikation (keine langen „Dienstwege“) - Förderung von Initiative und Eigenverantwortung o Ergebniskontrolle statt Verfahrenskontrolle o Klare Festlegung von Aufgaben, Kompetenzen und Verantwortung (AKV) o Keine Rückdelegation Bei der Wahl des Führungsverhaltens sind personenbezogene und situative Bedingungen zu beachten. Nach Staehle lassen sich folgende Führungsstile unterscheiden: 56 Abbildung 122: Skala der Führungsstile 56 Staehle, 2014, modifiziert <?page no="117"?> 3.1 Projektaufbauorganisation 117 Im modernen Projektmanagement sind der beratende, konsultative und partizipative Führungsstil angebracht. Zunehmend finden ‒ gerade auch in IT-Projekten ‒ in agilen Vorgehensweisen auch delegative Führungsstile Anwendung … im Grunde findet hier keine wirkliche Führung mehr statt, sondern eine Selbstorganisation bzw. Selbststeuerung des Teams. Wann welches Führungsverhalten angebracht und zielführend ist, sollte letztlich die konkrete Projekt- und Teamsituation entscheiden. So bevorzugen Mitarbeiter je nach Typ mehr oder weniger stark ausgeprägte Freiheiten und Entscheidungsspielräume. 3.1.1.2 Weitere Rollen Neben den Kernrollen haben sich eine Reihe weiterer Rollen in der erfolgreichen Projektdurchführung bewährt. Diese werden insbesondere im PRINCE2-Standard für Projektmanagement postuliert und beschrieben: Abbildung 123: Rollenbeschreibung: Projektunterstützung Abbildung 124: Rollenbeschreibung: Nutzervertretung Die Nutzervertretung ist strategisch und auch operativ aufgestellt - im Lenkungsausschuss (s.u.) sowie im Projekt-Team.  Sicherstellung der Nutzung der ggf. verbindlichen PM-Werkzeuge Verantwortung  Administrative Unterstützungsleistung für ein einzelnes Projekt („Projektbüro“)  Rat und Hilfe beim Umgang mit den Projektmanagement- Tools  (Unterstützung bei) Datenerfassung, z.B. Tätigkeitsnachweise, Projektsachstände  Begleitung, administrative Betreuung wie Archivierung und Ablage von Daten und Dokumenten Aufgaben  Anstoß von Verbesserungen des PM-Instrumentariums Befugnisse  Projektleitung Berichtsweg Projektunterstützung <?page no="118"?> 118 Takt 3: Projektorganisation Abbildung 125: Rollenbeschreibung: Lieferantenvertretung Lieferant kann ein externer Dienstleister, aber auch beispielsweise die interne IT sein. Abbildung 126: Rollenbeschreibung: Projektsicherung Die Wahrnehmung der Rolle erfolgt in der Regel thematisch fokussiert durch verschiedene Personen. 3.1.2 Projektgremien Schließlich sind im Kontext eines Projektes verschiedene Gremien zu bilden. Je nach Projektgröße und Komplexität variieren diese hinsichtlich ihrer Besetzung, ihres Umfangs sowie ihres Tagungsrhythmus. Wichtigstes Gremium, das in keinem größeren Projekt fehlen darf, ist der Lenkungsausschuss, oftmals auch Lenkungs- oder Steuerungskreis genannt: <?page no="119"?> 3.1 Projektaufbauorganisation 119 Abbildung 127: Rollenbeschreibung: Lenkungsausschuss Das sogenannte Change Control Board (dt. „Änderungssteuerungsgruppe“) wird bei wichtigen fachlichen Änderungen einberufen (Festlegung hierzu im Projekthandbuch). Die Durchführung der Änderung selbst wird durch die Projektleitung geplant und angestoßen. Abbildung 128: Rollenbeschreibung: Change Control Board Projektbeispiel: Kleiner Lenkungskreis Auch auf der strategischen Steuerungsebene eines IT-Projekts, auf der klassischerweise ein Lenkungsausschuss etabliert war, kam der sog. Kleine Lenkungskreis, KLK, zum Tragen. Die Bildung eines KLK ‒ bestehend aus kaufmännisch verantwortlichen Managern der Auftragnehmer- und der Auftraggeberseite sowie der jeweiligen operativen Projektmanager ‒ ermöglichte, den Entscheidungsfluss signifikant zu verbessern. Der KLK tagte in engen Abständen oder ad hoc und wurde als wichtiger, wenn auch nicht alleiniger Teil des Lenkungsausschusses mit der Kompetenz ausgestatten, Entscheidungen übergeordneter Bedeutung kurzfristig zu fällen, sodass ein weiterer Lauf des Projekts nicht etwa durch Wartezeit auf den nächsten turnusgemäßen Lenkungsausschuss behindert wurde. Dabei wurde im Zweifel auch mit überschaubarem Risiko in Kauf genommen, dass durch den KLK getroffene Entscheidungen letztlich durch den Gesamt- Lenkungsausschuss nicht bestätigt wurden und Korrekturen vorzunehmen waren. Letzteres blieb de facto ein theoretisches Konstrukt, sodass sich das Vorgehen vollends bewährt hat.  Entscheidung, wie bzgl. einer oder mehrerer zusammenhängender fachlicher Änderungen (Change Requests) verfahren werden soll Verantwortung  Bewerten der Projektsituation als Ausgangsbasis der zu treffenden Entscheidung  Erstellen von managementspezifischen Entscheidungskriterien als Basis der zu treffenden Entscheidung  Festlegen des weiteren Vorgehens, um Änderungsanträge umzusetzen Aufgaben  Treffen der Entscheidung zu einer oder mehreren Problemmeldungen/ Änderungsanträgen auf Basis der Problem-/ Änderungsbewertung Befugnisse  Auftraggeber/ Lenkungsausschuss Berichtsweg Change Control Board 1 <?page no="120"?> 120 Takt 3: Projektorganisation 3.1.3 RACI-Matrix Eine schlanke und praxisbewährte Methode, um Rollen bzw. Personen im Projekt den definierten Aufgaben, z.B. in Form der Arbeitspakete, zuzuordnen ist die sogenannte RACI-Matrix. Mit der Definition von Verantwortlichkeiten und Mitwirkungen nach dem RACI-Modell gelingt die Zusammenführung des Projektstrukturplans und der Unternehmensorganisation auf Arbeitspaketebene in übersichtlicher Form. Abbildung 129: RACI - Zuordnung von Zuständigkeiten Dabei sind die Buchstaben wie folgt definiert: Responsible Accountable Durchführungsverantwortung: zuständig für die Ausführung und den Abschluss der Aufgabe. Freigabeverantwortung: verantwortlich und haftbar für Kosten und Auswirkungen (nur eine Person). Consulted Informed Fachliche Unterstützung: mitwirkend, muss/ soll beteiligt werden, liefert Input Informationsrecht: wird über die Inhalte/ Ergebnisse informiert. Dabei sollte die Durchführungsverantwortung eindeutig definiert werden, d.h. pro Ziele in der RACI-Matrix genau einmal vergeben werden. Alle anderen Zuordnungen können grundsätzlich beliebig oft eingetragen werden. Mit der RACI-Matrix gelingt es, gerade auch große Projekte mit vielen Vorgängen bzw. Arbeitspaketen in übersichtlicher, eindeutiger und vollständiger Form organisatorisch zu gestalten. In der Matrix sollten alle im Projekt beteiligten Rollen bzw. Personen aufgelistet sein. Dabei kann auch rollierend vorgegangen werden: über Platzhalter und Rollen bis schließlich zu konkreten Personen - je nach vorliegendem Kenntnisstand bzw. Projektfortschritt. Auf der Y-Achse werden vielfach die Elemente des Projektstrukturplans aufgetragen. Push oder Pull? Durch das vorgestellte Vorgehen zur rollierenden Ressourcenplanung wird der klassische Ansatz der Einsatzplanung operationalisiert, der die verfügbaren Kapazitäten den Projektbedarfen zuordnet - oder kurz: „Bring the people to the work“. Anders verhält es sich im Szenario des kapazitätsorientierten Pull-Systems, wie es mit dem Projekt-Kanban (folgt) umgesetzt werden kann. Der Pull-Mechanismus dreht die Planungslogik um zu einem „Bring the work to the people“, d.h. die geschilderten Schritte der rollierenden Ressourcenplanung passen so nicht <?page no="121"?> 3.1 Projektaufbauorganisation 121 mehr. Dennoch können und sollten sie in abgewandelter Form dazu dienen, die Personalbedarfe mit einem entsprechenden Zeithorizont zu erkennen, um dispositiv agieren zu können. Wir schauen später (bei den Ausführungen zum sogenannten Agilometer, folgt) noch einmal etwas genauer auf die Frage, wie Teams zu Projekten allokiert werden. Zum Abschluss dieses Abschnitts eine kleine zusammenfassende Aufgabe: ▲ Nun haben wir insgesamt eine ganze Reihe strukturierenden Elemente in der Projektplanung kennengelernt. Ordnen Sie doch einmal nachfolgend die Begriffe den richtigen Flächen oder Schnittmengen zu. Abbildung 130: Aufgabe: Zusammenhang innerhalb der Projektplanung 3.1.4 Lösungen ▲ Strukturierende Elemente in der Projektplanung Abbildung 131: Aufgabe: Zusammenhang innerhalb der Projektplanung ‒ Lösung Organisation Ablauf Produktstruktur Aufgaben- Struktur  RACI-Matrix  Vorgang  Teilprojekt  Stelle/ Rolle  PSP  Termine  Meilenstein  Teilaufgabe  Projektprozesse  Berichtsweg  Projektphasen Organisation Ablauf Produktstruktur Aufgaben- Struktur  RACI-Matrix  Vorgang  Teilprojekt  Stelle/ Rolle  PSP  Termine  Meilenstein  Teilaufgabe  Projektprozesse  Berichtsweg  Projektphasen <?page no="122"?> 122 Takt 3: Projektorganisation 3.2 Projekt-Vorgehensmodelle Im Laufe der Jahre haben sich verschiedenen Vorgehensmodelle zu klassischen und agilen Ansätzen gerade auch für IT-Projekte herausgebildet. Vorgehensmodelle beschreiben im engeren Sinne den strukturellen Ablauf eines Projekts. (Im weiteren Sinne enthalten sie auch Rollen, Artefakte etc.) Sie sind damit in der Regel an einen bestimmten Typ von Projekt gebunden - ein Bauprojekt hat eben einen anderen Ablauf als ein IT-Projekt. Gleichwohl gibt es auch einige universelle Merkmale. Allgemein spricht man von Lifecycle (Lebenszyklus) eines Projekts (nach DIN). In den letzten ca. zwei Jahrzenten hat sich dabei eine Polarisierung zwischen sogenannten „klassischen“ und „agilen“ Vorgehensmodellen herauskristallisiert. Die klassischen Modelle sind charakterisiert durch einen plangetriebenen Ansatz und eine hierarchisch abgesetzte Projektleitungsrolle („Plan & Control“). Die agilen Vorgehensweisen wurden essenziell durch das Agile Manifest der Software-Entwicklung fundiert und sind eine iterative-inkrementelle Vorgehensweise und weitgehende Selbstorganisation des Projekt-Teams charakterisiert („Inspect & Adapt“). In einer Symbiose etablieren sich zunehmend Mischformen - die hybriden Modelle. Bevor wir zu einigen der bekanntesten Vorgehensmodelle kommen, erläutere ich Ihnen in den folgenden Videos die methodischen Grundlagen der klassischen und der agilen Ansätze. ► Video 3.6a-c (klassisch vs. agil) URL: https: / / youtu.be/ 88P1ub7HDfU URL: https: / / youtu.be/ bjmAw8X6Vp4 URL: https: / / youtu.be/ Rh6WFyOs_70 Lassen Sie uns zunächst einmal einige klassisch-sequenzielle Vorgehensmodelle anschauen. 3.2.1 Klassische Vorgehensmodelle 3.2.1.1 Wasserfall „Wasserfall“ ist ein lineares Modell, in dem die einzelnen Projektphasen sequenziell nacheinander angeordnet sind. Die Phasen umfassen sachlogisch zusammenhängende Tätigkeiten, die zu einem entsprechenden Projekt-(zwischen-)ergebnis führen, z.B. zu einem Konzept. Eine Phase endet mit einem Meilenstein, an dem die Arbeiten und Ergebnisse überprüft und synchronisiert werden und die nächstfolgende Phase freigegeben wird. Der grundlegende Ablauf sieht nur eine Richtung vor, wobei Rücksprünge aber möglich ‒ wenngleich in der Regel mit Mehraufwand verbunden ‒ und daher nicht erwünscht sind. Insofern setzt der sinnvolle Einsatz des Wasserfallmodells eine gewisse Planbarkeit und Stabilität und vor allem eine kausale Arbeitsfolge voraus. Abbildung 132: Wasserfallmodell <?page no="123"?> 3.2 Projekt-Vorgehensmodelle 123 Beispiele für IT-Projekte [1] Anforderungsanalyse und -spezifikation resultiert in dem Lastenheft [2] Systemdesign und -spezifikation resultiert in dem Software-Design und in der Software- Architektur [3] Programmierung und Modultests resultiert in der eigentlichen Software [4] Integrations- und Systemtest [5] Auslieferung, Einsatz und Software-Wartung Varianten des Wasserfallmodells ermöglichen die teilweise Parallelisierung bzw. das Vorziehen von Phasen(-starts), wodurch sich die Phasen überlappen. 3.2.1.2 V-Modell Das V-Modell ist eine Weiterentwicklung des Wasserfallmodells. Es ergänzt dieses im Wesentlichen um die zur kaskadenförmig gestalteten Konzepterstellung komplementären Prozesse der Qualitätssicherung (QS). Auf diese Weise entsteht die namensgebende V-Struktur. Abbildung 133: V-Modell Auf der linken Seite des „V“ umfasst das Modell die konzeptionelle Entwicklung des Systems durch die wasserfallmäßig aufeinander folgenden Phasen: [K1] Analyse der allgemeinen Anforderungen [K2] Anreicherung der funktionalen und nichtfunktionalen Anforderungen an die Systemarchitektur [K3] Systementwurf mit Planung der Komponenten und Schnittstellen [K4] Konzeption der Softwarearchitektur im Detail Auf dieser Basis wird schließlich das System entwickelt [E]. Demgegenüber stehen auf der QS-Seite des „V“ die Teilphasen [Q1] Unit Tests zur Überprüfung der reinen Funktionalität (ref. [K1]) [Q2] Integrationstests zur Überprüfung des Zusammenwirkens der Komponenten (ref. [K2]) [Q3] Systemtests zur Überprüfung der allgemeinen Anforderungen an das System (ref. [K3]) [Q4] Abnahme zur Überprüfung der Anwenderakzeptanz für den täglichen Betrieb (ref. [K4] <?page no="124"?> 124 Takt 3: Projektorganisation Das V-Modell XT ist eine für Bundesbehörden entwickelte Ausgestaltung, die auch in der Privatwirtschaft weite Verbreitung gefunden hat, „XT“ steht für Extreme Tailoring, d.h. die grundsätzlich umfangreiche Möglichkeit, das Modell für die eigenen Bedarfe anzupassen. In seiner aktuellen Fassung enthält es auch agile Entwicklungsprinzipien. Einordnung linearer Vorgehensmodelle Kritik trifft insbesondere Modelle mit streng sequenziellem Vorgehen, daher existieren eine Reihe von Weiterentwicklungen. Meist betrifft Kritik nicht die Modelle selbst, sondern eine zu bürokratische Handhabung. Rücksprünge sind auch in diesen Modellen möglich, aber standardmäßig nicht vorgesehen/ eingeplant. Bei der Entwicklung materieller Produkte, im Anlagenbau und in der Bauwirtschaft gibt es eine weitgehende Akzeptanz. Hier einige ausgewählte positive Aspekte: - Modelle können an Projektgröße flexibel angepasst werden. - Projektleiter sollte Meilensteine immer dicht setzen und die gewünschten Meilensteinergebnisse sehr genau beschreiben! - Strukturierung des Projektes (Komplexitätsreduktion). - Gemeinsames Verständnis von Projektmanagement und einheitliche Vorgehensweise. - Transparenz über Fortschritt des Projektes über Meilensteinergebnisse (Projekt-Controlling und -Qualitätsmanagement). - Reduktion des Risikos der Projektabwicklung (Abbruchstellen in Form von Reviews). 3.2.2 Agile Vorgehensmodelle In der Praxis wird zunehmend in Form iterativer Vorgehensmodelle vorgegangen. Beim iterativen Modell werden mehrere Projektphasen so lange durchlaufen, bis das gewünschte Ergebnis erreicht worden ist. Wir können grundsätzlich differenzieren: Evolutionäre Vorgehensmodelle Ein noch nicht detailliert beschriebenes Endprodukt wird mittels zyklischem Durchlaufen von Phasen (Iteration) evolutionär weiterentwickelt: Abbildung 134: Evolutionäres Vorgehensmodell Abbildung 135: Inkrementelles Vorgehensmodell <?page no="125"?> 3.2 Projekt-Vorgehensmodelle 125 Inkrementelle Vorgehensmodelle Evolutionäres Vorgehensmodell (Abbildung 135), bei dem hingegen ein spezifiziertes Endprodukt in Teilprodukte (Inkremente, lat.: Zuwachs) zerlegt wird, die mittels zyklischem Durchlaufen von Phasen zu einem Ganzen weiterentwickelt werden. Der Benutzer hat nach jeder Iteration ein funktionierendes Produkt, wie in Abbildung 135 gezeigt. Lassen Sie uns einmal im weiteren Verlauf einige iterativ(-inkrementell)e und letztlich agile Vorgehensmodelle anschauen. Beginnen wir mit dem … 3.2.2.1 Spiralmodell Eine alternative Weiterentwicklung des Wasserfallmodells ist das Spiralmodell, das bereits systematisch einen iterativ-inkrementellen Ablauf vorsieht. Dabei sieht jeder Spiraldurchlauf grundsätzlich folgende Schritte vor: [1] Festlegung der Ziele [2] Risikoanalyse, Beurteilung von Alternativen [3] [Weiter-)Entwicklung der Lösung inkl. Test [4] Planung der nächsten Phase Abbildung 136: Spiralmodell Das Modell beinhaltet somit ein risikogetriebenes Vorgehen, das aus Prototypen in mehreren Iterationen das endgültige System entwickelt. Dieses Vorgehen ‒ insbesondere für die Entwicklung des Produkts ‒ kann in den einzelnen Iterationen in Abhängigkeit von der Risikoanalyse variieren. <?page no="126"?> 126 Takt 3: Projektorganisation 3.2.2.2 Prototyping 57 In diesem Abschnitt lernen Sie das Prototyping kennen. Je nach Branche gibt es leicht unterschiedliche Auffassungen davon, was ein Prototyp ist und dementsprechend auch, was Prototyping bedeutet. Ganz allgemein ist Prototyping der Prozess zur Veranschaulichung der Idee und Funktionsweise eines Produktes oder Services. Prototyping ist auch in der Software-Entwicklung eine Methode, die schnell zu ersten Ergebnissen führt. Angefangen bei einer ersten einfachen Version erfolgte im Prototyping die schrittweise Annäherung an das fertige Endprodukt. Im Verlauf einer Produktentwicklung tauchen ständig Fragen auf, die mit Hilfe von Prototypen geklärt werden können, zum Beispiel:  Was ist die Kernfunktion eines Produktes?  Welcher Logik folgt die Interaktion?  Ist diese für den Nutzer nachvollziehbar und macht sie Spaß oder ist sie langweilig oder sogar frustrierend? Ziel des Prototyping ist es, möglichst frühzeitig Feedback zum Produkt einzuholen und dieses direkt in die weitere Entwicklung einfließen zu lassen. Probleme und Änderungswünsche können so frühzeitig erkannt werden. So bleibt die Entwicklung am Nutzerbedürfnis, die kostenaufwendige Entwicklung unnötiger Features wird in der Regel gespart und der Innovationsprozess wird beschleunigt. Bei allen Vorgehensweisen des (IT-)Prototyping soll eine neue Applikation oder allgemein eine Lösung erstellt werden. Je nach Art des Produkts, der Phase in der Entwicklung und der Zielgruppe kommen jedoch ganz unterschiedliche Prototypen zum Einsatz − es existieren unterschiedliche Arten von Prototyping. Nachfolgend werden folgende Arten näher vorgestellt:  das explorative Prototyping,  das evolutionäre Prototyping sowie  das experimentelle Prototyping. Beim explorativen Prototyping ist man sich bei einigen Anforderungen unsicher, ob diese so umsetzbar sind. Daher erstellt man für diese speziellen Anforderungen ein Prototyp. Falls die Umsetzung erfolgreich war, wird die Anforderung aufgenommen, der Prototyp wird verworfen. Beim evolutionären Prototyping sind einige Antworten definiert, viele Informationen und Ideen fehlen jedoch noch. Daher wird erst mal ein Prototyp entworfen, der dann immer weiterentwikkelt wird. Dies wird so lange gemacht, bis die fertige Applikation vorliegt. Beim experimentellen Prototyping soll eine neue Applikation erstellt werden, es ist jedoch aktuell noch nicht ganz klar, was überhaupt verlangt ist. Daher wird zuerst ein Prototyp erstellt, welcher aufgrund von technischen Möglichkeiten und Ideen weiterentwickelt wird. Anschließend werden die Anforderungen definiert, der Prototyp wird verworfen. Zusammenfassend: Abbildung 137: Arten des Prototyping 57 Grosser, o.J.; XO Projects, o.J. <?page no="127"?> 3.2 Projekt-Vorgehensmodelle 127 Zu Beginn der Entwicklung werden oft sehr einfache, sogenannte Low-File-Prototypen erstellt. Das können zum Beispiel Scribbles sein, Papier-Prototypen oder einfache digitale Wireframes (sehr frühe konzeptionelle Entwürfe einer Website oder eines Software-Front-Ends). Dabei spielen die Gestaltung und Funktion noch keine Rolle. Das Augenmerk liegt auf der Anordnung von Elementen und der Benutzerführung. Diese Low-File-Prototypen eignen sich insbesondere zur Unterstützung der Kommunikation innerhalb eines Projekt-Teams, zum Beispiel, um sich auf eine konkrete Idee zu einigen. Immer dann, wenn nicht auf einem gemeinsamen fachlichen Level kommuniziert wird, zum Beispiel zwischen Entwicklern und Endnutzern, ist eine solche stärkere visuelle Ausarbeitung nötig. Demgegenüber beinhalten High-File-Prototypen detaillierte Design-Entwürfe mit zum Beispiel konkreten Schriften, Formen und Farben. Sie simulieren schon recht genau das Endprodukt und dessen Funktionalität. High-File-Prototypen können sogenannte Mock-Ups sein, interaktive Click Dummies (ohne fachliche Funktionalität), aber auch physische Prototypen, die man mit Hilfe eines 3D-Druckers erzeugt. Ein Mock-Up ist ein Demonstrationsmodell (oftmals nur eine Attrappe), das genutzt wird, um das Design oder die Haptik des geplanten Produkts zu veranschaulichen. Mithilfe von hochwertigen Mock-Ups können am Ende der Ideenentwicklung bereits erste Ideen an Nutzern getestet werden. Am Ende des Prototyping stehen in erster Linie physische bzw. programmierte Prototypen, mit denen wesentliche Funktionen eines Produktes getestet werden können. 3.2.2.3 Scrum Scrum ist ein agiles Vorgehensmodell, das von Ken Schwaber und Jeff Sutherland im berühmten Scrum Guide 1995 erstmalig vorgestellt wurde. Sie gehören zu den Autoren, welche auch das Agile Manifest veröffentlicht haben. Im Fokus stand dabei der Entwicklungsprozess von IT-Produkten - mehr im Sinne einer kontinuierlichen Entwicklung als eines abgeschlossenen Projektes. Insbesondere stellt Scrum keinen vollständigen PM-Ansatz dar, fehlen doch viele Elemente des PM, wie sie im Unified Project Management Framework (UPMF) beschrieben sind, wie z.B. ein explizites Stakeholdermanagement. 58 Gleichwohl ist Scrum als meistgenutzter agiler Ansatz nicht mehr aus der Durchführung von IT-Projekten wegzudenken. 59 Vielfach werden organisationsspezifische PM-Elemente ergänzt oder mit anderen kombiniert, sodass sogenannte hybride Modelle entstehen. Doch zurück zu Scrum im Kern. Scrum versucht nicht, jeden Schritt vorzugeben, sondern bietet ein Rahmenwerk für ein agiles Prozessmanagement. Dieser Rahmen besteht z.B. aus Projektrollen und einem Prozessablauf, innerhalb dessen gewisse Gestaltungsfreiheiten bestehen, denn Agilität bedeutet auch, dass jede Firma individuelle Anpassungen an eigene Bedarfe vornehmen soll. 60 Folgende Auflistung vermittelt die wichtigsten Begriffe der Scrum-Methode: • Sprint: entspricht einer Iteration • Scrum Master: ist verantwortlich für das Einhalten des Scrum-Prozesses • Product Owner: ist als Fachexperte verantwortlich für die Anforderungen • Daily Scrum: ein Daily-Standup-Meeting 58 Hüsselmann, 2021, S. 58ff 59 Komus, 2020 60 Preußig, 2018, S. 132 <?page no="128"?> 128 Takt 3: Projektorganisation Abbildung 138: Scrum-Prozessmodell • Retroperspektive: ein Meeting zur Rückschau auf den Prozess zwecks kontinuierlicher Verbesserung • Review: ein Meeting, um Feedback zum aktuellen Inkrement zu erhalten • Definition of Done: vom ganzen Team akzeptierte Kriterien, wann genau eine Aufgabe als erledigt gilt • Product Backlog: die für das Produkt insgesamt umzusetzenden Aufgaben bzw. Anforderungen • Sprint Backlog: die für die nächste Iteration (Sprint) umzusetzenden Aufgaben bzw. Anforderungen. Die Artefakte in einem Scrum-Prozess Der Begriff Artefakte beschreibt Erzeugnisse, die während der Entwicklung als Zwischenergebnis entstehen. Die Artefakte in Scrum sind: • Inkrement: Das Inkrement ist ein Teilprodukt der Entwicklung, welches nach einer Iteration (Scrum: Sprint) entsteht. • Product Backlog: Das Product Backlog erfasst die insgesamt umzusetzenden Aufgaben für das Endprodukt. • Sprint Backlog: Die für die nächste Iteration (Sprint) umzusetzenden Aufgaben werden im Sprint Backlog festgehalten. Ein Inkrement ist das aus einem Sprint entstandene Teilprodukt, das bei jeder Iteration entsteht und auf dem vorherigen aufbaut. Die Besonderheit beim Inkrement im Scrum-Umfeld ist, dass jedes Teilprodukt individuell in einem einsatzfähigen Zustand ist, sodass der Kunde es auch verwenden könnte. Die vom Kunden geforderten Anforderungen an das Produkt werden im Product Backlog festgehalten. Dabei ist hervorzuheben, dass es nie als vollständig angesehen wird, da sich die Anforderungen im Laufe des Projektes ändern dürfen, um mit den Kundenwünschen bei sich ändernden Marktbedingungen auf dem neuesten Stand zu bleiben. Um zu differenzieren, welche Anforderungen bereits detailliert genug sind, um sie umzusetzen, werden sie als „ready“ markiert und können anschließend in das Sprint Backlog übernommen werden. Das Product Backlog enthält für jede Anforderung auch eine Schätzung des Arbeitsaufwands, der für die Umsetzung erforderlich ist. Die Schätzung wird von den für die Umsetzung eingeteilten Mitarbeiter direkt vorgenommen, wodurch ein möglichst genauer Wert gegeben sein soll. Um das Product Backlog <?page no="129"?> 3.2 Projekt-Vorgehensmodelle 129 kontinuierlich zu pflegen, wird es regelmäßig mit den Wünschen der Stakeholder abgeglichen. Anforderungen müssen auf den „ready“-Zustand gebracht werden, um sie im nächsten Sprint abzuarbeiten. Für diese Pflege des Product Backlog ist der Product Owner zuständig. Geplante Verbesserungen und Fehlerbehebungen am Produkt, die etwa aus dem Sprint Review hervorgehen, werden auch in das Product Backlog aufgenommen. Dabei werden die Produktanforderungen im Product Backlog geordnet und durchnummeriert. Dadurch soll gewährleistet werden, dass ersichtlich ist, welche der Anforderungen eine höhere Priorität haben als andere. Die Basis für das konkrete Arbeiten bildet das Sprint Backlog, denn hier werden die Aufgaben für den aktuellen Sprint aufgelistet. Unter Zuhilfenahme des Product Backlog werden passende Anforderungen für das folgende Inkrement ausgewählt und in konkreten Aufgaben formuliert. Dazu gehört auch die Aufwandsschätzung, denn durch ständige Pflege des Sprint Backlogs ist leicht ersichtlich, ob das Team noch im Zeitplan liegt. Durch Aufsummieren der geschätzten Dauer einzelner Aufgaben kann so leicht ermittelt werden, wie viel Arbeit bereits erledigt ist und wie viel noch vor dem Team liegt. Dabei gehört das Sprint Backlog dem Team, welches für die Erledigung der Aufgaben zuständig ist. Sie bestimmen, welche Aufgaben aufgenommen werden, den aktuellen Fortschritt und wer für die Erledigung zuständig ist. Es ist nicht erlaubt, dass Außenstehende Aufgaben hinzufügen. Die Rollen für das Scrum Team Bei Scrum gibt es im Kern konkret drei Rollen für das Team: • ein Scrum Master, • ein Product Owner und • das Development Team. Es ist nicht ausgeschlossen, aber nicht ratsam, dass der Scrum Master und der Product Owner dieselbe Person sind. Um Interessenskonflikte zu vermeiden, trennt man diese Rollen also auf, denn es ist häufig der Fall, dass der Scrum Master die Prozesse strikt einhalten möchte, während der Product Owner möglichst viele Kundenwünsche erfüllen möchte. Ansonsten sind in der Praxis Doppelrollen möglich und üblich. Den Scrum Master gibt es nur einmal. Er ist für die Einhaltung der Regeln des Scrum-Prozesses verantwortlich und berät Stakeholder und Teammitglieder zu den Vorgängen. In folgender Aufstellung sind einige wichtige Verantwortlichkeiten zusammengefasst. Er … • schafft Verständnis für Notwendigkeit klarer Product-Backlog-Einträge im Scrum-Team, • vermittelt das richtige Verständnis von Agilität und ihrer Anwendung, • coacht das Entwicklerteam zur Selbstorganisation und funktionsübergreifender Teamarbeit, • beseitigt Hindernisse, die das Team aufhält, • leitet und coacht die Organisation bei der Einführung von Scrum, • identifiziert Möglichkeiten zur Produktivitätssteigerung. Wie beim Scrum Master wird die Rolle des Product Owner genau einmal vergeben. Seine Nähe zum Kunden soll gewährleisten, dass er die Anforderungen genau kennt. Seine Verantwortlichkeit besteht darin, dem Team das gesamte notwendige Wissen über das Produkt zu vermitteln, welches es für die Realisierung benötigt. Er ist insbesondere für die Erstellung und Pflege des Product Backlog verantwortlich. Er stellt sicher, dass das Entwicklerteam die Einträge im Product Backlog genau versteht. Weiterhin soll er sicherstellen, dass die Einträge im Product Backlog immer so sortiert sind, dass die Ziele optimal erreicht werden. Außerdem muss der Product Owner das Product Backlog für das gesamte Team sichtbar und verständlich präsentieren, damit klar ist, woran als Nächstes gearbeitet wird. <?page no="130"?> 130 Takt 3: Projektorganisation Die Entwickler, die die Anforderungen in das fertige Produkt umsetzen sollen, nennt man Development Team. Bei Scrum sticht heraus, dass die Entwickler eine besondere Verantwortung für die eigenen Aufgaben und den Gesamtprozess tragen: sie haben ein Mitspracherecht, an welcher Aufgabe sie als Nächstes arbeiten, und sind dafür verantwortlich, diese Aufgabe ins Verhältnis zu den aktuellen Aufgaben der anderen Entwickler zu setzen. Sie sollen dafür Sorge tragen, dass sie selbstständig die Abhängigkeiten der verschiedenen Aufgaben abwägen, um innerhalb eines Sprints das bestmögliche Zwischenprodukt zu entwickeln. Anders als im klassischen Projektmanagement, in dem der Projektleiter diese Reihenfolgen festlegt, soll durch die Eigenverantwortung bei Scrum die Produktivität maximiert werden. Hierbei sind zwei Grundregeln für die Selbstorganisation und die Autonomie des Development Teams essenziell: • Die Entwickler arbeiten ausschließlich nach den fachlichen Angaben des Product Owners. • Die Entwickler dürfen nicht von Außerhalb des Scrum-Prozesses zusätzliche Aufgaben bekommen. Weitere wichtige Regeln gehen aus der offiziellen Beschreibung des Scrum-Prozesses hervor, welche folgend zusammengefasst sind: • Keiner, auch nicht der Scrum Master, kann dem Development Team vorschreiben, wie das Produkt aus dem Product Backlog erstellt wird. • Innerhalb des Development Teams gibt es keine Hierarchien, auch nicht auf fachlicher Ebene. • Einzelne Entwickler können fachspezifische Fähigkeiten haben, die Rechenschaftspflicht liegt dennoch beim gesamten Team. • Scrum sieht die sinnvolle Teamgröße von neun Entwicklern vor, um diese Art der Arbeitsorganisation effizient zu gestalten. Da Scrum eine Methode des Prozessmanagements darstellt und nicht des Projektmanagements, gibt es bewusst keinen Projektleiter. „Das Prozessmanagement kann also in ein Projektmanagement eingebettet sein. Letzteres hat dann auch einen Projektleiter.“ 61 Je nach Firmenpolitik kann der Scrum Master die klassischen Aufgaben des Projektleiters übernehmen, oder sie werden auf die Teammitglieder aufgeteilt. Allgemein sollte im Scrum durch Selbstmanagement aber weniger Management nötig sein. Die Ereignisse in einem Scrum-Projekt Wie bereits kennengelernt, gibt es im Scrum den sogenannten Sprint als Iteration. Das besondere bei Scrum ist, dass es ein paar Regeln zu beachten gilt. Die Dauer der Sprints darf höchstens 4 Wochen betragen, wobei sich die Dauer der einzelnen Sprints innerhalb des Scrum-Projekts nicht verändern soll und die Sprints zeitlich direkt aneinander liegen. Die Anforderungen für den jeweiligen Sprint werden einmal vorher festgelegt, danach dürfen keine weiteren hinzukommen. Der Umfang der Anforderungen darf vom Development Team reduziert werden, wenn sonst zum Abgabezeitpunkt kein fertiges Zwischenprodukt vorgelegt werden könnte oder gar das Abgabedatum verschoben werden müsste. Ereignisse, die zu einem Sprint stattfinden, sind das Sprint Planning, der Daily Scrum, der Sprint Review und die Sprint Retrospective, die im Folgenden näher erläutert werden sollen. Das gesamte Scrum Team hält zu Beginn eines Sprints das Sprint Planning Meeting ab, bei dem festgelegt wird, welche Anforderungen im aktuellen Sprint umgesetzt werden sollen. Die Einbindung aller Teammitglieder soll dabei helfen, die Motivation und das Verantwortungsbewusstsein der Mitglieder zu stärken. Ziel des Meetings ist es, alle Aufgaben zu planen, die für das nächste Inkrement realistisch erledigt werden können. Der Product Owner soll dabei die ausgewählten Einträge aus dem Product Backlog so erklären, dass es keine Unklarheiten gibt. 61 Preußig, 2018, S. 144 <?page no="131"?> 3.2 Projekt-Vorgehensmodelle 131 Es vermittelt hier zwischen den Stakeholdern und dem Development Team. Am Ende des Termins soll das gesamte Team eine konkrete Vorstellung vom fertigen Teilprodukt dieses Sprints haben. Der Scrum Master sorgt für die korrekte Durchführung des Sprint Plannings. Dabei geht es auch um die Einhaltung des Zeitfensters, das bei einem 4-Wochen-Sprint maximal 8 Stunden betragen darf, bei kürzeren Sprints proportional weniger. Der Daily Scrum ist eine kurze Tagesbesprechung (Daily Standup Meeting). Um langwierige und unproduktive Meetings zu vermeiden, sollen diese Tagesbesprechungen bewusst im Stehen abgehalten werden. Die drei Fragen, die jedes Teammitglied dabei beantworten soll, sind: • Was habe ich seit dem letzten Daily Scrum konkret erreicht? • Woran arbeite ich heute? • Was hält mich von bestimmten Aufgaben ab? Sollte es akute Probleme bei einem Entwickler geben, werden vom Team präzise Gegenmaßnahmen geplant, um bei der Bewältigung der Aufgabe zu helfen. Durch das Daily Scrum soll das Team reibungslos arbeiten und den Scrum Master auf dem Laufenden halten. Eine Dauer von 15 Minuten soll dabei nicht überschritten werden, wobei das Meeting immer am selben Ort zur selben Zeit stattfinden soll. Der Scrum Master sorgt für die korrekte Einhaltung der Regeln. Das Sprint Review soll durch eine Nachsteuerung von Projektanforderungen eine hohe Kundenzufriedenheit hervorbringen. Dabei wird zugrunde gelegt, dass der Kunde ein Produkt meist erst dann besser versteht, wenn er es nutzen und Erfahrungen in der Anwendung sammeln kann. Hier wird den Stakeholdern am Ende des Sprints das fertige Teilprodukt präsentiert. Das Product Backlog kann unter Umständen angepasst werden, da die Stakeholder nun den aktuellen Arbeitsstand des gesamten Projektes kennen, und können nachsteuern. Bei einem 4-wöchigen Sprint sollte das Sprint Review nicht länger als 4 Stunden dauern. Retroperspektiven dienen der Selbstreflektion und Verbesserung des Projekt-Teams und der Prozesse. Bei diesem Meeting soll das Scrum Team die Zusammenarbeit, die Werkzeuge und die Prozesse der Zusammenarbeit reflektieren und Verbesserungsvorschläge machen. Die Sprint Retrospective findet zwischen den Sprint Reviews des aktuellen und dem Sprint Planning des nächsten Sprints statt. Die Dauer des Meetings soll bei maximal 3 Stunden liegen, wenn die Sprintdauer 4 Wochen beträgt. 3.2.2.4 eXtreme Programming Extreme Programming (XP) ist eine iterative Vorgehensweise zur Entwicklung von Software. Es setzt sich in der ursprünglichen Fassung aus den aufeinander aufbauenden Elementen Values (Werte), Principles (Prinzipien) und Practices (Techniken) zusammen. Neue Funktionalitäten werden permanent entwickelt, integriert und getestet. Für die zu entwickelnden Funktionalitäten werden jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (Prototyping) und ein Akzeptanztest durchgeführt. XP eignet sich für kleine bis mittlere Teams mit bis zu 15 Personen und ist ein strenger und disziplinierter Entwicklungsprozess, der stark auf die Kundeneinbindung fokussiert ist. Die Rollen im XP Die Rollen im XP sind nicht in Stein gemeißelt und dienen nur der anfänglichen Orientierung. Ziel ist, dass jeder im XP-Team im Rahmen seiner Möglichkeiten, auch rollenübergreifend, zum Gesamterfolg beiträgt. - Produktbesitzer … hat Verantwortung, setzt Prioritäten, Entscheider für bestes ROI. Beispiele : Produktmanagement, Marketing, ein Benutzer, Kunde, Manager des Benutzers, Analyst, Sponsor. <?page no="132"?> 132 Takt 3: Projektorganisation Abbildung 139: Extreme Programming (XP) 62 - Kunde … entscheidet, was gemacht wird, gibt regelmäßig Rückmeldung, Auftraggeber. Beispiele : Auftraggeber, kann auch der Produktbesitzer sein, kann, muss aber nicht der Benutzer sein. - Entwickler … entwickelt das Produkt. Das ganze Entwicklungsteam besteht aus Entwicklern: Programmierer, Tester, DB-Experten, Architekt, Designer. - Projektmanager … ist gewöhnlich der Produktbesitzer. Kann auch Entwickler, aber nicht Manager des Teams sein. Führung des Teams. - Benutzer … wird das zu erstellende Produkt nutzen. Values (Werte) Die Werte Kommunikation, Mut, Feedback, Respekt und Einfachheit stehen bei XP im Vordergrund und bilden die Basis, auf der die Prinzipien aufbauen. Principles (Prinzipien) Es gibt 14 Prinzipien, die eine Brücke zwischen den eher abstrakten Werten und den direkt zur Anwendung kommenden Techniken bilden: Verantwortung übernehmen, Einfachheit anstreben (sowohl beim Entwicklungsprozess als auch beim Produkt, gezielte Experimente (zeigen frühzeitig Fehlentwicklungen auf und bestätigen andererseits funktionierende Ansätze), Veränderung wollen (wer sich gegen Veränderungen stemmt, kann nicht agil werden und sich an beständig ändernde Umfeldbedingungen anpassen), ehrliches Messen (kein Schönreden von Arbeitsergebnissen), inkrementelle Veränderung, an örtliche Gegebenheiten anpassen (sowohl die Arbeitsmethoden als auch das erzeugte Produkt), offene, aufrichtige Kommunikation, „auf Sieg spielen“, Qualitätsarbeit (nicht „quick and dirty“), unmittelbares Feedback (hält Kosten niedrig und vermeidet Terminverzögerungen), geringe Anfangsinvestition, Lernen lehren (fortlaufendes Lernen ist ein essentieller Bestand agiler Vorgehensweisen), „mit leichtem Gepäck reisen (unnötige und umständliche Arbeitsweisen und Werkzeuge vermeiden) sowie Instinkte des Teams nutzen, nicht dagegen arbeiten. 62 Von DonWells ‒ Diese Grafik wurde von diesem Werk abgeleitet: Extreme Programming.svg, CC BY-SA 3.0, https: / / commons.wikimedia.org/ w/ index.php? curid=28871488 <?page no="133"?> 3.2 Projekt-Vorgehensmodelle 133 Practices (Techniken) Die traditionellen Praktiken des XP sind folgende: Kunde ist vor Ort, Planungsspiel (zu Beginn der Entwicklungs-Iteration, um den Arbeitsumfang und die technische Umsetzung abzustimmen), kurze Release-Zyklen (zum Einholen des Kundenfeedbacks),gemeinsam vereinbarte Programmierstandards, fortlaufende Integration, Collective Ownership (alle tragen eine gemeinsame Verantwortung für das Erstellte), Metapher (User Stories werden allgemeinverständlich beschrieben), nachhaltiges Tempo (Vermeidung von Überlastung der Teammitglieder durch zu große Arbeitslasten), Pair Programming (Programmieren zu zweit mit regelmäßigem Rollentausch), Refactoring (das Arbeitsergebnis wird kontinuierlich in kleinen, funktionserhaltenden Schritten optimiert), einfaches Design sowie Testen. 3.2.2.5 Feature Driven Development (FDD) 63 FDD wurde als schlanke Methode von Jeff De Luca im Jahre 1997 definiert, um ein großes zeitkritisches Projekt (15 Monate, 50 Entwickler) durchzuführen. Seitdem wurde FDD kontinuierlich weiterentwickelt. FDD stellt den Feature-Begriff in den Mittelpunkt der Entwicklung. Jedes Feature stellt einen Mehrwert für den Kunden dar. Die Entwicklung wird anhand eines Feature- Plans organisiert. Eine wichtige Rolle spielt der Chefarchitekt (engl. Chief Architect), der ständig den Überblick über die Gesamtarchitektur und die fachlichen Kernmodelle behält. Bei größeren Teams werden einzelne Entwicklerteams von Chefprogrammierern (engl. Chief Programmer) geführt. Abbildung 140: Feature Driven Development 64 FDD definiert ein Prozess- und ein Rollenmodell, die gut mit existierenden klassischen Projektstrukturen harmonieren. Daher fällt es vielen Unternehmen leichter, FDD einzuführen als XP oder Scrum. Außerdem ist FDD ganz im Sinne der agilen Methoden sehr kompakt. Es lässt sich auf 10 Seiten komplett beschreiben. FDD wurde von Haus aus für große Projekte konzipiert und schafft den Spagat von kleinen bis großen Teams deshalb ohne Umstrukturierung und Anpassungsprozesse. Anders als seine agilen Pendants Scrum und XP besitzt FDD eine ausgeprägtere Planungsphase im Vorfeld der Iterationen. 63 nach Wikipedia, nach Wolf/ Bleek, 2011, S. 164ff; IAPM, 2017, S. 31ff 64 nach Ambler, 2002 Entwicklung eines Gesamtmodells Objektmodell + Notizen (mehr Form als Inhalt) Erstellen einer Feature- Liste Liste von Features, gruppiert nach Gruppen und Themen-bereichen Planen nach Features Entwicklungsplan Konzeption nach Features Design-Paket (Hinzufügen weiterer Inhalte zum Objektmodell) Realisieren nach Features abgeschlossene, kundenbewertete Funktion <?page no="134"?> 134 Takt 3: Projektorganisation FDD-Prozessmodell FDD-Projekte durchlaufen fünf Prozesse: [P1] Entwickle ein Gesamtmodell (Rollen: alle Projektbeteiligten) [P2] Erstelle eine Feature-Liste (Rollen: in der Regel nur die Chefprogrammierer) [P3] Planung je Feature (Rollen: Projektleiter, Entwicklungsleiter, Chefprogrammierer) [P4] Entwurf je Feature (Rollen: Chefprogrammierer, Entwickler) [P5] Programmierung je Feature (Rollen: Entwickler) Die ersten drei Prozesse werden innerhalb weniger Tage durchlaufen. Die Prozesse 4 und 5 werden in ständigem Wechsel durchgeführt, weil jedes Feature in maximal 2 Wochen realisiert wird. Prozess #1: Entwickle ein Gesamtmodell Im ersten Prozess definieren Fachexperten und Entwickler unter Leitung des Chefarchitekten Inhalt und Umfang des zu entwickelnden Systems. In Kleingruppen werden Fachmodelle für die einzelnen Bereiche des Systems erstellt, die in der Gruppe vorgestellt, ggf. überarbeitet und schließlich integriert werden. Das Ziel dieser ersten Phase ist ein Konsens über Inhalt und Umfang des zu entwickelnden Systems sowie das fachliche Kernmodell. Prozess #2: Erstelle eine Feature-Liste Im zweiten Prozess detaillieren die Chefprogrammierer die im ersten Prozess festgelegten Systembereiche in Features. Dazu wird ein dreistufiges Schema verwendet: Fachgebiete (engl. Subject Areas) bestehen aus Geschäftstätigkeiten (engl. Business Activities), die durch Schritte (engl. Steps) ausgeführt werden. Die Schritte entsprechen den Features. Die Features werden nach dem einfachen Schema <Aktion> <Ergebnis> <Objekt> aufgeschrieben, z. B. „Berechne Gesamtsumme der Verkäufe“. Ein Feature darf maximal zwei Wochen zu seiner Realisierung benötigen. Das Ergebnis dieses zweiten Prozesses ist eine kategorisierte Feature-Liste, deren Kategorien auf oberster Ebene von den Fachexperten aus Prozess #1 stammen. Prozess #3: Planung je Feature Im dritten Prozess planen der Projektleiter, der Entwicklungsleiter und die Chefprogrammierer die Reihenfolge, in der Features realisiert werden sollen. Dabei richten sie sich nach den Abhängigkeiten zwischen den Features, der Auslastung der Programmierteams sowie der Komplexität der Features. Auf Basis des Plans werden die Fertigstellungstermine je Geschäftsaktivität festgelegt. Jede Geschäftsaktivität bekommt einen Chefprogrammierer als Besitzer zugeordnet. Außerdem werden für die bekannten Kernklassen Entwickler als Besitzer festgelegt (engl. Class Owner List). Prozess #4: Entwurf je Feature Im vierten Prozess weisen die Chefprogrammierer die anstehenden Features Entwicklerteams auf Basis des Klassenbesitztums zu. Die Entwicklerteams erstellen ein oder mehrere Sequenzdiagramme für die Features und die Chefprogrammierer verfeinern die Klassenmodelle auf Basis der Sequenzdiagramme. Die Entwickler schreiben dann erste Klassen- und Methodenrümpfe. Schließlich werden die erstellten Ergebnisse inspiziert. Bei fachlichen Unklarheiten können die Fachexperten hinzugezogen werden. Prozess #5: Programmierung je Feature Im fünften Prozess programmieren die Entwickler die im vierten Prozess vorbereiteten Features. Bei der Programmierung werden Komponententests und Code-Inspektionen zur Qualitätssicherung eingesetzt. <?page no="135"?> 3.2 Projekt-Vorgehensmodelle 135 FDD-Rollenmodell - Project Manager … stimmt die Verteilung der Ressourcen ab und ist verantwortlich für die Terminierung des Projektes. An der eigentlichen Programmierarbeit hat der Project Manager keinen Anteil. Er ist verantwortlich für die administrativen Aufgaben im Projekt. - Chief Architect … behält den Überblick über die Architektur der gesamten Software und der zentralen Modelle. Der Chief Architect unterstützt Entwickler und Kunden bei der gemeinsamen Entwicklung neuer Softwarekomponenten. Bei kleinen Projekten mit einer geringen Personaldecke verschmelzen die Funktion des Chief Architect und die Funktion des Chefprogrammierers zu einer Rolle. - Development Manager … ist der Moderator des Tagesgeschäfts und löst Ressourcenprobleme. Bei manchen Projekten wird die Rolle des Development Managers mit der des Chief Architect oder des Project Manager verknüpft. - Chief Programmer … führen bei größeren Projekten die einzelnen Entwicklerteams, erstellen Feature Listen, planen und steuern deren Umsetzung und verantworten die ihnen zugeordneten Geschäftstätigkeiten. - Class Owners … sind Entwickler, die in kleinen Teams für die Umsetzung der Features sorgen und sich mit ihren Chief Programmers und dem Chief Architect an deren Entwurfsplanung beteiligen. Sie sind den Key-Classes zugeordnet. - Domain Experts … sind Anwender, Kunden, Sponsoren, Geschäftsanalysten oder eine Kombination daraus. Sie haben eine profunde Kenntnis der Aufgabe (Domänenwissen), die das zu entwickelnde Produkt haben muss. Neben den genannten gibt es noch andere Rollen, die bei Bedarf eine unterstützende Funktion haben können. 3.2.2.6 Design Thinking Design Thinking geht in seinem Ansatz weit über das klassische Gestalten hinaus und rückt, im Gegensatz zu den technischen Disziplinen, bei denen die Machbarkeit im Vordergrund steht, den Anwender und seine Wünsche in den Mittelpunkt. Die multidisziplinären Entwicklerteams begeben sich in die Rolle des Anwenders und versuchen mit „seinen Augen“ das Problem zu analysieren. Design Thinking ist dabei keiner Branche zugeordnet, sondern eignet sich als systematische Lösungsstrategie für viele komplexe Problemstellungen, Entwicklung von Serviceleistungen und innovativer Produkte aus unterschiedlichsten Bereichen. Gefundene Lösungen und Ideen sollen in der Form von Prototypen möglichst früh erstellt werden, um ein entsprechendes Feedback vom Anwender zu ermöglichen. Die erzielten Ergebnisse und innovativen Problemlösungen vereinen am Ende die drei essentiellen Komponenten technologische Machbarkeit, Wirtschaftlichkeit und die Erfüllung eines Bedürfnisses oder Wunsches. Design Thinking beruht im Wesentlichen auf einem gemeinschaftlichen Arbeits- und Denkprozess, der durch die folgenden drei Elemente gefördert wird: Multidisziplinäre Teams Mehrere multidisziplinäre, heterogene Teams von jeweils fünf bis sechs Personen arbeiten mit der Unterstützung eines methodisch ausgebildeten Coaches an einem Thema. Ziel ist es immer, anfassbare, begreifbare Ergebnisse zu erzielen und diese mit den anderen Teams auszutauschen, um möglichst viele Perspektiven auf die Problemlösung zu erhalten. <?page no="136"?> 136 Takt 3: Projektorganisation Abbildung 141: Design Thinking 65 Design Thinking Prozess Design Thinking hat seinen Ursprung in Silicon Valley, einer Umgebung, die von pragmatischem und schnellem unternehmerischen Handeln geprägt ist. Beim Design Thinking wird der Übergang von der Idee zu einem Prototyp, an dem die Anforderungen gespiegelt werden können, zügig vollzogen. Dies geschieht iterativ in sechs Phasen, wobei Rückkopplungen in vorherige Phasen möglich sind. In … Phase 1, „Verstehen“, versuchen sich die Teammitglieder mit Hilfe von Befragungen in die Nutzerperspektive hineinzuversetzen, um dann in … Phase 2 „Beobachten“ zu verfolgen, wie Anwender mit den jeweiligen Problemstellungen umgehen. Basierend auf diesen Beobachtungen werden in der … Phase 3 Sichtweisen definiert, die gewonnenen Erkenntnisse zusammengetragen und verdichtet und verschiedene Anwenderperspektiven herausgearbeitet, damit ein ganzheitlicher, 360-Grad- Blick auf das Problem entsteht. Nach dieser Phase des „Einfühlens“ schließt sich die … Phase 4, „Ideenfindung“, an. Bei diesem Suchprozess spielt die Arbeitsumgebung und ihre Möglichkeiten für kreative Prozesse eine große Rolle. In der vorletzten … Phase 5 fokussiert man sich auf die geeignetsten Ideen und überführt diese in aufwandsarme Prototypen. Final werden diese in der … Phase 6, „Testen“, auf ihre Brauchbarkeit hin untersucht. Die agilen Modelle sind also insbesondere durch iterativ-inkrementelle Vorgehensweisen gekennzeichnet. Dabei ist zu beachten: ��� Inkrementelles Vorgehen erfordert Interaktion! Agiles Vorgehen erfordert immer eine starke Beteiligung des Fachbereichs und schnelle Rückkopplung der Ergebnisse durch Anwender (siehe Abbildung 142). In einer extremen Ausprägung verschwinden sogar die Grenzen des Projektes - es entsteht der sogenannte DevOps-Ansatz. Der Name DevOps verbindet die Begriffe Development (Entwicklung) und IT Operations (IT-Betrieb). DevOps gehören durch ihren kontinuierlichen Zyklus von Entwicklung und Betrieb nicht zu Arbeitsform der Projekte (siehe Abbildung 143). Durch verbindende und teamübergreifende Prozesse und Werkzeuge soll Softwarequalität, Entwicklungsgeschwindigkeit und Auslieferung verbessert und erhöht werden. 65 teamentwicklung-lab.de <?page no="137"?> 3.2 Projekt-Vorgehensmodelle 137 Abbildung 142: Inkrementelles Vorgehen erfordert Interaktion Abbildung 143: DevOps 3.2.3 Hybrides Vorgehen 66 Das Resümee der Ausführungen zu den Vorgehensmodellen identifiziert die zwei folgenden Pole hinsichtlich der Projektmanagement-Ansätze: • plangetrieben … mit Betonung von Stabilität und Planungssicherheit, und • agil … mit Betonung von Flexibilität und Adaptierbarkeit. Verschiedene Studien und Praxiserfahrungen zeigen, dass häufig unternehmens- und kontextbezogen ein hybrider Methodenmix eingesetzt wird, also standardisierte Vorgehensweisen nicht in ihrer ursprünglich erdachten Reinform angewendet werden. Viele Autoren und Studien sprechen von sog. hybriden Vorgehensweisen. In Anlehnung an die Definition von Timinger ergibt sich folgende definitorische Beschreibung: Als hybrides Projektmanagement wird die Nutzung von Praktiken (Prozesse, Methoden, Tools), Organisationsformen (Strukturen, Rollen, A/ B/ V) 67 und Phasenabläufen unterschiedlicher Standards oder Vorgehensmodelle in einem Projekt bezeichnet. Dies erfolgt mit dem Ziel, die kontextbezogenen Bedingungen (Komplexitätsgrad der Maßnahme, Fähigkeiten der Organisation, formelle Rahmenbedingungen) bestmöglich zur Erreichung der Projektziele zu berücksichtigen. Insgesamt können in der Praxis verschiedene Ausprägungen hybrider Projektmanagement-Ansätze angewendet und beobachtet werden. Gerade auch z.B. mit Blick auf die Kombination klassischer und plangetriebener Ansätze sind dies folgende Modus Operandi: 66 aus Hüsselmann, 2021, S. 50-52; siehe auch Blust 2019; Timinger 2015, S. 241 ff. 67 A/ B/ V: Aufgaben, Befugnisse und Verantwortlichkeiten Systementwicklung Sprint 1 Sprint n Sprint 2 Sprint Backlog Sprint Backlog Sprint Backlog Product Backlog = Realisierungskonzept/ „Business Blueprint“ sequenzielle Bearbeitung weitere Sprints Anforderungen/ Lastenheft/ Requirements Fachabteilungen Nutzung Akzeptanz Einführungskoordination (Planung, Cut Over, Change Mgmt., Trainings, etc.) Inkrement weitere Ergebnisse Inkrement Einbindung <?page no="138"?> 138 Takt 3: Projektorganisation Bimodal: Hier werden in entsprechend umfangreichen Projekten einzelne Teilprojekte mit verschiedenen Vorgehensweisen durchgeführt. Design to Budget Sicherstellung Konformität zum Big Picture des Projekts Abbildung 144: Bimodales Vorgehensmodell So können z.B. in einem SAP-Einführungsprojekt Standardanteile im Wasserfallmodus (Business Blueprint → Customizing → Datenübernahme etc.), während Zusatzentwicklungen - dem originären Anlass agiler Software-Entwicklung entsprechend - nach Scrum abgewickelt werden. Evolutionär: Der Modus des Projektes ändert sich Projektablauf. Gewinnung von Planungs- und Lösungssicherheit Abbildung 145: Evolutionäres Vorgehensmodell z.B. werden aufgrund von Unsicherheiten zu Beginn des Projektes zunächst einige Sprints durchgeführt, bis ausreichend Sicherheit in Sachen Vorgehen und Lösung erreicht, d.h. die Komplexität reduziert wurde. Best-of-Breed: Lösungselemente aus den verschiedenen Ansätzen werden synthetisierend zu einer neuen, den Umständen entsprechend optimierten Methode vereint − z.B. Time-Boxing innerhalb des Wasserfallvorgehens: Cherry Picking Abbildung 146: Best-of-Breed-Vorgehensweise Kombinationen der o.g. Ausprägungen sowie weitere Ableitungen sind denkbar. Die Fähigkeit einer Organisation, verschiedene „Betriebssysteme“ zugleich zu leben, wird auch als organisationale Ambidextrie , also im übertragenen Sinne Beidhändigkeit, bezeichnet. Es stellt sich schlussendlich die Frage, wann welche Kombination sinnvoll anzuwenden ist. Zur Beantwortung dienen nicht zuletzt die Ausführungen zur projektindividuellen Adaption des PM-System s sowie des entwickelten Agilometers (folgen). Im Buch Lean Project Management. Hybride Methoden wertschöpfend anwenden 68 werden einige Beispiele hybrider Ausgestaltung in IT-Projekten vorgestellt, die der strukturellen, zeitlichen sowie kontextuellen Ambidextrie zuzuordnen sind. Schauen Sie doch mal rein. 68 Hüsselmann, 2021 <?page no="139"?> 3.3 Projekttypisierung 139 3.3 Projekttypisierung 69 Neben der immanenten Herausforderung von Projekten, einzig- und neuartige Vorhaben zu sein, die von daher genuin mit Unsicherheiten und Risiken behaftet sind, deutet die empirische Analyse darauf hin, dass die kontextuellen Gegebenheiten eines konkreten Projekts vielfach nicht im Sinne einer spezifischen Ausgestaltung des PM-Systems des Projekts berücksichtigt werden. Mit anderen Worten: Die Management-Erfordernisse von Projekten schwanken einzelfallbezogen und sollten sich in einer adaptiven Ausgestaltung widerspiegeln. Schauen Sie sich dazu einmal als kurze Motivation folgendes Video an. ► Video 3.7 (Adaption), URL: https: / / youtu.be/ dfPTGZGDRzI Aufgrund der vielseitigen Charakteristika von Projekten „lassen sich unterschiedliche Projekttypen oder Projektarten identifizieren, die entsprechend ihrer Eigenschaften auch besondere Anforderungen an das Projektmanagement stellen“. Entscheidend für einen erfolgreichen Projektverlauf kann daher eine Typisierung des Projekts in der frühen Initiierungsphase sein, da somit für das Projektmanagement die ersten grundlegenden Informationen zur Ausarbeitung des Projektdesigns gegeben sind. Die Projektmanagement- Anforderungen und -methoden zur Leitung eines Projekts richten sich nach Bedeutung sowie insbesondere Größe und Komplexität des Vorhabens: Abbildung 147: Bildung von Projektkategorien ��� Übrigens: Mit der Größe des Projektes steigt überproportional (! ) der PM-Aufwand. Dies soll insbesondere verhindern, dass Projekte höhere finanzielle und zeitliche Ressourcen benötigen, als anfangs geplant - ein in der Realität häufig vorkommendes Szenario. Praxisbeispiele wie der Bau des Denver International Airport (1989) untermauern die hohe Bedeutung von Analysen hinsichtlich der Projekttypisierung und eines umfangreichen Wissensstands vor Projektstart. Es war der Wunsch der Stadt Denver, dass der Bau des Gepäcktransportsystems aufgeteilt wird, indem jede Fluggesellschaft ein eigenes System plant und selbstständig umsetzt. Erkannt wurde deutlich zu spät, dass nur eine Gesellschaft diesem Wunsch 69 Hüsselmann, 2021, S. 157ff, S. 200ff; siehe auch Shenhar/ Dvir, 2007, S. 21ff, S.63 ff; Gessler, 2012, S. 51; GPM, 2017, S. 106; Zell, 2017, S. 5; Frick et al., 2019, S. 1006; Reiss, 2018, S. 44 <?page no="140"?> 140 Takt 3: Projektorganisation nachkam. In Folge sollte deren System auf das gesamte Fluggelände angewandt werden. Jedoch konstruierte die Fluggesellschaft ein fortschrittliches und automatisiertes System, dessen Errichtung weit komplexer und zeitlich aufwendiger war als in der Gesamtplanung des Projekts vorgesehen. Daraus resultierend wurde aus einem standardmäßigen Großprojekt zusätzlich ein Innovationsprojekt. Dies führte zu Verzögerungen im Projektablauf und ständigen Anforderungsänderungen, wodurch sich die Kosten und Dauer des Projekts erhöhten. Allein für die Fehlplanung des Gepäcktransportsystems fielen Mehrkosten in Höhe von 118 Millionen US-Dollar an. Die Eröffnung des Flughafens verzögerte sich von Oktober 1993 auf Februar 1995. Dennoch kam es nach der Eröffnung zu stärkeren funktionalen Einschränkungen, was rückblickend auf die fehlgeschlagene Planung zurückzuführen ist. 70 Die Bildung der unterschiedlichen Typen richtet sich dabei u.a. nach Kategorien von Stakeholdern (z.B. interne oder externe Auftraggeber), von Projektaufgaben (z.B. Produktentwicklungs- oder Standard-Software-Implementierungsprojekte) und/ oder Komplexitätsmerkmalen (z.B. Budgetvolumen, Heterogenität der Stakeholder) sowie dem Innovationsgrad des Projekts. 3.3.1 Typen von IT-Projekten 3.3.1.1 Allgemeine Betrachtung Ein zentraler Ansatz mit Auswirkung auf die Gestaltung des PM-Systems ist die Kategorisierung eines Projekts mit Hinblick auf deren externe und interne Komplexität. Diese Abgrenzung ist insbesondere für Zwecke einer gezielten Ressourcenallokation, die Auswahl der Instrumente für die Projektsteuerung und für die Definition des Projekt-Teams (insbesondere der Projektleitung) in Bezug auf die benötigte Erfahrung für das vorgesehene Projekt sinnvoll. Die nachfolgende Abbildung 148 zeigt die möglichen Ausprägungen auf. 71 Abbildung 148: Projektcharakterisierung hinsichtlich Komplexität von Projektinhalt und -umfang 70 s. Büttgen/ Fabricius (Hrsg.), o.J., S. 1 sowie Drexl/ Hans/ Käck, 2002 71 in Anlehnung an Jenny, 2014, S. 49 und Pommeranz, 2011, S. 18 <?page no="141"?> 3.3 Projekttypisierung 141 Die Abszisse in Abbildung 148 beschreibt die Komplexität des Projektinhalts; dabei kann zwischen „fluid“ und „kristallin“ unterschieden werden. Kristalline Projekte zeichnen sich beispielsweise durch eine klare Zielvorstellung und einen Lösungsansatz aus, der auf bereits erlangten Erkenntnissen vorheriger Projekte aufbaut. Zudem weisen sie vielmals eine relativ transparente Komplexität auf. Im Gegensatz dazu weisen Projekte mit einer fluiden Projektstruktur zwar auch eine klare Zielvorstellung auf, jedoch ist der Lösungsweg zur Realisierung des Projekts noch ungewiss. Die Ordinatenachse des Modells beschreibt die Komplexität der Projektumwelt. Bei hoher Ausprägung handelt es sich um ein Projekt, das komplexe und komplizierte Wirkungszusammenhänge aufweist. Im Gegensatz dazu stellen sich die Wirkungszusammenhänge von Projekten mit einer geringen Komplexität oftmals als einfach dar. Anhand dieser Dimensionen lassen sich vier unterschiedliche Projekttypen aus dem Modell ableiten. Komplexe Standardprojekte: Es handelt sich um Projekte mit klaren Zielvorgaben, bei denen Methoden und Hilfsmittel bedingt durch die vorliegende Erfahrung bis zu einer bestimmten Größenordnung formalisiert und standardisiert sind. Sie verfügen über vielfältige fachliche und soziale Verbindungen. Routineprojekte: Sie stellen Projekte dar, bei denen auf einen großen Erfahrungsschatz zurückgegriffen werden kann. Sie sind mithilfe einer standardisierten Vorgehensweise zu bearbeiten. Eine Kostenabweichung von beispielsweise wenigen Prozenten ist als ungewöhnlich zu beurteilen. Pionierprojekte: Sie bilden Projekte, die eine komplexe Projektumwelt aufweisen. Des Weiteren haben sie einen hohen Neuheitsgehalt und hohes Risikopotenzial inne. Für sie existiert kein Erfahrungswissen, daher ist der Umfang der für das Projekt benötigten Aufgaben schwer zu prognostizieren. Innovationsprojekte: Bei Innovationsprojekten muss vor allem auf das Wissen einzelner Experten zurückgegriffen werden, die das methodische Vorgehen anhand der vorliegenden Problemstellung auswählen können. Dieser Projekttyp besitzt eine geringe Komplexität der Projektumwelt und eine fluide Projektstruktur. 3.3.1.2 Typisierung von Technologieprojekten Beim sogenannten Diamond Approach handelt sich um ein Modell in der Form eines Diamanten, bei dem Projekte anhand von vier Dimensionen betrachtet werden. Der Ansatz beruht ebenso auf der Annahme, dass Projekte ein erfolgsorientiertes, flexibles und adaptierbares Framework benötigen. Dabei soll der Diamond Approach ein Werkzeug darstellen, aus dem sich ein dem Projekttyp entsprechend adäquater Führungsstil ableiten lässt. Dazu soll jede der vier Dimensionen bei der Projektplanung berücksichtigt werden, da diese einen unterschiedlichen Einfluss auf das Projektmanagement ausüben. Entlang der Abszisse wird in das Projekt nach den Ausprägungen der Neuartigkeit (Novelty) und der Komplexität (Complexity) bewertet. Entlang der Ordinate wird die Ausprägung der Technologie (Technology) und der Geschwindigkeit (Pace) für das Projekt betrachtet 72 (siehe Abbildung 149). Jedes dieser Kriterien repräsentiert drei oder vier Ausprägungen verschiedener Projekttypen. So beeinflusst die Neuartigkeit eines Projekts beispielsweise den benötigen Zeitraum, die Dimension der Technologie die technischen Anforderungen des Projekt-Teams, die Dimension der Komplexität die Projektorganisation und die Dimension der benötigten Geschwindigkeit die Selbständigkeit des Projekt-Teams und die Partizipation des Top-Managements. 72 s. Shenhar/ Dvir, 2007, S.11 ff., S. 50 <?page no="142"?> 142 Takt 3: Projektorganisation Abbildung 149: Der „NTCP-Diamond“ nach Shenhar/ Dvir 3.3.1.3 Typisierung von IT-Projekten Zur Strukturierung von Projekten speziell im IT-Bereich lassen sich vier idealtypische Grundtypen von Projekten identifizieren, die anhand der beiden Kriterien Strategische Zielsetzung (kurzfristige Rentabilität vs. langfristiges Wachstum) und Technologieumfang (Shared Infrastructure vs. Business Solution) unterschieden werden. Die sich aus der Unterteilung ergebenden Projekttypen weisen spezifische Merkmale in Bezug auf die Bewertung bzw. die Höhe der Projektbudgets auf. 73 Abbildung 150: Typisierung von IT-Projekten Bei Projekten vom Typ Transformation geht es darum, die bestehende IT-Struktur des Unternehmens an veränderte Anforderungen des Marktes oder der Wettbewerbssituation anzupassen. So kann beispielsweise die Umstellung des gesamten Buchungssystems einer Fluggesellschaft als ein solches Projekt angesehen werden. 73 siehe auch Ross/ Beath, 2002, S. 53, zitiert nach Kunz, 2007, S. 60 <?page no="143"?> 3.3 Projekttypisierung 143 Im Gegensatz dazu handelt es sich bei Erneuerungsprojekten um Software-Updates, Erweiterungen der Hardware-Kapazitäten oder Änderungen an anderen Software-Plattformen. Das Hauptziel der Projekte vom Typ Prozessverbesserung ist die Realisierung von Zeit- und Kosteneinsparungen innerhalb IT-dominierter Prozesse. Die Erprobung neuer Möglichkeiten im IT-Bereich, z. B. neuer webbasierter Dienste, gehört zu den Projekten des Typs Experimente. Der Typisierungsansatz zielt explizit darauf ab, die Projektgesamtheit nach Projektbudgetierungsaspekten im Sinne einer inhaltlichen Gruppierung strategischer Aktivitäten zu untergliedern. Darüber hinaus sind in dem Ansatz auch Vorteile einer getrennten Priorisierung der verschiedenen Projekttypen zu erkennen. Dennoch ist die Struktur nicht generell auf alle Unternehmen übertragbar. Zudem ist die Unterscheidung der Typen im Praxisfall nicht immer trennscharf möglich. Generell können auch andere Ansätze zur Typisierung von Projekten in Unternehmen angewendet werden, z.B. nach strategischer Bedeutung oder Risikoart. 3.3.2 Adaption PM-System Viele PM-Frameworks beinhalten durchaus mehr oder weniger explizit die Forderung nach einer spezifischen Ausgestaltung des PM-Systems. Beispielhaft seien hier PRINCE2 und das V-Modell XT genannt. PRINCE2 fordert innerhalb seiner sieben Grundprinzipien die „Anpassung an die Projektumgebung“. Als Einflussfaktoren nennt PRINCE2 dabei die Branche, existierende Unternehmensstandards, die PM-Reife der Organisation sowie Faktoren wie Größe, Komplexität, Wichtigkeit, Kapazität und Risiken. 74 Letztere Einflussfaktoren finden auch im V-Modell XT (eXtreme Tailoring) Eingang. Das V-Modell XT bezeichnet die Anpassung des Standards an projektspezifische Belange als Tailoring - also als das „Zuschneiden“. Dabei werden im Schwerpunkt die Produkte, Aktivitäten und generell Elemente, die im Projekt anhand dessen Typisierung nicht benötigt werden, weggelassen. Grundsätzlich wird aber auch die Hinzunahme zusätzlich erforderlicher Elemente zugestanden. Zur Typisierung wird neben den oben genannten Faktoren insbesondere der Projektgegenstand (z.B. Systementwicklung vs. -adaption) herangezogen. Abbildung 151: Begriffsklärung zur Adaption eines PM-Systems 74 s. AXELOS, 2017, S. 64 ff.; Höhn et al., 2008 Adaption (Anpassung) Tailoring (Zuschneiden) Fokussierung (Schwerpunktsetzung) Auswahl (alternativer Möglichkeiten) Ergänzung (neuer Elemente)  In erster Linie Weglassen von nicht notwendigen PM-Elementen (Vermeidung von Verschwendung)  Besondere Betonung und Augenmerk auf ausgewählte PM-Elemente (Wertorientierung)  Selektion z. B. des richtigen Vorgehensmodell (sequenziell, inkrementell etc.) (Adäquatheit)  Besonderheiten des Projekts, z. B. bzgl. der Dokumentation, gesetzlicher Grundlagen etc. <?page no="144"?> 144 Takt 3: Projektorganisation Eine konkrete Hilfestellung, wie die Anpassungen operativ vorzunehmen sind, liefern die bekannten Frameworks tendenziell nicht. Einig sind sich die Frameworks darin, dass die Anpassung in einer frühen Phase des Projekts vorgenommen und im Projekthandbuch (/ -leitdokumentation, / -managementplan etc., je nach Begriffswelt) zu dokumentieren ist. Im vorliegenden Modul wird das in Abbildung 151 beschriebene Verständnis der Adaption eines PM-Systems verwendet. Mit PM-System wird hier das Management eines konkreten Projekts bezeichnet, im Gegensatz zum PM-System einer Organisation ( Enterprise PM-System, EPMS ). Die Adaption des PM-Systems lässt sich wie in der folgenden Abbildung 152 dargestellt umsetzen und einordnen. Abbildung 152: Adaption des PM-Systems im PM-LifeCycle Im Zuge der Adaption sind die PM-Disziplinen (1) zu vernachlässigen, (2) zu stärken, (3) alternativ zu gestalten oder gegenüber üblichen Vorgehensweisen (4) zu ergänzen. Beispiele hierfür sind: (1) Der Bau einer neuen Lagerhalle ist ein Investitionsprojekt. Das Change-Management kann tendenziell vernachlässigt werden. (2) Der Merger zweier Unternehmen ist ein Organisationsprojekt. Das Change-Management muss besonders betont werden. (3) Die neuartige Gestaltung der Customer Journey mit Hilfe eines Kundenportals ist ein Marketing-Innovationsprojekt. Die Vorgehensweise sollte inkrementell (agil) erfolgen. (4) Der Rollout eines Rechnungswesen-IT-Systems nach China erfordert die Einhaltung spezieller, in keinem Standard vorgesehener Regulatorien. Diese sind entsprechend im Vorgehensmodell zu ergänzen. 3.3.3 Agilometer Im bisherigen Verlauf wurde dargestellt, dass das PM den Anforderungen und Bedürfnissen des Projektes gerecht werden muss, und die Annahme, ein Ansatz könne alle Projekte zufriedenstellend managen, den Erfolg der Projekte gefährdet. Für jedes Projekt von Grund auf einen eigenen Ansatz zu entwerfen, steht jedoch in keinem Verhältnis zum Aufwand. Obwohl ein vordefinierter Ansatz im Regelfall nicht zu allen Eigenschaften des Projekts passen wird, ist die Anpassung eines funktionalen Ansatzes an zentralen Stellen erfolgsversprechender als der Aufbau einer völlig projektindividuellen Herangehensweise. Um ein Vorgehensmodell nachvollziehbar und begründbar punktuell anzupassen, ist die Identifikation aussagekräftiger Merkmale zwingend erforderlich. 75 75 Wysocki, 2019, S. 18; Timinger, 2017, S. 281; Hüsselmann, 2021, S. 157ff <?page no="145"?> 3.3 Projekttypisierung 145 Als Grundlage werden die im sogenannten Agilometer verwendeten Merkmale genutzt. Dabei werden die Merkmale in drei Kategorien unterteilt, basierend auf der Betrachtungsebene der Organisation, in der das Merkmal anzutreffen ist (siehe Abbildung 153). Auf der einen Seite stehen die Merkmale, die das Projekt beziehungsweise den Projektgegenstand direkt betreffen. Auf der anderen Seite stehen die Merkmale, die durch die durchführende Unternehmung gebildet werden. Zwischen diesen Ebenen werden die durch das Projekt-Team beeinflussten Merkmale angesiedelt, die partiell auch als Schnittmenge zwischen den projektspezifischen und den unternehmensspezifischen Eigenschaften angesehen werden können. Abbildung 153: Die drei Merkmalskategorien des Agilometers Bei den Merkmalen kann festgestellt werden, was im Unternehmen „ nicht gegeben “ oder „ stark ausgeprägt “ ist, und aufgrund dessen entschieden werden, ob es eher agil oder klassisch geprägt ist bzw. welche Projektmanagementmethoden in diesen Ist-Zuständen vorzugsweise zu empfehlen sind. Dies soll dabei helfen, anschließend Optionen zur Adaption des Projektmanagements durch agile Ansätze erkennen zu können. 3.3.3.1 Unternehmensspezifische Merkmale Unternehmensspezifische Merkmale werden durch die Struktur und die Prozesse des Unternehmens geprägt. Unabhängig vom einzelnen Projekt bilden sie die Basis, inwiefern sich agile und klassische Ansätze in die übergeordneten Strukturen des Unternehmens einbinden lassen. Eine Änderung dieser Merkmale erfordert Zeit und umfasst weite Teile des Unternehmens. 76 unternehmensspezifische Merkmale nicht gegeben stark ausgeprägt flache Hierarchie (agile Unternehmenskultur) klassisch neutral agile Affinität des Managements klassisch agil hohe Flexibilität der Unternehmensprozesse klassisch neutral agile strategische Ausrichtung klassisch agil Abbildung 154: Unternehmensspezifische Merkmale 76 siehe auch Hüsselmann, 2021, S. 160; Timinger, 2017, S. 165, 245 <?page no="146"?> 146 Takt 3: Projektorganisation Hierarchie des Unternehmens / Unternehmenskultur Die Hierarchie des Unternehmens beeinflusst insbesondere die Eignung agiler Ansätze. Klassische Ansätze eignen sich in steilen und flachen Hierarchiestrukturen gleichermaßen, agile Ansätze profitieren von flachen Hierarchien, in denen sich einzelne Mitarbeiter einbringen können. Die Hierarchie des Unternehmens kann als ein wesentliches Element der Unternehmenskultur aufgefasst werden, unter welcher sich auch das gruppen-/ projektspezifische Zielsystem als eine Ausprägung aufnehmen lässt. Das Zielsystem berücksichtigt, inwiefern den Mitgliedern finanzielle Anreize für eine Leistung geboten werden und ob diese Anreize auf der eigenen Leistung oder auf der Leistung des gesamten Teams fußen. Affinität des Managements Die Affinität des Managements für eine agile oder klassische Philosophie wird insbesondere durch den Support des Managements für diese ausgedrückt. Auch ist - mit Blick auf agile Affinität - ein gewisses Mindset hierin enthalten, da Agilität nicht nur mit der Ausführung gewisser Praktiken erreicht werden kann, sondern maßgeblich auch von der Einstellung der Individuen beeinflusst wird. Flexibilität der Unternehmensprozesse In Unternehmen mit unflexiblen Prozessen eignen sich agile Vorgehensmodelle nicht, da diese durch starre Schnittstellen in ihren Möglichkeiten eingeschränkt werden. Wenn flexible Prozesse gegeben sind, so eignen sich beide Philosophien gleichermaßen. Strategische Ausrichtung des Unternehmens Im Gegensatz zum Agilometer wird die Ausrichtung des Unternehmens unabhängig von der Affinität des Managements betrachtet und von der Unternehmenskultur getrennt. Während die Kultur die - auch inoffiziellen - Gegebenheiten betrachtet, beinhaltet die strategische Ausrichtung die bewusste, langfristige Planung für gegenwärtige und zukünftige Projekte und kann von der real gelebten Kultur abweichen. 3.3.3.2 Projektteamspezifische Merkmale Projektteamspezifische Merkmale werden vor allem durch die Zusammenstellung des Projekt- Teams und die mit dem Projekt befassten Individuen definiert. Einzelne Merkmale lassen sich so auch an die Mehrheit der Merkmale anpassen, um ein einheitlicheres Bild der Eignung zu schaffen. Ob diese Anpassung nicht nur theoretisch, sondern auch praktisch möglich ist, hängt von den verfügbaren Ressourcen der Organisation ab. 77 projektteamspezifische Merkmale nicht gegeben stark ausgeprägt interdisziplinäre Zusammenarbeit erfolgskritisch neutral agil Erfahrungen in agiler Arbeitsweise und Qualifikationen klassisch agil kleines Projekt-Team klassisch agil Mitarbeiter bevorzugen Freiheitsgrade klassisch agil Team arbeitet in räumlicher Nähe klassisch neutral Abbildung 155: Projektteamspezifische Merkmale 77 siehe auch Hüsselmann, 2021, S. 162.; Boehm/ Turner, 2003; Wysocki, 2019, S. 47; IAPM, 2017; S. 38 <?page no="147"?> 3.3 Projekttypisierung 147 Interdisziplinäre Zusammenarbeit Die Fokussierung auf die Zusammenarbeit und der hohe Stellenwert der Kommunikation im Team fördert die interdisziplinäre Lösungsfindung. Projekte, deren Gegenstand eine interdisziplinäre Lösung erfordert, eignen sich besser für agile Ansätze. Wenn nur eine Fachrichtung im Projekt benötigt wird, eignen sich agile und klassische Vorgehensweisen gleichermaßen. Erfahrungen und Qualifikationsgrad Unabhängig vom Vorgehen im Projekt ist die Qualifikation des Teams im gewählten Modell von Bedeutung, um das Projekt erfolgreich durchzuführen. Einerseits sind hier Kenntnisse der Methoden, aber auch Erfahrungen in der praktischen Anwendung zusammengefasst. Für agile Vorgehensweisen wird im Gegensatz zu klassischen Projekten zusätzlich zur Qualifikation im Projektmanagementvorgehen auch hoher Wert auf fachliche Qualifikation gelegt. Boehm und Turner führen am Beispiel des agilen Vorgehens im IT-Umfeld aus, dass die Selbstorganisation in agilen Teams höhere fachliche Qualifikation und Fähigkeit zur Zusammenarbeit im Team erfordert. Größe des Projekt-Teams Die geforderte Kommunikation im Rahmen eines agilen Projekts limitiert die Größe des Projekt-Teams. Ab einer gewissen Größe werden die Kommunikation und die Selbstorganisation im agilen Bereich ineffizient und stoßen an ihre Grenzen, sodass agile Ansätze sich nur schlecht skalieren lassen, durch die Skalierung an Agilität verlieren und somit starrer und plangetriebener werden. Im Gegensatz dazu steht der hohe formalisierte Planungsaufwand im Voraus bei kleinen Projekten beziehungsweise Projekt-Teams oft nicht im Verhältnis zum Nutzen. Mitarbeiter bevorzugen Freiheitsgrade Die Fokussierung auf die Eigenverantwortung und Selbststeuerung in agilen Projekten ermöglicht es den Mitarbeitern, ihre eigenen Vorstellungen und Ideen in den Verlauf des Projekts einzubringen. Für Teams, deren Mitglieder in solchen Situationen aufblühen, eignen sich agile Vorgehensmodelle. Wenn Mitarbeiter klare Orientierungshilfen und Arbeitsanweisungen wünschen, empfiehlt sich ein klassischer Ansatz. Räumliche Verteilung des Teams Für viele Praktiken des agilen Projektmanagements sind eine physische Nähe und Kontakt am Arbeitsplatz förderlich. Auch für die von Boehm und Turner identifizierte Notwendigkeit, in agilen Projekten viel zu kommunizieren und zu kollaborieren, ist eine geringe räumliche Distanz der Mitglieder des Projekt-Teams zuträglich. 3.3.3.3 Projektspezifische Merkmale Projektspezifische Merkmale werden im Wesentlichen durch den Gegenstand des Projekts sowie den Auftraggeber und weitere Stakeholder bestimmt. Diese lassen sich in gewissen Grenzen in Zusammenarbeit mit den Stakeholdern beeinflussen. 78 78 siehe auch Paukner/ Seel/ Timinger, 2018, S. 168; Boehm/ Turner, 2003, S. 33ff.; Hüsselmann, 2021, S. 161; Wysocki, 2019, S. 8, 95, 383 <?page no="148"?> 148 Takt 3: Projektorganisation projektspezifische Merkmale nicht gegeben stark ausgeprägt Sicherheit bezüglich des Vorgehens und der Technologie agil klassisch hohe Dynamik des Projekts neutral agil hohe strukturelle Kompliziertheit des Projektgegenstands neutral klassisch Anforderungen an Projektbegleitdokumentation neutral klassisch Kritikalität des Projektgegenstands hoch neutral klassisch Quick Wins erforderlich neutral agil Änderung am Projektgegenstand möglich klassisch neutral detaillierte Planung gefordert neutral klassisch intensiver Austausch mit Anwendern und Auftraggeber klassisch agil hohes Vertrauen zwischen Auftraggeber und Dienstleister klassisch neutral Abbildung 156: Projektspezifische Merkmale Sicherheit bezüglich des Vorgehens und der Technologie Klassisches Vorgehen beinhaltet weite Teile der Planung im Voraus. Um möglichst passend planen zu können, ist es nötig, dass der Weg zur Erreichung des Projektziels klar ersichtlich ist. Dazu ist eine grundsätzliche Vorstellung des geeigneten Lösungswegs, sowie der zur Lösung benötigten Technologien erforderlich. Im Gegensatz dazu profitiert agiles Vorgehen davon, den Lösungsweg iterativ zu finden. Dynamik des Projekts Die Dynamik eines Projekts äußert sich in der Häufigkeit der Anforderungsänderungen. Während agile Methoden mit diesen zumeist gut umgehen können und diese im Projektverlauf vorsehen, leiden klassische Projekte unter häufiger Änderung der Anforderungen. Boehm und Turner messen die Dynamik des Projekts, indem sie den Anteil der monatlich geänderten Anforderungen in Relation zur Gesamtheit der Anforderungen setzen. Die von ihnen genutzte Skala sieht 1% geänderte Anforderungen als niedrig und reicht bis zu 50%. Strukturelle Kompliziertheit des Projektgegenstands Ein komplizierter Projektgegenstand zeichnet sich dadurch aus, dass verschiedene Elemente aufeinander aufbauen. Dies kann schnell den Rahmen übersteigen, der in einem agilen Team überblickt und bearbeitet werden kann. Bei hoher struktureller Kompliziertheit eignen sich klassische Ansätze, während eine geringe Kompliziertheit keine Tendenz für agiles oder klassisches Vorgehen indiziert. <?page no="149"?> 3.3 Projekttypisierung 149 Anforderung an Projektbegleitdokumentation Auch wenn agiles Projektvorgehen keinesfalls bedeutet, dass das Projekt nicht dokumentiert wird, so können klassische Projekte zumeist besser formalisierte Anforderungen an die Dokumentation, beispielsweise von Projektsponsor oder öffentlichen Stellen, erfüllen. Kritikalität des Projektgegenstands / Gefährdungspotenzial Das Gefährdungspotenzial des Projektgegenstands beschreibt die Gefahr, die bei einem Produktfehler von dem Projektgegenstand ausgehen kann. Hierbei spielt auch die vorgesehene Einsatzumgebung und nicht nur der Projektgegenstand an sich eine Rolle. Boehm und Turner unterteilen das Gefährdungspotenzial auf einer fünfstufigen Skala in Schritten von Komfortverlust über den Verlust signifikanter Ressourcen bis zum Verlust vieler Menschenleben. Hochkritische Projekte sollten in klassischen Vorgehensweisen bearbeitet werden, wohingegen unkritische Projekte als neutral zu betrachten sind.79 Quick Wins erforderlich Wenn früh im Projekt Zwischenergebnisse aus der Projektbearbeitung gefordert werden, so eignet sich eine iterative, agile Herangehensweise. Wenn keine nutzbaren Zwischenergebnisse benötigt werden, eignen sich beide Ansätze des Projektmanagements, solange das für die agile Projektdurchführung benötigte Feedback ins Projekt eingespielt wird. Anpassungsfähigkeit des Projektgegenstands Das Merkmal der Anpassungsfähigkeit ist eng verwandt mit dem Merkmal der Quick Wins, betrachtet jedoch einen grundsätzlich anderen Aspekt. Während im Vorherigen auf die Anforderungen und Möglichkeiten des Auftraggebers abgezielt wurde, wird hier die technische Eignung des Projektgegenstands betrachtet: Ist der Projektgegenstand in späteren Phasen des Projekts einfach zu adaptieren oder sind Änderungen mit hohem Einsatz von Zeit, Ressourcen und finanziellen Mitteln verbunden. Falls Letzteres der Fall ist, so eignen sich agile Methoden kaum. Bei einer hohen Anpassungsfähigkeit lässt sich keine Aussage über die Eignung der Projektmanagementansätze treffen. Detaillierte Planung gefordert Die Kernidee des agilen Vorgehens widerspricht der detaillierten beziehungsweise fein granulierten Planung vor Beginn des Projekts. Somit eignen sich für Projekte, in denen eine derartige Planung gefordert wird, nur klassische Ansätze. Wenn keine spezifischen Anforderungen an die Projektplanung gestellt werden, ist an diesem Merkmal keine Tendenz abzuleiten. Austausch mit Anwendern und Auftraggeber Für erfolgreiches iteratives Vorgehen ist Feedback der Kunden des Projekts wichtig, um zu gewährleisten, dass der Projektgegenstand sich über die Iterationen im Sinne des Kunden entwickelt. In klassischen Projekten kann ein intensiver Austausch in der Planungsphase Nutzen stiften, in späteren Phasen ist die Einbindung von Auftraggeber und Anwender mit zusätzlichem Aufwand durch Änderungen verbunden. Somit eignen sich Projekte, in denen der Kunde stark eingebunden ist, für agile Ansätze. Wenn der Kunde nicht für eine enge Zusammenarbeit zur Verfügung steht, eignen sich klassische Ansätze. 79 Hüsselmann, 2021, S. 160 ff. <?page no="150"?> 150 Takt 3: Projektorganisation Vertrauen zwischen Auftraggeber und Dienstleister Für die erfolgreiche Durchführung eines agilen Projekts ist ein vertrauensvolles Verhältnis, in dem beide Seiten gemeinsam nach Lösungen streben, erforderlich. Wenn das Verhältnis eine strikte, vertragliche Regelung benötigt, so eignen sich klassische Vorgehensweisen für das Projekt. Projektspezifisch gibt es weitere Merkmale, die gegen beide Vorgehensweisen sprechen können. Diese erfordern entweder eine andere Vorgehensweise oder eine Veränderung der Rahmenbedingungen vor Beginn des Projekts, um die Ausprägung dieser Merkmale zu ändern. Sicherheit bezüglich des Ziels Dieses Kriterium spielt eine wichtige Rolle für das Projektmanagement, jedoch nicht in der hier betrachteten Fragestellung. Eine hohe Unsicherheit bezüglich des Ziels führt dazu, dass sowohl klassische als auch agile Methoden ungeeignet sind, das Projekt zu managen. Hüsselmann empfiehlt für solche Projekte den Ansatz der Effectuation, Wysocki spricht, abhängig davon, ob der Weg zur Lösung unklar ist, von emertxen oder extremen Projekten, die entsprechend gemanagt werden müssen. Komplexität des Projektgegenstands Ein komplexes Projekt zeichnet sich dadurch aus, dass in einem komplizierten Projekt viele Wechselwirkungen zwischen verschiedenen Elementen bestehen. Im Gegensatz zu einem komplizierten Projekt, das trotz der vielschichtigen Elemente sich strukturieren und planen lässt, verhindern die Wechselwirkungen und Abhängigkeiten eine für ein klassisches Vorgehen nötige Planung. Gleichzeitig gelten die Einschränkungen, die ein kompliziertes Projekt ungeeignet für agile Vorgehensweisen machen, auch für komplexe Projekte. Hüsselmann führt Ansätze aus, komplexe Projekte zu vereinfachen und zu zerlegen, um entweder die Wechselwirkungen zu eliminieren oder die Anzahl der Elemente zu reduzieren und so das Projekt aus dem Bereich der komplexen Projekte zu bewegen. Dieser Ansatz löst das Dilemma der komplexen Projekte und ermöglicht die Suche nach den passenden Ansätzen für die einzelnen Teile des ursprünglichen Projekts. 3.3.4 Fazit Die Analyse praktischer Projekte mithilfe des Agilometers zeigt, dass sich Projekte in der Realität nicht problemlos in agil und klassisch unterteilen lassen. Zumindest einige Merkmale widersprechen im Regelfall der überwiegenden Tendenz, in einzelnen Fällen kann dies zu einer sehr knappen Indikation in die eine oder andere Richtung führen. Zur Erstellung eines projektindividuellen, an die Merkmale angepassten Vorgehensmodells wird in einem ersten Schritt die grundsätzliche Eignung des Projekts beziehungsweise einzelner Projektabschnitte für ein agiles oder klassisches Vorgehen untersucht. Wenn einige oder mehrere Merkmale dieser grundsätzlichen Eignung widersprechen, wird das grundlegende Vorgehensmodell gezielt an diesen Stellen um Praktiken erweitert, die die fraglichen Merkmalsausprägungen in das Vorgehensmodell integrieren. Die Kombination dieser zu einem völlig neuen, hybriden Vorgehensmodell kann jedoch dazu führen, dass der Aufwand den Nutzen signifikant übersteigt. Somit wird immer ein Rahmen benötigt, der gezielt angepasst wird. Die Rollen in agilen und klassischen Welten unterscheiden sich deutlich voneinander. Es lassen sich auch keine eindeutigen Entsprechungen füreinander finden, da sich die Ansprüche an Persönlichkeit und Qualifikation unterscheiden. Ausgehend von der Grundorganisation der projektdurchführenden Organisation sind Entsprechungen für die jeweils andere Philosophie zu <?page no="151"?> 3.4 Transferaufgaben Takt 3 151 finden, auch wenn diese Entsprechung nicht zwingend an Rollen, sondern vielmehr an Personen orientiert sein kann. Je mehr Praktiken zur Ergänzung und Erweiterung in Richtung hybrides Projektmanagement eingesetzt werden, desto mehr Kommunikation zur projektindividuellen Kompetenzverteilung wird benötigt. Allgemein lässt sich jedoch sagen, dass die Rollenfindung vereinfacht wird, wenn sowohl in agilem als auch klassischem Rahmen eine Unterteilung in Prozessverantwortung und Produktverantwortung durchgeführt wird. Dies bedeutet im Allgemeinen, dass weder die gleichen Teams in agilem und klassischem Kontext eingesetzt werden können, noch, dass eine Person für alle Philosophien als Führungskraft geeignet ist. Vielmehr ist ein vermehrt auf Persönlichkeit und Qualifikation der Projektbeteiligten zu fokussieren. Dies führt zu der Konstellation, dass wenn in einer Organisation klassische, agile und hybride Projekte nebeneinander durchgeführt werden, die unternehmensspezifischen und teamspezifischen Merkmale bei der Entscheidung, wie das Projekt durchgeführt wird, im Regelfall ausgeklammert werden können. Die unternehmensspezifischen Merkmale sind im Rahmen der Entscheidung relevant, ob im fraglichen Unternehmen überhaupt mehrere Philosophien eingesetzt werden können. Die teamspezifischen Merkmale sind bei der Entscheidung relevant, welches Team für das Projekt geeignet ist. Wenn sowohl agile als auch klassische Teams im Unternehmen beschäftigt sind, so entscheiden primär die teamspezifischen Eigenschaften darüber, wie ein Projekt durchgeführt wird. Das (Projektportfolio-)Management identifiziert das geeignete Vorgehensmodell und sucht anhand dessen ein Team aus, dessen Qualifikationen zum Projekt passt. Alternativ ist auch ein Modell vorstellbar, in dem das Portfoliomanagement die Projekte priorisiert und sammelt. Aus dieser Sammlung wählen die Teams entsprechend ihrer Kapazitäten diejenigen Projekte aus, die zu den Stärken des Teams passen. Für dieses Vorgehen sind feste Teams sowohl in allen Vorgehensmodellen eine Voraussetzung. Sobald jedoch die unternehmensspezifischen Merkmale sich zwischen verschiedenen Projekten unterscheiden, beispielsweise durch externe Partnerunternehmen, sind diese wieder in die Entscheidung mit einzubeziehen. Gleiches gilt für teamspezifische Merkmale: Sollte aus Gründen wie der Erfahrung nur ein Team für ein Projekt in Frage kommen, so sind die teamspezifischen Merkmale für die Entscheidung, welches Vorgehen gewählt wird, relevant. Abschließend zum Kapitel auch hier ein kurzes Wrap-up im Video: ► Video 3.8 (Wrap-up), URL: https: / / youtu.be/ 3EnT1UIQOKs 3.4 Transferaufgaben Takt 3 3.4.1 Vorgehensmodell Es stellt sich die Frage, welches Vorgehensmodell für das Projekt das richtige ist. Mit Blick auf die Frage, ob eher klassisch plangetrieben oder eher agil vorgegangen werden sollte, kann das Agilometer eingesetzt werden. ▲ Wenden Sie also bitte einmal im Kontext des von Ihnen betrachteten Projekts das zur Verfügung gestellte MS Excel-Tool „Agilometer“ an. Zu welcher Erkenntnis gelangen Sie? Welcher Typ von Projekt ist das ausgewählte? ▼ Tool [Agilometer] <?page no="152"?> 152 Takt 3: Projektorganisation 3.4.2 Projektorganisation Sie haben im Modul die RACI-Methode zur strukturierten Beschreibung organisatorischer Zuständigkeiten im Projekt kennengelernt. ▲ Bitte erstellen Sie für Ihr ausgewähltes Projekt eine RACI-Matrix. Sie finden dafür eine MS Excel-Vorlage vor. ▼ Tool [RACI-Matrix] Viel Spaß! <?page no="153"?> 4 Takt 4: Projektsteuerung In diesem Takt werden einige ausgewählte PM-Disziplinen thematisiert. Auch hierzu finden Sie zur Einleitung im folgenden Video einen Überblick über den folgenden Takt und eine Motivation und Einordnung des Themas. ► Video 4.1 (Einleitung), URL: https: / / youtu.be/ SnLIhb_ekoc 4.1 Vertragsmanagement Das Beschaffungsmanagement in Projekten beinhaltet die Prozesse für den Kauf oder Erwerb der Produkte, Dienstleistungen und Ergebnisse, die von außerhalb des Projektteams für die Durchführung der Arbeit benötigt werden. Es umfasst das Vertragsmanagement und die Prozesse zur Änderungssteuerung, die zum Managen der von autorisierten Projektteammitgliedern ausgegebenen Verträge oder Bestellungen erforderlich sind. Folgende Prozesse sind im Beschaffungsmanagement in Projekten enthalten: Abbildung 157: Teilprozesse im Beschaffungsmanagement Auch das Management kommerzieller Projekte, Commercial Project Management genannt, in denen die eigene Organisation der Projektauftragnehmer ist, erfordert nicht zuletzt ein ausgeprägtes Vertragsmanagement. Von der Gestaltung des Vertrags über die Überwachung der vertraglich geschuldeten Leistungserbringung, das Nachforderungsmanagement (Claim Management) bis hin zur formellen Abnahme und Übergabe der Projektergebnisse, der kaufmännischen Abrechnung und anschließenden Handhabung von Gewährleistung sowie Garantieleistungen ergibt sich hier eine eigene, durchaus juristisch geprägte Domäne des Projektmanagements. Schauen Sie zunächst einmal in eine kurze Einführung zum Vertragsmanagement. ► Video 4.2 (Überblick Vertragsmanagement), URL: https: / / youtu.be/ rOwkPKbpgxU Nur wenn man genau weiß, welche Rechten und Pflichten man hat, kann man diese auch einhalten bzw. einfordern! Projektteams müssen sich strikt an die Verträge (und an die Gesetze) halten. Von zentraler Bedeutung ist hierbei der Projektvertrag. ��� (Projekt-)Verträge sind die rechtliche Grundlage für ein Projekt. <?page no="154"?> 154 Takt 4: Projektsteuerung Der Projektvertrag zeichnet sich besonders durch die Einmaligkeit seiner Zielsetzungen aus. Ist der Vertrag erfüllt, ist das (unmittelbare Projekt-)Ziel erreicht. An den Projektvertrag knüpft das Vertragsmanagement an … und schließlich auch das Nachforderungs-(Claim-)Management. Der Projektvertrag …  wird zwischen dem Auftraggeber und der ausführenden Partei geschlossen. Er regelt die Rechte und Pflichten beider Parteien. Die Projektmanager beider Parteien müssen den Vertrag kennen - und vor allem auch verstehen! Eine gewisse Grundkenntnis in rechtlichen Dingen ist unabdingbar.  Es ist wichtig, dass sich die Parteien strikt an den Projektvertrag halten. Er bildet die Grundlage des Handelns. Vertragsmanagement …  dient zur Steuerung der Gestaltung, des Abschlusses, der Fortschreibung und der Abwicklung von Verträgen zur Erreichung der Projektziele. Claim Management … • bezeichnet die „Überwachung und Beurteilung von Abweichungen bzw. Änderungen und deren wirtschaftlichen Folgen zwecks Ermittlung und Durchsetzung von Ansprüchen.“ (DIN 69905: 1997) Abbildung 158: Der Vertrag im Projektmanagement 4.1.1 Vertragsarten In der bilateralen Gestaltung von Projektverträgen lassen sich auf kommerzieller und Leistungsebene grundsätzlich folgende Unterscheidungen treffen: Leistung Werkvertrag versus Dienstleistungsvertrag kommerziell Festpreisvertrag versus Vertrag auf Zeit- und Materialbasis (Time & Materials) Abbildung 159: Typisierung der Vertragsarten <?page no="155"?> 4.1 Vertragsmanagement 155 ��� Die Legal-Perspektive umfasst die Art des Leistungsgegenstands, der geschuldet wird, sowie die juristischen Konsequenzen hieraus (z.B. Haftung und Gewährleistung). 80 Beim Werkvertrag schuldet der Auftragnehmer dem Auftraggeber ein erfolgreich geliefertes Gewerk, für das er eine Vergütung erhält. Typisches Beispiel im Projektkontext ist die gemäß den vereinbarten Spezifikationen zu erstellende technische Anlage oder eine funktionierende Software. Der Dienstleistungsvertrag ist pauschal nicht gesetzlich geregelt. Kern ist - wie der Name schon sagt − die Erbringung einer Dienstleistung im Gegensatz zu einer Sachleistung. Beispiel im Projektgeschäft ist die Entwicklungsleistung eines Ingenieurs. Geschuldet wird typischerweise das Einbringen einer Arbeitsleistung nach aktuellem Stand der zugehörigen fachlichen Domäne (State-of-the-Art). ��� Die kaufmännische Perspektive umfasst die kommerzielle Handhabung des Projektes, insbesondere mit Blick auf die Fakturierung. Mit dem Begriff Festpreis ist in der Regel ein Pauschalpreis gemeint, mit dem alle Einzelleistungen abgegolten sein sollen, die zur Herstellung einer vertragsgerechten und mängelfreien Leistung erforderlich sind. Die Leistung wird zu einem vereinbarten Preis vergütet, egal wieviel Aufwand geleistet wurde: • Keine Tätigkeitsnachweise erforderlich. • Oftmals phasenbezogener Zahlungsplan. • Unternehmerisches Risiko und Chance bzgl. Deckungsbeitrag für den Auftragnehmer groß. Beim Vertrag auf Zeit- und Materialbasis erklärt sich der Auftraggeber demgegenüber bereit, den Auftragnehmer nach seinen tatsächlich angefallenen Aufwänden zu bezahlen. Die Leistung wird nach „Time & Material“ vergütet: • In der Regel Tätigkeitsnachweise notwendig. • Oftmals zeitbezogene Fakturierung, z.B. monatlich. • Teilweise mit vereinbarter Obergrenze („Deckelung“) der fakturierbaren Aufwände. Ein Pauschalpreis ist hier aufgrund der bestehenden Unsicherheiten hinsichtlich der Aufwände zumindest seitens des Auftragnehmers oftmals nicht seriös kalkulierbar. Mit der geschilderten grundsätzlichen Einteilung - eine weitere differenzierte Betrachtung der unterschiedlichen jeweiligen Varianten etc. bleibt hier den Juristen vorbehalten - wird deutlich, dass der Vertragsgestaltung bei der Umsetzung von Lean PM eine nicht unwichtige Bedeutung zukommt. Auch wenn vielfach Werkverträge zum Festpreis vereinbart und Dienstleistungen nach Time & Material abgegolten werden, ist es ein weit verbreiteter zu beobachtender Irrtum, dass nur diese Kombinationen möglich seien. Durch die Trennung der rechtlichen Aspekte (Was wird geschuldet? ) von den kommerziellen (Wie wird abgerechnet? ) lassen sich auch z.B. Werkverträge abschließen, die nach Zeit- und Material abgerechnet werden. Vielfach wird hier natürlich der abrechenbare Aufwand gedeckelt sein, um nicht ein Fass ohne Boden zu erzeugen. Im Sinne der Verteilung von Risiken und Chance zwischen den Vertragspartnern sind dann entsprechende Mechanismen der Steuerung zu vereinbaren, wie Toleranzen, Schwellenwerte, Bonus-Malus-Regeln etc. Entscheidend ist hier, dass (gesetzliche) Regelungen zu Abnahme, Gefahrenübergang, Gewährleistung und gegebenenfalls Garantie durch den werkvertraglichen Charakter gewahrt bleiben. 80 siehe auch BGB §§ 631 ff. bzw. §§ 611 ff. <?page no="156"?> 156 Takt 4: Projektsteuerung 4.1.2 Change Requests Änderungen des Inhalts und Umfangs verändern i.d.R. den Projektauftrag und müssen durch Änderungsanträge (Change Request) formalisiert und administriert werden. Das Anforderungs- und Umfangsmanagement in Projekten beinhaltet die erforderlichen Prozesse, um sicherstellen, dass das Projekt alle erforderlichen Arbeiten, aber auch nur diese, umfasst, um es erfolgreich zu beenden. Hierbei geht es vorrangig um die Definition und Steuerung dessen, was im Projekt eingeschlossen ist und was nicht. ��� Jede Änderung des Kunden/ Auftraggebers, die eine Auswirkung auf den Vertrag/ Projektauftrag hat, erfordert einen Änderungsantrag (Change Request)! Inhalte eines Antrags - Beispiele mit Ursachen: • Ergebnis/ Qualität: Anforderungsänderungen des Auftraggebers • Zeit: Fehler in der Durchführung, Marktsituation • Kosten: gesetzliche Änderungen • Personelles: Aufnahme eines neuen Mitglieds im Lenkungsausschuss Die Status von Änderungen sind zu dokumentieren, z.B.: • beantragt • freigegeben bzw. abgelehnt • geplant • durchgeführt • abgenommen Abbildung 160: CR Managementprozess − Übersicht Das Anforderungsänderungsmanagement (Change Request Management) befasst sich mit der Organisation, Verwaltung und Abwicklung von Änderungsanträgen. Mögliche Prozessschritte (nach ICB 3.0): ► Festlegung der Änderungspolitik mit Verantwortlichkeiten und anzuwendendem Prozess ► Erfassung und Bearbeitung der beantragten Änderungen→ Änderungsantrag (Change Request). ► Analysieren und Bewertung hinsichtlich der Projektfolgen (Inhalt, Termine, Kosten, Risiko, Qualität). ► Entscheidung: Freigabe oder Ablehnung der Änderungen durch eine autorisierte Instanz, z.B. Projektleiter, Lenkungsausschuss oder Change Control Board (CCB). <?page no="157"?> 4.1 Vertragsmanagement 157 ► Planung, Durchführung, Überwachung und Abschluss der genehmigten Änderungen. ► Änderung des Basis-Projektplans. ► Dokumentation der Lessons Learned für zukünftige Projekte. Den CR Managementprozess in der Übersicht zeigt die Abbildung 159. Änderungsmanagement behandelt Änderungen so, dass das Projektziel bzw. der Projektnutzen nicht gefährdet wird. 4.1.3 Claims Eine Pflichtverletzung eines Vertragspartners ist als Leistungsstörung im Rahmen des Vertragsmanagements zu behandeln. Folgende Arten der Leistungsstörung sind nicht selten zu beobachten: • Leistung wurde gar nicht erbracht • Mitwirkungspflichten wurden nicht erfüllt • Leistung ist unvollständig • Leistung hat nicht die vereinbarte Qualität • Termin für die Leistung wurde überschritten Folgende Rechte haben die Vertragspartner bei Leistungsstörungen: • Nacherfüllung (Gelegenheit zur Nachbesserung) • Vertragsstrafe (nur wenn vereinbart) • Selbstvornahme (Mängelbeseitigung durch Auftraggeber) • Schadensersatz (bei Verschulden des Vertragspartners) • Kündigung aus wichtigem Grund (Vertragsverhältnis nicht mehr zumutbar) • Annullierung (Rückabwicklung auf vorvertraglichen Zustand) Definition Claim Ein Claim ist eine Nachforderung aufgrund eines Vertrags, die eine Vertragspartei an die andere stellt, wenn … - Zusatzleistungen aufgrund von nicht vereinbarten Anordnungen erbracht werden, die andere Vertragspartei ihre Pflichten nicht oder nur mangelhaft erfüllt, und die Vertragsabwicklung nachweislich behindert oder unterbrochen wird. Beim Claim Management geht es darum, die Abweichungen zum eigentlichen Vertrag zu erfassen und dem jeweiligen Projektpartner als Leistung bzw. Zahlung zuzuordnen. Beispiele • Durch den Ausfall der IT-Infrastruktur ist die Projektarbeit um 2 Tage nach hinten gerutscht. Wer übernimmt die Stillstandskosten? • Statt der im Pflichtenheft beschriebenen Marken-Hardware ist eine wesentlich günstigere und qualitativ schwächere Hardware aus einem Discounter verbaut worden. Wie ist damit umzugehen? Die Übergänge zwischen Vertrags- und Claim Management sind fließend. Der Schwerpunkt liegt zunächst auf dem Vertragsmanagement − mit Vertragsabschluss tritt das Claim Management in Erscheinung: <?page no="158"?> 158 Takt 4: Projektsteuerung Abbildung 161: Übergänge zwischen Vertrags- und Claim Management sind fließend Das auf ordnungsgemäße Vertragserfüllung ausgerichtete Vertragsmanagement weicht zunehmend dem erlösorientierten Claim Management. Die Intensität des Claim Management variiert je nach • Vertragsart (z.B. Gewerk oder Dienstleistung), sowie • Auftraggeber-Auftragnehmer-Konstellation (z.B. partnerschaftlich oder konfrontativ) • Branche (z.B. Bau oder IT) Folgende Claim-Strategien sind in der Praxis zu beobachten: Abbildung 162: Claim-Strategien Ein ausgeprägtes, insbesondere aggressives Claim-Verhalten hat sich allerdings in Projekten vielfach als kontraproduktiv für den Projekterfolg erwiesen, da zuviel Kapazität in vertragliche Konfliktbewältigung fließt. Insbesondere auch bei agil durchgeführten Projekten, bei denen die Anforderungen von vorneherein flexibel gehalten und im Laufe des Projekts nachgesteuert werden ergibt sich zwingend das Erfordernis eines veränderten Vertragsmanagements und einer veränderten Vertragsgestaltung. Die wird mit dem sogenannten agilen Festpreisvertrag erreicht, der im Folgenden beschrieben wird. Eine weiterführende Verallgemeinerung stellt der im Anschluss beschrieben relationale Vertrag dar. 4.1.4 Agiler Festpreisvertrag Agilität ist die Kunst des Maximierens der Arbeit, die nicht getan werden muss. Die agile Durchführung von Projekten erfordert im Kern ein Umdenken hinsichtlich der Fixierung der Dimensionen des Magischen Dreiecks. <?page no="159"?> 4.1 Vertragsmanagement 159 Abbildung 163: Das Magische Dreieck im agilen und klassischen Projektvorgehen Die Flexibilisierung des Scope im agilen Kontext ermöglicht es, bei fixierten Zeit- und Ressourcenansätzen Ergebnisse mit fortlaufender Optimierung des Nutzens zu erzielen − ggf. nicht unter vollständiger Abbildung aller möglicher/ denkbarer Anforderungen. Eine Variante der Vertragsgestaltung liefert dabei der Agile Festpreisvertrag . 81 Ziel dieser Vertragsform ist es u.a., den Werkvertragscharakter zu erhalten, gleichzeitig aber eine deutlich gesteigerte Flexibilität bei der Leistungserstellung zu erzielen. Im Sinne eines Pauschalpreises wird dazu ein monetäres Budget vereinbart, dass bei personalaufwandsdominierten Projektarten, wie z.B. der Software-Entwicklung, letztlich zu einem Kontingent an Personentagen für die Projektdurchführung führt. Auf der anderen Seite der Vertragsmedaille steht der Scope, also der Leistungsumfang der beauftragten Sachleistung (Anlage, IT etc.). Ein starres Lastenbzw. Pflichtenheft liefert hier wenig bis keinen Spielraum. Um diesbezüglich Möglichkeiten der Steuerung zu erzielen, sollten Methoden, wie sie im Abschnitt zum „atmenden“ Scope und auch der rollierenden Planung beschrieben werden, zum Einsatz kommen. Folgende Prozessschritte dienen zur Vereinbarung eines Agilen Festpreises: Abbildung 164: Prozessschritte Vereinbarung Agiler Festpreis 81 siehe auch Opelt et al., 2014 Scope-Definition Beschreibung Vertragsgegenstand per Vision/ Epics Auswahl Referenz-User Stories und Analogieschätzung durch Lieferant Gemeinsamer Workshop zu Umfang User Stories und Annahme Analogschätzung Prozessdefinition Festlegung Riskshare und Checkpoint-Phasen Vereinbarung Prozess zu Scope- Verwaltung & -Entscheidung Vereinbarung kommerzieller und rechtlicher Rahmen sowie Bonussystem <?page no="160"?> 160 Takt 4: Projektsteuerung Unter einem Epic versteht man im Kontext des Anforderungsmanagements die Beschreibung einer Anforderung an eine neue Software auf einer hohen Abstraktionsebene. Die Beschreibung der Anforderung geschieht dabei in der Alltagssprache (vergleichbar User Story). Preismodelle in der Übersicht Die folgende Übersicht stellt die geschildeten Preismodelle (auch in Varianten) einmal hinsichtlich ausgewählter Aspekte bewertend gegenüber: 82 Abbildung 165: Gegenüberstellung und Bewertung Vertragsmodelle 4.1.5 Relationaler Vertrag Lean-PM-Prinzipien wie Lernen aus Erfahrungen, offene Fehlerkultur, Partizipation etc. verlangen jedoch noch weitere Aspekte einer adäquaten Vertragsgestaltung. Es geht um die Art und Weise der Zusammenarbeit bei der Abwicklung des Projekts. Klassische Verträge zur Projektabwicklung sind sog. transaktionale Verträge. Sie klären den Leistungsgegenstand inkl. aller Rechte und Pflichten der Projektbeteiligten durch möglichst detaillierte, justiziable und mit Haftungssanktionen abgesicherte Regelungen. Durch den Vertrag sollen dabei bereits im Vorfeld mögliche (negative) Entwicklungen vorweggenommen, Risiken verteilt sowie Ansprüche und Haftung gesichert werden. Dies führt vielfach zu einem Wettbewerbsdenken unter den Projektbeteiligten, wenig Anreiz zu gemeinsamer Wertschöpfungsorientierung, sondern vielmehr Fokussierung auf ökonomische Einzelinteressen (Silo-Denken) und wenig Kollaboration. 83 Für kommerzielle Projekt, die vielfach gekennzeichnet sind durch eine Vielzahl von vertraglich einzubindenden Partnern - z.B. für große Softwareeinführungsprojekte Auftraggeber, Projektsteuerer, Projektleiter, Beratungsunternehmen sowie Lieferanten für verschiedene Gewerke - führten die vielfach problematischen Konsequenzen klassischer Vertragsgestaltung zur Entwicklung partnerschaftlicher gestalteter Verträge, den sog. relationalen Verträgen. Diese sind als Reaktionen auf typische, strukturelle Probleme bei einer Vielzahl von Vorhaben entstanden: Zeitverzögerungen, einseitige Risikoverlagerung, Feststellung nicht umsetzbarer Anforderungen erst in der Realisierungsphase, verdeckter Preiswettbewerb inkl. Vergabe von Leistungen zu nicht wirtschaftlich auskömmlichen Preisen mit der Folge einer hohen Anzahl an Nachträgen etc. Relationale Verträge sind in der Regel Mehrparteienverträge, die auf den (nur) gemeinsamen Projekterfolg ausgerichtet und durch folgende Elemente charakterisiert sind: 82 Oestereich, 2006 83 s. Bethan 2020 Aspekt Preismodell Budgetsicherheit Anforderungsflexibilität Verhandlungsaufwand Schätzsicherheit Qualitätsrisiko Preisüberhöhungstendenz Gewinnchance Verlustrisiko Auftragssicherheit Abnahmeaufwand Kalkulationstransparenz Wasserfall- Vorgehen Agiles Vorgehen Festpreis 😊😊 ☹☹ ☹ ☹☹ ☹ ☹ 😊😊 ☹ 😊😊 😊😊 ☹ 😐 😐 Aufwandspreis ☹☹ 😊😊 😊 ☹☹ 😊😊 😊 😊 😊😊 ☹ 😊😊 ☹ 😊 😊 Aufwand mit Obergrenze 😊😊 😊 😐 ☹☹ ☹☹ 😊😊 😐 ☹ ☹ 😊😊 ☹ 😊 😊 Mehrstufiger Festpreis 😊 😊 ☹ 😊 😊 😊😊 😊 😐 😐 😐 😐 😊 😊 Anforderungseinheitspreis 😊😊 😊😊 ☹ 😊😊 😊 😊😊 😊 ☹ ☹ 😐 😊😊 ☹ 😊 Agiler Festpreis 😊😊 😊😊 😐 😊😊 😊 😊😊 😊 😊 😊😊 😐 😊😊 ☹ 😊 <?page no="161"?> 4.2 Qualitätsmanagement 161 Kooperation und Kollaboration als Grundlage der Projektabwicklung integrative Regelung der Leistungserstellungsprozesse (Konzeption, Realisierung etc.) gemeinsame Entwicklung und Verantwortung für Projektziele frühzeitiges Einbinden der Schlüsselbeteiligten - Vermeidung von Informationsbrüchen und -asymmetrien - Werte wie Offenheit, Transparenz, Vertrauen, Ehrlichkeit, Verlässlichkeit, Lernbereitschaft, gegenseitige Unterstützung und Lean Thinking Definition von Mechanismen zur Förderung der Zusammenarbeit gemeinsame Organisationsstrukturen räumliche Zusammenarbeit - Einstimmigkeitsprinzip, zumindest als Grundsatz gemeinsame Projektsteuerung integriertes IT-System zur fachlichen und administrativen Steuerung du Dokumentation Solidarisches Anreizsystem inkl. Risiko- und Chancengemeinschaft (Shared Risks) - Win-Winbzw. Common-Loss-Strategien gemeinsame Belohnung (Joint Reward) gemeinsame Risikotragung, zumindest partiell (ggf. abgestuft je nach Beteiligung) - Transparenz (Open Book) Gemeinsames Risikomanagement monetäre Reserve für unvorhergesehene Fälle - Nutzung Risikoregister (Werkzeug) - Frühwarnsystem gemeinsame Verantwortung Zusammenfassend gestalten relationale Verträge die Beziehung der Projektpartner so, dass die Verantwortlichkeiten und Vorteile des Projekts fair und transparent aufgeteilt werden. Dabei sind die Mechanismen der Umsetzung auf Vertrauen und Partnerschaft ausgerichtet. Dies führt im Allgemeinen zur Verbesserung der Arbeitsbeziehungen zwischen den Projektbeteiligten, der Effizienz und Effektivität der Management- und der fachlichen Projektprozesse, der Konfliktlösungsfähigkeit und schließlich des wirtschaftlichen Erfolgs (für alle). 84 Sie sind vielfach Langzeitverträge, die sich im Laufe der Zeit entwickeln und die Beziehungen zwischen den Partnern nachhaltig fordern. 4.2 Qualitätsmanagement Qualität ist, wenn der Kunde zurückkommt, nicht das Produkt. Das Qualitätsmanagement (QM) in Projekten beinhaltet sämtliche Vorgänge der Organisation, damit das Projekt die Bedürfnisse erfüllt, für die es durchgeführt wurde.“ 85 Das QM in Projekten beinhaltet die in Abbildung 166 dargestellten Prozesse (Deming-Kreis des Qualitätsmanagements). Genau wie in einem Unternehmen insgesamt, ist der Nutzen des QM im Projekt − als Teildisziplin des PM− folgender: 84 s. Colledge 2004, S. 1 85 nach PMI, 2004, S. 179 <?page no="162"?> 162 Takt 4: Projektsteuerung Abbildung 166: Teilprozesse des Qualitätsmanagements • effizientere Abläufe • eindeutige Schnittstellen • gleichbleibende Qualität • Aussagen zur Qualitätsfähigkeit und Zuverlässigkeit • Aufzeigen von Bedarfen an Änderungen, und damit • Festlegung von Korrekturmaßnahmen Damit wächst das Kundenbzw. Auftraggebervertrauen. 4.2.1 Qualitätssicherung Um die Qualität in einem Projekt sicherzustellen, ist die Anwendung von Arbeitsmitteln (Projekt-Handbuch, QM-Plan) und Verfahren unerlässlich. Folgende Qualitätsmaßnahmen sind in IT-Projekten typisch:  Tests (Module, System, Integration, Akzeptanz) o funktionale Tests o Belastungstests o Anwenderzufriedenheit  Ergänzende externe Prüfungen o Konzepte o Systeme  Nutzung von Checklisten, Templates usw.  Reviews: Zwischenmessungen und -auswertungen  Audits: (externe) Konformitätsprüfungen … aber auch  Feedback-Abfragen  Kommunikationsmaßnahmen o interne Kommunikation <?page no="163"?> 4.2 Qualitätsmanagement 163 o externe Kommunikation o Meetings  Mitarbeiterausbildung o Qualifizierungsmaßnahmen o Workshops Projekt-Review Das Projekt-Review ist ein Prüfverfahren, in dem das Projekt hinsichtlich „Kosten, Leistung und Zeit“ kritisch beleuchtet wird. Es werden die erreichten Sachergebnisse hinsichtlich der Vorgaben analysiert, der Projektverlauf bewertet und Probleme diskutiert. Es sollen Abweichungen und mögliche Steuerungsmaßnahmen aufgezeigt werden. Zeitpunkte: z.B. am Phasenende Qualitätsnachweis mittels Audit Ein Audit ist eine systematische, unabhängige Untersuchung. Sie dient dazu, festzustellen, ob eine Verfahrensweise und die damit verbundenen Ergebnisse den Vorgaben entsprechen. Außerdem soll es eine Aussage darüber erlauben, ob die geplanten Abläufe geeignet sind, die Qualitätsziele zu erreichen. Grundlage des Audits ist das unternehmensweite PM-Handbuch. Auditoren dürfen nur Personen sein, die keine unmittelbare Verantwortung in dem zu auditierenden Bereich haben. Statische und dynamische Prüfungen In Abhängigkeit vom Prüfobjekt und von der Verantwortlichkeit für Freigabe und Abnahme gibt es im Wesentlichen zwei Formen der statischen Prüfung - im Wesentlichen für Dokumente: Umlaufreview: Prüfer sind mit den Inhalten grundsätzlich vertraut (z.B. durch gemeinsame Bearbeitung). Sitzungsreview: Inhalte müssen vorgestellt werden, sind nicht selbsterklärend. Tests IT-Systeme demgegenüber sind aufgrund einer dynamischen Prüfung zu unterziehen. Der Testplan ist Zusammenfassung von einem oder mehreren Testfällen; er ist mit Bezug auf Tester unterteilt in Testpakete und enthält den Durchführungsplan für die Tests. 4.2.1.1 Externe Beurteilung Externe Beurteilungen werden im Allgemeinen in Form von Audits durchgeführt. Sie dienen zur Zertifizierung des betrachteten Managementsystems und/ oder zum Benchmarking. Zertifizierung Eine Zertifizierung ist eine Bescheinigung der Übereinstimmung eines Produktes, Managementsystems oder einer Personenqualifikation durch eine unabhängige Stelle. Benchmarking Das Project Excellence-Modell (PE) der GPM ist ein Instrument, mit dem es möglich ist, ein Projekt mit einem neutralen Bewertungsverfahren zu untersuchen. <?page no="164"?> 164 Takt 4: Projektsteuerung Kriteriengruppen im PE-Modell sind: 86 Projektergebnisse Projektprozesse Abbildung 167 Kriteriengruppen im Project Excellence-Modell 4.2.2 Qualitätsplanung Im Rahmen der Qualitätsplanung erfolgt die Spezifikation der Qualitätsprüfungen. Üblicherweise ist der QS-Plan, in dem die Qualitätsplanung dokumentiert wird, aus Gründen der Handhabung mehrstufig aufgebaut: Abbildung 168: Struktur der QM-Konzeption Inhalte eines QS-Plans 1. Systematik der Qualitätssicherung • Klassifizierung der Prüfobjekte und -methoden • Grundsystematik der Prüfmethoden • Struktur der QS-Dokumentation 86 GPM, 2014 <?page no="165"?> 4.2 Qualitätsmanagement 165 2. QS-Organisation • Aufbauorganisation und QS-Rollen • Aufgaben und Verantwortlichkeiten (QS-Prüfung) 3. Durchführung der Qualitätssicherung • QS-Prozess • Durchführung von (statischen) Prüfungen • Durchführung von Tests 4. Durchführung von Abnahmen und Durchführungsentscheidungen • Abnahmeprozess • Abnahmebedingungen Der Prüfplan ist integraler Bestandteil der Qualitätsmanagement-Systematik, die im QS-Plan grundlegend definiert ist. Der Prüfplan beantwortet folgende Fragen: - Was sind genau die Prüfobjekte? - Wer prüft wann was? - Wie ist der Ablauf der Prüfung? - Wie wird mit den Ergebnissen umgegangen? Definition Prüfobjekt „Es ist die eindeutig definierte identifizierbare Version des Prüfobjektes festzulegen, auf die sich die Prüfspezifikation beziehungsweise das Prüfprotokoll bezieht.“ Es gilt also, zunächst einmal die relevanten Prüfobjekte zu identifizieren. Für ein IT-Projekt ergibt sich typischerweise folgend Klassifizierung der Prüfobjekte: Abbildung 169: Prüfobjekte ‒ Klassifizierungsschema <?page no="166"?> 166 Takt 4: Projektsteuerung Der Prüfplan bildet dadurch die Basis zur Erreichung einer adäquaten Qualität über die gesamte Projektdauer für das Ziel einer hochwertigen Ergebniserstellung und regelt bzw. beinhaltet folgende Themen:  Organisatorische und zeitliche Einplanung der Prüfungen.  Prüfprozedur: Vorbereitung, Durchführung und Auswertung.  Prüfspezifikation: Formale und inhaltliche Kriterien.  Protokollierung der Prüfungen: Angaben zum Prüfungsvorgang, Resultat, Bewertung (→ Template). Dazu folgende Definitionen 87 : Prüfspezifikation „Eine Prüfspezifikation dient dem Prüfer als Vorgabe und Anleitung bei der Durchführung der Prüfung. In der Regel wird, entsprechend den Vorgaben des QS-Handbuchs, für jede zu prüfende Produktversion beziehungsweise für jedes zu prüfende Prozessexemplar eine spezifische Prüfspezifikation erstellt. Für jede Prüfung wird somit eine eigene Prüfspezifikation erstellt.“ Prüfkriterien „In den Prüfkriterien wird die Prüfmethode (beispielsweise Review, Inspektion und Interviews), der Abdeckungsgrad (zum Beispiel Stichprobenprüfung und vollständige Prüfung) sowie die formalen und inhaltlichen Prüfkriterien (wie inhaltliche Korrektheit, Einhaltung der Projektstandards, Gestaltung, Rechtschreibung) beschrieben. Zu den Prüfkriterien gehören auch die Bedingungen für das erfolgreiche beziehungsweise nicht erfolgreiche Ende der Prüfung.“ Inhaltliche Qualitätskriterien für Dokumente Die Anforderungen der inhaltlichen QS von konzeptionellen Dokumenten sind grundsätzlich kaum zu pauschalisieren. Wesentliche Anforderung ist es, dass die beschriebenen Inhalte im Sinne des Zweckes des Konzeptes / der Dokumentation folgenden Kriterien genügen: Kriterium Bedeutung: Sind die Inhalte … Korrektheit … fachlich korrekt / richtig Vollständigkeit … vollständig, gibt es bspw. allfällige Abgrenzungen und Benennungen offener Punkte Relevanz … relevant (z.B. adäquate Darstellungstiefe/ -granularität) Konsistenz … konsistent/ widerspruchsfrei (in sich und übergreifend) sowie redundanzfrei Adäquatheit … zielführend Reproduzierbarkeit … verständlich & reproduzierbar/ nachvollziehbar Übertragbarkeit … (weitgehend) wiederverwendbar Die o.g. Kriterien sollten im Rahmen der Erstellung des Prüfplans zur Beantwortung der Fragestellung „Wer prüft was? “ herangezogen werden. 87 nach V-Modell XT, 1997 <?page no="167"?> 4.2 Qualitätsmanagement 167 Formale Qualitätskriterien für Dokumente • Hat das Dokument eine eindeutige Identifikation? • Ist ein Deckblatt vorhanden und ist es vollständig ausgefüllt? • Ist ein Inhaltsverzeichnis vorhanden? • Stimmt das Inhaltsverzeichnis mit der Gliederung des Dokuments überein? • Existiert ein Abbildungsverzeichnis? • Ist das Dokument nach Zielgruppen gegliedert? • Ist das Dokument für die Zielgruppe(n) verständlich? • Ist das Dokument vollständig? • Entspricht das Layout den Standards? • Sind allgemeine firmeninterne und/ oder projektspezifische Richtlinien zur Unterlagenstellung eingehalten worden? • Ist das Dokument verständlich gegliedert, übersichtlich aufgebaut und leicht verständlich (Grafiken, Tabellen, ...)? • Sind Bilder und graphische Darstellungen ... o eine übersichtliche Ergänzung des Textes? o übersichtlich und nicht überladen? o verständlich bzgl. der verwendeten Symbole? o eindeutig den entsprechenden Kapiteln oder Textstellen zugeordnet? • Ist der Inhalt widerspruchsfrei? • Sind alle nicht allgemein bekannten Begriffe und Abkürzungen definiert? • Ist das Dokument aktuell? • Ist das Dokument stets mit aktuellem Inhalt reproduzierbar? • Ist das Dokument vollständig, d.h. fehlen keine Textstellen, Seiten, Abbildungen? • Existiert ein Abkürzungsverzeichnis? • Existiert ein Quellenverzeichnis? • Sind Querverweise eindeutig? • Sind alle Referenzdokumente aufgelistet? • Gibt es eine Änderungshistorie? • Sind die Änderungen markiert? • Hat das Dokument einen Versionsstand? • Sind alle Seiten eindeutig als der Dokumentversion zugehörig zu identifizieren? • Ist der Autor genannt? • Sind Vertraulichkeitsstufen und Urheberrechte ausgewiesen? • Ist der Status angegeben und richtig? • Sind Seitenzahlen und Gesamtseiten auf jeder Seite angegeben? • Sind Begriffe eindeutig definiert und durchgängig verwendet? • Ist das Dokument inhaltlich geprüft? • Ist das letzte Speicherdatum des Dokumentes angegeben? Anregung: Nutzen Sie die Positionen der inhaltlichen und formalen Qualitätssicherung von Dokumenten in Ihren Projekten doch als Checkliste! <?page no="168"?> 168 Takt 4: Projektsteuerung 4.2.3 Abnahmen Die Abnahme stellt eine wesentliche Verpflichtung des Auftraggebers dar. Durch einen geregelten Abnahmeprozess wird diese Verpflichtung operationalisiert. Aus pragmatischen Gründen wird oftmals unterschieden zwischen „Freigaben“ und „Abnahmen“: Abnahmen ergänzen Freigaben um formale Aspekte (der QS sowie gemäß Projektvertrag/ -auftrag) sowie um einen Vollständigkeitsanspruch. Der PL (des Auftragnehmers) legt Liefergegenstände formell „Bereit zur Abnahme“ vor; damit beginnt die vereinbarte Abnahmefrist. Eine Abnahme kann „ohne Mängel“ oder „mit Mängeln“ erfolgen: • (Nur) „gravierende Mängel“ können zur Abnahmeverweigerung führen. • Erkannte Mängel müssen vom Auftraggeber (Kunden) in einer stichtagsbezogenen Mängelliste dokumentiert werden und es muss eine Frist zur Nachbesserung gesetzt werden. Mit der Abnahme wird der sog. „Gefahrenübergang“ vollzogen, d.h. die Verantwortung geht auf den Auftraggeber über! ��� Eine Abnahme i.e.S. gibt es nur im Kontext eines Werkvertrags! Im folgenden Video erläutere ich den Abnahmeprozess etwas detaillierter. ► Video 4.3 (Abnahmeprozess), URL: https: / / youtu.be/ 1LdPjEOWDdk Eine Abnahme erfolgt in der Regel „mit (nicht gravierenden) Mängeln“. Zur Abnahme erfolgt seitens des Auftraggebers eine Abnahmeerklärung. Abnahmegegenstände sind dabei • die Lieferobjekte gemäß Ergebnistypenliste, • das Gesamtsystem, sowie • weitere, durch den Projektauftrag festgeschriebene Obliegenheiten des Auftragnehmers. Hierzu wird seitens der PL eine vollständige Übersicht erstellt und geführt → Mängelliste. In der Mängelliste werden alle Resttätigkeiten festgehalten. Die Einträge der Mängelliste müssen quantifiziert & qualifiziert, terminiert und vom Auftragnehmer bestätigt werden. Struktur der Mängelliste − Was? − Wer? − Bis wann? − Mängelkategorie? − Status? Die Frist zur Mängelbeseitigung muss „angemessen“ sein − bspw. sind 30 Tage üblich. ▼ Tool [Abnahmeprotokoll] 4.2.3.1 Abnahmegegenstände in IT-Projekten Abnahmetest • Installation und Tests in Testumgebung • Plausibilität der Ergebnisse • Vollständigkeit der Funktionalitäten <?page no="169"?> 4.3 Risikomanagement 169 • Erfolgreiche Massentests (möglichst mit Echtdaten) • Gutes Performanceverhalten (Antwortzeiten, Verarbeitungszeiten) bei realistischen Datenmengen • Störungsfreier Wiederanlaufs nach Abbruch • Vollständigkeit der Dokumentation • … Produkt-Dokumentation • Systemdokumentation • Betriebshandbuch • Benutzeranleitung • ggf. Schulungsunterlagen • … 4.3 Risikomanagement 4.3.1 Projektrisiken Fehlendes oder unzureichendes Risikomanagement erweist sich in vielen Projekten als Problem, wenn nicht als Ursache, die zu massiven Schwierigkeiten führen. Dazu beispielhaft ein Testat aus einem Beitrag von Spiegel Online zum gescheiterten Drohnen-Projekt „Euro Hawk“ der Bundeswehr: „Keine professionelle Chancen-Risiken-Abwägung“. Doch schauen Sie doch zunächst einmal in das folgende einleitende Video zum Risikomanagement. ► Video 4.4 (Risikomanagement), URL: https: / / youtu.be/ U5Nl4q_burE Projekte beinhalten ein viel höheres Risiko als Routinearbeiten. Denn per Definition sind Projekte Vorhaben, die sich durch die Einmaligkeit auszeichnen. Daher ist ein gutes Projektrisikomanagement unerlässlich! Es geht darum, mögliche Risiken so früh wie möglich zu erkennen, zu bewerten und sich darauf einzustellen. Da Risiken oftmals erst gewahr werden, wenn sie eingetreten sind, werden sie oftmals nicht früh und systematisch genug behandelt: „Verdrängung ist vieler Probleme Anfang.“ Risikovorsorge ist meist erheblich billiger als den Schaden zu beheben, wenn aus einem Risiko der Problemfall wird. Die Vorsorgekosten müssen dabei gegen die anzunehmende Schadenshöhe abgewogen werden. Projektrisiken können z.B. bei einem Projekt- und IT-Dienstleister schnell zu Unternehmensrisiken werden! In vielen Bereichen schreibt der Gesetzgeber aber auch Risikomanagement vor (z.B. KonTraG, Basel II). Projektrisikomanagement im Projekt umfasst die • Identifikation, Klassifizierung und Bewertung von Projektrisiken aller Art sowie die • Entwicklung und Durchführung von Maßnahmen zur Risikobewältigung. Die Risikoanalyse und -bewältigung sind ein systematischer und formaler Prozessansatz − im Gegensatz zur Intuition. <?page no="170"?> 170 Takt 4: Projektsteuerung Definition Projektrisiko 88 „Ein Projektrisiko ist ein mit gewisser Wahrscheinlichkeit eintretendes Ereignis, das ein Projekt, d.h. die Projektergebnisse oder den Projektverlauf, (meist negativ) beeinflussen kann. Bei einem positiven Einfluss spricht man von Chancen. Risiken kommen meistens aus dem Projektumfeld, können aber auch aus dem Projekt selbst kommen (z.B. bei stark innovativen Projekten).“ Anmerkung: Die DIN 69901 spricht in ihrer Definition nur von negativen Risiken, also den Gefahren. Ein Risiko kann eine oder mehrere Ursachen und bei seinem Eintreten eine oder mehrere Auswirkungen haben. Das Risiken- und Chancenmanagement ist ein fortlaufender Prozess während aller Phasen des Projektlebenszyklus, von der Ausgangsidee bis zum Projektabschluss. 89 In verschiedenen Projektphasen treten unterschiedliche Risiken auf. Beispielhafte Risiken … … eines Unternehmens, das ein neues Rechenzentrum errichten will: ▲ Überlegen Sie bitte kurz, welche Lösungsansätze Sie sehen, bevor Sie weiterlesen. mögliche Risiken mögliche Lösung / mögliche Vorkehrungen Die Sonneneinstrahlung wurde nicht bedacht, das Rechenzentrum wird zu warm im Sommer, die Fenster lassen sich aus Sicherheitsgründen nicht zum Lüften öffnen. • Bei der Planung die Wärmeentwicklung beachten. • Evtl. Absturzsicherungen vor den Fenstern einplanen. • Klimasysteme schon in der Planung mit einbeziehen. Die IT-Ausstattung erweist sich als nicht praktikabel. • Mitarbeiter, die später in dem Rechenzentrum arbeiten, mit in die Planung einbeziehen. Der Generalunternehmer (GU) kann auf Grund finanzieller Engpässe nicht mehr weiterarbeiten. • Bei Vertragsgestaltung Vertragserfüllungsbürgschaften mit dem GU abschließen. Risiko-„Reichweite“ von Projekten Risiko ist nicht gleich Risiko. Erforderlich ist eine Betrachtung der Wirkungs-„Reichweite“ (siehe Abbildung 169). Je weiter man in der Betrachtung in Richtung der Wirkung („nach unten“) schaut, desto schwieriger wird es für das Projekt-Team, das Risiko zu beeinflussen. Hier ist insbesondere der Auf- 88 nach Bartsch-Beuerlein, 2013, S. 208 89 siehe PMI bzw. ICB <?page no="171"?> 4.3 Risikomanagement 171 Abbildung 170: Risiko-„Reichweite“ von Projekten traggeber in der Pflicht, z.B. durch laufende Umfeldanalysen zu erkennen, ob die Nutzenerwartung, die mit dem Projekt verbunden ist, weiterhin erfüllt werden kann. Typischerweise treten Projektrisiken in folgenden Kategorien auf: Risikoart Beispiele kaufmännische Risiken • Zahlungsschwierigkeiten des Auftraggebers während der Projektabwicklung. • Vertrag widerspricht sich in einzelnen Punkten, GU kann wg. Liquiditätsengpässen nicht liefern. technische Risiken • Rechnerkapazität reicht für das Projekt nicht aus. • Leitungsunterbrechung wg. Baggerarbeiten in der Nachbarstraße Terminrisiken • Hardware für die Büros kann wg. Stau im Suezkanal nicht geliefert werden. • Die Ausstattung für die IT-Arbeitsplätze wird geändert, die neue Planung kommt erst 2 Wochen später. Ressourcenrisiken • Ausgewählte Mitarbeiter stehen wg. Krankheit plötzlich nicht zur Verfügung. • Einzelne Mitglieder im Projekt-Team werden zu einem anderen Projekt berufen. „politische“ Risiken • Entscheidung für einen problematischen Zulieferer wegen persönlichem Kontakt. 4.3.2 Der Regelkreis des Risikomanagements Wie in allen Projektmanagement-Disziplinen sollte das Risikomanagement auch dem üblichen Regelkreis, bestehend aus Identifikation → Bewertung → Behandlung und → Controlling der Risiken folgen. Ausgangsbasis ist dabei die zuvor definierte Risikostrategie., mit der die grundlegenden Rahmenbedingungen, Zuständigkeiten, Prozesse und Methoden festgelegt werden. <?page no="172"?> 172 Takt 4: Projektsteuerung Abbildung 171: Regelkreis des Risikomanagements 90 Vorgehen bei der Risikoidentifikation und -bewertung 1. Sammlung und Gruppierung von Risiken 2. Klassifizierung von Risiken „Eintritts-… …-wahrscheinlichkeit“: hoch - mittel - gering …-auswirkung“: gering - gravierend - existenziell 3. Handhabung von Risiken „Eintritts-… …-auslöser“ (qualifiziert): Welche Ursache hat das Eintreten des Risikos? …-folgen“ (qualifiziert): Welche negativen Folgen hat das Eintreten des Risikos? …-indikatoren“: Woran erkennt man (frühzeitig), dass das Risiko eintritt/ eingetreten ist? …-verhinderung“: Welche Maßnahmen sind (wann und durch wen) zu ergreifen, damit sich die Eintrittswahrscheinlichkeit verringert? Dabei kann ein Erfassungs- und Bewertungs-Template wie das folgende zum Einsatz kommen: 90 RiskNET, o.J., leicht modifiziert Risiko: Wahrscheinlichkeit: hoch - mittel - gering Auswirkung: gering - gravierend - existenziell Auslöser: Welche Ursache hat das Eintreten des Risikos? Folgen: Welche negativen Folgen hat das Eintreten des Risikos? <?page no="173"?> 4.3 Risikomanagement 173 Abbildung 172: Risiko-Template Der Risikowert berechnet sich dann wie folgt: Risikowert = Eintrittswahrscheinlichkeit • Auswirkung … d.h. der Erwartungswert eines Risikos Die Erfassung aller Risiken sollte schlussendlich in einem Risikoregister erfolgen, wie beispielhaft hier abgebildet: Abbildung 173: Risikoregister ▲ Frage: Ist das eingetragene Risiko wirklich eines? Aus dem Risikoregister lässt sich toolunterstützt das Risikoportfolio ableiten, das die Risikosituation im Projekt visualisiert: Abbildung 174: Risikoportfolio ‒ Beispiel A B C B C D C D E - Auswirkung - gering gravierend existenziell gering mittel hoch Mangelnde Verfügbarkeit personeller Ressourcen Schlechte Steuerbarkeit/ Zielerreichung der AP/ B-Teams Mangelnde Lösungskompetenz Strittige Aufgabenverteilung zwischen AN & AG Mangelnde Mitwirkung/ Unterstützung/ Einführungsbereitschaft der Projektbehörden Ressourcen-Engpässe für Schulungen Zuständigkeit Datenmigration unklar Strittige Positionen im PÄ- oder CR-Management Mangelnde Rollout-Fähigkeit/ -Akzeptanz des Systems Probleme mit Datenmigrations- Werkzeug/ -Regelwerk Mangelnde fachliche Abstimmung Keine Termin- und Bedarfsgerechte Bereitstellung der Schnittstelle zum Abrechnungssystem Inadäquater Projektstrukturplan Mangelnde(r) Übertragbarkeit/ Bestand der organisatorischen Konzepte Äußere technische Anforderungen - Eintrittswahrscheinlichkeit - Indikatoren: Woran erkennt man, dass das Risiko eintritt/ eingetreten ist? Maßnahmen: Welche Maßnahmen sind (wann und durch wen) zu ergreifen, damit die Eintrittswahrscheinlichkeit sich verringert? <?page no="174"?> 174 Takt 4: Projektsteuerung Hier sind bereits beispielhaft Risiken aus einem realen Software-Einführungsprojekt eingetragen. Die Felder klassifizieren in dem Portfolio die „Gefahrenklasse“. „A“-Risiken sind demzufolge aufgrund ihrer hohen Eintrittswahrscheinlichkeit und ihrer für das Projekt existenziellen Auswirkung unbedingt zu behandeln. „E“-Risiken, deren Eintritt sehr unwahrscheinlich ist und - falls sie eintreten - die Auswirkung auch gering, können im Allgemeinen vernachlässigt bzw. in Kauf genommen werden. ▼ Tool [Risikoregister] 4.3.3 Normstrategien Mit Einordnung in das Risikoportfolio können und müssen entsprechende Maßnahmen identifiziert werden, mit denen den Risiken begegnet wird: Abbildung 175: Projektrisikomanagement - Strategien Die beispielhaften Maßnahmen beschreiben plakativ den Umgang mit Risiken bei der Einrichtung eines Rechenzentrums und dem identifizierten Risiko eines Brandes. Ziel der Maßnahmen ist es, die Bewertung eines Risikos „von rechts oben nach links unten“ zu treiben, bis das Restrisiko schließlich akzeptierbar ist. Dazu haben sich eine Reihe von Normstrategien herausgebildet, wie sie im Folgenden dargestellt sind. Risikovermeidung Vorrangiges Ziel ist es, das Risiko erst gar nicht einzugehen. Falls ein Risiko sich abzeichnet, wird auf diese Anforderung oder diese Aufgabe verzichtet. Beispiele • Im Angebotscontrolling eines Software-Unternehmens wird festgestellt, dass die Entwicklungskosten zur Erfüllung des gewünschten Lastenhefts des Kunden nicht abzuschätzen sind. Von einem Angebot wird abgesehen. A B C B C D C D E (“Rauchen verbieten”) Auswirkung reduzieren („Versicherung abschließen“) Eintreten vermeiden Auswirkung reduzieren (“Feuerlöscher installieren”) gering mittel hoch - Eintrittswahrscheinlichkeit - - Auswirkung - gering gravierend existenziell <?page no="175"?> 4.3 Risikomanagement 175 • In einem erdbebengefährdeten Gebiet soll ein Kraftwerk gebaut werden. Es gibt keine Versicherung auf dem Markt, die ein solches Risiko versichert. Die Kosten und das Risiko sind nicht abzusehen. ▲ Finden Sie andere Beispiele aus Ihrer Unternehmensrealität, bei der diese Strategie sinnvoll ist? Risikoverminderung Die Eintrittswahrscheinlichkeit eines Risikos soll gesenkt werden. Beispiel Das Risiko einer starken Budgetübertretung kann durch engmaschigere Kontrollen verringert werden. ▲ Finden Sie andere Beispiele aus Ihrer Unternehmensrealität, bei der diese Strategie sinnvoll ist? Risikobegrenzung Hier soll die Höhe des Schadensfalls begrenzt werden. Beispiel Der Ausfall des Rechenzentrums durch Stromausfall, verursacht durch eine nahe gelegene Baustelle in der Nähe des Hauptstromversorgungskabels, wird durch die Besorgung eines Stromaggregates verhindert. ▲ Finden Sie andere Beispiele aus Ihrer Unternehmensrealität, bei der diese Strategie sinnvoll ist? Risikoverlagerung Hier geht es darum, mögliche Risiken auf andere Institutionen, wie z.B. Versicherungen oder den GU zu übertragen. Beispiel Im Vertrag wird verhandelt, dass der GU eine Vertragserfüllungsbürgschaft bringen muss. ▲ Finden Sie andere Beispiele aus Ihrer Unternehmensrealität, bei der diese Strategie sinnvoll ist? Risikoakzeptanz Manche Risiken müssen auch einfach akzeptiert werden. Das sind Risiken mit einer geringen Eintrittswahrscheinlichkeit und einer niedrigen Schadenshöhe. <?page no="176"?> 176 Takt 4: Projektsteuerung Das Richtfest kann wegen schlechtem Wetter im August nicht wie geplant im Freien stattfinden. Es müssen kleine Sicherheitsvorkehrungen für die Besucher getroffen werden, die jetzt ins Gebäude kommen sollen. Kosten geschätzt: ca. 500,00 €. ▲ Finden Sie andere Beispiele aus Ihrer Unternehmensrealität, bei der diese Strategie sinnvoll ist? Das letzte Beispiel zeigt es auf: Generell sollten die Kosten für die Maßnahme zur Begegnung eines Risikos gegen die (monetär ausgedrückten) Risikowert abgewogen werden. ��� Achtung! Den Erwartungswert sollte man nur summarisch bei der Menge der Risiken als Maßstab nehmen. Bei einzelnen Risiken ist die Abwägung schwieriger, z.B. wenn es eine hohe (teure) Auswirkung gibt, aber nur eine kleine Eintrittswahrscheinlichkeit. (Dies ist im Übrigen der Anwendungsfall von Versicherungen.) Das systematische Risikomanagement ist eine Königsdisziplin des Projektmanagements! Projekte scheitern in der Regel oder erreichen nicht die ursprünglichen Ziele, weil Umstände eingetreten sind, die vorher nicht eingeplant waren. Dies steht im krassen Widerspruch zur in der Praxis oft zu beobachten Vernachlässigung des Risikomanagements. Risiken sind eben (zunächst) oftmals relativ abstrakt und die Befassung mit ihnen ist nicht ohne entsprechenden Aufwand zu leisten. 4.3.4 Lösungen ▲ Frage: Ist das eingetragene Risiko wirklich eines? Kein wirkliches Risiko → einplanbar als Randbedingung! 4.4 Projektcontrolling 4.4.1 Grundlagen Projektcontrolling bedeutet „beobachten und steuern”: • … beobachten im Sinne des Vergleichs von Soll und Ist, und • … steuern im Sinne von Definition und Kontrolle von abhelfenden Maßnahmen. Im folgenden Video ordne ich den Projekt-Controlling-Prozess einmal grundsätzlich in den Projektlebenszyklus ein. ▼ Video 4.5 (PCO-Prozess), URL: https: / / youtu.be/ t9Arck0E2HY Projektcontrolling basiert auf dem Vergleich einer Vielzahl von Projektparametern und unterstützt die aktuelle Projektauswertung als ein klar entscheidender Faktor des Managements. Benötigt wird ein Kontrollsystem, das Informationen als Basis für steuernde Maßnahmen bietet. Definitionen Projektcontrolling/ -steuerung DIN 69900-5: 2009: „Sicherstellung des Erreichens aller Projektziele durch Ist-Datenerfassung, Soll-Ist-Vergleich, Analyse der Abweichungen, Bewertung der Abweichungen gegebenenfalls mit Korrekturvorschlägen, Maßnahmenplanung, Steuerung der Durchführung von Maßnahmen.“ PRINCE2 (2009): Beispiel <?page no="177"?> 4.4 Projektcontrolling 177 „Zweck des Prozesses [Steuern einer Phase] ist es, die anfallenden Arbeiten zuzuweisen und zu verfolgen, offene Punkte zu bearbeiten, erzielte Fortschritte an den Lenkungsausschuss zu berichten und ggf. Korrekturmaßnahmen einzuleiten, damit die Phase innerhalb der Toleranzen bleibt.“ PMI: „Vergleich von aktuellen Leistungen mit geplanten Leistungen, Analyse von Abweichungen, zu bewertende Trends mit Wirkung auf Prozessverbesserungen, Bewertung möglicher Alternativen und Empfehlung geeigneter Hilfsmaßnahmen nach Bedarf.“ Hauptaufgabe Wirtschaftliche, organisatorische und informatorische Überwachung und Steuerung des Projekts. Das Projektcontrolling erfüllt insgesamt folgende Aufgaben: ► Unterstützung des Projektmanagers mit der Formulierung von Projektzielen und Erfolgskriterien. ► Entwicklung von KPIs zur Entdeckung von Varianzen und zur Kontrolle des Projekterfolgs. ► Implementieren von geeigneten Standards und Kreisläufen. ► Vergleich der Projektpläne hinsichtlich Leistung, Qualität, Zeitplan, Kosten mit den tatsächlichen Ergebnissen (Fortschritt vs. Zielvorgabe). ► Interpretation der Ergebnisse und die Durchführung von Hilfsmaßnahmen und Änderungen am Projektplan. ► Reporting/ Berichtswesen und angemessene Projektdokumentation. ► Verarbeitung und Bereitstellung von Erfahrungen (“Lessons learned”). Weitere Begriffe des Projekt-Controllings Plan-Werte Werte aus dem ursprünglichen Projektplan Ist-Werte Tatsächliche Werte am Stichtag Soll-Werte Neue Werte durch revidierte Planung am Stichtag (= aktualisierte Plan-Werte) Basisplan Der Basisplan dient als Vergleichsreferenz zu den während der Projektdurchführung ermittelten Ist-Werten und Soll-Werten Reporting-Verfahren … beinhaltet • Berichtspflichten Wer meldet welche Daten zu welchen Terminen? • Berichtswege An wen wird berichtet? Wer ist zu informieren? Welches Medium wird verwendet? • Berichtsform z.B. Standard-Formular Fortschrittsgrad Der Fortschrittsgrad (= Fertigstellungsgrad) ist das Verhältnis der zu einem Stichtag erbrachten Leistung zur Gesamtleistung eines Vorgangs oder eines Projekts <?page no="178"?> 178 Takt 4: Projektsteuerung Herausforderungen bei der Fortschrittsermittlung Verschiedene Faktoren können eine Aussage über den wirklichen Projektfortschritt erschweren: • Fehlende (Mengen)-Maßstäbe (z.B. Anlagenbau: technische Planung, F&E-Projekte) • Die technische Planung lässt sich nicht ohne Weiteres messen. • Ähnlich verhält es sich bei IT-Entwicklungsprojekten, die keine proportionalen Entwicklungsphasen haben. • Auch die Fortschrittsmessung von Organisationsprojekten ist nicht trivial. Beispiel Software-Entwicklung Wenn ein Projekt zum Ziel hat, ein Pflichtenheft zu erstellen, und zwei Entwickler diese Aufgabe übernommen haben, werden diese wahrscheinlich zuerst ein „Gerüst“ erstellen und die relativ einfachen Punkte bearbeiten. D.h. falls die Gesamtanzahl der Seiten auf 100 geschätzt wurde, sind z.B. die ersten 60 Seiten schon sehr schnell fertig. Die eigentliche Arbeit steht aber noch an. Eine Berechnung: „bereits vorliegende Seiten / geschätzte Gesamtzahl der Seiten“ ist hier sicher nicht geeignet. Ursachen für Abweichungen In Projekten kommt es regelmäßig zu Abweichungen vom Plan. Ursachen dafür können wie folgt klassifiziert werden: Planungsfehler  fehlende Planungserfahrung, Arbeiten wurden vergessen  falsche (zu optimistische) Aufwandsschätzung  Übernahme des Zeit- und Kostendrucks des Auftraggebers in die Planung  Komplexität überfordert Mitarbeiter, … Unvorhersehbares im Projektverlauf  neue Anforderungen im Projektverlauf  technische, personelle oder organisatorische Probleme  Ausscheiden von Mitarbeitern  Konkurs eines Lieferanten, … Ausführungsfehler  Fehler bei der Planausführung  fehlende Mitarbeiter-Qualifikation  es wurden unnötige Arbeiten gemacht, … ▲ Fallen Ihnen weitere Aspekte ein? <?page no="179"?> 4.4 Projektcontrolling 179 Terminüberschreitung sind wohl die häufigste Art der Abweichung vom Plan in Projekten. Folgende Ursachen können dafür typischerweise identifiziert werden: • Liefertermine von Fremdfirmen nicht eingehalten. • Zusätzliche ungeplante Arbeiten notwendig. • Änderungen der Projektziele durch den Auftraggeber. • Zu optimistische Schätzung in der Planung. • Verspätetes Eintreffen von notwendigen Daten/ Entscheidungen. • … Wir lernen im weiteren Verlauf dieses Abschnitts professionelle Methoden zur Beurteilung des Projektfortschritts kennen, die nicht zuletzt auch dazu dienen sollen., möglichst frühzeitig einer Fehlentwicklung entgegenwirken zu können. Allerdings macht es viel Sinn, im Projekt „vor den Ball zu kommen“, d.h. nach Möglichkeit bereits bei ersten Anzeichen einer Fehlentwicklung sensibel reagieren zu können: Frühwarnindikatoren sind hierbei wichtige Anzeichen für den „Turnaround“ eines Projekts − oftmals wichtiger als die (scheinbar) präzise Fortschrittskontrolle. Sie werden bewusst nicht unter den üblichen Disziplinen des Projektmanagements wie Leistung, Kosten, Zeit zusammengefasst − weil sie den Blick auf die sozialen Aspekte eines Projekts lenken. Typische Frühwarnindikatoren sind: Abbildung 176: Frühwarnindikatoren Kulturelle Veränderung  Projektmitarbeiter wollen sich als Helden beweisen und stecken sich und anderen deshalb überzogene, ehrgeizige Ziele, die definitiv nicht eingehalten werden können.  Projektmitarbeiter arbeiten nicht mehr sachbezogen, sondern die eigene Profilierung hat höchste Priorität. Teamleiter ignorieren Hilfegesuche ihrer Mitarbeiter.  Ein realistisches Budget wurde geplant und genehmigt, dieses wird dann aber zusammengestrichen, weil „es ja auch einfacher gehen muss“.  Das Projekt startet schwach und lässt dann stark nach, sprich: die Motivation der Mitarbeiter lässt von Beginn an zu wünschen übrig und wird im Projektverlauf eher noch geringer.  Fehler werden vertuscht oder schöngeredet; Notlügen gelten als das Mittel der Wahl.  Eine offene Fehlerdiskussion im Projekt oder mit den Stakeholdern ist nicht mehr möglich. Zieldiskussion  Scope-Diskussionen wiederholen sich. Anforderungen werden häufig geändert („Scope- Creep“).  Erweiterung der Ziele des Projekts, während der Endtermin unverändert bestehen bleibt. <?page no="180"?> 180 Takt 4: Projektsteuerung  Unkontrollierte Zunahme der Anzahl der am Projekt beteiligten Personen, zumindest aus Sicht eines Projektmitarbeiters.  Generelle Zunahme der Komplexität, weil zu viele Projekte gleichzeitig laufen; dadurch mehr Abhängigkeiten und Wechselwirkungen, die niemand mehr unter Kontrolle hat.  Zunehmende Aufgabe beziehungsweise zunehmendes Nichteinhalten von Strukturen und Methoden.  Ausfall von Meetings oder Teilnahme von weniger Mitarbeitern als bislang. Konflikte  Abnahme der teaminternen Kommunikation oder der Kommunikation mit dem Projektumfeld beziehungsweise Nichteinhaltung von vereinbarten Kommunikationsregeln.  Zunahme von Konflikten zwischen Mitarbeitern, Stakeholdern, im gesamten Projektumfeld sowie zwischen Linie und Projekt. Zunahme des „Flurfunks“, der immer mehr Zeit in Anspruch nimmt. Erhöhter Druck  Zunahme des Drucks von außen auf das Projekt, etwa durch ungeduldige Stakeholder oder Kunden; alle am Projekt Beteiligten registrieren diese Angespanntheit von außen.  Abnahme des Vertrauens in das Projekt: Anzahl der sogenannten „Deep Dives“ (detaillierte Darstellung und Hinterfragung von Sachverhalten) steigt, bis sich diese irgendwann zu „Deeper Dives“ und schließlich zu „Deeper Dive Review“ steigern.  Plötzliches Hinterfragen von Dingen; mögliche Folgen: Reviews, Audits oder langatmige und endlose Gespräche mit den Stakeholdern. Steigende Anzahl von Beschwerden, zum Beispiel über Liefereinheiten oder Kommunikation im Projekt.  Unangemessene und unnötige Eskalationen.  Projektmitarbeiter stehlen sich durch einfaches Informieren aus der Verantwortung („Melden macht frei “). Faktenlage  Die Umsetzung hinkt dem Zeitplan hinterher.  Verbrauch von zu viel Budget ohne entsprechenden Ergebnisfortschritt. Meilensteine werden nicht eingehalten.  Leicht zu messende Projektkennzahlen laufen aus dem Ruder (zum Beispiel Earned Value, Actual Cost, Planned Value, siehe unten). Verringertes Commitment  Änderung der Strategie ohne angemessenes Aufgreifen der Rückwirkungen auf das Projekt. Beispiel : Auswechslung des Managements.  Bestimmte Stakeholder wie etwa Sponsoren oder Dienstleister sind von der Sinnhaftigkeit des Projekts nicht mehr so überzeugt wie noch zu Beginn.  Stakeholder erscheinen nicht mehr zu den Meetings, und wenn, geben sie sich uninteressiert. Stakeholder sind grundsätzlich nicht mehr präsent.  Abzug von Ressourcen aus dem Projekt und Budgetkürzungen.  Umgesetzte Aktivitäten dienen der eigenen Absicherung. <?page no="181"?> 4.4 Projektcontrolling 181 Verschlechterte Mitarbeiterbeteiligung  Zunahme der Fluktuation aus dem Projekt und dadurch Instabilität des Umfelds.  Klagen über zu hohe Arbeitslast in Form von Überstunden oder Wochenendschichten.  Hoher oder niedriger Krankenstand, weil Kranke aus Angst, ihre Stelle zu verlieren, trotzdem arbeiten, sich die Zahl der Burnout-Fälle häuft und Projektmitarbeiter über längere Zeit krank sind.  Eingeplante Ressourcen stehen nicht zur Verfügung; Mitarbeiter arbeiten plötzlich lieber in anderen Projekten mit.  Projektmitarbeiter arbeiten nicht mehr in ihrer ursprünglichen Rolle; sie übernehmen ohne geordnete Neuplanung verstärkt Aufgaben, für die sie ursprünglich nicht vorgesehen waren.  Zunehmende Überbuchung von Schlüsselpersonen; alle Aktivitäten konzentrieren sich nur noch auf sie. Veränderte Erwartungen  Abnahme der Qualität der gelieferten Ergebnisse.  Geplante Lösungen funktionieren trotz guter Vorbereitung und Entwicklung nicht.  Immer häufiger werden Dinge an wichtigen Schnittstellen in unfertigem Zustand übergeben.  Kunde ist mit den Ergebnissen nicht zufrieden; egal, ob seine Ansprüche über die Zeit gewachsen sind oder ob die Lieferqualität tatsächlich schlechter geworden ist.  Informationen von Stakeholdern kommen im Team nicht mehr an; Mitarbeiter in einer Querschnittsrolle oder einem Teilprojekt fühlen sich nicht mehr ausreichend informiert. ��� Achten Sie in Ihren Projekten auf diese Frühwarnindikatoren! Je früher Fehlentwicklungen aufgegriffen und behoben werden, desto geringer ist deren Auswirkung. Doch kommen wir jetzt einmal zu den „harten“ Instrumenten des Projektcontrollings. Die DIN 69 901-3 liefert folgende Übersicht über die Instrumente und Methoden, auf die wir im Folgenden - mehr oder weniger tiefgehend - eingehen werden. 91 Abbildung 177: Instrumente des Projekt-Controllings 91 siehe Schlick, 2015 <?page no="182"?> 182 Takt 4: Projektsteuerung Beginnen wir mit dem … 4.4.2 Plan-Ist-Vergleich Eine einfache Form des Plan-Ist-Vergleichs lässt sich „Bordmitteln“ wie Excel & Co. realisieren. Dazu folgendes Beispiel aus dem IT-Infrastrukturprojekt, das uns schon eine Weile begleitet: 92 Abbildung 178: Plan-Ist-Vergleich ‒ Beispiel Schauen wir uns das einmal ein wenig systematischer an. Es lassen sich typischerweise vier Vergleichsformen unterscheiden: 93 Abbildung 179: Plan-Ist-Vergleich − Vergleichsformen 92 Wehnes, 2014 93 siehe Zimmermann et al., 2010, nach Schlick, 2015 <?page no="183"?> 4.4 Projektcontrolling 183 Die Vergleichsverfahren sind also unterschiedlich aufwändig und haben eine unterschiedliche Aussagekraft. Welches Sie letztlich in Ihren Projekten einsetzen sollten, hängt von Faktoren wie Laufzeit und Komplexität des Projektes ab. Werden Abweichungen des Ist-Zustands vom Plan festgestellt, werden Steuerungsmaßnahmen notwendig - korrektiv oder reaktiv: korrektive Steuerungsmaßnahmen Anpassung des Istan den Soll-Zustand (→ Korrekturmaßnahmen) reaktive Steuerungsmaßnahmen Anpassung des Sollan den Ist-Zustand (→ Planänderung) Personalkapazität • Mehrstunden: Überstunden, Wochenendarbeiten Produktivität • verbesserter Tool- und Methodeneinsatz • Information, Motivation Dauer der Arbeitspakete am kritischen Pfad kürzen • Überlappungen vorsehen, Abhängigkeiten eliminieren • Rationalisierungspotenzial nutzen konsequente Aktualisierung der Plantermine • Beginn- und Endtermin, Vorgangsdauer, Abhängigkeiten Outsourcing von Teilaufgaben Projektumfang/ Funktionalität/ Qualität • Reduzieren, Versionsbildung, Änderung von Prioritäten Ressourcenerweiterung und Budgetaufstockung ��� Vorsicht … es gilt Brooks Law: “Adding manpower to a late project … makes it later! ” 4.4.3 Der Statusbericht Dem Berichtswesen kommt im Projekt eine durchaus wesentliche Aufgabe im Rahmen der Projektsteuerung zu. Was auf den ersten Blick ganz einfach erscheint, offenbart nicht selten im Projektalltag ein paar wesentliche Lücken. Schauen Sie selbst: ► Video 4.6 (Statusbericht), URL: https: / / youtu.be/ 72ju9yKr48U Fragt man die Projektmitglieder informell, so bekommt man nicht selten recht unspezifische Aussagen, wie z.B. 94 typische Aussagen wahrheitsgemäße Übersetzung Es ist geplant, mit der Arbeit zu beginnen. Es ist zu früh, um sagen zu können, wann die Arbeit begonnen werden kann. Die Arbeit begann am … Einige Mitarbeiter kontierten auf das Projekt ab … Die Lieferung des letzten Teils ist geplant für… Es ist unmöglich, fertig zu werden vor dem … 94 Schelle et al., 2008 <?page no="184"?> 184 Takt 4: Projektsteuerung Die Lieferung steht kurz bevor. Es ist immer noch nicht so weit. Die Arbeit war fertig. Die Ergebnisse machen aber weitere Untersuchungen erforderlich. Es hat nicht funktioniert. Abbildung 180: Projektfortschrittsprosa Das möchte man natürlich vermeiden! Zur Kommunikation des Sachstands kommen daher - hoffentlich nicht nur - formalisierte Statusberichte zu Einsatz. Definition Statusbericht „Bericht, in dem die Projektleitung den Auftraggeber/ Lenkungsausschuss bzw. der Arbeitspaket- oder Teilprojektverantwortliche die Projektleitung in festgelegten regelmäßigen Abständen über die in einer Berichtsperiode erzielten Fortschritte unterrichtet (Projektbzw. Teamstatusbericht). Inhalt ist insbesondere der Fortschritt und Sachstand mit Blick auf Termine, Budgeteinhaltung, Umfang und Qualität. Ferner werden aktuelle Risiken bzw. deren Entwicklung und Entscheidungsbedarfe adressiert.“ (PRINCE2) Dabei sollen formalisierte Meldungen zum Fortschritt des Projekts bzw. der Arbeitspakete zum Tragen kommen, z.B. zum AP-Status: • „noch nicht begonnen, in Arbeit, abgeschlossen, abgenommen“, • „erwarteter Fertigstellungstermin“, • „Restaufwand“, … Üblich für die Erfassung von Statusinformationen sind sogenannte One Pager, wie in der folgenden Abbildung gezeigt: Abbildung 181: Projektstatusbericht ‒ Template <?page no="185"?> 4.4 Projektcontrolling 185 Dabei kommen vielfach einfache Office-Anwendungen zum Einsatz, aber natürlich auch integrierte, datenbankbasierte Tools. Wichtig ist, dass die Information kompakt, strukturiert und übersichtlich erfolgt. Die im beispielhaften Status-One-Pager aufgeführten Felder dienen stets zur Beschreibung, was seit dem letzten Statusbericht geschehen ist und was bis zum nächsten geschehen wird. Es empfiehlt sich, auch eine Trendinformation mitzugeben, um Interventionen gezielter gestalten zu können. ��� Der Statusbericht ist nicht nur ein Bericht „von unten nach oben“, sondern dient auch zur Anforderung von Entscheidungen! Eine weit verbreitete, managementtaugliche Angabe des Projektstatus, wie auch im Beispiel- Template zu erkennen, ist die Projektampel. Sie ist intuitiv, aber eine sinnvolle Anwendung erfordert eine semantische Vereinbarung der Ampelfarben. Ansonsten besteht die Gefahr der Verwässerung (à la „grün + rot = gelb“) oder der individuellen, persönlichkeitsbezogenen Interpretation (was vielleicht schon rot ist, sieht nicht jeder Projektteilnehmer automatisch gleich - es gibt eben vorsichtigere und forschere Typen etc.) Folgende Semantik der Ampel hat sich bewährt: Abbildung 182: Die Projektampel Auch bei einer klareren Definition der Statusinformation bleibt es aber dabei: ��� Ein formaler Bericht ersetzt nicht die persönliche Statuskommunikation. Systematisch geplante Projektbesprechungen dienen zur Sicherstellung der Kommunikation bezüglich. des Projektstatus: … zum direkten Informationsaustausch, … als Grundlage einer gezielten Projektsteuerung - insbesondere bei Schwierigkeiten. Folgende Auslöser lassen sich dabei unterscheiden: <?page no="186"?> 186 Takt 4: Projektsteuerung Abbildung 183: Statuskommunikation Regelmäßige Projektbesprechungen Die Erstellung von Statusberichten muss mit entsprechenden persönlichen Statusbesprechungen synchronisiert sein. Ziel ist die Ermittlung des Projektstatus in Kernteam-Meetings bzw. Teilprojekt-Meetings. Sie erfolgen regelmäßig, z.B. als wöchentlicher, 14-tägiger oder monatlicher Jour fixe. Hauptaufgaben sind: • Projektstatus feststellen • Diskussion von Problemen („problem of the day“) • Informationen austauschen • Planabweichungen (Termine, Kosten, Aufwand) besprechen • erforderliche Steuerungsmaßnahmen ausarbeiten • Teamgeist fördern und Motivation steigern • Stakeholder-, Risiko-, Kommunikations- und Qualitätsmanagement • Vorbereitung von Lenkungsausschuss-Sitzungen und Projekt-Events Mit Blick auf die Strukturen im Projekt ergibt sich eine Kaskade der Kommunikation, etwa wie folgt: Phasenbezogen z.B. 14-tägig z.B. wöchentlich Lenkungsausschuss Projekt (-leitung) Teilprojekt (-leitung) Arbeitspaket (-verantwortung) Sitzung LA PL Jour Fixe Teambesprechung • Entscheidungsbedarfe mit Projektauftragsbezug • Gesamtstatus • Strategische Risiken • Entscheidungsbedarfe mit Gesamtprojektbezug • Teilprojektstatus • Risikobehandlung • Entscheidungsbedarfe • AP-Aktivitäten und -Status • operative Risiken Bericht Auftraggeber Protokoll Protokoll Statusbericht Register offener Punkte Register offener Punkte Abbildung 184: Meeting-Struktur und Statuskommunikation <?page no="187"?> 4.4 Projektcontrolling 187 Deren Rhythmus bzw. Häufigkeit sollte nicht zuletzt von der Projektdauer abhängen. Empfohlene Monitoring-Zyklen sind z.B. für den PL Jour fixe: Projektdauer: < 6 Monate 7−24 Monate Zyklus: wöchentlich 14-tägig Zumeist mit etwas höherer Frequenz in der Startphase und vor Produktivstart. Ergebnisgesteuerte Projektbesprechungen Diese sind ergänzend zu den Regeltreffen wie folgt einzuordnen: Ziel Treffen von Entscheidungen Teilnehmer Lenkungsausschuss, PL, Controller Zeitpunkt Wichtige Ergebnisse liegen vor bzw. sollten gemäß Planung vorliegen und sind abzunehmen. Beispiele • Abnahme von Meilensteinen • Freigabe der Folgephase • Unterbrechung des Projektes • Abnahme der Ergebnisse • Beendigung des Projekts Alle zur Entscheidung anstehenden Punkte werden dabei in Beschlussvorlagen zusammengefasst. Sitzungsergebnis: Entscheidung über das weitere Vorgehen im Projekt („Go! “ / „no Go! “). Ereignisgesteuerte Projektbesprechungen Diese sind schließlich wie folgt charakterisiert: Ziel Lösung von großen, unvorhergesehenen Problemen Teilnehmer Zusammensetzung nach Art des Ereignisses • Bei Krisensituationen: Projektleitung, Kernteam, Auftraggeber, Lenkungsausschuss. • Meistens: Spezialistenteam, auch Nicht-Projektteammitarbeiter, zur schnellen bzw. nachhaltigen Lösung des Problems. Zeitpunkt im Bedarfsfall Beispiele • Projektkrisen • plötzlich geänderte Rahmenbedingungen (z.B. Gesetzesänderung, Marktereignis) • erhebliche Personalprobleme (z.B. Ausscheiden des PLs) • erhebliche Planungsabweichungen (Zeit, Kosten, Ergebnis) • erhebliche Liefer- und Bestellprobleme • schwierige entwicklungstechnische Sachprobleme 4.4.4 Fortschrittsfeststellung Ziel des Statusberichtswesens ist insbesondere ein effektives Fortschritts-Controlling mit … • realistischer, objektivierbarer Sachstandsfeststellung, • Ermöglichung einer Prognosefähigkeit, <?page no="188"?> 188 Takt 4: Projektsteuerung • Erkennung von notwendigen „Eingreifpunkten“ durch die nächsthöhere Projektinstanz. Daraus ergibt sich die Ableitung folgender Prinzipien: • Anwendung einer zielführenden Bewertungs-Systematik mit klaren Fortschrittsangaben und aussagekräftigen Kennzahlen, • Fokussierung auf Lieferobjekte (Produkte & Zwischenprodukte), • Vermeidung von subjektiven Aussagen und „verwässernden“ Aggregationen durch Nutzung eines Status-„Dashboard“ (Cockpit) sowie berechnete Gesamtstatus-Aussagen mit Hilfe einer Scorecard (Gewichtung der einzelnen Dimensionen wie Zeit, Qualität, Kosten, Risiko). Die Berechnung des Fertigstellungsgrads kann Tücken aufweisen. Lassen Sie uns das einmal an Beispielen verdeutlichen: Beispiel 1 geplante Kosten A plan : 3,6 Mio.€ bislang angefallener Aufwand A ist : 1,2 Mio.€ 1. geschätzter Fertigstellungsgrad FGR : 40% 2. revidierter Fertigstellungsgrad FGR : 20% Formel: A soll ≔ A plan x FGR ▲ Berechnen Sie doch zunächst einmal selbst A ist und A soll für 1. und 2. Berechnung für 1. 3,6 Mio.€ x 40% = 1,44 Mio. € → A ist < A soll Berechnung für 2. 3,6 Mio.€ x 20% = 0,72 Mio. € → A ist > A soll Wir kommen also zu völlig unterschiedlichen Aussagen! Anstatt den Fertigstellungsgrad des AP in % abzuschätzen, fragt man besser: Wie viel Aufwand ist noch zur Fertigstellung notwendig? Der Fertigstellungsgrad errechnet sich dann aus der Formel Zur Anwendung Beispiel 2 geplanter Aufwand: 10 Tsd. € Istaufwand: 4 Tsd. € geschätzter Restaufwand: 8 Tsd. € → FGR = 4 / (4 + 8)*100 = 33% Folgende weitere Arten der Bestimmung des Fertigstellungsgrads sind in der Praxis vorzufinden: 𝐹𝐹𝐹𝐹𝐹𝐹 = 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 𝐴𝐴 𝑖𝑖𝑖𝑖𝑖𝑖 𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 𝐴𝐴 𝑖𝑖𝑖𝑖𝑖𝑖 + 𝐹𝐹𝑅𝑅𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 𝐴𝐴 𝑟𝑟𝑟𝑟𝑖𝑖𝑖𝑖 <?page no="189"?> 4.4 Projektcontrolling 189 „Percent Complete Estimate“ (Proportionale Schätzung) • Der jeweilige Fertigstellungsgrad für ein Arbeitspaket wird in Form eines Anteils von Gesamtlieferumfang bewertet. • Die Schätzung unterliegt den (subjektiven) Annahmen des Schätzers. • Für lang andauernde Arbeitspakete mit relativ großer Unsicherheit behaftet. „0/ 100-Ansatz“ • Der Fertigstellungsgrad von Arbeitspaketen wird entweder mit 0 oder 100% der vollständigen Leistung bewertet. • Die Aussagekraft dieser konservativen Schätzmethode auf das Gesamtprojekt wird durch einen feingranularen PSP mit vielen Arbeitspaketen verbessert. • Die Methode ist besonders geeignet für Projekte mit Arbeitspaketen von kurzer Dauer. „Fixed Formular“ (Feste Formel) • Zum Berichtszeitpunkt wird dem Fertigstellungsgrad ein definierter Prozentsatz entsprechend eines erreichten Status zugewiesen. Der Rest erst bei Fertigstellung. • Eine detaillierter PSP ist Voraussetzung für eine erfolgreiche Anwendung der Methode. • Die Dauer der AP sollte die Länge des Betrachtungszeitraum nicht überschreiten. „Weighted Milestones“ (Meilensteinbewertungstechnik) • Diese Methode verlangt nach einer feingranularen PSP, ergänzt um eine Planung von „Mikromeilensteinen“ zur Bewertung lang andauernder und über den Betrachtungszeitpunkt hinausgehender Arbeitspakete. • Diese Methode ermöglicht das Aufdecken von ungünstigen Kosten- und Termintrends am Ende des Betrachtungszeitraums. Abbildung 185: Bestimmung des Fertigstellungsgrads Schauen wir uns das Fortschrittsschema „Fixed Formular“ einmal in einer möglichen Ausgestaltung im Projekt an. Die Festlegung von Bearbeitungsstufen vereinheitlicht dabei die Statusangaben - einerseits für zu erarbeitende Dokumente, andererseits für technische Produkte, also etwa Software-Applikationen: <?page no="190"?> 190 Takt 4: Projektsteuerung Abbildung 186: Fortschrittsschema „Fixed Formular“ ‒ Beispiel Dokumente Mit folgender Spezifikation der Stufen mit Blick auf Fachkonzepte: Abbildung 187: Fortschrittsschema „Fixed Formular“ ‒ Beispiel Fachkonzept Und mit folgender Spezifikation der Stufen mit Blick auf (IT-)Produkte: Abbildung 188: Fortschrittsschema „Fixed Formular“ ‒ Beispiel (IT-) Produkte <?page no="191"?> 4.4 Projektcontrolling 191 Die Schemata sind ggf. je nach Dokumentenbzw. Produktart auszugestalten. Die folgende Übersicht zeigt noch einmal die Methoden in der Zusammenfassung und ergänzt weitere typische, eingängige Proportionalitätsverfahren: 95 FGR: Fertigstellungsgrad Abbildung 189: Verfahren und ihre Anwendung Wenden wir uns nun einmal den Königsdisziplinen des Projektcontrollings zu - der Meilenstein- Trendanalyse (MTA) sowie der Earned Value Analyse (EVA). Vor dem Hintergrund der Positionierung und Ausrichtung des vorliegenden Moduls schauen wir aber „nur kurz vorbei“, damit ein grundsätzliches Verständnis für dies professionellen und wirksamen Methoden entsteht. 4.4.5 Earned Value Analyse Reicht es aus, im Projekt den Fortschritt festzustellen, um das Projekt ausreichend zu steuern? Schauen Sie sich einmal folgende Überlegungen an. ► Video 4.7 (Zeit-Aufwand-Kurve), URL: https: / / youtu.be/ FVzgnB4MQLo Die Earned Value Analyse (EVA) ist eine Technik zur Messung und Vorhersage des Fortschritts eines Projekts. Sie ist eine Methodik zum integrierten Management von Projektumfang, -zeitplan und -kosten (dt. Leistungs-/ Arbeitswert-Analyse) und stellt dem geplanten Fortschritt (Planned Value) den tatsächlichen Aufwand (Actual Costs) sowie den erreichten Leistungswert (Earned Value) gegenüber. 95 GPM, 2012 <?page no="192"?> 192 Takt 4: Projektsteuerung Damit ermöglicht die EVA über die Ableitung von Kennzahlen Aussagen zur Performance des Projekts sowie Prognosen mit Blick auf den Fertigstellungszeitpunkt. Dabei stehen in der klassischen EVA der Aufwand und die Kosten des Projekts als planerischer Maßstab im Vordergrund. Bei der EVA werden Ergebnisse inklusiv der angefallenen Kosten und der verstrichenen Zeit betrachtet. EVA liefert eine Bewertung des Projektfortschritts, aber nicht zuletzt auch Prognosedaten zum Projektverlauf. Kenngrößen der Earned Value Analyse Für ein bestimmtes Datum werden die folgenden drei Werte ermittelt: Planned Value (PV) • Die Kosten der budgetierten Leistung, die zum Analysezeitpunkt durchgeführt sein soll. • Dies ist der festgelegte Ausgangswert, gegen die der tatsächliche Fortschritt des Projekts gemessen wird. Der PV wird in der Regel so dargestellt, dass man kumuliert die budgetierten Mittel über den Projektplan erkennt: Abbildung 190: Earned Value Analyse ‒ Grundschema Actual Cost (AC) • Tatsächlich entstandene und erfasste Gesamtkosten der Arbeit bis zum Analysezeitpunkt. • AC ist ein Hinweis auf die Höhe der ausgegebenen Mittel zur Erreichung der tatsächlichen Leistung bis heute. • Die Kosten, die zum aktuellen Zeitpunkt tatsächlich angefallen sind. Und schließlich … Earned Value (EV) • Die Kosten, die für die zum aktuellen Zeitpunkt geleistete Arbeit budgetiert waren → die dem Fertigstellungsgrad entsprechenden Plankosten (Fertigstellungswert). • „Plan-Kosten für Ist-Leistung“. Setzt man diese Kenngrößen in Relation zueinander - beispielsweise den Earned Value zu den Actual Costs (EV / AC), so drücken diese Relativzahlen die Performance des Projektes zum betrachteten Zeitpunkt aus. Auf diese Weise lässt sich eine Prognose etwa der finalen Kosten (bei gleichbleibender Performance) machen. Dies ist die große Stärke der EVA. <?page no="193"?> 4.4 Projektcontrolling 193 Insgesamt lässt sich folgende Bewertung der EVA vornehmen: Vorteile Nachteile • Integrative Betrachtung von Leistungen und Kosten sowie eingeschränkt auch Terminen. • Transparenz über den tatsächlichen Leistungsfortschritt im Projekt. • Frühzeitiges Erkennen von (Kosten- & Termin-)Abweichungen. • Entscheidungsunterstützung bei der Steuerung von Projekten. • Valide Prognosen der Projektgesamtkosten zum Fertigstellungstermin bereits ab einem frühen Zeitpunkt bzw. geringem Fertigstellungsgrad möglich. • EVA ist gut für Großprojekte geeignet. • Die EVA wird teilweise als aufwändiges und bürokratisches Verfahren missverstanden. • Indikator für den Projektverlauf − aber kein unmittelbares Ableiten von Maßnahmen zur Verbesserung der Projektleistung möglich. • Uneindeutige Ansätze zur Ermittlung des Arbeitswerts (EV). Einsatzvoraussetzungen • Hoher Reifegrad des PM im Unternehmen. • Gründliche Planung der Arbeitspakete (AP). • Steuerbarkeit des Projektes über die AP. • Zeitnahe Erfassung von Ist-Kosten & Planänderungen. Die EVA ist ein nützliches Instrument im Projektcontrolling, jedoch ist ihre Verbreitung im Projektalltag von Organisationen vergleichsweise gering. Dies liegt offenbar an ihrer vermeintlichen Komplexität und sicher auch an der begrenzten Aussagekraft in bestimmten Projektkontexten. Wir haben die EVA daher im PPM-Labor der TH Mittelhessen zu einer „Integrierten EVA“ weiterentwickelt und die Anwendungsbereiche erweitert. 96 Drei Bereiche werden dabei adressiert: • die Anpassung der EVA für sachkostendominierte Projekte, • die Anwendung in agilen Projektvorgehensweisen … • und auf Projektportfolioebene. Um Kostenarten in der EVA sinnvoll einzusetzen, ist eine Differenzierung in verschiedene Kategorien erforderlich. Diese Unterscheidung erfolgt insbesondere zwischen sog. arbeitswertinduzierenden und arbeitswertneutralen Kosten. 1. Arbeitswertinduzierende Kosten (awi): Diese Kosten stehen in direkter Korrelation mit dem Projektfortschritt und sind für die klassische EVA relevant. Beispiele hierfür sind Personalkosten, Hilfs- und Betriebsstoffe sowie externe Kosten, die kontinuierlich nach Leistungserbringung abgerechnet werden. Diese Kostenarten können direkt dem Fortschritt eines Projekts zugeordnet werden und sind somit entscheidend für die Berechnung des Earned Value. 2. Arbeitswertneutrale Kosten (awn): Diese Kostenarten haben keinen direkten Bezug zum Projektfortschritt und sind für die klassische EVA nicht geeignet. Dazu zählen beispielsweise 96 s. Hüsselmann/ Hergenröder, 2024 <?page no="194"?> 194 Takt 4: Projektsteuerung Kosten für die Beschaffung von Hardware oder einmalige Zahlungen, die nicht in direktem Zusammenhang mit der Leistungserbringung stehen. Diese Kosten sollten separat ausgewiesen werden, um sprunghafte Anstiege der tatsächlichen Kosten (AC) in der EVA zu vermeiden. Die Differenzierung zwischen awi- und awn-Kosten ermöglicht eine präzisere Anwendung der EVA, da nur die awi-Kosten für die Berechnung des Earned Value und des Planned Value herangezogen werden sollten. Für die awn-Kosten ist eine separate Behandlung nach der sog. „Mitlaufenden Kalkulation“ erforderlich, um die Gesamtprojektkosten korrekt zu prognostizieren und zu steuern. Zusammenfassend ist die Unterscheidung der Kostenarten entscheidend, um die Aussagekraft der EVA zu erhöhen und eine fundierte Kostenprognose zu ermöglichen. Durch die neuartige Differenzierung von Kostenarten wird die EVA vielseitiger einsetzbar und auch die Integration typischer Metriken im agilen Vorgehen möglich. 4.4.6 Meilenstein-Trend-Analyse Die MTA dient zur Überwachung der Fälligkeit von Meilensteinen während des Projekts. Sie ist eine einfache Methode, Terminveränderungen auf Meilensteinebene während des Projektverlaufs zu visualisieren und zeigt Verzögerungen in einem frühen Stadium (Entwicklung von Trends) an. Ziele: • Schärfung des Terminbewusstseins für alle Projektmitarbeiter durch Aufzeigen der Terminsituation im Projekt. • Frühzeitiges Erkennen von Terminabweichungen. • Rechtzeitiges Einleiten von Gegenmaßnahmen. • Einfache grafische Darstellung des Termintrends mit Soll-/ Ist-Vergleich der definierten Meilensteine. Voraussetzung ist das Vorhandensein eines Meilensteinplans. Durch regelmäßige zeitgerechte Berichterstattung mittels einer MTA kann die wahrscheinliche Termintreue des Projektes schon relativ früh innerhalb des Gesamtverlaufes prognostiziert werden. So ist es möglich, späten Erkenntnissen - dem sog. „Late Awakening (s.u.) - noch rechtzeitig entgegenzuwirken. Eine Meilenstein-Trend-Analyse (MTA) überwacht die Änderungen der Meilenstein-Daten und visualisiert sie in einem Diagramm: Abbildung 191: Meilenstein-Trend-Analyse ‒ Grundschema <?page no="195"?> 4.4 Projektcontrolling 195 Die vertikale Achse repräsentiert den Planungszeitraum des Projekts. Die horizontale Achse des Dreiecksrasters repräsentiert den Berichtszeitraum mit einer identischen Zeitskala. Wenn Meilensteine aktualisiert werden, wird eine aktuelle Prognose der Fristen je nach Fortschreiten des Projekts erstellt. Wenn das gemeldete Meilenstein-Datum von dem ursprünglich geplanten Datum abweicht, dann verlässt das Polygon die horizontale Linie: • Horizontale Linie: Termin wird gehalten. • Steigende Linie: Frist an jedem Bilanzstichtag überschritten. • Fallende Linie: Meilenstein wird früher erreicht. Late Awakening-Effekt Das „Späte Erwachen“ ist ein typischer Effekt, der mit dem Einsatz der MTA vermieden werden kann. Dazu folgende beispielhafte Schaubild: Abbildung 192: Typische MTA-Kurven ‒ Beispiel „Spätes Erwachen“ Nach dem zweiten Berichtszeitpunkt zeigen die folgenden Meilensteine 4 - 7 keine Reaktion auf den Verzug! Zu prüfen: • Sind die Meilensteine wirklich unabhängig voneinander? • Sind die Puffer groß genug, um Verzögerungen zu kompensieren? • Berichtet der Projektmanager (Meilenstein 4) den aktuellen Status korrekt? • Hat der Projektmanager genügend Informationen über seine Aktivitäten? Weitere typische Trendverläufe - Alle Kurven zeigen geringe Terminverschiebungen (auf, ab): → Normalzustand. - Die Kurven der MS-Termine steigen alle stark an: → unrealistische, überoptimistische Einstellung zu Terminen (→ Lernen! ) <?page no="196"?> 196 Takt 4: Projektsteuerung - Die Kurven der MS-Termine verlaufen auffällig exakt wie geplant, jeweils vor Realisierung des MS steigt die Kurve steil an: → man stellt den Projektleiter ruhig („Wir machen das schon“), zum Ende lässt sich aber nichts mehr schönreden → verhindert die Möglichkeit rechtzeitiger korrigierender Eingriffe. - Die Kurven der MS-Termine fallen signifikant stark ab: → zu große Terminreserven eingeplant. - Die Kurven der MS-Termine oszillieren stark: → Indikator für große Unsicherheit bei den Terminaussagen in Erstschätzung und laufender Prognose. - Der MS-Trend steigt stark an (Terminverschiebung), ein davon abhängiger, nachfolgender MS zeigt hinsichtlich seines Termins einen waagerechten Trend: → geringes Verständnis für Vernetzung und Abhängigkeiten in Terminplänen → Gefahr des „Late Awakening“. Vorgehen zum Einsatz der MTA ► Zum Startzeitpunkt werden die geplanten Meilensteintermine eingezeichnet (Y-Achse). ► Zu jedem Berichtszeitpunkt (X-Achse) werden neue Schätzwerte für die Meilensteine ermittelt und in das Diagramm eingetragen. Zur MTA lässt sich folgende Bewertung abgeben: • MTA zeigt Warnungen, ist aber keine “Root Cause”-Analyse. • MTA ist wirkungsvoll in Kombination mit der Earned Value Analyse (EVA): Während die EVA den Zeitplan und die Kosten basierend auf der Leistung der vorangegangenen Projektfortschritte ermittelt, spiegelt die MTA die Schätzung der Beteiligten für die folgenden Projektphasen wider. ��� Für einen Marathonläufer sind wichtige Meilensteine farbig markiert, um ihn für den Rest der Strecke zu motivieren. Die Motivationswirkung gilt bei Projektmeilensteinen ebenso: Es motiviert, die wesentlichen Zwischenziele erreicht zu haben. 4.4.7 Open Issue Management Im Laufe eines Projektes entstehen kontinuierlich weitere operative To-Dos, Entscheidungsbedarfe oder Issues, die in keinem Plan der Welt à priori vorgesehen werden können. Für die operative Steuerung eines Projekts ist es kritisch, dass diese Dinge in der Offenen-Punkte-Verwaltung administriert werden. Die Elemente des Projekt-Scope sowie die dynamisch entstehenden offenen Punkte bilden dann im Verlauf des Projekts gemeinsam den Backlog der anstehenden Arbeiten. Die Verwaltung bzw. das Management der offenen Punkte („To-Dos“, „Issues“) eines Projektes stellt eine Indikation für die Ordnung des Projekts in Gänze dar: „Zeig mir die Offene-Punkte- Liste und ich sage dir den Zustand des Projektes! “. Insofern kommt dem eine wichtige Bedeutung im operativen Management des Projekts zu. Ein zentrales, für alle zugreifbare Register offener Punkte (RoP) ist daher unerlässlich. Darin werden die Punkte adressaten- und prioritätengerecht dokumentiert. Im Projektverlauf entwickelt sich das RoP dynamisch und ersetzt zunehmend den Projektplan (siehe Abbildung 193). Im RoP werden alle formell zu bearbeitenden offenen Punkte und Probleme erfasst und gepflegt. Die Projektleitung sollte dieses Register regelmäßig kontrollieren. Offene Punkte können sein: • „To-dos“ → (in der Regel kleinere) Aufgaben, die im Projektverlauf außerhalb der generellen Projektablaufplanung aufkommen und zu erledigen sind. <?page no="197"?> 4.4 Projektcontrolling 197 Abbildung 193: RoP und Projektplan bilden den Backlog • Entscheidungsbedarfe → (im Allgemeinen) Klärungsbedarfe, die zur weiteren Bearbeitung der operativen Aufgaben notwendig sind. • „Issues“ → eine grundlegende Aufgabe oder Herbeiführung einer Voraussetzung (z.B. auch Entscheidung), die zur weiteren Bearbeitung zumindest von Teilen des Projekts essenziell ist. Beispiel Abbildung 194: Register offener Punkte ‒ Beispiel Das RoP sollte ständiger Begleiter im Zuge der Projektsteuerung werden. So hat es sich insbesondere bewährt, handlungsfordernde Punkte aus Protokollen unmittelbar in das RoP zu übernehmen, um auf diese Weise die frist- und sachgerechte Abarbeitung zu überwachen. So können neben den reinen Termininformationen weitere steuernde Festlegungen aufgenommen werden, wie z.B. das zuständige Regel-Meeting: Abbildung 195: Erfolgsfaktor „Offene-Punkte-Verwaltung“ Datum Status Probleme Termin Wer Ursache/ Lösung 01.07.2025 erl SAM Workplace; immer wieder Probleme mit Aktiv-X-Komponente 15.07.2025 Alma. allgemeine Lösung funktioniert noch nicht 01.07.2025 erl tnsnames.ora (Miracle) musste von Hand nachgeschossen werden 15.07.2025 Alma. in check-csv aufnehmen 01.07.2025 erl Bei Hardwareaustausch durch IT-SZ (WAN) vorher Info an Migrationsteam 04.07.2025 Gst. Pointner informiert WAN- Team 01.07.2025 erl Englische Postfächer, auch bei nicht gesicherten Postfächern 15.07.2025 Hut / May 08.07.2025 erl Fire-Abonnement Hinweis in Checkliste aufnehmen 15.07.2025 Poi <?page no="198"?> 198 Takt 4: Projektsteuerung Die Positionen des RoP unterliegen somit (in jedem Projekt) einer fortlaufenden Fortschreibung und Priorisierung, die sich in die Systematik der Backlog-Priorisierung einpassen muss. Über die Zeit des Projekts werden mehr und mehr Positionen des ursprünglichen, scopebezogenen Backlogs abgearbeitet. Auf der anderen Seite kommen laufend neue offene Punkte hinzu, die es abzuarbeiten gilt. Am Ende des Projekts muss die Liste leer sein oder darf zumindest keine Positionen mehr enthalten, die abnahmebzw. betriebshinderlich sind. (Eine vollständig leere Liste offener Punkte ist wohl Utopie und wird in agilen Ansätzen auch gar nicht mehr gefordert. In jedem Fall ist die Klassifizierung der Kritikalität der restlichen offenen Punkte entscheidend für den weiteren Verlauf.) Eine weitere Methode, die nicht zuletzt auch im Zusammenhang mit dem Management offener Punkte zu sehen ist und die in den letzten Jahren im Zuge der Agilisierung der Projektarbeit an Bedeutung gewonnen hat, ist der … 4.4.8 Projekt-Kanban Kanban-Systeme sind ursprünglich in der Produktion zum Einsatz gekommen und bekannt geworden. Sie dienen der pull-orientierten Produktionssteuerung und wurden erstmalig von Ohno bei Toyota im TPS entwickelt, das als Quelle für die folgenden Ableitungen des Lean Production und schließlich des Lean Managements bezeichnet werden darf. Im Kern geht es dabei darum, in der sequenziellen Fertigung ein selbststeuerndes System zu etablieren, das es ermöglicht, Überproduktion (an einzelnen Arbeitsstationen) zu vermeiden, ebenso Wartezeiten auf Material-Input, und damit einen nivellierten Fluss der Produktion gleichmäßig und verschwendungsarm zu gestalten. Dabei wird, vereinfacht dargestellt, die Produktion in Arbeitsstation N-1 durch einen Pull, also eine konkrete Bedarfsmitteilung der nachfolgenden Arbeitsstation N ausgelöst. Diese Bedarfsmitteilung erfolgt mit Hilfe einer Materialkarte - auf Japanisch dem Kanban . Abbildung 196: Schematisches Taskboard im Projekt-Kanban Die Idee der Pull-Orientierung wurde in der Folge zunächst auf die Entwicklung von Software, insbesondere im betriebsnahen Bereich der Umsetzung von Änderungsanforderungen aufgegriffen. Auch hier kann in der Regel ein sequenzielles Arbeiten beobachtet werden, bestehend aus Anforderungsanalyse, Konzeption, Realisierung, Testen, Produktionsvorbereitung und schließlich Go Live. Nicht zuletzt auch vielfach mit verschiedenen Arbeitsstationen, sprich Bearbeitern, wie Analysten, Programmierer, Tester etc. Ziel war es dabei, einen gleichmäßigen Arbeitsfluss für die Bearbeiter (Entwickler) zu erzielen und eine Überlastung und damit Ineffizienz durch das <?page no="199"?> 4.4 Projektcontrolling 199 typische Schieben (Push) der Anforderung in die Arbeitsprozesse zu vermeiden oder zumindest zu verringern. Dabei wird der oben geschilderte Wertstrom in einem Taskboard abgebildet, das die verschiedenen Phasen/ Arbeitsschritte des Prozesses in aufeinanderfolgenden Spalten darstellt 97 (siehe Abbildung 196). Der Bearbeiter von Prozess N zieht bei freier Kapazität einen Auftrag aus den abgeschlossenen Aufgaben des vorgelagerten Prozess N-1. Um an dieser Stelle eine Überlastung zu vermeiden, sind für diejenigen Prozessschritte, für die eine solche Überlastung hinderlich wäre, z.B. das gleichzeitige Bearbeiten zu vieler Change Request, Work-in-Progress-Limitierungen anzuwenden. Die WiP-Limits, gemessen in Arbeitsaufwand, sog. Story Points oder schlichtweg Anzahl der Aufgaben, begrenzen also die Arbeitslast in Prozessschritt N und sind auch der Benchmark für die Feststellung freier Kapazität dort. Im Projekt-Kanban ist es erforderlich, dass diese hinsichtlich ihrer Kritikalität oder ihres Nutzens bemessen werden, der damit verbundene Aufwand reicht im Allgemeinen als Steuerungsgröße nicht aus. Priorisierungsmechanismen können ganz einfacher Natur sein, etwa Prio A, B oder C, oder auch differenzierter, wie beispielsweise mit der WSJF-Kennzahl oder dem TVD vorgestellt. Damit erweitern wir das übliche IT-Kanban-Board um einen klassischen Projektplan als Taktgeber aus übergeordneter Perspektive. Aus dem Plan ergeben sich rollierend die Aufgaben, die als „Next to do“ zur Bearbeitung anstehen. Ein Push-Pull-Mechanismus entsteht im Sinne eines hybriden Projektmanagements. Teilweise werden in den Taskboards auch sog. Fast Lanes eingerichtet, auf denen kurzfristig aufkommende, hoch dringliche Aufträge durch das System geschleust werden. Je nach Auslastung hinsichtlich des WiP-Limits müssen dabei bereits gestartete Arbeiten ggf. auf Halten (on Hold) gesetzt werden. Das Projekt-Kanban-System hat seinen Ursprung im Anforderungsmanagement für IT-Realisierungen, nicht zuletzt im Bereich des Change Request Managements. Dabei wird, wie im Produktions-Kanban-System auch, ein definierter Prozess im laufenden (IT-) Produktionsprozess abgebildet und selbstregulativ gesteuert. Größere Entwicklungsaufträge führen aber zu Entwicklungsprojekten, da hierbei ganze Teams an komplexen Lösungen arbeiten, die zu einer signifikant neuartigen Lösung führen. Es ist offensichtlich, dass die Gestaltung eines Projekt-Kanban- Systems noch einmal eine weitere, differenzierte Ausgestaltung der IT-Kanban-Systematik erfordert. So ist z.B. der projektspezifische Wertstrom bei der Gestaltung des Taskboards ebenso wie vielfältige Abhängigkeiten der Aufgaben untereinander zu berücksichtigen. Zunächst einmal ist der Wertschöpfungsprozess des Projekts oder des Teils des Projekts, der über die Kanban-Systematik gesteuert werden soll, zu definieren. Er bildet die Grundstruktur des Taskboards. Hier spielt natürlich der Projektgegenstand eine entscheidende Rolle, denn es macht beispielsweise einen Unterschied, ob eine IT-Anwendung entwickelt oder eine Abteilung reorganisiert werden soll. Nicht zuletzt, weil auch im modernen Projektmanagement eine Agilisierung stattfindet, d.h. IT- Projekte werden nicht mehr mit einem Big Design Up Front begonnen und enden in einem späten Big Bang des Go Lives des neuen Systems, bietet die Steuerung mithilfe eines Kanban-Boards hier entsprechendes Potenzial, um den o.g. sequenziellen Ablauf des Projekts in der Umsetzung zu flexibilisieren. Die einzelnen Prozesse, die Gegenstand des Projekts sind, fungieren dabei als einzelne Elemente, die durch den Projektwertstrom verändert, sprich bearbeitet werden. Die folgende Abbildung zeigt die Grundstruktur eine Projekt-Kanban-Boards schematisch. 97 nach Hüsselmann, 2021, S. 136 ff. <?page no="200"?> 200 Takt 4: Projektsteuerung Abbildung 197: Projektablauforientiertes Design des Projekt-Kanbans Wie im originären IT-Kanban auch, wird das Projekt-Kanban durch einen Backlog von links befüllt. Im Projekt bildet sich dieser Backlog aus Positionen des Pflichtenhefts, d.h. dem definierten Scope des Projekts. In agilen Projekten, bei denen die Grenzen zur kontinuierlichen Produktentwicklung teilweise verwischen ( DevOps ), ist der Backlog grundsätzlich offener gestaltet und unterliegt häufigeren Veränderungen. Je nach Projektansatz sind hier verschiedene Priorisierungsregeln von Vorteil - etwas die MuSCoW-Regel bei klassischerem Vorgehen oder die WSJF-Regel im Agilen. Zur Priorisierung gehört auch die Betrachtung der Dringlichkeit. Diese wird in Projekten erzeugt durch vorgegebene Termine, etwa den Go Live einer gesetzlich geforderten Funktionalität. Bei solchen Vorgaben errechnen sich die spätest möglichen Startzeitpunkte für den Beginn der Bearbeitung einer Aufgabe durch Rückwärtsterminierung, einer Form des Pull-Prinzips in Projekten. Damit liegt auf der Hand, dass diese Terminanforderung dafür geeignet ist, die „Next-to-do“-Spalte des Taskboards zu befüllen. Im Projekt erfolgt somit die operative Priorisierung in erster Linie durch die Dringlichkeit der Aufgabenerledigung. Andere Priorisierungen, die den Nutzen eines Elements in den Vordergrund stellen, sind eher auf der taktisch-strategischen Ebene der Prioritätenbildung anzusiedeln. Einmal akzeptierte Elemente unterliegen der operativen Steuerung im Projekt. Zusammenfassend bleibt festzustellen, dass der Backlog eines Projekts, ob mit oder ohne Kanban-Steuerung, sich zusammensetzt aus den geplanten und den zunächst ungeplanten Positionen, die abgearbeitet werden sollen. Im folgenden Video gehe ich auf horizontal und vertikal gekoppelte Kanban-Boards ein. ► Video 4.8 (Kanban-Boards), URL: https: / / youtu.be/ UxB5S2R7hmI 4.4.9 Critical Chain Project Management Als großes Problem für den schnellen Abschluss eines Projektes werden oft Personalressourcenkonflikte angesprochen, die sich aufgrund des begrenzten Budgets der einzelnen Projekte nicht durch einen höheren Personaleinsatz lösen lassen. Demnach werden Mitarbeiter häufig zum Multitasking gezwungen, sodass ein einzelner Mitarbeiter gleichzeitig an mehreren Aufgaben Teilprozess 1 Teilprozess 2 Teilprozess 3 Teilprozess N NEXT DONE Backlog Visualisierung: • Wer arbeitet an welcher Task • On Hold/ Waiting/ Probleme • Markierung: Was ist in (jeder Spalte) fertig? (oder „doing“vs. „done“-Subspalte) → Pull der nächsten Spalte • Swimlane je Epic/ Themenkomplex WiP-Limit! WiP-Limit? WiP-Limit? Wertschöpfungskette des Projekts <?page no="201"?> 4.4 Projektcontrolling 201 arbeitet. Zugleich werden die Zeitvorgaben zur Bewältigung der aufgetragenen Aufgaben reduziert, um den vorgegebenen Netzplan einhalten zu können. Critical Chain Project Management CCPM verfolgt das Ziel, die Durchlaufzeit einzelner Projekte in einer Organisation zu verringern, ohne zusätzliches Personal einsetzen zu müssen. Dies beinhaltet ebenfalls die richtige Priorisierung der Projekte durch die strategische Planung der Unternehmensführung. Der Lösungsansatz des CCPM basiert auf den fünf Schritten der Theory of Constraints (ToC). Dieser Ansatz verfolgt die Strategie, sämtliche Planungs- und Steuerungsaktivitäten auf den Engpass im Prozess auszurichten, um die Produktivität zu steigern. 98 Exkurs: Die Fünf Schritte der ToC Dazu wird der Engpass zunächst identifiziert, sodass daraufhin eine Strategie ausgearbeitet werden kann, um diesen bestmöglich auszulasten. Nun werden alle anderen Ressourcen oder Tätigkeiten diesem Engpass untergeordnet. Zuletzt erfolgt die Erweiterung der Kapazität des Engpasses, wodurch jedoch an einer anderen Stelle ein neuer Engpass entsteht. Demnach muss nun wieder mit Schritt eins begonnen werden, um den neuen Engpass zu identifizieren. Übertragen auf das CCPM bedeutet dies, zunächst die kritische Kette als Engpass zu identifizieren, welche als längste Kette abhängiger Ereignisse definiert wird, deren Abhängigkeit entweder aufgaben- oder personalbezogen ist. In Schritt zwei werden die Mitarbeiter als begrenzte Ressourcen des Engpasses nun optimal mit den Aufgaben der kritischen Kette ausgelastet, indem deren Multitasking reduziert wird. Denn durch die Erteilung einer neuen Aufgabe erst nach der Fertigstellung der zuvor bearbeiteten Aufgabe, kann die zeitaufwendige Einarbeitungszeit minimiert werden. Zuletzt werden die Tätigkeiten der Ressourcen außerhalb der kritischen Kette in Form von Mitarbeitern an die ideale Abwicklung der kritischen Kette angepasst, auch falls dies ggf. eine Drosselung deren Produktivität entspricht. Critical Chain im Multiprojektmanagement Der Critical Chain Management Ansatz in der Multiprojektumgebung beschäftigt sich mit der der Reihenfolge der durchzuführenden Projekte auf der Basis des vorhandenen Engpasses innerhalb der Organisation. Das Top-Management legt zunächst die strategische Priorisierung der durchzuführenden Projekte fest. Dies kann beispielsweise die Zusage der Liefertermine sein. Projekte mit dem frühsten Liefertermin werden folglich als erstes begonnen. Im nächsten Schritt bezieht sich das Multiprojektmanagement auf die zuvor beschriebenen fünf Schritte der „Theory of Constraints“ und identifiziert den Engpass. Bei einem Engpass handelt es sich um eine Ressource beispielsweise Abteilungen, Maschinen, Mitarbeiter oder Werkzeug, die den Abschluss der Projekte am stärksten beschränkt. Dieser Engpass wird auch als „Drum Ressource“ bezeichnet, da er den größten Einfluss auf die Projekte hat und deshalb den „Takt“ angibt. Dieser Effekt soll mit der nachfolgenden Abbildung 198 veranschaulicht werden. Hierbei werden drei ähnliche Projekte zeitgleich begonnen, die die gleiche Anzahl sowie Abfolge von (A bis G) Ressourcen benötigen. Es zeigt sich, dass die Ressource E die am stärksten belastete Ressource aller Projekte ist und einen Engpass darstellt. Entsteht eine Verzögerung bei dieser Ressource, hat diese den größten Einfluss auf die Fertigstellung aller Projekte. Bei dieser Darstellung der Projektabfolge starten alle Projekte gleichzeitig und jede Ressource ist Multitasking ausgesetzt, weshalb diese Organisation langsamer arbeitet, als sie eigentlich könnte. 98 siehe auch Kerzner, 2008, S. 859ff; Techt, 2011a, S. 13ff <?page no="202"?> 202 Takt 4: Projektsteuerung Abbildung 198: Parallel laufende Projekte mit Engpassressource E Nachdem der Engpass identifiziert wurde, muss entschieden werden, wie der Engpass bestmöglich genutzt werden soll. Hierbei ist zu beachten, dass nicht alle drei Projekte gleichzeitig begonnen werden können. Darüber hinaus muss der Multiprojektmanager auf Basis der Vorgaben des Business Managements eine Reihenfolge festlegen, welche Projekte wann gestartet werden. Anschließend wird eine optimale Verteilung des Engpasses geplant. Dadurch wird sichergestellt, dass der Engpass ohne Multitasking ausgelastet ist und mit optimaler Effizienz arbeitet. Anschließend werden die anderen Ressourcen dem Engpass untergeordnet und in den Projektablaufplan eingesetzt. In dem nachfolgenden Schema wird deutlich, dass durch eine Staffelung der Projekte der Einsatz von Multitasking bei allen Ressourcen vermieden werden kann. Projekte 1 und 2 können nun vorzeitig zum Abschluss gebracht werden. Abbildung 199: Optimaler Projektablauf Kann die Arbeitsgeschwindigkeit des Engpasses beschleunigt werden, beschleunigt dies das Gesamtsystem und die Projekte gelangen schneller zum Abschluss. Treten jedoch wie in der Praxis üblich Verzögerungen beim Engpass ein, arbeitet das Gesamtsystem langsamer und der Projektabschluss verzögert sich. Mit der Festlegung der Projektstaffelung und -ablauf ist die theoretische Grundlage für ein idealisiertes System aufgestellt. <?page no="203"?> 4.4 Projektcontrolling 203 Puffermanagement Weiter ist für das CCPM die Implementierung eines Puffermanagements während der Projektdurchführung erforderlich, um die kritische Kette vor Verzögerungen zu schützen. So wird in Critical-Chain-Projekten entlang der kritischen Kette ein Projektpuffer eingesetzt, welche durch Versorgungspuffer am Ende von unkritischen Pfaden unterstützt wird. Die Größe der jeweiligen Puffer ergibt sich aus der Halbierung der ursprünglich angesetzten Bearbeitungszeit für die einzelnen Aktivitäten. Benötigt nun eine Aufgabe mehr Zeit als ursprünglich dafür angesetzt, wird der damit verbundene Puffer aufgebraucht. Somit wird aus Berichten über den Pufferverbrauch deutlich, welche Projekte aktuell Gefahr laufen, gesetzte Termine nicht einhalten zu können. Verdeutlicht wird dieses Vorgehen anhand der grafischen Unterteilung eines Projektes in dessen einzelne Aktivitäten mit den dazugehörigen Puffern je nach Kette: Abbildung 200: Einsatz von Versorgungs- und Projektpuffern in Critical Chain Projekten Abbildung 201: Fieber-Chart über die Fertigstellung der kritischen Kette 99 99 Techt, 2015, S. 213 <?page no="204"?> 204 Takt 4: Projektsteuerung Aus der Abbildung 200 geht hervor, dass für die Einhaltung des Projektplans vor allem der Vergleich an verbrauchtem Projektpuffer zu der prozentualen Fertigstellung der kritischen Kette entscheidend ist. Schließlich stellen die Versorgungspuffer lediglich die termingerechte Fertigstellung der unkritischen Ketten sicher, so dass erst nach dem vollständigen Verbrauch der Versorgungspuffer sich ein weiterer Zeitbedarf auf den Projektpuffer auswirkt. Dies erlaubt eine geringere Priorität in der Überwachung von Versorgungspuffern im Vergleich zum Projektpuffer. In vorangegangener Abbildung 201 wird der prozentuale Vergleich zwischen dem Projektpuffer und der Fertigstellung der kritischen Kette in einem sogenannten „Fieber-Chart“ verdeutlicht. Die Auftragung des Fieber-Charts in der Abbildung zeigt, dass sich der Projektpuffer jedoch auch regenerieren kann, falls die Bearbeitung der Aufgaben innerhalb der kritischen Kette schneller erfolgt als ursprünglich angesetzt. Dies setzt jedoch voraus, dass die im Anschluss benötigte Ressource auch zur Verfügung steht, um mit der nächsten Aufgabe zu beginnen. Abschließend zu diesem Kapitel steht Ihnen wieder ein Video mit einer kurzen Zusammenfassung zur Verfügung. ► Video 4.9 (Wrap Up), URL: https: / / youtu.be/ lN7JOMeqyXE 4.5 Transferaufgaben Takt 4 4.5.1 Vertrag Haben Sie im Rahmen des von Ihnen betrachteten Projektes einen Vertrag als Auftragnehmer oder Verträge als Auftraggeber, z.B. für Entwickler oder Berater abgeschlossen? ▲ Ordnen Sie doch bitte einmal Ihren Vertrag in der im Modul vorgestellten Vertragssystematik ein! Wenn Sie keinen Vertrag abgeschlossen haben, dann bearbeiten Sie diese Aufgabe bitte mit einem fiktiven Vertrag bzw. Projekt. ▲ Ist Ihr Vertrag bzw. sind Ihre Verträge ideal abgeschlossen? Ergibt sich ggf. die Erkenntnis, dass eine andere (klassische) Vertragsform hilfreich wäre? ▲ Sehen Sie Potenziale für innovative Vertragsformen, wie Agiler Festpreisvertrag oder Relationaler Vertrag? 4.5.2 Risiken Aus der Vertragsgestaltung - aber natürlich nicht nur - ergeben sich Risiken für Projekte. ▲ Identifizieren Sie bitte einmal die Risiken für Ihr ausgewähltes Projekt und bewerten diese mit der vorgestellten Systematik. ▼ Sie finden dazu ein entsprechendes MS Excel-Template, das Sie nutzen können. Füllen Sie in dem Template im Reiter [RisikoRegister] zunächst die Kopfdaten zum Projekt aus, insbesondere das Budget als Bezugsgröße). Anmerkung: Wenn Sie in Spalte „N“ das Schadensausmaß als monetär klassifizieren („€“), dann errechnet sich daraus summarisch das monetäre Risiko für das Projekt. ▲ Sind für die identifizierten zumindest größten Risiken in Ihrem Projekt entsprechende Maßnahmen definiert worden? ▲Welche Risiken haben einen besonderen Bezug zur Unternehmensebene? <?page no="205"?> 4.5 Transferaufgaben Takt 4 205 ��� Wenn Sie diese Aufgaben vollständig bearbeiten haben, dann haben Sie entweder das gute Gefühl gewonnen, dass Ihr Projekt bzgl. Vertrags- und Risikoaspekten gut aufgestellt ist … oder Sie haben mehr oder wenige dringenden Handlungsbedarf identifiziert … Anmerkung: Wenn Sie Handlungsbedarf identifiziert haben, dann können Sie im Tool gleich die Registerkarte [Maßnahmen] nutzen. Viel Spaß! <?page no="207"?> 5 Takt 5: Das Projekt in der Organisation Auch der letzte Takt wird mit einem kurzen Video eingeleitet. ► Video 5.1 (Einleitung WM & LL), URL: https: / / youtu.be/ zs1KOoLxCBw 5.1 Lernen in und mit Projekten Das Wissensmanagement beschäftigt sich damit, Wissen, Erkenntnisse und Erfahrungen einzelner Mitarbeiter, Teams oder ganzer Organisationseinheiten anderen Mitarbeitern und Organisationseinheiten zur Verfügung zu stellen. Bei Projekten besteht die Herausforderung darin, dass sie kurze Einschwingphasen haben, in der Natur der Sache neuartig und zeitlich begrenzt sind. Am Ende des Projektes (oder auch schon bestimmter Projektabschnitte) löst sich das Projekt- Team auf und neue Teams mit anderer Besetzung entstehen. Wissen und Erfahrungen müssen über diesen organisatorischen Bruch gerettet werden. Die Wissenssicherung am Phasen- oder Projektende wird auch als Lessons Learned bezeichnet. 5.1.1 Einordnung Sehen Sie sich doch einmal das Video zum Big Picture des Wissensmanagements an. ► Video 5.2 (Wissensmanagement), URL: https: / / youtu.be/ 0YjtqlTxUWk Je nach Betrachtungsebene ergeben sich verschiedene typische Methoden. Auf der Projektebene sollten systematisch Lessons Learned identifiziert werden, wie es sich z.B. im agilen Vorgehensmodell Scrum in Form von Retrospektiven etabliert hat. Entscheidend für den unmittelbaren Projektnutzen ist, diese Retrospektiven nicht nur am Ende des Projektes durchzuführen, sondern regelmäßig im Projektverlauf, etwa bei Phasenübergängen (bei Scrum: Sprint -Übergängen). Klassische Standards des PM adressieren diese Forderung, etwa PRINCE2 mit dem Prinzip Lernen aus Erfahrungen im Prozess Managen des Phasenübergangs . Aus einer längerfristigen, übergeordneten Perspektive ergibt sich Forderung nach einer fortlaufenden Weiterentwicklung des PM-Systems, also des Strebens nach Perfektion im organisationellen Projektmanagement. Über Projektabschlussberichte sollten Projekterkenntnisse, welche generalisierbar sind, in das PM-System - im Allgemeinen durch ein PM-Handbuch dokumentiert - einfließen. Das dokumentierte und in zentralen Organisationseinheiten wie PMOs oder dem PPM institutionalisierte Wissen über Projekte kann dann in Form unternehmensspezifischer Standards à priori als Vorgabe und in Form von Supervision (Reviews, Audits) zur Laufzeit in die Projekte einfließen. Schließlich bleibt noch der Mensch als einzelnes Teammitglied, dessen individuelle Arbeitsorganisation - gerade auch unter dem Aspekt sich tendenziell selbstorganisierender Projekt- Teams - entscheidend zum Erfolg des Ganzen beiträgt. Neben der Selbstreflexion sind hier systematisch vor allem Rückkopplungen in Form von Feedback durch den Vorgesetzten sowie innerhalb der sog. Peer-Group , also im Projekt-Team „unter Gleichen“, typische Instrumente. <?page no="208"?> 208 Takt 5: Das Projekt in der Organisation Abbildung 202: Wissensmanagement in Organisation und Projekt Zentrale Fragestellungen sind dabei: [1] Wie kann ein Projekt(team) effizient das in der Organisation vorhandene Wissen mit Bezug auf den Projektgegenstand nutzen? [2] Wie wird die Wertschöpfung des Projekts auch für zukünftige Aktivitäten der Organisation bereitgestellt? [3] Wie wird innerhalb eines Projekts das Wissen (Ziele, Ergebnisse, Fortschritt, Prozesse) effizient & effektiv administriert? Schauen Sie gerne in die drei Positionen in der Grafik, um mögliche Mittel und Wege des Wissensmanagements an der jeweiligen Stelle zu finden: [1] • Best Practices • Standards • Musterlösungen [2] • Dokumente • Prozeduren & Organisation • Inhalt & Ergebnisse [3] • Erfahrungen, Lessons Learned • Know-how-Träger • Lösungen 5.1.2 Lessons Learned im Projekt Idealerweise geschieht das Lernen aus Erfahrung im Sinne des KVP laufend. Um aber die Durchführung des KVP sicherzustellen, sollte dies systematisch bei Phasenübergängen eingeplant werden: Abbildung 203: Wissensgewinnung, -transfer und -nutzung Projektwissen der Organisation Projektwissen des Projekts [1] [2] [3] <?page no="209"?> 5.1 Lernen in und mit Projekten 209 Die zielführendste Gewinnung von Lessons Learned (LL) ist die Durchführung eines LL-Workshops zur Erfahrungssicherung direkt am Ende einer Phase:  Der Zeitpunkt ist günstig.  Die Erfahrungen sind noch frisch.  Essentielle Erfahrungen für die nächste Phase und neue Projekte können gesammelt, ausgewertet und gesichert werden.  Verwendete Instrumente (Templates, Checklisten, …) und Prozesse der Zusammenarbeit sollten optimiert werden. In klassischen Methoden, wie z.B. PRINCE2, ist dies auch bereits seit langem fest verankert (Lernen aus Erfahrungen) und agile Vorgehensweisen fokussieren hierauf noch einmal besonders. So sind es z.B. bei Scrum die Retrospektiven , die zur Gewinnung von Lessons Learned explizit vorgesehenen Prozeduren am Ende eines jeden Sprints (also kurzen Phasen). Hilfreiche Fragen sind dabei:  Was war besonders gut und sollte für Folgeprojekte übernommen werden?  Welche Planänderungen gab es und was waren die Ursachen?  Welche Checklisten, Templates etc. sind zu modifizieren?  Was sollte in der kommenden Phase anders gemacht oder unbedingt beibehalten werden?  Was kann für ein ähnliches neues Projekt übernommen oder muss dort anders gemacht werden? Wie die Fragen aufzeigen, geht es bei den Lessons Learned nicht nur um die Störfaktoren, die die Arbeitet unnötig erschwert haben, sondern auch um die Erfolgsfaktoren. Allzu leicht werden diese nämlich übersehen und ggf. in den Folgephasen nicht mehr konsequent umgesetzt. Abbildung 204: Faktorenportfolio Die Ergebnisse des LL-Workshops sollten dokumentiert und mit daraus folgenden Maßnahmen versehen werden. Hier ergibt sich insgesamt folgende praxisbewährte Dokumentationsform: <?page no="210"?> 210 Takt 5: Das Projekt in der Organisation ID eindeutiger Identifizierer der Position Themenbereich dient zur Clusterung der Position, um ggf. Maßnahmen und/ oder Umsetzungsverantwortung zu bündeln, z.B. Kommunikation Faktor Benennung des identifizierten Einflussfaktors, z.B. schlechte Einbindung der Nutzer in die Konzeption Kurzbeschreibung Erläuterung, Hintergrundinformation zur Position Kategorie Erfolgsfaktor (E) oder Störfaktor (S) Einfluss Bewertung der Signifikanz der Position, etwa hoch - mittel − gering, zur Ableitung einer Priorisierung von Maßnahmen Maßnahme Benennung einer Maßnahme zur Behandlung des Einflussfaktors, z.B. regelmäßige Durchführung von Reviews mit den Nutzern Kurzbeschreibung Maßnahme Erläuterung, Hintergrundinformation zur Maßnahme Bemerkung sonstige Anmerkungen zur Erläuterung Beispiel aus einem ERP-Einführungsprojekt Abbildung 205: Wissen sichern: Lessons Learned ‒ Beispiel Durch die Definition entstehen neue To-dos, die in den Projekt-Backlog ( Register offener Punkte) einfließen müssen! Dort werden sie mit weiteren administrativen Elementen ergänzt, wie etwa Fälligkeit oder Verantwortlichkeit, sodass die Verfolgung der Umsetzung ermöglicht wird. Durch die Überführung der identifizierten und bewerteten Lektionen (Lessons) in konkrete Maßnahmen wird vermieden, dass aus Lessons Learned nur Lessons Lost werden. Man kann grundsätzlich fünf Status des Umgangs mit Lessons Learned identifizieren, die im Projektzusammenhang in der Praxis zu finden sind: Lessons Demand Detected, … Documented, … Presented, … Accepted und schließlich … Converted . 100 Vielfach sei in der Praxis nur die Stufe „präsentiert“ anzutreffen, d.h. die konsequente Umsetzung der Lektionen erfolgt nicht und die Erkenntnisse sind dann doch verloren - die Mühe der Erarbeitung ist verschwendet. Erst in der Stufe „umgesetzt2 ( converted ) bringen die Lessons Learned den mit ihrem Namen verbundenen Nutzen. 100 s. Kloss 2019, S. 211 <?page no="211"?> 5.1 Lernen in und mit Projekten 211 Die zeitlichen Abstände dieser Lessons-Learned-Workshops orientieren sich in der Regel an der Länge der Projektphasen. Je kürzer ein Projekt dauert, desto häufiger sind die Erkenntnissammlungen durchzuführen, sollen sie noch einen Nutzen für den restlichen Verlauf des Projekts spielen. Eine praktikable Faustregel ist, dass einzelne Projektphase auch bei längeren Projekten aber nicht länger als drei Monate sein sollten (andernfalls wäre eine Aufteilung sinnvoll), sodass hiermit der spätest mögliche Turnus für LL festgelegt ist. Bei Scrum dauern die Phasen, also die Sprints, beispielsweise zwei bis vier Wochen, wodurch sich ein entsprechender Takt der Retrospektiven ergibt. Je häufiger LL-Workshops durchgeführt werden, je weniger Zeit also zwischen zwei aufeinander folgenden Workshops liegt, desto stringenter und leichtfüßiger sollten diese durchgeführt werden, andernfalls droht ein Ermüdungseffekt - Zitat eines Scrum-Team-Mitglieds: „Was sollen wir denn in der 25. Retro noch besprechen? “ So wird für die Retrospektiven in Scrum beispielsweise eine maximale Dauer von 1,5 bis 2,5 Stunden gefordert - je nach Sprintlänge. Um Verschwendung zu vermeiden, kann das Treffen auch kürzer ausfallen, auf ein gänzliches Weglassen sollten man aber verzichten. Sind die Projektphase und die Abstände länger, kann ein solcher LL-Workshop auch gerne einmal einen halben bis einen ganzen Takt dauern. Dies dürfte in der Regel alles andere als Verschwendung von Zeit und Kapazitäten sein, wovon man alte Projekthasen aber oftmals auch überzeugen muss. Der nachgängige Nutzen wird es beweisen. 5.1.3 Starfish-Methode Eine leichtgewichtige Methode zur Durchführung von Retrospektiven/ Lessons-Learned-Workshops ist die Starfish-Methode: Abbildung 206: Starfish-Methode für Retrospektiven Die fünf Felder dieses „Seesterns“ sprechen für sich und eignen sich sehr gut als Visualisierung in einem teamweiten Workshop. In Kombination mit der zuvor vorgestellten Lessons-Learned- Dokumentation lässt sich die Starfish-Übung auch als Einstieg im Teamwork verwenden. Das Feld „Einfluss“ der Dokumentation wird dann etwas differenzierter nach den fünf Feldern des Starfish gestaltet. ▲ Haben Sie ein konkretes Vorhaben vor Augen? Dann probieren Sie doch mal auf die Schnelle, einen Seestern zu befüllen. Es kommt hier jetzt nicht auf Vollständigkeit an. → siehe Transferaufgabe Tag? <?page no="212"?> 212 Takt 5: Das Projekt in der Organisation Egal, welches Werkzeug letztlich verwendet wird: Im Nachfolge-Workshop sollte die Dokumentation des Vorgänger-Workshops wieder hervorgeholt und der Sachstand der Umsetzung sowie ggf. neue Erkenntnisse hiermit abgeglichen werden. 5.1.4 Multiprojekt-Wissensmanagement Nachdem wir im vorangegangenen Abschnitt primär auf das Lernen im Projekt abgezielt haben, schauen wir jetzt noch kurz auf das organisationelle Lernen (in einer ganzen Projektlandschaft). Instrumente des Multiprojekt-Wissensmanagements Folgende Instrumente könne dabei grundsätzlich eingesetzt werden: prozessorientierte Instrumente  Nach Projektende mit Teammitgliedern durchgeführte Nachbetrachtung hinsichtlich der Projektarbeit & der möglichen Erfahrungsweitergabe  Durchführung mit Hilfe von Dokumentenanalysen (z.B. Reports, Budgets Targets) und Face-to-Face bzw. kooperativen Teamsitzungen.  Ergebnisse werden in schriftlicher Form (z.B. Abschlussberichte) festgehalten. dokumentenorientierte Instrumente  Erfahrungsberichte, ausführliche Projekthistorien mit detaillierten Daten- und Projektverlaufsangaben sowie direkter Eingabe von Lessons Learned in Datenbanken  Methoden können kontinuierlich oder einmalig (Historie) eingesetzt werden. organisatorische Instrumente  Benennung eines Wissensmanagers als Prozesseigner  Schaffung von Anreizen zur Wissensweitergabe  Gewährung von Freiräumen zur Wissensaufbereitung Abbildung 207: Projektwissensmanagement − Beispiel Business Blueprint Live System Improvement Strategy Strategie Konzeption Implementierung Controlling Business Case Process Map Process-Systems Map Process-Data Map Process-Organization Map E2E Scenario Map Business Processes Model System Infrastructure Map Master Data Map System Organization Model E2E Scenarios Process Configuration System Infrastructure Master Data Definition System Org. Definition Process Integration Process Performance Systems Performance Master Data Management Organizational Performance SAP NALCOMIS IT IMP DEFAS DAAS/ MILS SPS MILSTRIP <?page no="213"?> 5.1 Lernen in und mit Projekten 213 Gerade auch bei Projekten, die in einer Organisation in ihrer Art nicht nur einmal vorkommen, sondern wiederholt - etwas bestimmte Kundenprojekte -, sollten diese Instrumente sodann in gewisse Standards bzw. Best Practices münden. Auf diese Weise können die Qualität gesteigert und der Aufwand für Folgeprojekte vermindert werden - das Rad muss nicht jedes Mal neu erfunden werden. Die vorangegangene Abbildung 207 zeigt beispielhaft eine Wissensbasis für Standardsoftware- Einführungen. Hier werden Vorgehen und Artefakte musterhaft aufgeführt und bereitgestellt. ��� Systematische Wissensmanagement kostet Geld ‒ fehlendes Wissensmanagement kostet (gerade auch in wissensintensiven Vorhaben, wie IT-Projekten) mehr! Oft wird man in Projekten von den Mittelgebern gefragt, wieviel das denn koste und ob sich das lohne. Eine Antwort darauf ist in der Regel schwer zu geben - zumindest valide. Der Nutzen lässt sich jedoch mit einer einfachen Überlegung veranschaulichen: Abbildung 208: Warum Projekt-Wissensmanagement? ‒ Beispiel Hier wird beispielhaft illustriert, welchen Nutzen man erwarten kann, wenn 100 Personen sich in ein komplexes System (z.B. ein Großprojekt) einarbeiten müssen - mit und ohne systematisches Wissensmanagement, hier in Form des sogenannten „Onboardings“. ▲ Wie ist in Ihrer Organisation die Akzeptanz für (Projekt-)Wissensmanagement einzuschätzen? 5.1.5 Kommunikation Wir haben bereits ausgewählte Grundlagen des Themenkomplexes „Führung“ besprochen. Einer der wichtigsten Bausteine für Führung, wie auch für die Gewährleistung des Informations- und Wissensflusses in der Organisation (siehe auch Abschnitt Statusberichtswesen), ist die Kommunikation zwischen den Projektbeteiligten. ��� Kommunikation ist im Projekt nicht alles, aber ohne Kommunikation ist alles nichts! <?page no="214"?> 214 Takt 5: Das Projekt in der Organisation Betrachten wir dazu einmal das sympathische Beispiel „Aufruhr im Wald“ als Grundlage für die Transferleistung in den Projektalltag: Große Aufruhr im Wald! Es geht das Gerücht um, der Bär habe eine Todesliste. Alle fragen sich, wer denn nun da drauf steht. Als erster nimmt der Hirsch allen Mut zusammen, geht zum Bären und fragt ihn: „Sag mal, Bär, steh ich auch auf deiner Liste? “ „Ja,“ sagt der Bär, „auch dein Name steht auf der Liste.“ Voller Angst dreht sich der Hirsch um und geht. Und wirklich, nach zwei Tagen wird der Hirsch tot aufgefunden. Die Angst bei den Waldbewohnern steigt immer mehr, und die Gerüchteküche um die Frage, wer denn nun auf der Liste stehe, brodelt. Der Keiler ist der erste, dem der Geduldsfaden reißt und der den Bären aufsucht, um ihn zu fragen, ob er auch auf der Liste stehen würde. „Ja,“ antwortet der Bär, „auch du stehst auf der Liste“. Verängstigt verabschiedet sich der Keiler vom Bären. Und auch ihn fand man nach zwei Tagen tot auf. Nun bricht die Panik bei den Waldbewohnern aus. Nur der Hase traut sich noch den Bären aufzusuchen. „Bär, steh ich auch auf der Liste? “ „Ja, auch du stehst auf der Liste.“ „Kannst du mich da streichen? “ „Ja klar, kein Problem! “ Die Moral von der Geschichte: Kommunikation ist alles! Ich denke, der Transfer auf die Projektwelt gelingt einfach. Nur wer fragt und redet, dem kann geholfen werden. Kommunikation als Erfolgsfaktor Wie informiert man Mitarbeiter? Abbildung 209: Kommunikation als Erfolgsfaktor ‒ 4 W Anforderungen an Projektkommunikation • Die richtige Information muss an die relevanten Stakeholder in einer ihren Erwartungen entsprechenden und einheitlichen Form weitergegeben werden. • Kommunikation sollte zweckorientiert, klar verständlich und aktuell sein. • Die Kommunikation gehört zu den wichtigsten Fähigkeiten für einen erfolgreichen Projektmanager. <?page no="215"?> 5.1 Lernen in und mit Projekten 215 Ziel ist, die Projekt-Stakeholder zeitnah, angemessen, aktiv und ehrlich über den Projektfortschritt und besondere Projektereignisse informieren. Abbildung 210: Teilprozesse der Kommunikationsplanung Um die Kommunikation nicht dem Zufall oder den persönlichen Vorlieben bzw. Eigenschaften der Projektbeteiligten zu überlassen, ist eine systematische Kommunikationsplan wertvoll bis unerlässlich. Dazu gehört die Aufstellung eines Kommunikationsplans, der folgende Fragen beantwortet: Abbildung 211: Fragen der Kommunikationsplanung Im Beispiel sieht das dann möglicherweise so aus: Abbildung 212: Fragen der Kommunikationsplanung ‒ Beispiel Stakeholder identifizieren Projektbezug bestimmen Ableiten und Definieren der Kommunikations- … -bedarfe -intensität -meilensteine -plan <?page no="216"?> 216 Takt 5: Das Projekt in der Organisation Zur Ausgestaltung des Kommunikationsplans steht in der Regel ein ganzer Kommunikationsbaukasten zur Verfügung: Abbildung 213: Baukasten der Kommunikationsplanung Nicht alle Instrumente dieses Baukastens sind für alle Kommunikationszwecke gleich gut geeignet. Eine Studie unter 754 Projektmanagern gibt bzgl. Relevanz und Nutzung interessante Aufschlüsse: 101 Abbildung 214: Relevanz und Nutzung der Kommunikationsformate Bei den meisten Instrumenten erkennt man ein gewisses „Knowing-Doing-Gap“: Relevanz und Nutzungsintensität sind nicht in Einklang! ▲ Wie sieht es bei Ihnen im Unternehmen diesbezüglich aus? 101 Nagel, 2013 Wen? Was? Wie? Vorstand / Steuerkreis Startinformationen Intranet/ Internet E-Mail Messen Lenkungsausschuss Planungen Telefon Brief Presseartikel Selbstverwaltung Statusberichte Flyer Gem. Laufwerk Pressekonf. Ressortdirektoren Entscheidungen Marktplatz Poster Anzeigen Abteilungsleitung Feedback Pers.versamml. Forum Event Personalrat Erfolgsmeldungen PM-Portal Präsentation Veranstaltung Führungskräfte Ergebnisse Wikis Gespräche Prj.-Name, Logo Mitarbeiter Roll-Out Film, Video Konferenzen Projektmotto Externe Projektabschluss Newsletter Web-/ Tel.-Konf. Social Media <?page no="217"?> 5.1 Lernen in und mit Projekten 217 Nutzen Sie doch die Stakeholder-Analyse des Projekts für eine zielgerichtete Kommunikation bzw. Einbindung der Beteiligten und Betroffenen. Dazu dient folgende Portfoliodarstellung mit den zugehörigen Normstrategien: Abbildung 215: Normstrategien der Kommunikation Wir können bei der Kommunikation nicht davon ausgehen, dass unserer Nachrichten nur Daten und Fakten der Sachebene enthalten. Entscheidend ist, was beim Empfänger ankommt und welche Informationen dieser aus der Nachricht zieht. Der Empfänger bestimmt die Botschaft: ��� Nicht das, was gesagt wird, ist entscheidend, sondern das, was beim Empfänger ankommt! Betrachten wir in diesem Zusammenhang das Kommunikationsmodell von Schulz von Thun, auch Vier-Seiten-Modell genannt: Abbildung 216: Vier-Seiten-Modell der Kommunikation Nehmen wir an, die Nachricht des Beifahrers lautet „Es ist grün.“ Nach Schulz von Thun hat diese Nachricht vier Seiten: 102  Die Sachebene enthält Daten und Fakten: „Die Ampel ist grün“ 102 vgl. Timinger, 2017, S. 325 <?page no="218"?> 218 Takt 5: Das Projekt in der Organisation  Der Appell soll etwas bewirken und enthält eine Aufforderung: „Fahr endlich los.“  Die Beziehungsebene berücksichtigt, wie Sender und Empfänger zueinander stehen und wie die Nachricht jenseits von Fakten und Daten verstanden werden kann: „Du brauchst Hilfe.“  Die Selbstkundgabe gibt etwas über den Sender preis: Was denkt dieser, was sagt die Nachricht über ihn aus? „Ich bin ungeduldig.“ In diesem Zusammenhang ist das Bonmot des Mathematikers Norbert Wiener zutreffend: „Ich weiß nicht, was ich gesagt habe, bevor ich nicht die Antwort des anderen darauf gehört habe.“ 5.1.6 Eskalation Eine spezifische Zielrichtung der Kommunikation ist die Eskalation. Schauen wir dazu kurz in das folgende Video. ► Video 5.3 (Eskalation), URL: https: / / youtu.be/ PqVsj_bXRIw Eskalationen sind nichts Schlimmes im Projekt oder Programm. Sie sind das Einfordern der spontan notwendigen oder bisher nicht erfolgten Entscheidungen auf definierte Weise - vorausgesetzt, eine geregelte Governance ist etabliert. 103 Kleine Konflikte, die sich durch gemeinsame Diskussionen im Team auf der operativen Ebene wieder erledigen, werden nicht durch Eskalationen behandelt. Wenn eine Hierarchieebene ein auftretendes Problem nicht selbst lösen kann, dann sprechen wir von Eskalationsmanagement. Eskalationen sind in vielen Köpfen negativ besetzt. Es meint aber eigentlich nur einen Projektautomatismus, bei dem festgelegt ist, wer, wann und in welcher Form ein eskalationsrelevantes Thema an die nächsthöhere Entscheidungsebene weitergibt (siehe Abbildung 217). In diesem Zusammenhang hört man die ein oder andere projektbeteiligte Person oftmals sagen: „Das müssen wir eskalieren! “ 104 Abbildung 217: Eskalationspyramide 103 Widmann, 2019 104 Jordan, 2020, modifiziert <?page no="219"?> 5.1 Lernen in und mit Projekten 219 Der Sachverhalt sollte immer von beiden Parteien (Auftraggeber und Auftragnehmer) gemeinsam beschrieben werden und abgestimmt sein. Eskalationsstufen • Alle möglichen Maßnahmen sollten ergriffen werden, um einen Eskalationssachverhalt auf der niedrigsten Stufe zu lösen. Vor dem Start eines Eskalationsprozesses sollten die Konsequenzen deutlich artikuliert werden. • Auf jeder Stufe sollte zwischen den Beteiligten versucht werden, eine Lösung zu finden. Ist diese nicht möglich, sollte - nach vorheriger Abstimmung und unter Berücksichtigung der Anzahl der Eskalationstage (Verweildauer auf einer Eskalationsstufe) - der Eskalationssachverhalt an die jeweilig nächste Eskalationsstufe weitergegeben werden. • Der Projektmanager ist für die Problemlösung verantwortlich und bleibt es auch bei jeder Eskalationsstufe. In der Praxis haben sich drei Phasen im Eskalationsmanagement herauskristallisiert: 104 Abbildung 218: Phasen im Eskalationsmanagement Anbahnungsphase (Phase 1) Eskalationen in Projekten sind nicht grundsätzlich schlecht. Um in schwierigen Projektsituationen Klarheit zu schaffen, ist es immer gut, die Dinge zuerst offen anzusprechen und klar mit allen Beteiligten zu kommunizieren. Eskalationsphase (Phase 2) Sieht sich das Projekt dann trotz Transparenz nicht in der Lage, die Situation aufzulösen und zu entscheiden, dann hilft die aktive Eskalation z.B. an den zuständigen Lenkungsausschuss (strategische Ebene)! Das Projekt wird entlastet und kann nach der Entscheidung unter klaren Vorgaben weiterarbeiten. Wichtig hierbei ist, dass jede Eskalation mit einem entsprechenden Entscheidungs-Template aufbereitet und dem Entscheiderkreis zur Verfügung gestellt wird. Neben der Aufarbeitung bestehender Probleme steht selbstverständlich auch die Planung der Folgeschritte im Fokus. Diese Planung muss abgestimmt und von allen Projektverantwortlichen getragen werden. Alle Beteiligte müssen zudem bereit sein, an einer Lösung mitzuwirken. Eingeleitete Schritte müssen überwacht werden. Ein starker Austausch der einzelnen Parteien während der Eskalation und die Kontrolle des Fortschritts sind hier wichtig. ��� Inhalte der Eskalation • Genaue Beschreibung des Sachverhalts, so dass er von Dritten direkt verstanden werden kann. • In welchem Bereich und zu welchem Zeitpunkt ist der Sachverhalt entstanden? • Wer hat den Sachverhalt in welchem Reporting-Medium (z.B. wöchentlicher Statusbericht) auf die Tagesordnung gebracht? <?page no="220"?> 220 Takt 5: Das Projekt in der Organisation • Was ist getan worden, um das ursprüngliche Risiko bzw. Problem zu verhindern, es bei Auftreten zu lösen bzw. es abzumildern? • Wer war an der Lösungssuche beteiligt? • Wie zeitkritisch ist der Sachverhalt bzw. bis wann wird eine Lösung benötigt? • Benennung des Risikogrades und Bewertung der Auswirkung (Impact). • Welche Aktivitäten werden zur Lösung vorgeschlagen? • Beschreibung des Lösungsansatzes mit Schätzung der Zeitschiene (Timeline), der Ressourcen und der Benennung des Verantwortlichen für die Lösung. Reflexionsphase (Phase 3) In der Reflexionsphase wird über die getroffene Entscheidung reflektiert und notfalls können mögliche Nachjustierungen durchgeführt werden. Das soll aber auf keinen Fall bedeuten, dass getroffene Entscheidungen sofort wieder hinterfragt werden. Hiermit ist gemeint, dass Entscheidungen eine Reflektion benötigen, um vom Gesamtprojekt akzeptiert zu werden und einen möglichen Weg für zukünftige Entscheidungen zu ebnen. Zusammenfassend lässt sich sagen: - Unter Eskalationsmanagement wird ein definierter und gewollter Prozess innerhalb eines Projektes verstanden, um Entscheidungen auf die nächsthöhere Ebene zu delegieren. - Das Eskalationsmanagement kann in drei Phasen gegliedert werden: Anbahnungs-, Eskalations- und Reflexionsphase. - Das richtige Timing der Eskalation ist ausschlaggebend. - Eskalationen im Projekt sollten positiv besetzt sein, weil Eskalationen projektrelevante Entscheidungen treffen und somit den Erfolg des Projektes garantieren. 5.1.7 Projektmarketing „Tue Gutes und rede darüber! “ Walter Fisch Projekte erfordern durch ihre zeitliche Begrenzung und den unterschiedlich involvierten Zielgruppen ein spezielles Projektmarketing. Gerade bei Projekten, bei denen mit Ablehnung zu rechnen ist oder die tiefgreifende Veränderungen nach sich ziehen, spielt das Projektmarketing eine zentrale Rolle. Ziel des Projektmarketings ist es, das Projekt auf dem Weg zur Zielerreichung sowie bei der Etablierung der Projektergebnisse in der Zielorganisation optimal unter Miteinbezug des Projektumfelds und der strategischen Ausrichtung zu unterstützen. Der Nutzen des Projektmarketings liegt im Wesentlichen darin:  Das Projekt und das Produkt an die Zielgruppen heranzuführen.  Eine Verbesserung des Projektablaufs durch eine positive Grundeinstellung zu ermöglichen und somit das Arbeitsklima zu verbessern.  Widerstände abzubauen und durch eine präventive Schadensbegrenzung die Schaffung einer Identifikationsgrundlage zu erzeugen.  Die Einführung zu unterstützen und somit wenn immer möglich die Akzeptanz der Nutzung des Projektergebnisses zu erhöhen. Zielgruppen des Projektmarketings sind prinzipiell alle Stakeholder, speziell: <?page no="221"?> 5.2 Überleitung in den Betrieb 221 Abbildung 219: Projektmarketing ‒ Zielgruppen Folgende Kanäle können für das Projektmarketing sinnvoll sein:  Projektflyer  Pressemitteilungen  Artikel, Sonderdrucke  Internet-/ Intranet-Auftritt  Präsentationen Nachfolgend zwei Beispiele aus einem IT-Infrastruktur- und Reorganisationsprojekt: Pressebericht (extern) Projektflyer (intern) Abbildung 220: Projektmarketing − Beispiele 5.2 Überleitung in den Betrieb 5.2.1 Cut-over-Planung Eine Anwendungsmigration beschreibt den Austausch einer Anwendung durch eine neue Anwendung. Bei diesem Prozess kommen Elemente sowohl der Hard- und Softwaremigration als auch der Datenmigration zusammen. Es handelt sich also um eine grundsätzliche Umstellung des Anwendungssystems, um neue Technologien und Funktionen zu nutzen. Eine sorgfältige Planung bildet bei diesen Projekten die Basis für die Wahrung der Datenkonsistenz und den <?page no="222"?> 222 Takt 5: Das Projekt in der Organisation erfolgreichen Wechsel der Funktionalität von dem alten auf das neue Anwendungssystem. Die Planung der Umstellung ist ein wesentlicher Bestandteil einer Migration. Je früher damit begonnen wird, desto größer sind die Chancen, Prozesse und Daten erfolgreich von der alten in die neue Welt zu überführen. Dennoch wird dieser Teil des Projektgeschäfts meist stiefmütterlich behandelt. Ein Kernelement der Planung ist der sogenannte Cut-over-Plan . 105 Dabei gilt es, den Übergangsprozess vom Altsystem auf das neue Anwendungssystem ( Cut-over ) möglichst exakt im Vorfeld zu planen und zu definieren. Die Erstellung des Cut-over-Plans sollte in mehreren Iterationen erfolgen. Mit jeder Iterationsstufe wird die Cut-over-Planung feiner, detaillierter und terminlich exakter. Im Cut-over-Plan sollten mindestens folgende Punkte berücksichtigt werden: • Welche Komponenten werden wann und in welcher Folge produktiv gesetzt? • Wann wird mit der Übernahme der Stammdaten begonnen? • Wann wird mit der Übernahme der Bewegungsdaten begonnen? • Wann wird das Altsystem abgeschaltet? • Erfolgt eine Archivierung des Altsystems? Auf der zeitlichen Ebene wird manchmal vom Cut-over als einem Zeitpunkt gesprochen, sei es der Cut-over einer Generalprobe oder das Go-Live-Ereignis im Sinne eines Change of Controls (CoC), der rechtlichen Übergabe der Daten oder des Dienstes. Meistens spricht man jedoch von einem Zeitabschnitt: 106 Abbildung 221: Cut-over auf zeitlicher Ebene Der Cut-over beginnt im Vorfeld des Transition-Wochenendes und umfasst die Konzeptions- und Testphase sowie das Go Live, gefolgt von einer Post-Transition-Phase, innerhalb derer Prozesse abgeschlossen werden müssen. 107 Im Falle beispielsweise eines Wertpapiermigrationsprojekts sind dies zum Beispiel die offenen und rückwirkenden Transaktionen. 5.2.2 Betriebsübergabe Die Betriebsübergabe dient zur Einführung (z.B. Installation) der Projektergebnisse (z.B. eines neuen Systems) und zur Aufnahme des Betriebs. Sie gewährleistet einen sicheren Übergang vom bestehenden zum im Betrieb befindlichen neuen Zustand (z.B. System). 105 nach Kreutz, 2020 sowie Buch/ Cholewa, 2021 106 Buch/ Cholewa, 2021 107 Buch/ Cholewa, 2021 <?page no="223"?> 5.2 Überleitung in den Betrieb 223 In der Praxis besteht die Gefahr, dass Projektpersonal quasi „schleichend“ mit der erarbeiteten Lösung in den Normalbetrieb übergeht. Beispiel • Die Entwicklungsabteilung entwickelt ein Software-System zur Planung von Prozessleitanlagen. Nach der Fertigstellung werden Entwickler zum Teil für die technische Planung mit dem System in der Planungsabteilung eingesetzt. • Offensichtlich sind wichtige Arbeitspakete, wie z.B. Schulung, Erstellung aussagefähiger Benutzerunterlagen o.ä., für die Lösung nicht berücksichtigt worden. Die Kernfrage lautet daher: Wie wird ein reibungsloser Betrieb bei der Übergabe der Projektergebnisse in die Linienorganisation sichergestellt? → 5.2.3 Einführungskonzept 5.2.3 Einführungskonzept Das Einführungskonzept beantwortet wichtige Fragen zur Aufnahme des Normalbetriebs: 108 • Wurde das System in die Produktionsumgebung oder zumindest produktionsähnliche Umgebung migriert, um Abnahmetests durchzuführen? • Sind Infrastrukturvoraussetzungen (z.B. Benutzer, Berechtigungen) geschaffen worden? • Haben die Anwender genügende Ausbildung und Erfahrung, um das neue System wirkungsvoll zu nutzen? • Wurde der Übergang von der alten zur geänderten Tätigkeit für jeden Anwender erfolgreich durchgeführt (z.B. durch Schulung)? • Sind alle Betroffenen über die Neuverteilung der Aufgaben und Zuständigkeiten informiert worden? Ist der Betriebsverantwortliche ernannt? • Sind alle organisatorischen Voraussetzungen für den Betrieb des neuen Systems vorhanden? • Ist die Unterstützung bei Anwendungs- und Betriebsproblemen geregelt? • Ist die Wartung des Systems geregelt? Gibt es einen Wartungsvertrag? Mindestens die letzten drei Positionen sind schlussendlich in einem Betriebshandbuch auch über das Projektende hinaus festzuhalten. 5.2.4 Hypercare Bei der Einführung von IT-Systemen hat sich in der Praxis zur Anlaufsicherung der Ansatz „Hypercare“ bewährt: Hier steht ein Ansprechpartner in den ersten Tagen der Nachlaufphase zum Go Live zu jeder Anwenderfrage Rede und Antwort. Bestenfalls ist dieser Ansprechpartner vor Ort und kann so innerhalb weniger Minuten Nutzern direkt am Arbeitsplatz helfen. Nebenbei werden alle Fragen, Probleme und jegliches Feedback dokumentiert. Mit Hypercare wird ein begrenzter Zeitraum nach Abschluss einer Phase in der IT eines Unternehmens (z. B. im Anschluss an eine Softwareeinführung) bezeichnet. 109 Der Begriff beschreibt einen Zustand erhöhter Bereitschaft innerhalb der IT-Organisation. Dabei gehen die primär Beteiligten inkl. Dienstleistern in eine spezielle Pflege der betroffenen IT-Umgebung, indem sie den Benutzern zusätzlichen Support anbieten. Dieser zusätzliche Support hilft neuen und bestehenden Kunden bzw. Anwendern zu verstehen, wie das neue Produkt, der neue Service, die neue Funktion oder das neue Programm zu nutzen sind. Zudem werden auftretende Probleme und Fragestellungen oftmals direkt oder unmittelbar geklärt. 108 vgl. HERMES, 2004 109 siehe auch noventum, o.J.; Grötsch, 2018 <?page no="224"?> 224 Takt 5: Das Projekt in der Organisation So erhalten die Mitarbeiter nicht nur eine vollumfängliche Betreuung, sondern im Nachgang auch Schulungsunterlagen, die speziell auf die Fragestellungen der eigenen Mitarbeiter eingehen. Hypercare ist aber keine Universallösung. So versagt diese Vorgehensweise beispielsweise dann, wenn man viele Außendienstmitarbeiter schulen möchte, die ihre Zeit größtenteils auf dem Weg zum oder beim Kunden verbringen. 5.3 Projektabschluss Wann ist ein Projekt zu Ende? Es ist nicht immer ganz leicht, den Projektabschluss definieren. Dazu ein Beispielprojekt: Entwicklung eines Software-Systems für die Verwaltung. Ende des Projektes: Nach der Lieferung und der Installation? Oder: Erst dann, wenn gezeigt werden kann, dass die Projektziele erreicht wurden, z.B. Senkung der Verwaltungslaufzeiten um 15%? Der PM-Aufwand steigt zum Abschluss noch einmal an: 110 Abbildung 222: PM-Aufwand im Projektverlauf Ziel ist es, ein für alle Beteiligten erkennbares Ende zu schaffen und dies zu markieren. Die PM- Aktivitäten konzentrieren sich auf den vertrags-/ auftragsgemäßen Abschluss der relevanten Arbeitspakete, z.B. Übergabe, Test, Inbetriebsetzung, Überweisung, Behebung von Restmängeln, Ergebnisdokumentation sowie Kommunikation der Projektergebnisse. Nach DIN 69 9000-2 gehören zum Projektabschluss folgende Inhalte: Formaler Projektabschluss Projektabnahme durch den Auftraggeber o ggf. Mängelliste Abwicklung der Vertragsbeziehungen Auflösung der Projektorganisation o Entlastung der Projektleitung o Rückführung der Projektmitglieder und -ressourcen, Projektabschluss-Workshop 110 angelehnt an PMI, 2008 <?page no="225"?> 5.3 Projektabschluss 225 Übergabe der Projektergebnisse an die Betriebsorganisation Erstellung und Veröffentlichung des Projektabschlussberichts Archivierung der Projektdokumentation Anlaufsicherung Nutzerbetreuung (siehe oben „Hypercare“) Erfahrungssicherung („Lessons Learned“) Analyse Projektverlauf & Projektergebnisse Erfahrungssicherung für Folgeprojekte Erhebung der Zufriedenheit der Stakeholder (Feedbacks) Nachbearbeitung ggf. Mängelbehebung ggf. Gewährleistungssicherung Nutzenrevision Nachkalkulation Schauen wir in einige der genannten Elemente einmal etwas genauer hinein. 5.3.1 Kundenzufriedenheit Ein wesentliches Projektergebnis ist stets die Zufriedenheit des Kunden bzw. Auftraggebers (extern bzw. intern) mit den Projektergebnissen. Durch die systematische Feststellung der Kundenzufriedenheit werden wichtige Lernchancen genutzt … und die Beziehung zum Auftraggeber positiv beeinflusst. Instrumente zur Ermittlung der Kundenzufriedenheit sind: • Informelle Gespräche zwischen Projektleiter und Auftraggeber. Der Projektleiter sollte diese Ergebnisse an das Projekt-Team weitergeben. • Einladung des Kunden zum Projektabschluss-Workshop bzw. -Präsentation. • Schriftliche Befragung des Kunden. Beispiel „Wie zufrieden waren Sie mit der Projektplanung? “ Abbildung 223: Skala der Kundenzufriedenheit 5.3.2 Abschlussbericht Der Abschlussbericht enthält eine Zusammenfassung und Bewertung des Projektverlaufs (Ausgangslage, Vorgehensweise, …) sowie die Darstellung und Bewertung der Projektergebnisse (erbrachte Leistungen, Termine, Kosten, Erfahrungen, Übergang in die Line, …). sehr zufrieden sehr unzufrieden <?page no="226"?> 226 Takt 5: Das Projekt in der Organisation Definition Projektabschlussbericht Nach DIN 69900-5 ist der Projektabschlussbericht „die zusammenfassende, abschließende Darstellung von Aufgaben und erzielten Ergebnissen, von Zeit-, Kosten- und Personalaufwand sowie gegebenenfalls von Hinweisen für mögliche Anschlussprojekte.“ PRINCE2 definiert den Projektabschlussbericht als einen „Bericht, den der Projektmanager für den Lenkungsausschuss erstellt. Darin wird die Übergabe aller Produkte bestätigt, der Business Case aktualisiert und durch Vergleich mit den Vorgaben in der ursprünglichen Projektleitdokumentation [Projekthandbuch] bewertet, wie gut das Projekt durchgeführt worden ist.“ Beispiel für den Aufbau eines Abschlussberichts Dokumenteninformation Zielsetzung und Aufbau des Berichts 1 Das Projekt in der Übersicht 1.1 Ausgangssituation 1.2 Projektziele und -inhalte 1.3 Projektabschnitt „Planung“ - Verlaufsübersicht 1.4 Projektabschnitt „Implementierung“ - Kernaspekte der Projektdurchführung 1.5 Projektorganisation 1.5.1 Planungsabschnitt 1.5.2 Implementierungsabschnitt 2 Evaluierung 2.1 Projektverlauf und Lessons Learned 2.1.1 Projektabschnitt „Planung“ 2.1.2 Projektabschnitt „Implementierung“ 2.1.3 Bewertungen 2.2 Zielerreichung 2.2.1 Zielerreichung: Dimension Zeit 2.2.2 Zielerreichung: Dimension Qualität & Umfang 2.2.3 Zielerreichung: Dimension Kosten 2.3 Ergebnisse und Nutzen 2.4 Ausblick und Empfehlungen 3 Entlastung Projektorganisation Anhang Die Projektnachkalkulation ist dabei gleichsam der letzte Soll-Ist-Vergleich im Projektverlauf. Sie dient der abschließenden Ermittlung der tatsächlichen Kosten und Wirtschaftlichkeit der Erstellung des Projektergebnisses. Die Projektnachkalkulation ist ein weiteres Element der Lessons Learned und sollte zukünftigen Projekten der Organisation zugänglich gemacht werden. Eine häufige Situation ist jedoch, dass der Projektnutzen (= übergeordneter Projekterfolg) im Allgemeinen mit zeitlicher Verzögerung zum Projektendtermin (= Produktivstart) eintritt. Abbildung 224: „Projektinkasso“ ‒ in der Regel nach dem Projekt Es stellt sich die Frage, ob der erwartete (prognostizierte) Nutzen − in der geplanten Höhe − wirklich eingetreten ist. <?page no="227"?> 5.3 Projektabschluss 227 5.3.3 Nutzenrevision Die Feststellung des Nutzens ist im Allgemeinen keine triviale Aufgabe, die zumindest die Verfügbarkeit diesbezüglich aussagefähiger KPIs erfordert. Zur Erinnerung: Der Nutzen ist eine messbare Verbesserung, die aus einem Projektergebnis resultiert und von einem oder mehreren Stakeholdern als Vorteil betrachtet wird. Der Nutzenrevisionsplan definiert, wie und wann gemessen werden kann, ob ein erwarteter Projektnutzen erreicht worden ist. Vorgehen zur Nutzenrevision: • Nutzenrevisionsplan erarbeiten (Planung) o Möglichkeiten der Feststellung o Zeitpunkt der Feststellung • Wirtschaftlichkeitsbetrachtung (Kosten vs. Nutzen) mit Ist-Daten durchführen • Ggf. Maßnahmen erarbeiten, um Nachhaltigkeit des Projekterfolgs zu sichern • Bericht an den Auftraggeber • Erfahrungssicherung für Folgeprojekte 5.3.4 Auflösung des Projekts Mit Projektende (wie gesagt, in der Regel ist das schon vor dem „Nutzeninkasso“) erfolgt die Auflösung des Projekts. Diese sollte, wie auch das Aufsetzen des Projekts zu Beginn, systematisch erfolgen: Ressourcenfreigabe und Auflösen der Projektorganisation Mitarbeiter, Räume, Rechner etc. … • sind nur für einen bestimmten Zeitraum bereitgestellt, • müssen wieder freigegeben werden, • ggf. Verträge für Räume, Geräte usw. kündigen. Häufiger Konflikt bei Projektende (insbesondere bei langläufigen Projekten mit Vollzeit-Projektmitarbeitern): • Projektmitarbeiter wollen Sicherheit und orientieren sich auf Rückkehr in die Linie bzw. auf neue interessante Aufgaben. • Erfahrenes Team muss das Projekt aber erfolgreich zu Ende führen. Auflösen der Umfeldbeziehungen Der Projektleiter und das Projektteam nehmen die aktualisierte Projektumfeldanalyse zur Hand und prüfen folgende Kriterien: • Welche Aufgaben sind vom Projektteam in Bezug zum Umfeld noch zu erledigen? • Welche Aufgaben sind vom Umfeld in Bezug auf das Projekt noch zu erledigen? • Wie werden die jeweiligen Stakeholder über den Projektabschluss in Kenntnis gesetzt? Darüber hinaus ist es wichtig, die Wirkung der Projektergebnisse auf die Auftraggeber-Organisation zu prüfen (→ Nutzenrevision). <?page no="228"?> 228 Takt 5: Das Projekt in der Organisation 5.4 Management der Projektlandschaft ‒ speziell der IT Die IT wird klassischerweise als Enabler der Fachbereiche, sprich des Geschäftsbetriebs, verstanden. Mit Blick auf die zunehmende Bedeutung der IT für den geschäftlichen Erfolg - Stichwort Digitalisierung - wandelt sich die Positionierung der IT zunehmend hin zu einer partnerschaftlichen, unmittelbar am Geschäftsbetrieb Beteiligten. Nicht selten wird die IT sogar vom Enabler zu Treiber des Geschäfts. Neue IT-Trends, die immer schneller den Markt beeinflussen, ermöglichen - und erfordern − vielfach auf der Basis einer Internet-Vernetzung von Menschen, Unternehmen, Maschinen und Produkten eine entsprechende Weiterentwicklung des Unternehmens, bis hin zu einer Digitalen Transformation, bei der die IT-basierten Services rund um (oder sogar anstatt) der Projekte einen immer größer werdenden Anteil am Geschäftsmodell einnehmen. Die folgende Abbildung zeigt angesichts dieser Entwicklung eine ganzheitliche Einordnung des IT-Managements auf. 111 Abbildung 225: Aufgabenfelder und Positionierung des IT-Managements Mit Blick auf das IT-Projektmanagement soll im Folgenden ein Überblick über das IT-Projektportfoliomanagement gegeben werden. Ausgangsbasis und professionelle Voraussetzung dafür ist die Existenz einer IT-Strategie, deren Erstellung wiederum selbst als IT-(Strategie-)Projekt zu verstehen ist. 111 Resch, 2009 <?page no="229"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 229 5.4.1 Ausgangsbasis IT-Strategie Eine IT-Strategie, die vollständig in die Geschäftsstrategie integriert ist, ist Voraussetzung für eine wertschöpfende IT. Ohne diese Integration ist ein systematischer Wertbeitrag der IT nicht möglich. Die Umsetzung dessen soll in einem Beispiel verdeutlicht werden. 112 Ein Unternehmen hat beispielsweise drei operative Zielsetzungen im Rahmen seiner Geschäftsstrategie definiert: Produktführerschaft, Marktreichweite und Operative Exzellenz.  Stärkung der Produktführerschaft: Konzentration auf Produktlinien und Anwendungen mit Potenzial für Innovations- und Marktführerschaft wie auch mit klar erkennbarem Kundenmehrwert.  Ausbau der Marktreichweite: Gezielte Bearbeitung nach Marktsegmenten und effizienter Einsatz aller direkten Vertriebskanäle wie auch Integration neuer Verkaufsansätze.  Verbesserung der operativen Exzellenz: Weltweite Standardisierung von Geschäftsprozessen auf höchstem Niveau zur Steigerung der Kundenzufriedenheit und Effizienz. Den größten Ansatzpunkt der IT-Strategie identifiziert das Unternehmen vor allem im Bereich der operativen Exzellenz. Abbildung 226: Fokussierung der IT-Strategie innerhalb der Geschäftsstrategie Dabei muss die IT-Strategie stets in Abstimmung mit der Geschäftsstrategie weiterentwickelt werden: Das Unternehmen betreibt die Pflege seiner Kundenkontakte über ein Direktvertriebsmodell, das verschiedene Verkaufs- und Vertriebskanäle ermöglicht. Diese Kanäle sind: Verkaufsberater, telefonischer Kundenservice, eigene Ladengeschäfte, die ausschließlich eigene Produkte anbieten, Filialen in bestehenden Einzelhandelsgeschäften, Online (Internetshop) und B2B-Schnittstellen zu Großkunden. Die für die einzelnen Vertriebskanäle definierten Prozesse sind immer eng mit den IT-Diensten und IT-Anwendungen verwoben, und diese Verflechtung ist modular, so dass vor allem ein Multi-Channel-System (MCS) erreicht werden kann. MCS bedeutet, dass Kunden z.B. über den Vertriebskanal Kundenservice ein Angebot erhalten können und diese Information anschließend automatisch in den Kundenstammdaten gespeichert wird. Diese Informationen sind in allen Vertriebskanälen sichtbar, so dass der Verkaufsberater direkt beim Kunden eine Vorführung des konkreten Werkzeugs durchführen kann, um einerseits dem 112 Petry et al., 2010, S. 47-67 Produktführerschaft Marktreichweite Operative Excellenz Fokussierung der IT-Strategie <?page no="230"?> 230 Takt 5: Das Projekt in der Organisation Kunden die Handhabung des Produkts und das Wissen über dessen Einsatzgebiet zu vermitteln und andererseits die Kundenbeziehung zu vertiefen. Auf der IT-Seite wird dabei zwischen universellen IT-Diensten und -Anwendungen und spezifischen IT-Diensten und -Anwendungen unterschieden. Universelle IT-Services und -Applikationen sorgen für die nahtlose Umsetzung und Unterstützung von globalen End-to-End-Geschäftsprozessen im Unternehmen. Ein Beispiel hierfür ist der Abrechnungsprozess, der als universell definierte Prozesskomponente abgewickelt wird. Aus der universellen Prozessdefinition wird das Konzept des MCS abgeleitet, das eine Aufteilung in die oben genannten Vertriebs- und Absatzkanäle ermöglicht, wobei diese Kanäle indirekt über das MCS und die globale Prozessdefinition auf die universellen IT-Services hinsichtlich der Stammdaten zugreifen. Für die jeweiligen Distributions- und Vertriebskanäle steht die IT direkt mit den oben genannten spezifischen IT-Services und Anwendungen zur Verfügung. Die folgende Abbildung veranschaulicht die Zusammenhänge aus Sicht der aus der IT-Strategie verfügbaren Struktur einerseits und den globalen Prozessdefinitionen mit den entsprechenden Vertriebskanälen andererseits. Abbildung 227: Realisierung der IT-Strategie auf Basis von globalen Prozess- und Datendefinitionen und des Multi-Channel-Systems (MCS) Für die IT-Strategie ist es unerlässlich, die Geschäftsstrategien zu verstehen und diese dann in eine integrierte IT-Strategie zu übertragen. Im folgenden Beispiel wurde die IT-Strategie in fünf Teilbereiche untergliedert:  Hochverfügbarkeit der IT-Infrastruktur: Eine weltweit einheitliche Infrastruktur sorgt für hohe Verfügbarkeit ‒ die Systeme werden zentral gehostet und sind weltweit zugänglich. Hohe Verfügbarkeit von Computer- und Netzwerkdiensten Internet-basiertes und on-Demand High-Performance Netzwerkverarbeitung Global koordinierter Fokus auf IT- Ressourcenbereitstellung Standardisierte IT- Praktiken und - Werkzeuge Optimierte globale, Workflow-basierte Anwendungen zur Prozess- & Datenverarbeitung F&E Einkauf Produktion Marketing Logistik Vertrieb Finanzen After Market Service Ableitung Multi Channel Service (MCS) Verkaufsberater Zentrale Shop Telefonischer Kundendienst Online-Shop B2B Spezifische IT- Unterstützung, z.B. CRM und Mobile Spezifische IT- Unterstützung, z.B. ERP- Integration Spezifische IT- Unterstützung, z.B. ERP- Integration Spezifische IT- Unterstützung, z.B. Telefonie- Kundenstamm- Integration Spezifische IT- Unterstützung, E-Shop-ERP- Integration Spezifische IT- Unterstützung, EDI-ERP- Integration Spezifische IT- Services Kanäle Infoabgleich MCS Ableitung zu MCS Globale Prozessdefinition Strategie IT-Services Globaler Support (24/ 7) und kontinuierliche Realisierung der IT-Strategie durch Projekte <?page no="231"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 231  Hohe Leistungsfähigkeit der eingesetzten, vollständig vernetzten IT-Infrastruktur: Jede Filialorganisation hat Zugriff auf die Infrastruktur und Anwendungslandschaft.  Ein globales IT-Team: Keine lokalen Teams, sondern drei strategische Standorte gewährleisten Betrieb und Support rund um die Uhr.  Standardisierte IT-Verfahren und -Tools: Die gesamte IT nutzt einheitliche Praktiken und Standardtools sowohl in der Infrastruktur als auch bei den Anwendungen.  Eine optimierte globale Anwendungslandschaft für gemeinsame Prozesse und Kerndaten: ein integriertes Anwendungssystem mit einem strategischen Partner. Der Wertbeitrag der IT wird in enger Partnerschaft mit den Geschäftsbereichen des Unternehmens erzielt. Dies spiegelt sich zum einen in der verbesserten Kundenzufriedenheit und zum anderen in der internen Produktivitätssteigerung wider. Erfolgreiche Praxisbeispiele zeigen, dass dabei die Grenze zwischen IT-Projekt und Geschäftsprojekt de facto aufgehoben werden sollte. Projekte werden gemeinsam geplant und durchgeführt ‒ und das Projektende ist erreicht, wenn der zu Projektbeginn definierte Geschäftsnutzen erreicht ist. Auf Basis dieser Zusammenhänge kann die IT-Strategie (weiter-)entwickelt werden. Das Vorgehen dazu ist in der folgenden Abbildung dargestellt. Abbildung 228: Vorgehensweise bei der IT-Strategie-Entwicklung 113 Im Rahmen der Standortbestimmung erfolgt die Analyse der IT-Situation und -Anforderungen. Es gilt herauszufinden, wie die IT-Organisation aufgestellt ist und seitens der Kunden wahrgenommen wird. Dazu kann ein Fragenkatalog, beispielsweise orientiert am COBIT-Referenzmodell, genutzt werden. 114 Dieser umfasst Fragen zu: • Geschäftsprozessorientierung • Kundenorientierung • operationeller Qualität • Zukunftsorientierung 113 nach Bernhardt et al., 2014, S. 28; Petry et al., 2010, S. 55 114 COBIT (Control Objectives for Information and Related Technology) ist ein internationales Framework zur IT-Governance. Fokussierung Operative Strategieumsetzung Standortbestimmung SWOT, Potenziale, Gaps Strategieformulierung Konzeption, Aktualisierung Taktische Planung der Umsetzung • Bestehende IT-Strategie • Projektportfolio • Geschäftsmodell • IT- & Service Management • Leistungen, Kosten • Anwendungs-/ Produktportfolio • Infrastruktur • Organisation, Personal • IT-Prozesse • Geschäftsstrategie/ -ziele • Externe Anforderungen • Innovationen, IT-Trends • Vision, Zweck/ Rolle der IT • Business Value der IT • IT-strategische Prinzipien • Grundlagen • Agilität • Verlässlichkeit • IT-strateg. Stoßrichtungen • Key Focus Areas • Handlungsfelder • Ziele • Kritische Erfolgsfakt. • Dokumentation • Grundsatzentscheidungen • Roadmap mit Bebauungs- und Vorhabenplanung • Investitionsplanung und Budgetfreigabe • Anpassung laufende Projektplanungen • Anpassung Mehrjahresplanung • Marketing & Kommunikation <?page no="232"?> 232 Takt 5: Das Projekt in der Organisation Beispiel Fragenkatalog Geschäftsprozessorientierung Abbildung 229: Fragenkatalog Geschäftsprozessorientierung ‒ Beispiel IT-Strategien für große Unternehmen nehmen leicht erhebliche Ausmaße an. Daher bietet es sich oftmals an, dass die IT-Strategie zeitlich und inhaltlich in verschiedenen Teilen erstellt bzw. fortgeschrieben wird. Dabei sind folgende Abgrenzungen gebräuchlich: thematische Schwerpunktsetzung entsprechend Nutzenabsicht (siehe nachfolgender Abschnitt) - Begrenzung der geografischen Abdeckung (z.B. nach Regionen) - Abgrenzung nach Geschäftsbereichen - Abgrenzung nach rechtlichen Einheiten Eine Fokussierung mit Blick auf Teilstrategien bzw. Schwerpunkte einerseits oder der Gesamtstrategie andererseits sollte daher das IT-Strategieprojekt eingrenzen. 5.4.2 Nutzen von Strategieprojekten Der Nutzen von IT-Strategieprojekten kann allgemein je nach Unternehmenssituation und Projektauftrag unterschiedlich sein. 115 In einer Studie mit mehr als 400 europäischen Unternehmen hat bspw. BearingPoint folgende Nutzenkategorien identifiziert bzw. deren Häufigkeit ermittelt: 115 siehe auch Bernhardt et al., 2014, S. 17−32 <?page no="233"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 233 Abbildung 230: Häufigkeit eingetretener Nutzeneffekte Die folgende Abbildung liefert eine Einordnung der typischen Nutzenkategorien in die Funktionsbereiche moderner IT-Organisationen. Abbildung 231: Nutzenkategorien und Funktionsbereiche In der Praxis werden typischerweise natürlich nicht alle Nutzenaspekte im Rahmen eines IT- Strategieprojektes verfolgt. Vielfach ergeben sich auch Synergieeffekte. Z.B. ist anzunehmen, dass eine Nutzenkategorie wie „Verbesserte Transparenz/ Steuerbarkeit“ - gleichwohl die am häufigsten genannte - in der Regel nicht unmittelbarer Auslöser oder Einflussfaktor für die Entwicklung der IT-Strategie sein wird, sondern vielmehr gleichsam als „Mitnahmeeffekte“ in vielen verschiedenen Maßnahmen erscheinen. Beim Aufsetzen von IT-Strategieprojekten sollten die genannten Nutzenkategorien systematisch berücksichtigt und im Projektauftrag klar adressiert werden. Dabei empfiehlt es sich, nach Möglichkeit die Ziele mit gezielten Fragestellungen SMART - also spezifisch, messbar, akzeptiert, Markt Operations Lieferanten Enabling von Geschäftsstrategien Management & Steuerung Verbesserte Transparenz/ Steuerbarkeit Kostensenkung/ Produktivitätssteigerungen/ Synergien Reduzierung von IT-Risiken/ Investitionssicherheit Sicherstellung IT-Compliance Etablierung organisatorischer Erfolgsvoraussetzungen Erhöhte Anwender- / Kundenzufriedenheit Sicherstellung Stabilität des IT-Betriebs <?page no="234"?> 234 Takt 5: Das Projekt in der Organisation realistisch und terminiert - zu formulieren; z.B.: „Wie können wir unsere Rechenzentrumskosten bis Ende nächsten Jahres um mindestens 20% senken? “ 5.4.3 Projektportfoliomanagement Die Unternehmensstrategie wird in Form von Projekten operationalisiert, sprich umgesetzt ‒ das gilt natürlich auch für den IT-Bereich. Die beiden zentralen Herausforderungen im Rahmen der taktischen Planung von Projekten gemäß der Unternehmensstrategie sind der möglichst effiziente Einsatz der Ressourcen, insbesondere Personal und Geld, und die Auswahl der Projekte mit dem größten Geschäftsnutzen bzw. Aufwands-Nutzen-Verhältnis. Dazu müssen in einem Projektportfoliomanagement (PPM) Projekte bzw. Anforderungen diesbezüglich mit geeigneten Methoden, Prozessen und Organisationsformen übergeordnet bewertet, verwaltet und gesteuert werden. Dabei sind die Projektlandschaft in ihrer Vielfalt zu visualisieren, die Projekte zu priorisieren und zu kategorisieren, Konflikte aufzulösen, Budgets und Risiken zu managen etc. Sehen Sie dazu ein einleitendes Video. ► Video 5.4 (Einleitung PPM), URL: https: / / youtu.be/ SyrRud8Pe8s Durch richtig eingesetztes PPM können Unternehmen und Fach- und IT-Abteilungen folgenden Nutzen erzielen: 116 - 0ptimaler Projektmix durch strategisches Alignment durch eine zentrale Steuerung aus Business-, IT- und Unternehmenssicht höherer, auch fachbereichsübergreifender Nutzen der Projekte durch Gesamtbetrachtung (nicht isoliert) - Transparenz über die Projektlandschaft, dadurch erleichterte Handhabung von deren Komplexität - Priorisierung der Projekte anhand ihrer Wirksamkeit bzgl. Geschäftsnutzen - Priorisierung und Steuerung der Projekte aus der Perspektive des strategischen IT- und Unternehmensmanagements - Erhöhung der Management-Aufmerksamkeit für das Projektmanagement und dessen Stellenwert Kernaufgabe Priorisierung Mehrprojekt-Situationen führen vielfach zu Problemen, denn parallele Projektaktivitäten konkurrieren häufig um die gleichen Ressourcen (z.B. Personen, Budgets, Infrastruktur usw.). Eine primäre Kernfrage des Projektportfoliomanagements lautet daher: Welche Projekte sollen in welcher Reihenfolge durchgeführt werden bzw. bis zu welchem Grad können Projekte parallelisiert werden? 116 Drechsler et al., 2014, S. 70 <?page no="235"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 235 Abbildung 232: Parallele Projektaktivitäten konkurrieren um Ressourcen Weitere Kernfragen des Projektportfoliomanagements sind: Abbildung 233: Kernfragen des Projektportfolio-Managements Der Wunsch nach Integration von Portfoliosteuerung und Projektmanagement wirft in der Praxis eine Reihe von Herausforderungen auf:  Koordination zwischen den periodischen Linienfunktionen und den lebenswegbezogenen Projektmanagementaufgaben  projektübergreifende Allokation und Steuerung von (Engpass-)Ressourcen  finanzielle Steuerung der Projektlandschaft insgesamt  Behandlung von Niveauunterschieden im Projektportfolio  Umgang mit Unsicherheit bzw. Risiken  Ausrichtung der Projekte an den Unternehmens-/ Organisationszielen A B C D B D C D A Projekt 1 B A F D A D E D C Projekt 2 C F G D E D H D E Projekt 3 Zeit Kernfragen des Portfolio-Managements Welche Projekte werden derzeit durchgeführt? Wie laufen die Projekte? Welche Risiken sind zu erwarten? Wie priorisiere ich bei Konflikten? Bringen die Projekte den erwarteten Mehrwert? Passt Angebot und Nachfrage von Kapazitäten/ Budget? Wer arbeitet an welchem Projekt? Was sind die Kosten u. Aufwendungen für jedes Projekt? Stimmt das Portfolio mit strategischen Zielen überein? <?page no="236"?> 236 Takt 5: Das Projekt in der Organisation  Herstellen von Vergleichbarkeit der Projekte im Portfolio  integrierte Betrachtung von Selektionskriterien und Zwängen bei der Projektpriorisierung  zeitnahe, rollierende Planung, Steuerung und Kontrolle des Projektportfolios  Vermeidung von inhaltlichen Redundanzen bzw. Mehrfachlösungen im Projektportfolio  Interoperabilität mit angrenzenden Führungssystemen Ein Projektportfolio wird typischerweise eben in Portfolioform dargestellt, zumindest auf einer High-Level-Ebene: 117 Abbildung 234: Typische Visualisierung eines Projektportfolios ‒ Beispiel Eine solche Darstellung ist sehr intuitiv und ermöglicht die Visualisierung mehrere Dimensionen der Projekte - im Beispiel der Wert eines betrachteten Parameters der Projekte (z.B. aktueller Fortschritt), das Risiko, das Budget, die Projektart etc. 5.4.4 Nutzwertanalyse Die Nutzwertanalyse (NWA) ist ein Verfahren zur Analyse und Bewertung komplexer Handlungsalternativen mit dem Zweck, diese entsprechend den Präferenzen des Entscheidungsträgers im Hinblick auf sein Zielsystem zu ordnen. Soll unter mehreren, miteinander schwer vergleichbaren Alternativen ausgewählt werden, stellt die NWA ein Instrument zur Bestimmung der vom Entscheidungsträger bevorzugten Alternativen dar. Dazu müssen die Alternativen hinsichtlich parametrisierbarer Kriterien bewertet werden. Eine NWA ist insbesondere geeignet, wenn „weiche“ - also in Geldwert oder Zahlen nicht darstellbare - Kriterien vorliegen, anhand derer zwischen verschiedenen Alternativen eine Ent- 117 vgen.de <?page no="237"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 237 scheidung gefällt werden muss. Und dies ist bei den allermeisten Projekten der Fall. Stehen z.B. vier Projektszenarien zur Auswahl (etwa Eigenentwicklung, Einführung Standardsoftware, Cloud-Lösung oder Outsourcing), könnte eine NWA beispielsweise wie folgt aussehen: Abbildung 235: Nutzwertanalyse − Beispiel Der Gesamtnutzwert ist dann die Summe der Teil-Nutzwerte. ��� Achtung: Der Nutzwert ist nur eine Hilfsgröße, mit deren Hilfe es gelingen soll, Alternativen zu vergleichen. Absolut gesehen hat er keine Aussagekraft. Auch sind geringe Unterschiede zwischen den Nutzwerten zweier Alternativen kein valides Entscheidungskriterium! ▲ Haben Sie eine Idee, wie die „krummen“ Zahlen in dem Beispiel zustande gekommen sind? Die im Beispiel genutzten Kriterien haben folgende Hintergründe: Abbildung 236: Mögliche Kriterien der NWA ‒ Beispiel Nutzwertanalyse PVS 3.0  Kriterium Gew. Szenario 1 Szenario 2 Szenario 3 Szenario 4 Projektierung Realisierungsdauer 5 0 0 0 0 Realisierungsaufwand 10 0 0 0 0 Realisierungsrisiko 10 0 0 0 0 Schnittstellenproblematik 10 0 0 0 0 Qualifizierungsaufwand 5 0 0 0 0 Betrieb Systemhoheit 5 0 0 0 0 Systempflegeaufwand 10 0 0 0 0 Organisationsentwicklung Akzeptanz 10 0 0 0 0 Strategische Ausrichtung 15 0 0 0 0 Organisatorische Optimierung 5 0 0 0 0 Nutzen 15 0 0 0 0 Ergebnis 0 0 0 0 Nutzwertanalyse PVS 3.0 - PosZW  Kriterium Gew. Szenario 1 Szenario 2 Szenario 3 Szenario 4 Projektierung Realisierungsdauer 5 0,71 0,86 -0,86 -0,86 Realisierungsaufwand 10 1,00 0,71 -1,14 -1,00 Realisierungsrisiko 10 0,57 0,71 -0,86 -1,43 Schnittstellenproblematik 10 -1,29 -0,14 -1,29 1,29 Qualifizierungsaufwand 5 0,71 0,43 -0,43 -1,00 Betrieb Systemhoheit 5 0,00 0,43 -0,57 0,86 Systempflegeaufwand 10 -1,14 1,00 -0,57 0,14 Organisationsentwicklung Akzeptanz 10 -0,57 0,71 0,71 1,14 Strategische Ausrichtung 15 -1,29 1,29 0,29 0,29 Organisatorische Optimierung 5 -1,43 1,00 0,86 1,43 Nutzen 15 -1,14 0,86 1,00 1,71 Ergebnis -50,71 75,71 -17,14 33,57 -2 eindeutig negativ beurteilt -1 eher negativ beurteilt 0 neutral 1 eher positiv beurteilt 2 eindeutig positiv beurteilt <?page no="238"?> 238 Takt 5: Das Projekt in der Organisation Etwas allgemeiner gefasste Kriterienkategorien lassen sind folgender Aufstellung entnehmen: Abbildung 237: Bewertungskriterien Das folgende Video befasst sich mit der Synthese des Priorisierungsverfahrens. ► Video 5.5 (Priorisierung), URL: https: / / youtu.be/ xX9p3uyTW_k Viele weitere Techniken zur Handhabung des Projektportfolios kommen zum Einsatz. Diese zu erläutern sprengt den Rahmen dieses Moduls, daher soll im Folgenden (nur) auf das Prozessmodell des (IT-)Projektportfoliomanagement PPM geschaut werden. 5.4.5 Prozessmodell PPM Der prozessuale Zusammenhang zwischen PPM und PM lässt sich zunächst wie folgt darstellen: Abbildung 238: Prozesszusammenhang PPM und PM Hier wird auch deutlich, dass das PPM eine Aufgabe ist, die über die Dauer eines Projektes hinausgeht. PPM ist eine Daueraufgabe, die durchzuführen ist, solange das Unternehmen Projekte durchführt. Dies ist ein fundamentaler Unterschied zur zeitlichen Begrenztheit einzelner Projekte. Projekt-Portfoliomanagement Projekt-Vorgehensmodell Projektmanagement-Prozesse  Business Case  Projektantrag  Entscheid Machbarkeit Ideen Anforderungen.  Statusberichte  Maßnahmen  Abschluss- Bericht Nutzen Nutzung <?page no="239"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 239 Gemäß der Aufgabenvielfalt des PPM lassen sich eine Reihe von Geschäftsprozessen identifizieren, die zur ablauforganisatorischen Umsetzung des PPM beitragen. An der TH Mittelhessen haben wir dazu das in der folgenden Abbildung dargestellte High-Level-Prozessmodell (HL-PM) entwickelt. 118 Abbildung 239: High-Level-Prozessmodell Projektportfoliomanagement Das HL-PM ist grundlegend strukturiert nach dem „FAU-Modell des Geschäftsprozessmanagements (Führungs-, Ausführung- und Unterstützungsprozesse) mit den Prozessbereichen „Strategisches & Normatives PPM“, „Operatives Multiprojektmanagement“ sowie „PPM-System-Bereitstellung“. Fachlicher Kernprozess ist natürlich das Projektmanagement selbst, das zwar die operative Basis des PPM darstellt, aber strukturell vom PPM selbst abgrenzbar ist. Wesentliche Outputs im PPM-Prozess Die folgende Übersicht verdeutlicht die Motivation ausgewählter Prozesse den IT-PPM anhand deren wesentlicher Outputs: Abbildung 240: Wesentliche Outputs im PPM-Prozess 118 s. Hüsselmann, 2024, S. 91 ff. Projektmanagement  Status  Change Requests  Risiken & Chancen  Eskalationen  Projektergebnisse  Abschlussbericht PP-Management System Design  Projektportfolio-Struktur  Strategische Budgets  Scoring-Modell Project Demand Management  Projektinformationen  Projektbewertungen  Projekt-Ranking PP-Authorization  Portfolio-Optimierung  Freigaben, Projektauftrag  Ressourcen  Projekt(e)-Roadmap Performance Management  Status (aggregiert)  Steuernde Maßnahmen  Rahmenbedingungen  Abnahmen Vorgaben | Strategie Innovationen | BVW  Projektantrag  Projektpläne  Ressourcenanforderungen <?page no="240"?> 240 Takt 5: Das Projekt in der Organisation ▲ Stöbern Sie doch einmal in den Prozesssteckbriefen der folgenden einzelnen Geschäftsprozesse! Hier erfahren Sie mehr zu Zweck und Aufgaben der Prozesse! 119 Prozessbezeichnung E2E-Bezeichnung Dt. Entwicklung der Projektportfolio-Managementsystemstrategie Engl. Project Portfolio Management System Strategy Determination Corporate Strategy-to- PPM Strategy Prozesszweck • Übertragung der übergeordneten Unternehmensstrategie auf das Projektportfoliomanagement • strategische Ausrichtung des PPM • Bildung von Teilportfolios Prozessbeschreibung • Definition der strategischen Ausrichtung der Ziele für das PPM • Ableiten von Anforderungen und Leistungsumfang des PPM anhand der allgemeinen Unternehmensstrategie und den Unternehmenszielen • Festlegung der relevanten Unternehmenswertströme Prozessbezeichnung E2E-Bezeichnung Dt. Projektportfolio- Autorisierung Engl. Project Portfolio - Authorization Application-to-Assignment Prozesszweck • Bildung geeigneter Programme innerhalb des Portfolios • Aufstellung eines mit den verfügbaren Mittel realisierbares Projektportfolio • Abstimmung des Projektportfolios mit der Budget- und Ressourcenplanung Prozessbeschreibung • Neupriorisierung von bereits vorhandenen Projekten zusammen mit Fachabteilungen • Entscheidung über ein realisierbares Projektportfolio (Auswahl, Ausbalancierung) treffen • Freigabe und Auslösung von Projekten (Autorisieren) Prozessbezeichnung E2E-Bezeichnung Dt. PPM-Governance Engl. PPM-Governance PPM Strategy-to-Rules & Regulations Prozesszweck • Einführung und Validierung eines effizienten und effektiven Managementsystems für die Projektlandschaft des Unternehmens • Etablierung verbindlicher Bewertungskriterien und Gewichtung für die Projektauswahl 119 s. auch Hüsselmann, 2024, S. 99 ff., dort zu den Prozessen auch weitere Aspekte wie Prozessverantwortliche und -kunden, Nutzenerwartung, Performance Indikatoren sowie Erfolgsfaktoren. <?page no="241"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 241 • Ermöglichung der zielgerichteten Aufteilung des für Projekte vorgesehenen strategischen Budgetrahmens auf die strategisch relevanten Tätigkeitsfelder des Unternehmens Prozessbeschreibung • Aufbau eines Scoring-Modells und Definition der relevanten Projekt-KPIs • Abstimmung des Modells mit dem Management • Festlegung der relevanten Projektkategorien und -typen • laufende Überprüfung und Anpassung des PPM-Systems Prozessbezeichnung E2E-Bezeichnung Dt. Management der Projekt-Anforderungen Engl. Project Demand Management Requirement-to-Assessment Prozesszweck • Projektanträge klassifizieren und bewerten • Interdependenzen feststellen und koordinieren • Bewertung von Projektänderungsanträgen Prozessbeschreibung • Erhebung verfügbarer Informationen zu den laufenden und geplanten Projekten sowie zusätzlicher Projekt-Informationen, die für den Bewertungsprozess („Pitch“) benötigt werden • Konsolidierung der Projektanträge, -klassifizierungen und -bewertungen auf Basis übergreifender Einflussfaktoren • Bewertung und Priorisierung der Projekte auf Ebene der Fachabteilungen (Kosten-Nutzenanalyse, strategischer Beitrag) • Ermittlung der Interdependenzen zwischen den Projekten Prozessbezeichnung E2E-Bezeichnung Dt. Leistungsmanagement Engl. Performance Management Results-to-Measure Prozesszweck • Monitoring und Steuerung der Projekte des Portfolios, um die Effizienz der Projekt- und Programmdurchführung zu gewährleisten (die Dinge „richtig” tun) • Programm-/ Portfolio-Zusammenstellung wird gegebenenfalls zeitnah angepasst, um Verschwendung zu vermeiden Prozessbeschreibung • Etablierung eines periodischen Reporting und Monitoring-Prozesses • Festlegung von standardisierten Berichtsinhalten und -definitionen • Durchführung von regelmäßigen Programm-/ Portfolio-Reviews • Anpassung bzw. Neuausrichtung des Programms/ Portfolios bei Bedarf <?page no="242"?> 242 Takt 5: Das Projekt in der Organisation Prozessbezeichnung E2E-Bezeichnung Dt. Ressourcenmanagement Engl. Resource Management Resource Needto-Provision Prozesszweck • Disposition der Ressourcen (jeder Art, insbesondere auch personeller) in der richtigen Menge zum richtigen Zeitpunkt am richtigen Ort Prozessbeschreibung • Einplanung und Zuweisung der Ressourcen für die Projekte • Erstellung von notwendigen Ausschreibungen und Abschließen von Verträgen mit Partnern und Lieferanten • Schaffung von Transparenz hinsichtlich Angebot und Nachfrage von Ressourcen • Auflösung von Ressourcenkonflikten Prozessbezeichnung E2E-Bezeichnung Dt. Nutzenmanagement Engl. Benefits Management Business Case-to-Valuation Prozesszweck • Sicherstellung, dass die Nutzenerwartung, die mit der Genehmigung von Projekten verbunden wird, überwacht und festgestellt wird sowie ggf. korrigierende Maßnahmen ergriffen werden - nicht zuletzt auch nach dem Projektende Prozessbeschreibung • Identifikation, Definition, Planung, Realisierung und Verfolgung von Benefits (gewünschte Wirkung einer Investition) • Erheben und Überwachen des Nutzen-Realisierung-Verhältnisses des Projektportfolios • Sammeln von gewonnenen Erkenntnissen und Kommunikation über das gesamte Projektportfolio • Etablierung von Methoden & Standards zur Identifikation eingetretenen Nutzens sowie zur Planung von Nutzen-Revisionen Prozessbezeichnung E2E-Bezeichnung Dt. Entwicklung von Methoden & Tools Engl. Development of PPM- Methods & Tools Requirement-to-Tool Prozesszweck • Operative Methoden und Werkzeuge (Tools, insbesondere IT-Systeme) für die Prozesse des operativen Multiprojektmanagements und des strategisch & normativen Projektportfoliomanagements bereitstellen, damit der PPM-Prozess gesamtheitlich effizient und effektiv durchgeführt werden kann • Sicherstellung von Nutzbarkeit, Effizienz und Qualität eingesetzter Instrumente Prozessbeschreibung • Methoden und Tools (M&T) des PPM und des Einzel-Projektmanagement entwickeln • Standards definieren • Unterstützung bei der Anwendung der Methoden & Tools (Coaching, Schulung, …) • Weiterentwickeln der Methoden & Tools • Steuerung der Änderungsanträge zu diesen Werkzeugen <?page no="243"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 243 Prozessbezeichnung E2E-Bezeichnung Dt. Betrieb des PPM-Systems Engl. PPM-System Operations Tool-to-Usage Prozesszweck • Trägt dazu bei, ein stabiles und zuverlässiges PPM-(IT-)System zu unterhalten • Stellt sicher, dass Belegschaft und Management des Unternehmens (IT-)Tool-seitig unterstützt werden, um die gewünschten Ergebnisse zu erzielen Prozessbeschreibung • Installation, Konfiguration, Automatisierung, Überwachung, Sicherung, Verwaltung und Problembehebung der PPM-(IT-)Systeme • Verwaltung der allgemeinen Benutzerrechte und -zugriffe Prozessbezeichnung E2E-Bezeichnung Dt. Informations- & Wissensmanagement Engl. Information & Knowledge Management Data-to-Knowledge Prozesszweck • Informationszugang und -austausch in der gesamten PPM-Organisation sicherstellen • Ermöglichen eines zielgerichteten Zugriffs auf vorhandenes Wissen zur Vermeidung von Doppelarbeiten, zur Effizienzsteigerung und zur Erhöhung der Ergebnisqualität in der Projekt arbeit Prozessbeschreibung • Erfassen, Verarbeiten, Aufbereiten, Speichern und Bereitstellen der relevanten Informationen mit Bezug zur Projektarbeit zur richtigen Zeit, am richtigen Ort und im richtigen Medium/ Kanal • Kommunikation der Informationen an die betroffenen Ebenen und Personen Prozessbezeichnung E2E-Bezeichnung Dt. Management der Kunden & Stakeholder Engl. Client & Stakeholder Management Interests-to-Measure Control Prozesszweck • Die Einflussgruppen des PPM akzeptieren und unterstützen im Idealfall das System • Negativ eingestellte Einflussgruppen können das PPM-System nicht „torpedieren“ Prozessbeschreibung • Bedürfnisse der wichtigsten Interessensgruppen ermitteln und bei der PPM-Durchführung berücksichtigen • Ableiten geeigneter Maßnahmen aus den ermittelten Bedürfnissen der Stakeholder • Ebenen übergreifende Umsetzung und Anwendung der Maßnahmen • Überwachen der Stakeholder-Entwicklung <?page no="244"?> 244 Takt 5: Das Projekt in der Organisation Prozessbezeichnung E2E-Bezeichnung Dt. Chancen- & Risikomanagement Engl. Risk & Opportunity Management Risk Uncertainty-to- Measure Control Prozesszweck • Sicherstellung, dass unsichere, ungeplante Einflussfaktoren, die ggf. auf den Erfolg von Projekten einwirken, entweder handhabbare Auswirkungen (Gefahren/ Risiken i.e.S.) haben oder aktiv genutzt werden (Chancen, d.h. Risiken i.w.S.) Prozessbeschreibung • Durchführung von Risikoidentifikation, Risikoanalyse, Risikobewertung, Risikovorsorge, Risikoüberwachung und Risikosteuerung auf Portfolioebene • Identifizierung, Analyse von übergreifenden Chancen und Gefahren (sog. „Known Unknowns“) • Beherrschung von Gefahren • Nutzung von Chancen • Vorgabe von Methoden & Standards zum übergreifenden Risikomanagement Diese Prozesse durchlaufen den schon bekannten Plan → Do → Check → Act-Zyklus … und zwar unter ganz vielfältigen Blickwinkeln. Schauen Sie dazu einmal in das folgende Video. ► Video 5.6 (PPM-Lifecycle), URL: https: / / youtu.be/ AisukqzC-iI Erfolgsfaktor Regelmäßige Überprüfung Erfolgreiche Unternehmen führen periodisch wiederkehrende Prozesse durch, in denen das komplette Portfolio überprüft wird: • Ein effektives Portfolio-Management hängt u.a. davon ab, wie oft das Portfolio überprüft wird. • Im Falle von Fehlentwicklungen kann dann umso rascher gegengesteuert werden. • Je häufiger das Portfolio überprüft wird, desto schneller können notwendige Kurskorrekturen vorgenommen werden. (GJP: Geschäftsjahresplanung) Abbildung 241: PPM-Prozesszyklen im Geschäftsjahr ‒ Beispiel <?page no="245"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 245 Zusammenfassend lassen sich folgende Erfolgsfaktoren für das Projektportfoliomanagement aufführen: • Ziele und Nutzen des Portfolio-Managements müssen intern klar aufzeigt werden. • Unterstützung durch das Top-Management muss sichergestellt sein. • Rollen, Verantwortungen und Zuständigkeiten für das Portfolio-Management müssen definiert sein. • Für jeden Prozessschritt müssen die Ziele und notwendigen Inputs an Informationen klar beschrieben sein. • Integration in den bestehenden Planungs- und Budgetierungsprozess muss sichergestellt sein. • Enge Verzahnung mit etablierten Projekt- und Programm-Management muss gegeben sein. • Aktualität, Richtigkeit und Vollständigkeit der Inputdaten müssen sichergestellt sein. • Das Projektportfolio muss regelmäßig überprüft und aktualisiert werden. und schließlich • Das Projektportfoliomanagement sollte durch ein adäquates IT-System unterstützt werden. 5.4.6 Überblick IT-PM-Software Zum organisationellen Projektmanagementsystem gehört auch eine adäquate IT-Unterstützung. Die Unternehmensberatung TPG - The Project Group spricht hinsichtlich einer idealen IT-Unterstützung vom „PPM-Paradies“. 120 Schauen Sie sich dazu doch zunächst das kurze Einleitungsvideo an. ► Video 5.7 (PPM-Paradise), URL: https: / / youtu.be/ idyxbrDtJfM Paradiesische Zustände herrschen demnach, wenn die PM-Software alle aufgeführten Aufgabenbereiche intuitiv und integrativ abdeckt. Schöne Welt, die oftmals in der Praxis nicht wirklich zu erreichen ist. Wie im Video bereits gezeigt, gilt es vielfach, die PM-Software in die ERP- Systemlandschaft zu integrieren - wenn man so will, die projektbezogenen Lücken zu stopfen. Kaum einer Software gelingt es, alle gewünschten Funktionalitäten und Aufgaben gleich gut abzudecken. Gleich einem unhandlichen Schweizer Messer wären das folgende Elemente: Abbildung 242: Funktionen von PM-Software 120 TPG, 2016 <?page no="246"?> 246 Takt 5: Das Projekt in der Organisation Wie auch für ein solches Monster-Schweizer Messer - das gibt es - gilt für die gesuchte Software à la „eierlegende Wollmilchsau“: ist nicht wirklich nutzbar! Wo sehen Unternehmen den größten Bedarf an einer IT-Unterstützung im (Multi-)Projektmanagement? Schauen wir dazu einmal in eine empirische Untersuchung, die Seidl vor einigen Jahren veröffentlicht hat: 121 Abbildung 243: IT-Unterstützung im (Multi-)PM Bringen wir also zunächst einmal ein wenig Struktur in die Vielfalt der Systeme. (Multi-)PM-Software ist kein klar definiertes Produkt und lässt sich in folgende Klassen einteilen. 122 Dabei lassen sich „Einzel-PM-SW“ und „Multi-PM-SW“ unterscheiden: Abbildung 244: Klasseneinteilung (Multi-)PM-Software Planungs-Software Netzpläne, Balkenpläne, Projektstrukturpläne, Anforderungslisten, … erstellen und pflegen Ressourcenverwaltungs-Software Ressourcen (Mitarbeiter, Maschinen, Räume, …) den Aufgaben zuordnen und ihre Auslastung steuern 121 Seidl, 2011, S. 161 122 vgl. projektmagazin , 2015 26,2% 24,6% 21,3% 16,4% 14,8% 11,5% 8,2% 6,6% 4,9% 4,9% 3,3% 3,3% 3,3% 11,5% 0% 5% 10% 15% 20% 25% 30% Multiprojektsteuerung allgemein Ressourcen- und Kapazitätsmanagement Projektportfolio-Reporting, Transparenz Umgang mit Abhängigkeiten/ Komplexität Einheitliche Datenbasis, Datenkonsolidierung Planung Wissensbasis & Wissensmanagement Priorisierung Ablauf- und Terminmanagement (derzeit) kein Bedarf Überwachung des Nutzens/ strategischer… Aufwands- und Kostenmanagement Qualitätsmanagement Sonstige <?page no="247"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 247 Rechnungswesen- & Controlling-Software Kostenträger & -stellen den Projekten zuordnen und ihre Auslastung steuern Aufwandserfassung, buchhalterische Kontrolle des Projektbudgets, Überwachung des inhaltlichen Projektfortschritts sowie der Termintreue und zur Prognose der Schlüsselkennzahlen SW-Lösungen für spezielle PM-Aufgaben Konfigurations-, Qualitäts-, Risiko-, Aufgaben-Management, Wirtschaftlichkeitsrechnungen, Prozessoptimierung, Journale, … Dokumentenmanagementsysteme Verwaltung und Archivierung der Projektdokumente Kollaborations-Plattformen Projektkommunikation, Unterstützung von Projektprozessen, Workflows Programme für Mehrprojekttechnik und Projektportfoliomanagement Gesamtansichten des unternehmensweiten Projektportfolios, für das Top-Management Standard-Büro-Software Textverarbeitung, Tabellenkalkulation, Präsentation und/ oder Datenbankverwaltung, … Telekommunikationssoftware E-Mail-Clients, Browser, Videokonferenzen, … PM-SW wird oftmals im Kontext von Multi-Projekt-Situationen eingesetzt. MPM-SW lässt sich wiederum wie folgt klassifizieren: Abbildung 245: Klassifizierung Multi-PM-Software Die Landschaft der MPM-Software-Anbieter ist sehr vielfältig und dynamisch. Generell lassen sich folgende Anbietertypen unterscheiden: PM-Spezialisten, (ERP-)Komplettierer sowie Spin- Offs (großer IT-Anbieter). Hier eine Auswahl - ohne Anspruch auf Vollständigkeit und ohne Wertung: <?page no="248"?> 248 Takt 5: Das Projekt in der Organisation Abbildung 246: Landschaft der MPM-Software-Anbieter Im Leistungsumfang stehen dabei, wie bereits ausgeführt, Einzelprojektmanagement, Mehrprojektmanagement und Projektportfolio-Management - oft mit fließenden Übergängen. Vielfach wird PM-SW komplementär zur Enterprise Resource Planning-Systemen eingesetzt. Schauen wir einmal auf die Integration von PPM-Software und ERP-System etwas detaillierter: ► Video 5.8 (ERP-Integration), URL: https: / / youtu.be/ EmYa14nJj8E Im Internet findet sich eine Reihe von Portalen bzw. Marktforschungs- oder Beratungsunternehmen, die Vergleiche von IT-Anbietern für Projektmanagement durchgeführt haben. Vielleicht werden Sie hier fündig: ###QR Code oder hier: ###QR Code Abbildung 247: Infos zu aktuellen PM-Software-Anbietern <?page no="249"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 249 Die Vielfalt der Anbieter macht es deutlich: ��� Die Auswahl und Einführung einer (Multi-)PM-Software erfordert ein systematisches Vorgehen! Das projektmagazin sowie ein Arbeitsergebnis zum „Auswahlprozess für Projektmanagement- Software“ der Fachgruppe Software für PM-Aufgaben der GPM formulieren dazu wie folgt: Vorgehensmodell „Der häufigste und schwerwiegendste Fehler, der beim Kauf einer PM-Software gemacht wird, besteht darin, dass man glaubt, mit dem Tool würde man zugleich Projektmanagement einführen. Dies führt nicht nur mit absoluter Sicherheit zum Scheitern des Vorhabens, sondern mit großer Wahrscheinlichkeit sogar dazu, dass alle Betroffenen sowohl PM als auch die Software auf Dauer ablehnen werden.“ „Voraussetzung für die Einführung einer PM-SW: etablierte, akzeptierte und gelebte PM-Prozesse“. Daraus abgeleitet ergibt sich prinzipiell folgendes Vorgehensmodell: Abbildung 248: PM-SW-Einführung ‒ Vorgehensmodell Die Anforderungen werden dabei in einem Kriterienkatalog definiert, der unterschiedliche Aspekte in typischerweise vier Kriteriengruppen umfasst 123 , wie in Abbildung 249 gezeigt. Mit Hilfe dieses Katalogs und der darauf basierenden Analyse möglicher Anbieter (→ Shortlist) lässt sich dann eine Nutzwertanalyse, die wir ja auch schon im Zusammenhang mit der Projektauswahl kennengelernt haben, durchführen, wie in Abbildung 250 dargestellt. 123 nach Thome, 2007, S. 12, modifiziert <?page no="250"?> 250 Takt 5: Das Projekt in der Organisation Abbildung 249: MPM-SW-Auswahl mit Kriterienkatalog Abbildung 250: Nutzwertanalyse zur MPM-SW-Auswahl Strategien zur Prüfung der Software Abbildung 251: Strategien zur Prüfung der Software Teil A Rahmenbedingungen • Kostenrahmen • Allgemeine Funktionalitäten • Betriebssystem • Datenbank • Schnittstellen Teil B Funktionale Abdeckung • Struktur- & Zeitplanung • Multiprojektmanagement • Ressourcen- & Kostenplanung • Berichtswesen/ Dokumentation • Ist-Datenerfassung • Projektsteuerung Teil C Branchenlösungen • Schnittstellen • Branchenspezifische Funktionen Teil D Anbieterleistungen • Installationen/ Referenzen • Finanzierungskonzept • Kosten pro Arbeitsplatz • Dienstleistungen/ Service Kriterienkatalog Teil A Rahmenbedingungen • Kostenrahmen • Allgemeine Funktionalitäten • Betriebssystem • Datenbank • Schnittstellen Teil B Funktionale Abdeckung • Struktur- & Zeitplanung • Multiprojektmanagement • Ressourcen- & Kostenplanung • Berichtswesen/ Dokumentation • Ist-Datenerfassung • Projektsteuerung Teil C Branchenlösungen • Schnittstellen • Branchenspezifische Funktionen Teil D Anbieterleistungen • Installationen/ Referenzen • Finanzierungskonzept • Kosten pro Arbeitsplatz • Dienstleistungen/ Service Kriterienkatalog Auswahl: Bewertung: <?page no="251"?> 5.4 Management der Projektlandschaft ‒ speziell der IT 251 Die Erfüllung der wesentlichen Anforderungen sollte ernsthaft und angemessen geprüft werden. Die funktionalen Anforderungen können dabei anhand des erwarteten Implementierungsrisikos sowie des geschätzten Implementierungsaufwands klassifiziert werden. Hieraus lässt sich dann die Strategie zur Prüfung und Vorauswahl ableiten 124 , wie in Abbildung 251 wiedergegeben. Abschließend folgt nun noch eine Zusammenfassung des letzten Takts im Video. ► Video 5.9 (Wrap-up), URL: https: / / youtu.be/ HaUSFtFJJbM Wenn Sie aktuell Projekte managen oder ein Projektportfolio verantworten, sind Sie mit hoher Wahrscheinlichkeit bereits mit dem Thema Künstliche Intelligenz konfrontiert - oder werden es in Kürze sein. Das folgende Kapitel gibt daher ergänzend einen kurzen Überblick, wie KI praktisch im Projektmanagement eingesetzt werden kann und worauf Sie dabei achten sollten. 5.4.7 Einsatz von Künstlicher Intelligenz Was ist Künstliche Intelligenz? Künstliche Intelligenz (KI) beschreibt die Fähigkeit von Softwaresystemen, Aufgaben zu lösen, für die normalerweise menschliche Intelligenz erforderlich ist - z. B. Mustererkennung, Sprachverarbeitung oder Entscheidungsfindung. Ein wichtiger Teilbereich ist das maschinelle Lernen, bei dem Systeme aus bestehenden Daten eigenständig Regeln und Modelle ableiten, anstatt jede Entscheidung vorab zu programmieren. Als generative KI werden Systeme bezeichnet, die eigenständig neue Inhalte erstellen können - etwa Texte, Bilder, Audios oder sogar Softwarecode. Diese basieren häufig auf sogenannten Large Language Models (LLMs), wie GPT (Generative Pre-trained Transformer), die mit Milliarden von Parametern trainiert wurden. Allgemeine Anwendungsfelder von KI - Automation - KI verändert Arbeitsprozesse: KI unterstützt die Automatisierung repetitiver Aufgaben. Beispielsweise können Rechnungsprozesse, E-Mail-Filter oder Dokumentenerstellung automatisiert werden. Das schafft Freiräume für wertschöpfende Tätigkeiten. - Insights - KI verändert Entscheidungsprozesse: Durch die Analyse großer Datenmengen generiert KI Business-Insights - etwa Kundenverhalten, Markttrends oder interne Schwachstellen. Diese Erkenntnisse verbessern die Entscheidungsqualität erheblich. - Engagement - KI verändert Kundeninteraktionen: KI kann Kundenbedürfnisse antizipieren und dynamisch auf sie eingehen - z. B. durch Chatbots, personalisierte Angebote oder automatisierte Servicevorgänge. - Creation - KI unterstützt kreative Prozesse: Generative KI kann Vorschläge für Logos, Präsentationen, Texte, Produktdesigns oder sogar Forschungsansätze liefern. Sie fungiert als „kreativer Co-Pilot“. Spezifischer Einsatz von KI im Projektmanagement Die genannten Prinzipien lassen sich zielgerichtet auf das Projekt- und das Projektportfoliomanagement übertragen: 124 Seidl, 2011, S. 181 <?page no="252"?> 252 Takt 5: Das Projekt in der Organisation 1. Anwendungsbeispiele im operativen Projektmanagement ̶ Projektanträge: Generative KI erstellt aus einer kurzen Beschreibung automatisch strukturierte Entwürfe für Projektanträge mit Zielen, Budget- und Zeitrahmenvorschlägen. ̶ Risikobewertungen: Aus historischen Projektdaten kann KI typische Risiken ableiten und diese kategorisieren - inklusive Eintrittswahrscheinlichkeiten. ̶ Stakeholder-Analysen: Basierend auf vorhandenen Kommunikationsdaten kann KI relevante Stakeholder und potenzielle Konfliktfelder identifizieren. ̶ Statusberichte: Regelmäßige Fortschrittsberichte können automatisiert aus Aufgaben-, Zeit- und Budgetdaten generiert werden - im passenden Layout. 2. Anwendungsbeispiele im Projektportfoliomanagement ̶ Datenanalyse und Mustererkennung: KI kann Trends und wiederkehrende Muster im Projektportfolio erkennen - z. B. typische Verzögerungen oder Ressourcenkonflikte. ̶ Priorisierung von Projekten: KI kann anhand von strategischen Zielwerten automatisiert Empfehlungen für Projektprioritäten geben. ̶ Prognose von Projektverläufen: Auf Basis von Echtzeitdaten können Wahrscheinlichkeiten für Projekterfolg oder -verzögerung abgeleitet werden. Versuche diesbezüglich bei einem großen Telekommunikationsunternehmen haben aber auch gezeigt: Hier ist eine Kosten-Nutzen-Analyse unerlässlich, denn die Verfügbarmachung korrekter, nutzbarer Datensätze bedeutet in der Regel einen nicht unerheblichen Aufwand. Chancen und Risiken beim Einsatz generativer KI Chancen • Schnelligkeit: erste Entwürfe für komplexe Dokumente in Minuten • Standardisierung: einheitlichere Ergebnisse bei wiederkehrenden Formaten • Effizienz: weniger Aufwand bei Analyse, Dokumentation und Reporting Risiken • Scheinkompetenz durch Sprachqualität: KI-generierte Texte wirken häufig fundiert - auch wenn sie es faktisch nicht sind. Ohne menschliche Kontrolle drohen inhaltliche Fehler. • Datenschutz & IP-Schutz: Sensible Daten dürfen nicht unreflektiert über KI-Plattformen verarbeitet werden. Firmen sollten klare Richtlinien und eigene geschützte KI-Instanzen nutzen. • Bias & ethische Fragestellungen: KI kann Vorurteile aus Trainingsdaten übernehmen. Entscheidungen dürfen nicht automatisiert getroffen werden, wenn sie Mitarbeitende oder Kunden unmittelbar betreffen. Zukunftsausblick: KI im PM - wohin geht die Reise? In weingen Jahren wird KI tief in die Projektarbeit integriert sein. Folgende Entwicklungen sind absehbar: • Virtuelle PM-Assistenten: KI-gestützte Projektassistenten übernehmen Terminabsprachen, Erinnerungssysteme, Meeting-Protokolle oder Aufgabenverteilung. • Adaptive Projektplanung: KI passt Projektpläne in Echtzeit an Veränderungen an (Ressourcen, Markt, Technologien). • Selbstlernende Portfoliosteuerung: Systeme lernen aus Erfolg und Misserfolg und schlagen neue Steuerungslogiken vor. <?page no="253"?> 5.5 Transferaufgaben Takt 5 253 Der Einsatz von KI - insbesondere generativer Systeme - eröffnet im Projektmanagement große Potenziale, birgt aber auch neue Verantwortlichkeiten. Wer die Chancen nutzt und die Risiken kontrolliert, wird produktiver, schneller und zukunftsfähiger arbeiten können. Die Devise lautet: „Menschliche Steuerung - maschinelle Unterstützung.“ KI wird Projektmanager nicht ersetzen, aber sie massiv entlasten und ihre strategische Rolle stärken. To be continued … 125 5.5 Transferaufgaben Takt 5 Sie haben im Verlauf der Transferaufgaben dieses Moduls vermutlich und hoffentlich einige Erkenntnisse zum Zustand des Projektes oder des Projektmanagements Ihrer Organisation gewonnen. 5.5.1 Lessons Learned ▲ Bereiten Sie doch einmal Ihre Lessons Learned in Form des im Modul vorgestellten Starfish auf. Natürlich können und sollten hier ggf. noch weitere Aspekte Eingang finden. ▲ Was werden Sie unmittelbar nach dem Studium es Buches als Erstes umsetzen? 5.5.2 Lösungen ▲ Haben Sie eine Idee, wie die „krummen“ Zahlen in dem Beispiel zustande gekommen sind? → Mittelwertbildung im Team 5.5.3 Projektportfolio Ein Projekt kommt selten allein … und das bereitet in der Regel Konflikte bei der Frage bezüglich der adäquaten Allokation der zur Verfügung stehenden Ressourcen. Welche Projekte existieren in Ihrer Organisation? ▲ Befüllen Sie doch einmal eine visuelle Projektportfoliodarstellung mit den Projekten, die Sie überblicken können. Nutzen Sie dabei die Dimensionen Nutzen, Risiko und Kosten (Budget) für die Darstellung jedes Projekts. ▲ Wie sind das Projektportfolio oder der dargestellte Ausschnitt daraus zu bewerten? Sind die Projekte bezüglich der Dimensionen stimmig ausgewählt? Viel Spaß bei der Bearbeitung! ��� Sollten Sie bei der Beantwortung dieser Fragen ein Projekt mit einem klaren und eindeutigen „Missmatch“ identifizieren … dann wäre dieses Projekt ein Kandidat für einen unmittelbaren Stopp … (? ) 125 Dank an ChatGPT für das Redigieren meines Textentwurfs zu diesem Unterkapitel. <?page no="254"?> 254 Takt 5: Das Projekt in der Organisation 5.6 Zum Abschluss des Buches … ��� 10 Tipps für erfolgreiche (IT-)Projekte Die folgenden zehn Regeln von Campana & Schott bieten eine pragmatische und praxiserprobte Orientierung, wie Sie IT-Projekte zum Erfolg führen können. 126 Unterschiedliche Interessensgruppen wie etwa Anwender, Projektteam und Management, müssen unterschiedlich „abgeholt“ werden, damit das IT-Projekt den gewünschten Erfolg hat. Bei IT-Projekten sollte daher zusätzlich zum Projektmanagement auch dem Veränderungsmanagement (Management of Change) besondere Aufmerksamkeit gewidmet werden. 1. Projektauftrag klar definieren Ein Projektauftrag dokumentiert die Projektziele und die zeitlichen sowie finanziellen Rahmenbedingungen. Der Auftrag gilt als eine Art „Vertrag“ zwischen dem Geldgeber für das Projekt und dem Projektleiter. Am Projektende bildet er die Grundlage für die Abnahme der Projektergebnisse und damit den Projekterfolg. Achten Sie daher bei der Definition des Projektauftrags auf eine Zielbeschreibung nach dem SMART-Prinzip: specific, measurable, accepted, realistic, timely. 2. Betroffene zu Beteiligten machen Binden Sie die zukünftigen Anwender des IT-Systems frühzeitig und regelmäßig in das Projekt ein. Eine Stakeholderanalyse zu Projektbeginn hilft, Interessensgruppen zu identifizieren und diese über den gesamten Projektverlauf mit Informationen zu versorgen. Dabei empfiehlt es sich, gemeinsam mit den Beteiligten eine rollenspezifische Nutzenargumentation zu erarbeiten. Indem Sie den Anwendern aufmerksam zuhören, erkennen Sie deren Leidensdruck und können die Erwartungshaltung besser steuern. 3. Projekt sinnvolle Arbeitspakete unterteilen Egal ob ein IT-Projekt klassisch oder agil vorgeht, reduzieren Sie die Komplexität und lassen Sie wenn möglich recht schnell vorzeigbare Ergebnisse für die Anwender entstehen. Folgen Sie dabei einem im Unternehmen standardisierten Phasen-Ansatz. Zum Ende einer jeden Phase (Stage Gate) sorgen Sie dafür, dass der Projektleiter in Abstimmung mit dem Lenkungsausschuss bewusst die Entscheidung für den Fortgang oder den Abbruch des Projekts trifft. „Wenn du entdeckt hast, dass du ein totes Pferd reitest, steig ab.“ Diese indianische Weisheit hilft Ihnen, Kosten zu sparen und schont die Nerven aller Projektbeteiligten. 4. Projekt(kern)team klein halten Ein kleines Projektteam reduziert die Abstimmungsaufwände. Entscheidungen lassen sich schneller treffen. Definieren Sie gleich zu Projektbeginn Spielregeln zur Zusammenarbeit. Diese Spielregeln sorgen für eine offene Kommunikation und bieten auch im Konfliktfall eine Orientierung. Wenn möglich führen Sie das Projektteam räumlich in einem Büro zusammen. Sorgen Sie dafür, dass es für jedes Meeting eine Agenda gibt und dass Protokoll geführt wird. Klären Sie die Verantwortlichkeiten und harmonisieren Sie diese mit den Jahreszielen. Das schafft einen zusätzlichen Anreiz, das Projekt zum Erfolg zu führen. 126 Verspohl, 2013 <?page no="255"?> 5.6 Zum Abschluss des Buches … 255 5. Umgang mit Change Requests definieren Die einzige Konstante ist der der Wandel. Hinterfragen Sie Änderungswünsche während der Projektdurchführung kritisch und prüfen Sie sie auf ihre Sinnhaftigkeit / Plausibilität. Zeigen Sie die finanziellen und zeitlichen Auswirkungen auf. Die Aufnahme, Bewertung, Priorisierung, Einplanung und Umsetzung von Change Requests erfordert einen klar definierten Prozess. Bei komplexen IT-Systemen hat sich darüber hinaus die Ernennung eines Systemarchitekten bewährt, der die Auswirkungen einer Änderung auf das Gesamtsystem im Blick behält. 6. Abnahme-Prozess formalisieren Legen Sie direkt zu Projektbeginn den Abnahmeprozess für die Spezifikation und den User Acceptance Test fest: Für die Abnahme der Spezifikation empfiehlt sich ein kleines Excel- Dokument, in dem die Reviewer den alten und den gewünschten neuen Text beschreiben. Wichtig sind klar definierte Zeitfenster für die Abnahmen, um diese frühzeitig bei den freigebenden Personen einzuplanen und Verzögerungen zu vermeiden. Für die Testphase sollten dokumentierte Testfälle bereitstehen. Der erfolgreiche Abschluss dieser Testfälle führt automatisch zur Systemabnahme. 7. Projektmanagement leben 90 Prozent des Projektmanagements sind Kommunikation! Der Rest lebt von der Erfahrung und dem Fingerspitzengefühl des Projektleiters und des gesamten Projektteams. Gute Stimmung im Projekt sorgt für ein gutes Arbeitsklima und die Extraportion an Motivation. Ein gemeinsames Frühstück am Morgen stärkt beispielsweise den Teamzusammenhalt. Ein aktives Risikomanagement analysiert mögliche „Worst-Case-Szenarien“ bereits im Vorfeld und sieht geeignete Gegenmaßnahmen vor. Eine Projektkultur im Unternehmen, die ihren Namen verdient, und die Einbindung in ein Portfoliomanagement sind weitere Rahmenbedingungen für erfolgreiches Projektmanagement. Wo professionelles Projektmanagement als Bestandteil der Unternehmenskultur verstanden wird, zeigt sich das zum Beispiel in Form von Projekt-Management-Karrierepfaden und/ oder bestimmten Befugnissen gegenüber der Linie. 8. Management of Change: die Anwender abholen, wo sie stehen Ohne zufriedene Anwender kein Projekterfolg. Die Veränderungen, die Sie lange geplant haben, sind für die unterschiedlichen Anwender neu und ungewohnt. Ängste der Anwender können den Erfolg von Projekten unnötig gefährden. Begleiten Sie die Anwender daher in der Zeit nach der Umstellung. Die obligatorische Anwenderschulung und -dokumentation alleine reichen dafür nicht; planen Sie nach dem Go-live ca. 6 Wochen „Hypercare“ ein. Stellen Sie dem Anwender einen „Kümmerer“ oder „Key User“ zur Seite, der ihm bei Problemen hilft und seine Fragen beantwortet. Sie reduzieren dadurch Ängste im Umgang mit dem neuen IT-System und können noch wertvolle Verbesserungsvorschläge aufnehmen. 9. Übergabe in den Betrieb sicherstellen Indem Sie als Projektleiter die Übergabe in den Betrieb begleiten und dokumentieren, schaffen Sie die Voraussetzung dafür, dass Sie sich mit dem Projektende neuen Aufgaben zuwenden <?page no="256"?> 256 Takt 5: Das Projekt in der Organisation können. Der Betrieb ist in der Lage, Probleme und Änderungswünsche eigenständig zu beheben bzw. umzusetzen. 10. Lessons Learned umsetzen Schaffen Sie die Voraussetzung für eine lernende Organisation: Werten Sie mit Ihrem Team bei einer Projektabschluss-Veranstaltung die gemachten Erfahrungen aus, bereiten Sie diese auf und geben sie Ihre „Lessons Learned“ an die Projektmanagement-Community im Unternehmen weiter. Nur so erreichen Sie, dass auch Ihre Kollegen aus Ihren Projekterfahrungen lernen können und die Effizienz bei der Projektdurchführung verbessert wird. Happy Projects! Viel Erfolg in Ihren Projekten! <?page no="257"?> Anhang Quellen und weiterführende Literatur Agile Business Consortium (Hrsg.) (2019): Agile Project Management Handbook. V2. Agile Business Consortium. Stationery Office Books. London (GB) Axelos (Hrsg.) (2017): Managing Successful Projects with PRINCE2. Axelos. The Stationery Office Ltd. London (GB) Balzert, H. (2010): Lehrbuch der Software-Technik, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, Spektrum Akademischer Verlag. Heidelberg Barton, T. / Herrmann, F. / Meister, V. / Müller, C. / Seel, C. / Steffens, U. (Hrsg.) (2018): Prozesse, Technologie, Anwendungen, Systeme und Management 2018. Angewandte Forschung in der Wirtschaftsinformatik 2018. 31. AKWI-Jahrestagung. Hamburg, 09.09.2018 bis 12.09.2018. Arbeitskreis Wirtschaftsinformatik an Fachhochschulen. Heidemann Buch Bernert, C. / Scheurer, S. / Wehnes, H. (Hrsg.) (2024): KI in der Projektwirtschaft. Was verändert sich durch KI im Projektmanagement? UVK Verlag (GPM Trend). München Bernhardt, M. / Correnz, W. / Hamidian, K. (2014): IT-Strategie: Abwarten lohnt nicht. In: Lang et al., 2014, S. 17‒32 Blust, M. (2019): Methoden, Chancen und Risiken hybrider Projektmanagementvorgehensmodelle. PVM2019. GI. Lörrach, 24.10.2019 Boehm, B.W. / Turner, R. (2003): Observations on Balancing Discipline and Agility. In: Proceedings of the Agile Development Conference (ADC’03) Buch, A. / Cholewa, J. (2021): Cut-Over - der unterschätzte Teil in Migrationsprojekten. Online: https: / / www.it-finanzmagazin.de/ cut-over-der-unterschaetzte-teil-in-migrationsprojekten- 116398/ , abgerufen am 03.03.2022 Burghardt, M. (2008): Projektmanagement, 8. Aufl., Publics Corporate Publishing. Erlangen Büttgen, M. / Fabricius, G. (Hrsg.) (o.J.). Planungsverhalten im Projektmanagement. Online: https: / / www.gpm-ipma.de/ fileadmin/ user_upload/ GPM/ Know-How/ Ergebnisbericht_Studie_Planungsverhalten.pdf. abgerufen am 01.12.2018 Colledge, B. (2004): Relational Contracting - Creating Value Beyond the Project. In: Tagungsband zum Relational Contracting Symposium. S. 1‒19. Atlanta (US) Crameri, M. / Heck, U. (2010): Erfolgreiches IT-Management in der Praxis. Ein CIO-Leitfaden. Springer Vieweg. München Drechsler, A. / Parvahan, P. / Ahlemann, F. (2014): IT-Projektportfoliomanagement. In: Lang et al., 2014, S. 69−90 Drexl, N. / Hans, S. / Käck, S. (2002): Hauptseminar Analyse von Softwarefehlern ‒ Softwarefehler in der Logistik am Beispiel des Denver International Airport Gepäcktransportsystems. Technische Universität München Ebel, N. (2011): „PRINCE2: 2009 - für Projektmanagement mit Methode“, Addison-Wesley Verlag. München <?page no="258"?> 258 Anhang Eidgenössisches Finanzdepartement EFD, Informatiksteuerungsorgan des Bundes ISB (Hrsg.) (2016): HERMES 5.1. Projektmanagementmethode für alle Projekte. REFERENZHANDBUCH, 3. Aufl. Unter Mitarbeit von Hélène Mourgue d’Algue, Guido Eicher und Bernhard Kruschitz. Bern (CH) Frick, A. / Schoper, Y. / Röschlein, R. / Seidl, J. (2019): Projektdesign. In: GPM 2019, S. 1004‒1037 Gessler, M. (2012): Projektarten. In: GPM & Gessler 2012, S. 43‒51 GPM (Hrsg.) (2014): Empirische PMO Studie 2013/ 14, in Kooperation mit der HfWU Hochschule für Wirtschaft und Umwelt Nürtingen-Geislingen. Deutsche Gesellschaft für Projektmanagement e.V. Nürnberg GPM (Hrsg.) (2015): Ergänzung und Veränderung von Erfolgsfaktoren im Projektmanagement bei zunehmender Internationalisierung, Deutsche Gesellschaft für Projektmanagement e.V. Nürnberg GPM (Hrsg.) (2017): Individual Competence Baseline für Projektmanagement, Version 4.0, Deutsche Fassung. Deutsche Gesellschaft für Projektmanagement e.V. Nürnberg GPM (Hrsg.) (2019): Kompetenzbasiertes Projektmanagement (PM4). Handbuch für Praxis und Weiterbildung im Projektmanagement. Deutsche Gesellschaft für Projektmanagement e.V. Nürnberg GPM (Hrsg.) (2023): Projektifizierung 2.0. Zweite Makroökonomische Vermessung der Projekttätigkeit in Deutschland. Studie. GPM Deutsche Gesellschaft für Projektmanagement e. V./ EBS Universität für Wirtschaft und Recht, UVK Verlag. Tübingen GPM / Gessler, M. (Hrsg.) (2012): Kompetenzbasiertes Projektmanagement (PM3): Handbuch für Projektarbeit, Qualifizierung und Zertifizierung. 5. Aufl., Deutsche Gesellschaft für Projektmanagement e.V. Nürnberg Grave, T. (08.01.2012): Wie schreibt man ein gutes Vision Statement? online: https: / / advicio.com/ tools/ vision-statement/ , abgerufen am 09.03.2022 Grosser, T. (o.J.): Prototyping. Online: https: / / youtu.be/ RamZDtO4Z8g, abgerufen am 14.03.2022 Grötsch, C. (11.04.2018): Hypercare & Self-Learning: So arbeitet man Mitarbeiter ein. Online: https: / / www.handelskraft.de/ hypercare-self-learning-so-arbeitet-man-mitarbeiter-ein/ , abgerufen am 03.03.2022 Höhn, R. / Höppner, S. / Rausch, A. (2008): Das V-Modell XT. Anwendungen, Werkzeuge, Standards (eXamen.press). Springer. Berlin, Heidelberg Hüsselmann, C. (2020): Das Unified Project Management Framework. Ein kompakter Prozessrahmen für Projekte. BoD-Books on Demand. Norderstedt Hüsselmann, C. (2021): Lean Project Management. Hybride Methoden wertschöpfend anwenden, Schäffer-Poeschel. Stuttgart Hüsselmann, C. (2024): Lean-Adaptive Project Portfolio Management. Ein prozess- und prinzipienorientiertes Referenzmodell. Schäffer-Poeschel. Stuttgart Hüsselmann, C. / Hergenröder, J. (2024): Integrierte Earned Value Analyse. Kostendifferenzierung, Anwendung für agile Projekte und auf Portfolioebene (GPM Science), UVK Verlag. Tübingen IAPM (Hrsg.) (2017): Weißbuch Hybrid Project Management. Liechtenstein <?page no="259"?> Quellen und weiterführende Literatur 259 IONOS (2019): Spiralmodell: Das Modell für Risikomanagement in der Softwareentwicklung. Online: https: / / www.ionos.de/ startupguide/ produktivitaet/ spiralmodell/ IONOS (2020): Was ist das V-Modell? online: https: / / www.ionos.de/ digitalguide/ websites/ webentwicklung/ v-modell/ , abgerufen am 14.03.2022 Jenny, B. (2014): Projektmanagement: Das Wissen für eine erfolgreiche Karriere. 4. Aufl., vdf. Zürich Jochem, R. (2019): Was kostet Qualität? - Wirtschaftlichkeit von Qualität ermitteln. 2. Aufl., Hanser Verlag. München Jordan, A. (04.06.2020): Eskalationsmanagement bei Projekten. Online: https: / / isr.de/ news/ projektmanagement-methoden-heute-eskalationsmanagement-bei-projekten/ , abgerufen am 14.03.2022 Kammerer, S. / Lang, M. / Amberg, M. (Hrsg.) (2012): IT-Projektmanagement-Methoden: Best Practices von Scrum bis PRINCE2. symposion. Düsseldorf Kerzner, H. (2008): Projektmanagement. Ein systemorientierter Ansatz zur Planung und Steuerung. Unter Mitarbeit von Grau, N. mitp-Verl. Bonn. Kloss, R. (2019): Adding Value to Project Management - The Magic Triangle Meets the “Cultural” Iceberg. In: Stangel-Meseke et al. (2019), S. 205-218 Komus, A. (2016): Erfolgsfaktoren im Projektmanagement: Studien-ergebnisse und praktische Empfehlungen, 2016. Online: https: / / www.komus.de/ app/ download/ 8835262686/ 2016-01-EF- PM-Ergebn_Empfehlungen.pdf? t=1505927228, abgerufen am 02.04.2025 Komus, A. et al. (2020): Ergebnisbericht Status Quo (Scaled) Agile 2019/ 2020. 4. Internationale Studie zu Nutzen und Erfolgsfaktoren (skalierter) agiler Ansätze. BPM-Labor für Business Process Management und Organizational Excellence. HS Koblenz Kreutz, I. (2020): Cut-over-Planung im Rahmen der Anwendungsmigration. Online: https: / / www.slidaris.de/ aktuelles/ anwendungsmigration-cut-over-planung/ , abgerufen am 03.03.2022 Krypczyk, V. (2016a): Lastenheft: Anforderungen in der Softwareentwicklung richtig definieren. Online: https: / / entwickler.de/ online/ development/ lastenheft-anforderungen-softwareentwicklung-255339.html, abgerufen am 17.04.2019 Krypczyk, V. (2016b): Aufbau von Lastenheften und Ermittlung von Benutzeranforderungen. Online: https: / / entwickler.de/ online/ development/ lastenheft-aufbau-ermittlung-benutzeranforderungen-255356.html, abgerufen am 17.04.2019 Kuhrmann, M. (o.J.): Spiralmodell, Universität Potsdam. Online: https: / / www.enzyklopaedieder-wirtschaftsinformatik.de/ lexikon/ is-management/ Systementwicklung/ Vorgehensmodell/ Spiralmodell, abgerufen am 14.03.2022 Kunz, C. (2007): Strategisches Multiprojektmanagement (Unternehmensführung & Controlling). Springer Fachmedien. Wiesbaden Kuster, J. / Huber, E. et al. (2011): Handbuch Projektmanagement. Springer. Berlin Heidelberg Lang, M. (Hrsg.) (2014): CIO-Handbuch ‒ Band 3. Strategien für die innovative und agile IT- Organisation. Symposion. Düsseldorf Lechler, T. (2005): Projektmanagement. Konzepte zur Einzel- und Multi-Projektführung. In: Albers, S. et al. (Hrsg.), Handbuch Technologie- und Innovationsmanagement, Gabler/ GWV Fachverlage. Wiesbaden <?page no="260"?> 260 Anhang Litke, H.-D. / Kunow, I. / Schulz-Wimmer, H. (2022): Projektmanagement, 5. Aufl., Haufe. Freiburg Nagel, K. (2013): Anspruch und Wirklichkeit der Projektkommunikation ‒ eine empirische Studie unter Projektmanagern. In: projektMANAGEMENTaktuell, 3/ 2013, S. 29‒31 Noventum (o.J.): Hypercars. Online: https: / / www.noventum.de/ de/ glossar-mergers-and-acquisitions-archive/ hypercare.html, abgerufen am 03.03.2022 Oestereich, B. (2006): Der Agile Festpreis und andere Preis- und Vertragsmodelle. In: OOSE Fachartikel (1/ 2006), S. 31-33 Okujava, S. (2006): Wirtschaftlichkeitsanalysen für IT-Investitionen, WiKu-Verlag Online Projektmanagement (o.J.): Die Product Vision in Scrum. Online: www.online-projektmanagement.info/ agiles-projektmanagement-scrum-methode/ scrum-artfakte/ product-vision/ , abgerufen am 09.03.2022 Opelt, A. / Gloger, B. / Pfarl, W. / Mittermayr, R. (2018): Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge, 3., überarb. Aufl. (Hanser eLibrary). Hanser. München Paukner, M. / Seel, C. / Timinger, H. (2018): Projektparameter für das Tailoring hybrider Projektmanagementvorgehensmodelle. In: Barton et al. (2018), S. 166-176 Petry, M. / Nemetz, M. / Roelz, T. (2010): Bestimmung des Wertbeitrags der IT. Praxis bei Hilti AG. In: Crameri et al., 2010, S. 47-67 Pichler, R. (o.J.): The Product Canvas. Online: https: / / www.romanpichler.com/ tools/ the-product-canvas/ , abgerufen am 09.03.2022 PMI (2004/ 2008/ 2009): A Guide to the Project Management Body of Knowledge. PMBOK® Guide. 3.-5. Aufl., Project Management Institute. Newtown Square, PA (US) Pommeranz, I. (2011): Komplexitätsbewältigung im Multiprojektmanagement. Die Handlungsperspektive der Multiprojektleiter. Dissertation. Fakultät für Wirtschaftswissenschaft. Universität Augsburg Preußig, J. (2018): Agiles Projektmanagement. Scrum, User Stories, Task Boards & Co., 2. Aufl. Haufe Gruppe. Freiburg München Stuttgart projektmagazin (Hrsg.) (2014): PM-Standards und -Zertifizierungen im Überblick. Spotlight. Eine themenspezifische Zusammenstellung von Fachartikeln aus dem projektmagazin. www.projektmagazin.de Reiss, M. (2013): Hybrides Projektmanagement. Innovative Management-Architekturen zur Bewältigung neuer Komplexitätsformen in der Projektarbeit. In: Wald et al. (2013), S. 95-112 Resch, O. (2013): Einführung in das IT-Management. Grundlagen, Umsetzung, Best Practice. Erich Schmidt Verlag RiskNET (o.J.): Der Prozess des Risikomanagements, RiskNET GmbH. Online: https: / / www.risknet.de/ wissen/ risk-management-prozess/ , abgerufen am 14.03.2022 Ruf, W. / Fittkau, T. (2008): Ganzheitliches IT-Projektmanagement: Wissen, Praxis, Anwendungen, Oldenbourg Verlag. München Schelle, H./ Ottmann, R./ Pfeiffer, A. (2008): Projektmanager. 3. Auflage, GPM Deutsche Gesellschaft für Projektmanagement e.V. Nürnberg Schillinger, F. (2018): Requirements Engineering, NETFOMIC Whitepaper <?page no="261"?> Quellen und weiterführende Literatur 261 Schlick, M. (2015): Qualitäts- und Projektmanagement, Skript, RWTH Aachen Schütte, R. / Seufert, S. / Wulfert, T. (2019): Das Wertbeitragscontrolling als Anreicherung bestehender Vorgehensmodelle des Software Engineering. PVM 2019. Gesellschaft für Informatik (GI). Lörrach Seidl, J. (2011): Multiprojektmanagement. Springer Berlin Heidelberg. Berlin, Heidelberg Shenhar, A.J./ Dvir, D. (2007): Reinventing Project Management. The Diamond Approach To Successful Growth And Innovation. Harvard Business Review Press. Boston SOPHIST (Hrsg.) (2016): Requirements Engineering. Die kleine RE-Fibel. 3. Aufl. Carl Hanser Verlag, München Springer Gabler Verlag (Hrsg.), Gabler Wirtschaftslexikon, Stichwort: Nutzen. Online: http: / / wirtschaftslexikon.gabler.de/ Archiv/ 2440/ nutzen-v10.html, abgerufen am 02.04.2025 Staehle, W.H. / Conrad, P. / Sydow, J. (2014): Management. Eine verhaltenswissenschaftliche Perspektive. 8. Aufl., Vahlen. München Stangel-Meseke, M. / Boven, C. / Braun, G. / Habisch, A. / Scherle, N. / Ihlenburg, F. (Hrsg.) (2019): Practical Wisdom and Diversity. Aligning Insights, Virtues and Values. Springer Gabler. Wiesbaden Techt, U. / Lörz, H. (2015): Critical Chain: Beschleunigen Sie Ihr Projektmanagement. 3. Aufl., Haufe-Lexware. Freiburg Techt, U. / Schumacher, J.-O. / Stix, G. (2011): Pragmatisches Ressourcenmanagement in einer Multiprojektumgebung. Teil 1‒3. In: projektmagazin (22-24) Timinger, H. (2017): Modernes Projektmanagement. Mit traditionellem, agilem und hybridem Vorgehen zum Erfolg. Wiley-VCH. Weinheim TPG (Hrsg.) (2016): Wie Sie ein Projekt-, Portfolio-und Ressourcen-Management System erfolgreich einführen, Webinar, The Project Group, 30.03.2016 Verspohl, O. (28.12.2013): 10 Tipps für erfolgreiche IT-Projekte. Online: https: / / www.computerwoche.de/ a/ 10-tipps-fuer-erfolgreiche-it-projekte,2489690,2, abgerufen am 03.03.2022 Voorhorst, F. (2013): Expressive product design. Introducting the product design canvas, Brick42 Wagner, R. / Grau, N. (Hrsg.) (2013): Basiswissen Projektmanagement - Projekte steuern und erfolgreich beenden. Symposion. Düsseldorf Wald, A. / Mayer, T.-L. / Wagner, R. / Schneider, C. (Hrsg.) (2013): Advanced project management (Vol. 3). Komplexität. Dynamik. Unsicherheit. 1. Auflage., GPM Deutsche Gesellschaft für Projektmanagement e.V (GPM Buchreihe Forschung, 07). Nürnberg Wehnes, H. (2014): Professionelles Projektmanagement in der Praxis, Skript, Universität Würzburg Wendler, R. (2009): Reifegradmodelle für das IT-Projektmanagement, TU Dresden 2009 Widmann, M. (11.04.2019): Regeln der Eskalation. Online: https: / / marc-widmann.de/ regeln-dereskalation/ , abgerufen am 14.03.2022 Wysocki, R.K. / Sneed, R. / Kaikini, S. (2014): Effective project management. Traditional, agile, extreme, Seventh edition. Wiley. Indianapolis, Indiana (US) XO Project (Hrsg.) (o.J.): Was ist Prototyping? Eine kurze Definition und Anwendungsempfehlung. Online: https: / / www.youtube.com/ watch? v=pBZvUZtT8r0, abgerufen am 14.03.2022 Zell, H. (2017): Projektmanagement - lernen, lehren und für die Praxis. 7. Aufl., BoD. Norderstedt <?page no="263"?> Abbildungsverzeichnis Abb. 1 Differenzierung von IT-Projekten ..............................................................................................16 Abb. 2 Charakteristik von Projekten ......................................................................................................18 Abb. 3 Einordnung Projektmanagement ...............................................................................................19 Abb. 4 Aufgaben des Projektmanagements ..........................................................................................19 Abb. 5 Projektmanagement-Prozesse .....................................................................................................20 Abb. 6 Das Projektumfeld ..........................................................................................................................22 Abb. 7 Klassifizierung der Projektumfeldfaktoren ..............................................................................22 Abb. 8 Klassifizierung der Projektumfeldfaktoren (Template) ........................................................23 Abb. 9 Umfeldregister (Beispiel) ..............................................................................................................23 Abb. 10 Umfeldregister (Template) ...........................................................................................................23 Abb. 11 Stakeholder-Management-Prozess .............................................................................................25 Abb. 12 Stakeholder-Register......................................................................................................................26 Abb. 13 Stakeholder-Portfolio.....................................................................................................................27 Abb. 14 Stakeholder-Management-Strategie ..........................................................................................27 Abb. 15 Stakeholder-Register......................................................................................................................28 Abb. 16 Der Stakeholder-Management-Prozess.....................................................................................29 Abb. 17 Projektumfeldanalyse (Beispiel IT-Projekt) .............................................................................30 Abb. 18 Prozess der Projektbeantragung .................................................................................................31 Abb. 19 Ziele im Magischen Dreieck ........................................................................................................33 Abb. 20 Messbarkeit der Ziele.....................................................................................................................34 Abb. 21 Merkmale gut formulierter Ziele ................................................................................................34 Abb. 22 Zielfindung − Beispiele .................................................................................................................35 Abb. 23 Zielhierarchie mit Muss-, Soll- & Kann-Zielen .......................................................................36 Abb. 24 Zieltabelle mit Muss-, Soll- & Kann-Zielen..............................................................................36 Abb. 25 Zielkreuz nach Coverdale.............................................................................................................37 Abb. 26 Zielbeziehungen und -verträglichkeit .......................................................................................38 Abb. 27 Mittelbare und unmittelbare Ziele .............................................................................................39 Abb. 28 Fundierte Zielanalyse ....................................................................................................................39 Abb. 29 Zielbeziehungen und -verträglichkeit (Maßnahmen) ...........................................................40 Abb. 30 Erweitertes Magisches Dreieck des Projektmanagements...................................................40 Abb. 31 Abwicklungserfolg und Anwendungserfolg............................................................................42 Abb. 32 Abwicklungsvs. Anwendungserfolg .......................................................................................43 Abb. 33 Typische Nutzenkategorien von IT-Projekten........................................................................44 <?page no="264"?> 264 Anhang Abb. 34 Wirtschaftlichkeitsbetrachtung .................................................................................................. 44 Abb. 35 Über die Anwendung zum Nutzen ............................................................................................ 44 Abb. 36 Aufbau eines Business Case ........................................................................................................ 45 Abb. 37 Nutzenbetrachtung ........................................................................................................................ 45 Abb. 38 Kataloge der IT-WiBe.................................................................................................................... 47 Abb. 39 Projektsteckbrief............................................................................................................................. 48 Abb. 40 Project Canvas ................................................................................................................................ 48 Abb. 41 Hauptgründe für Projekterfolg ................................................................................................... 50 Abb. 42 Aufbaustruktur des UPMF ........................................................................................................... 52 Abb. 43 Typische Produktentwicklung? .................................................................................................. 57 Abb. 44 Rolle des Requirements Engineerings in Software-Projekten ............................................ 58 Abb. 45 Arten von Anforderungen ........................................................................................................... 59 Abb. 46 Das Kano-Modell............................................................................................................................ 59 Abb. 47 Dokumentation von Anforderungen......................................................................................... 60 Abb. 48 Satzschablone für funktionale Anforderungen ...................................................................... 61 Abb. 49 Lastenheft - ein Gestaltungsvorschlag nach Balzert ............................................................ 62 Abb. 50 Projektvorgehen im Bereich der Voruntersuchung .............................................................. 62 Abb. 51 Methodische Erhebung von Anforderungen........................................................................... 63 Abb. 52 Requirements Engineering im Projektvorgehen .................................................................... 63 Abb. 53 Fragmentierung des RE................................................................................................................. 64 Abb. 54 Mikro-Spezifikation ist (vielfach) nicht wertschöpfend....................................................... 65 Abb. 55 Einordung des Projekt-Kontextes .............................................................................................. 65 Abb. 56 Das Spiralmodell............................................................................................................................. 66 Abb. 57 Minimum Viable Product ............................................................................................................. 66 Abb. 58 Fragen zur Produktvision............................................................................................................. 67 Abb. 59 Satzschablone für die Produktvision ......................................................................................... 67 Abb. 60 Satzschablone für die Produktvision ......................................................................................... 68 Abb. 61 Satzschablone für eine User Story ............................................................................................. 68 Abb. 62 Prozess des Requirements Management .................................................................................. 69 Abb. 63 Häufiger Verlauf der Entwicklung eines Projekts ................................................................. 69 Abb. 64 Klassifizierung von Anforderungen .......................................................................................... 70 Abb. 65 Atmender Scope mit der MuSCo(W)-Regel............................................................................. 71 Abb. 66 Kosten-Nutzenwert-Matrix ......................................................................................................... 73 Abb. 67 Weighted Shortest Job First (WSJF)........................................................................................... 75 <?page no="265"?> Abbildungsverzeichnis 265 Abb. 68 Planung als Ausgangsbasis für die Projektsteuerung ...........................................................76 Abb. 69 Aufbau eines Projektstrukturplans ............................................................................................77 Abb. 70 PSP für ein Software-Projekt .......................................................................................................78 Abb. 71 PSP eines Webseiten-Relaunches ...............................................................................................79 Abb. 72 Arbeitspakete in der phasenorientierten Planung .................................................................81 Abb. 73 Vorgehen bei der PSP-Erstellung ...............................................................................................81 Abb. 74 Vorgehen der Projektstrukturierung .........................................................................................82 Abb. 75 Aufwand vs. Dauer.........................................................................................................................83 Abb. 76 Perspektiven für eine valide Aufwandschätzung ...................................................................83 Abb. 77 Schätzmethoden im Überblick.....................................................................................................84 Abb. 78 Planning Poker ................................................................................................................................85 Abb. 79 Checkliste Aufwandsplanung......................................................................................................86 Abb. 80 Grafischer Phasenplan...................................................................................................................87 Abb. 81 Generisches Phasenmodell...........................................................................................................88 Abb. 82 „Goldener Schnitt“ von Projektphasen .....................................................................................89 Abb. 83 Goldener Schnitt − Beispiel SAP-Einführung .........................................................................90 Abb. 84 Quality Gates ‒ Aufbau .................................................................................................................91 Abb. 85 Projektabschnitte ‒ Aufbau..........................................................................................................92 Abb. 86 Projektablauf mit Vorstudie .........................................................................................................93 Abb. 87 Ablauf mit Vorstudie .....................................................................................................................93 Abb. 88 Projektabschnitte − beispielhafte Anwendung Releases ......................................................94 Abb. 89 Projektabschnitte − beispielhafte Anwendung Rollout (RO) ..............................................94 Abb. 90 Projektablaufplan............................................................................................................................95 Abb. 91 Sequenzielle oder parallele Bearbeitung ...................................................................................96 Abb. 92 Zeitplan .............................................................................................................................................96 Abb. 93 PAP ‒ Netzplan................................................................................................................................96 Abb. 94 PAP ‒ Gantt-Chart..........................................................................................................................97 Abb. 95 PAP − Beispiel Auswahl Standard-Software ...........................................................................97 Abb. 96 Gantt-Chart − Bewertung.............................................................................................................98 Abb. 97 Rollierende Planung .......................................................................................................................99 Abb. 98 Zwei Welten: Linie - Projekte ..................................................................................................101 Abb. 99 „Nebenher“-Projektorganisation ..............................................................................................102 Abb. 100 Typische Projektorganisation ‒ kleine Projekte.................................................................103 Abb. 101 Erweiterte Projektleitung .........................................................................................................103 <?page no="266"?> 266 Anhang Abb. 102 Typische Projektorganisation ‒ große Projekte ................................................................. 104 Abb. 103 Organigramm eines großen IT-Projekts .............................................................................. 104 Abb. 104 Organigramm eines großen IT-Projektes ‒ Abschnitt Rollout....................................... 105 Abb. 105 Projektorganigramm − Systematik........................................................................................ 106 Abb. 106 Funktionale Organisation ........................................................................................................ 106 Abb. 107 Matrix-Organisation.................................................................................................................. 107 Abb. 108 Projektbasierte Organisation .................................................................................................. 108 Abb. 109 Projektleitung im Stab .............................................................................................................. 109 Abb. 110 Befugnisse der Projektleitung................................................................................................. 109 Abb. 111 Organisationsformen und Weisungsbefugnisse................................................................. 110 Abb. 112 Vergleich der Organisationsformen ...................................................................................... 111 Abb. 113 Aufgaben − Befugnisse - Verantwortung von Rollen...................................................... 112 Abb. 114 Strukturierte Rollenbeschreibung ‒ Beispiel....................................................................... 112 Abb. 115 Strukturierte Rollenbeschreibung ‒ Template .................................................................... 112 Abb. 116 Kongruenzprinzip der Rollendefinition................................................................................ 113 Abb. 117 Rollenbeschreibung: Projektleitung ...................................................................................... 113 Abb. 118 Rollenbeschreibung: Projektmitarbeiter............................................................................... 114 Abb. 119 Rollenbeschreibung: Auftraggeber ........................................................................................ 114 Abb. 120 Rollenbeschreibung: Teilprojektleitung ............................................................................... 115 Abb. 121 PM-Anforderungen ................................................................................................................... 115 Abb. 122 Skala der Führungsstile ............................................................................................................ 116 Abb. 123 Rollenbeschreibung: Projektunterstützung ......................................................................... 117 Abb. 124 Rollenbeschreibung: Nutzervertretung ................................................................................ 117 Abb. 125 Rollenbeschreibung: Lieferantenvertretung........................................................................ 118 Abb. 126 Rollenbeschreibung: Projektsicherung ................................................................................. 118 Abb. 127 Rollenbeschreibung: Lenkungsausschuss ............................................................................ 119 Abb. 128 Rollenbeschreibung: Change Control Board....................................................................... 119 Abb. 129 RACI - Zuordnung von Zuständigkeiten ............................................................................ 120 Abb. 130 Aufgabe: Zusammenhang innerhalb der Projektplanung ............................................... 121 Abb. 131 Aufgabe: Zusammenhang innerhalb der Projektplanung ‒ Lösung ............................. 121 Abb. 132 Wasserfallmodell........................................................................................................................ 122 Abb. 133 V-Modell....................................................................................................................................... 123 Abb. 134 Evolutionäres Vorgehensmodell ............................................................................................ 124 Abb. 135 Inkrementelles Vorgehensmodell .......................................................................................... 124 <?page no="267"?> Abbildungsverzeichnis 267 Abb. 136 Spiralmodell .................................................................................................................................125 Abb. 137 Arten des Prototyping ...............................................................................................................126 Abb. 138 Scrum-Prozessmodell ................................................................................................................128 Abb. 139 Extreme Programming (XP).....................................................................................................132 Abb. 140 Feature Driven Development ..................................................................................................133 Abb. 141 Design Thinking .........................................................................................................................136 Abb. 142 Inkrementelles Vorgehen erfordert Interaktion .................................................................137 Abb. 143 DevOps ..........................................................................................................................................137 Abb. 144 Bimodales Vorgehensmodell ...................................................................................................138 Abb. 145 Evolutionäres Vorgehensmodell.............................................................................................138 Abb. 146 Best-of-Breed-Vorgehensweise...............................................................................................138 Abb. 147 Bildung von Projektkategorien ...............................................................................................139 Abb. 148 Projektcharakterisierung hinsichtlich Komplexität von Projektinhalt und -umfang .........................................................................................................................................140 Abb. 149 Der „NTCP-Diamond“ nach Shenhar/ Dvir ..........................................................................142 Abb. 150 Typisierung von IT-Projekten.................................................................................................142 Abb. 151 Begriffsklärung zur Adaption eines PM-Systems ..............................................................143 Abb. 152 Adaption des PM-Systems im PM-LifeCycle.......................................................................144 Abb. 153 Die drei Merkmalskategorien des Agilometers ..................................................................145 Abb. 154 Unternehmensspezifische Merkmale.....................................................................................145 Abb. 155 Projektteamspezifische Merkmale .........................................................................................146 Abb. 156 Projektspezifische Merkmale...................................................................................................148 Abb. 157 Teilprozesse im Beschaffungsmanagement .........................................................................153 Abb. 158 Der Vertrag im Projektmanagement .....................................................................................154 Abb. 159 Typisierung der Vertragsarten................................................................................................154 Abb. 160 CR Managementprozess − Übersicht.....................................................................................156 Abb. 161 Übergänge zwischen Vertrags- und Claim Management sind fließend .......................158 Abb. 162 Claim-Strategien .........................................................................................................................158 Abb. 163 Das Magische Dreieck im agilen und klassischen Projektvorgehen .............................159 Abb. 164 Prozessschritte Vereinbarung Agiler Festpreis...................................................................159 Abb. 165 Gegenüberstellung und Bewertung Vertragsmodelle .......................................................160 Abb. 166 Teilprozesse des Qualitätsmanagements ..............................................................................162 Abb. 167 Kriteriengruppen im Project Excellence-Modell ................................................................164 Abb. 168 Struktur der QM-Konzeption ..................................................................................................164 Abb. 169 Prüfobjekte ‒ Klassifizierungsschema ...................................................................................165 <?page no="268"?> 268 Anhang Abb. 170 Risiko-„Reichweite“ von Projekten ....................................................................................... 171 Abb. 171 Regelkreis des Risikomanagements....................................................................................... 172 Abb. 172 Risiko-Template.......................................................................................................................... 173 Abb. 173 Risikoregister .............................................................................................................................. 173 Abb. 174 Risikoportfolio ‒ Beispiel ......................................................................................................... 173 Abb. 175 Projektrisikomanagement - Strategien................................................................................ 174 Abb. 176 Frühwarnindikatoren ................................................................................................................ 179 Abb. 177 Instrumente des Projekt-Controllings .................................................................................. 181 Abb. 178 Plan-Ist-Vergleich ‒ Beispiel ................................................................................................... 182 Abb. 179 Plan-Ist-Vergleich − Vergleichsformen ................................................................................ 182 Abb. 180 Projektfortschrittsprosa............................................................................................................ 184 Abb. 181 Projektstatusbericht ‒ Template............................................................................................. 184 Abb. 182 Die Projektampel........................................................................................................................ 185 Abb. 183 Statuskommunikation............................................................................................................... 186 Abb. 184 Meeting-Struktur und Statuskommunikation .................................................................... 186 Abb. 185 Bestimmung des Fertigstellungsgrads .................................................................................. 189 Abb. 186 Fortschrittsschema „Fixed Formular“ ‒ Beispiel Dokumente ......................................... 190 Abb. 187 Fortschrittsschema „Fixed Formular“ ‒ Beispiel Fachkonzept........................................ 190 Abb. 188 Fortschrittsschema „Fixed Formular“ ‒ Beispiel (IT-) Produkte..................................... 190 Abb. 189 Verfahren und ihre Anwendung ............................................................................................ 191 Abb. 190 Earned Value Analyse ‒ Grundschema ................................................................................ 192 Abb. 191 Meilenstein-Trend-Analyse ‒ Grundschema ...................................................................... 194 Abb. 192 Typische MTA-Kurven ‒ Beispiel „Spätes Erwachen“ ..................................................... 195 Abb. 193 RoP und Projektplan bilden den Backlog............................................................................. 197 Abb. 194 Register offener Punkte ‒ Beispiel ......................................................................................... 197 Abb. 195 Erfolgsfaktor „Offene-Punkte-Verwaltung“........................................................................ 197 Abb. 196 Schematisches Taskboard im Projekt-Kanban ................................................................... 198 Abb. 197 Projektablauforientiertes Design des Projekt-Kanbans ................................................... 200 Abb. 198 Parallel laufende Projekte mit Engpassressource E........................................................... 202 Abb. 199 Optimaler Projektablauf ........................................................................................................... 202 Abb. 200 Einsatz von Versorgungs- und Projektpuffern in Critical Chain Projekten ............... 203 Abb. 201 Fieber-Chart über die Fertigstellung der kritischen Kette............................................... 203 Abb. 202 Wissensmanagement in Organisation und Projekt........................................................... 208 Abb. 203 Wissensgewinnung, -transfer und -nutzung ...................................................................... 208 <?page no="269"?> Abbildungsverzeichnis 269 Abb. 204 Faktorenportfolio........................................................................................................................209 Abb. 205 Wissen sichern: Lessons Learned ‒ Beispiel ........................................................................210 Abb. 206 Starfish-Methode für Retrospektiven ....................................................................................211 Abb. 207 Projektwissensmanagement − Beispiel.................................................................................212 Abb. 208 Warum Projekt-Wissensmanagement? ‒ Beispiel .............................................................213 Abb. 209 Kommunikation als Erfolgsfaktor ‒ 4 W ..............................................................................214 Abb. 210 Teilprozesse der Kommunikationsplanung .........................................................................215 Abb. 211 Fragen der Kommunikationsplanung....................................................................................215 Abb. 212 Fragen der Kommunikationsplanung ‒ Beispiel.................................................................215 Abb. 213 Baukasten der Kommunikationsplanung .............................................................................216 Abb. 214 Relevanz und Nutzung der Kommunikationsformate.......................................................216 Abb. 215 Normstrategien der Kommunikation ....................................................................................217 Abb. 216 Vier-Seiten-Modell der Kommunikation ..............................................................................217 Abb. 217 Eskalationspyramide..................................................................................................................218 Abb. 218 Phasen im Eskalationsmanagement.......................................................................................219 Abb. 219 Projektmarketing ‒ Zielgruppen ............................................................................................221 Abb. 220 Projektmarketing − Beispiele ..................................................................................................221 Abb. 221 Cut-over auf zeitlicher Ebene ..................................................................................................222 Abb. 222 PM-Aufwand im Projektverlauf .............................................................................................224 Abb. 223 Skala der Kundenzufriedenheit...............................................................................................225 Abb. 224 „Projektinkasso“ ‒ in der Regel nach dem Projekt.............................................................226 Abb. 225 Aufgabenfelder und Positionierung des IT-Managements ..............................................228 Abb. 226 Fokussierung der IT-Strategie innerhalb der Geschäftsstrategie ...................................229 Abb. 227 Realisierung der IT-Strategie auf Basis von globalen Prozess- und Datendefinitionen und des Multi-Channel-Systems (MCS)........................................................230 Abb. 228 Vorgehensweise bei der IT-Strategie Entwicklung............................................................231 Abb. 229 Fragenkatalog Geschäftsprozessorientierung ‒ Beispiel ..................................................232 Abb. 230 Häufigkeit eingetretener Nutzeneffekte ...............................................................................233 Abb. 231 Nutzenkategorien und Funktionsbereiche ...........................................................................233 Abb. 232 Parallele Projektaktivitäten konkurrieren um Ressourcen..............................................235 Abb. 233 Kernfragen des Projektportfolio-Managements .................................................................235 Abb. 234 Typische Visualisierung eines Projektportfolios ‒ Beispiel.............................................236 Abb. 235 Nutzwertanalyse − Beispiel .....................................................................................................237 Abb. 236 Mögliche Kriterien der NWA ‒ Beispiel ...............................................................................237 Abb. 237 Bewertungskriterien ..................................................................................................................238 <?page no="270"?> 270 Anhang Abb. 238 Prozesszusammenhang PPM und PM ................................................................................... 238 Abb. 239 High-Level-Prozessmodell Projektportfoliomanagement ............................................... 239 Abb. 240 Wesentliche Outputs im PPM-Prozess ................................................................................. 239 Abb. 241 PPM-Prozesszyklen im Geschäftsjahr ‒ Beispiel ............................................................... 244 Abb. 242 Funktionen von PM-Software................................................................................................. 245 Abb. 243 IT-Unterstützung im (Multi-)PM............................................................................................ 246 Abb. 244 Klasseneinteilung (Multi-)PM-Software............................................................................... 246 Abb. 245 Klassifizierung Multi-PM-Software ....................................................................................... 247 Abb. 246 Landschaft der MPM-Software-Anbieter ............................................................................. 248 Abb. 247 Infos zu aktuellen PM-Software-Anbietern......................................................................... 248 Abb. 248 PM-SW-Einführung ‒ Vorgehensmodell ............................................................................. 249 Abb. 249 MPM-SW-Auswahl mit Kriterienkatalog ............................................................................ 250 Abb. 250 Nutzwertanalyse zur MPM-SW-Auswahl............................................................................ 250 Abb. 251 Strategien zur Prüfung der Software .................................................................................... 250 <?page no="271"?> Stichwortverzeichnis Abnahme 123, 153, 165, 168, 223, 255 der Qualität 181 Projekt~ 224 Abschlussbericht 212 agiler Festpreisvertrag 158, 204 Agilometer 5, 121, 138, 144 Arbeitspaket 53, 78, 80, 105 atmender Scope 69 Audit 163 Aufwandsermittlung 81, 82 Balkenplan 97 Business Case 21, 41, 43, 47, 52, 54 Change Request 12, 70, 156, 255 Claim 12, 70, 153, 154, 157 Critical Chain Project Management (CCPM) 11, 200 Design Thinking 135 Earned Value Analyse 11, 191 Erfolgsfaktor 210 Kommunikation als ~ 214 Erfolgsfaktoren 11, 16, 29, 49 Festpreisvertrag, agiler 158, 204 Finanzmittelplan 54 Fortschrittsfeststellung 187 Hypercare 223 IT-Strategie 11, 229, 230 Kanban 11, 198, 199 Kano-Modell 60 Kommunikationsmaßnahmen 29, 162 Kundenzufriedenheit 71, 225 Künstliche Intelligenz 251 Lenkungsausschuss 118 Lenkungskreis 119 Lessons Learned 177, 207, 208, 210, 253, 256 Magisches Dreieck 33, 40, 43 Meilenstein 49, 87, 91, 122, 187, 194 Minimum Viable Product (MVP) 11, 66 Multiprojektmanagement 201 Netzplantechnik 96 Nicht-Ziele 38 Normstrategien 38, 40, 174 Nutzenrevision 11, 225, 227 Nutzwertanalyse 45, 236, 249 Open Issue Management 196 PDCA-Zyklus 19 Planung, rollierende 98 PM-Framework 20, 50, 143 PM-Software 11, 246, 248 Portfolio-Management 20, 244 Priorisierung 31, 43, 70, 200, 234, 238, 252 Produktionsvorbereitung 92 Produktvision 66, 67 Projektablaufplan 53 Projektablaufplanung 95 Projektabschluss 224 Projektabschlussbericht 225, 226 Projektantrag 31, 39 Projektauftrag 11, 21, 29, 30, 42, 47, 52, 155, 156 Projektbeschreibung 21, 47 Projektcontrolling 176, 181 Projektdokumentation 177, 224, 225 Projekterfolg 12, 24, 40, 42, 49, 52, 160, 227 Projektgremien 118 Projekthandbuch 54 Projekt-Kick-Off 49 Projektkommunikation 11, 214 Projektlebenszyklus 87, 170 Projektmanagement-Framework 11 Projektmarketing 48, 220 Projektorganisation 47, 101, 110, 152 Projektphasen 51, 87, 93, 170 <?page no="272"?> 272 Anhang Projektplan 53 Projektportfoliomanagement 234, 238 Projektrisiken 169 Projektstaffelung 202 Projektstart 36, 47, 49 Projektstatusbericht 53 Projektsteuerung 153 Projektstrukturplan 53, 76, 78, 120 Projektstrukturplanung 11, 95, 105 Projekt-Team 49, 53, 102, 103, 122, 147, 207 Projekttypisierung 11, 100, 139 Projektumfeld 11, 24, 105 Projektumfeld-Analyse 21 Projektvorbereitung 21, 29 Projektziele 17, 19, 21, 31, 49, 154 Prototyping 126 Prüfobjekt 165 Qualitätsmanagement 54, 86, 124, 161, 186 Qualitätsplanung 31, 164 Qualitätssicherung 86, 162 RACI-Matrix 120, 152 relationaler Vertrag 160, 204 Requirements Management 57, 69 Ressourcenplanung 120, 242 Risikomanagement 11, 29, 52, 169, 176 Risikoportfolio 173 Rollen im Projekt 111 rollierende Planung 98 Scope-Management 70 Scrum 127 Spiralmodell 125 Stakeholder 11, 21, 23, 29, 31, 40, 42, 52, 58, 69, 127, 179, 180, 215, 227 Stakeholder-Analyse 21, 24, 26, 27, 217, 252 Stakeholder Management 25, 27 Statusbericht 183, 185, 219, 252 Target Value Design 72 Transferaufgabe 5, 50, 55, 100, 151, 204, 253 Umfeldanalyse 21, 227 Unified Project Management Framework (UPMF) 5, 19, 51, 114, 127 User Stories 68, 85 Vertrag, relationaler 160, 204 Vertragsarten 154 Vertragsmanagement 153 Vorgehensmodell 12, 51, 63, 65, 68, 88, 122, 124, 127, 150, 249 Wasserfallmodell 122 Wissensmanagement 207, 212 Zielanalyse 38 Zielbeziehungen 38 Zieldefinition 11, 34, 37 Zielentwicklung 39 Zielhierarchie 35 Zielkonflikt 38, 39 Zielregister 36 <?page no="273"?> ISBN 978-3-381-14261-3 Prof. Dr. rer. oec. Claus Hüsselmann ist Leiter der PPM Labors im FB Wirtschaftsingenieurwesen an der TH Mittelhessen. Seine Schwerpunkte und Publikationen umfassen u. a. das Multiprojektmanagement (Ko-Leitung der GPM-Fachgruppe) sowie hybride PM-Ansätze (Lean PM). Projekte sind komplex und erfordern zielgerichtete Planung und Steuerung - besonders für Führungskräfte, die Projekte leiten oder begleiten. Das Buch vermittelt in kompakter und praxisnaher Form die wichtigsten Methoden und Vorgehensweisen, um Projekte erfolgreich zu planen und durchzuführen. Es bietet einen strukturierten Einstieg ins Projektmanagement und unterstützt Sie dabei, die Qualität der Projektergebnisse zu sichern, Kosten und Termine einzuhalten und Projekte souverän zum Erfolg zu führen. Praktische Übungen und hilfreiche Tools fördern Ihr Lernen, sodass Sie das Gelernte direkt in die Praxis umsetzen können. Ein Schwerpunkt liegt dabei auf IT-Projekten. Das Buch richtet sich an Fach- und Führungskräfte mit Projektverantwortung in der Praxis sowie Studierende, die einen Berufsweg im Projektmanagement anstreben. Hüsselmann Projektmanagement für Führungskräfte Claus Hüsselmann Projektmanagement für Führungskräfte Ein Grundlagenkurs in 5 Takten