Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: kommentar@oreilly.de.

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 Autoren 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

Inhalt

Danke!

1Warum dieses Buch?

Projektmanagementzertifizierungen

Vorgehensmodelle

Mehr ist manchmal zu viel

Ziel des Buchs

2Projektmanagement auf einen Blick

Man kommt am Denken nicht vorbei!

Was haben alle Projekte gemeinsam?

Projektmanagement auf einen Blick

Projekte erfolgreich ins Ziel führen

Teil I: Vorbereitung und Start

3Projekte planen

Durch Planung lernen

Beginne mit dem Ende!

Verändere die Sichtweise auf das Projekt

Planungstiefe

Sei gedanklich immer einen Schritt voraus!

Essenz

4Meilensteine definieren

Wann startet ein Projekt?

Wann ist ein Projekt zu Ende?

Was passiert dazwischen?

Was ist wichtig beim Erreichen eines Meilensteins?

Essenz

5Ressourcen managen

Wie viel sind genug?

Mehr ist zuerst weniger

Essenz

6Risiken antizipieren

Risiken erfassen

Transparenz bewahren

Projekt gedanklich abschreiten

Risiken minimieren

Risiken überwachen

Essenz

7Projekte starten

Was braucht es für einen Projektstart?

Projekt-Kick-off – die Wirkung nach innen

Projektmarketing – die Wirkung nach außen

Essenz

Teil II: Realisierung und Abschluss

8Projekte steuern

Fertig oder fertig fertig?

Aufwand schätzen, Fertigstellungsgrad messen

Plausibilisierung

Essenz

9Softwarequalität beeinflussen

Was ist Softwarequalität?

Wann entstehen Fehler?

Wie entstehen Fehler?

Die Kultur macht den Unterschied

Essenz

10Dokumentation festlegen

Was hat die Dokumentation mit der Produktqualität zu tun?

Welche Dokumente braucht es nun?

Dokumentation im agilen Umfeld

Was ist sonst noch wichtig?

Essenz

11Projekte abschließen

It’s not a Bug, it’s a Feature!

Abnahme

Dokumentation

Lessons Learned

Abschlussfeier

Essenz

Teil III: Rollen und Beziehungen

12Rollen definieren

Warum braucht es Rollen?

Welche Rollen soll man nun implementieren?

Wie sieht das AKV-Prinzip der Grundrollen aus?

Essenz

13Projektleiter und Agilität

Aufgaben in der Projektführung

Interner vs. externer Auftraggeber

Kann man Verantwortung teilen?

Essenz

14Teams bilden

Kopf- versus Handarbeit

Wer sind die Richtigen?

Ein Topteam formen

Essenz

15Stakeholder einbeziehen

Verbündete gewinnen

Vertrauen aufbauen

Positive Nachrichten senden

Essenz

16Schwierigkeiten anpacken

Umgang mit Schwierigkeiten

Arten von Schwierigkeiten

Was heißt das für den Projektleiter?

Essenz

 

17Agilität in Projekten

Werte der Agilität

Kern der Agilität

Grenzen der Agilität

18Starthilfe

Welches Vorgehensmodell passt nun?

Reflexion als Entscheidungshilfe für dein Tailoring

19Schlusswort

Anhang

Index

Danke!

Es gehört für uns zu den schönsten Dingen im Leben, die Zeit mit etwas zu verbringen, woran wir glauben, was uns begeistert und worauf wir stolz sind.

Dazu gehört die Arbeit an diesem Buch. Auf diesem Weg wurden wir unterstützt von Michel Vergères, der mit seinen klaren Analysen und Rückmeldungen in spannenden Diskussionen wesentlich zu dessen Qualität beigetragen hat. Genauso viel Qualität hat das Buch sprachlich wie inhaltlich gewonnen durch die wertvollen und kurzweiligen Team-Meetings mit unserer Lektorin von O’Reilly, Ariane Hesse.

Nicht zuletzt ein großer Dank unseren Familien, die uns den notwendigen Freiraum zugestanden haben.

KAPITEL 1

Warum dieses Buch?

Projekte haben für Firmen eine große Bedeutung – egal ob interne Projekte oder externe Kundenaufträge. Schließlich geht es um Geschäftserfolg, Wettbewerbsfähigkeit und Kundenvertrauen. Abhängig von dieser Wichtigkeit der Projekte sollte der Projekterfolg entsprechend groß sein. Wie steht es in der Praxis also um die Erfolge?

Gemäß dem CHAOS-Report der Standish Group liegen heute die Chancen, ein IT-Projekt erfolgreich abzuwickeln, in dem niedrigen Bereich der 30er-Prozente. Und dies, obwohl man seit Jahrzehnten versucht, die Ausbildung der Projektleiter zu verbessern sowie die Abwicklung der Projekte in Vorgehensmodellen zu standardisieren.

Wie kann das sein!? Fehlt da etwas? Wir sind der Meinung ja, nämlich die Essenz des Projektmanagements zu begreifen und anzuwenden. Was wir darunter genau verstehen, folgt gleich, zunächst schauen wir uns aber die bisherigen Bemühungen an, Projekte erfolgreicher zu gestalten, und warum das bisher nicht genügte.

Projektmanagementzertifizierungen

Bereits 1965 wurde der Vorläufer der heutigen International Project Management Association (IPMA) gegründet. Unter dem Dach der IPMA haben sich bis heute rund 70 nationale Projektmanagementvereinigungen zusammengeschlossen mit dem Ziel, Projektleiterinnen und Projektleiter international zu vernetzen und den Austausch untereinander zu fördern. Zusätzlich werden Ausbildungen und Zertifizierungen angeboten, wobei hier bewusst die Handlungskompetenzen eines Projektleiters in den Vordergrund gestellt werden und keine Methoden oder Tools. Diese Handlungskompetenzen werden in der sogenannten Individual Competence Baseline (ICB) zusammengefasst und umfassen aktuell 28 Kompetenzelemente, gruppiert in die drei Kompetenzbereiche Kontext, Menschen und Praktiken.

Neben der europäisch geprägten IPMA gibt es seit 1969 das US-amerikanische Project Management Institute (PMI), das eine vergleichbare Organisation darstellt. Mit seinem PMBOK-Guide stellt es im Unterschied zu der europäischen Herangehensweise ein prozessorientiertes Modell bereit, das vom IEEE als Standard anerkannt wurde.

Mit PRINCE2 (Projects IN Controlled Environments) gibt es eine dritte weltweit verbreitete Projektmanagementmethode, die anhand eines Best-Practice-Leitfadens konkrete Handlungsempfehlungen für jede Projektphase gibt. Ursprünglich wurde diese Methode von den britischen Behörden eingeführt und weiterentwickelt und wird heute von der privaten AXELOS angeboten.

Alle drei Organisationen bieten Zertifizierungen für Projektleiter an, die in den letzten Jahren einen enorm wachsenden Zulauf verzeichneten. Vermutlich kennst du bereits zertifizierte Kolleginnen oder Kollegen oder gehörst sogar selbst dazu.

Vorgehensmodelle

In den vergangenen Jahrzehnten sind zahlreiche Vorgehensmodelle für IT-Projekte entstanden (siehe Tabelle 1-1 unten). Alle haben das Ziel, die verschiedenen Phasen, Rollen und Artefakte eines Projekts zu standardisieren und so allen Projektbeteiligten Sicherheit und eine klare Leitlinie zu geben, die vermittelt, wer wann was zu tun hat. Lass uns dazu die wesentlichen Ansätze kurz überfliegen.

Der prominenteste Vertreter unter den Vorgehensmodellen ist sicher das Wasserfallmodell, das das Projekt sequenziell in aufeinanderfolgende Phasen unterteilt, wobei die Ergebnisse einer Phase als Voraussetzungen für die nächste Phase dienen. Es ist ein leicht verständliches Modell und in der einen oder anderen Ausprägung stark verbreitet. Die größte Schwäche dieses Modells ist sicher das lineare Vorgehen und die damit verbundene mangelnde Flexibilität gegenüber Änderungen und neuen Anforderungen. Eine erste Verbesserung dieses Wasserfallmodells stellt das ebenfalls sequenzielle V-Modell dar, das zusätzlich die Testphasen den jeweiligen Entwicklungsphasen gegenüberstellt und so Stufe um Stufe die Verifikation und Validierung gewährleistet. Dank dieser Eigenschaft trifft man das V-Modell typischerweise in einem sicherheitsrelevanten Umfeld an, in dem Verifikation und Validierung wesentliche Anforderungen sind. Mit dem Spiralmodell wurde 1986 zeitgleich ein iteratives Vorgehensmodell vorgestellt, das die Phasen mehrfach spiralförmig durchläuft. Dies erlaubt es, im Projektverlauf dazuzulernen, sich dem Ziel anzunähern und so die Risiken zu minimieren. Allerdings wiederholt man hier mit wenigen Iterationen die Phasen vollständig, was nur ein langsames Lernen zulässt.

Dieses iterative Vorgehen und somit rasche Lernen hat sich aber als zentrales Element mit großem Mehrwert herausgestellt und wurde von weiteren Vorgehensmodellen, wie Rational Unfied Process (RUP), Extreme Programming (XT) oder Scrum, aufgegriffen sowie verfeinert. Die Zyklen wurden zeitlich stark gekürzt, sodass die gewonnenen Erkenntnisse viel rascher in die nächste Iteration einfließen können. Zudem versprechen agile Methoden gemäß ihrem Manifest [TAM01] schnellere und flexiblere Projekte durch leichtgewichtigere Prozesse und größere Kundennähe im Vergleich zu klassischen Vorgehensmodellen. Diese agilen Ansätze wurden von den klassischen Modellen ebenfalls aufgegriffen, und ihre Vorgehensmodelle wurden entsprechend modifiziert, so beispielsweise geschehen beim V-Modell, das zum V-Modell 97 und später zum V-Modell XT erweitert wurde.

Welches dieser Vorgehensmodelle kommt nun in der Praxis tatsächlich zum Einsatz? Viele Unternehmen möchten die Vorteile aus beiden Welten – also den klassischen wie auch den agilen Projektmanagementansatz – nutzen, weshalb häufig hybride Vorgehensweisen eingesetzt werden. Die Wahl des Vorgehensmodells hängt zudem wesentlich vom Fachgebiet deiner Software und der Unternehmenskultur ab.

Die Vielfalt und der Wandel der Modelle lassen erahnen, dass eine wirklich zuverlässige Methode, Projekte erfolgreich ins Ziel zu führen, noch nicht gefunden wurde und es wahrscheinlich so nie geben wird.

Nachfolgende Tabelle enthält eine Übersicht der wesentlichen Vorgehensmodelle und ihrer Einordnung. Dabei ist diese Auflistung nicht vollständig, sie soll lediglich einen Überblick über die großen Veränderungen geben und zeigen, wie lange bereits versucht wird, Projektmanagement zu standardisieren.

Tabelle 1-1: Übersicht über wesentliche Vorgehensmodelle

Modell	Bekannt seit	Herkunft
Phasenorientierte Modelle
Phasenorientiertes Modell	1956	erstes Phasenmodell (H. D. Benington)
Wasserfallmodell	1970	Basismodell (W. W. Royce)
Hermes	1975	IT-Entwicklungsprojekte der Bundesverwaltung der Schweiz
V-Modell	1986	IT-Entwicklungsprojekte der
V-Modell 97	1997	Bundesrepublik Deutschland
V-Modell XT	2005
PRINCE	1989	ursprünglich britischer
PRINCE2	1996	Regierungsstandard
Iterative Modelle
Spiralmodell	1986	iteratives Vorgehensmodell (B. W. Boehm)
RUP (Rational Unified Process)	1999	iteratives Vorgehensmodell (Rational Software)
Agile Modelle
Scrum	1995	iteratives, agiles Vorgehensmodell (J. Sutherland, K. Schwaber)
XP (Extreme Programming)	1997	iteratives, agiles Vorgehensmodell (K. Beck)
Agile Modelle für große Projekte
SAFe (Scaled Agile Framework)	2011	agiles Vorgehensmodell für große Projekte (D. Leffingwell)
Nexus	2015	K. Schwaber
Scrum@Scale	2018	J. Sutherland

Mehr ist manchmal zu viel

Genauso wenig, wie es gelingt, die Projektabläufe zu standardisieren, führen die vielfältigen Bemühungen, Projektleiterinnen und Projektleiter besser auszubilden, offensichtlich nicht in ausreichendem Maße zum gewünschten Erfolg.

Wieso reicht das nicht?

Schauen wir auf die vielfältigen Aufgaben eines Projektleiters, zeigt sich, dass er ein wahres Multitalent sein muss: Er soll planen, organisieren, motivieren, verhandeln und vieles mehr. Dass dieser Eindruck nicht täuscht, zeigt sich beispielsweise an der IPMA-Zertifizierung, denn gemäß dieser müssen sich Projektleiterinnen und Projektleiter aktuell in 133 Kompetenzindikatoren beweisen – gruppiert in 28 Kompetenzelemente! Vor diesem Hintergrund stellt sich die Frage, ob Projektleiter die Besonderheiten ihres jeweiligen Projekts überhaupt noch erkennen oder aufgrund der (zu) hohen Erwartungen häufig dazu neigen, die Prozessschritte und Checklisten unreflektiert abzuarbeiten. Diese Vorgehensweise gibt dem Projektleiter zwar ein gutes Gefühl (eine Scheinsicherheit), alles richtig gemacht zu haben, doch es besteht auch die Gefahr, wesentliche Aspekte des jeweiligen Projekts aus dem Blick zu verlieren.

Ähnlich verhält es sich mit den Vorgehensmodellen: Sie sind oft überfrachtet, sodass die zugrunde liegende Zielsetzung der einzelnen Methoden und Arbeitsschritte kaum noch erkennbar ist. Wie kommt das?