Modernes Projektmanagement in der Praxis E-Book

Holger Timinger

• Herausgeber: Wiley-VCH GmbH
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 470

Beschreibung

Projekte durchzuführen ist eine komplexe Angelegenheit. Das richtige Vorgehensmodell stellt dabei das Fundament für den späteren Projekterfolg dar, denn es führt die Projektbeteiligten strukturiert von der Idee bis zum gewünschten Ergebnis. Holger Timinger unterstützt Sie bei der Auswahl des zu Ihrem Projekt passenden Projektmanagementansatzes und der individuellen Anpassung der zugehörigen Methoden an die Erfordernisse Ihres Projekts. Dabei stellt er Ihnen gemäß einer modernen Betrachtungsweise Werkzeuge mit traditionellem, agilem oder hybridem Ansatz vor und beschreibt deren Stärken und Schwächen. Stets verständlich und mit vielen Beispielen ist dieses Buch Ihr Wegweiser zum richtigen Vorgehensmodell und damit zum Erfolg Ihrer Projekte.

Leseprobe

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.

1. Auflage 2021

© 2021 Wiley-VCH GmbH, Weinheim

All rights reserved including the right of reproduction in whole or in part in any form. This book published by arrangement with John Wiley and Sons, Inc.

Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in Teilen und in jeglicher Form. Dieses Buch wird mit Genehmigung von John Wiley and Sons, Inc. publiziert.

Wiley, the Wiley logo and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.

Wiley und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.

Coverfoto: cosmokidz – stock.adobe.comKorrektur: Petra Heubach-Erdmann

Print ISBN: 978-3-527-53053-3

Inhaltsverzeichnis

Cover

Titelblatt

Impressum

Einleitung

Über das Buch

Meine Leser

Vorwissen

Ziel des Buchs

Was bedeutet was

1 Grundlagen des Projektmanagements

Übersicht

Grundlagen planbasierten Projektmanagements

Grundlagen agilen Projektmanagements

Auf einen Blick

Übungsfragen und Beispiele

2 Aufbau von Vorgehensmodellen des Projektmanagements

Übersicht

Strukturelle Bausteine von Vorgehensmodellen

Funktionale Bausteine von Vorgehensmodellen

Prozessuale Bausteine von Vorgehensmodellen

Auf einen Blick

Übungsfragen und Beispiele

3 Standardisierte Vorgehensmodelle des Projektmanagements

Übersicht

Sequenzielle Vorgehensmodelle

Nebenläufige Vorgehensmodelle

Wiederholende Vorgehensmodelle

Agile Vorgehensmodelle

Weitere agile Vorgehensmodelle

Hybride Vorgehensmodelle

Vergleich standardisierter Vorgehensmodelle

Auf einen Blick

Übungsfragen und Beispiele

4 Auswahl und Tailoring von Vorgehensmodellen

Übersicht

Modelle zur Auswahl von Vorgehensmodellen

Tailoring

Exemplarisches Tailoring der Definitionsphase

Exkurs: Tailoring agiler Vorgehensmodelle für Hardware-Entwicklungsprojekte

Auf einen Blick

Übungsfragen und Beispiele

5 Beispiele aus der Praxis

Übersicht

Beispiele zur Auswahl und zum Tailoring von Vorgehensmodellen

Beispiele zur Konstruktion neuer Vorgehensmodelle

Beispiele zur Einführung neuer Vorgehensmodelle

Auf einen Blick

6 Baukasten für Vorgehensmodelle

Übersicht

Strukturelle Bausteine

Funktionale Bausteine

Prozessuale Bausteine

7 Glossar

8 Lösungen zu den Übungsfragen und Beispielen

Lösungen zu den Aufgaben aus Kapitel 1

Lösungen zu den Aufgaben aus Kapitel 2

Lösungen zu den Aufgaben aus Kapitel 3

Lösungen zu den Aufgaben aus Kapitel 4

Stichwortverzeichnis

End User License Agreement

Illustrationsverzeichnis

Einleitung

Abbildung 0.1: Farbcodes für unterschiedliche Themen und Kapitel dieses Buch...

Kapitel 1

Abbildung 1.1: Schematischer Ablauf planbasierter und agiler Projekte in Anl...

Abbildung 1.2: Roter Faden des Projektmanagements als sehr einfaches Vorgehe...

Abbildung 1.3: Beispiel eines Project Canvas

Abbildung 1.4: Magisches Dreieck aus traditioneller und agiler Sicht

Abbildung 1.5: Beispiel eines Phasen- und Meilensteinplans. Die Ziffern in d...

Abbildung 1.6: Übersicht wichtiger Projektbeteiligter

Abbildung 1.7: Verantwortlichkeiten und Befugnis wichtiger projektbeteiligte...

Abbildung 1.8: Beispiel eines RACI-Diagramms

Abbildung 1.9: Aufbau und Zusammenhang von Projektstrukturplan, Terminplan s...

Abbildung 1.10: Wird der tatsächliche Aufwand einer zu verrichtenden Arbeit ...

Abbildung 1.11: Methoden zur Ermittlung des Fertigstellungsgrads mit Stärken...

Abbildung 1.12: Wichtige Begriffe der Earned-Value-Analyse im Diagramm

Abbildung 1.13: Überblick über wichtige Bestandteile der Earned-Value-Analys...

Abbildung 1.14: Visualisierung des zeitlichen Verlaufs der Meilensteine über...

Abbildung 1.15: Phasen des Projektabschlusses

Abbildung 1.16: Analyse und Visualisierung identifizierter Risiken mit Maßna...

Abbildung 1.17: Vertragsarten in der Übersicht

Abbildung 1.18: Schablone zur Formulierung von User Stories nach Cohn (Cohn ...

Abbildung 1.19: Beispiel eines Taskboards (links) und eines Kanbanboards (re...

Abbildung 1.20: Mögliche Darstellung eines Zielindikators

Abbildung 1.21: Beispiel eines Burndown Charts

Abbildung 1.22: Beispielhafte Visualisierung des kumulativen Flusses

Kapitel 2

Abbildung 2.1: Wesentliche Bestandteile eines Vorgehensmodells

Abbildung 2.2: FELICS-Framework mit Bausteinen zur Entwicklung und Konfigura...

Abbildung 2.3: Ausprägungen von Komplexität in Projekten in Anlehnung an Boo...

Abbildung 2.4: Checkliste Phasen, Meilensteine und Aktivitäten in Vorgehensm...

Abbildung 2.5: Auszug einer Stakeholderanalyse für die Entwicklung eines Rol...

Abbildung 2.6: Exemplarisches Organigramm einer traditionellen Projektorgani...

Abbildung 2.7: Checkliste Rollen in Vorgehensmodellen

Abbildung 2.8: Kurze Eskalationen durch die Instanzen auf regelmäßiger Basis...

Abbildung 2.9: Überblick über funktionale Bausteine von Vorgehensmodellen

Abbildung 2.10: Checkliste zur Förderung der Orientierungsfunktion als funkt...

Abbildung 2.11: Symbolhafte Darstellung bekannter Vorgehensmodelle

Abbildung 2.12: Checkliste zur Förderung der Qualitätssicherung als funktion...

Abbildung 2.13: Verifizierung und Validierung zur Überprüfung einer vollstän...

Abbildung 2.14: Vorgehensmodell für die Entwicklung von Medizinprodukten für...

Abbildung 2.15: Pyramidisierung der automobilen Zulieferstruktur nach Djabar...

Abbildung 2.16: Synchronisierungsbedarf im Produktentstehungsprozess

Abbildung 2.17: Checkliste zur Förderung der Synchronisation als funktionale...

Abbildung 2.18: Checkliste zur Förderung der Kommunikation als funktionaler ...

Abbildung 2.19: Beispiel und Auszug einer tabellarischen Stakeholderanalyse...

Abbildung 2.20: Exemplarische Kommunikationsbedarfe einiger Stakeholdergrupp...

Abbildung 2.21: Beispiel eines Kommunikations-Strukturdesigns

Abbildung 2.22: Checkliste zur Förderung der Kollaboration als funktionaler ...

Abbildung 2.23: Übersicht über Möglichkeiten von Kollaborationsplattformen

Abbildung 2.24: Checkliste zur Integration der Messung von Kennzahlen als fu...

Abbildung 2.25: Checkliste zur Integration von Wissensmanagement als funktio...

Abbildung 2.26: Wissensmanagement als Bestandteil eines planbasierten Wasser...

Abbildung 2.27: Beispiel eines planbasierten Produktentstehungsprozesses als...

Abbildung 2.28: Einfaches BPMN-2.0-Modell des Prozesses zur Erstellung eines...

Abbildung 2.29: Checkliste für die Festlegung prozessualer Bausteine

Abbildung 2.30: Exemplarische SIPOC-Darstellung der Earned-Value-Analyse

Kapitel 3

Abbildung 3.1: Sequenzielle Projektbearbeitung nach dem Wasserfallmodell

Abbildung 3.2: Steckbrief des Wasserfallmodells mit Bewertung wichtiger Funk...

Abbildung 3.3: Sequenzielle Projektbearbeitung nach dem V-Modell

Abbildung 3.4: Steckbrief des V-Modells mit Bewertung wichtiger Funktionen e...

Abbildung 3.5: Nebenläufige Projektbearbeitung mit Simultaneous Engineering...

Abbildung 3.6: Steckbrief des Simultaneous Engineering mit Bewertung wichtig...

Abbildung 3.7: Wiederholende inkrementelle Projektbearbeitung

Abbildung 3.8: Das Spiralmodell als Spezialform wiederholender Vorgehensmode...

Abbildung 3.9: Steckbrief des Spiralmodells mit Bewertung wichtiger Funktion...

Abbildung 3.10: Scrum im Überblick

Abbildung 3.11: Übersicht wichtiger Artefakte in Scrum

Abbildung 3.12: Schema für die Formulierung von User Stories in Anlehnung an...

Abbildung 3.13: Sprint Backlog als Taskboard mit User Stories (links) sowie ...

Abbildung 3.14: Überblick über Scrum-Ereignisse, zuständige Rollen und Artef...

Abbildung 3.15: Ablauf eines Sprint Reviews

Abbildung 3.16: Steckbrief von Scrum mit Bewertung wichtiger Funktionen eine...

Abbildung 3.17: Beispiel eines Kanbanboards

Abbildung 3.18: Steckbrief von Kanban mit Bewertung wichtiger Funktionen ein...

Abbildung 3.19: Makrozyklus des Design Thinkings in Anlehnung an Lewrick et ...

Abbildung 3.20: Mikrozyklus des Design Thinkings in Anlehnung an Lewrick et ...

Abbildung 3.21: DevOps zur Verbindung der Entwicklung von Software (hellgrün...

Abbildung 3.22: Feedbackschleifen bei Extreme Programming und deren zeitlich...

Abbildung 3.23: Wasser-Scrum-Fall-Vorgehensmodell als sequenzielle Kombinati...

Abbildung 3.24: V-Scrum-Vorgehensmodell, bei dem Scrum zwischen den beiden Ä...

Abbildung 3.25: Gegenüberstellung einiger planbasierter und agiler Vorgehens...

Kapitel 4

Abbildung 4.1: Vorgehen bei der Auswahl und dem Tailoring von Vorgehensmodel...

Abbildung 4.2: Unterschied des Ablaufs planbasierter und agiler Vorgehensmod...

Abbildung 4.3: Die Stacey-Matrix fördert die Orientierung bei der Entscheidu...

Abbildung 4.4: Diamantmodell nach Shenhar und Dvir (Shenhar und Dvir 2007) u...

Abbildung 4.5: Cynefin-Framework nach Snowden (Snowden 2000)

Abbildung 4.6: Parameter für die Wahl zwischen planbasierten und agilen Vorg...

Abbildung 4.7: Charakterisierung von zwei Projekten anhand der Parameter zur...

Abbildung 4.8: Beispiel eines unternehmensindividuellen Entscheidungsbaums z...

Abbildung 4.9: Baukasten für die Konstruktion von Vorgehensmodellen

Abbildung 4.10: Beispielhafte Anwendung des Baukastens FELICS für die Konstr...

Abbildung 4.11: Ordnungsrahmen für hybrides Projektmanagement HyProMM (Timin...

Abbildung 4.12: Auszug aus HyProMM zur Illustration der Umsetzung mit unters...

Abbildung 4.13: Übersicht möglicher Methoden zum Einsatz in Vorgehensmodelle...

Abbildung 4.14: Gegenüberstellung der Projektphasen des Beispiels und der Pr...

Abbildung 4.15: Netzdiagramm zu Aufgabe 4.3

Kapitel 5

Abbildung 5.1: Aufbau des zusammenfassenden Steckbriefs der Praxisbeispiele...

Abbildung 5.2: Ursachenanalyse »Projektmanagement« der Helbinux GmbH mithilf...

Abbildung 5.3: Ausgefülltes Netzdiagramm als Ergebnis des Workshops zur Char...

Abbildung 5.4: Gekapseltes hybrides Vorgehensmodell: im Innenverhältnis agil...

Abbildung 5.5: Anwendung des Baukastens zur Konstruktion von Vorgehensmodell...

Abbildung 5.6: Kanbanboard für Projekte der Helbinux GmbH

Abbildung 5.7: Auszug aus der SWOT-Analyse der Stärken, Schwächen, Chancen u...

Abbildung 5.8: Möglichkeiten des Umgangs mit Engpässen bei der Hyrstöp GmbH ...

Abbildung 5.9: Kommunikationspyramide zur strukturierten und schnellen Entsc...

Abbildung 5.10: Produktentstehungsprozess der Friedrichven AG

Abbildung 5.11: Produktentstehungsprozess nach der Überarbeitung

Abbildung 5.12: Baukasten zur Konstruktion von Vorgehensmodellen für ein Ein...

Abbildung 5.13: Ermittlung der Bausteine für das neue Vorgehensmodell mithil...

Abbildung 5.14: Umfeld der Produktentwicklung des Unternehmens

Abbildung 5.15: Neuer Produktentstehungsprozess als Wasser-Scrum-Fall-Vorgeh...

Abbildung 5.16: Schnittstelle zwischen Software- und Hardwareentwicklung wäh...

Abbildung 5.17: Organisation der projektübergreifenden Softwareentwicklung a...

Abbildung 5.18: Anteil der Projektarbeit an Gesamtarbeitszeit für verschiede...

Abbildung 5.19: Kanbanboard für die Anwendung im neuen Vorgehensmodell

Kapitel 6

Abbildung 6.1: Baukasten FELICS für die Konstruktion von Vorgehensmodellen

Abbildung 6.2: Aufbau der Steckbriefe zur Beschreibung der Elemente des Bauk...

Orientierungspunkte

Cover Page

Inhaltsverzeichnis

Fangen Sie an zu lesen

Seitenliste

3

4

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

345

346

347

348

349

350

351

352

353

354

355

356

357

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

Einleitung

Über das Buch

Dieses Buch über modernes Projektmanagement liefert eine fundierte, umfassende und praxisrelevante Auseinandersetzung über Vorgehensmodelle, Werkzeuge und Rollen des Projektmanagements. Der Titel des Buchs lautet bewusst »Modernes Projektmanagement«. Es wird darum gehen, jenseits vorgefestigter Meinungen über traditionelle, planbasierte und agile Vorgehensmodelle die situativ am besten passenden Abläufe, Methoden und Rollen auszuwählen, zu kombinieren und anzuwenden. Der Schwerpunkt liegt hierbei weniger auf dem einzelnen Projekt als vielmehr in der Konstruktion und dem Tailoring von Vorgehensmodellen für bestimmte Projektarten. So sind Sie nach dem Lesen dieses Buchs in der Lage, beispielsweise ein Vorgehensmodell für technische Produktentwicklungsprojekte oder für Projekte zur Organisation von Messebeteiligungen zusammenzustellen und Ihren Bedürfnissen entsprechend anzupassen.

Unter dem Schlagwort »Agilität« gibt es derzeit viele Publikationen und Praxisbeispiele. »Agil werden« ist in aller Munde – es klingt als Gegenpol zu »träge und behäbig« gut und dynamisch. Allerdings zeigt die Praxis auch, dass nicht alles, was derzeit als agil verkauft wird, auch wirklich zu mehr Agilität führt oder im Kontext der jeweiligen Anwendung wirklich agil ist. Alsbald breitet sich Verwunderung über die vermeintlichen Heilsbringer aus, da sie nicht immer die gewünschte Wirkung entfalten.

Wir werden uns in diesem Buch mit der Frage auseinandersetzen, was Agilität bedeutet. Dabei werden wir feststellen, dass Agilität zunächst einmal eine Geisteshaltung ist. Vorgehensmodelle und Methoden können Agilität fördern, nicht aber selbst agil sein. Dennoch sprechen wir häufig verkürzt von »agilen Methoden« und werden das aufgrund der besseren Lesbarkeit auch in diesem Buch tun – wohl wissend, dass damit Methoden gemeint sind, die uns in der Anwendung agiler Werte und Prinzipien unterstützen.

Um dies zu erreichen, werden verschiedene Vorgehensmodelle des Projektmanagements mit ihren Stärken und Schwächen vorgestellt und bewertet. Anhand einer nachvollziehbaren Systematik werden Sie in die Lage versetzt, nach einem strukturierten Schema Methoden auszuwählen und das zu Ihrer Projektaufgabe passende Projektmanagement zu konfigurieren.

Meine Leser

Ich wende mich mit diesem Buch an Leser, die losgelöst von traditionellen, planbasierten oder agilen Vorfestlegungen das zu ihrer Projektaufgabe passende Projektmanagement anwenden wollen.

Das Buch soll all denen eine besondere Hilfestellung bieten, die in strukturierter Form ihr Projektmanagement auf den aktuellen Stand bringen wollen. Es wird viel Wert gelegt auf eine umfassende Erläuterung von Bausteinen, die den Aufbau und die Wirkweise von Vorgehensmodellen des Projektmanagements bestimmen. Außerdem werden wir uns mit der Frage beschäftigen, wie wir existierende Vorgehensmodelle anpassen können. Diese Anpassung ist auch unter dem Begriff Tailoring bekannt.

Die Erläuterungen erfolgen praxisnah, das heißt, nach dem Lesen des Buchs sollen Sie nicht nur Lust haben, passende Methoden auszuwählen und anzuwenden, sondern auch in der Lage sein, dies erfolgreich zu tun. Ich selbst habe viele dieser Methoden in unterschiedlichen Projekten eingesetzt – angefangen von typischen technischen Entwicklungsprojekten in der Industrie über Projekte im öffentlichen Bereich bis hin zu Projekten von Bürgerinitiativen.

Vorwissen

Das Buch setzt Grundkenntnisse des Projektmanagements voraus. Es hilft Ihnen beim Lesen, wenn Sie Begriffe wie Terminplanung, Projektkosten, Controlling, Berichtswesen, Scrum und Kanban einordnen können. Auch wenn viele Methoden im Einzelnen vorgestellt werden, ist es leichter, deren Bewertung und Einsatzmöglichkeiten zu verstehen, wenn Sie bereits eigene Projekte als Teammitglied oder in verantwortlicher Position durchgeführt haben.

Sollten Sie einzelne Themen oder Grundlagen vertiefen wollen, lege ich Ihnen mein Buch »Modernes Projektmanagement: Mit traditionellem, agilem und hybridem Vorgehen zum Erfolg« ans Herz. Dieses Grundlagenlehrwerk schafft die entsprechenden Voraussetzungen, um in die Welt der Vorgehensmodelle einzutauchen und erfolgreiches Projektmanagement weiter zu systematisieren.

Ziel des Buchs

Die vor einigen Jahren begonnene agile Transformation hat eine Vielzahl an neuen Vorgehensmodellen und Methoden hervorgebracht. In der Praxis werden diese teilweise bunt gemischt. Aber wie beim Kochen gilt auch hier: Ein gutes Ergebnis wird erzielt, wenn man die richtigen Gewürze kombiniert und nicht unreflektiert einfach viele, nicht harmonierende Gewürze mischt.

Nach dem Lesen des Buchs …

verstehen Sie viele unterschiedliche traditionelle, planbasierte und agile Methoden des Projektmanagements

können Sie diese Methoden anhand Ihrer individuellen Anforderungen bewerten, auswählen und kombinieren

sind Sie in der Lage, ein vollständiges und stimmiges Vorgehensmodell für das zu Ihrer Projektaufgabe passende Projektmanagement zu konfigurieren

Was bedeutet was

Die Symbole und Markierungen des Buchs sind weitestgehend selbsterklärend. Wichtige Begriffe, die Sie beim schnellen Lesen nicht übersehen sollten, werden fett gedruckt. Kursivdruck dient der Hervorhebung im Zusammenhang eines Satzes oder eines Abschnitts.

Zur Erleichterung der Orientierung werden Symbole und spezielle Darstellungen genutzt:

Definitionendienen dem Erwerb einer einheitlichen Sprache, um mit anderen Personen im Projekt unmissverständlich und professionell kommunizieren zu können. Definitionen sind kursiv, der zu definierende Begriff ist zusätzlich fett gedruckt. Alle Definitionen befinden sich zusätzlich im Glossar des Buchs.

Tipp

Tipps werden in diesem Buch wie dieses Beispiel dargestellt. Ähnliche Darstellungen gibt es für Warnungen und zur Hervorhebung von Stellen, an denen Vorsicht geboten ist.

In jedem Kapitel finden Sie Übungen, Praxisbeispiele oder Fallstudien, die die Anwendbarkeit des neu Erlernten fördern. Beispiele innerhalb eines Kapitels werden wie folgt markiert:

Beispiel

Beispiele für Projekte sind die Organisation einer Urlaubsreise oder Betriebsfeier, die Verbesserung von Unternehmensabläufen, der Bau von Gebäuden sowie die Entwicklung neuer Produkte oder Dienstleistungen.

Wo immer es möglich und sinnvoll ist, werden im Buch deutsche Begriffe für Sachverhalte, Methoden und Abläufe verwendet. Gerade im agilen Management haben sich aber viele Begriffe aus dem Englischen etabliert. Es würde gekünstelt wirken und Ihnen das Verständnis erschweren, wenn in diesem Buch wenig gebräuchliche oder neue deutsche Begriffe dafür eingeführt würden, die in anderen Werken unüblich sind. Alle besonders wichtigen Begriffe finden Sie gesammelt als Glossar in Kapitel 7.

Zur besseren Orientierung im Buch werden Farbcodes verwendet, die Ihnen signalisieren, ob eine Methode eher planbasierten, traditionellen oder agilen Ursprungs ist. Methoden, die sich sowohl in planbasierten als auch in agilen Projekten einsetzen lassen, werden als hybride Methoden bezeichnet und ebenfalls farblich markiert. Die verwendeten Farbcodes können Abbildung 0.1 entnommen werden. Überall dort, wo eine eindeutige Zuordnung nicht möglich ist oder der allgemeingültige Charakter eines Vorgehensmodells oder einer Methode betont werden soll, wird der blaue Farbton verwendet. Dies gilt auch für alle Kapitelmarkierungen sowie die Hervorhebungen bei Tipps, Warnungen und Beispielen.

Abbildung 0.1: Farbcodes für unterschiedliche Themen und Kapitel dieses Buchs

Ein abschließender Hinweis: Sie finden im Buch viele Praxisbeispiele und Fallstudien, die auf Erfahrungen des Autors beruhen. Zur besseren Lesbarkeit werden Personen und Unternehmen teilweise mit konkreten, aber rein fiktiven Namen versehen. Sollten sich Übereinstimmungen mit realen Personen oder Unternehmen finden, so sind diese rein zufällig und nicht gewollt.

Außerdem wird zum Erhalt der Lesbarkeit darauf verzichtet, stets alle Geschlechterrollen zu verwenden. Stattdessen werden in willkürlicher Verteilung unterschiedliche Rollen verwendet und betont, dass die in diesem Buch verwendeten Rollen für alle Geschlechter gleichermaßen geeignet sind.

Abbildungen für Dozenten

Sollten Sie Dozent sein und die Abbildungen aus diesem Buch für Ihre Unterrichtsmaterialien nutzen wollen, registrieren Sie sich unter

https://www.wiley-vch.de/ISBN978-3-527-53053-3

1Grundlagen des Projektmanagements

In diesem Kapitel

fassen wir wichtige Grundlagen des planbasierten und agilen Projektmanagements zusammen

wiederholen wir wichtige Methoden der Definition, Planung und Steuerung von Projekten

legen wir die Grundlagen, um unterschiedliche Methoden des Projektmanagements später vergleichen und bewerten zu können

Übersicht

Grundlegende Begriffe

Wir wollen in diesem Kapitel den Grundstein für modernes Projektmanagement legen, indem wir verbreitete Vorgehensmodelle betrachten und ihre Stärken und Schwächen herausarbeiten. Damit wir eine unmissverständliche Sprache sprechen, definieren wir zunächst einige Begriffe:

EinProjektist ein in der Regel einmaliges und von anderen Aufgaben unterscheidbares Vorhaben mit begrenzten zeitlichen, finanziellen, personellen und sachbezogenen Ressourcen. Projekte verfolgen definierte Ziele und haben eine projektspezifische Organisation.

Beispiel

Unter diese Definition fallen ganz unterschiedliche Vorhaben, wie beispielsweise Bauvorhaben, ein privater oder geschäftlicher Umzug, eine Veranstaltung oder Feier oder die Entwicklung neuer Anlagen, Produkte oder Dienstleistungen.

Die management-, organisations- und führungsbezogenen Aufgaben zur Bearbeitung eines Projekts werden Projektmanagement genannt:

UnterProjektmanagementversteht man die Gesamtheit der Aufgaben, Methoden und Mittel aus den Bereichen Definition, Planung, Steuerung, Projektabschluss und Führung zur erfolgreichen Durchführung von Projekten.

Welche Aufgaben, Methoden und Mittel für das Projektmanagement eingesetzt werden, sollte vom jeweiligen Projekt und dessen Projektgegenstand, das heißt dem Projektergebnis, abhängen. Hier beginnt genau die Kunst des Projektmanagements: Gute Projektmanager können nicht nur Methoden des Projektmanagements anwenden, sondern zuvor auch die richtigen Methoden auswählen und verschiedene Methoden zu einem vernünftigen und in sich stimmigen Gesamtvorgehen zur Lösung der Projektaufgabe kombinieren.

Vorgehensmodelle

Vorgehensmodelle stellen einen roten Faden für die Aufgaben, Methoden und Mittel des Projektmanagements dar. Sie sind wie ein Kochrezept, an dessen Ende ein gutes Ergebnis steht.

EinVorgehensmodellfasst Methoden und Elemente, Prozesse und Phasen eines standardisierten Projektablaufs zusammen.

Viele Vorgehensmodelle wurden in der Mitte des 20. Jahrhunderts entwickelt, als in der Luft- und Raumfahrt anspruchsvolle Projekte mit hohem Risikopotenzial durchgeführt wurden. Die Vorgehensmodelle sollten sicherstellen, dass das Projektergebnis den geforderten Qualitätskriterien entspricht und niemand zu Schaden kommt. Hierfür nutzen die Vorgehensmodelle viele aufeinander abgestimmte Pläne. Bekannte Vertreter damals entwickelter Vorgehensmodelle sind das Wasserfallmodell (Royce 1970) und das V-Modell (Boehm 1979). Diese und weitere werden wir später im Detail analysieren.

Gegen Ende des 20. Jahrhunderts wurde in immer mehr Produkte Software integriert beziehungsweise Software als eigenständiges Produkt sehr verbreitet. Viele Entwickler empfanden die bis dato bekannten Vorgehensmodelle als zu starr. Sie galten als wenig geeignet, um mit der neuen durch Software ermöglichten Dynamik der schnellen Umsetzung von Ideen klarzukommen. In der Folge entstanden neue Vorgehensmodelle, die auf besonderen Werten und Prinzipien beruhen und die wir heute agile Vorgehensmodelle nennen. Die bekanntesten Vertreter sind Scrum (Sutherland et al. 1997) und Kanban (Anderson 2010).

Wir wollen uns in diesem Buch sowohl mit planbasierten als auch mit agilen Vorgehensmodellen beschäftigen und diese Vorgehensmodelle sogar zu einer dritten Art, den hybriden Vorgehensmodellen kombinieren. Da Wasserfall- und V-Modell schon etwas älter sind, spricht man heute vielfach von traditionellen oder auch klassischen Vorgehensmodellen des Projektmanagements. Gemein ist diesen Vorgehensmodellen, dass sie versuchen, die Zukunft des Projekts durch Pläne abzubilden und diese Pläne anschließend abzuarbeiten. Deshalb werden diese Vorgehensmodelle auch planbasierte Vorgehensmodelle genannt. Im weiteren Verlauf dieses Buchs wird hauptsächlich dieser Begriff verwendet, da traditionell manchmal mit veraltet gleichgesetzt wird. Sie werden aber noch sehen, dass auch modernes Projektmanagement in bestimmten Situationen auf Pläne setzt.

Planbasiertes, agiles und hybrides Projektmanagement

Die im vorigen Abschnitt neu gelernten Begriffe fassen wir hier nun kurz zusammen:

Unterplanbasiertem Projektmanagementversteht man einen planbasierten Projektablauf. Zu Beginn werden umfangs-, zeit- und kostenbezogene Ziele definiert und Pläne zu deren Erreichung aufgestellt. Während der Steuerungsphase werden die Pläne umgesetzt und Planabweichungen minimiert.

Agiles Projektmanagementist ein Überbegriff für Projektmanagementkonzepte, die auf die agilen Werte und Prinzipien des Agilen Manifests bauen. Agiles Projektmanagement ist gekennzeichnet durch flexibles, iteratives, kundenorientiertes und unbürokratisches Vorgehen.

Alshybrides Projektmanagementwird die Nutzung von Methoden, Rollen, Prozessen und Phasen unterschiedlicher Standards oder Vorgehensmodelle bezeichnet.

Untermodernem Projektmanagementwollen wir in diesem Buch situativ angemessenes Projektmanagement verstehen, das eine effiziente und effektive Projektdurchführung ermöglicht. Es kann sowohl planbasierte als auch agile Komponenten beinhalten.

Modernes Projektmanagement denkt nicht in planbasierten, agilen oder hybriden Kategorien. Stattdessen werden die zu einem Projektumfeld, einer Projektaufgabe und einer Projektsituation passenden Komponenten des Projektmanagements eingesetzt. Dies können je nach Projekt rein planbasierte, rein agile oder hybride, das heißt gemischte, Komponenten sein.

Eine schöne, wenn auch vereinfachende Darstellung der Unterschiede zwischen planbasiertem und agilem Projektmanagements liefert (Wysocki 2014), siehe Abbildung 1.1.

Abbildung 1.1: Schematischer Ablauf planbasierter und agiler Projekte in Anlehnung an (Wysocki 2014)

Bei planbasiertem Projektmanagement laufen die einzelnen Phasen sequenziell ab. Das Projekt wird bis zum Ende geplant. Eine iterative Bearbeitung des Projektgegenstands erstreckt sich meist nur auf eine iterativ durchgeführte Umsetzung in der Steuerungsphase auf Basis zuvor erstellter Projektpläne. Beim agilen Projektmanagement wird nach der Projektinitialisierung und Definition der Projektziele ein Plan für die iterative Umsetzung erstellt. Im Detail geplant wird immer nur die jeweils folgende Iteration. Die Umsetzung erfolgt in der Steuerungsphase. An deren Ende wird geprüft, ob weitere Iterationen notwendig sind. Diese werden dann schrittweise geplant und umgesetzt. Das heißt, das iterative Vorgehen erstreckt sich nicht nur auf die Umsetzung in der Steuerungsphase, sondern auch auf die Planung. Dies wiederholt sich so lange, bis das Projekt abgeschlossen werden kann. In Extremfällen ist sogar eine iterative Anpassung der Projektziele in der Definitionsphase möglich (grau gezeichneter Pfeil in Abbildung 1.1).

Diese Darstellung ist stark vereinfachend. Erfahrene Projektmanager werden sich auch beim planbasierten Projektmanagement die Freiheit nehmen, weit in der Zukunft liegende und unklare Projektphasen nur ansatzweise beziehungsweise nur grob zu planen und diese Pläne dann iterativ zu verfeinern. Umgekehrt erfordert die Praxis häufig auch in agilen Projekten die Erstellung von Plänen über die unmittelbar anstehende folgende Iteration hinaus. Dennoch zeichnet Abbildung 1.1 eine insgesamt treffende Sicht auf Unterschiede planbasierten und agilen Projektmanagements. Auf Basis dieser Abbildung können wir schon jetzt den Kern modernen Projektmanagements erkennen:

Planbasiertes Projektmanagement setzt voraus, dass die Zukunft des Projekts planbar ist, das heißt, dass die Anforderungen an den Projektgegenstand hinreichend definiert und die Bearbeitung der Anforderungen bekannt ist. Umgekehrt bedeutet dies: Sind Anforderungen unklar oder deren Bearbeitung nicht bekannt, bietet sich agiles Projektmanagement an. Die Kriterien zur Auswahl planbasierten oder agilen Vorgehens vertiefen wir später in diesem Buch.

Um die Unterschiede der beiden Vorgehensmodelle besser zu verstehen, werden wir im Folgenden einige Grundlagen auffrischen. Erst dann kommen wir zum eigentlichen Anliegen dieses Buchs, den Bausteinen für moderne Vorgehensmodelle im Projektmanagement. Wer einen tieferen Einstieg in die Grundlagen wünscht, dem seien entsprechende Lehrbücher empfohlen (Timinger 2017).

Grundlagen planbasierten Projektmanagements

Einführung

Planbasiertes Projektmanagement zeichnet sich durch stimmige und die Projektzukunft abbildende Pläne aus. Diese werden in der Regel sequenziell, das heißt, nacheinander und aufeinander aufbauend erstellt, siehe Abbildung 1.2. Außerdem gibt es kontinuierliche Aufgaben, die sich über die gesamte Projektlaufzeit erstrecken. Hierzu gehören beispielsweise das Risiko- und Stakeholdermanagement, mit deren Hilfe Unsicherheiten in der Planung berücksichtigt werden.

Abbildung 1.2: Roter Faden des Projektmanagements als sehr einfaches Vorgehensmodell

Die Pläne in Abbildung 1.2 wurden den Projektmanagementphasen gemäß DIN 69901-2 (DIN 69901-2) Initialisierung, Definition, Planung, Steuerung und Abschluss zugeordnet. Diese Phasen werden nun kurz erläutert.

Initialisierung

In der Initialisierungsphase geht es darum, einen geordneten Projektstart zu ermöglichen. Dazu gehören

die Entscheidung, ob das anstehende Vorhaben als Projekt durchgeführt werden soll,

die Festlegung des Kernteams und

die Wahl des zum Projekt passenden Vorgehensmodells für das Projektmanagement.

In vielen Unternehmen ist es üblich, dass für den Projektstart ein Projektantrag gestellt werden muss. Wird dieser positiv beschieden, werden erste Ressourcen für die folgende Projektdefinition und Projektplanung bereitgestellt. Um ein möglichst gutes Verständnis über das anstehende Projekt zu bekommen, werden häufig Projektsteckbriefe oder der sogenannte Project Canvas genutzt. Dieser soll einen Rundumblick auf das Projekt und seine Facetten ermöglichen. Ein Beispiel eines solchen Project Canvas ist in Abbildung 1.3 dargestellt. Die Anzahl und der Inhalt der verwendeten Kategorien variieren von Unternehmen zu Unternehmen. Es sollten die Kategorien verwendet werden, die für eine fundierte Entscheidung über den Projektstart notwendig sind und die dabei helfen, das passende Vorgehensmodell für das anstehende Projekt zu wählen.

Abbildung 1.3: Beispiel eines Project Canvas

Der Project Canvas unterstützt dabei, sich nicht nur auf den Projektgegenstand zu fokussieren, sondern sich bereits vor oder zu Beginn des Projekts mit Risiken, Stakeholdern, Budgets etc. auseinanderzusetzen.

Am Ende der Initialisierungsphase …

ist das Projekt genehmigt,

sind Ressourcen und das Budget (zumindest für die nächste Projektphase) freigegeben,

sind Risiken und Stakeholder des anstehenden Projekts initial bekannt und

kann auf Basis der gesammelten Informationen das geeignete Vorgehensmodell gewählt werden.

Der letztgenannte Punkt ist ein wesentlicher Bestandteil dieses Buchs und wird in späteren Kapiteln entsprechend ausführlich behandelt.

Definition

In der Definitionsphase geht es darum, Ziele und Anforderungen an das Projekt und dessen Projektgegenstand zu definieren und die Projektorganisation mit Verantwortungen, Befugnissen und Schnittstellen nach außen festzulegen.

Ziele und Anforderungen

Die Zieldefinition erfolgt über SMART formulierte Ziele. SMART steht hierbei für spezifisch, messbar, anspruchsvoll, realistisch und terminiert. Die Ziele sollten die Eckpfeiler des magischen Dreiecks erfüllen, das heißt, leistungs-, kosten- und terminbezogene Ziele enthalten, siehe Abbildung 1.4.

Abbildung 1.4: Magisches Dreieck aus traditioneller und agiler Sicht

Die traditionelle Sicht planbasierter Projekte geht von einem festen Leistungsumfang aus. Die Aufwände, Termine, Ressourcen und Kosten werden auf Basis dieses Leistungsumfangs geschätzt und können bei Problemen variieren. Bei rein agilen Projekten werden die Kosten und Termine vorab fixiert und der Leistungsumfang durch eine konsequente Priorisierung skaliert. Die beiden Sichten sind Extremformen, von denen es in der Praxis natürlich Abweichungen gibt.

Grundsätzlich lässt sich jedoch festhalten: In planbasierten Projekten kommt der Ziel- und Anforderungsermittlung zu Projektbeginn eine zentrale Rolle zu, da diese dort fest vereinbart und dann sequenziell umgesetzt werden.

EineAnforderungist die dokumentierte Repräsentation einer

Bedingung oder Fähigkeit, die zur Lösung eines Problems oder zur Zielerreichung benötigt wird oder einer

Bedingung oder Fähigkeit eines Systems zur Erfüllung eines Vertrags, einer Norm, einer Spezifikation oder anderer Dokumente

.

Neben der SMARTen Zielformulierung sollten mögliche Zielkonflikte frühzeitig identifiziert und die Ziele und Anforderungen auf Vollständigkeit überprüft werden. Wichtig ist, Zusammenhänge zwischen Anforderungen zu kennen und Konkurrenzbeziehungen im Auge zu behalten beziehungsweise frühzeitig aufzulösen. Damit ist gemeint, vorhersehbare Probleme bei der Erfüllung konträrer Ziele oder Anforderungen mit Maßnahmen zur Beherrschung zu versehen. Dies kann durch eine frühzeitige und ehrliche Priorisierung der Anforderungen erfolgen, sodass im Konfliktfall klar ist, welche Anforderung bevorzugt umgesetzt wird. Alternativ kann der Konflikt auch ins Risikomanagement übernommen und dort entsprechend berücksichtigt werden.

Beispiel

In einem Projekt wird das Ziel ausgegeben, bis zum Beginn einer Industriemesse den Prototyp eines neuen Produkts als Ausstellungsstück fertigzustellen. Der Funktionsumfang für diesen Prototyp ist sehr groß. Um zielgerichtet arbeiten zu können, werden die Funktionen priorisiert. Die Priorisierung berücksichtigt sowohl fachlich-inhaltliche Zwänge als auch wirtschaftliche Gesichtspunkte. So müssen die implementierten Funktionen inhaltlich zusammenpassen und den Messebesuchern einen positiven Eindruck vermitteln. Gleichzeitig werden aber auch Funktionen abgegrenzt, auf die im Zweifelsfall verzichtet werden kann. Diese werden entsprechend niedriger priorisiert.

Das Beispiel illustriert etwas plakativ die Erfordernisse an den Umgang mit konkurrierenden Anforderungen (hier Leistungsumfang in Konkurrenz zu Terminen). Tatsächlich ist dies in der Praxis nicht immer leicht aufzulösen. In der Theorie ist die frühzeitige Entwicklung von Alternativszenarien, beispielsweise die Ausstellung eines Prototyps mit reduziertem Funktionsumfang, eine gute und richtige Sache. In der Praxis kann dies aber dazu führen, dass sich das Team zu früh auf das Alternativszenario einstellt und erst gar keine Bemühungen anstellt, den vollen Funktionsumfang fristgerecht zu liefern. Erfahrene Projektmanager werden das bessere Szenario ganz genau analysieren und eine geeignete Wahl treffen.

Phasenplanung

Gute Ziele und Anforderungen sind gemäß SMART-Prinzip sowohl anspruchsvoll als auch realistisch. Ob ein Projekt als erfolgreich wahrgenommen wird, hängt von der Stakeholderzufriedenheit und von der Erreichung der Projektziele ab. Bevor Ziele kommuniziert werden, sollten diese deshalb unter Vorbehalt analysiert werden. Ein erster, grober Phasenplan hilft dabei, mögliche Kosten und Termine grob mit den gesteckten Zielen abzugleichen. Erst bei erfolgreichem Abgleich sollten die Ziele dann fest vereinbart werden. Andernfalls besteht die Gefahr, dass das Team von Beginn des Projekts an durch unrealistische Zielfestlegungen demotiviert wird.

Phasenplänesind grobe Projektpläne, die das Projekt in Phasen strukturieren und für jede Phase die zu erledigenden Aufgaben, die benötigten Ressourcen und Kosten sowie die Termine grob festlegen. Die Phaseneinteilung erfolgt meist anhand eines Phasenmodells. Dessen Phasen werden als Ausgangspunkt für die Phasenplanung genutzt.

Phasenmodellesind Bestandteile eines Vorgehensmodells und strukturieren das Projekt in zeitlich voneinander abgegrenzte Phasen. Phasen können sequenziell (nacheinander), teilweise parallel, komplett parallel oder (mehrfach) wiederkehrend durchlaufen werden.

Abbildung 1.5 zeigt das Beispiel eines Phasenplans für den Bau eines Einfamilienhauses. Die Ziffern in den roten Kreisen skizzieren die Bearbeitungsreihenfolge.

Abbildung 1.5: Beispiel eines Phasen- und Meilensteinplans. Die Ziffern in den roten Kreisen beziehen sich auf die Bearbeitungsschritte bei der Erstellung eines Phasen- und Meilensteinplans und werden im Fließtext erläutert.

Zunächst wird das übergeordnete Projektziel formuliert und anschließend der Projektverlauf in Phasen gegliedert. An den Phasenübergängen werden Meilensteine formuliert. Für jede Phase werden nun die Hauptaktivitäten, wie beispielsweise »Grundstück kaufen«, ergänzt und mit ersten Kostenschätzungen und Durchlaufzeiten (Dauer) ergänzt. Die Kostenschätzungen in dieser frühen Projektphase können mit Überschlagsrechnungen, Pauschalen oder auf Basis grober Kennzahlen ermittelt werden. Die Kosten und Durchlaufzeiten je Phase werden aufsummiert und die Gesamtsumme der Kosten und Dauer ermittelt. Die Informationen über die Durchlaufzeiten können nun mit den Daten der Meilensteine abgeglichen werden. Außerdem kann überprüft werden, ob sich die grob geplanten Kosten mit den gesteckten kostenbezogenen Zielen des Projekts decken.

Weichen die gesteckten Ziele von diesem ersten groben Projektplan ab, kann im Rahmen von Optimierungsworkshops versucht werden, den Projektgegenstand günstiger oder schneller zu realisieren. Ist dies nicht möglich, muss eine Anpassung der Ziele erwogen werden.

Arten der Projektorganisation

Eine weitere wichtige Aufgabe in der Definitionsphase ist die Festlegung der Projektorganisation. Auch wenn sich diese mit fortschreitendem Projekt ändern kann, sind frühzeitige Überlegungen hierzu hilfreich.

DieProjektorganisationbesteht aus einer Gruppe von Menschen und der dazugehörigen Infrastruktur, für die Vereinbarungen bezüglich Autorität, Beziehungen und Zuständigkeiten unter Ausrichtung auf die Geschäfts- und Funktionsprozesse getroffen werden.

Wir unterscheiden zwischen projektexterner und projektinterner Organisation. Die projektexterne Organisation definiert die Schnittstellen zur Stammorganisation und zu anderen projektexternen Stakeholdern. Eine Übersicht wichtiger interner und externer Stakeholder liefert Abbildung 1.6.

Abbildung 1.6: Übersicht wichtiger Projektbeteiligter

Verbreitete Organisationsformen zur Festlegung des Zusammenwirkens von Projekten und Stammorganisation sind die autonome, die Einfluss- und die Matrix-Projektorganisation.

Die autonome (oder reine) Projektorganisation ordnet die Mitarbeiter eines Projekts fachlich und disziplinarisch dem Projektmanager zu. Konflikte zwischen Linien- und Projektmanager kommen deshalb nicht vor. Der Projektmanager hat eine starke Stellung, was gerade bei der Projektsteuerung hilfreich ist. Durch die klare Zuordnung zu einem Projekt ist die Identifikation der Mitarbeiter mit diesem in der Regel hoch, was meist motivierend und damit erfolgsfördernd ist. Allerdings ist diese Organisationsform aufwendig in ihrer Einrichtung, da formelle Vorgesetztenverhältnisse für jedes Projekt neu geordnet werden müssen. Deshalb lohnt sich diese Organisationsform nur bei großen, langfristigen Projekten. Auch die Auslastungssteuerung ist nicht einfach, da jedem Mitarbeiter sinnvolle und seiner Qualifikation entsprechende Aufgaben im Projekt zugewiesen werden müssen.

Bei der Einfluss- (oder Stab-)Projektorganisation wird der Projektmanager direkt der Unternehmens- oder Bereichsleitung unterstellt. Er hat eine Stabsstelle ohne fachlich oder disziplinarisch zugeordnete Mitarbeiter. Der Projektmanager kann das Projektteam mit Mitgliedern aus unterschiedlichen Unternehmensbereichen nur koordinieren, ohne dabei Weisungsbefugnis zu haben. Eine solche Organisationsform lässt sich einfach und schnell einrichten und ermöglicht eine gute Auslastung der Mitarbeiter über Abteilungen hinweg. Durch den Verbleib der Mitarbeiter in der Linie ist zudem der Wissensaustausch mit anderen Mitarbeitern gewährleistet.

Die Matrix-Projektorganisation versucht, die Stärken der beiden bereits genannten Formen zu vereinen. Die Mitarbeiter werden fachlich dem Projektmanager unterstellt, verbleiben aber disziplinarisch in der Linie. Dadurch können Mitarbeiter einfach mehreren Projekten oder sowohl Projekt- als auch Linienaufgaben zugeordnet werden. Die Auslastungssteuerung ist folglich gut. Durch den Verbleib in der Linienorganisation ist auch der Wissensaustausch über Projektgrenzen hinweg einfach zu organisieren. Durch die Teilung der Befugnisse und Verantwortlichkeiten zwischen Projektmanager und Linienmanager kann es zu Konflikten kommen, die unter Umständen auf dem Rücken der Mitarbeiter ausgetragen werden und zu ihrer Überlastung führen können.

Organisation von Projektrollen und Eskalation

In jedem Projekt gibt es unterschiedliche Stakeholder, die bestimmte Rollen einnehmen. Die Rollen der in Abbildung 1.6 genannten Stakeholder werden in Abbildung 1.7 näher definiert.

EineRollebeschreibt eine Position im Projekt, die mit einer bestimmten Verantwortung, mit dafür notwendigen Befugnissen und gleichzeitig mit einer Erwartungshaltung anderer Stakeholder verknüpft ist.

Eine weitere, in Abbildung 1.7 nicht genannte Rolle ist der Sponsor. Der Begriff des Projektsponsors wird in der Praxis unterschiedlich eingesetzt. Als Unterstützer fungiert der Sponsor als Pate oder Mentor und unterstützt das Projektteam bei der Beseitigung von Hindernissen. Als Geldgeber trägt er die Finanzierung des Projekts. Dann ist er der finanzielle Auftraggeber. Die inhaltlichen Anforderungen an das Projekt können ebenfalls von ihm oder einem anderen (inhaltlichen) Auftraggeber kommen.

Die projektinterne Organisation trifft Festlegungen innerhalb des Projekts. Hier können Vereinbarungen über Teilprojekte und die Verteilung von Verantwortlichkeiten und Befugnissen innerhalb des Projekts festgelegt werden.

Abbildung 1.7: Verantwortlichkeiten und Befugnis wichtiger projektbeteiligter Stakeholder

EineVerantwortungist eine mit einer bestimmten Aufgabe einhergehende Verpflichtung, dafür zu sorgen, dass das Richtige zur Erfüllung der Aufgabe oder zur Erreichung eines Ziels unternommen wird, und dafür einzustehen.

EineBefugnisist eine Berechtigung, bestimmte Handlungen durchführen und Entscheidungen treffen zu können.

Der Begriff der Kompetenz, der teilweise synonym zur Befugnis verwendet wird, wird in diesem Buch wie folgt definiert:

EineKompetenzist die nachgewiesene Fähigkeit, Wissen und Fertigkeiten situativ angemessen anzuwenden.

Verantwortlichkeiten und Befugnisse können in einem RACI- oder AKV-Diagramm strukturiert dokumentiert werden. RACI steht für Responsible, Accountable, Consulted und Informed. Dieses Diagramm legt fest, wer für die Durchführung verantwortlich ist (responsible), wer die Freigabe verantwortet beziehungsweise die Budgethoheit hat (accountable), wer fachlich beratend hinzugezogen werden muss (consulted) und wer zu informieren ist (informed). Abbildung 1.8 zeigt das Beispiel eines RACI-Diagramms.

Abbildung 1.8: Beispiel eines RACI-Diagramms

Beim AKV-Diagramm werden in vergleichbarer Weise die Aufgaben, Kompetenzen (im Sinne der oben beschriebenen Befugnis) und Verantwortlichkeiten festgelegt.

Um im Konfliktfall sachlich und lösungsorientiert handeln zu können, sollten bereits beim Aufbau der Projektorganisation Eskalationspfade entwickelt und mit dem Projektteam und anderen Instanzen abgestimmt werden.

EineEskalationist die geordnete Weiterleitung eines Sachverhalts an die nächsthöhere Hierarchiestufe, wenn dieser auf der jetzigen Hierarchiestufe nicht gelöst werden kann.

Unerfahrene Projektmanager scheuen häufig vor einer frühen Eskalation zurück und versuchen, ein Problem, das ihre Befugnisse übersteigt, doch irgendwie zu lösen. Sie haben Sorge, dass eine Eskalation als Schwäche oder Inkompetenz wahrgenommen werden kann. Deshalb und weil sich zu Projektbeginn meistens einvernehmlich und sachlich begründet festlegen lässt, wer im Konfliktfall für Entscheidungen zuständig ist, sollten bereits bei Einrichtung der Projektorganisation entsprechende Festlegungen getroffen werden.

Der Eskalationspfad sollte Projektmitarbeiter, Teilprojektmanager und den Projektmanager einschließen und kann, sollten dessen Befugnisse überschritten werden, auch projektexterne Stakeholder wie die Geschäftsleitung, den Auftraggeber oder den Lenkungsausschuss einbeziehen. Eskalationspfade können als Flussdiagramm, Tabellen oder in Textform definiert werden. Sie legen fest, an wen in welchem Fall zu eskalieren ist.

Am Ende der Definitionsphase …

sind die Projektziele SMART formuliert und mittels Phasenplan auf Machbarkeit hin untersucht,

wurden die Anforderungen an den Projektgegenstand gesammelt und analysiert und

ist die Projektorganisation definiert.

Planung

In der Planungsphase werden auf Basis der definierten Projektziele und Anforderungen Projektpläne erstellt. Dies schließt Pläne

zur inhaltlichen Bearbeitung des Projektgegenstands (was soll gemacht werden?),

zur zeitlichen Bearbeitung (wann wird was gemacht?),

zur ressourcenbezogenen Bearbeitung (wer/was wird benötigt?) und

zur kostenbezogenen Bearbeitung (was kostet das Projekt und der Projektgegenstand?)

mit ein.

Während der Definitionsphase haben wir mit dem Phasenplan einen allerersten Grobplan des Projekts erstellt. Dieser diente der Überprüfung der Projektziele auf Realisierbarkeit. Nachdem die Ziele festgelegt sind und als realistisch bewertet wurden, kann nun die Detailplanung erfolgen.

Beim planbasierten, traditionellen Projektmanagement hat diese Planung ein besonderes Gewicht: Sie soll ein Abbild der Zukunft liefern und die Zusammenarbeit aller Projektbeteiligten erleichtern. So möchte der Auftraggeber wissen, was das Projekt und der Projektgegenstand kosten wird und wann dieser verfügbar sein wird. Das Projektteam selbst muss sich bei größeren Projekten abstimmen. Es wird festgelegt, wann wer was macht, damit die einzelnen Bearbeitungsschritte ineinandergreifen und das gewünschte Gesamtergebnis liefern. Bei vielen Beteiligten, beispielsweise mehreren Fachbereichen in einer Matrix-Projektorganisation oder externen Lieferanten, ist die inhaltliche Koordination wichtig. Die Beteiligten sollten wissen, welche Teilergebnisse von einem Bearbeiter an den nächsten Bearbeiter in welchem Zustand übergeben werden. Auch die zeitliche Festlegung der Übergabe hilft den Beteiligten, sich auf den Beginn von Arbeiten vorzubereiten und dafür entsprechende Zeiten freizuhalten.

Tipp

Immer dann, wenn sich die Zukunft aufgrund vorhersehbarer Abläufe in Plänen abbilden lässt, helfen uns Pläne bei der Koordination des Projekts. Kritisch ist diese Planung bei Projekten, bei denen Ziele, Anforderungen, Ressourcen etc. einer hohen Volatilität unterliegen. Dann ist ein Plan ein eher unzuverlässiges Abbild der Zukunft. Gute Projektmanager arbeiten dann mit Grobplänen, die abschnittsweise im Detail verfeinert werden, sobald die Volatilität abgenommen hat. Sie werden später noch sehen, dass Sie damit quasi fließend vom planbasierten zum sogenannten agilen Projektmanagement übergehen.

Für die einzelnen inhalts-, termin-, ressourcen- und kostenbezogenen Pläne gibt es verschiedene Ausführungsmöglichkeiten beziehungsweise Methoden. Die von den meisten Standards empfohlene Abfolge lautet:

Projektstrukturplan

Terminplanung

zeitaufgelöster Ressourcenplan

zeitaufgelöster Kostenplan

Für die Erstellung von Termin-, Ressourcen- und Kostenplänen müssen wir die im Projektstrukturplan geplanten Inhalte hinsichtlich ihres Aufwands und ihrer Kosten schätzen. Wir beschäftigen uns nun zunächst mit allen genannten Plänen und diskutieren anschließend ein paar Aspekte zur Aufwands- und Kostenschätzung.

Grundlagen der Planung

Ein Projektstrukturplan, ein Terminplan sowie ein Ressourcen- und Kostenplan sind in Abbildung 1.9 illustriert.

DerProjektstrukturplandokumentiert die Projektstruktur mit Teilaufgaben und Arbeitspaketen als hierarchisches Diagramm oder als Tabelle oder Liste.

An der Spitze des Projektstrukturplans steht das sogenannte Wurzelelement als Ursprung (oder eben Wurzel) des Projekts. Das Wurzelelement besteht aus einer (meist unternehmensweit eindeutigen) Projektnummer und dem Projektnamen. Im Beispiel der Abbildung 1.9 ist dies »1 Projekt Renovierung«. Unter dem Wurzelelement wird der Projektstrukturplan weiter untergliedert, beispielsweise in sogenannte Teilaufgaben oder Teilprojekte, im Beispiel »1.1 Projektmanagement« und »1.2 Durchführungsphase« und auf der untersten Ebene in Arbeitspakete.

Abbildung 1.9: Aufbau und Zusammenhang von Projektstrukturplan, Terminplan sowie Ressourcen- und Kostenplan

EinArbeitspaketist eine in sich geschlossene Aufgabe, die im Projektstrukturplan nicht weiter untergliedert wird. Die Summe aller Arbeitspakete des Projektstrukturplans ergibt alles, was im Projekt erledigt werden muss. Erst im Ablauf- und Terminplan, der auf dem Projektstrukturplan aufbaut, werden Arbeitspakete bei Bedarf weiter in sogenannte Vorgänge untergliedert.

Der Projektstrukturplan listet alle geplanten Aufgaben, erlaubt aber keine Aussage über deren Bearbeitungsreihenfolge. Die Arbeitspakete werden entweder nach Phasen, nach Funktionen oder nach Objekten gegliedert. Diese Gliederungspunkte bilden die Teilaufgaben. Alle Arbeitspakete, Teilaufgaben und das Gesamtprojekt erhalten eine eindeutige fortlaufende Nummer, die sogenannte Codierung. Die Codierung hilft bei der unmissverständlichen Dokumentation von Arbeitspaketen und Teilaufgaben in Computersystemen, die für das Projektmanagement eingesetzt werden. Bei größeren Arbeitspaketen oder wenn mehrere Personen bei der Bearbeitung eines Arbeitspakets mitwirken, können die Arbeitspakete separat mit zusätzlichen Informationen beschrieben werden.

Die Vollständigkeit aller Aufgaben im Projektstrukturplan ist deshalb so wichtig, weil alle nachfolgenden Pläne aus dem Projektstrukturplan abgeleitet werden. In einem ersten Schritt werden aus Arbeitspaketen sogenannte Vorgänge und Meilensteine abgeleitet.

EinVorgangist ein Ablaufelement, das eine in sich geschlossene Aufgabe repräsentiert. Ein Arbeitspaket kann im Ablauf- und Terminplan in einen oder mehrere Vorgänge überführt werden. Während ein Arbeitspaket festlegt, was zu erledigen ist, definieren Vorgänge die (zeitlichen) Abläufe der Aufgaben.

Meilensteinesind Ereignisse von besonderer Bedeutung. Sie definieren wichtige Zeitpunkte im Projekt, an denen bestimmte Ergebnisse vorliegen müssen.

Abhängigkeiten zwischen Vorgängen können über Pfeile, sogenannte Anordnungsbeziehungen modelliert werden und die Vorgänge zeitlich sortiert werden.

Anordnungsbeziehungenverknüpfen Vorgänge und Meilensteine. Sie stellen einen quantifizierbaren sachlogischen Zusammenhang her.

Ein sachlogischer Zusammenhang zwischen zwei Vorgängen ergibt sich aus inhaltlichen Abhängigkeiten. So kann das Mauerwerk eines Hauses erst erstellt werden, wenn zuvor das Fundament gegossen wurde. Außerdem sind Anordnungsbeziehungen quantifizierbar. Damit ist gemeint, dass mit einer Anordnungsbeziehung festgelegt werden kann, ob der nachfolgende Vorgang oder Meilenstein unmittelbar oder mit quantifizierbarem zeitlichem Abstand erfolgt. Bevor beispielsweise das Mauerwerk erstellt wird, muss das frisch gegossene Fundament erst einige Tage trocknen. Diese Trocknungsdauer kann als Zeitspanne mit der Anordnungsbeziehung im Plan dokumentiert werden.

Der mittlere Teil der Abbildung 1.9 zeigt, wie aus dem Projektstrukturplan ein Terminplan in Form eines Balkenplans entstanden ist.

DerTerminplanlegt die sachlogische Reihenfolge der Aufgaben im Projekt fest und ergänzt diese durch die Berücksichtigung von realistischen Durchlauf- und Wartezeiten um konkrete Termine.

Die Codierung der Vorgänge und Meilensteine leitet sich aus dem Projektstrukturplan ab, sodass jederzeit rückverfolgbar ist, zu welchem Arbeitspaket die Vorgänge und Meilensteine gehören. So wurden aus dem Arbeitspaket »1.1.1 Renovierung planen« des Projektstrukturplans

der Meilenstein »1.1.1.1 Projekt gestartet« und

der Vorgang »1.1.1.2 Renovierung planen«

im Terminplan.

Aus dem Terminplan wird durch Ergänzung von Ressourcen und Kosten der Ressourcen- und Kostenplan, siehe Abbildung 1.9 unten. Den Vorgängen werden Ressourcen und Kosten zugeordnet und diese werden zeitlich entsprechend den Ergebnissen des Terminplans verteilt. Im vorgestellten Beispiel erfolgt die Planung auf Tagesbasis mit den Tagen Montag (Mo) bis Samstag (Sa). Diese zeitliche Untergliederung ist dem benötigten Detaillierungsgrad anzupassen. Bei einem kurzen Projekt kann die Planung auf Tagesbasis durchaus angemessen sein. Bei einem mehrjährigen Großprojekt hingegen werden derart fein untergliederte Pläne unhandlich und schwer zu aktualisieren. Stattdessen wird dann auf Wochen- oder Monatsbasis geplant.

Tipp

Die Skalierung der Zeitachse kann durchaus variieren. So können beispielsweise die unmittelbar folgenden zwei Monate eines Projekts auf Wochenbasis, die Zeit darüber hinaus dann auf Monatsbasis geplant werden.

Auch können einzelne Aktivitäten eines Projekts mit unterschiedlicher Skalierung geplant werden. So kann der Bau eines Prototyps für eine Ausstellung auf Wochenbasis geplant werden und der Tag der Ausstellung mit vielen einzelnen zu berücksichtigenden Handlungen auf Stundenbasis.

Drei Fragen sind auf jeden Fall zu klären, bevor man sich für eine bestimmte Skalierung entscheidet:

Welche Skalierung wird für die gewählte Art des Controllings und der Projektsteuerung benötigt?

Sind die verfügbaren Daten (Arbeitspakete, Aufwandsschätzungen, Informationen über verfügbares Personal etc.) für die gewählte Skalierung ausreichend bekannt?

Ist der Aufwand für die Pflege eines Plans mit der gewählten Skalierung leistbar?

Um den Zusammenhang zwischen zeitlicher Skalierung der Planung und der Projektsteuerung geht es später noch. Die in der zweiten Frage oben erwähnte Datenqualität ist essenziell: Ein Plan ist nur so gut wie die Daten, auf denen er beruht. Und die dritte Frage soll darauf aufmerksam machen, dass Pläne mit hohem Detaillierungsgrad auch aufwendig in der Pflege sein können. Übersteigt der Pflegeaufwand das tatsächlich Leistbare, arbeiten die Projektbeteiligten mit detaillierten, aber nicht gepflegten, veralteten und damit wertlosen Plänen.

Wie die Ressourcen entlang der Zeitachse verteilt werden, ist Gegenstand der Planung. So wurde im Beispiel der Abbildung 1.9 angenommen, dass für Vorgang 1.2.2 pro Zeiteinheit (= Tag) zwei Mitarbeiterstunden einzuplanen sind. Für Vorgang 1.2.3 hingegen werden von Dienstag bis Donnerstag drei Mitarbeiterstunden und am Freitag fünf Mitarbeiterstunden eingeplant.

Für jede Zeiteinheit der gewählten zeitlichen Skalierung werden die benötigten Ressourcen aufsummiert, in Kosten umgerechnet und mit weiteren Kosten, beispielsweise Sachkosten, ergänzt. Damit ergibt sich der Kostengang des Projekts. Im Beispiel von Abbildung 1.9 steht dieser in der Zeile »Kosten / Tag«. Summiert man ihn über die Zeitachse auf, ergibt sich die Kostensumme, auch integraler Kostengang genannt, die wir später für das Controlling und die Projektsteuerung noch benötigen.

Die hier vorgestellte Projektstrukturplanung, die Terminplanung mit Balkenplänen sowie die zeitaufgelöste Ressourcen- und Kostenplanung eignen sich für mittlere und große Projekte. Für kleine Projekte wird der damit einhergehende Planungsaufwand häufig als zu hoch wahrgenommen. Dennoch sollten auch in kleinen Projekten Inhalte, Termine, Ressourcen und Kosten geplant werden – nur mit anderen, einfacheren Methoden.

Statt eines Projektstrukturplans kann eine einfache Aufgabenliste verwendet werden. Für die Terminplanung reicht eventuell ein Meilensteinplan, bei dem nur die wichtigsten Termine festgelegt werden. Ressourcen und Kosten werden nicht zeitaufgelöst geplant, sondern einfach als Liste aufsummiert.

Solche Pläne sind deutlich schneller zu erstellen und zu pflegen, bieten allerdings auch weniger Controlling- und Steuerungsmöglichkeiten. Diese sind bei kleineren Projekten aber auch nicht immer erforderlich.

Aufwands- und Kostenschätzung

Bei der Ermittlung und Planung von Inhalten, Aufwänden, Terminen, Ressourcen und Kosten helfen Methoden und ein Grundverständnis bestimmter Zusammenhänge. Dies soll hier zur Auffrischung von Grundlagen kurz umrissen werden.

Die Inhalte und Aufgaben eines Projekts ergeben sich meist aus Überlegungen, wie die vom Auftraggeber gesteckten Anforderungen umgesetzt werden sollen. Dennoch werden immer wieder Aufgaben vergessen, beispielsweise weil die Anforderungen unvollständig sind oder begleitende Aktivitäten, wie die Qualitätssicherung, das Stakeholdermanagement oder das Berichtswesen unberücksichtigt bleiben. Deshalb empfiehlt es sich, zu Beginn des Projekts mithilfe des folgenden Vorgehens einen möglichst umfassenden Überblick über die anstehenden Inhalte und Aufgaben zu skizzieren:

Prüfung, ob die identifizierten Anforderungen vollständig und konsistent sind und vom Projektteam verstanden werden

Sichtung des vorgegebenen Vorgehensmodells, beispielsweise des unternehmensindividuellen Produktentstehungsprozesses, und Identifikation der Aufgaben, die dieser vorschreibt

Einbeziehung von Experten, die bewerten können, ob für die Erledigung von Aufgaben bestimmte Rahmenbedingungen einzuhalten sind, wie beispielsweise Richtlinien, Normen und Standards

Überprüfung des Stakeholdermanagementplans und der Risikoanalyse hinsichtlich daraus abzuleitender Maßnahmen zur Erledigung

Berücksichtigung von Erfahrungen aus früheren, vergleichbaren Projekten

Tipp

Beim planbasierten Projektmanagement ist eine vollständige Inhalts- und Aufgabenplanung essenziell für den Projekterfolg. Alle Pläne bauen darauf auf.

Beim agilen Projektmanagement gibt es diesen Vollständigkeitsanspruch der Inhalts- und Aufgabenplanung nicht. Dennoch gilt auch dort: Wenn Aufgaben früh vorhersehbar sind, sollten sie auch früh erfasst werden. Dies erleichtert die Koordination der Aufgaben und die Schaffung von Freiräumen zur Erledigung.

Erfahrene Projektbeteiligte können unterscheiden zwischen vorhersehbaren und planbaren Inhalten und Aufgaben und Situationen, in denen Inhalte und Aufgaben noch nicht absehbar oder ausreichend klar umrissen sind. Dann ist die Planung schwierig und es sollten alternative Methoden gewählt werden. Hierzu können Workshops zur Auftragsklärung und Anforderungsdetaillierung gehören oder agile Ansätze des iterativen Arbeitens.

Sind die Inhalte und Aufgaben identifiziert, müssen die zugehörigen Aufwände und Kosten zur Bearbeitung ermittelt werden. Da bei Projekten viele Aufgaben neuartig oder einmalig sind, kann hierbei nicht immer auf bekannte Daten zurückgegriffen werden. Typische Methoden der Aufwands- und Kostenschätzung sind:

Bei der

Expertenschätzung

werden ein oder mehrere Experten befragt. Je nach Anzahl involvierter Experten sind die Ergebnisse mehr oder weniger subjektiv. Auch hängt das Ergebnis stark davon ab, ob jemand wirklich Experte auf dem Gebiet ist. Spezielle Formen der Expertenbefragung sind die Einzel- und Mehrfachfachschätzung, die (Breitband-)Delphi-Methode und die Schätzklausur.

Voraussetzung für die

Analogieschätzung

ist, dass vergleichbare Aufgaben bereits in früheren Projekten geleistet wurden und die realen Aufwände und Kosten erfasst und dokumentiert wurden. Dann werden die Erfahrungswerte auf die aktuelle Schätzaufgabe übertragen.

Bei der

Dreipunktschätzung

(auch Bereichsschätzung oder PERT-Schätzung von

P

rogram

E

valuation and

R

eview

T

echnique) werden statt eines Schätzwerts gleich mehrere ermittelt: ein pessimistischer, ein realistischer und ein optimistischer. Daraus lassen sich Aussagen zum Risikograd der Aufgabe ableiten.

Die

parametergestützte Schätzung

eignet sich nur für Aufgaben, bei denen sich der Aufwand über eine Gleichung berechnen lässt. Solche Gleichungen werden häufig auf Basis empirischer Daten ermittelt und dann angewandt. Ein bekannter Vertreter ist das COCOMO-II(

Co

nstructive

Co

st

Mo

del)-Verfahren.

Das

Funktionspunktverfahren (Function-Point-Schätzung)

findet in der Softwareentwicklung Anwendung und ist in einer eigenen Norm beschrieben (ISO/IEC 20926

2009

). Es kombiniert Schätzungen, parametergestützte Berechnungen und Erfahrungen der Vergangenheit.

Es ging bereits kurz um die Abhängigkeit der Qualität der Pläne von den zugrunde liegenden Daten. Hierzu ein paar weitere Überlegungen anhand von Abbildung 1.10. Betrachten wir drei Fälle:

Fall 1: Exakte Schätzung: Der geschätzte Aufwand entspricht genau dem tatsächlichen, später ermittelten Aufwand. In diesem Fall existiert keine Fehlschätzung und es entsteht kein Mehraufwand für das Projekt. Dies ist der Idealfall.

Fall 2: Überschätzung: Der geschätzte Aufwand ist größer als der tatsächlich benötigte Aufwand. Etwas naiv könnte man annehmen, dass dann die Aufgaben einfach früher oder günstiger erledigt werden. In der Praxis schlagen in diesem Fall aber das Studentensyndrom beziehungsweise das Parkinson’sche Gesetz zu:

Das

Studentensyndrom

besagt, dass Arbeit immer möglichst spät erledigt wird. Tatsächlich haben die meisten Mitarbeiter (bei Weitem nicht nur Studierende) einen vollen Schreibtisch. Sobald sich herauskristallisiert, dass mehr Zeit als geplant zur Verfügung steht, wird die Aufgabe zeitlich zurückgestellt und dringendere Aufgaben erledigt. Im besten Fall wird die Aufgabe dann gerade noch fristgerecht abgegeben. Häufig kommt dann kurz vor Schluss aber noch etwas dazwischen, sodass eine fristgerechte Fertigstellung nicht mehr möglich ist. Obwohl bei frühzeitigem Beginn der Bearbeitung eigentlich genug Zeit gewesen wäre, droht Verzug.

Abbildung 1.10: Wird der tatsächliche Aufwand einer zu verrichtenden Arbeit unterschätzt beziehungsweise überschätzt, entsteht zusätzlicher Aufwand, der den Gesamtaufwand des Projekts erhöht (McConnell 2006).

Gemäß dem

Parkinson’schen Gesetz

(nach C. Northcote Parkinson) dehnt sich Arbeit genau in dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht. Das Mehr an Zeit wird genutzt, um eine besonders schöne (und teure) Lösung zu erarbeiten oder andere Aufgaben an die eigentlich zu erledigende Aufgabe anzuhängen. Auch hier gilt, dass dadurch trotz genügend Zeit Verzug droht. Die überschüssige Zeit wird nicht zur Risikoreduzierung oder Vorarbeit eingesetzt, sondern anderweitig genutzt. In

Abbildung 1.10

ist dieser Bereich rechts der vertikalen Achse illustriert. Das Parkinson’sche Gesetz begründet den skizzierten linearen Zusammenhang zwischen Grad der Überschätzung und Mehraufwand.

Fall 3: Unterschätzung: Der geschätzte Aufwand ist kleiner als der tatsächlich benötigte Aufwand. Stellen Sie sich vor, Sie haben die Fertigstellung einer Aufgabe zu einem bestimmten Termin zugesagt. Während der Bearbeitung bemerken Sie, dass Sie den Termin nicht halten können. Typischerweise nimmt der Projektmanager oder Auftraggeber dies nicht schulterzuckend zur Kenntnis, sondern beruft Krisensitzungen ein, fordert engmaschige Projektberichte oder initiiert Workshops zur Projektbeschleunigung. Diese Maßnahmen kosten Zeit (und Geld) und begründen den überproportionalen Anstieg des Zusatzaufwands gegenüber dem Grad der Unterschätzung.

Die Lösung für das in Abbildung 1.10 illustrierte Phänomen ist (theoretisch) denkbar einfach: Aufwände und Kosten sollten möglichst genau geschätzt werden, um Mehraufwand, der allein durch die Fehlschätzung entsteht, zu reduzieren. Nehmen Sie also das Thema Aufwands- und Kostenschätzung ernst und gehen Sie dabei sorgfältig vor. Es gibt genügend Methoden für unterschiedliche Schätzsituationen, die in der Praxis allerdings auch genutzt werden müssen. Einige davon wie die Expertenschätzung, Analogieschätzung und die Dreipunktschätzung haben wir in diesem Kapitel wiederholt. Eine ausführlichere Erläuterung dieser und weiterer Verfahren finden Sie beispielsweise in (Timinger 2017).

Vorsicht

Aus den vorgenannten Überlegungen lässt sich noch etwas anderes ableiten: Manche Projektmanager tendieren dazu, viele Meilensteine im Projekt zu setzen. Anhand der Meilensteine soll der Projektfortschritt überwacht werden. Immer dann, wenn ein Meilenstein erreicht wird, werden weitere Aufgaben in Angriff genommen.

Meilensteine können ein Projekt aber auch ausbremsen: Nehmen wir als Beispiel den Meilenstein »Konstruktion erstellt« mit Fälligkeitsdatum Ende Juli. Wird der Meilenstein zu ambitioniert gesetzt, tritt Fall 3 – Unterschätzung ein und das Projekt leidet unter überproportionalen Zusatzaufwänden. Wird der Meilenstein zu großzügig terminiert, tritt Fall 2 – Überschätzung ein. Studentensyndrom und Parkinson’sches Gesetz schlagen zu und bremsen das Projekt aus.

Kanban als populäres agiles Vorgehensmodell verzichtet bewusst auf Meilensteine und betont den Fluss der Arbeit durch das Projekt. Aber auch in planbasierten Projekten sollten wir uns der potenziell schädlichen Wirkung von Meilensteinen bewusst sein und diese mit Bedacht setzen und anwenden.

Am Ende der Planungsphase …

ist der Inhalt des Projekts bekannt,

sind Aufwände und Kosten geschätzt,

sind Termine, Ressourcen und Kosten geplant.

Steuerung

Sie wissen bereits, dass die Erarbeitung des Projektgegenstands in planbasierten, traditionellen Projekten auf Basis der erstellten Pläne erfolgt. Die Einhaltung der Pläne wird in der sogenannten Steuerungsphase überwacht. Bei Planabweichungen werden entsprechende Maßnahmen zur Planerreichung oder zur Planänderung initiiert. Damit kommt der Steuerungsphase eine zentrale Rolle bei der zielgerechten Erarbeitung des Projektgegenstands zu.

Eine umfassende Ermittlung und Analyse des Projektstatus erlaubt die Earned-Value-Analyse (auch in Deutschland ist dieser Begriff verbreiteter als der Begriff Fertigstellungswertmethode). Sie ermöglicht gleichzeitig kosten-/aufwands- und terminbezogene Aussagen zum Projektstatus. Sie erfordert dafür allerdings etwas Methodenkenntnis und entsprechende Daten über geplante und tatsächlich geleistete Aufwände. Eine einfachere, aber eben auch weniger aussagekräftige Methode ist die Meilensteintrendanalyse.

Earned-Value-Analyse

Die Bearbeitungsschritte der Earned-Value-Analyse können wie folgt zusammengefasst werden:

Ermittlung des aktuellen Fertigstellungsgrads des Projekts

Analyse des Fertigstellungsgrads

Planung, Initiierung, Umsetzung und Überwachung von Steuerungsmaßnahmen in Abhängigkeit des Analyseergebnisses

Die Ermittlung des Fertigstellungsgrads ist Grundvoraussetzung für das Verständnis des aktuellen Projektstatus. Ohne Kenntnis des aktuellen Status können keine geeigneten Steuerungsmöglichkeiten zur effizienten und effektiven Zielerreichung definiert werden. Der Fertigstellungsgrad ist das Verhältnis einer Leistung zur Gesamtleistung an einem gewählten Stichtag. Er wird üblicherweise in Prozent angegeben und mit PC (für Percentage Complete) abgekürzt.

Eine verlässliche Ermittlung des Fertigstellungsgrads ist in der Praxis nicht ganz einfach. Verbreitete Methoden mit unterschiedlichen Stärken und Schwächen sind in Abbildung 1.11 dargestellt.

Abbildung 1.11: Methoden zur Ermittlung des Fertigstellungsgrads mit Stärken (Daumen hoch) und Schwächen (Daumen nach unten)

Die einzelnen Methoden haben unterschiedliche, in der Abbildung erläuterte Stärken und Schwächen. Zunächst wird der Fertigstellungsgrad PCi für jedes Arbeitspaket i ermittelt. Anschließend werden die einzelnen Fertigstellungsgrade PCi zum Fertigstellungsgrad PC