Basiswissen für Softwareprojektmanager im klassischen und agilen Umfeld E-Book

Andreas Johannsen

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: iSQI-Reihe
• Sprache: Deutsch
• Veröffentlichungsjahr: 2017

Seitenzahl: 404

Beschreibung

Das Buch vermittelt das Grundlagenwissen im Bereich Softwareprojektmanagement. Es behandelt die wesentlichen Aspekte und Betätigungsfelder sowie wichtige Begriffe und Konzepte. Neben Aufgaben und Rollen des Projektmanagements in sequenziellen und agilen Vorgehensmodellen stehen Grundprinzipien und Methoden eines guten Teammanagements und Aspekte der sozialen Kompetenz im Vordergrund. Die Themen im Einzelnen: - Projektorganisation - Prozess- und Vorgehensmodelle in der Softwareentwicklung - Projektinitiierung - Projektplanung - Projektumsetzung und -controlling - Projektabnahme und -abschluss - Qualitätsmanagement - Risikomanagement - Personalmanagement - Reifegradmodelle Das Buch enthält zahlreiche Übungsaufgaben mit Lösungshinweisen und eignet sich nicht nur bestens für die Prüfungsvorbereitung zum "Certified Professional for Project Management (CPPM)", sondern gleichzeitig auch als kompaktes Basiswerk zum Thema an Hochschulen. Der Leser findet in diesem Buch viele konkrete Handlungsvorschläge für die Praxis und wird so befähigt, praktische Aufgaben im Projektmanagement zu übernehmen.

Leseprobe

Prof. Dr. Andreas Johannsen ist seit 2006 Inhaber der Professur »Systementwicklung und -integration« sowie geschäftsführender Direktor des Instituts für Betriebliche Anwendungssysteme (IBAW) der Technischen Hochschule Brandenburg. Darüber hinaus ist er Inhaber der Johannsen Management Consulting (JMC) in Berlin und seit vielen Jahren Trainer von Projektmanagement-Zertifikatskursen.

Dr. Anne Kramer begann ihre Laufbahn als Projektmanagerin in Paris für Schlumberger Systems. Seit 2001 ist sie für die sepp.med GmbH als Projektmanagerin und Prozessberaterin tätig. Als Autorin und Trainerin befasst sie sich regelmäßig mit zertifizierenden Schulungen u. a. zu den Themen »Projektmanagement« und »modellbasiertes Testen«.

Horst Kostal ist seit 1996 als Projektmanager in den Bereichen Automatisierungstechnik, Medizintechnik und Automotive tätig. Seit dem Jahr 2011 ist er für Methodpark als Consultant, Coach und Trainer in den Bereichen Projektmanagement, Agilität, Reifegradprozesse und funktionale Sicherheit unterwegs.

Ewa Sadowicz ist Trainerin und Moderatorin für die Menschen im Projekt. Sie moderiert Teamentwicklungsprozesse und trainiert die Methoden-, Schlüssel- und Verhaltenskompetenzen im Projektmanagement und im agilen Kontext. Ewa Sadowicz ist Gründungsmitglied bei EinfachStimmig.

Dr. Daniela Stokar von Neuforn ist seit 1992 freiberufliche Trainerin und Coach in den Bereichen Kommunikation, Demografie, Kunden- und Serviceorientierung sowie Train the Trainer. Seit 2011 ist sie Inhaberin der Firma TTM Training&TransferManagement. Sie zeichnete einen Großteil der Abbildungen in diesem Buch und verlieh ihm so seinen künstlerischen Wert.

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

Andreas Johannsen · Anne Kramer · Horst Kostal · Ewa Sadowicz

Basiswissen fürSoftwareprojektmanagerim klassischen und agilen Umfeld

Aus- und Weiterbildung zumASQF® 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

Geleitwort von Stephan Goericke

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 GoerickeInternational Software Quality InstituteDirector

Vorwort

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 SadowiczErlangen und Berlin, Februar 2017

Inhaltsübersicht

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

Inhaltsverzeichnis

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

Einleitung

Motivation

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.

Modernes Softwareprojektmanagement

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:

Modernisierung der Lehrinhalte und Angleichung an aktuelle Normen sowie

verstärkte Betonung der Soft Skills.

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.

Der ASQF® CPPM

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.

Ein paar Worte zum Buch

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–1Zusammenspiel 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.

Das Fallbeispiel

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.

1Überblick und Einführung

1.1Woran scheitern Projekte? – Projekterfolgs- und -misserfolgskriterien

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

Mangelnde technische Fähigkeiten

Kommunikationsprobleme und Führungsschwäche

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–1Hauptursachen 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.

1.2Wichtige Begriffe im Projektmanagement

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.

DefinitionProjekt

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–2Klassifizierung 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.:

Feste Abschlusstermine

Limitiertes Budget

Verfügbarkeit der Ressourcen

Einzuhaltende Normen und Gesetze

Interne Vorgaben der Organisation

U. v. a. m.

DefinitionProzess

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.

DefinitionProjektphasen

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–3Schematische 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.

1.3Softwareprojektmanagement im Überblick

1.3.1Prozess- und Themengruppen nach ISO 21500

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.

Die sogenannten »Themengruppen« fassen Prozesse zusammen, die zu einem inhaltlichen Thema gehören. Insgesamt gibt es zehn Themengruppen: Integration, Stakeholder, Inhalte, Ressourcen, Termine, Kosten, Risiko, Qualität, Beschaffung und Kommunikation.

Die sogenannten »Prozessgruppen« fassen Prozesse nach den logischen Schwerpunkten ihrer Tätigkeiten zusammen. Es gibt fünf Prozessgruppen: Initiierung, Planung, Umsetzung, Controlling und Abschluss.

Tab. 1–1Zehn Themengruppen nach ISO 21500

Themengruppe

Umfasst alle Prozesse, die erforderlich sind, um …

Aufgaben

Integration

Projektabläufe aufeinander abzustimmen und den Überblick zu behalten (wichtige Ergebnisse sind der Projektauftrag, der Projektplan, Meilensteinreviews und Lessons Learned)

Vorgänge und Prozesse ermitteln, definieren, kombinieren, vereinheitlichen, koordinieren und abschließen

Stakeholder

Stakeholder angemessen zu involvieren

Auftraggeber, Kunden und andere Stakeholder ermitteln, leiten und lenken

Inhalte

die richtigen Arbeiten und Lieferobjekte durchzuführen bzw. zu erstellen (und auch nur diese, also keine unnötigen Arbeiten oder nicht geforderten Lieferobjekte)

Arbeiten und Lieferobjekte bestimmen, leiten und lenken

Ressourcen

die Rahmenbedingungen zu schaffen, damit das Projekt erfolgreich abgewickelt werden kann

Personen, Einrichtungen, Geräte, Materialien, Infrastruktur und Werkzeuge bestimmen und beschaffen

Termine

Termine festzulegen und zu halten

Projektvorgänge zeitlich planen

Fortschritt gegenüber dem Plan überwachen

Kosten

die Finanzierung des Projektes sicherzustellen und die Kosten im geplanten Rahmen zu halten

Budget planen und beschaffen

Kosten überwachen

Risiko

böse Überraschungen zu vermeiden und im Ernstfall gewappnet zu sein

Gefahren und Chancen bestimmen und bewerten

Maßnahmen einleiten und lenken

Qualität

fehlerfreie, qualitativ hochwertige Lieferobjekte zu erstellen

Qualitätssicherung und -kontrolle planen und durchführen

Beschaffung

ggf. Komponenten oder Dienstleistungen einzukaufen und den Zulieferer zu managen

Produkte, Dienstleistungen planen und erwerben

Lieferantenbeziehungen leiten und lenken

Kommunikation

sicherzustellen, dass alle am Projekt Beteiligten alle für sie erforderlichen Informationen besitzen, damit das Projekt möglichst reibungsfrei ablaufen kann

für das Projekt relevante Informationen planen, leiten und lenken

Informationen verteilen

Tabelle 1–1 liefert einen Überblick über die zehn Themengruppen nach ISO 21500. Tabelle 1–2 zeigt eine vergleichbare Übersicht für die fünf Prozessgruppen. Obwohl die Zeilen in Tabelle 1–2 stark an die bereits erwähnten Projektphasen erinnern, soll damit keine zeitliche Abfolge der Vorgänge suggeriert werden. Beispielsweise werden die Prozesse aus der Gruppe »Abschluss« zu jedem Meilenstein durchlaufen.

Tab. 1–2Fünf Prozessgruppen nach ISO 21500

Prozessgruppe

Umfasst alle Prozesse, die erforderlich sind, um …

Aufgaben

Initiierung

das Projekt zu starten (u. a. wird hier der Projektmanager mit dem Projekt beauftragt)

Projektzielsetzung definieren

Stakeholder ermitteln

Projektteam zusammenstellen

Planung

eine möglichst realistische Vorstellung der zukünftigen Projektabläufe zu haben, eine Grundlage für das Controlling zu schaffen und dem Projekt die gewünschte Richtung zu geben (z. B. durch einen Qualitätsmanagementplan)

Projektplan erstellen

Lieferumfang und Arbeitspakete definieren

Aufwands- und Kostenschätzung durchführen

Risikoanalyse durchführen

Terminplan erstellen

Qualitätssicherung, Beschaffung und Kommunikation planen

Umsetzung

das Projektteam bei der Erstellung der Lieferobjekte zu unterstützen und Hindernisse aus dem Weg zu räumen (auch die eigentliche Durchführung der Projektmanagementvorgänge fällt in diese Gruppe)

Arbeiten koordinieren

Projektteam weiter entwickeln

Risiken beherrschen

Qualität sichern

Lieferanten auswählen

Informationen kommunizieren

Controlling

die Projektdurchführung zu überwachen (engl.: Monitoring) und so zu steuern, dass die Projektpläne eingehalten werden

Einhaltung von Inhalten, Terminen und Kosten überwachen

Änderungen und Risiken managen

Qualität überwachen

Projektteam und Zulieferer aussteuern

Kommunikation sicherstellen

Abschluss

eine Projektphase und am Ende das ganze Projekt sauber abzuschließen und Verbesserungen für die Zukunft einzuleiten

den Abschluss einer Phase oder des Projektes formal feststellen

Lessons Learned ermitteln

Jede Tätigkeit im Projektmanagement lässt sich jeweils einer der Gruppen zuordnen. So gehört z. B. das Management des Projektteams zur Themengruppe »Ressourcen« und zur Prozessgruppe »Controlling«. Wir wollen es jedoch dabei belassen und uns lieber den Aufgaben des Projektmanagements zuwenden.

1.3.2Aufgaben des Projektmanagements

Die wesentliche Aufgabe des Projektmanagements besteht darin, das Projekt erfolgreich abzuwickeln. Wohlgemerkt: Wir sprechen bewusst vom »Projektmanagement« und nicht vom »Projektmanager«, da es sich dabei, wie bereits erwähnt, um mehrere Personen handeln kann, die jeweils einen Teil der Verantwortung für Projektaktivitäten und -ergebnisse übernehmen. Darüber hinaus agiert das Projektmanagement auch nach außen. Es bildet die Schnittstelle zum Kunden und ist verantwortlich für Vertragsverhandlungen.

Projektmanagement spielt sich auf zwei Ebenen ab. Einerseits haben wir die prozessbedingten Aufgaben. Hier reden wir von Methoden, Schnittstellen und Ergebnissen. Andererseits gibt es auch die rollenbasierten Aufgaben. Damit sind alle Aufgaben gemeint, bei denen es auf die Soft Skills ankommt.

Prozessbedingte Aufgaben

Typische prozessbedingte Aufgaben des Projektmanagements sind:

Projektorganisation festlegen

Projektplan erstellen

Arbeitspakete und Meilensteine planen

Methoden und Werkzeuge für das Projekt auswählen

Risikomanagement durchführen

Projektteam führen

Form der Berichterstattung festlegen

Einhaltung der Pläne überwachen (Termine, Kosten, Prozesse)

Kontakt mit dem Kunden halten

Verhandlungen mit dem Kunden führen

u. v. a. m.

Rollenbasierte Aufgaben

Darüber hinaus nimmt das Projektmanagement (bzw. der Projektmanager und alle, die ihm unter die Arme greifen) verschiedene Rollen ein, die wiederum ebenfalls bestimmte Aufgaben nach sich ziehen (siehe Tab. 1–3).

Tab. 1–3Rollenbasierte Aufgaben des Projektmanagements

Rolle

Aufgaben

Beziehungsmanager(Repräsentant, Führungskraft, Kontaktpfleger, Motivator)

das Projekt nach außen repräsentieren

das Projektteam führen und motivieren

Kontakte mit Stakeholdern pflegen

Informationsgeber(Beobachter, Informant, Sprecher)

Projektabläufe und -umfeld beobachten

Informationen verteilen

als Sprecher für das Projekt auftreten

Entscheidungsträger(Unternehmer, Problemlöser, Ressourcenverteiler, Unterhändler)

unternehmerische Entscheidungen treffen

Probleme adressieren und lösen

Ressourcen beschaffen und zuteilen

Verträge aushandeln

Es ist wichtig, dass dem Softwareprojektmanager die Bedeutung der rollenbedingten Aufgaben bewusst ist.3

1.3.3Kompetenzanforderungen an Projektmanager

Projektmanagement ist eine anspruchsvolle Aufgabe. Der Projektmanager bewegt sich permanent im Spannungsfeld aus Kosten, Terminen und Qualität bzw. Inhalt, das in Abbildung 1–4 dargestellt ist. Wer schneller liefern will, muss entweder höhere Kosten akzeptieren oder den Leistungsumfang kürzen bzw. Abstriche bei der Qualität in Kauf nehmen.

Abb. 1–4Spannungsfelder im Projektmanagement

Doch auch Kunden, Projektteam und Organisation verfolgen oft unterschiedliche, im schlimmsten Fall sogar widersprüchliche Interessen. Der Projektmanager muss daher permanent abwägen und Entscheidungen treffen. Auch wenn es gerne suggeriert wird: Der Kunde hat nicht immer Recht und man tut ihm auch keinen Gefallen damit, unrealistische Projektziele zu akzeptieren.

Erforderliche Kompetenzen

Projektmanager benötigen daher eine Reihe verschiedener Kompetenzen. Neben den klassischen Hard Skills wie Fachwissen und Methodenkompetenz sind vor allem Soft Skills gefragt. Dazu zählen soziale Kompetenz, Persönlichkeit und Organisationskompetenz (siehe Abb. 1–4). Um die in Tabelle 1–3 dargestellten rollenbedingten Aufgaben zu erfüllen, muss er außerdem führen, kommunizieren, verhandeln und Probleme lösen können. Diese allgemeinen Managementfähigkeiten bilden die Grundlage erfolgreichen Projektmanagements. Da dieses Thema so wichtig ist, haben wir ihm ein eigenes Kapitel in diesem Buch gewidmet (Kap. 10 »Personalmanagement«).

Vier Verantwortungsbereiche

Die erforderlichen Kompetenzen eines Projektmanagers lassen sich in vier Verantwortungsbereiche gliedern4 [SFIA]:

Autonomie

Einfluss

Komplexität

Unternehmerische Kompetenzen

Autonomie

Gute Projektmanager besitzen große Autonomie und scheuen sich nicht davor, Verantwortung zu übernehmen. Für Teammitglieder mit Projektmanagementverantwortung bedeutet dies, dass sie sich trauen, Entscheidungen zu treffen und dann zu ihren Handlungen stehen. Für vorgesetzte Projektmanager, die Arbeiten delegieren, bedeutet dies, dass sie sich hinter die Entscheidungen ihrer Mitarbeiter stellen, denen sie Aufgaben übertragen haben.

Einfluss

Einfluss zu nehmen bedeutet, dass der Projektmanager einerseits das Team im Sinne der Projektziele beeinflusst, andererseits aber auch die Kundenseite und das Unternehmen beeinflusst. Jeder Projektmitarbeiter nimmt Einfluss auf Projekt und Unternehmen, wenn er durchsetzt, dass Abläufe vereinfacht oder neue Methoden oder moderne Technologien eingesetzt werden. Der Projektmanager kann als Kundenansprechpartner dazu beitragen, stabile, langfristige Geschäftsbeziehungen aufzubauen.

Komplexität

Der Projektmanager sollte fundierte Kenntnisse der Branche, der eingesetzten Technologien und generell des Projektumfeldes besitzen. Hinzu kommen Methodenkenntnisse bezüglich Anforderungs- und Risikomanagement, Projektplanungs- und -controllingmethoden und Qualitätssicherung. All diese Kenntnisse bilden zusammen einen mentalen Werkzeugkasten, der ihm hilft, die ständig steigende Komplexität von Softwareprojekten hinsichtlich Technik, Terminen und Qualität zu beherrschen.

Unternehmerische Kompetenzen

Projektmanager übernehmen im gewissen Grad auch unternehmerische Aufgaben, z. B., wenn sie mit Zulieferern Verträge aushandeln. Auch das im Projekt betriebene Risikomanagement begrenzt unternehmerische Risiken der Organisation.

Projektmanager benötigen Soft Skills.

Das Zusammenspiel dieser vier Verantwortungsbereiche bildet die Grundlage für ein erfolgreiches Projektmanagement. Wie stark diese Kompetenzbereiche gefordert sind, hängt im Einzelnen von der übertragenen Aufgabe, der Organisation und der Projektumgebung ab. In großen Firmen verhandelt üblicherweise eine zentrale Einkaufsabteilung mit den Zulieferern. Hier muss der Projektmanager stärker intern seinen Einfluss geltend machen.

1.4Zusammenfassung

In diesem Kapitel wurde ein Überblick über das Thema »Projektmanagement« vermittelt und einige für das Verständnis notwendige Begriffe definiert. Zu den »key takeaways« gehören:

Die meisten Projekte scheitern an Mängeln im Prozess (z. B. unklare Anforderungen), mangelnden technischen Fähigkeiten und/oder Kommunikationsproblemen und Führungsschwäche.

Projektmanagement ist häufig auf verschiedene Personen verteilt.

Der internationale Standard ISO 21500 gliedert Projektmanagementprozesse einerseits thematisch in zehn Themengruppen und andererseits logisch in fünf Prozessgruppen.

Projektmanagement besteht aus prozessbedingten und rollenbedingten Aufgaben.

Personen, die mit Projektmanagementaufgaben betraut werden, benötigen neben technischen auch eine Vielzahl nicht technischer Fähigkeiten.

1.5Übungsaufgaben

Erläutern Sie, an welchen Faktoren Projekte üblicherweise scheitern.

Nennen und beschreiben Sie drei wesentliche Begriffe, die durch die ISO 21500 definiert sind.

Nennen Sie die zehn Projektmanagementthemengruppen.

Beschreiben Sie den Zusammenhang, der zwischen den Projektkernprozessen »Planung« und »Controlling« besteht.

Nennen Sie fünf Kernaufgaben des Projektmanagements.

Erklären Sie, warum ein Projektmanager unternehmerische Kompetenzen aufweisen sollte.

2Projektorganisation

2.1Ziele und Aufgaben der Projektorganisation

Projektorganisation

Die Projektorganisation regelt die Zusammenarbeit im Projekt hinsichtlich Verantwortlichkeiten, Aufgaben und Rechte der beteiligten Personen. Aufgabe der Projektorganisation ist es, sowohl die statischen Aspekte (Aufbauorganisation) als auch die dynamischen Aspekte (Ablauforganisation) des Projektes zu regeln. Eine gute Projektorganisation sichert kurze Entscheidungswege und klare Verantwortlichkeiten. [ASQF CPPM 2016]

DefinitionProjektorganisation

Die Kernaufgabe der Projektorganisation besteht darin, die Zusammenarbeit aller Beteiligten zu regeln. Jeder soll wissen, was von ihm erwartet wird, welchen Spielraum er hat und wofür er de facto verantwortlich ist. Wir unterscheiden dabei zwischen Aufbau- und Ablauforganisation. Wie man den Begriffen unschwer entnehmen kann, beschäftigt sich die Aufbauorganisation mit statischen Aspekten, die Ablauforganisation hingegen mit dynamischen Aspekten.

Festlegung der Verantwortlichkeiten

Hinsichtlich der Verantwortlichkeiten legt die Projektorganisation insbesondere fest [Hindel 2009]:

welche Aufgaben und Rechte die einzelnen Projektbeteiligten besitzen,

welche Kompetenzen zur Erfüllung dieser Aufgabe nötig sind,

inwiefern interne (z. B. Teilteams) und externe (z. B. Unterauftragnehmer) Schnittstellen angebunden werden und

welche Eskalationswege gestaltet sind.

Eine effiziente Projektorganisation ermöglicht schlanke Entscheidungswege und transparente Verantwortlichkeiten.

2.2Aufbauorganisation

2.2.1Bedeutung und Ziele der Aufbauorganisation

Idealerweise erfolgt die Definition von Verantwortlichkeiten und Beziehungen innerhalb des Projektes über die offizielle Festlegung einer Projektaufbauorganisation. Im Grunde sprechen wir hier über eine Art Organigramm, aus dem ersichtlich wird, welche Verantwortung und Befugnisse die einzelnen Projektmitarbeiter bzw. die am Projekt beteiligten Organisationseinheiten haben und in welcher Beziehung sie zueinanderstehen.

Projektaufbauorganisation ≠ Stammorganisation

Die Aufbauorganisation des Projektes sollte allerdings nicht mit der Aufbauorganisation des Unternehmens verwechselt werden (die wir hier vereinfacht die »Stammorganisation« nennen). In der Regel sollte für jedes Projekt eine individuelle aufbauorganisatorische Lösung gefunden werden, die in die bestehende Stammorganisation eingebettet werden muss. Schließlich ist ein Projekt etwas Einzigartiges, zeitlich Begrenztes, was nicht unbedingt in die »normalen« Abläufe des Unternehmens passt.

Ziele der Aufbauorganisation

Eine projektspezifische Aufbauorganisation erlaubt es uns, insbesondere mittlere und größere Projekte überhaupt erst effektiv und effizient durchzuführen. Sie ermöglicht es, drei wesentliche Ziele zu erreichen:

Spezielle, für die Projektabwicklung zuständige Organisationseinheiten einzurichten, die für ihre Aufgabe optimal aufgestellt sind.

Diese Organisationseinheiten in die Stammorganisation des Unternehmens einzuordnen, damit geklärt ist, wer was zu bestimmen hat.

Die Kooperation (also die Zusammenarbeit) zwischen der Projektorganisation und der Stammorganisation zu regeln.

Konkret heißt dies beispielsweise, dass es aus Spezialisten zusammengesetzte Projektteams gibt, deren Projektmanager häufig nicht hierarchisch vorgesetzt ist – und trotzdem geklärt ist, wer die Urlaubsanträge genehmigt.

Zu berücksichtigende Rollen

Welche Rollen muss eine Projektaufbauorganisation berücksichtigen? Ganz wichtig sind natürlich der Auftraggeber des Projektes (der als interner oder externer Kunde auftreten kann), das Projektteam und das Projektmanagement selbst. Dies gilt sowohl für sequenzielle als auch (entsprechend angepasst) für agile Vorgehensmodelle. Zu den Unterschieden der Vorgehensmodelle kommen wir aber erst später (siehe Kap. 3).

2.2.2Mögliche Formen der Aufbauorganisation

Grundsätzlich haben sich in der Praxis vier Basismodelle zur Gestaltung der Aufbauorganisation etabliert. Natürlich ist es auch hier – wie in vielen anderen Bereichen des Projektmanagements – möglich, Zwischenlösungen oder Kombinationen der folgenden Möglichkeiten einzusetzen:

Projektabwicklung im Rahmen der Stammorganisation

Prinzip der Projektorganisation im Rahmen der Stammorganisation

Hier ändert sich, grob gesagt, nichts. Die Projektabwicklung innerhalb der Stammorganisation verzichtet darauf, projektspezifische Organisationseinheiten zu definieren. Es werden die Abteilungen involviert, die für das Projekt relevant sind und benötigt werden.

Dies hat grundsätzlich erst einmal den Vorteil, dass nicht in die Unternehmensorganisation eingegriffen werden muss.

Abb. 2–1Projektabwicklung innerhalb der Stammorganisation

Allerdings birgt dieses Vorgehen die Gefahr, dass Projekttätigkeiten durch das Tagesgeschäft vernachlässigt werden (oder umgekehrt) und dass der interdisziplinäre Austausch über Abteilungsgrenzen hinaus nur mühsam erfolgt.

Vorteile der Projektorganisation im Rahmen der Stammorganisation

Die Projektorganisation im Rahmen der Stammorganisation hat eine Reihe von Vorteilen:

(+) Es sind keine Änderungen der Aufbauorganisation (»Versetzungen« etc.) nötig.

(+) Die Kommunikationswege sind kurz.

(+) Das Projektmanagement hat guten »Durchgriff« auf das Team.

Nachteile der Projektorganisation im Rahmen der Stammorganisation

Die Nachteile der Projektorganisation »in der Linie« (wie diese Form manchmal auch genannt wird) sind demgegenüber:

(-) Das Tagesgeschäft hat oft »erste Priorität«.

(-) Es ist nicht immer das fachlich qualifizierte Personal verfügbar.

(-) Diese Organisationsform wird oft für kleine Projekte oder weniger umfangreiche Projektphasen eingesetzt, wobei sich nicht selten während der Projektlaufzeit herausstellt, dass sie nicht angemessen ist und geändert werden sollte (so geschehen in unserem Fallbeispiel).

Stabsprojektorganisation (Einflussprojektorganisation)

Prinzip der Stabsprojektorganisation

Bei der Stabsprojektorganisation – manchmal auch Einflussprojektorganisation genannt – existiert zwar ein Projektmanager bzw. die Rolle des Projektmanagements zwecks Koordination der Projektabwicklung, die verantwortliche Person ist aber in einer Stabsstelle angesiedelt. Die disziplinarische Weisungs- und Entscheidungsbefugnis über den Mitarbeiter verbleibt beim Linienvorgesetzten. Nur für den Einsatz der Projektmitarbeiter im Rahmen der Projektarbeit unterliegen diese fachlich dem Projektmanager. Ebenso bleiben die Projektmitarbeiter ihren einzelnen Abteilungen auch während des Projekts erhalten. Der Projektmanager ist meist in einer eigenen Stabseinheit angesiedelt und koordiniert von dieser aus die Projektmitarbeiter.

Abb. 2–2Stabsprojektorganisation

Auch in diesem Modell findet bis auf die Schaffung einer Stabsstelle »Projektmanagement« kein wesentlicher Eingriff in die bestehende Organisationsform statt (siehe Abb. 2–2). Obwohl der Projektmanager eine separate Stabsstelle oder sogar Stabsabteilung erhält, ist dieses Modell organisatorisch als aufwandsarm anzusehen, da in allen anderen Organisationseinheiten keine Änderungen vorzunehmen sind.

Der Projektmanager als Berater

Der Projektmanager besitzt bei dieser Form eine koordinierende und beratende Funktion, die Weisungsbefugnis über die Projektmitarbeiter obliegt weiterhin (zumindest zum überwiegenden Teil) dem Linienmanagement. Dies bietet Konfliktpotenzial in zweierlei Weise. Zum einen ist der Projektmanager auf die Kooperationsbereitschaft der Fachabteilungen angewiesen, da auch hier die Gefahr besteht, dass Projekttätigkeiten dem Tagesgeschäft unterliegen. Zum anderen ist er auf die Kooperationsbereitschaft der Projektmitarbeiter angewiesen, da der Projektmanager gegenüber Projektmitarbeitern keine Handlungsbefugnisse besitzt und dies zu einer mangelnden Akzeptanz führen könnte.

Vorteile der Stabsprojektorganisation

Die Vorteile der Stabsprojektorganisation sind grob zusammengefasst:

(+) Die Kooperation getrennter Organisationseinheiten kann im Rahmen des Projektes gesteuert werden.

(+) Es müssen nur geringe Veränderungen in der bestehenden Organisation vorgenommen werden.

Nachteile der Stabsprojektorganisation

Die Nachteile der Stabsprojektorganisation sind demgegenüber:

(-) Das Projektmanagement hat keine oder kaum Weisungsbefugnisse.

(-) Die Verantwortungsverhältnisse sind oft unklar.

(-) Es entsteht ein hoher Koordinationsaufwand zwischen den Abteilungen.

Matrixprojektorganisation

Prinzip der Matrixprojektorganisation