Projektmanagement - Hochschule Augsburg

Transcription

Vorlesung
Projektmanagement
Wintersemester 2012/2013
Wolfgang Kowarschick
Hochschule Augsburg
Draft (4. Oktober 2012)
2
Inhalt
1 Definitionen
1.1 Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Definition (von W. Kowarschick) . . . . . . . . .
1.1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . .
Funktionalität und Qualität sowie strategische Ziele
Zeit . . . . . . . . . . . . . . . . . . . . . . . . .
Kosten . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 Ressourcen . . . . . . . . . . . . . . . . . . . . .
1.2 Projektmanagement . . . . . . . . . . . . . . . . . . . . .
1.2.1 Definition . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Aufgaben des Projektmanagements . . . . . . . .
1.2.3 Theory of Constraints . . . . . . . . . . . . . . .
1.2.4 Zusammenfassung . . . . . . . . . . . . . . . . .
1.3 Projekterfolg . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Risikomanagement . . . . . . . . . . . . . . . . . . . . .
1.4.1 Wie vermeidet man einen Misserfolg? . . . . . . .
1.4.2 Vorgehensweise . . . . . . . . . . . . . . . . . . .
1.4.3 Typische Risiken und Vorsorgemaßnahmen . . . .
1.5 Vergleich von Projekten mittels Euro-Tagen . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Projektverlauf
2.1 Verschiedene Phasenmodelle . . . . . . . . . . . . . . . . .
2.1.1 Die Spezifikationsphase: Was soll gemacht werden?
2.1.2 Designphase (Entwurfsphase) . . . . . . . . . . . .
2.1.3 Fertigungsphase (Entwicklung) . . . . . . . . . . .
2.1.4 Einführungsphase . . . . . . . . . . . . . . . . . . .
2.1.5 Review . . . . . . . . . . . . . . . . . . . . . . . .
2.1.6 Die Nutzungs- und Aufarbeitungsphase . . . . . . .
2.2 Wasserfall- und Spiralmodell . . . . . . . . . . . . . . . . .
2.3 V-Modell XT . . . . . . . . . . . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
8
12
13
14
14
15
17
17
17
19
26
26
32
32
33
34
40
45
. . . 47
. . . 48
. . . 53
. . . 62
. . . 63
. . . 64
. . . 64
. . . 66
. . . 69
3 Schätzung
73
3.1
Die Schätzgrößen . . . . . . . . . . . . . . . . . . . . . . . . . .
73
3.2
Voraussetzunggen für gute Schätzungen . . . . . . . . . . . . . .
75
3.2.1
Divide et Impera . . . . . . . . . . . . . . . . . . . . . .
75
3.2.2
Projektphasen und -vorgänge . . . . . . . . . . . . . . . .
76
3.2.3
Akzeptierbare Abweichungen . . . . . . . . . . . . . . .
79
3.2.4
Schneller oder billiger als geplant ist erlaubt! . . . . . . .
81
Schätzungen von Phasen und Vorgängen . . . . . . . . . . . . . .
82
3.3.1
Erwartungswert und Standardabweichung . . . . . . . . .
87
3.3.2
Zentraler Grenzwertsatz der Statistik . . . . . . . . . . . .
88
3.3.3
Weitere Verteilungen für Mehrpunktschätzungen . . . . .
94
3.4
Delphi-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
3.5
Die Function-Point-Methode . . . . . . . . . . . . . . . . . . . .
98
3.6
COCOMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.3
3.6.1
3.7
Die Güte von Schätzverfahren . . . . . . . . . . . . . . . 104
Was ist ein Personenmonat? . . . . . . . . . . . . . . . . . . . . 107
4 Planung
113
4.1
Projektpläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.2
Grobplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.2.1
4.3
4.4
4.5
Projektstrukturplan . . . . . . . . . . . . . . . . . . . . . 115
Feinplanung, insb. Ressourcen-Management . . . . . . . . . . . . 117
4.3.1
Netzpläne . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.3.2
Vorwärts- und Rückwärtsrechnung . . . . . . . . . . . . . 128
4.3.3
Balkendiagramme (Gantt-Diagramme) . . . . . . . . . . 130
Feinplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.4.1
Personalplanung . . . . . . . . . . . . . . . . . . . . . . 135
4.4.2
Bedarfsplanung der Betriebsmittel . . . . . . . . . . . . . 141
4.4.3
Kapazitätsausgleich, Resource Leveling . . . . . . . . . . 143
4.4.4
Kostenplanung . . . . . . . . . . . . . . . . . . . . . . . 145
4.4.5
Kalender . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Methode der kritischen Kette . . . . . . . . . . . . . . . . . . . . 147
4.5.1
Integrierter Puffer . . . . . . . . . . . . . . . . . . . . . . 149
4
4.5.2
Die kritische Kette . . . . . . . . . . . . . . . . . . . . . 153
4.5.3
Zubringerpuffer (Feeding Buffer) . . . . . . . . . . . . . 160
4.5.4
Ressourcenpuffer . . . . . . . . . . . . . . . . . . . . . . 164
4.5.5
Kritischer Pfad und kritische Kette: Ein Vergleich . . . . . 168
4.6
Beispiele für den erfolgreichen Einsatz von CCPM . . . . . . . . 171
4.7
Multiprojektmanagement . . . . . . . . . . . . . . . . . . . . . . 171
4.8
Projektkontrolle (Controlling) . . . . . . . . . . . . . . . . . . . 171
4.8.1
Dringlichkeitslisten . . . . . . . . . . . . . . . . . . . . . 172
4.8.2
Tätigkeitsberichte . . . . . . . . . . . . . . . . . . . . . . 172
4.8.3
Zeitdiagramme . . . . . . . . . . . . . . . . . . . . . . . 173
4.8.4
Gesamtpufferverbrauch als Risikoindikator . . . . . . . . 175
4.8.5
Earned-Value-Analyse . . . . . . . . . . . . . . . . . . . 177
5 Menschenführung und Teamarbeit
181
5.1
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.2
Führungsstile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.3
Druck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
5.3.1
Folgen von übermäßigem Druck . . . . . . . . . . . . . . 188
5.3.2
Wie übt man Druck aus? . . . . . . . . . . . . . . . . . . 188
5.4
Teamarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.5
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.5.1
Wie kann man Motivation erkennen? . . . . . . . . . . . 191
5.5.2
Motivationstheorien . . . . . . . . . . . . . . . . . . . . 192
5.6
Individualpsychologischer Ansatz . . . . . . . . . . . . . . . . . 195
5.7
Die Wechselbeziehungen im Verhalten von Chef und Mitarbeiter . 197
6 Dokumentation
199
6.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
6.2
Welche Arten von Dokumentation sind brauchbar? . . . . . . . . 199
6.3
Regeln für gute Kommentare . . . . . . . . . . . . . . . . . . . . 200
5
6
Kapitel 1
Definitionen
Fremdwörterduden [2001]:
Projekt: Plan, Unternehmung, Entwurf, Vorhaben
managen: leiten, zustande bringen, geschickt bewerkstelligen, organisieren
Brockhaus [1991b]:
Projekt (lat. proiectum „das nach vorn Geworfene“):
geplante oder bereits begonnene Unternehmung, Vorhaben
Projektmanagement:
Gesamtheit der Planungs-, Leitungs- und Kontrollaktivitäten, die bei zeitlich
befristeten Vorhaben (d. h. Projekten) anfallen.
Kellner, Hedwig (Kellner [2001]):
Merkmale eines Projektes:
– es ist ein einmaliges Vorhaben
– es ist zeitlich begrenzt
– es ist ein komplexes Vorhaben
– es macht die Zusammenarbeit von Menschen aus unterschiedlichen
Fachgebieten notwendig
– es sind neuartige und unbekannte Probleme zu lösen
– es steht unter besonderem Risiko
– es hat ein eigenes Budget
– während der Projektarbeit stehen die Mitarbeiter und der Leiter unter
besonderem Druck
Projektmanagement:
alle Tätigkeiten, die das ausführende Arbeiten im Projekt erst ermöglichen
DIN 69901:
Projekt:
Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer
Gesamtheit gekennzeichnet ist, wie z. B.
– Zielvorgabe
– zeitliche, finanzielle oder andere Bedingungen
– Abgrenzung gegenüber anderen Vorhaben
7
– projektspezifische Organisation
Projektmanagement (PM):
Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für
die Abwicklung eines Projektes.
1.1 Projekte
1.1.1 Definition (von W. Kowarschick)
Ein Projekt (englisch: Project) ist ein zeitlich begrenztes, eigenständiges, komplexes und riskantes Vorhaben mit klaren Vorgaben bezüglich Funktionalität und
Qualität und mit eigenem, fast immer begrenztem Budget.
Die Realisierung eines Projektes wird von einem Auftraggeber finanziert und einem Auftragnehmer übertragen. Der Auftragnehmer nimmt dazu ein Projektteam
und (andere) geeignete Ressourcen zu Hilfe.
Das Projektergebnis wird nach erfolgreichem Projektende von Benutzern eingesetzt. Es kann überdies Auswirkungen auf weitere Personen haben: die Betroffenen.
Auftraggeber, Auftragnehmer, Projektteam und Benutzer sind die so genannten
Projektbeteiligten. Im weiteren Sinne zählen auch die Betroffenen dazu.
Beispiele für Projekte
– Asterix und Kleopatra: Bau eines Palastes für Cäsar (Goscinny und
Uderzo [1968])
– Ich baue ein Haus
– Falls erfolgreich: Folgeprojekt: Ich ziehe um
– Entwicklung eines elektronischen Aufsatzdienstes für mehrere bayerische Hochschulen
– Erstellung einer Multimediapräsentation für ein Unternehmen
Gegenbeispiele (Tagesgeschäfte)
–
–
–
–
Asterix kämpft gegen die Römer
Ich bereite das Frühstück, ich kaufe Lebensmittel ein
Elektronische Lieferung von Aufsätzen
Pressen von Multimedia-CD-ROMs
8
Anmerkungen
– Ein Projekt ist ein eigenständiges, komplexes und riskantes Vorhaben.
→ Neuartige, unbekannte Probleme sind zu lösen.
→ Verschiedene Techniken, Methoden und Spezialisten müssen eingesetzt
und koordiniert werden. Menschenführung ist diewichtigste Aufgabe
des Projektleiters.
→ Großes Risiko im Vergleich zum Tagesgeschäft.
→ Risikomanagement ist die zweitwichtigste Aufgabe des Projektleiters.
Hin und wieder wird auch die Einmaligkeit von Projekten gefordert (vgl.
Kellner [2001]), um sauber zwischen Projekt und Tagesgeschäft zu unterscheiden. Ich verzichte ganz bewusst auf diese Forderung, da ein Hausbau
oder die Realisierung eines Web-Auftrittes auch dann als Projekt angesehen
werden sollte, wenn das Unternehmen schon Dutzende von Häusern gebaut
bzw. Web-Auftritten realisiert hat. Als Auftraggeber kann ich dann allerdings viel präzisere Schätzungen hinsichtlich Zeit und Kosten einfordern.
– Ein Projekt hat klare Vorgaben bzgl. Funktionalität und Qualität.
→ Der Auftraggeber entscheidet darüber was das Projektergebnis einmal
leisten soll (Funktionalität) und welche Güte es haben soll (Qualität);
der Auftragnehmer akzeptiert oder lehnt ab.
→ Am Ende ist entscheidbar, ob die Ziele erreicht oder verfehlt wurden.
– Ein Projekt ist zeitlich begrenzt. Daraus leiten Projektleiter häufig folgende
Konsequenzen ab:
→ Der Auftraggeber legt die Dauer fest; der Auftragnehmer akzeptiert
oder lehnt ab.
→ Es gibt definierte Start-, Zwischen- und Endtermine; diese werden vom
Auftragnehmer festgelegt; Meilensteine werden mit dem Auftraggeber
abgesprochen.
Dies ist aber grundfalsch. Da ein Projekt eine riskante Unternehmung ist,
können keine genauen Termine abgegeben werden, sondern nur Zeitspannen, in denen ein Projekt voraussichtlich beendet ist. Diese Zeitspannen sind
umso größer, je weniger Erfahrung mit vergleichbaren Projekten vorliegt.
Dieser Punkt wird im Abschnitt 3.3.2 sowie im Abschnitt 1.2.3 ausführlich
diskutiert.
Besser ist daher:
→ Auftraggeber und Auftragnehmer einigen sich über einen Zeitraum oder
einen variablen Funktionskatalog. Das heißt, es gibt einen Zeitrahmen
für das erwartete Projektende oder es gibt einen festen Termin zusammen mit einem Katalog von Funktionen, die im Zweifelsfall nicht realisiert werden.
→ Es gibt für Meilensteine keine fixen Termine.
9
– Ein Projekt hat ein eigenes, (fast immer) begrenztes Budget.
→ Der Auftraggeber trägt die Kosten; Auftraggeber und Auftragsnehmer
einigen sich über einen Kostenrahmen.
→ Kosten und Nutzen müssen gegeneinander aufgewogen werden.
(Dies gilt sowohl für Auftraggeber als auch für Auftragnehmer und Benutzer – auch sollte das Projektergebnis nicht auf Kosten Unbeteiligter
gehen).
→ „Wer zahlt, schafft an.“ – Falsch!
Die Ziele müssen vorher schriftlich vereinbart werden; Änderungen an
den Zielen müssen ebenfalls schriftlich vereinbart werden. Von Anfang
an sollte bei der Finanzierung ein finanzieller Puffer für spätere Änderungswünsche eingeplant werden.
→ Für die Schätzung der Kosten gilt dieselbe Aussage wie für die Schätzung der Dauer. Je seltener ein vergleichbares Projekt durchgeführt
wurde, desto größer ist der Rahmen, in dem sich die Kosten bewegen
werden. Genauere Zahlen gibt es nur, wenn viele Vergleichsprojekte
vorliegen.
– Ein Projekt hat einen Auftraggeber und einen Auftragnehmer
→ Auftraggeber und Auftragnehmer einigen sich, unter Berücksichtigung der Wünsche der späteren Benutzer, über realistische Projektziele
(Funktionalität, Qualität, Projektdauer und Projektkosten) – Vorgaben
vom Auftraggeber; Vorschläge, Annahme oder Ablehnung durch den
Auftragnehmer.
– Ein Projekt wird von einem Projektteam realisiert.
→ Der Auftragnehmer wählt geeignete (und nicht etwa nur möglichst billige) Mitarbeiter und insbesondere einen geeigneten Projektleiter. Dieser sollte möglichst früh (in den allerersten Projektphasen) an der Projektdefinition beteiligt werden (am Besten auch an der Auswahl des
Teams).
→ Ein großes Projekt kann in mehrere Teilprojekte mit eigenen Teams
und Teilprojektleitern untergliedert werden. Einen Gesamtprojektleiter
(Projektmanager) gibt es dennoch.
10
– Ein Projekt verbraucht Ressourcen (Material, Lizenzen etc.).1
→ Der Auftragnehmer wählt geeignetes Material, Lizenzen, etc., um das
Projektziel, d. h. die Realisierung der Funktionalitäten in der geforderten Qualität unter Berücksichtigung der Zeit- und Kostenvorgaben, zu
erreichen.
→ Die Ressourcen müssen stets zur rechten Zeit in der richtigen Menge
am richtigen Ort sein.
– Das Projektergebnis wird nach Projektende von Benutzern eingesetzt.
→ Die Wünsche des Benutzers müssen bei der Projektplanung berücksichtigt werden. Ein Projektergebnis, das nicht akzeptiert wird, ist selten für
den Auftraggeber von großem Nutzen.
→ Das Projektergebnis eines erfolgreichen Projektes sollte für alle Beteiligten von Nutzen sein: Auftraggeber, Auftragnehmer und Benutzer und
es sollte Betroffenen nicht schaden.
Zitat aus InformationWeek (Neumann [1999]):
Unterschätzte Anwender: IT-Abteilungen wissen, daß die Zufriedenheit der internen Anwender und der Kunden für die Beurteilung ihrer Leistung wichtig sind; die Hersteller halten die
Meinung der User für unerheblich.
Auf S. 40 im selben Artikel bewerten 350 Anwender die Benutzerfreundlichkeit der IT-Systeme (Rang 2, Vorjahr Rang 3) und den Feedback der Anwender im eigenen Betrieb (Rang 6, Vorjahr Rang 9) als
sehr wichtige Technikaspekte.
Die Hersteller sind ganz anderer Meinung: Rang 11 und Rang 15.
– Das Projektergebnis hat Auswirkungen auf Betroffene (z. B. Anwohner an
einem neuen Flughafen).
→ Die negativen Auswirkungen auf Betroffene müssen so minimal wie
möglich gehalten werden.
→ Prozesskosten, durch Prozesse entstehende Verzögerungen, Entschädigungszahlungen etc. müssen berücksichtigt werden.
→ Projekte können an Betroffenen scheitern!
1
Von einem rein funktionalen Standpunkt aus gesehen, ist ein Mitarbeiter auch nur eine Ressource, die vom Projekt verbraucht wird (immerhin geht ein Teil seiner gesamten Lebenszeit
für das Projekt drauf). Gegenüber den Mitarbeitern sollte man zwischen Ressource und Personal allerdings tunlichst unterscheiden. Deshalb wurde zuvor der Punkt „Projektteam“ auch
separat behandelt. Beachten Sie aber, dass die nachfolgenden Aussagen eins zu eins auch für
Projektteams gelten!
11
1.1.2 Ziele
Ein Projekt verfolgt neben den vier vertraglich festgelegten Zielen Funktionalität,
Qualität, Kosten und Zeit normalerweise auch strategische Ziele, wie Verbesserung des Arbeitsablaufs, Steigerung der Mitarbeitermotivation oder der Kundenzufriedenheit, mehr Marktmacht etc. Diese Ziele können allerdings häufig weder
präzise definiert werden, noch ist es am Ende möglich, definitiv zu entscheiden,
in welchem Maße sie erreicht wurden. Das wesentliche strategische Ziel dürfte jedoch immer sein, dass das Projektergebnis für alle Beteiligten in irgendeiner Form
von Nutzen ist.
Jedes Projekt basiert auf zwei Ecksäulen: Ziele (Was?) und Ressourcen (Wie?).
Die formalen Ziele legt der Auftraggeber (in Abstimmung mit den Auftragnehmer) fest und die Ressourcen der Auftragnehmer (oft macht der Auftraggeber
allerdings auch bezüglich der Ressourcen Vorgaben). Beide Vertragsparteien verfolgen i. Allg. auch noch strategische Ziele mit einem Projekt.
Projektziele
Funktionalität
Qualität
Zeit
Auftraggeber
Was?
Auftragnehmer
Wie?
Kosten
Ressourcen
strategische
Ziele
strategische
Ziele
Projekte basieren i. Allg. nicht auf dem Prinzip Hoffnung:
„Fangen wir mal an und sehen dann, ob was dabei rauskommt.“
(Ausnahme: Grundlagenforschungsprojekte)
→ Am Anfang müssen klare und erreichbare Ziele formuliert werden (Analyse,
Spezifikation, Pflichtenheft, evtl. Vorprojekte).
→ Am Ende muss entschieden werden können, inwieweit diese Ziele erreicht
wurden, d. h., inwieweit das Projekt erfolgreich war.
Die Ziele sollten einen konkreten Nutzen für alle Beteiligten mit sich bringen (das
gilt selbst für die Grundlagenforschung: das „Menschheitswissen“, das als Basis
für alle anderen Projekte dient, wird vermehrt).
12
Funktionalität und Qualität sowie strategische Ziele
Spezifikation
Was soll im Projekt erreicht werden (Funktionalität), und von welcher Güte soll
das Ergebnis sein (Qualität). Strategische Ziele werden i. Allg. in der Spezifikation
nicht formuliert.
Asterix und Kleopatra
– Funktionalität: prunkvoller Palast für Cäsar
– Qualität: rechtwinklige Stufen, Steine fallen nicht von der Decke, Türen
klemmen nicht (Gegenbeispiel: Das Haus von Numerobis)
– strategische Ziele: Nachweis, dass Ägypter nicht dekadent sind; Gewinn einer Wette
Der Auftraggeber, der Auftragnehmer und vor allem die Benutzer erwarten sich
vom Projektergebnis einen Gewinn oder anderen Nutzen:
– Kleopatra (Auftraggeber): Will Wette gewinnen.
– Numerobis (Auftragnehmer): Will mit Gold überschüttet werden und Folgeaufträge haben.
– Miraculix (Teammitglied): Will einem alten Freund helfen und bedeutende
Schriften aus der alexandrinischen Bibliothek lesen.
– Asterix, Obelix, Idefix (Teammitglieder): Wollen Miraculix helfen, wollen
außerdem Spaß (Römer verprügeln), Action und Abenteuer.
– Sekretaris, Arbeiter (Teammitglieder): Wollen Geld verdienen und – im Falle der Arbeiter (die ausdrücklich keine Sklaven sind) – möglichst wenige
Peitschenhiebe.
– Cäsar (Nutzer des Palastes): Will Wette gewinnen (und nicht etwa den Palast
nutzen!).
– Pyradonis (Betroffener – Konkurrent von Numerobis, der leer ausging): Will
das Projekt selbst durchführen oder besser noch die Hälfte des Gewinns
(Gold) ohne das Risiko zu tragen (von Krokodilen gefressen zu werden).
Man beachte: Es handelt sich durchwegs um strategische Ziele. Keiner der Beteiligten interessiert sich für das eigentliche Projektergebnis: den Palast.
Das Projektergebnis sollte die gewünschte Funktionalität (und nur diese!) in der
gewünschten Qualität aufweisen. Dies gilt sogar dann, wenn der Benutzer (wie
Cäsar) gar nicht das Projektergebnis nutzen will.
→ ständige Überwachung des Funktionsumfangs
→ geeignete Qualitätstests
13
Um wirklich von Nutzen zu sein (d. h. i. Allg. Gewinn abzuwerfen), sollte das
Projekt nicht nur funktionierende, sondern auch qualitativ hochwertige Ergebnisse
liefern. Gegenbeispiel Windows-Software: häufig viel Funktionalität in schlechter
Qualität. Gutes Marketing oder Monopol ⇒ trotzdem Gewinn.
Es gilt leider nicht „hohe Qualität ⇒ hoher Gewinn“. Oftmals wird der Gewinn mit der Verminderung der Qualität vergrößert (z. B. gibt es heute keine
DVD-/CD-ROM-Laufwerke mehr mit Staub- und Kratzschutz in Form von Cartridges Wikipedia [2006c]).
Bei der Festlegung der Ziele müssen Auftraggeber und Auftragnehmer die Wünsche der späteren Benutzer berücksichtigen. Ein Produkt, das am Benutzer vorbeientwickelt wurde, wird sicherlich kein Erfolg. Das heißt, von Anfang an sollte
der Benutzer in die Projektplanung mit einbezogen werden!
Zeit
Spezifikation: Zeitplan
Auftraggeber: möchte nur begrenzte Zeit warten
(Asterix: genau 3 Monate)
Zeitplan und zur Verfügung stehende Zeit müssen in Einklang gebracht werden:
→ eventuelle Abstriche an Funktionalität/Qualität
oder mehr Ressourcen ⇒ höhere Kosten
Reale Zeiten und Zeitplan müssen im Einklang gehalten werden:
→ ständige Überwachung des Zeitplanes
Auch geringe Zeitüberschreitungen können evtl. Katastrophen zur Folge haben,
z. B., wenn der Konkurrent schneller war oder wenn ein multimedialer Ausstellungskatalog erst nach der zugehörigen Ausstellung fertiggestellt wird oder wenn
der Projektleiter von Krokodilen gefressen wird.
Kosten
Spezifikation: Kostenschätzung
Auftraggeber: stellt i. Allg. nur begrenzte Mittel zur Verfügung
Kostenschätzung und zur Verfügung stehende Mittel müssen in Einklang gebracht
werden
→ ständige Überwachung des Budgets (Budgetüberschreitung hat evtl. Katastrophe wie z. B. Konkurs zur Folge)
14
Anmerkung
Nicht alle Auftraggeber erwarten die vollständige Erfüllung aller Projektziele. Special-Effects-Firmen (SFX-Firmen) wie z. B. Digital Domain (Titanic, 25
Mio. Dollar, Nachverhandlungen 40 Mio Dollar → 4 Mio Dollar + 31 Mitarbeiter
Verlust), müssen auf Verlangen der Hollywood Filmstudios manchmal nur entweder on time (d. h. im vorgegebenen Zeitraum) oder on budget (d. h. im Rahmen
des vorgegebenen Budgets) arbeiten, aber am Besten natürlich Beides. (QUELLE
FEHLT [????])
1.1.3 Ressourcen
Wesentlicher Projektbestandteil von Anfang an: der Ressourcenplan.
Es muss insbesondere abgeschätzt werden können, ob die Projektziele überhaupt
erreichbar sind.
Funktionalität/Qualität, Zeitplan und Kostenplan müssen mit dem Ressourcenplan
in Einklang gebracht werden.
Ressource „Mensch“:
Welche und wie viele Spezialisten werden benötigt?
Achtung: Jede Person ist für Ihr Arbeitsgebiet ein „Spezialist“, das gilt beispielsweise auch für einfache Schreibkräfte, Sklaven (Asterix) und „minderqualifizierte“ Mitarbeiter – in einem guten Team erbringt jede Person die maximale Leistung entsprechend ihren Fähigkeiten.
Ein Witz eines unbekannten Autors bringt das sehr schön zum Ausdruck:
Bei einer Firma werden fünf Kannibalen als Sekretäre angestellt.
Bei der Begrüßung der Kannibalen sagt der Chef:
„Ihr könnt jetzt hier arbeiten, verdient gutes Geld und könnt zum
Essen in unsere Kantine gehen. Also lasst die anderen Mitarbeiter
in Ruhe.“
Die Kannibalen geloben, keine Kollegen zu belästigen.
Nach vier Wochen kommt der Chef wieder und sagt: „Ihr arbeitet
sehr gut. Nur uns fehlt seit gestern eine Putzfrau, wisst Ihr was aus
der geworden ist?“
Die Kannibalen antworten alle mit nein und schwören mit der Sache
nichts zu tun haben. Als der Chef wieder weg ist, fragt der Boss
der Kannibalen: „Wer von euch Affen hat die Putzfrau gefressen?“
Meldet sich hinten der letzte ganz kleinlaut: „Ich war es.“
Sagt der Boss: „Du Idiot, wir ernähren uns seit vier Wochen von
Teamleitern, Abteilungsleitern und Projektmanagern, damit keiner
etwas merkt, und du Depp musst die Putzfrau fressen...!!!“
15
Die Mitarbeiterführung ist und bleibt die wesentliche Aufgabe eines jeden
Projektleiters/-managers.
Ressource „Hardware“:
Was für Maschinen, Geräte, Rechner, Steine (Asterix) etc. werden benötigt?
Ressource „Software“:
Was für Programme werden benötigt?
Ressource „Informationen“:
Was für Informationsquellen (Bücher, Internet, Hotline, Archive) werden benötigt?
Ressource „Infrastruktur“:
Was für Räumlichkeiten, welcher Verwaltungsapparat, welche Wartungsverträge, welche Telekommunikationsmöglichkeiten (video conferencing!) etc.
werden benötigt?
Ressource „Rechte“:
Für viele Medien (Bild, Audio, Video etc.) müssen Lizenzgebühren gezahlt,
d. h. Verwertungsrechte oder andere Rechte erworben werden.
Ressource „Vorsorge“:
Risikomanagement (Versicherungen, Wartung etc.) ist unverzichtbar, kostet
aber Geld!
Ressource „Lagerhaltung“:
Die Lagerung von Hardware kostet Platz und damit Geld. Allerdings können
Bauteile etc., die nicht rechtzeitig zur Verfügung stehen, ebenfalls Geld kosten
(Just-in-time senkt die Kosten, erhöht aber das Risiko).
Ressource „Schulung“:
Die Teammitglieder sollten optimal auf die Projekt-Anforderungen vorbereitet sein. Die Schulung von Mitarbeiter kostet zwar Zeit und Geld, allerdings
kann sich der Gesamt-Zeitgewinn, der sich durch sinnvolle Schulungen ergibt,
positiv auf die Gesamtkosten auswirken.
Ressource „Unterauftragnehmer“:
Fremdfirmen, andere Abteilungen, Consultants etc. können als externe „Unterauftragnehmer“ zur Erfüllung der Projektziele beitragen.
Ressource „Verbrauchsmaterial“
Steht benötigtes Büromaterial bereit? Gibt es eine „Kaffeekasse“ für die Verpflegung von Gästen? (Mitarbeiter verwalten ihre eigene Kaffeekasse). Und
so weiter.
Wenn irgendwelche Ressourcen zu den geplanten Kosten oder während des geplanten Zeitraums nicht zur Verfügung stehen, müssen eventuell Abstriche an den
16
formalen Zielen (Funktionalität, Qualität, Zeit und/oder Kosten) gemacht werden
(an den strategischen Zielen werden i. Allg. keine Abstriche gemacht).
Ressourcenplan und realer Ressourcenverbrauch müssen stets im Einklang gehalten werden.
Achtung: Besonders günstige Ressourcen zu beschaffen ist ein typisches Beispiel
für das Prinzip: „Wir sparen, koste es was es wolle!“ Da wird eine Maschine von
einem Lieferanten beschafft, der diese 1 000 Euro billiger verkauft als ein Konkurrent. Allerdings hätte der Konkurrent vier Wochen eher liefern können. Projektleiter übersehen gerne, dass Mitarbeiter, die wegen eines fehlenden Bauteils
vier Wochen lang nicht weiterarbeiten können, wesentlich mehr kosten als 1 000
Euro. Sehr viele Manager optimieren lokal (hier: 1 000 Euro bei einem Bauteil
gespart); sie übersehen dabei allerdings dass viele lokale Optima i. Allg. kein globales Optimum (hier: Gesamtkosten möglichst gering) zur Folge haben.
1.2 Projektmanagement
1.2.1 Definition
Unter Projektmanagement verstehe ich, ein Projekt hinsichtlich der Ecksäulen formale Ziele („Qualität und Funktionalität“, „Kosten“, „ Zeit“) und Ressourcen zu
planen, zu organisieren und zu kontrollieren, das Risiko des Scheiterns zu minimieren sowie das zugehörige Projektteam zu führen.
Zu diesem Zweck werden i. Allg. ein verantwortlicher (Gesamt-)Projektleiter und
eventuell mehrere Teilprojektleiter (d. h. Leiter von Teilprojekten) bestimmt.
1.2.2 Aufgaben des Projektmanagements
Die Aufgaben des Projektleiters sind also – neben der Menschenführung – die
Projektplanung, -organisation und -kontrolle sowie das Risikomanagement:
– Projektziele sind unter Beteiligung des (zukünftigen) Projektleiters frühzeitig zwischen Auftraggeber und Auftragnehmer abzustimmen und schriftlich
in verbindlicher Form (Vertrag) präzise festzuhalten. Änderung an den Projektzielen müssen ebenfalls stets schriftlich in verbindlicher Form festgelegt
werden.
– Der Projektleiter muss die Spezifikation durch genaue Projektpläne (Kostenpläne, Zeitpläne, Ressourcenpläne, Aufgabenaufteilung, Risikoindikatoren
etc.) absichern!
17
– Risiken sind frühzeitig zu identifizieren. Es muss Vorsorge getroffen werden,
für den Fall, dass ein Risiko, d. h. ein potentielles zukünftiges Problem zu
einem echten Problem wird (DeMarco und Lister [2003]).
Nach der Menschenführung ist die zweitwichtigste Aufgabe des Projektleiters, Vorkehrungen für rechtzeitige und richtige Reaktionen bei Planabweichungen zu treffen und bei allen Abweichungen dann auch rechtzeitig und
richtig steuernd einzugreifen (Risikomanagement).
Gäbe es mit Sicherheit keine Abweichungen, bräuchte man keinen Projektleiter, sondern nur einen Projektplaner.
– Im laufenden Projekt muss also die Einhaltung dieser Pläne fortwährend
kontrolliert werden, um frühzeitig Risiken zu erkennen, die zu echten Problemen werden:
• Werden die vereinbarten Funktionen (und nur diese!) von den Entwicklern in der vereinbarten Qualität erstellt (Qualitätstests)?
• Werden die Zeitpläne eingehalten?
Sind Zwischenergebnisse innerhalb der erwarteten Zeitfenster (Meilensteine) fertig?
• Werden die Kostenpläne eingehalten?
• Entwickelt sich der Ressourcenverbrauch wie geplant; werden die Ressourcen optimal eingesetzt?
Rechtzeitige Lieferungen der benötigten Hard- und Software, keine
Überschreitungen der gesetzten Limits, wie z. B. Rechenkontingente,
zufriedene Mitarbeiter (unzufriedene Mitarbeiter sind sehr teuer!) etc.
• Ein Projektleiter sollte sich aber hüten, alles kontrollieren zu wollen.
Es reicht, wenn er sich auf diejenigen Aspekte seines Projektes konzentriert, deren Nicht-Erfüllung eine Nicht-Erfüllung einzelner Projektziele zur Folgen haben.
Wenn beispielsweise ein so genannter nicht-kritischer Vorgang um zwei
Wochen hinter der Zeit herhinkt, das Ergebnis aber trotzdem noch immer rechtzeitig zur Verfügung stehen wird, besteht für den Projektleiter
keinerlei Handlungsbedarf!
Leider managen die meisten Manager zum größten Teil Probleme, deren Lösung für sie gar keinen Gewinn bedeutet. (90%, Quelle: irgendwo
bei Goldratt: QUELLE FEHLT [????])
Überarbeitete Manager beschäftigen sich mit Dingen, mit denen Sie sich nicht beschäftigen sollten. (DeMarco [2001], S.
71)
Laut dpa-Meldung räumt z.B. mehr als die Hälfte von 1400 Geschäftsreisenden ein, dass ein Teil ihrer Reisen verzichtbar sei (dpa [2006]).
18
– Nach Abschluss des Projektes weist der Projektleiter im Rahmen einer Projektabnahme nach, dass:
• das Produkt alle geforderten Funktionen der Spezifikation enthält
• das Produkt in der vereinbarten Qualität erstellt wurde
• das Budget innerhalb des vereinbarten Finanzierungsrahmens liegt
• die Termine innerhalb des vereinbarten Zeitfensters liegen
Der Projektleiter muss über das nötige Wissen, die nötigen Kompetenzen und die
nötigen Menschenkenntnisse verfügen, um angemessene Entscheidungen treffen
zu können.
Der Projektleiter muss allerdings nicht über so viel Fachwissen verfügen, um
selbst aktiv an der Entwicklung mitwirken zu können. Bei den allermeisten Projekten ist er bereits mit der Projekt-Leitung (d. h. Führung, Organisation, Problemlösungen etc.) zu mehr als 100% ausgelastet (siehe z. B. Hoffmeyer [2006]).
Murphys Gesetz
„Wenn etwas schiefgehen kann, dann geht es schief.“
„If there’s more than one possible outcome of a job or task, and one of those
outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.“
(Diese Aussage geht auf Edward A. Murphy, jr. zurück. Den genauen Wortlaut seiner ursprünglichen Aussage, die er nach einem missglücktem Experiment gemacht haben soll, kenne ich allerdings nicht, dazu kursieren im Netz
zu viele unbelegte Versionen.)
Anders gesagt: Alles dauert länger als geplant, kostet mehr als geplant und
leistet weniger als geplant.
Grund
meist menschliches Versagen
Deshalb
Nach Abschluss des Projektes: „Erfahrung reflektieren“, um dieselben Fehler
nicht ein zweites Mal zu machen (Fehleranalyse).
Frei nach Konfuzius: „Wer einen Fehler macht und nichts daraus lernt, macht
einen zweiten.“
1.2.3 Theory of Constraints
(vgl. Goldratt und Cox [2002], Goldratt [2003]) Die Theory of Constraints und
später das Critical-Chain-Projektmanagement wurden von Dr. Eliyahu Moshe
Goldratt (31. März 1948 – 11. Juni 2011) begründet. (Todesnachricht: Techt
[2011])
19
Welche Entscheidungen muss ein Manager treffen, und welche Entscheidungen
sind überflüssig oder gar schädlich, da sie nichts zum Erfolg des Unternehmens
oder des Projektes beitragen oder diesen sogar behindern? Goldratt geht davon
aus, dass bis zu 90 % aller Management-Entscheidungen in die zweite Kategorie
fallen.
Abbildung 1.1: Konvoi
Engpass und Puffermanagement
Um den Unterschied zwischen sinnvollen und nutzlosen oder gar fehlerhaften Entscheidungen zu veranschaulichen, schlägt Goldratt ein einfaches Gedankenexperiment vor: Die Aufgabe ist es, einen Konvoi von Fahrzeugen (oder auch eine
Gruppe von Wanderern/Schülern, die auf einem schmalen Pfad hintereinander
gehen) so schnell wie möglich vom Start (Abbildung 1.1 a) vollständig ins Ziel
(Abbildung 1.1 b) zu bringen. Dabei können sich die Fahrzeuge nicht überholen.
Wodurch ist die Fahrtdauer des Konvois begrenzt? Durch die Geschwindigkeit des
langsamsten Fahrzeugs (Abbildung 1.1 c, das langsamste Fahrzeug ist mit einem
x gekennzeichnet). Die vor diesem Fahrzeug fahrenden Fahrzeuge können beliebig schnell fahren. Das hat aber keine Auswirkung auf die Ankunft des letzten
Fahrzeugs, der entweder selbst das langsamste ist oder hinter diesem festhängt.
Wie sollte ein Manager vorgehen, um den Konvoi zu beschleunigen? Die sinnvollste Vorgehensweise wäre, zunächst das langsamste Fahrzeug (= den „Engpass“, engl. „constraint“) zu ermitteln und dann dieses Fahrzeug schneller zu machen (z.B. indem es von unnützem Ballast befreit wird oder einen stärkeren Motor
erhält). Falls der Konvoi weiter beschleunigt werden soll, wiederholt man diese
beiden Schritte einfach.
20
Der Manager kann aber auch nutzlose Entscheidungen treffen, wie z. B. die gleichzeitige Beschleunigung aller Fahrzeuge. Dies würde zwar auch das Engpass-Fahrzeug beschleunigen (was sinnvoll ist), aber eben auch alle übrigen Fahrzeuge, was
in der aktuellen Situation sinnlos ist und nur Kosten verursacht, da der Konvoi dadurch nicht schneller ans Ziel kommt.
Eine fehlerhafte Entscheidung wäre, das Engpass-Fahrzeug weiter zu verlangsamen, indem es z. B. mit noch mehr Transportgut beladen wird. Eine subtilere Fehlentscheidung wäre, einige oder gar alle anderen Fahrzeuge soweit in ihrer Leistungsfähigkeit zu beschränken (um „Kosten zu sparen“), dass sie genauso leistungsfähig sind wie das Engpass-Fahrzeug. Diese Entscheidung hätte eine deutliche Verlangsamung des Konvois zur Folge, auch wenn das auf den ersten Blick
nicht klar ist. Darauf wird im nachfolgenden Paragraphen „Management der kurzfristigen Kostensenkung“ noch genauer eingegangen.
Zunächst soll eine andere Frage diskutiert werden: Was macht man dagegen, dass
die Fahrzeuge, die sich vor dem Engpass-Fahrzeug befinden, nicht auf und davon
fahren? Laut Goldratt reicht es, wenn man das erste Fahrzeug an eine (virtuelle)
„Kette“ (engl. „chain“) legt, die mit dem Engpassfahrzeug verbunden ist (Abbildung 1.1 d). Damit erreicht man, dass sich das erste Fahrzeug und damit auch alle
anderen Fahrzeuge, die sich vor dem Engpass-Fahrzeug befinden, nicht beliebig
weit entfernen können.
Die Kette darf allerdings nicht zu kurz sein. Sonst bremst eine Störung bei einem vorausfahrenden Fahrzeug (z.B. ein Tankvorgang) auch das Engpass-Fahrzeug aus.
Nun machen wir ein zweites Gedankenexperiment (Abbildung 1.2 a): Ein Produkt
wird erstellt, indem Lieferanten „L“ die geeigneten Rohstoffe liefern und diese der
Reihe nach von verschiedenen Maschinen „Mi“ (oder auch Arbeitern) weiterverarbeitet werden (zum Beispiel am Fließband), bis das fertige Produkt vorliegt und
von Kunden „K“ gekauft werden kann.
Auch hier gibt es eine Engpass-Maschine, mit dem geringsten Durchsatz (im Diagramm ist dies die Maschine M3, die wiederum mit einem „x“ markiert wurde).
Maschinen, die in der Produktionsreihenfolge vor dieser Maschine stehen, können mehr Zwischenprodukte produzieren, die in Zwischenlagern vor der jeweils
nachfolgenden Maschine gelagert werden müssen. Genauso wie Fahrzeuge, die
vor dem Engpass-Fahrzeug fahren, beliebig großen Abstand gewinnen können,
können Maschinen, die vor der Engpass-Maschine produzieren, beliebig große
Zwischenlager erzeugen.
Im Beispiel (Abbildung 1.2 a) kann M1 nicht so viele Rohstoffe verarbeiten, wie
der Lieferant liefert. M2 arbeitet schneller als M1 und muss daher hin und wieder
Leerlaufzeiten hinnehmen. Allerdings produziert M2 deutlich mehr Zwischenprodukte, als M3 verarbeiten kann. Alle Maschinen, die in der Produktionskette nach
21
$# %& %'(& )%
& !-
-
.-
-
!"#
!"#
!"#
& !"#
+ & , + & , + & , + & , * & !"#
Abbildung 1.2: Produktion
M3 stehen, könnten mehr Zwischenprodukte verarbeiten, hängen aber hinter M3
fest, da diese Maschine nicht genug Zwischenprodukte erstellt.
Auch hier ist die beste Managementstrategie wieder: Engpass finden und beschleunigen. Außerdem sollten die Lieferanten an die Kette genommen werden.
Sie sollten stets nur so viele Rohstoffe liefern, dass das Zwischenlager vor M3
immer mit genügend vielen Zwischenprodukten gefüllt ist, d. h., dass ein kleiner
Lieferengpass oder ein kurzzeitiger Produktionsstopp an einer der Maschinen M1
oder M2 die Engpass-Maschine nicht ausbremst (Abbildung 1.2 b). Da die reine
Just-in-Time-Strategie, die hier verfolgt wird, bei Streiks oder anderen unvorhergesehenen Ereignissen zu Problemen führen kann, kann man theoretisch mit einer
zweiten Kette auch noch ein etwas größeres Rohstofflager vor Maschine M1 einrichten (Abbildung 1.2 c). Prinzipiell könnte man aber auch das Zwischenlager
vor M3 einfach entsprechend vergrößern.
22
Wenn die Managementstrategie „Engpass finden, dann Engpass beheben“ zyklisch immer und immer wieder durchgeführt wird, tritt irgendwann eine von folgenden zwei Extremsituationen ein:
1. Die Lieferanten sind der Engpass.
2. Die Kundennachfrage ist der Engpass. (Abbildung 1.2 d)
In beiden Fällen sollte – wie üblich – versucht werden, den Engpass zu beheben. Im ersten Fall braucht man neue oder weitere Lieferanten oder auch Alternativ-Rohstoffe. Im zweiten Fall muss man die Nachfrage ankurbeln. Falls dies
gelingt, ist wieder eine der Maschinen der Engpass, die dann wieder beschleunigt werden muss. Spätestens wenn es allerdings irgendwann nicht mehr gelingt,
den Engpass „Kundennachfrage“ zu beheben und der Leerlauf bei allen Maschinen immer größer wird, muss man ein neues, innovatives Produkt auf den Markt
werfen.
Das heißt, so viel ein Manager auch optimiert, nach jeder Optimierung muss ein
weiterer Optimierungsschritt folgen. Das Management kommt nie an den Punkt,
an dem es nichts mehr zu verbessern oder zu verändern/erneuern gibt.
Goldratt geht davon aus, dass auch in einem großen Maschinenpark, in dem mehrere Maschinen teilweise parallel an verschiedenen Zwischenprodukten arbeiten
(die erst später zu einem größeren Ganzen zusammengefügt werden), immer genau eine Engpass-Maschine existiert, die den Gesamtdurchsatz bestimmt. Dies ist
der Engpass, der den Durchsatz bestimmt und auf den sich der zuständige Manager konzentrieren muss.
Das Vorgehen, sich auf den Engpass zu konzentrieren und diesen mit einem
sinnvollen Puffermanagement von engpass-externen Störungen abzuschirmen, bezeichnet Goldrat als „Theory of Constraint“ (ToC, Engpasstheorie).
Im Projektmanagement identifiziert er den kritischen Pfad als Engpass. Um Zeitund Kostenprobleme in den Griff zu bekommen, schlägt er ein explizites Puffermangement vor. Einen kritischen Pfad mit explizitem Puffer bezeichnet er – in
Anlehnung an die „Pufferkette“ – als „kritische Kette“ (vgl. Goldratt [2002]).
Typische Managementfehler
Obwohl die vorgestelle Management-Strategie („immer wieder: Engpass finden
und dann diesen Engpass beheben“) zumindest im Fall des Konvois sofort einleuchtet, gibt es mehrere alternative Management-Strategien, die leider weit verbreitet sind, aber dennoch falsch.
Viele Manager haben ein Problem damit, wenn eine Ressource nicht zu 100 %
ausgelastet ist. Damit wird der Meinung dieser Manager nach Geld verschwendet.
Dies führt dann zu vollkommen falschen Management-Entscheidungen.
23
Management by Objectives
Eine mögliche Management-Strategie wäre z. B., mit jedem Fahrer des Konvois
bzw. mit jedem Arbeiter an einer Maschine Ziele zu vereinbaren („Management
by Objectives“, MbO, Management durch Zielvereinbarung): Ein Fahrer der 10 %
schneller fährt als bisher bzw. ein Arbeiter der 10 % mehr Zwischenprodukte erzeugt als bisher, erhält eine Bonuszahlung.
Dies hat folgende Effekte: Die Fahrer, die vor dem Engpass fahren, vergrößern den
Abstand zum Engpass noch schneller als bisher; die Zwischenlager vor dem Engpass wachsen noch schneller als bisher. Die Fahrer hinter dem Engpass-Fahrzeug
bzw. die Arbeiter hinter der Engpass-Maschine sind sauer auf den Engpass-Verantwortlichen, da sie durch diesen ausgebremst werden. Vielleicht wird auch der
Engpass etwas beschleunigt, so dass die Produktion tatsächlich etwas erhöht wird.
Aber zu welchem Preis?
Ich habe in meinem Bekanntenkreis einen derartigen Fall miterlebt. Es geht um
eine Firma, die PCs am Fließband montiert (Endmontage). Neben angelernten Arbeitern jobben – vor allem während der Ferienzeit – regelmäßig auch Schüler und
Studenten für ein paar Wochen bei dieser Firma. Die Anzahl der PCs, die pro
Stunde montiert werden können, hängt davon ab, wie lange der langsamste Arbeiter für seinen Montage-Vorgang braucht. Und der langsamste Arbeiter – d. h.
der Engpass – ist fast immer ein Schüler oder Student, der die notwendigen Griffe
noch nicht so routiniert beherrscht, wie ein festangestellter Arbeiter. Dies wäre
nicht weiter problematisch gewesen, wenn die Firma nicht eine Gruppen-Leistungsprämie ausgelobt hätte: Für jeweils soundso viele PCs, die vom Team am
Fließband über das Soll hinaus montiert wurden, gab es eine kleine Extraprämie
in Form eines etwas besseren Stundenlohns. Und so wurde der Engpassarbeiter
regelmäßig das Ziel von Mobbingattacken. Insbesondere Schüler und Studenten
hatten zu leiden, wenn sie besonders langsam waren. (Den Fließband-Arbeitern
war natürlich nicht klar, dass es für den optimalen Durchsatz einen und nur einen
Engpass geben muss. Dieser Punkt wird im Paragraph „Management der kurzfristigen Kostensenkung“ diskutiert.)
Größere Zwischenlager und unzufriedene Mitarbeiter, die irgendwann innerlich
kündigen, kosten i. Allg. deutlich mehr, als durch eine Zielvereinbarung hinzugewonnen werden kann. Diese Management-Strategie geht davon aus, dass viele
lokale Optimierungen (jeder Fahrer, jede Maschine wird beschleunigt) auch eine
globale Optimierung (= einen größeren Gewinn) zur Folge haben. Dies ist laut
Tom DeMarco (DeMarco [2001]) ein nicht auszurottender Trugschluss, der die
Firmen Geld ohne Ende kostet. MbO wurde in der Mitte des vorigen Jahrhunderts
erfunden und hat sich seitdem unausrottbar in die Köpfe der meisten Manager
eingenistet, obwohl heute bekannt ist, dass dieses Management-Prinzip fast nur
Nachteile mit sich bringt. (Weitere Nachteile, werden im Kapitel 5 diskutiert.)
24
Management ohne Kenntnis des Engpasses
Eine weitere Management-Entscheidung könnte sein, irgendwelche Maschinen,
die schon alt und klapprig aussehen, durch schnellere Maschinen zu ersetzen. Hier
wird genausowenig wie bei MbO analysiert, wo eigentlich die Probleme liegen,
sondern aus dem Bauch heraus irgend etwas optimiert. Auch dies führt nur in den
seltenen Fällen, bei denen zufällig der Engpass optimiert wird, zum Erfolg.
Im Genesatz zu MbO ist diese Art der Entscheidung nur nutzlos (falls nicht zufällig gerade die Engpass-Maschine optimiert wird), aber immerhin nicht schädlich
(wenn man von den derzeit sinnlosen Investionen absieht).
Management der kurzfristigen Kostensenkung
Eine letzte Entscheidung könnte sein, die Kosten zu senken, indem die Leerlaufzeiten von Maschinen reduziert werden. Teure Maschinen werden durch billigere,
nicht ganz so leistungsfähige Maschinen ersetzt. Teure Mitarbeiter werden durch
weniger qualifizierte und dadurch billigere Arbeiter ersetzt oder gleich ganz entlassen. Et cetera. Solchen Managern schwebt ein optimales System vor: Alle Maschinen sind exakt gleich leistungsfähig. Insbesondere am Fließband wird dieses
Ziel angestrebt: Alle Arbeitsschritte müssen exakt im vorgegebenen Takt erfolgen.
Doch auch diese Strategie ist vollkommen widersinnig. Wenn alle Maschinen exakt gleich schnell sind, hat jede Störung einer dieser Maschine Auswirkungen auf
den Gesamtdurchsatz. Am Beispiel des Konvois sieht man das sehr schön: Wenn
ein Auto tankt, müssen die Nachfolger warten (da das Überholen nicht möglich
ist). Wenn das Engpass-Fahrzeug tankt, hat dies Auswirkungen auf die Durchschnittsgeschwindigkeit des Konvois (und damit auch auf die Gesamtdauer der
Fahrt), da dieses Fahrzeug die verlorene Zeit nie wieder einholen kann. Wenn dagegen ein anderes Auto tankt, hat dies keine Auswirkungen auf die Durchschnittsgeschwindigkeit des Konvois. Fahrzeuge, die hinter dem Engpass-Fahrzeug fahren, können wieder zum Engpass-Fahrzeug aufschließen, indem sie kurzzeitig
schneller fahren. Und Fahrzeuge, die vor den Engpass-Fahrzeug fahren, behindern
dieses nicht, wenn der Abstand (Puffer) groß genug ist. Nach dem Tankvorgang
fahren diese Fahrzeuge ebenfalls ein Zeitlang etwas schneller als zuvor, um den
alten Abstand wieder herzustellen.
Wenn hingegen alle Fahrzeuge gleichschnell sind, ist jedes Fahrzeug ein Engpass. Das heißt, jeder Tankvorgang und jede sonstige Verzögerung eines beliebigen Fahrzeugs hat negative Auswirkungen auf die Durchschnittsgeschwindigkeit
des Konvois, da kein Fahrzeug eine Verzögerung mehr aufholen kann. Es ist daher
zwingend notwendig, dass es ein und nur ein Engpassfahrzeug gibt, sonst schaukeln sich die Störungen beliebig auf.
Die Erkenntnis, dass man genügen Puffer benötigt, um Schwankungen aufzufangen, ist von zentraler Bedeutung. Ein ausgefeiltes Puffermangement ist viel wichtiger, als man gemeinhin annimmt.
25
1.2.4 Zusammenfassung
Die wichtigste Erkenntnis, die man aus den Ergebnissen von Goldratt ziehen
muss, ist, dass man sich als Manager nicht um alles zu kümmern braucht, sondern
dass man nur die wirklich relevanten Risiken und Probleme in den Griff bekommen muss. Wer die Engpässe in seinem Unternehmen oder Projekt nicht kennt
und auf’s Geratewohl irgendwelche lokalen Optimierungen mit der Gießkanne
vornimmt, ist kein Manager, sondern ein Versager.
Die andere wichtige Erkenntnis ist, dass es ohne gutes Puffermangement nicht
geht.
Man erinnere sich: Goldratt vermutet, dass bis zu 90 % aller Management-Entscheidungen entweder keine Auswirkungen oder sogar negative Auswirkungen
haben!
Die wesentlichen Aufgaben eines Projektleiters sind:
1. Menschenführung (Zwischenmenschliche und persönliche Probleme erkennen und und nach Möglichkeit mindern)
2. Risikomanagement (Probleme frühzeitig erkennen und vermeiden), hierzu
zählt insbesondere das Puffermanagement
3. Planung und Kontrolle (gute Planung = Problemvermeidung, Kontrolle = Probleme frühzeitig erkennen)
In allen drei Fällen gilt: Konzentration auf die wirklich relevanten Problemgebiete. Nur diejenigen Risiken und Probleme sind von Interesse, die das Erreichen der
Problemziele gefährden. Eine Mediation, nur weil ein Mitarbeiter mal schlecht
gelaunt ist, das Managen von unbedeutenden Risiken (Kaffee geht aus) oder extrem unwahrscheinlichen Risiken, die Planung jedes kleinsten Details oder von
Komponenten, die vielleicht gar nicht realisiert werden, sind überflüssig und lenken nur von den wirklichen Managementaufgaben ab.
1.3 Projekterfolg
Wann ist ein Projekt erfolgreich?
Wenn man Projektleiter fragt: Misserfolge gibt es nicht! Es gibt höchstens verwickelte Erklärungen, warum die ganze Sache als „durchaus erfolgreich“ anzusehen
ist (Kellner [2001]). Also braucht man ein paar gute Definitionen.
Projekterfolg aus neutraler Sicht (juristische Sicht)
Die neutrale Sichtweise kann nur die schriftlichen Vereinbarungen zwischen Auftraggeber und -nehmer zur Grundlage haben.
26
erfolgreich:
Ein Projekt ist erfolgreich, wenn alle vertraglich festgelegten Ziele erfüllt
wurden: Spätestens zu den vorgegebenen Terminen und im Rahmen des vorgegebenen Budgets wird die geforderte Funktionalität in der geforderten Qualität geliefert.
sehr erfolgreich:
Ein erfolgreiches Projekt ist sehr erfolgreich, wenn die Anforderungen (Erwartungen) teilweise übertroffen wurden, d. h., wenn die gewünschten Ergebnisse früher geliefert werden können und/oder wenn die Kosten geringer waren als geplant und/oder wenn die geplante Funktionalität in höherer Qualität
realisiert werden konnte und/oder – in Absprache mit den Auftraggebern –
wenn ein erweiterter Funktionsumfang in mindestens der geforderten Qualität realisiert werden konnte.
gescheitert:
Ein Projekt ist gescheitert, wenn ein oder mehrere vertraglich vereinbarte Projektziele nicht erreicht wurden.
Vertraglich können auch andere Erfolgsmodelle definiert werden: Zum Beispiel
Hollywood Filmstudios: on time oder on budget. In diesem Fall ist ein Projekt erst
dann gescheitert, wenn es sowohl den Zeit-, als auch den Finanzrahmen überzieht.
Projekterfolg aus Sicht eines Projektbeteiligen (Auftraggeber, -nehmer, Benutzer, Projektleiter . . .)
erfolgreich:
Ein Projekt ist erfolgreich, wenn das Ergebnis für den jeweiligen Projektbeteiligten von Nutzen ist, d. h., wenn z. B. der Nutzen (z. B. der spätere Gewinn)
die Kosten wie geplant deutlich übersteigt oder allgemeiner, wenn die strategischen Ziele des Projektbeteiligten erfüllt wurden. Dies gilt selbst dann,
wenn einzelne Projektziele verfehlt worden sind.
sehr erfolgreich:
Ein erfolgreiches Projekt ist sehr erfolgreich, wenn der Nutzen die Erwartungen deutlich übersteigt.
weniger erfolgreich:
Ein Projekt ist weniger erfolgreich, wenn das (evtl. zu spät gelieferte oder zu
teurere oder zu schlechte) Projektergebnis immer noch von Nutzen ist, d. h.,
wenn die strategischen Ziele nur teilweise, nicht aber im gewünschten Maß
erreicht werden.
gescheitert (erfolglos):
Ein Projekt ist gescheitert, wenn das (evtl. gar nicht vorhandene) Ergebnis
nutzlos für den Projektbeteiligten ist. Dies gilt selbst dann, wenn das Projekt
im juristischen Sinne erfolgreich war!
27
katastrophal gescheitert:
Ein Projekt ist katastrophal gescheitert, wenn das Ergebnis den Projektbeteiligten ruiniert.
Projekterfolg aus Sicht der Betroffenen
erfolgreich:
Ein Projekt ist erfolgreich, wenn das Ergebnis den Betroffenen nicht ernstlich
schadet.
Wie wir gesehen haben, unterscheiden sich die Definitionen von Projekterfolg
aus juristischer Sicht und aus Sicht der Projektbeteiligten fundamental. Die erste
Definition basiert auf den vertraglich vereinbarten Zielen Funktionalität, Qualität,
Kosten und Zeit, der zweiten Definition liegen dagegen die strategischen Ziele der
jeweiligen Projektbeteiligten zugrunde.
Fazit: Wirklicher Projekterfolg (aus nicht-juristischer Sicht)
erfolgreich:
Ein Projekt ist für einen Beteiligten (Auftraggeber, Auftragnehmer, Benutzer)
erfolgreich, wenn das geplante Kosten/Nutzen-Verhältnis erzielt wird (Dieses
Verhältnis muss natürlich kleiner als 1 sein.)
sehr erfolgreich:
Ein Projekt ist für einen Beteiligten sehr erfolgreich, wenn das geplante Kosten/Nutzen-Verhältnis deutlich übertroffen wurde (d. h. deutlich kleiner als
geplant ist).
weniger erfolgreich:
Ein Projekt ist für einen Beteiligten weniger erfolgreich, wenn das echte Kosten/Nutzen-Verhältnis zwar nicht erzielt wurde, aber zumindest kleiner als 1
ist.
gescheitert:
Ein Projekt ist für einen Beteiligten gescheitert, wenn das echte Kosten/Nutzen-Verhältnis größer 1 ist, aber keinen Ruin für den Beteiligten bedeutet.
katastrophal gescheitert:
Ein Projekt ist für einen Beteiligten katastrophal gescheitert, wenn es ihn
ruiniert.
Ein (sehr) erfolgreiches Projekt, das Betroffenen einen größeren Schaden zufügt,
ist aus Sicht der Betroffenen gescheitert oder sogar katastrophal gescheitert.
28
Beispiel 1
Zum Beispiel war der Bau der ersten Atombombe aus Sicht der Projektbeteiligten
erfolgreich. Aus Sicht der Bewohner von Hiroshima und Nagasaki und eigentlich auch aus Sicht der gesamten Weltbevölkerung ist dieses Projekt katastrophal
gescheitert.
Beispiel 2
Abwasser auf Kosten der Allgemeinheit ungeklärt in Flüsse ablassen.
Wenn Betroffene mit ihren Klagen Erfolg haben, kann sich das Blatt auch für ein
zunächst erfolgreiches Projekt später in das Gegenteil umkehren (Schadensersatzzahlungen etc.).
Kosten/Nutzen-Planung
Wie man an diesen Definitionen sieht, kann man den wirklichen Projekterfolg nur
dann bestimmen, wenn man Kosten und Nutzen gleichermaßen geplant hat (vgl.
hierzu Teil IV in DeMarco und Lister [2003]).
Häufig sieht die Planung jedoch so aus:
Kosten: 1.237.534,13 Euro
Nutzen: Das müssen wir haben.
Strategische Ziele eines gewinnorientierten Unternehmens
Goldratt definiert die strategischen Ziele eines gewinnorientierten Unternehmens
folgendermaßen (Goldratt [2003]):
1. Gewinn machen bzw. steigern (heute und in Zukunft)
2. sicheres und befriedigendes Umfeld für Belegschaft schaffen (heute und in
Zukunft)
3. Markt zufrieden stellen (heute und in Zukunft)
Was heißt „Gewinn steigern“?
1. Nettogewinn steigern
Nettogewinn = Einnahmen − Ausgaben > 0
(unter Berücksichtigung der Inflation)
2. Rendite steigern
Rendite = Gewinn / Investition
3. Cashflow steigern
Cashflow = Menge des verfügbaren („flüssigen“) Geldes für Investitionen etc.
Geldmittel werden dem Cashflow entzogen durch:
– Lagerbestände
29
– Infrastruktur (Gebäude etc.)
– laufende Projekte
Achtung: ein länger andauernder negativer Cashflow, d. h. der Geldzufluss ist
geringer als der Geldabfluss, führt zur Insolvenz, auch wenn der Gewinn und
Rendite stimmen, da die frei verfügbaren Finanzmittel immer weiter bis auf
Null abnehmen (vgl. Flash-Animation Biz/ed [2006]).
Beispiele
– Titanic, der Film (QUELLE FEHLT [????]): sehr erfolgreich für den Auftraggeber, trotz Kosten von 200 Mio Dollar (100 Mio geplant) sowie 6 Monate Verzug.
Aus Sicht von Digital Domain: erfolgreich, wenn man den Prestigegewinn
durch den Film berücksichtigt, oder gescheitert, wenn man die Verluste berücksichtigt (trotz Nachverhandlungen: 4 Millionen Dollar Verlust; außerdem haben 31 Mitarbeiter ihren Job verloren, da für sie keine geeigneten
Projekte akquiriert werden konnten).
– Projekt: Bau des Bahnhofs Canfranc (Scheytt [1998])
Gebäude: 241m langer „Palast“, 1853 Planungsbeginn, 1882 Bewilligung (6
Jahre Bauzeit, 60000 Pesetas Subvention/km, Steuerfreiheit auf Baumaterialien), 1928 Einweihung (46 Jahre reale Bauzeit), wegen unterschiedlicher
Spurbreiten und fehlender Elektrifizierung auf spanischer Seite: für Auftraggeber ein Flop, d. h. gescheitert! (Allerdings nicht katastrophal gescheitert,
da die beteiligten Staaten Spanien und Frankreich daran nicht Konkurs gegangen sind.)
– Projekt: Bau der ersten Atombombe „Manhattan Project“ (Brockhaus
[1991a], Schattenmacher [2004])
Projektleiter: Oppenheimer, Robert (22.4.1904 - 18.2.1967; Krebs)
Juli 1943: Direktor der Forschungslaboratorien in Los Alamos (New Mexiko)
Budget: unbegrenzt; zum Schluss mehr als 2 Milliarden Dollar
Zeit: genau 19 Monate
Team: die besten Physiker Amerikas
Das Projekt wurde erfolgreich abgeschlossen: funktionierendes Ergebnis genau zum angestrebten Termin („Tag X“).
21 und 24 Tage nach Projektende wurde das Ergebnis in Hiroshima und
Nagasaki eingesetzt. Für das amerikanische Militär war das Projektergebnis
ein voller Erfolg; für die Betroffenen – die Bewohner von Hiroshima und
Nagasaki und später für die ganze Menschheit (Wettrüsten) – war das Projekt
katastrophal gescheitert (gerade weil es formal erfolgreich war).
30
Oppenheimer war kurze Zeit ein Nationalheld. Während des Projektes hat
er allerdings einen Mitarbeiter bei einem Atomunfall verloren (das erste Opfer einer Atombombe). Später widersetzte sich Oppenheimer dem Bau der
Wasserstoffbombe ⇒ Untersuchungsverfahren wegen angeblicher kommunistischer Gesinnung, 1954 Ausschluss von allen Staatsgeheimnissen und
öffentlichen Ämtern, 1963 Rehabilitation.
Aussagen von Oppenheimer (im Spielfilm):
• „Wir entwickeln das Ding nur, für ihren Einsatz tragen andere die Verantwortung.“
• „Manchmal glaube ich, dass wir trotz aller unserer Intelligenz vom
Raubtier abstammen.“
– Projekt: Untersuchung über Heilungswirkung verschiedener Varianten des
synthetischen Hormons Levothyroxin bei Schilddrüsenerkrankungen (Rubner [1990])
Projektleiterin: Betty Dong, Pharmazeutin an der Universität von Kalifornien in San Franzisko
Projektergebnis: alle vier untersuchten Präparate wirken bei den meisten Patienten gleich gut.
Einer der Auftraggeber, die Firma Boots, erklärte die Studie für fehlerhaft
(d. h. als Misserfolg) und verbot die Veröffentlichung. Boots stellte das teuerste und meistverschriebene der vier untersuchten Präparate her.
Gutachter des Journals of the American Medical Association konnten keine
Fehler in der Studie finden. Das Ergebnis wurde erst später, als die Geschichte publik wurde, veröffentlicht. Kosten für Versicherungen und Kranke: 365
Millionen Dollar.
Bemerkung
Für das Scheitern eines Projektes aus der Sicht des Auftraggebers ist nicht notwendigerweise der Projektleiter verantwortlich. Wenn dieser zu den gegebenen
Terminen und im Rahmen des vorgegebenen Budgets die geforderte Funktionalität liefert, das Ergebnis aber trotzdem für den Auftraggeber nutzlos ist, lag
bereits ein Planungsfehler vor (z. B. Eisenbahnbrücke ohne Eisenbahn: Die „Soda-Brücke“ von Rödental; dpa [2005], Wikipedia [2011b], Wikipedia [2006b]).
Allerdings sollte der Projektleiter schon von Anfang an, d. h. auch während der
Planungsphase, verantwortlich am Projekt beteiligt sein. In diesem Fall wäre er
auch mitverantwortlich für das Scheitern des Projektes.
31
1.4 Risikomanagement
1.4.1 Wie vermeidet man einen Misserfolg?
Ein erfolgreiches Projekt zu leiten, sollte das Ziel eines jeden Projektleiters sein.
Erfolgreich heißt dabei: erfolgreich aus juristischer Sicht, aus Sicht des Projektleiters, aus Sicht des Auftragnehmers, aus Sicht des Auftraggebers, aus Sicht des
Benutzers und – sofern ein ethisches Verantwortungsbewusstsein besteht – aus
Sicht der Betroffenen.
Aber auch weniger erfolgreiche oder nur relativ kurzzeitig erfolgreiche Projekte
werden eventuell noch akzeptiert.
Darum: Wie vermeidet man Misserfolge und erst recht Katastrophen?
1. Regel
Es gibt kein Patentrezept!
(„There are no Silver Bullets“: Brooks [1986], Wikipedia [2006a])
2. Regel
Der Projektleiter muss „einfach“ für jedes (managebare) Risiko, das für sein Projekt zum Problem werden kann, rechtzeitig Strategien zur Minderung der Auswirkungen und/oder Strategien zur Reaktion entwickeln. Falls ein Risiko zum echten
Problem wird, muss er rechtzeitig und richtig reagieren.
Numerobis: „In Ägypten haben wir gegen die Zeit, gegen den Personalmangel
und gegen die Römer zu kämpfen. Vor allem gegen den Architekten Pyradonis,
meinen Konkurrenten.“
Leider lassen sich nicht alle möglichen Probleme vorhersagen oder gar beseitigen.
Man sollte sich die tückischen Fallen aber von vorne herein klar machen, um
wenigstens möglichst viele dieser Risiken zu vermeiden oder zumindest deren
Auswirkungen abzumildern.
Für das Management heißt das im Wesentlichen einen fähigen Projektleiter – wie
Numerobis? – einzusetzen und glasklare Projektziele zu formulieren, die nachträglich – wenn überhaupt – nur kontrolliert geändert werden können.
Der Projektleiter sollte sich möglichst auf die Erfüllung der Projektziele konzentrieren (können), d. h., dem Begriff „erfolgreich“ sollte die neutrale Sicht zugrunde gelegt werden (auch wenn das nicht immer zu vertreten ist – siehe Oppenheimer).
32
1.4.2 Vorgehensweise
(vgl. DeMarco und Lister [2003])
1. Risiken identifizieren
2. Risiken bewerten
– Risiko-Eintrittswahrscheinlichkeit abschätzen
– Risikofolgen abschätzen
– Ist das Risko managebar?
3. Vorbeugemaßnahmen, Gegenmaßnahmen überlegen
– Kosten der Risikovorsorge abschätzen
4. managebare Risiken nach Priorität sortieren;
hohe Eintrittswahrscheinlichkeit + schlimme Folgen ⇒ hohe Priorität;
mögliche Formel, um Risiken zu gewichten:
Eintrittswahrscheinlichkeit · ( Problemkosten − Risikovorsorgekosten )
5. gute und tragfähige Problemindikatoren finden ⇒ Frühwarnsystem
6. Risiken managen
– Wenn Vorsorge möglich: Vorsorge treffen
– Problemindikatoren überwachen
– rechtzeitig Gegenmaßnahmen einleiten
Achtung: Nicht jeder Indikator ist sinnvoll. Krebsvorsorge ist z. B. nur dann sinnvoll, wenn die Vorsorge auch einen positiven Effekt für die Patienten hat: höhere
Lebenserwartung und/oder höhere Lebensqualität. PSA-Tests zur Prostata-Vorsorgeuntersuchungen bieten diese Vorteile derzeit mit hoher Wahrscheinlichkeit
nicht (Albin [2010]), auch der Sinn von Mammographie-Reihenuntersuchungen
ist umstritten (Nekolla et al. [2005], Dubben und Beck-Bornholdt [2010]).
In der New York Times schreibt Richard Albin, der PSA vor 40 Jahren entdeckt
hat:
PSA sollte keinesfalls genutzt werden, um alle Männer über 50 regelmäßig zu testen, wie es jene wollen, die wahrscheinlich davon profitieren.
Ich hätte mir nie träumen lassen, dass meine Entdeckung vor 40 Jahren
in eine derartige profitgetriebene Katastrophe für das Gesundheitswesen führen würde. Die Medizin sollte sich der Realität stellen und den
unangemessenen Einsatz von PSA-Tests stoppen. Das würde Milliarden Dollar sparen und Millionen Männer vor unnötigen und beeinträchtigenden Behandlungen bewahren.
(Albin [2010], Übersetzung in der SZ)
33
Im Oktober 2011 empfahl die U.S. Preventive Services Task Force, ein Gremium des US-Gesundheitsministerium, die Abschaffungen des PSA-Tests in der
USA.(Briseño [2011])
1.4.3 Typische Risiken und Vorsorgemaßnahmen
Im Folgenden werden Beispiele für Risiken angegeben, die ein Projekt scheitern
lassen können, wenn sie nicht rechtzeitig bedacht werden. Für viele Risiken werden zusätzlich mögliche Vorsorgemaßnahmen angegeben.
– falsche Funktionalität
• funtioniert nicht (Vorsorgemaßnahme: Integration von Entwicklung
und Tests, z. B. Spiralmodell)
• Benutzer akzeptieren System nicht (Vorsorgemaßnahme: Benutzer
frühzeitig mit ins Boot holen, Gegenmaßnahme: nachträgliche Anpassung des Systems)
• überzogene oder nicht-realisierbare Funktionalität
∗ Der Auftraggeber möchte eine „eierlegende Wollmilchsau“ (Vorsorgemaßnahme: Anforderungen frühzeitig vertraglich fixieren)
∗ neue Techniken sollen eingesetzt werden, die noch gar nicht das
Stadium der Forschung hinter sich gelassen haben (Solche Projekte
sollten nur als Forschungsprojekte durchgeführt werden.)
• Inflation der Anforderungen = ausufernde Änderungswünsche während
der Projektlaufzeit (Vorsorgemaßnahme: explizites Änderungsmanagement etablieren)
– Qualitätsprobleme
• schlechte Qualität (Vorsorgemaßnahmen: Qualitätsanforderungen in
Lasten-/Pflichtenheft einbauen, Qualitätssicherung, Qualitätsmanagement)
• überzogene oder nicht-realisierbare Qualität z. B.: Ein System mit
100 % Ausfallsicherheit kann nicht erstellt werden.
Forderungen wie Ausfallzeit unter 30 Min/Jahr sind dagegen, bei entsprechenden Kosten, schon realisierbar:
99,99 % Ausfallsicherheit =
ˆ max. 53 Min Ausfall/Jahr
99,999 % Ausfallsicherheit =
ˆ max. 5 Min Ausfall/Jahr
– kritisches bzw. falsches Zeitmanagement
• Mitarbeiter werden krank oder haben Urlaub. (Vorsorgemaßnahme:
Puffermanagement, Gegenmaßnahme: Hilfskraft einstellen, aber keinen Ersatz-Mitarbeiter)
34
• Lieferschwierigkeiten, Systemausfall etc.; Pyradonis behindert Steinnachschub (Vorsorgemaßnahme: Puffermanagement)
Achtung: Die Puffer, die für einzelne Vorgänge ermittelt werden,
sollten zu größeren Einheiten zusammengefasst werden (Zubringerpuffer, Gesamtpuffer etc.; siehe Abschnitt 4.5.)
• Mitarbeiter verlassen den Betrieb (Mitarbeiterfluktuation). Vor allem
gute Mitarbeiter gehen, andere „kündigen innerlich“, wenn sie unzufrieden sind. (Vorsorgemaßnahme: gute Menschenführung)
• Die Mitarbeiter erliegen dem Studentensyndrom (Goldratt [2002],
Fachbezeichnung: Prokrastination). (Vorsorgemaßnahmen: kurze Vorgänge, keine Parallelarbeit, realistische Schätzungen (Vertrauen!))
Arbeitseifer
Oh, jetzt wird’s
aber knapp!
anfängliche
Begeisterung
Ist ja noch Zeit!
Start
Ende
2/3 Zeit
1/3 Arbeit
Zeit
1/3 Zeit
2/3 Arbeit
Abbildung 1.3: Studentensyndrom, vgl. Goldratt [2002]
• Ein guter Mitarbeiter/Projektleiter arbeitet in normalen Zeiten höchstens 4 Tage à 6 Stunden (= 24 Stunden) pro Woche aktiv für das Projekt,
wenn sie nicht von Routine-Aufgaben entlastet werden.
Asterix: Arbeiter arbeiten zu langsam.
(Vorsorgemaßnahmen: Zaubertrank; Falls man diesen nicht zur Hand
hat: Zeiten realistisch schätzen, Mitarbeiter an kritischen Vorgängen von anderen Arbeiten entlasten, Resource Leveling (siehe Abschnitt 4.4.3))
35
• Sinnlose Wartezeiten kosten Zeit (Microsoft-Lösung: Win95-Buttons
für bevorzugte Abfertigung in der Kantine; Cusumano und Selby
[1997]).
• Telekommunikation kostet Zeit: Jedes Telefonat, jede E-Mail reißt
einen Wissensarbeiter aus seiner „Denkarbeit“, durchschnittlich passiert dies alle 11 Minuten (Pilgram [2011]) – es dauert danach jeweils
ca. 10 Minuten seine Gedanken danach wieder auf die eigentliche Arbeit zu konzentrieren, d. h., sich zu „vertiefen“ (DeMarco [2001]). (Vorsorgemaßnahme: Störungen von Mitarbeitern möglichst fernhalten)
• Projektexterne Tätigkeiten kosten Zeit.
• Der Zeitplan ist inhärent falsch („politischer Zeitplan“, „agressive Zeitplanung“; Vorsorgemaßnahme: gute Schätzmethoden einsetzen).
• Die Konkurrenz ist schneller (evtl. mit weniger Funktionalität oder
Qualität).
– kritische Kostenplanung (bei Asterix nicht gegeben, Geld ist reichlich da)
• Risikomanagement (wie z.B. Einplanung von Pufferzeiten) kostet Geld.
(Vorsorgemaßnahme: nur sinnvolle Risiken managen)
• Probleme (wie z.B. Ausfallzeiten) kosten Geld. (Vorsorgemaßnahme:
Puffermanagement)
• Spezialisten kosten Geld.
(Es kann allerdings billiger sein, einen Profi zu 1 000 Euro/Tag zu holen,
als einen Amateur zu 100 Euro/Tag.)
• Geeignetes Material kostet Geld. (Vorsorgemaßnahme: Bei der Planung
nicht übersehen)
• Lizenzen und andere Rechte kosten Geld. (Vorsorgemaßnahme: Bei der
Planung nicht übersehen)
• Der Kostenplan ist inhärent falsch („politischer Zeitplan“, „agressive
Zeitplanung“).
• Die Konkurrenz ist billiger (evtl. mit weniger Funktionalität oder
schlechterer Qualität).
Ressourcen
Der Projektleiter hat i. Allg. keinen oder nur wenig Einfluss auf die Projektziele
„Kosten“, „Zeit“, „Funktionalität“ und „Qualität“. Was er beeinflussen kann, sind
die von ihm eingesetzten Ressourcen zur Erfüllung dieser Ziele.
– Unzufriedene Mitarbeiter können jedes Projekt zu Fall bringen:
Mobbing, zuviel Kontrolle, zu wenig Kontrolle etc.
(Vorsorgemaßnahme: gute Menschenführung;
Asterix: Arbeiter wollen weniger Peitschenhiebe)
– Kommunikationsprobleme (Vorsorgemaßnahme: gute Menschenführung)
36
– geringe Produktivität der (falschen oder auch unmotivierten) Mitarbeiter
(Vorsorgemaßnahme: gute Menschenführung)
– „Ressourcenklau“ zwischen rivalisierenden Projekten
(Vorsorgemaßnahme: gute Menschenführung durch höhere Führungsebenen)
– zu knappe Ressourcen
(Rechnerzeiten, Kopierkontingente, Raumnot etc., Asterix: zu wenig Sklaven; Lösung: Zaubertrank)
– unwirtschaftlicher Einsatz von Ressourcen
(Mensch, Material, Infrastrukturen, Information)
– Verfügbarkeit von Ressourcen ist nicht sichergestellt
(Asterix: Steine fehlen ⇒ Problem trotz Zaubertank)
– falsche Ressourcen
(unfähige Mitarbeiter, die für das Tagesgeschäft nicht geeignet und daher
verfügbar sind; nicht-erweiterbare Multimedia-Rechner ohne Soundkarten,
unausgereifte Entwicklungswerkzeuge etc.)
– Auftraggeber oder Lieferant liefert benötigte Ressourcen zu spät
– Sabotage
Spezifikationskollaps
Ein sehr großes Risiko ist jedoch auch, dass der Projektleiter gar nicht weiß, welche Ziele er eigentlich verfolgen soll.
– In der Spezifikation werden zu Projektbeginn, da sich die beteiligten Parteien
nicht einigen können, keine konkreten Angaben zu Anforderungen gemacht
(nur Luftblasen). Wolkige Spezifikation ist möglich, wolkige Entwicklung
nicht ⇒ irgendwann kommt es zum Crash.
Dieses Risiko wird sofort zum Problem, sobald ein derartig schwammiger Vertrag formal geschlossen wird. Das heißt, die Risikovorsorge muss sehr frühzeitig
erfolgen, evtl. noch, bevor überhaupt ein Projektteam eingesetzt wird. Hier sind
auch wieder höhere Führungsebenen gefragt, die über dem Projektteam liegen.
Probleme von außen
Neben den tyischen Managementfehlern gibt es noch Risiken, deren Problemwerdung vom Projektteam nur schwer abgewendet werden können:
– höhere Gewalt (Konkurs des Auftraggebers, Streik, Umweltkatastrophen)
– Spionage
– Konkurrenz hat mehr „Marktmacht“
37
Menschen
Projekte scheitern dennoch meist an Menschen:
– Management („Managementfehler häufigste Insolvenzursache“, AZ [2006])
– Projektteam (Projektleiter und Projektmitarbeiter)
– Auftraggeber
– externe Partner
– Benutzer (akzeptieren das Projektergebnis nicht)
– Betroffene (klagen erfolgreich gegen Projektergebnis)
Man beachte, dass es schwierig ist, Risiken zu finden, die nicht auf Managementfehler zurück zu führen sind, und diese beeinflussen meist auch nur die Projektziele „Dauer“ und „Kosten“:
– Krankheit der Mitarbeiter (Dauer)
– Konkurs eines Sub-Unternehmers (Dauer, Kosten)
– Ressourcenknappheit wg. Streik, Lieferengpässen etc. (Dauer, Kosten)
– Hardware fällt aus (Dauer, Kosten)
– Steigende Preise (Kosten)
– geeignete Hardware/Software steht nicht zur Verfügung (Funktionalität,
Qualität, Dauer, Kosten)
Bei den meisten Problemen, die auftreten, handelt es sich jedoch um Managementfehler:
– keine Konzentration des Managements auf wesentliche Aufgaben
– Manager kümmern sich nicht um Projektinterna, treffen aber Entscheidungen
– Ausüben von negativem Druck
– Ausüben von „positivem“ Druck, wie z.B. Management by Objectives
– Angst vor Versagen ⇒ zuviel Kontrolle
– Angst vor Sympathieverlust ⇒ zu wenig Kontrolle
– kein Risikomanagement
– Kommunikationsoverhead
– Spezifikationskollaps
– Inflation der Anforderungen
– falsche Zeitplanung, wie z.B. fixe Termine oder Parallelarbeit durch Mitarbeiter, falsche Kostenplanung, falsche Ressourcenplanung etc.
38
Weitere typische zwischenmenschliche Probleme:
– nutzlose Meetings aufgrund von Profilierungssucht
– irreale Kosten-/Zeitschätzungen, weil Auftragnehmer das Projekt unbedingt
oder überhaupt nicht haben will
– Pläne werden über die Köpfe der Betroffenen hinweg erstellt
– DV-Spezialisten ignorieren Belange von Normalbenutzern („Diese Idioten
verstehen sowieso nichts davon“)
– Mitarbeiter, Partner etc. verstehen sich nicht
(wahllos zusammengewürfelte Teams)
– Neid („Eigentlich wäre ich an der Reihe gewesen, Projektleiter zu sein“ etc.)
– Mobbing
– Sabotage durch unzufriedene Mitarbeiter, Projektleiter, Konkurrenten (Pyradonis) oder Benutzer
– etc. pp.
Kernrisiken
Projektrisiken gibt es viele. Am Besten ist es natürlich, alle managebare Risiken auch zu managen, sofern diese eine gewisse Relevanz haben. Ein Risiko wie
z. B. „Ein Asteroid vernichtet einen Großteil der Menschheit“ ist nicht managebar
und kann daher ignoriert werden. Genauso kann ein Risiko wie z. B. „Der Kaffee
ist aus“ ignoriert werden; hier finden die Projektmitarbeiter i. Allg. eine eigene
tragfähige Lösung (z. B. einen Kaffeebeauftragten, der rechtzeitig für Nachschub
sorgt).
Es ist schon viel gewonnen, wenn wesentliche Kernrisiken berücksichtigt werden. Kernrisiken zeichnen sich durch hohe Eintrittswahrscheinlichkeit und hohe
Kosten aus, wenn sie wirklich eintreten.
Urs Gulba [2004] nennt folgende Top-Risiken in Softwareprojekten:
– Dynamische Anforderungen (= andauernde Veränderung der Anforderungen)
– schlechte Projektplanung und -schätzung
– mangelhafte Kommunikation
– fehlende oder unzureichende Qualitätssicherung
– unreife Softwaretechniken sowie unzulängliche Entwicklungsmethoden und
-werkzeuge
39
DeMarco und Lister [2003] geben folgende fünf Kernrisiken an:
– inhärent fehlerhafter Zeitplan
– Inflation der Anforderungen (ausufernde Anforderungen)
– Mitarbeiterfluktuation
– Spezifikationskollaps
– geringe Produktivität
Es fällt auf, das in beiden Quellen jeweils nur ein Problem genannt wird, das
die Arbeitsleistung betrifft – und dies auch noch als letztes. Die anderen Risiken können durch harte Arbeit des Teams kaum mehr beeinflusst werden. Sie als
Projektleiter können allerdings gegen die meisten Risiken ankämpfen. Bei Problemen wie einem inhärenten Zeitplan oder einem Spezifikationskollaps, können
allerdings auch Sie (nachträglich!) nicht mehr viel ausrichten.
Wesentliche Kernprobleme bestehen schon frühzeitig. Das heißt, viele Kernrisiken müssen schon sehr früh berücksichtigt werden, da sie sonst schon früh zu
echten Problemen werden (auch wenn das häufig erst spät, viel zu spät erkannt
wird).
Ein klassisches Beispiel ist der erste Versuch des Toll-Collect-Projektes. Um den
Auftrag zu erhalten, hat das Konsortium eine Projektlaufzeit von weniger als einem Jahr veranschlagt. „Im Vorfeld nach anstehender Bundestagswahlen einigte
man sich auf elf Monate“ (Borchers [2004]). Dass diese Zeitspanne für ein derart
komplexes Projekt viel zu kurz war, dürfte selbst jedem Laien klar sein. Nachdem
die veranschlagten elf Monate vorbei waren, wurde eine realistische Schätzung
von mehreren Jahren Projektdauer vorgenommen und in einem zweiten Versuch
wurde das Projekt erfolgreich abgeschlossen.
1.5 Vergleich von Projekten mittels Euro-Tagen
Ein billiges Projekt mit langer Laufzeit bindet eventuell mehr Kapital, als ein
teures Projekt mit kurzer Laufzeit. Um den Wert eines Projektes abschätzen zu
können, reicht es daher nicht, den später erwarteten Gewinn zu berücksichtigen.
Man sollte auch den Effekt auf den Cashflow betrachten. Goldratt schlägt vor,
dies mit Hilfe des künstlichen Maßes „Euro-Tage“ zu tun (Goldratt [2002], TOC
Times [2005]).
Wenn ein Projekt 1 000 Euro einen Monat lang bindet, entspricht dies laut Goldratt einer Investition von 30 000 Euro-Tagen = 1 000 Euro · 30 Tage. Verschiedene
Euro-Tag-Investitionen werden einfach aufaddiert.
40
Nehmen wir an, unser Projekt hätte eine Laufzeit von 3 Monaten. Jeder Monat
koste uns 1 000 Euro, anschließend verdienen wir monatlich 500 Euro mit dem
Projektergebnis. Das heißt, wir investieren 3 000 Euro und müssen insgesamt 9
Monate (= 3 Monate Projektlaufzeit + 6 Monate Verdienst am Projektergebnis)
warten, bis wir die Investition wieder „herein“geholt haben. Nach 9 Monaten haben wir also genauso viel Geld zur Verfügung als davor. Erst jetzt verdienen wir
mit dem Projekt Geld.
Wir hatten allerdings neun Monate lang Geld gebunden (dem Cashflow entzogen),
welches wir anderweitig für evtl. bessere Investitionen hätten verwenden können.
Wie groß war nun die Auswirkung auf den Cashflow?
Unsere Investition betrug 3 000 Euro, nach 9 Monaten hatten wir das Geld wieder.
Das entspricht einer Investition von 3 000 Euro · 9 · 30 Tage = 810 000 Eurotage,
man spricht auch von Investitions-Euro-Tagen.
Diese Rechnung ist allerdings etwas grob, da wir die 3 000 Euro ja nicht sofort am
ersten Tag investiert hatten und auch nicht 9 Monate lang auf jeden Cent verzichten mussten. Bei genauerer Rechnung ergibt sich folgende Investitionssumme:
1. Monat: 1 000 Euro investiert
30 Tage · 1 000 Euro = 30 000 Euro-Tage, Summe: 30 000 Euro-Tage
2. Monat: weitere 1 000 Euro investiert
3. Monat: weitere 1 000 Euro investiert
4. Monat: 500 Euro verdient ⇒ noch 2 500 Euro investiert
8. Monat: 500 Euro verdient ⇒ noch 500 Euro investiert
30 Tage · 500 Euro = 15 000 Euro-Tage, Summe: 405 000 Euro-Tage
9. Monat: 500 Euro verdient ⇒ noch 0 Euro investiert
30 Tage · 0 Euro = 0 Euro-Tage,
Summe: 405 000 Euro-Tage
10. Monat: 500 Euro verdient ⇒ 500 Euro Gewinn
Das heißt, wir verdienen erst ab dem 10. Monat Geld, haben dafür aber 9 Monate lang auf Investitionsmittel in Höhe von 405 000 Euro-Tagen verzichtet. Wenn
wir das Geld für diese Zeit anders (besser) angelegt hätten, hätten wir evtl. früher
41
mehr Geld verdient. Das heißt, wir können erst dann von einem echten Reingewinn sprechen, wenn wir mir dem Projekt nicht nur das Geld, sondern auch die
verlorenen Euro-Tage wieder verdient haben.
Die Rechnung der so genannten Durchsatz-Euro-Tage, d. h. der Euro-Tage, die
wir durch das Projekt gewinnen, beginnt ab dem Zeitpunkt, ab dem wir erstmals
einen echten Gewinn einfahren. Bei unserem Projekt ist das der 10. Monat. Die
Durchsatz-Euro-Tage werden geanuso wie die Investitions-Euro-Tage berechnet:
10. Monat: 500 Euro Gewinn
30 Tage · 500 Euro = 15 000 Euro-Tage, Summe: 15 000 Euro-Tage
11. Monat: weitere 500 Euro Gewinn
13. Mona:t weitere 500 Euro Gewinn
(26 Tage · 3 500 Euro = 94 500 Euro-Tage, Summe: 409 000 Euro-Tage)
Das heißt, am Ende des 16. Monats (genauer: 4 Tage zuvor) haben wir so viele Durchsatz-Euro-Tage verdient, wie wir Investitions-Euro-Tage zuvor verloren hatten. Bis dahin haben wir außerdem 3 500 Euro mit unserem Projekt verdient. Über den Zeitraum von 7 Monaten entspricht das einer Investitionskraft
von 420 000 Euro-Tagen. Diese Investitionskraft hätten wir auch gehabt – und das
auch noch früher –, wenn wir das Projekt gar nicht gestartet hätten. (Inflationsbereinigt hätten wir sogar noch ein paar Tage länger warten müssen, bis wir unsere
ursprüngliche Investitionskraft wieder hergestellt hätten).
Welche Bedeutung hat also der 17. Monat für unser Projekt? Das ist der Zeitpunkt,
ab dem wir wirklich neues Geld verdienen, das wir zusätzlich investieren oder
verleben können. Im Magazin „TOC Times“ steht: „. . . the project Flushes – we
really return the investment in both money and opportunity lost“ (TOC Times
[2005]).
In einem Internetforum (Zultner [2009]) wird von Richard Zultner der Sinn der
Investiontions- und der Durchsatz-Euro-Tage mit einem sehr einfachen „Gegenbeispiel“ in Frage gestellt. Das Argument lautete wie folgt: Wenn jemand 10 Euro
auf zwei Arten anlegen könne, einmal für einen Tag, um dann 20 Euro zurückDraft (4. Oktober 2012)
42
zubekommen (= 10 Euro Gewinn)2 und einmal für 10 Tage, um dann 100 Euro
zurückzubekommen (= 90 Euro Gewinn), dann sei es auf jeden Fall besser, es für
10 Tage anzulegen, weil dann der Gewinn deutlich größer sei. Dies widerspräche
aber dem Ergebnis der Berechnung der Investitions-Euro-Tage, die im ersten Fall
nur 10 · 1 = 10 Euro-Tage betrügen, im zweiten dagegen 10 · 10 = 100 Euro-Tage. Dieses Ergebnis würde ja bedeuten, dass man die 10 Euro besser nur einen Tag
anlegen sollte, weil der Flush dann wesentlich früher einträte. In jedem Lehrbuch
stünde dagegen, dass die andere Variante die bessere Wahl sei.
Hat er Recht? Ja, er hat Recht, aber nur, wenn eine Reinvestition – wie von Zultner
gefordert – nicht möglich ist. Sehen wir uns dieses Beipiel (mit diesen fantastischen Gewinnmöglichkeiten) mal etwas genauer an. Angenommen, ich wäre im
Besitz von genau 10 Euro und legte sie so an, dass ich nach 10 Tagen 90 Euro
Gewinn machte. Bis ich diesen Gewinn einstreichen könnte, wären meine 10 Euro gebunden und ich könnte sie nicht anderweitig verwenden. Dies drückt sich im
Wert „100 Investiotions-Euro-Tage“ aus.
Wenn ich dagegen die 10 Euro nur ein Tag lang anlegte, hätte ich am nächsten
Tag 20 Euro zur Verfügung, die ich gleich wieder investieren könnte. Die 20 Euro legte ich natürlich bereits am zweiten Tag wieder zu den Super-Bedingungen
„Verdopplung in einem Tag“ an. Das heißt, nach zwei Tagen (am dritten Tag) hätte ich 40 Euro, nach drei Tagen 80, nach 4 Tagen 160 und so weiter. Auf diese
Weise hätte ich nach 10 Tagen einen Gewinn von 10230 Euro erwirtschaftet.
Der wesentliche Punkt bei dem Maß „Euro-Tag“ ist, dass er nur dann Sinn macht,
wenn ich mein Geld regelmäßig möglichst sinnvoll investieren will und kann. Dieses Maß hilft einem dabei, zu entscheiden, welche Investitionen wirklich sinnvoll
sind. Wenn ich zwischen diesen fantastischen Investionsmöglichkeiten „Verdopplung in einem Tag“ und „Verzehnfachung in 10 Tagen“ nur ein einziges Mal wählen kann und es keine anderen Reinvestitionmöglichkeiten gibt, dann sollte ich
natürlich die Verzehnfachung wählen. Wenn mir aber nach einem oder auch zwei
Tagen wieder eine Super-Investtionsmöglichkeit angeboten wird, dann ist die Verdopplung der Verzehnfachung i. Allg. vorzuziehen, da diese die Investitionsmittel
nicht so lange bindet.
Allerdings nützen die ganzen schönen Berechnungen von Euro-Tagen nichts,
wenn die Schätzungen der Projektdauer, der Kostenverläufe und der erwarteten
Gewinne schlecht oder gar vollkommen unseriös sind.
Andererseits macht einem die Berücksichtigung der Euro-Tage erst klar, welche
Kosten eine große Zeitverzögerung wirklich verursacht. Es wird nicht nur der
Reingewinn geschmälert (wenn sich das neue Handy beispielsweise nur noch ein
2
Richard Zultner wählt ein etwas komplexeres Beispiel: Nach zwei und nach 5 Tage erhalte ich
jeweils 20 Euro Gewinn.
43
halbes Jahr verkaufen lässt und nicht, wie geplant, ein ganzes Jahr, da es zu spät
auf den Markt gekommen ist). Es wird auch die Investitionskraft, d. h. der Cashflow, empfindlich geschmälert.
Fazit
Wenn man die Auswahl zwischen mehreren Projekten hat, sollte man bei der Entscheidung, welche davon realisiert werden sollten, nicht nur die Kosten und den
später erhofften Gewinn, sondern auch die Auswirkungen auf die Investitionskraft, d. h. die Investitions- und die Durchsatz-Euro-Tage berücksichtigen.
44
Kapitel 2
Projektverlauf
„Ein Fußmarsch von 1000 Meilen beginnt mit dem ersten Schritt.“
(chinesisches Sprichwort)
Jede menschliche Tätigkeit lässt sich in Phasen einteilen (aufstehen, waschen,
anziehen, frühstücken, zur Arbeit fahren etc.)
Ebenso lässt sich jedes Projekt in Phasen unterteilen (Spezifikationsphase, Designphase, Fertigungsphase, Einführungsphase etc.)
Prinzipiell ist es möglich, zwei Phasen überlappen zu lassen (Nahrungsaufnahmephase + Informationsphase = frühstücken + Zeitung lesen)
Auch in Projekten könnte man mehrere Phasen einander überlappen lassen. Zum
Beispiel könnte man mit der Einführungsphase (Aufstellen von Hardware beim
Benutzer, Installation von Basissoftware etc.) begonnen werden, bevor die Fertigungsphase vollständig abgeschlossen ist. Im Falle von Terminproblemen wird
man manchmal auch so vorgehen.
Allerdings ist es sicherer, eine Phase vollständig abzuschließen und dann erst mit
der nächsten zu beginnen.
Ein sehr schönes Beispiel lieferte im Sommersemester 2005 der Bau des neuen Schülegebäudes der Hochschule Augsburg. Die erste Planungsfirma hatte das
Handtuch geworfen, eine zweite Planungsfirma übernahm den Job. Während diese Firma die Anschlüsse von Steckdosen, Netzwerk etc. plante, wurden bereits
die zugehörigen Leerrohre auf der Baustelle einbetoniert. Den Mitarbeitern des
Fachbereichs Informatik, die an der Planung beteiligt waren, standen veraltete
Pläne zur Verfügung, in denen sich z. B. Türen an anderen Stellen als aktuell geplant befanden. Aber das war sowieso egal, da ja auf der Baustelle bereits Fakten
geschaffen wurden.
Besser ist es i. Allg. jede Phase vollständig abzuschließen, bevor die nächste begonnen wird. Während einer Phase können allerdings verschiedene Aufgaben
(Vorgänge) parallel bearbeitet werden.
Das Ende einer Phase wird auch als Meilenstein bezeichnet. Dabei unterscheidet
man zwischen internen Meilensteinen, die nur innerhalb des Projektteams von Bedeutung sind, und den externen Meilensteinen, bei denen die Teilergebnisse dem
45
Auftraggeber präsentiert werden und mit ihm das weitere Vorgehen abgestimmt
wird.
Phase 1
Projektstart
Phase 2
Phase 3
Meilenstein 1
Meilenstein 2
Projektende
Prinzipielles Vorgehen
Ein Projekt wird in n Phasen unterteilt. Es sei i ∈ 1, 2, . . . , n.
Phase i:
– Dauer i
– Budget i
– Funktionalität und Qualität i
– Pläne i
– Ressourcen i
– Vorgänge i
→ Produkt i (Meilenstein am Ende der Phase i)
Review i mit Entscheidung (und evtl. mit Planänderungen):
– weiter: Phase i + 1 wird gestartet (bzw. Projektende, wenn Phase i + 1 nicht
existiert, d. h., wenn i = n),
– weiter mit Ziel- oder Planänderung: Phase i + 1 wird nach Änderung der
Ziele oder Pläne gestartet
– zurück: Phase i (oder sogar eine frühere Phase) wird wiederholt
– zurück mit Ziel- oder Planänderung: Phase i (oder sogar eine frühere Phase)
wird nach Änderung der Ziele oder Pläne wiederholt
– Projektabbruch (da sinnvolle Ziele nicht mehr erreicht werden können)
Bei einem Review können auch Projektziele (Kosten, Zeit, Funktionalität, Qualität) geändert werden. Dies sollte jedoch stets schriftlich mit Zustimmung aller
Beteiligten erfolgen (Änderungsmanagement).
Dieses Vorgehen garantiert, dass die Phase n zur Zufriedenheit aller (oder zumindest der Mehrheit) abgeschlossen wird oder dass das Projekt wegen unüberwindbaren Problemen, Unwirtschaftlichkeit oder Ähnlichem vollkommen gestoppt
wird.
46
Vorteile des Phasenmodells
– Schätzungen sind, wenn man ein Projekt in mehrere Teile wie z. B. einzelne
Phasen unterteilt und diese einzeln schätzt, viel besser, als wenn man ein
Projekt im Ganzen schätzt. (siehe Abschnitt 3.2.2)
– Das Projekt dümpelt nicht vor sich hin, da man immer erreichbare Ziele vor
Augen hat.
– Die Zeit, Budget- und Zielplanung kann schrittweise erfolgen. Man stattet
beispielsweise das Projekt zunächst nur mit einem Budget für die ersten ein,
zwei Phasen aus und entscheidet dann, ob man mit dem eigentlichen Projekt
starten will.
– Zu jedem Meilenstein/Review-Zeitpunkt wissen alle Beteiligten, wo das
Projekt steht. Allerdings zaubern Projektleiter und -mitarbeiter bei Reviews
oft ganz schön.
– Bei jedem Review kann eine formale Änderung alter Projektziele erfolgen
(Änderungsmanagement, Change Management). Schlimmstenfalls kann entschieden werden, mehrere Phasen zu wiederholen (z. B. weil der Hardwarehersteller der Zielplattform Pleite gegangen ist – in derart krassen Fällen
sollte allerdings nicht erst eine Review-Phase abgewartet werden).
– Das Risikomanagement wird deutlich einfacher.
2.1 Verschiedene Phasenmodelle
Es gibt kein „einzig richtiges“ Phasenmodell!
Welche Phasen notwendig sind, welche Meilensteine gesetzt werden sollten,
hängt immer vom aktuellen Projekt ab.
Prinzipiell gibt es bei Softwareprojekten fünf große Abschnitte (aber keine normierten Begriffe dafür), die allerdings auch verschränkt ablaufen können (Spiralmodell; siehe Abschnitt 2.2):
1. Spezifikationsphase (Projektziele: Was soll erreicht werden?)
2. Designphase (Wie werden die Projektziele erreicht?)
3. Fertigungsphase (Realisierung der Projektziele)
4. Einführungsphase (Übergabe der Projektergebnisse an den Auftraggeber/die
Benutzer)
5. Aufarbeitungsphase (+ Nutzungsphase)
Nach Abschluss der Einführungsphase ist das Projekt eigentlich abgeschlossen.
Allerdings sollte man die Erfahrungen, Erfolge und Fehler in einer abschließenden
47
Aufarbeitungsphase reflektieren, um daraus für ein nächstes Projekt zu lernen.
Die Nutzungsphase ist nicht mehr Bestandteil des Projektes. In dieser Phase anfallende Arbeiten, wie z. B. Wartungstätigkeiten, gehören zum Tagesgeschäft (obwohl viele Projektarbeiten leider oft in die Wartung verlegt werden, um den Termin formal einhalten zu können; Bananenprodukt: Das Produkt reift beim Kunden).
Ein erfolgreiches Projekt kann ein oder mehrere Folgeprojekte initiieren. Das
heißt, in die Nutzungsphase (eventuell sogar schon in frühere Projektphasen) können die Planungsphasen der Nachfolgeprojekte fallen.
Diese fünf Grobphasen können je nach Projekt unterschiedlich umfangreich und
in unterschiedliche Teilphasen gegliedert sein.
2.1.1 Die Spezifikationsphase: Was soll gemacht werden?
Ziel dieser Phase ist es festzulegen, was gemacht werden soll. Zunächst startet ein
Projekt meist ohne konkrete Vorstellungen, ohne Projektleiter und Projektmanagement.
Typische Phasen während der Spezifikationsphase:
Initialisierungsphase, Planungsphase, Bedarfsermittlung, Vorstudie
Zunächst muss die Projektidee geboren werden. Das kann ganz spontan im Schlaf
passieren, oder man sucht gezielt nach neuen Projektideen mit Hilfe einer Vorstudie oder Bedarfsermittlung (Brainstorming etc.).
Am Anfang ist die Idee!
Orientierung (Informationsphase)
– Welche Bedürfnisse bestehen (z. B. Benutzerbefragungen)?
– Welche Probleme oder Engpässe bestehen (Problemanalyse)?
– Wo ist eine Marktnische (Übersichtsanalyse)?
Untersuchung
→ Gibt es Lösungsmöglichkeiten für die erkannten Probleme?
– Ist zumindest eine Lösung realisierbar (Konzeptanalyse)?
– Nutzt die Lösung dem Auftraggeber (grobe Kosten-/Nutzenschätzung)?
– Ist eine Lösung der Probleme wirtschaftlich notwendig?
Eine Bedarfsermittlung wird normalerweise vom Auftraggeber alleine durchgeführt, eine Vorstudie wird dagegen oft als Auftragsarbeit an eine andere Firma
48
(z. B. Beraterfirma) vergeben. Es ist von Vorteil, wenn der zukünftige Projektleiter in dieser Phase schon aktiv beteiligt ist.
Eventuell wird während einer Bedarfsermittlung auch schon ein Rahmenkonzept
erstellt (z. B. Orientierung an unternehmensweitem Datenmodell, Zusammenstellung potentieller Anwendungen). Es ist sogar möglich, schon Rahmenpläne zu
erstellen (Teilprojekte mit Zielen, einzusetzende Ressourcen etc.).
Vorstudien sind eigentlich selbst wieder Projekte mit dem Ziel, die Machbarkeit
eines größeren Projektes zu analysieren und ein Rahmenkonzept sowie Rahmenpläne zu erstellen:
Während der Designphase des Vorprojektes kann eine so genannte Systemanalyse durchgeführt werden, während der Fertigungsphase sollten ein oder mehrere
Konzepte erstellt werden, und während der Einführungsphase sollte ein Konzept
ausgewählt und eine Entscheidung für das eigentliche Projekt getroffen werden.
Review
Genehmigung
– einer Anforderungsliste
– von Ausschreibungsunterlagen
– eines Lastenheftes, welches die wesentlichen Projektziele beschreibt (d. h.
Funktionalität, Qualität, grobe Kostenvorstellung, grobe Dauer)
– eines Rahmenkonzeptes
– von Rahmenplänen
– sowie Beschluss, die nächste Phase zu beginnen
Akquisitionsphase
Diese Phase erfolgt, sobald Sie wissen, dass Sie ein Projekt durchführen wollen,
Ihnen aber die Mittel dafür fehlen (vor allem, wenn Sie nicht selbst der Auftraggeber sind). Die Phase kann sich direkt an die Informationsphase anschließen oder
auch erst nach Verabschiedung irgendeiner Grobspezifikation erfolgen.
Wenn Sie zuwenig Geld haben, müssen Sie Projektpartner und/oder Geldgeber
finden.
Typische Projektpartner: andere Abteilungen, externe Unternehmen anderer Branchen, europäische Unternehmen derselben Branche etc.
Typische Geldgeber: der Aufsichtsrat, der Abteilungsleiter, ein anderes Unternehmen (wenn Sie z. B. einer Technologietransferstelle angehören), der bayerische
Staat (Existenzgründerdarlehen etc.), die EU (Esprit etc.).
49
Probleme
Die Akquisitionsphase kann sehr lange dauern (manchmal ein Jahr und mehr,
Canfranc: 30 Jahre).
Die ursprünglichen Projektziele können dabei völlig über den Haufen geworfen
werden.
Die zugeteilten Geld- und Zeitmittel können oft rein politischer Natur sein („Hier
haben Sie eine Million, lösen Sie das Problem in 15 Monaten!“).
Als potentieller Projektleiter sollten Sie von Anfang an bei der Akquise beteiligt
sein. Es gibt nichts Schlimmeres, als zum Projektleiter eines undurchführbaren
Projektes ernannt zu werden (völlig überzogene Ziele bezüglich Funktionalität,
Qualität, Zeit und/oder Kosten, z. B. Toll Collect in elf Monaten (Projektstart: 20.
September 2000, Buchholz [2003]; Projektende: 31. August 2003, manager-magazin [2003]).
Während der Akquisitionsphase werden oftmals mehr oder weniger detaillierte
Pläne ausgearbeitet (Phasenpläne mit Meilensteinen, Kostenpläne, Ressourcenpläne etc.). Doch Vorsicht! Die Pläne der Akquisitionsphase sind oft politischer
Natur. Es gibt Projekte, bei denen heißt es am Ende der Akquisitionsphase: „Jetzt
haben wir die Fördergelder. Was machen wir damit?“
Review
Genehmigung der Finanzierung. Jetzt kann oft schon mit gutem Gewissen ein
Projektvertrag zwischen Auftragsnehmer und -geber geschlossen werden (wenn
bereits „belastbare“ Rahmenkonzepte, ein Lastenheft o. Ä. vorliegen).
Definitionphase (Konzeptphase)
Spätestens in dieser Phase muss ein verantwortlicher Projektleiter bestimmt werden.
In den ersten Teilphasen der Spezifikationsphase werden normalerweise nur grobe Zielvorstellungen formuliert (Lastenheft). Spätestens wenn klar ist, dass ein
Projekt gestartet werden soll, müssen die Ziele genau definiert und verbindlich
festgelegt werden. Ein Pflichtenheft oder eine Spezifikation muss geschrieben werden. Diese muss genau spezifizieren, was zu tun ist, welche Normen einzuhalten
sind, wer für was verantwortlich ist (auch der Auftraggeber hat Pflichten!), wie
Probleme kommuniziert werden etc.
Zunächst sollten Funktionalität und Qualität festgelegt werden. Dabei müssen
„messbare“ Erfolgskriterien festgelegt werden.
Beispiel „Aufsatzdienst Elektra“
Der Aufsatzdienst Elektra soll druckbare Aufsätze in einer Qualität besser als Fax
per Internet ausliefern.
50
Die Bearbeitung einer Bestellung durch eine Fachkraft dauert am Rechner nicht
mehr als 20 Sek/Seite.
Und so weiter.
Beispiel „Internetpräsentation für die HS Augsburg“
– läuft auf allen Browsern
– insbesondere kann jede Seite mit jedem HTML-4.01-konformen Browser
betrachtet werden (auch Lynx, Braille-Zeilen etc.)
– Barrierefreiheit
– läuft auch ohne JavaScript (wird wegen Sicherheitsproblemen oft sogar via
Proxy herausgefiltert)
– und so weiter
Auch strategische Ziele können formuliert werden. Die Erfüllung derartiger Ziele kann allerdings meist nicht nachgewiesen werden – dann muss man auf die
Aufnahme in das Pflichtenheft verzichten.
Anschließend sollten Kosten und Zeit geschätzt und die anderen Ziele eventuell
angepasst werden.
Bei größeren Projekten werden teilweise Kosten- und Zeitpläne nur für die nächsten Schritte genauer spezifiziert und für spätere Schritte dagegen zunächst nur
grob festgelegt (höhere Fehlertoleranz).
Anmerkung 1
Eine Schätzung basiert auf vielen Unbekannten und macht daher keine exakten
Angaben über die echten Kosten und den echten Zeitbedarf. Ein guter Projektleiter zeichnet sich dadurch aus, dass seine Schätzungen im Mittel, d. h., wenn man
viele von ihm geleitete Projekt in Betracht zieht, richtig sind. Einzelne Projekte
kosten mal mehr, mal weniger als geschätzt, und sie dauern mal länger und mal
kürzer als geschätzt. Die Abweichungen von den realen Werten sollten umso kleiner sein, je häufiger ein Projektleiter ein Projekt derselben Art durchgeführt hat.
Die Unsicherheiten hinsichtlich der Kosten und der Dauer des ersten Marsfluges
sind wesentlich zahlreicher, als bei einem Architekten, der sein hundertstes Haus
baut. Im ersten Fall sind Schwankungen von vielen 100 % zu erwarten, im zweiten
Fall sollten sich die Abweichungen im einstelligen Prozentbereich bewegen.
Anmerkung 2
Im Pflichtenheft sollte nicht stehen, wie etwas zu realisieren ist. (Grobe) Vorgaben bezüglich der Ressourcen können allerdings über die Ziele gemacht werden
(z. B.: Software muss mit vorhandener Software kompatibel sein – Das ist Bestandteil der Funktionalität. Das Projekt hat 3 Mitarbeiter – Das ist Bestandteil
51
der Kostenvorgabe: Es wird Geld für 3 Mitarbeiter und 2 Rechner zur Verfügung
gestellt. Das heißt aber nicht, dass nicht 6 Halbtagskräfte eingestellt werden dürften. Und so weiter.)
Der Auftragnehmer sollte über die Ressourcenplanung selbstständig entscheiden
können. Bei Inhouse-Ressourcen kommt es dabei allerdings häufig zu Problemen,
wenn die Ressourcen auch von anderen Projekten oder Gruppen benötigt werden
(z. B. Netzspezialisten, Hardware etc.). Die Lösung dieses Problems sollte allerdings nicht heißen: „Jedes Projektteam versucht möglichst viele der benötigten
Ressourcen zu ergattern.“ In seinen Vorlesungen pflegte Prof. Ulrich Güntzer zu
sagen: „Wer knappe Ressourcen hortet, verknappt die Ressourcen weiter.“ Die
Lösung des Problems heißt Multiprojektmanagement (siehe Abschnitt 4.7).
Review
Genehmigung des Pflichtenheftes und Beschluss, die Designphase zu starten. Spätestens jetzt sollte ein Projektvertrag zwischen Auftraggeber und -nehmer geschlossen werden.
Die Spezifikationphase kann sich in mehrere Teilphasen untergliedern. Dabei
kann es, muss es aber nicht zu Zwischenreviews kommen.
Die Definitionsphase sollte allerdings immer mit einem Review beendet werden.
Dort werden sich Auftraggeber und Auftragnehmer spätestens einig, ob das Projekt gestartet wird und was dabei genau herauskommen soll.
Spätestens jetzt liegt ein offizieller Starttermin für das Projekt fest.
Vorbereitungsphase
Nun – d. h. bis zum offiziellen Starttermin – ist der Projektleiter spätestens gefordert, detaillierte Pläne zu erstellen sowie sich nach geeigneten Mitarbeitern und
anderen Ressourcen umzuschauen: Er weiß jetzt genau (oder sollte es zumindest
wissen), was zu tun ist.
Im Allgemeinen sollten die Pläne – zumindest in groben Zügen – bereits vorliegen. Auch ist oft schon ein Teil der zukünftigen Mitarbeiter bekannt und ein Teil
der benötigten Ressourcen vorhanden.
An der Feinarbeit kommt der Projektleiter allerdings nicht vorbei. Und zwar schon
bevor die Designphase beginnt.
Bei der Erstellung von Plänen kann ihm ein PM-Tool von Nutzen sein. Die Arbeit
abnehmen kann ihm ein derartiges Werkzeug allerdings nicht, denken er (oder sie)
selbst!
Typische Pläne
– Terminpläne mit Meilensteinen
52
– Kostenpläne (Wann fallen welche Kosten an?)
– Ressourcenpläne (Wann werden welche Ressourcen benötigt?)
– Aufgabenpläne (Wer ist mit welchen Aufgaben betreut?)
– Qualitätssicherung (Qualitätsmanagement)
– Risikovorsorge (Risikomanagement)
– Verfahren bei nachträglichen Änderungen (Änderungsmanagement)
– Benutzerschulung
Man beachte, dass Planung (im obigen Sinne) eigentlich ständig stattfindet. Es
gibt es oft keine dedizierte Feinplanungsphase – daher spreche ich auch von Vorbereitungsphase. Die Grobplanung kann schon im Rahmen der früheren Teilphasen erfolgt und genehmigt worden sein. Oder die Feinplanung liegt vollkommen
in der Verantwortung des Projektleiters und bedarf deshalb überhaupt keines formalen Reviews, sondern nur eines internen Reviews durch den Projektleiter. Falls
er dabei jedoch gravierende Zielkonflikte entdeckt, muss er vor Beginn der Designphase den Auftraggeber informieren, um eventuell die Ziele neu zu definieren
oder das Projekt abzubrechen.
Review
Eine Vorbereitungsphase zwischen Zielformulierung und echtem Projektstart gibt
es dennoch fast immer. Diese Phase bedarf – da sie sich meist nur mit Planung
und Ressourcenbeschaffung befasst – nicht unbedingt eines formalen Reviews,
da es den Auftraggeber nicht interessieren sollte und meist auch nicht interessiert, mit welche Ressourcen das Projekt durchgeführt wird. Auch hier gilt aber,
dass zumindest der Projektleiter oder ein Projektverantwortlicher (der nicht notwendigerweise auch der Projektleiter sein muss, sondern auch eine ranghöhere
Person des Auftraggebers sein kann) am Ende der Vorbereitungsphase Bilanz ziehen muss: Kann das Projekt starten oder nicht? Wenn nein, wird wiederum der
Auftraggeber informiert.
Fazit: Meist handelt es sich beim Vorbereitunsphasen-Review um ein projektinternes Review.
2.1.2 Designphase (Entwurfsphase)
Spätestens jetzt startet das Projekt offiziell. Es sollte einen griffigen Namen und
am besten ein griffiges Logo bekommen.
Die Designphase ist die wesentlichste Phase, da sie das Fundament für das spätere
Produkt legt. Gravierende Fehler aus der Designphase können später kaum noch
53
ausgebügelt werden, außer wenn das Projekt im Sinne des Spiralmodells (siehe
Abschnitt 2.2) realisiert wird.
Wesentlich Ziel der Designphase: Festzulegen wie das Pflichtenheft realisiert
wird? (Dort steht nur was realisiert werden soll.)
Typische Aufgaben in der Designphase
– Entwicklung von Datenmodellen, Schnittstellendefinitionen, Ablaufplänen,
Schaltplänen, Storyboards etc.
– (grobes) Mediendesign (Screendesign, Audiodesign etc. )
– Erstellung von Funktionsmodellen, Simulation etc.
– rapid Prototyping (evtl. schon in Vorstudie)
– Basteln von 3D-Modellen aus Holz, Pappe, Kunststoff (3D-Drucker!)
– Tests: Auswahl von geeigneter Zielhardware, -software, Programmiersprachen, Datenbanksysteme etc.
– Beginn der Dokumentation!!!!
(Auch Lasten- und Pflichtenheft sind Bestandteil der Dokumentation ⇒ Die
Dokumentation sollte eigentlich schon in vollem Gange sein.)
– Verfahren für
• Wartung, Versionspflege
• Backup und Recovery
• Qualitätssicherung und Tests
• Datenschutz, Datensicherheit
• Urheberrechte, Lizenzvereinbarungen
• Installation in Zielumgebung
• Umstellung von bisherigem Verfahren auf neues
(Bayerische Vereinsbank: Multimediaschulung für Windows NT)
• Schulung
Der Projektleiter muss entscheiden, welche Designmethoden und Designwerkzeuge eingesetzt werden (z. B. objektorientierte Modellierung gemäß UML), wer
welche Designaufgaben übernimmt, bis wann das Design steht etc.
Außerdem muss er mit der Soll-Ist-Überwachung beginnen: Wie weit weicht das
Projekt vom Plan ab? Gegebenfalls muss er gegensteuern. Darüberhinaus muss er
die Schätzungen für die Folgephasen verfeinern.
Hausbau ohne zentimetergenaue Baupläne: undenkbar!
Softwareentwicklung ohne Datenmodell und Design: der Regelfall!
(siehe S. 98 Kellner [2001]).
54
Wunschziel: Das Design beschreibt das Produkt so konkret, dass es nur noch realisiert (= kodiert zusammengebaut, -geschraubt, . . . ) werden muss. Heute wird
ein Projekt meist „agiler“ gemäß einem so genannten Spiralmodell (siehe Abschnitt 2.2) durchgeführt. Hier sieht das Wunschziel etwas anders aus: Das Design
beschreibt die nächste Projektversion so konkret, dass diese nur noch realisiert
werden muss.
Probleme
– Man kann keine „Lines of Code“ vorweisen.
– Die Projektdauer wird in Augen des Auftraggebers „künstlich“ verlängert.
– Der Auftraggeber will Ergebnisse sehen.
– Es blinkt und blitzt nichts.
– „Denken ist keine Arbeit.“
– Der „Hacker“ unter den Entwicklern will endlich richtig programmieren. Er
weiß eh, wie’s geht.
– Schlechte Projektleitung.
– Mangelhafte Kompetenz/Kreativität der Beteiligten.
– Sich an ein Design zu halten.
– Zeit drängt ⇒ „lieber anfangen“
Bei vielen Firmen ist Hacking verboten (wird trotzdem gemacht).
Grund: Firmen machen sich sonst von Hackern abhängig.
Unwartbarer Code kann nur weggeworfen und neu geschrieben werden.
Design wir oft nicht ernst genommen. Es gehört halt zu einem Projekt dazu (Kellner: Höflichkeitsakt). Man hält sich aber nicht das Design, sondern fügt es der
Projektdokumentation bei. Kellner: „Da ist alles sauber abgeheftet und stört nicht
bei der Arbeit.“
Designfehler sind verdammt teuer.
Beispiel: Y2K-Problem (Year-2000 problem)
Zweistellige Darstellung: 99 + 1 = 00 ⇒ 1999 + 1 = 1900
Hauptproblem: Finden von Problemcode in vielen Millionen Zeilen von Code
(LOC).
Hilfsprogramme zur automatischen Umsetzung: teuer
Erfolgsgarantie < 100 %
⇒ oftmals wurden mehrere verschiedene Tools parallel eingesetzt
⇒ Vervielfachung der Kosten
Dennoch kamen die Unternehmen nicht an der Handarbeit vorbei.
55
Bemerkung
Das Argument „Die Speicherplatzvorteile einer Zwei-Byte-Lösung waren vor 30
Jahren wesentlich, da Speicher knapp war. Deshalb war das Y2K-Problem unvermeidbar.“ zieht nicht. In zwei Byte passen mehr als 65000 Jahre. Selbst in einem
Byte bringt man 256 Jahre unter. Das heißt: Zwei Byte für 100 Jahre bedeutet
Speicherplatzverschnitt.
Fazit: Es handelt sich ausschließlich um ein schlechtes Design. Es wurde gewählt,
weil diese Art der Datumsdarstellung allgemein üblich war und ist, und sich niemand Gedanken über die Konsequenzen gemacht hat. Die Zwei-Byte-Codierung
ist soweit vorbereitet, dass auch in den ersten zehn Jahren des neuen Jahrtausends
die meisten Menschen die Jahre mit 00(?), 01, 02, 03,. . . abkürzen, anstelle von 0,
1, 2, 3,. . . Kaum einer schreibt 17. 3. 6, sondern 17. 3. 06 oder 17. 03. 06. Warum?
Aus reiner gesellschaftlicher Konvention!
Weitere Datums-Probleme:
Unix: 1. 1. 1970 + 231 sec = 19. 1. 2038, 3:14:08 Uhr (vgl. Wikipedia [2011d])
DOS: 1980 − 2108 (vgl Tannenbaum [2002], Garantie bis 2035 – Danach ist laut
Redmont DOS tot)
Windows95 (ohne Patch): – 2000 (z. B. 2003 = C3, eigene leidvolle Erfahrung;
vgl. Microsoft [1999a])
Windows95 (mit Patch): Garantie bis 31. 12. 2035 (vgl. Microsoft [1999b])
weitere 4-Byte-Speicherplatz-Datums-Normen: ISO, Europa etc.
Problemlösung: 8 Byte =
ˆ 1018 sec = 3 · 1011 Jahre
Wenn die Menschheit nicht länger als die Dinosaurier leben (200 Mio Jahre) reichen 7 Byte für eine sekundengenaue Darstellung. :-)
Anmerkung
Es gibt viele verwandte Probleme wie z. B. das 49,7-Tage-Problem (4-Byte-Zähler für millisekundengenaue Timer beginnen nach 4 294 967 296 Millisekunden =
49,7 Tagen wieder bei Null), Dow-Jones-Index > 10 000 etc.
Beispiel Kuka Roboter GmbH: Bei einem Praktikantenbesuch erzählte mir ein
Mitarbeiter, dass bestimmte Roboter alle 49,7 Tage für mehrere Stunden ausfielen. Der Fehler wurde allerdings meist erst nach 99,4 Tagen entdeckt, da Roboter
normalerweise immer Samstags installiert werden, um den Arbeitsablauf nicht zu
behindern (49,7 Tage später ist ein Sonntag).
Geschätzte Kosten der Designfehler für das Y2K-Problem
(vgl. Berghel [1998])
56
USA: 8.465.060 Personenmonate, $70.753.562.795 Kosten für Y2K-spezifische
Softwareprobleme (eine derartige präzise Schätzung halte ich allerdings für Humbug)
Weitere $125 Milliarden um Datenbanken und Data Warehouses zu reparieren.
Weitere Schätzungen
(vgl. Jansen und Neumann [1997])
Juli 1997, konkrete Aktionen von deutschen Unternehmen zur Behebung des
Y2K-Problems:
4 % Planungsphase
13 % mit Korrekturen begonnen
21 % sehen keine Probleme
28 % sind unentschlossen
34 % noch keine Aktion geplant
Viele Unternehmen und Behörden behandelten das Y2K-Problem lange Zeit als
Randproblem, das sich irgendwie von selbst lösen sollte. Eine Mehrheit der Unternehmen hatte kein Budget für die Umstellung eingeplant.
Rund 30% alle Computersysteme waren nicht Jahr-2000-kompatibel.
Giga Information Group: Viele Firmen werden das Jahr 2001 nicht mehr erleben.
So schlimm ist es dann doch nicht gekommen.
Erfahrungsgemäß werden nur 14 % aller größeren Entwicklungsvorhaben fristgerecht fertiggestellt.
Kosten
(vgl. Jansen und Neumann [1997])
Spezialisten kosten 1000 DM/Tag, Tendenz steigend
(Großbritannien 3000 DM/Tag)
Umstellungsdauer je Programm: 20 % benötigen 35 h, 50 % benötigen 20h,
30 % benötigen 10 h ⇒ 20 h/Programm
Personenjahr: 1600 h, 125 000 DM (Anmerkung von WK: zu billig geschätzt)
Kosten: $600 Milliarden weltweit (Schätzung der Gartner Group laut Jansen und
Neumann [1997])
Hohe Reenineering-Kosten ⇒ IT-Ersatzinvestitionen werden in den kommenden
Jahren reduziert.
57
Beispiel ARAG
(vgl. Biskamp und Kunisch-Holtz [1998], Kunisch-Holtz [1998])
1989 provisorische Umstellung (da 10-Jahres-Policen ab 1990 nicht mehr erfasst
werden konnten).
Ab 1996 Analyse einer dauerhaften Umstellung.
Abschluss des Projektes: 2005 – bis dahin konnte man mit den Provisorien von
1989 leben.
„Externer“ Betreuer der Umstellung: Alldata, IT-Tochter der ARAG
Lösung, um 3800 Datenbanken nicht auch noch neu aufbauen zu müssen:
– Vierstellige Jahreszahlen werden in zweistellige Felder gepackt.
– Saubere Lösungen werden später angestrebt.
Die Alldata benötigt etwa 20 PJ um 4,6 Millionen Zeilen Code zu prüfen. Kosten:
5,6 Millionen Mark =
ˆ 1,20 DM/LOC. Diese Umstellungskosten sind sehr günstig,
da neuere Schätzungen von $1,50/LOC = 2,70 DM/LOC ausgehen.
Grund: Nur 250 000 Zeilen „Problemcode“. Der Rest konnte automatisch umgestellt werden.
Projektleiter: „Je älter ein Programm, desto spannender wird’s.“
Die Alldata gibt keine vertragliche Garantie auf 100 % richtige Umstellung. Die
Tests geschehen nicht in Simulationen, sondern in der Praxis.
BHF-Bank
(vgl. Biskamp und Kunisch-Holtz [1998],Biskamp [1998])
Umstellung von 6000 individuell entwickelte Anwendungen
(obige Kostenschätzung: 6000 · 20 h = 80 PJ)
Umstellung durch verschiedene Dienstleiter + eigene Mannschaft
Probleme: Suche nach Datumsfeldern in 10 Millionen LOC
Abnahmetests bei Projektende
Filetransfer von und zu Partnerunternehmen (Schnittstellendefinitionen)
Kosten:
ca. 15 Millionen Mark (grobe Schätzung; exaktes Volumen ist unbekannt; die Bank muss auf jedem Fall zahlen)
Projektleiter Moses: „Wenn wir als Bank zwei Tage nicht am elektronischen Zahlungsverkehr hängen, dann sind wir aus dem Geschäft.“
Notfallpläne: zusätzliche Mitarbeiter werden von anderen Projekten abgezogen
58
Vorbeugung gegen Notfälle: Cleanmanagement
Das heißt, dass ein Programm, das den Jahr-2000-Abnahme-Test bestanden hat,
bis zum Ende des Tests nicht mehr verändert werden darf (Ausnahme: neue
Jahr-2000-Probleme).
⇒ In Einzelfällen können andere Bugs monatelang nicht behoben werden.
Phase I (1996):
Strategie und Bestandserfassung
Phase II (1996/97): Detail-Analyse und Planung
Phase III (1997/98): Implementierung
Phase IV (1998/99): Gesamtintegrationstests
Beispiel einer typischen Design-Entscheidung
Sortierverfahren: Welches ist für mein Problem geeignet?
Beispiel „Bubblesort“ (Knuth [1997]):
Führe Folgendes solange durch, bis keine Vertauschung mehr stattgefunden
hat:
Gehe die ganze Objektliste mit Ausnahme des letzten Elements durch:
Wenn das aktuelle Objekt und sein rechter Nachbar in der falschen
Reihenfolge stehen, vertausche sie.
Beobachtung
– Dieser Algorithmus hängt von keiner Programmiersprache ab.
⇒ Die zu verwendende Sprache kann (relativ) unabhängig von den zu verwendenden Algorithmen gewählt werden.
– Der Algorithmus legt sich noch nicht auf eine Datenstruktur fest (Array,
verkettete Liste, SQL-Tabelle etc.).
– Der Algorithmus legt sich noch nicht auf einen Elementtyp fest (Integer,
String, Record etc.).
– Der Algorithmus legt sich noch nicht auf einen Vergleichsoperator fest (Integervergleich, Stringvergleich etc.)
– Der Algorithmus hat eine mathematisch bestimmbare Komplexität, nur abhängig von der Anzahl n der zu sortierenden Elemente (sofern die zugrundeliegende Datenstruktur es erlaubt, die Objektliste in linearer Zeit zu durchlaufen und zwei Elemente in konstanter Zeit zu vertauschen):
im besten Fall n − 1 Vergleiche, im schlechtesten Fall n · (n − 1) Vergleiche,
im Mittel O(n2 ) Vergleiche.
Es gibt noch viele weitere Sortierverfahren (siehe beispielsweise Knuth [1997])):
59
Quicksort
Hauptspeicherverfahren, im Mittel O(n · log n), im schlechtesten Fall O(n 2 )
(oft bei bereits sortierten Mengen)
Mergesort
auch für Datenmengen, die nicht in den Hauptspeicher passen geeignet, im
Mittel sowie im schlechtesten Fall O(n · log n), im Mittel um einen konstanten Faktor langsamer als Quicksort.
parallele Sortierverfahren
noch Forschungsgegenstand; das theoretische Optimum liegt bei O(log n);
Richard Cole hat z. B. zwei Algorithmen vorgestellt, die ein Menge von Objekten mit dieser Zeitkomplexität sortieren können, allerdings werden dafür
n Prozessoren benötigt (Cole [1988]); wenn die Anzahl der Elemente auf ein
paar Milliarden beschränkt ist (= alle praktischen Fälle) sind effiziente parallele Sortierverfahren mit einer fixen Anzahl von Prozessoren mit der Komplexität O(n) bekannt (Obermaier [1993]).
Quicksort ist im Mittel um einen konstanten Faktor schneller als Mergesort, kann
diese Geschwindigkeit aber nicht garantieren. Bubblesort ist für sehr kleine Datenmengen (< 100 Elemente) das schnellste Verfahren. Quicksort und Bubblesort
sortieren „in place“, d. h. ohne Zusatzspeicher.
Im Laufe der Designphase muss eine Entscheidung getroffen werden, welches
Verfahren verwendet wird.
Einflussfaktoren: Anzahl der zu sortierenden Elemente, verfügbare Datenstrukturen, verfügbare Software (Wiederverwendung), garantierte Antwortzeiten etc.
Beispiel: 1 000 000 Elemente zu sortieren, 1 000 000 Vergleiche pro Sekunde.
O(n2 ): 1012 Vergleiche ⇒ 106 Sekunden · const1 = 11, 6 Tage · const1
O(n · log n): 106 · 20 Vergleiche ⇒ 20 Sekunden · const2
O(n): 106 Vergleiche pro CPU ⇒ 1 Sekunde · const3
O(log n): 20 Vergleiche pro CPU ⇒ 20 Mikrosekunden · const4
Quicksort kann wegen Worst-case-Komplexität keine Antwortzeiten garantieren,
Mergesort schon!
Aufgrund solcher and ähnlicher Probleme müssen Entscheidungen vor dem Programmieren getroffen werden. Während der Entwicklung wird oft nur mit geringen Datenmengen gearbeitet – da funktioniert auch der Bubblesort – die böse
Überraschung kommt dann im Realbetrieb.
Rucksack-Programmierung
Ohne sauberes Design kommt es während der Entwicklung und noch mehr während des laufenden Betriebs im Rahmen der Wartung zur so genannten RuckDraft (4. Oktober 2012)
60
sack-Programmierung. Wenn ein im Design übersehener Sonderfall zu Problemen
führt, wird ein Rucksack zum Code hinzugefügt:
if <Sonderfall> then <Rucksack> else <alter Code>
Viele Rucksäcke machen ein Programm unwartbar.
Diese Technik kennen übrigens auch E-Techniker. Wenn sich im Platinen-Layout
ein Fehler befindet, wird manchmal eine „Rucksack-Platine“ angefertigt, die auf
die ursprüngliche Platine montiert wird und den fehlerhaften Teil ersetzt.
Teilphasen
Auch die Designphase kann in mehrere Teilphasen (mit Reviews) unterteilt werden:
– Entwicklung von Basiskonzepten
– Auswahl geeigneter Hardware, Software-Tools, Algorithmen etc.
(Vergleich von 20 objektorientierten Datenbanksystemen,
Vergleich von verschiedenen Präsentationstools,
Leistungsmessungen verschiedener Kompressions-Algorithmen,
Bestimmung der Qualität verschiedener Druckformate
etc.)
– Implementierung eines Prototypen (rapid Prototyping)
– Erstellung des endgültigen Designs (Datenmodelle, Storyboards etc.)
– usw.
Review
Am Ende der Designphase muss ein Review erfolgen.
Die Ergebnisse des Designs müssen dem Auftraggeber vorgestellt werden, insbesondere, wenn diese ernsthafte Änderungen an einen oder mehreren Projektzielen
zur Folge haben.
Die Entscheidung, die dann getroffen wird lautet wie immer:
weiter (mit oder ohne Zieländerung):
Das Projekt wird gemäß Design realisiert.
zurück (mit oder ohne Zieländerung):
Das Design wird überarbeitet.
stopp:
Das Projekt wird ergebnislos beendet.
Es muss allen Beteiligten klar sein, dass im nächsten Schritt Designänderungen
nur noch schwer durchzuführen sind – und sehr teuer werden können – sofern das
Projekt gemäß dem Wasserfallmodell (Abschnitt 2.2) entwickelt wurde.
61
Jetzt ist jede Struktur, jede Oberfläche, jedes Modul, jeder Datentransfer definiert.
Es darf nicht sein, dass während der Fertigungsphase neue Module und Datenstrukturen entstehen (Ausnahme: Es wurde eine explizites Änderungsmanagement
etabliert). Eine bessere Alternative ist es, Design- und Fertigungsphase zyklisch
abzuwechseln, um die Kosten von Designfehlern in den Griff zu bekommen (vgl.
Abschnitt 2.2).
Beispiel Hausbau
Solange nur Architektenpläne gezeichnet werden, kann eine Wand ganz einfach
verschoben oder ein zusätzliches Leerrohr eingezogen werden.
Wenn die Wände aber mal stehen, sind Veränderungen nur mit zusätzlichen Kosten möglich.
2.1.3 Fertigungsphase (Entwicklung)
In dieser Phase wird das Produkt realisiert.
Funktionsbeschreibungen und Design liegen vor, „Kreativität“ ist nicht mehr gefragt, „gute Ideen“ schaden meist mehr, als dass sie nützen.
Es kommt allerdings immer wieder zu Überraschungen:
– Probleme treten auf, die im Design nicht berücksichtigt wurden.
– Der Auftraggeber hat neue Wünsche (hier sind Diplomatie und starke Nerven vom Projektleiter gefordert). Auch hier gilt wieder: Ein gut durchdachtes
Änderungsmanagement sollte auf keinen fehlen.
– Das Team folgt nicht dem Design (schlechtes Design?, schlechte Menschenführung?, Design nur Show für Management?).
Typische Aktivitäten in der Entwicklungsphase:
– Einrichten der Entwicklungsumgebung
– Entwicklung von Software
– Erstellung von Medien-Objekten (Audio, Video, Bild, Text)
– Erstellung des Gesamtsystems
– Testen des Produktes (Funktionalität + Qualität)
– Realisierung von Datensicherheit, Datenschutz, Backup und Recovery etc.
– Schreiben des Benutzerhandbuches und anderer Dokumentationen wie
Schulungsunterlagen, Systemhandbuch, Installationsanleitung etc.
62
– Vorbereitung der Projektübergabe (Systemumstellung, Abnahme durch den
Auftraggeber etc.)
Auch hier kann es wieder viele Teilphasen geben:
– Erstellung von Medien-Objekten und Systemkomponenten
– Integrations- und Dokumentationsphase
– Qualitätssicherung
– α-Testphase
– β-Testphase
– γ-Testphase
Reviews
Am Ende einer Fertigungsphase liegt Folgendes vor:
– Das fertige Produkt bzw. das fertige Teilprodukt
– Die fertige Dokumentation bzw. die fertige Teildokumentation (Benutzerhandbuch, Systemhandbuch etc.)
– Nachweise über Projekterfolg in Hinblick auf die Ziele Funktionalität, Qualität, Termine und Kosten
Es gibt zahlreiche weitere „Produkte“, die am Ende einer Fertigungsphase vorliegen können:
– Ausgebildete Betreuer und/oder Benutzer
– Anweisungen für:
• Installation
• Wartung + Versionspflege
• Datenschutz + Datensicherheit
• Backup + Recovery
• etc.
– Detailpläne für Einführung und Umstellung
Der Review dient dazu, aufgrund dieser Unterlagen zu entscheiden, ob das Produkt eingesetzt bzw. das Teilprodukt als Basis weiterer Entwicklungen dient und
ab wann.
2.1.4 Einführungsphase
Typische Aktivitäten (evtl. auch Teilphasen):
– Installation in der Zielumgebung
63
– Testen und Pilotläufe im realen Umfeld (Systemtests)
– Inbetriebnahme
– Tuningmaßnahmen
– Erstellung von Mängellisten (Mängel gibt es jetzt immer noch)
– Übergabe an die Benutzer, das Rechenzentrum, die Systembetreuer
– Umstellung (inklusive Unterstützung durch Projektteam bis zum erfolgreichen Abschluss der Umstellung)
– Analyse während des Realbetriebs
• Wird das Produkt korrekt genutzt?
• Wird es akzeptiert?
• Wird der erwartete Nutzen (voraussichtlich) erreicht?
• Greifen die Maßnahmen zu
∗ Benutzerunterstützung (Online-Hilfe!!!)
∗ Datenschutz und Sicherheit
∗ Qualitätssicherung
∗ etc.
– Schulung
Daneben müssen Projektabschlussarbeiten durchgeführt werden:
– Abnahmeprotokoll
• Abschlussbericht + Erfahrungsbericht
• Testbericht
• Nachweis des Projekterfolges
• Nachkalkulation (abschließender Soll/Ist-Vergleich)
– Analyse von Planabweichungen (Ursachen?)
– Auflösung des Projektteams
2.1.5 Review
Im Review findet die Abnahme durch den Auftraggeber statt.
Achtung: Die Abnahmekriterien müssen bereits vorher schriftlich vereinbart worden sein. Insbesondere muss klar sein, welche Testergebnisse vorliegen müssen.
2.1.6 Die Nutzungs- und Aufarbeitungsphase
Während der Nutzungsphase müssen Wartungs- und/oder Pflegearbeiten durchgeführt werden.
64
Wartung: Beseitigung von Problemen
Pflege:
Weiterentwicklung
Grady [1992]:
– Auf 10 Fehler, die vor der Produktfreigabe durch Testen gefunden wurden, kommt ein Fehler, der nach der Freigabe gefunden wird (z. B.: „Zeitsprung“-Fehler wie Y2K)
– Es dauert die 4- bis 10-fache Zeit, um in einem umfangreichen, im Einsatz
befindlichen Software-Produkt einen Fehler zu finden und zu beheben, als in
einem Produkt kurz vor oder kurz nach der Freigabe.
Schlechte Entwicklungsarbeit
⇒ Fehlerkorrekturen während der Wartung (korrigierende Aktivitäten)
Sehr schlechte Entwicklungsarbeit
⇒ Neu- oder Umentwicklungen während der Wartung (sehr schlecht, aber leider
weit verbreitet)
Software, die erstmals freigegeben wurde, arbeitet normalerweise ineffizient, da
sie noch nicht optimiert wurde.
⇒ Optimierung während der Wartung (perfektionierende Aktivitäten)
Änderungen in der technischen Umgebung (z. B. neue HW), der Funktionen (z. B.
durch Gesetzesänderungen), der Oberflächen etc.
⇒ Anpassung während der Pflege (anpassende Aktivitäten)
Achtung: Wartung und Pflege machen einen Großteil des Aufwands während
des Lebenszyklusses eines Produktes aus: 2/3 – 4/5 (67 %–80 %) des Gesamtaufwands (QUELLE FEHLT [????]).
Aufarbeitungsphase
Für den Projektleiter ist das Projekt beendet. Für Pflege und Wartung ist meist
jemand anders zuständig.
Allerdings sollten er oder besser noch das ehemalige Team das Projekt noch einmal aufarbeiten.
Es gibt drei wesentliche Fragen, die beantwortet werden sollten:
1. Was leistet das Produkt, und was sollte es leisten?
2. Wie wurde im Projekt geschätzt und geplant? Wie wurden Termine und Budget eingehalten?
3. Wie war und ist die Zufriedenheit von Benutzern, Auftraggeber, Management,
Team, Projektleiter und externen Partnern?
Achtung: Es geht nicht um Anschuldigungen und Rechtfertigungen.
65
Neubewertung
Nach längerer Zeit (sechs bis zwölf Monaten) kann das Projektergebnis noch einmal neu bewertet werden.
– Hat sich der erwartete Nutzen eingestellt?
– Wenn nein, warum nicht?
Allerdings wird dies meist nicht gemacht:
– Es seien keine Kapazitäten frei (Personal und Zeit).
– Es sei viel zukunftsorientierter nach vorne zu blicken.
– Ändern kann man es sowieso nichts mehr.
Ja! Aber – man kann viele Problemen in zukünftigen Projekten vermeiden.
In seinem Roman „Der Termin“ (DeMarco [1998]) erfindet Tom DeMarco den Job
„Manager der Software-Metrik-Gruppe“, einen „Software-Archäologen“. Dessen
Aufgabe ist es, alle möglichen Informationen über alte Projekte „auszugraben“,
um damit die Schätzungen für aktuelle und zukünftige Projekte deutlich zu verbessern.
Der Projektmanager Tomkins verliert dadurch seinen persönlichen Assistenten,
weil dieser die besten Beziehungen zu den meisten Mitarbeitern im Unternehmen
hat. Der Berater des Projektmanagers gibt einen triftigen Grund dafür an, diesen
Verlust zu akzeptieren:
„Wir verlieren ihn nicht, wir geben ihm nur einen Job, bei dem er alle seine Talente
einsetzen kann. Das ist unsere Aufgabe als Manager. Mitarbeiter dort einzusetzen,
wo sie ihre Fähigkeiten und Talente am wirkungsvollsten einbringen können. Das
ist es, was Management wirklich bedeutet.“
2.2 Wasserfall- und Spiralmodell
Das im letzten Abschnitt vorgestellte Modell wird in der Fachliteratur Wasserfallmodell genannt. Dieser Begriff geht auf W. W. Royce [1970] zurück (vgl.
Wasserfall-Modell [2005]). Er verwendet zwar nicht den Begriff „waterfall model“, die von ihm verwendete Grafik erinnert aber an einen Wasserfall.
Royce definiert dabei die Phasen: System Requirements, Software Requirements,
Analysis, Program Design, Coding, Testing and Operations.
Das von mir im letzten Abschnitt vorgestellte Wasserfallmodell ist im Prinzip wie
folgt aufgebaut (graphisch angelehnt an Royce):
66
weiter
Phase 1
Review 1
weiter
zurück
Phase 2
Review 2
stop
weiter
zurück
Phase 3
Review 3
stop
weiter
zurück
Phase 4
Review 4
stop
zurück
stop
Das Wasserfallmodell hat einen prinzipiellen Nachteil. Wenn am Ende einer
großen und damit langen und teuren Phase im Review ein Problem entdeckt wird,
kosten ein oder gar mehrere Schritte zurück viel Zeit und Geld.
Schon Royce hatte gefordert, den Schritt von einer Phase zur nächsten (heute Review genannt) mindestens zweimal zu durchlaufen. Er schlug auch vor, einzelne
Phasen je nach Komplexität mehrfach zu durchlaufen.
Später hat Barry Boehm den Gedanken, einzelne Phasen mehrfach zu durchlaufen, weiterentwickelt (Boehm [1988]). Sein Modell wird durch eine Spirale visualisiert, in der bestimmte Phasen immer wieder durchlaufen werden und dabei auf
die Ergebnisse des letzten Zykluses zurückgreifen. Barry Boehm nennt das Modell daher auch „Spiralmodell“. Er schlägt folgende vier Phasen vor, die zyklisch
mehrmals durchlaufen werden:
1. Klärung der Ziele, Anforderungen und Randbedingungen
2. Risikoanalyse, Erstellung eines Prototypen
3. Implementierung und Test
4. Review (Auswertung des aktuellen Zykluses, Planung des nächsten Zykluses
oder Projektende/-abbruch)
67
Ph. 1d
Ph. 1c
Ph. 1b
Ph. Ph. Ph. Ph.
4d 4c 4b 4a
Ph. 1a
Ph. Ph. Ph. Ph.
Ph. 3a 2a 2b 2c 2d
Ph. 3b
Ph. 3c
Ph. 3d
Am Modell von Boehm fällt auf, dass er ein großer Verfechter von Risikomanagement und Prototyping ist. Prinzipiell lässt sich jedoch sein Vorschlag auf jedes
Wasserfallmodell anwenden. Die Vorteile liegen auf der Hand: Ein Rückschritt
um eine oder gar mehrere Phasen ist wesentlich billiger und weniger zeitintensiv
als beim Wasserfallmodell. Design-Entscheidungen werden schrittweise getroffen und anschließend gleich überprüft. Auftretende Probleme werden frühzeitig
erkannt.
Ich schlage daher folgendes Modell vor: Nach Abschluss der Spezifikationsphase
(d. h., wenn eine Spezifikation vorliegt), werden Design und Fertigungsphase im
Sinne des Spiralmodells zyklisch durchgeführt.
In jedem Zyklus werden folgende Schritte durchgeführt:
1. Design
2. Implementierung
3. Test (evtl. mit Implementierung verschränkt)
Nach jedem Schritt wird ein internes Review durchgeführt, nach jedem Zyklus
oder einer gewissen Anzahl von Zyklen wird jeweils ein großes Review mit dem
Auftraggeber durchgeführt (Meilenstein).
Heutzutage hat sich im Projekt-Management ein neues Modewort etabliert: agil.
Man spricht von agilem Projekt-Management, agilen Prozessen etc. Das Wort agil
steht dabei für leicht, flexibel. (siehe z. B. Oestreich und Weiss [2008])
Der erste Vertreter des agilen Software-Entwicklungsprozesses war das Extreme
Programming von Kent Beck (Beck [2000]). Weitere Modelle, wie z. B. der Rational Unified Process (Jacobson et al. [1999], IBM [2011]) oder Scrum (Schwaber
[2004]), folgten.
68
Allen gemeinsam ist es, kurze Iterationszyklen einzusetzen. Also kann mit Fug
und Recht behauptet werden, dass Boehm mit dem Spiralmodell eine der wesentlichen Grundlagen des agilen Projektmanagements eingeführt hat.
2.3 V-Modell XT
(geschützte Marke der Bundesrepublik Deutschland)
Dieses Kapitel basiert auf dem Aufsatz: Bundesrepublik Deutschland [2004].
Das V-Modell definiert einen Leitfaden zum Planen und Durchführen von Entwicklungsprozessen unter Berücksichtigung des gesamten System-Lebenszykluses:
– Es definiert die zu erstellenden Projektergebnisse.
– Es legt Verantwortlichkeiten eines jeden Projektbeteligten fest (Auftragnehmer + Auftraggeber).
– Es regelt detailliert „Wer“ „Wann“ „Was“ in einem Projekt zu tun hat (auch
die Kooperation zwischen Auftraggebern und -nehmern).
– Andere Richtlinien (ISO-Standards, Verfahrensanweisung CPM der Bundeswehr, Vorgänger V-Modell 97) sind weniger konkret, aber noch im Gebrauch.
– Für Projekte in Unternehmen und Einrichtungen des öffentlichen und militärischen Bereichs gedacht sowie für Behörden und Dienststellen des Bundes
und der Bundeswehr.
– Auch für kleine mittelständische Unternehmen geeignet.
– Vertragsgrundlage, Arbeitsanleitung, Kommunikationsbasis
– Anwendbar auf möglichst viele Projektkonstellationen (Anpassung an konkretes Projekt heißt Tailoring).
– Zweistufiges Verfahren für Pflege und Erweiterung des V-Modells selbst;
Innovationszyklen in vergleichsweise kurzen Abständen.
(Fast) jedes Projekt, das gemäß dem V-Modell durchgeführt wird, besteht aus zwei
Projekten: einem Projekt aus Sicht des Auftraggebers (AG) und einem Projekt aus
Sicht des Auftragnehmers (AN). Für Projektphasen, die von beiden gemeinsam
beendet werden, müssen jeweils bestimmte, während der Projektphase vom AN
oder AG erstellte Dokumente von beiden akzeptiert werden.
69
AG AN
Projekt 2
definiert
AG AN
Projekt 1
genehmigt
AG
Anforderungen3
festgelegt
AG
Projekt
4
ausgeschrieben
AN
Angebot 5
abgegeben
AG
AN
Änderungsplan
festgelegt 14
AG AN
Projekt 6
beauftragt
AG AN
Abnahme
erfolgt 13
Verifizierung
Validierung
AN
System
7
spezifiziert
System
entworfen
AN
Lieferung 12
durchgeführt
AN
8
AN
Feinentwurf 9
abgeschlossen
AG
AN
15
Projekt
abgeschlossen
System
integriert
AN
11
AN
Systemelemente
realisiert
10
Spezifikation und Zerlegung Realisierung und Integration
Zyklen möglich (über Änderungspläne)
Dieser allgemeine Phasenplan kann durch Tailoring für ein bestimmtes Projekt
konkretisiert werden. Zum Beispiel kann ein Projekt mit zwei Zyklen definiert
werden:
1. Zyklus: Entwicklung eines Prototyps
2. Zyklus: Entwicklung des eigentlichen Systems
Besonderheiten des V-Modell XT
– eine Systementwicklung = zwei V-Modell-Projekte
(Systementwicklungsprojekt eines Auftraggebers +
Systementwicklungsprojekt eines Auftragnehmers)
– Schnittstellen zwischen beiden Projekten sind genau beschrieben
– Ausschreibung enthält Lastenheft + Vorgaben für Projekthandbuch
70
Projekt 1
genehmigt
Projekt
definiert
Prototyp
Projekt 6
beauftragt
2
4
Projekt
ausgeschrieben
Anforderungen
3
festgelegt
Abnahme
erfolgt 13
Änderungsplan
14
festgelegt
System
Projekt 6
beauftragt
Abnahme
erfolgt 13
15
Projekt
abgeschlossen
Abbildung 2.1: Phasenplan eines Systementwicklungs-Projektes mit PrototypEntwicklung aus Sicht des Auftraggebers (Tailoring-Ergebnis)
– Angebot enthält vertragsrelevante Teile des Projekthandbuches + Qualitätssicherungshandbuch
– Angebotsannahme endet mit Vertrag
– Pflichtenheft = Gesamtsystem-Spezifikation
– Projektstatusberichte: Projektfortschritt, -planung, Steuerungsmaßnahmen,
Qualitätssicherung, Problem-/Änderungslisten
– Lenkungsausschuss + Änderungsgruppen: beide Parteien sind vertreten
– Zwischen- + Endprodukte werden durch Lieferung an den Auftraggeber
übermittelt
– Validierung (Eignung des Produktes bezogen auf Einsatzzweck, „Are we
building the right product?“)
Verifikation (Produkt stimmt mit Spezifikation überein, „Are we building the
product right?“)
– Abnahmeerklärung des Auftraggebers nach Lieferung
– Projektabschlussbericht des Auftragnehmers
– bei notwendigen Änderungen kann zu früheren Phasen zurückgesprungen
werden (AG: Projekt beauftragt, Anforderungen festgelegt etc., AN: System
71
spezifiziert etc.)
– Auftragnehmer kann als Auftraggeber für Unterauftragnehmer fungieren ⇒
zwei weitere Teilprojekte gemäß V-Modell
– große Projekte müssen in Teilprojekte unterteilt werden
– Tailoring: Anpassung des V-Modells an konkretes Projekt
– Entwicklung gemäß dem Spiralmodell ist möglich
(Zyklen über das „V“ einschließlich Änderungsmodul)
AG AN
Projekt 1
genehmigt
AG AN
Projekt 2
definiert
AG
Anforderungen3
festgelegt
AG
Projekt
4
ausgeschrieben
AN
Angebot 5
abgegeben
AG
AN
Projektfortschritt
überprüft
14
AG
Iteration
geplant
AG AN
Projekt 6
beauftragt
AN
15
AG AN
Abnahme
erfolgt 13
AN
System
7
spezifiziert
System
entworfen
AN
Lieferung 12
durchgeführt
Verifizierung
AN Validierung
8
AN
Feinentwurf 9
abgeschlossen
AG
AN
Projekt
16
abgeschlossen
System
integriert
AN
11
AN
Systemelemente
realisiert
10
Spezifikation und Zerlegung Realisierung und Integration
Zyklen möglich (über Änderungspläne)
Abbildung 2.2: Aktualisierte Version V1.3 des V-Modell XT (V-Modellr XT
Autoren [2006])
72
Kapitel 3
Schätzung
Schätzungen (Zeit, Kosten und auch Ressourcen) werden immer schon in den
ersten Projektphasen (spätestens in der Definitionsphase) erstellt und benötigt.
Diese primären Schätzungen werden allerdings laufend angepasst.
Hauptproblem: In den frühen Phasen eines Projektes kann der Aufwand aufgrund sehr vieler unbekannter Größen meist nicht genau abgeschätzt werden. Andererseits will der Auftraggeber wissen, was es kostet und wann es fertig ist.
1. Lösung: Man legt sich nicht fest
⇒ kein Projekt
2. Lösung: Man sagt irgendein Datum und irgendeinen Preis
⇒ politische Daten, die nichts mit dem Projekt zu tun haben
⇒ sicherlich große Abweichungen
3. Lösung: standardisierte oder individuelle Schätzmethoden
Hermann Josef Abs, Karl Valentin, Mark Twain, Winston Churchill etc.: „Prognosen sind besonders dann schwierig, wenn sie sich auf die Zukunft beziehen.“
1. Grundregel: Schätzungen sind keine Weissagungen, d. h. keine verbindlichen
Voraussagen.
2. Grundregel: Je ferner die Zukunft, desto schwieriger sind die Schätzungen
Die Schätzungen werden während des Projektes laufend überwacht und so früh
wie möglich korrigiert. Also nicht erst am Ende der Projektlaufzeit (nachsehen)
nachsehen, was noch zu tun ist und dann eine Verlängerung um beantragen (vgl.
Toll Collect).
3.1 Die Schätzgrößen
Die Zielparameter Zeit, Kosten, Funktionalität und Qualität beeinflussen die
Schätzung.
73
Funktionalität
Qualität
+
+
-
-
+ +
Kosten
Zeit (Dauer)
Wenn an einem Parameter gedreht wird, hat das einen Einfluss auf einen oder
mehrere andere Parameter.
Im Teufelsquadrat von Sneed [1987] ist die Produktivität eines Entwicklungssystems als viereckige Fläche dargestellt. Der Flächeninhalt muss (in weiten Teilen) konstant bleiben, auch wenn die Ziele geändert werden, da die Produktivität
i. Allg. durch keine wie auch immer geartete Maßnahmen kurzfristig verbessert
werden kann (Produktivitätsverbesserungen sind nur mit langer Vorlaufzeit möglich; DeMarco [1998]). Das heißt, wenn zum Beispiel mehr Funktionalität in weniger Zeit erstellt werden soll, leidet darunter die Qualität und die Kosten steigen
(Überstunden, bessere Werkzeuge, externe Experten etc.).
Noch eine Warnung: Es ist insbesondere nicht möglich, die Produktivität eines
Teams durch Vergrößerung beliebig zu steigern, da der Kommunikationsaufwand
wächst. Es gibt nicht nur bei Parallelrechnern keinen optimalen Speedup, sondern auch bei parallel arbeitenden Menschen. Eine Vergrößerung eines Teams hat
zudem zunächst einen negativen Effekt: Neue Mitglieder müssen eingearbeitet
werden, alte Mitglieder werden dadurch von ihrer eigentlichen Arbeit abgehalten. Außerdem gilt grundsätzlich: Ein überbesetztes Team leistet stets weniger als
ein richtig besetztes. Das heißt aber nicht, dass sich die optimale Teamgröße im
Verlauf des Projektes nicht ändern kann. Im Allgemeinen ist es gut, ein Projekt
mit einem kleinen Team zu beginnen und dann, wenn alles spezifiziert ist und
es nur noch um Routine-Arbeiten geht, zu vergrößern. An einem Neubau arbeiten zunächst auch nur ein paar Architekten und Bauingenieure, bevor eine große
Anzahl von Bauarbeitern loslegt.
74
Für die Schätzungen hat das folgende Auswirkungen: Bei mindestens einem Parameter sollte man einen Fehlerpuffer einplanen („on time“ oder „on budget“ – evtl.
auch „on time and on budget“ mit optionalen Anteilen bei Funktionalität und/oder
Qualität).
3.2 Voraussetzunggen für gute Schätzungen
Für Schätzungen gelten zwei „Naturgesetze“:
1. Schätzungen fallen genauer aus, wenn man das zu schätzende Projekt in
kleinere, voneinander möglichst unabhängige „Teile“ unterteilt, diese einzeln
schätzt und alle Schätzungen zu einer Gesamtschätzung aufsummiert.
2. Schätzungen fallen umso genauer aus, je mehr vergleichbare Projekte bekannt
sind.
Hausbau: Kosten für ein Einfamilienhaus können mit einer Genauigkeit von
wenigen 1000 Euro (=
ˆ ca. 1 %) angegeben werden.
Umzug der Bundesregierung nach Berlin:
Abweichungen um mehrere 10 % sind möglich.
1. Flug zum Mond/Mars:
Gesamtkosten können erst spät abgeschätzt werden.
3.2.1 Divide et Impera
Das erste der beiden „Naturgesetze“ kann man sich sehr schön an zwei einfachen
Beispielen verdeutlichen.
Der Pötzseil-Case
(siehe Kupper [1993])
„Pötzseil“ ist im Kölner Sprachgut das Seil, an dem der Eimer in einem Brunnen
herabgelassen wird. Der Test verläuft wie folgt: Ein längeres Seil wird in zwei
gleichlange Teile zerschnitten. Die eine Hälfte wird in 5-8 unterschiedlich lange
Teile zerschnitten.
1. Test:
Länge des halben Seils schätzen.
2. Test:
Länge der Einzelstücke schätzen und Summe bilden.
3. Test:
Länge der Einzelstücke nacheinander schätzen, nach jeder Schätzung
wird die richtige Länge verraten. Anschließend wird wieder die Summe
gebildet.
75
Ergebnis: „Divide et Impera“ (teile und herrsche) führt zum Ziel. Dieser Test wurde mehrfach mit Studenten des ehemaligen Studiengangs Multimedia
durchgeführt. Das Ergebnis war jedes Mal dasselbe. Die Schätzungen
im zweiten und vor allem dritten Test waren deutlich besser als die
Schätzungen im ersten Test.
Gewicht des Eifelturms
π·Daumen-Schätzungen von Studenten, die die PM-Vorlesung von W. Kowarschick besuchen, streuen sehr weit (100 t bis 100.000.000 t).
(gute) Schätzung
Der Eiffelturm wird in folgende „Teile“ unterteilt: Höhe; Grundfläche eines Stahlklotzes, der entsteht, wenn die Leerräume entfernt werden; Gewicht von einem
Kubikmeter Stahl:
Zusammengedrückt nimmt der Eifelturm eine Fläche von ca. 2m · 2m ein, die
Höhe beträgt ca. 300 m, Eisen (Stahl) wiegt: 7, 8 t/m3 (im Physikbuch nachgeschlagen: Kuchling [1976])
⇒ Gewichtsschätzung: 300 m · 2m · 2m · 7, 8 t/m3 = 9 360 t
Realität (Eiffelturm [2006])
Original-Gewicht: 7 300 t (=
ˆ 4 kg/cm2 =
ˆ Erwachsener auf der Sitzfläche eines
Stuhls)
heutiges Gewicht: 10 000 t (wg. Beton statt Stahl ⇒ Rückbau geplant)
Original-Höhe:
312, 27 m (mit Flagge)
heutige Höhe:
324, 00 m (mit Antenne)
Bei dieser Art der Schätzung kann es natürlich immer noch passieren, dass jemand die Grundfläche des „Eiffelturmquaders“ vollkommen überschätzt, z. B. mit
10m · 10m. Die daraus resultierende Schätzung (nämlich 234 000 t) ist zwar deutlich besser als 100.000.000 t, aber immer noch indiskutabel schlecht. Das heißt,
bevor man über die Grundfläche des Quaders eine seriöse Aussage machen kann,
muss man den Eiffelturm noch genauer analysieren, d.h. noch feingranularer unterteilen.
3.2.2 Projektphasen und -vorgänge
Projektphasen
Ein Projekt sollte, wie in Kapitel 2 beschrieben wurde, auf jeden Fall in einzelne
Phasen unterteilt werden. Diese Einteilung kann insbesondere, wie beim PötzseilCase, verwendet werden, um robuste Kosten- und Zeitschätzungen zu erstellen.
76
Die Gesamtdauer und die Gesamtkosten des Projektes lassen sich im Nachhinein ermitteln, indem man die „Dauer i“ bzw. „Kosten i“ der einzelnen Phasen
i ∈ {1, ..n} aufsummiert (wobei jeweils die Dauer bzw. Kosten des zugehörigen
Reviews in den Werten „Dauer i“ bzw. „Kosten i“ enthalten sind):
n
n
P
P
Projektdauer =
Daueri
Projektkosten =
Kosteni
i=1
i=1
Anmerkung
Zu den Kosten können evtl. noch irgendwelche phasenunabhängige Fixkosten hinzukommen, die gegebenenfalls bei der Berechnung der Gesamtkosten oder bei den
im Folgenden vorgestellten Schätzungen dazugerechnet werden müssen.
Schätzungen zu Projektbeginn
Für die Schätzung von Dauer und Kosten zu Projektbeginn hat die Einteilung in
Phasen bzw. Vorgänge den Vorteil, dass Dauer und Kosten auch schon zu diesem
Zeitpunkt genauer abgeschätzt werden können, als dies ohne Phaseneinteilung
möglich wäre (Pötzseil-Case: Divide et Impera, teile und herrsche):
Projektdauermin =
Projektdauermax =
n
P
i=1
n
P
Projektkostenmin =
geschätzte Daueri,min
i=1
n
P
Projektkostenmax =
geschätzte Daueri,max
i=1
n
P
i=1
geschätzte Kosteni,min
geschätzte Kosteni,max
wobei geschätzte Daueri,min , geschätzte Daueri,max , geschätzte Kosten i,min und
geschätzte Kosteni,max Worst-Case- und Best-Case-Schätzwerte sind. Hier gilt
natürlich das 2. Naturgesetz der Schätzung (Abschnitt 3.2): Je mehr vergleichbare
Projekte bekannt sind, desto geringer ist die Differenz zwischen den Worst-Caseund den zugehörigen Best-Case-Schätzungen.
Wie man an diesen Formeln sieht, sollte man seine Schätzungen gleich von Anfang an mit einem Unsicherheitsfaktor versehen. Im obigen Beispiel werden für
jeden Projektabschnitt zwei Schätzwerte angegeben: Ein minimaler Wert (best
case) und ein maximaler (worst case). In Abschnitt 3.3 werden darüber hinaus
noch Dreipunkt- und Vierpunktschätzungen eingeführt: minimaler Wert, maximaler Wert, wahrscheinlichster Wert und evtl. noch die Wahrscheinlichkeit des
wahrscheinlichsten Werts.
Wie sagt Goldratt in jedem seiner Bücher? „Murphy lebt!“
77
Schätzungen zu im Laufe des Projektes
Bei jedem Meilenstein j kann die Schätzung präzisiert werden:
Projektdauermin =
j
P
i=1
Projektdauermax =
j
P
Daueri +
i=1
Projektkostenmin =
Projektkostenmax =
Daueri +
j
P
i=1
j
P
i=1
n
P
i=j+1
geschätzte Daueri,min
n
P
i=j+1
Kosteni +
Kosteni +
geschätzte Daueri,max
n
P
i=j+1
n
P
i=j+1
geschätzte Kosteni,min
geschätzte Kosteni,max
wobei die Schätzwerte geschätzte Daueri,min, geschätzte Daueri,max ,
geschätzte Kosteni,min und geschätzte Kosten i,max für i > j anhand der bisherigen Erkenntnisse angepasst werden können und sollten.
Auf diese Weise werden die Schätzungen, d.h. die Abweichungen zwischen Minimalwerten und Maximalwerten i. Allg. immer geringer:
-.+#/%0#21$%
"!$#&%(')*
,+# " Draft (4. Oktober 2012)
78
Der Nachteil dieser Art von Schätzung ist, dass zum Zeitpunkt der Projektdefinition, wenn also ein verbindlicher Vertrag geschlossen werden soll, der u. a. die
Dauer und die Kosten festlegt, i. Allg. noch keine Einteilung in Phasen vorliegt.
Schätzmethoden, die zu diesem Zeitpunkt eingesetzt werden können, werden in
Abschnitt 3.4, Abschnitt 3.5 und Abschnitt 3.6 vorgestellt.
Projektvorgänge
Die Planung und Schätzung kann sogar noch feingranularer erfolgen, wenn man
eine Phase wie in Kapitel 2 beschrieben weiter in einzelne Vorgänge unterteilt. Im
Gegensatz zu Phasen können Vorgänge allerdings durchaus parallel ablaufen.
Für die Schätzung bzw. Ermittlung der Gesamtkosten gelten die obigen Formeln
weiterhin: die (bekannten oder geschätzten) Kosten aller Vorgänge werden einfach
aufsummiert (gegebenenfalls werden noch bestimmte Fixkosten hinzuaddiert).
Bei der Berechnung der Gesamtdauer mit Hilfe von Vorgängen muss man allerdings berücksichtigen, dass Vorgänge i. Allg. parallel ablaufen. Hier muss man
zunächst aus der Menge aller Vorgänge eine Folge von zusammenhängenden,
nicht-parallel-laufenden Vorgängen wählen. Normalerweise definiert der so genannte kritische Pfad (siehe Abschnitt 4.3.1) eine derartige Folge. Allerdings ist
es nicht ausgeschlossen, wenn auch nur selten der Fall, dass zwei parallele Vorgänge auf dem kritischen Pfad liegen (und es sich eigentlich um ein kritisches
Vorgangsnetz handelt). Erst die kritische Kette (siehe Abschnitt 4.5) besteht mit
Sicherheit aus einer zusammenhängenden Folge von nicht-parallelen Vorgängen.
Gerade für die kritische Kette können die im Folgenden vorgestellten Schätzmethoden ebenfalls sehr vorteilhaft eingesetzt werden.
3.2.3 Akzeptierbare Abweichungen
Schätzungen für spätere Phasen werden i. Allg. einen größeren Unsicherheitsfaktor enthalten, als Schätzungen für frühere Phasen. Dies darf allerdings nicht
als Freibrief verstanden werden. Schätzungen müssen von Anfang an sorgfältig
durchgeführt werden.
Achtung:
Die Chance, dass eine Schätzung mit einer Genauigkeit von +/- 10 % stimmt,
liegt in der Spezifikationsphase bei lediglich 2/3 (Ende der Orientierungsphase) bis 4/5 (Ende der Definitionsphase). Nach dem Ende der Designphase liegt
sie kontinuierlich bei ca. 9/10. (QUELLE FEHLT [????])
Beispiel
Phase 1: +/- 5 % Kostenabweichung
79
..
.
Phase n: +/- 20 % Kostenabweichung
Das heißt, bei gegebenen Gesamtprojektkosten von beispielsweise 100 000 Euro
liegt für jede Phase eine Kostenmarge fest:
Phase 1: 5 000 Euro +/- 250 Euro
Phase 2: 30 000 Euro +/- 2 100 Euro
Phase 3: . . .
Außerdem sollte der prozentuale Anteil des Aufwands der einzelnen Phasen vom
Gesamtaufwand geschätzt werden.
Phase 1: 5 % des Gesamtaufwands
Phase 2: 30 % des Gesamtaufwands
Phase 2.1: 10 % des Gesamtaufwands
Phase 2.2: 20 % des Gesamtaufwands
Phase 3: . . .
Beispiele (QUELLE FEHLT [????], vermutlich InformationWeek)
Bertelsmann:
Definition: 30 %
Design:
30 %
Codierung: 15–20 %
Test:
20–25 %
Hewlett-Packard:
Definition: 18 %
Design:
19 %
Codierung: 34 %
Test:
29 %
Damit können Abweichungen, die sich in einer Projektphase ergeben, auf das
Gesamtprojekt fortgeschrieben werden.
Solange der Projektleiter im Rahmen der vorgegebenen Zeit- und Kostenmargen
bleibt, gibt es wenig Grund gegenzusteuern. Bei günstigerem Abschneiden kann
er sogar einen Überschuss in die nächste Phase mitnehmen. Bei Annäherung an
die Obergrenze muss er allerdings Maßnahmen ergreifen, damit er diese Grenze
nicht überschreitet.
Bei jedem Review sollten neue Schätzungen für die Restphasen auf Basis der
bisherigen Erfahrungen stattfinden. Sind beispielsweise die Kosten bisher in jeder Phase um 3 % überschritten worden und wird der geschätzte prozentuale Zusammenhang zwischen den einzelnen Phasen nicht geändert, so heißt das, dass
die Schätzkosten für die Folgephasen ebenfalls um je 3 % erhöht werden müssen
(sonst müssen evtl. nur die geschätzten Gesamtkosten korrigiert werden).
80
Andererseits können nach einem Review die Unsicherheitsintervalle i. Allg. nach
unten korrigiert und die Schätzungen des prozentualen Anteils der Einzelphasen
am Gesamtaufwand verbessert werden. Daraus ergeben sich neue (minimale und
maximale) Gesamtkosten.
3.2.4 Schneller oder billiger als geplant ist erlaubt!
Beachten Sie, dass hier für alle Schätzungen nicht ein fixer Wert, sondern ein
Intervall eingeplant wurde. Oftmals wird bei Schätzungen jedoch nur ein Wert
ermittelt. Viele Projektleiter interpretieren derartige Schätzungen so: Alles kostet
mindestens soviel wie geschätzt und dauert mindestens so lange wie geschätzt.
Das heißt, es kostet nie weniger und dauert nie kürzer als geschätzt. Höhere Kosten und längere Laufzeiten kommen dagegen sehr oft vor (und werden stillschweigend auch schon eingeplant).
Die Gründe für dieses Schieflage sind meist gar nicht unseriöse Schätzungen, sondern die Angst, beim nächsten Projekt weniger Geld bzw. Zeit zu bekommen,
wenn man zugibt, dass die Schätzungen (augenscheinlich) zu „großzügig“ waren. Wenn ein Unternehmer nichts gegen dieses Angst unternimmt, dann kostet
ihn das viel Geld. Ein gesundes Unternehmen weiß, dass die Realität in beiden
Richtungen von einer Schätzung abweichen kann, nach oben und nach unten!
Ein typisches Negativbeispiel dafür, dass diese Erkenntnis nicht immer vorhanden ist, ist das berüchtigte Dezemberfieber z. B. in Einrichtungen des öffentlichen Dienstes: Wenn zugewiesene Gelder in einem Jahr nicht vollständig aufgebraucht werden, geht der Geldgeber davon aus, dass der Bedarf prinzipiell zu hoch
geschätzt wurde – und kürzt die Mittelzuweisungen in den Folgejahren entsprechend. Aus diesem Grund werden spätestens im Dezember alle noch vorhandenen
Geldmittel für irgendetwas ausgegeben, nur damit die Zuweisungen im nächsten
Jahr nicht gekürzt werden.
Aufgrund der Tatsache, dass es bei der hier vorgestellten Art der Schätzung verschiedene Schätzwerte gibt (Minimum, Erwartungswert, Maximum), sollten die
Schätzungen sogar dreifach durchgeführt werden.
Projektkosten/dauer unter optimalen Bedingungen
Projektkosten/dauer unter normalen Bedingungen
Projektkosten/dauer unter schwierigen Bedingungen (worst case ohne Katastrophen)
81
3.3 Schätzungen von Phasen und Vorgängen
In den folgenden Beispielen beziehe ich mich stets auf Schätzungen von Zeiträumen. Für die Schätzung von Kostenspannen gelten dieselben statistische Gesetzmäßigkeiten.
Mit Ausnahme von PERT (Malcolm et al. [1959], Miller [1963]) basieren die
etablierten Projektmanagement-Methoden auf der so genannten Einpunkt-Schätzung: Für jede zu schätzende Dauer und jeden zu schätzenden Kostenfaktor wird
ein Wert geschätzt – und dann für bare Münze genommen.
Das wirkliche Leben ist jedoch anders. Murphy lebt! Wenn man mich fragt, wie
lange ich von zu Hause zu meinem Arbeitsplatz braucht, antworte ich 20 Minuten.
Nur – eigentlich sind es nie genau 20 Minuten. Mal schaffe ich es in 15 Minuten
(alle Ampeln sind grün, kein Laster hält mich auf), das andere Mal stehe ich im
Stau auf der B17 und komme erst nach einer Stunde an.
Welche Schätzung soll ich also verwenden?
– 15 Minuten?
(Das schaffe ich höchstens einmal in 10 Jahren. 2011 habe ich dies das erste
Mal seit 1998 geschafft!)
– 20 Minuten?
(Das schaffe ich oft, selten geht es schneller, meist dauert es ein paar Minuten länger.)
– 60 Minuten?
(Das schaffe ich so gut wie immer, meist bin ich aber viel schneller.)
Wenn man einen Mitarbeiter fragt, wie lange er für einen Vorgang braucht, hängt
die Antwort von seiner Erfahrung ab. Ein Anfänger würde im obigen Fall mit 15
Minuten rechnen. Er sieht die möglichen Probleme, die ihn behindern können,
noch nicht und fällt mit dieser Schätzung erst einmal auf die Nase. Ein „Profi“
antwortet „30 Minuten“, wenn es sich um einen nicht so wichtigen Vorgang handelt. Bei einem wichtigen Vorgang antwortet er „60 Minuten“, weil er sich sicher
ist, dass er ihn in dieser Zeit auch erledigen kann.
Und sein Chef und dessen Chef schlagen vorsichtshalber jeder nochmal 30 Minuten drauf, für den Fall, dass der Big-Boss das Ganze um 20 % kürzt. Und so
kommt zum Schluss eine Schätzung von 96 Minuten zu Stande.
Das Problem ist, das der „Profi“ die von ihm oder seines Chefs genannte Zeit,
d. h. die gesamten 96 Minuten, auch nutzen wird, da ansonsten die Schätzungen
für unglaubwürdig gehalten würden (vgl. Dezemberfieber).
Erschwerend kommt hinzu, dass er für die Erledigung mehr Zeit als notwendig
hat und deshalb leicht dem Studentensyndrom erliegt (Abbildung 1.3).
82
Wenn im letzten Drittel etwas schief geht, dauert die Realisierung noch länger als
geschätzt, obwohl bereits sehr viel Puffer in der Schätzung enthalten war.
Aus langjähriger Erfahrung kann ich Goldratts Beobachtungen bestätigen: Eine
Abschlussarbeit (Bachelor, Master, Diplom) wird normalerweise erst am Stichtag,
häufig sogar erst 5 Minuten vor der angegebenen Uhrzeit abgegeben – oder es wird
eine Verlängerung beantragt. Es kommt schon mal vor, dass eine Arbeit einige
Tage „zu früh“ abgegeben wird. Aber es passiert nur äußerst selten, dass sie einen
Monat vor dem Stichtag fertig ist. Und das ist auch nur dann der Fall, wenn ein
anderer triftiger Grund für diese Eile vorliegt (Student hat Zusage für Arbeitsplatz
o.Ä.).
Wie löst man nun dieses Problem?
Tom DeMarco (DeMarco und Lister [2003]) und Eliyahu Goldratt (Goldratt
[2002]) schlagen vor, Unsicherheiten explizit zu managen.
An Stelle eines einzigen Wertes werden für jeweils drei bis vier Schätzwerte ermittelt.
– bester Fall (best case)
– normaler Fall (normal case)
evtl. zusätzlich: Wie wahrscheinlich ist dieser Fall?
– schlechtester Fall (worst case)
Mit diesen Werten kann die Dichtefunktion einer Wahrscheinlichkeitsverteilung
festgelegt werden. Goldratt und DeMarco verwenden Dichtefunktionen, die gut
durch die Beta-Verteilung beschrieben werden können. Aber auch die einfachere
Dreiecksverteilung leistet gute Dienste (vgl. Gartner [1999]).
Dichte der Dreiecksverteilung
Es seien a, b, c ∈ R mit a < b und c ∈]a, b[. Dann ist die Dichte fD der Dreiecksverteilung XD folgendermaßen definiert (vgl. Abbildung 3.1, Dreiecksverteilung
[2006], Rinne [2003]):

2(x−a)

 (b−a)(c−a) für a ≤ x ≤ c

2(b−x)
fD (x) :=
für c < x ≤ b
(b−a)(b−c)



0
sonst
Dichte der Beta-Verteilung
Es seien a, b, α, β ∈ R mit a < b und α, β ≥ 1. Dann ist die Dichte fB der Beta-Verteilung XB folgendermaßen definiert (vgl. Abbildung 3.1, Beta-Verteilung
[2006], Rinne [2003]):
83
Abbildung 3.1: Beta- und Dreiecksverteilung von Wolfgangs Fahrt zur HSA
fB (x) :=

 (x−a)α−1 ·(b−x)β−1
B(α−β)(b−a)α+β−1
0
für a ≤ x ≤ b
sonst
Dabei ist die Beta-Funktion folgendermaßen definiert:
B(α, β) :=
Z1
0
tα−1(1 − t)β−1 dt =
Γ(α) · Γ(β)
Γ(α + β)
Die Beta-Funktion kann also durch die Gammafunktion, das ist die Verallgemeinerung der Fakultätsfunktion n!, ausgedrückt werden (Bronstein und Semendjajew [1980]).
Der Punkt c, an dem die Dichte jeweils ihr Maximum annimmt, heißt Modus
(engl. mode). Der Wert, den sie dort annimmt wird Modalwert genannt.
Unabhängig davon, welche der beiden Wahrscheinlichkeitsverteilung man verwendet, sagt diese für das Beispiel der Fahrt zur HSA aus, dass Wolfgang spätestens nach 60 Minuten mit Sicherheit am Ziel ist. Dies entspricht allerdings nicht
der Realität. Wolfgang kann auch einen Unfall haben und erst Tage oder Wochen
später oder auch gar nicht mehr kommen. Während man extrem lange VerzögeDraft (4. Oktober 2012)
84
rungen theoretisch auch mit extrem langgezogenen Beta-Verteilungen modellieren kann wird der Fall, dass ein Vorgang und damit evtl. das ganze Projekt nicht
beendet werden kann, von den vorgestellten Verteilungsfunktionen nicht erfasst.
Dies könnte man allerdings mit rechtsseitig unbegrenzten Verteilungen, wie z. B.
der F-Verteilung (Rinne [2003]), der Log-Normalverteilung (Rinne [2003]) oder
der Weibull-Verteilung (Rinne [2003]) modellieren.
DeMarco und Lister [2003] schlagen dagegen vor, den vollständigen Projektabbruch als ein explizites Risiko zu modellieren.
Im Folgenden gehen wir jedoch davon aus, dass die Dauer eines Vorgangs mit einer Dreipunktschätzung (d. h. mit einer Dreiecksverteilung oder Beta-Verteilung)
oder einer Vierpunktschätzung (d. h. mit einer Beta-Verteilung, bei der auch der
Modalwert, d. h. die Höhe der Dichte am Punkt c geschätzt wird) hinreichend genau beschrieben werden kann.
Verteilungsfunktionen
Welche Informationen hält die Dichtefunktion, die für eine Schätzung ermittelt
wird, für uns bereit? Um diese Frage zu beantworten, muss man sich ein wenig
genauer mit den Eigenschaften von Wahrscheinlichkeitsverteilung befassen.
Zu jeder stetigen Dichte f (x) gibt es die Wahrscheinlichkeitsverteilungs-Funktion
F (x):
Rx
P (X ≤ x) := F (x) :=
f (t) dt
−∞
Für die Dreiecksverteilung XD gilt (Dreiecksverteilung [2006]):


0
für x < 0



2

(x−a)
0 +
für a ≤ x ≤ c
(b−a)(c−a)
FD (x) :=
2
(b−x)


1 + (b−a)(b−c) für c < x ≤ b




1
für b < x
Damit kann man z. B. berechnen, wie wahrscheinlich es ist, dass Wolfgang spätestens nach 20 Minuten in der HSA ist (a = 15, b = 60, c = 20)
FD (20) = 0 +
(20 − 15)2
25
1
=
= =
ˆ 11, 1 %
(60 − 15)(20 − 15)
45 · 5
9
Es ist schon erstaunlich, dass ich es im Schnitt nur jede zweite Woche an einem
Tag wirklich in 20 Minuten oder weniger schaffe (wenn man diese Verteilung zu
Grunde legt).
Man kann die Frage auch umkehren. Wie viel Fahrtzeit muss ich einplanen, damit
ich in 50 % oder gar 95 % der Fälle rechtzeitig ankomme?
85
Dies kann mit Hilfe der Umkehrfunktion F −1 für die Verteilungsfunktion F berechnet werden:
(
√
a + (b − a) mp
für p ≤ m
−1
p
FD (p) :=
b − (b − a) (1 − m)(1 − p) für p > m
c−a
wobei m := b−a
F −1(p) wird p-Quantil oder p-Perzentil genannt (wobei F eine Verteilungsfunktion ist, für die F −1 existiert).
Das 50 %-Quantil und das 95 %-Quantil berechnen sich für unser Beispiel wie
folgt:
20−15 = 5 = 1
m = 60−15
45
9
r
−1(0, 5) = 60 − (60 − 15) (1 − 1 )(1 − 0, 5)
FD
9
r
8 1
·
= 60 − 45
9 2
= 30
r
1
−1
FD (0, 95) = 60 − (60 − 15) (1 − )(1 − 0, 95)
9
r
8
· 0, 05
= 60 − 45
9
= 50
Um also in 50 % der Fälle rechtzeitig an die HSA zu kommen, müsste ich 30
Minuten Fahrtzeit einplanen. Und 50 Minuten Fahrzeit ergeben sich, wenn ich bei
95 % aller Fahrten rechtzeitig ankommen wollte.
Die Realität sieht allerdings anders aus. Staus passieren in der Früh nur sehr selten.
50 Minuten vorher fahre ich definitiv nicht von zu Hause los. Die Beta-Verteilung
XB beschreibt die reale Situation besser. Ihre Verteilungsfunktion ist folgendermaßen definiert (Statistik [2006]):
FB (x) :=
Zx
fβ (t)dt
−∞
Leider lassen sich weder die Verteilungsfunktion FB noch die zugehörige Umkehrfunktion FB−1 der Beta-Verteilung mit geschlossenen mathematischen Formeln beschreiben, sondern müssen algorithmisch (z. B. mit Fixpunktiteration)
ermittelt werden. Tools wie Mathcad (PTC [2011]) stellen allerdings geeignete
Funktionen zur Verfügung.
86
Abbildung 3.2: Beta-Verteilung
Für die obige Beta-Verteilung ergeben sich bessere Schätzwerte als bei der Dreiecks-Verteilung. Folgende Parameter liegen der Grafik zu Grunde: a = 15, b = 60,
c = 20, α = 1, 738, β = 6, 908. Die Parameter α und β wurden so gewählt, dass
der Modalpunkt von fB bei c liegt und dort den Wert 0,075 annimmt.
FB (20)
= 0, 284 =
ˆ 28, 4 %
−1
FB (0, 5) = 23
FB−1(0, 95) = 35
(50 %-Quantil = Median)
(95 %-Quantil)
Das heißt, in knapp 30 % der Fälle schaffe ich es wirklich in 20 Minuten oder
weniger. Wenn ich 23 Minuten einplane, bin ich in 50 % aller Fälle pünktlich.
Gehe ich sogar 35 Minuten vor einem geplanten Termin aus dem Haus, komme
ich nur noch in 5 % der Fälle zu spät. Diese Zeiten treffen die Realität schon ganz
gut. In Wirklichkeit komme ich nur in höchstens 2% der Fälle zu spät, wenn ich 35
Minuten Fahrzeit einplane. Das heißt, der Wert am Modalpunkt wurde mit 0,075
vermutliche etwas zu niedrig gewählt.
3.3.1 Erwartungswert und Standardabweichung
Das 50 %-Quantil (der Median) kann relativ gut mit dem Erwartungswert abgeschätzt werden. 50 %-Quantil und Erwartungswert unterscheiden sich allerdings
umso mehr je unsymmetrischer die Verteilung ist.
87
Erwartungswert einer Dreiecksverteilung XD :
a+b+c
3
Erwartungswert einer Beta-Verteilung XB :
µ(XD ) =
µ(XB ) =
αb + βa
α+β
Für unser Beispiel ergibt sich:
15 + 60 + 20
= 31, 7 ≈ 30
3
1, 74 · 60 + 6, 91 · 15
= 24, 1 ≈ 23
µ(XB ) =
1, 74 + 6, 91
µ(XD ) =
(50 %-Quantil)
(50 %-Quantil)
Die Streuung um diesen Erwartungswert wird mit Hilfe der Standardabweichung
berechnet:
q
b−a
c−a
σ(XD ) =
2(1 − m + m2 ), wobei m =
6
b−a
s
b−a
αβ
σ(XB ) =
α+β α+β+1
Für unser Beispiel ergibt sich:
s
12
60 − 15
1
σ(XD ) =
2(1 − + ( )) = 10, 1
6
9
9
r
60 − 15
1, 74 · 6, 91
σ(XB ) =
= 5, 8
1, 74 + 6, 91 1, 74 + 6, 91 + 1
3.3.2 Zentraler Grenzwertsatz der Statistik
Zur Abschätzung der Gesamtdauer einer Folge von Vorgängen, bei denen die jeweilige Einzeldauer mit Hilfe irgendwelchen Verteilungen (Dreieecksverteilung,
Beta-Verteilung etc.) geschätzt wird, kann mit dem zentralen Grenzwertsatz der
Statistik (Bronstein und Semendjajew [1980]) erfolgen.
Dieser besagt, dass unter bestimmten Voraussetzungen, die Summe einer Menge von Zufallsgrößen X1 , . . . , Xn angenähert normalverteilt ist. Der Erwartungswert, die Varianz und die Standardabweichung dieser Normalverteilung können
dabei wie folgt abgeschätzt werden:
88
µ
n
X
Xi
i=1
V ar
n
X
i=1
!
≈
n
X
!
≈
Xi
µ(Xi )
i=1
n
X
V ar(Xi )
i=1
und da die Standardabweichung die Wurzel aus der Varianz ist:
! v
u n
n
X
uX
1·σ
Xi ≈ t (1 · σ(Xi ))2
i=1
i=1
! v
u n
n
X
uX
2·σ
Xi ≈ t (2 · σ(Xi ))2
i=1
i=1
! v
u n
n
X
uX
3·σ
Xi ≈ t (3 · σ(Xi ))2 etc.
i=1
i=1
Der Erwartungswert der Summe ist also ungefähr gleich der Summe der Erwartungswerte und die Varianz der Summe ist ungefähr gleich der Summe der Varianzen. Besonders interessant ist, dass die Standardabweichung der Summe ungefähr
gleich der Wurzel aus der Summe der Quadrate der einzelnen StandardabweiP
chungen ist. Dieser Wert ist i. Allg. deutlich kleiner als die Summe
σ(Xi ) der
einzelnen Standardabweichungen. Das heißt, die Streuungen der einzelnen Verteilungen heben sich zum Teil gegenseitig auf!
Man kann davon ausgehen, dass jedes „normale“ Projekt die Voraussetzungen
(Bronstein und Semendjajew [1980]) des Zentralen Grenzwertsatzes erfüllt: Die
Schätzungen der einzelnen Phasen oder Vorgänge sind voneinander unabhängig,
die Schätzungen sind sind klein verglichen mit der Gesamtsumme (d. h. es gibt
keine Phasen oder Vorgänge, die einen Großteil des Gesamtprojektes ausmachen),
es gibt „zahlreiche“ Vorgänge etc.
Standardabweichung
Mit Hilfe der Standardabweichung kann die Unsicherheit einer Abschätzung
quantifiziert werden. Für eine Normalverteilung gilt dabei die 68/95/99,7-Regel
(vgl. Jann [2005]):
P (µ − 1σ ≤ X ≤ µ + 1σ) ≈ 68 %
P (µ − 2σ ≤ X ≤ µ + 2σ) ≈ 95 %
P (µ − 3σ ≤ X ≤ µ + 3σ) ≈ 99, 7 %
89
90
Abbildung 3.3: Standardabweichungen der Normalverteilung
Das heißt, mit einer Wahrscheinlichkeit von 68 % liegt der Schätzwert im Intervall
[µ − 1σ, µ + 1σ] etc. (siehe Abbildung 3.3).
Allerdings ist diese Regel für das Projektmanagement nicht sonderlich geeignet,
da Projekte, die früher fertig werden als geplant, nie ein Problem darstellen (oder
zumindest nie darstellen sollten). Daher propagiere ich, dass im Projektmanagement die (von mir so genannte) 84/98/99,9-Regel eingesetzt werden sollte:
P (X ≤ µ + 1σ) ≈ 84 %
P (X ≤ µ + 2σ) ≈ 98 %
P (X ≤ µ + 3σ) ≈ 99, 9 %
Das heißt, mit einer Wahrscheinlichkeit von 84 % liegt der Schätzwert im Intervall
]−∞, µ + 1σ] etc. (siehe Abbildung 3.3), wobei man im Projektmanagement ∞
getrost durch 0 ersetzen kann, da es keine negativen Projektlaufzeiten gibt.
Um beispielsweise für eine Folge von Phasen oder kritischen Vorgängen abzuschätzen, bis zu welchem Zeitpunkt alle Vorgänge mit ca. 84%, 98% oder gar
99,9 % Wahrscheinlichkeit beendet sind, geht man daher folgendermaßen vor:
1. Man ermittelt für alle Phasen (oder kritischen Vorgänge) den jeweiligen Erwartungswert µi und die Standardabweichung σi ;
2. Man berechnet den Erwartungswert
die Standardabweichung der Summe
qund
Pn
Pn
2
der Vorgänge: µ = i=1 µi , σ =
i=1 σi ;
3. Man berechnet den Wert µ + σ, µ + 2σ oder µ + 3σ, je nach gewünschter
Sicherheit.
Beispiel
Gegeben seien fünf Phasen. Für diese werden folgende Schätzungen ermittelt
(a=Minimum, b=Maximum, c=erwarteter Wert, p(c)= Modalwert):
a
1
3
5
1
4
c
6
7
6
5
6
σ=
b
9
19
8
9
9
p(c)
0,13
0,87
0,21
0,5
Verteilung
Dreiecksverteilung
Beta-Verteilung
Beta-Verteilung
Beta-Verteilung
Beta-Verteilung
Summe
µi
5,33
8,33
6,10
5,00
6,10
30,87
σi
1,65
2,85
0,44
1,63
0,74
7,31
q
σ12 + σ22 + σ32 + σ42 + σ52 = 3,78 < 7,31
µ + 1σ = 30,87 + 1 · 3,78 = 34,65
µ + 2σ = 30,87 + 2 · 3,78 = 38,43
µ + 3σ = 30,87 + 3 · 3,78 = 42,21
91
Abbildung 3.4: Dichtefunktionen der Schätzungen von fünf Phasen
Abbildung 3.5: Simulation und Schätzung: Dauer von fünf Phasen
Die zugehörigen Dichtefunktionen sind in Abbildung 3.4 zu sehen. In Abbildung 3.5 wird die Schätzung der Gesamtdauer für die zuvor geschätzten fünf Projektphasen illustriert. Das Histogramm (durchgezogene Linie) wurde mit Hilfe
einer Monte-Carlo-Simulation (Gellert und Kästner [1979]) ermittelt: Dabei wurde 30 000 mal für jede Phase ein Zufallswert gemäß der geschätzten Verteilungsfunktion berechnet. Diese fünf Schätzwerte wurden jeweils zu einer Gesamtsum-
92
me addiert. Der jeweilige Histogrammwert gibt an, wie oft der jeweilige x-Wert
(Dauer in Tagen) erzielt wurde.
Die gepunktete Linie visualisiert die Normalverteilung, die mit Hilfe des Zentralen Grenzwertsatzes aus den fünf Dichtefunktionen berechnet wurde. Sie wurde
so skaliert, dass die Höhe mit der Höhe des Histogramms übereinstimmt. Für diese
Verteilung wurden der Erwartungswert µ = 30.87 (Tage) sowie das 2σ-Intervall
[µ − 2σ, µ + 2σ] = [23.31, 38.43] eingetragen.
Die Schätzung gemäß dem zentralen Grenzwertsatz besagt also, dass das Projekt
mit einer Wahrscheinlichkeit von 95 % innerhalb von 23 bis 38 Tagen fertig gestellt wird. Noch wichtiger ist das Ergebnis der 84/98/99,9-Regel: Das Projekt
wird mit einer Wahrscheinlichkeit von 98 % in maximal 38 Tagen fertiggestellt.
Wie man an der Monte-Carlo-Simulation deutlich erkennen kann, ist diese Schätzung etwas zu pessimistisch. Eigentlich liegen der Erwartungswert und das
95 %-Intervall einen Tag früher. Das kommt daher, dass lauter linkslastige Schätzungen verwendet wurden.
Daran, dass selbst bei lediglich fünf Phasen die Abweichung unter 5 % liegt, sieht
man, wie gut der zentrale Grenzwertsatz funktioniert. Die Ungenauigkeit, die sich
durch die Verwendung des Grenzwertsatzes ergibt, beträgt lediglich einen Tag.
Bei 15 Phasen (siehe Abbildung 3.6) ist die Abweichung schon nicht mehr der
Rede wert (unter 1 %).
Abbildung 3.6: Simulation und Schätzung: Dauer von 15 Phasen
93
Anmerkung
Die84/98/99,9-Regel besagt, dass, wenn man für jedes Projekt lediglich 1σ als
Gesamtpuffer vorsieht, jedes sechste Projekt nicht rechtzeitig fertiggestellt wird
(zumindest, wenn man den Puffer auch wirklich als Puffer benutzt; vgl Abschnitt 4.5). Daher ist ein 1σ-Puffer sicher ein guter Kompromiss, wenn man den
Kunden kurze Projektlaufzeiten anbieten und dennoch einen Gewinn aus dem Projektergenissen erzielen möchte.
3.3.3 Weitere Verteilungen für Mehrpunktschätzungen
Es gibt zahlreiche Dichte-/Verteilungsfunktionen, die zur Ermittlung von µ- und
σ-Werten herangezogen werden können. Beispiele:
Einpunkt-Schätzung
– fertig nach c Tagen
– Kosten in Höhe von c
Geeignete Dichte- bzw. Verteilungsfunktionen sind zum Beispiel:
unendlich
1
c
c
Sicheres Ergebnis
Dichte
Verteilung
c
Normalverteilung
(Standardabweichung ist fix)
94
Zweipunkt-Schätzung
– frühestens fertig nach a Tagen,
spätestens fertig nach b Tagen,
oder an Stelle von b: vermutlich fertig nach c Tagen (höchste Wahrsch.)
– minimale Kosten a,
maximale Kosten b,
oder an Stelle von b: vermutliche Kosten c (höchste Wahrsch.)
Geeignete Dichte- bzw. Verteilungsfunktionen nutzen jeweils zwei dieser Schätzwerte und definieren für andere Freiheitsgrade gegebenenfalls geeignete Defaultwerte. Beispiele:
a
b
Rechtecksverteilung
a
b
Normalverteilung
a c
F−Verteilung,
Log−Normalverteilung ...
b−a
Normalverteilung: a = µ − 2σ, b = µ + 2σ ⇒ µ = b+a
2 ,σ= 4
Dreipunkt-Schätzung
vermutlich fertig nach c Tagen (höchste Wahrscheinlichkeit),
oder an Stelle von b: d = p(c) (Modalwert)
maximale Kosten b,
vermutliche Kosten c (höchste Wahrscheinlichkeit),
oder an Stelle von b: d = p(c) (Modalwert)
Geeignete Dichte- bzw. Verteilungsfunktionen nutzen jeweils drei Schätzwerte
und definieren für andere Freiheitsgrade gegebenenfalls geeignete Defaultwerte.
Beispiele:
d
a c
b
Dreiecksverteilung
a c
b
Beta−Verteilung
95
a c
F−Verteilung,
Log−Normalverteilung ...
Vierpunkt-Schätzung
vermutlich fertig nach c Tagen (höchste Wahrscheinlichkeit),
d = p(c) (Modalwert)
maximale Kosten b,
vermutliche Kosten c (höchste Wahrscheinlichkeit),
d = p(c) (Modalwert)
Alle vier der genannten Werte werden geschätzt. Dafür eignet sich vor allem die
Beta-Verteilung:
d
d
a c
b
Beta−Verteilung
a c
b
Beta−Verteilung
PERT
Für PERT wird eine Beta-Verteilung verwendet, bei der Erwartungswert und Standardabweichung folgendermaßen abgeschätzt werden:
b−a
a + 4c + b
,
σ=
6
6
Laut Frank Grubbs [1962] ist die Schätzung für folgende α- und β-Werte korrekt:
√
√
α = 3 + √2, β = 3 − √2
(rechtslastig)
(linkslastig)
α = 3 − 2, β = 3 + 2
µ=
Für alle anderen Beta-Verteilungen sind diese Approximationen falsch und meist
auch ziemlich schlecht.
96
3.4 Delphi-Methode
Schätzungen sollten von Experten, d. h. von Personen mit Erfahrung im zu schätzenden Gebiet vorgenommen werden. Wenn man mehrere Experten unabhängig
voneinander Schätzungen vornehmen lässt und die Ergebnisse dann mittelt, erhält
am im Allgemeinen bessere Ergebnisse, als wenn man nur einen Experten befragt.
Dieses Verfahren ist als Expertenschätzung bekannt. (Jakoby [2010])
Noch bessere Ergebnisse erhält man bei der so genannten Delphi-Methode, die
von der Rand-Corporation in den 1960er-Jahren entwickelt wurde. Hier schätzen
mehrere Experten zunächst unabhängig voneinander. Anschließend präsentieren
sie ihre Ergebnisse den anderen Experten und begründen ihre Schätzwerte. Es
ist dabei nicht notwendig, dass ein Experte den anderen überzeugt, es geht nur
darum, dass sich die anderen Experten mit anderen Aspekten, die die Schätzung
beeinflussen können, vertraut machen. Danach schätzt jeder Experte noch einmal.
Der Mittelwert der Schätzungen wird wieder als Schätzwert genommen. (Jakoby
[2010])
Die Expertenschätzung und die Delphi-Methode lassen sich natürlich problemlos so verallgemeinern, dass ein minimaler und ein maximaler Schätzwert als Ergebnis ermittelt werden. Zunächst müssen die Experten jeweils zwei Schätzwerte
(Minimum und Maximum) abgeben. Und zum Schluss kann man die Minima und
die Maxima entweder mitteln oder – um ganz auf Nummer sicher zu gehen – das
jeweils absolute Minimum und das absolute Maximum als Schätzwerte verwenden.
97
3.5 Die Function-Point-Methode
Diese Methode wurde von Alan Albrecht bei IBM in den späten 70er-Jahren entwickelt (Albrecht [1979]) und ist heute als ISO-Norm standardisiert (ISO/IEC
20926:2009 [2009]). Sie basiert auf Analogieschluss und Gewichtung.
Grundidee: Ein Vorhaben wird in verschiedene Grundfunktionen zerlegt. Ursprünglich sah Alan Albrecht folgende Einteilung vor:
Eingaben, Ausgaben, Abfragen, Schnittstellen, logische Datenbestände
Heute kann die Function-Point-Methode jedoch für viele Projekttypen mit ganz
unterschiedlichen Grundfunktionen eingesetzt werden .
Dann wird für jede Grundfunktion Art (siehe oben), Umfang (z. B. LOC) und
Komplexität (z. B. leicht, mittel, schwer) festgelegt. Abhängig von einer firmenspezifischen Function-Point-Funktion f (Art, Umfang, Komplexität) werden jeder
Grundfunktion so genannte Function Points zugeordnet.
Aus der Summe der Function Points kann der Gesamtaufwand abgeschätzt werden.
Abbildung 3.7: Eine mögliche Schätzfunktion für die FP-Methode
98
Vorteile:
– Die Kurve wird mit jedem abgeschlossenen Projekt genauer.
– Man hat ein robustes Schätzwerkzeug zur Verfügung.
– Man kann auch Dreipunkt-Schätzungen (Min, Mittel, Max) vornehmen, wenn man für jede Grundfunktion drei entsprechende
Function-Point-Werte ermittelt.
Nachteile:
– Die Daten vieler vergleichbarer Projekte (ähnliche Aufgaben,
ähnliche Anzahl Mitarbeiter) müssen zur Verfügung stehen.
– Die Aufwandsschätzung (z. B. LOC) je Grundfunktion ist zu Anfang des Projektes oft problematisch.
Der Function-Point-Graph ist umso nützlicher, je geringer die einzelnen Punkte von Approximationslinie abweichen. Laut DeMarco [2001] gibt es wissenschaftliche Studien, die ein hochinteressantes Ergebnis haben: Wenn man die Abschätzung des Arbeitsaufwandes nicht tagesgenau, sondern stundengenau macht
(und dabei geleistete Überstunden berücksichtigt), wird die Streuung größer und
nicht etwa kleiner! Fazit: Die tagesgenaue Schätzung ist viel aussagekräftiger. Der
Grund dafür ist: Ein Mitarbeiter leistet jeden Tag ungefähr dasselbe unabhängig
davon, ob er „nur“ 8 Stunden arbeitet oder 12 Stunden. Überstunden haben keinerlei positiven Effekt (aber viele negative Effekte)!!
99
3.6 COCOMO
COCOMO: Constructive Cost Model
COCOMO wurde in den späten Siebzigern von Barry Boehm entwickelt (Boehm
[1981]) und hat sich seitdem zu einem der wichtigsten Schätzmethoden gemausert. In den Neunzigern wurde eine gründlich überarbeitete Version II vorgestellt
(Boehm et al. [2000]).
COCOMO wurde für das Wasserfallmodell konzipiert.
COCOMO II kommt auch mit iterativen Modellen (Spiralmodell) zurecht.
Alle Schätzungen von COCOMO basieren auf den so genannten Kilo Source Lines of Code (KSLOC). Man findet auch die Bezeichnung Kilo Delivered Source
Instructions (KDSI). Das sind die Anzahl der ausgelieferten Befehle (Schleifen,
Zuweisungen, Vergleiche), nicht einfach die Anzahl der Befehlszeilen (Lines of
Code = LOC). In COCOMO II können auch Function Points, Use Cases etc. zur
Schätzung herangezogen werden. Diese werden durch das so genannte Backfiring
in KSLOC umgerechnet. Allerdings sind diese Werte häufig nicht sonderlich stark
korreliert (Seibert [2005]).
Bei COCOMO werden drei Arten von Projekten unterschieden:
organic:
kleines Projekt (< 50 KSLOC), kleines Team, erfahrende Programmierer, stabile Entwicklungsumgebung
semi-detached: größeres Projekt (50 – 300 KSLOC), Programmierer mit unterschiedlichen Erfahrungsleveln; Mittelding zwischen organic und
embedded
embedded:
relativ groß (> 300 KSLOC), schwierige Nebenbedingungen,
größere Unsicherheit, höherer Innovationsgrad
Für jede Projektart können die Anzahl der benötigten Personenmonate, die Entwicklungszeit und die Teamgröße mittels einfacher Formeln aus den geschätzten
KSLOC ebenfalls abgeschätzt werden.
Für die Schätzmethode werden in Basic COCOMO folgende Zahlen verwendet:
Personenmonate (PM)
organic
semi-detached
embedded
Dauer
Anzahl Mitarb.
2, 4 · KSLOC1,05
2, 5 · PM0,38
PM/Dauer ≈ 0, 7 · KSLOC0,651
3, 6 · KSLOC 1,20
2, 5 · PM0,32
3, 0 · KSLOC 1,12
2, 5 · PM0,35
Bei der Schätzung gemäß Intermediate COCOMO werden neben der Anzahl der
ausgelieferten Codezeilen weitere so genannte Kostentreiber berücksichtigt.
Die Projektdauer wird mit folgenden Formeln ermittelt:
100
organic
semi-detached
embedded
PM
Dauer
3, 2 · KSLOC1,05 · f
2, 5 · PM0,38
2, 8 · KSLOC 1,20 · f
2, 5 · PM0,32
3, 0 · KSLOC 1,12 · f
2, 5 · PM0,35
Der Effort Adjustment Factor f wird dabei durch Multiplikation von „Gewichten“
für weitere Kostentreiber ermittelt. Für jeden von fünfzehn Kostentreiber wird der
Aufwand geschätzt und gemäß der nachfolgenden Tabelle gewichtet (deutsche
Übersetzung von W. Kowarschick):
sehr
Kostentreiber
gering
Produktmerkmale
Erforderliche
0,75
System-Zuverlässigkeit
Datenbankgröße
Komplexität des Produktes
0,70
Plattformmerkmale
Anforderungen an Laufzeitperformanz
Hauptspeicherbedarf
Änderungshäufigkeit der Systemumgebung
Anforderungen an Antwortzeiten
Personalmerkmale
Analysefähigkeiten
1,46
SW-Entwicklungs-Fähigkeiten
1,29
Erfahrungen im
1,42
Anwendungsgebiet
Erfahrungen mit der
1,21
Systemumgebung
Erfahrungen mit der
1,14
Programmiersprache
Projektmerkmale
Verwendung von Software1,24
Entwicklungstools
Einsatz von Software1,24
Engineering-Methoden
Anforderungen an Entwick1,23
lungsdauer
101
gering
normal
hoch
sehr
hoch
extrem
hoch
0,88
1,00
1,15
1,40
0,94
0,85
1,00
1,00
1,08
1,15
1,16
1,30
1,65
1,00
1,11
1,30
1,66
1,00
1,00
1,06
1,15
1,21
1,30
1,56
0,87
0,87
1,00
1,07
1,15
1,19
1,13
1,17
1,00
1,00
1,00
0,86
0,91
0,86
0,71
0,82
0,70
1,10
1,00
0,90
1,07
1,00
0,95
1,10
1,00
0,91
0,82
1,10
1,00
0,91
0,83
1,08
1,00
1,04
1,10
Die genauesten Schätzergebnisse lassen sich mit Detailed COCOMO ermitteln.
Dabei werden die Gewichte der Kostentreiber für jede Projektphase separat gemäß
obiger Tabelle ermittelt. Barry Boehm teilt dabei ein Projekt in sechs Phasen ein:
– Analyse (Requirements)
– Grobentwurf (Product Design)
– Feinentwurf (Detailed Design)
– Implementierung und Modul-Test (Code and Unit Test)
– Integration und Test (Itegration and Test)
– Wartung (Maintenance)
COCOMO II unterscheidet sich in einige wesentlichen Punkten von COCOMO:
Function Point, UML Use Cases etc. können ebenfalls zu Schätzung herangezogen werden. Die zugehörigen Schätzwerte werden durch das so genannte Backfiring in KSLOCs umgerechnet. Allerdings sind die Umrechnungstabellen noch
nicht sehr ausgereift.
Bei der Entwicklung von Software kann die Wiederverwendung von Code berücksichtigt werden.
Es werden drei Modelle unterschieden:
Application Composition Model:
für frühe Projektphasen
Early Design Model:
ebenfalls für frühe Projektphasen, aber vorrangig für die Evaluation von Architekturen und Entwicklungsstrategien, wenn viele Details des zu schätzenden Projektes noch unbekannt sind
Post-Architecture Model:
für detaillierte Schätzungen nach der Entwurfsphase
Zur Abschätzung der Projektaufwandes in Personenmonaten (PM) und der Projektdauer in Monaten (M) werden in COCOMO II ähnliche Funktionen wie in
COCOMO verwendet, allerdings mit anderen Parametern (die folgenden Formeln
wurden vereinfacht – ohne Wiederverwendung von Code und Entwicklungszeitverkürzung):
PM = A · KSLOCE · f
M = C · PMF
(Projektaufwand)
(Projektdauer)
wobei
102
A = 2, 94
B = 0, 91
C = 3, 67
D = 0, 28
E = B + 0, 01 ·
5
X
Fj
j=1
F = D + 0, 2 · (E − B)
gesetzt wird. Die fünf Faktoren Fj werden projektabhängig aus den folgenden
Organisationsfaktoren ermittelt:
Organisationsfaktoren
– Erfahrungen im Produktbereich
– Entwicklungsflexiblität
– Ausgereiftheit des Entwurfs
– Stakeholder-Zusammenhalt
– Software-Prozessreife
Der Effort Adjustment Factor f wird wieder durch Multiplikation von „Gewichten“ für weitere Kostentreiber ermittelt. Dabei wurden in COCOMO II einige Kostentreiber leicht modifiziert und deren Anzahl etwas erhöht (deutsche Übersetzung
gemäß Seibert [2005]). Die Gewichte wurden gegenüber COCOMO neu justiert.
Produktfaktoren
– Erforderliche Zuverlässigkeit
– Datenbankgröße
– Produkt-/Modulkomplexität
– Wiederverwendbarkeit
– Dokumentationsumfang
Plattformfaktoren
– Rel. Rechnerzeitnutzung
– Rel. Hauptspeichernutzung
– Plattform-Änderungsdynamik
Personalfaktoren
– Systemanalysefähigkeit
– Programmierfähigkeit
103
– Anwendungserfahrung
– Plattformerfahrung
– Sprach- und Tool-Erfahrung
– Personelle Kontinuität
Projektfaktoren
– Nutzung von SW-Tools
– Standortübergreifende Teamarbeit
– Verfügbare Projektzeit
Für das Post-Architecture Model kommen alle siebzehn Kostentreiber zum Einsatz, für die Schätzungen der ersten Projektphasen werden nur sieben und teilweise andere Kostentreiber berücksichtigt.
3.6.1 Die Güte von Schätzverfahren
Leider gibt es kein allgemeingültiges Verfahren, um präzise und verlässliche Vorhersagen zu machen. (Elzer [1994])
Faustregel: π · Daumen
Schätze die Größe des Codes (LOC) und teile sie durch die vom Teamleiter geschätzte Produktivität des Teams (LOC/Monat) und multipliziere dies mit dem Kosten eines Monats.
Diese Regel ist nicht schlechter, als viele kompliziertere Regeln (obwohl sie nur
drei Parameter berücksichtigt und nur einen linearen Zusammenhang beschreibt).
Siba N. Mohanty hat 1981 ein 36-KLOC-Projekt benutzt, um die Vorhersagequalität von verschiedenen Kostenmodellen zu untersuchen. (Mohanty [1981]) Die
Ergebnisse sind erschütternd (und werden im Wesentlichen von Folgeuntersuchungen bestätigt):
104
Verfahren
Anzahl
Einflussgrößen
13
13
15
Kosten
Dauer
(Dollar)
(Monate)
1 Farr und Zagorski
362.500
2 Naval Air Dev. Center
2.001.410
3 Wolverton (einfach)
925.200
Wolverton (mittel)
1.138.680
Wolverton (schwer)
1.359.936
4 Kustanowitz
5
1.600.000
– 2.766.667 19,6 – 25,8
5 Aerospace
4
1.342.250
6 GRC
4
1.224.515
7 SDC
12
1.200.585
8 Price-S
10
1.330.000
18
9 Walston and Felix
2
565.000
13,77
10 Aron
4
530.576
11 Schneider
3
880.290
12 Doty
9
682.208
Mohanty nimmt an, dass eine Person 50.000$ im Jahr kostet, das sind 4166.67$
pro Monat. Ich schätze jetzt einfach mal, das eine Person 2.000 LOC pro Jahr
programmieren, testen und integrieren kann, das sind 167 LOC pro Monat oder
10 LOC pro Tag.
Das Verfahren π · Daumen liefert dann für das von Mohanty defi36.000 LOC ·
nierte 36-KLOC-Beispielsprojekt folgende Kostenschätzung: 167
LOC/PM
4.167 $/PM = 898.275$
Der Durchschnitt aller fünfzehn Schätzwerte ist ca 25 % größer: 1.193.988 $.
Damit liegt der durch die Methode π · Daumen ermittelte Schätzwert gut im Rennen.
Fazit
Der höchste Schätzwert ist 7,6 mal so hoch wie der niedrigste. Das sind eigentlich
keine brauchbaren Ergebnisse!
Mohanty führt dieses Ergebnis darauf zurück, dass den jeweiligen Schätzmethoden firmenspezifische Schätzparameter zu Grunde liegen. Er vermutet außerdem,
dass sich die einzelnen Methoden hinsichtlich der Ansprüche an die Qualität des
Ergebnisses unterscheiden. Dies ist aber nur ein Spezialfall der Beobachtung, dass
bei verschiedenen Unternehmen verschiedene Randbedingungen gelten.
Aus der Beobachtung von Mohanty folgt, dass Schätzmethoden, die nicht auf das
jeweilige Unternehmen kalibriert werden, sind nicht sonderlich aussagekräftig.
Oder andersherum: Schätzmethoden, wie die Function-Point-Methode, COCOMO etc., sind wesentlich genauer, wenn sie kalibriert werden, d. h., wenn die
105
Schätzparameter der jeweiligen Methode durch mathematisch-statistische Analyse historischer Projektdaten an die Verhältnisse des jeweiligen Entwicklungsbereiches angepasst werden.
Dieses Ergebnis wird durch eine Untersuchung von Burghardt [1995] bestätigt.
Er hat 60 Projekte der Firma Siemens analysiert und COCOMO-Schätzungen mit
Kalibrierung mit Standard-COCOMO-Schätzungen verglichen. Das Ergebnis dieser Untersuchung ist, dass die Vorhersagen durch die Kalibrierung wesentlich besser werden:
– COCOMO ohne Kalibrierung: maximaler Fehler ±20 % in 45 % der Fälle
– COCOMO mit Kalibrierung: maximaler Fehler ±20 % in 95 % der Fälle
Prinzipiell sollte die Schätzung also phasenweise erfolgen (siehe Pötzseil-Case) und möglichst bekannte Werte aus vergleichbaren Projekten berücksichtigen
(Analogieverfahren + Gewichtung, wie z. B. eine moderne Function-Point-Methode). Außerdem sollten Schätzungen nicht vom Projektleiter allein, sondern von
mehreren Experten vorgenommen werden (Expertenschätzung). Deren Schätzungen sollten nicht zu weit auseinander liegen, da sonst vermutlich noch nicht alle
Fakten bekannt sind und damit berücksichtigt werden (vgl. „Die fünf Weisen“).
Die ursprünglichen Formeln von COCOMO II wurden auf Basis von 160 Projekten ermittelt. Diese Basis ist im Laufe der Zeit auf 250 Projekte angewachsen.
Für COCOMO-Varianten ist die Zahl der zugrundeliegenden Projekte dagegen
teilweise noch recht gering. (Seibert [2005])
Beispiel: COCOTS zur Schätzung der Kosten für Evaluation, betriebsspezifischen
Anpassung und Integration von Standardsoftware basierte im Jahr 2005 auf lediglich 20 Projekten.
COCOMO II wird laut Aussage von Barry Boehm laufend weiter entwickelt. Die
Umrechnungstabellen von Function Points in KSLOC sind noch großen Änderungen unterworfen. Auf die Frage, ob Backfiring bereits praktisch eingesetzt werden
kann, antwortete Barry Boehm im Jahr 2005: „Wir arbeiten darauf hin, haben aber
ähnliche Hürden zu überwinden, wie sie die Funktionspunktleute früher hatten.“
(Seibert [2005])
Sechs Jahre später hat sich COCOMO zu einem wichtigen Schätzwerkzeug entwickelt. Beispielsweise bietet die Cost Xpert Tool Suite (Cost Xpert [2011a]) der
Firma Cost Xpert, einem Co-Autor der COCOMO-II-Methode, COCOMO-Schätzungen an, die – laut Aussage von Cost Xpert – schon „out of the box“ mit einer
Genauigkeit von ±20 % aufwarten können. Bei einer Kalibrierung der Projektdatenbank auf firmenspezifische Projekte soll sogar eine Abweichung von unter
±10 % zwischen den Schätzungen und den späteren wirklichen Werten die Regel
sein. (Cost Xpert [2011b])
106
3.7 Was ist ein Personenmonat?
Viele Zeit-Schätzverfahren liefern als Ergebnis eine Anzahl von Personenmonaten
(PM).
Allerdings ist der Wert nicht unproblematisch:
1. Problem
– Ein PJ (Personenjahr) hat nur (9–)10 PM (Personenmonate)
– Ein PM hat höchstens 16 PT (Personentage) und nicht etwa 20
– Ein PT hat höchstens 6 Ph (Personenstunden) und nicht etwa 8
– Ein PJ entspricht somit 1000 Ph effektiver Projektarbeit und nicht etwa
1600 = 200 · 8
Das heißt, man muss sich zunächst einmal darauf verständigen, was die Begriffe
PJ, PM, PW, PT und Ph eigentlich bedeuten.
Balzert [1998] berechnet die Bruttoarbeitszeit wie folgt:
– 37-Stundenwoche
– 5-Tagewoche
– 20,8 Arbeitstage/Monat
– 10 Monate/Jahr (wg. Urlaub und Krankheit)
⇒
–
–
–
–
1 PTbrutto = 37/5 h = 7, 4 h
1 PWbrutto = 37 h
1 PMbrutto = 7, 4 h · 20, 8 = 154 h (153, 92 h)
1 PJ = 10 · 153, 9 h = 1539 h
Die Nettoarbeitszeiten berechnet er einfach, indem er die 1539 h auf 12 Monate
verteilt:
– 1 PMnetto = 1539 h/12 = 128 h (128, 25 h)
– 1 PTnetto = 128, 25 h/20, 8 = 6, 2 h
– 1 PWnetto = 6, 2 h · 5 = 31 h
Dabei bleiben allerdings die Ausfallzeiten im Projekt wegen anderer Aufgaben
unberücksichtigt.
107
Ich führe daher zusätzlich den Begriff der Projektarbeitszeit ein, die nur die Arbeitszeit berücksichtigt, die ein Mitarbeiter tatsächlich für das zugehörige Projekt
aufbringt (reale Projektarbeitszeit):
– 1 PTPA = 6 h
– 1 PWPA = 4 · 6 h = 24 h
– 1 PMPA = 17 · 6 h = 102 h (oder 16 · 6 h = 96 h)
– 1 PJPA = 10 · 102 h = 1020 h
Wenn man einen Mitarbeiter von allen anderen Arbeiten entlastet, sind theoretisch
auch folgende Arbeitszeiten möglich (Wunschziel):
– 1 PTPAe = 8 h
– 1 PWPAe = 5 · 8 h = 40 h
– 1 PMPAe = 20, 8 · 8 h = 166 h
– 1 PJPAe = 10 · 166 h = 1660 h
Dies stimmt im Prinzip mit den von Balzert eingeführten Bruttoarbeitszeiten überein. Im Allgemeinen können jedoch nur wenige Mitarbeiter von anderen Aufgaben entlastet werden. Dies ist aber auch gar nicht notwendig. Nur die Mitarbeiter,
die kritische Vorgänge bearbeiten, sollten von projektfernen Arbeiten möglichst
ferngehalten werden. Vor allem im Critical-Chain-Projekt-Management (siehe
Abschnitt 4.5) ist es üblich, Mitarbeiter, die an der so genannten kritischen Kette
arbeiten, vollkommen von anderen Aufgaben zu entlasten.
Mit welchen Begriffen man arbeitet ist letztlich egal, wenn sich alle Projektbeteiligten einig sind, was unter PJ, PM und PT zu verstehen ist. Auf eine stundengenaue Schätzung sollte man allerdings verzichten. Ein Mitarbeiter leistet an einem
12h-Tag i. Allg. weniger als an einem 8h-Tag (DeMarco [1998]).
Solange nicht bekannt ist, was PJ, PM, PW und PT genau bedeutet, kann die
Monatsproduktivität allerdings nicht in Jahres- oder Tagesproduktivitäten umgerechnet werden.
Die Produktivität wiederum ist wichtig, um z. B. den Bedarf an Mitarbeitern für
bestimmte Aufgaben zu ermitteln.
Die Produktivität eines Programmierers wird häufig in LOC/PM (LOC = Lines
of Code) oder NCSS/PM (NCSS = Non Commented Source Statements – HP
– schlecht, da Kommentare nichts zählen, aber wichtig sind) gemessen. Neben
dem Maß LOC gibt es natürlich noch viele weitere Maße, wie HTML-Seiten/PT,
AVI-Sekunden/PW, Platinen-Bauteile/PM etc., die wesentlich von der Tätigkeit
des Spezialisten abhängen.
108
Beispiel
Aufgabe:
200 LOC-Programm erstellen
Produktivität: 25 LOC/(PT · MA)
Dauer:
(MA = Mitarbeiter)
5 PT
Bedarf MA =
=
=
=
Aufwand/Dauer
(200 LOC/25( LOC/(PT · MA)))/5 PT
8 PT · MA/5 PT
1, 6 MA
Man beachte, dass die Produktivität für jede mögliche Definition von Personenmonat andere Werte hat. Wenn man davon ausgeht, dass eine Person in einem
Jahr eine gewisse Leistung (z. B. 2000 LOC) erbringen kann, ergibt sich folgendes Bild:
2000 LOC/PJ
= 200 LOC/PMbrutto =
48 LOC/PWbrutto = 9, 6 LOC/PTbrutto = 1, 3 LOC/Phbrutto
2000 LOC/PJ
= 166, 6̄ LOC/PMnetto =
40 LOC/PWnetto = 8 LOC/PTnetto = 1, 08 LOC/Phnetto
2000 LOC/PJPA
47 LOC/PWPA
= 200 LOC/PMPA =
= 11, 8 LOC/PTPA = 1, 96 LOC/PhPA
2000 LOC/PJPAe = 200 LOC/PMPAe =
48 LOC/PWPAe = 9, 6 LOC/PTPAe = 1, 00 LOC/PhPAe
Ich mag die Messung in Bruttozeiten (= 1 Jahr hat 10 Monate) lieber, da dann die
Zuordnung reale Zeit ↔ Projektzeit einfacher ist. August, Osterwoche, Pfingstwoche, 2 Wochen Weihnachten entfallen ⇒ Das reale Jahr hat auch 10 Monate,
in denen (voll) gearbeitet wird.
Außerdem ist mir die Messung in Projektarbeitszeiten (6 h/Tag, 16–17 Tage/Monat) lieber, als die übliche Vollarbeitszeiten, da auch diese Werte leichter
mit der Realität in Einklang zu bringen sind.
Wenn ich drei Aufgaben à 6 PTPA bearbeiten lasse und erhalte nach einem realen Monat das gewünschte Ergebnis, habe ich rein rechnerisch sogar etwas Zeit
gewonnen (da 18 PT PA = 1, 125 PM PA ).
Ein Mitarbeiter muss im Durchschnitt etwas mehr leisten als geplant, da Krankheit
und Dienstreisen den Durchschnitt drücken. Wenn man die üblichen Ferienmonate, wie oben angedeutet, intern als Nullarbeitszeiten rechnet, dann ist jede Arbeit,
die die Mitarbeiter in dieser Zeit leisten, eine „Mehrarbeit“, die mit anderen außerplanmäßigen Fehlzeiten gegengerechnet werden kann.
109
erstes (bereits gelöstes) Problem
Alle anderen Definitionen von Personenmonaten etc. sind im laufenden Projekt
schwieriger mit der Realität abzugleichen, da die vom Mitarbeiter zu leistende
„Mehrarbeit“ (gegenüber den errechneten Werten) höher ist.
(größeres) zweites Problem
Das Maß Ph (Personenstunde) ist unbrauchbar. Tom DeMarco (DeMarco [2001])
berichtet von wissenschaftlichen Untersuchungen (leider ohne die genaue Quelle
anzugeben), die ein erstaunliche Ergebnis liefern.
Eine Function-Point-Schätzfunktion wird durch Minimierung der Summe der Abstandsquadrate einer Menge von bekannten FP-Werten bereits abgeschlossener
Projekte ermittelt (vgl. Abbildung 3.7). Je kleiner diese Summe der Abstandsquadrate ist, desto brauchbarer ist die Schätzfunktion.
Nun sollte man vermuten, dass eine Verfeinerung der Messung auch eine Verkleinerung der Summe der Abstandsquadrate zur Folge hat. Wenn man also die
Gesamtpunktzahl jedes einzelnen Projekts anhand der Personenstunden ermittelt,
sollte man eine bessere Schätzfunktion erhalten, als wenn man dies Gesamtpunktzahlen anhand der Personentage ermittelt, da im ersten Fall Überstunden berücksichtigt werden und im zweiten nicht.
Doch das Gegenteil ist der Fall. Wenn man die Berechnung auf Basis der Personenstunden vornimmt wird die Summe der Fehlerquadrate größer!
Das heißt, dass das Maß „Personentag“ die Produktivität der Mitarbeiter genauer
beschreibt, als das Maß „Personenstunde“. Der Grund dafür ist, dass Überstunden
so gut wie keine Auswirkung auf das Arbeitsergebnis haben: Eine Person leisten
im Durchschnitt an zwei 12-Stundentagen genauso viel wie an zwei 8-StundenTagen (und nicht etwa so viel wie an drei 8-Stunden-Tagen)!
Fazit 1
Überstunden schaden fast immer (außer wenn man einen kurzen Endspurt hinlegt
und danach eine Erholungsphase einschiebt). Laut DeMarco bringen Überstunden
folgende Nachteile mit sich:
– Qualitätsminderung
– Burnout bei den Mitarbeitern
– Ineffiziente Nutzung der normalen Arbeitszeit
– Erhöhte Personalfluktuation
Aus diesem Grund postuliert Kurt Beck, der Erfinder des Extreme Programming,
in seinem „Manifest“ (Beck [2000]) u. a. das Prinzip der „40-Stunden-Woche“.
Auch er hält Überstunden für kontraproduktiv.
110
Fazit 2
Schätzungen sollten immer tagesgenau und nie stundengenau vorgenommen werden.
(größtes) drittes Problem
Wenn eine Person in einem Monat 1 PM Arbeit leistet, heißt das nicht, dass 2
Personen in einem halben Monat auch 1 PM Arbeit leisten.
Grund: Kommunikationsoverhead: Zwei Mitarbeiter müssen sich absprechen.
Das heißt, wenn eine Person 8 Tage an einem Vorgang arbeitet, reichen 1,6 Personen nicht aus, um den Vorgang bereits in 5 Tagen zu erledigen (die obige Rechnung ist also fehlerhaft). Die zweite Person muss in dieser Zeit vielleicht nicht
Vollzeit, aber zumindest deutlich mehr als 60 % Prozent seiner Arbeitszeit an diesem Vorgang mitarbeiten.
Allgemeiner: Wenn n Personen gleichzeitig an einem Problem arbeiten, ergeben
sich n · (n − 1)/2 2-Personen-Kommunikationskanäle, außerdem gibt es 3-Personen-Kommunikation, 4-Personen-Kommunikation . . . und Team-Kommunikation (Lagebesprechung etc.). Das heißt, der Kommunikationsoverhead wächst mit
mindestens O(n2 ) mit der Anzahl der an einer Aufgabe beteiligten Personen.
Wenn beispielweise der Kommunikationsaufwand zwischen je zwei Teammitgliedern, die an einem Problem gemeinsam arbeiten, bei durchschnittlich 10 %, d. h.
bei 4 h/Woche liegt, so berechnet man die die Dauer des zugehörigen Vorgangs
mittels d = 1/(MA ∗ pAL), wobei pAL die produktive Arbeitsleistung eines Mitarbeiters ist (die kommunikative Arbeitsleistung kAL ist gleich 1 − pAL):
1 Person braucht 1, 0 (= 1/(1 · 1, 0)) Zeiteinheiten
2 Personen brauchen 0, 5̄ (= 1/(2 · 0, 9)) Zeiteinheiten
3 Personen brauchen 0, 41 (= 1/(3 · 0, 8)) Zeiteinheiten
9 Personen brauchen 0, 5̄ (= 1/(9 · 0, 2)) Zeiteinheiten
11 Personen werden gar nicht fertig :-)
Oder kurz: Viele Köche verderben den Brei!
Achtung: Diese Beobachtung besagt nicht, dass nicht mehrere unabhängige Vorgänge parallel ausgeführt werden können, um die Projektdauer zu beschleunigen (z. B. Tests auf verschiedenen Zielplattformen oder gleichzeitige Entwicklung von zwei unabhängigen Modulen wie Automotor
und Fahrersitz).
111
Zeit (in Tagen)
kommunikative
Arbeitsleistung je
Mitarbeiter
(innerhalb von 10 Tagen)
10
9
8
7
6
5
4
3
2
1
0
reale Arbeitszeit
theoretisches Optimum
produktive
Arbeitsleistung je
Mitarbeiter
(innerhalb von 10 Tagen)
1 2 3 4 5 6 7 8 9 10 11
Anzahl Mitarbeiter
1 MA: kostenoptimal
3 MA: bester Kompromiss aus Kosten und Zeit (evtl. 2 MA)
5 MA: zeitoptimal (theoretisch auch 6 MA)
weitere Probleme
Weitere Probleme bei der Bewertung, wie viele Arbeit von einer Person in einem
PM geleistet werden kann, sind:
1. Verschiedene Personen leisten in derselben Zeit verschieden viel.
2. Mitarbeiter bringen nicht jeden Tag volle Leistung (Schnupfen, private Probleme, Spannungen im Team, eine versaute Präsentation etc.).
3. Neulinge, die erst später in ein Projekt integriert werden, leisten weniger, da
sie sich erst einarbeiten müssen.
4. Neulinge blockieren andere Mitarbeiter, d. h., auch erfahrene Projektmitarbeiter leisten weniger, wenn sie zusätzlich einen Neuling einarbeiten müssen.
wichtige Erkenntnis
Hilfskräfte können Projektmitglieder von Routineaufgaben, wie Kopieren, EMail-Vorsortierung, Telefondienst etc. entlasten, ohne den Kommunikationsoverhead drastisch zu erhöhen. Neues Fachpersonal kann dies nicht.
Ein Vier-Personen-Team plus Hilfskraft ist laut Tom DeMarco (DeMarco [2001])
nicht nur billiger, sondern auch noch effizienter als ein Fünf-Personen-Team ohne
Hilfskraft.
112
Kapitel 4
Planung
Planung ist eine der Hauptaufgaben des Projektleiters.
Planung wird oft nicht sonderlich geliebt:
– Einfach mal loslegen ist einfacher, als vorher zu planen
– Planen lohne sich eh nicht, da ja doch alles anders komme.
– Planen behindere die Kreativität.
Nein: Planung ist kreativ, planloses Herumstochern im Nebel dagegen nicht.
Es gibt drei Möglichkeiten mit Planung umzugehen:
Erst handeln, dann denken
Es gibt viele (schlechte) Projektleiter, die Planung hassen und nur als Show für
das Management veranstalten, sich im Projektverlauf aber wenig darum scheren.
„Fangt schon mal an, den Papierkram machen wir später.“
Wenn man jedoch versucht Zeit zu sparen, indem man handelt bevor man denkt,
verbraucht man in der Summe viel mehr Zeit (spätere Fehlerbereinigung).
Denken statt Handeln
Es gibt aber auch (schlechte ) Projektleiter, die Planung zelebrieren: Alles wird
geplant und analysiert (PC-Tools); Alternative über Alternative wird untersucht,
nur getan wird nichts.
Erst denken, dann handeln: Storming, Norming, Performing
Saubere Planung besteht aus zwei Phasen, dann wird gehandelt:
Storming:
Ideensammlung; noch unstrukturiert (z. B. Brainstorming).
Norming:
Nun werden die Ideen sortiert und es wird geplant.
Performing: Schließlich werden die Pläne auch durchgeführt.
Brainstorming bedeutet, dass möglichst viele Ideen gesammelt werden, die nicht
bewertet werden (gut/schlecht etc.).
Die Stromingphase sollte lange genug dauern.
113
Die Planung von Projekten erfolgt normalerweise in drei Schritten:
grobe Projektplanung
z.B. Projektstrukturpläne
feinere Projektplanung
z.B. Netzpläne oder auch Balkendiagramme
Detailplanung
z.B. Balkendiagramme
Bei kleinen, übersichtlichen Projekten werden oft keine Netzpläne, sondern nur
eine einfache Grobplanung und Balkendiagramme erstellt.
4.1 Projektpläne
Alles muss geplant werden ⇒ viele Pläne. Diese sollten immer aktuell gehalten
werden – sonst sind sie nur Show und sind den Aufwand nicht wert, den man in
sie investiert hat.
Beispiele für Pläne
– Organisationsplan
Verantwortlichkeiten, Kompetenzen
– Kommunikationsplan, Berichts- und Informationswesen
Wer informiert wen wann worüber in welcher Form?
– Budget
Wie viel, wann, von wem, wofür?
– Arbeitspläne
Aufgaben (bzw. Vorgänge): Was, wann, wer?
– Personalpläne
Wer, was, wann, wann nicht (Urlaub etc.)?
– Schulungspläne
Projektteam, Anwender, Systembetreuer
– Ausstattungspläne
– Beschaffungspläne
– Testpläne
114
– Wartungspläne
– Kontrollpläne
Soll/Ist-Vergleiche, Review etc.
Ergebnis: stopp/zurück/weiter
– Änderungspläne
– Abbruchplan
– etc.
Wie gesagt: Irgendwann sollte man auch etwas arbeiten. :-)
4.2 Grobplanung
Bevor man Detailpläne erstellen kann, müssen erst einmal grobe Beschreibungen
der Aufgaben vorliegen. Man beachte, dass die Grobplanung eine gute Basis für
frühe Schätzungen darstellt.
4.2.1 Projektstrukturplan
Ein Projekt sollte zunächst hierarchisch strukturiert werden: Zunächst nach Komponenten, dann nach Aktivitäten, die notwendig sind, um die Komponenten zu
erstellen.
Dazu dienen die so genannten Projektstrukturpläne (PSP, engl.: work breakdown
structures, WBS).
Komponenten-Projektstrukturplan (KPSP)
Internet−Auftritt
Metzgerei Meier
Startseite
Katalog
Bestellung
...
Fleisch Wurst Käse Sonstiges
115
Aktivitäten-Projektstrukturplan (APSP)
Internet−Auftritt
Metzgerei Meier erstellen
Tools und Techniken
auswählen
Content
beschaffen/erstellen
Seitenstruktur
festlegen
Layout
festlegen
Text
Fotos
Videos
Web−Seiten
erstellen
Startseite
erstellen
Katalog
programmieren
Bestell−
komponente
programmieren
Abbildung 4.1: APSP in MS Project 2010
Prerequisite-Tree
(Klein et al. [2005]) fehlt noch
116
Grafiken
4.3 Feinplanung, insb. Ressourcen-Management
Im Aktivitäten-Prozessstrukturplan enthalten die Blätter die so genannten Vorgänge:
Ein Vorgang ist eine in sich abgeschlossene genau spezifizierte Aktivität, die innerhalb einer angemessenen Zeitdauer durchgeführt werden kann. Wenn diese
Aussage für ein APSP-Blatt noch nicht zutrifft, muss der entsprechende Knoten
eventuell in weitere Teilaufgaben aufgesplittet werden.
Für jeden Vorgang wird Folgendes festgelegt:
– Name des Vorgangs
– Abhängigkeiten von anderen Vorgängen
– Zeitdauer (z. B. Mehrpunktschätzung mittels Dreiecks- oder Beta-Verteilung)
– Kosten (z. B. Mehrpunktschätzung mittels Dreiecks- oder Beta-Verteilung)
– Personal und weitere benötigte Ressourcen
Ergebnis, Kosten und Zeitdauer eines Vorgangs müssen natürlich mit der Gesamtplanung und den Gesamtzielen vereinbar sein. Das heißt, die Summe der Vorgangskosten einer Projektphase sollten in etwa gleich den geschätzten Kosten für
diese Phase sein. Und die Gesamtdauer aller Vorgänge sollte der geschätzten Dauer entsprechen, wobei Vorgänge durchaus parallel ablaufen können.
4.3.1 Netzpläne
Netzpläne dienen dazu, Abhängigkeiten zwischen Vorgängen zu visualisieren.
Darüber hinaus können sie weitere Informationen enthalten:
Vorgangs- oder Ereignisnummer, frühester/spätester Starttermin/Endtermin,
Dauer , Kosten, Ressourcen, Pufferzeitenetc.
Es gibt mehrere Arten von Netzplänen:
Vorgangspfeil-Netzpläne (VPN; Vorgänge werden als Beziehungen modelliert)
Vorgang
117
Ereignisknoten-Netzpläne (EKN; Beziehungen zwischen Ereignissen = Ergebnissen von Vorgängen werden modelliert, z. B. Vorgang „Startseite erstellen“ =
ˆ Ereignis „Startseite wurde erstellt“).
Ereignis
Ereignis
Vorgangsknoten-Netzpläne (VKN; Beziehungen zwischen Vorgängen werden modelliert; ähnlich EKN).
Vorgang
Vorgang
Vorgangspfeil-Netzpläne (VPN) werden als historisch erste Darstellungsform der
Netzplantechnik angesehen. Diese Art der Darstellung wurde 1956 für die Critical-Path-Method entwickelt. Vorgangsknoten-Netzpläne (VKN) wurden 1958 im
Zusammenhang mit der Mèthode des Potentiels Metra (Metra Potential Method,
MPM) eingeführt. Im selben Jahr wurden im Rahmen der Programm Evaluation und Review Technique (PERT) die Ereignisknoten-Netzpläne (EKN) erstmals
vorgestellt. Heute sind VPN und EKN nur noch von geschichtlichem Interesse.
Die Vorgangsknoten-Netzpläne werden allgemein verwendet. Häufig spricht man
auch (eigentlich fälschlicherweise) von PERT-Diagrammen oder PERT-Netzplänen, meint damit heute aber stets VPNs und nicht die veralteten EKNs. (Kelley
und Walker [1959], Miller [1963], Bouyssou und Vanderpooten [2011])
VPN: ursprünglich Critical Path Method (CPM, Kelley und Walker [1959])
EKN: ursprünglich Program Evaluation and Review Technique (PERT, Miller
[1963])
VKN: ursprünglich Mèthode des Potentiels Metra (MPM, Bouyssou und Vanderpooten [2011]), heute Standard für alle Methoden
Anmerkung
– CPM arbeitet mit Ein-Punkt-Schätzung
– PERT arbeitet mit Drei-Punkt-Schätzung; Beta-Verteilung (optimistisch,
pessimistisch, wahrscheinlich)
Bei VPNs wird die Dauer direkt beim Vorgang notiert. Die Knoten enthalten eine
laufende Nummer sowie den frühesten und den spätesten Starttermin.
Bei EKNs wird die Dauer ebenfalls an den Beziehungspfeilen angebracht. Laufende Nummer, frühester und spätester Termin werden in den Knoten notiert.
118
In VKNs wird die gesamte Information (laufende Nummer, Bezeichnung, frühester und spätester Starttermin, Dauer und freie Pufferzeit, frühester und spätester
Endtermin etc.) in den Vorgangsknoten notiert. An den Pfeilen wird die Art der
Beziehung notiert, zumindest, wenn es sich nicht um eine Standard-Ende-AnfangBeziehung handelt (siehe weiter unten).
Die frühesten Start- und Endtermine der Vorgänge werden zunächst ausgehend
vom ersten hin zu späteren Vorgängen mit Hilfe der Dauer und der Abhängigkeiten ermittelt. Dieser Vorgang wird Vorwärtsrechnung genannt. Dann können die
spätesten Start- und Endtermine ausgehend vom letzten Vorgang ermittelt werden.
Dieser Vorgang heißt Rückwärtsrechnung.
Ein kritischer Knoten ist ein Knoten, dessen frühester Starttermin gleich dessen
spätestem Starttermin ist. Jede Verzögerung, an der dieser Knoten beteiligt ist, hat
eine Verzögerung der gesamten Phase und damit des Gesamtprojektes zur Folge,
wenn man die verlorene Zeit nicht anderweitig wieder hereinarbeiten kann. In
einem VKN spricht man auch von kritischen Vorgängen.
Ein kritischer Pfad ist eine Liste oder gar ein ganzes Netz zusammenhängender
kritischer Knoten.
Pufferzeiten
Die Differenz zwischen frühestem und spätestem Starttermin (oder Endtermin)
eines Vorgangs heißt gesamte Pufferzeit (des aktuellen Vorgangs). Um diese Zeitspanne kann ein Vorgang verzögert werden, ohne das Gesamtprojekt zu verzögern.
Dabei kann es allerdings passieren, dass die Pufferzeiten nachfolgender Vorgänge verringert werden. Ein kritischer Vorgang zeichnet sich also dadurch aus, dass
seine gesamte Pufferzeit gleich Null ist.
Daneben kann man für die einzelnen Vorgänge auch noch die freie Pufferzeit berechnen. Das ist diejenige Zeit, um die der Start eines Vorgangs verzögert werden
kann, ohne dass sich dadurch die Pufferzeit eines Nachfolgevorgangs verringert.
Die freie Pufferzeit berechnet man aus dem frühestens Endtermin eines nichtkritischen Vorgangs und dem Minimum des frühesten Start-Termins aller direkten Nachfolgervorgänge. Die freie Pufferzeit eines Vorgangs ist stets kleiner oder
gleich dessen gesamte Pufferzeit.
Für Vorgänge kann auch ein fixer Start- oder Endtermin vorgegeben werden. In
diesem Fall kann die Vorwärts- und die Rückwärtsrechnung eventuell negative
Pufferzeiten und damit einen so genannten zeitinkonsistenten Netzplan liefern.
Beispiel
Für ein Software-Projekte werde eine geeignete Datenbank gesucht. Im Aktivitäten-Projektstrukturplan wurden folgende Vorgänge für diese Teilaufgabe ermittelt:
119
Nr.
Name
Vorgänger Nachfolger Dauer
1 Phasenstart
–
2; 4
0d
2 DBMS anschaffen
1
3
6d
3 DBMS installieren
2
5; 6
2d
4 Testszenario entwickeln
1
5; 6
7d
5 Testdaten einspielen
3; 4
7
1d
6 Testszenario implementieren 3; 4
7
3d
7 DBMS testen und wählen
5; 6
8
2d
8 Phasenende
7
–
0d
In der Spalte „Vorgänger“ wird jeweils angegeben, welche Vorgänge abgeschlossen sein müssen, bevor der aktuelle Vorgang starten kann. In der Spalte „Nachfolger“ sind diejenigen Vorgänge aufgeführt, die frühestens starten können, wenn
der aktuelle Vorgang abgeschlossen ist.
Die verschiedenen Visualisierungsmöglichkeiten dieser Vorgangsbeziehungen mit
Hilfe Netzplänen werden in Abbildung 4.2, Abbildung 4.3 und Abbildung 4.4
gezeigt.
Anmerkung 1
Was bedeutet eigentlich „Vorgang A beginnt am Tag X“ bzw. „Vorgang A endet
am Tag X“? Darunter verstehe ich Folgendes:
Vorgang A beginnt am Tag X
= Vorgang A beginnt am Tag X um 24:00 Uhr
= Vorgang A beginnt am Tag X+1 um 00:00 Uhr
= Vorgang A beginnt am Tag X+1 um 8:00 Uhr
(reguläre Arbeitszeit)
Vorgang A endet am Tag X
= Vorgang A endet am Tag X um 24:00 Uhr
= Vorgang A endet am Tag X um 17:00 Uhr
(reguläre Arbeitszeit)
Das heißt, aus Sicht der Projektarbeitszeit gilt folgende Gleichung:
Tag X, 17:00 Uhr = Tag X+1, 8:00 Uhr.
Der Grund ist, dass die Mitarbeiter von 17:00 eines Tages bis 8:00 Uhr des Folgetages nichts für das Projekt machen, sondern auch noch ein Privatleben haben.
(Die genauen Anfangs- und Endzeiten variieren natürlich von Unternehmen zu
Unternehmen.)
Anmerkung 2
Obwohl Netzdiagramme den zeitlichen Aspekt stark betonen, eignen sie sich auch
zur Kosten- und Ressourcenschätzung und -planung.
120
121
DBMS−Testlizenzen
anschaffen (2)
6
0
0
1
Phasenstart
EKN
6
6
7
8
4
Testszenario
entwickelt
6
2
Testlizenzen
angeschafft
6
2
2
8
8
3
DBM−Systeme
installiert
DBM−Systeme
installieren (3)
2
8
8
1
4
8 10
3
1
3
3
11 11
5
11 11
6
Testszenario
implementiert
9 11
5
Testdaten
eingespielt
Testszenario
implementieren (6)
3
Testdaten
einspielen (5)
1
Abbildung 4.2: VPN- und EKN-Netzpläne für die Auswahl eines Datenbank-Management-Systems
7
6
Testszenario
entwickeln (4)
7
Phasenstart
(1)
VPN
2
2
DBMS
testen und
auswählen (7)
2
13 13
7
DBMS
getestet und
ausgewählt
13 13
6
122
0
0
0
0
1
Meilenstein
kritisch
nicht−kritisch
0
0
Phasenstart
VKN
0
1
fE
sE
7
1
fS
D
fE
sS
gP
sE
=
=
=
=
=
=
7
8
6
6
4
2
0
frühester Starttermin
Dauer
frühester Endtermin
spätester Starttermin
gesamte Pufferzeit
spätester Endtermin
6
6
8
8
3
DBM−Systeme
installieren
1
2
9
11
5
8
8
3
0
11
11
6
Testszenario
implementieren
10
8
Testdaten
einspielen
Abbildung 4.3: VKN-Netzplan für die Auswahl eines Datenbank-Management-Systems
D
gP
<Nummer>
Vorgangsname
fS
sS
6
0
Testszenario
entwickeln
0
0
2
DBM−Systeme
anschaffen
2
0
13
13
0
0
Phasenende
11
11
13
13
8
13
13
7
DBMS testen
und ausgewählen
4
3
( ( 0
%
'+
A
F6G
6>
L8
I >A
56
; H:
IA
; H:
778 9
;8 :
IA
C9
; H:
787= 96
56
<7
=8
6>
N >F
L8
; 6>
@ ED>
A
778 9
E
F6G
>
E
; 6>
D
M6
8
AG
. / -& , '+ I>
F6G
A
@ ED>
; H:
KJ G
>A
7875 96
BC
IA
8
; H:
D
bc a
6DC
7G
C
=7 >
>A
d
86
JK G
0
C
AG
>
F6G
;
A
;
A
O >F
O >F
0
!"
( ' ( &
#$
#$
.&
#
3
7875 96
7G
`a
86
7= >
? 6C
AG
C
7A
JJ 6>
6>
\ CH
I >A [
UZ
1
YQ
W VX
V
TU
RS
PQ
86 [
B8 C
6
8>
>D ; 9>
< C KJ 6
86 [
B8 C
6
8 >9
^8 >]
9
0
D
. / -& , '+ 6_D> [
22 MH J6
6 J>
8 >D M H
C9 7 6>
> J >6
G
I >A [
9 9
8 >9 8 >9
; > ^8 >
KJ 6 ]
9
VQ
)
)
!*
#$
"
!"
& &
@ ED>
A9
@7 >
;:
778 9
778 9
56
7A
BC
778 9
7@ >
778 9
; 6>:
<7
56
;8 :
D
?>
=6
;:
F6G
8>
8 >A9
?>
; 6>:
56
qu
k
kl
qd s
qr s
t
g
ic j
pj
m
<H
I >A
k
h ag c on
ef
l
J>
@ HC
123
Abbildung 4.4: VKN-Netzplan für die Auswahl eines Datenbank-Management-Systems (mit MS Project 2003 erstellt)
1 Vorgangsbeziehungen
Es werden vier Vorgangsbeziehungen unterschieden:
Normalfolge: Ende-Anfang (EA)
Anfangsfolge: Anfang-Anfang (AA)
Endfolge:
Ende-Ende (EE)
Sprungfolge: Anfang-Ende (AE)
Normalfolge
Eine Normalfolge (EA) besagt, dass der nächste Vorgang erst begonnen werden
darf, wenn der vorherige beendet wurde.
Beispiel
Design
EA
Implementierung
Mit der Implementierung kann evtl. auch schon etwas früher begonnen werden,
z. B. 5 Tage vor Ende des Designs.
EA − 5d
Design
Implementierung
Es ist auch möglich einen etwas späteren Start als das Ende des Design festzulegen.
EA + 3d
Design
Implementierung
Anfangsfolge
Eine Anfangsfolge (AA) besagt, dass ein zweiter Vorgang gleichzeitig mit dem
ersten anfangen muss.
Beispiel
Implementierung
auf der
Zielplattenform
AA
regelm. Backup
der
Zielplattform
oder die regelmäßigen Backups starten schon einen Tag vorher
Implementierung
auf der
Zielplattenform
AA−1d
regelm. Backup
der
Zielplattform
124
Beachten Sie, dass der Anfang der regelmäßigen Backups vom Anfang der Implementierung auf der Zielplattform abhängt und nicht umgekehrt. Mit Hilfe eines
Balkendiagramms (Gantt-Diagramm Abschnitt 4.3.3) kann man diesen Zusammenhang besser visualisieren. Die linke Seite des Balkens wird am Start-Datum
in einen Kalender eingetragen und die rechte Seite am Ende-Datum.
Implementierung auf Zielplattform
AA
Backups auf Zielplattform
...
Implementierung auf Zielplattform
AA−1d
Backups auf Zielplattform
...
Endfolge
Eine Endfolge (EE) besagt, dass ein zweiter Vorgang zusammen mit dem ersten
beendet wird.
Beispiel
Netzpläne
Übergabe
an
Kunden
EE
regelm. Backup
auf der
Zielplattform
Übergabe
an
Kunden
EE+1d
regelm. Backup
auf der
Zielplattform
125
Balkendiagramme
Übergabe an Kunden
EE
... Backups auf Zielplattform
Übergabe an Kunden
EE+1d
... Backups auf Zielplattform
Sprungfolge
Eine Sprungfolge (AE) besagt, dass der zweite Vorgang erst beendet werden darf,
wenn der erste begonnen wurde.
Beispiel
Netzpläne
neue Anwendung
in
Betrieb
AE
alte Anwendung
in
Betrieb
neue Anwendung
in
Betrieb
AE+5d
alte Anwendung
in
Betrieb
126
Balkendiagramme
neue Anwendung In Betrieb ...
AE
... alte Anwendung in Betrieb
neue Anwendung In Betrieb ...
AE+5d
... alte Anwendung in Betrieb
Die alte Anwendung darf erst beendet werden, wenn die neue in den Einsatz
kommt.
Relative Verschiebung von Start- und Endterminen
Oftmals fallen Anfang und Ende von zwei Vorgängen nicht genau zusammen,
sondern unterscheiden sich um einige Tage. Wie in den Beispielen gezeigt wurde,
notiert man dies wie folgt:
EA + 5 d: Vorgang 2 startet frühestens 5 Tage nach Ende von Vorgang 1
EA − 3 d: Vorgang 2 startet frühestens 3 Tage vor Ende von Vorgang 1
AA + 2 d: Vorgang 2 startet frühestens 2 Tage nach Start von Vorgang 1
AA − 1 d: Vorgang 2 startet frühestens 1 Tag vor Start von Vorgang 1
EE + 4 d: Vorgang 2 endet frühestens 4 Tage nach Ende von Vorgang 1
EE − 4 d: Vorgang 2 endet frühestens 4 Tage vor Ende von Vorgang 1
AE + 6 d: Vorgang 2 endet frühestens 6 Tage nach Start von Vorgang 1
AE − 2 d: Vorgang 2 endet frühestens 2 Tage vor Start von Vorgang 1
127
Man beachte, dass mit Hilfe von Addition und Subtraktion von Zeitabständen jede
Abhängigkeit zwischen zwei (endlichen) Vorgängen als Normalfolge, Anfangsfolge, Endfolge oder Sprungfolge notiert werden kann. Bei der Auswahl einer
geeigneten Folge kommt es also nicht auf formale, sondern nur auf praktische
Überlegungen an.
4.3.2 Vorwärts- und Rückwärtsrechnung
Nachdem in einen VKN-Netzplan die Vorgänge, die jeweilige Vorgangsdauer und
die Beziehungen zwischen den Vorgängen (als Pfeile) eingetragen wurden, kann
man die frühesten und spätesten Start- und End-Termine mittels der so genannte
Vorwärts- und Rückwärtsrechnung ermitteln. Daraus lassen sich anschließend die
Pufferzeiten und der kritische Pfad ableiten.
Am Beispiel der Auswahl eines DBMS (Abbildung 4.3) sollen die beiden Algorithmen für den Fall, dass es nur EA-Beziehungen gibt, erläutert werden.
Algorithmus: Vorwärtsrechnung
In den Dummy-Vorgang „Phasenstart“ oder „Projektstart“ wird als frühester
Start- und Endtermin jeweils 0 eingetragen.
Das heißt, das Projekt beginnt am nullten Tag um 24:00 Uhr, also am 1. Tag
um 8:00 Uhr. Um welchen Tag es sich hierbei konkret handelt, muss separat (im
Gantt-Diagramm; Abschnitt 4.3.3) festgelegt werden.
Solange es noch Vorgänge gibt, deren frühesten Start- und Endtermine noch nicht
eingetragen wurden, führe für jeden dieser Vorgänge Folgendes aus:
Wenn die spätesten Endtermine aller EA-Vorgänger-Vorgänge ermittelt wurden:
Trage das Maximum dieser Endtermine als frühesten Starttermin für
den aktuellen Vorgang ein.
Trage als frühesten Endtermin des aktuellen Vorgangs den frühesten
Starttermin plus der Dauer des aktuellen Vorgangs ein.
Dieser Algorithmus endet, wenn der früheste Start- und der der früheste End-Termin in den Dummy-Vorgang „Phasenende“ oder „Projektende“ eingetragen wurden. Diese beiden Werte stimmen überein (da die Dauer des Dummy-Vorgangs
0 Tage beträgt). Dieser Wert sagt aus, wie lange es dauert, die Phase bzw. das
Projekt zu beenden (wenn die Dauer jedes einzelnen Vorgangs richtig geschätzt
wurde).
128
Algorithmus: Rückwärtsrechnung
Bei der Rückwärtsrechnung geht man davon aus, dass die Gesamtdauer der Projektphase bzw. des Projektes minimal sein soll.
Man initialisiert also den spätesten Start- und den spätesten Endtermin des Dummy-Vorgangs „Phasenende“ oder „Projektende“ mit denjenigen Werten, die in
diesem Vorgang als frühester Start- und Endtermin eingetragen sind.
Solange es noch Vorgänge gibt, deren späteste Start- und Endtermine noch nicht
eingetragen wurden, führe für jeden dieser Vorgänge Folgendes aus:
Wenn die spätesten Starttermine aller EA-Nachfolger-Vorgänge ermittelt
wurden:
Trage das Minimum dieser Starttermine als spätesten Endtermin für
den aktuellen Vorgang ein.
Trage als spätesten Starttermin des aktuellen Vorgangs den spätesten
Endtermin minus der Dauer des aktuellen Vorgangs ein.
Algorithmus: Pufferzeiten und kritischer Pfad
Die gesamte Pufferzeit eines einzelnen Vorgangs ermittelt man, indem man den
frühestens Starttermin vom spätesten Starttermin subtrahiert.
In Abbildung 4.3 hat der Vorgang 5 beispielsweise einen Puffer von zwei Tagen.
Der Vorgang 4 hat einen Puffer von einem Tag.
Die freie Pufferzeit eines Vorgangs ermittelt man indem man den spätesten Endtermin des Vorgangs vom Minimum der frühesten Starttermine aller Nachfolgervorgänge subtrahiert.
In Abbildung 4.3 sind die freien Pufferzeiten nicht eingetragen. Sie stimmen mit
den gesamten Pufferzeiten überein. In Abbildung 4.23 unterscheiden sich die Pufferzeiten von Vorgang Vc: Die gesamte Pufferzeit beträgt 3 Tage, die freie Pufferzeit ist dagegen 0 Tage. Das heißt, wenn sich dieser Vorgang verzögert, wird
automatisch auch die Pufferzeit des Nachfolgevorgangs Vd reduziert.
Den kritischen Pfad ermittelt man, indem man alle Vorgänge mit einer freien Pufferzeit von 0 Tagen als kritisch markiert. Man beachte, das hierbei nicht unbedingt
ein „Pfad“ enstehen muss, es kann auch ein Netz von kritischen Knoten entstehen.
Komplexere Beziehungen
In Abbildung 4.7 ist ein Netzplan angegeben, der relativ komplexe Beziehungsarten enthält: neben verschiedenen Normalfolgen finden sich dort eine Anfangsfolge und eine Endfolge. Nur eine Sprungfolge fehlt noch. Hier erfolgt die Vorwärtsund die Rückwärtsrechnung im Prinzip genauso, wie zuvor beschrieben. Allerdings müssen jetzt andere Werte übertragen werden.
129
Beispiel: Der früheste Starttermin von V3 ermittelt sich aus dem Maximum von
3 (= spätester Endetermin von V1) und 4 (= frühester Starttermin von V2 plus 4
Tage; wegen der Beziehung AA+4d).
Die in Abbildung 4.7 gezeigten Diagramme unterscheidet sich in einem wichtigen
Punkt von den von MS Project 2010 erstellten Diagrammen (Abbildung 4.8): Im
Netzplan von MS Project enthält der Vorgang V2 keinen Puffer. Aus der Tatsache,
dass der Start von V2 kritisch ist, folgert Project, dass es keinen Puffer für das Vorgangsende geben kann. Dies entspricht jedoch nicht der Faktenlage. Der andere
Unterschied ist, dass MS Project 2010 im Gegensatz zu MS Project 2003 defaultmäßig den freien Puffer im Gantt-Diagramm (siehe den folgenden Abschnitt) anzeigt. MS Project 2003 hat dagegen – wie dies auch in Abbildung 4.7 gemacht
wird – den Gesamtpuffer angezeigt. Im Gantt-Diagramm von Abbildung 4.8 werden beiden Pufferarten angezeigt: Oben der Gesamtpuffer und unten der freie Puffer.
4.3.3 Balkendiagramme (Gantt-Diagramme)
Aus Netzplänen können so genannte Balken- oder Gantt-Diagramme abgeleitet
werden (siehe z. B. Abbildung 4.7, Abbildung 4.8 oder auch Abbildung 4.5). Der
Name geht auf Henry Gantt zurück (Gantt [1913]).
Balkendiagramme betonen den Zeitaspekt mehr als Netzdiagramme, da die Balkenlänge abhängig von der Dauer des zugehörigen Vorgangs gewählt wird. Die für
Netzpläne eingeführten Beziehungen (EA, AA, EE, AE) gibt es gleichermaßen für
Balkendiagramme. (Die Beispiele des letzten Abschnittes wurden zusätzlich auch
schon in Form von Balkendiagrammen angegeben.)
130
0
. !
!
.
/ !
!
6
.
45 3
!
#
%
$,
$
1
%
23
,
$,
)
$ - - ) $ ( #
'
! "
&
!
%
*
)
EF
=>
6C
D
?
D
9
=
6G
*
*
$
&
'
+ ! "
+
#
$
)
>
B<
;5 <
: 39
-
78
131
5 A@
>
Abbildung 4.5: Gantt-Diagramm für den Netzplan aus Abschnitt 4.3.1 (mit MS Project 2010 erstellt)
132
0
0
0
0
1
0
1
0
0
2
1
1
Vb
1
0
Va
2
3
1
1
3
2
1
1
0
3
2
0
Ve
3
3
0
Vc
3
3
6
3
6
4
3
3
3
6
5
0
Vf
2
3
3
Vd
8
8
7
5
8
5
8
8
4EA
2EA
3EA, 6EA
5EA, 7EA
2d
2d
5d
0d
Vd
Ve
Vf
Ende
6
7
8
5
1EA
3d
Vc
4
1EA
2d
Vb
3
1EA
Va
2
0d
Vorgänger
1d
Start
1
Nr. Name Dauer
Abbildung 4.6: Vorgangsknotennetz und Gantt-Diagramm
8
8
8
fS
sS
D
gP
fP
fE
sE
<Nummer>
Vorgangsname
0
0
Ende
5. April 2010
12. April 2010
19. April 2010
26.April 2010
S S MDMD F S S MDMD F S S MDMD F S S MDMD F S S
Gantt−Diagramm (gemäß CPM, mit kritischen Pfad und freien sowie gesamten Pufferzeiten)
0
0
Start
Vorgangsknotennetz
=
=
=
=
=
=
=
Dauer
gesamte Pufferzeit
freie Pufferzeit
Meilenstein
kritischer Vorgang
freie Pufferzeit
gesamte Pufferzeit
Vorgang
fS
D
fE
sS
gP
sE
fP
Meilenstein
kritischer Vorgang
Vorgang
133
0
0
3d
3d
2d
2d
4d
0d
3 Vorgang 2
4 Vorgang 3
5 Vorgang 4
6 Vorgang 5
7 Vorgang 6
8 Phasenende
3
3
3
6
3
4
3
Di 17.5.
Mi 11.5.
Mi 11.5.
Fr 6.5.
Mo 9.5.
Mo 2.5.
Mo 2.5.
Mo 2.5.
Anfang
4
4
2
3
V4
3
0
V3
Vorgänger
3
6
EA−1d
AA+4d
Di 17.5. 6EA, 7EA
Di 17.5. 4EA−1d
Do 12.5. 4EE+1d, 5EA
Mo 9.5. 2EA−1d, 3EA
Mi 11.5. 2EA, 3AA+4d
Di 4.5. 1EA
Di 4.5. 1EA
Mo 2.5.
Ende
Starttermin ist kritisch
Ende ist unkritisch
0
0
V2
3
1
2
5
8
EE+1d
6
6
EA−1d
6
8
V6
4
0
8
10
6
10
10
7
theoretisch
auch 5
2
2
V5
10
10
10
10
8
fS
sS
D
gP
fE
sE
<Nummer>
Vorgangsname
0
0
Ende
2. Mai 2005
16. Mai 2005
9. Mai 2005
S S MDMD F S S MDMD F S S MDMD F S S
5
7
7
4
Abbildung 4.7: Beispiel für Netzplan- und Balkendiagramm mit komplexeren Abhängigkeiten
3d
2 Vorgang 1
Dauer
0d
0
0
1
1 Phasenstart
Nr. Name
0
0
Start
0
1
V1
=
=
=
=
=
=
Dauer
gesamte Pufferzeit
kritischer Vorgang
Vorgang
(Gesamt−)Puffer
freier Puffer
Meilenstein
fS
D
fE
sS
gP
sE
Meilenstein
kritisch
nicht−kritisch
134
Abbildung 4.8: Beispiel für Netzplan- und Balkendiagramm mit komplexeren Abhängigkeiten (mit MS Project 2010 erstellt)
4.4 Feinplanung
Bislang haben wir uns im Rahmen der Planung im Wesentlichen mit den Beziehungen zwischen Vorgängen befasst. Implizit lag dabei die Annahme zu Grunde,
dass jederzeit unbegrenzte Ressourcen zur Verfügung stehen. Allerdings ist dem
im Allgemeinen leider nicht so. Aufgabe des Ressourcen-Management ist es, den
Bedarf an Ressourcen (Einsatzmittel) vorherzusagen und eine Einsatzoptimierung
zu erreichen, d. h. Engpässe und Leerläufe nach Möglichkeit zu vermeiden.
Ressourcen (auch Einsatzmittel genannt) sind:
– Personal
– Betriebsmittel (Hardware, Software etc.)
Man unterscheidet:
– termintreue Ressourcenplanung
„Wie viele Ressourcen brauche ich, um diese und jene Vorgänge bis zu diesen und jenen Terminen abzuschließen?“
– kapazitätstreue Ressourcenplanung
„Wann kann ich frühestens diese und jene Vorgänge bei gegebenen Ressourcen abschließen?“
Wie in Abschnitt 3.7 gezeigt wurde, ist die termintreue Ressourcenplanung gerade hinsichtlich des Personaleinsatzes i. Allg. nicht möglich. Folgende Milchmädchenrechnung funktioniert – wie wir gesehen haben – sicher nicht: „In zwei
Tagen muss der Rohbau meiner Fabrik stehen stehen. Um dieses Ziel zu erreichen
brauche ich 1278 Bauarbeiter.“
4.4.1 Personalplanung
Folgende Gesichtspunkte müssen beachtet werden:
– verfügbare Personalkapazität
– Qualifikation
– zeitliche und örtliche Verfügbarkeit
– organisatorische Zugehörigkeit
– psychologische Aspekte („Never Change a Winning Team“; eine behinderte
Person in einem neuen Team erhöht die Erfolgschancen DeMarco und Lister
[1991] etc.)
Ziel der Personalplanung: optimaler Personaleinsatz über die gesamte Projektlaufzeit.
135
Beispiel „Spiel Aquaris“
Das Spiel Aquaris wurde im Jahr 2006 im Rahmen eines Multimedia-Semesterprojektes von einer Studentengruppe entwickelt. In diesem Spiel geht es darum,
dass 6 Spieler mit Hilfe von Seilzugsteuerungen virtuelle Wasserauffangbehälter mit Wasser und Bonuselementen befüllen. Je zwei Spieler bilden ein Team:
Der Sammler sammelt das Wasser und die Bonuselemente. Der Blocker versucht
Maluselemente abzublocken und zum Gegner zu kicken. Das Wasser und Bonuselemente sollte er oder sie natürlich möglichst nicht abblocken.
2
4
Spielsteuerung
Spieldesign
0
0
8
0
8
8
8
8
11
0
19
19
6
1
Ende
Start
0
0
0
0
19
19
0
0
3
6
4
19
19
5
Animation
Spiellogik
0
4
0
0
6
10
6
10
9
4
15
19
nicht−kritisch
<Nummer>
Vorgangsname
fS
sS
D
gP
fE
sE
fS
D
fE
sS
gP
sE
=
=
=
=
=
=
Dauer
gesamte Pufferzeit
kritisch
Meilenstein
Abbildung 4.9: Netzplan des Computerspiels Aquaris
Die in Abbildung 4.9 und Abbildung 4.10 angegebenen Zahlen sind fiktiv. Allerdings war – neben Informatikern und Gestaltern – tatsächlich erstmals auch ein
Mechatroniker an einem Multimedia-Projekt beteiligt.
Anhand des verfügbaren/eingeplanten Personals muss die Dauer von Vorgängen
(in Personentagen etc.) ermittelt werden. Der (zeitlich variable) Bedarf an Mitarbeitern kann nach qualifikationsorientierten sowie organisationsorientierten Gesichtspunkten ermittelt werden. Wenn Mitarbeiter gleichzeitig in mehr als einem
Projekt arbeiten – was Sie als Projektleiter laut DeMarco [2001] tunlichst vermeiden sollten –, kann die Bedarfsplanung auch projektorientiert erfolgen.
Bei der qualifikationsorientierten Bedarfsplanung werden zu jedem Zeitpunkt die
136
Personal
3
Qualifika−
tion Informatiker
Vorgänge
Spieldesign
Spiellogik
Animation
Spielsteuerung
4
Designer
1
Mechatronik eingeplantes
Personal
3
3
1
1
2
1
3
3
3
2
Abbildung 4.10: Personalplanung des Computerspiels Aquaris
Mitarbeiter
7
6
5
4
3
2
1
0
Spieldesign
Designer
Spiellogik
Informatiker
Problem: 5 Designer werden gebraucht
Spielsteuerung
Informatiker
Mechatroniker
Animation
Designer
Animation Informatiker
Projektleiter
Spielsteuerung
Informatiker
Mechatroniker
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Zeit
Abbildung 4.11: Qualifikationsorientierte Bedarfsplanung
Anzahl der benötigten MA mit bestimmter Qualifikation in ein Diagramm eingetragen (siehe Abbildung 4.11).
Bei der organisationsorientierten Bedarfsplanung werden die Mitarbeiter nicht
nach ihrer Qualifikation, sondern nach ihrer organisatorischen Zugehörigkeit
(Abt. 1, Abt. 2, Partner A, Partner B etc.) in ein Bedarfsdiagramm eingetragen.
Bei der projektorientierten Planung wird die Anzahl der Mitarbeiter eines jeden
Projektes in ein Bedarfsdiagramm eingetragen.
In allen Fällen kann man an derartigen Diagrammen Engpässe und Leerläufe ablesen (siehe Abbildung 4.12). Man beachte, dass die Anzahl vorhandener Mitarbeiter (oder Spezialisten) über die Zeit nicht notwendigerweise konstant ist.
Im obigen Beispiel „Spiel Aquaris“ ergibt sich das Problem, dass keine 5 Designer
zur Verfügung stehen (siehe Abbildung 4.13). Das heißt, nach 8 Projekttage ergibt
sich für zwei Tage ein Engpass an Designern. Danach folgt ein Leerlauf. Der
Bedarf an Designern reduziert sich vor Projektende sogar auf Null (zumindest in
unseren fiktiven Beispiel).
137
Mitarbeiter
Engpass
Engpass
Leerlauf
Leerlauf
Leerlauf
Anzahl
Mitarbeiter
Zeit
Abbildung 4.12: Leerlauf und Engpässe
Designer
Anzahl
Designer
Zeit
Abbildung 4.13: Leerlauf und Engpässe am Beispiel des Projektes „Auqaris“
Die eigentliche Aufgabe des Ressourcen-Management ist es, die zeitliche Abfolge von Vorgängen so abzuändern, dass Engpässe (d. h. Überstunden oder Einstellungen von weiterem Personal, Zukauf weiterer Ressourcen etc.) nach Möglichkeit vermieden werden. Im Wesentlichen werden dabei vorhandene Leerlaufzeiten
abgebaut. Primär sind dazu nicht-kritische Vorgänge geeignet, deren Erledigung
nach hinten – nach Möglichkeit in bestehende Leerlaufphasen – verschoben werden kann.
In Abbildung 4.14 werden fünf Vorgänge angegeben zusammen mit der jeweiligen Dauer sowie der Anzahl der Mitarbeiter, die eingeplant werden muss, um
den jeweiligen Vorgang in der angegebenen Zeit erfolgreich abzuschließen. In
Abbildung 4.15 ist eingetragen, wie der Personalbedarf aussieht, wenn zu jedem
Zeitpunkt beliebig viele Projektarbeiter zu Verfügung stehen.
138
<Nummer>
Vorgangsname
2
V2
5
D
2
1
V3
5
4
D = Dauer
MA = Anzahl Mitarbeiter
5
3
V1
4
MA
V5
2
3
3
4
V4
7
4
Abbildung 4.14: Netzplan von fünf Vorgängen
MA
Termin
V4
Anzahl
MA
5
V2
V1
V4
V3
V5
0
0
5
10
15
Zeit
Abbildung 4.15: Resultat der Vorgangsplanung
Wenn das Projektteam (neben dem Projektleiter) nur sechs Mitglieder hat, die alle
gleichermaßen geeignet sind, die Vorgänge zu bearbeiten, kommt es vom vierten
bis zum neunten Tag zu einem Personalengpass. Ab dem neunten Tag kommt es
dagegen zu einem Leerlauf. Wenn man versucht, diesen Engpass so zu beheben,
dass die Arbeit an Vorgang V4 in den Tagen neun bis dreizehn erledigt wird,
damit der ursprüngliche Termin gehalten wird (termintreue Planung), muss man
fünf Kröten schlucken (Abbildung 4.16):
139
– Ohne Überstunden geht es nicht.
– Das V4-Team ändert ständig seine Größe: 1,33 MA für 3 Tage, 3 MA für 2
Tage, 6 MA für 2 Tage, 3 MA für 2 Tage.
– Sechs Mitarbeiter auf einmal sind zuviel und behindern sich nur.
– Für V4 waren nur vier Mitarbeiter vorgesehen. Evtl. hat man gar keine sechs
Experten für diesen Vorgang.
– Die laut Netzplan vorgegebene Abhängigkeit V4 → V5 wird verletzt.
MA
Termin
Überstunden
Anzahl
MA
5
V4
V2
V1
V4
V3
V5
0
0
5
10
15
Zeit
Abbildung 4.16: Termintreue Personalplanung
Die kapazitätstreue Personalplanung (Abbildung 4.17) vermeidet die meisten dieser Nachteile. Dafür verschiebt sich der Endtermin um drei Tage. Wenn man die
sich ändernde Mitarbeiterzahl an Vorgang V4 noch weiter abmildern will, könnte
man auf den Start des Vorgangs mit einem Mitarbeiter in den vier bis sechs verzichten. Dies hätte eine weitere Verschiebung des Endtermins um einen Tag nach
hinten zur Folge. Dafür hätte man auch Luft, den Vorgang V4 an den Tagen 13
und 14 mit jeweils vier Mitarbeitern zu Ende zu führen (auch wenn rechnerisch
nur jeweils drei Mitarbeiter nötig wären).
Für das Spiel Aquaris muss beispielsweise der Start des Vorgangs 5 „Animation“
um zwei Tage nach hinten geschoben werden (Abbildung 4.18). Diese Modifikation ist sowohl kapazitätstreu als auch termintreu. Der Puffer des Vorgangs „Animation“ wird allerdings reduziert. Dafür gewinnt der Vorgang „Spiellogik“ zwei
Tage freien Puffer hinzu.
140
MA
Termin
Anzahl
MA
5
V2
V1
V4
V3
V4
V5
0
0
5
10
15
Zeit
Abbildung 4.17: Kapazitätstreue Planung
4.4.2 Bedarfsplanung der Betriebsmittel
Abhängig von der „Beständigkeit“ der Betriebsmittel unterscheidet man:
– verzehrbare Betriebsmittel (Büromaterial, Toner etc.)
– nicht-verzehrbare Betriebsmittel (Räume, Rechner, Software etc.)
Eine Betriebsmittelplanung ist nur dann notwendig, wenn Engpässe sehr wahrscheinlich sind. Ansonsten rentiert sich der zusätzliche Arbeitsaufwand nicht.
Für verzehrbare Betriebsmittel sollten genügend Finanzreserven vorgesehen werden, so dass fehlendes Material rechtzeitig nachbestellt werden kann. Nicht verzehrbare Betriebsmittel sollten in genügender Zahl bereitgestellt werden.
Wenn eine Betriebsmittelplanung notwendig sein sollte, so läuft diese im wesentlichen wie die Personalplanung ab. Man unterscheidet dabei zwischen:
– vorratseingeschränkter Einsatzplanung
Ein nicht-vergrößerbarer Vorrat eines Betriebsmittels muss möglichst fair
auf mehrere Nutzer aufgeteilt werden ⇒ Belegungspläne o. Ä.
– bedarfsbezogener Einsatzplanung
Zunächst wird von einem unbegrenzten Vorrat eines Betriebsmittels ausgegangen. Dann wird der eigentliche Bedarf zu den verschiedenen Zeiten ermittelt. Eventuell kann der Bedarf durch termintreue oder kapazitätstreue Auslastungsoptimierung verringert werden. Schließlich können die
Betriebsmittel gemäß dem errechneten Bedarf angeschafft werden.
– freier Einsatzplanung
Wenn keine Gefahr von Engpässen besteht, kann die Planung auf die Sammlung von Benutzerbedürfnissen (oder -wünschen) beschränkt werden.
141
142
1EA
2EA
3EA
8d
6d
11d
9d
0d
2 Spieldesign
3 Spiellogik
4 Spielsteuerung
5 Animation
6 Ende
1EA
2EA
3EA
0d
8d
6d
11d
9d
0d
1 Start
2 Spieldesign
3 Spiellogik
4 Spielsteuerung
5 Animation
6 Ende
3 Inf.
2 Des. + 1 Inf.
1 Inf. + 1 Mech.
3 Des.
3 Inf.
2 Des. + 1 Inf.
1 Inf. + 1 Mech.
3 Des.
Abbildung 4.18: Aquaris: Gantt-Diagramme mit und ohne Ressourcenengpass
4EA, 5EA
1EA
Dauer
Nr. Name
Vorgänger
4EA, 5EA
1EA
0d
1 Start
Vorgänger
Dauer
Nr. Name
kritischer Vorgang
Vorgang
(Gesamt−)Puffer
freier Puffer
Meilenstein
kritischer Vorgang
Vorgang
Puffer
Meilenstein
4.4.3 Kapazitätsausgleich, Resource Leveling
Wenn man in Gantt-Diagrammen Vorgänge und deren Nachfolgervorgänge nach
hinten verschiebt, um Ressourcen-Engpässe auszugleichen, spricht man von Kapazitätsausgleich oder Resource Leveling. Beispiele für Resource Leveling wurden schon im letzten Abschnitt vorgestellt (siehe Abbildung 4.17 und Abbildung 4.18).
Ein wichtiger Spezialfall stellt der Kapazitätsausgleich auf Mitarbeiterebene dar.
Ein Mitarbeiter sollte – wann immer es sich vermeiden lässt – nicht an zwei Aufgaben gleichzeitig arbeiten. Erst recht sollte ein Mitarbeiter nicht an zwei Projekten gleichzeitig arbeiten. Der Grund dafür ist ganz einfach: Die Fertigstellung
aller Aufgaben verzögert sich (Abbildung 4.19)!
Abbildung 4.19: Verzögerungseffekte von quasi-paralleler Arbeit
143
Ein Mensch kann immer nur eine Aufgabe zur selben Zeit absolvieren. Sogar die
Aussage, dass Frauen multitaskingfähig seien und Männer nicht, ist laut einer Studie des Instituts für Arbeit und Gesundheit der gesetzlichen Unfallversicherung
nichts als ein Märchen (DGVU [2010]).
Wenn sie (oder er) mehrere Aufgaben „gleichzeitig“ erledigen will, geht dies nur
im so genannten „Timesharing-Verfahren“: Nach jeweils einer kurzen Zeitspanne
widmet sie sich einer anderen Aufgabe. Dies hat zur Folge, dass sich das Ende
aller Aufgaben mit Ausnahme der letzten verzögert (siehe Abbildung 4.19 b).
Leider ist es nicht so, dass ein Mensch ohne Probleme die jeweilige Aufgabe
wechseln kann. Jeder so genannte „Taskwechsel“ hat eine zusätzliche Verzögerung zur Folge. Das heißt alle Endtermine, auch der der letzten Aufgabe, verzögert
sich zusätzlich. (siehe Abbildung 4.19 c)
Beispiele für diese Verzögerungseffekte gibt es viele. Es wäre z. B. viel effizienter und effektiver Lehrveranstaltungen nacheinander in Blöcken zu halten als
in jeder Woche parallel diverse Lehrveranstaltungen zu besuchen, da man sich
dann immer nur auf ein Thema konzentrieren müsste und das ständige Umdenken entfallen würde. Laut Aussage einer Studentin, die ein Auslandssemester in
Schweden verbracht hat, wird dieses Konzept in Schweden tatsächlich umgesetzt.
Ein viel schlimmeres Beispiel sind Telefon und E-Mail. „Ungestörtes Arbeiten ist
zum Luxus geworden. Büromenschen können sich im Schnitt elf Minuten auf eine
Aufgabe konzentrieren, bevor sie auf einem der vielen Kommunikationskanäle
unterbrochen werden.“ (Pilgram [2011])
Die dauernden Unterbrechungen durch diese Medien kosten die Unternehmen jedes Jahr Milliardenbeträge. Jede Unterbrechung reißt einen Geistesarbeiter aus
seinen Gedanken. Die nachfolgende Eintauchphase, um wieder voll konzentriert
an der zuvor unterbrochenen Aufgabe arbeiten zu können, dauert laut Untersuchen von DeMarco und Lister (DeMarco und Lister [1985]) ca. 15 Minuten. Das
heißt drei 5-Minuten-Telefonate in einer Stunde kosten die gesamte Stunde als
produktive Arbeitszeit.
Ein weiteres Problem ist das so genannte Matrix-Projektmanagement. Kupper
[1993] hält dies für die „geeignetste Form, [um] DV-Projekte durchzuführen“.
Projektmitarbeiter haben jeweils zwei Chefs: Einen Chef – den Personalvorgesetzen – der Fach- oder Stabsabteilung, der sie zugeordnet sind sowie den Projektleiter als Fachvorgesetzen. DeMarco [2001] hält das Matrix-Projektmanagement
dagegen für absurd. Für vollkommen verfehlt hält er die Idee, dass der Personalvorgesetzte einen Mitarbeiter, der in einem Projekt nicht ausgelastet ist, gleichzeitig an mehreren Projekten (mit jeweils unterschiedlichen Fachvorgesetzen) mitarbeiten lässt. Hier kommt zu den üblichen Taskwechsel-Verzögerungen noch das
Problem hinzu, dass der Mitarbeiter in kein Team richtig integriert ist. Dies hat
144
wesentlich gravierendere Negativ-Effekte als die übrigen Zeitverluste durch Taskwechsel.
Laut DeMarco [2001] setzt sich der durch Taskwechsel verursachte Zeitausfall
insgesamt aus folgenden Komponenten zusammen:
– Routinearbeiten, um auf die neue Aufgabe umzuschalten
– Doppelarbeit, weil eine Aufgabe in einem ungünstigen Moment abgebrochen werden musste
– Eintauchzeit bei denkintensiven Aufgaben
– Frustration (emotionale Eintauchzeit)
– Verlust des Teambildungseffkts (bei Mitarbeit an mehreren Projekten gleichzeitig)
In einer Studie (DeMarco und Lister [1985]), bei der 600 Programmierer unter
realen Bedingungen Programmieraufgaben lösen mussten, wiesen Tim Lister und
Tom DeMarco nach, dass jeder Taskwechsel mit einem Konzentrationsverlut von
ca. 20 Minuten verbunden ist. Bei 0,4 Wechseln pro Stunde summiert sich dies
zu mehr als einer Stunde Arbeitszeitverlust, was 15 % der Arbeitszeit bei einem
8-Stunden-Tag bedeutet.
Fazit
Resource Leveling auf Mitarbeiterebene ist bei jedem Projekt ein Muss!
Resource Leveling beschleunigt ein Projekt, wenn die Ressourcen vorgegeben
sind.
Resource Leveling bedeutet dagegen fast immer einer Verlängerung der Projektlaufzeit gegenüber dem theoretischen Optimum, bei dem unbeschränkt viele Ressourcen zur Verfügung stehen, die sich gegenseitig nicht behindern. Nur, wann hat
man das schon?
4.4.4 Kostenplanung
Die Kostenplanung erfolgt in Abhängigkeit von allen anderen Planungsaktivitäten.
Das Ziel ist immer auch eine projektumfassende Vollkostenrechnung, angefangen bei der Vorplanung, endend beim Abschlussbericht. Zu den ressourcenspezifischen Kosten (Ressourcenkosten) addieren sich noch die Gemeinkosten (wie
Büromiete, Löhne und Gehälter von Verwaltung und Management etc.), die sich
nicht spezifischen Projekten zuordnen lassen.
145
Für Personal muss zwischen normalen Stundensätzen und Überstundensätzen unterschieden werden. Diese können Gemeinkosten enthalten (Personalvollkosten)
oder nicht. Bei manchen Unternehmen (wie z. B. dem Staat) werden die Kosten für
alle Mitarbeiter derselben Qualifikation gemittelt (Personaldurchschnittskosten).
Das heißt, unterschiedliche Gehälter aufgrund von Leistungs- oder Familienzulagen o. Ä. werden projektunabhängig verrechnet.
Bei Betriebsmitteln entstehen Gemeinkosten (z. B. Büros), Festkosten (z. B. Neuanschaffung nicht-verzehrbarer Betriebsmittel) und laufende Kosten (z. B. Nachkauf aufgebrauchter verzehrbarer Betriebsmittel, Zeitschriften, Wartungsverträge
etc.)
Anmerkung
Auch Erlöse sind Kosten, und zwar negative Kosten.
4.4.5 Kalender
Wesentlich für alle Planungen sind die Kalender. Der wichtigste Kalender ist der
Projektkalender, in dem alle freien Tage (Samstage, Sonntage, Feiertage, Betriebsferien) eingetragen werden.
Daneben kann es beliebig viele Ressourcenkalender geben, in denen die Verfügbarkeit der einzelnen Ressourcen (Personal und Betriebsmittel) eingetragen wird.
Normalerweise enthalten die Ressourcenkalender lediglich mehr freie Tage als
der Projektkalender (Urlaub, Rechner auf CeBIT etc.). Allerdings gibt es auch
Ressourcen, die an ansonsten arbeitsfreien Tagen sinnvolle Arbeiten durchführen
können (Zement kann auch am Wochenende trocknen, 3D-Animationen können
auch über Weihnachten ohne Aufsicht gerendert werden etc.).
Manchmal sind auch spezielle Vorgangskalender wichtig, wenn z. B. bestimmte Vorgänge im Ausland stattfinden und der betriebsspezifische Projektkalender
daher keine Anwendung finden kann (sehr zum Leidwesen einiger Dienstreisender). Sollte ein PM-Tool keine Ressourcenkalender mit beliebig veränderbaren
Arbeitszeiten unterstützen, so können Wochenend- und Feiertagsarbeit auch mit
Vorgangskalendern modelliert werden.
146
4.5 Methode der kritischen Kette
Eliyahu Goldratt hat die Theory of Constraints (ToC, siehe Abschnitt 1.2.3) –
nachdem diese sehr erfolgreich war – zur Methode der kritischen Kette (CCPM,
Critical Chain Project Management) weiterentwickelt. Während ToC auf die Bedürfnisse der Produktionswirtschaft abgestimmt ist, ist CCPM für das Projektmanagement gedacht.
In dem Roman „Die Kritische Kette – Das neue Konzept im Projektmanagement“
(Goldratt [2002]) identifiziert Goldratt den kritischen Pfad als denjenigen Engpass, auf den ein Projektleiter sein Augenmerk konzentrieren muss. Wie bei ToC
ist ein explizites Puffermangement wesentlich.
Im englischen Wikipedia-Artikel über PERT werden für ein Beispielsprojekt sieben Vorgänge gemäß PERT geschätzt (Abbildung 4.20).
Vorgang
A
B
C
D
E
F
G
Vorgänger
–
–
A
A
B; C
D
E
Dauer: Schätzungen
best (a) normal (c) worst (b)
2
4
6
3
5
9
4
5
7
4
6
10
4
5
7
3
4
8
3
5
8
µi
(PERT)
4,00
5,33
5,17
6,33
5,17
4,50
5,17
σi
(PERT)
0,67
1,00
0,50
1,00
0,50
0,83
0,83
Abbildung 4.20: Wikipedia-Beispiel (Wikipedia [2011c])
Die Schätzwerte µi für die Dauer der einzelnen Vorgänge sowie σi wurden mittels
der PERT-Formeln µi = (ai + 4ci + bi )/6 und σi = (bi − ai )/6 ermittelt (siehe
Abschnitt 3.3.3), wobei die σi -Werte im Wikipedia-Artikel nicht angegeben wurden. In Abbildung 4.21 wird oben das zugehörige Gantt-Diagramm gezeigt.
Eine große Frage bleibt: Ist die im Wikipedia-Artikel angewendete Art der Schätzung der Projektgesamtdauer, bei der ausschließlich die Erwartungswerte (ungerundet) aufsummiert werden, überhaupt sinnvoll? Laut zentralem Grenzwertsatz (Abschnitt 3.3.2) liefert die Summe aller Erwartungswerte der kritischen
Vorgänge eine recht gute Schätzung für den Erwartungswert der Gesamtdauer: µ = 4, 00 + 5, 17 + 5, 17 + 5, 17 = 19, 51. (Besser noch wären tagesgenaue
Schätzungen; vgl. Abschnitt 3.5)
Doch was sagt der Erwartungswert µ aus? Er sagt aus, dass das Projekt mit einer Wahrscheinlichkeit von 50 % nach neunzehneinhalb Tagen fertig sein wird. 1
Insofern ist die Wikipedia-Schätzung ziemlich gewagt.
1
Für die Normalverteilung ist das 50 %-Quartil gleich dem Erwartungswert.
147
µi + σ i
(PERT)
4,67
6,33
5,67
7,33
5,67
5,33
6,00
148
Abbildung 4.21: Gantt-Diagramme für das PERT-Beispiel; oben: µi ; unten: µi + σi
Um ein deutlich besseres Ergebnis zu erhalten, muss man zu jedem Vorgang
einen Sicherheitspuffer zuschlagen. Wenn man beispielsweise zu jedem Vorgang
einen Puffer von einem σi hinzuaddiert (σi = (bi − ai )/6, sofern man wieder eine
PERT-Schätzung zugrunde legt), erhält man deutlich längere Laufzeiten.
Die Gesamtdauer beträgt nun: 4, 67 + 5, 67 + 5, 67 + 6, 00 = 22, 01. Sie ist also
um 2, 5 Tage angewachsen. Diese Dauer ermittelt man, indem man alle µ i + σi
aufaddiert (rechte Spalte Abbildung 4.20). In Abbildung 4.21 wird unten das zugehörige Gantt-Diagramm gezeigt.
Laut zentralem Grenzwertsatz ist µ weiterhin gleich 19, 51 und σ =
p
0, 672 + 0, 52 + 0, 52 + 0, 832 = 1, 28 bzw. 2σ = 2, 56.
Das heißt, die Gesamtdauer von 22 Tagen entspricht ungefähr dem Wert µ + 2σ.
Dieser Termin kann nach der 84/98/99,9-Regel mit einer Wahrscheinlichkeit von
ca. 98 % eingehalten werden.
Fazit: Wenn man die PERT-Methode oder eine verwandte Methode verwendet,
muss man für jeden einzelnen Vorgang eine gewissen Sicherheitspuffer einplanen,
um eine gute Schätzung für die Gesamtdauer zu erhalten.
4.5.1 Integrierter Puffer
In den klassischen Gantt-Diagrammen ist – wie zuvor gezeigt wurde – normalerweise für jeden Vorgang ein Puffer implizit in der geschätzten Dauer enthalten.
50%−Quartil
Puffer
Gerade wenn ein Projektleiter Einpunkt-Schätzungen vornimmt, bei denen er sein
Team nach der Dauer von Vorgängen fragt, erhält er niemals 50/50-Schätzwerte.
Je wichtiger ein Vorgang ist, desto mehr Puffer enthält die geschätzte Dauer, damit
sich die Mitarbeiter ziemlich sicher sein können, dass sie den Termin auch halten.
Das heißt, man erhält 80 %-/90 %-/95 %- oder gar 99 %-Schätzungen. Beispielsweise fahre ich an Prüfungstagen spätestens 50 Minuten vor Prüfungsbeginn zur
HSA, um rechtzeitig anzukommen, obwohl mir mit 99-prozentiger Sicherheit 35
Minuten ausreichen würden. Bislang habe ich nur einmal eine Stunde zur HSA
gebraucht, weil ich in einem Stau stand: Und das war natürlich ein Prüfungstag.
Das Vorgehen, für jeden Vorgang einen großen Puffer in die Schätzung zu integrieren, hat zwei gravierende Nachteile:
– Selbst wenn man jedem Vorgang nur einen geringen Puffer hinzufügt (z. B.
σi ), ist der Gesamtpuffer fast immer deutlich größer als dies nach dem zentralen Grenzwertsatz notwendig wäre. Im obigen Beispiel haben sich bereits
die vier Einzelpuffer von jeweils σi schon zu einem Projektgesamtpuffer
149
von 2σ aufaddiert. Bei weiteren Vorgängen und insbesondere bei deutlich
größeren Vorgangspuffern sprengt die Gesamtsumme aller Einzelpuffer sehr
schnell jede sinnvolle Grenze: 2σ, 3σ, 4σ . . .
– Gemäß dem Gesetz von Parkinson [1955] hat viel Puffer einen gravierenden
Nachteil: Der Arbeitsaufwand wächst immer so weit, wie die Zeit, die zur
Verfügung steht. Die Gründe dafür sind folgende:
• Das Studentensyndrom (vgl. Abbildung 1.3)
• Parallelarbeit: Wenn genügend Zeit vorhanden ist, können auch noch
andere Aufgaben parallel bearbeitet werden.
• Die Angst der Mitarbeiter, eine Arbeit zu früh erfolgreich zu beenden,
da dies i. Allg. zur Folge hat, dass beim nächsten Projekt die abgegebenen Schätzungen vom Projektleiter reduziert werden (vgl. Dezemberfieber). Diese Angst geht häufig sogar soweit, dass der implizite Puffer
auch dann nicht genutzt wird, wenn der Vorgängervorgang verspätet
beendet wurde.
Fazit: Egal wie lange die Projektdauer geplant wurde und wie viel Puffer für jeden einzelnen Vorgang eingeplant wurde, das Projekt wird nicht vorzeitig fertig, sondern höchstens noch später. Das heißt, auch wenn für das Wikipedia-Beispiels-Projekt (Abbildung 4.21) eine Fifty-fifty-Chance besteht, dass es vor dem
1. 7. fertiggestellt werden könnte, wird es nicht vor dem 1. 7. fertig gestellt. Und
wenn man, wie vorgeschlagen, in jeden Vorgang zusätzlichen Puffer einfügt, dann
wird es nicht vor dem 6. 7. fertig. PUNKT!
Laut DeMarco [2001] trifft „das Parkinsonsche Gesetz [...] auf Ihre Mitarbeiter
mit Sicherheit nicht zu“, da die Lebenszeit der Angestellten einfach zu kurz ist,
um bei der Arbeit herumzutrödeln. Er betont dies, weil er ein Gegner von Druck
ist. Projektleiter sollen sich nicht verleitet fühlen, das Parkinsonsche Gesetz auszuhebeln, indem sie Scheintermine – das heißt, Termine, die nicht gehalten werden können – vorgeben. Ein derartige Termin wäre im Wikipedia-Beispiel der
28. 6. (µ − 2σ), ein theoretisch machbarer Termin, der mit ca. 0 % Wahrscheinlichkeit auch gehalten werden kann.
Laut Goldratt sind die Projektleiter selbst Schuld, wenn das Parkinsonsche Gesetz
zuschlägt: Erstens ist Resource Leveling ein Muss, d. h. Parallelarbeit sollte wann
immer möglich vermieden werden. Und zweitens sind fixe Termine von Übel. Termine sind Schätzungen und damit keine unverrückbaren Größen. Die Mitarbeiter
müssen sicher sein, dass jede Schätzung auch als solche angesehen wird. Wer früher fertig wird, hat nicht schlechter geschätzt, als derjenige der später fertig wird.
Bei einer guten Schätzung – das ist eine 50 %-Schätzung ohne zusätzlichen Puffer
– ist beides gleich wahrscheinlich. Absolut tödlich für das Vertrauen der Mitarbeiter ist es, wenn ein Projektleiter für Vorgänge, die vorzeitig abgeschlossen wurde,
in Folgeprojekten automatisch kürzere Laufzeiten ansetzt!
150
Wie kann man es erreichen, dass das Projekt tatsächlich irgendwann zwischen den
28. 6. und dem 6. 7. fertig gestellt wird?
Laut Goldratt [2002] erreicht man dies, indem man die Vorgangspuffer explizit
verwaltet. Genauer: Man nimmt für die einzelnen Vorgänge Fifty-fifty-Schätzungen vor und fügt am an Ende des kritischen Pfades einen Gesamtpuffer hinzu, der
von allen Vorgängen genutzt werden kann. Im folgenden Diagramm sieht man in
Abbildung a drei Vorgänge, die einen impliziten Puffer enthalten. In Abbildung b
wurde dieser Puffer separiert, summiert und hinter den verkürzten Vorgängen als
eigenständiger „Puffervorgang“ eingefügt. Dadurch hat sich die Gesamtdauer der
drei Vorgänge nicht verändert. Wie wir aber bereits wissen (Zentraler Grenzwertsatz der Statistik: Abschnitt 3.3.2), kann man den Puffer von einer Summe von
Vorgängen kürzer wählen. Dies wird in Abbildung c visualisiert.
a)
µ1
2σ1
µ2
b)
µ1
µ2
µ3
c)
µ1
µ2
µ3
2σ2
2σ1
2·
µ3
2σ2
2σ3
2σ3
q
σ12 + σ22 + σ32
Ein weiteres Beispiel finden Sie in Abbildung 4.22. Hier wurde der Gesamtpuffer,
der für das Gantt-diagramm in Abbildung 4.21 gemäß dem zetralen Grenswertsatz
berechnet wurde, als expliziter Vorgang (Nr. 9) ins Diagramm eingefügt.
Den Mitarbeitern werden keine fixen Termine mehr genannt. Stattdessen wird jeder Vorgang begonnen, sobald der Vorgängervorgang abgeschlossen wurde. Den
Mitarbeitern wird mitgeteilt, dass z. B. ca. vier Tage für den gerade gestarteten
Vorgang eingeplant wurden. Allerdings wird kein Termin gesetzt. Das heißt, sagen Sie nicht: „In vier Tagen muss das Ergebnis da sein (nicht früher und nicht
später)“. Sondern die Mitarbeiter werden angehalten, so lange wie nötig am Vorgang zu arbeiten, um alle Vorgaben hinsichtlich Funktionalität und Qualität zu
erfüllen. Sobald sie fertig sind, startet der nächste Vorgang und der Projektleiter
passt den Gesamtpuffer an: Wurde der Vorgang zu spät beendet, wird der Gesamtpuffer entsprechend gekürzt, anderenfalls wird er entsprechend verlängert.
Ganz wichtig: Mitarbeiter, die an kritischen Vorgängen arbeiten, werden von allen anderen Tätigkeiten entlastet.
Bei einem gut geschätzten Projekt und guter Menschenführung (d. h., die Mitarbeiter vertrauen darauf, dass weder Terminverzögerungen noch vorzeitige Vorgangsfertigstellung negative Folgen für sie haben) sollte die Größe des Gesamtpuffers „pulsieren“ (vgl. Abschnitt 4.8.4).
151
152
Abbildung 4.22: CCPM-Diagramme für das PERT-Beispiel; oben: Gesamtpuffer; unten: Gesamtpuffer und Zubringerpuffer
Definition 4.5.1 (Kritische Kette)
Eine kritische Kette ist ein kritischer Pfad ohne Ressourcenkonflikte und
ohne parallele kritische Vorgänge, dem ein so genannter Gesamtpuffer als
letzter Vorgang hinzugefügt wurde.
Die Dauer eines jeden Vorgangs wird mittels der Erwartungswerte zugehöriger Mehrpunktschätzungen ermittelt, die Dauer des Gesamtpuffers
mittels der Wurzel aus der Summe der Quadrate der Standardabweichungen, die für die kritischen Vorgänge ermittelt wurden.
Definition 4.5.2 (Methode der kritischen Kette)
Die Methode der kritischen Kette (Critical Chain Project Management,
CCPM) erweitert die klassische Methode des kritischen Pfades um folgende Elemente:
– starke Reduktion von Parallelarbeit
– explizite Verwaltung des Gesamtpuffers (kritische Kette)
– explizite Verwaltung der Puffer für nicht-kritische Vorgänge (Zubringerpuffer)
– Abschaffung von fixen Terminen
4.5.2 Die kritische Kette
Die kritische Kette eines Projektes wird in drei Schritten ermittelt:
1. Schritt: Klassische Planung
1. Komponenten-Projektstrukturplan (KPSP) erstellen
(siehe Abschnitt 4.2.1).
2. Aktivitäten-Projektstrukturplan (APSP) aus KPSP ableiten
3. Gantt-Diagramm aus APSP ableiten
(siehe Abbildung 4.1).
4. Für alle Vorgänge (= Blätter des APSP) EA-Abhängigkeiten ermitteln
5. In das zugehörige Gantt-Diagramm die EA-Abhängigkeiten der Vorgänge
eintragen.
6. Für alle Vorgänge vi Mehrpunktschätzungen vornehmen
sowie µi und σi ermitteln (siehe Abschnitt 3.3.1).
7. In das zugehörige Gantt-Diagramm die Dauer µi der Vorgänge eintragen.
8. EA-Abhängigkeiten und Dauer in zugehörigen Netzplan übernehmen.
153
Wenn an dieser Stelle eine Vorwärts- und Rückwärtsrechnung gemäß klassischer
Vorgehensweise (CPM, PERT, MPM etc.) durchgeführt wird (Abschnitt 4.3.2), erhält man laut zentralem Grenzwertsatz (Abschnitt 3.3.2) einen Zeitplan, der unter
optimalen Bedingungen, d. h., wenn zu jedem Zeitpunkt genügend Ressourcen
zur Verfügung stehen, mit 50-prozentiger Wahrscheinlichkeit eingehalten werden
kann. Beispiele für das Ergebnis einer derartigen Berechnung: Abbildung 4.23
und Abbildung 4.29.
Diese optimalen Bedingungen stehen aber fast nie zur Verfügung. Daher muss als
nächster Schritt das Resource Leveling (Abschnitt 4.4.3) erfolgen.
2. Schritt: Resource Leveling
9. Für alle Vorgänge die benötigten Ressourcen (inkl. Mitarbeiter) ermitteln.
10. Ressourcen in das Gantt-Diagramm eintragen.
11. Resource Leveling durchführen:
(a) Netzplan um ressourcenbedingte Abhängigkeiten erweitern: Wenn eine
Ressource A zwei Vorgänge V1 und V2 parallel bearbeiten müsste, wird
eine zusätzliche EA-Beziehung zwischen V1 und V2 im Netzplan eingetragen (und am Besten mit der verantwortlichen Ressource markiert).
Die Richtung dieser Beziehung, d. h. die Reihenfolge in der A die beiden
Vorgänge bearbeitet, kann frei gewählt werden, sofern nicht schon eine
andere Abhängigkeit eine bestimmte Reihenfolge vorgibt.
(b) Durch die neuen Abhängigkeiten, die durch das Resource Leveling eingeführt werden, kann es im Netzplan zu Redundanzen kommen. Die redundanten Beziehungspfeile können – müssen aber nicht – aus Gründen
der Übersichtlichkeit entfernt werden.
Beispiele für um ressourcenbedingte Abhängigkeiten erweiterte Netzpläne: Abbildung 4.24 und Abbildung 4.30. Ressourcenbedingte Abhängigkeiten wurden
mit gestrichelten Linien eingetragen und mit den zugehörigen Ressourcen markiert. Redundanten Abhängigkeiten wurden mit kleinen Doppelstrichen symbolisch ausgestrichen. In Abbildung 4.24 ist beispielsweise die EA-Beziehung von
Start nach Vc redundant, da sich diese Abhängigkeit schon aus den EA-Beziehungen Start nach Va und Va nach Vc ergibt. Die letztere EA-Beziehung ergibt sich
daraus, dass Ressource B sowohl bei Vorgang Va als auch bei Vorgang Vc benötigt
wird.
Wenn man nun wieder eine Vorwärts- und Rückwärtsrechnung gemäß klassischer
Vorgehensweise durchführt (Abschnitt 4.3.2), ergibt sich i. Allg. aufgrund der zusätzlichen Abhängigkeiten ein etwas späterer Endtermin. Im ersten Beispiel hat
sich beispielsweise der Endtermin um einen Tag nach hinten verschoben (vgl. Abbildung 4.23 und Abbildung 4.24), im zweiten Beispiel sogar um zwei Tage (vgl.
154
Abbildung 4.29 und Abbildung 4.30). Man beachte, dass sich i. Allg. auch der kritische Pfad ändert. Insbesondere wird bei Ein-Personen-Projekten jeder Vorgang
durch das Resource Leveling kritisch.
Man erhält mit Hilfe des Resource Levelings einen Zeitplan, der unter den gegebenen Bedingungen in 50 Prozent der Fälle eingehalten werden kann. Um
nun einen Endtermin zu ermitteln, zu dem das Projekt mit einer deutlich höheren
Wahrscheinlichkeit abgeschlossen werden kann, muss man einen Gesamtpuffer
für das Projekt berechnen, der die Unsicherheiten aller kritischen Einzelvorgänge
in sich vereint.
Anmerkung: In den Gantt-Diagrammen der Beispiele in Abbildung 4.24 und Abbildung 4.30 wurden im Gegensatz zu den Beispielen in Abbildung 4.23 und Abbildung 4.29 nur noch die freien Pufferzeiten eingetragen (und als maximale Zubringerpuffer bezeichnet). Die Gesamtpufferzeiten der einzelnen Vorgänge sind
sowohl für die Berechnung des Projekgesamtpuffers als auch für die Berechnung
der Zubringerpuffer (siehe Abschnitt 4.5.3) uninteressant.
155
3. Schritt: Pufferberechnung
12. Ins Gantt-Diagramm zu jedem Vorgang die im 6. Schritt ermittelten σ i eintragen.
13. Sollte es sich beim kritischen Pfad nicht um einen Pfad, sondern um ein Netz
mit parallelen kritischen Vorgängen handeln: Von parallel laufenden kritischen Pfaden jeweils eines auswählen und als kritisch beibehalten. Die anderen parallel laufenden kritischen Pfade werden ab sofort als nicht-kritisch
betrachtet.
14. Die Größe des Gesamtpuffers g auf ganze Tage gerundet gemäß
qP dem zentralen
2
Grenzwertsatz (Abschnitt 3.3.2) ermitteln: g = 2σ = 2 ·
i∈K σi , wobei
K die Menge der kritischen Vorgänge ist.
15. Den Gesamtpuffer als letzter Vorgang in das Gantt-Diagramm einfügen.
Beispiele für die Berechnung des Projektgesamtpuffers: Abbildung 4.25 und Abbildung 4.31.
Die Wahl von 2σ als Länge des Gesamtpuffers hat zur Folge, dass – sofern die
Schätzungen in Ordnung sind – das Projekt mit einer Wahrscheinlichkeit von
97,5 % bis zum durch den Gesamtpuffer bestimmten Endtermin fertig wird. Mit
großer Wahrscheinlichkeit kann es sogar deutlich früher beendet werden.
Will man eine noch höhere Sicherheit haben, so sollte man 3σ als Länge des
Gesamtpuffers wählen, dann wird das Projekt mit einer Wahrscheinlichkeit von
99,85 % termingerecht beendet. Allerdings dürfte eine derartige Sicherheit i. Allg.
zu Lasten der Konkurrenzfähigkeit gehen. Die Konkurrenten werden vermutlich
kürzere Projektlaufzeiten im Angebot haben.
Aber selbst die Wahl von lediglich 1 · σ als Länge des Gesamtpuffers kann – gerade im Hinblick auf die Konkurrenzfähigkeit – sinnvoll sein. Den dadurch ermittelten Endtermin kann man gemäß der 84/98/99,9-Regel mit 84 % Wahrscheinlichkeit einhalten. Das heißt, in nicht einmal jedem fünften Projekt wird der Termin
nicht eingehalten.
Neben dem Projektgesamtpuffer für die kritischen Vorgänge sollten auch die so
genannten Zubringerpuffer für die nicht-kritischen Vorgänge möglichst geschickt
ermittelt werden. In Abbildung 4.24 und Abbildung 4.30 sind für die nicht-kritischen Vorgänge die freien Puffer als maximal möglichen Zubringerpuffer eingetragen. Allerdings sollte man nicht-kritische Vorgänge nicht so früh wie möglich,
sondern so spät wie möglich beginnen. Die Gründe dafür sowie die Vorgehensweise, wenn der Zubringerpuffer rechnerisch länger sein müsste, als es freien Puffer
zulassen, werden im nächsten Abschnitt besprochen.
156
157
0
0
0
0
1
0
1
0
0
2
1
Vb
1
0
Va
2
3
1
1
3
2
1
1
0
3
2
0
Ve
3
3
Vc
3
3
6
3
6
4
3
3
3
6
5
0
Vf
2
3
Vd
8
8
7
5
8
5
8
8
8
8
8
fS
sS
D
gP
fE
sE
<Nummer>
Vorgangsname
0
0
Ende
fS
D
fE
sS
gP
sE
=
=
=
=
=
=
Dauer
gesamte Pufferzeit
Meilenstein
kritischer Vorgang
Vorgang
2EA
3EA, 6EA
5EA, 7EA
2d
5d
0d
Ve
Vf
Ende
6
7
8
5. April 2010
12. April 2010
19. April 2010
26.April 2010
Abbildung 4.23: Projekt 2010: 1. Vorgangsknotennetz und 1. Gantt-Diagramm
4EA
2d
Vd
5
1EA
3d
Vc
4
1EA
2d
Vb
3
1EA
Va
2
0d
Vorgänger
1d
Start
1
Nr. Name Dauer
Meilenstein
kritischer Vorgang
freie Pufferzeit
gesamte Pufferzeit
Vorgang
1. Gantt−Diagramm (gemäß CPM, ohne Resource Leveling, mit kritischen Pfad und freien sowie gesamten Pufferzeiten)
0
0
Start
1. Vorgangsknotennetz
158
0
0
0
0
1
0
0
B
1
4
2
2
2
0
A
2
0
2
2
Ve
Vb
3
3
3
1
2
1
1
C
4
4
6
4
7
4
B
4
4
4
7
5
0
Vf
2
3
Vd
9
9
7
6
9
5
9
9
9
9
8
fS
sS
D
gP
fE
sE
<Nummer>
Vorgangsname
0
0
Ende
fS
D
fE
sS
gP
sE
1EA
1EA
4EA
2EA
3EA, 6EA
5EA, 7EA
1d
2d
3d
2d
2d
5d
0d
Va
Vb
Vc
Vd
Ve
Vf
Ende
2
3
4
5
6
7
8
C
A
B
B
A
B,C
Ressource
5. April 2010
12. April 2010
19. April 2010
26. April 2010
1EA
0d
Start
1
Nr. Name Dauer Vorgänger
Dauer
gesamte Pufferzeit
Meilenstein
kritischer Vorgang
max. Zubringerpuffer
Vorgang
=
=
=
=
=
=
Meilenstein
kritischer Vorgang
Vorgang
2. Gantt−Diagramm (gemäß CPM, mit Resource Leveling, kritischem Pfad und maximalen Zubringerpuffern)
0
0
Start
0
1
Vc
Va
2
2. Vorgangsknotennetz (mit Resource Leveling)
159
Vb, Ve, Vf
2*sqrt(1,03^2+0,24^2) = 2,11 ~ 2
Vc, Vd
2d
2d
5 Vd
6 Ve
0d
3d
4 Vc
8 Ende
2d
3 Vb
5d
1d
2 Va
7 Vf
0d
1 Start
5EA, 7EA
3EA, 6EA
2EA
4EA
1EA
1EA
1EA
1,03
0,24
0,41
B
B
A
5. April 2010
12. April 2010
19. April 2010
26. April 2010
Abbildung 4.25: Projekt 2010: 3. Gantt-Diagramm
0,71
0,62
A
C
0,62
σ
B,C
Ressource
Meilenstein
Gesamtpuffer
kritischer Vorgang
Zubringerpuffer
Vorgang
3. Gantt−Diagramm (gemäß CCPM, ohne Pfeile, mit Resource Leveling, kritischem Pfad, Zubringerpuffern und Gesamtpuffer)
2*sqrt(0,62^2 + 0.41^2 + 0,71^2) = 2.06 ~ 2
Berechnung des Gesamtpuffers:
Va
2*sqrt(0,62^2) = 1,24 ~ 1
Berechnung der Zubringerpuffer:
4.5.3 Zubringerpuffer (Feeding Buffer)
Wie werden bei CCPM nicht-kritische Vorgänge verwaltet? Bei der klassischen
Methode des kritischen Pfades werden nicht-kritische Vorgänge so früh wie möglich gestartet. Dies bringt zwar möglicherweise einen großen Zeitpuffer mit sich,
hat aber auch Nachteile:
– Große Pufferzeiten ⇒ Studentensyndrom
– Ergebnisse von nicht-kritischen Vorgängen, die sehr früh vorliegen, werden
später evtl. gar nicht mehr benötigt, falls sich die Projektziele ändern (Änderungsmanagement).
– Gerade zu Beginn bestimmter Phasen werden evtl. viele Vorgänge gleichzeitig gestartet. Dies hält dann den Projektleiter von seiner eigentlichen Aufgabe, die kritischen Bereiche zu managen, ab.
Goldratt schlägt daher vor, nicht-kritische Vorgänge so spät wie möglich zu beginnen. So spät wie möglich heißt: Man muss soviel Puffer vorsehen, dass Verzögerungen an nicht-kritischen Vorgängen nach Möglichkeit die kritische Kette
nicht beeinträchtigen. Auch hier gilt wieder: Man fasst die Puffer möglichst vieler
nicht-kritischer Vorgänge zu einem Puffer zusammen und fügt diesen an das Ende
des zugehörigen Teilpfades (Abbildung 4.26, a). Diese Art von Puffer wird von
Goldratt als Zubringerpuffer (feeding buffer) bezeichnet. Der Zubringerpuffer
ist i. Allg. kleiner als der freie Puffer des zugehörigen Pfades (Abbildung 4.26, b).
a)
V6
V1
b)
V2
V6
V1
V1
V2
V8
V3
V4
V7
V2
V6
c)
V7
V8
V3
V7
Zubringerpuffer
V5
freier Puffer
V4
V5
V4
V5
V8
V3
Abbildung 4.26: Ermittlung eines Zubringerpfades
Ein Teilpfad, für den ein Zubringerpuffer ermittelt werden kann, besteht aus einer
Folge von nicht-kritischen Vorgängen, an deren Ende i. Allg. ein freier Puffer vorhanden ist, der mögliche Verzögerungen dieser Vorgangskette abpuffert, wie z. B.
160
V6 → V7 → V8 in Abbildung 4.26, b. Das Ergebnis dieses so genannten Zubringerpfades wird von Vorgang V5 im so genannten Empfängerpfad V1 → . . . → V5
benötigt. Man beachte, dass Zubringerpfade kleiner als Empfängerpfade sein sollten. Das heißt, der Vorgang V1 wird als Element des Empfängerpfades angesehen,
obwohl er theoretisch auch dem Zubringerpfad zugerechnet werden könnte.
In seltenen Fällen gibt es Zubringerpfade ohne freien Puffer. Ein derartiges Beispiel wird in Abbildung 4.26, c illustriert. So ein Pfad entsteht z. B., wenn alle
Vorgänge V1 . . . V8 kritisch sind und bei der Ermittlung der kritischen Kette die
Vorgänge V6 . . . V8 im Schritt 13 des Algorithmus zur Ermittlung des Gesamtpuffers einfach als nicht-kritisch deklariert werden. Aber auch wenn alle Vorgänge
V1 . . . V8 nicht-kritisch sind, kann diese Konstellation in seltenen Fällen auftreten. In so einem Fall gibt es zwei Möglichkeiten, Zubringer- und Empfängerpfad
festzulegen:
1. Empfängerpfad V1 → V2 → V3 → V4 → V5
Zubringerpfad V6 → V7 → V8
2. Empfängerpfad V1 → V6 → V7 → V8 → V5
Zubringerpfad V2 → V3 → V4
Der Projektleiter wählt einfach den aus seiner Sicht wichtigeren Pfad als Empfängerpfad. In einem derartigen Fall ist ist der berechnete Zubringerpuffer größer
als der (nicht vorhandene) freie Puffer. Im übernächsten Paragraphen Überhang
werden Lösungsmöglichkeiten für dieses Problem vorgestellt.
Berechnung des Zubringerpuffers von Zubringerpfaden
Im Beispiel in Abbildung 4.24 gibt es zwei Zubringerpfade (Va und Vc → Vd)
ebenso wie im oberen Gantt-Diagramm von Abbildung 4.22 (B und D → F). Anhand des letzteren Gantt-Diagramms soll die Ermittlung der Zubringerpuffer noch
einmal genauer erklärt werden. In diesem Diagramm sind drei nicht-kritische Vorgänge enthalten. Das Ergebnis von Vorgang B wird am 17. Juni bei Start des
Vorganges E benötigt. Da der Vorgang B nach vier Tagen abgeschlossen werden
kann, hat er einen freien Puffer von weiteren vier Tagen, sofern er gleich am 6.
Juni gestartet wird.
Die Vorgänge D und F bilden einen Pfad von zwei Vorgängen, deren Gesamtergebnis erst zu Projektende benötigt wird. Der freie Puffer am Ende der beiden
Vorgänge beträgt ebenfalls vier Tage.
Für nicht-kritische Pfade wird der Zubringerpuffer auf die gleiche Weise wie der
Projektgesamtpuffer für den kritischen Pfad, indem die Quadrate der Standardabweichungen der zugehörigen Vorgänge aufsummiert werden und daraus die Wurzel gezogen wird. Je nachdem, mit welcher Wahrscheinlichkeit man eine Verzögerung des kritischen Pfades vermeiden will, multipliziert man das Ergebnis mit 2
161
oder 3 (bei nicht-kritischen Vorgängen sind Verzögerungen wahrscheinlicher, da
Mitarbeiter meist nicht von anderen Aufgaben entlastet werden):
q
p
2 = 2 12 = 2
z1 = 2 σB
q
q
2 + σ 2 = 2 12 + 0, 832 = 2, 6 ≈ 3
z2 = 2 σD
F
Dementsprechend kann im Beispiel von Abbildung 4.22 der Start von Vorgang B
um zwei Tage nach hinten verschoben werden und der Start der Vorgänge D und
F um jeweils einen Tag (Abbildung 4.22: unteres Diagramm).
In den Beispielen in Abbildung 4.25 und Abbildung 4.31 wurden die Zubringerpuffer auf dieselbe Art und Weise ermittelt.
Überhang
Bei der Ermittelung der Dauer eines Zubringerpuffers kann es passieren, dass gar
nicht so viel freier Puffer vorhanden ist, wie benötigt wird (vgl. Abbildung 4.27,
a). Diese Problem tritt insbesondere bei ehemaligen kritischen Vorgängen auf, die
da sie auf parallelen Pfaden zur kritischen Kette liegen, einfach als nicht-kritisch
definiert wurden. Bei derartigen Vorgängen ist für einen Zubringerpuffer überhaupt kein Zeitfenster vorhanden (da sie ja eigentlich kritisch wären).
Über dieses Problem schweigt sich Goldratt leider aus. Und Leach [2005] schlägt
lediglich vor, den Überhang einfach als Puffer in den nachfolgenden Pfad einzufügen (vgl. Abbildung 4.27, b).
Überhang u
a)
V6
V1
b)
V7
V2
V6
V1
c)
V3
V7
V2
V6
V1
V8
V5
V8
V3
V7
V2
V4
V4
V5
V8
V3
V4
V5
Abbildung 4.27: Überhang des Zubringerpuffers
Ich halte die Lösung von Leach für unbefriedigend, da Zwischenpuffer das Projekt
unnötig verlängern. Besser ist es, den Überhang zum Puffer der nachfolgenden
Kette (also zu einem Zubringerpuffer, falls die nachfolgende Kette nicht-kritisch
162
ist, oder sonst zum Gesamtpuffer) hinzuzufügen (vgl. Abbildung 4.27, c). Dafür
gibt es mehrere Möglichkeiten:
1. Den gesamten Überhang zum Gesamtpuffer hinzufügen (dies ist nicht viel
besser als Lösung b).
2. Den Überhang u als eigenständigen Vorgangspuffer ansehen, der bei der
Berechnung des Puffers einfach mit einbezogen wird:
r
σ12
+ σ22 + σ32
+ σ42 + σ52 +
u 2
PufferV 1..V 5 = 2
2
q
(2σ1 )2 + (2σ2 )2 + (2σ3 )2 + (2σ4 )2 + (2σ5 )2 + u2
=
Achtung: u enthält schon den Faktor 2, wenn bei der Pufferberechnung jeweils
2σ ermittelt wurde.
3. Den Überhang u mit dem „virtuellen Puffer“ vqdes Parallelpfades vergleichen
(siehe Abbildung 4.28, im Beispiel gilt v = 2
σ22 + σ32 + 2σ42 ).
Ist u ≤ v, wird u ignoriert, anderenfalls wird der „Überhang des Überhangs“
u − v gemäß 2. in den Gesamtpuffer eingerechnet.
s
u−v 2
2
2
2
2
2
PufferV 1..V 5 = 2 σ1 + σ2 + σ3 + σ4 + σ5 +
2
V6
V1
V7
Überhang u
V8
V2
V3
V4
V2
V3
V4
V5
virtueller Puffer v
Abbildung 4.28: Virtueller Puffer
Keine dieser drei Methoden kann mathematisch streng begründet werden, da es
kein mit dem zentralen Grenzwertsatz vergleichbaren Satz für die Approximation
der Zufallsverteilung von parallel laufenden Ereignissen gibt.
Also muss das Bauchgefühl ran:
– Die erste Lösung ist sicher zu grob. Davon würde ich abraten.
– Die zweite Lösung ist vermutlich auch noch zu pessimistisch, da V4 ja auch
schon abgepuffert ist und dieser Puffer teilweise mitbenutzt werden kann.
– Die dritte Lösung ist zu optimistisch, da die Wahrscheinlichkeit, dass sich
einer von zwei parallelen Vorgängen verzögert, höher ist, als dass sich ein
einziger Vorgang verzögert.
163
Ich würde i. Allg. dennoch die dritte Lösung anwenden. Wenn allerdings an einer
Einmündestelle gleichzeitig die Zubringerpuffer von drei oder noch mehr Ketten
einen Überhang aufweisen, würde ich zwar ebenfalls zur dritten Lösung tendieren,
aber das Maximum aller parallelen Überhänge um einen gewissen Sicherheitsaufschlag erhöhen.
Speziallfall
Wenn zwei kritische Pfade parallel verlaufen, muss bei CCPM einer der beiden
Pfade als nicht-kritisch dekalriert werden. In diesem Fall ist es besser, denjenigen
Pfad als kritisch zu belassen, der der größeren „virtuelle Zwischenpuffer“ besitzt,
da in diesem Fall der „virtuelle Zischenpuffer“ des anderen (ehemals kritischen)
Pfades gemäß Möglichkeit 3 einfach ignoriert werden kann.
4.5.4 Ressourcenpuffer
Kurz bevor ein Mitarbeiter (oder eine andere wichtige Resource) mit der Arbeit
an einem kritischen Vorgang beginnt, sollte er von anderen wichtigen Aufgaben
freigestellt werden, so dass er ohne Verzögerung mit der Arbeit an dem kritischen
Vorgang beginnen kann, sobald der Vorgängervorgang abgeschlossen ist.
Diese Art von Puffer bezeichnet Goldratt als Ressourcenpuffer (resource buffer).
Ressourcenpuffer werden allerdings in kein Diagramm eingetragen oder sonstwie
explizit dargestellt. Es handelt sich lediglich um eine Managementhandlung.
164
165
0
0
0
0
1
0
4
1
4
Vb
3
0
1
5
3
3
3
2
3
5
3
3
2
2
Vd
4
0
Vc
5
7
5
7
7
4
7
7
7
8
2
0
Vf
1
1
Ve
9
9
7
8
9
6
9
9
9
9
8
fS
sS
D
gP
fE
sE
<Nummer>
Vorgangsname
0
0
Ende
fS
D
fE
sS
gP
sE
=
=
=
=
=
=
Dauer
gesamte Pufferzeit
Meilenstein
kritischer Vorgang
Vorgang
Vb
Vc
Vd
Ve
Vf
Ende
4
5
6
7
8
Va
2
3
Start
1
0d
2d
1d
2d
4d
1d
3d
0d
1. Aug. 2011
8. Aug. 2011
15. Aug. 2011
22. Aug. 2011
6EA, 7EA
4EA, 5EA
4EA
2EA, 3EA
2EA
1EA
1EA
Meilenstein
kritischer Vorgang
freie Pufferzeit
gesamte Pufferzeit
Vorgang
1. Gantt−Diagramm (gemäß CPM, ohne Resource Leveling, mit kritischem Pfad und freien sowie gesamten Pufferzeiten)
0
0
Start
0
0
Va
1. Vorgangsknotennetz (ohne Resource Leveling)
166
0
0
0
0
1
0
2
1
2
Vb
3
0
1
3
3
3
3
2
A
B
7
7
3
3
2
0
Vd
4
0
B
Vc
9
9
5
7
7
4
B
9
9
9
10
2
0
Vf
1
1
Ve
11
11
7
10
11
6
11
11
11
11
8
fS
sS
D
gP
fE
sE
<Nummer>
Vorgangsname
0
0
Ende
fS
D
fE
sS
gP
sE
1EA
2EA
2EA, 3EA
4EA
4EA, 5EA
6EA, 7EA
3d
1d
4d
2d
1d
2d
0d
Va
Vb
Vc
Vd
Ve
Vf
Ende
2
3
4
5
6
7
8
C
B
B
A, B
B
A
Ressource
1. Aug. 2011
8. Aug. 2011
15. Aug. 2011
22. Aug. 2011
1EA
0d
Start
1
Dauer
gesamte Pufferzeit
Meilenstein
kritischer Vorgang
max. Zubringerpuffer
Vorgang
=
=
=
=
=
=
Meilenstein
kritischer Vorgang
Vorgang
2. Gantt−Diagramm (gemäß CPM, mit Resource Leveling, kritischem Pfad und maximalen Zubringerpuffern)
0
0
Start
0
0
Va
2. Vorgangsknotennetz (mit Resource Leveling)
167
Pe = 2*0 = 0
Pacdf = 2*sqrt(0,41²+2,08²+1,65²+1,78²) = 6,45
Pb = 2*0,49 = 0,98 ~ 1,
2d
1d
5 Vd
6 Ve
0d
4d
4 Vc
8 Ende
1d
3 Vb
2d
3d
2 Va
7 Vf
0d
1 Start
6EA, 7EA
4EA, 5EA
4EA
2EA, 3EA
2EA
1EA
1EA
2,08
1,65
0,00
A, B
B
B
1. Aug. 2011
8. Aug. 2011
15. Aug. 2011
22. Aug. 2011
Abbildung 4.31: Projekt 2011: 3. Gantt-Diagramm
1,78
0,49
B
C
0,41
σ
A
Ressource
Meilenstein
kritischer Vorgang
Gesamtpuffer
Zubringerpuffer
Vorgang
3. Gantt−Diagramm (gemäß CCPM, mit Resource Leveling, kritischem Pfad, Zubringerpuffern und Gesamtpuffer)
Gesamtpuffer:
Zubringerpuffer:
4.5.5 Kritischer Pfad und kritische Kette: Ein Vergleich
Methode des kritischen Pfades
Statistische Fluktuationen werden im
Allgemeinen nur im Form von Pufferzeiten in den einzelnen Vorgängen beachtet.
Methode der kritischen Kette
Statistische Fluktuationen werden als
unabänderlich angesehen und daher
bei der Planung und Projektverlauf
von Anfang an berücksichtigt.
⇒ Paradigmenwechsel
Bis heute ist es nicht gelungen, ein
Verfahren zu entwickeln, mit dem sich
ein in statistischer Hinsicht „optimaler“ Zeitplan erstellen lässt. Daher gibt
sich CCPM damit zufrieden, einen
möglichst guten Zeitplan zu erstellen.
Die Dauer eines Vorgangs wird so geschätzt, dass der Vorgang innerhalb
der geschätzten Zeit mit großer Wahrscheinlichkeit beendet wird (mindestens 80 %, meist jedoch deutlich mehr:
90 %, 95 %, 99 %).
Das heißt, alle Einzelschätzungen enthalten implizit einen eigenen Puffer,
um statistische Fluktuationen abzufangen.
Die Dauer eines Vorgangs wird so geschätzt, dass dieser Vorgang innerhalb
der geschätzten Zeit lediglich mit ca.
50 %-iger Wahrscheinlichkeit beendet
wird (Erwartungswert ≈ Median).
Die Einzelpuffer werden bei kritischen Vorgängen als Gesamtpuffer an
das Projektende angefügt. Für zusammengehörige Ketten von nicht-kritische Vorgänge werden die Einzelpuffer ebenfalls zu einem Puffer zusammengefasst als so genannte Zubringerpuffer ins Gantt-Diagramm eingefügt.
Aufgrund statistischer Gesetze können der Gesamtpuffer und die Zubringerpuffer i. Allg. deutlich kürzer gewählt werden, als die Summe der jeweils zugehörigen Einzelpuffer.
⇒ Zeitgewinn
Fortsetzung auf der nächsten Seite
168
Vorgänge werden termingerecht beendet oder – bei unerwarteten Problemen
– später. Trotz der großen Einzelpuffer
werden Vorgänge i. Allg. nicht früher
beendet. Gründe:
– Studentensyndrom
– Die Terminplanung sieht einen
früheren Start von Nachfolgevorgängen nicht vor.
– Mitarbeiter haben keinen Anreiz einen Vorgang vor dem Termin zu beenden. Im Gegenteil:
Wenn sie einen Vorgang früher
beenden, wird ihnen beim nächsten Mal i. Allg. weniger Zeit für
einen Vorgang gewährt. Und dies
versuchen sie zu vermeiden.
Es wird häufig Multitasking, d.h. der
gleichzeitige Einsatz von Mitarbeitern
(oder anderen Ressourcen) in mehreren Vorgängen, betrieben.
Dies geschieht vor allem, um jede
Ressource so gut wie möglich auszulasten.
Insbesondere kommt es oft zu Planungen, bei denen eine Ressource in
mehreren parallel laufenden Vorgängen jeweils zu 100 % verplant ist (fehlendes Resource Leveling). Derartige
Vorgänge werden normalerweise nicht
termingerecht beendet.
Vorgänge werden vor, zum oder nach
dem gesetzten Termin beendet.
Für die Mitarbeiter gibt es keine festen Terminvorgaben, sondern nur die
Vorgabe, einen Vorgang so schnell wie
möglich zu beenden, ohne Abstriche
an Funktionalität oder Qualität zu machen. Mitarbeiter dürfen dabei nicht
unter Druck gesetzt werden, insbesondere Überstunden sind nur in Ausnahmefällen zulässig.
⇒ Zeitgewinn bei früher, termingerecht oder nur leicht verspätet beendeten Vorgängen (da die Vorgangsdauer
kürzer als bei CPM geschätzt wird).
Multitasking wird grundsätzlich vermieden, d.h., Resource Leveling ist
Pflicht.
⇒ Zeitgewinn, da Multitasking jeden
Einzelvorgang bis auf den letzten verzögert.
⇒ nochmals Zeitgewinn, da der Overhead, der durch Taskwechsel entstehen würde, entfällt.
Fortsetzung auf der nächsten Seite
169
Mitarbeiter, die an kritischen Vorgängen arbeiten, werden nicht vom Tagesgeschäft entlastet.
Mitarbeiter, die an kritischen Vorgängen arbeiten, werden vom Tagesgeschäft entlastet (wenig Telefon,
kaum E-Mails, keine anderen Aufgaben etc.).
⇒ Zeitgewinn
Die Drei-Punkt-Schätzmethode für
die Dauer der Einzelvorgänge (kürzeste Dauer, wahrscheinliche Dauer,
längste Dauer) ist wenig hilfreich, da
CPM für jeden Vorgang einen Schätzwert und nicht drei benötigt.
Natürlich kann man dennoch Dreipunkt-Schätzungen durchführen (wie
dies beispielsweise bei PERT gemacht
wird) und dann beispielsweise µi + σi
als Schätzwerte für die jeweilige Dauer verwenden. Bei vielen Vorgängen
ist auch dieser (implizite) Puffer deutlich zu groß.
Die Drei-Punkt-Schätzmethode für
die Dauer der Einzelvorgänge (kürzeste Dauer, wahrscheinliche Dauer,
längste Dauer) ist sehr hilfreich und
wird meist eingesetzt, um für jeden
Vorgang sowohl einen guten Schätzwert für die Dauer (Erwartungswert),
als auch für einen notwendigen Puffer
(2 bis 3 mal Standardabweichung) zu
ermitteln.
Tabelle 4.1: Vergleich der Methoden des kritischen Pfades und der kritischen Kette
170
4.6 Beispiele für den erfolgreichen Einsatz von
CCPM
Bahnstromspezialist Transtechnik aus Holzkirchen. (Steeger [2005], Klein et al.
[2005])
Fehlt im Skript noch!
4.7 Multiprojektmanagement
(vgl. Goldratt [2002], Leach [2005])
Fehlt im Skript noch!
4.8 Projektkontrolle (Controlling)
Projektkontrolle bedeutet, regelmäßig den aktuellen Stand des Projektes mit dem
geplanten Stand zu vergleichen (Soll-Ist-Vergleich) und bei wesentlichen Abweichungen frühzeitig gegenzusteuern.
Kontrolle ist ein wesentlicher Bestandteil der fortwährenden Planung (der selbst
auch geplant werden muss).
Insbesondere folgende Pläne sollten überwacht werden:
– Terminplan
– Kostenplan
– Qualitätskontrollplan
Bei der Kontrolle müssen dieselben Werkzeuge (SW-Tools etc.) zum Einsatz kommen, wie bei der Planung, um vergleichbare Werte zu erhalten.
Anforderungen an Pläne aus Sicht der Projektkontrolle:
– Jeder Vorgang endet mit einem „Produkt“, d. h., es ist entscheidbar, ob der
Vorgang beendet wurde oder nicht.
– Vorgänge sind kurz (wenn möglich ein oder wenige Wochen).
– Ergebnisse sind in irgendeiner Form messbar und damit vergleichbar.
171
4.8.1 Dringlichkeitslisten
Ein wichtiges Mittel zur Steuerung und Kontrolle von Projekten, sind die so genannten Dringlichkeitslisten (hot lists). In diese Listen werden dringende Tätigkeiten (mit Terminen) eingetragen, die sich nicht exakt in ein Balkendiagramm
bringen lassen oder die aus einem anderen Grund besonders beachtet werden müssen.
Die Dringlichkeitsliste sollte immer aktuell gehalten werden.
4.8.2 Tätigkeitsberichte
Um ein Projekt zu überwachen, kann man die so genannten Tätigkeitsberichte
einführen.
In einem (wöchentlichen) Tätigkeitsbericht trägt jeder Mitarbeiter ein, wie lange
er an welchem Vorgang gearbeitet hat.
Achtung: Tätigkeitsberichte sind unbeliebt und tragen häufig zu einem schlechteren Betriebsklima bei (vgl. Abschnitt 5.3). Um wirklich Tätigkeitsberichte und
keine Lügenberichte zu erhalten, sollten Sie sie nach Möglichkeit vermeiden oder
zumindest Folgendes beachten:
– Entweder alle oder keiner (und nicht etwa nur die schlechteren Mitarbeiter).
– Keine minutengenaue Zeiterfassung. Eine Genauigkeit von höchstens 1 h
reicht vollkommen.
– Machen Sie ihren Mitarbeitern klar, dass Sie wissen, dass die Mitarbeiter
höchstens 6 h an 4 Tagen pro Woche produktiv für das Projekt arbeiten können.
– Machen Sie ihren Mitarbeitern außerdem klar, dass die Erfassung von Überstunden für sie nur von Vorteil ist.
– Machen Sie den Mitarbeitern außerdem klar, dass die Erfassung der Daten
nicht gegen sie verwendet wird.
– Sorgen Sie dafür, dass die Mitarbeiter Ihren Aussagen vertrauen können.
– Setzen Sie diese Art von Berichten nicht als Druckmittel gegen Ihre Mitarbeiter, sondern für Ihre Mitarbeiter (zu deren Entlastung) ein.
Tätigkeitsberichte haben mehrere Vorteile:
– Ihnen stehen aktuelle Zahlen (einschließlich aktualisierter Schätzungen) für
die weitere Planung zur Verfügung.
– Sie haben konkrete Zahlen für realistische Schätzungen von Folgeprojekten.
172
– Sie sehen, bei welchen Tätigkeiten Projektarbeitszeit verloren geht.
– Sie haben Daten (nachdem Sie die Einzeldaten anonymisiert und aggregiert
haben), mit denen Sie gegenüber Betriebsrat („Warum so viele Überstunden?’") und dem Management („Warum so wenig Projektarbeit?“) argumentieren können.
Tätigkeitsberichte können allerdings zum echten Problem werden, wenn Sie die
obigen Punkte nicht strikt beachten. Mir ist eine ehemalige Mitarbeiterin eines
großen deutschen Unternehmens bekannt, die sich irgendwann weigerte, Tätigkeitsberichte zu unterschreiben. Jedesmal, wenn sie einen derartigen Bericht gewissenhaft ausgefüllt hatte, kam ihr Chef und „verbesserte“ (genauer: fälschte)
ihn. Alle Meetings und sonstigen Arbeitsstunden, die nicht irgendeinem Projekt
zugeordnet werden konnten, für das die Abteilung stundenweise bezahlt wurde,
wurde einem dieser Projekte zugeschlagen. Später hat der Chef diese Berichte
selbst unterschrieben (nachdem er sie entsprechend seinen Vorstellungen angepasst hatte).
4.8.3 Zeitdiagramme
Die Schätzungen, wie viele Tage ein Vorgang noch benötigt, können in ein so
genanntes Zeitdiagramm eintragen werden.
D
A
B
C
1. Juni 8. 15. 22. 29. 6. 13. 20. 27. 3. 10. 17. 24.
geplante
Zeit
8.
15.
22.
29.
6. Juli
13.
20.
27.
3. Aug.
10.
17.
24.
tatsächliche Zeit
Der Schätzer von A hat für die berühmten letzten 10 % länger gebraucht, als für
173
174
Überstunden
Allg. Meetings
Ausbildung
Literaturstudium
Sonst. (z.B. Verwaltung)
Summe
Ausfallzeiten
Krankheit, Arzt
Urlaub
sonst. Abwesenheit
Wartung
Name: H. Meier
Projekt
Amun
8
2
Mo
2
4
1
9
6
3
Di
8
2
2
Mi
4
-2
6
Do
4
2
8
1
3
2
Fr
2
-1
39
3
3
31
2
Datum (Montag): 22. Juni 1998
Summe noch Tage Bemerkungen
12
2
6
20
unerwart. Probleme
3
2
ungeplant
8
Tabelle 4.2: Beispiel eines Tätigkeitsberichtes
Tätigkeit
Codierung
Design
Dienstgang
Interview Hr M.
Tätigkeitsbericht
den Rest. B war ein optimaler Schätzer (ein Pedant?). C wurde unterwegs optimistisch, erreichte dann jedoch das Ziel „nur“ zur anfangs geplanten Zeit. Und
D hatte zum Schluss eine Woche Verzögerung, nachdem er zwischenzeitig pessimistischer geschätzt hatte.
4.8.4 Gesamtpufferverbrauch als Risikoindikator
Die Kontrolle des Gesamtpufferverbrauchs liefert einem einen wunderbaren Indikator zur Früherkennung von Problemen hinsichtlich des angestrebten Endtermins
(vgl. Abschnitt 1.4).
Der Gesamtpufferverbrauch sollte maximal dem Projektfortschritt entsprechen.
Das heißt, wenn erst 50 % Prozent des Projektes erledigt wurde, sollte auch nicht
mehr als 50 % des Puffers verbraucht worden sein.
Dies kann man mit einem ganz einfachen Diagramm überwachen (siehe Abbildung 4.32): In der x-Richtung werden die kritischen Vorgänge eingetragen und
zwar jeweils an demjenigen Projekttag, an dem sie beendet sein sollten (Wochenende und Feiertage werden nicht beachtet!). In y-Richtung notiert man für jeden
Vorgang, sobald er abgeschlossen wurde, den Gesamtpufferverbrauch (entweder
prozentual oder auch in Tagen).
Das Diagramm wird in drei Bereiche eingeteilt: Einen roten Bereich, einen gelben
Bereich und einen grünen Bereich.
Das Diagramm wird wie folgt interpretiert: Solange die Eintragungen im grünen
Bereich vorgenommen werden, ist auch alles auch alles im grünen Bereich. Sollte der Pufferverbrauch in den gelben Bereich eintreten, so muss der Projektleiter
Gegenaktionen (wie z. B. eine Änderung des Terminplans oder des Funktionsumfangs) planen. Spätestens, wenn der Pufferverbrauch in den roten Bereich eintritt,
sollte er die Gegenmaßnahmen auch durchführen.
Wohin genau das gelbe Band zwischen den roten Bereich und den grünen Bereich gelegt wird, muss jeder Projektleiter selbst entscheiden. Im Beispiel umfasst der Bereich zu Projektbeginn das Intervall [20 %, 40 %] und zu Projektende
[90 %, 100 %]. Diesen Intervallen (die ich favorisieren würde) liegt die Idee zugrunde, dass, wenn es zu Projektanfang zu etwas größeren Schwankungen kommt,
diese nicht gleich zu hektischen Gegenreaktionen führen sollten. Ein großer Pufferverbrauch zu Projektende ist auch kein Drama mehr. Mann könnte das Intervall
bei Projektende sogar auf den einen Punkt reduzieren: [100 %, 100 %].
Leach [2005] ist etwas vorsichtiger: Zu Projektbeginn wählt er das Intervall
[5 %, 10 %] und zu Projektende [60 %, 90 %]. Das heißt, für ihn ist ein Pufferverbrauch von mehr als 90 % bei Projektende ein unerwünschtes Ergebnis. Ein
Pufferverbrauch von 60 % kurz vor Projektende nötigt den Projektleiter noch zu
175
Abbildung 4.32: Risikoindikator für den Projektendtermin
Gegenaktionen. Ich halte das für falsch! Ich würde den Wert 60 % deutlich erhöhen.
Der im Wikipedia-Artikel zu CCPM (Wikipedia [2011a]) im Diagramm „Projektverlauf“ (angefertigt von Wolfram Müller von www.Speed4Projects.Net) vorgestellte gelbe Bereich liegt zu Projektbeginn im Intervall [−31 %, 50 %] (das Minuszeichen ist kein Druckfehler!) und zu Projektende im Intervall [92 %, 100 %].
Während das Projektende in Ordnung ist, ist der Projektbeginn vollkommen unbrauchbar. Selbst wenn man zu Projektbeginn den Gesamtpuffer vergrößern kann,
befindet man sich im gelben Bereich, der anzeigt, dass man Gegenmaßnahmen
planen muss. Erst nachdem 25 % des Projektes fertiggestellt wurden, liegt ein Gesamtpufferverbrauch von 0 % im grünen Bereich!???
Im CCPM-Artikel von Klein et al. [2005] ist sogar ein noch größerer gelber BeDraft (4. Oktober 2012)
176
reich angegeben. Im selben Artikel wird Dr. Hans-Joachim Schulz, Geschäftsführer von Transtechnik zitiert, dass er sich nur um Projekte, deren Gesamtpufferverbrauch sich im roten oder gelben Bereich befindet, zu kümmern braucht. Das
vorgestellte Diagramm bedeutet für den armen Herrn Schulz, dass sich gerade
zu Projektanfang jedes Projekt im gelben Bereich befindet und er sich mit allen
diesen Projekten, die noch gar keine Probleme aufweisen, befassen müsste.
Man beachte, dass es drei Arten von Projekten gibt:
– Die gesunden Projekte (= richtig geschätzten) pendeln in y-Richtung um den
Null-Punkt herum.
– Die zu optimistisch geschätzten Projekte streben von der x-Achse nach oben
weg.
– Die zu pessimistisch geschätzten Projekte streben dagegen nach unten weg.
Ich habe ganz bewusst in Abbildung 4.32 für den grünen Bereich auch die negative y-Achse eingezeichnet, um noch einmal klar zu machen, dass die vorzeitige
Beendigung eines Vorgangs genauso häufig passiert, wie die verspätete Beendigung. Leider wird diese Tatsache weder im Buch von Leach [2005] noch im Wikipedia-Artikel zu CCPM (Wikipedia [2011a]) noch im Artikel von Klein et al.
[2005] visualisiert. Auch hier stellt man wieder fest, dass eine vorzeitige Abgabe
von Ergebnissen für die meisten Menschen keine Option darstellt, die man ernsthaft in Erwägung ziehen muss.
4.8.5 Earned-Value-Analyse
Gewöhnliche Kostenüberwachung vergleicht zu jedem Zeitpunkt die geplanten
(SOLL-Kosten) mit den angefallenen Kosten (IST-Kosten). Diese Zahlen spiegeln
aber ein falsches Bild wieder. Wenn zum Zeitpunkt x beispielsweise die SOLLKosten gleich den IST-Kosten sind, aber erst 67 % der bis dahin geplanten Arbeit
geleistet wurde, so liegt man nicht im Kostenrahmen, sondern hat ihn um 50 %
überzogen (3/3 der Kosten bei 2/3 der Arbeit).
Um derartige Probleme frühzeitig zu entdecken, wurde die so genannte
Earned-Value-Analyse (Arbeitswert-Analyse) eingeführt.
Der Earned-Value (Arbeitswert) gibt den Wert der Arbeit an, die bis zum Stichtag
geleistet wurde. Dieser Wert entspricht den Kosten, die tatsächlich hätten entstehen dürfen. Im obigen Fall entspricht der Earned-Value lediglich 67 % der SOLLKosten. Verglichen mit dem Earned-Value sind die IST-Kosten um den Faktor 1,5
zu hoch.
177
Kennzahlen einer Earned-Value-Analyse
1. Budgetkosten der geplanten Arbeit (BCWS = Budgeted Cost of Work Scheduled)
BCWS bezeichnen die Kosten, die für die bis zum Zeitpunkt x geplante Arbeit
eingeplant waren: Sollkosten für geplante Arbeit.
2. Earned Value (BCWP = Budgeted Cost of Work Performed)
BCWP werden oft als Budgetkosten der geleisteten Arbeit bezeichnet. Sie
bezeichnen die Kosten, die für die bis zum Zeitpunkt x tatsächlich geleistete
Arbeit eingeplant waren: Sollkosten für geleistete Arbeit.
BCWP/BCWS entspricht dem Prozentsatz der geleisteten Arbeit (in unserem Beispiel z. B. 40 000/60 000 = 0, 67). Man kann auch die Differenz von
geleisteter und geplanter Arbeit bilden: BCWP − BCWS (in unserem Fall
40 000 − 60 000 = −20 000). Dieser Wert heißt Leistungsabweichung oder
Planabweichung (SV, schedlue variance). Negative Planabweichungen sagen
– genauso wie BCWP/BCWS-Werte < 1 – aus, dass man entweder dem Plan
hinterherhinkt oder dass man das vorgesehene Budget überschreitet.
3. Ist-Kosten der geleisteten Arbeit (ACWP = Actual Cost of Work Performed)
ACWP gibt an, wie viel Geld bislang wirklich ausgegeben wurde. Die Differenz BCWP−ACWP heißt Kostenabweichung (CV). Der Faktor (cost variance) ACWP/BCWP (= 1,5 in unserem Beispiel, da in unserem Beispiel ACWP
= BCWS angenommen wurde) kann verwendet werden, um eine neue Schätzung für die Projektgesamtkosten zu erstellen. Der Kehrwert BCWP/ACWP
(= 0,67 in unserem Beispiel) heißt Kostenentwicklungsindex (CPI, cost performance index). Ein Wert >1 bedeutet eine gute Kostenentwicklung, ein Wert
<1 zeigt Probleme an.
4. Abweichung bei Fertigstellung (VAC = variance at completion)
Die Abweichung bei Fertigstellung ist die Differenz aus den (geschätzten)
Gesamtkosten (EAC = estimated cost at completion) und dem Gesamtbudget
(BAC = budget at completion): VAC = EAC − BAC. Es gilt dabei dabei:
EAC = BAC · ACWP / BCWP
5. Geschätzte Restkosten bis zur Fertigstellung (ETC)
Die geschätzten Gesamtkosten (EAC) minus den bisherigen Kosten (ACWP)
sind die geschätzten Restkosten bis zur Fertigstellung (ETC = estimated cost
to completion).
An Tag X hätte die erst am Stichtag geleistete Arbeit bereits geleistet sein sollen.
178
Kosten
EAC
Restkosten
(ETC)
Istkosten
Kostenabweichung
zur Fertigstellung
(VAC)
Soll/Ist−Abweichung
(keine Aussagekraft)
ACWP
BAC
Kosten−
abweichung (CV)
Sollkosten
BCWS
Leistungs−
abweichung (SV)
Plankosten
BCWP
Zeit
X
Stichtag
Abbildung 4.33: Übersicht über die wesentlichen Earned-Value-Größen
179
180
Kapitel 5
Menschenführung und
Teamarbeit
5.1 Management
Einen ganz wesentlichen Anteil am Projekterfolg hat das Management, da es für
das Klima im Unternehmen die Hauptverantwortung trägt. Mitarbeiter, die sich
wohlfühlen und mit dem Unternehmen identifizieren, leisten mehr.
Patrizia Pitcher, Professorin für Führungsfragen an der kanadischen BusinessSchool École des Hautes Études Commerciales in Montreal, hat ein Buch mit
dem Titel „Das Führungsdrama“ geschrieben (Pitcher [1997]). Darin seziert sie
die Gründe für den Aufstieg und den Fall einer weltweit operierenden, milliardenschweren Finanzfirma (siehe z. B. SZ Nr. 61, 14./15. März 1998, Seite I).
Sie teilt die Menschen in drei Gruppen ein (obwohl es nach ihrer Aussage Grauzonen und eher 9 Gruppen gibt):
Künstler:
intuitiv, visionär, unternehmerisch, sprunghaft, kühn, menschenorientiert etc.
Handwerker: zuverlässig, realistisch, berechenbar, pünktlich, stabil, hilfsbereit,
liebenswürdig, human etc.
Technokraten: entschlossen, kompromisslos, kühl-sachlich, steif, hart arbeitend,
scharfsinnig, energisch etc.
Ein Mensch kann auch eine Mischung aus zwei Kategorien sein (z. B. ein kreativer
Handwerker oder praktischer Künstler)1, niemals jedoch aus allen dreien.
Dem oben erwähnte Unternehmen gelingt mit einem Künstler als Firmengründer, vier Handwerkern und einem Technokraten in der zweiten Führungsebene
ein atemberaubender Aufstieg in die Weltspitze. Technokraten besorgten später
den Niedergang. Sie sind zwar brillant, aber am falschen Platz verheerend. Erst
1
Solche Menschen suchen wir als Multimedianer!
181
wurde der Künstler (ohne ihn vorher zu informieren) gefeuert, dann die Handwerker. Alle wurden durch Technokraten (d. h. Klone der vorhandenen Technokraten)
ersetzt.
Es gab neue Computer, neue Kontrollverfahren, Vorführungen, auf denen lediglich gezeigt wurde, wie toll die Firma ist etc. Neue Märkte, neue Produkte, neue
Projekte waren out – in waren nur noch neue Wege, die Firma zu organisieren.
Viele gute Leute wurden entlassen, weil angeblich ihre Ergebnisse schlecht waren.
Technokraten sind „dumm und blind“ (Pitcher [1997]). Sie glauben selbst, alles im
Interesse der Firma zu tun. Sie glauben auch, dass Künstler mit ihren verrückten
Vorstellungen eine Gefahr für die Firma sind und Handwerker zu dumm, um einen
Beitrag zu leisten.
5.2 Führungsstile
„Angewandte Führungsstile sind nur dann erfolgreich, wenn die menschlichen
Eigenschaften der am Führungsprozess beteiligten zusammenpassen.“ (Oyen und
Schlegel [1986]).
Man unterscheidet folgende Führungsstil-Varianten (Lewin et al. [1993], Schmidt
[2003]):
– Autoritäre Führung:
Der Führende entscheidet, d. h. hat Handlungsvollmacht.
– Kooperative Führung:
Der Führende fungiert als Initiator und Aktivator. Die Gruppenmitlieder sind
aktiv am Prozess der Willensbildung beteiligt.
– Laissez-faire-Führung
Der „Führende“ stellt lediglich sachliche Arbeitsmittel bereit, greift aber in
die Handlungsprozesse der Gruppe nicht ein.
Zwischen diesen Extremen gibt es natürlich Abstufungen:
autoritär – patriarchisch – beratend – kooperativ – partizipativ – demokratisch
autoritär:
Der Vorgesetzte entscheidet.
patriarchalisch: Der Vorgesetzte entscheidet und versucht zu überzeugen.
beratend:
Der Vorgesetzte entscheidet, gestattet jedoch Fragen zu seinen
Entscheidungen.
kooperativ:
Der Vorgesetzte entscheidet erst, nachdem er die Meinung der
Untergebenen gehört hat.
182
partizipativ:
Das Team entwickelt Vorschläge, der Vorgesetzte wählt einen
aus.
demokratisch:
Der Vorgesetzte legt den Entscheidungsspielraum fest, das Team
entscheidet.
demokratischer: Das Team entscheidet, der Vorgesetzte fungiert als Koordinator
nach innen und nach außen.
Heute werden die verschiedenen Führungsstile normalerweise Management-byMethoden genannt (Schmidt [2003]).
– Management by Objectives (MbO, weit verbreitet)
Die Führung durch Zielsetzung basiert im wesentlichen auf der regelmäßigen Festlegung von Unternehmens- (oder Projekt-)zielen. Vorgesetzte geben ihren Mitarbeitern Ziele vor, die Mitarbeiter entscheiden selbstständig.
Am Periodenende werden die Mitarbeiter beurteilt (vorgegebene vs. erreichte Ziele).
Dies ist der Managementstil der 50er-Jahre. Er ist vollkommen veraltet und
unbrauchbar, aber leider weit verbreitet. (Deming [2000],DeMarco und Lister [1991],DeMarco [2001])
Nachteile:
• Es können nur messbare Ziele vereinbart werden, keine strategischen.
• Durch MbO werden nur bestehende Prozesse optimiert. Risiken werden
nicht eingegangen. Das heißt: MbO verhindert Veränderungen.
• MbO bewirkt Wettbewerb im Team. Dies ist das Gegenteil von Teamarbeit.
• MbO bewirkt übermäßigen Druck mit allen seinen negativen Folgen
wie Burnout, Mitarbeiterfluktuation etc.(vgl. Abschnitt 5.3).
• Instrinsische Motivation wird durch extrinsische Motivation ersetzt.
• MbO optimiert lokal (jeder Mitarbeiter versucht seine Leistung zu optimieren – insbesondere auf Kosten anderer). Dies steht jedoch fast immer im Widerspruch zur globalen Optimierung, die die Optimierung
der Unternehmensgewinne und anderer Unternehmensziele zur Aufgabe hat (vgl. Abschnitt 1.2.3 (ToC): Die Optimierung der Leistung aller
Fahrzeuge oder Maschinen ist auch hier kontraproduktiv.)
Der Widerspruch, dass sich viele lokale Optimierungsbemühungen kontrapoduktiv auf die globalen Optimierungsbemühungen auswirkt, wird von Robert D. Austin als Dysfunktion bezeichnet (Austin [1996]). Austin führt folgendes Beispiel an: Wenn in einer Fabrik die Anzahl der Nägel optimiert
werden soll, werden nur noch kleine Stahlstifte produziert. Wird dagegen
das Gewicht optimiert, werden nur noch Gleisbolzen hergestellt. Das Unternehmensziel, möglichst viele Nägel zu verkaufen, wird in beiden Fällen
183
nicht erreicht, da die von Kunden gewünschten Nägel fehlen.
DeMarco [2001] begründen aufgrund der jahrzehntelangen Erfahrung mit
MbO, dass Dysfunktion ein inhärenter Mangel von MbO ist. Beispielsweise
verkauft ein Verkäufer, der aufgrund von MbO angespornt wird, eine Verkaufsquote zu erfüllen, mit hoher Wahrscheinlichkeit kaum benötigte Güter.
Der Effekt ist, dass die Kundenbasis immer kleiner wird, weil die Kundenzufriedenheit in den Hintergrund tritt.
– Management by Results (MbR)
Hier werden nicht nur Ziele, sondern die erwarteten Ergebnisse vorgegeben.
Diese Art des Managements ist auch nicht besser als MbO.
– Management by Exception (MbE)
Normal- und Routinefälle werden von untergeordneten Mitarbeitern völlig
selbständig entschieden. Ausnahmefälle, d. h. insbesondere Abweichungen
von vereinbarten Zielen, werden vom Vorgesetzten entschieden. ⇒ Klare
Definition der übertragenen Aufgaben ist wichtig. Alles, was nicht klar festgelegt wurde, ist ein Ausnahmefall.
Auch hier gelten Kontrollzahlen als Maxime. Damit ist auch diese Methode
nicht besser als MbO.
– Management by Delegation (MbD)
Aufgaben und Befugnisse werden an Mitarbeiter unterer Hierarchieebenen
delegiert und geeignet kontrolliert.
Kompetenzen an Untergebene abzugeben und diesen Vertrauen zu schenken
ist ein Prinzip, dass auch von Tom DeMarco und Timothy Lister favorisiert
wird (DeMarco und Lister [1991], DeMarco [2001])
– Management by Participation (MbP)
Starke Mitarbeiterbeteiligung bei Entscheidungen, das heißt schwache partizipative Führung.
– Management by Alternatives (MbA)
Es werden mehrere Lösungsalternativen entwickelt und eine ausgewählt, das
heißt starke partizipative Führung.
– Management by Motivation (MbM)
Der Vorgesetzte versucht Bedürfnisse, Interessen, Einstellungen und persönliche Ziele der Mitarbeiter zu erkennen und diese zum Wohle des Unternehmens (oder Projektes) einzusetzen. Die Mitarbeiter sollten Spaß an der
Arbeit haben.
– Und viele weitere . . .
Es fällt auf, dass autoritäre Führungsstile gar nicht als Mb-Methoden formalisiert
wurden.
184
5.3 Druck
(vgl. DeMarco [1998], DeMarco [2001])
Tom DeMarco schlägt folgendes Gedankenexperiment vor: Wenn die Mitarbeiter
ohne Druck ihr aktuelles Projekt bis zum Zeitpunkt X fertigstellen, wie verschiebt
sich dann der Zeitpunkt, wenn man den Druck mit einem fiktiven „Druckhebel“
beliebig erhöhen kann.
Die meisten Menschen tendieren dazu, die Auswirkung von Druck folgendermaßen einzuschätzen (vgl. DeMarco [2001]):
Dauer
X
0
0
Druck
Kein Druck
außer bestehender Vertrag
und Interessae an Tätigkeit
Die unter Managern weit verbreitete Meinung ist, dass durch die Erhöhung des
Drucks der Fertigstellungstermin deutlich vorverlegt werden kann. Einen Zeitgewinn von 50% halten viele Manager für realistisch. Eine weitere Erhöhung des
Drucks soll dann zwar keinen zusätzlichen Zeitgewinn mehr mit sich bringen. Er
soll aber auch nicht schaden, solange man den Druck nicht vollkommen überzieht.
Für Menschen, die körperlich arbeiten, wie z. B. Galeerensträflinge oder Verkäufer einer Großbäckerei, mag es gelten, dass massiver Druck sie zu andauernden
Höchstleistungen anspornt. Und wenn genug Nachschub zum Ausgleich der Mitarbeiterfluktuation (Kündigung, Tod auf der Galeere etc.) vorhanden ist, mag die
Rechnung sogar aufgehen. Aber selbst Numerobis merkt schnell, dass er trotz
zahlreicher Peitschenhiebe sein Ziel nicht erreichen kann (Goscinny und Uderzo
[1968]). Uns steht ein Zaubertrank als bessere Alternative leider nicht zur Verfügung.
185
Kann diese Modell auch für Wissensarbeiter funktionieren, wenn es anscheinend
bei Sklaven so wunderbar wirkt?
Aus Sicht zahlreicher Manager sind Wissensarbeiter lediglich bessere Sklaven,
die durch Angst vor Arbeitsplatzverlust, Kürzung von Sonderzahlungen, verzögerte Karrieresprünge sowie durch (unrealistische) Zielvorgaben oder „Zielvereinbarungen“, angeordnete Überstunden etc. zu höheren Leistungen angespornt
werden können und müssen. Das funktioniert schon bei körperlicher Arbeit nur,
wenn man genügend Arbeiter hat, die bei einem „Ausfall“ sofort einspringen können. Bei Wissensarbeiten ist die Vorstellung, durch Druck bessere Arbeitsleistungen erzielen zu wollen, vollkommen abwegig. Laut Tom DeMarco gibt es einen
einfachen Grund dafür:
Leute, die unter Druck stehen, denken nicht schneller. (DeMarco
[2001])
Nachdenken kann man man nicht beschleunigen. Wer optimale Leistungen erbringen will, sollte dafür sorgen, dass er kein Multitasking
betreibt und eine Zeitlang nicht erreichbar ist. (Barbara Knab in Pilgram [2011])
Stress mache nicht erfinderisch, sagt auch der Zeitforscher Karlheinz
Geißler. „Unter Zeitdruck neigt man dazu, eher konventionelle Lösungen anzustreben“ (Pilgram [2011])
Die Anzahl der elementaren Entscheidungen pro Sekunde kann durch Druck nicht
erhöht werden. Menschen können lediglich Zeitverschwendungen vermeiden und
abends länger arbeiten. Das hat aber in gesunden Organisationen kaum Auswirkungen, da motivierte Mitarbeiter sowieso wenig Zeit verschwenden, wenn das
Management sie arbeiten lässt, und längere Arbeitszeiten lediglich eine höhere
Fehlerquote erzeugen. Fehler, die man um 2000 Uhr gemacht hat, muss man am
nächsten Tag erst einmal beseitigen, bevor man weiterarbeiten kann, oder sie stören den Ablauf zu einem anderen ungünstigen Zeitpunkt. Wissensarbeiter leisten
im Durchschnitt an einem Zehn-Stunden-Tag absolut (und nicht nur relativ) nicht
mehr als an einem Acht-Stunden-Tag.
Tom DeMarco geht davon aus, das durch wenig Druck die Arbeitsleistung um
maximal 15% erhöht werden kann. Bei zuviel Druck konzentrieren sich die Mitarbeiter mehr auf den Druck als auf die Projektarbeit. Bei sehr viel Druck kündigen die guten und vor allem die besten Mitarbeiter. Das heißt, das Ergebnis des
des obigen Gedankenexperiments sieht eher folgendermaßen aus (vgl. DeMarco
[2001]):
186
Dauer
X
0
0
Druck
Kein Druck
außer bestehender Vertrag
und Interessae an Tätigkeit
Ganz ohne Druck arbeitet ein Mensch normalerweise sicher eher ineffizient (vgl.
Studentensyndrom, Abbildung 1.3). Realistische Meilensteine sorgen allerdings
schon für genug Druck. Und ein wenig zusätzliche Motivation kann sicher auch
nicht schaden (siehe Abschnitt 5.5).
Doch spätestens, wenn das letzte Quäntchen Ineffizienz eliminiert wurde, bewirkt
weiterer Druck das genaue Gegenteil von dem, was sich der Manager davon verspricht. Zunächst fangen die Mitarbeiter an, selbst für Ausgleich zu sorgen (vermehrt private Telefonate; vermehrtes nutzloses Surfen; Arztbesuch während der
Arbeitszeit, auch wenn dies außerhalb der Arbeitszeit möglich wäre etc.). Wächst
der Druck weiter, so folgt irgendwann die innere Kündigung und/oder die echte
Kündigung. Je besser die Mitarbeiterin ist, umso eher sieht Sie sich nach einer
neuen Stelle um. Aber es sind gerade die Besten, die ein Unternehmen halten
muss, um erfolgreich zu sein (Kanter und Zagata-Meraz [2007]). Laut einer Studie (Gallup Engagement Index 2010) der Marktforscher von Gallup in Potsdam
haben im Jahr 2010 21 % der Beschäftigten in Deutschland innerlich gekündigt,
66 % machen Dienst nach Vorschrift. Im Oktober und November 2010 wurden
insgesamt 1 920 Arbeitnehmer repräsentativ für die Arbeitnehmerschaft ab 18
Jahren befragt. „Die volkswirtschaftlichen Kosten aufgrund von innerer Kündigung belaufen sich auf eine Summe zwischen 121,8 und 125,7 Milliarden Euro
jährlich.“ Dies entspricht 11 mal dem Etat für „Bildung und Forschung“ im Jahr
2011. Die Fehlzeiten der Arbeitnehmer, die eine hohe innere Bindung an Unternehmen haben ist 21,7 % geringer als die der Arbeitnehmer ohne innere Bindung.
187
Außerdem ist deren Innovationskraft um 40,5 % höher. (Gallup [2011])
Tom DeMarco bezeichnet das erste, grundfalsche „Druckmodell“ als das Modell
eines Kindesmisshandlers. Dieser meint durch vollkommen überzogene Strafen
die Ungezogenheit der Kinder minimieren zu können. Obwohl jeder gebildete
Mensch heute wissen sollte, dass sich misshandelte Kinder schlechter benehmen
als andere Kinder, sind Misshandlungen immer noch an der Tagesordnung.
Manager, die ihre Mitarbeiter massiv unter Druck setzen, um vermeintlich mehr
Leistung zu erzielen, erreichen nur das Gegenteil und sind auch nicht viel besser
als Kindesmisshandler und peitschenschwingende Sklavenaufseher.
5.3.1 Folgen von übermäßigem Druck
– Verzögerung von Terminen (Der Mitarbeiter beschäftigt sich mehr mit der
Druckvermeidung als mit seiner Arbeit)
– Mitarbeiter kommen krank in die Arbeit, machen Fehler und stecken gesunde Kollegen an (Laut einer Studien der „Felix Burda Stiftung“ hätte eine Gesundheitsvorsorge, die vollständig über den Arbeitgeber abgewickelt
wird, weniger Ausfallzeiten, weniger Krankheitstage, mehr Motivation und
einen Image-Bonus zur Folge; News [2011])
– Burnout
– innere Kündigung
– Bildung von „Zombies“ (so nennt Tom DeMarco Mitarbeiter die keinen produktiven Beitrag mehr leisten; ich habe einmal von einem Mitarbeiter gehört,
der bei einem großen deutschen Unternehmen jahrelang ein Postwägelchen
durch die Gegend geschoben haben soll ohne je etwas von A nach B gebracht
zu haben)
– steigende Mitarbeiterfluktuation (mehr echte Kündigungen)
Die Kosten der Mitarbeiterfluktuation belaufen sich laut Gallup Engagement Index 2010 auf durchschnittlich 1.314 Euro je Mitarbeiter und Jahr an. Die Ermittlung dieser Kosten auf Basis der Umfrageergebnisse ist laut Gallup als „konservativ“ anzusehen. Sie merken an, dass andere Quellen als Fluktuationskosten pro
Mitarbeiter das doppelte der reinen Gehaltskosten und der Nebenkosten eines Jahres anführen. Gallup [2011]
5.3.2 Wie übt man Druck aus?
Es folgt eine unvollständige Liste von Möglichkeiten, Druck auszuüben:
188
– Leistungssteigerungsprogramme (wie z. B. bei Infineon, Handelsblatt
[2003])
– Ausüben von negativem Druck wie Verbreitung von Angst, z. B. indem man
jährlich die so genannten „low performer“ entlässt, wie dies z. B. unter Jack
Welch bei General Electrics üblich war (Handelsblatt [2003]); Abhilfe: Negativen Druck vollkommen vermeiden.
– Ausüben von „positivem“ Druck (so genannte Motivationsanreize), wie z.B.
Auszeichnung des Mitarbeiter des Monats, Außergewöhnliches Engagement
einzelner Mitarbeiter in Gegenwart anderer herausheben, MbO etc.(d. h. extrinsische Motivation als Ersatz für intrinsische Motivation); Abhilfe: Auf
„positiven“ Druck ebenso verzichten.
– Mitarbeitern falsche/ungeeignete/diskriminierende Aufgaben zuweisen, nur
erstklassige Leistungen gelten lassen; Abhilfe: Mitarbeiter gemäß ihren Fähigkeiten und Neigungen einsetzen.
– Management-Todsünden begehen wie Diskriminierung, Missachtung, Herabwürdigung, Lächerlich machen von Mitarbeitern, Mitarbeitern sinnlose
Extraarbeiten aufhalsen; Abhilfe: Sich auf keinen Fall zu solchen Aktionen
verleiten lassen.
– Mobbing; Abhilfe: Aktiver Kampf gegen Mobbing, Mediatoren.
– Dokumentationswahn (zum Beispiel: jede Tätigkeit muss stundengenau erfasst werden – ich habe sogar einmal erlebt, wie ein Chef eine seiner Sekretärinnen angewiesen hat, ihre Tätigkeiten minutengenau zu erfassen – dies fällt
bereits unter die Kategorie „Herabwürdigung“ oder gar „Mobbing“, wenn
diese Anweisung längerfristig aufrechterhalten wird); Abhilfe: Die Mitarbeiter lieber produktiv arbeiten lassen.
– Überstunden; Abhilfe: Überstunden vermeiden, wann immer dies möglich
ist (sie bringen sowieso nichts, Abschnitt 3.5)
– Unnötige Parallelarbeit durch Mitarbeiter; Abhilfe: Resource Leveling.
– Fixe Termine; Abhilfe: keine fixen Termine, sondern 50%-Termine – in 50
Prozent der Fälle sollte der Vorgang schneller erledigt werden und in 50
Prozent der Fälle langsamer.
– Scheintermine oder sich über scheinbare Zeitvergeudung ereifern (noch
schlimmer als fixe Termine); Abhilfe: Darauf verzichten.
– Selbst mit gutem Beispiel vorangehen (immer der erste sein, der kommt, und
der letzte, der geht), um zu zeigen, was von den Mitarbeitern erwartet wird;
Abhilfe: Darauf verzichten.
– Kommunikationsoverhead; Abhilfe: Einzelne Aufgaben möglichst von klei189
nen Teams bearbeiten lassen, Kommunikationsbedarf zwischen den verschiedenen Teams gering halten, gute Kommunikationsplattformen einsetzen, keine Massenmeetings.
– Bürokratie; Abhilfe: Bürokratie vermindern (z. B. sollte sich jeder Mitarbeiter Büromaterial aus einem Schrank nehmen können ohne vorher ein Formular ausfüllen und die Unterschrift zweier Bevollmächtigter einholen zu
müssen).
5.4 Teamarbeit
Dieser Abschnitt muss überarbeitet werden.
Teamarbeit ist die ausgeprägteste Form der Gruppenarbeit. Sie hat viele Vorteile (wie hoher Problemlösungsgrad und gegenseitige Anregung und Verstärkung).
Allerdings gibt es auch Nachteile (wie hoher Kommunikationsaufwand, Konkurrenzdenken und Informationsfülle).
Förderung der Teambildung
DeMarco und Lister [1991]
– Team auf ein gemeinsames Ziel ausrichten
– Team zum Erfolg verhelfen
– Elitegefühl stärken
– Qualität zum Kult machen!
– Vielfalt ins Team bringen
– nur Strategien, nicht aber Taktiken zur Erfüllung der Strategien vorgeben
– „Never change a winning team“
Verhinderung der Teambildung
DeMarco und Lister [1991]
– Kontrolle statt Vertrauen und Autonomie
– Bürokratie
– räumliche Trennung statt räumlicher Nähe
– gleichzeitige Mitarbeit in mehreren Teams
– Scheintermine, d. h. nicht-einhaltbare Termine
190
5.5 Motivation
(vgl. Kupper [1993])
Einer der wichtigsten Erfolgsfaktoren für Team- und/oder Projektarbeit ist die
Motivation von Mitarbeitern (siehe MbM).
Man unterscheidet dabei zwischen intrinsischer und extrinsischer Motivation.
Wenn ein Mitarbeiter intrinsisch motiviert ist, erledigt er seine Arbeit aus eigenem Antrieb heraus, weil er an der Arbeit Interesse und auch Spaß hat. Ist er
hingegen extrinsich motiviert, so erledigt er seine Arbeit aufgrund äußerer Gründe, um z. B. Geld zum Leben zu verdienen oder um unangenehme Konsequenzen
zu vermeiden.
Obwohl intrinsisch motivierte Mitarbeiter i. Allg. wesentlich bessere Arbeitsergebnisse liefern, setzen die meisten Manager auf extrinsische Motivationsanreize
(mehr Geld, Statussymbole, Leistungsvereinbarungen, mehr Druck etc.).
Ein typisches Beispiel für einen intrinsisch motivierten Mitarbeiter ist der Basketballprofi Dirk Nowitzki. Bereits im Jahr 2008 kündigte er an, dass er zugunsten
von attraktiven Neuverpflichtungen auf einen Teil seines Gehaltes verzichten würde. sid [2008] Im Juli 2010 machte er seine Ankündigung wahr. Pausch [2011]
These 1 (von Kupper [1993])
Motivationstheorien wurden entwickelt um von Mitarbeitern ein Maximum an
Leistung zu erhalten.
Man muss Motivation und Manipulation unterscheiden:
– Motivation heißt, die Wünsche der Mitarbeiter zu fördern.
– Manipulation heißt, die eigenen Wünsche den Mitarbeitern aufzuzwingen.
Die Grenze zwischen Motivation und Manipulation ist fließend. Man sollte dennoch versuchen, sie nicht zu überschreiten.
5.5.1 Wie kann man Motivation erkennen?
von Rosenstiel und Lutz zeigen drei Wege auf, um die Grundmotivation von Mitarbeitern festzustellen (von Rosenstiel und Lutz [1974]):
Die Introspektion
Der Mensch versucht die Motive seines Handelns selber zu analysieren („Warum
rauche ich?", „Warum mag ich Kollegin Meyer nicht?“).
191
Die Introspektion hat zwei Nachteile: Zum einen ist es oft schwer die wirklichen
Gründe für sein eigenes Verhalten zu ergründen (man lügt sich selbst an oder weiß
es einfach nicht besser) und zum anderen teilt man die echten Gründe anderen –
insbesondere seinem Chef – oft nur ungern mit („Ich muss zur Elternversammlung.“ anstelle von „Ich habe diese Woche schon zweimal bis in die Nacht hinein
gearbeitet.“).
Abhilfe für das zweite Problem: starke Vertrauensbasis zwischen Vorgesetzten
und Untergebenen und am besten auch zwischen Kollegen; Ehrlichkeit und Offenheit des Vorgesetzten.
Die Fremdbeobachtung
Die Fremdbeobachtung (Vorgesetzter beobachtet Mitarbeiter etc.) ist ebenso
schwer wie die Introspektion. („Frau Huber arbeitet sehr produktiv. Sie identifiziert sich also mit dem Projekt.“ In Wirklichkeit will sie dem Chef der Nachbarabteilung imponieren, damit sie in ein weniger chaotisches Projekt wechseln
kann.)
Analyse von Verhaltensergebnisse
Hier werden nicht Verhaltensweisen direkt, sondern Ergebnisse von Verhaltensweisen analysiert. Es gehört viel detektivisches Gespür dazu, daraus die richtigen
Schlüsse zu ziehen. (Herr Franz ist hinter seinem Plan zurück. Sie kommen ein-,
zweimal unverhofft zu seinem Arbeitsplatz – und dieser ist leer. Schlussfolgerung:
Herr Franz fehlt öfter ⇒ Zeitprobleme. Später erfahren Sie, dass es unvermutete
Probleme gab, die Franz mit einer Kollegin der Nachbarabteilung zu lösen versuchte.)
5.5.2 Motivationstheorien
Da die Motivation von Mitarbeitern nur sehr schwer zu analysieren ist, wurden
mehrere Motivationstheorien aufgestellt.
Dynamische Motivationstheorie
Die dynamische Motivationstheorie, die 1943 von Abraham Maslow begründet
wurde (Maslow [1943], Abbildung 5.1), geht davon aus, dass die Bedürfnisse des
Menschen in Schichten eingeteilt sind. Solange die Bedürfnisse einer niedrigeren
Schicht nicht erfüllt sind, macht es keinen Sinn, die Bedürfnisse einer höheren
Schicht zu erfüllen (z. B., um ihn oder sie zu motivieren).
192
1. Physiologisch bedingte Bedürfnisse (Grundbedürfnisse)
Hunger, Durst, Schlaf, Sexualtrieb etc.
meist erfüllt (ausreichende Bezahlung, gesunder Arbeitsplatz – aber sexuelle
Belästigungen am Arbeitsplatz)
2. Sicherheitsbedürfnisse
Bedürfnisse, um langfristig die Bedürfnisse der ersten Schicht zu befriedigen
meist erfüllt (Kündigungsschutz, Weiterbildung, Altersversorgung – aber derzeit gefährdet ⇒ großer „Motivations“druck auf Arbeitnehmer)
3. Soziale Bedürfnisse oder Kontaktbedürfnisse
Bedürfnisse nach Zugehörigkeit, Zusammenhalt, Gruppenintegration, Liebe
usw.
meist erfüllt (Teamarbeit, Gruppenbildung, Information – aber Mobbing)
4. Ichbezogene Bedürfnisse
Streben nach Achtung, Prestige, Wertschätzung, Status, (sozialem) Erfolg
gegenwärtiger Ansatz zur Motivation der Mitarbeiter (Status-Symbole, Bezahlung, Beförderung)
5. Bedürfnisse nach Selbstverwirklichung (etwas schwammig)
Streben nach freier Entfaltung, Erprobung der Fähigkeiten in allen Bereichen
des Lebens
Viele streben danach (Einfluss, Macht, Vollmacht) – aber der Weg dorthin
führt über „Leichen“
Abbildung 5.1: Maslowsche Bedürfnispyramide
Zwei-Faktoren-Theorie
Die so genannte Zwei-Faktoren-Theorie oder Motivation-Maintenance-Theorie
von Frederick Herzberg, Bernard Mausner und Barbara Synderman (Herzberg
et al. [1959]) resultiert aus der Befragung tausender von Mitarbeitern unterschiedlicher Unternehmen.
193
Dabei wird zwischen Hygienefaktoren (Dissatisfier) und Motivationsfaktoren (Satisfier) unterschieden. Die Erfüllung von Hygienefaktoren wird von den Mitarbeitern erwartet. Ein Fehlen schafft schlechte Arbeitsbedingungen, Unzufriedenheit
etc. Die Erfüllung von Motivationsfaktoren ist dagegen die Ursache für Zufriedenheit, positive Einstellungen, überdurchschnittliche Leistungen etc.
Beispiele für Dissatisfier
– Arbeitsbedingungen
– Einkommen (Gehalt, Entlohnung)
– Sicherheit
– Einfluss auf Privatleben
– Beziehungen zu Kollegen und Vorgesetzten
– Firmenpolitik
– Führungsstil, Arbeitsbedingungen
Beispiele für Satisfier
– die Tätigkeit selbst (sie macht Spaß)
– Achtung und Anerkennung
– Leistungs- und Erfolgserlebnisse
– Aufstiegschancen
– Wachstum
These 2 (von Kupper [1993])
Motivationstheorien sind in der Praxis oft zum Scheitern verurteilt, da sie nur
Statistiken, nicht aber Individuen berücksichtigen.
Beispiele
Es gibt Mitarbeiter, denen sind Freizeit und Freiheit wichtiger als Einkommen und
Status.
Es gibt Hungerstreikende, die ignorieren Bedürfnisse der ersten Schicht zur Erfüllung von Bedürfnissen einer höheren Schicht. Ein Beispiel dafür ist der Hungerstreik, der z. B. von Mahatma Ghandi sehr erfolgreich eingesetzt wurde, um die
englische Vorherrschaft in Indien zu beenden.
Es gibt Mitarbeiter, die Angst vor eigenen Entscheidungen haben und sich nur
unter permanenter Kontrolle wohl fühlen.
194
5.6 Individualpsychologischer Ansatz
(vgl. Kupper [1993])
Bessere Ergebnisse als die Motivationstheorien versprechen Erkenntnisse der Individualpsychologie, die von Alfred Adler 1907 begründet wurde (Adler [1907]).
Als Projektleiter müssen sie kein Diplompsychologe sein, ein wenig Basiswissen schadet dagegen nichts. Sie sollten in der Lage sein, sich in die Psyche Ihrer
Mitarbeiter hineinzuversetzen, sie zu verstehen, mit ihnen zu fühlen.
Nahziele und Grundmotivation
Jeder Mensch hat seinen spezifischen Lebensstil. Dieser ist im wesentlichen durch
folgende Fragen zu charakterisieren:
– Wie sieht er sich selbst?
– Wie sieht er die anderen?
– Wie sieht er die Welt?
– Welchen Bezug hat er zur Gemeinschaft?
– Was will er erreichen (Selbstwert, Lebensziel)?
– Wie will er sein Lebensziel erreichen bzw. seinen Selbstwert steigern
(Nahziele)?
Die Nahziele eines Menschen geraten oft mit den (Nah-)Zielen und Rechten anderer Menschen in Konflikt. Es können fünf Nahziele identifiziert werden, unter
denen Fehlverhalten und -handlungen eines Menschen ablaufen. Diese Nahziele
laufen bei jeweiligem Misserfolg häufig nacheinander ab:
1. Entschuldigung für eigene Mängel
2. Aufmerksamkeit erregen
3. Machtkampf
4. Rache
5. Resignation
Entschuldigung für eigene Mängel
Der Mitarbeiter ist auf sich fixiert. Er versucht seine Fehler auf andere oder „die
Umwelt“ abzuwälzen.
Beispiel
„Ich konnte das nicht erledigen, weil mein Rechner defekt war.“ Aber der Rechner
von Kollege Meyer war frei und geeignet.
195
Regelmäßige Krankheit bei wichtigen Terminen (psychische Probleme drücken
sich in somatischen Problemen aus). „Ich konnte das nicht erledigen, da ich ja
krank war.“
Aufmerksamkeit erregen
Der Mitarbeiter will durch seine Handlungen oder sein Verhalten Aufmerksamkeit
erregen und damit sein Selbstwertgefühl steigern.
Beispiele
Das „Fahrradfahrersyndrom“: nach oben buckeln, nach unten treten.
Ein ehemals zuverlässiger Mitarbeiter fängt an, viele Fehler zu machen oder ständig zu wiedersprechen.
Um derartige Verhaltensweisen zu interpretieren, sollte man sich fragen: „Was
passiert, wenn der Mitarbeiter viele Fehler macht?“ – Er wird zum Chef zitiert. –
„Und dann?“ – Der Chef unterhält sich länger mit ihm. Aha: Er hat Aufmerksamkeit gesucht und gefunden ⇒ Steigerung der Selbstwertgefühls. „Warum sucht er
Aufmerksamkeit? Wurde er benachteiligt, zu wenig beachtet etc.?“
Machtkampf
Wenn Auffälligkeiten zur Steigerung des Selbstwert(gefühl)s nicht ausreichen,
greifen viele Menschen zu stärkeren Mitteln. Ein Machtkampf beginnt.
Beispiele
Der Chef ist penibel (ein Technokrat), der Mitarbeiter eher lax (ein Künstler). Der
Chef verlangt mehr Sorgfalt, der Mitarbeiter reagiert mit Dienst nach Vorschrift.
Der Machtkampf kann auch in Aufgabenverweigerung gipfeln (wichtige Unterlagen werden nicht weitergereicht, Daten gelöscht etc.), um zu beweisen, dass man
unabkömmlich ist. Dieser Beweis dient wiederum der Hebung des Selbstwertgefühls („Ohne mich geht es nicht!“).
Rache
Ein Mitarbeiter, der einen Machtkampf verloren hat, greift oft zum Mittel der
Rache.
Beispiele
Ein Sohn bricht alle Ausbildungen ab, die sein Vater finanziert (da er nicht studieren durfte, da er dann gesellschaftlich besser gestellt wäre als sein Vater) und liegt
dem Vater mit 35 Jahren noch auf der Tasche.
Ein Mitarbeiter verpatzt eine Demo (z. B. Absturz mit blauem Bildschirm bei der
Windows 98-Präsentation), um seinem Chef schwer zu schaden.
196
Resignation
Wenn auch Rache nichts mehr hilft, resigniert ein Mensch meist. Er arbeitet nicht
mehr zum Nutzen des Unternehmens, sondern sitzt nur noch seine Zeit ab.
Beispiele
„Unfähige“ Abteilungsleiter werden auf Posten ohne Aufgabengebiet abgeschoben, Mitarbeiter werden in der Planung nicht mehr berücksichtigt und/oder erhalten überflüssige Aufgaben usw.
5.7 Die Wechselbeziehungen im Verhalten von Chef
und Mitarbeiter
fehlt
197
198
Kapitel 6
Dokumentation
6.1 Einführung
Es gibt viele Standards zu diesem Thema: IEEE Dokumentationsstandard, DIN
66230, 66231 und 66233, VDI 3550.
In der Praxis gibt es dagegen nur selten eine gute Dokumentation.
Zwei typische Arten von schlechter Dokumentation:
– zu oberflächlich: nur grobe Diagramme etc.
– zu detailliert: tausende von Seiten Text (SQL3-Standard)
Außerdem gibt es noch weitere wesentliche Probleme:
– Dokumentation und Realität weichen oft stark von einander ab
– gruppenspezifische Terminologie ist von Dritten nicht zu verstehen
Hauptgründe für schlechte Dokumentationen:
– Mitarbeiter, die nicht dokumentieren, glauben, sie seien dadurch unentbehrlich
– Projektleiter behandeln die Dokumentation zweitrangig
– Projekte geraten fast immer in Zeitdruck ⇒ Abstriche an Dokumentation
– Informatiker können kein Deutsch/Englisch bzw. können sich nicht allgemeinverständlich ausdrücken
(Microsoft stellt zum Übersetzen der englischen Texte und Button/Menu-Bezeichner Germanisten und keine Informatiker ein)
6.2 Welche Arten von Dokumentation sind brauchbar?
Es gibt wenig Erfahrungsmaterial.
1983 veröffentlichte Guimares eine Untersuchung, bei der Personen, die Software
zu ändern und zu warten hatten, nach der Nützlichkeit der ihnen übergebenen
Dokumentation befragt wurden (Guimares [1983]).
199
Ergebnis
wichtigste Dokumentation: (kommentiertes) Programmlisting
wichtige Dokumentation:
verbale Beschreibungen, Systemflusspläne,
Input/Output-Layout
unwichtige Dokumentation: Programmflusspläne (klar, da zu detailliert)
Pseudocode (unklar, war wohl meist sehr schlecht)
6.3 Regeln für gute Kommentare
Programmkommentare sollten andere Programmierer in die Lage versetzen, ein
Programm zu warten und weiterzuentwickeln.
– Kommentare sollten kurz, aber prägnant sein.
– Trivialkommentare sind zu vermeiden.
Gegenbeispiel:
I = I+1 // I wird um 1 erhöht
– Aussagekräftige Namen machen viele Kommentare überflüssig (da sie selbst
als Kommentare dienen).
Beispiel:
AnzahlButtonClicks = AnzahlButtonClicks + 1
anstelle von
B = B+1
– Der Zweck jeder Klasse, Methode, Funktion, Prozedur etc. sollte beschrieben
werden.
– Methodenparameter und Attribute sollten beschrieben werden, wenn sie
nicht selbsterklärend sind (aussagekräftige Namen!).
– Programme sollten lesbar sein:
sinnvolle Einrückungen und Leerzeilen; Strukturierung des Quelltextes
durch Unterteilung in Hauptkommentare, unter Kommentare, Anmerkungen
etc.
– Inline-Dokumentation am besten unter Zuhilfenahme von automatischen
Dokumentations-Tools (Javadoc, ASDoc, Eiffel, LATEX, Spezialsoftware –
evtl. auch selbst geschrieben) ist einer separaten Dokumentation vorzuziehen.
Grund: Die Dokumentation kann relativ einfach und sollte auch stets aktuell
gehalten werden.
– Am Anfang jeder Datei sollten Verwaltungsinformationen stehen:
200
•
•
•
•
•
•
•
•
•
•
Programmname
Modulname
Autor(en)
Versionsnummer (Release, Level)
Status mit Datum (geplant, in Bearbeitung, freigegeben etc.)
Aufgabe (kurze Beschreibung)
Komplexität (O-Notation)
wesentliche Designentscheidungen
wesentliche Änderungen
etc.
– Englischsprachige Kommentare sind oft vorteilhaft:
• ausländische Projektpartner und Mitarbeiter verstehen den Code ebenfalls
• Hilfestellungen durch andere Internetbenutzer ist einfacher
• Umlaute bereiten keine Probleme (gilt auch für Variablen- und Methodennamen)
201
202
Literatur
A. Adler [1907]:
Studie über Minderwertigkeit von Organen, Urban & und Schwarzenberg, http://www.archive.org/stream/
studieberminder00adlegoog, Berlin, Wien
R. Albin [2010]: Der große Prostata-Irrtum – Ein beliebter Tumortest ist in Wahrheit eine Katastrophe für das Gesundheitssystem, Süddeutsche Zeitung, Seite 16, 12. März 2010
A. J. Albrecht [1979]: Measuring application development productivity, Proceedings of the IBM Applications Development Symposium, Seiten 83–92
R. D. Austin [1996]: Measuring and Managing Performance in Organizations,
Dorset House
AZ [2006]: Managementfehler häufigste Insolvenzursache, Augsburger Allgemeine, Jahrgang 2006, 27. September 2006
H. Balzert [1998]: Lehrbuch der Software-Technik – Software-Management,
Software-Qualitätssicherung, Unternehmensmodellierung, Band 2, Spektrum
Akademischer Verlag GmbH, Heidelberg - Berlin
K. Beck [2000]: Extreme Programming - Das Manifest, Band 2, Addison-Wesley
H. Berghel [1998]: The year-2000 problem and the new riddle of induction, Communications of the ACM, Jahrgang 41, Seiten 13–17, März 1998
Beta-Verteilung
[2006]:
Beta-Verteilung,
hs-augsburg.de/Beta-Verteilung
http://glossar.
S. Biskamp [1998]: Jahr-2000-Tools gezielt eingesetzt, InformationWeek, Jahrgang 1–2, Seiten 34–35, Januar 1998
S. Biskamp, H. Kunisch-Holtz [1998]: Beim Datumsprojekt sind Extreme gefragt,
InformationWeek, Jahrgang 1–2, Seiten 30–31, Januar 1998
Biz/ed [2006]:
Cash Flow simulation, www.bized.ac.uk/learn/
business/accounting/cashflow/simulation/negative.
htm, 18. Dezember 2006
B. W. Boehm [1981]: Software Engineering Economics, Prentice Hall
B. W. Boehm [1988]: A spiral model of software development and enhancement,
IEEE Computer, Jahrgang 21, Nr. 5, Seiten 61–72, Mai 1988
B. W. Boehm, E. Horowitz, R. Madachy, D. Reifer, B. K. Clark, B. Steece, A. W.
Brown, S. Chulani, C. Abtsm [2000]: Software Cost Estimation with COCO203
MO II, Prentice Hall
D. Borchers [2004]: Verursacherbedingt verspätet, c’t Magazin für Computertechnik, Jahrgang 2004, Nr. 22, Seiten 92–97
D. Bouyssou, D. Vanderpooten [2011]: Bernard Roy – From Graph Theory to
Multiple Criteria, In: Profiles in Operations Research (Hg. A. A. Assad, S. I.
Gass), International Series in Operations Research & Management Science„
chap. 42, Springer-Verlag GmbH, Heidelberg, 1. Ausgabe
C. Briseño [2011]:
Prostatakrebs – USA schaffen umstrittenen Prostata-Test ab, http://www.spiegel.de/wissenschaft/medizin/
0,1518,790439,00.html, 07. Oktober 2011
Brockhaus [1991a]: Brockhaus-Enzyklopädie – Nos-Per, Band 16, F.A. Brockhaus
GmbH, Mannheim
Brockhaus [1991b]: Brockhaus-Enzyklopädie – Pes-Rac, Band 17, F.A. Brockhaus GmbH, Mannheim
I. Bronstein, K. Semendjajew [1980]: Taschenbuch der Mathematik, F.A. Brockhaus GmbH, Leipzig
F. Brooks [1986]: No silver bullet - essence and accident in software engineering, Proceedings of the IFIP Tenth World Computing Conference, Seiten
1069–1076
C. Buchholz [2003]: Was die Maut-Misere wirklich kostet, manager-magazin.de,
19. September 2003
Bundesrepublik Deutschland [2004]: V-Modellr XT, ftp://ftp.uni-kl.
de/pub/v-modell-xt/Release-1.0/Dokumentation/pdf/V_
Modell_XT_v1_0.pdf
M. Burghardt [1995]: Projektmanagement – Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsvorhaben, Publicidis MCD, München/Erlangen, 3. Ausgabe
R. L. Cole [1988]: Parallel merge sort, Siam Journal on Computing, Jahrgang 17,
Seiten 770–785
Cost Xpert [2011a]: Cost Xpert Tool Suite, http://www.costxpert.com/
de/expertise/produkt/cost_xpert_tool_suite
Cost Xpert [2011b]: Wie genau sind die Schätzungen mit der IME?, http:
//www.costxpert.eu/de/support_download/faqs
M. Cusumano, R. Selby [1997]: How Microsoft builds software, Communications
of the ACM, Jahrgang 40, Nr. 6, Seiten 53–61, Juni 1997
T. DeMarco [1998]: Der Termin, Carl Hanser Verlag, München
204
T. DeMarco [2001]: Spielräume, Carl Hanser Verlag, München
T. DeMarco, T. Lister [1985]: Programmer performance and the effects of the
workplace, In: Proceedings of the 8th international conference on Software engineering, ICSE ’85, Seiten 268–272, Los Alamitos, CA, USA, IEEE
Computer Society Press
T. DeMarco, T. Lister [1991]: Wien wartet auf Dich! Der Faktor Mensch im
DV-Management, Carl Hanser Verlag, München
T. DeMarco, T. Lister [2003]: Bärentango, Carl Hanser Verlag, München
W. E. Deming [1986, 2000]: Out of the Crisis, MIT Press
DGVU
[2010]:
Irrglaube
Multitasking,
http://www.
arbeit-und-gesundheit.de/webcom/show_article.php/
_c-676/_nr-3/i.html, Oktober 2010
dpa [2005]: Die „Soda-Brücke“ von Rödental, Süddeutsche Zeitung, Jahrgang
2005, 18. Juli 2005
dpa [2006]: Zwei Drittel der Manager machen sinnlose Reisen, Süddeutsche Zeitung, Jahrgang 2006, Nr. 272, Seiten V2/11, 25./26. November 2006
Dreiecksverteilung [2006]:
Dreiecksverteilung,
hs-augsburg.de/Dreiecksverteilung
http://glossar.
H.-H. Dubben, H.-P. Beck-Bornholdt [2010]: Der Hund der Eier legt – Erkennen
von Fehlinformation durch Querdenken, Rowohlt Taschenbuch Verlag, Reinbeck bei Hamburg, 5. Ausgabe
Eiffelturm [2006]:
The official site of the Eiffel Tower, http:
//www.tour-eiffel.fr/teiffel/uk/documentation/
stucture/page/chiffres.html
P. F. Elzer [1994]: Management von Softwareprojekten, Friedr. Vieweg & Sohn
Verlagsgesellschagt mbH
Fremdwörterduden [2001]: Duden – Das Fremdwörterbuch, Band 5, Dudenverlag, Mannheim, Leipzig, Wien, Zürich, 7. Ausgabe
Gallup [2011]:
Gallup Engagement Index, http://eu.gallup.com/
Berlin/118645/Gallup-Engagement-Index.aspx
H. L. Gantt [1913]: Work, wages, and profits, Engineering Magazine Co., 2. Ausgabe
P. Gartner [1999]: Die Drei-Punkt-Schätzmethode zur Kalkulation des Projektaufwands, Projektmanagement, Jahrgang 1999, Nr. 4, Seiten 33–37
W. Gellert, H. Kästner (Hg.) [1979]: Lexikon der Mathematik, VEB Bibliographisches Institut Leipzig, Leipzig, 2. Ausgabe
205
E. M. Goldratt [2002]: Die Kritische Kette – Das neue Konzept im Projektmanagement, Campus Verlag, Frankfurt, New York, August 2002
E. M. Goldratt [2003]: Das Ziel – Teil II, Campus Verlag, Frankfurt, New York
E. M. Goldratt, J. Cox [2002]: Das Ziel – Ein Roman über Prozessoptimierung,
Campus Verlag, 3. Ausgabe
Goscinny, Uderzo [1968]: Asterix und Kleopatra, Delta Verlag GmbH, Stuttgart
R. Grady [1992]: Practical Software Metrics for Project Management and Process
Improvement, Prentice-Hall International Inc., Englewood Cliffs, New Jersey
F. E. Grubbs [1962]: Attempts to validate certain PERT statistics or ’picking on
PERT’, Operations Research, Jahrgang 10, Nr. 6, Seiten 912–915
T. Guimares [1983]: Managing application program maintanance expenditures,
Communications of the ACM, Jahrgang 26, Nr. 10, Seiten 739–746, Oktober 1983
U. Gulba [2004]: Vabanque – Vermeidung von Risiken in IT-Projekten, iX Magazin für professionelle Informationstechnik, Jahrgang 2004, Nr. 6, Seiten
98–100
Handelsblatt [2003]:
Zuckerbrot und Peitsche, http://www.
handelsblatt.com/unternehmen/management/strategie/
zuckerbrot-und-peitsche/2273054.html, 16. September 2003
F. Herzberg, B. Mausner, B. B. Snyderman [1959]: The Motivation to Work, Wiley, New York
M. Hoffmeyer [2006]: Gerangel um das große Ganze, Süddeutsche Zeitung, Jahrgang 2006, Nr. 149, Seiten 147
IBM [2011]: IBM Rational Unified Process (RUP), http://www-01.ibm.
com/software/awdtools/rup/, 9. Mai 2011
ISO/IEC 20926:2009 [2009]: Software and systems engineering – Software measurement – IFPUG functional size measurement method, International Organization for Standardization, Genf
I. Jacobson, G. Booch, J. Rumbaugh [1999]: The unified software development
process, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA
W. Jakoby [2010]: Projektmanagement für Ingenieure, Vieweg + Teubner Verlag
B. Jann [2005]: Einführüng in di Statistik, Oldenbourg Wissenschaftsverlag, Oldenburg, http://books.google.de/books?id=vfo6Mrurw3IC
I. Jansen, G. Neumann [1997]: Abenteuerlustig ins nächste Jahrtausend, InformationWeek, Jahrgang 3, Seiten 36–38, Juli 1997
M. Kanter, S. Zagata-Meraz [2007]: Hewitt Associates’ research shows impact
206
that pivotal employees have on business results, press release: http://
www.hewittassociates.com/Intl/NA/en-US/AboutHewitt/
Newsroom/PressReleaseDetail.aspx?cid=3411, 08. 01 2007
J. E. Kelley, M. R. Walker [1959]: Critical-path planning and scheduling, In:
Papers presented at the December 1-3, 1959, eastern joint IRE-AIEE-ACM
computer conference, IRE-AIEE-ACM ’59 (Eastern), Seiten 160–173, New
York, NY, USA, ACM
H. Kellner [2001]: Die Kunst, DV-Projekte zum Erfolg zu führen, Carl Hanser
Verlag, 2. Ausgabe
Klein, Vikas, Zehetner [2005]: Projektmanagement: Mit der Critical-ChainMethode die Projektlaufzeit entscheidend verkürzen, Der Controlling-Berater, Hauffe, http://www.brainguide.de/data/publications/
PDF/pub49181.pdf, Jahrgang 1, Seiten 45 –70
D. E. Knuth [1997]: The Art of Computer Programming, Band 3, Addison Wesley
Longman, Inc., Amsterdam, 2. Ausgabe
H. Kuchling [1976]: Physik, Nachschlagebücher für Grundlagenfächer, VEB
Fachbuchverlag Leipzig, Leipzig, 13. Ausgabe
H. Kunisch-Holtz [1998]: Die Komplettlösung als Dienstleistung, InformationWeek, Jahrgang 1–2, Seiten 32–33, Januar 1998
H. Kupper [1993]: Zur Kunst der Projektsteuerung, R. Oldenbourg Verlag
L. P. Leach [2005]: Critical Chain Project Management, Artech House, 2. Ausgabe
K. Lewin, R. Lippitt, R. White [1993]: Patterns of aggressive behavior in
experimentally created, Journal of Social Psychology, http://books.
google.co.uk/books?id=vdvXOxzbiNwC&pg=PA200,
Oktober 1993
D. G. Malcolm, J. H. Roseboom, C. E. Clark, W. Fazar [1959]: Application of
a technique for research and development program evaluation, Operations
Research, Jahrgang 7, Seiten 646–670, September/Oktober 1959
manager-magazin [2003]:
ber 2003
Stolpe(r)gefahr, manager-magazin.de, 8. Septem-
A. H. Maslow [1943]: A Theory of Human Motivation, Psychological Review,
Jahrgang 50
Microsoft [1999a]: MS Windows 95 Year 2000 Update, http://technet.
microsoft.com/de-at/library/cc751503(en-us).aspx#
XSLTsection127121120120
Microsoft [1999b]: Windows 95 Jahr 2000 Kompatibilität, http://www-pc.
207
uni-regensburg.de/systemsw/win95/y2k.htm, 08. Juni 1999
R. W. Miller [1963]: Schedule, Cost and Profit Control with PERT – A comprehensive Guide for Program Management, MacGraw-Hill Book Company,
Inc., New York
S. N. Mohanty [1981]: Software cost estimation: Present and future, Software
Practice and Experience, Jahrgang 11, Nr. 2, Seiten 103–121
E. A. Nekolla, J. Griebel, G. Brix [2005]: Einführung eines Mammographiescreeningprogramms in Deutschland – Erwägungen zu Nutzen und Risiko,
Radiologie, Jahrgang 45, Seiten 245–254
G. Neumann [1999]: Inkompatibel, IT-Anbieter verstehen ihre Kunden nicht, InformationWeek, Seiten 36–46, Juli 1999
B.
News
[2011]:
Erfolgsfaktor
betrieblich
Prävention,
http://www.burda-news.de/content/
erfolgsfaktor-betriebliche-praevention, 31. Mai 2011
J. K. Obermaier [1993]: Effiziente Speicherverwaltung für Datenbanksysteme auf
Parallelrechnern, Technische Universität München, Dissertation
B. Oestreich, C. Weiss [2008]: APM – Agiles Projektmanagement, dpunkt.verlag,
Heidelberg
V. Oyen, H. B. Schlegel [1986]: Projektmanagement heute, Gabal, Gesellschaft
zur Förderung Anwendungsorientierter Betriebswirtschaft und Aktiver Lernmethoden in Fachhochschule und Praxis e.V.
C. N. Parkinson [1955]: Parkinson’s Law, The Economist, http://www.
economist.com/node/14116121?story_id=14116121, http:
//www.berglas.org/Articles/parkinsons_law.pdf, November 1955
S. Pausch [2011]: Gehaltsverzicht – NBA wittert Verschwörung, Berliner Morgenpost, 15. Juli 2011
J. Pilgram [2011]: Hallo Chef, was gibt’s?, Süddeutsche Zeitung, Jahrgang 2011,
Nr. 156, Seiten V2/9, 9. Juli 2011
P. Pitcher [1997]: Das Führungsdrama; Künstler, Handwerker und Technokraten
im Management, Klett-Cotta, Stuttgart
PTC [2011]: Mathcad, http://www.ptc.com/products/mathcad/,
13. Mai 2011
QUELLE FEHLT [????]: Die Quellen-Angabe fehlt im Skript noch
H. Rinne [2003]: Handbuch der Statistik, Verlag Hatti Deutsch, 3. Ausgabe
W. W. Royce [1970]: Managing the development of large software systems, ProDraft (4. Oktober 2012)
208
ceedings of IEEE Wescon, August 1970
J. Rubner [1990]: Wissenschaftler – die Hilfsarbeiter der Industrie, Süddeutsche
Zeitung, Jahrgang 1990, Nr. 84
Schattenmacher [2004]: Der Schattenmacher, DVD ASIN: B0002DSPRK
S. Scheytt [1998]: Endstation Grössenwahn, ZUG – Für Menschen unterwegs
(Deutsche Bahn), Seiten 42–46, Februar 1998
W. J. Schmidt (Hg.) [2003]: TRAINPLAN – Führungstraining – Kompetent führen, delegieren und motivieren (CD-ROM), Schmitt Wirtschaftsberatungsgesellschaft, Wien, 2.0. Ausgabe
K. Schwaber [2004]: Agile Project Management with Scrum, Microsoft-Press
S. Seibert [2005]: „Wir wollten ein Schätztool, das die Kunden-Lieferanten-Zusammenarbeit unterstützt“ – Interview mit Barry Boehm, Projekt Management aktuell, Jahrgang 2005, Nr. 1, Seiten 9–13
sid [2008]: Gehaltsverzicht für den Meistertitel, n24, 25. Dezember 2008
H. Sneed [1987]: Software-Management, Müller GmbH, Köln
Statistik [2006]: Statistik, http://pm.hs-augsburg.de/statistik
O. Steeger [2005]: „Ruhe bitte! Hier arbeitet die ‘kritische Kette’!“, projekt MANAGEMENT, Seiten 8–13, Februar 2005
A. S. Tannenbaum [2002]: Moderne Betriebssysteme, Pearson Studium, Köln, 2.
Ausgabe
U. Techt [2011]: Dr. Eliyahu Moshe Goldratt ist am 11. Juni 2011 gestorben,
http://www.toc-institute.com/news/de/2011-06-11/
Dr--Eliyahu-Moshe-Goldratt-ist-am-11--Juni-2011-gestorben,
11. Juni 2011
TOC Times [2005]: The TOC Times, http://www.goldratt.com/
toctquarterly/april2005.htm#dollardays, April 2005
V-Modellr XT Autoren [2006]: V-Modellr XT, http://v-modell.
iabg.de/dmdocuments/V-Modell-XT-Gesamt-Deutsch-V1.
3.pdf
von Rosenstiel, Lutz [1974]: Motivation im Betrieb, Goldman, München
Wasserfall-Modell
[2005]:
Projektmagazin,
projektmagazin.de/glossar/gl-0825.html
http://www.
Wikipedia [2006a]:
No Silver Bullet – Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=No_
Silver_Bullet&oldid=75515227, 21. September 2006
209
Wikipedia [2006b]:
Soda-Brücke – Wikipedia, Die freie Enzyklopädie,
http://de.wikipedia.org/w/index.php?title=Soda-Br%
C3%BCcke&oldid=20113538, 21. September 2006
Wikipedia [2006c]:
Steckmodul – Wikipedia, Die freie Enzyklopädie,
http://de.wikipedia.org/w/index.php?title=
Steckmodul&oldid=19369965, 19. September 2006
Wikipedia [2011a]:
Critical-Chain-Projektmanagement — Wikipedia, Die
freie
Enzyklopädie,
http://de.wikipedia.org/w/index.
php?title=Critical-Chain-Projektmanagement&oldid=
89672191, 8. Juni 2011
Wikipedia [2011b]: Itztalbrücke (eisenbahn) — wikipedia, die freie enzyklopädie, //de.wikipedia.org/w/index.php?title=Itztalbr%
C3%BCcke_(Eisenbahn)&oldid=81634018, 6. Oktober 2011
Wikipedia [2011c]:
Program Evaluation and Review Technique — Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/
w/index.php?title=Program_Evaluation_and_Review_
Technique&oldid=424800741, 19. April 2011
Wikipedia [2011d]:
Unixzeit – Wikipedia, Die freie Enzyklopädie,
http://de.wikipedia.org/w/index.php?title=
Unixzeit&oldid=88176928, 05. Mai 2011
R. E. Zultner [2009]: Help on Flush with Dollar-Days?, http://finance.
groups.yahoo.com/group/cmsig/message/2299
210

Projektmanagement - Hochschule Augsburg

Transcription

Similar documents

Projektmanagement - Cosmopolitan University

Gründungsführer Berlin 2001 - Ingenieurbüro Uwe Otto, Berlin

LNA 1.Teil

OpenGl mit C++ - Thomas Cassebaum

rsync68 - ing

(VEP) in Bremen: Präsentation zum Sachstand

Volume P-250(2015)

Besprechungsprotokoll Vorstandssitzung vom 12.09.2014

Besprechungsprotokoll Vorstandssitzung vom 10.12.2013

Studierende des Fachbereichs

Wireless-N PC-Karte

Jira im PM Ticketing System im IT-Projekt Management Do’s & Don’ts

GanttProject Tutorial - htl

und Verwitterungsformen im ligurisch

Elektromobilität vor Ort aus einer Hand in der Zukunft