|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.de/plus |
Aus- und Weiterbildung zum
ASQF® Certified Professional for Project Management (CPPM)
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer
Illustrationen: Daniela Stokar von Neuforn, TTM Training&TransferManagement, Berlin
Satz: Birgit Bäuerlein
Herstellung: Susanne Bröckelmann
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
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:
Print978-3-86490-429-5
PDF978-3-96088-172-8
ePub978-3-96088-173-5
mobi978-3-96088-174-2
1. Auflage 2017
Copyright © 2017 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.
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
Projekte erfolgreich termin-, kosten- und qualitätsgerecht zu managen, wird immer mehr zu einer Herausforderung. Die Anforderungen an Projektmanager sind hoch: Die Produktionszyklen werden kürzer und die Wettbewerbsbedingungen verschärfen sich. Sie kontrollieren das Budget, haben den aktuellen Projektstatus im Blick, führen und koordinieren das Team. Sie leisten einen entscheidenden Beitrag zur Sicherung des Projektes. Aber wie können sich Arbeitgeber sicher sein, den geeigneten und qualifizierten Mitarbeiter für diese Aufgabe auszuwählen?
Qualifizierte Projektmanager sind im Allgemeinen und im Besonderen im Softwareprojektmanagement sehr gefragt. Wer über umfassende Projektmanagement-Skills verfügt, ist klar im Vorteil. Wer diese mit einem Zertifikat nachweisen kann, ist es noch mehr. Für eine Vergleichbarkeit wird seitens der Wirtschaft immer wieder ein Standard gefordert. Die Bedeutung von Leistungsnachweisen in Form von Prüfungen und Zertifikaten unabhängiger Instanzen ist in den letzten Jahren stark angestiegen und wird dies auch weiterhin tun.
Es gibt eine hohe Anzahl an Schulungsangeboten, die allerdings unterschiedliche Niveaus haben. Für den Arbeitgeber ist es schwierig einzuschätzen, was er von einem bestimmten Zertifikat erwarten kann oder eben auch nicht. Es ist also insbesondere für angehende Projektmanager sehr wichtig, dass ein Standard zur Verfügung steht, der ein einheitliches Konzept mit allen wichtigen Inhalten kontinuierlich verfolgt. Es ist auch für die Personalplanung leichter, wenn der Arbeitgeber auf Mitarbeiter mit einem etablierten Projektmanagementzertifikat zurückgreifen kann.
Das International Software Quality Institute (iSQI) ist weltweit die Anlaufstelle für solche Softwarequalitätsstandards. Das Zertifizierungsprogramm des iSQI umfasst u. a. das ASQF® Certified Professional for Project Management. Diese Zertifizierungsprüfung erschien 2016 in einer modernisierten und zukunftssicheren Neuauflage des etablierten Schemas. Mit der kontinuierlichen Pflege der Inhalte soll sichergestellt werden, dass die Ausbildung den Anforderungen an die Mitarbeiter und den Bedürfnissen der Industrie entspricht. Und das auch in der Zukunft. Der neue Lehrplan zum ASQF® Certified Professional for Project Management setzt auf Standards und aktuelle internationale Normen. iSQI prüft und zertifiziert unabhängig nach diesen Standards. Ebenso sorgt das iSQI gemeinsam mit internationalen Partnern für die Etablierung der Standards in zahlreichen Ländern auf allen Kontinenten. Im Ergebnis entstehen Zertifizierungen, die international anerkannte Aushängeschilder sind.
Die vorliegende Auflage dieses Buches verweist auf die immer weiterwachsende Bedeutung und die kontinuierliche Etablierung von Standards und Zertifizierungen im Bereich Projektmanagement. Die Autoren haben auf der Grundlage ihrer vorherigen Arbeit die Standards für Projektmanagement weiterentwickelt und die Grundlagen erneut für uns aufgearbeitet und festgehalten. Ich möchte mich bei ihnen für ihr Engagement und dafür, dass sie ihre Expertise mit uns teilen, bedanken.
Abschließend wünsche ich allen (zukünftigen) Projektmanagern und Interessierten viel Freude beim Durcharbeiten des Buches, viel Erfolg für die spätere Zertifizierungsprüfung und gutes Gelingen aller folgenden Projekte!
Stephan Goericke
International Software Quality Institute
Director
Als wir uns 2015 zusammenfanden, um den Lehrplan zum ASQF®Certified Professional for Project Management [ASQF CPPM 2016] grundlegend zu überarbeiten, wurde uns rasch klar, dass ein neuer Kurs auch ein neues Lehrbuch verlangt. Gesagt, getan – und so kam Lenchen auf das Land1 bzw. dieses Buch in Ihre Hand.
Doch braucht die Welt wirklich ein weiteres Buch über Projektmanagement? Wir fanden schon. Zwar gibt es bereits viele Werke zu diesem Thema, doch wir wollten neue Schwerpunkte setzen. Ein Buch, das sowohl sequenzielle als auch agile Ansätze praxisorientiert vereint und darüber hinaus soziale Kompetenzen angemessen behandelt, sucht man auf dem Markt bislang vergebens. Wir wollten ein kurzweiliges Buch für all diejenigen schreiben, die mehr oder weniger explizit mit Softwareprojektmanagementaufgaben betraut sind.
»Softwareprojektmanagementaufgaben« – was für ein Wort! 31 Buchstaben, deren Wirkung einer Schlaftablette gleichkommt. Genau dies wollten wir jedoch nicht. Wir finden Softwareprojektmanagement Tag für Tag aufs Neue faszinierend und hoffen, diese Passion auch an unsere Leser weitergeben zu können.
Dieses Buch verdankt somit seine Entstehung zwei Organisationen: dem ASQF® bezüglich der Inhalte und dem dpunkt.verlag hinsichtlich der Form. Wir möchten uns an dieser Stelle daher ganz herzlich bedanken. Besonderes erwähnen möchten wir Norbert Kastner und Rainer Alt und ihre wertvolle Mithilfe bei der Fertigstellung des Buches. Dank auch an Ronald Huster und Dr. Armin Metzger für die logistische und moralische Unterstützung, an Jerome Horn für die redaktionelle Unterstützung sowie an Stephan Goericke für sein Geleitwort. Vom dpunkt.verlag stand uns Frau Preisendanz stets mit Rat und Tat zur Seite.
Viele der Grafiken in diesem Buch entsprangen der künstlerischen Hand von Dr. Daniela Stokar von Neuforn. Auch ihr möchten wir noch einmal ganz besonders unseren Dank aussprechen.
Wer einmal an der Erstellung eines Buches mitgewirkt hat, weiß nur zu gut, welche Geduldsprobe gerade die »letzten Züge« für die engsten Vertrauten bedeutet. Ohne die Unterstützung unserer Partnerinnen und Partner, ohne das Verständnis und die Rücksichtnahme unserer Kinder, gäbe es dieses Buch nicht in der vorliegenden Form. Daher gilt unser ganz besonderer Dank unseren Familien.
Liebe Leserinnen!
Wir haben uns entschieden, zumindest eine der guten alten Deutschregeln zu befolgen (ansonsten folgt dieses Buch der neuen deutschen Rechtschreibung). Wir sprechen ab sofort nicht mehr von »Projektmanagerinnen und Projektmanagern«, auch nicht von »Projektmanager-Innen« oder gar von »Projektmanagenden«, sondern schlicht von »Projektmanagern«. Selbstverständlich schließt die männliche Form systematisch die weibliche mit ein. Sie werden im Verlauf des Buches ohnehin feststellen, dass Sie hinsichtlich der erforderlichen Soft Skills und speziell der Kommunikation möglicherweise im Vorteil sind … (gez.: die Autorinnen)
Andreas Johannsen, Anne Kramer,
Horst Kostal und Ewa Sadowicz
Erlangen und Berlin, Februar 2017
Einleitung
1Überblick und Einführung
2Projektorganisation
3Prozess- und Vorgehensmodelle in der Softwareentwicklung
4Projektinitiierung
5Projektplanung
6Projektumsetzung und -controlling
7Projektabnahme und -abschluss
8Qualitätsmanagement
9Risikomanagement
10Personalmanagement
11Reifegradmodelle
12Zusammenfassung
Anhang
ALösungshinweise
BGlossar
CReferenzen
Index
Einleitung
Motivation
Modernes Softwareprojektmanagement
Der ASQF® CPPM
Ein paar Worte zum Buch
Das Fallbeispiel
1Überblick und Einführung
1.1Woran scheitern Projekte? – Projekterfolgs- und -misserfolgskriterien
1.2Wichtige Begriffe im Projektmanagement
1.3Softwareprojektmanagement im Überblick
1.3.1Prozess- und Themengruppen nach ISO 21500
1.3.2Aufgaben des Projektmanagements
1.3.3Kompetenzanforderungen an Projektmanager
1.4Zusammenfassung
1.5Übungsaufgaben
2Projektorganisation
2.1Ziele und Aufgaben der Projektorganisation
2.2Aufbauorganisation
2.2.1Bedeutung und Ziele der Aufbauorganisation
2.2.2Mögliche Formen der Aufbauorganisation
2.2.3Was bei der Auswahl eine Rolle spielt
2.3Ablauforganisation
2.3.1Bedeutung und Ziele der Ablauforganisation
2.3.2Projektrollen
2.3.3Projektgremien
2.4Zusammenfassung
2.5Übungsaufgaben
3Prozess- und Vorgehensmodelle in der Softwareentwicklung
3.1Überblick zu Prozess- und Vorgehensmodellen
3.1.1Sequenzielle Vorgehensmodelle
3.1.2Agile Vorgehensmodelle
3.1.3Sequenziell oder agil? – Die Qual der Wahl
3.2Unternehmensspezifische Softwareentwicklungsprozesse
3.3Agiles Vorgehensmodell am Beispiel »Scrum«
3.3.1Prinzipien – was agil ausmacht
3.3.2Konzepte – die agile Strategie
3.3.3Rollen – wer ist für was verantwortlich?
3.3.4(Sprint-)Phasen – der Sprint-Flow
3.3.5Scrum-Meetings
3.3.6Scrum-Artefakte
3.3.7Scrum und agiles Personalmanagement
3.3.8Scrum: Zwischenbilanz eines Erfolgsmodells
3.4Die Praxis hybrider Vorgehensmodelle
3.5Zusammenfassung
3.6Übungsaufgaben
4Projektinitiierung
4.1Was passiert jetzt? – Aktivitäten der Projektinitiierung
4.1.1Chancen und Risiken ermitteln und abwägen
4.1.2Informationen für die Projektdurchführung beschaffen
4.1.3Vertragliches klären
4.1.4Vorgehensmodell festlegen
4.1.5Ressourcen beschaffen
4.2Projektdefinition und Projektauftrag
4.3Vertragsgestaltung – nicht nur lästiges Beiwerk!
4.4Anforderungsanalyse – ohne geht es nicht!
4.5Die weichen Faktoren – erforderliche Soft Skills
4.5.1Verhandlungsgeschick
4.5.2Selbstbewusstsein und Entscheidungsfreudigkeit
4.5.3Kommunikationsfähigkeit
4.5.4Moderation und Visualisierungstechniken
4.6Zusammenfassung
4.7Übungsaufgaben
5Projektplanung
5.1Zur Bedeutung der Planung
5.2Die Festlegung des Projektumfangs
5.3Die Meilensteinplanung – wozu?
5.3.1Meilensteinpläne in der sequenziellen Welt
5.3.2Meilensteinpläne im agilen Umfeld
5.4Big Picture – welche Struktur hat das Projekt?
5.5Der Weg zu realistischen Aufwänden
5.5.1Wie schätzen wir?
5.5.2Größenschätzungen
5.5.3Expertenschätzungen
5.5.4Zeit sparen mit Analogiemethoden
5.5.5Fortgeschrittene Methoden
5.5.6Umgang mit Risiken beim Schätzen
5.6Wo entstehen die Kosten in einem Softwareprojekt?
5.7Aktivitätenzeitplan oder Storyboard – die Grundlage für das Controlling schaffen
5.7.1Einfluss der Aktivitätenzeitplanung auf das Projektcontrolling
5.7.2Die Anordnung der Aktivitäten über die Zeit
5.7.3Der kritische Pfad
5.7.4Die Personaleinsatzplanung
5.8Der transparente Verlauf der Kosten
5.9Der Projektplan entsteht
5.10Zusammenfassung
5.11Übungsaufgaben
6Projektumsetzung und -controlling
6.1Der Sinn des Projektcontrollings
6.2Umsetzung in verschiedenen Umfeldern
6.3Die Kunst der Erfassung des Projektfortschritts
6.3.1Generelle Regeln
6.3.2Die projektinterne Erfassung
6.3.3Der Blick von außen auf das Projekt
6.4Fortschrittsberichtswesen und Informationsaustausch
6.4.1Effiziente Statusberichte
6.4.2Sinnvolle Besprechungen
6.5Trendsysteme
6.5.1Die Meilenstein-Trendanalyse
6.5.2Die Earned-Value-Analyse
6.6Änderungsmanagement
6.6.1Sequenzielle Vorgehensmodelle
6.6.2Agile Vorgehensmodelle haben weniger Probleme
6.7Zusammenfassung
6.8Übungsaufgaben
7Projektabnahme und -abschluss
7.1Projektabnahme
7.1.1Fachliche Abnahme
7.1.2Vertragsrechtliche Abnahme
7.2Projektabschluss
7.3Erforderliche Soft Skills und Methoden
7.4Zusammenfassung
7.5Übungsaufgaben
8Qualitätsmanagement
8.1Qualität geht alle an – Qualitätsmanagement als Querschnittsaufgabe
8.2Der Qualitätsmanagementplan
8.3Qualitätssicherung für Prozesse – wie sauber arbeiten wir?
8.4Qualitätssicherung für Produkte – wie gut sind die Ergebnisse?
8.5Wenn etwas schiefgeht – Umgang mit Abweichungen
8.6Arbeitsteilung in der Praxis
8.7Zusammenfassung
8.8Übungsaufgaben
9Risikomanagement
9.1Grundgedanke des Risikomanagementprozesses
9.2Aktivitäten des Risikomanagements
9.2.1Risikoermittlung – bloß nichts übersehen!
9.2.2Risikobewertung – wie schlimm kann es werden?
9.2.3Risikobeherrschung – was können wir tun?
9.2.4Risikocontrolling – immer wachsam bleiben!
9.3Erforderliche Soft Skills
9.4Risikomanagement in sicherheitskritischen Bereichen
9.5Zusammenfassung
9.6Übungsaufgaben
10Personalmanagement
10.1Personalmanagement im Unternehmen
10.1.1Ziele und Devisen
10.1.2Aufgaben des Personalmanagements im Unternehmen
10.1.3Funktion des Personalmanagements im Unternehmen
10.2Personalmanagement im Projekt
10.2.1Bedeutung des Personalmanagements im Projekt
10.2.2Querschnittsaufgabe im Projektverlauf
10.2.3Personalmanagement und Projektphasen
10.2.4Projektmanager und Personalabteilung – erfolgreiche Zusammenarbeit bei der Personalauswahl
10.2.5Teambegleitung
10.3Personalmanagement richtig gemacht – worauf es besonders ankommt
10.3.1Erfolgsfaktor »soziale Kompetenz«
10.3.2Erfolgsfaktor »Kommunikation«
10.3.3Erfolgsfaktor »Motivation«
10.3.4Erfolgsfaktor »Führung«
10.4Arbeiten im Team
10.4.1Klassische vs. agile Teams
10.4.2Teamführung erfordert Methodenkompetenz
10.4.3Teamuhr nach Tuckman
10.4.4Teamrollen nach M. Belbin
10.4.5Rollen des Projektmanagers
10.5Zusammenfassung
10.6Übungsaufgaben
11Reifegradmodelle
11.1Das Grundprinzip von Reifegradmodellen
11.2Geschichtliche Entwicklung
11.3Ein paar Details zu CMMI
11.4Weitere Details zu ISO/IEC 15504 (SPICE)
11.5Reifegradmodelle und agil – ein Widerspruch?
11.6Zusammenfassung
11.7Übungsaufgaben
12Zusammenfassung
12.1Das Wichtigste nochmal in Kürze
12.2Ausblick
Anhang
ALösungshinweise
BGlossar
CReferenzen
Index
Es ist schon frustrierend: 1972 schrieb Edsger W. Dijkstra zum ersten Mal über die »Softwarekrise«. 1996 erschien der erste Chaos Report der Standish Group und zeigte uns, wie wenige Softwareprojekte als erfolgreich gelten können. Heute, 30 Jahre später, gibt es unzählige Bücher über Softwareentwicklung, und dennoch laufen Softwareprojekte immer wieder aus dem Ruder. Die Software wird entweder deutlich teurer als geplant, nicht rechtzeitig fertig oder enthält bei Auslieferung noch inakzeptable Fehler (sprich: Bugs).
Warum ist das so? Haben wir denn seit 1972 nichts gelernt? Doch, haben wir. Inzwischen hat sich in der Industrie auch für die Softwareentwicklung der Prozessgedanke durchgesetzt. Dieser Gedanke stammt ursprünglich aus der Fertigung. Die Grundidee besteht darin, alle Arbeitsschritte klar zu definieren, sodass sie kontrolliert und reproduzierbar ablaufen. Auf diese Weise kann nachweislich eine einheitliche, idealerweise hohe Qualität produziert werden.
Anders als bei Hardware gibt es jedoch für Software keine Trennung zwischen Entwicklung und Produktion. Daher sind Prozesse in der Entwicklung gefragt. Software Engineering ist inzwischen ein Studienfach an Universitäten und Fachhochschulen.
Trotzdem kommt es immer wieder zu spektakulären Fehlschlägen bei Softwareprojekten. Ende März 2016 verlor die japanische Raumfahrtagentur JAXA1 durch eine eindrucksvolle Verkettung von Hardware- und Softwarefehlern das 286 Millionen US-Dollar teure Röntgenteleskop Hitomi (japanisch: Auge, Pupille). Bei einer Neuausrichtung des Weltraumteleskops kam es zu einer falschen Bestimmung der Lagedaten und damit zur irrtümlichen Meldung, der Satellit rotiere. Um die nicht vorhandene Rotation zu stoppen, wurde das Reaktionsrad aktiviert. Das Teleskop geriet nun tatsächlich ins Trudeln, was wiederum das Kontrollsystem des Teleskops aktivierte. Unglücklicherweise war die betreffende Funktion vor dem Hochladen nicht ordentlich getestet worden. Statt Hitomi zu stabilisieren, wurden die Schubdüsen in die falsche Richtung aktiviert und somit die Rotation verstärkt, bis die Solarpaneele abbrachen. Damit fand die auf 10 Jahre ausgelegte Mission nach 3 Tagen ein abruptes Ende.
Dieses Beispiel ist natürlich besonders spektakulär, zeigt jedoch eine der typischen Schwierigkeiten, mit der eigentlich alle Softwareprojekte konfrontiert sind: Software ist in der Regel extrem komplex und das Zusammenspiel verschiedener Funktionen ist schwer zu überblicken. Dabei ist es an und für sich leicht, oft sogar viel zu leicht, Funktionen zu programmieren. Das verleitet dazu, »mal eben was zu ändern«. In der Regel sind es jedoch gerade diese Änderungen, die zu unerwarteten Wechselwirkungen mit bereits programmierten Funktionen führen.
Die Erkenntnis, dass Änderungen in unserer schnelllebigen Zeit eher die Regel als die Ausnahme sind, hat in der Softwareentwicklung zu einem Umdenken geführt. Seit 2000 haben sich zunehmend die sogenannten »agilen« Vorgehensmodelle durchgesetzt, bei denen die Software iterativ in möglichst kurzen Zyklen entwickelt wird. Die Kenntnis dieser Vorgehensmodelle und deren Einfluss auf das Projektmanagement gehört heute zum Werkzeugkasten eines modernen Softwareprojektmanagers.
Womit wir beim Thema wären. Dieses Buch richtet sich an alle Mitarbeiter in Softwareprojekten, die direkt oder indirekt mit Projektmanagementaufgaben betraut sind. Dies können »hauptamtliche« Projektmanager mit Weisungsbefugnis sein, ebenso wie Softwareentwickler, die für die Zeit des Projektes ihren Kollegen als Primus inter Pares vorstehen. In agilen Vorgehensmodellen verschwimmen die Grenzen zum klassischen Projektmanager noch weiter, da das Projektteam teilweise Projektmanagementaufgaben übernimmt. Wenn in diesem Buch die Rede vom »Projektmanager« ist, meinen wir daher immer die Rolle und nicht zwangsläufig eine bestimmte Person.
Dieses Buch vermittelt Grundlagen, die jeder Projektmanager kennen und verstehen sollte, um erfolgreich zu sein. Der Inhalt des Buches entspricht dem Lehrplan des »ASQF® Certified Professional for Project Management« (kurz: CPPM). Dieser Lehrplan wurde 2016 vollständig überarbeitet, wobei zwei Aspekte im Vordergrund standen:
Da dieses Buch als Lehrbuch zum Kurs gedacht ist, beschreiben die zwei Punkte der Liste auch die Unterschiede zum Vorgängerbuch »Basiswissen Softwareprojektmanagement. Es werden systematisch sowohl die »klassisch« sequenzielle als auch die agile Vorgehensweise dargelegt. Wir gehen in jedem Kapitel darauf ein, wie die jeweils beschriebenen Tätigkeiten im einen wie im anderen Umfeld umgesetzt werden. Darüber hinaus richtet sich die Terminologie des Lehrplans (und damit auch dieses Buches) nach dem erstmalig 2012 erschienenen »Leitfaden zum Projektmanagement«, dem internationalen Standard ISO 21500.
Der verstärkte Fokus auf das Thema »Soft Skills« hängt eng mit der Zielgruppe des Kurses zusammen. Softwareprojektmanager sind oft eher technisch vorgebildet. Die fachliche Kenntnis ist jedoch nur die eine Seite der Medaille. Viel wichtiger und im Zweifelsfall auch entscheidender für den Projekterfolg ist jedoch die menschliche Komponente. Gerade Softwareentwickler mit lateraler Führungsverantwortung müssen sich mit dem Gedanken vertraut machen, dass ihre profunden Kenntnisse (z. B. der Programmiersprache) weniger ausschlaggebend für den Erfolg sind als ihre Soft Skills. Sie, die dafür ausgebildet wurden, Softwarearchitekturen und -algorithmen zu entwerfen, sollen plötzlich als Moderator, Verhandlungsführer, Schlichter und Motivator auftreten. Daher gehen wir in jedem Kapitel auch auf die jeweils erforderlichen »weichen Kompetenzen« ein, die für die jeweilige Rolle erforderlich sind.
Die erste Version des Kurses »Certified Professional for Project Management« (CPPM) wird seit 2004 vom International Software Quality Institute (kurz: iSQI) angeboten. Zuvor hatte sich eine Arbeitsgruppe des Arbeitskreises Software-Qualität und Fortbildung e. V. (ASQF®) gebildet, um einen schlanken, speziell auf Softwareprojektmanagement ausgerichteten Lehrplan zu verfassen. Auch die aktuelle Überarbeitung ist auf eine ASQF-Arbeitsgruppe zurückzuführen, an der die Autoren dieses Buches beteiligt waren. Der aktuelle Lehrplan ist hier zu finden: https://www.isqi.org/de/project-management.html.
Im Gegensatz zu den bekannten Projektmanagementschulungen der International Project Management Association (IPMA)2 und des amerikanischen Project Management Institute (PMI) fokussiert der ASQF® CPPM ausschließlich auf das für Softwareprojekte erforderliche Grundwissen. Weiterführende Themen wie Multiprojektmanagement werden explizit ausgespart, um den Kurs nicht zu überfrachten. Auch dieses Buch folgt der gleichen Logik, liefert jedoch den einen oder anderen Hinweis über den Tellerrand hinaus.
Wenn von Projektmanagementkursen die Rede ist, sollte auch ein Hinweis auf PRINCE2 nicht fehlen. PRINCE steht für »Projects in Controlled Environments«. Dahinter verbirgt sich eine Projektmanagementmethode, die sich bis heute großer Beliebtheit erfreut. Inzwischen gibt es auch »PRINCE2 Agile«, ein Ergänzungsmodul, das das eher auf sequenziellen Vorgehensmodellen aufsetzende PRINCE2-Handbuch um die wichtigsten agilen Prinzipien erweitert.
Der ASQF® CPPM steht nicht im Widerspruch zu den hier genannten Kursen, hat allerdings auch nicht den gleichen Anspruch auf Vollständigkeit. Noch einmal: Es geht hier ausschließlich um Softwareprojekte unter meist lateraler Leitung.
Dieses Buch gliedert sich in 12 Kapitel und folgt damit nahezu 1 zu 1 der Gliederung des ASQF®-CPPM-Lehrplans.
Kapitel 1 bietet einen Überblick über das Thema Softwareprojektmanagement und enthält Definitionen der wichtigen Begriffe. Das Kapitel orientiert sich eng am Standard ISO 21500 mit dem Ziel, eine einheitliche Terminologie zu schaffen, die auch im Buch durchgängig verwendet wird.
Kapitel 2 behandelt mögliche Projektorganisationsformen, wobei zwischen Aufbau- und Ablauforganisation unterschieden wird.
In Kapitel 3 werden verschiedene Prozess- und Vorgehensmodelle beschrieben. Wir unterscheiden prinzipiell zwischen sequenziellen und agilen Vorgehensmodellen mit ihren exemplarischen Vertretern »V-Modell« und »Scrum«.
Kapitel 4 bis 7 beschreiben den Ablauf eines Projektes, beginnend mit der Projektinitiierung (Kap. 4) über die Projektplanung (Kap. 5), Projektumsetzung und -controlling (Kap. 6) bis hin zu Projektabnahme und -abschluss (Kap. 7).
Abb. 0–1 Zusammenspiel der Kapitel 4 bis 7
Abbildung 0–1 zeigt das Zusammenspiel dieser vier Kapitel. Planung bzw. Umsetzung und Controlling werden während eines Projektes meist mehrfach durchlaufen, während die Initiierung naturgemäß nur einmal zu Beginn und Abnahme und Abschluss einmal am Ende des Projektes stattfinden.
Kapitel 8 widmet sich dem Qualitätsmanagement. Dabei konzentrieren wir uns auf die Bedeutung der Qualitätssicherung in Projekten. Schließlich ist dies kein Lehrbuch für Softwaretester. Etwas ausführlicher wird die Frage der Qualitätssicherung für Prozesse behandelt, da diese den Projektmanager zumindest indirekt betreffen.
Kapitel 9 handelt vom Risikomanagement. Auch hier geht es zunächst einmal um den Grundgedanken des Risikomanagementprozesses, bevor die einzelnen Aktivitäten der Risikoermittlung, -bewertung, -beherrschung und des Risikocontrollings beschrieben werden. Ein kleiner Exkurs behandelt das Risikomanagement in sicherheitskritischen Bereichen.
Kapitel 10 ist ein besonders wichtiges Kapitel dieses Buches, denn hier geht es um Personalmanagement. Neben Phasen und Aktivitäten des Personalmanagements werden Themen wie Teamentwicklung, soziale Kompetenz und Mitarbeitermotivation adressiert. Der Leser bekommt einen Einblick in die Bedeutung der menschlichen Aspekte im Projektmanagement, die nur allzu gerne unterschätzt wird.
Kapitel 11 liefert einen Überblick über Reifegradmodelle und wie diese verwendet werden können, um Prozesse einerseits zu bewerten und andererseits zu verbessern.
Kapitel 12 ist das einzige Kapitel, das kein direktes Äquivalent im CPPM-Lehrplan hat. Es enthält eine kurze Zusammenfassung des Buches.
Das Thema »Soft Skills« zieht sich wie ein roter Faden durch das ganze Buch. Wann immer angebracht, gehen wir darauf ein, welche nicht technischen Kompetenzen ein Projektmanager benötigt, um die jeweils beschriebenen Aufgaben erfolgreich zu meistern.
Wie Johann Wolfgang von Goethe so schön sagte: »Grau, teurer Freund, ist alle Theorie (…)« Das soll nicht sein! Deshalb haben wir in diesem Buch ein durchgängiges Fallbeispiel verwendet, das realistischer nicht sein könnte, da es auf tatsächlichen Erfahrungen der Autoren basiert.
Bei unserem Fallbeispiel handelt es sich um ein Inhouse-Projekt zur Entwicklung einer Plattform. Es gab also keinen externen Kunden. Die zu entwickelnde Grafikplattform war dazu bestimmt, von Applikations- und Kundenprojekten verwendet zu werden. Konkret sprechen wir von Grafikfunktionen, die beispielsweise dazu dienen, Instrumententafeln für Maschinen oder Fahrzeuge zu realisieren.
Insgesamt gab es zwei Projektteams. Sieben Mitarbeiter entwickelten die Grafik-Engine, fünf weitere die Grafikbibliothek. Ihnen vorgesetzt war ein Projektmanager, der gleichzeitig auch organisatorisch der Teamleiter war. Dieser Projektmanager bündelte alle Informationen und war als einziger Stakeholder den Teams bekannt.
Wie es in der Realität so ist, sah sich das Projekt mit einer Reihe von Herausforderungen konfrontiert, die durch gezieltes Projektmanagement hätten vermieden werden können. Beispielsweise wurde das Projekt bis zu einem gewissen Punkt ohne dokumentierte Anforderungen betrieben. Der Projektmanager hatte alle Informationen im Kopf und steuerte die Mitarbeiter einzeln aus. Generell ließ die Kommunikation im Projekt zu wünschen übrig. Es gab keine erkennbare Abstimmung mit abhängigen Projekten. Die Teammitglieder wussten wenig bis nichts von der Arbeit ihrer Kollegen, wodurch das Projekt für sie extrem unattraktiv wurde. Erschwerend kam hinzu, dass es so gut wie keine Projektmanagementaktivitäten hinsichtlich Planung, Controlling, Qualitätssicherung und Risikomanagement gab.
Wer schon in Softwareprojekten gearbeitet hat, wird sich das Setup vorstellen können. Wir nutzen dieses durchgängige Fallbeispiel im Buch, um zu zeigen, welche Projektmanagementaktivität an welcher Stelle hätte helfen können.
Stopp!
Haben Sie die Einleitung gelesen? Falls nicht, holen Sie das bitte jetzt nach, denn sie ist wichtig für das weitere Verständnis des Buches und enthält Inhalte, die für die Zertifizierung erforderlich sein können.
Wie bereits in der Einleitung dargestellt, laufen Softwareentwicklungsprojekte selten wirklich glatt ab. Häufig können Termine nicht gehalten werden, laufen Kosten aus dem Ruder oder die angeblich »fertige« Software ist doch noch nicht so weit wie gedacht. Bei Auslieferung stellt sich dann heraus, dass Funktionalität fehlt oder noch fehlerhaft ist, und es kommt zu unangenehmen Diskussionen, Reklamationen und Nachlieferungen.
Die Tatsache, dass so viele Softwareprojekte scheitern, hat jedoch auch einen (fragwürdigen) Vorteil: Es lässt sich statistisch ganz gut auswerten, woran es gelegen hat. Bei genauerer Betrachtung stellt sich heraus, dass viele Probleme auf eine der folgenden drei Ursachen zurückzuführen sind:
Mängel im Prozess
Mängel im Prozess liegen u. a. dann vor, wenn nicht oder nur unzureichend festgelegt ist, wie gearbeitet werden soll. Das führt dazu, dass Mitarbeiter ihre Arbeit nach bestem Wissen und Gewissen erledigen, dabei aber möglicherweise wichtige Schritte überspringen. Ein ganz typisches Beispiel ist die Festlegung der Softwarearchitektur. Natürlich machen sich die Entwickler Gedanken über die Architektur. Dies war auch in unserem Fallbeispiel so. Leider gab es keinerlei Vorgabe, dass die Architektur auch niedergeschrieben und aktuell gehalten werden muss. Alle neuen Teammitglieder, die nicht am initialen Workshop teilgenommen hatten, waren dadurch stark benachteiligt und den anderen Teams fehlte eine verbindliche Festlegung der Schnittstellen. Unklare Schnittstellen sind überhaupt ein häufiger Mangel im Prozess, ebenso wie unklare Anforderungen, ungenügende Abstimmungen oder fehlende verbindliche Vereinbarungen hinsichtlich der Vorgehensweise im Prozess oder der technischen Umsetzung im Produkt.
Mangelnde technische Fähigkeiten
Mangelnde technische Fähigkeiten sind eigentlich relativ einfach zu beheben. Wenn ein Entwickler die Programmiersprache nicht beherrscht, muss man ihn eben auf eine Schulung schicken und einarbeiten. Fatalerweise ist es aber nicht immer so offensichtlich, dass Schulungsbedarf besteht. Wer sich mit Anforderungsmanagement oder Qualitätssicherung nicht auskennt, ist sich dessen nicht unbedingt bewusst. Man weiß ja nicht, was man nicht weiß. Daher ist es wichtig, dass der Projektmanager zumindest Grundlagen kennt, die wir in diesem Buch vermitteln.
Kommunikationsprobleme und Führungsschwäche
Während sich die ersten zwei Hauptursachen durch fachliche Kompetenz vermeiden lassen, erfordert der Umgang mit Kommunikationsproblemen Soft Skills. Ein schönes Beispiel ist der Umgang mit Konflikten. Wir werden in Kapitel 10 »Personalmanagement« sehen, dass Konflikte eine völlig normale Erscheinung im Teambildungsprozess sind. Projektmanager sollten daher wissen, wie sie diese geschickt managen.
Noch heikler wird es, wenn wir das Thema Führung betrachten. Hier kann ein Projektmanager unbewusst erschreckend viel falsch machen. Daher möchten wir gleich zu Beginn einem weitverbreiteten Denkfehler entgegenwirken: Mitarbeiter zu führen heißt in unseren Augen nicht, ihnen Vorschriften zu machen, was sie wie zu tun haben, sondern sie anzuleiten und zu lenken. Dazu gehört auch, Aufgaben zu delegieren. In unserem Fallbeispiel agierte der Projektmanager als »Mega Brain«, d. h., alle Entscheidungen liefen über ihn. Gleichzeitig ärgerte er sich jedoch regelmäßig, dass die Teammitglieder ihn wegen jeder Kleinigkeit befragten. Hier waren die Entscheidungskompetenzen völlig unklar.
Abb. 1–1 Hauptursachen für gescheiterte Softwareprojekte
Abbildung 1–1 zeigt noch einmal die Hauptursachen für gescheiterte Softwareprojekte im Überblick. Häufig überlagern sich mehrere Ursachen, aber fast immer sind menschliche Schwächen beteiligt.
Da wir schon dabei sind, Begriffe wie »Führung« zu klären, sollten wir noch ein bisschen weiter ausholen und die wichtigsten Begriffe im Projektmanagement kurz ansprechen. Schließlich ist es ein erklärtes Ziel des ASQF® CPPM, eine einheitliche Terminologie zu etablieren. Man kann nämlich trefflich aneinander vorbei diskutieren, wenn jeder ein anderes Verständnis z. B. des Begriffs »Projekt« hat. Im besten Fall verliert man nur unnötig Zeit. Unterschiedliche Interpretationen können jedoch auch zu ärgerlichen Missverständnissen oder gar zu Fehlern führen.
Der Lehrplan erfindet das Rad nicht neu, sondern setzt auf dem internationalen Standard ISO 21500 auf. Manche Begriffe sind für die Zertifizierung zum ASQF® CPPM wichtig. Diese haben wir als Merksatz hervorgehoben und zur besseren Übersicht im Glossar am Ende des Buches noch einmal zusammengestellt.
Definition Projekt
Was verstehen wir nun also unter dem Begriff »Projekt«?
Projekt
Ein Projekt besteht aus einer einzigartigen Gruppe von Prozessen, die auf eine Zielsetzung ausgerichtete, koordinierte und gesteuerte Vorgänge mit Beginn- und Fertigstellungsterminen umfassen. [ISO 21500]
Wie man sieht, sind Normen nicht unbedingt eine geeignete Nachtlektüre, es sei denn, man will sofort einschlafen. Übersetzt bedeutet dies: Ein Projekt besteht aus Prozessen, hat einen Anfang und ein Ende und soll ein vorher festgelegtes Ziel erreichen. Auf Prozesse kommen wir gleich noch zu sprechen. Zur Definition eines Projektes gehört noch, dass es koordiniert und gesteuert wird. Am Ende werden Lieferobjekte bereitgestellt, die spezifische Anforderungen erfüllen.
Abb. 1–2 Klassifizierung von Projekten
Kein Projekt gleicht dem anderen. Abbildung 1–2 zeigt eine mögliche Klassifizierung verschiedener Projekttypen. Auch das Vorgehensmodell (sequenziell oder agil) und andere projektspezifische Charakteristika beeinflussen die Art und Weise, wie ein Projekt abgewickelt wird. In der Regel unterliegen Projekte gleich mehreren Randbedingungen, wie z. B.:
Definition Prozess
Nachdem wir Projekte mit Prozessen erklärt haben, müssen wir auch den Begriff »Prozess« klar definieren.
Prozess
Ein Prozess besteht aus einer Reihe von zusammenhängenden Vorgängen. [ISO 21500]
Mit »Vorgängen« sind die im Projekt geplanten Arbeitspakete gemeint. In diesem Buch interessiert uns besonders der Softwareentwicklungsprozess, also die Abfolge von Arbeitspaketen, die zur Erstellung einer Software führen sollen. Jeder Prozess hat einen Eingang und einen Ausgang. Die Eingangsdaten eines Softwareentwicklungsprozesses sind die (mehr oder weniger formalisierten) Stakeholder-Anforderungen. Ausgangsdaten sind die Software selbst, die erstellte Dokumentation und eventuell weitere Leistungen des Projektteams.
Definition Projektphasen
Natürlich müssen auch für das Projektmanagement Prozesse festgelegt werden. Je nachdem, ob eine sequenzielle oder agile Vorgehensweise gewählt wird, unterscheiden sich die Abläufe bzw. Vorgänge, die zur Leitung und Steuerung des Projektes zum Einsatz kommen. Die Festlegung der anzuwendenden Projektmanagementprozesse erfolgt üblicherweise im Projektmanagementplan, sofern sie nicht ohnehin organisationsweit vorgegeben sind.
Projektphasen
Projekte werden gewöhnlich (…) in Projektphasen unterteilt. Diese Phasen sollen einer logischen Abfolge mit Beginn und Ende folgen und Ressourcen zur Erstellung von Lieferobjekten nutzen. [ISO 21500]
Jedes Projekt sollte in wenigstens drei Phasen unterteilt sein: Projektinitiierung, Projektumsetzung und Projektabschluss. Jede dieser Phasen umfasst eine Reihe von Arbeitspaketen, die logisch und zeitlich zusammenhängen und im Projektplan entsprechend verknüpft sind (mehr dazu in Kap. 5). Während der Projektinitiierung werden die Grundlagen für die Umsetzung geschaffen, während der Umsetzungsphase entsteht unter anderem die Software und während der Projektabschlussphase werden alle bis dahin noch offenen Aufgaben abgeschlossen.
Längere Projekte sollten mehrere Umsetzungsphasen haben, damit die einzelne Phase nicht zu lang wird. Wirklich entscheidend ist nämlich der Übergang von einer Phase zur nächsten, der Meilenstein. Meilensteine markieren die zeitliche, aber auch die sachliche Trennung der Projektphasen. Sie sind ein Moment des Innehaltens und der Kontrolle, ob das Projekt noch in die richtige Richtung läuft oder einer Kursänderung bedarf. Je länger die Phase ist, desto größer ist die Gefahr, weit vom Weg abzukommen.
Definition Projektlebenszyklus
Alle Projektphasen zusammen ergeben den Projektlebenszyklus.
Projektlebenszyklus
Projektphasen werden zusammen als der Projektlebenszyklus bezeichnet.
Der Projektlebenszyklus erstreckt sich über den Zeitraum vom Beginn des Projekts bis zu dessen Ende. Die Phasen werden durch Entscheidungspunkte (Meilensteine), die sich je nach Organisationsumfeld unterscheiden können, voneinander getrennt.
Abb. 1–3 Schematische Darstellung des Projektlebenszyklus
Definition Projektmanagement
Abbildung 1–3 zeigt eine schematische Darstellung des Projektlebenszyklus mit Projektphasen und Meilensteinen (M1 bis M5), wie sie in vielen organisationsweiten Prozessbeschreibungen zu finden ist1.
Projektmanagement
Projektmanagement ist die Anwendung von Methoden, Hilfsmitteln, Techniken und Kompetenzen in einem Projekt. Es umfasst das (…) Zusammenwirken der verschiedenen Phasen des Projektlebenszyklus. [ISO 21500]
Projektmanagement wird durch Prozesse umgesetzt, die je nach Projekt ausgewählt und aufeinander abgestimmt sind. Es ist wenig sinnvoll, Anforderungen zu erfassen, nachdem die Software schon entwickelt wurde. Wie die Anforderungen erfasst werden, hängt aber u. a. vom Vorgehensmodell (sequenziell oder agil) ab.
In Abbildung 1–3 sind die Prozesse im unteren Teil schematisch als halboffene Kästen dargestellt. Dabei kann sich ein Prozess durchaus über mehrere Phasen erstrecken. Typischerweise ist dies beim Risikomanagement der Fall. Um das Projekt steuern zu können, sollten den Phasen jedoch spezifische Lieferobjekte zugeordnet werden (z. B. die Anforderungsspezifikation oder die Risikoanalyse). Diese können dann spätestens zum Meilenstein geprüft und gegen die Anforderungen des Projektauftraggebers, der Kunden und anderer Stakeholder abgeglichen werden.
Definition Stakeholder
Der Begriff »Stakeholder« ist übrigens im Projektmanagement sehr allgemein definiert.
Stakeholder
Person, Gruppe oder Organisation, die an irgendeinem Aspekt des Projekts interessiert ist oder diesen beeinflusst, davon betroffen ist oder sich davon betroffen fühlen kann. [ISO 21500]
Stakeholder sind also nicht nur Personen, die Anforderungen an das Produkt haben, sondern auch solche, die möglicherweise störend »dazwischenfunken«, weil sie sich durch das Projekt bedroht fühlen. Folglich ist es extrem wichtig, alle Stakeholder zu identifizieren, deren Anforderungen und Ziele zu kennen und angemessen zu managen.
Projektmanager vs. Projektleiter
Vielleicht haben Sie sich schon gefragt, warum wir eigentlich immer von »Projektmanager« sprechen, wo dies doch ein deutschsprachiges Buch ist. Schließlich könnten wir auch von »Projektleitern« sprechen. Tatsächlich werden beide Begriffe im deutschen Sprachgebrauch synonym verwendet. Was auf der Visitenkarte steht, hängt von der Organisationform und -kultur des jeweiligen Unternehmens ab.
Definition Projektleitung
Es gibt aber einen Unterschied zwischen »Projektmanagement« und »Projektleitung«.
Projektleitung
Für die Dauer eines Projektes geschaffene Organisationseinheit, welche für Planung, Steuerung und Überwachung eines Projektes verantwortlich ist. [DIN 69 901]
Der Begriff »Projektleitung« bezieht sich also auf organisatorische Festlegungen, während es im »Projektmanagement« um Prozesse bzw. Aufgaben geht.
Die Projektleitung ist jedoch nicht zwangsläufig einer einzelnen Person übertragen. Größere oder komplexere Projekte haben häufig »Teilprojektmanager/innen und/oder »Fach-Projektmanager/innen«, wie es in der Norm DIN 69 901 heißt. Wie genau die Aufteilung der Verantwortung ist, hängt von den Bedürfnissen der Projektphasen und der Organisationsform ab. Auch das Vorgehensmodell spielt eine Rolle. Im agilen Umfeld übernehmen die Teammitglieder mindestens eine Projektleitungsaufgabe: Sie planen ihre Iterationen selbst.2
In diesem Buch wird durchweg vom Projektmanager die Rede sein, da wir damit die Rolle bezeichnen, die für die jeweilige Teilaufgabe verantwortlich ist. Diese Rolle kann durchaus auf mehrere Personen verteilt sein.
Eine wesentliche Herausforderung für den Projektmanager ist, dass er praktisch nichts tun kann, ohne dass es Wechselwirkungen mit anderen Tätigkeiten hat. Jede Änderung erfordert eine Neuplanung, birgt neue Risiken, muss kommuniziert werden …
Die Autoren der ISO 21500 haben versucht, diese Wechselwirkungen zu verdeutlichen, und dazu die Tätigkeiten des Projektmanagers nach zwei Perspektiven klassifiziert.
Tab. 1–1 Zehn Themengruppen nach ISO 21500
