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.
Softwareentwicklungsprojekte auf Basis des PMBOK® Guide führen
2., überarbeitete und aktualisierte Auflage
Niklas Spitczok von Brisinski · niklas@pitpm.net
Guy Vollmer · guy@pitpm.net
Ute Weber-Schäfer · ute@pitpm.net
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 · heidi.heilmann@augustinum.net
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
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 Gruhn
Essen, im Dezember 2013
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
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:
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
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.
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
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.
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:
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.
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.
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.
Die grafischen Elemente der BPMN werden eingeteilt in (s. dazu auch Abb. 1–1):
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.
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.
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
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.