Pragmatisches IT-Projektmanagement E-Book

Niklas Spitczok von Brisinski

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2014

Seitenzahl: 376

Beschreibung

Jedes Softwareentwicklungsprojekt ist einmalig. Es bringt unterschiedlichste Charaktere für einen begrenzten Zeitraum mit dem Ziel zusammen, ein neues, herausragendes Produkt zu entwickeln. Dieses Buch zeigt ein praxiserprobtes Vorgehen, das Softwareprojekte zum gewünschten Erfolg bringen kann. Basierend auf dem PMBOK Guide des Project Management Institute stellt es eine einfache, effiziente Vorgehensweise für das Management von Softwareentwicklungsprojekten vor. Die 2. Auflage berücksichtigt die Änderungen, die sich durch den neuen PMBOK Guide 5 ergeben.

Leseprobe

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 Software-technik 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.

Pragmatisches IT-Projektmanagement

Softwareentwicklungsprojekte auf Basis des PMBOK® Guide führen

2., überarbeitete und aktualisierte Auflage

Niklas Spitczok von BrisinskiGuy VollmerUte Weber-Schäfer

Niklas Spitczok von Brisinski · [email protected]

Guy Vollmer · [email protected]

Ute Weber-Schäfer · [email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Herstellung: Birgit Bäuerlein

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · [email protected]

Bibliografische Information der Deutschen Nationalbibliothek

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

ISBN:

Buch 978-3-86490-045-7

PDF 978-3-86491-452-2

ePub 978-3-86491-453-9

2., überarbeitete und aktualisierte Auflage 2014

Copyright © 2014 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 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 4 3 2 1 0

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 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 GruhnEssen, im Dezember 2013

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ßerhalb 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.

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 www.pitpm.net 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

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.

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 http://www.PITPM.net 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

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.

Inhaltsverzeichnis

1       Einleitung

2       PMBOK® Guide, PMI® und PMP®

2.1    Project Management Professional (PMP®)

2.2    Andere Projektmanagementzertifikate

2.3    PMBOK® Guide in »klassischen« IT-Projekten

2.4    PMBOK® Guide in agilen Projekten

3       Softwareentwicklungsprojekte mit dem PMBOK® Guide managen

3.1    PITPM: PMBOK®-Guide-basiertes Vorgehensmodell für Softwareentwicklungsprojekte

3.2    Aufbau von PITPM

3.3    PITPM-Knowledge-Areas

3.4    PITPM-Projektphasen

3.5    PITPM-Projektkontrollpunkte

3.6    PITPM-Knowledge-Areas und -Phasen im Überblick

3.7    Iterativ-agile Prozesse in PITPM

3.8    PITPM-Projektrollen

3.9    Vorlagen zum Download

4       Vorbereitungsphase (V)

4.1    Projektumfang bestimmen (V.1)

4.1.1     Leistungsumfang bestimmen (V1.1)

4.1.2     Grobanforderungen identifizieren (V1.2)

4.1.3     Projektorganisation definieren (V1.3)

4.1.4     Aufwand abschätzen (V.1.4)

4.2    Risiken analysieren (V.2)

4.2.1     Risiken identifizieren (V.2.1)

4.2.2     Risiken bewerten und priorisieren (V.2.2)

4.3    Projekt beauftragen (V.3)

4.3.1     Projektauftrag entwickeln und bereitstellen (V.3.1)

4.3.2     Kontrollpunkt 1: Projektauftrag erteilt

5       Planungsphase (P)

5.1   Projekt konfigurieren (P.1)

5.1.1     Projektteam aufstellen (P.1.1)

5.1.2     Kick-off-Workshop durchführen (P.1.2)

5.1.3     Projektmanagementplan entwickeln (P.1.3)

5.1.4     Risikoplanung konfigurieren (P.1.4)

5.1.5     Beschaffung und Zulieferungen planen (P.1.5)

5.1.6     Projekt-Controlling aufsetzen (P.1.6)

5.1.7     Projektkommunikation planen (P.1.7)

5.1.8     Softwareentwicklung konfigurieren (P.1.8)

5.1.9     Anforderungsanalyse planen (P.1.9)

5.1.10    Change-Request-Prozess planen (P.1.10)

5.1.11    Qualitätsplan erstellen (P.1.11)

5.1.12    Kontrollpunkt 2: Projekt konfiguriert

5.2    Stakeholder analysieren (P.2)

5.2.1     Stakeholder identifizieren (P.2.1)

5.2.2     Anforderungsgeber identifizieren (P.2.2)

5.2.3     Stakeholder einschätzen (P.2.3)

5.2.4     Maßnahmen planen (P.2.4)

5.3    Anforderungsliste erstellen (P.3)

5.3.1     Anforderungen erheben (P.3.1)

5.3.2     Anforderungsliste priorisieren (P.3.2)

5.3.3     Anforderungsliste fertigstellen (P.3.3)

5.4    Release- und Iterationsplan entwickeln (P.4)

5.4.1     Release- und Iterationsplan entwickeln (P.4.1)

5.5    Projektplan erstellen (P.5)

5.5.1     Basis-Projektplan erstellen (P.5.1)

5.5.2     Ressourcen planen (P.5.2)

5.5.3     Kontrollpunkt 3: Projektplanung abgenommen

6       Durchführungsphase (D)

6.1    Teams bilden und Aufgaben zuweisen (D.1)

6.1.1     Teams bilden (D.1.1)

6.1.2     Teammitglied ein- oder ausplanen (D.1.2)

6.1.3     Aufgaben übergeben (D.1.3)

6.1.4     Teambarometer einrichten (D.1.4)

6.2    Projektteam steuern (D.2)

6.2.1     Teamphase identifizieren (D.2.1)

6.2.2     Teambarometer auswerten (D.2.2)

6.2.3     Projektteam entwickeln (D.2.3)

6.3    Projektumfang kontrollieren und anpassen (D.3)

6.3.1     Projektumfang verifizieren (D.3.1)

6.3.2     Change Request verfassen (D.3.2)

6.3.3     Change-Request-Prozess auslösen (D.3.3)

6.4    Feinspezifikation für Iteration erstellen (D.4)

6.4.1     Feinspezifikation für Iteration erstellen (D.4.1)

6.5    Feinspezifikation technisch abnehmen (D.5)

6.5.1     Feinspezifikation technisch überprüfen und abnehmen (D.5.1)

6.5.2     Kontrollpunkt 4: Planung der Iteration abgenommen

6.6    Projektkommunikation steuern (D.6)

6.6.1     Projektstatusbericht erstellen (D.6.1)

6.6.2     Informationen zur Verfügung stellen (D.6.2)

6.6.3     Stakeholder einbeziehen und informieren (D.6.3)

6.6.4     Projektteam einbeziehen und informieren (D.6.4)

6.7    Risiken überwachen (D.7)

6.7.1     Bestehendes Risikoregister abgleichen und ergänzen (D.7.1)

6.7.2     Maßnahmen zur Risikobewältigung planen (D.7.2)

6.8    Zulieferungen steuern (D.8)

6.8.1     Externe Zulieferungen kontrollieren und bewerten (D.8.1)

6.8.2     Externe Leistung abrechnen (D.8.2)

6.8.3     Vertrag kündigen (D.8.3)

6.8.4     Dienstleister bewerten (D.8.4)

6.9    Software entwickeln (D.9)

6.9.1     Software entwerfen (D.9.1)

6.9.2     Software implementieren (D.9.2)

6.9.3     Software testen (D.9.3)

6.10    Projektkosten überwachen (D.10)

6.10.1     Projektkostendaten erfassen (D.10.1)

6.10.2     Projektkosten aktualisieren (D.10.2)

6.11    Software testen (D.11)

6.11.1     Tests durchführen und protokollieren (D.11.1)

6.11.2     Test dokumentieren (D.11.2)

6.12    Iteration abschließen und bereitstellen (D.12)

6.12.1     Ergebnis mit Planung abgleichen (D.12.1)

6.12.2     Endgültiges Deployment durchführen (D.12.2)

6.12.3     Abgeschlossene Iteration bewerten und folgende planen (D.12.3)

6.12.4     Kontrollpunkt 5: Bereitstellung zur Abnahme

7       Einführungsphase (E)

7.1    Einführung planen (E.1)

7.1.1     Einführung planen (E.1.1)

7.2    Abnahmetest durchführen (E.2)

7.2.1     Abnahmetestbereitschaft erklären (E.2.1)

7.2.2     Abnahmetest koordinieren (E.2.2)

7.2.3     Abnahmetest durchführen (E.2.3)

7.2.4     Abnahme erklären (E.2.4)

7.2.5     Liefergegenstand nachbessern (E.2.5)

7.2.6     Kontrollpunkt 6: Abnahme erteilt

7.3    Produkt einführen (E.3)

7.3.1     Produkt einführen (E.3.1)

7.3.2     Produktverantwortung abgeben (E.3.2)

7.3.3     Kontrollpunkt 7: Produktionsstart

8       Abschlussphase (A)

8.1    Projekt abschließen (A.1)

8.1.1     Projekt abschließen (A.1.1)

8.2    Risikoregister schließen (A.2)

8.2.1     Projekterkenntnisse festhalten (A.2.1)

8.2.2     Risikoregister schließen (A.2.2)

8.3    Teammitglieder ausplanen (A.3)

8.4    Verträge beenden (A.4)

8.4.1     Verträge beenden (A.4.1)

8.5    Projektkostenrechnung abschließen (A.5)

8.5.1     Feedback zu den Projektkosten erstellen (A.5.1)

8.6    Postmortem durchführen (A.6)

8.6.1     Postmortem durchführen (A.6.1)

8.6.2     Abschließenden Projektbericht verfassen (A.6.2)

8.6.3     Kontrollpunkt 8: Projekt beendet

9       Implementierung eines Vorgehensmodells

9.1    Vorgehensweise

9.2    Phase 1: Untersuchen

9.3    Phase 2: Definieren

9.4    Phase 3: Testen

9.5    Phase 4: Implementieren

9.6    Phase 5: Betreiben und Optimieren

9.7    Weitere Aufgaben und Abgrenzung zum PMO

Anhang

       A Überblick über die bekanntesten Projektmanagementzertifikate mit IT-Relevanz

A.1    IPMA

A.2    PRINCE2

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

C       Literaturverzeichnis

Stichwortverzeichnis

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.

Kein Softwareprojekt ist wie das andere.

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 Projekte erreichen die gesteckten Ziele nicht.

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).

PMBOK Guide des PMI

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.

Pragmatisches IT-Projektmanagement

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.

»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

Zielgruppe

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:

Teamgröße von vier bis max. zwölf Personen

Laufzeit etwa drei bis zwölf Monate

Aufwand etwa 50 bis 500 Personentage

Struktur des Buches

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.

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

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.

PMBOK Guide Ed. 5

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-Industriestandard aktualisiert und versioniert wird. Die Notation verzichtet auf komplexe Konstrukte.

BPMN im Internet

Mehr Informationen zu BPMN finden Sie im Internet, z.B. unter http://www.omg.org/bpmn 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

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 http://www.PITPM.net. Die dort abgelegten Dateien aktualisieren wir laufend, der Download ist für Sie kostenlos. Über Ihr Feedback freuen wir uns unter [email protected].

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.

Project Management Institute (PMI)

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 100.000 Mitglied auf, Ende 2008 waren es weltweit gut 280.000 Mitglieder, mit Stand Juli 2013 gibt das PMI in der Mitgliederzeitschrift PMI Today die Mitgliederzahl mit über 439.000 weltweit an – ein beachtenswertes Wachstum.

Ein Überblick über weitere relevante Zertifizierungen anderer Organisationen im Umfeld des Projektmanagements findet sich im Anhang.

Standardisierung des Projektmanagements durch das PMI

Das PMI hat mit der Standardisierung der systembezogenen Inhalte und dem Aufbau eines weltweit einheitlichen Projektmanagementzertifikats zur globalen Vereinheitlichung des Projektmanagements 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.

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.

PMBOK Guide unterliegt den Standards ANSI und IEEE.

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.

CAPM und PMP

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.

2.1 Project Management Professional (PMP®)

Das Zertifikat PMP gilt drei Jahre.

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 2011-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 520.000 Personen, in Deutschland davon immerhin knapp 10.000 (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 2.500 und 5.000 € 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.

Professional Development Units (PDUs) dokumentieren die Erhaltung des Zertifikats.

Ä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.

Continuing Certification Requirements (CCR) beschreiben die Rahmenbedingungen zum Erhalt des Status.

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.

PMI Communities of Practice

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 NonProfit-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.

Chapters sind weitestgehend autarke Lokalverbände des PMI.

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 »Vice Presidents« für jedes erdenkliche Tätigkeitsfeld wie Mitgliederdienste, Marketing, Technologie usw. Das Konstrukt funktioniert aber recht gut, wie die kontinuierlich steigenden Mitgliedszahlen belegen. Das liegt auch daran, dass die Mitglieder aus verschiedenen Domänen stammen und ihre Lebens- und Berufserfahrung einbringen. So sind der Austausch und der Umgang miteinander meist von einer entspannten Atmosphäre geprägt. Zudem ist der Charity-Gedanke und damit die Bereitschaft, sich in Vereinen zu organisieren, in den USA wesentlich ausgeprägter als im deutschsprachigen Raum. Darüber hinaus haben Organisationen wie das PMI in den Vereinigten Staaten wirtschaftlich eine weitaus größere Bedeutung als bei uns.

PMI Chapter München: wachstumsstärkstes Chapter im deutschen Sprachraum

Daher gilt: Wer Spaß daran hat, sollte sich beteiligen. Davon lebt die Organisation. So sind zum Beispiel in Deutschlands wachstumsstärkstem und mittlerweile größtem Chapter München, das mit seinen zusätzlichen Local Groups in Nürnberg, Regensburg/Passau und Karlsruhe/Stuttgart den süddeutschen Raum abdeckt, bereits über 1.100 Mitglieder organisiert, und die Zahl wächst stetig.

Code of Ethics and Professional Conduct

Dennoch ist es immer angebracht, die Entwicklung kritisch zu beobachten. Zwar hat ein PMP den »Code of Ethics and Professional Conduct « unterschrieben, der recht hohe Maßstäbe an das eigene Verhalten im Beruf ansetzt. Darin steht jedoch nicht, dass die Handlungen des PMI kritiklos hinzunehmen sind.

PMBOK Guide Edition 4 ist kein Quantensprung.

So war zum Beispiel die PMBOK Guide Edition 4 im Jahr 2008 kein Quantensprung in der Evolution der Projektmethodik. Die Änderungen waren minimal, der Zugewinn erst nach intensiver Recherche erkennbar. Vielen Lesern des PMBOK Guide fehlt zudem eine Einbettung der Prozesse in ein Phasenmodell. Der Guide unterteilt die Prozesse nur in Gruppen, deren Prozesse je nach Projektphase überlappend und mit unterschiedlicher Intensität durchgeführt werden.

PMBOK Guide ist »nur« eine Beschreibung »bewährter Praxis«.

Im Sinne der Beschreibung »bewährter Praxis« wäre eine Einteilung in feste Phasen auch gar nicht sinnvoll, für den direkten Einsatz im Projekt ist die im PMBOK Guide dargestellte Sicht aber bei Weitem nicht explizit genug. Aus unserer Erfahrung ist die Anwendung eines einfachen Phasenmodells wesentlich pragmatischer, da andernfalls die Zusammenhänge nicht deutlich und nachvollziehbar werden. So hieß es in der Edition 4 des PMBOK Guide noch: »Each process occurs at least once in every project and occurs in one or more of the project phases, if the project is divided into phases.« Jeder Prozess sollte also in wirklich jeder Phase ausgeführt werden. Haben Sie das mal versucht? Vermutlich nicht, denn es macht wenig Sinn. Das haben die Autoren des PMBOK Guide Edition 5 wohl auch festgestellt, denn nun heißt es: »A phase may emphasize processes from a particular Project Management Process Group, but it is likely that most or all processes will be executed in some form in each phase.« Gegenüber der letzten Version haben die Autoren die Notwendigkeit der Durchführung aller Prozesse in allen Phasen deutlich abgeschwächt. Was konsequenterweise fehlt ist die exakte Definition einer Phase und ihrer Start- und Endebedingungen. Auch hier zeigt sich, dass ein Vorgehen nicht unmittelbar dem PMBOK Guide entnommen werden kann, sondern adaptiert werden muss.

Trotz einiger Kritik überwiegen die Vorteile von Methodik, Organisation und Zertifikat:

Die gesamte

Methodik

ist trotz des umfangreichen PMBOK Guide immer noch recht praxisnah. Zumindest erschließt sich dem Aspiranten recht schnell die mögliche Anwendung in seinem persönlichen Arbeitsgebiet. Der modulare Aufbau erlaubt auch die Anwendung nur spezifischer Wissensgebiete oder Prozessgruppen.

Wer sich in der

Organisation

beteiligen möchte, wird immer einen geeigneten Posten finden. Wer seine Passion auf anderen Feldern sucht, braucht aber auch kein schlechtes Gewissen zu haben. Ein PMP muss nicht zwingend Mitglied im PMI sein.

Das

Zertifikat

ist weltweit anerkannt. Wer einen PMP im Titel führt, wird von relevanten Stellen meist als Fachmann eingestuft.

2.2 Andere Projektmanagementzertifikate

Seriöse Zertifikate müssen regelmäßig erneuert werden.

Ein Zertifikat, gleich wofür und für wen es ausgestellt wurde, dokumentiert die Erfüllung vorgegebener Anforderungen zum Zeitpunkt der Erlangung. Es kann damit jedoch immer nur eine Momentaufnahme sein, die je nach Domäne und Anwendungsbereich möglicherweise nur eine befristete Haltbarkeit hat. Seriöse Zertifikate wie der PMP oder die Zertifikate der IPMA (International Project Management Association) erfordern daher ihre regelmäßige Erneuerung, meistens in einem Abstand von drei bis fünf Jahren.

Zudem korreliert in der Regel die Wertigkeit eines Zertifikats mit dem Aufwand, es zu erlangen. Ein Beispiel: Die Zertifizierung zum IPMA Level A setzt jahrelange Erfahrung in großen Projekten voraus, dazu entsteht für den Prüfling ein Aufwand vergleichbar mit einer umfangreichen Diplomarbeit. Im Gegensatz dazu steht das Zertifikat der Scrum Alliance zum »Certified Scrum Product Owner« (CSPO, Stand Juni 2013): Jeder Teilnehmer eines zweitägigen Kurses wird anschließend ohne Prüfung zertifiziert. Um die Zertifizierung zum »Certified Scrum Master« (CSM) zu erlangen, muss man einen recht einfachen Onlinetest bestehen.

Dennoch gilt: Unabhängig vom Zertifikat muss sich sein Inhaber zwangsläufig mit dem Thema auseinandergesetzt haben. Die Tiefe kann variieren, aber wenn Sie die Wahl zwischen zwei erfahrenen Projektmanagern hätten, und nur einer hat ein aussagekräftiges Zertifikat – wen würden Sie zuerst wählen? Bis zum Vorstellungsgespräch hätte der Zertifikatsinhaber zumindest einen Qualifizierungsvorteil.

Zertifikate sorgen zudem global für ein einheitliches Verständnis. Wenn zwei PMPs von der »Project Charter« sprechen, dann meinen sie das gleiche Artefakt. Haben Sie einen PMP in Ihrem Team, dann können Sie erwarten, dass er die PMBOK-Guide-Prozesse und -Wissensgebiete beherrscht, die adäquaten Werkzeuge kennt und einem gewissen Verhaltenskodex folgt. Um sicherzugehen, dass ein Aspirant sein Handwerk wirklich versteht, sollte er vorab zu einigen projektbezogenen Situationen Stellung beziehen. Die Antworten lassen darauf schließen, welches Selbstverständnis und welchen Erfahrungsschatz das potenzielle Teammitglied mitbringt. In der Praxis treffen wir immer wieder auf Projektmanager, die zwar hochdekoriert sind und Zertifikate aller Projektmanagementströmungen vorweisen können, ihre Aufgaben jedoch ohne Empathie erledigen und dadurch weder das Team noch den Kunden hinter sich bringen.

Zertifikate sind auch eine dauerhafte Einnahmequelle für den Herausgeber.

Der nachfolgende Aspekt spielt aber fast immer eine Rolle: Bei entsprechender Akzeptanz garantieren Zertifikate dem herausgebenden Unternehmen mit wenigen Ausnahmen eine dauerhafte Einnahmequelle. Daher gilt: Zertifikate ersetzen zwar niemals die persönliche Bewertung, sie spiegeln aber den Erfahrungsschatz und die grundlegende Auffassung eines Kandidaten wider.

Ein Überblick über weitere relevante Zertifikate zum Projekt- oder Vorgehensmanagement wird in Anhang A vermittelt.

2.3 PMBOK® Guide in »klassischen« IT-Projekten

IT- und im besonderen Softwareentwicklungsprojekte sind meist bestimmt durch Technologieeinsatz, hohe Komplexität und hohen Kommunikationsaufwand.

Individualsoftwareentwicklung ist der »Erlkönig unter den Projekten«.

Die Entwicklung von Individualsoftware ähnelt eher der Konstruktion eines »Erlkönigs« (Prototyp der Serienfertigung in der Automobilindustrie) als dem so häufig bemühten Bau eines Einfamilienhauses oder einer Brücke:

Softwareprojekte sind überwiegend personal- und damit kostenintensiv. Das eingesetzte Material (Hardware, Software) nimmt dabei aus Kostensicht meist eine untergeordnete Rolle ein.

Softwareprojekte unterliegen kontinuierlichen Änderungen während des Entwicklungsprozesses. Anders als bei Projekten mit einem materiellen Produkt sind die Konsequenzen einer Softwareänderung für Außenstehende oft nicht nachvollziehbar.

Individualsoftware löst immer ein spezifisches Problem. Hierbei mag es zwar Analogien oder verwandte Lösungsmuster geben, aber es gibt kein Fertigprodukt aus dem Verkaufsregal. Je größer die Anteile der individuellen Entwicklung sind, desto höher fällt daher meist das Projektrisiko aus, was sich letztlich in den Projektkosten niederschlägt.

Durch die Integration vieler Disziplinen, vorrangig der fachlichen Expertise (also die Domänenexperten des Bereichs, in dem das Produkt eingesetzt werden soll) mit der Softwareentwicklung, stoßen häufig sehr verschiedene Persönlichkeiten mit unterschiedlichen Erfahrungshorizonten aufeinander, die letztlich anhand ihrer Produktivität bewertet werden. Das verlangt von beiden Seiten Verständnis und Interesse für die Belange der anderen und für das gesamte Vorgehen.

PMBOK Guide Extensions

Das PMI bietet seit 2006 Spezialisierungen des PMBOK Guide für bestimmte Branchen an, die sogenannten »Extensions«. 2006 kam die Extension »Government« (Öffentliche Verwaltung, vgl. [PMI 2006]) auf den Markt, 2007 folgte »Construction« (Baugewerbe, vgl. [PMI 2007]). Diese Spezialisierungen, die bisher zudem nur zur veralteten PMBOK Guide Edition 3 geschrieben wurden, sind außerhalb der USA weitestgehend unbedeutend.

Das soll sich mit der für den Winter 2013/2014 avisierten Software Extension zum PMBOK Guide 5 [PMI 2013] ändern. Zur Drucklegung war das Werk noch nicht verfügbar. Wir Autoren hatten jedoch die Möglichkeit, im Rahmen des Review-Prozesses einen Blick auf die Vorabversion zu werfen. Was wir gesehen haben, war vielversprechend: Zwar wird auch diese Extension vorrangig auf den US-amerikanischen Markt ausgerichtet sein, jedoch sind die Standards und Vorgehensweisen in der Softwareentwicklung deutlich universeller als die des Baugewerbes oder gar die der Verwaltung. Wie der PMBOK Guide selbst wird sich die Extension nicht 1:1 einsetzen lassen, sie macht den Guide aber wesentlich konkreter. Wir verstehen die neue Extension als Mittelstufe zwischen dem unspezifischen PMBOK Guide und unserem in diesem Buch vorgestellten, sehr konkreten Vorgehen.

Teile der PMBOK-Guide-Prozesse im RUP

Darüber hinaus finden sich Teile des PMBOK Guide in verwandten Konzepten wieder. Als eines der Unternehmen mit den meisten PMP-zertifizierten Mitarbeitern weltweit vertreibt IBM mit dem Rational Unified Process (RUP) eine in die Jahre gekommene, aber sehr