Prozessübergreifendes Projektmanagement (eBook)

Vorwort 6
Ziele dieses Buches 6
Wer dieses Buch lesen sollte 6
Inhalte dieses Buches 7
Die Autoren 8
Konventionen in diesem Buch 9
Danksagungen 9
Inhaltsverzeichnis 10
1 Einführung in das Projektmanagement 15
1.1 Was ist ein Projekt? 15
1.2 Was ist Projektmanagement? 17
1.3 Projektmanagement in der Theorie 18
1.3.1 Die Integration von Projektmanagement in Prozessmodellen 18
1.3.1.1 Hinführung zum Thema 18
1.3.1.2 Allgemeines zu Prozessmodellen 18
1.3.1.3 Sprachliche Aspekte von Prozessmodellen 20
1.3.1.4 Integration von Projektmanagement im Rational Unified Process 20
1.3.1.5 Projektmanagement im V-Modell 24
1.3.2 Die Schnittstelle von Projektmanagement zu anderen Disziplinen im Software- Engineering 27
1.3.3 Anforderungen an einen guten Projektleiter 29
1.3.3.1 Einführung 29
1.3.3.2 „ Nichtkriterien“ für einen guten Projektleiter 30
1.3.3.3 Kriterien zur Projektleiterqualifikation 30
1.3.4 Das Mentorenprinzip 32
1.3.4.1 Ausgangssituation in den meisten Unternehmen 32
1.3.4.2 Grundgedanke des Mentorenprinzips 33
1.3.4.3 Der Stufenplan des Mentorenprinzips 34
1.3.4.4 Knowledge -Management -Systeme als Hilfsmittel 35
1.3.4.5 Negative Konsequenzen der Nichtbeachtung des Mentorenprinzips 36
1.3.4.6 Vorteile und Nachteile des Mentorenprinzips 38
1.3.5 Projektmanagement als Remote Management – mehr als nur eine Standortfrage 38
1.3.5.1 Einführung 38
1.3.5.2 Ausgangssituation für das Remote Management 39
1.3.5.3 Tücken und Chancen des Remote Managements 40
1.3.5.4 Zwischenlösung Büroservice 41
1.3.5.5 Entscheidungskriterien 43
1.3.6 Fazit 44
1.4 Projektmanagement in der Praxis 45
1.4.1 Der Spagat zwischen Theorie und Praxis 45
1.4.2 Feindbild Kunde 47
1.4.3 Feindbild interne Personalplanung 49
1.4.4 Feindbild Gewerkschaften und Betriebsräte 50
1.4.5 Feindbild Technologiewandel 51
1.4.6 Feindbild Änderungswünsche 53
1.4.7 Feindbild Toolumgebung 55
1.4.8 Der Projektabbruch als letzte Konsequenz 57
1.4.8.1 Einführung 57
1.4.8.2 Kriterien für einen Projektabbruch 57
1.4.8.3 Wer bricht ab? 59
1.4.8.4 Vorgehensweise beim Projektabbruch 60
1.4.8.5 Wenn der Kunde abbricht 61
1.4.8.6 Schlussfolgerung 62
1.4.9 Fazit 62
1.5 Unterschiedliche Projekttypen 63
1.5.1 Einführung 63
1.5.2 Klassifizierung von Projekten anhand ihrer Größe 64
1.5.3 Klassifizierung von Projekten anhand ihrer Kritikalität 64
1.5.4 Klassifizierung von Projekten anhand der Art der Abwicklung 66
1.5.5 Sonstige Klassifizierungen von Projekten 67
1.5.6 Fazit 67
1.6 Ausblick auf die weiteren Kapitel dieses Buches 68
2 Die Softwarekrise – Ursachenforschung 69
2.1 Einführung in die Problematik 69
2.2 Statistiken zur Softwarekrise 70
2.3 Warum Projekte scheitern 71
2.3.1 Allgemeines 71
2.3.2 Wann ist ein Projekt gescheitert? 72
2.3.2.1 Wann ist ein Projekt erfolgreich? 72
2.3.2.2 Wann ist ein Projekt gescheitert? 73
2.3.2.3 Früherkennung von nicht erfolgreichen Projekten 74
2.3.3 Zu hohe Erwartungen an Projekte 76
2.3.4 Unklare Anforderungen 77
2.3.5 Wechselnde Technologien 78
2.3.6 Mangelnde Kommunikation 79
2.3.7 Zu späte Integration und fehlende Werkzeugunterstützung 81
2.3.8 Zu hohe Dokumentenorientierung 83
2.3.9 Fehlende Prozessmodelle 84
2.3.10 Mangelnde Ausbildung 85
2.3.11 Fehlende Ressourcen 86
2.3.12 Fehlende Qualitätssicherung 87
2.3.13 Nachlassende Produktivität bei langjährigen Projekten 89
2.3.14 Zusammenfassung 90
2.4 Auswirkungen der Softwarekrise auf das Projektmanagement 90
2.4.1 Allgemeines 90
2.4.2 Misstrauen gegenüber Aufwandsschätzungen 91
2.4.3 Aufwändigere Vertragsgestaltungen 92
2.4.4 Immer häufigerer Einsatz von Open-Source- Produkten 93
2.4.4.1 Einführung in Open-Source-Produkte 93
2.4.4.2 Vorteile von Open-Source-Produkten 93
2.4.4.3 Nachteile von Open-Source-Produkten 94
2.4.4.4 Nutznießer von Open-Source-Produkten 96
2.4.4.5 Relativierung 97
2.4.4.6 Projektmanagement und Open-Source-Problematiken 97
2.4.5 Fazit 99
2.5 Die 80:20-Regel 100
3 Elemente und Techniken des Projektmanagements 101
3.1 Einführung in die Thematik 101
3.2 Der Projektleiter als Puffer zwischen Wunsch und Realität 101
3.3 Rollen innerhalb des Projektmanagements 104
3.3.1 Allgemeines zu Rollen 104
3.3.2 Die Erstellung von Rollenbeschreibungen 105
3.3.3 Die Rolle der Projektassistenz 106
3.3.4 Die Rolle des Teilprojektleiters 107
3.3.5 Die Rolle des Werkzeugverantwortlichen 108
3.3.6 Die Rolle des externen Coaches 110
3.3.7 Kaufmännische und technische Projektleitung 111
3.4 Das zentrale Werkzeug im Projektmanagement 112
3.4.1 Einführung 112
3.4.2 Ein paar Grundlagen von Microsoft Project 113
3.4.2.1 Einführung 113
3.4.2.2 Projektbeginn 113
3.4.2.3 Festlegung von Ressourcen 114
3.4.2.4 Festlegung und Zuordnung von Arbeitszeiten 115
3.4.2.5 Anpassung der Ansicht 116
3.4.2.6 Der Meilenstein-orientierte Ansatz 117
3.4.2.7 Integration von Sammelvorgängen 118
3.4.2.8 Zuordnung von Aktivitäten 119
3.4.3 Weitere Diagramme in MS Project 122
3.4.3.1 Das Netzplandiagramm 122
3.4.3.2 Das Diagramm Vorgang:Einsatz 124
3.4.3.3 Das Diagramm Ressource:Einsatz 124
3.4.3.4 Das Diagramm Ressource:Grafik 125
3.4.3.5 Sonstige Diagrammarten 125
3.4.4 Fazit 126
3.5 Das Projekttagebuch 126
3.6 Die Risikostrategie 127
3.6.1 Allgemeines zum Thema Risikomanagement 127
3.6.1.1 Definition 127
3.6.1.2 Rückblick auf Ihre letzten Projekte 127
3.6.1.3 Die häufigsten Risiken 128
3.6.2 Elemente des Risikomanagements 129
3.6.2.1 Einstellung zu Risiken 129
3.6.2.2 Die Risikoidentifizierung 132
3.6.2.3 Risikoklassen 134
3.6.2.4 Risikowahrscheinlichkeitsklassen 135
3.6.2.5 Die Risikomatrix 136
3.6.2.6 Fazit 138
3.7 Die Meilensteinorientierung 138
3.7.1 Allgemeines und Begriffsfindung 138
3.7.2 Unterschiedliche Meilensteine 139
3.7.3 Der LCO-Meilenstein 140
3.7.4 Der LCA-Meilenstein 140
3.7.5 Der IOC-Meilenstein 141
3.7.6 Das Produktrelease 141
3.7.6.1 Allgemeines 141
3.7.6.2 Produktrelease einer individuellen Lösung 142
3.7.6.3 Release eines Produktes, das großflächig verteilt wird 142
3.8 Die „Commitment-Orientierung“ 143
3.8.1 Problemfall Motivation 143
3.8.2 Management by Commitment 144
3.8.3 Das erforderliche Umfeld 146
3.9 Unterauftragnehmermanagement 147
3.9.1 Warum Unterauftragnehmer? 147
3.9.2 Aspekte der Auswahl und Zusammenarbeit mit einem Unterauftragnehmer 148
3.9.2.1 Ausgangssituationen 148
3.9.2.2 Vom Kunden vorgegebener Unterauftragnehmer 148
3.9.2.3 Eigener Unterauftragnehmer 149
3.9.2.4 Ausschreibung 150
3.9.3 Gefahren und Risiken der Integration von Unterauftragnehmern 152
3.9.3.1 Art der Integration des Unterauftragnehmers im Projekt 152
3.9.3.2 Body Leasing 152
3.9.3.3 Auslagerung eines Teilprojektes 153
3.9.3.4 Zulieferer 155
3.9.4 Fazit 155
3.10 Programmierrichtlinien 156
3.10.1 Hinführung zum Thema 156
3.10.2 Der MISRA-Standard 157
3.10.3 Beispiele 159
3.10.4 Die Bedeutung von Reports 160
3.10.5 Aussicht 161
3.11 Zusammenfassung 162
4 Das Berichtswesen im Projektmanagement 163
4.1 Eine Neufassung von Krieg und Frieden 163
4.2 Berichtswesen gegenüber dem Kunden 164
4.2.1 Sinn und Ziele des Berichtswesens 164
4.2.2 Projektfortschrittsberichte 166
4.2.2.1 Allgemeines zu Projektfortschrittsberichten 166
4.2.2.2 Der Aufbau eines Projektfortschrittberichtes in Formularform 166
4.2.3 Prototypen 169
4.2.4 Output von MS Project 170
4.3 Berichtswesen gegenüber dem eigenen Management 172
4.3.1 Sinn und Zweck des Berichtswesens gegenüber dem eigenen Management 172
4.3.2 Mehr als nur bunte Bilder 172
4.3.2.1 Einführung 172
4.3.2.2 Der Fokus des Managements 173
4.3.2.3 Exkurs: Der Projektleiter und sein Status als Vertriebsmitarbeiter 174
4.3.2.4 Goldene Regeln 175
4.3.2.5 Inhalte 176
4.3.3 Automatisiertes Berichtswesen im Projekt 177
4.3.3.1 Allgemeines 177
4.3.3.2 Berichte aus MS Project 178
4.3.3.3 Berichtsgeneratoren der einzelnen Werkzeuge 179
4.3.3.4 SQS Process Performance Management (PPM) 179
4.3.3.5 Business Objects Crystal Reports 180
4.3.4 Fazit 181
4.4 Mit dem Druck umgehen 181
4.4.1 Der Druck auf den Projektleiter 181
4.4.2 Den Druck nach unten weitergeben 182
4.4.3 Den Druck aus dem Projekt nehmen 183
4.4.4 Die gesunde Mischung 183
4.5 Exkurs: Abhängigkeit vom Gehaltsmodell 184
4.5.1 Einführung 184
4.5.2 Die Diskrepanz zwischen fachlicher und disziplinarischer Führung 185
4.5.3 Unterschiedliche Arten von Gehaltsmodellen und Kündigungsschutz 187
4.5.4 Unterschiedliche Arten der Mitarbeiterführung in kritischen Projekten 189
5 Notwendigkeiten größerer Projekte 191
5.1 Gute Vorbereitung ist 90% des Erfolgs 191
5.2 Planungswerkzeuge 191
5.2.1 Sicht für Sicht zum Überblick 192
5.2.1.1 Allgemeines 192
5.2.1.2 Projektumfang und Meilensteine 193
5.2.1.3 Projektstrukturplan 197
5.2.1.4 Größen-, Aufwands- und Kostenschätzungen 199
5.2.1.5 Zeit- und Ressourcenplan 203
5.2.1.6 Kostenplan 204
5.2.1.7 Q- Plan und Risikobetrachtung 205
5.2.2 Planungshorizonte 206
5.2.3 Fazit 206
5.3 Konfigurations- und Änderungsmanagement 207
5.3.1 Alles auf einen Griff verfügbar: Konfigurationsmanagement 208
5.3.2 Alles unter Kontrolle: Änderungsmanagement 209
5.3.3 Volldampf voraus: Parallele Änderungen 210
5.3.4 Tools 211
5.3.4.1 IBM Rational ClearCase 211
5.3.4.2 Telelogic Synergy (Continuus) 212
5.3.4.3 CVS 213
5.3.4.4 Weitere Tools 214
5.3.5 Fazit 214
6 Projekte als Prozess-Instanzen 215
6.1 Die Rydersoft AG 215
6.1.1 Das Unternehmen 215
6.1.2 Das Projektvorhaben 216
6.1.3 Das Projektumfeld 218
6.2 Startvorbereitungen 219
6.2.1 Allgemeines 219
6.2.2 Prozesse und Prozessmodelle 219
6.2.2.1 Übersicht 219
6.2.2.2 220
6.2.2.3 221
6.2.2.4 222
6.2.2.5 223
6.2.3 Prozess-Metamodelle 225
6.2.4 Darstellung von Prozessmodellen 228
6.2.5 Das Projektportal project> kit
6.2.5.1 Einführung 230
6.2.5.2 231
6.2.5.3 235
6.2.5.4 236
6.2.5.5 Werkzeugeinsatz bei Rydersoft 237
6.2.6 Berücksichtigung von Prozessnormen 238
6.2.7 Erstellung von Prozessmodellen 238
6.2.8 Anpassung an die Corporate Identity 242
6.3 Achtung, Fertig, Los! 242
6.3.1 Der Projektstart 242
6.3.2 Das Projekt als Prozessinstanz 243
6.3.3 Die Initialisierung der anderen Werkzeuge 245
6.3.4 Die Projektplanung 245
6.3.5 Festlegung der Meilensteine 249
6.4 Auf dem Projekt-Fairway 250
6.4.1 Hinführung 250
6.4.2 Lebende Prozessbeschreibungen 250
6.4.3 Ständiger Informationsaustausch 253
6.5 Im Projektcockpit 254
6.5.1 Einführung 254
6.5.2 Der aktuelle Projektstatus 254
6.5.2.1 Unterschiedliche Sichten 254
6.5.2.2 Der Projektstatus aus Sicht des Projektleiters 255
6.5.2.3 Der Projektstatus aus Managementsicht 256
6.5.3 Geänderte Rahmenbedingungen 257
6.5.4 Einhaltung der Prozessqualität 259
6.6 Am Ende steht der Anfang 260
6.6.1 Kontinuierliche Prozessverbesserung 261
6.6.2 Effizienzsteigerung durch Prozessorientierung 262
Literaturverzeichnis 263
Abbildungsverzeichnis 267
Akronyme 271
Numerisch 273
A 273
B 273
C 274
D 274
E 274
F 274
G 275
H 275
I 275
K 275
L 276
M 276
N 276
O 276
P 276
Q 277
R 277
S 278
T 278
U 279
V 279
W 279
X 279
Z 279
Stichwortverzeichnis 273

4 Das Berichtswesen im Projektmanagement (S.149)

Gerhard Versteegen

4.1 Eine Neufassung von Krieg und Frieden
Es gibt wohl kaum ein Thema, das ungeliebter ist als das Berichtswesen innerhalb des Projektmanagements. Sie als Projektleiter werden mit Grauen daran denken, wie Sie nun Ihrem Vorstand gegenüber verargumentieren müssen, warum sich schon wieder ein Meilenstein verschiebt, warum nun doch zusätzliche Ressourcen benötigt werden, warum auf einmal neue Hard- oder Software beschafft werden soll, warum der Kunde unzufrieden ist usw.

Aber auch das Berichtswesen gegenüber dem Kunden ist mehr oder weniger eine lästige Aufgabe – „Ich will arbeiten und nicht labern," so ein junger Projektmanager, der innerhalb einer Woche zum dritten Mal zum Kunden zitiert wurde.

Das Perverse an der ganzen Geschichte: Je kritischer ein Projekt wird (je mehr also Ihr Einsatz als Projektleiter gefordert ist), desto mehr werden Sie sich in irgendwelchen Meetings wiederfinden, sich unsinnige Ratschläge anhören müssen und mit mehr oder weniger versteckten Drohungen konfrontiert werden. Als würde der Projektdruck an sich schon nicht ausreichen – es wird noch zusätzlicher Druck auf Sie aufgebaut. Und damit Sie den Druck auch richtig genießen können, wird er gleich von zwei Seiten aufgebaut: vom Kunden und von Ihrem Management.

Daher unser Tipp: Nutzen Sie das Berichtswesen nicht nur dafür, Ihrem Management und Ihren Kunden den jeweils aktuellen Status aufzuzeigen – verwenden Sie das Berichtswesen auch dazu, um die im Kapitel zuvor behandelten Aspekte eines Projekttagebuchs zu integrieren. Bauen Sie somit haltlosen Schuldzuweisungen vor und nehmen Sie den Vorwürfen den Wind aus den Segeln. Sehen Sie also das Berichtswesen nicht als Rechtfertigung, sondern vielmehr als Absicherung!

Oder noch positiver: Sehen Sie es als Bestätigung Ihres Erfolgs! In diesem Kapitel wollen wir das Berichtswesen unter den bereits angesprochenen Gesichtspunkten – gegenüber dem Kunden einerseits und gegenüber dem eigenen Management auf der anderen Seite – darstellen. Im Anschluss gehen wir nochmals auf das Thema Mitarbeiterführung ein, hier beleuchten wir die unterschiedlichen Möglichkeiten, wie der Projektleiter mit dem kontinuierlichen Druck umgeht, der auf ihm lastet.Viel hängt dabei von der Unternehmenskultur ab; in einem kleinen Exkurs zeigen wir auf, welche Rolle dabei das Gehaltsmodell spielen kann.

4.2 Berichtswesen gegenüber dem Kunden

4.2.1 Sinn und Ziele des Berichtswesens

Bei jeder Tätigkeit, die man ausübt, fragt man sich zunächst nach dem Sinn und Zweck – so natürlich auch beim Berichtswesen. Gut, der Kunde zahlt und er will schließlich auch wissen wofür. Daher hat er einen Anspruch auf regelmäßige Projektfortschrittsberichte.

Kein Kunde wird sich damit zufrieden geben, wenn man sich nach Erhalt eines Auftrags zurückzieht und irgendwann mal mit einer fertigen Software (und einer Rechnung) erscheint. Durch das regelmäßige Berichtswesen will der Kunde sicherstellen, dass Sie mit Ihrem Projekt auch auf dem richtigen Weg sind; es dient also in einer gewissen Form auch Ihrer eigenen Sicherheit.

Sollten Sie Ihr Projekt nicht nach Festpreis, sondern nach Aufwand abwickeln (nur noch sehr wenige Projektleiter sind in dieser glücklichen Lage), ist das Berichtswesen auch als Stunden- bzw. Tagesnachweis zu werten, auf dessen Basis abgerechnet wird.