Niklas Spitczok von Brisinski Guy Vollmer Ute Weber-Schäfer

Transkript

1

2 Niklas Spitczok von Brisinski leitet das Projektmanagement- Office der adesso AG in München. In seinen Verantwortungsbereich gehören die Definition und Durchsetzung von Projektmanagementstandards, das Monitoring exponierter Projekte sowie das Proposal Management. Als Diplom-Betriebswirt (FH) mit Schwerpunkt Wirtschaftsinformatik arbeitete er davor in Softwareentwicklungsprojekten vor allem an der Schnittstelle zwischen Fachbereich und IT und hatte dort seinen Fokus auf das Projektund Anforderungsmanagement gelegt. Er ist vom PMI zertifizierter Project Management Professional (PMP ) und Mitglied im PMI Chapter München. Die zahlreichen Projekte aus der adesso-praxis haben geholfen, den Inhalt der zweiten Auflage noch pragmatischer zu gestalten. Guy Vollmer ist seit 2009 Professor für Informatik und Softwaretechnik am Fachbereich Informatik der Fachhochschule Dortmund und lehrt im Bachelor- und Masterstudium. Von 2006 bis 2009 war er als Senior Consultant bei der adesso AG Dortmund beschäftigt und für unterschiedliche Kunden des deutschen Gesundheitswesens tätig. Parallel zu seiner Promotion an der Ruhr-Universität Bochum bei Prof. Dr.-Ing. Thomas Herrmann und Prof. Dr.-Ing. Helmut Balzert arbeitete er von 2001 bis 2006 als Projektleiter und wissenschaftlicher Mitarbeiter am Fraunhofer-Institut für Software- und Systemtechnik (ISST) in Dortmund und war an zahlreichen öffentlichen, forschungsspezifischen bzw. industriellen Softwareentwicklungsprojekten beteiligt. Vor und parallel zu seinem Informatikstudium an der TU Dortmund war er zehn Jahre als Softwareentwickler am Fraunhofer-Institut für Materialfluss und Logistik (IML) Dortmund sowie am Simulations-Dienstleistungszentrum (SDZ GmbH) in Dortmund tätig. Ute Weber-Schäfer hat 2012 ihr Unternehmen PromISE Projektmanagement IT Solution Experts gegründet und ist als selbstständige IT-Beraterin tätig. Aufbauend auf einer über 20-jährigen Berufserfahrung in der IT-Branche berät sie Kunden aus unterschiedlichen Branchen bei der Umsetzung ihrer IT-Projekte. Als zertifizierter Coach und Managementtrainer hat sie sich einen breiten Erfahrungsschatz sowohl im Projekt- und Anforderungsmanagement als auch im Bereich des Coachings und Change Management erworben. Nach ihrer Promotion in der Betriebswirtschaftslehre war sie zunächst 15 Jahre in leitender Stellung bei der SAP AG in Walldorf sowie bei der SAP UK in London tätig, wo sie einerseits komplexe bereichsübergreifende Softwareentwicklungsprojekte gesteuert und andererseits internationale Kunden bei der Einführung von Software beraten hat. Im Anschluss hat sie ihre Erfahrungen in das Projektgeschäft bei der adesso AG eingebracht. Ihre Kernkompetenz liegt auf den»weichen Faktoren«im Projektmanagement.

3 Niklas Spitczok von Brisinski Guy Vollmer Ute Weber-Schäfer Pragmatisches IT-Projektmanagement Softwareentwicklungsprojekte auf Basis des PMBOK Guide führen 2., überarbeitete und aktualisierte Auflage

4 Niklas Spitczok von Brisinski Guy Vollmer Ute Weber-Schäfer Lektorat: Christa Preisendanz Copy-Editing: Ursula Zimpfer, Herrenberg Herstellung: Birgit Bäuerlein Umschlaggestaltung: Helmut Kraus, Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. ISBN: Buch PDF epub , überarbeitete und aktualisierte Auflage 2014 Copyright 2014 dpunkt.verlag GmbH Wieblinger Weg Heidelberg Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Insbesondere sind PMI, PMBOK Guide, PMP, CAPM, PMI-SP, PMI-RMP und PgMP geschützte Bezeichnungen des Project Management Institute, Newton Square, PA, USA. Das Project Management Institute war nicht an der Erstellung des Buches beteiligt und hat es auch nicht auf Richtigkeit geprüft. Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen

5 v Geleitwort zur zweiten Auflage Erfolgreich verlaufende Softwareentwicklungsprojekte sind die hohe Kunst des IT-Projektmanagements und des Software-Engineerings. Die vielfach komplexen Ziele und Anforderungen an eine Individualsoftware termintreu und im veranschlagten Budgetrahmen umzusetzen, stellen eine große Herausforderung industrieller und ingenieurmäßiger Softwareentwicklung dar. Um Softwareentwicklungsprojekte besser plan- und steuerbar zu machen, werden seit Jahrzehnten Ansätze, Konzepte, Vorgehens- und Prozessmodelle entwickelt, die im praktischen Alltag der Softwareentwicklung mal mehr, mal weniger erfolgreich sind. So haben etliche Projekte nach wie vor große Mühen, die gesteckten Ziele zu erreichen. Neben den bekannten sequenziellen und iterativ-inkrementellen Modellen sowie den Monolithen, wie zum Beispiel V-Modell und Rational Unified Process, hat insbesondere die agile Softwareentwicklung in den letzten Jahren eine zunehmend breitere und nachhaltigere Erfolgsspur hinterlassen. Parallel dazu hat es in den USA auf Basis zahlreicher Projekte aus Gewerbe und Industrie etliche Initiativen für eine fundierte Projektmanagementmethodik gegeben. Diese Erfahrungen, Erkenntnisse und darauf basierenden Methoden und Vorgehensweisen sind in den»guide to the Project Management Body of Knowledge«(PMBOK Guide) des Project Management Institute (PMI ) eingeflossen. Aus rein projektmanagementspezifischer Perspektive greifen die verfügbaren Lösungen und Ansätze bei der Softwareentwicklung allerdings oftmals zu kurz, da Dauer und Gesamtkosten sowie Anforderungen und Qualität des Endprodukts deutlich schwieriger vorauszuplanen sind als in der Fertigungsindustrie. In diesem Kontext wird ersichtlich, dass Niklas Spitczok von Brisinski, Guy Vollmer und Ute Schäfer-Weber im vorliegenden Buch einen neuen und äußerst pragmatischen Weg gehen, um komplexe Softwareentwicklungsprojekte erfolgreich managen und durchführen

6 vi Geleitwort zur zweiten Auflage zu können. Im Rahmen ihres innovativen Lösungsansatzes schlagen sie vor, eine Vereinigung und pragmatische Ausprägung dieser beiden Entwicklungsstränge zum einen die softwarespezifische, zum anderen die projektmanagementspezifische vorzunehmen. Auf diese Weise wird eine äußerst pragmatische Mischung aus konkreten, softwarezentrierten Methoden, Sprachen und Werkzeugen zur effizienten und effektiven Softwareentwicklung mit den wichtigsten Erfahrungen, Best Practices und Lessons Learned aus dem Bereich des IT-Projektmanagements integriert. Und auf Basis konkreter praktischer Erfahrungen rücken in der nun vorliegenden zweiten Auflage auch die in der Praxis mittlerweile erfolgreich eingesetzten Ansätze, Methoden und Konzepte der agilen Softwareentwicklung stärker in den Vordergrund. Vor dem Hintergrund ihrer langjährigen Erfahrung im Bereich industrieller Softwareentwicklungsprojekte erkennen die Autoren zudem, dass ein effizientes und effektives Management von Softwareentwicklungsprojekten nicht allein die technischen Disziplinen in den Vordergrund zu stellen hat, sondern für den Projekterfolg insbesondere auch soziale, kommunikative und psychologische Aspekte zu berücksichtigen sind. Durch die Entwicklung eines detaillierten und vollständigen Werkzeug- und Methodenkastens für ein pragmatisches Software-Engineering versetzen die Autoren Projektteams in die Lage, auch in unvorhergesehenen Projektsituationen adäquat, angemessen und methodisch fundiert vorzugehen. Zur Durchführung erfolgreicher komplexer Softwareentwicklungsprojekte ist es somit wünschenswert, wenn Projektmanager, Anforderungsanalytiker, Softwarearchitekten und -entwickler, Tester, kurzum: alle in ein Projekt involvierten Informatiker und IT-Experten, das in diesem Buch vorgestellte innovative Vorgehensmodell einsetzen. Auf dieser Basis können sie ihre Softwareentwicklungsprojekte pragmatisch, effizient und erfolgreich durchführen. Prof. Dr. Volker Gruhn Essen, im Dezember 2013

7 vii Vorwort zur zweiten Auflage Als wir 2009 die Vision für die erste Auflage entwickelten, war unser Ziel, ein beherrschbares und damit pragmatisches Vorgehensmodell für Softwareentwicklungsprojekte vorzustellen, das trotz seiner Einfachheit auf einer soliden Methodik basiert. Seitdem bildet der PMBOK Guide des PMI die Grundlage unseres Vorgehensmodells. Im Sommer 2010 erschien die erste Auflage unseres Buches. So ganz wollte unser Vorgehen nicht dem damaligen Zeitgeist entsprechen: Um uns herum schien es nur noch agile Projekte zu geben, jeder sprach von Scrum, viele hatten einen Kurs zum Product Owner oder Scrum Master besucht. Sollten wir so daneben gelegen haben? Hatten wir vielleicht eine Entwicklung verpasst? Mitnichten. In den letzten zwei Jahren hat sich in vielen Projekten gezeigt, dass ein gewisser Grad an Agilität zwar unverzichtbar, die komplette Umstellung auf eine agile Vorgehensweise wie z.b. Scrum aber nicht immer praktikabel und auch nicht immer die beste Lösung ist (vgl. dazu auch [Komus 2012]). Zudem dient Agilität oft noch als Entschuldigung für einen nicht strukturierten Softwareentwicklungsprozess: Fehlen Spezifikationsdokumente, ist die Entwicklung eben agil. Stakeholder werden auch nicht mehr analysiert, weil man ja agil vorgeht und so alles im Fluss ist. Und Risikomanagement? Verzichtbar, wir arbeiten ja agil, da deckt man Probleme sowieso schrittweise auf. Projektpläne wurden schon immer überbewertet, denn sie sind ja bereits überholt, wenn sie zum ersten Mal veröffentlicht werden. Und einen Projektmanager brauchen wir auch nicht mehr, das regeln wir alles basisdemokratisch. Wir sind ja agil. Das alles finden wir nicht richtig. An agile Projektmanager denn wir sind der Meinung, dass es noch einen geben muss werden andere und zum Teil deutlich komplexere Anforderungen gestellt als an den Leiter eines»klassisch«geführten Projektes. Denn ohne definiertes Vorgehensmodell läuft ein agiles Team Gefahr, am Ende doch außer-

8 viii Vorwort zur zweiten Auflage halb von Zeit und Budget zu liegen oder von den Risiken überrollt zu werden. Dennoch glauben wir, dass Auftragnehmer und vor allem Auftraggeber ihre Einstellung zur Agilität allmählich ändern. Auch in Zukunft wird nicht jedes Projekt agil sein. Aber es ist hilfreich, sich der gut funktionierenden agilen Elemente zu bedienen, um sie in ein fundiertes und vor allem pragmatisches Vorgehensmodell zu integrieren. Diese»machbare Agilität«auf der einen und der PMBOK Guide in der im Januar 2013 erschienenen fünften Auflage auf der anderen Seite bildeten unsere Leitplanken bei der Entwicklung der zweiten Auflage des Buches und damit der neuen Auflage des Vorgehensmodells. Eingeflossen sind auch die zahlreichen Kommentare und Bewertungen, die wir in einer Umfrage unter unseren Lesern im Sommer 2012 durchgeführt haben. Im Ergebnis gehen daraus vier wesentliche Neuerungen hervor, die Auswirkungen auf das gesamte Vorgehen haben: 1. Schlankere Prozesse: Einige Prozesse haben wir deutlich schlanker gestaltet, wie etwa die Konfiguration des Projektes in der Planungsphase. Das war in der ersten Ausgabe doch recht ausführlich, in der Praxis in diesem Umfang kaum durchführbar und brachte dem Projekt letztlich auch nur geringen Mehrwert. Deutlich einfacher haben wir auch die Anforderungsdefinition gestaltet sowie etliche Prozesse in der Durchführungsphase. 2. Iterativ-agiles Vorgehen: Wir streben nun an, möglichst in jedem Projekt iterativ vorzugehen. Jede Iteration ermöglicht den unmittelbaren Abgleich mit den Kundenerwartungen und soll so das Gesamtrisiko minimieren, am Bedarf vorbei zu entwickeln. Das bedeutet aber auch, dass die»klassische Komplettspezifikation vorab«eher die Ausnahme ist. Wir arbeiten daher allgemein mit Anforderungen wie User Stories, Use Cases oder Features, die in einer Anforderungsliste ähnlich zu einem Product Backlog geführt werden. Diese Umstellung erfordert eine gänzlich andere Arbeitsweise, ermöglicht aber Agilität in einem abgesicherten Rahmen. Die bisher schon enthaltene iterative Vorgehensweise haben wir gestärkt, differenzieren uns dadurch aber auch weiterhin von einem vollständig agilen Vorgehen.

9 Vorwort zur zweiten Auflage ix 3. PMBOK Guide 5: Die Änderungen in der neuesten Fassung fünf des PMBOK Guide sind sofern sie uns relevant erschienen in das Buch eingeflossen. Entscheidend war für uns vor allem die Einführung des zusätzlichen Wissensgebiets»Stakeholder Management«. Zwar kann man leidlich darüber debattieren, ob dann nicht noch zahlreiche weitere Wissensgebiete relevant wären aber hier setzt das PMI für unsere Begriffe an der richtigen Stelle an. Wir haben daher unser Autorenteam um Ute Weber-Schäfer erweitert, die in ihrer beruflichen Praxis vorrangig Stakeholder Management und Teammanagement immer wieder gelebt, eingeführt und weiterentwickelt hat. 4. Konsequente Praxistauglichkeit: Unser Leitmotiv bei allen Richtungsentscheidungen innerhalb des Buches und des Vorgehensmodells war immer»gelebter Pragmatismus«. Brauchen wir wirklich noch eine Vorlage für persönliche Interviews? Muss man tatsächlich eine Offene-Punkte-Liste anbieten? Benötigt die Konfiguration der Prozesse der externen Beschaffung unbedingt einen eigenen Prozess? Das sind nur drei Beispiele, die wir mit»nein«beantwortet haben. Was nicht wirklich wertschöpfend war, haben wir aus dem Vorgehen entfernt oder doch zumindest vereinfacht. Unsere Basis ist und bleibt der PMBOK Guide. Wie auch in der ersten Auflage finden Sie zu jeder PITPM-Aktivität die Referenz zum entsprechenden Abschnitt im PMBOK Guide. Eingeflossen sind auch die Entwicklungen aus dem Umfeld des PMI-ACP, des»agile Certified Practitioners«. Dieses neue Zertifikat des PMI ist die Antwort auf die zahlreich vergebenen Zertifikate der Scrum Alliance im Umfeld der Agilität. Wir wünschen uns, dass wir mit dieser zweiten Auflage einen Beitrag zu mehr strukturiertem und systematischem Vorgehen in Softwareentwicklungsprojekten leisten können. Wie bisher stellen wir Ihnen auf sämtliche Vorlagen als Download kostenlos zur Verfügung. Wir freuen uns außerdem über Ihr Feedback zum Buch, zum Modell oder auch zu einzelnen Vorlagen. Niklas Spitczok von Brisinski Guy Vollmer und Ute Weber-Schäfer Ottobrunn, im Dezember 2013

10 x Vorwort zur zweiten Auflage

11 xi Vorwort zur ersten Auflage Als wir Anfang 2009 dem Verlag, Kollegen und Vorgesetzten unser Buchprojekt vorgestellt haben, stießen wir auf zwei gegenläufige Meinungsbilder. Diejenigen, die mit dem PMBOK Guide des PMI etwas anzufangen wussten, haben unser Vorhaben begrüßt und unterstrichen, dass das Werk eine Lücke füllen könne. Die anderen waren skeptisch: Softwareprojekte auf Basis des PMBOK Guide leiten ist das sinnvoll? Das Werk über die Zusammenfassung der»bewährten Praxis«des Projektmanagements hat systembedingt inhaltlich keinen Bezug zur Softwareentwicklung, bietet aber einen Bauchladen an Prozessen und Verfahren, um ein Projekt methodisch sicher zu führen. Aber muss sich in der Softwareentwicklung nicht alles der Technologie unterordnen? Das Gegenteil ist der Fall, und viele Gespräche, Diskussionen und Überlegungen später sind wir mehr denn je davon überzeugt, dass der PMBOK Guide sehr wohl dabei helfen kann, ein Softwareprojekt zu führen. Häufig mangelt es gerade in der Softwareentwicklung als recht junge Disziplin an methodischem Vorgehen. Es sollten aber zwei Punkte beachtet werden: Einige Unternehmen sprechen davon, den»pmbok Guide einzuführen«. Das ist etwas zu kurz gedacht: Der Guide beinhaltet lediglich die bewährte Praxis, nicht jedoch die Abbildung auf eine Branche oder gar das eigene Unternehmen. Die Prozesse des PMBOK Guide müssen angepasst werden, um sie betrieblich nutzbar zu machen. Das vorliegende Buch ist eine Anpassung für Softwareentwicklungsprojekte. Nicht jedes Projekt eignet sich für die in diesem Buch vorgestellte Vorgehensweise. Sie vereint zwar einige agile Ansätze in sich, ist aber für vollständig agile Projekte nicht oder nur bedingt geeignet. Einige Teilprozesse und einige der Vorlagen lassen sich dennoch auch in rein agilen Prozessen hervorragend einsetzen.

12 xii Vorwort zur ersten Auflage Unter Beachtung dieser Vorgaben bietet die Vorgehensweise einen methodisch sicheren und schnellen Einstieg in das eigene Projekt. Was aber macht die ganze Sache pragmatisch? Der PMBOK Guide in seiner Urform ist in etwa so pragmatisch wie die häufig bemühte und mittlerweile dankenswerterweise abgeschaffte EU-Verordnung zum Krümmungswinkel von Bananen und Gurken: inhaltlich schwer nachvollziehbar und erst einmal ohne Relevanz für Leben und Job. Neben der vorab erwähnten Interpretation des PMBOK Guide zur Verwendung in Softwareentwicklungsprojekten bedurfte es aus unserer Sicht daher weiterer Mittel, um ihn zu»pragmatisieren«: Uns fehlte ein Phasenmodell, die unmissverständliche Zuordnung von Prozessen zu Phasen, die Streichung nicht direkt wertschöpfender Prozesse und die vollständige Integration einfach zu benutzender Vorlagen in das Vorgehen. Das alles bieten wir nun in diesem Buch an. Das daraus entstandene Vorgehen»PITPM«(sprich»Pitpim«) steht einfach für den Titel des Buches:»Pragmatisches IT-Projektmanagement«. Wir hoffen, dass wir mit diesem Buch all denen aus der Seele sprechen, die den PMP (Project Management Professional) nicht nur gemacht haben, um ihn auf der Visitenkarte anzugeben, sondern die die Inhalte in Softwareentwicklungsprojekten wirklich anwenden wollen. Und allen Lesern ohne jegliche Zertifizierungsambitionen sei gesagt, dass sämtliche Prozesse auch ohne PMP- und PMBOK -Guide-Hintergrund leicht zu verstehen und anzuwenden sind. Das gilt natürlich auch für die Vorlagen, die Sie im Internet unter finden. Alles ganz pragmatisch. Wir sind beide Westfalen und verzichten gerne auf Schnörkel. Niklas Spitczok von Brisinski und Guy Vollmer, Ottobrunn, Dortmund Juni 2010

13 xiii Dankeschön! Ein Buch wie dieses schreibt sich nicht von allein uns haben viele Hände und Köpfe geholfen, die wichtigsten sind nachfolgend genannt: Beim dpunkt.verlag gilt unser ganz besonderer Dank Christa Preisendanz für ihr äußerst umsichtiges Lektorat und Michael Barabas für seine freundliche Unterstützung. Ein großes Dankeschön geht an Prof. Dr. Volker Gruhn, Michael Kenfenheuer und Dr. Rüdiger Striemer für die großzügige Unterstützung seitens der adesso AG, ohne die dieses Buch nicht entstanden wäre. Auf der letzten Wegstrecke hat Frau Prof. Dr. Heidi Heilmann mit ihrer durchweg schonungslosen, aber äußerst konstruktiven Kritik maßgeblich zur Qualität und Praktikabilität des Buches beigetragen. Dafür ein besonders großes»dankeschön«! Herbert Gonder, PMP und IPMA Level B, hat mit seinem fachlichen Hintergrund als Zertifikatsinhaber und Past President des PMI Chapter München vor allem auf die Übereinstimmung mit den Grundlagen des PMBOK Guide hingearbeitet. Sehr beeindruckt waren wir auch von der akribischen Arbeit von Ursula Zimpfer, die im Copy-Editing eine für uns Autoren beschämend große Menge von Fehlern gefunden und korrigiert hat. Die Ursprünge des Modells gehen zurück auf die adesso AG, daher gilt unser besonderer Dank Eberhard Wolff, Joachim Seidler, Dirk Platz, Andreas Hartmann, Karsten Tinnefeld, Alfred Broeckers, Michael Schmal, Michael Kemper, Michael Rittinghaus und Gregor Schwald sowie den vielen nicht namentlich genannten Kollegen, die sich schon zuvor um pragmatische Vorgehensweisen zur effizienten und effektiven Softwareentwicklung gekümmert haben. Manuela Gruhn hat mit ihrer großen Erfahrung die gesamte Produktion enorm unterstützt.

14 xiv Dankeschön!

15 xv Inhaltsverzeichnis 1 Einleitung 1 2 PMBOK Guide, PMI und PMP Project Management Professional (PMP ) Andere Projektmanagementzertifikate PMBOK Guide in»klassischen«it-projekten PMBOK Guide in agilen Projekten Softwareentwicklungsprojekte mit dem PMBOK Guide managen PITPM: PMBOK -Guide-basiertes Vorgehensmodell für Softwareentwicklungsprojekte Aufbau von PITPM PITPM-Knowledge-Areas PITPM-Projektphasen PITPM-Projektkontrollpunkte PITPM-Knowledge-Areas und -Phasen im Überblick Iterativ-agile Prozesse in PITPM PITPM-Projektrollen Vorlagen zum Download Vorbereitungsphase (V) Projektumfang bestimmen (V.1) Leistungsumfang bestimmen (V1.1) Grobanforderungen identifizieren (V1.2) Projektorganisation definieren (V1.3) Aufwand abschätzen (V.1.4)

16 xvi Inhaltsverzeichnis 4.2 Risiken analysieren (V.2) Risiken identifizieren (V.2.1) Risiken bewerten und priorisieren (V.2.2) Projekt beauftragen (V.3) Projektauftrag entwickeln und bereitstellen (V.3.1) Kontrollpunkt 1: Projektauftrag erteilt Planungsphase (P) Projekt konfigurieren (P.1) Projektteam aufstellen (P.1.1) Kick-off-Workshop durchführen (P.1.2) Projektmanagementplan entwickeln (P.1.3) Risikoplanung konfigurieren (P.1.4) Beschaffung und Zulieferungen planen (P.1.5) Projekt-Controlling aufsetzen (P.1.6) Projektkommunikation planen (P.1.7) Softwareentwicklung konfigurieren (P.1.8) Anforderungsanalyse planen (P.1.9) Change-Request-Prozess planen (P.1.10) Qualitätsplan erstellen (P.1.11) Kontrollpunkt 2: Projekt konfiguriert Stakeholder analysieren (P.2) Stakeholder identifizieren (P.2.1) Anforderungsgeber identifizieren (P.2.2) Stakeholder einschätzen (P.2.3) Maßnahmen planen (P.2.4) Anforderungsliste erstellen (P.3) Anforderungen erheben (P.3.1) Anforderungsliste priorisieren (P.3.2) Anforderungsliste fertigstellen (P.3.3) Release- und Iterationsplan entwickeln (P.4) Release- und Iterationsplan entwickeln (P.4.1)

17 Inhaltsverzeichnis xvii 5.5 Projektplan erstellen (P.5) Basis-Projektplan erstellen (P.5.1) Ressourcen planen (P.5.2) Kontrollpunkt 3: Projektplanung abgenommen Durchführungsphase (D) Teams bilden und Aufgaben zuweisen (D.1) Teams bilden (D.1.1) Teammitglied ein- oder ausplanen (D.1.2) Aufgaben übergeben (D.1.3) Teambarometer einrichten (D.1.4) Projektteam steuern (D.2) Teamphase identifizieren (D.2.1) Teambarometer auswerten (D.2.2) Projektteam entwickeln (D.2.3) Projektumfang kontrollieren und anpassen (D.3) Projektumfang verifizieren (D.3.1) Change Request verfassen (D.3.2) Change-Request-Prozess auslösen (D.3.3) Feinspezifikation für Iteration erstellen (D.4) Feinspezifikation für Iteration erstellen (D.4.1) Feinspezifikation technisch abnehmen (D.5) Feinspezifikation technisch überprüfen und abnehmen (D.5.1) Kontrollpunkt 4: Planung der Iteration abgenommen Projektkommunikation steuern (D.6) Projektstatusbericht erstellen (D.6.1) Informationen zur Verfügung stellen (D.6.2) Stakeholder einbeziehen und informieren (D.6.3) Projektteam einbeziehen und informieren (D.6.4) Risiken überwachen (D.7) Bestehendes Risikoregister abgleichen und ergänzen (D.7.1) Maßnahmen zur Risikobewältigung planen (D.7.2)

18 xviii Inhaltsverzeichnis 6.8 Zulieferungen steuern (D.8) Externe Zulieferungen kontrollieren und bewerten (D.8.1) Externe Leistung abrechnen (D.8.2) Vertrag kündigen (D.8.3) Dienstleister bewerten (D.8.4) Software entwickeln (D.9) Software entwerfen (D.9.1) Software implementieren (D.9.2) Software testen (D.9.3) Projektkosten überwachen (D.10) Projektkostendaten erfassen (D.10.1) Projektkosten aktualisieren (D.10.2) Software testen (D.11) Tests durchführen und protokollieren (D.11.1) Test dokumentieren (D.11.2) Iteration abschließen und bereitstellen (D.12) Ergebnis mit Planung abgleichen (D.12.1) Endgültiges Deployment durchführen (D.12.2) Abgeschlossene Iteration bewerten und folgende planen (D.12.3) Kontrollpunkt 5: Bereitstellung zur Abnahme Einführungsphase (E) Einführung planen (E.1) Einführung planen (E.1.1) Abnahmetest durchführen (E.2) Abnahmetestbereitschaft erklären (E.2.1) Abnahmetest koordinieren (E.2.2) Abnahmetest durchführen (E.2.3) Abnahme erklären (E.2.4) Liefergegenstand nachbessern (E.2.5) Kontrollpunkt 6: Abnahme erteilt

19 Inhaltsverzeichnis xix 7.3 Produkt einführen (E.3) Produkt einführen (E.3.1) Produktverantwortung abgeben (E.3.2) Kontrollpunkt 7: Produktionsstart Abschlussphase (A) Projekt abschließen (A.1) Projekt abschließen (A.1.1) Risikoregister schließen (A.2) Projekterkenntnisse festhalten (A.2.1) Risikoregister schließen (A.2.2) Teammitglieder ausplanen (A.3) Verträge beenden (A.4) Verträge beenden (A.4.1) Projektkostenrechnung abschließen (A.5) Feedback zu den Projektkosten erstellen (A.5.1) Postmortem durchführen (A.6) Postmortem durchführen (A.6.1) Abschließenden Projektbericht verfassen (A.6.2) Kontrollpunkt 8: Projekt beendet Implementierung eines Vorgehensmodells Vorgehensweise Phase 1: Untersuchen Phase 2: Definieren Phase 3: Testen Phase 4: Implementieren Phase 5: Betreiben und Optimieren Weitere Aufgaben und Abgrenzung zum PMO

20 xx Inhaltsverzeichnis Anhang 275 A Überblick über die bekanntesten Projektmanagementzertifikate mit IT-Relevanz 277 A.1 IPMA A.2 PRINCE A.3 isqi und IREB A.4 Scrum: CSPO und CSM A.5 PMI : PMI-ACP, CAPM, PgMP und andere A.6 Andere Zertifikate B Glossar 287 C Literaturverzeichnis 291 Stichwortverzeichnis 297

21 1 1 Einleitung Jedes Softwareentwicklungsprojekt hat ein individuelles Ziel und ist in seiner Form einmalig. Hierbei gilt es, die individuellen Vorstellungen, Wünsche und oftmals komplexen oder sich teilweise widersprechenden Anforderungen des Kunden mit strikten ökonomischen, zeitlichen oder technologischen Vorgaben in Einklang zu bringen. Zudem werden im Rahmen eines Softwareentwicklungsprojektes immer verschiedene Charaktere mit unterschiedlichen Erfahrungen, Kenntnissen und Fertigkeiten für einen begrenzten Zeitraum zusammengebracht, um ein kundenspezifisches Softwaresystem zu entwickeln. Projektteams in der Softwareentwicklung sehen sich in diesem Kontext oftmals mit erheblichen Herausforderungen konfrontiert: Sie müssen unter anderem die Erwartungen des Fachbereichs mit den technischen und ökonomischen Möglichkeiten in Einklang bringen, Risiken früh erkennen, kontrollieren und im schlimmsten Fall Fehlentwicklungen ausbaden. Und das zu einem möglichst niedrigen Preis bei gleichbleibend hohen Qualitätsanforderungen des Kunden. Zahlreiche Softwareentwicklungsprojekte haben große Mühe, dieses Spannungsfeld zwischen Anforderungen, Technologie, Risiken und Kosten erfolgreich zu meistern. Oftmals verzögern sich diese Projekte, liefern ein anderes, bisweilen funktional reduziertes Ergebnis oder werden teurer als ursprünglich geplant. Auch wenn es seit etlichen Jahren eine Vielzahl von Vorgehensund Prozessmodellen für die industrielle Softwareentwicklung gibt, die Fehlentwicklungen konstruktiv entgegenwirken sollen, sind doch immer wieder Fehlschläge zu konstatieren. Vor diesem Hintergrund ist es hilfreich, sowohl Entwicklungen wie Agilität in der Softwareentwicklung zu berücksichtigen als auch über den eigenen Tellerrand zu blicken und von bewährten internationalen Methoden aus dem Bereich des Projektmanagements zu lernen. Hierbei fiel der Blick schnell auf den bewährten PMBOK Guide des PMI (zugunsten der besseren Lesbarkeit verzichten wir ab hier auf das Warenschutzzeichen hinter den Akronymen des PMI im Fließtext). Kein Softwareprojekt ist wie das andere. Zahlreiche Projekte erreichen die gesteckten Ziele nicht.

22 2 1 Einleitung PMBOK Guide des PMI Pragmatisches IT-Projektmanagement Der PMBOK Guide fokussiert in seiner Form als Sammlung bewährter Praxis allerdings keine Softwareentwicklungsprojekte und ist so auch nicht softwarespezifisch ausgeprägt. Er ist generisch konzipiert und kann theoretisch vom Industrieanlagenbau über Sozialprojekte bis hin zu Restrukturierungen eingesetzt werden. Folglich lässt er sich nicht ohne Anpassungen in Softwareentwicklungsprojekten anwenden. Zudem ist der Guide auf den angloamerikanischen Raum ausgerichtet, sodass er auch aus kulturellen und rechtlichen Erwägungen heraus nur mittelbar für Softwareentwicklungsprojekte aus dem deutschsprachigen bzw. europäischen Raum geeignet ist. Um den PMBOK Guide des PMI auch in Softwareentwicklungsprojekten unmittelbar einsetzen zu können, ist neben einer entsprechenden Adaptierung die praktische Erprobung in mittleren und großen Softwareentwicklungsprojekten vonnöten. Beide Voraussetzungen wurden im Rahmen dieses Buches geschaffen. Als Ergebnis wird ein praxiserprobtes Vorgehen auf Basis des PMBOK Guide präsentiert, das agile Anteile enthält, aber dennoch gelebte Praxis widerspiegelt und so pragmatisch in Softwareentwicklungsprojekten eingesetzt werden kann. Für die Leser, die bereits die erste Auflage dieses Buches kennen, besteht die wohl wichtigste Änderung in der Vereinfachung des iterativen Vorgehens: Iterationsplanung und -durchführung finden nun zeitversetzt im Rahmen der Durchführungsphase statt. Etliche Beispiele zeigen, warum sich etwas mehr»pragmatische«methodik auszahlen kann, um so die Erfolgswahrscheinlichkeit Ihres Projektes substanziell zu erhöhen. Auf Grundlage des PMBOK Guide wurde eine sehr gut nachvollziehbare, praxisnah anwendbare sowie höchst effiziente Vorgehensweise für das Management von Softwareentwicklungsprojekten entwickelt, die in diesem Buch vorgestellt wird. Hilfreiche Prozessabbildungen, zahlreiche Vorlagen für Ergebnisdokumente sowie eine PMBOK-Guide-Referenz gibt es inklusive. Tipp:»Leichte«Vorgehensmodelle für havarierte Projekte Wenn einem Projekt eine Schieflage droht, gilt der erste Gedanke für gewöhnlich nicht der eingesetzten Projektmethode. Ob sich ein Seitenblick auf den Reifegrad des Methodikeinsatzes dennoch lohnt, haben wir gemeinsam mit den Autoren des»turnaround ThinkTanks«untersucht. Mit dem Ergebnis, dass zumindest eine Facette des Projekterfolgs (im Falle einer Havarie dann eher des Misserfolgs) doch davon abhängt. TurnAround setzt daher PITPM als»leichtes«vorgehensmodell ein, um havarierten Projekten eine gewisse Grundstruktur zu geben.

23 1 Einleitung 3»TurnAround. Wenn Projekte kopfstehen und klassisches Projektmanagement versagt«ist ein Buchprojekt, das die TurnAround-Experten Roger Dannenhauer, Torsten J. Koerting und Michael Merkwitza angestoßen haben. Das Buch bietet TurnAround-Projektmanagern ganz neue Ansätze und Ideen: Es beschäftigt sich mit den fünf Phasen des TurnAround und beleuchtet für jede Phase Kennzeichen, Probleme und Lösungsmethoden. Leitmotiv ist es, den Mensch in den Mittelpunkt zu stellen. Das Buch zielt auf eine neue Projektkultur, in der die Geisteshaltung eine zentrale Rolle spielt denn ohne sie bringt keine Methode das gewünschte Ergebnis (vgl. [Dannenhauer et al. 2013]). Zielgruppe und Struktur des Buches Zur Zielgruppe dieses Buches zählen Manager, IT-Leiter und Projektmanager von kleinen bis mittleren Softwareentwicklungsprojekten aus Industrie und Forschung. Zudem gehören System- und Anforderungsanalytiker, Softwarearchitekten und -entwickler und Organisationsberater zur Zielgruppe. Ein mittleres Projekt ist dabei wie folgt definiert: Zielgruppe Teamgröße von vier bis max. zwölf Personen Laufzeit etwa drei bis zwölf Monate Aufwand etwa 50 bis 500 Personentage Das Buch besteht aus neun Kapiteln, wovon sich fünf unmittelbar mit dem Vorgehensmodell zur pragmatischen Softwareentwicklung beschäftigen. Nach der Einleitung und der Einführung in das Modell in Kapitel 1 und 2 werden in Kapitel 3 die Struktur und Rahmenbedingungen geklärt, um mit dem PMBOK Guide Softwareentwicklungsprojekte zweckmäßig managen und durchführen zu können. In Kapitel 4 wird auf die Vorbereitungsphase von Softwareentwicklungsprojekten Bezug genommen. Hierzu zählen unter anderem die Bestimmung des Projektumfangs und die Erteilung des Projektauftrags zu den wichtigsten Aktivitäten. In Kapitel 5 werden die Aktivitäten der Planungsphase eines Softwareentwicklungsprojektes detailliert beschrieben. Hierzu gehört neben der Projektkonfiguration mit größtenteils organisatorischen Aspekten auch der umfangreiche Prozess der Planung des Anforderungsmanagements. Zudem gibt es in dieser Phase eine Reihe von Konfigurationsprozessen, unter anderem die Konfiguration der Qualitäts- und Risikoplanung. In der Durchführungsphase in Kapitel 6 werden neben der eigentlichen Erzeugung des Softwareprodukts weitestgehend Prozesse und Aktivitäten zur Steuerung, Lenkung und ggf. erforderlichen Anpassung des Projektes durchgeführt. Struktur des Buches

24 4 1 Einleitung In Kapitel 7 wird die Einführungsphase des entwickelten Softwareprodukts beschrieben. Neben der vorbereitenden Einführungsplanung steht hier der zentrale Prozess der Softwareauslieferung und -einführung beim Kunden auf der Agenda. Kapitel 8 beschäftigt sich mit der Abschlussphase. Hierbei werden unter anderem die Kostenrechnung abgeschlossen sowie das Postmortem zum Projekt durchgeführt. Die konkrete Implementierung eines Vorgehensmodells ist zentraler Gegenstand von Kapitel 9. Im Anhang befinden sich ein kurzer Überblick über relevante Projektmanagementzertifikate, ein Glossar mit einer Erläuterung relevanter Fachbegriffe, das Literatur- und Quellenverzeichnis sowie der Index. Zudem ist dem Buch ein großformatiges Poster beigelegt, aus dem die Prozesse und Dokumentationsflüsse im Detail hervorgehen. Konventionen und Notationen PMBOK Guide Ed. 5 Abkürzungen werden bei ihrer ersten Verwendung im Text zunächst im Volltext geschrieben und in Klammern abgekürzt, um sie anschließend in ihrer abgekürzten Form durchgängig weiter zu verwenden. Zur besseren Lesbarkeit und Hervorhebung werden einzelne Begriffe fett oder kursiv gesetzt. Bei der Beschreibung von Personen und Rollen wird der Einfachheit halber grundsätzlich die maskuline Ausprägung verwendet. Somit bezeichnet die maskuline Form einer Person bzw. einer Rolle sowohl die männliche als auch die weibliche Ausprägung, ohne dadurch eine Wertung vorzunehmen. Als zentrale Referenz und Literaturquelle wird der PMBOK Guide (5. Ausgabe) in englischer Sprache referenziert (vgl. [PMI 2012]). Die deutsche Fassung war zum Zeitpunkt der Erstellung des Buches noch nicht verfügbar. Tipp: PMBOK Guide als Referenz Zwar ist der Besitz des PMBOK Guide Edition 5 nicht zwingende Voraussetzung, um die Inhalte des Buches nachvollziehen zu können. Dennoch sei der Erwerb all denen empfohlen, die tiefer in die Thematik einsteigen wollen. Business Process Modeling Notation (BPMN) Sämtliche Prozesse und Abläufe wurden auf Basis der Business Process Modeling Notation (BPMN) entworfen und modelliert, wobei stellenweise auf eine konforme Darstellung zugunsten besserer Nachvollziehbarkeit verzichtet wurde. Die BPMN ist eine grafische Modellierungssprache für Arbeits- und Geschäftsprozesse, die von der Object Management Group (OMG) kontinuierlich als De-facto-Industrie-

25 1 Einleitung 5 standard aktualisiert und versioniert wird. Die Notation verzichtet auf komplexe Konstrukte. BPMN im Internet Mehr Informationen zu BPMN finden Sie im Internet, z.b. unter oder in [Weilkiens et al. 2010]. Die grafischen Elemente der BPMN werden eingeteilt in (s. dazu auch Abb. 1 1): Flow Objects, also der Knoten oder der einzelne Schritt im Diagramm, Connecting Objects, also die verbindenden Kanten zwischen den Schritten, Swimlanes als die organisatorischen Bereiche, in denen mehrere Akteure an einem Prozess beteiligt sind, Artefacts, also die Eingangs- oder Ausgangsdokumente aus einer Aktivität. Abb. 1 1 Die wichtigsten Elemente der BPMN

26 6 1 Einleitung Mit diesen Mitteln können Prozesse einfach dargestellt werden. Auf eine detaillierte Einführung wird an dieser Stelle verzichtet, denn die Diagramme sind weitgehend selbsterklärend. Erwähnenswert ist, dass der Inhaber einer Swimlane einen Prozess oder eine Aktivität nicht zwingend selbst erbringen muss, jedoch für das Ergebnis verantwortlich ist und sie daher anleitet. So ist beispielsweise für die Schätzung der Projektmanager verantwortlich, der diese jedoch für gewöhnlich nicht alleine durchführen wird. Tipp: Alle Vorlagen im Internet Sämtliche hier vorgestellten Vorlagen und Checklisten finden Sie auch im Internet unter Die dort abgelegten Dateien aktualisieren wir laufend, der Download ist für Sie kostenlos. Über Ihr Feedback freuen wir uns unter info@pitpm.net.

27 7 2 PMBOK Guide, PMI und PMP In den vergangenen drei Jahrzehnten hat sich ein stetig steigender personeller Bedarf für die Organisationsform»Projekt«entwickelt, wodurch ein eigenes Qualifikationsprofil hervorgebracht wurde: der»projektmanager«. Vor diesem Hintergrund gibt es mittlerweile eine Vielzahl von Einrichtungen, Organisationen und Institutionen, die jeweils auf ihre eigene Art und Weise Projektmanagement lehren oder zertifizieren.»projektmanager«versus»projektleiter«in diesem Buch sprechen wir durchgehend vom Projektmanager als höchste organisatorische Instanz im operativen Projekt. In der Literatur gibt es keine einheitliche Abgrenzung zwischen einem Projektmanager und einem Projektleiter. Aus unserer Sicht ist das»managen«eines Projektes umfassender und aktiver als das»leiten«. Der Projektmanager kann daher, je nach Organisationsform, fachliche oder technische Projektleiter in seinem Team haben. Unsere Definition kann durchaus von Definitionen in anderen Werken abweichen. Die weltweit größte Projektmanagementorganisation ist das Project Management Institute (PMI). Es wurde 1969 in Atlanta (USA) mit dem Ziel gegründet, ein einheitliches Projektmanagementverfahren zu schaffen. Die stark amerikanisch geprägte Organisation nahm 2003 das Mitglied auf, Ende 2008 waren es weltweit gut Mitglieder, mit Stand Juli 2013 gibt das PMI in der Mitgliederzeitschrift PMI Today die Mitgliederzahl mit über weltweit an ein beachtenswertes Wachstum. Ein Überblick über weitere relevante Zertifizierungen anderer Organisationen im Umfeld des Projektmanagements findet sich im Anhang. Das PMI hat mit der Standardisierung der systembezogenen Inhalte und dem Aufbau eines weltweit einheitlichen Projektmanagementzertifikats zur globalen Vereinheitlichung des Projektmanage- Project Management Institute (PMI) Standardisierung des Projektmanagements durch das PMI

28 8 2 PMBOK Guide, PMI und PMP ments beigetragen. Durch die weltumspannende Organisation mit einem einheitlichen Projektmanagementstandard ist ein stetig wachsendes Netzwerk entstanden, denn jedes Mitglied kann nur profitieren, wenn es das System selbst im positiven Sinne vertritt. Die zwei wesentlichen Errungenschaften des PMI sind denn auch die Treiber des Erfolgs: zum einen die Erstellung des Methodenwerkes»A Guide to the Project Management Body of Knowledge«, kurz nur»pmbok Guide«genannt, zum anderen das dazugehörige Zertifikat zum Project Management Professional (PMP). PMBOK Guide PMBOK Guide Der Titel des Werkes wird etwa»pimbock Gaid«ausgesprochen und kürzt den langen Titel so akzeptabel ab. Sprechen Sie in Anwesenheit eines PMP niemals nur vom»pmbok«ohne»guide«er wird Sie darauf hinweisen, dass das Werk ja nur der»guide«zum»body of Knowledge«ist. Das»BoK«verleitet deutsche Muttersprachler gelegentlich, an ein»book«als Buch zu denken. Das ist hier aber nicht gemeint. PMBOK Guide unterliegt den Standards ANSI und IEEE. CAPM und PMP In der Einführung bezeichnen die Autoren das Werk als kollektive Zusammenfassung des Wissens der Fachrichtung Projektmanagement. Es ist also im Wesentlichen eine Sammlung der Vorgehensweisen, die insbesondere im angloamerikanischen Raum als bewährte Praxis anerkannt sind. Die beschriebenen Methoden sind auf Projekte aus verschiedenen Anwendungsbereichen anwendbar. Der PMBOK Guide ist prozessorientiert, und ein Projekt kann demnach nur durch die erfolgreiche Koordination vieler Prozesse durchgeführt werden. Das American National Standards Institute (ANSI) und das Institute of Electrical and Electronics Engineers (IEEE) erkennen den PMBOK Guide als Standard an. Der 1986 erstmals aufgelegte Guide wurde 1991 in den ANSI-Standard aufgenommen und obliegt damit regelmäßigen Aktualisierungen. Die erste offizielle Version vom PMBOK Guide wurde 1994 veröffentlicht, im Dezember 2012 wurde die Edition fünf freigegeben. Auf Basis des PMBOK Guide erfolgen die Prüfungen zum geringer qualifizierten»certified Associate in Project Management«(CAPM), zum neuen»agile Certified Professional«(ACP) und vor allem zum umfangreicheren»project Management Professional«(PMP). Die Zertifikate sind der zweite wesentliche Baustein im Konzept des PMI. Im folgenden Abschnitt wird das Zertifikat PMP kurz vorgestellt.

29 2.1 Project Management Professional (PMP ) Project Management Professional (PMP ) Im Rahmen eines vierstündigen, computergestützten Multiple-Choice- Tests mit 200 Fragen werden die Inhalte des PMBOK Guide und der Examination Content Outline, Revised August 2011 (vgl. [PMI b]) abgefragt. Die bisherige Exam Specification (vgl. [PMI 2005]) wird durch das neue und kostenlos erhältliche Content Outline ersetzt. Wer den Test bestanden hat, darf anschließend für drei Jahre den Titel PMP führen. Zu Anfang des Jahres 2013 können das weltweit über Personen, in Deutschland davon immerhin knapp (vgl. [Oestereich et al. 2013]). Das macht sich nicht nur gut auf der Visitenkarte: Wer die Theorie auf sein Arbeitsumfeld überträgt, arbeitet in Projekten meist sicherer und zielstrebiger. Auch wenn nicht jeder Zertifikatsinhaber automatisch ein brillanter Projektmanager ist und umgekehrt ein brillanter Projektmanager nicht zwangsläufig ein Zertifikat benötigt. PMBOK Guide, PMP und alle damit verbundenen Aktivitäten haben maßgeblich den Erfolg des PMI bestimmt, sodass heute ein einheitlicher Standard die globale Kooperation in Projekten zwischen Unternehmen und Kulturen vereinfacht. Das PMI ist in Größe und Ausrichtung damit weltweit konkurrenzlos. Allerdings: Eine Organisation wie das PMI mit einem Umsatz von über 142 Millionen US$ und einem Barvermögen von über 19 Millionen US$ (Stand Jahresende 2011, [PMI 2011-a]) ist kein Wohltätigkeitsverein es ist schlichtweg ein kommerzieller Wirtschaftsbetrieb, der wie jedes andere Unternehmen seine Angestellten bezahlen muss. Wer die Prüfung zum PMP bestehen will, muss neben Erfahrung vor allem über die nötigen Finanzen verfügen: Ohne Bücher zur Prüfung lässt sich schwerlich lernen, zudem sollte ein Kurs belegt werden, bei dem die Inhalte dem Projektmanagementverständnis des PMBOK Guide entsprechen. Der Kurs ist zwar nicht verpflichtend und kann durch jedes andere Projektmanagementseminar mit vergleichbaren Inhalten ersetzt werden, ein Besuch erhöht die Erfolgswahrscheinlichkeit aber ganz sicher. Die Prüfung kostet aktuell 405 US$ bzw. 340 für PMI-Mitglieder (Stand Juni 2013), die Mitgliedschaft liegt derzeit bei 139 US$ einmalig und 129 US$ für jedes Folgejahr. Mit Kurs, Material und allen Nebenkosten kommen so einmalig zwischen und zusammen. Eine dennoch lohnenswerte Investition, insbesondere wenn der Arbeitgeber die Kosten übernimmt. Ebenso wie der PMBOK Guide regelmäßig vom PMI zu aktualisieren ist, so muss ein PMP innerhalb der dreijährigen Laufzeit seines Zertifikats Punkte in Form von»professional Development Units«(PDUs) sammeln und damit seine Weiterentwicklung dokumentieren. Das Zertifikat PMP gilt drei Jahre.

30 10 2 PMBOK Guide, PMI und PMP Professional Development Units (PDUs) dokumentieren die Erhaltung des Zertifikats. Continuing Certification Requirements (CCR) beschreiben die Rahmenbedingungen zum Erhalt des Status. PMI Communities of Practice Chapters sind weitestgehend autarke Lokalverbände des PMI. Ähnlich wie bei den beliebten Bonusmeilenprogrammen bekommt ein PMP für die Teilnahme an Seminaren, Vorträgen oder Fachbeiträgen Punkte gutgeschrieben. Hat er im Gültigkeitszeitraum genug Punkte gesammelt, darf er sich zwar nicht an den Petits Fours in der Business Class Lounge gütlich tun, aber gegen Zahlung von derzeit 60 US$ (für PMI-Mitglieder, alle anderen zahlen 150 US$) als Gebühr für die Anerkennung der»continuing Certification Requirements«(CCR) wird ihm für weitere drei Jahre das Zertifikat verliehen. Alternativ kann auch die vierstündige Prüfung wiederholt werden, die prinzipiell ohne Lernaufwand bestanden werden müsste. Es soll tatsächlich einige Hartgesottene geben, die das tun. Schwierig wird es nur, wenn es zwischenzeitlich einen Editionswechsel des PMBOK Guide gegeben hat: Dann muss der Prüfling zumindest die neuen Inhalte lernen. Da durch den ANSI-Standard alle vier Jahre eine neue Edition vorgelegt werden muss, muss man spätestens bei der zweiten Wiederholung neuen Stoff lernen. Zudem unterliegt die Zertifizierung der ISO 17024, die u.a. beinhaltet, dass sich alle fünf bis sieben Jahre auch die Prüfungsordnung ändern soll. Derzeit stammt sie aus dem August 2011 (vgl. [PMI 2011-b]). Einfacher wäre es, einen der (für gewöhnlich kostenpflichtigen) PDU-fähigen Kurse der vielen zertifizierten Anbieter zu besuchen. Oder sich Kurse anderer Seminaranbieter anrechnen zu lassen. Erfreulicherweise zählen da auch»inhouse«-seminare, sofern sie dem Projektmanagement zuzurechnen sind. Oder man tritt einer PMI Community of Practice bei, die mittlerweile häufig einstündige Webseminare anbieten, die jeweils eine PDU bringen. Es gibt auch ganz andere Möglichkeiten, um PDUs zu verdienen. Neben dem Selbststudium wird zum Beispiel Projektarbeit in Non- Profit-Organisationen ebenso honoriert wie die Mitarbeit an Fachartikeln oder Büchern zum Projektmanagement. Wer sämtliche Regeln kennt und unmittelbar nach der Zertifizierung damit beginnt, fleißig PDUs zu sammeln, kommt bequem und weitgehend ohne Zusatzkosten zum Ziel. Zudem gibt es»chapters«, also vom PMI autorisierte Vereine, die überregional agieren. Die Teilnahme an einem»chapter Meeting«, auf dem es projektmanagementbezogene Vorträge und die Möglichkeit für einen persönlichen Austausch gibt, wird für gewöhnlich mit einer PDU je Stunde honoriert. Für Einsteiger mag der ungewohnt hohe und relativ strikte Organisationsgrad der Chapter, Communitys und verwandter Einheiten abschreckend wirken: Da gibt es einen»chair«,»vice Chairs«und