Projektmanagement - Wintersemester 2012/2013

Vorlesung

Projektmanagement

Wintersemester 2012/2013

Wolfgang KowarschickHochschule Augsburg

Draft (4. Oktober 2012) 2

Inhalt

1 Definitionen 7

1.1 Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1.1 Definition (von W. Kowarschick) . . . . . . . . . . . . . 8

1.1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Funktionalität und Qualität sowie strategische Ziele . . . . 13

Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.1.3 Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2.2 Aufgaben des Projektmanagements . . . . . . . . . . . . 17

1.2.3 Theory of Constraints . . . . . . . . . . . . . . . . . . . 19

1.2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 26

1.3 Projekterfolg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.4 Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.4.1 Wie vermeidet man einen Misserfolg? . . . . . . . . . . . 32

1.4.2 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . 33

1.4.3 Typische Risiken und Vorsorgemaßnahmen . . . . . . . . 34

1.5 Vergleich von Projekten mittels Euro-Tagen . . . . . . . . . . . . 40

2 Projektverlauf 45

2.1 Verschiedene Phasenmodelle . . . . . . . . . . . . . . . . . . . . 47

2.1.1 Die Spezifikationsphase: Was soll gemacht werden? . . . 48

2.1.2 Designphase (Entwurfsphase) . . . . . . . . . . . . . . . 53

2.1.3 Fertigungsphase (Entwicklung) . . . . . . . . . . . . . . 62

2.1.4 Einführungsphase . . . . . . . . . . . . . . . . . . . . . . 63

2.1.5 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.1.6 Die Nutzungs- und Aufarbeitungsphase . . . . . . . . . . 64

2.2 Wasserfall- und Spiralmodell . . . . . . . . . . . . . . . . . . . . 66

2.3 V-Modell XT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3 Draft (4. Oktober 2012)

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

3.3 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.6.1 Die Güte von Schätzverfahren . . . . . . . . . . . . . . . 104

3.7 Was ist ein Personenmonat? . . . . . . . . . . . . . . . . . . . . 107

4 Planung 113

4.1 Projektpläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.2 Grobplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.2.1 Projektstrukturplan . . . . . . . . . . . . . . . . . . . . . 115

4.3 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

4.4 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

4.5 Methode der kritischen Kette . . . . . . . . . . . . . . . . . . . . 147

4.5.1 Integrierter Puffer . . . . . . . . . . . . . . . . . . . . . . 149


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


Kapitel 1

Definitionen

Fremdwörterduden [2001]:Projekt: Plan, Unternehmung, Entwurf, Vorhabenmanagen: leiten, zustande bringen, geschickt bewerkstelligen, organisieren

Brockhaus [1991b]:Projekt (lat. proiectum „das nach vorn Geworfene“):geplante oder bereits begonnene Unternehmung, VorhabenProjektmanagement:Gesamtheit der Planungs-, Leitungs- und Kontrollaktivitäten, die bei zeitlichbefristeten 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 DruckProjektmanagement: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 ihrerGesamtheit gekennzeichnet ist, wie z. B.

– Zielvorgabe– zeitliche, finanzielle oder andere Bedingungen– Abgrenzung gegenüber anderen Vorhaben


– projektspezifische OrganisationProjektmanagement (PM):Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel fürdie Abwicklung eines Projektes.

1.1 Projekte

1.1.1 Definition (von W. Kowarschick)

Ein Projekt (englisch: Project) ist ein zeitlich begrenztes, eigenständiges, kom-plexes und riskantes Vorhaben mit klaren Vorgaben bezüglich Funktionalität undQualität und mit eigenem, fast immer begrenztem Budget.

Die Realisierung eines Projektes wird von einem Auftraggeber finanziert und ei-nem Auftragnehmer übertragen. Der Auftragnehmer nimmt dazu ein Projektteamund (andere) geeignete Ressourcen zu Hilfe.

Das Projektergebnis wird nach erfolgreichem Projektende von Benutzern einge-setzt. Es kann überdies Auswirkungen auf weitere Personen haben: die Betroffe-nen.

Auftraggeber, Auftragnehmer, Projektteam und Benutzer sind die so genanntenProjektbeteiligten. Im weiteren Sinne zählen auch die Betroffenen dazu.

Beispiele für Projekte

– Asterix und Kleopatra: Bau eines Palastes für Cäsar (Goscinny undUderzo [1968])

– Ich baue ein Haus– Falls erfolgreich: Folgeprojekt: Ich ziehe um– Entwicklung eines elektronischen Aufsatzdienstes für mehrere bayeri-

sche 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


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 Aufgabedes 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 unter-scheiden. Ich verzichte ganz bewusst auf diese Forderung, da ein Hausbauoder die Realisierung eines Web-Auftrittes auch dann als Projekt angesehenwerden sollte, wenn das Unternehmen schon Dutzende von Häusern gebautbzw. Web-Auftritten realisiert hat. Als Auftraggeber kann ich dann aller-dings 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 folgendeKonsequenzen 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 Auftraggeberabgesprochen.

Dies ist aber grundfalsch. Da ein Projekt eine riskante Unternehmung ist,können keine genauen Termine abgegeben werden, sondern nur Zeitspan-nen, in denen ein Projekt voraussichtlich beendet ist. Diese Zeitspannen sindumso größer, je weniger Erfahrung mit vergleichbaren Projekten vorliegt.Dieser Punkt wird im Abschnitt 3.3.2 sowie im Abschnitt 1.2.3 ausführlichdiskutiert.Besser ist daher:→ Auftraggeber und Auftragnehmer einigen sich über einen Zeitraum oder

einen variablen Funktionskatalog. Das heißt, es gibt einen Zeitrahmenfür das erwartete Projektende oder es gibt einen festen Termin zusam-men mit einem Katalog von Funktionen, die im Zweifelsfall nicht rea-lisiert werden.

→ Es gibt für Meilensteine keine fixen Termine.


– 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 Be-nutzer – auch sollte das Projektergebnis nicht auf Kosten Unbeteiligtergehen).

→ „Wer zahlt, schafft an.“ – Falsch!Die Ziele müssen vorher schriftlich vereinbart werden; Änderungen anden Zielen müssen ebenfalls schriftlich vereinbart werden. Von Anfangan sollte bei der Finanzierung ein finanzieller Puffer für spätere Ände-rungswünsche eingeplant werden.

→ Für die Schätzung der Kosten gilt dieselbe Aussage wie für die Schät-zung der Dauer. Je seltener ein vergleichbares Projekt durchgeführtwurde, desto größer ist der Rahmen, in dem sich die Kosten bewegenwerden. Genauere Zahlen gibt es nur, wenn viele Vergleichsprojektevorliegen.

– Ein Projekt hat einen Auftraggeber und einen Auftragnehmer→ Auftraggeber und Auftragnehmer einigen sich, unter Berücksichti-

gung der Wünsche der späteren Benutzer, über realistische Projektziele(Funktionalität, Qualität, Projektdauer und Projektkosten) – Vorgabenvom Auftraggeber; Vorschläge, Annahme oder Ablehnung durch denAuftragnehmer.

– Ein Projekt wird von einem Projektteam realisiert.→ Der Auftragnehmer wählt geeignete (und nicht etwa nur möglichst bil-

lige) Mitarbeiter und insbesondere einen geeigneten Projektleiter. Die-ser sollte möglichst früh (in den allerersten Projektphasen) an der Pro-jektdefinition beteiligt werden (am Besten auch an der Auswahl desTeams).

→ Ein großes Projekt kann in mehrere Teilprojekte mit eigenen Teamsund Teilprojektleitern untergliedert werden. Einen Gesamtprojektleiter(Projektmanager) gibt es dennoch.


– Ein Projekt verbraucht Ressourcen (Material, Lizenzen etc.).1

→ Der Auftragnehmer wählt geeignetes Material, Lizenzen, etc., um dasProjektziel, d. h. die Realisierung der Funktionalitäten in der geforder-ten Qualität unter Berücksichtigung der Zeit- und Kostenvorgaben, zuerreichen.

→ Die Ressourcen müssen stets zur rechten Zeit in der richtigen Mengeam richtigen Ort sein.

– Das Projektergebnis wird nach Projektende von Benutzern eingesetzt.→ Die Wünsche des Benutzers müssen bei der Projektplanung berücksich-

tigt werden. Ein Projektergebnis, das nicht akzeptiert wird, ist selten fürden Auftraggeber von großem Nutzen.

→ Das Projektergebnis eines erfolgreichen Projektes sollte für alle Betei-ligten von Nutzen sein: Auftraggeber, Auftragnehmer und Benutzer undes sollte Betroffenen nicht schaden.Zitat aus InformationWeek (Neumann [1999]):

Unterschätzte Anwender: IT-Abteilungen wissen, daß die Zu-friedenheit der internen Anwender und der Kunden für die Be-urteilung ihrer Leistung wichtig sind; die Hersteller halten dieMeinung der User für unerheblich.

Auf S. 40 im selben Artikel bewerten 350 Anwender die Benutzer-freundlichkeit der IT-Systeme (Rang 2, Vorjahr Rang 3) und den Feed-back der Anwender im eigenen Betrieb (Rang 6, Vorjahr Rang 9) alssehr wichtige Technikaspekte.Die Hersteller sind ganz anderer Meinung: Rang 11 und Rang 15.

– Das Projektergebnis hat Auswirkungen auf Betroffene (z. B. Anwohner aneinem neuen Flughafen).→ Die negativen Auswirkungen auf Betroffene müssen so minimal wie

möglich gehalten werden.→ Prozesskosten, durch Prozesse entstehende Verzögerungen, Entschädi-

gungszahlungen 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 Res-source, die vom Projekt verbraucht wird (immerhin geht ein Teil seiner gesamten Lebenszeitfür das Projekt drauf). Gegenüber den Mitarbeitern sollte man zwischen Ressource und Per-sonal allerdings tunlichst unterscheiden. Deshalb wurde zuvor der Punkt „Projektteam“ auchseparat behandelt. Beachten Sie aber, dass die nachfolgenden Aussagen eins zu eins auch fürProjektteams gelten!


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 Verbesse-rung des Arbeitsablaufs, Steigerung der Mitarbeitermotivation oder der Kunden-zufriedenheit, mehr Marktmacht etc. Diese Ziele können allerdings häufig wederprä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 je-doch immer sein, dass das Projektergebnis für alle Beteiligten in irgendeiner Formvon Nutzen ist.

Jedes Projekt basiert auf zwei Ecksäulen: Ziele (Was?) und Ressourcen (Wie?).Die formalen Ziele legt der Auftraggeber (in Abstimmung mit den Auftragneh-mer) fest und die Ressourcen der Auftragnehmer (oft macht der Auftraggeberallerdings auch bezüglich der Ressourcen Vorgaben). Beide Vertragsparteien ver-folgen i. Allg. auch noch strategische Ziele mit einem Projekt.

Funktionalität

Projektziele

Qualität

Zeit Kosten

Ressourcen

Was?

Wie?

Auftraggeber

Auftragnehmer

Zielestrategische

strategischeZiele

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 erreichtwurden, d. h., inwieweit das Projekt erfolgreich war.

Die Ziele sollten einen konkreten Nutzen für alle Beteiligten mit sich bringen (dasgilt selbst für die Grundlagenforschung: das „Menschheitswissen“, das als Basisfür alle anderen Projekte dient, wird vermehrt).


Funktionalität und Qualität sowie strategische Ziele

Spezifikation

Was soll im Projekt erreicht werden (Funktionalität), und von welcher Güte solldas Ergebnis sein (Qualität). Strategische Ziele werden i. Allg. in der Spezifikationnicht formuliert.

Asterix und Kleopatra

– Funktionalität: prunkvoller Palast für Cäsar

– Qualität: rechtwinklige Stufen, Steine fallen nicht von der Decke, Türenklemmen nicht (Gegenbeispiel: Das Haus von Numerobis)

– strategische Ziele: Nachweis, dass Ägypter nicht dekadent sind; Gewinn ei-ner Wette

Der Auftraggeber, der Auftragnehmer und vor allem die Benutzer erwarten sichvom Projektergebnis einen Gewinn oder anderen Nutzen:

– Kleopatra (Auftraggeber): Will Wette gewinnen.

– Numerobis (Auftragnehmer): Will mit Gold überschüttet werden und Folge-aufträge haben.

– Miraculix (Teammitglied): Will einem alten Freund helfen und bedeutendeSchriften aus der alexandrinischen Bibliothek lesen.

– Asterix, Obelix, Idefix (Teammitglieder): Wollen Miraculix helfen, wollenaußerdem Spaß (Römer verprügeln), Action und Abenteuer.

– Sekretaris, Arbeiter (Teammitglieder): Wollen Geld verdienen und – im Fal-le der Arbeiter (die ausdrücklich keine Sklaven sind) – möglichst wenigePeitschenhiebe.

– Cäsar (Nutzer des Palastes): Will Wette gewinnen (und nicht etwa den Palastnutzen!).

– Pyradonis (Betroffener – Konkurrent von Numerobis, der leer ausging): Willdas 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 Betei-ligten interessiert sich für das eigentliche Projektergebnis: den Palast.

Das Projektergebnis sollte die gewünschte Funktionalität (und nur diese!) in dergewünschten Qualität aufweisen. Dies gilt sogar dann, wenn der Benutzer (wieCäsar) gar nicht das Projektergebnis nutzen will.

→ ständige Überwachung des Funktionsumfangs

→ geeignete Qualitätstests


Um wirklich von Nutzen zu sein (d. h. i. Allg. Gewinn abzuwerfen), sollte dasProjekt nicht nur funktionierende, sondern auch qualitativ hochwertige Ergebnisseliefern. Gegenbeispiel Windows-Software: häufig viel Funktionalität in schlechterQualität. Gutes Marketing oder Monopol⇒ trotzdem Gewinn.

Es gilt leider nicht „hohe Qualität ⇒ hoher Gewinn“. Oftmals wird der Ge-winn mit der Verminderung der Qualität vergrößert (z. B. gibt es heute keineDVD-/CD-ROM-Laufwerke mehr mit Staub- und Kratzschutz in Form von Cart-ridges Wikipedia [2006c]).

Bei der Festlegung der Ziele müssen Auftraggeber und Auftragnehmer die Wün-sche der späteren Benutzer berücksichtigen. Ein Produkt, das am Benutzer vor-beientwickelt wurde, wird sicherlich kein Erfolg. Das heißt, von Anfang an sollteder 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ätoder 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 Ausstel-lungskatalog erst nach der zugehörigen Ausstellung fertiggestellt wird oder wennder 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 gebrachtwerden

→ ständige Überwachung des Budgets (Budgetüberschreitung hat evtl. Kata-strophe wie z. B. Konkurs zur Folge)


Anmerkung

Nicht alle Auftraggeber erwarten die vollständige Erfüllung aller Projektzie-le. Special-Effects-Firmen (SFX-Firmen) wie z. B. Digital Domain (Titanic, 25Mio. Dollar, Nachverhandlungen 40 Mio Dollar→ 4 Mio Dollar + 31 MitarbeiterVerlust), müssen auf Verlangen der Hollywood Filmstudios manchmal nur entwe-der on time (d. h. im vorgegebenen Zeitraum) oder on budget (d. h. im Rahmendes vorgegebenen Budgets) arbeiten, aber am Besten natürlich Beides. (QUELLEFEHLT [????])

1.1.3 Ressourcen

Wesentlicher Projektbestandteil von Anfang an: der Ressourcenplan.

Es muss insbesondere abgeschätzt werden können, ob die Projektziele überhaupterreichbar sind.

Funktionalität/Qualität, Zeitplan und Kostenplan müssen mit dem Ressourcenplanin 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 bei-spielsweise auch für einfache Schreibkräfte, Sklaven (Asterix) und „minder-qualifizierte“ Mitarbeiter – in einem guten Team erbringt jede Person die ma-ximale 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 zumEssen in unsere Kantine gehen. Also lasst die anderen Mitarbeiterin Ruhe.“Die Kannibalen geloben, keine Kollegen zu belästigen.Nach vier Wochen kommt der Chef wieder und sagt: „Ihr arbeitetsehr gut. Nur uns fehlt seit gestern eine Putzfrau, wisst Ihr was ausder geworden ist?“Die Kannibalen antworten alle mit nein und schwören mit der Sachenichts zu tun haben. Als der Chef wieder weg ist, fragt der Bossder 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 vonTeamleitern, Abteilungsleitern und Projektmanagern, damit keineretwas merkt, und du Depp musst die Putzfrau fressen...!!!“


Die Mitarbeiterführung ist und bleibt die wesentliche Aufgabe eines jedenProjektleiters/-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 be-nötigt?

Ressource „Infrastruktur“:Was für Räumlichkeiten, welcher Verwaltungsapparat, welche Wartungsver-trä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, kostetaber Geld!

Ressource „Lagerhaltung“:Die Lagerung von Hardware kostet Platz und damit Geld. Allerdings könnenBauteile 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 vorberei-tet sein. Die Schulung von Mitarbeiter kostet zwar Zeit und Geld, allerdingskann 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 „Un-terauftragnehmer“ zur Erfüllung der Projektziele beitragen.

Ressource „Verbrauchsmaterial“Steht benötigtes Büromaterial bereit? Gibt es eine „Kaffeekasse“ für die Ver-pflegung von Gästen? (Mitarbeiter verwalten ihre eigene Kaffeekasse). Undso weiter.

Wenn irgendwelche Ressourcen zu den geplanten Kosten oder während des ge-planten Zeitraums nicht zur Verfügung stehen, müssen eventuell Abstriche an den


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 gehal-ten werden.

Achtung: Besonders günstige Ressourcen zu beschaffen ist ein typisches Beispielfür das Prinzip: „Wir sparen, koste es was es wolle!“ Da wird eine Maschine voneinem Lieferanten beschafft, der diese 1 000 Euro billiger verkauft als ein Kon-kurrent. Allerdings hätte der Konkurrent vier Wochen eher liefern können. Pro-jektleiter übersehen gerne, dass Mitarbeiter, die wegen eines fehlenden Bauteilsvier Wochen lang nicht weiterarbeiten können, wesentlich mehr kosten als 1 000Euro. Sehr viele Manager optimieren lokal (hier: 1 000 Euro bei einem Bauteilgespart); sie übersehen dabei allerdings dass viele lokale Optima i. Allg. kein glo-bales 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 for-male Ziele („Qualität und Funktionalität“, „Kosten“, „ Zeit“) und Ressourcen zuplanen, zu organisieren und zu kontrollieren, das Risiko des Scheiterns zu mini-mieren sowie das zugehörige Projektteam zu führen.

Zu diesem Zweck werden i. Allg. ein verantwortlicher (Gesamt-)Projektleiter undeventuell mehrere Teilprojektleiter (d. h. Leiter von Teilprojekten) bestimmt.

1.2.2 Aufgaben des Projektmanagements

Die Aufgaben des Projektleiters sind also – neben der Menschenführung – dieProjektplanung, -organisation und -kontrolle sowie das Risikomanagement:

– Projektziele sind unter Beteiligung des (zukünftigen) Projektleiters frühzei-tig zwischen Auftraggeber und Auftragnehmer abzustimmen und schriftlichin verbindlicher Form (Vertrag) präzise festzuhalten. Änderung an den Pro-jektzielen müssen ebenfalls stets schriftlich in verbindlicher Form festgelegtwerden.

– Der Projektleiter muss die Spezifikation durch genaue Projektpläne (Kosten-pläne, Zeitpläne, Ressourcenpläne, Aufgabenaufteilung, Risikoindikatorenetc.) absichern!


– 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 zueinem echten Problem wird (DeMarco und Lister [2003]).Nach der Menschenführung ist die zweitwichtigste Aufgabe des Projektlei-ters, Vorkehrungen für rechtzeitige und richtige Reaktionen bei Planabwei-chungen zu treffen und bei allen Abweichungen dann auch rechtzeitig undrichtig steuernd einzugreifen (Risikomanagement).Gäbe es mit Sicherheit keine Abweichungen, bräuchte man keinen Projekt-leiter, sondern nur einen Projektplaner.

– Im laufenden Projekt muss also die Einhaltung dieser Pläne fortwährendkontrolliert werden, um frühzeitig Risiken zu erkennen, die zu echten Pro-blemen werden:

• Werden die vereinbarten Funktionen (und nur diese!) von den Entwick-lern in der vereinbarten Qualität erstellt (Qualitätstests)?

• Werden die Zeitpläne eingehalten?Sind Zwischenergebnisse innerhalb der erwarteten Zeitfenster (Meilen-steine) fertig?

• Werden die Kostenpläne eingehalten?• Entwickelt sich der Ressourcenverbrauch wie geplant; werden die Res-

sourcen 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 konzen-triert, deren Nicht-Erfüllung eine Nicht-Erfüllung einzelner Projektzie-le zur Folgen haben.Wenn beispielsweise ein so genannter nicht-kritischer Vorgang um zweiWochen hinter der Zeit herhinkt, das Ergebnis aber trotzdem noch im-mer rechtzeitig zur Verfügung stehen wird, besteht für den Projektleiterkeinerlei Handlungsbedarf!Leider managen die meisten Manager zum größten Teil Probleme, de-ren Lösung für sie gar keinen Gewinn bedeutet. (90%, Quelle: irgendwobei Goldratt: QUELLE FEHLT [????])

Überarbeitete Manager beschäftigen sich mit Dingen, mit de-nen 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äfts-reisenden ein, dass ein Teil ihrer Reisen verzichtbar sei (dpa [2006]).


– Nach Abschluss des Projektes weist der Projektleiter im Rahmen einer Pro-jektabnahme 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 dienötigen Menschenkenntnisse verfügen, um angemessene Entscheidungen treffenzu können.

Der Projektleiter muss allerdings nicht über so viel Fachwissen verfügen, umselbst aktiv an der Entwicklung mitwirken zu können. Bei den allermeisten Pro-jekten ist er bereits mit der Projekt-Leitung (d. h. Führung, Organisation, Problem-lö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 thoseoutcomes will result in disaster or an undesirable consequence, then some-body will do it that way.“(Diese Aussage geht auf Edward A. Murphy, jr. zurück. Den genauen Wort-laut seiner ursprünglichen Aussage, die er nach einem missglücktem Experi-ment gemacht haben soll, kenne ich allerdings nicht, dazu kursieren im Netzzu viele unbelegte Versionen.)Anders gesagt: Alles dauert länger als geplant, kostet mehr als geplant undleistet weniger als geplant.

Grundmeist menschliches Versagen

DeshalbNach Abschluss des Projektes: „Erfahrung reflektieren“, um dieselben Fehlernicht ein zweites Mal zu machen (Fehleranalyse).Frei nach Konfuzius: „Wer einen Fehler macht und nichts daraus lernt, machteinen zweiten.“

1.2.3 Theory of Constraints

(vgl. Goldratt und Cox [2002], Goldratt [2003]) Die Theory of Constraints undspäter das Critical-Chain-Projektmanagement wurden von Dr. Eliyahu MosheGoldratt (31. März 1948 – 11. Juni 2011) begründet. (Todesnachricht: Techt[2011])


Welche Entscheidungen muss ein Manager treffen, und welche Entscheidungensind überflüssig oder gar schädlich, da sie nichts zum Erfolg des Unternehmensoder des Projektes beitragen oder diesen sogar behindern? Goldratt geht davonaus, dass bis zu 90 % aller Management-Entscheidungen in die zweite Kategoriefallen.

��

��

��

�

��

�

��

�

�

�

Abbildung 1.1: Konvoi

Engpass und Puffermanagement

Um den Unterschied zwischen sinnvollen und nutzlosen oder gar fehlerhaften Ent-scheidungen zu veranschaulichen, schlägt Goldratt ein einfaches Gedankenexpe-riment vor: Die Aufgabe ist es, einen Konvoi von Fahrzeugen (oder auch eineGruppe von Wanderern/Schülern, die auf einem schmalen Pfad hintereinandergehen) 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 deslangsamsten Fahrzeugs (Abbildung 1.1 c, das langsamste Fahrzeug ist mit einemx gekennzeichnet). Die vor diesem Fahrzeug fahrenden Fahrzeuge können belie-big schnell fahren. Das hat aber keine Auswirkung auf die Ankunft des letztenFahrzeugs, der entweder selbst das langsamste ist oder hinter diesem festhängt.

Wie sollte ein Manager vorgehen, um den Konvoi zu beschleunigen? Die sinn-vollste Vorgehensweise wäre, zunächst das langsamste Fahrzeug (= den „Eng-pass“, engl. „constraint“) zu ermitteln und dann dieses Fahrzeug schneller zu ma-chen (z.B. indem es von unnützem Ballast befreit wird oder einen stärkeren Motorerhält). Falls der Konvoi weiter beschleunigt werden soll, wiederholt man diesebeiden Schritte einfach.


Der Manager kann aber auch nutzlose Entscheidungen treffen, wie z. B. die gleich-zeitige Beschleunigung aller Fahrzeuge. Dies würde zwar auch das Engpass-Fahr-zeug beschleunigen (was sinnvoll ist), aber eben auch alle übrigen Fahrzeuge, wasin der aktuellen Situation sinnlos ist und nur Kosten verursacht, da der Konvoi da-durch nicht schneller ans Ziel kommt.

Eine fehlerhafte Entscheidung wäre, das Engpass-Fahrzeug weiter zu verlangsa-men, indem es z. B. mit noch mehr Transportgut beladen wird. Eine subtilere Fehl-entscheidung wäre, einige oder gar alle anderen Fahrzeuge soweit in ihrer Leis-tungsfähigkeit zu beschränken (um „Kosten zu sparen“), dass sie genauso leis-tungsfähig sind wie das Engpass-Fahrzeug. Diese Entscheidung hätte eine deut-liche Verlangsamung des Konvois zur Folge, auch wenn das auf den ersten Blicknicht klar ist. Darauf wird im nachfolgenden Paragraphen „Management der kurz-fristigen Kostensenkung“ noch genauer eingegangen.

Zunächst soll eine andere Frage diskutiert werden: Was macht man dagegen, dassdie Fahrzeuge, die sich vor dem Engpass-Fahrzeug befinden, nicht auf und davonfahren? Laut Goldratt reicht es, wenn man das erste Fahrzeug an eine (virtuelle)„Kette“ (engl. „chain“) legt, die mit dem Engpassfahrzeug verbunden ist (Abbil-dung 1.1 d). Damit erreicht man, dass sich das erste Fahrzeug und damit auch alleanderen Fahrzeuge, die sich vor dem Engpass-Fahrzeug befinden, nicht beliebigweit entfernen können.

Die Kette darf allerdings nicht zu kurz sein. Sonst bremst eine Störung bei ei-nem vorausfahrenden Fahrzeug (z.B. ein Tankvorgang) auch das Engpass-Fahr-zeug aus.

Nun machen wir ein zweites Gedankenexperiment (Abbildung 1.2 a): Ein Produktwird erstellt, indem Lieferanten „L“ die geeigneten Rohstoffe liefern und diese derReihe nach von verschiedenen Maschinen „Mi“ (oder auch Arbeitern) weiterver-arbeitet werden (zum Beispiel am Fließband), bis das fertige Produkt vorliegt undvon Kunden „K“ gekauft werden kann.

Auch hier gibt es eine Engpass-Maschine, mit dem geringsten Durchsatz (im Dia-gramm ist dies die Maschine M3, die wiederum mit einem „x“ markiert wurde).Maschinen, die in der Produktionsreihenfolge vor dieser Maschine stehen, kön-nen mehr Zwischenprodukte produzieren, die in Zwischenlagern vor der jeweilsnachfolgenden Maschine gelagert werden müssen. Genauso wie Fahrzeuge, dievor dem Engpass-Fahrzeug fahren, beliebig großen Abstand gewinnen können,können Maschinen, die vor der Engpass-Maschine produzieren, beliebig großeZwischenlager erzeugen.

Im Beispiel (Abbildung 1.2 a) kann M1 nicht so viele Rohstoffe verarbeiten, wieder Lieferant liefert. M2 arbeitet schneller als M1 und muss daher hin und wiederLeerlaufzeiten hinnehmen. Allerdings produziert M2 deutlich mehr Zwischenpro-dukte, als M3 verarbeiten kann. Alle Maschinen, die in der Produktionskette nach


� ��

� ��

��

� ��

�� ! " #

�� ! " #

� ��

�� ! " #

$�� # %�& � %�'(& )�� %� & � � � ��

� ��

�� & �� ! " #

� ��

�� *�� & � �� ! " #

� ��

� ��

� ��

+ & � �,� � � �� + & � �,� � � �� + & � �,� � � �� + & � �,� � � ��

� -

� -

. -

��-

! -

� ��

Abbildung 1.2: Produktion

M3 stehen, könnten mehr Zwischenprodukte verarbeiten, hängen aber hinter M3fest, da diese Maschine nicht genug Zwischenprodukte erstellt.

Auch hier ist die beste Managementstrategie wieder: Engpass finden und be-schleunigen. Außerdem sollten die Lieferanten an die Kette genommen werden.Sie sollten stets nur so viele Rohstoffe liefern, dass das Zwischenlager vor M3immer mit genügend vielen Zwischenprodukten gefüllt ist, d. h., dass ein kleinerLieferengpass oder ein kurzzeitiger Produktionsstopp an einer der Maschinen M1oder M2 die Engpass-Maschine nicht ausbremst (Abbildung 1.2 b). Da die reineJust-in-Time-Strategie, die hier verfolgt wird, bei Streiks oder anderen unvorher-gesehenen Ereignissen zu Problemen führen kann, kann man theoretisch mit einerzweiten Kette auch noch ein etwas größeres Rohstofflager vor Maschine M1 ein-richten (Abbildung 1.2 c). Prinzipiell könnte man aber auch das Zwischenlagervor M3 einfach entsprechend vergrößern.


Wenn die Managementstrategie „Engpass finden, dann Engpass beheben“ zy-klisch immer und immer wieder durchgeführt wird, tritt irgendwann eine von fol-genden 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 behe-ben. Im ersten Fall braucht man neue oder weitere Lieferanten oder auch Alter-nativ-Rohstoffe. Im zweiten Fall muss man die Nachfrage ankurbeln. Falls diesgelingt, ist wieder eine der Maschinen der Engpass, die dann wieder beschleu-nigt werden muss. Spätestens wenn es allerdings irgendwann nicht mehr gelingt,den Engpass „Kundennachfrage“ zu beheben und der Leerlauf bei allen Maschi-nen immer größer wird, muss man ein neues, innovatives Produkt auf den Marktwerfen.

Das heißt, so viel ein Manager auch optimiert, nach jeder Optimierung muss einweiterer 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 meh-rere Maschinen teilweise parallel an verschiedenen Zwischenprodukten arbeiten(die erst später zu einem größeren Ganzen zusammengefügt werden), immer ge-nau eine Engpass-Maschine existiert, die den Gesamtdurchsatz bestimmt. Dies istder Engpass, der den Durchsatz bestimmt und auf den sich der zuständige Mana-ger konzentrieren muss.

Das Vorgehen, sich auf den Engpass zu konzentrieren und diesen mit einemsinnvollen Puffermanagement von engpass-externen Störungen abzuschirmen, be-zeichnet Goldrat als „Theory of Constraint“ (ToC, Engpasstheorie).

Im Projektmanagement identifiziert er den kritischen Pfad als Engpass. Um Zeit-und Kostenprobleme in den Griff zu bekommen, schlägt er ein explizites Puffer-mangement vor. Einen kritischen Pfad mit explizitem Puffer bezeichnet er – inAnlehnung an die „Pufferkette“ – als „kritische Kette“ (vgl. Goldratt [2002]).

Typische Managementfehler

Obwohl die vorgestelle Management-Strategie („immer wieder: Engpass findenund dann diesen Engpass beheben“) zumindest im Fall des Konvois sofort ein-leuchtet, gibt es mehrere alternative Management-Strategien, die leider weit ver-breitet 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.


Management by Objectives

Eine mögliche Management-Strategie wäre z. B., mit jedem Fahrer des Konvoisbzw. mit jedem Arbeiter an einer Maschine Ziele zu vereinbaren („Managementby Objectives“, MbO, Management durch Zielvereinbarung): Ein Fahrer der 10 %schneller fährt als bisher bzw. ein Arbeiter der 10 % mehr Zwischenprodukte er-zeugt als bisher, erhält eine Bonuszahlung.

Dies hat folgende Effekte: Die Fahrer, die vor dem Engpass fahren, vergrößern denAbstand zum Engpass noch schneller als bisher; die Zwischenlager vor dem Eng-pass wachsen noch schneller als bisher. Die Fahrer hinter dem Engpass-Fahrzeugbzw. die Arbeiter hinter der Engpass-Maschine sind sauer auf den Engpass-Ver-antwortlichen, da sie durch diesen ausgebremst werden. Vielleicht wird auch derEngpass 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 umeine Firma, die PCs am Fließband montiert (Endmontage). Neben angelernten Ar-beitern jobben – vor allem während der Ferienzeit – regelmäßig auch Schüler undStudenten für ein paar Wochen bei dieser Firma. Die Anzahl der PCs, die proStunde montiert werden können, hängt davon ab, wie lange der langsamste Ar-beiter 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 Griffenoch nicht so routiniert beherrscht, wie ein festangestellter Arbeiter. Dies wärenicht weiter problematisch gewesen, wenn die Firma nicht eine Gruppen-Leis-tungsprämie ausgelobt hätte: Für jeweils soundso viele PCs, die vom Team amFließband über das Soll hinaus montiert wurden, gab es eine kleine Extraprämiein Form eines etwas besseren Stundenlohns. Und so wurde der Engpassarbeiterregelmäßig das Ziel von Mobbingattacken. Insbesondere Schüler und Studentenhatten zu leiden, wenn sie besonders langsam waren. (Den Fließband-Arbeiternwar natürlich nicht klar, dass es für den optimalen Durchsatz einen und nur einenEngpass geben muss. Dieser Punkt wird im Paragraph „Management der kurzfris-tigen Kostensenkung“ diskutiert.)

Größere Zwischenlager und unzufriedene Mitarbeiter, die irgendwann innerlichkündigen, kosten i. Allg. deutlich mehr, als durch eine Zielvereinbarung hinzu-gewonnen werden kann. Diese Management-Strategie geht davon aus, dass vielelokale Optimierungen (jeder Fahrer, jede Maschine wird beschleunigt) auch eineglobale Optimierung (= einen größeren Gewinn) zur Folge haben. Dies ist lautTom DeMarco (DeMarco [2001]) ein nicht auszurottender Trugschluss, der dieFirmen Geld ohne Ende kostet. MbO wurde in der Mitte des vorigen Jahrhundertserfunden und hat sich seitdem unausrottbar in die Köpfe der meisten Managereingenistet, obwohl heute bekannt ist, dass dieses Management-Prinzip fast nurNachteile mit sich bringt. (Weitere Nachteile, werden im Kapitel 5 diskutiert.)


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. Hierwird genausowenig wie bei MbO analysiert, wo eigentlich die Probleme liegen,sondern aus dem Bauch heraus irgend etwas optimiert. Auch dies führt nur in denseltenen 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äl-lig 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 Leerlauf-zeiten von Maschinen reduziert werden. Teure Maschinen werden durch billigere,nicht ganz so leistungsfähige Maschinen ersetzt. Teure Mitarbeiter werden durchweniger qualifizierte und dadurch billigere Arbeiter ersetzt oder gleich ganz ent-lassen. Et cetera. Solchen Managern schwebt ein optimales System vor: Alle Ma-schinen sind exakt gleich leistungsfähig. Insbesondere am Fließband wird diesesZiel angestrebt: Alle Arbeitsschritte müssen exakt im vorgegebenen Takt erfolgen.

Doch auch diese Strategie ist vollkommen widersinnig. Wenn alle Maschinen ex-akt gleich schnell sind, hat jede Störung einer dieser Maschine Auswirkungen aufden Gesamtdurchsatz. Am Beispiel des Konvois sieht man das sehr schön: Wennein Auto tankt, müssen die Nachfolger warten (da das Überholen nicht möglichist). Wenn das Engpass-Fahrzeug tankt, hat dies Auswirkungen auf die Durch-schnittsgeschwindigkeit des Konvois (und damit auch auf die Gesamtdauer derFahrt), da dieses Fahrzeug die verlorene Zeit nie wieder einholen kann. Wenn da-gegen ein anderes Auto tankt, hat dies keine Auswirkungen auf die Durchschnitts-geschwindigkeit des Konvois. Fahrzeuge, die hinter dem Engpass-Fahrzeug fah-ren, können wieder zum Engpass-Fahrzeug aufschließen, indem sie kurzzeitigschneller fahren. Und Fahrzeuge, die vor den Engpass-Fahrzeug fahren, behinderndieses nicht, wenn der Abstand (Puffer) groß genug ist. Nach dem Tankvorgangfahren diese Fahrzeuge ebenfalls ein Zeitlang etwas schneller als zuvor, um denalten Abstand wieder herzustellen.

Wenn hingegen alle Fahrzeuge gleichschnell sind, ist jedes Fahrzeug ein Eng-pass. Das heißt, jeder Tankvorgang und jede sonstige Verzögerung eines beliebi-gen Fahrzeugs hat negative Auswirkungen auf die Durchschnittsgeschwindigkeitdes Konvois, da kein Fahrzeug eine Verzögerung mehr aufholen kann. Es ist daherzwingend notwendig, dass es ein und nur ein Engpassfahrzeug gibt, sonst schau-keln sich die Störungen beliebig auf.

Die Erkenntnis, dass man genügen Puffer benötigt, um Schwankungen aufzufan-gen, ist von zentraler Bedeutung. Ein ausgefeiltes Puffermangement ist viel wich-tiger, als man gemeinhin annimmt.


1.2.4 Zusammenfassung

Die wichtigste Erkenntnis, die man aus den Ergebnissen von Goldratt ziehenmuss, ist, dass man sich als Manager nicht um alles zu kümmern braucht, sonderndass man nur die wirklich relevanten Risiken und Probleme in den Griff bekom-men muss. Wer die Engpässe in seinem Unternehmen oder Projekt nicht kenntund auf’s Geratewohl irgendwelche lokalen Optimierungen mit der Gießkannevornimmt, ist kein Manager, sondern ein Versager.

Die andere wichtige Erkenntnis ist, dass es ohne gutes Puffermangement nichtgeht.

Man erinnere sich: Goldratt vermutet, dass bis zu 90 % aller Management-Ent-scheidungen entweder keine Auswirkungen oder sogar negative Auswirkungenhaben!

Die wesentlichen Aufgaben eines Projektleiters sind:

1. Menschenführung (Zwischenmenschliche und persönliche Probleme erken-nen und und nach Möglichkeit mindern)

2. Risikomanagement (Probleme frühzeitig erkennen und vermeiden), hierzuzählt insbesondere das Puffermanagement

3. Planung und Kontrolle (gute Planung = Problemvermeidung, Kontrolle = Pro-bleme frühzeitig erkennen)

In allen drei Fällen gilt: Konzentration auf die wirklich relevanten Problemgebie-te. Nur diejenigen Risiken und Probleme sind von Interesse, die das Erreichen derProblemziele gefährden. Eine Mediation, nur weil ein Mitarbeiter mal schlechtgelaunt ist, das Managen von unbedeutenden Risiken (Kaffee geht aus) oder ex-trem unwahrscheinlichen Risiken, die Planung jedes kleinsten Details oder vonKomponenten, die vielleicht gar nicht realisiert werden, sind überflüssig und len-ken 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 verwi-ckelte Erklärungen, warum die ganze Sache als „durchaus erfolgreich“ anzusehenist (Kellner [2001]). Also braucht man ein paar gute Definitionen.

Projekterfolg aus neutraler Sicht (juristische Sicht)

Die neutrale Sichtweise kann nur die schriftlichen Vereinbarungen zwischen Auf-traggeber und -nehmer zur Grundlage haben.


erfolgreich:Ein Projekt ist erfolgreich, wenn alle vertraglich festgelegten Ziele erfülltwurden: Spätestens zu den vorgegebenen Terminen und im Rahmen des vor-gegebenen Budgets wird die geforderte Funktionalität in der geforderten Qua-lität geliefert.

sehr erfolgreich:Ein erfolgreiches Projekt ist sehr erfolgreich, wenn die Anforderungen (Er-wartungen) teilweise übertroffen wurden, d. h., wenn die gewünschten Ergeb-nisse früher geliefert werden können und/oder wenn die Kosten geringer wa-ren als geplant und/oder wenn die geplante Funktionalität in höherer Qualitätrealisiert werden konnte und/oder – in Absprache mit den Auftraggebern –wenn ein erweiterter Funktionsumfang in mindestens der geforderten Quali-tät realisiert werden konnte.

gescheitert:Ein Projekt ist gescheitert, wenn ein oder mehrere vertraglich vereinbarte Pro-jektziele nicht erreicht wurden.

Vertraglich können auch andere Erfolgsmodelle definiert werden: Zum BeispielHollywood Filmstudios: on time oder on budget. In diesem Fall ist ein Projekt erstdann gescheitert, wenn es sowohl den Zeit-, als auch den Finanzrahmen überzieht.

Projekterfolg aus Sicht eines Projektbeteiligen (Auftraggeber, -nehmer, Be-nutzer, Projektleiter . . .)

erfolgreich:Ein Projekt ist erfolgreich, wenn das Ergebnis für den jeweiligen Projektbetei-ligten 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 stra-tegischen 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 Erwartun-gen deutlich übersteigt.

weniger erfolgreich:Ein Projekt ist weniger erfolgreich, wenn das (evtl. zu spät gelieferte oder zuteurere 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) Ergebnisnutzlos für den Projektbeteiligten ist. Dies gilt selbst dann, wenn das Projektim juristischen Sinne erfolgreich war!


katastrophal gescheitert:Ein Projekt ist katastrophal gescheitert, wenn das Ergebnis den Projektbetei-ligten ruiniert.

Projekterfolg aus Sicht der Betroffenen

erfolgreich:Ein Projekt ist erfolgreich, wenn das Ergebnis den Betroffenen nicht ernstlichschadet.

Wie wir gesehen haben, unterscheiden sich die Definitionen von Projekterfolgaus juristischer Sicht und aus Sicht der Projektbeteiligten fundamental. Die ersteDefinition basiert auf den vertraglich vereinbarten Zielen Funktionalität, Qualität,Kosten und Zeit, der zweiten Definition liegen dagegen die strategischen Ziele derjeweiligen 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 (DiesesVerhältnis muss natürlich kleiner als 1 sein.)

sehr erfolgreich:Ein Projekt ist für einen Beteiligten sehr erfolgreich, wenn das geplante Kos-ten/Nutzen-Verhältnis deutlich übertroffen wurde (d. h. deutlich kleiner alsgeplant ist).

weniger erfolgreich:Ein Projekt ist für einen Beteiligten weniger erfolgreich, wenn das echte Kos-ten/Nutzen-Verhältnis zwar nicht erzielt wurde, aber zumindest kleiner als 1ist.

gescheitert:Ein Projekt ist für einen Beteiligten gescheitert, wenn das echte Kos-ten/Nutzen-Verhältnis größer 1 ist, aber keinen Ruin für den Beteiligten be-deutet.

katastrophal gescheitert:Ein Projekt ist für einen Beteiligten katastrophal gescheitert, wenn es ihnruiniert.

Ein (sehr) erfolgreiches Projekt, das Betroffenen einen größeren Schaden zufügt,ist aus Sicht der Betroffenen gescheitert oder sogar katastrophal gescheitert.


Beispiel 1

Zum Beispiel war der Bau der ersten Atombombe aus Sicht der Projektbeteiligtenerfolgreich. Aus Sicht der Bewohner von Hiroshima und Nagasaki und eigent-lich auch aus Sicht der gesamten Weltbevölkerung ist dieses Projekt katastrophalgescheitert.

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 einzunächst erfolgreiches Projekt später in das Gegenteil umkehren (Schadensersatz-zahlungen etc.).

Kosten/Nutzen-Planung

Wie man an diesen Definitionen sieht, kann man den wirklichen Projekterfolg nurdann 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 Unternehmensfolgendermaßen (Goldratt [2003]):

1. Gewinn machen bzw. steigern (heute und in Zukunft)

2. sicheres und befriedigendes Umfeld für Belegschaft schaffen (heute und inZukunft)

3. Markt zufrieden stellen (heute und in Zukunft)

Was heißt „Gewinn steigern“?

1. Nettogewinn steigernNettogewinn = Einnahmen − Ausgaben > 0(unter Berücksichtigung der Inflation)

2. Rendite steigernRendite = Gewinn / Investition

3. Cashflow steigernCashflow = Menge des verfügbaren („flüssigen“) Geldes für Investitionen etc.Geldmittel werden dem Cashflow entzogen durch:

– Lagerbestände


– Infrastruktur (Gebäude etc.)– laufende Projekte

Achtung: ein länger andauernder negativer Cashflow, d. h. der Geldzufluss istgeringer als der Geldabfluss, führt zur Insolvenz, auch wenn der Gewinn undRendite stimmen, da die frei verfügbaren Finanzmittel immer weiter bis aufNull abnehmen (vgl. Flash-Animation Biz/ed [2006]).

Beispiele

– Titanic, der Film (QUELLE FEHLT [????]): sehr erfolgreich für den Auf-traggeber, trotz Kosten von 200 Mio Dollar (100 Mio geplant) sowie 6 Mo-nate Verzug.Aus Sicht von Digital Domain: erfolgreich, wenn man den Prestigegewinndurch den Film berücksichtigt, oder gescheitert, wenn man die Verluste be-rücksichtigt (trotz Nachverhandlungen: 4 Millionen Dollar Verlust; außer-dem haben 31 Mitarbeiter ihren Job verloren, da für sie keine geeignetenProjekte akquiriert werden konnten).

– Projekt: Bau des Bahnhofs Canfranc (Scheytt [1998])Gebäude: 241m langer „Palast“, 1853 Planungsbeginn, 1882 Bewilligung (6Jahre Bauzeit, 60000 Pesetas Subvention/km, Steuerfreiheit auf Baumate-rialien), 1928 Einweihung (46 Jahre reale Bauzeit), wegen unterschiedlicherSpurbreiten und fehlender Elektrifizierung auf spanischer Seite: für Auftrag-geber ein Flop, d. h. gescheitert! (Allerdings nicht katastrophal gescheitert,da die beteiligten Staaten Spanien und Frankreich daran nicht Konkurs ge-gangen 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 Mexi-ko)Budget: unbegrenzt; zum Schluss mehr als 2 Milliarden DollarZeit: genau 19 MonateTeam: die besten Physiker AmerikasDas Projekt wurde erfolgreich abgeschlossen: funktionierendes Ergebnis ge-nau zum angestrebten Termin („Tag X“).21 und 24 Tage nach Projektende wurde das Ergebnis in Hiroshima undNagasaki eingesetzt. Für das amerikanische Militär war das Projektergebnisein voller Erfolg; für die Betroffenen – die Bewohner von Hiroshima undNagasaki und später für die ganze Menschheit (Wettrüsten) – war das Projektkatastrophal gescheitert (gerade weil es formal erfolgreich war).


Oppenheimer war kurze Zeit ein Nationalheld. Während des Projektes hater allerdings einen Mitarbeiter bei einem Atomunfall verloren (das erste Op-fer einer Atombombe). Später widersetzte sich Oppenheimer dem Bau derWasserstoffbombe ⇒ Untersuchungsverfahren wegen angeblicher kommu-nistischer 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 Ver-antwortung.“

• „Manchmal glaube ich, dass wir trotz aller unserer Intelligenz vomRaubtier abstammen.“

– Projekt: Untersuchung über Heilungswirkung verschiedener Varianten dessynthetischen Hormons Levothyroxin bei Schilddrüsenerkrankungen (Rub-ner [1990])Projektleiterin: Betty Dong, Pharmazeutin an der Universität von Kaliforni-en in San FranziskoProjektergebnis: alle vier untersuchten Präparate wirken bei den meisten Pa-tienten 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 teu-erste und meistverschriebene der vier untersuchten Präparate her.Gutachter des Journals of the American Medical Association konnten keineFehler in der Studie finden. Das Ergebnis wurde erst später, als die Geschich-te publik wurde, veröffentlicht. Kosten für Versicherungen und Kranke: 365Millionen Dollar.

Bemerkung

Für das Scheitern eines Projektes aus der Sicht des Auftraggebers ist nicht not-wendigerweise der Projektleiter verantwortlich. Wenn dieser zu den gegebenenTerminen und im Rahmen des vorgegebenen Budgets die geforderte Funktio-nalität liefert, das Ergebnis aber trotzdem für den Auftraggeber nutzlos ist, lagbereits ein Planungsfehler vor (z. B. Eisenbahnbrücke ohne Eisenbahn: Die „So-da-Brücke“ von Rödental; dpa [2005], Wikipedia [2011b], Wikipedia [2006b]).Allerdings sollte der Projektleiter schon von Anfang an, d. h. auch während derPlanungsphase, verantwortlich am Projekt beteiligt sein. In diesem Fall wäre erauch mitverantwortlich für das Scheitern des Projektes.


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 Projekt-leiters, aus Sicht des Auftragnehmers, aus Sicht des Auftraggebers, aus Sicht desBenutzers und – sofern ein ethisches Verantwortungsbewusstsein besteht – ausSicht der Betroffenen.

Aber auch weniger erfolgreiche oder nur relativ kurzzeitig erfolgreiche Projektewerden eventuell noch akzeptiert.

Darum: Wie vermeidet man Misserfolge und erst recht Katastrophen?

1. RegelEs gibt kein Patentrezept!(„There are no Silver Bullets“: Brooks [1986], Wikipedia [2006a])

2. RegelDer Projektleiter muss „einfach“ für jedes (managebare) Risiko, das für sein Pro-jekt zum Problem werden kann, rechtzeitig Strategien zur Minderung der Auswir-kungen und/oder Strategien zur Reaktion entwickeln. Falls ein Risiko zum echtenProblem wird, muss er rechtzeitig und richtig reagieren.

Numerobis: „In Ägypten haben wir gegen die Zeit, gegen den Personalmangelund 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, umwenigstens möglichst viele dieser Risiken zu vermeiden oder zumindest derenAuswirkungen abzumildern.

Für das Management heißt das im Wesentlichen einen fähigen Projektleiter – wieNumerobis? – einzusetzen und glasklare Projektziele zu formulieren, die nach-träglich – wenn überhaupt – nur kontrolliert geändert werden können.

Der Projektleiter sollte sich möglichst auf die Erfüllung der Projektziele konzen-trieren (können), d. h., dem Begriff „erfolgreich“ sollte die neutrale Sicht zugrun-de gelegt werden (auch wenn das nicht immer zu vertreten ist – siehe Oppenhei-mer).


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 sinn-voll, wenn die Vorsorge auch einen positiven Effekt für die Patienten hat: höhereLebenserwartung und/oder höhere Lebensqualität. PSA-Tests zur Prostata-Vor-sorgeuntersuchungen bieten diese Vorteile derzeit mit hoher Wahrscheinlichkeitnicht (Albin [2010]), auch der Sinn von Mammographie-Reihenuntersuchungenist umstritten (Nekolla et al. [2005], Dubben und Beck-Bornholdt [2010]).

In der New York Times schreibt Richard Albin, der PSA vor 40 Jahren entdeckthat:

PSA sollte keinesfalls genutzt werden, um alle Männer über 50 regel-mäßig zu testen, wie es jene wollen, die wahrscheinlich davon profitie-ren.Ich hätte mir nie träumen lassen, dass meine Entdeckung vor 40 Jahrenin eine derartige profitgetriebene Katastrophe für das Gesundheitswe-sen führen würde. Die Medizin sollte sich der Realität stellen und denunangemessenen Einsatz von PSA-Tests stoppen. Das würde Milliar-den Dollar sparen und Millionen Männer vor unnötigen und beein-trächtigenden Behandlungen bewahren.

(Albin [2010], Übersetzung in der SZ)


Im Oktober 2011 empfahl die U.S. Preventive Services Task Force, ein Gremi-um des US-Gesundheitsministerium, die Abschaffungen des PSA-Tests in derUSA.(Briseño [2011])

1.4.3 Typische Risiken und Vorsorgemaßnahmen

Im Folgenden werden Beispiele für Risiken angegeben, die ein Projekt scheiternlassen können, wenn sie nicht rechtzeitig bedacht werden. Für viele Risiken wer-den 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 Anpas-sung des Systems)

• überzogene oder nicht-realisierbare Funktionalität∗ Der Auftraggeber möchte eine „eierlegende Wollmilchsau“ (Vor-

sorgemaßnahme: Anforderungen frühzeitig vertraglich fixieren)∗ neue Techniken sollen eingesetzt werden, die noch gar nicht das

Stadium der Forschung hinter sich gelassen haben (Solche Projektesollten nur als Forschungsprojekte durchgeführt werden.)

• Inflation der Anforderungen = ausufernde Änderungswünsche währendder Projektlaufzeit (Vorsorgemaßnahme: explizites Änderungsmanage-ment etablieren)

– Qualitätsprobleme• schlechte Qualität (Vorsorgemaßnahmen: Qualitätsanforderungen in

Lasten-/Pflichtenheft einbauen, Qualitätssicherung, Qualitätsmanage-ment)

• überzogene oder nicht-realisierbare Qualität z. B.: Ein System mit100 % Ausfallsicherheit kann nicht erstellt werden.Forderungen wie Ausfallzeit unter 30 Min/Jahr sind dagegen, bei ent-sprechenden Kosten, schon realisierbar:

99,99 % Ausfallsicherheit =̂ max. 53 Min Ausfall/Jahr99,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 kei-nen Ersatz-Mitarbeiter)


• Lieferschwierigkeiten, Systemausfall etc.; Pyradonis behindert Stein-nachschub (Vorsorgemaßnahme: Puffermanagement)

Achtung: Die Puffer, die für einzelne Vorgänge ermittelt werden,sollten zu größeren Einheiten zusammengefasst werden (Zubrin-gerpuffer, Gesamtpuffer etc.; siehe Abschnitt 4.5.)

• Mitarbeiter verlassen den Betrieb (Mitarbeiterfluktuation). Vor allemgute Mitarbeiter gehen, andere „kündigen innerlich“, wenn sie unzu-frieden sind. (Vorsorgemaßnahme: gute Menschenführung)

• Die Mitarbeiter erliegen dem Studentensyndrom (Goldratt [2002],Fachbezeichnung: Prokrastination). (Vorsorgemaßnahmen: kurze Vor-gänge, keine Parallelarbeit, realistische Schätzungen (Vertrauen!))

StartZeit

Arbeitseifer

Oh, jetzt wird’s

Ende

Ist ja noch Zeit!

aber knapp!

Begeisterunganfängliche

2/3 Zeit1/3 Arbeit

1/3 Zeit2/3 Arbeit

Abbildung 1.3: Studentensyndrom, vgl. Goldratt [2002]

• Ein guter Mitarbeiter/Projektleiter arbeitet in normalen Zeiten höchs-tens 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 Handhat: Zeiten realistisch schätzen, Mitarbeiter an kritischen Vorgän-gen von anderen Arbeiten entlasten, Resource Leveling (siehe Ab-schnitt 4.4.3))


• Sinnlose Wartezeiten kosten Zeit (Microsoft-Lösung: Win95-Buttonsfür bevorzugte Abfertigung in der Kantine; Cusumano und Selby[1997]).

• Telekommunikation kostet Zeit: Jedes Telefonat, jede E-Mail reißteinen Wissensarbeiter aus seiner „Denkarbeit“, durchschnittlich pas-siert dies alle 11 Minuten (Pilgram [2011]) – es dauert danach jeweilsca. 10 Minuten seine Gedanken danach wieder auf die eigentliche Ar-beit zu konzentrieren, d. h., sich zu „vertiefen“ (DeMarco [2001]). (Vor-sorgemaßnahme: Störungen von Mitarbeitern möglichst fernhalten)

• Projektexterne Tätigkeiten kosten Zeit.• Der Zeitplan ist inhärent falsch („politischer Zeitplan“, „agressive Zeit-

planung“; 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 Planungnicht übersehen)

• Lizenzen und andere Rechte kosten Geld. (Vorsorgemaßnahme: Bei derPlanung nicht übersehen)

• Der Kostenplan ist inhärent falsch („politischer Zeitplan“, „agressiveZeitplanung“).

• Die Konkurrenz ist billiger (evtl. mit weniger Funktionalität oderschlechterer 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, sinddie 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)Draft (4. Oktober 2012) 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ührungsebe-nen)

– zu knappe Ressourcen(Rechnerzeiten, Kopierkontingente, Raumnot etc., Asterix: zu wenig Skla-ven; 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 daherverfü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ß, wel-che Ziele er eigentlich verfolgen soll.

– In der Spezifikation werden zu Projektbeginn, da sich die beteiligten Parteiennicht einigen können, keine konkreten Angaben zu Anforderungen gemacht(nur Luftblasen). Wolkige Spezifikation ist möglich, wolkige Entwicklungnicht⇒ irgendwann kommt es zum Crash.

Dieses Risiko wird sofort zum Problem, sobald ein derartig schwammiger Ver-trag formal geschlossen wird. Das heißt, die Risikovorsorge muss sehr frühzeitigerfolgen, evtl. noch, bevor überhaupt ein Projektteam eingesetzt wird. Hier sindauch wieder höhere Führungsebenen gefragt, die über dem Projektteam liegen.

Probleme von außen

Neben den tyischen Managementfehlern gibt es noch Risiken, deren Problemwer-dung vom Projektteam nur schwer abgewendet werden können:

– höhere Gewalt (Konkurs des Auftraggebers, Streik, Umweltkatastrophen)

– Spionage

– Konkurrenz hat mehr „Marktmacht“


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 Management-fehler zurück zu führen sind, und diese beeinflussen meist auch nur die Projekt-ziele „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 Manage-mentfehler:

– keine Konzentration des Managements auf wesentliche Aufgaben

– Manager kümmern sich nicht um Projektinterna, treffen aber Entscheidun-gen

– 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 Mitar-beiter, falsche Kostenplanung, falsche Ressourcenplanung etc.


Weitere typische zwischenmenschliche Probleme:

– nutzlose Meetings aufgrund von Profilierungssucht

– irreale Kosten-/Zeitschätzungen, weil Auftragnehmer das Projekt unbedingtoder überhaupt nicht haben will

– Pläne werden über die Köpfe der Betroffenen hinweg erstellt

– DV-Spezialisten ignorieren Belange von Normalbenutzern („Diese Idiotenverstehen 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 (Py-radonis) oder Benutzer

– etc. pp.

Kernrisiken

Projektrisiken gibt es viele. Am Besten ist es natürlich, alle managebare Risi-ken auch zu managen, sofern diese eine gewisse Relevanz haben. Ein Risiko wiez. B. „Ein Asteroid vernichtet einen Großteil der Menschheit“ ist nicht managebarund kann daher ignoriert werden. Genauso kann ein Risiko wie z. B. „Der Kaffeeist aus“ ignoriert werden; hier finden die Projektmitarbeiter i. Allg. eine eigenetragfähige Lösung (z. B. einen Kaffeebeauftragten, der rechtzeitig für Nachschubsorgt).

Es ist schon viel gewonnen, wenn wesentliche Kernrisiken berücksichtigt wer-den. Kernrisiken zeichnen sich durch hohe Eintrittswahrscheinlichkeit und hoheKosten aus, wenn sie wirklich eintreten.

Urs Gulba [2004] nennt folgende Top-Risiken in Softwareprojekten:

– Dynamische Anforderungen (= andauernde Veränderung der Anforderun-gen)

– schlechte Projektplanung und -schätzung

– mangelhafte Kommunikation

– fehlende oder unzureichende Qualitätssicherung

– unreife Softwaretechniken sowie unzulängliche Entwicklungsmethoden und-werkzeuge


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, dasdie Arbeitsleistung betrifft – und dies auch noch als letztes. Die anderen Risi-ken können durch harte Arbeit des Teams kaum mehr beeinflusst werden. Sie alsProjektleiter können allerdings gegen die meisten Risiken ankämpfen. Bei Pro-blemen wie einem inhärenten Zeitplan oder einem Spezifikationskollaps, könnenallerdings auch Sie (nachträglich!) nicht mehr viel ausrichten.

Wesentliche Kernprobleme bestehen schon frühzeitig. Das heißt, viele Kernrisi-ken müssen schon sehr früh berücksichtigt werden, da sie sonst schon früh zuechten Problemen werden (auch wenn das häufig erst spät, viel zu spät erkanntwird).

Ein klassisches Beispiel ist der erste Versuch des Toll-Collect-Projektes. Um denAuftrag zu erhalten, hat das Konsortium eine Projektlaufzeit von weniger als ei-nem Jahr veranschlagt. „Im Vorfeld nach anstehender Bundestagswahlen einigteman sich auf elf Monate“ (Borchers [2004]). Dass diese Zeitspanne für ein derartkomplexes Projekt viel zu kurz war, dürfte selbst jedem Laien klar sein. Nachdemdie veranschlagten elf Monate vorbei waren, wurde eine realistische Schätzungvon mehreren Jahren Projektdauer vorgenommen und in einem zweiten Versuchwurde das Projekt erfolgreich abgeschlossen.

1.5 Vergleich von Projekten mittels Euro-Tagen

Ein billiges Projekt mit langer Laufzeit bindet eventuell mehr Kapital, als einteures Projekt mit kurzer Laufzeit. Um den Wert eines Projektes abschätzen zukö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], TOCTimes [2005]).

Wenn ein Projekt 1 000 Euro einen Monat lang bindet, entspricht dies laut Gold-ratt einer Investition von 30 000 Euro-Tagen = 1 000 Euro · 30 Tage. VerschiedeneEuro-Tag-Investitionen werden einfach aufaddiert.


Nehmen wir an, unser Projekt hätte eine Laufzeit von 3 Monaten. Jeder Monatkoste uns 1 000 Euro, anschließend verdienen wir monatlich 500 Euro mit demProjektergebnis. Das heißt, wir investieren 3 000 Euro und müssen insgesamt 9Monate (= 3 Monate Projektlaufzeit + 6 Monate Verdienst am Projektergebnis)warten, bis wir die Investition wieder „herein“geholt haben. Nach 9 Monaten ha-ben wir also genauso viel Geld zur Verfügung als davor. Erst jetzt verdienen wirmit 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 amersten Tag investiert hatten und auch nicht 9 Monate lang auf jeden Cent verzich-ten mussten. Bei genauerer Rechnung ergibt sich folgende Investitionssumme:

1. Monat: 1 000 Euro investiert30 Tage · 1 000 Euro = 30 000 Euro-Tage, Summe: 30 000 Euro-Tage

2. Monat: weitere 1 000 Euro investiert30 Tage · 2 000 Euro = 60 000 Euro-Tage, Summe: 90 000 Euro-Tage

3. Monat: weitere 1 000 Euro investiert30 Tage · 3 000 Euro = 90 000 Euro-Tage, Summe: 180 000 Euro-Tage

4. Monat: 500 Euro verdient⇒ noch 2 500 Euro investiert30 Tage · 2 500 Euro = 75 000 Euro-Tage, Summe: 255 000 Euro-Tage




8. Monat: 500 Euro verdient⇒ noch 500 Euro investiert30 Tage · 500 Euro = 15 000 Euro-Tage, Summe: 405 000 Euro-Tage

9. Monat: 500 Euro verdient⇒ noch 0 Euro investiert30 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 Mona-te lang auf Investitionsmittel in Höhe von 405 000 Euro-Tagen verzichtet. Wennwir das Geld für diese Zeit anders (besser) angelegt hätten, hätten wir evtl. früher


mehr Geld verdient. Das heißt, wir können erst dann von einem echten Reinge-winn sprechen, wenn wir mir dem Projekt nicht nur das Geld, sondern auch dieverlorenen Euro-Tage wieder verdient haben.

Die Rechnung der so genannten Durchsatz-Euro-Tage, d. h. der Euro-Tage, diewir durch das Projekt gewinnen, beginnt ab dem Zeitpunkt, ab dem wir erstmalseinen echten Gewinn einfahren. Bei unserem Projekt ist das der 10. Monat. DieDurchsatz-Euro-Tage werden geanuso wie die Investitions-Euro-Tage berechnet:

10. Monat: 500 Euro Gewinn30 Tage · 500 Euro = 15 000 Euro-Tage, Summe: 15 000 Euro-Tage

11. Monat: weitere 500 Euro Gewinn30 Tage · 1 000 Euro = 30 000 Euro-Tage, Summe: 45 000 Euro-Tage


13. Mona:t weitere 500 Euro Gewinn30 Tage · 2 000 Euro = 60 000 Euro-Tage, Summe: 150 000 Euro-Tage




(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 vie-le Durchsatz-Euro-Tage verdient, wie wir Investitions-Euro-Tage zuvor verlo-ren hatten. Bis dahin haben wir außerdem 3 500 Euro mit unserem Projekt ver-dient. Über den Zeitraum von 7 Monaten entspricht das einer Investitionskraftvon 420 000 Euro-Tagen. Diese Investitionskraft hätten wir auch gehabt – und dasauch noch früher –, wenn wir das Projekt gar nicht gestartet hätten. (Inflationsbe-reinigt hätten wir sogar noch ein paar Tage länger warten müssen, bis wir unsereursprü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 oderverleben können. Im Magazin „TOC Times“ steht: „. . . the project Flushes – wereally return the investment in both money and opportunity lost“ (TOC Times[2005]).

In einem Internetforum (Zultner [2009]) wird von Richard Zultner der Sinn derInvestiontions- und der Durchsatz-Euro-Tage mit einem sehr einfachen „Gegen-beispiel“ in Frage gestellt. Das Argument lautete wie folgt: Wenn jemand 10 Euroauf zwei Arten anlegen könne, einmal für einen Tag, um dann 20 Euro zurück-


zubekommen (= 10 Euro Gewinn)2 und einmal für 10 Tage, um dann 100 Eurozurückzubekommen (= 90 Euro Gewinn), dann sei es auf jeden Fall besser, es für10 Tage anzulegen, weil dann der Gewinn deutlich größer sei. Dies widersprächeaber dem Ergebnis der Berechnung der Investitions-Euro-Tage, die im ersten Fallnur 10 · 1 = 10 Euro-Tage betrügen, im zweiten dagegen 10 · 10 = 100 Euro-Ta-ge. Dieses Ergebnis würde ja bedeuten, dass man die 10 Euro besser nur einen Taganlegen sollte, weil der Flush dann wesentlich früher einträte. In jedem Lehrbuchstünde dagegen, dass die andere Variante die bessere Wahl sei.

Hat er Recht? Ja, er hat Recht, aber nur, wenn eine Reinvestition – wie von Zultnergefordert – nicht möglich ist. Sehen wir uns dieses Beipiel (mit diesen fantasti-schen Gewinnmöglichkeiten) mal etwas genauer an. Angenommen, ich wäre imBesitz von genau 10 Euro und legte sie so an, dass ich nach 10 Tagen 90 EuroGewinn machte. Bis ich diesen Gewinn einstreichen könnte, wären meine 10 Eu-ro gebunden und ich könnte sie nicht anderweitig verwenden. Dies drückt sich imWert „100 Investiotions-Euro-Tage“ aus.

Wenn ich dagegen die 10 Euro nur ein Tag lang anlegte, hätte ich am nächstenTag 20 Euro zur Verfügung, die ich gleich wieder investieren könnte. Die 20 Eu-ro 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ät-te ich 40 Euro, nach drei Tagen 80, nach 4 Tagen 160 und so weiter. Auf dieseWeise 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. Die-ses Maß hilft einem dabei, zu entscheiden, welche Investitionen wirklich sinnvollsind. Wenn ich zwischen diesen fantastischen Investionsmöglichkeiten „Verdopp-lung in einem Tag“ und „Verzehnfachung in 10 Tagen“ nur ein einziges Mal wäh-len kann und es keine anderen Reinvestitionmöglichkeiten gibt, dann sollte ichnatürlich die Verzehnfachung wählen. Wenn mir aber nach einem oder auch zweiTagen wieder eine Super-Investtionsmöglichkeit angeboten wird, dann ist die Ver-dopplung der Verzehnfachung i. Allg. vorzuziehen, da diese die Investitionsmittelnicht 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 erwartetenGewinne schlecht oder gar vollkommen unseriös sind.

Andererseits macht einem die Berücksichtigung der Euro-Tage erst klar, welcheKosten eine große Zeitverzögerung wirklich verursacht. Es wird nicht nur derReingewinn 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 ichjeweils 20 Euro Gewinn.


halbes Jahr verkaufen lässt und nicht, wie geplant, ein ganzes Jahr, da es zu spätauf den Markt gekommen ist). Es wird auch die Investitionskraft, d. h. der Cash-flow, empfindlich geschmälert.

Fazit

Wenn man die Auswahl zwischen mehreren Projekten hat, sollte man bei der Ent-scheidung, welche davon realisiert werden sollten, nicht nur die Kosten und denspäter erhofften Gewinn, sondern auch die Auswirkungen auf die Investitions-kraft, d. h. die Investitions- und die Durchsatz-Euro-Tage berücksichtigen.


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, Desi-gnphase, Fertigungsphase, Einführungsphase etc.)

Prinzipiell ist es möglich, zwei Phasen überlappen zu lassen (Nahrungsaufnahme-phase + Informationsphase = frühstücken + Zeitung lesen)

Auch in Projekten könnte man mehrere Phasen einander überlappen lassen. ZumBeispiel könnte man mit der Einführungsphase (Aufstellen von Hardware beimBenutzer, Installation von Basissoftware etc.) begonnen werden, bevor die Fer-tigungsphase vollständig abgeschlossen ist. Im Falle von Terminproblemen wirdman manchmal auch so vorgehen.

Allerdings ist es sicherer, eine Phase vollständig abzuschließen und dann erst mitder nächsten zu beginnen.

Ein sehr schönes Beispiel lieferte im Sommersemester 2005 der Bau des neu-en Schülegebäudes der Hochschule Augsburg. Die erste Planungsfirma hatte dasHandtuch geworfen, eine zweite Planungsfirma übernahm den Job. Während die-se Firma die Anschlüsse von Steckdosen, Netzwerk etc. plante, wurden bereitsdie zugehörigen Leerrohre auf der Baustelle einbetoniert. Den Mitarbeitern desFachbereichs Informatik, die an der Planung beteiligt waren, standen veraltetePläne zur Verfügung, in denen sich z. B. Türen an anderen Stellen als aktuell ge-plant befanden. Aber das war sowieso egal, da ja auf der Baustelle bereits Faktengeschaffen wurden.

Besser ist es i. Allg. jede Phase vollständig abzuschließen, bevor die nächste be-gonnen 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 unterscheidetman zwischen internen Meilensteinen, die nur innerhalb des Projektteams von Be-deutung sind, und den externen Meilensteinen, bei denen die Teilergebnisse dem


Auftraggeber präsentiert werden und mit ihm das weitere Vorgehen abgestimmtwird.

Phase 1 Phase 2 Phase 3

Projektstart 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 nichtexistiert, d. h., wenn i = n),

– weiter mit Ziel- oder Planänderung: Phase i + 1 wird nach Änderung derZiele 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, Qua-lität) geändert werden. Dies sollte jedoch stets schriftlich mit Zustimmung allerBeteiligten erfolgen (Änderungsmanagement).

Dieses Vorgehen garantiert, dass die Phase n zur Zufriedenheit aller (oder zumin-dest der Mehrheit) abgeschlossen wird oder dass das Projekt wegen unüberwind-baren Problemen, Unwirtschaftlichkeit oder Ähnlichem vollkommen gestopptwird.


Vorteile des Phasenmodells

– Schätzungen sind, wenn man ein Projekt in mehrere Teile wie z. B. einzelnePhasen unterteilt und diese einzeln schätzt, viel besser, als wenn man einProjekt im Ganzen schätzt. (siehe Abschnitt 3.2.2)

– Das Projekt dümpelt nicht vor sich hin, da man immer erreichbare Ziele vorAugen hat.

– Die Zeit, Budget- und Zielplanung kann schrittweise erfolgen. Man stattetbeispielsweise das Projekt zunächst nur mit einem Budget für die ersten ein,zwei Phasen aus und entscheidet dann, ob man mit dem eigentlichen Projektstarten will.

– Zu jedem Meilenstein/Review-Zeitpunkt wissen alle Beteiligten, wo dasProjekt steht. Allerdings zaubern Projektleiter und -mitarbeiter bei Reviewsoft ganz schön.

– Bei jedem Review kann eine formale Änderung alter Projektziele erfolgen(Änderungsmanagement, Change Management). Schlimmstenfalls kann ent-schieden werden, mehrere Phasen zu wiederholen (z. B. weil der Hardware-hersteller der Zielplattform Pleite gegangen ist – in derart krassen Fällensollte 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 nor-mierten Begriffe dafür), die allerdings auch verschränkt ablaufen können (Spi-ralmodell; 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/dieBenutzer)

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


Aufarbeitungsphase reflektieren, um daraus für ein nächstes Projekt zu lernen.

Die Nutzungsphase ist nicht mehr Bestandteil des Projektes. In dieser Phase an-fallende Arbeiten, wie z. B. Wartungstätigkeiten, gehören zum Tagesgeschäft (ob-wohl viele Projektarbeiten leider oft in die Wartung verlegt werden, um den Ter-min formal einhalten zu können; Bananenprodukt: Das Produkt reift beim Kun-den).

Ein erfolgreiches Projekt kann ein oder mehrere Folgeprojekte initiieren. Dasheißt, in die Nutzungsphase (eventuell sogar schon in frühere Projektphasen) kön-nen die Planungsphasen der Nachfolgeprojekte fallen.

Diese fünf Grobphasen können je nach Projekt unterschiedlich umfangreich undin 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 einProjekt meist ohne konkrete Vorstellungen, ohne Projektleiter und Projektmana-gement.

Typische Phasen während der Spezifikationsphase:

Initialisierungsphase, Planungsphase, Bedarfsermittlung, Vorstudie

Zunächst muss die Projektidee geboren werden. Das kann ganz spontan im Schlafpassieren, oder man sucht gezielt nach neuen Projektideen mit Hilfe einer Vorstu-die 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 durchge-führt, eine Vorstudie wird dagegen oft als Auftragsarbeit an eine andere Firma


(z. B. Beraterfirma) vergeben. Es ist von Vorteil, wenn der zukünftige Projektlei-ter in dieser Phase schon aktiv beteiligt ist.

Eventuell wird während einer Bedarfsermittlung auch schon ein Rahmenkonzepterstellt (z. B. Orientierung an unternehmensweitem Datenmodell, Zusammenstel-lung potentieller Anwendungen). Es ist sogar möglich, schon Rahmenpläne zuerstellen (Teilprojekte mit Zielen, einzusetzende Ressourcen etc.).

Vorstudien sind eigentlich selbst wieder Projekte mit dem Ziel, die Machbarkeiteines größeren Projektes zu analysieren und ein Rahmenkonzept sowie Rahmen-pläne zu erstellen:

Während der Designphase des Vorprojektes kann eine so genannte Systemanaly-se durchgeführt werden, während der Fertigungsphase sollten ein oder mehrereKonzepte erstellt werden, und während der Einführungsphase sollte ein Konzeptausgewä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 Auftragge-ber sind). Die Phase kann sich direkt an die Informationsphase anschließen oderauch erst nach Verabschiedung irgendeiner Grobspezifikation erfolgen.

Wenn Sie zuwenig Geld haben, müssen Sie Projektpartner und/oder Geldgeberfinden.

Typische Projektpartner: andere Abteilungen, externe Unternehmen anderer Bran-chen, europäische Unternehmen derselben Branche etc.

Typische Geldgeber: der Aufsichtsrat, der Abteilungsleiter, ein anderes Unterneh-men (wenn Sie z. B. einer Technologietransferstelle angehören), der bayerischeStaat (Existenzgründerdarlehen etc.), die EU (Esprit etc.).


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 geworfenwerden.

Die zugeteilten Geld- und Zeitmittel können oft rein politischer Natur sein („Hierhaben Sie eine Million, lösen Sie das Problem in 15 Monaten!“).

Als potentieller Projektleiter sollten Sie von Anfang an bei der Akquise beteiligtsein. Es gibt nichts Schlimmeres, als zum Projektleiter eines undurchführbarenProjektes 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-ma-gazin [2003]).

Während der Akquisitionsphase werden oftmals mehr oder weniger detailliertePläne ausgearbeitet (Phasenpläne mit Meilensteinen, Kostenpläne, Ressourcen-pläne etc.). Doch Vorsicht! Die Pläne der Akquisitionsphase sind oft politischerNatur. Es gibt Projekte, bei denen heißt es am Ende der Akquisitionsphase: „Jetzthaben wir die Fördergelder. Was machen wir damit?“

Review

Genehmigung der Finanzierung. Jetzt kann oft schon mit gutem Gewissen einProjektvertrag zwischen Auftragsnehmer und -geber geschlossen werden (wennbereits „belastbare“ Rahmenkonzepte, ein Lastenheft o. Ä. vorliegen).

Definitionphase (Konzeptphase)

Spätestens in dieser Phase muss ein verantwortlicher Projektleiter bestimmt wer-den.

In den ersten Teilphasen der Spezifikationsphase werden normalerweise nur gro-be Zielvorstellungen formuliert (Lastenheft). Spätestens wenn klar ist, dass einProjekt gestartet werden soll, müssen die Ziele genau definiert und verbindlichfestgelegt werden. Ein Pflichtenheft oder eine Spezifikation muss geschrieben wer-den. Diese muss genau spezifizieren, was zu tun ist, welche Normen einzuhaltensind, wer für was verantwortlich ist (auch der Auftraggeber hat Pflichten!), wieProbleme 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 Faxper Internet ausliefern.


Die Bearbeitung einer Bestellung durch eine Fachkraft dauert am Rechner nichtmehr 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 Browserbetrachtet werden (auch Lynx, Braille-Zeilen etc.)

– Barrierefreiheit

– läuft auch ohne JavaScript (wird wegen Sicherheitsproblemen oft sogar viaProxy herausgefiltert)

– und so weiter

Auch strategische Ziele können formuliert werden. Die Erfüllung derartiger Zie-le kann allerdings meist nicht nachgewiesen werden – dann muss man auf dieAufnahme in das Pflichtenheft verzichten.

Anschließend sollten Kosten und Zeit geschätzt und die anderen Ziele eventuellangepasst werden.

Bei größeren Projekten werden teilweise Kosten- und Zeitpläne nur für die nächs-ten Schritte genauer spezifiziert und für spätere Schritte dagegen zunächst nurgrob festgelegt (höhere Fehlertoleranz).

Anmerkung 1

Eine Schätzung basiert auf vielen Unbekannten und macht daher keine exaktenAngaben über die echten Kosten und den echten Zeitbedarf. Ein guter Projektlei-ter zeichnet sich dadurch aus, dass seine Schätzungen im Mittel, d. h., wenn manviele von ihm geleitete Projekt in Betracht zieht, richtig sind. Einzelne Projektekosten mal mehr, mal weniger als geschätzt, und sie dauern mal länger und malkürzer als geschätzt. Die Abweichungen von den realen Werten sollten umso klei-ner sein, je häufiger ein Projektleiter ein Projekt derselben Art durchgeführt hat.Die Unsicherheiten hinsichtlich der Kosten und der Dauer des ersten Marsflugessind wesentlich zahlreicher, als bei einem Architekten, der sein hundertstes Hausbaut. Im ersten Fall sind Schwankungen von vielen 100 % zu erwarten, im zweitenFall sollten sich die Abweichungen im einstelligen Prozentbereich bewegen.

Anmerkung 2

Im Pflichtenheft sollte nicht stehen, wie etwas zu realisieren ist. (Grobe) Vorga-ben bezüglich der Ressourcen können allerdings über die Ziele gemacht werden(z. B.: Software muss mit vorhandener Software kompatibel sein – Das ist Be-standteil der Funktionalität. Das Projekt hat 3 Mitarbeiter – Das ist Bestandteil


der Kostenvorgabe: Es wird Geld für 3 Mitarbeiter und 2 Rechner zur Verfügunggestellt. Das heißt aber nicht, dass nicht 6 Halbtagskräfte eingestellt werden dürf-ten. Und so weiter.)

Der Auftragnehmer sollte über die Ressourcenplanung selbstständig entscheidenkö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 aller-dings nicht heißen: „Jedes Projektteam versucht möglichst viele der benötigtenRessourcen zu ergattern.“ In seinen Vorlesungen pflegte Prof. Ulrich Güntzer zusagen: „Wer knappe Ressourcen hortet, verknappt die Ressourcen weiter.“ DieLö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 ge-schlossen werden.

Die Spezifikationphase kann sich in mehrere Teilphasen untergliedern. Dabeikann 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 Pro-jekt 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 gefor-dert, detaillierte Pläne zu erstellen sowie sich nach geeigneten Mitarbeitern undanderen Ressourcen umzuschauen: Er weiß jetzt genau (oder sollte es zumindestwissen), was zu tun ist.

Im Allgemeinen sollten die Pläne – zumindest in groben Zügen – bereits vorlie-gen. Auch ist oft schon ein Teil der zukünftigen Mitarbeiter bekannt und ein Teilder benötigten Ressourcen vorhanden.

An der Feinarbeit kommt der Projektleiter allerdings nicht vorbei. Und zwar schonbevor die Designphase beginnt.

Bei der Erstellung von Plänen kann ihm ein PM-Tool von Nutzen sein. Die Arbeitabnehmen kann ihm ein derartiges Werkzeug allerdings nicht, denken er (oder sie)selbst!

Typische Pläne

– Terminpläne mit Meilensteinen


– 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. Esgibt es oft keine dedizierte Feinplanungsphase – daher spreche ich auch von Vor-bereitungsphase. Die Grobplanung kann schon im Rahmen der früheren Teilpha-sen erfolgt und genehmigt worden sein. Oder die Feinplanung liegt vollkommenin der Verantwortung des Projektleiters und bedarf deshalb überhaupt keines for-malen Reviews, sondern nur eines internen Reviews durch den Projektleiter. Fallser dabei jedoch gravierende Zielkonflikte entdeckt, muss er vor Beginn der Desi-gnphase den Auftraggeber informieren, um eventuell die Ziele neu zu definierenoder das Projekt abzubrechen.

Review

Eine Vorbereitungsphase zwischen Zielformulierung und echtem Projektstart gibtes dennoch fast immer. Diese Phase bedarf – da sie sich meist nur mit Planungund Ressourcenbeschaffung befasst – nicht unbedingt eines formalen Reviews,da es den Auftraggeber nicht interessieren sollte und meist auch nicht interes-siert, mit welche Ressourcen das Projekt durchgeführt wird. Auch hier gilt aber,dass zumindest der Projektleiter oder ein Projektverantwortlicher (der nicht not-wendigerweise auch der Projektleiter sein muss, sondern auch eine ranghöherePerson des Auftraggebers sein kann) am Ende der Vorbereitungsphase Bilanz zie-hen muss: Kann das Projekt starten oder nicht? Wenn nein, wird wiederum derAuftraggeber informiert.

Fazit: Meist handelt es sich beim Vorbereitunsphasen-Review um ein projektin-ternes Review.

2.1.2 Designphase (Entwurfsphase)

Spätestens jetzt startet das Projekt offiziell. Es sollte einen griffigen Namen undam besten ein griffiges Logo bekommen.

Die Designphase ist die wesentlichste Phase, da sie das Fundament für das spätereProdukt legt. Gravierende Fehler aus der Designphase können später kaum noch


ausgebügelt werden, außer wenn das Projekt im Sinne des Spiralmodells (sieheAbschnitt 2.2) realisiert wird.

Wesentlich Ziel der Designphase: Festzulegen wie das Pflichtenheft realisiertwird? (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, Programmierspra-chen, Datenbanksysteme etc.

– Beginn der Dokumentation!!!!(Auch Lasten- und Pflichtenheft sind Bestandteil der Dokumentation⇒ DieDokumentation 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 Designwerk-zeuge eingesetzt werden (z. B. objektorientierte Modellierung gemäß UML), werwelche Designaufgaben übernimmt, bis wann das Design steht etc.

Außerdem muss er mit der Soll-Ist-Überwachung beginnen: Wie weit weicht dasProjekt vom Plan ab? Gegebenfalls muss er gegensteuern. Darüberhinaus muss erdie 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]).


Wunschziel: Das Design beschreibt das Produkt so konkret, dass es nur noch rea-lisiert (= kodiert zusammengebaut, -geschraubt, . . . ) werden muss. Heute wirdein Projekt meist „agiler“ gemäß einem so genannten Spiralmodell (siehe Ab-schnitt 2.2) durchgeführt. Hier sieht das Wunschziel etwas anders aus: Das Designbeschreibt die nächste Projektversion so konkret, dass diese nur noch realisiertwerden 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. Erweiß 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 (Kell-ner: Höflichkeitsakt). Man hält sich aber nicht das Design, sondern fügt es derProjektdokumentation bei. Kellner: „Da ist alles sauber abgeheftet und stört nichtbei 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.


Bemerkung

Das Argument „Die Speicherplatzvorteile einer Zwei-Byte-Lösung waren vor 30Jahren wesentlich, da Speicher knapp war. Deshalb war das Y2K-Problem unver-meidbar.“ zieht nicht. In zwei Byte passen mehr als 65000 Jahre. Selbst in einemByte bringt man 256 Jahre unter. Das heißt: Zwei Byte für 100 Jahre bedeutetSpeicherplatzverschnitt.

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 nie-mand Gedanken über die Konsequenzen gemacht hat. Die Zwei-Byte-Codierungist soweit vorbereitet, dass auch in den ersten zehn Jahren des neuen Jahrtausendsdie 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 lautRedmont 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) rei-chen 7 Byte für eine sekundengenaue Darstellung. :-)

Anmerkung

Es gibt viele verwandte Probleme wie z. B. das 49,7-Tage-Problem (4-Byte-Zäh-ler 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 einMitarbeiter, dass bestimmte Roboter alle 49,7 Tage für mehrere Stunden ausfie-len. Der Fehler wurde allerdings meist erst nach 99,4 Tagen entdeckt, da Roboternormalerweise immer Samstags installiert werden, um den Arbeitsablauf nicht zubehindern (49,7 Tage später ist ein Sonntag).

Geschätzte Kosten der Designfehler für das Y2K-Problem

(vgl. Berghel [1998])


USA: 8.465.060 Personenmonate, $70.753.562.795 Kosten für Y2K-spezifischeSoftwareprobleme (eine derartige präzise Schätzung halte ich allerdings für Hum-bug)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 desY2K-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 alsRandproblem, das sich irgendwie von selbst lösen sollte. Eine Mehrheit der Un-ternehmen 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 fristge-recht 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 undNeumann [1997])

Hohe Reenineering-Kosten ⇒ IT-Ersatzinvestitionen werden in den kommendenJahren reduziert.


Beispiel ARAG

(vgl. Biskamp und Kunisch-Holtz [1998], Kunisch-Holtz [1998])

1989 provisorische Umstellung (da 10-Jahres-Policen ab 1990 nicht mehr erfasstwerden konnten).

Ab 1996 Analyse einer dauerhaften Umstellung.

Abschluss des Projektes: 2005 – bis dahin konnte man mit den Provisorien von1989 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 umge-stellt werden.

Projektleiter: „Je älter ein Programm, desto spannender wird’s.“

Die Alldata gibt keine vertragliche Garantie auf 100 % richtige Umstellung. DieTests 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 LOCAbnahmetests bei ProjektendeFiletransfer von und zu Partnerunternehmen (Schnittstellendefinitio-nen)

Kosten: ca. 15 Millionen Mark (grobe Schätzung; exaktes Volumen ist unbe-kannt; die Bank muss auf jedem Fall zahlen)

Projektleiter Moses: „Wenn wir als Bank zwei Tage nicht am elektronischen Zah-lungsverkehr hängen, dann sind wir aus dem Geschäft.“

Notfallpläne: zusätzliche Mitarbeiter werden von anderen Projekten abgezogen


Vorbeugung gegen Notfälle: CleanmanagementDas 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: neueJahr-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 stattgefundenhat:

Gehe die ganze Objektliste mit Ausnahme des letzten Elements durch:Wenn das aktuelle Objekt und sein rechter Nachbar in der falschenReihenfolge stehen, vertausche sie.

Beobachtung

– Dieser Algorithmus hängt von keiner Programmiersprache ab.⇒ Die zu verwendende Sprache kann (relativ) unabhängig von den zu ver-wendenden 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 (In-tegervergleich, Stringvergleich etc.)

– Der Algorithmus hat eine mathematisch bestimmbare Komplexität, nur ab-hängig von der Anzahl n der zu sortierenden Elemente (sofern die zugrunde-liegende Datenstruktur es erlaubt, die Objektliste in linearer Zeit zu durch-laufen 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])):


QuicksortHauptspeicherverfahren, im Mittel O(n · log n), im schlechtesten Fall O(n2)(oft bei bereits sortierten Mengen)

Mergesortauch für Datenmengen, die nicht in den Hauptspeicher passen geeignet, imMittel sowie im schlechtesten Fall O(n · log n), im Mittel um einen konstan-ten Faktor langsamer als Quicksort.

parallele Sortierverfahrennoch Forschungsgegenstand; das theoretische Optimum liegt bei O(log n);Richard Cole hat z. B. zwei Algorithmen vorgestellt, die ein Menge von Ob-jekten mit dieser Zeitkomplexität sortieren können, allerdings werden dafürn Prozessoren benötigt (Cole [1988]); wenn die Anzahl der Elemente auf einpaar Milliarden beschränkt ist (= alle praktischen Fälle) sind effiziente paral-lele Sortierverfahren mit einer fixen Anzahl von Prozessoren mit der Komple-xität O(n) bekannt (Obermaier [1993]).

Quicksort ist im Mittel um einen konstanten Faktor schneller als Mergesort, kanndiese Geschwindigkeit aber nicht garantieren. Bubblesort ist für sehr kleine Da-tenmengen (< 100 Elemente) das schnellste Verfahren. Quicksort und Bubblesortsortieren „in place“, d. h. ohne Zusatzspeicher.

Im Laufe der Designphase muss eine Entscheidung getroffen werden, welchesVerfahren verwendet wird.

Einflussfaktoren: Anzahl der zu sortierenden Elemente, verfügbare Datenstruk-turen, 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 · const1O(n · log n): 106 · 20 Vergleiche ⇒ 20 Sekunden · const2O(n): 106 Vergleiche pro CPU ⇒ 1 Sekunde · const3O(log n): 20 Vergleiche pro CPU ⇒ 20 Mikrosekunden · const4Quicksort kann wegen Worst-case-Komplexität keine Antwortzeiten garantieren,Mergesort schon!

Aufgrund solcher and ähnlicher Probleme müssen Entscheidungen vor dem Pro-grammieren getroffen werden. Während der Entwicklung wird oft nur mit ge-ringen 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äh-rend des laufenden Betriebs im Rahmen der Wartung zur so genannten Ruck-


sack-Programmierung. Wenn ein im Design übersehener Sonderfall zu Problemenfü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-Layoutein Fehler befindet, wird manchmal eine „Rucksack-Platine“ angefertigt, die aufdie ursprüngliche Platine montiert wird und den fehlerhaften Teil ersetzt.

Teilphasen

Auch die Designphase kann in mehrere Teilphasen (mit Reviews) unterteilt wer-den:

– 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 Druckformateetc.)

– 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, insbe-sondere, wenn diese ernsthafte Änderungen an einen oder mehreren Projektzielenzur 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änderungennur noch schwer durchzuführen sind – und sehr teuer werden können – sofern dasProjekt gemäß dem Wasserfallmodell (Abschnitt 2.2) entwickelt wurde.


Jetzt ist jede Struktur, jede Oberfläche, jedes Modul, jeder Datentransfer definiert.Es darf nicht sein, dass während der Fertigungsphase neue Module und Daten-strukturen entstehen (Ausnahme: Es wurde eine explizites Änderungsmanagementetabliert). Eine bessere Alternative ist es, Design- und Fertigungsphase zyklischabzuwechseln, 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 einfachverschoben oder ein zusätzliches Leerrohr eingezogen werden.

Wenn die Wände aber mal stehen, sind Veränderungen nur mit zusätzlichen Kos-ten möglich.

2.1.3 Fertigungsphase (Entwicklung)

In dieser Phase wird das Produkt realisiert.

Funktionsbeschreibungen und Design liegen vor, „Kreativität“ ist nicht mehr ge-fragt, „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 Ner-ven vom Projektleiter gefordert). Auch hier gilt wieder: Ein gut durchdachtesÄnderungsmanagement sollte auf keinen fehlen.

– Das Team folgt nicht dem Design (schlechtes Design?, schlechte Menschen-fü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 wieSchulungsunterlagen, Systemhandbuch, Installationsanleitung etc.


– Vorbereitung der Projektübergabe (Systemumstellung, Abnahme durch denAuftraggeber 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 (Benutzer-handbuch, Systemhandbuch etc.)

– Nachweise über Projekterfolg in Hinblick auf die Ziele Funktionalität, Qua-lität, Termine und Kosten

Es gibt zahlreiche weitere „Produkte“, die am Ende einer Fertigungsphase vorlie-gen 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 Pro-dukt eingesetzt bzw. das Teilprodukt als Basis weiterer Entwicklungen dient undab wann.

2.1.4 Einführungsphase

Typische Aktivitäten (evtl. auch Teilphasen):

– Installation in der Zielumgebung


– 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 erfolgrei-chen 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 wor-den 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 durchge-führt werden.


Wartung: Beseitigung von Problemen

Pflege: Weiterentwicklung

Grady [1992]:

– Auf 10 Fehler, die vor der Produktfreigabe durch Testen gefunden wur-den, kommt ein Fehler, der nach der Freigabe gefunden wird (z. B.: „Zeit-sprung“-Fehler wie Y2K)

– Es dauert die 4- bis 10-fache Zeit, um in einem umfangreichen, im Einsatzbefindlichen Software-Produkt einen Fehler zu finden und zu beheben, als ineinem 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 leiderweit verbreitet)

Software, die erstmals freigegeben wurde, arbeitet normalerweise ineffizient, dasie 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ährenddes Lebenszyklusses eines Produktes aus: 2/3 – 4/5 (67 %–80 %) des Gesamt-aufwands (QUELLE FEHLT [????]).

Aufarbeitungsphase

Für den Projektleiter ist das Projekt beendet. Für Pflege und Wartung ist meistjemand anders zuständig.

Allerdings sollten er oder besser noch das ehemalige Team das Projekt noch ein-mal 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 Bud-get 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.


Neubewertung

Nach längerer Zeit (sechs bis zwölf Monaten) kann das Projektergebnis noch ein-mal 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“. DessenAufgabe ist es, alle möglichen Informationen über alte Projekte „auszugraben“,um damit die Schätzungen für aktuelle und zukünftige Projekte deutlich zu ver-bessern.

Der Projektmanager Tomkins verliert dadurch seinen persönlichen Assistenten,weil dieser die besten Beziehungen zu den meisten Mitarbeitern im Unternehmenhat. Der Berater des Projektmanagers gibt einen triftigen Grund dafür an, diesenVerlust zu akzeptieren:

„Wir verlieren ihn nicht, wir geben ihm nur einen Job, bei dem er alle seine Talenteeinsetzen kann. Das ist unsere Aufgabe als Manager. Mitarbeiter dort einzusetzen,wo sie ihre Fähigkeiten und Talente am wirkungsvollsten einbringen können. Dasist es, was Management wirklich bedeutet.“

2.2 Wasserfall- und Spiralmodell

Das im letzten Abschnitt vorgestellte Modell wird in der Fachliteratur Wasser-fallmodell genannt. Dieser Begriff geht auf W. W. Royce [1970] zurück (vgl.Wasserfall-Modell [2005]). Er verwendet zwar nicht den Begriff „waterfall mo-del“, 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 wiefolgt aufgebaut (graphisch angelehnt an Royce):


stop

stop

stop

stop

Phase 2 Review 2

Phase 3 Review 3

Phase 4 Review 4

zurück

zurück

zurück

Phase 1 Review 1

zurück

weiter

weiter

weiter

weiter

Das Wasserfallmodell hat einen prinzipiellen Nachteil. Wenn am Ende einergroß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 Re-view genannt) mindestens zweimal zu durchlaufen. Er schlug auch vor, einzelnePhasen je nach Komplexität mehrfach zu durchlaufen.

Später hat Barry Boehm den Gedanken, einzelne Phasen mehrfach zu durchlau-fen, weiterentwickelt (Boehm [1988]). Sein Modell wird durch eine Spirale visua-lisiert, in der bestimmte Phasen immer wieder durchlaufen werden und dabei aufdie Ergebnisse des letzten Zykluses zurückgreifen. Barry Boehm nennt das Mo-dell daher auch „Spiralmodell“. Er schlägt folgende vier Phasen vor, die zyklischmehrmals 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 Zyklusesoder Projektende/-abbruch)


Ph. 1a

Ph. 3a

Ph. 2a

Ph. 4a

Ph. Ph. Ph. 4b4c4d

Ph. 1b

Ph. 1c

Ph. 1d

Ph. Ph. Ph. 2b 2c 2d

Ph. 3b

Ph. 3c

Ph. 3d

Am Modell von Boehm fällt auf, dass er ein großer Verfechter von Risikomana-gement und Prototyping ist. Prinzipiell lässt sich jedoch sein Vorschlag auf jedesWasserfallmodell anwenden. Die Vorteile liegen auf der Hand: Ein Rückschrittum eine oder gar mehrere Phasen ist wesentlich billiger und weniger zeitintensivals beim Wasserfallmodell. Design-Entscheidungen werden schrittweise getrof-fen und anschließend gleich überprüft. Auftretende Probleme werden frühzeitigerkannt.

Ich schlage daher folgendes Modell vor: Nach Abschluss der Spezifikationsphase(d. h., wenn eine Spezifikation vorliegt), werden Design und Fertigungsphase imSinne 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 Zyklusoder einer gewissen Anzahl von Zyklen wird jeweils ein großes Review mit demAuftraggeber 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 agilsteht dabei für leicht, flexibel. (siehe z. B. Oestreich und Weiss [2008])

Der erste Vertreter des agilen Software-Entwicklungsprozesses war das ExtremeProgramming von Kent Beck (Beck [2000]). Weitere Modelle, wie z. B. der Ratio-nal Unified Process (Jacobson et al. [1999], IBM [2011]) oder Scrum (Schwaber[2004]), folgten.


Allen gemeinsam ist es, kurze Iterationszyklen einzusetzen. Also kann mit Fugund Recht behauptet werden, dass Boehm mit dem Spiralmodell eine der wesent-lichen 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 Ent-wicklungsprozessen unter Berücksichtigung des gesamten System-Lebenszyklu-ses:

– Es definiert die zu erstellenden Projektergebnisse.

– Es legt Verantwortlichkeiten eines jeden Projektbeteligten fest (Auftragneh-mer + Auftraggeber).

– Es regelt detailliert „Wer“ „Wann“ „Was“ in einem Projekt zu tun hat (auchdie Kooperation zwischen Auftraggebern und -nehmern).

– Andere Richtlinien (ISO-Standards, Verfahrensanweisung CPM der Bun-deswehr, Vorgänger V-Modell 97) sind weniger konkret, aber noch im Ge-brauch.

– Für Projekte in Unternehmen und Einrichtungen des öffentlichen und militä-rischen Bereichs gedacht sowie für Behörden und Dienststellen des Bundesund der Bundeswehr.

– Auch für kleine mittelständische Unternehmen geeignet.

– Vertragsgrundlage, Arbeitsanleitung, Kommunikationsbasis

– Anwendbar auf möglichst viele Projektkonstellationen (Anpassung an kon-kretes 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 zweiProjekten: einem Projekt aus Sicht des Auftraggebers (AG) und einem Projekt ausSicht des Auftragnehmers (AN). Für Projektphasen, die von beiden gemeinsambeendet werden, müssen jeweils bestimmte, während der Projektphase vom ANoder AG erstellte Dokumente von beiden akzeptiert werden.


ProjektAG

abgeschlossen

AN

ProjektAG

definiert

ANAnforderungenAG

festgelegt

ProjektAG AN

AbnahmeAG

erfolgt

AN

beauftragtVerifizierungValidierung

Systemspezifiziert

ANLieferungdurchgeführt

AN

Systementworfen

ANSystemintegriert

AN

Feinentwurfabgeschlossen

ANSystemelementerealisiert

AN

Spezifikation und Zerlegung Realisierung und Integration

Zyklen möglich (über Änderungspläne)

ProjektAG

genehmigt

AN1 2 3 4 5Angebot

abgegeben

AN

ausgeschriebenProjektAG

14

613

15

7

8

9

12

11

10

AG ANÄnderungsplanfestgelegt

Dieser allgemeine Phasenplan kann durch Tailoring für ein bestimmtes Projektkonkretisiert werden. Zum Beispiel kann ein Projekt mit zwei Zyklen definiertwerden:

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


Änderungsplanfestgelegt

Projektbeauftragt

Abnahmeerfolgt

Abnahmeerfolgt

Projektabgeschlossen

Projektdefiniert

Projektgenehmigt

Anforderungenfestgelegt ausgeschrieben

Projekt

System

Prototyp

Projektbeauftragt

213

4

613

14

613

15

Abbildung 2.1: Phasenplan eines Systementwicklungs-Projektes mit Prototyp-Entwicklung aus Sicht des Auftraggebers (Tailoring-Ergebnis)

– Angebot enthält vertragsrelevante Teile des Projekthandbuches + Qualitäts-sicherungshandbuch

– 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 webuilding the right product?“)Verifikation (Produkt stimmt mit Spezifikation überein, „Are we building theproduct right?“)

– Abnahmeerklärung des Auftraggebers nach Lieferung

– Projektabschlussbericht des Auftragnehmers

– bei notwendigen Änderungen kann zu früheren Phasen zurückgesprungenwerden (AG: Projekt beauftragt, Anforderungen festgelegt etc., AN: System


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)

ProjektAG

abgeschlossen

AN

ProjektAG

definiert

ANAnforderungenAG

festgelegt

ProjektAG AN

AbnahmeAG

erfolgt

AN

beauftragt

Systemspezifiziert

ANLieferungdurchgeführt

AN

Systementworfen

ANSystemintegriert

AN

Feinentwurfabgeschlossen

ANSystemelementerealisiert

AN

Spezifikation und Zerlegung Realisierung und Integration

Zyklen möglich (über Änderungspläne)

ProjektAG

genehmigt

AN1 2 3 4 5Angebot

abgegeben

AN

ausgeschriebenProjektAG

613

7

8

9

12

11

10

14

AG ANProjektfortschrittüberprüft

AG ANIterationgeplant

15 16

ValidierungVerifizierung

Abbildung 2.2: Aktualisierte Version V1.3 des V-Modell XT (V-Modellr XTAutoren [2006])


Kapitel 3

Schätzung

Schätzungen (Zeit, Kosten und auch Ressourcen) werden immer schon in denersten 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 auf-grund sehr vieler unbekannter Größen meist nicht genau abgeschätzt werden. An-dererseits 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.: „Progno-sen sind besonders dann schwierig, wenn sie sich auf die Zukunft beziehen.“

1. Grundregel: Schätzungen sind keine Weissagungen, d. h. keine verbindlichenVoraussagen.

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ühwie 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 dieSchätzung.


-

Funktionalität

Kosten Zeit (Dauer)

Qualität

-

+ +

++

-

-

Wenn an einem Parameter gedreht wird, hat das einen Einfluss auf einen odermehrere andere Parameter.

Im Teufelsquadrat von Sneed [1987] ist die Produktivität eines Entwicklungssys-tems als viereckige Fläche dargestellt. Der Flächeninhalt muss (in weiten Tei-len) konstant bleiben, auch wenn die Ziele geändert werden, da die Produktivitäti. Allg. durch keine wie auch immer geartete Maßnahmen kurzfristig verbessertwerden kann (Produktivitätsverbesserungen sind nur mit langer Vorlaufzeit mög-lich; DeMarco [1998]). Das heißt, wenn zum Beispiel mehr Funktionalität in we-niger 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 einesTeams durch Vergrößerung beliebig zu steigern, da der Kommunikationsaufwandwächst. Es gibt nicht nur bei Parallelrechnern keinen optimalen Speedup, son-dern auch bei parallel arbeitenden Menschen. Eine Vergrößerung eines Teams hatzudem zunächst einen negativen Effekt: Neue Mitglieder müssen eingearbeitetwerden, alte Mitglieder werden dadurch von ihrer eigentlichen Arbeit abgehal-ten. Außerdem gilt grundsätzlich: Ein überbesetztes Team leistet stets weniger alsein richtig besetztes. Das heißt aber nicht, dass sich die optimale Teamgröße imVerlauf des Projektes nicht ändern kann. Im Allgemeinen ist es gut, ein Projektmit einem kleinen Team zu beginnen und dann, wenn alles spezifiziert ist undes nur noch um Routine-Arbeiten geht, zu vergrößern. An einem Neubau arbei-ten zunächst auch nur ein paar Architekten und Bauingenieure, bevor eine großeAnzahl von Bauarbeitern loslegt.


Für die Schätzungen hat das folgende Auswirkungen: Bei mindestens einem Para-meter sollte man einen Fehlerpuffer einplanen („on time“ oder „on budget“ – evtl.auch „on time and on budget“ mit optionalen Anteilen bei Funktionalität und/oderQualitä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 inkleinere, voneinander möglichst unabhängige „Teile“ unterteilt, diese einzelnschätzt und alle Schätzungen zu einer Gesamtschätzung aufsummiert.

2. Schätzungen fallen umso genauer aus, je mehr vergleichbare Projekte bekanntsind.

Hausbau: Kosten für ein Einfamilienhaus können mit einer Genauigkeit vonwenigen 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 einfachenBeispielen verdeutlichen.

Der Pötzseil-Case

(siehe Kupper [1993])

„Pötzseil“ ist im Kölner Sprachgut das Seil, an dem der Eimer in einem Brunnenherabgelassen wird. Der Test verläuft wie folgt: Ein längeres Seil wird in zweigleichlange Teile zerschnitten. Die eine Hälfte wird in 5-8 unterschiedlich langeTeile 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ätzungwird die richtige Länge verraten. Anschließend wird wieder die Summegebildet.


Ergebnis: „Divide et Impera“ (teile und herrsche) führt zum Ziel. Dieser Test wur-de mehrfach mit Studenten des ehemaligen Studiengangs Multimediadurchgeführt. Das Ergebnis war jedes Mal dasselbe. Die Schätzungenim zweiten und vor allem dritten Test waren deutlich besser als dieSchätzungen im ersten Test.

Gewicht des Eifelturms

π·Daumen-Schätzungen von Studenten, die die PM-Vorlesung von W. Kowar-schick 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 Stahl-klotzes, der entsteht, wenn die Leerräume entfernt werden; Gewicht von einemKubikmeter Stahl:

Zusammengedrückt nimmt der Eifelturm eine Fläche von ca. 2m · 2m ein, dieHöhe beträgt ca. 300m, Eisen (Stahl) wiegt: 7, 8 t/m3 (im Physikbuch nachge-schlagen: Kuchling [1976])⇒ Gewichtsschätzung: 300m · 2m · 2m · 7, 8 t/m3 = 9360 t

Realität (Eiffelturm [2006])

Original-Gewicht: 7 300 t (=̂ 4 kg/cm2=̂ Erwachsener auf der Sitzfläche einesStuhls)

heutiges Gewicht: 10 000 t (wg. Beton statt Stahl⇒ Rückbau geplant)

Original-Höhe: 312, 27m (mit Flagge)

heutige Höhe: 324, 00m (mit Antenne)

Bei dieser Art der Schätzung kann es natürlich immer noch passieren, dass je-mand die Grundfläche des „Eiffelturmquaders“ vollkommen überschätzt, z. B. mit10m · 10m. Die daraus resultierende Schätzung (nämlich 234 000 t) ist zwar deut-lich 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 un-terteilen.

3.2.2 Projektphasen und -vorgänge

Projektphasen

Ein Projekt sollte, wie in Kapitel 2 beschrieben wurde, auf jeden Fall in einzelnePhasen unterteilt werden. Diese Einteilung kann insbesondere, wie beim Pötzseil-Case, verwendet werden, um robuste Kosten- und Zeitschätzungen zu erstellen.


Die Gesamtdauer und die Gesamtkosten des Projektes lassen sich im Nachhin-ein ermitteln, indem man die „Dauer i“ bzw. „Kosten i“ der einzelnen Phaseni ∈ {1, ..n} aufsummiert (wobei jeweils die Dauer bzw. Kosten des zugehörigenReviews in den Werten „Dauer i“ bzw. „Kosten i“ enthalten sind):

Projektdauer =n∑

i=1Daueri Projektkosten =

n∑

i=1Kosteni

Anmerkung

Zu den Kosten können evtl. noch irgendwelche phasenunabhängige Fixkosten hin-zukommen, die gegebenenfalls bei der Berechnung der Gesamtkosten oder bei denim 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 inPhasen bzw. Vorgänge den Vorteil, dass Dauer und Kosten auch schon zu diesemZeitpunkt genauer abgeschätzt werden können, als dies ohne Phaseneinteilungmöglich wäre (Pötzseil-Case: Divide et Impera, teile und herrsche):

Projektdauermin =n∑

i=1geschätzte Daueri,min

Projektdauermax =n∑

i=1geschätzte Daueri,max

Projektkostenmin =n∑

i=1geschätzte Kosteni,min

Projektkostenmax =n∑

i=1geschätzte Kosteni,max

wobei geschätzte Daueri,min, geschätzte Daueri,max, geschätzte Kosteni,min undgeschätzte Kosteni,max Worst-Case- und Best-Case-Schätzwerte sind. Hier giltnatürlich das 2. Naturgesetz der Schätzung (Abschnitt 3.2): Je mehr vergleichbareProjekte bekannt sind, desto geringer ist die Differenz zwischen den Worst-Case-und den zugehörigen Best-Case-Schätzungen.

Wie man an diesen Formeln sieht, sollte man seine Schätzungen gleich von An-fang an mit einem Unsicherheitsfaktor versehen. Im obigen Beispiel werden fürjeden Projektabschnitt zwei Schätzwerte angegeben: Ein minimaler Wert (bestcase) und ein maximaler (worst case). In Abschnitt 3.3 werden darüber hinausnoch Dreipunkt- und Vierpunktschätzungen eingeführt: minimaler Wert, maxi-maler Wert, wahrscheinlichster Wert und evtl. noch die Wahrscheinlichkeit deswahrscheinlichsten Werts.

Wie sagt Goldratt in jedem seiner Bücher? „Murphy lebt!“


Schätzungen zu im Laufe des Projektes

Bei jedem Meilenstein j kann die Schätzung präzisiert werden:

Projektdauermin =j∑

i=1Daueri +

n∑

i=j+1geschätzte Daueri,min

Projektdauermax =j∑

i=1Daueri +

n∑

i=j+1geschätzte Daueri,max

Projektkostenmin =j∑

i=1Kosteni +

n∑

i=j+1geschätzte Kosteni,min

Projektkostenmax =j∑

i=1Kosteni +

n∑

i=j+1geschätzte Kosteni,max

wobei die Schätzwerte geschätzte Daueri,min, geschätzte Daueri,max,geschätzte Kosteni,min und geschätzte Kosteni,max für i > j anhand der bis-herigen Erkenntnisse angepasst werden können und sollten.

Auf diese Weise werden die Schätzungen, d.h. die Abweichungen zwischen Mi-nimalwerten und Maximalwerten i. Allg. immer geringer:

��

� � ��

�� "!$#&%(')��*��,+�#

�� "��

-.+��#/%�0��#21$%��


Der Nachteil dieser Art von Schätzung ist, dass zum Zeitpunkt der Projektdefi-nition, wenn also ein verbindlicher Vertrag geschlossen werden soll, der u. a. dieDauer und die Kosten festlegt, i. Allg. noch keine Einteilung in Phasen vorliegt.Schätzmethoden, die zu diesem Zeitpunkt eingesetzt werden können, werden inAbschnitt 3.4, Abschnitt 3.5 und Abschnitt 3.6 vorgestellt.

Projektvorgänge

Die Planung und Schätzung kann sogar noch feingranularer erfolgen, wenn maneine Phase wie in Kapitel 2 beschrieben weiter in einzelne Vorgänge unterteilt. ImGegensatz zu Phasen können Vorgänge allerdings durchaus parallel ablaufen.

Für die Schätzung bzw. Ermittlung der Gesamtkosten gelten die obigen Formelnweiterhin: die (bekannten oder geschätzten) Kosten aller Vorgänge werden einfachaufsummiert (gegebenenfalls werden noch bestimmte Fixkosten hinzuaddiert).

Bei der Berechnung der Gesamtdauer mit Hilfe von Vorgängen muss man aller-dings berücksichtigen, dass Vorgänge i. Allg. parallel ablaufen. Hier muss manzunächst aus der Menge aller Vorgänge eine Folge von zusammenhängenden,nicht-parallel-laufenden Vorgängen wählen. Normalerweise definiert der so ge-nannte kritische Pfad (siehe Abschnitt 4.3.1) eine derartige Folge. Allerdings istes nicht ausgeschlossen, wenn auch nur selten der Fall, dass zwei parallele Vor-gänge auf dem kritischen Pfad liegen (und es sich eigentlich um ein kritischesVorgangsnetz handelt). Erst die kritische Kette (siehe Abschnitt 4.5) besteht mitSicherheit aus einer zusammenhängenden Folge von nicht-parallelen Vorgängen.Gerade für die kritische Kette können die im Folgenden vorgestellten Schätzme-thoden ebenfalls sehr vorteilhaft eingesetzt werden.

3.2.3 Akzeptierbare Abweichungen

Schätzungen für spätere Phasen werden i. Allg. einen größeren Unsicherheits-faktor enthalten, als Schätzungen für frühere Phasen. Dies darf allerdings nichtals Freibrief verstanden werden. Schätzungen müssen von Anfang an sorgfältigdurchgefü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 Orientierungspha-se) bis 4/5 (Ende der Definitionsphase). Nach dem Ende der Designphase liegtsie kontinuierlich bei ca. 9/10. (QUELLE FEHLT [????])

Beispiel

Phase 1: +/- 5 % Kostenabweichung


Phase 2: +/- 7 % KostenabweichungPhase 3: +/- 10 % Kostenabweichung...Phase n: +/- 20 % Kostenabweichung

Das heißt, bei gegebenen Gesamtprojektkosten von beispielsweise 100 000 Euroliegt für jede Phase eine Kostenmarge fest:

Phase 1: 5 000 Euro +/- 250 EuroPhase 2: 30 000 Euro +/- 2 100 EuroPhase 3: . . .

Außerdem sollte der prozentuale Anteil des Aufwands der einzelnen Phasen vomGesamtaufwand geschätzt werden.

Phase 1: 5 % des GesamtaufwandsPhase 2: 30 % des Gesamtaufwands

Phase 2.1: 10 % des GesamtaufwandsPhase 2.2: 20 % des Gesamtaufwands

Phase 3: . . .

Beispiele (QUELLE FEHLT [????], vermutlich InformationWeek)

Bertelsmann: Hewlett-Packard:Definition: 30 % Definition: 18 %Design: 30 % Design: 19 %Codierung: 15–20 % Codierung: 34 %Test: 20–25 % Test: 29 %

Damit können Abweichungen, die sich in einer Projektphase ergeben, auf dasGesamtprojekt fortgeschrieben werden.

Solange der Projektleiter im Rahmen der vorgegebenen Zeit- und Kostenmargenbleibt, gibt es wenig Grund gegenzusteuern. Bei günstigerem Abschneiden kanner sogar einen Überschuss in die nächste Phase mitnehmen. Bei Annäherung andie Obergrenze muss er allerdings Maßnahmen ergreifen, damit er diese Grenzenicht überschreitet.

Bei jedem Review sollten neue Schätzungen für die Restphasen auf Basis derbisherigen Erfahrungen stattfinden. Sind beispielsweise die Kosten bisher in je-der Phase um 3 % überschritten worden und wird der geschätzte prozentuale Zu-sammenhang zwischen den einzelnen Phasen nicht geändert, so heißt das, dassdie 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).


Andererseits können nach einem Review die Unsicherheitsintervalle i. Allg. nachunten korrigiert und die Schätzungen des prozentualen Anteils der Einzelphasenam Gesamtaufwand verbessert werden. Daraus ergeben sich neue (minimale undmaximale) 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 einIntervall eingeplant wurde. Oftmals wird bei Schätzungen jedoch nur ein Wertermittelt. Viele Projektleiter interpretieren derartige Schätzungen so: Alles kostetmindestens 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 Kos-ten und längere Laufzeiten kommen dagegen sehr oft vor (und werden stillschwei-gend auch schon eingeplant).

Die Gründe für dieses Schieflage sind meist gar nicht unseriöse Schätzungen, son-dern die Angst, beim nächsten Projekt weniger Geld bzw. Zeit zu bekommen,wenn man zugibt, dass die Schätzungen (augenscheinlich) zu „großzügig“ wa-ren. Wenn ein Unternehmer nichts gegen dieses Angst unternimmt, dann kostetihn das viel Geld. Ein gesundes Unternehmen weiß, dass die Realität in beidenRichtungen von einer Schätzung abweichen kann, nach oben und nach unten!

Ein typisches Negativbeispiel dafür, dass diese Erkenntnis nicht immer vorhan-den ist, ist das berüchtigte Dezemberfieber z. B. in Einrichtungen des öffentli-chen Dienstes: Wenn zugewiesene Gelder in einem Jahr nicht vollständig aufge-braucht werden, geht der Geldgeber davon aus, dass der Bedarf prinzipiell zu hochgeschätzt wurde – und kürzt die Mittelzuweisungen in den Folgejahren entspre-chend. Aus diesem Grund werden spätestens im Dezember alle noch vorhandenenGeldmittel für irgendetwas ausgegeben, nur damit die Zuweisungen im nächstenJahr nicht gekürzt werden.

Aufgrund der Tatsache, dass es bei der hier vorgestellten Art der Schätzung ver-schiedene Schätzwerte gibt (Minimum, Erwartungswert, Maximum), sollten dieSchätzungen sogar dreifach durchgeführt werden.

Projektkosten/dauer unter optimalen Bedingungen

Projektkosten/dauer unter normalen Bedingungen

Projektkosten/dauer unter schwierigen Bedingungen (worst case ohne Kata-strophen)


3.3 Schätzungen von Phasen und Vorgängen

In den folgenden Beispielen beziehe ich mich stets auf Schätzungen von Zeiträu-men. Für die Schätzung von Kostenspannen gelten dieselben statistische Gesetz-mäßigkeiten.

Mit Ausnahme von PERT (Malcolm et al. [1959], Miller [1963]) basieren dieetablierten Projektmanagement-Methoden auf der so genannten Einpunkt-Schät-zung: Für jede zu schätzende Dauer und jeden zu schätzenden Kostenfaktor wirdein Wert geschätzt – und dann für bare Münze genommen.

Das wirkliche Leben ist jedoch anders. Murphy lebt! Wenn man mich fragt, wielange 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 imStau 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 ersteMal seit 1998 geschafft!)

– 20 Minuten?(Das schaffe ich oft, selten geht es schneller, meist dauert es ein paar Minu-ten 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ängtdie Antwort von seiner Erfahrung ab. Ein Anfänger würde im obigen Fall mit 15Minuten 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 han-delt. Bei einem wichtigen Vorgang antwortet er „60 Minuten“, weil er sich sicherist, dass er ihn in dieser Zeit auch erledigen kann.

Und sein Chef und dessen Chef schlagen vorsichtshalber jeder nochmal 30 Mi-nuten drauf, für den Fall, dass der Big-Boss das Ganze um 20 % kürzt. Und sokommt 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ätzungenfür unglaubwürdig gehalten würden (vgl. Dezemberfieber).

Erschwerend kommt hinzu, dass er für die Erledigung mehr Zeit als notwendighat und deshalb leicht dem Studentensyndrom erliegt (Abbildung 1.3).


Wenn im letzten Drittel etwas schief geht, dauert die Realisierung noch länger alsgeschätzt, obwohl bereits sehr viel Puffer in der Schätzung enthalten war.

Aus langjähriger Erfahrung kann ich Goldratts Beobachtungen bestätigen: EineAbschlussarbeit (Bachelor, Master, Diplom) wird normalerweise erst am Stichtag,häufig sogar erst 5 Minuten vor der angegebenen Uhrzeit abgegeben – oder es wirdeine Verlängerung beantragt. Es kommt schon mal vor, dass eine Arbeit einigeTage „zu früh“ abgegeben wird. Aber es passiert nur äußerst selten, dass sie einenMonat vor dem Stichtag fertig ist. Und das ist auch nur dann der Fall, wenn einanderer triftiger Grund für diese Eile vorliegt (Student hat Zusage für Arbeitsplatzo.Ä.).

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 er-mittelt.

– 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 Wahrscheinlichkeitsverteilungfestgelegt werden. Goldratt und DeMarco verwenden Dichtefunktionen, die gutdurch die Beta-Verteilung beschrieben werden können. Aber auch die einfachereDreiecksverteilung 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 Dreiecks-verteilung XD folgendermaßen definiert (vgl. Abbildung 3.1, Dreiecksverteilung[2006], Rinne [2003]):

fD(x) :=

2(x−a)(b−a)(c−a)

für a ≤ x ≤ c

2(b−x)(b−a)(b−c)

für c < x ≤ b

0 sonst

Dichte der Beta-Verteilung

Es seien a, b, α, β ∈ R mit a < b und α, β ≥ 1. Dann ist die Dichte fB der Be-ta-Verteilung XB folgendermaßen definiert (vgl. Abbildung 3.1, Beta-Verteilung[2006], Rinne [2003]):


Abbildung 3.1: Beta- und Dreiecksverteilung von Wolfgangs Fahrt zur HSA

fB(x) :=

(x−a)α−1·(b−x)β−1

B(α−β)(b−a)α+β−1für a ≤ x ≤ b

0 sonst

Dabei ist die Beta-Funktion folgendermaßen definiert:

B(α, β) :=

1∫

0

tα−1(1 − t)β−1dt =Γ(α) · Γ(β)

Γ(α + β)

Die Beta-Funktion kann also durch die Gammafunktion, das ist die Verallgemei-nerung der Fakultätsfunktion n!, ausgedrückt werden (Bronstein und Semendja-jew [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 ver-wendet, sagt diese für das Beispiel der Fahrt zur HSA aus, dass Wolfgang spätes-tens nach 60 Minuten mit Sicherheit am Ziel ist. Dies entspricht allerdings nichtder Realität. Wolfgang kann auch einen Unfall haben und erst Tage oder Wochenspäter oder auch gar nicht mehr kommen. Während man extrem lange Verzöge-


rungen theoretisch auch mit extrem langgezogenen Beta-Verteilungen modellie-ren kann wird der Fall, dass ein Vorgang und damit evtl. das ganze Projekt nichtbeendet 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]) oderder Weibull-Verteilung (Rinne [2003]) modellieren.

DeMarco und Lister [2003] schlagen dagegen vor, den vollständigen Projektab-bruch als ein explizites Risiko zu modellieren.

Im Folgenden gehen wir jedoch davon aus, dass die Dauer eines Vorgangs mit ei-ner Dreipunktschätzung (d. h. mit einer Dreiecksverteilung oder Beta-Verteilung)oder einer Vierpunktschätzung (d. h. mit einer Beta-Verteilung, bei der auch derModalwert, d. h. die Höhe der Dichte am Punkt c geschätzt wird) hinreichend ge-nau beschrieben werden kann.

Verteilungsfunktionen

Welche Informationen hält die Dichtefunktion, die für eine Schätzung ermitteltwird, für uns bereit? Um diese Frage zu beantworten, muss man sich ein weniggenauer mit den Eigenschaften von Wahrscheinlichkeitsverteilung befassen.

Zu jeder stetigen Dichte f(x) gibt es die Wahrscheinlichkeitsverteilungs-FunktionF (x):

P (X ≤ x) := F (x) :=x∫

−∞f(t) dt

Für die Dreiecksverteilung XD gilt (Dreiecksverteilung [2006]):

FD(x) :=

0 für x < 0

0 +(x−a)2

(b−a)(c−a)für a ≤ x ≤ c

1 +(b−x)2

(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

(60− 15)(20 − 15)=

25

45 · 5 =1

9=̂ 11, 1%

Es ist schon erstaunlich, dass ich es im Schnitt nur jede zweite Woche an einemTag wirklich in 20 Minuten oder weniger schaffe (wenn man diese Verteilung zuGrunde legt).

Man kann die Frage auch umkehren. Wie viel Fahrtzeit muss ich einplanen, damitich in 50 % oder gar 95 % der Fälle rechtzeitig ankomme?


Dies kann mit Hilfe der Umkehrfunktion F−1 für die Verteilungsfunktion F be-rechnet werden:

F−1D (p) :=

{

a + (b− a)√

mp für p ≤ m

b− (b− a)√

(1 −m)(1− p) für p > m

wobei m := c−ab−a

F−1(p) wird p-Quantil oder p-Perzentil genannt (wobei F eine Verteilungsfunk-tion ist, für die F−1 existiert).

Das 50 %-Quantil und das 95 %-Quantil berechnen sich für unser Beispiel wiefolgt:

m = 20−1560−15 = 5

45 = 19

F−1D (0, 5) = 60 − (60 − 15)

√

(1 − 1

9)(1− 0, 5)

= 60 − 45

√

8

9· 1

2= 30

F−1D (0, 95) = 60 − (60− 15)

√

(1− 1

9)(1 − 0, 95)

= 60 − 45

√

8

9· 0, 05

= 50

Um also in 50 % der Fälle rechtzeitig an die HSA zu kommen, müsste ich 30Minuten Fahrtzeit einplanen. Und 50 Minuten Fahrzeit ergeben sich, wenn ich bei95 % 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-VerteilungXB beschreibt die reale Situation besser. Ihre Verteilungsfunktion ist folgender-maßen definiert (Statistik [2006]):

FB(x) :=

x∫

−∞fβ(t)dt

Leider lassen sich weder die Verteilungsfunktion FB noch die zugehörige Um-kehrfunktion F−1

B der Beta-Verteilung mit geschlossenen mathematischen For-meln beschreiben, sondern müssen algorithmisch (z. B. mit Fixpunktiteration)ermittelt werden. Tools wie Mathcad (PTC [2011]) stellen allerdings geeigneteFunktionen zur Verfügung.


Abbildung 3.2: Beta-Verteilung

Für die obige Beta-Verteilung ergeben sich bessere Schätzwerte als bei der Drei-ecks-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, dassder Modalpunkt von fB bei c liegt und dort den Wert 0,075 annimmt.

FB(20) = 0, 284 =̂ 28, 4%

F−1B (0, 5) = 23 (50 %-Quantil = Median)

F−1B (0, 95) = 35 (95 %-Quantil)

Das heißt, in knapp 30 % der Fälle schaffe ich es wirklich in 20 Minuten oderweniger. 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, kommeich nur noch in 5 % der Fälle zu spät. Diese Zeiten treffen die Realität schon ganzgut. In Wirklichkeit komme ich nur in höchstens 2% der Fälle zu spät, wenn ich 35Minuten Fahrzeit einplane. Das heißt, der Wert am Modalpunkt wurde mit 0,075vermutliche etwas zu niedrig gewählt.

3.3.1 Erwartungswert und Standardabweichung

Das 50 %-Quantil (der Median) kann relativ gut mit dem Erwartungswert abge-schätzt werden. 50 %-Quantil und Erwartungswert unterscheiden sich allerdingsumso mehr je unsymmetrischer die Verteilung ist.


Erwartungswert einer Dreiecksverteilung XD:

µ(XD) =a + b + c

3

Erwartungswert einer Beta-Verteilung XB :

µ(XB) =αb + βa

α + β

Für unser Beispiel ergibt sich:

µ(XD) =15 + 60 + 20

3= 31, 7 ≈ 30 (50 %-Quantil)

µ(XB) =1, 74 · 60 + 6, 91 · 15

1, 74 + 6, 91= 24, 1 ≈ 23 (50 %-Quantil)

Die Streuung um diesen Erwartungswert wird mit Hilfe der Standardabweichungberechnet:

σ(XD) =b− a

6

√

2(1 −m + m2), wobei m =c− a

b− a

σ(XB) =b− a

α + β

√

αβ

α + β + 1

Für unser Beispiel ergibt sich:

σ(XD) =60 − 15

6

√

2(1 − 1

9+ (

1

9

2)) = 10, 1

σ(XB) =60 − 15

1, 74 + 6, 91

√

1, 74 · 6, 911, 74 + 6, 91 + 1

= 5, 8

3.3.2 Zentraler Grenzwertsatz der Statistik

Zur Abschätzung der Gesamtdauer einer Folge von Vorgängen, bei denen die je-weilige Einzeldauer mit Hilfe irgendwelchen Verteilungen (Dreieecksverteilung,Beta-Verteilung etc.) geschätzt wird, kann mit dem zentralen Grenzwertsatz derStatistik (Bronstein und Semendjajew [1980]) erfolgen.

Dieser besagt, dass unter bestimmten Voraussetzungen, die Summe einer Men-ge von Zufallsgrößen X1, . . . ,Xn angenähert normalverteilt ist. Der Erwartungs-wert, die Varianz und die Standardabweichung dieser Normalverteilung könnendabei wie folgt abgeschätzt werden:


µ

(

n∑

i=1

Xi

)

≈n∑

i=1

µ(Xi)

V ar

(

n∑

i=1

Xi

)

≈n∑

i=1

V ar(Xi)

und da die Standardabweichung die Wurzel aus der Varianz ist:

1 · σ(

n∑

i=1

Xi

)

≈

√

√

√

√

n∑

i=1

(1 · σ(Xi))2

2 · σ(

n∑

i=1

Xi

)

≈

√

√

√

√

n∑

i=1

(2 · σ(Xi))2

3 · σ(

n∑

i=1

Xi

)

≈

√

√

√

√

n∑

i=1

(3 · σ(Xi))2etc.

Der Erwartungswert der Summe ist also ungefähr gleich der Summe der Erwar-tungswerte und die Varianz der Summe ist ungefähr gleich der Summe der Varian-zen. Besonders interessant ist, dass die Standardabweichung der Summe ungefährgleich der Wurzel aus der Summe der Quadrate der einzelnen Standardabwei-chungen ist. Dieser Wert ist i. Allg. deutlich kleiner als die Summe

∑

σ(Xi) dereinzelnen Standardabweichungen. Das heißt, die Streuungen der einzelnen Ver-teilungen 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: DieSchätzungen der einzelnen Phasen oder Vorgänge sind voneinander unabhängig,die Schätzungen sind sind klein verglichen mit der Gesamtsumme (d. h. es gibtkeine 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ätzungquantifiziert 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%


Abb

ildu

ng3.

3:S

tand

arda

bwei

chun

gen

der

Nor

mal

vert

eilu

ng


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 (oderzumindest nie darstellen sollten). Daher propagiere ich, dass im Projektmanage-ment 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 abzu-schätzen, bis zu welchem Zeitpunkt alle Vorgänge mit ca. 84%, 98% oder gar99,9 % Wahrscheinlichkeit beendet sind, geht man daher folgendermaßen vor:

1. Man ermittelt für alle Phasen (oder kritischen Vorgänge) den jeweiligen Er-wartungswert µi und die Standardabweichung σi;

2. Man berechnet den Erwartungswert und die Standardabweichung der Summe

der Vorgänge: µ =∑n

i=1 µi, σ =√

∑ni=1 σ2

i ;

3. Man berechnet den Wert µ + σ, µ + 2σ oder µ + 3σ, je nach gewünschterSicherheit.

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 c b p(c) Verteilung µi σi1 6 9 Dreiecksverteilung 5,33 1,653 7 19 0,13 Beta-Verteilung 8,33 2,855 6 8 0,87 Beta-Verteilung 6,10 0,441 5 9 0,21 Beta-Verteilung 5,00 1,634 6 9 0,5 Beta-Verteilung 6,10 0,74

Summe 30,87 7,31

σ =√

σ21 + σ2

2 + σ23 + σ2

4 + σ25 = 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


� � �

� � � �

� � � �

� � � �

� � � �

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 Abbil-dung 3.5 wird die Schätzung der Gesamtdauer für die zuvor geschätzten fünf Pro-jektphasen illustriert. Das Histogramm (durchgezogene Linie) wurde mit Hilfeeiner Monte-Carlo-Simulation (Gellert und Kästner [1979]) ermittelt: Dabei wur-de 30 000 mal für jede Phase ein Zufallswert gemäß der geschätzten Verteilungs-funktion berechnet. Diese fünf Schätzwerte wurden jeweils zu einer Gesamtsum-


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 Zentra-len Grenzwertsatzes aus den fünf Dichtefunktionen berechnet wurde. Sie wurdeso skaliert, dass die Höhe mit der Höhe des Histogramms übereinstimmt. Für dieseVerteilung 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 Projektmit einer Wahrscheinlichkeit von 95 % innerhalb von 23 bis 38 Tagen fertig ge-stellt wird. Noch wichtiger ist das Ergebnis der 84/98/99,9-Regel: Das Projektwird mit einer Wahrscheinlichkeit von 98 % in maximal 38 Tagen fertiggestellt.

Wie man an der Monte-Carlo-Simulation deutlich erkennen kann, ist diese Schät-zung etwas zu pessimistisch. Eigentlich liegen der Erwartungswert und das95 %-Intervall einen Tag früher. Das kommt daher, dass lauter linkslastige Schät-zungen verwendet wurden.

Daran, dass selbst bei lediglich fünf Phasen die Abweichung unter 5 % liegt, siehtman, wie gut der zentrale Grenzwertsatz funktioniert. Die Ungenauigkeit, die sichdurch die Verwendung des Grenzwertsatzes ergibt, beträgt lediglich einen Tag.Bei 15 Phasen (siehe Abbildung 3.6) ist die Abweichung schon nicht mehr derRede wert (unter 1 %).

Abbildung 3.6: Simulation und Schätzung: Dauer von 15 Phasen


Anmerkung

Die84/98/99,9-Regel besagt, dass, wenn man für jedes Projekt lediglich 1σ alsGesamtpuffer vorsieht, jedes sechste Projekt nicht rechtzeitig fertiggestellt wird(zumindest, wenn man den Puffer auch wirklich als Puffer benutzt; vgl Ab-schnitt 4.5). Daher ist ein 1σ-Puffer sicher ein guter Kompromiss, wenn man denKunden kurze Projektlaufzeiten anbieten und dennoch einen Gewinn aus dem Pro-jektergenissen 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:

c

unendlich

c

1

VerteilungDichteSicheres Ergebnis

(Standardabweichung ist fix)Normalverteilung

c


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ätz-werte und definieren für andere Freiheitsgrade gegebenenfalls geeignete Default-werte. Beispiele:

a bRechtecksverteilung

caF−Verteilung, Log−Normalverteilung ...

Normalverteilunga b

Normalverteilung: a = µ− 2σ, b = µ + 2σ ⇒ µ = b+a2 , σ = b−a

4

Dreipunkt-Schätzung

– frühestens fertig nach a Tagen,spätestens fertig nach b Tagen,vermutlich fertig nach c Tagen (höchste Wahrscheinlichkeit),oder an Stelle von b: d = p(c) (Modalwert)

– minimale Kosten a,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ätzwerteund definieren für andere Freiheitsgrade gegebenenfalls geeignete Defaultwerte.Beispiele:

bcDreiecksverteilung Beta−Verteilung

bcaa caF−Verteilung,Log−Normalverteilung ...

d


Vierpunkt-Schätzung

– frühestens fertig nach a Tagen,spätestens fertig nach b Tagen,vermutlich fertig nach c Tagen (höchste Wahrscheinlichkeit),d = p(c) (Modalwert)

– minimale Kosten a,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 dieBeta-Verteilung:

Beta−Verteilunga bc

d

Beta−Verteilunga bc

d

PERT

Für PERT wird eine Beta-Verteilung verwendet, bei der Erwartungswert und Stan-dardabweichung folgendermaßen abgeschätzt werden:

µ =a + 4c + b

6, σ =

b− a

6

Laut Frank Grubbs [1962] ist die Schätzung für folgende α- und β-Werte korrekt:

α = 3 +√

2, β = 3 −√

2 (rechtslastig)α = 3−

√2, β = 3 +

√2 (linkslastig)

Für alle anderen Beta-Verteilungen sind diese Approximationen falsch und meistauch ziemlich schlecht.


3.4 Delphi-Methode

Schätzungen sollten von Experten, d. h. von Personen mit Erfahrung im zu schät-zenden Gebiet vorgenommen werden. Wenn man mehrere Experten unabhängigvoneinander Schätzungen vornehmen lässt und die Ergebnisse dann mittelt, erhältam 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, dievon der Rand-Corporation in den 1960er-Jahren entwickelt wurde. Hier schätzenmehrere Experten zunächst unabhängig voneinander. Anschließend präsentierensie ihre Ergebnisse den anderen Experten und begründen ihre Schätzwerte. Esist dabei nicht notwendig, dass ein Experte den anderen überzeugt, es geht nurdarum, dass sich die anderen Experten mit anderen Aspekten, die die Schätzungbeeinflussen 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 problem-los so verallgemeinern, dass ein minimaler und ein maximaler Schätzwert als Er-gebnis ermittelt werden. Zunächst müssen die Experten jeweils zwei Schätzwerte(Minimum und Maximum) abgeben. Und zum Schluss kann man die Minima unddie Maxima entweder mitteln oder – um ganz auf Nummer sicher zu gehen – dasjeweils absolute Minimum und das absolute Maximum als Schätzwerte verwen-den.


3.5 Die Function-Point-Methode

Diese Methode wurde von Alan Albrecht bei IBM in den späten 70er-Jahren ent-wickelt (Albrecht [1979]) und ist heute als ISO-Norm standardisiert (ISO/IEC20926:2009 [2009]). Sie basiert auf Analogieschluss und Gewichtung.

Grundidee: Ein Vorhaben wird in verschiedene Grundfunktionen zerlegt. Ur-sprü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 ganzunterschiedlichen Grundfunktionen eingesetzt werden .

Dann wird für jede Grundfunktion Art (siehe oben), Umfang (z. B. LOC) undKomplexität (z. B. leicht, mittel, schwer) festgelegt. Abhängig von einer firmen-spezifischen Function-Point-Funktion f(Art, Umfang, Komplexität) werden jederGrundfunktion so genannte Function Points zugeordnet.

Aus der Summe der Function Points kann der Gesamtaufwand abgeschätzt wer-den.

Abbildung 3.7: Eine mögliche Schätzfunktion für die FP-Methode


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) vor-

nehmen, wenn man für jede Grundfunktion drei entsprechendeFunction-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 An-fang des Projektes oft problematisch.

Der Function-Point-Graph ist umso nützlicher, je geringer die einzelnen Punk-te von Approximationslinie abweichen. Laut DeMarco [2001] gibt es wissen-schaftliche Studien, die ein hochinteressantes Ergebnis haben: Wenn man die Ab-schätzung des Arbeitsaufwandes nicht tagesgenau, sondern stundengenau macht(und dabei geleistete Überstunden berücksichtigt), wird die Streuung größer undnicht etwa kleiner! Fazit: Die tagesgenaue Schätzung ist viel aussagekräftiger. DerGrund dafür ist: Ein Mitarbeiter leistet jeden Tag ungefähr dasselbe unabhängigdavon, ob er „nur“ 8 Stunden arbeitet oder 12 Stunden. Überstunden haben kei-nerlei positiven Effekt (aber viele negative Effekte)!!


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 gemau-sert. 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 Li-nes of Code (KSLOC). Man findet auch die Bezeichnung Kilo Delivered SourceInstructions (KDSI). Das sind die Anzahl der ausgelieferten Befehle (Schleifen,Zuweisungen, Vergleiche), nicht einfach die Anzahl der Befehlszeilen (Lines ofCode = LOC). In COCOMO II können auch Function Points, Use Cases etc. zurSchätzung herangezogen werden. Diese werden durch das so genannte Backfiringin KSLOC umgerechnet. Allerdings sind diese Werte häufig nicht sonderlich starkkorreliert (Seibert [2005]).

Bei COCOMO werden drei Arten von Projekten unterschieden:

organic: kleines Projekt (< 50 KSLOC), kleines Team, erfahrende Pro-grammierer, stabile Entwicklungsumgebung

semi-detached: größeres Projekt (50 – 300 KSLOC), Programmierer mit unter-schiedlichen Erfahrungsleveln; Mittelding zwischen organic undembedded

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 Ent-wicklungszeit und die Teamgröße mittels einfacher Formeln aus den geschätztenKSLOC ebenfalls abgeschätzt werden.

Für die Schätzmethode werden in Basic COCOMO folgende Zahlen verwendet:

Personenmonate (PM) Dauer Anzahl Mitarb.

organic 2, 4 · KSLOC1,05 2, 5 · PM0,38 PM/Dauer ≈ 0, 7 · KSLOC0,651

semi-detached 3, 0 · KSLOC1,12 2, 5 · PM0,35 PM/Dauer ≈ 0, 8 · KSLOC0,728

embedded 3, 6 · KSLOC1,20 2, 5 · PM0,32 PM/Dauer ≈ 0, 96 · KSLOC0,816

Bei der Schätzung gemäß Intermediate COCOMO werden neben der Anzahl derausgelieferten Codezeilen weitere so genannte Kostentreiber berücksichtigt.

Die Projektdauer wird mit folgenden Formeln ermittelt:


PM Dauer

organic 3, 2 · KSLOC1,05 · f 2, 5 · PM0,38

semi-detached 3, 0 · KSLOC1,12 · f 2, 5 · PM0,35

embedded 2, 8 · KSLOC1,20 · f 2, 5 · PM0,32

Der Effort Adjustment Factor f wird dabei durch Multiplikation von „Gewichten“für weitere Kostentreiber ermittelt. Für jeden von fünfzehn Kostentreiber wird derAufwand geschätzt und gemäß der nachfolgenden Tabelle gewichtet (deutscheÜbersetzung von W. Kowarschick):

sehr sehr extremKostentreiber gering gering normal hoch hoch hochProduktmerkmaleErforderlicheSystem-Zuverlässigkeit

0,75 0,88 1,00 1,15 1,40

Datenbankgröße 0,94 1,00 1,08 1,16Komplexität des Produktes 0,70 0,85 1,00 1,15 1,30 1,65PlattformmerkmaleAnforderungen an Laufzeit-performanz

1,00 1,11 1,30 1,66

Hauptspeicherbedarf 1,00 1,06 1,21 1,56Änderungshäufigkeit der Sys-temumgebung

0,87 1,00 1,15 1,30

Anforderungen an Antwort-zeiten

0,87 1,00 1,07 1,15

PersonalmerkmaleAnalysefähigkeiten 1,46 1,19 1,00 0,86 0,71SW-Entwicklungs-Fähigkeiten 1,29 1,13 1,00 0,91 0,82Erfahrungen imAnwendungsgebiet

1,42 1,17 1,00 0,86 0,70

Erfahrungen mit derSystemumgebung

1,21 1,10 1,00 0,90

Erfahrungen mit derProgrammiersprache

1,14 1,07 1,00 0,95

ProjektmerkmaleVerwendung von Software-Entwicklungstools

1,24 1,10 1,00 0,91 0,82

Einsatz von Software-Engineering-Methoden

1,24 1,10 1,00 0,91 0,83

Anforderungen an Entwick-lungsdauer

1,23 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 herangezo-gen werden. Die zugehörigen Schätzwerte werden durch das so genannte Back-firing in KSLOCs umgerechnet. Allerdings sind die Umrechnungstabellen nochnicht sehr ausgereift.

Bei der Entwicklung von Software kann die Wiederverwendung von Code berück-sichtigt 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 Ar-chitekturen und Entwicklungsstrategien, wenn viele Details des zu schätzen-den 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 Pro-jektdauer in Monaten (M) werden in COCOMO II ähnliche Funktionen wie inCOCOMO verwendet, allerdings mit anderen Parametern (die folgenden Formelnwurden vereinfacht – ohne Wiederverwendung von Code und Entwicklungszeit-verkürzung):

PM = A · KSLOCE · f (Projektaufwand)M = C · PMF (Projektdauer)

wobei


A = 2, 94B = 0, 91C = 3, 67D = 0, 28

E = B + 0, 01 ·5∑

j=1

Fj

F = D + 0, 2 · (E −B)

gesetzt wird. Die fünf Faktoren Fj werden projektabhängig aus den folgendenOrganisationsfaktoren ermittelt:

Organisationsfaktoren

– Erfahrungen im Produktbereich

– Entwicklungsflexiblität

– Ausgereiftheit des Entwurfs

– Stakeholder-Zusammenhalt

– Software-Prozessreife

Der Effort Adjustment Factor f wird wieder durch Multiplikation von „Gewich-ten“ für weitere Kostentreiber ermittelt. Dabei wurden in COCOMO II einige Kos-tentreiber leicht modifiziert und deren Anzahl etwas erhöht (deutsche Übersetzunggemäß 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


– 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 Ein-satz, für die Schätzungen der ersten Projektphasen werden nur sieben und teilwei-se 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 Vor-hersagen zu machen. (Elzer [1994])

Faustregel: π ·Daumen

Schätze die Größe des Codes (LOC) und teile sie durch die vom Team-leiter geschätzte Produktivität des Teams (LOC/Monat) und multipli-ziere dies mit dem Kosten eines Monats.

Diese Regel ist nicht schlechter, als viele kompliziertere Regeln (obwohl sie nurdrei Parameter berücksichtigt und nur einen linearen Zusammenhang beschreibt).

Siba N. Mohanty hat 1981 ein 36-KLOC-Projekt benutzt, um die Vorhersagequa-lität von verschiedenen Kostenmodellen zu untersuchen. (Mohanty [1981]) DieErgebnisse sind erschütternd (und werden im Wesentlichen von Folgeuntersu-chungen bestätigt):


Verfahren Anzahl Kosten DauerEinflussgrößen (Dollar) (Monate)

1 Farr und Zagorski 13 362.5002 Naval Air Dev. Center 13 2.001.4103 Wolverton (einfach) 15 925.200

Wolverton (mittel) 1.138.680Wolverton (schwer) 1.359.936

4 Kustanowitz 5 1.600.000– 2.766.667 19,6 – 25,8

5 Aerospace 4 1.342.2506 GRC 4 1.224.5157 SDC 12 1.200.5858 Price-S 10 1.330.000 189 Walston and Felix 2 565.000 13,77

10 Aron 4 530.57611 Schneider 3 880.29012 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 Jahrprogrammieren, testen und integrieren kann, das sind 167 LOC pro Monat oder10 LOC pro Tag.

Das Verfahren π · Daumen liefert dann für das von Mohanty defi-nierte 36-KLOC-Beispielsprojekt folgende Kostenschätzung: 36.000 LOC

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 Ren-nen.

Fazit

Der höchste Schätzwert ist 7,6 mal so hoch wie der niedrigste. Das sind eigentlichkeine brauchbaren Ergebnisse!

Mohanty führt dieses Ergebnis darauf zurück, dass den jeweiligen Schätzmetho-den firmenspezifische Schätzparameter zu Grunde liegen. Er vermutet außerdem,dass sich die einzelnen Methoden hinsichtlich der Ansprüche an die Qualität desErgebnisses unterscheiden. Dies ist aber nur ein Spezialfall der Beobachtung, dassbei verschiedenen Unternehmen verschiedene Randbedingungen gelten.

Aus der Beobachtung von Mohanty folgt, dass Schätzmethoden, die nicht auf dasjeweilige Unternehmen kalibriert werden, sind nicht sonderlich aussagekräftig.Oder andersherum: Schätzmethoden, wie die Function-Point-Methode, COCO-MO etc., sind wesentlich genauer, wenn sie kalibriert werden, d. h., wenn die


Schätzparameter der jeweiligen Methode durch mathematisch-statistische Ana-lyse historischer Projektdaten an die Verhältnisse des jeweiligen Entwicklungsbe-reiches 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 mitKalibrierung mit Standard-COCOMO-Schätzungen verglichen. Das Ergebnis die-ser Untersuchung ist, dass die Vorhersagen durch die Kalibrierung wesentlich bes-ser 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-Ca-se) und möglichst bekannte Werte aus vergleichbaren Projekten berücksichtigen(Analogieverfahren + Gewichtung, wie z. B. eine moderne Function-Point-Me-thode). Außerdem sollten Schätzungen nicht vom Projektleiter allein, sondern vonmehreren Experten vorgenommen werden (Expertenschätzung). Deren Schätzun-gen sollten nicht zu weit auseinander liegen, da sonst vermutlich noch nicht alleFakten bekannt sind und damit berücksichtigt werden (vgl. „Die fünf Weisen“).

Die ursprünglichen Formeln von COCOMO II wurden auf Basis von 160 Projek-ten ermittelt. Diese Basis ist im Laufe der Zeit auf 250 Projekte angewachsen.Für COCOMO-Varianten ist die Zahl der zugrundeliegenden Projekte dagegenteilweise noch recht gering. (Seibert [2005])

Beispiel: COCOTS zur Schätzung der Kosten für Evaluation, betriebsspezifischenAnpassung und Integration von Standardsoftware basierte im Jahr 2005 auf ledig-lich 20 Projekten.

COCOMO II wird laut Aussage von Barry Boehm laufend weiter entwickelt. DieUmrechnungstabellen von Function Points in KSLOC sind noch großen Änderun-gen unterworfen. Auf die Frage, ob Backfiring bereits praktisch eingesetzt werdenkann, 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 ent-wickelt. Beispielsweise bietet die Cost Xpert Tool Suite (Cost Xpert [2011a]) derFirma Cost Xpert, einem Co-Autor der COCOMO-II-Methode, COCOMO-Schät-zungen an, die – laut Aussage von Cost Xpert – schon „out of the box“ mit einerGenauigkeit von ±20% aufwarten können. Bei einer Kalibrierung der Projekt-datenbank auf firmenspezifische Projekte soll sogar eine Abweichung von unter±10% zwischen den Schätzungen und den späteren wirklichen Werten die Regelsein. (Cost Xpert [2011b])


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 etwa1600 = 200 · 8

Das heißt, man muss sich zunächst einmal darauf verständigen, was die BegriffePJ, 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 Monateverteilt:

– 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 Aufgabenunberücksichtigt.


Ich führe daher zusätzlich den Begriff der Projektarbeitszeit ein, die nur die Ar-beitszeit berücksichtigt, die ein Mitarbeiter tatsächlich für das zugehörige Projektaufbringt (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 theoretischauch 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 über-ein. Im Allgemeinen können jedoch nur wenige Mitarbeiter von anderen Aufga-ben entlastet werden. Dies ist aber auch gar nicht notwendig. Nur die Mitarbeiter,die kritische Vorgänge bearbeiten, sollten von projektfernen Arbeiten möglichstferngehalten werden. Vor allem im Critical-Chain-Projekt-Management (sieheAbschnitt 4.5) ist es üblich, Mitarbeiter, die an der so genannten kritischen Kettearbeiten, vollkommen von anderen Aufgaben zu entlasten.

Mit welchen Begriffen man arbeitet ist letztlich egal, wenn sich alle Projektbetei-ligten einig sind, was unter PJ, PM und PT zu verstehen ist. Auf eine stundenge-naue Schätzung sollte man allerdings verzichten. Ein Mitarbeiter leistet an einem12h-Tag i. Allg. weniger als an einem 8h-Tag (DeMarco [1998]).

Solange nicht bekannt ist, was PJ, PM, PW und PT genau bedeutet, kann dieMonatsproduktivität allerdings nicht in Jahres- oder Tagesproduktivitäten umge-rechnet werden.

Die Produktivität wiederum ist wichtig, um z. B. den Bedarf an Mitarbeitern fürbestimmte Aufgaben zu ermitteln.

Die Produktivität eines Programmierers wird häufig in LOC/PM (LOC = Linesof Code) oder NCSS/PM (NCSS = Non Commented Source Statements – HP– schlecht, da Kommentare nichts zählen, aber wichtig sind) gemessen. Nebendem 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ätigkeitdes Spezialisten abhängen.


Beispiel

Aufgabe: 200 LOC-Programm erstellen

Produktivität: 25 LOC/(PT ·MA) (MA = Mitarbeiter)

Dauer: 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 Personen-monat andere Werte hat. Wenn man davon ausgeht, dass eine Person in einemJahr eine gewisse Leistung (z. B. 2000 LOC) erbringen kann, ergibt sich folgen-des 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 = 200 LOC/PMPA =47 LOC/PWPA = 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 dieZuordnung reale Zeit ↔ Projektzeit einfacher ist. August, Osterwoche, Pfingst-woche, 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 Ta-ge/Monat) lieber, als die übliche Vollarbeitszeiten, da auch diese Werte leichtermit der Realität in Einklang zu bringen sind.

Wenn ich drei Aufgaben à 6 PTPA bearbeiten lasse und erhalte nach einem rea-len Monat das gewünschte Ergebnis, habe ich rein rechnerisch sogar etwas Zeitgewonnen (da 18 PTPA = 1, 125 PMPA).

Ein Mitarbeiter muss im Durchschnitt etwas mehr leisten als geplant, da Krankheitund Dienstreisen den Durchschnitt drücken. Wenn man die üblichen Ferienmona-te, 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.


erstes (bereits gelöstes) Problem

Alle anderen Definitionen von Personenmonaten etc. sind im laufenden Projektschwieriger 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 Quelleanzugeben), die ein erstaunliche Ergebnis liefern.

Eine Function-Point-Schätzfunktion wird durch Minimierung der Summe der Ab-standsquadrate einer Menge von bekannten FP-Werten bereits abgeschlossenerProjekte ermittelt (vgl. Abbildung 3.7). Je kleiner diese Summe der Abstandsqua-drate ist, desto brauchbarer ist die Schätzfunktion.

Nun sollte man vermuten, dass eine Verfeinerung der Messung auch eine Ver-kleinerung der Summe der Abstandsquadrate zur Folge hat. Wenn man also dieGesamtpunktzahl jedes einzelnen Projekts anhand der Personenstunden ermittelt,sollte man eine bessere Schätzfunktion erhalten, als wenn man dies Gesamtpunkt-zahlen anhand der Personentage ermittelt, da im ersten Fall Überstunden berück-sichtigt werden und im zweiten nicht.

Doch das Gegenteil ist der Fall. Wenn man die Berechnung auf Basis der Perso-nenstunden vornimmt wird die Summe der Fehlerquadrate größer!

Das heißt, dass das Maß „Personentag“ die Produktivität der Mitarbeiter genauerbeschreibt, als das Maß „Personenstunde“. Der Grund dafür ist, dass Überstundenso gut wie keine Auswirkung auf das Arbeitsergebnis haben: Eine Person leistenim Durchschnitt an zwei 12-Stundentagen genauso viel wie an zwei 8-Stunden-Tagen (und nicht etwa so viel wie an drei 8-Stunden-Tagen)!

Fazit 1

Überstunden schaden fast immer (außer wenn man einen kurzen Endspurt hinlegtund danach eine Erholungsphase einschiebt). Laut DeMarco bringen Überstundenfolgende 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.


Fazit 2

Schätzungen sollten immer tagesgenau und nie stundengenau vorgenommen wer-den.

(größtes) drittes ProblemWenn eine Person in einem Monat 1 PM Arbeit leistet, heißt das nicht, dass 2Personen 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 Per-sonen nicht aus, um den Vorgang bereits in 5 Tagen zu erledigen (die obige Rech-nung ist also fehlerhaft). Die zweite Person muss in dieser Zeit vielleicht nichtVollzeit, aber zumindest deutlich mehr als 60 % Prozent seiner Arbeitszeit an die-sem Vorgang mitarbeiten.

Allgemeiner: Wenn n Personen gleichzeitig an einem Problem arbeiten, ergebensich n · (n− 1)/2 2-Personen-Kommunikationskanäle, außerdem gibt es 3-Per-sonen-Kommunikation, 4-Personen-Kommunikation . . . und Team-Kommunika-tion (Lagebesprechung etc.). Das heißt, der Kommunikationsoverhead wächst mitmindestens O(n2) mit der Anzahl der an einer Aufgabe beteiligten Personen.

Wenn beispielweise der Kommunikationsaufwand zwischen je zwei Teammitglie-dern, 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 Vorgangsmittels d = 1/(MA ∗ pAL), wobei pAL die produktive Arbeitsleistung eines Mit-arbeiters ist (die kommunikative Arbeitsleistung kAL ist gleich 1 − pAL):

1 Person braucht 1, 0 (= 1/(1 · 1, 0)) Zeiteinheiten2 Personen brauchen 0, 5̄ (= 1/(2 · 0, 9)) Zeiteinheiten3 Personen brauchen 0, 41 (= 1/(3 · 0, 8)) Zeiteinheiten4 Personen brauchen 0, 35 (= 1/(4 · 0, 7)) Zeiteinheiten5 Personen brauchen 0, 33 (= 1/(5 · 0, 6)) Zeiteinheiten6 Personen brauchen 0, 33 (= 1/(6 · 0, 5)) Zeiteinheiten7 Personen brauchen 0, 35 (= 1/(7 · 0, 4)) Zeiteinheiten8 Personen brauchen 0, 41 (= 1/(8 · 0, 3)) Zeiteinheiten9 Personen brauchen 0, 5̄ (= 1/(9 · 0, 2)) Zeiteinheiten10 Personen brauchen 1, 0 (= 1/(10 · 0, 1)) Zeiteinheiten11 Personen werden gar nicht fertig :-)

Oder kurz: Viele Köche verderben den Brei!

Achtung: Diese Beobachtung besagt nicht, dass nicht mehrere unabhängige Vor-gänge parallel ausgeführt werden können, um die Projektdauer zu be-schleunigen (z. B. Tests auf verschiedenen Zielplattformen oder gleich-zeitige Entwicklung von zwei unabhängigen Modulen wie Automotorund Fahrersitz).


reale Arbeitszeit

theoretisches Optimum

Zeit (in Tagen) kommunikativeArbeitsleistung jeMitarbeiter(innerhalb von 10 Tagen)

(innerhalb von 10 Tagen)

produktiveArbeitsleistung jeMitarbeiter

5

9

7

8

6

4

3

2

1

0

10

1 2 3 4 5 6 7 8 9 10 11 Anzahl Mitarbeiter1 MA: kostenoptimal

5 MA: zeitoptimal (theoretisch auch 6 MA)3 MA: bester Kompromiss aus Kosten und Zeit (evtl. 2 MA)

weitere Probleme

Weitere Probleme bei der Bewertung, wie viele Arbeit von einer Person in einemPM geleistet werden kann, sind:

1. Verschiedene Personen leisten in derselben Zeit verschieden viel.

2. Mitarbeiter bringen nicht jeden Tag volle Leistung (Schnupfen, private Pro-bleme, Spannungen im Team, eine versaute Präsentation etc.).

3. Neulinge, die erst später in ein Projekt integriert werden, leisten weniger, dasie sich erst einarbeiten müssen.

4. Neulinge blockieren andere Mitarbeiter, d. h., auch erfahrene Projektmitarbei-ter leisten weniger, wenn sie zusätzlich einen Neuling einarbeiten müssen.

wichtige Erkenntnis

Hilfskräfte können Projektmitglieder von Routineaufgaben, wie Kopieren, E-Mail-Vorsortierung, Telefondienst etc. entlasten, ohne den Kommunikationsover-head 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 ohneHilfskraft.


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ürdas 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 wirdgeplant 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 nichtbewertet werden (gut/schlecht etc.).

Die Stromingphase sollte lange genug dauern.


Die Planung von Projekten erfolgt normalerweise in drei Schritten:

z.B. Balkendiagramme

z.B. Projektstrukturpläne

z.B. Netzpläne oder auch Balkendiagramme

grobe Projektplanung

feinere Projektplanung

Detailplanung

Bei kleinen, übersichtlichen Projekten werden oft keine Netzpläne, sondern nureine einfache Grobplanung und Balkendiagramme erstellt.

4.1 Projektpläne

Alles muss geplant werden ⇒ viele Pläne. Diese sollten immer aktuell gehaltenwerden – sonst sind sie nur Show und sind den Aufwand nicht wert, den man insie investiert hat.

Beispiele für Pläne

– OrganisationsplanVerantwortlichkeiten, Kompetenzen

– Kommunikationsplan, Berichts- und InformationswesenWer informiert wen wann worüber in welcher Form?

– BudgetWie viel, wann, von wem, wofür?

– ArbeitspläneAufgaben (bzw. Vorgänge): Was, wann, wer?

– PersonalpläneWer, was, wann, wann nicht (Urlaub etc.)?

– SchulungspläneProjektteam, Anwender, Systembetreuer

– Ausstattungspläne

– Beschaffungspläne

– Testpläne


– Wartungspläne

– KontrollpläneSoll/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 Beschreibungender Aufgaben vorliegen. Man beachte, dass die Grobplanung eine gute Basis fürfrühe Schätzungen darstellt.

4.2.1 Projektstrukturplan

Ein Projekt sollte zunächst hierarchisch strukturiert werden: Zunächst nach Kom-ponenten, dann nach Aktivitäten, die notwendig sind, um die Komponenten zuerstellen.

Dazu dienen die so genannten Projektstrukturpläne (PSP, engl.: work breakdownstructures, WBS).

Komponenten-Projektstrukturplan (KPSP)

...

Startseite Katalog

Metzgerei Meier

Wurst Käse SonstigesFleisch

Bestellung

Internet−Auftritt


Aktivitäten-Projektstrukturplan (APSP)

Tools und Technikenauswählen

Layoutfestlegen

Internet−Auftritt

Bestell−komponente

Startseiteerstellen

Katalogprogrammieren

programmieren

erstellenWeb−Seiten

Metzgerei Meier erstellen

VideosFotosText Grafiken

Contentbeschaffen/erstellenfestlegen

Seitenstruktur

Abbildung 4.1: APSP in MS Project 2010

Prerequisite-Tree

(Klein et al. [2005]) fehlt noch


4.3 Feinplanung, insb. Ressourcen-Management

Im Aktivitäten-Prozessstrukturplan enthalten die Blätter die so genannten Vorgän-ge:

Ein Vorgang ist eine in sich abgeschlossene genau spezifizierte Aktivität, die in-nerhalb einer angemessenen Zeitdauer durchgeführt werden kann. Wenn dieseAussage für ein APSP-Blatt noch nicht zutrifft, muss der entsprechende Knoteneventuell 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-Vertei-lung)

– 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 Gesamt-planung und den Gesamtzielen vereinbar sein. Das heißt, die Summe der Vor-gangskosten einer Projektphase sollten in etwa gleich den geschätzten Kosten fürdiese Phase sein. Und die Gesamtdauer aller Vorgänge sollte der geschätzten Dau-er 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


Ereignisknoten-Netzpläne (EKN; Beziehungen zwischen Ereignissen = Ergebnis-sen von Vorgängen werden modelliert, z. B. Vorgang „Startseite erstellen“ =̂ Er-eignis „Startseite wurde erstellt“).

Ereignis Ereignis

Vorgangsknoten-Netzpläne (VKN; Beziehungen zwischen Vorgängen werden mo-delliert; ähnlich EKN).

Vorgang Vorgang

Vorgangspfeil-Netzpläne (VPN) werden als historisch erste Darstellungsform derNetzplantechnik angesehen. Diese Art der Darstellung wurde 1956 für die Criti-cal-Path-Method entwickelt. Vorgangsknoten-Netzpläne (VKN) wurden 1958 imZusammenhang mit der Mèthode des Potentiels Metra (Metra Potential Method,MPM) eingeführt. Im selben Jahr wurden im Rahmen der Programm Evaluati-on und Review Technique (PERT) die Ereignisknoten-Netzpläne (EKN) erstmalsvorgestellt. Heute sind VPN und EKN nur noch von geschichtlichem Interesse.Die Vorgangsknoten-Netzpläne werden allgemein verwendet. Häufig spricht manauch (eigentlich fälschlicherweise) von PERT-Diagrammen oder PERT-Netzplä-nen, meint damit heute aber stets VPNs und nicht die veralteten EKNs. (Kelleyund 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 Vander-pooten [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 einelaufende Nummer sowie den frühesten und den spätesten Starttermin.

Bei EKNs wird die Dauer ebenfalls an den Beziehungspfeilen angebracht. Lau-fende Nummer, frühester und spätester Termin werden in den Knoten notiert.


In VKNs wird die gesamte Information (laufende Nummer, Bezeichnung, frühe-ster und spätester Starttermin, Dauer und freie Pufferzeit, frühester und spätesterEndtermin etc.) in den Vorgangsknoten notiert. An den Pfeilen wird die Art derBeziehung notiert, zumindest, wenn es sich nicht um eine Standard-Ende-Anfang-Beziehung handelt (siehe weiter unten).

Die frühesten Start- und Endtermine der Vorgänge werden zunächst ausgehendvom ersten hin zu späteren Vorgängen mit Hilfe der Dauer und der Abhängigkei-ten ermittelt. Dieser Vorgang wird Vorwärtsrechnung genannt. Dann können diespä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 dessenspätestem Starttermin ist. Jede Verzögerung, an der dieser Knoten beteiligt ist, hateine Verzögerung der gesamten Phase und damit des Gesamtprojektes zur Folge,wenn man die verlorene Zeit nicht anderweitig wieder hereinarbeiten kann. Ineinem VKN spricht man auch von kritischen Vorgängen.

Ein kritischer Pfad ist eine Liste oder gar ein ganzes Netz zusammenhängenderkritischer Knoten.

Pufferzeiten

Die Differenz zwischen frühestem und spätestem Starttermin (oder Endtermin)eines Vorgangs heißt gesamte Pufferzeit (des aktuellen Vorgangs). Um diese Zeit-spanne kann ein Vorgang verzögert werden, ohne das Gesamtprojekt zu verzögern.Dabei kann es allerdings passieren, dass die Pufferzeiten nachfolgender Vorgän-ge verringert werden. Ein kritischer Vorgang zeichnet sich also dadurch aus, dassseine gesamte Pufferzeit gleich Null ist.

Daneben kann man für die einzelnen Vorgänge auch noch die freie Pufferzeit be-rechnen. Das ist diejenige Zeit, um die der Start eines Vorgangs verzögert werdenkann, ohne dass sich dadurch die Pufferzeit eines Nachfolgevorgangs verringert.Die freie Pufferzeit berechnet man aus dem frühestens Endtermin eines nicht-kritischen Vorgangs und dem Minimum des frühesten Start-Termins aller direk-ten Nachfolgervorgänge. Die freie Pufferzeit eines Vorgangs ist stets kleiner odergleich dessen gesamte Pufferzeit.

Für Vorgänge kann auch ein fixer Start- oder Endtermin vorgegeben werden. Indiesem Fall kann die Vorwärts- und die Rückwärtsrechnung eventuell negativePufferzeiten und damit einen so genannten zeitinkonsistenten Netzplan liefern.

Beispiel

Für ein Software-Projekte werde eine geeignete Datenbank gesucht. Im Aktivitä-ten-Projektstrukturplanwurden folgende Vorgänge für diese Teilaufgabe ermittelt:


Nr. Name Vorgänger Nachfolger Dauer1 Phasenstart – 2; 4 0 d2 DBMS anschaffen 1 3 6 d3 DBMS installieren 2 5; 6 2 d4 Testszenario entwickeln 1 5; 6 7 d5 Testdaten einspielen 3; 4 7 1 d6 Testszenario implementieren 3; 4 7 3 d7 DBMS testen und wählen 5; 6 8 2 d8 Phasenende 7 – 0 d

In der Spalte „Vorgänger“ wird jeweils angegeben, welche Vorgänge abgeschlos-sen sein müssen, bevor der aktuelle Vorgang starten kann. In der Spalte „Nach-folger“ sind diejenigen Vorgänge aufgeführt, die frühestens starten können, wennder aktuelle Vorgang abgeschlossen ist.

Die verschiedenen Visualisierungsmöglichkeiten dieser Vorgangsbeziehungen mitHilfe Netzplänen werden in Abbildung 4.2, Abbildung 4.3 und Abbildung 4.4gezeigt.

Anmerkung 1

Was bedeutet eigentlich „Vorgang A beginnt am Tag X“ bzw. „Vorgang A endetam 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 Fol-getages nichts für das Projekt machen, sondern auch noch ein Privatleben haben.(Die genauen Anfangs- und Endzeiten variieren natürlich von Unternehmen zuUnternehmen.)

Anmerkung 2

Obwohl Netzdiagramme den zeitlichen Aspekt stark betonen, eignen sie sich auchzur Kosten- und Ressourcenschätzung und -planung.


(1)

VPN

DB

MS−

Tes

tlize

nzen

ansc

haff

en (

2)6

inst

allie

ren

(3)

DB

M−

Syst

eme

2

Tes

tsze

nari

oen

twic

keln

(4)

7

Tes

tdat

enei

nspi

elen

(5)

1

Tes

tsze

nari

oim

plem

entie

ren

(6)

3

11115

11

DB

MS

test

en u

ndau

swäh

len

(7)

213

136

1313

66

00

Phas

enst

art

ange

scha

fft

Tes

tlize

nzen

ausg

ewäh

ltge

test

et u

nd

911

eing

espi

elt

Tes

tdat

en

1111

11

impl

emen

tiert

Tes

tsze

nari

o

88

inst

allie

rtD

BM

−Sy

stem

e

78

entw

icke

ltT

ests

zena

rio

DB

MS

22

1

1

3

3

2

6 7

EK

N

1

23

4

5

7

6

662

8103

884

Phas

enst

art

Abb

ildu

ng4.

2:V

PN

-un

dE

KN

-Net

zplä

nefü

rdi

eA

usw

ahle

ines

Dat

enba

nk-M

anag

emen

t-S

yste

ms


VK

N

DB

MS

test

enun

d au

sgew

ähle

n

2 0

7

11 111313

1 2

5

10119

eins

piel

enT

estd

aten

8

3 0

6

81111

8Tes

tsze

nari

oim

plem

entie

ren

6 0

2

066

02 0

688

6DB

M−

Syst

eme

inst

allie

ren

0 0

8

131313

13Phas

enen

de

ansc

haff

en

fS D fE sS gP sE

früh

este

r St

artte

rmin

= = = = = =

früh

este

r E

ndte

rmin

spät

este

r St

artte

rmin

spät

este

r E

ndte

rmin

gesa

mte

Puf

ferz

eit

Dau

er

nich

t−kr

itisc

h

kriti

sch

Mei

lens

tein

7 1

4

187

0Tes

tsze

nari

oen

twic

keln

D gPsS

sEfEfSV

orga

ngsn

ame

<N

umm

er>

0 0

1

000

0Phas

enst

art

3D

BM

−Sy

stem

e

Abb

ildu

ng4.

3:V

KN

-Net

zpla

nfü

rdi

eA

usw

ahle

ines

Dat

enba

nk-M

anag

emen

t-S

yste

ms


��

��

��

��

��

��

� ��

� ��

� ��

��

��

��

� ��

� � ��

� ��

� ��

��

��

��

� ��

��

��

� � ��

��

� !"#$#$% #

& �� ' ��(��

� � ��(

� !"#$") !*)

& �� & � ��

� � ��

'+&-,. /�� 0��1 �22 ��

��

��

��

��

��

��

� � ��

��

'+&-,. /�� 0� ��

��

��

� ��

��

��

��

� � ��

��

'+&.� �� 3�� 3� �41� ��

��

�(��

� ��

��

�(��

��

� � ��

��

� �� 0� �0��

� ��

��

��

� ��

��

��

� � ��

��

5 6787 9:;

<7:;8= 6787 9:;

5 6787 9:; >6? >7@>A98>7A

? >7@ >A98>7A

5 6787 9:; >6B CDD>@ EF6GCAG

B CDD>@ EF6GCAG

5 6787 9:; HAI>7AG>JK G8

�7AG>JK G8

5 6787 9:; HAIDC6=7 >68

? C6=7 >68

5 6787 9:; HAI>L8 >6A

� L8>6A

M 6FN >=8 9CDD>@ EF6GCAG

5 6787 9:; HAI; >6EF6G>; FO >A

<7:;8= 6787 9:; HAI; >6EF6G>; FO >A

P QR STUVW VXY QZUVQ

< CD>J 6K; >98 >6B8 C68�[

J 6K; >98 >9� AI > [\ CH>6

9]^8>98 >6B8 C68�[9]^8>98 >9� AI > [G>9CD8 >6M HJJ >6

@ CHJ >AI >< HDD>6_[

J 6>7 >6M HJJ >6

` abc ad

e fgh aic jkklm

lnc opjk gqrtsqd squ

Abb

ildu

ng4.

4:V

KN

-Net

zpla

nfü

rdi

eA

usw

ahle

ines

Dat

enba

nk-M

anag

emen

t-S

yste

ms

(mit

MS

Pro

ject

2003

erst

ellt

)


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 werdendarf, wenn der vorherige beendet wurde.

Beispiel

Design ImplementierungEA

Mit der Implementierung kann evtl. auch schon etwas früher begonnen werden,z. B. 5 Tage vor Ende des Designs.

Design ImplementierungEA − 5d

Es ist auch möglich einen etwas späteren Start als das Ende des Design festzule-gen.

Design ImplementierungEA + 3d

Anfangsfolge

Eine Anfangsfolge (AA) besagt, dass ein zweiter Vorgang gleichzeitig mit demersten anfangen muss.

Beispiel

regelm. BackupImplementierungauf derZielplattenform

derZielplattform

AA

oder die regelmäßigen Backups starten schon einen Tag vorher

regelm. BackupImplementierungauf derZielplattenform

derZielplattform

AA−1d


Beachten Sie, dass der Anfang der regelmäßigen Backups vom Anfang der Imple-mentierung auf der Zielplattform abhängt und nicht umgekehrt. Mit Hilfe einesBalkendiagramms (Gantt-Diagramm Abschnitt 4.3.3) kann man diesen Zusam-menhang besser visualisieren. Die linke Seite des Balkens wird am Start-Datumin einen Kalender eingetragen und die rechte Seite am Ende-Datum.

Implementierung auf Zielplattform

Implementierung auf Zielplattform

AA

Backups auf Zielplattform ...

Backups auf Zielplattform ...

AA−1d

Endfolge

Eine Endfolge (EE) besagt, dass ein zweiter Vorgang zusammen mit dem erstenbeendet wird.

Beispiel

regelm. BackupÜbergabeanKunden

auf derZielplattform

EE

Netzpläne

regelm. BackupÜbergabeanKunden

auf derZielplattform

EE+1d


Übergabe an Kunden

Übergabe an Kunden

EE

... Backups auf Zielplattform

... Backups auf Zielplattform

Balkendiagramme

EE+1d

Sprungfolge

Eine Sprungfolge (AE) besagt, dass der zweite Vorgang erst beendet werden darf,wenn der erste begonnen wurde.

Beispiel

alte AnwendunginBetrieb

inBetrieb

neue Anwendung AE

Netzpläne

alte AnwendunginBetrieb

inBetrieb

neue Anwendung AE+5d


neue Anwendung In Betrieb ...

AE

... alte Anwendung in Betrieb

neue Anwendung In Betrieb ...

... alte Anwendung in Betrieb

Balkendiagramme

AE+5d

Die alte Anwendung darf erst beendet werden, wenn die neue in den Einsatzkommt.

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


Man beachte, dass mit Hilfe von Addition und Subtraktion von Zeitabständen jedeAbhängigkeit zwischen zwei (endlichen) Vorgängen als Normalfolge, Anfangs-folge, Endfolge oder Sprungfolge notiert werden kann. Bei der Auswahl einergeeigneten 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 unddie Beziehungen zwischen den Vorgängen (als Pfeile) eingetragen wurden, kannman die frühesten und spätesten Start- und End-Termine mittels der so genannteVorwärts- und Rückwärtsrechnung ermitteln. Daraus lassen sich anschließend diePufferzeiten und der kritische Pfad ableiten.

Am Beispiel der Auswahl eines DBMS (Abbildung 4.3) sollen die beiden Algo-rithmen 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ühesterStart- und Endtermin jeweils 0 eingetragen.

Das heißt, das Projekt beginnt am nullten Tag um 24:00 Uhr, also am 1. Tagum 8:00 Uhr. Um welchen Tag es sich hierbei konkret handelt, muss separat (imGantt-Diagramm; Abschnitt 4.3.3) festgelegt werden.

Solange es noch Vorgänge gibt, deren frühesten Start- und Endtermine noch nichteingetragen wurden, führe für jeden dieser Vorgänge Folgendes aus:

Wenn die spätesten Endtermine aller EA-Vorgänger-Vorgänge ermittelt wur-den:

Trage das Maximum dieser Endtermine als frühesten Starttermin fürden aktuellen Vorgang ein.Trage als frühesten Endtermin des aktuellen Vorgangs den frühestenStarttermin plus der Dauer des aktuellen Vorgangs ein.

Dieser Algorithmus endet, wenn der früheste Start- und der der früheste End-Ter-min in den Dummy-Vorgang „Phasenende“ oder „Projektende“ eingetragen wur-den. Diese beiden Werte stimmen überein (da die Dauer des Dummy-Vorgangs0 Tage beträgt). Dieser Wert sagt aus, wie lange es dauert, die Phase bzw. dasProjekt zu beenden (wenn die Dauer jedes einzelnen Vorgangs richtig geschätztwurde).


Algorithmus: Rückwärtsrechnung

Bei der Rückwärtsrechnung geht man davon aus, dass die Gesamtdauer der Pro-jektphase bzw. des Projektes minimal sein soll.

Man initialisiert also den spätesten Start- und den spätesten Endtermin des Dum-my-Vorgangs „Phasenende“ oder „Projektende“ mit denjenigen Werten, die indiesem Vorgang als frühester Start- und Endtermin eingetragen sind.

Solange es noch Vorgänge gibt, deren späteste Start- und Endtermine noch nichteingetragen wurden, führe für jeden dieser Vorgänge Folgendes aus:

Wenn die spätesten Starttermine aller EA-Nachfolger-Vorgänge ermitteltwurden:

Trage das Minimum dieser Starttermine als spätesten Endtermin fürden aktuellen Vorgang ein.Trage als spätesten Starttermin des aktuellen Vorgangs den spätestenEndtermin minus der Dauer des aktuellen Vorgangs ein.

Algorithmus: Pufferzeiten und kritischer Pfad

Die gesamte Pufferzeit eines einzelnen Vorgangs ermittelt man, indem man denfrü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 End-termin des Vorgangs vom Minimum der frühesten Starttermine aller Nachfolger-vorgänge subtrahiert.

In Abbildung 4.3 sind die freien Pufferzeiten nicht eingetragen. Sie stimmen mitden gesamten Pufferzeiten überein. In Abbildung 4.23 unterscheiden sich die Puf-ferzeiten von Vorgang Vc: Die gesamte Pufferzeit beträgt 3 Tage, die freie Puf-ferzeit ist dagegen 0 Tage. Das heißt, wenn sich dieser Vorgang verzögert, wirdautomatisch auch die Pufferzeit des Nachfolgevorgangs Vd reduziert.

Den kritischen Pfad ermittelt man, indem man alle Vorgänge mit einer freien Puf-ferzeit von 0 Tagen als kritisch markiert. Man beachte, das hierbei nicht unbedingtein „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 Beziehungsar-ten enthält: neben verschiedenen Normalfolgen finden sich dort eine Anfangsfol-ge und eine Endfolge. Nur eine Sprungfolge fehlt noch. Hier erfolgt die Vorwärts-und die Rückwärtsrechnung im Prinzip genauso, wie zuvor beschrieben. Aller-dings müssen jetzt andere Werte übertragen werden.


Beispiel: Der früheste Starttermin von V3 ermittelt sich aus dem Maximum von3 (= spätester Endetermin von V1) und 4 (= frühester Starttermin von V2 plus 4Tage; wegen der Beziehung AA+4d).

Die in Abbildung 4.7 gezeigten Diagramme unterscheidet sich in einem wichtigenPunkt von den von MS Project 2010 erstellten Diagrammen (Abbildung 4.8): ImNetzplan 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 Vor-gangsende geben kann. Dies entspricht jedoch nicht der Faktenlage. Der andereUnterschied ist, dass MS Project 2010 im Gegensatz zu MS Project 2003 default-mäßig den freien Puffer im Gantt-Diagramm (siehe den folgenden Abschnitt) an-zeigt. MS Project 2003 hat dagegen – wie dies auch in Abbildung 4.7 gemachtwird – den Gesamtpuffer angezeigt. Im Gantt-Diagramm von Abbildung 4.8 wer-den beiden Pufferarten angezeigt: Oben der Gesamtpuffer und unten der freie Puf-fer.

4.3.3 Balkendiagramme (Gantt-Diagramme)

Aus Netzplänen können so genannte Balken- oder Gantt-Diagramme abgeleitetwerden (siehe z. B. Abbildung 4.7, Abbildung 4.8 oder auch Abbildung 4.5). DerName geht auf Henry Gantt zurück (Gantt [1913]).

Balkendiagramme betonen den Zeitaspekt mehr als Netzdiagramme, da die Bal-kenlänge abhängig von der Dauer des zugehörigen Vorgangs gewählt wird. Die fürNetzpläne eingeführten Beziehungen (EA, AA, EE, AE) gibt es gleichermaßen fürBalkendiagramme. (Die Beispiele des letzten Abschnittes wurden zusätzlich auchschon in Form von Balkendiagrammen angegeben.)


� ��

� ��

� � ��

� ��

� ��

�

��

��

� ��

� ��

�

�� ! "� ��#� ��

��

� ��

��$� ��

$

�� ! "� ��

��

��$� ��

� ��

%

� �� &�� '� #(� ��

)� ��

� ��

��$� ��

�

� ��* �� +� ��

��

� ��

� �� $ ,%

�

� �� &�� +� ��

$� ��

� ��

�� $ ,%

)

��!� �� *� '��

��

��) ��

� ��- �� ,�

-

�� * �

��

� ��- ��

� ��- �� )

!

�

�

�

�

�

!

!

�

�

�

�

�

!

!

�

�

�

�

�

�� .��

�/ �� .��

�� 0 �.��

� ��

1 �� #� ��

� ��

� ��

2 345 36

7 89: 3;5 <==>?

>@5 AB<>96CDEFD6G

Abb

ildu

ng4.

5:G

antt

-Dia

gram

mfü

rde

nN

etzp

lan

aus

Abs

chni

tt4.

3.1

(mit

MS

Pro

ject

2010

erst

ellt

)


Vor

gang

skno

tenn

etz

Gan

tt−D

iagr

amm

(ge

mäß

CP

M, m

it k

riti

sche

n P

fad

und

frei

en s

owie

ges

amte

n P

uffe

rzei

ten)

MD

FS

SM

DF

SS

MD

FS

SS

SM

DM

DF

SS

MD

MD

MD

5. A

pril

2010

12. A

pril

2010

19. A

pril

2010

26.A

pril

2010

D gPsS

sEfEfSV

orga

ngsn

ame

<N

umm

er>

00

0 00

000

Star

t

0 0End

e

Star

t

End

e

Nam

e

1

2

8

Va

Va

Vb

Vc

Vd

Ve

Vf

33

03

30

Mei

lens

tein

kriti

sche

r V

orga

ng

Vor

gang

3

45

67

03

3

21 1

8

88 8

8

85

8

2

6

Vb

Vc

Vd

Ve

Vf

22

11

35

63

33

11

3

00

1

Mei

lens

tein

kriti

sche

r V

orga

ng

gesa

mte

Puf

ferz

eit

Vor

gang

frei

e Pu

ffer

zeit

Nr. 1 2 3 4 5 6 7 8

Dau

erV

orgä

nger

1EA

1EA

1EA

4EA

2EA

3EA

, 6E

A

5EA

, 7E

A

0d 1d 2d 3d 2d 2d 5d 0d

fS D fE sS gP sE

früh

este

r St

artte

rmin

= = = = = =

früh

este

r E

ndte

rmin

spät

este

r St

artte

rmin

spät

este

r E

ndte

rmin

gesa

mte

Puf

ferz

eit

Dau

er

=fr

eie

Puff

erze

itfP

fP

3

1

0

Abb

ildu

ng4.

6:V

orga

ngsk

note

nnet

zun

dG

antt

-Dia

gram

m


D gPsS

sEfEfSV

orga

ngsn

ame

<N

umm

er>

fS D fE sS gP sE

früh

este

r St

artte

rmin

= = = = = =

früh

este

r E

ndte

rmin

spät

este

r St

artte

rmin

spät

este

r E

ndte

rmin

gesa

mte

Puf

ferz

eit

Dau

er

nich

t−kr

itisc

h

kriti

sch

Mei

lens

tein

MD

FS

SM

DF

SS

0

4

0

6

0 00

000

Star

t

V1

V2

V4

V6

0V3

2V5

0 0End

e

33

11

43

7

47

68

82

10

10 10

10 10

10 10

4 06

5 832

3 633

3

Phas

enst

art

Nr.

SS

MD

MD

FS

SM

DM

D9.

Mai

200

5N

ame

Vor

gang

1

Vor

gang

2

Vor

gang

3

Vor

gang

4

Vor

gang

5

Vor

gang

6

Phas

enen

de

Vor

gäng

er

Fr 6

.5.

Do

12.5

.

Di 4

.5.

Di 4

.5.

End

eA

nfan

gD

auer

Mo

2.5.

Mo

9.5.

Di 1

7.5.

Di 1

7.5.

Di 1

7.5.

2. M

ai 2

005

16. M

ai 2

005

Mo

2.5.

Mo

2.5.

Mo

2.5.

Mo

9.5.

Mi 1

1.5.

Mi 1

1.5.

Mi 1

1.5.

60

auch

5th

eore

tisch

Star

tterm

in is

t kri

tisch

End

e is

t unk

ritis

ch

EE

+1d

AA

+4d

EA

−1d

EA

−1d

0d 3d 3d 3d 2d 2d 4d 0d

Vor

gang

kriti

sche

r V

orga

ng

Mei

lens

tein

frei

er P

uffe

r

(Ges

amt−

)Puf

fer

1 2 3 4 5 6 7 8

1EA

1EA

2EA

, 3A

A+

4d

2EA

−1d

, 3E

A

4EE

+1d

, 5E

A

4EA

−1d

6EA

, 7E

A

1

2 3

4 576

8

Abb

ildu

ng4.

7:B

eisp

ielf

ürN

etzp

lan-

und

Bal

kend

iagr

amm

mit

kom

plex

eren

Abh

ängi

gkei

ten


Abb

ildu

ng4.

8:B

eisp

ielf

ürN

etzp

lan-

und

Bal

kend

iagr

amm

mit

kom

plex

eren

Abh

ängi

gkei

ten

(mit

MS

Pro

ject

2010

erst

ellt

)


4.4 Feinplanung

Bislang haben wir uns im Rahmen der Planung im Wesentlichen mit den Bezie-hungen zwischen Vorgängen befasst. Implizit lag dabei die Annahme zu Grunde,dass jederzeit unbegrenzte Ressourcen zur Verfügung stehen. Allerdings ist demim Allgemeinen leider nicht so. Aufgabe des Ressourcen-Management ist es, denBedarf an Ressourcen (Einsatzmittel) vorherzusagen und eine Einsatzoptimierungzu 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 die-sen und jenen Terminen abzuschließen?“

– kapazitätstreue Ressourcenplanung„Wann kann ich frühestens diese und jene Vorgänge bei gegebenen Ressour-cen abschließen?“

Wie in Abschnitt 3.7 gezeigt wurde, ist die termintreue Ressourcenplanung ge-rade hinsichtlich des Personaleinsatzes i. Allg. nicht möglich. Folgende Milch-mädchenrechnung funktioniert – wie wir gesehen haben – sicher nicht: „In zweiTagen muss der Rohbau meiner Fabrik stehen stehen. Um dieses Ziel zu erreichenbrauche 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 behindertePerson in einem neuen Team erhöht die Erfolgschancen DeMarco und Lister[1991] etc.)

Ziel der Personalplanung: optimaler Personaleinsatz über die gesamte Projektlauf-zeit.


Beispiel „Spiel Aquaris“

Das Spiel Aquaris wurde im Jahr 2006 im Rahmen eines Multimedia-Semester-projektes von einer Studentengruppe entwickelt. In diesem Spiel geht es darum,dass 6 Spieler mit Hilfe von Seilzugsteuerungen virtuelle Wasserauffangbehäl-ter mit Wasser und Bonuselementen befüllen. Je zwei Spieler bilden ein Team:Der Sammler sammelt das Wasser und die Bonuselemente. Der Blocker versuchtMaluselemente abzublocken und zum Gegner zu kicken. Das Wasser und Bonus-elemente sollte er oder sie natürlich möglichst nicht abblocken.

nicht−kritisch

kritisch

MeilensteinD

gPsS sE

fEfS

Vorgangsname<Nummer>

fSDfEsSgPsE

frühester Starttermin======

frühester Endterminspätester Starttermin

spätester Endtermingesamte Pufferzeit

Dauer

0

0

0

00 0

00

01

2

3

4

5

Start

Spieldesign

Spiellogik

Spielsteuerung

8 8

8

4 4 10

6 9 15

0

0

Ende6

10 4 19

19

19

19

19

19

19

118

8

Animation

6 6

0 0

Abbildung 4.9: Netzplan des Computerspiels Aquaris

Die in Abbildung 4.9 und Abbildung 4.10 angegebenen Zahlen sind fiktiv. Aller-dings war – neben Informatikern und Gestaltern – tatsächlich erstmals auch einMechatroniker 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 Mit-arbeitern kann nach qualifikationsorientierten sowie organisationsorientierten Ge-sichtspunkten ermittelt werden. Wenn Mitarbeiter gleichzeitig in mehr als einemProjekt arbeiten – was Sie als Projektleiter laut DeMarco [2001] tunlichst vermei-den sollten –, kann die Bedarfsplanung auch projektorientiert erfolgen.

Bei der qualifikationsorientierten Bedarfsplanung werden zu jedem Zeitpunkt die


Qualifika−tion

VorgängeInformatiker Designer Mechatronik

11

21

3332

Personal 4 13

AnimationSpielsteuerung

Personaleingeplantes

SpieldesignSpiellogik

33

Abbildung 4.10: Personalplanung des Computerspiels Aquaris

1 2 4 5 7 8 9 11 12 13 14 16 17 18 19 203 6 10 1500

1

2

3

4

5

6

7

Mitarbeiter

InformatikerMechatroniker

Zeit

Spielsteuerung

SpielsteuerungInformatikerMechatronikerDesigner

Spieldesign

SpiellogikInformatiker

AnimationDesigner

Animation Informatiker Projektleiter

Problem: 5 Designer werden gebraucht

Abbildung 4.11: Qualifikationsorientierte Bedarfsplanung

Anzahl der benötigten MA mit bestimmter Qualifikation in ein Diagramm einge-tragen (siehe Abbildung 4.11).

Bei der organisationsorientierten Bedarfsplanung werden die Mitarbeiter nichtnach 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 jedenProjektes in ein Bedarfsdiagramm eingetragen.

In allen Fällen kann man an derartigen Diagrammen Engpässe und Leerläufe ab-lesen (siehe Abbildung 4.12). Man beachte, dass die Anzahl vorhandener Mitar-beiter (oder Spezialisten) über die Zeit nicht notwendigerweise konstant ist.

Im obigen Beispiel „Spiel Aquaris“ ergibt sich das Problem, dass keine 5 Designerzur Verfügung stehen (siehe Abbildung 4.13). Das heißt, nach 8 Projekttage ergibtsich für zwei Tage ein Engpass an Designern. Danach folgt ein Leerlauf. DerBedarf an Designern reduziert sich vor Projektende sogar auf Null (zumindest inunseren fiktiven Beispiel).


Leerlauf

Engpass

Leerlauf

Engpass

Leerlauf

Zeit

Anzahl

Mitarbeiter

Mitarbeiter

Abbildung 4.12: Leerlauf und Engpässe

Zeit

Designer

DesignerAnzahl

Abbildung 4.13: Leerlauf und Engpässe am Beispiel des Projektes „Auqaris“

Die eigentliche Aufgabe des Ressourcen-Management ist es, die zeitliche Abfol-ge von Vorgängen so abzuändern, dass Engpässe (d. h. Überstunden oder Einstel-lungen von weiterem Personal, Zukauf weiterer Ressourcen etc.) nach Möglich-keit vermieden werden. Im Wesentlichen werden dabei vorhandene Leerlaufzeitenabgebaut. Primär sind dazu nicht-kritische Vorgänge geeignet, deren Erledigungnach hinten – nach Möglichkeit in bestehende Leerlaufphasen – verschoben wer-den kann.

In Abbildung 4.14 werden fünf Vorgänge angegeben zusammen mit der jewei-ligen Dauer sowie der Anzahl der Mitarbeiter, die eingeplant werden muss, umden jeweiligen Vorgang in der angegebenen Zeit erfolgreich abzuschließen. InAbbildung 4.15 ist eingetragen, wie der Personalbedarf aussieht, wenn zu jedemZeitpunkt beliebig viele Projektarbeiter zu Verfügung stehen.


DauerAnzahl Mitarbeiter

==

DMA

D

Vorgangsname<Nummer>

MA

2V2

1V1

5

4

2

3V3

3

4V4

4

V5

34

5

7

5 2

Abbildung 4.14: Netzplan von fünf Vorgängen

50 10 150

5

Zeit

AnzahlMA

V3

V2

V4

V5V1

V4

TerminMA

Abbildung 4.15: Resultat der Vorgangsplanung

Wenn das Projektteam (neben dem Projektleiter) nur sechs Mitglieder hat, die allegleichermaßen geeignet sind, die Vorgänge zu bearbeiten, kommt es vom viertenbis zum neunten Tag zu einem Personalengpass. Ab dem neunten Tag kommt esdagegen 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 manfünf Kröten schlucken (Abbildung 4.16):


– 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 2Tage, 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 sechsExperten für diesen Vorgang.

– Die laut Netzplan vorgegebene Abhängigkeit V4→ V5 wird verletzt.

0 5 10 15

5

0Zeit

AnzahlMA

V3

V2

V5V1

V4V4

Überstunden

MA Termin

Abbildung 4.16: Termintreue Personalplanung

Die kapazitätstreue Personalplanung (Abbildung 4.17) vermeidet die meisten die-ser Nachteile. Dafür verschiebt sich der Endtermin um drei Tage. Wenn man diesich ändernde Mitarbeiterzahl an Vorgang V4 noch weiter abmildern will, könnteman auf den Start des Vorgangs mit einem Mitarbeiter in den vier bis sechs ver-zichten. Dies hätte eine weitere Verschiebung des Endtermins um einen Tag nachhinten zur Folge. Dafür hätte man auch Luft, den Vorgang V4 an den Tagen 13und 14 mit jeweils vier Mitarbeitern zu Ende zu führen (auch wenn rechnerischnur 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 Modifika-tion ist sowohl kapazitätstreu als auch termintreu. Der Puffer des Vorgangs „Ani-mation“ wird allerdings reduziert. Dafür gewinnt der Vorgang „Spiellogik“ zweiTage freien Puffer hinzu.


0 5 10 150

5

Zeit

AnzahlMA

V3

V2

V1 V4

V4

V5

MA Termin

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 wahr-scheinlich sind. Ansonsten rentiert sich der zusätzliche Arbeitsaufwand nicht.

Für verzehrbare Betriebsmittel sollten genügend Finanzreserven vorgesehen wer-den, so dass fehlendes Material rechtzeitig nachbestellt werden kann. Nicht ver-zehrbare Betriebsmittel sollten in genügender Zahl bereitgestellt werden.

Wenn eine Betriebsmittelplanung notwendig sein sollte, so läuft diese im wesent-lichen wie die Personalplanung ab. Man unterscheidet dabei zwischen:

– vorratseingeschränkter EinsatzplanungEin nicht-vergrößerbarer Vorrat eines Betriebsmittels muss möglichst fairauf mehrere Nutzer aufgeteilt werden⇒ Belegungspläne o. Ä.

– bedarfsbezogener EinsatzplanungZunächst wird von einem unbegrenzten Vorrat eines Betriebsmittels aus-gegangen. Dann wird der eigentliche Bedarf zu den verschiedenen Zei-ten ermittelt. Eventuell kann der Bedarf durch termintreue oder kapazi-tätstreue Auslastungsoptimierung verringert werden. Schließlich können dieBetriebsmittel gemäß dem errechneten Bedarf angeschafft werden.

– freier EinsatzplanungWenn keine Gefahr von Engpässen besteht, kann die Planung auf die Samm-lung von Benutzerbedürfnissen (oder -wünschen) beschränkt werden.


3 D

es.

3 In

f.

2 D

es. +

1 In

f.

1 In

f. +

1 M

ech

.

MD

FS

SM

DF

SS

MD

MD

FS

SM

DN

r.N

ame

1 2 3 4 5 6

Star

t

Spie

ldes

ign

Spie

llogi

k

Spie

lste

ueru

ng

Ani

mat

ion

Dau

er

0d

Vor

gäng

er

1EA

1EA

2EA

3EA

SS

MD

MD

FS

SM

D

End

e0d8d 6d 11

d 9d

4EA

, 5E

A

Vor

gang

kriti

sche

r V

orga

ng

Puff

er

Mei

lens

tein

3 D

es.

3 In

f.

2 D

es. +

1 In

f.

1 In

f. +

1 M

ech

.

MD

FS

SM

DF

SS

MD

MD

FS

SM

DN

r.N

ame

1 2 3 4 5 6

Star

t

Spie

ldes

ign

Spie

llogi

k

Spie

lste

ueru

ng

Ani

mat

ion

Dau

er

0d

Vor

gäng

er

1EA

1EA

2EA

3EA

SS

MD

MD

FS

SM

D

End

e0d8d 6d 11

d 9d

4EA

, 5E

AM

eile

nste

in

kriti

sche

r V

orga

ng

Vor

gang

(Ges

amt−

)Puf

fer

frei

er P

uffe

r

Abb

ildu

ng4.

18:A

quar

is:G

antt

-Dia

gram

me

mit

und

ohne

Res

sour

cene

ngpa

ss


4.4.3 Kapazitätsausgleich, Resource Leveling

Wenn man in Gantt-Diagrammen Vorgänge und deren Nachfolgervorgänge nachhinten verschiebt, um Ressourcen-Engpässe auszugleichen, spricht man von Ka-pazitätsausgleich oder Resource Leveling. Beispiele für Resource Leveling wur-den schon im letzten Abschnitt vorgestellt (siehe Abbildung 4.17 und Abbil-dung 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 Auf-gaben gleichzeitig arbeiten. Erst recht sollte ein Mitarbeiter nicht an zwei Pro-jekten gleichzeitig arbeiten. Der Grund dafür ist ganz einfach: Die Fertigstellungaller Aufgaben verzögert sich (Abbildung 4.19)!

� � �

��

� � �

��

��

��

� � ��

� � �

��

��

��

� � ��

� � �

��

Abbildung 4.19: Verzögerungseffekte von quasi-paralleler Arbeit


Ein Mensch kann immer nur eine Aufgabe zur selben Zeit absolvieren. Sogar dieAussage, dass Frauen multitaskingfähig seien und Männer nicht, ist laut einer Stu-die des Instituts für Arbeit und Gesundheit der gesetzlichen Unfallversicherungnichts als ein Märchen (DGVU [2010]).

Wenn sie (oder er) mehrere Aufgaben „gleichzeitig“ erledigen will, geht dies nurim so genannten „Timesharing-Verfahren“: Nach jeweils einer kurzen Zeitspannewidmet sie sich einer anderen Aufgabe. Dies hat zur Folge, dass sich das Endealler Aufgaben mit Ausnahme der letzten verzögert (siehe Abbildung 4.19 b).

Leider ist es nicht so, dass ein Mensch ohne Probleme die jeweilige Aufgabewechseln kann. Jeder so genannte „Taskwechsel“ hat eine zusätzliche Verzöge-rung zur Folge. Das heißt alle Endtermine, auch der der letzten Aufgabe, verzögertsich zusätzlich. (siehe Abbildung 4.19 c)

Beispiele für diese Verzögerungseffekte gibt es viele. Es wäre z. B. viel effizi-enter und effektiver Lehrveranstaltungen nacheinander in Blöcken zu halten alsin jeder Woche parallel diverse Lehrveranstaltungen zu besuchen, da man sichdann immer nur auf ein Thema konzentrieren müsste und das ständige Umden-ken entfallen würde. Laut Aussage einer Studentin, die ein Auslandssemester inSchweden verbracht hat, wird dieses Konzept in Schweden tatsächlich umgesetzt.

Ein viel schlimmeres Beispiel sind Telefon und E-Mail. „Ungestörtes Arbeiten istzum Luxus geworden. Büromenschen können sich im Schnitt elf Minuten auf eineAufgabe konzentrieren, bevor sie auf einem der vielen Kommunikationskanäleunterbrochen werden.“ (Pilgram [2011])

Die dauernden Unterbrechungen durch diese Medien kosten die Unternehmen je-des Jahr Milliardenbeträge. Jede Unterbrechung reißt einen Geistesarbeiter ausseinen Gedanken. Die nachfolgende Eintauchphase, um wieder voll konzentriertan der zuvor unterbrochenen Aufgabe arbeiten zu können, dauert laut Untersu-chen von DeMarco und Lister (DeMarco und Lister [1985]) ca. 15 Minuten. Dasheißt drei 5-Minuten-Telefonate in einer Stunde kosten die gesamte Stunde alsproduktive 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 Personalvorgeset-zen – der Fach- oder Stabsabteilung, der sie zugeordnet sind sowie den Projekt-leiter als Fachvorgesetzen. DeMarco [2001] hält das Matrix-Projektmanagementdagegen für absurd. Für vollkommen verfehlt hält er die Idee, dass der Personal-vorgesetzte einen Mitarbeiter, der in einem Projekt nicht ausgelastet ist, gleichzei-tig an mehreren Projekten (mit jeweils unterschiedlichen Fachvorgesetzen) mitar-beiten lässt. Hier kommt zu den üblichen Taskwechsel-Verzögerungen noch dasProblem hinzu, dass der Mitarbeiter in kein Team richtig integriert ist. Dies hat


wesentlich gravierendere Negativ-Effekte als die übrigen Zeitverluste durch Task-wechsel.

Laut DeMarco [2001] setzt sich der durch Taskwechsel verursachte Zeitausfallinsgesamt aus folgenden Komponenten zusammen:

– Routinearbeiten, um auf die neue Aufgabe umzuschalten

– Doppelarbeit, weil eine Aufgabe in einem ungünstigen Moment abgebro-chen werden musste

– Eintauchzeit bei denkintensiven Aufgaben

– Frustration (emotionale Eintauchzeit)

– Verlust des Teambildungseffkts (bei Mitarbeit an mehreren Projekten gleich-zeitig)

In einer Studie (DeMarco und Lister [1985]), bei der 600 Programmierer unterrealen Bedingungen Programmieraufgaben lösen mussten, wiesen Tim Lister undTom DeMarco nach, dass jeder Taskwechsel mit einem Konzentrationsverlut vonca. 20 Minuten verbunden ist. Bei 0,4 Wechseln pro Stunde summiert sich dieszu mehr als einer Stunde Arbeitszeitverlust, was 15 % der Arbeitszeit bei einem8-Stunden-Tag bedeutet.

Fazit

Resource Leveling auf Mitarbeiterebene ist bei jedem Projekt ein Muss!

Resource Leveling beschleunigt ein Projekt, wenn die Ressourcen vorgegebensind.

Resource Leveling bedeutet dagegen fast immer einer Verlängerung der Projekt-laufzeit gegenüber dem theoretischen Optimum, bei dem unbeschränkt viele Res-sourcen zur Verfügung stehen, die sich gegenseitig nicht behindern. Nur, wann hatman 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, angefan-gen bei der Vorplanung, endend beim Abschlussbericht. Zu den ressourcenspe-zifischen Kosten (Ressourcenkosten) addieren sich noch die Gemeinkosten (wieBüromiete, Löhne und Gehälter von Verwaltung und Management etc.), die sichnicht spezifischen Projekten zuordnen lassen.


Für Personal muss zwischen normalen Stundensätzen und Überstundensätzen un-terschieden werden. Diese können Gemeinkosten enthalten (Personalvollkosten)oder nicht. Bei manchen Unternehmen (wie z. B. dem Staat) werden die Kosten füralle Mitarbeiter derselben Qualifikation gemittelt (Personaldurchschnittskosten).Das heißt, unterschiedliche Gehälter aufgrund von Leistungs- oder Familienzula-gen o. Ä. werden projektunabhängig verrechnet.

Bei Betriebsmitteln entstehen Gemeinkosten (z. B. Büros), Festkosten (z. B. Neu-anschaffung nicht-verzehrbarer Betriebsmittel) und laufende Kosten (z. B. Nach-kauf aufgebrauchter verzehrbarer Betriebsmittel, Zeitschriften, Wartungsverträgeetc.)

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 derProjektkalender, in dem alle freien Tage (Samstage, Sonntage, Feiertage, Be-triebsferien) eingetragen werden.

Daneben kann es beliebig viele Ressourcenkalender geben, in denen die Verfüg-barkeit der einzelnen Ressourcen (Personal und Betriebsmittel) eingetragen wird.

Normalerweise enthalten die Ressourcenkalender lediglich mehr freie Tage alsder Projektkalender (Urlaub, Rechner auf CeBIT etc.). Allerdings gibt es auchRessourcen, die an ansonsten arbeitsfreien Tagen sinnvolle Arbeiten durchführenkönnen (Zement kann auch am Wochenende trocknen, 3D-Animationen könnenauch über Weihnachten ohne Aufsicht gerendert werden etc.).

Manchmal sind auch spezielle Vorgangskalender wichtig, wenn z. B. bestimm-te Vorgänge im Ausland stattfinden und der betriebsspezifische Projektkalenderdaher keine Anwendung finden kann (sehr zum Leidwesen einiger Dienstreisen-der). Sollte ein PM-Tool keine Ressourcenkalender mit beliebig veränderbarenArbeitszeiten unterstützen, so können Wochenend- und Feiertagsarbeit auch mitVorgangskalendern modelliert werden.


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 Be-dürfnisse der Produktionswirtschaft abgestimmt ist, ist CCPM für das Projektma-nagement gedacht.

In dem Roman „Die Kritische Kette – Das neue Konzept im Projektmanagement“(Goldratt [2002]) identifiziert Goldratt den kritischen Pfad als denjenigen Eng-pass, auf den ein Projektleiter sein Augenmerk konzentrieren muss. Wie bei ToCist ein explizites Puffermangement wesentlich.

Im englischen Wikipedia-Artikel über PERT werden für ein Beispielsprojekt sie-ben Vorgänge gemäß PERT geschätzt (Abbildung 4.20).

Vorgang Vorgänger Dauer: Schätzungen µi σi µi + σibest (a) normal (c) worst (b) (PERT) (PERT) (PERT)

A – 2 4 6 4,00 0,67 4,67B – 3 5 9 5,33 1,00 6,33C A 4 5 7 5,17 0,50 5,67D A 4 6 10 6,33 1,00 7,33E B; C 4 5 7 5,17 0,50 5,67F D 3 4 8 4,50 0,83 5,33G E 3 5 8 5,17 0,83 6,00

Abbildung 4.20: Wikipedia-Beispiel (Wikipedia [2011c])

Die Schätzwerte µi für die Dauer der einzelnen Vorgänge sowie σi wurden mittelsder PERT-Formeln µi = (ai + 4ci + bi)/6 und σi = (bi − ai)/6 ermittelt (sieheAbschnitt 3.3.3), wobei die σi-Werte im Wikipedia-Artikel nicht angegeben wur-den. 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ät-zung der Projektgesamtdauer, bei der ausschließlich die Erwartungswerte (un-gerundet) aufsummiert werden, überhaupt sinnvoll? Laut zentralem Grenzwert-satz (Abschnitt 3.3.2) liefert die Summe aller Erwartungswerte der kritischenVorgänge eine recht gute Schätzung für den Erwartungswert der Gesamtdau-er: µ = 4, 00 + 5, 17 + 5, 17 + 5, 17 = 19, 51. (Besser noch wären tagesgenaueSchätzungen; vgl. Abschnitt 3.5)

Doch was sagt der Erwartungswert µ aus? Er sagt aus, dass das Projekt mit ei-ner 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.


Abb

ildu

ng4.

21:G

antt

-Dia

gram

me

für

das

PE

RT-

Bei

spie

l;ob

en:µ

i;un

ten:

µi+

σi


Um ein deutlich besseres Ergebnis zu erhalten, muss man zu jedem Vorgangeinen Sicherheitspuffer zuschlagen. Wenn man beispielsweise zu jedem Vorgangeinen Puffer von einem σi hinzuaddiert (σi = (bi − ai)/6, sofern man wieder einePERT-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 alsoum 2, 5 Tage angewachsen. Diese Dauer ermittelt man, indem man alle µi + σiaufaddiert (rechte Spalte Abbildung 4.20). In Abbildung 4.21 wird unten das zu-gehörige Gantt-Diagramm gezeigt.

Laut zentralem Grenzwertsatz ist µ weiterhin gleich 19, 51 und σ =√

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 vonca. 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 – normaler-weise für jeden Vorgang ein Puffer implizit in der geschätzten Dauer enthalten.

Puffer50%−Quartil

Gerade wenn ein Projektleiter Einpunkt-Schätzungen vornimmt, bei denen er seinTeam 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, damitsich 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. Beispiels-weise fahre ich an Prüfungstagen spätestens 50 Minuten vor Prüfungsbeginn zurHSA, um rechtzeitig anzukommen, obwohl mir mit 99-prozentiger Sicherheit 35Minuten ausreichen würden. Bislang habe ich nur einmal eine Stunde zur HSAgebraucht, 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 inte-grieren, 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 zen-tralen Grenzwertsatz notwendig wäre. Im obigen Beispiel haben sich bereitsdie vier Einzelpuffer von jeweils σi schon zu einem Projektgesamtpuffer


von 2σ aufaddiert. Bei weiteren Vorgängen und insbesondere bei deutlichgrößeren Vorgangspuffern sprengt die Gesamtsumme aller Einzelpuffer sehrschnell jede sinnvolle Grenze: 2σ, 3σ, 4σ . . .

– Gemäß dem Gesetz von Parkinson [1955] hat viel Puffer einen gravierendenNachteil: Der Arbeitsaufwand wächst immer so weit, wie die Zeit, die zurVerfü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 abgegebe-nen Schätzungen vom Projektleiter reduziert werden (vgl. Dezember-fieber). Diese Angst geht häufig sogar soweit, dass der implizite Pufferauch dann nicht genutzt wird, wenn der Vorgängervorgang verspätetbeendet wurde.

Fazit: Egal wie lange die Projektdauer geplant wurde und wie viel Puffer für je-den einzelnen Vorgang eingeplant wurde, das Projekt wird nicht vorzeitig fer-tig, sondern höchstens noch später. Das heißt, auch wenn für das Wikipedia-Bei-spiels-Projekt (Abbildung 4.21) eine Fifty-fifty-Chance besteht, dass es vor dem1. 7. fertiggestellt werden könnte, wird es nicht vor dem 1. 7. fertig gestellt. Undwenn man, wie vorgeschlagen, in jeden Vorgang zusätzlichen Puffer einfügt, dannwird es nicht vor dem 6. 7. fertig. PUNKT!

Laut DeMarco [2001] trifft „das Parkinsonsche Gesetz [...] auf Ihre Mitarbeitermit 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 Druckist. Projektleiter sollen sich nicht verleitet fühlen, das Parkinsonsche Gesetz aus-zuhebeln, indem sie Scheintermine – das heißt, Termine, die nicht gehalten wer-den können – vorgeben. Ein derartige Termin wäre im Wikipedia-Beispiel der28. 6. (µ − 2σ), ein theoretisch machbarer Termin, der mit ca. 0 % Wahrschein-lichkeit auch gehalten werden kann.

Laut Goldratt sind die Projektleiter selbst Schuld, wenn das Parkinsonsche Gesetzzuschlägt: Erstens ist Resource Leveling ein Muss, d. h. Parallelarbeit sollte wannimmer möglich vermieden werden. Und zweitens sind fixe Termine von Übel. Ter-mine sind Schätzungen und damit keine unverrückbaren Größen. Die Mitarbeitermü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 Mitarbei-ter ist es, wenn ein Projektleiter für Vorgänge, die vorzeitig abgeschlossen wurde,in Folgeprojekten automatisch kürzere Laufzeiten ansetzt!


Wie kann man es erreichen, dass das Projekt tatsächlich irgendwann zwischen den28. 6. und dem 6. 7. fertig gestellt wird?

Laut Goldratt [2002] erreicht man dies, indem man die Vorgangspuffer explizitverwaltet. Genauer: Man nimmt für die einzelnen Vorgänge Fifty-fifty-Schätzun-gen vor und fügt am an Ende des kritischen Pfades einen Gesamtpuffer hinzu, dervon allen Vorgängen genutzt werden kann. Im folgenden Diagramm sieht man inAbbildung a drei Vorgänge, die einen impliziten Puffer enthalten. In Abbildung bwurde dieser Puffer separiert, summiert und hinter den verkürzten Vorgängen alseigenständiger „Puffervorgang“ eingefügt. Dadurch hat sich die Gesamtdauer derdrei Vorgänge nicht verändert. Wie wir aber bereits wissen (Zentraler Grenzwert-satz der Statistik: Abschnitt 3.3.2), kann man den Puffer von einer Summe vonVorgängen kürzer wählen. Dies wird in Abbildung c visualisiert.

µ1 2σ1 µ2 2σ2 µ3 2σ3

µ1 µ2 µ3 2σ1 2σ2 2σ3

µ1 µ2 µ3 2 ·√

σ21 + σ2

2 + σ23

a)

b)

c)

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 Grenswertsatzberechnet wurde, als expliziter Vorgang (Nr. 9) ins Diagramm eingefügt.

Den Mitarbeitern werden keine fixen Termine mehr genannt. Stattdessen wird je-der Vorgang begonnen, sobald der Vorgängervorgang abgeschlossen wurde. DenMitarbeitern wird mitgeteilt, dass z. B. ca. vier Tage für den gerade gestartetenVorgang eingeplant wurden. Allerdings wird kein Termin gesetzt. Das heißt, sa-gen Sie nicht: „In vier Tagen muss das Ergebnis da sein (nicht früher und nichtspäter)“. Sondern die Mitarbeiter werden angehalten, so lange wie nötig am Vor-gang zu arbeiten, um alle Vorgaben hinsichtlich Funktionalität und Qualität zuerfüllen. Sobald sie fertig sind, startet der nächste Vorgang und der Projektleiterpasst den Gesamtpuffer an: Wurde der Vorgang zu spät beendet, wird der Gesamt-puffer entsprechend gekürzt, anderenfalls wird er entsprechend verlängert.

Ganz wichtig: Mitarbeiter, die an kritischen Vorgängen arbeiten, werden von al-len anderen Tätigkeiten entlastet.

Bei einem gut geschätzten Projekt und guter Menschenführung (d. h., die Mit-arbeiter vertrauen darauf, dass weder Terminverzögerungen noch vorzeitige Vor-gangsfertigstellung negative Folgen für sie haben) sollte die Größe des Gesamt-puffers „pulsieren“ (vgl. Abschnitt 4.8.4).


Abb

ildu

ng4.

22:C

CP

M-D

iagr

amm

efü

rda

sP

ER

T-B

eisp

iel;

oben

:Ges

amtp

uffe

r;un

ten:

Ges

amtp

uffe

rund

Zub

ring

erpu

ffer


Definition 4.5.1 (Kritische Kette)Eine kritische Kette ist ein kritischer Pfad ohne Ressourcenkonflikte undohne parallele kritische Vorgänge, dem ein so genannter Gesamtpuffer alsletzter Vorgang hinzugefügt wurde.Die Dauer eines jeden Vorgangs wird mittels der Erwartungswerte zu-gehöriger Mehrpunktschätzungen ermittelt, die Dauer des Gesamtpuffersmittels der Wurzel aus der Summe der Quadrate der Standardabweichun-gen, 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 fol-gende Elemente:

– starke Reduktion von Parallelarbeit– explizite Verwaltung des Gesamtpuffers (kritische Kette)– explizite Verwaltung der Puffer für nicht-kritische Vorgänge (Zubrin-

gerpuffer)– 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(siehe Abschnitt 4.2.1).

3. Gantt-Diagramm aus APSP ableiten(siehe Abbildung 4.1).

4. Für alle Vorgänge (= Blätter des APSP) EA-Abhängigkeiten ermitteln(siehe Abschnitt 4.3.1).

5. In das zugehörige Gantt-Diagramm die EA-Abhängigkeiten der Vorgängeeintragen.

6. Für alle Vorgänge vi Mehrpunktschätzungen vornehmensowie µ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.


Wenn an dieser Stelle eine Vorwärts- und Rückwärtsrechnung gemäß klassischerVorgehensweise (CPM, PERT, MPM etc.) durchgeführt wird (Abschnitt 4.3.2), er-hält man laut zentralem Grenzwertsatz (Abschnitt 3.3.2) einen Zeitplan, der unteroptimalen Bedingungen, d. h., wenn zu jedem Zeitpunkt genügend Ressourcenzur Verfügung stehen, mit 50-prozentiger Wahrscheinlichkeit eingehalten werdenkann. Beispiele für das Ergebnis einer derartigen Berechnung: Abbildung 4.23und Abbildung 4.29.

Diese optimalen Bedingungen stehen aber fast nie zur Verfügung. Daher muss alsnä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, wirdeine zusätzliche EA-Beziehung zwischen V1 und V2 im Netzplan ein-getragen (und am Besten mit der verantwortlichen Ressource markiert).Die Richtung dieser Beziehung, d. h. die Reihenfolge in der A die beidenVorgänge bearbeitet, kann frei gewählt werden, sofern nicht schon eineandere Abhängigkeit eine bestimmte Reihenfolge vorgibt.

(b) Durch die neuen Abhängigkeiten, die durch das Resource Leveling ein-geführt werden, kann es im Netzplan zu Redundanzen kommen. Die red-undanten Beziehungspfeile können – müssen aber nicht – aus Gründender Übersichtlichkeit entfernt werden.

Beispiele für um ressourcenbedingte Abhängigkeiten erweiterte Netzpläne: Ab-bildung 4.24 und Abbildung 4.30. Ressourcenbedingte Abhängigkeiten wurdenmit gestrichelten Linien eingetragen und mit den zugehörigen Ressourcen mar-kiert. Redundanten Abhängigkeiten wurden mit kleinen Doppelstrichen symbo-lisch ausgestrichen. In Abbildung 4.24 ist beispielsweise die EA-Beziehung vonStart nach Vc redundant, da sich diese Abhängigkeit schon aus den EA-Beziehun-gen Start nach Va und Va nach Vc ergibt. Die letztere EA-Beziehung ergibt sichdaraus, dass Ressource B sowohl bei Vorgang Va als auch bei Vorgang Vc benötigtwird.

Wenn man nun wieder eine Vorwärts- und Rückwärtsrechnung gemäß klassischerVorgehensweise durchführt (Abschnitt 4.3.2), ergibt sich i. Allg. aufgrund der zu-sätzlichen Abhängigkeiten ein etwas späterer Endtermin. Im ersten Beispiel hatsich beispielsweise der Endtermin um einen Tag nach hinten verschoben (vgl. Ab-bildung 4.23 und Abbildung 4.24), im zweiten Beispiel sogar um zwei Tage (vgl.


Abbildung 4.29 und Abbildung 4.30). Man beachte, dass sich i. Allg. auch der kri-tische Pfad ändert. Insbesondere wird bei Ein-Personen-Projekten jeder Vorgangdurch das Resource Leveling kritisch.

Man erhält mit Hilfe des Resource Levelings einen Zeitplan, der unter den ge-gebenen Bedingungen in 50 Prozent der Fälle eingehalten werden kann. Umnun einen Endtermin zu ermitteln, zu dem das Projekt mit einer deutlich höherenWahrscheinlichkeit abgeschlossen werden kann, muss man einen Gesamtpufferfür das Projekt berechnen, der die Unsicherheiten aller kritischen Einzelvorgängein sich vereint.

Anmerkung: In den Gantt-Diagrammen der Beispiele in Abbildung 4.24 und Ab-bildung 4.30 wurden im Gegensatz zu den Beispielen in Abbildung 4.23 und Ab-bildung 4.29 nur noch die freien Pufferzeiten eingetragen (und als maximale Zu-bringerpuffer bezeichnet). Die Gesamtpufferzeiten der einzelnen Vorgänge sindsowohl für die Berechnung des Projekgesamtpuffers als auch für die Berechnungder Zubringerpuffer (siehe Abschnitt 4.5.3) uninteressant.


3. Schritt: Pufferberechnung

12. Ins Gantt-Diagramm zu jedem Vorgang die im 6. Schritt ermittelten σi eintra-gen.

13. Sollte es sich beim kritischen Pfad nicht um einen Pfad, sondern um ein Netzmit parallelen kritischen Vorgängen handeln: Von parallel laufenden kriti-schen Pfaden jeweils eines auswählen und als kritisch beibehalten. Die an-deren parallel laufenden kritischen Pfade werden ab sofort als nicht-kritischbetrachtet.

14. Die Größe des Gesamtpuffers g auf ganze Tage gerundet gemäß dem zentralen

Grenzwertsatz (Abschnitt 3.3.2) ermitteln: g = 2σ = 2 ·√

∑

i∈Kσ2i , 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 Ab-bildung 4.31.

Die Wahl von 2σ als Länge des Gesamtpuffers hat zur Folge, dass – sofern dieSchätzungen in Ordnung sind – das Projekt mit einer Wahrscheinlichkeit von97,5 % bis zum durch den Gesamtpuffer bestimmten Endtermin fertig wird. Mitgroß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 desGesamtpuffers wählen, dann wird das Projekt mit einer Wahrscheinlichkeit von99,85 % termingerecht beendet. Allerdings dürfte eine derartige Sicherheit i. Allg.zu Lasten der Konkurrenzfähigkeit gehen. Die Konkurrenten werden vermutlichkürzere Projektlaufzeiten im Angebot haben.

Aber selbst die Wahl von lediglich 1 · σ als Länge des Gesamtpuffers kann – gera-de im Hinblick auf die Konkurrenzfähigkeit – sinnvoll sein. Den dadurch ermittel-ten Endtermin kann man gemäß der 84/98/99,9-Regel mit 84 % Wahrscheinlich-keit einhalten. Das heißt, in nicht einmal jedem fünften Projekt wird der Terminnicht eingehalten.

Neben dem Projektgesamtpuffer für die kritischen Vorgänge sollten auch die sogenannten Zubringerpuffer für die nicht-kritischen Vorgänge möglichst geschicktermittelt werden. In Abbildung 4.24 und Abbildung 4.30 sind für die nicht-kriti-schen Vorgänge die freien Puffer als maximal möglichen Zubringerpuffer einge-tragen. 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 Vorgehenswei-se, wenn der Zubringerpuffer rechnerisch länger sein müsste, als es freien Pufferzulassen, werden im nächsten Abschnitt besprochen.


1. G

antt

−Dia

gram

m (

gem

äß C

PM

, ohn

e R

esou

rce

Lev

elin

g, m

it k

riti

sche

n P

fad

und

frei

en s

owie

ges

amte

n P

uffe

rzei

ten)

1. V

orga

ngsk

note

nnet

z

D gPsS

sEfEfSV

orga

ngsn

ame

<N

umm

er>

fS D fE sS gP sE

früh

este

r St

artte

rmin

= = = = = =

früh

este

r E

ndte

rmin

spät

este

r St

artte

rmin

spät

este

r E

ndte

rmin

gesa

mte

Puf

ferz

eit

Dau

er

MD

FS

SM

DF

SS

MD

FS

SS

SM

DM

DF

SS

MD

MD

MD

5. A

pril

2010

12. A

pril

2010

19. A

pril

2010

26.A

pril

2010

00

0 00

000

Star

t

0 0End

e

Star

t

End

e

Nam

e

1

2

8

Va

Va

Vb

Vc

Vd

Ve

Vf

33

03

30

Mei

lens

tein

kriti

sche

r V

orga

ng

Vor

gang

3

45

67

03

3

21 1

8

88 8

8

85

8

2

6

Vb

Vc

Vd

Ve

Vf

22

11

35

63

33

11

3

00

1

Mei

lens

tein

kriti

sche

r V

orga

ng

gesa

mte

Puf

ferz

eit

Vor

gang

frei

e Pu

ffer

zeit

Nr. 1 2 3 4 5 6 7 8

Dau

erV

orgä

nger

1EA

1EA

1EA

4EA

2EA

3EA

, 6E

A

5EA

, 7E

A

0d 1d 2d 3d 2d 2d 5d 0d

Abb

ildu

ng4.

23:P

roje

kt20

10:1

.Vor

gang

skno

tenn

etz

und

1.G

antt

-Dia

gram

m


B B A CAB,C

2. G

antt

−Dia

gram

m (

gem

äß C

PM

, mit

Res

ourc

e L

evel

ing,

kri

tisc

hem

Pfa

d un

d m

axim

alen

Zub

ring

erpu

ffer

n)

2. V

orga

ngsk

note

nnet

z (m

it R

esou

rce

Lev

elin

g)

D gPsS

sEfEfSV

orga

ngsn

ame

<N

umm

er>

fS D fE sS gP sE

früh

este

r St

artte

rmin

= = = = = =

früh

este

r E

ndte

rmin

spät

este

r St

artte

rmin

spät

este

r E

ndte

rmin

gesa

mte

Puf

ferz

eit

Dau

er

MD

FS

S

00

0 00

000

Star

t

0 0End

e1

2

8

Va

00

Mei

lens

tein

kriti

sche

r V

orga

ng

Vor

gang

3

45

67

3 252

Vb

Vc

Vd

Ve

Vf

22

11

33

BB

A

14

24

46

49

99

99

9 9

7 4

74

42

20

0

11

Nr. 1 2 3 4 5 6 7 8

Res

sour

ce

2

C

Nam

eD

auer

Vor

gäng

er

1EA

1EA

1EA

4EA

2EA

3EA

, 6E

A

5EA

, 7E

A

Star

t

Va

Vb

Vc

Vd

Ve

Vf

End

e

0d 1d 2d 3d 2d 2d 5d 0d

max

. Zub

ring

erpu

ffer

Vor

gang

kriti

sche

r V

orga

ng

Mei

lens

tein

SS

MD

MD

FS

SM

DM

DM

DM

DF

SS

MD

FS

S5.

Apr

il 20

1012

. Apr

il 20

1019

. Apr

il 20

1026

. Apr

il 20

10

Abb

ildu

ng4.

24:P

roje

kt20

10:2

.Vor

gang

skno

tenn

etz

und

2.G

antt

-Dia

gram

m


Ber

echn

ung

des

Ges

amtp

uffe

rs:

σ

B B A C

0,62

0,62

1,03

0,24

0,41

0,71

Ber

echn

ung

der

Zub

ring

erpu

ffer

:

B,C

A

3. G

antt

−Dia

gram

m (

gem

äß C

CP

M, o

hne

Pfe

ile, m

it R

esou

rce

Lev

elin

g, k

riti

sche

m P

fad,

Zub

ring

erpu

ffer

n un

d G

esam

tpuf

fer)

2*sq

rt(0

,62^

2) =

1,2

4 ~

1V

a

2*sq

rt(0

,62^

2 +

0.4

1^2

+ 0

,71^

2) =

2.0

6 ~

2V

b, V

e, V

f

2*sq

rt(1

,03^

2+0,

24^2

) =

2,1

1 ~

2V

c, V

d

MD

FS

SN

r.

Star

t

End

e

Nam

eD

auer

Vor

gäng

er

1 2 3 4 5 6 7 8

Va

Vb

Vc

Vd

Ve

Vf

Res

sour

ceS

SM

DM

DF

SS

MD

MD

MD

MD

FS

SM

DF

SS

Mei

lens

tein

Vor

gang

kriti

sche

r V

orga

ng

Zub

ring

erpu

ffer

Ges

amtp

uffe

r

1EA

1EA

0d 0d3d 2d 5d

1EA

5EA

, 7E

A

2d

3EA

, 6E

A

2EA

4EA

2d1d

26. A

pril

2010

19. A

pril

2010

12. A

pril

2010

5. A

pril

2010

Abb

ildu

ng4.

25:P

roje

kt20

10:3

.Gan

tt-D

iagr

amm


4.5.3 Zubringerpuffer (Feeding Buffer)

Wie werden bei CCPM nicht-kritische Vorgänge verwaltet? Bei der klassischenMethode des kritischen Pfades werden nicht-kritische Vorgänge so früh wie mög-lich 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, werdenspäter evtl. gar nicht mehr benötigt, falls sich die Projektziele ändern (Än-derungsmanagement).

– Gerade zu Beginn bestimmter Phasen werden evtl. viele Vorgänge gleichzei-tig gestartet. Dies hält dann den Projektleiter von seiner eigentlichen Aufga-be, die kritischen Bereiche zu managen, ab.

Goldratt schlägt daher vor, nicht-kritische Vorgänge so spät wie möglich zu be-ginnen. So spät wie möglich heißt: Man muss soviel Puffer vorsehen, dass Ver-zögerungen an nicht-kritischen Vorgängen nach Möglichkeit die kritische Kettenicht beeinträchtigen. Auch hier gilt wieder: Man fasst die Puffer möglichst vielernicht-kritischer Vorgänge zu einem Puffer zusammen und fügt diesen an das Endedes zugehörigen Teilpfades (Abbildung 4.26, a). Diese Art von Puffer wird vonGoldratt als Zubringerpuffer (feeding buffer) bezeichnet. Der Zubringerpufferist i. Allg. kleiner als der freie Puffer des zugehörigen Pfades (Abbildung 4.26, b).

V6 V7 V8

V1 V2 V3 V4

V6 V7 V8

V5

V1 V2 V3 V4 V5

a)

V1 V2 V3 V4 V5

V6 V7 V8 freier Pufferb)

c)

Zubringerpuffer

Abbildung 4.26: Ermittlung eines Zubringerpfades

Ein Teilpfad, für den ein Zubringerpuffer ermittelt werden kann, besteht aus einerFolge von nicht-kritischen Vorgängen, an deren Ende i. Allg. ein freier Puffer vor-handen ist, der mögliche Verzögerungen dieser Vorgangskette abpuffert, wie z. B.


V6→ V7 → V8 in Abbildung 4.26, b. Das Ergebnis dieses so genannten Zubrin-gerpfades wird von Vorgang V5 im so genannten Empfängerpfad V1→ . . .→ V5benötigt. Man beachte, dass Zubringerpfade kleiner als Empfängerpfade sein soll-ten. 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 Bei-spiel wird in Abbildung 4.26, c illustriert. So ein Pfad entsteht z. B., wenn alleVorgänge V1 . . . V8 kritisch sind und bei der Ermittlung der kritischen Kette dieVorgänge V6 . . . V8 im Schritt 13 des Algorithmus zur Ermittlung des Gesamtpuf-fers einfach als nicht-kritisch deklariert werden. Aber auch wenn alle VorgängeV1 . . . V8 nicht-kritisch sind, kann diese Konstellation in seltenen Fällen auftre-ten. In so einem Fall gibt es zwei Möglichkeiten, Zubringer- und Empfängerpfadfestzulegen:

1. Empfängerpfad V1→ V2 → V3→ V4→ V5Zubringerpfad V6→ V7 → V8

2. Empfängerpfad V1→ V6 → V7→ V8→ V5Zubringerpfad V2→ V3 → V4

Der Projektleiter wählt einfach den aus seiner Sicht wichtigeren Pfad als Emp-fängerpfad. In einem derartigen Fall ist ist der berechnete Zubringerpuffer größerals der (nicht vorhandene) freie Puffer. Im übernächsten Paragraphen Überhangwerden 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). An-hand des letzteren Gantt-Diagramms soll die Ermittlung der Zubringerpuffer nocheinmal genauer erklärt werden. In diesem Diagramm sind drei nicht-kritische Vor-gänge enthalten. Das Ergebnis von Vorgang B wird am 17. Juni bei Start desVorganges E benötigt. Da der Vorgang B nach vier Tagen abgeschlossen werdenkann, 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 Gesamter-gebnis erst zu Projektende benötigt wird. Der freie Puffer am Ende der beidenVorgänge beträgt ebenfalls vier Tage.

Für nicht-kritische Pfade wird der Zubringerpuffer auf die gleiche Weise wie derProjektgesamtpuffer für den kritischen Pfad, indem die Quadrate der Standardab-weichungen der zugehörigen Vorgänge aufsummiert werden und daraus die Wur-zel gezogen wird. Je nachdem, mit welcher Wahrscheinlichkeit man eine Verzö-gerung des kritischen Pfades vermeiden will, multipliziert man das Ergebnis mit 2


oder 3 (bei nicht-kritischen Vorgängen sind Verzögerungen wahrscheinlicher, daMitarbeiter meist nicht von anderen Aufgaben entlastet werden):

z1 = 2√

σ2B = 2

√

12 = 2

z2 = 2√

σ2D + σ2

F = 2

√

12 + 0, 832 = 2, 6 ≈ 3

Dementsprechend kann im Beispiel von Abbildung 4.22 der Start von Vorgang Bum zwei Tage nach hinten verschoben werden und der Start der Vorgänge D undF um jeweils einen Tag (Abbildung 4.22: unteres Diagramm).

In den Beispielen in Abbildung 4.25 und Abbildung 4.31 wurden die Zubringer-puffer auf dieselbe Art und Weise ermittelt.

Überhang

Bei der Ermittelung der Dauer eines Zubringerpuffers kann es passieren, dass garnicht 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, dieda sie auf parallelen Pfaden zur kritischen Kette liegen, einfach als nicht-kritischdefiniert wurden. Bei derartigen Vorgängen ist für einen Zubringerpuffer über-haupt kein Zeitfenster vorhanden (da sie ja eigentlich kritisch wären).

Über dieses Problem schweigt sich Goldratt leider aus. Und Leach [2005] schlägtlediglich vor, den Überhang einfach als Puffer in den nachfolgenden Pfad einzu-fügen (vgl. Abbildung 4.27, b).

V1 V2 V3 V4

V6 V7 V8b)

V5

V1 V2 V3 V4 V5

V6 V7 V8c)

V1 V2 V3 V4 V5

V6 V7 V8a)Überhang u

Abbildung 4.27: Überhang des Zubringerpuffers

Ich halte die Lösung von Leach für unbefriedigend, da Zwischenpuffer das Projektunnötig verlängern. Besser ist es, den Überhang zum Puffer der nachfolgendenKette (also zu einem Zubringerpuffer, falls die nachfolgende Kette nicht-kritischDraft (4. Oktober 2012) 162

ist, oder sonst zum Gesamtpuffer) hinzuzufügen (vgl. Abbildung 4.27, c). Dafürgibt es mehrere Möglichkeiten:

1. Den gesamten Überhang zum Gesamtpuffer hinzufügen (dies ist nicht vielbesser als Lösung b).

2. Den Überhang u als eigenständigen Vorgangspuffer ansehen, der bei derBerechnung des Puffers einfach mit einbezogen wird:

PufferV 1..V 5 = 2

√

σ21 + σ2

2 + σ23 + σ2

4 + σ25 +

(u

2

)2

=√

(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 jeweils2σ ermittelt wurde.

3. Den Überhang u mit dem „virtuellen Puffer“ v des Parallelpfades vergleichen

(siehe Abbildung 4.28, im Beispiel gilt v = 2√

σ22 + σ2

3 + 2σ24).

Ist u ≤ v, wird u ignoriert, anderenfalls wird der „Überhang des Überhangs“u− v gemäß 2. in den Gesamtpuffer eingerechnet.

PufferV 1..V 5 = 2

√

σ21 + σ2

2 + σ23 + σ2

4 + σ25 +

(

u− v

2

)2

V2 V3 V4V1 V5

V6 V7 V8Überhang u

V2 V3 V4virtueller Puffer v

Abbildung 4.28: Virtueller Puffer

Keine dieser drei Methoden kann mathematisch streng begründet werden, da eskein mit dem zentralen Grenzwertsatz vergleichbaren Satz für die Approximationder 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 auchschon abgepuffert ist und dieser Puffer teilweise mitbenutzt werden kann.

– Die dritte Lösung ist zu optimistisch, da die Wahrscheinlichkeit, dass sicheiner von zwei parallelen Vorgängen verzögert, höher ist, als dass sich eineinziger Vorgang verzögert.


Ich würde i. Allg. dennoch die dritte Lösung anwenden. Wenn allerdings an einerEinmündestelle gleichzeitig die Zubringerpuffer von drei oder noch mehr Ketteneinen Überhang aufweisen, würde ich zwar ebenfalls zur dritten Lösung tendieren,aber das Maximum aller parallelen Überhänge um einen gewissen Sicherheitsauf-schlag erhöhen.

Speziallfall

Wenn zwei kritische Pfade parallel verlaufen, muss bei CCPM einer der beidenPfade als nicht-kritisch dekalriert werden. In diesem Fall ist es besser, denjenigenPfad 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 Arbeitan einem kritischen Vorgang beginnt, sollte er von anderen wichtigen Aufgabenfreigestellt werden, so dass er ohne Verzögerung mit der Arbeit an dem kritischenVorgang 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 sonstwieexplizit dargestellt. Es handelt sich lediglich um eine Managementhandlung.


1. V

orga

ngsk

note

nnet

z (o

hne

Res

ourc

e L

evel

ing)

1. G

antt

−Dia

gram

m (

gem

äß C

PM

, ohn

e R

esou

rce

Lev

elin

g, m

it k

riti

sche

m P

fad

und

frei

en s

owie

ges

amte

n P

uffe

rzei

ten)

D gPsS

sEfEfSV

orga

ngsn

ame

<N

umm

er>

fS D fE sS gP sE

früh

este

r St

artte

rmin

= = = = = =

früh

este

r E

ndte

rmin

spät

este

r St

artte

rmin

spät

este

r E

ndte

rmin

gesa

mte

Puf

ferz

eit

Dau

er

MD

FS

SM

DF

SS

MD

FS

SS

SM

DM

DF

SS

MD

MD

MD

Nr.

00

0 00

000

Star

t

0 0End

e

00

1

2

5

8

4 5 6 7 8

Va

Vd4 0

Mei

lens

tein

kriti

sche

r V

orga

ng

Vor

gang

Vor

gang

Mei

lens

tein

3 Vb

Vc

12

3

4

213

37

1

Ve

6

Vf

7

35

79

78

99 9

9

91

8

90

77

25

54

4

73

3

8. A

ug. 2

011

1. A

ug. 2

011

15. A

ug. 2

011

22. A

ug. 2

011

gesa

mte

Puf

ferz

eit

frei

e Pu

ffer

zeit

kriti

sche

r V

orga

ng

321

Nam

eD

auer

Vor

gäng

er

Star

t

Va

Vb

Vc

Vd

Ve

Vf

End

e

0d 3d 1d 4d 2d 1d 2d 0d

1EA

1EA

2EA

2EA

, 3E

A

4EA

4EA

, 5E

A

6EA

, 7E

A

Abb

ildu

ng4.

29:P

roje

kt20

11:1

.Vor

gang

skno

tenn

etz

und

1.G

antt

-Dia

gram

m


2. V

orga

ngsk

note

nnet

z (m

it R

esou

rce

Lev

elin

g)

A B BBA, B

C

2. G

antt

−Dia

gram

m (

gem

äß C

PM

, mit

Res

ourc

e L

evel

ing,

kri

tisc

hem

Pfa

d un

d m

axim

alen

Zub

ring

erpu

ffer

n)

A

BB

B

D gPsS

sEfEfSV

orga

ngsn

ame

<N

umm

er>

fS D fE sS gP sE

früh

este

r St

artte

rmin

= = = = = =

früh

este

r E

ndte

rmin

spät

este

r St

artte

rmin

spät

este

r E

ndte

rmin

gesa

mte

Puf

ferz

eit

Dau

er

MD

FS

SM

DF

SS

MD

FS

SS

SM

DM

DF

SS

MD

MD

MD

8. A

ug. 2

011

1. A

ug. 2

011

15. A

ug. 2

011

22. A

ug. 2

011

00

0 00

000

Star

t

0 0End

e

00

1

2

5

8

Va

Vd4 0

Mei

lens

tein

kriti

sche

r V

orga

ng

Vor

gang

3 Vb

Vc

12

3

4

213

37

1

Ve

6

Vf

7

1 0

33

79

910

911

1111

1111

111110 9

7 97

03

22

Mei

lens

tein

kriti

sche

r V

orga

ng

Vor

gang

max

. Zub

ring

erpu

ffer

Nr. 1 2 3 4 5 6 7 8

Res

sour

ceN

ame

Dau

erV

orgä

nger

Star

t

Va

Vb

Vc

Vd

Ve

Vf

End

e

1EA

1EA

2EA

2EA

, 3E

A

4EA

4EA

, 5E

A

6EA

, 7E

A

0d 3d 1d 4d 2d 1d 2d 0d

Abb

ildu

ng4.

30:P

roje

kt20

11:2

.Vor

gang

skno

tenn

etz

und

2.G

antt

-Dia

gram

m


Zub

ring

erpu

ffer

:

Ges

amtp

uffe

r:

3. G

antt

−Dia

gram

m (

gem

äß C

CP

M, m

it R

esou

rce

Lev

elin

g, k

riti

sche

m P

fad,

Zub

ring

erpu

ffer

n un

d G

esam

tpuf

fer)

A B B

σ

1,65

1,78

BA, B

0,41

2,08

0,00

C

0,49

Pb =

2*0

,49

= 0

,98

~ 1,

P

e =

2*0

= 0

Pacd

f =

2*s

qrt(

0,41

²+2,

08²+

1,65

²+1,

78²)

= 6

,45

MD

FS

SM

DF

SS

MD

FS

SS

SM

DM

DF

SS

MD

MD

MD

8. A

ug. 2

011

1. A

ug. 2

011

15. A

ug. 2

011

22. A

ug. 2

011

Nr.

Star

t

End

e

Nam

eD

auer

Vor

gäng

er

1 2 3 4 5 6 7 8

Va

Vb

Vc

Vd

Ve

Vf

1EA

0d 0d3d 1d 4d 2d

1EA

2EA

1d 2d

2EA

, 3E

A

4EA

4EA

, 5E

A

Res

sour

ce

Mei

lens

tein

kriti

sche

r V

orga

ng

Vor

gang

Zub

ring

erpu

ffer

Ges

amtp

uffe

r

6EA

, 7E

A

Abb

ildu

ng4.

31:P

roje

kt20

11:3

.Gan

tt-D

iagr

amm


4.5.5 Kritischer Pfad und kritische Kette: Ein Vergleich

Methode des kritischen Pfades Methode der kritischen KetteStatistische Fluktuationen werden imAllgemeinen nur im Form von Puffer-zeiten in den einzelnen Vorgängen be-achtet.

Statistische Fluktuationen werden alsunabänderlich angesehen und daherbei der Planung und Projektverlaufvon Anfang an berücksichtigt.⇒ ParadigmenwechselBis heute ist es nicht gelungen, einVerfahren zu entwickeln, mit dem sichein in statistischer Hinsicht „optima-ler“ Zeitplan erstellen lässt. Daher gibtsich CCPM damit zufrieden, einenmöglichst guten Zeitplan zu erstellen.

Die Dauer eines Vorgangs wird so ge-schätzt, dass der Vorgang innerhalbder geschätzten Zeit mit großer Wahr-scheinlichkeit beendet wird (mindes-tens 80 %, meist jedoch deutlich mehr:90 %, 95 %, 99 %).Das heißt, alle Einzelschätzungen ent-halten implizit einen eigenen Puffer,um statistische Fluktuationen abzu-fangen.

Die Dauer eines Vorgangs wird so ge-schätzt, dass dieser Vorgang innerhalbder geschätzten Zeit lediglich mit ca.50 %-iger Wahrscheinlichkeit beendetwird (Erwartungswert≈Median).Die Einzelpuffer werden bei kriti-schen Vorgängen als Gesamtpuffer andas Projektende angefügt. Für zusam-mengehörige Ketten von nicht-kriti-sche Vorgänge werden die Einzelpuf-fer ebenfalls zu einem Puffer zusam-mengefasst als so genannte Zubringer-puffer ins Gantt-Diagramm eingefügt.Aufgrund statistischer Gesetze kön-nen der Gesamtpuffer und die Zubrin-gerpuffer i. Allg. deutlich kürzer ge-wählt werden, als die Summe der je-weils zugehörigen Einzelpuffer.⇒ Zeitgewinn

Fortsetzung auf der nächsten Seite


Methode des kritischen Pfades Methode der kritischen KetteVorgänge werden termingerecht been-det oder – bei unerwarteten Problemen– später. Trotz der großen Einzelpufferwerden Vorgänge i. Allg. nicht früherbeendet. Gründe:

– Studentensyndrom– Die Terminplanung sieht einen

früheren Start von Nachfolge-vorgängen nicht vor.

– Mitarbeiter haben keinen An-reiz einen Vorgang vor dem Ter-min zu beenden. Im Gegenteil:Wenn sie einen Vorgang früherbeenden, wird ihnen beim nächs-ten Mal i. Allg. weniger Zeit füreinen Vorgang gewährt. Und diesversuchen sie zu vermeiden.

Vorgänge werden vor, zum oder nachdem gesetzten Termin beendet.Für die Mitarbeiter gibt es keine fes-ten Terminvorgaben, sondern nur dieVorgabe, einen Vorgang so schnell wiemöglich zu beenden, ohne Abstrichean Funktionalität oder Qualität zu ma-chen. Mitarbeiter dürfen dabei nichtunter Druck gesetzt werden, insbeson-dere Überstunden sind nur in Ausnah-mefällen zulässig.⇒ Zeitgewinn bei früher, terminge-recht oder nur leicht verspätet beende-ten Vorgängen (da die Vorgangsdauerkürzer als bei CPM geschätzt wird).

Es wird häufig Multitasking, d.h. dergleichzeitige Einsatz von Mitarbeitern(oder anderen Ressourcen) in mehre-ren Vorgängen, betrieben.Dies geschieht vor allem, um jedeRessource so gut wie möglich auszu-lasten.Insbesondere kommt es oft zu Pla-nungen, bei denen eine Ressource inmehreren parallel laufenden Vorgän-gen jeweils zu 100 % verplant ist (feh-lendes Resource Leveling). DerartigeVorgänge werden normalerweise nichttermingerecht beendet.

Multitasking wird grundsätzlich ver-mieden, d.h., Resource Leveling istPflicht.⇒ Zeitgewinn, da Multitasking jedenEinzelvorgang bis auf den letzten ver-zögert.⇒ nochmals Zeitgewinn, da der Over-head, der durch Taskwechsel entste-hen würde, entfällt.

Fortsetzung auf der nächsten Seite


Methode des kritischen Pfades Methode der kritischen KetteMitarbeiter, die an kritischen Vorgän-gen arbeiten, werden nicht vom Tages-geschäft entlastet.

Mitarbeiter, die an kritischen Vor-gängen arbeiten, werden vom Ta-gesgeschäft entlastet (wenig Telefon,kaum E-Mails, keine anderen Aufga-ben etc.).⇒ Zeitgewinn

Die Drei-Punkt-Schätzmethode fürdie Dauer der Einzelvorgänge (kür-zeste Dauer, wahrscheinliche Dauer,längste Dauer) ist wenig hilfreich, daCPM für jeden Vorgang einen Schätz-wert und nicht drei benötigt.Natürlich kann man dennoch Drei-punkt-Schätzungen durchführen (wiedies beispielsweise bei PERT gemachtwird) und dann beispielsweise µi + σials Schätzwerte für die jeweilige Dau-er verwenden. Bei vielen Vorgängenist auch dieser (implizite) Puffer deut-lich zu groß.

Die Drei-Punkt-Schätzmethode fürdie Dauer der Einzelvorgänge (kür-zeste Dauer, wahrscheinliche Dauer,längste Dauer) ist sehr hilfreich undwird meist eingesetzt, um für jedenVorgang sowohl einen guten Schätz-wert für die Dauer (Erwartungswert),als auch für einen notwendigen Puffer(2 bis 3 mal Standardabweichung) zuermitteln.

Tabelle 4.1: Vergleich der Methoden des kritischen Pfades und der kritischen Kette


4.6 Beispiele für den erfolgreichen Einsatz vonCCPM

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 demgeplanten Stand zu vergleichen (Soll-Ist-Vergleich) und bei wesentlichen Abwei-chungen frühzeitig gegenzusteuern.

Kontrolle ist ein wesentlicher Bestandteil der fortwährenden Planung (der selbstauch 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 kom-men, 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 derVorgang beendet wurde oder nicht.

– Vorgänge sind kurz (wenn möglich ein oder wenige Wochen).

– Ergebnisse sind in irgendeiner Form messbar und damit vergleichbar.


4.8.1 Dringlichkeitslisten

Ein wichtiges Mittel zur Steuerung und Kontrolle von Projekten, sind die so ge-nannten Dringlichkeitslisten (hot lists). In diese Listen werden dringende Tätig-keiten (mit Terminen) eingetragen, die sich nicht exakt in ein Balkendiagrammbringen lassen oder die aus einem anderen Grund besonders beachtet werden müs-sen.

Die Dringlichkeitsliste sollte immer aktuell gehalten werden.

4.8.2 Tätigkeitsberichte

Um ein Projekt zu überwachen, kann man die so genannten Tätigkeitsberichteeinführen.

In einem (wöchentlichen) Tätigkeitsbericht trägt jeder Mitarbeiter ein, wie langeer an welchem Vorgang gearbeitet hat.

Achtung: Tätigkeitsberichte sind unbeliebt und tragen häufig zu einem schlech-teren Betriebsklima bei (vgl. Abschnitt 5.3). Um wirklich Tätigkeitsberichte undkeine Lügenberichte zu erhalten, sollten Sie sie nach Möglichkeit vermeiden oderzumindest Folgendes beachten:

– Entweder alle oder keiner (und nicht etwa nur die schlechteren Mitarbeiter).

– Keine minutengenaue Zeiterfassung. Eine Genauigkeit von höchstens 1 hreicht vollkommen.

– Machen Sie ihren Mitarbeitern klar, dass Sie wissen, dass die Mitarbeiterhöchstens 6 h an 4 Tagen pro Woche produktiv für das Projekt arbeiten kön-nen.

– Machen Sie ihren Mitarbeitern außerdem klar, dass die Erfassung von Über-stunden für sie nur von Vorteil ist.

– Machen Sie den Mitarbeitern außerdem klar, dass die Erfassung der Datennicht 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 Mitar-beiter, sondern für Ihre Mitarbeiter (zu deren Entlastung) ein.

Tätigkeitsberichte haben mehrere Vorteile:

– Ihnen stehen aktuelle Zahlen (einschließlich aktualisierter Schätzungen) fürdie weitere Planung zur Verfügung.

– Sie haben konkrete Zahlen für realistische Schätzungen von Folgeprojekten.


– Sie sehen, bei welchen Tätigkeiten Projektarbeitszeit verloren geht.

– Sie haben Daten (nachdem Sie die Einzeldaten anonymisiert und aggregierthaben), mit denen Sie gegenüber Betriebsrat („Warum so viele Überstun-den?’") und dem Management („Warum so wenig Projektarbeit?“) argumen-tieren können.

Tätigkeitsberichte können allerdings zum echten Problem werden, wenn Sie dieobigen Punkte nicht strikt beachten. Mir ist eine ehemalige Mitarbeiterin einesgroßen deutschen Unternehmens bekannt, die sich irgendwann weigerte, Tätig-keitsberichte zu unterschreiben. Jedesmal, wenn sie einen derartigen Bericht ge-wissenhaft ausgefüllt hatte, kam ihr Chef und „verbesserte“ (genauer: fälschte)ihn. Alle Meetings und sonstigen Arbeitsstunden, die nicht irgendeinem Projektzugeordnet werden konnten, für das die Abteilung stundenweise bezahlt wurde,wurde einem dieser Projekte zugeschlagen. Später hat der Chef diese Berichteselbst unterschrieben (nachdem er sie entsprechend seinen Vorstellungen ange-passt hatte).

4.8.3 Zeitdiagramme

Die Schätzungen, wie viele Tage ein Vorgang noch benötigt, können in ein sogenanntes Zeitdiagramm eintragen werden.

D8. 15. 22. 29. 6. 13. 20. 27. 3. 10. 17. 24.

8.

15.

22.

29.

6. Juli

13.

20.

27.

3. Aug.

10.

17.

24.

1. Juni

tatsächliche Zeit

geplanteZeit

A B C

Der Schätzer von A hat für die berühmten letzten 10 % länger gebraucht, als für


unge

plan

t

Tät

igke

itsbe

rich

tN

ame:

Dat

um (

Mon

tag)

:H

. Mei

er22

. Jun

i 199

8

Übe

rstu

nden

Sum

me

Sons

t. (z

.B. V

erw

altu

ng)

Lite

ratu

rstu

dium

Aus

bild

ung

Allg

. Mee

tings

sons

t. A

bwes

enhe

it

Url

aub

Kra

nkhe

it, A

rzt

Aus

fallz

eite

n

Proj

ekt

Tät

igke

it

Am

unC

odie

rung

Des

ign

Die

nstg

ang

Inte

rvie

w H

r M

.

War

tung

Mo

Di

Mi

Do

FrB

emer

kung

enSu

mm

eno

ch T

age

24

42

12

4 2 8

3 6 9 1

822

2 6 -2

831

6 3 2 8 2 3 3 39 -1

2 20

2

31

uner

war

t. P

robl

eme

Tabe

lle

4.2:

Bei

spie

lein

esT

ätig

keit

sber

icht

es


den Rest. B war ein optimaler Schätzer (ein Pedant?). C wurde unterwegs opti-mistisch, erreichte dann jedoch das Ziel „nur“ zur anfangs geplanten Zeit. UndD hatte zum Schluss eine Woche Verzögerung, nachdem er zwischenzeitig pessi-mistischer geschätzt hatte.

4.8.4 Gesamtpufferverbrauch als Risikoindikator

Die Kontrolle des Gesamtpufferverbrauchs liefert einem einen wunderbaren Indi-kator 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 nichtmehr als 50 % des Puffers verbraucht worden sein.

Dies kann man mit einem ganz einfachen Diagramm überwachen (siehe Abbil-dung 4.32): In der x-Richtung werden die kritischen Vorgänge eingetragen undzwar jeweils an demjenigen Projekttag, an dem sie beendet sein sollten (Wochen-ende und Feiertage werden nicht beachtet!). In y-Richtung notiert man für jedenVorgang, sobald er abgeschlossen wurde, den Gesamtpufferverbrauch (entwederprozentual oder auch in Tagen).

Das Diagramm wird in drei Bereiche eingeteilt: Einen roten Bereich, einen gelbenBereich und einen grünen Bereich.

Das Diagramm wird wie folgt interpretiert: Solange die Eintragungen im grünenBereich vorgenommen werden, ist auch alles auch alles im grünen Bereich. Soll-te der Pufferverbrauch in den gelben Bereich eintreten, so muss der ProjektleiterGegenaktionen (wie z. B. eine Änderung des Terminplans oder des Funktionsum-fangs) 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 Be-reich gelegt wird, muss jeder Projektleiter selbst entscheiden. Im Beispiel um-fasst der Bereich zu Projektbeginn das Intervall [20%, 40%] und zu Projektende[90%, 100%]. Diesen Intervallen (die ich favorisieren würde) liegt die Idee zu-grunde, dass, wenn es zu Projektanfang zu etwas größeren Schwankungen kommt,diese nicht gleich zu hektischen Gegenreaktionen führen sollten. Ein großer Puf-ferverbrauch zu Projektende ist auch kein Drama mehr. Mann könnte das Intervallbei 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 Puffer-verbrauch von mehr als 90 % bei Projektende ein unerwünschtes Ergebnis. EinPufferverbrauch von 60 % kurz vor Projektende nötigt den Projektleiter noch zu


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 „Projekt-verlauf“ (angefertigt von Wolfram Müller von www.Speed4Projects.Net) vorge-stellte gelbe Bereich liegt zu Projektbeginn im Intervall [−31%, 50%] (das Mi-nuszeichen ist kein Druckfehler!) und zu Projektende im Intervall [92%, 100%].Während das Projektende in Ordnung ist, ist der Projektbeginn vollkommen un-brauchbar. Selbst wenn man zu Projektbeginn den Gesamtpuffer vergrößern kann,befindet man sich im gelben Bereich, der anzeigt, dass man Gegenmaßnahmenplanen muss. Erst nachdem 25 % des Projektes fertiggestellt wurden, liegt ein Ge-samtpufferverbrauch von 0 % im grünen Bereich!???

Im CCPM-Artikel von Klein et al. [2005] ist sogar ein noch größerer gelber Be-


reich angegeben. Im selben Artikel wird Dr. Hans-Joachim Schulz, Geschäftsfüh-rer von Transtechnik zitiert, dass er sich nur um Projekte, deren Gesamtpuffer-verbrauch sich im roten oder gelben Bereich befindet, zu kümmern braucht. Dasvorgestellte Diagramm bedeutet für den armen Herrn Schulz, dass sich geradezu Projektanfang jedes Projekt im gelben Bereich befindet und er sich mit allendiesen 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 denNull-Punkt herum.

– Die zu optimistisch geschätzten Projekte streben von der x-Achse nach obenweg.

– 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 nega-tive y-Achse eingezeichnet, um noch einmal klar zu machen, dass die vorzeitigeBeendigung eines Vorgangs genauso häufig passiert, wie die verspätete Beendi-gung. Leider wird diese Tatsache weder im Buch von Leach [2005] noch im Wi-kipedia-Artikel zu CCPM (Wikipedia [2011a]) noch im Artikel von Klein et al.[2005] visualisiert. Auch hier stellt man wieder fest, dass eine vorzeitige Abgabevon Ergebnissen für die meisten Menschen keine Option darstellt, die man ernst-haft 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 spiegelnaber ein falsches Bild wieder. Wenn zum Zeitpunkt x beispielsweise die SOLL-Kosten gleich den IST-Kosten sind, aber erst 67 % der bis dahin geplanten Arbeitgeleistet 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 genannteEarned-Value-Analyse (Arbeitswert-Analyse) eingeführt.

Der Earned-Value (Arbeitswert) gibt den Wert der Arbeit an, die bis zum Stichtaggeleistet wurde. Dieser Wert entspricht den Kosten, die tatsächlich hätten entste-hen dürfen. Im obigen Fall entspricht der Earned-Value lediglich 67 % der SOLL-Kosten. Verglichen mit dem Earned-Value sind die IST-Kosten um den Faktor 1,5zu hoch.


Kennzahlen einer Earned-Value-Analyse

1. Budgetkosten der geplanten Arbeit (BCWS = Budgeted Cost of Work Sche-duled)BCWS bezeichnen die Kosten, die für die bis zum Zeitpunkt x geplante Arbeiteingeplant waren: Sollkosten für geplante Arbeit.

2. Earned Value (BCWP = Budgeted Cost of Work Performed)BCWP werden oft als Budgetkosten der geleisteten Arbeit bezeichnet. Siebezeichnen die Kosten, die für die bis zum Zeitpunkt x tatsächlich geleisteteArbeit eingeplant waren: Sollkosten für geleistete Arbeit.BCWP/BCWS entspricht dem Prozentsatz der geleisteten Arbeit (in unse-rem Beispiel z. B. 40 000/60 000 = 0, 67). Man kann auch die Differenz vongeleisteter und geplanter Arbeit bilden: BCWP − BCWS (in unserem Fall40 000 − 60 000 = −20 000). Dieser Wert heißt Leistungsabweichung oderPlanabweichung (SV , schedlue variance). Negative Planabweichungen sagen– genauso wie BCWP/BCWS-Werte < 1 – aus, dass man entweder dem Planhinterherhinkt 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 Diffe-renz BCWP−ACWP heißt Kostenabweichung (CV). Der Faktor (cost varian-ce) ACWP/BCWP (= 1,5 in unserem Beispiel, da in unserem Beispiel ACWP= BCWS angenommen wurde) kann verwendet werden, um eine neue Schät-zung für die Projektgesamtkosten zu erstellen. Der Kehrwert BCWP/ACWP(= 0,67 in unserem Beispiel) heißt Kostenentwicklungsindex (CPI, cost per-formance 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 costto completion).

An Tag X hätte die erst am Stichtag geleistete Arbeit bereits geleistet sein sollen.


Kosten−

Leistungs−abweichung (SV)

abweichung (CV)

BCWS

BAC

Kosten

Zeit

Stichtag

ACWP

BCWP

EAC

Restkosten(ETC)

Kostenabweichungzur Fertigstellung

(VAC)

Soll/Ist−Abweichung(keine Aussagekraft)

X

Istkosten

Sollkosten

Plankosten

Abbildung 4.33: Übersicht über die wesentlichen Earned-Value-Größen


Kapitel 5

Menschenführung undTeamarbeit

5.1 Management

Einen ganz wesentlichen Anteil am Projekterfolg hat das Management, da es fürdas Klima im Unternehmen die Hauptverantwortung trägt. Mitarbeiter, die sichwohlfühlen und mit dem Unternehmen identifizieren, leisten mehr.

Patrizia Pitcher, Professorin für Führungsfragen an der kanadischen Business-School École des Hautes Études Commerciales in Montreal, hat ein Buch mitdem Titel „Das Führungsdrama“ geschrieben (Pitcher [1997]). Darin seziert siedie Gründe für den Aufstieg und den Fall einer weltweit operierenden, milliar-denschweren 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 Grau-zonen und eher 9 Gruppen gibt):

Künstler: intuitiv, visionär, unternehmerisch, sprunghaft, kühn, menschen-orientiert 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 kreativerHandwerker oder praktischer Künstler)1, niemals jedoch aus allen dreien.

Dem oben erwähnte Unternehmen gelingt mit einem Künstler als Firmengrün-der, vier Handwerkern und einem Technokraten in der zweiten Führungsebeneein atemberaubender Aufstieg in die Weltspitze. Technokraten besorgten späterden Niedergang. Sie sind zwar brillant, aber am falschen Platz verheerend. Erst

1 Solche Menschen suchen wir als Multimedianer!


wurde der Künstler (ohne ihn vorher zu informieren) gefeuert, dann die Handwer-ker. Alle wurden durch Technokraten (d. h. Klone der vorhandenen Technokraten)ersetzt.

Es gab neue Computer, neue Kontrollverfahren, Vorführungen, auf denen ledig-lich gezeigt wurde, wie toll die Firma ist etc. Neue Märkte, neue Produkte, neueProjekte waren out – in waren nur noch neue Wege, die Firma zu organisieren.Viele gute Leute wurden entlassen, weil angeblich ihre Ergebnisse schlecht wa-ren.

Technokraten sind „dumm und blind“ (Pitcher [1997]). Sie glauben selbst, alles imInteresse der Firma zu tun. Sie glauben auch, dass Künstler mit ihren verrücktenVorstellungen eine Gefahr für die Firma sind und Handwerker zu dumm, um einenBeitrag zu leisten.

5.2 Führungsstile

„Angewandte Führungsstile sind nur dann erfolgreich, wenn die menschlichenEigenschaften der am Führungsprozess beteiligten zusammenpassen.“ (Oyen undSchlegel [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 sindaktiv am Prozess der Willensbildung beteiligt.

– Laissez-faire-FührungDer „Führende“ stellt lediglich sachliche Arbeitsmittel bereit, greift aber indie 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 seinenEntscheidungen.

kooperativ: Der Vorgesetzte entscheidet erst, nachdem er die Meinung derUntergebenen gehört hat.


partizipativ: Das Team entwickelt Vorschläge, der Vorgesetzte wählt einenaus.

demokratisch: Der Vorgesetzte legt den Entscheidungsspielraum fest, das Teamentscheidet.

demokratischer: Das Team entscheidet, der Vorgesetzte fungiert als Koordinatornach innen und nach außen.

Heute werden die verschiedenen Führungsstile normalerweise Management-by-Methoden genannt (Schmidt [2003]).

– Management by Objectives (MbO, weit verbreitet)Die Führung durch Zielsetzung basiert im wesentlichen auf der regelmäßi-gen Festlegung von Unternehmens- (oder Projekt-)zielen. Vorgesetzte ge-ben ihren Mitarbeitern Ziele vor, die Mitarbeiter entscheiden selbstständig.Am Periodenende werden die Mitarbeiter beurteilt (vorgegebene vs. erreich-te Ziele).Dies ist der Managementstil der 50er-Jahre. Er ist vollkommen veraltet undunbrauchbar, aber leider weit verbreitet. (Deming [2000],DeMarco und Lis-ter [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 Team-

arbeit.• 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 op-

timieren – insbesondere auf Kosten anderer). Dies steht jedoch fast im-mer im Widerspruch zur globalen Optimierung, die die Optimierungder Unternehmensgewinne und anderer Unternehmensziele zur Aufga-be hat (vgl. Abschnitt 1.2.3 (ToC): Die Optimierung der Leistung allerFahrzeuge oder Maschinen ist auch hier kontraproduktiv.)

Der Widerspruch, dass sich viele lokale Optimierungsbemühungen kontra-poduktiv auf die globalen Optimierungsbemühungen auswirkt, wird von Ro-bert D. Austin als Dysfunktion bezeichnet (Austin [1996]). Austin führt fol-gendes Beispiel an: Wenn in einer Fabrik die Anzahl der Nägel optimiertwerden soll, werden nur noch kleine Stahlstifte produziert. Wird dagegendas Gewicht optimiert, werden nur noch Gleisbolzen hergestellt. Das Un-ternehmensziel, möglichst viele Nägel zu verkaufen, wird in beiden Fällen


nicht erreicht, da die von Kunden gewünschten Nägel fehlen.DeMarco [2001] begründen aufgrund der jahrzehntelangen Erfahrung mitMbO, dass Dysfunktion ein inhärenter Mangel von MbO ist. Beispielsweiseverkauft ein Verkäufer, der aufgrund von MbO angespornt wird, eine Ver-kaufsquote zu erfüllen, mit hoher Wahrscheinlichkeit kaum benötigte Güter.Der Effekt ist, dass die Kundenbasis immer kleiner wird, weil die Kunden-zufriedenheit 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ölligselbständig entschieden. Ausnahmefälle, d. h. insbesondere Abweichungenvon vereinbarten Zielen, werden vom Vorgesetzten entschieden. ⇒ KlareDefinition der übertragenen Aufgaben ist wichtig. Alles, was nicht klar fest-gelegt wurde, ist ein Ausnahmefall.Auch hier gelten Kontrollzahlen als Maxime. Damit ist auch diese Methodenicht besser als MbO.

– Management by Delegation (MbD)Aufgaben und Befugnisse werden an Mitarbeiter unterer Hierarchieebenendelegiert und geeignet kontrolliert.Kompetenzen an Untergebene abzugeben und diesen Vertrauen zu schenkenist ein Prinzip, dass auch von Tom DeMarco und Timothy Lister favorisiertwird (DeMarco und Lister [1991], DeMarco [2001])

– Management by Participation (MbP)Starke Mitarbeiterbeteiligung bei Entscheidungen, das heißt schwache par-tizipative Führung.

– Management by Alternatives (MbA)Es werden mehrere Lösungsalternativen entwickelt und eine ausgewählt, dasheißt starke partizipative Führung.

– Management by Motivation (MbM)Der Vorgesetzte versucht Bedürfnisse, Interessen, Einstellungen und persön-liche Ziele der Mitarbeiter zu erkennen und diese zum Wohle des Unter-nehmens (oder Projektes) einzusetzen. Die Mitarbeiter sollten Spaß an derArbeit haben.

– Und viele weitere . . .

Es fällt auf, dass autoritäre Führungsstile gar nicht als Mb-Methoden formalisiertwurden.


5.3 Druck

(vgl. DeMarco [1998], DeMarco [2001])

Tom DeMarco schlägt folgendes Gedankenexperiment vor: Wenn die Mitarbeiterohne Druck ihr aktuelles Projekt bis zum Zeitpunkt X fertigstellen, wie verschiebtsich 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]):

0 Druck0

X

Kein Druckaußer bestehender Vertragund Interessae an Tätigkeit

Dauer

Die unter Managern weit verbreitete Meinung ist, dass durch die Erhöhung desDrucks der Fertigstellungstermin deutlich vorverlegt werden kann. Einen Zeitge-winn von 50% halten viele Manager für realistisch. Eine weitere Erhöhung desDrucks soll dann zwar keinen zusätzlichen Zeitgewinn mehr mit sich bringen. Ersoll 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äu-fer einer Großbäckerei, mag es gelten, dass massiver Druck sie zu andauerndenHöchstleistungen anspornt. Und wenn genug Nachschub zum Ausgleich der Mit-arbeiterfluktuation (Kündigung, Tod auf der Galeere etc.) vorhanden ist, mag dieRechnung sogar aufgehen. Aber selbst Numerobis merkt schnell, dass er trotzzahlreicher Peitschenhiebe sein Ziel nicht erreichen kann (Goscinny und Uderzo[1968]). Uns steht ein Zaubertrank als bessere Alternative leider nicht zur Verfü-gung.


Kann diese Modell auch für Wissensarbeiter funktionieren, wenn es anscheinendbei 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 „Zielver-einbarungen“, angeordnete Überstunden etc. zu höheren Leistungen angesporntwerden 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ön-nen. Bei Wissensarbeiten ist die Vorstellung, durch Druck bessere Arbeitsleistun-gen erzielen zu wollen, vollkommen abwegig. Laut Tom DeMarco gibt es eineneinfachen Grund dafür:

Leute, die unter Druck stehen, denken nicht schneller. (DeMarco[2001])

Nachdenken kann man man nicht beschleunigen. Wer optimale Leis-tungen erbringen will, sollte dafür sorgen, dass er kein Multitaskingbetreibt und eine Zeitlang nicht erreichbar ist. (Barbara Knab in Pil-gram [2011])

Stress mache nicht erfinderisch, sagt auch der Zeitforscher KarlheinzGeißler. „Unter Zeitdruck neigt man dazu, eher konventionelle Lösun-gen anzustreben“ (Pilgram [2011])

Die Anzahl der elementaren Entscheidungen pro Sekunde kann durch Druck nichterhöht werden. Menschen können lediglich Zeitverschwendungen vermeiden undabends länger arbeiten. Das hat aber in gesunden Organisationen kaum Auswir-kungen, da motivierte Mitarbeiter sowieso wenig Zeit verschwenden, wenn dasManagement sie arbeiten lässt, und längere Arbeitszeiten lediglich eine höhereFehlerquote erzeugen. Fehler, die man um 2000 Uhr gemacht hat, muss man amnächsten Tag erst einmal beseitigen, bevor man weiterarbeiten kann, oder sie stö-ren den Ablauf zu einem anderen ungünstigen Zeitpunkt. Wissensarbeiter leistenim Durchschnitt an einem Zehn-Stunden-Tag absolut (und nicht nur relativ) nichtmehr als an einem Acht-Stunden-Tag.

Tom DeMarco geht davon aus, das durch wenig Druck die Arbeitsleistung ummaximal 15% erhöht werden kann. Bei zuviel Druck konzentrieren sich die Mit-arbeiter mehr auf den Druck als auf die Projektarbeit. Bei sehr viel Druck kündi-gen die guten und vor allem die besten Mitarbeiter. Das heißt, das Ergebnis desdes obigen Gedankenexperiments sieht eher folgendermaßen aus (vgl. DeMarco[2001]):


0 Druck0

X

Kein Druckaußer bestehender Vertragund Interessae an Tätigkeit

Dauer

Ganz ohne Druck arbeitet ein Mensch normalerweise sicher eher ineffizient (vgl.Studentensyndrom, Abbildung 1.3). Realistische Meilensteine sorgen allerdingsschon für genug Druck. Und ein wenig zusätzliche Motivation kann sicher auchnicht schaden (siehe Abschnitt 5.5).

Doch spätestens, wenn das letzte Quäntchen Ineffizienz eliminiert wurde, bewirktweiterer Druck das genaue Gegenteil von dem, was sich der Manager davon ver-spricht. Zunächst fangen die Mitarbeiter an, selbst für Ausgleich zu sorgen (ver-mehrt private Telefonate; vermehrtes nutzloses Surfen; Arztbesuch während derArbeitszeit, auch wenn dies außerhalb der Arbeitszeit möglich wäre etc.). Wächstder Druck weiter, so folgt irgendwann die innere Kündigung und/oder die echteKündigung. Je besser die Mitarbeiterin ist, umso eher sieht Sie sich nach einerneuen Stelle um. Aber es sind gerade die Besten, die ein Unternehmen haltenmuss, um erfolgreich zu sein (Kanter und Zagata-Meraz [2007]). Laut einer Stu-die (Gallup Engagement Index 2010) der Marktforscher von Gallup in Potsdamhaben im Jahr 2010 21 % der Beschäftigten in Deutschland innerlich gekündigt,66 % machen Dienst nach Vorschrift. Im Oktober und November 2010 wurdeninsgesamt 1 920 Arbeitnehmer repräsentativ für die Arbeitnehmerschaft ab 18Jahren befragt. „Die volkswirtschaftlichen Kosten aufgrund von innerer Kündi-gung belaufen sich auf eine Summe zwischen 121,8 und 125,7 Milliarden Eurojährlich.“ Dies entspricht 11 mal dem Etat für „Bildung und Forschung“ im Jahr2011. Die Fehlzeiten der Arbeitnehmer, die eine hohe innere Bindung an Unter-nehmen haben ist 21,7 % geringer als die der Arbeitnehmer ohne innere Bindung.


Außerdem ist deren Innovationskraft um 40,5 % höher. (Gallup [2011])

Tom DeMarco bezeichnet das erste, grundfalsche „Druckmodell“ als das Modelleines Kindesmisshandlers. Dieser meint durch vollkommen überzogene Strafendie Ungezogenheit der Kinder minimieren zu können. Obwohl jeder gebildeteMensch heute wissen sollte, dass sich misshandelte Kinder schlechter benehmenals andere Kinder, sind Misshandlungen immer noch an der Tagesordnung.

Manager, die ihre Mitarbeiter massiv unter Druck setzen, um vermeintlich mehrLeistung zu erzielen, erreichen nur das Gegenteil und sind auch nicht viel besserals Kindesmisshandler und peitschenschwingende Sklavenaufseher.

5.3.1 Folgen von übermäßigem Druck

– Verzögerung von Terminen (Der Mitarbeiter beschäftigt sich mehr mit derDruckvermeidung als mit seiner Arbeit)

– Mitarbeiter kommen krank in die Arbeit, machen Fehler und stecken ge-sunde Kollegen an (Laut einer Studien der „Felix Burda Stiftung“ hätte ei-ne Gesundheitsvorsorge, die vollständig über den Arbeitgeber abgewickeltwird, weniger Ausfallzeiten, weniger Krankheitstage, mehr Motivation undeinen Image-Bonus zur Folge; News [2011])

– Burnout

– innere Kündigung

– Bildung von „Zombies“ (so nennt Tom DeMarco Mitarbeiter die keinen pro-duktiven Beitrag mehr leisten; ich habe einmal von einem Mitarbeiter gehört,der bei einem großen deutschen Unternehmen jahrelang ein Postwägelchendurch die Gegend geschoben haben soll ohne je etwas von A nach B gebrachtzu haben)

– steigende Mitarbeiterfluktuation (mehr echte Kündigungen)

Die Kosten der Mitarbeiterfluktuation belaufen sich laut Gallup Engagement In-dex 2010 auf durchschnittlich 1.314 Euro je Mitarbeiter und Jahr an. Die Ermitt-lung dieser Kosten auf Basis der Umfrageergebnisse ist laut Gallup als „konser-vativ“ anzusehen. Sie merken an, dass andere Quellen als Fluktuationskosten proMitarbeiter das doppelte der reinen Gehaltskosten und der Nebenkosten eines Jah-res anführen. Gallup [2011]

5.3.2 Wie übt man Druck aus?

Es folgt eine unvollständige Liste von Möglichkeiten, Druck auszuüben:


– Leistungssteigerungsprogramme (wie z. B. bei Infineon, Handelsblatt[2003])

– Ausüben von negativem Druck wie Verbreitung von Angst, z. B. indem manjährlich die so genannten „low performer“ entlässt, wie dies z. B. unter JackWelch bei General Electrics üblich war (Handelsblatt [2003]); Abhilfe: Ne-gativen Druck vollkommen vermeiden.

– Ausüben von „positivem“ Druck (so genannte Motivationsanreize), wie z.B.Auszeichnung des Mitarbeiter des Monats, Außergewöhnliches Engagementeinzelner Mitarbeiter in Gegenwart anderer herausheben, MbO etc.(d. h. ex-trinsische Motivation als Ersatz für intrinsische Motivation); Abhilfe: Auf„positiven“ Druck ebenso verzichten.

– Mitarbeitern falsche/ungeeignete/diskriminierende Aufgaben zuweisen, nurerstklassige Leistungen gelten lassen; Abhilfe: Mitarbeiter gemäß ihren Fä-higkeiten und Neigungen einsetzen.

– Management-Todsünden begehen wie Diskriminierung, Missachtung, Her-abwürdigung, Lächerlich machen von Mitarbeitern, Mitarbeitern sinnloseExtraarbeiten aufhalsen; Abhilfe: Sich auf keinen Fall zu solchen Aktionenverleiten lassen.

– Mobbing; Abhilfe: Aktiver Kampf gegen Mobbing, Mediatoren.

– Dokumentationswahn (zum Beispiel: jede Tätigkeit muss stundengenau er-fasst werden – ich habe sogar einmal erlebt, wie ein Chef eine seiner Sekretä-rinnen angewiesen hat, ihre Tätigkeiten minutengenau zu erfassen – dies fälltbereits unter die Kategorie „Herabwürdigung“ oder gar „Mobbing“, wenndiese Anweisung längerfristig aufrechterhalten wird); Abhilfe: Die Mitar-beiter lieber produktiv arbeiten lassen.

– Überstunden; Abhilfe: Überstunden vermeiden, wann immer dies möglichist (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 50Prozent der Fälle sollte der Vorgang schneller erledigt werden und in 50Prozent der Fälle langsamer.

– Scheintermine oder sich über scheinbare Zeitvergeudung ereifern (nochschlimmer als fixe Termine); Abhilfe: Darauf verzichten.

– Selbst mit gutem Beispiel vorangehen (immer der erste sein, der kommt, undder letzte, der geht), um zu zeigen, was von den Mitarbeitern erwartet wird;Abhilfe: Darauf verzichten.

– Kommunikationsoverhead; Abhilfe: Einzelne Aufgaben möglichst von klei-


nen Teams bearbeiten lassen, Kommunikationsbedarf zwischen den ver-schiedenen Teams gering halten, gute Kommunikationsplattformen einset-zen, keine Massenmeetings.

– Bürokratie; Abhilfe: Bürokratie vermindern (z. B. sollte sich jeder Mitarbei-ter Büromaterial aus einem Schrank nehmen können ohne vorher ein For-mular ausfüllen und die Unterschrift zweier Bevollmächtigter einholen zumüssen).

5.4 Teamarbeit

Dieser Abschnitt muss überarbeitet werden.

Teamarbeit ist die ausgeprägteste Form der Gruppenarbeit. Sie hat viele Vortei-le (wie hoher Problemlösungsgrad und gegenseitige Anregung und Verstärkung).Allerdings gibt es auch Nachteile (wie hoher Kommunikationsaufwand, Konkur-renzdenken 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


5.5 Motivation

(vgl. Kupper [1993])

Einer der wichtigsten Erfolgsfaktoren für Team- und/oder Projektarbeit ist dieMotivation von Mitarbeitern (siehe MbM).

Man unterscheidet dabei zwischen intrinsischer und extrinsischer Motivation.Wenn ein Mitarbeiter intrinsisch motiviert ist, erledigt er seine Arbeit aus eige-nem Antrieb heraus, weil er an der Arbeit Interesse und auch Spaß hat. Ist erhingegen extrinsich motiviert, so erledigt er seine Arbeit aufgrund äußerer Grün-de, um z. B. Geld zum Leben zu verdienen oder um unangenehme Konsequenzenzu vermeiden.

Obwohl intrinsisch motivierte Mitarbeiter i. Allg. wesentlich bessere Arbeitser-gebnisse 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 Basket-ballprofi Dirk Nowitzki. Bereits im Jahr 2008 kündigte er an, dass er zugunstenvon attraktiven Neuverpflichtungen auf einen Teil seines Gehaltes verzichten wür-de. 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 anLeistung 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 den-noch 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 Mit-arbeitern festzustellen (von Rosenstiel und Lutz [1974]):

Die Introspektion

Der Mensch versucht die Motive seines Handelns selber zu analysieren („Warumrauche ich?", „Warum mag ich Kollegin Meyer nicht?“).


Die Introspektion hat zwei Nachteile: Zum einen ist es oft schwer die wirklichenGrü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 Elternversamm-lung.“ anstelle von „Ich habe diese Woche schon zweimal bis in die Nacht hineingearbeitet.“).

Abhilfe für das zweite Problem: starke Vertrauensbasis zwischen Vorgesetztenund Untergebenen und am besten auch zwischen Kollegen; Ehrlichkeit und Of-fenheit des Vorgesetzten.

Die Fremdbeobachtung

Die Fremdbeobachtung (Vorgesetzter beobachtet Mitarbeiter etc.) ist ebensoschwer wie die Introspektion. („Frau Huber arbeitet sehr produktiv. Sie identi-fiziert sich also mit dem Projekt.“ In Wirklichkeit will sie dem Chef der Nach-barabteilung imponieren, damit sie in ein weniger chaotisches Projekt wechselnkann.)

Analyse von Verhaltensergebnisse

Hier werden nicht Verhaltensweisen direkt, sondern Ergebnisse von Verhaltens-weisen analysiert. Es gehört viel detektivisches Gespür dazu, daraus die richtigenSchlü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 unvermuteteProbleme gab, die Franz mit einer Kollegin der Nachbarabteilung zu lösen ver-suchte.)

5.5.2 Motivationstheorien

Da die Motivation von Mitarbeitern nur sehr schwer zu analysieren ist, wurdenmehrere Motivationstheorien aufgestellt.

Dynamische Motivationstheorie

Die dynamische Motivationstheorie, die 1943 von Abraham Maslow begründetwurde (Maslow [1943], Abbildung 5.1), geht davon aus, dass die Bedürfnisse desMenschen in Schichten eingeteilt sind. Solange die Bedürfnisse einer niedrigerenSchicht nicht erfüllt sind, macht es keinen Sinn, die Bedürfnisse einer höherenSchicht zu erfüllen (z. B., um ihn oder sie zu motivieren).


1. Physiologisch bedingte Bedürfnisse (Grundbedürfnisse)Hunger, Durst, Schlaf, Sexualtrieb etc.meist erfüllt (ausreichende Bezahlung, gesunder Arbeitsplatz – aber sexuelleBelästigungen am Arbeitsplatz)

2. SicherheitsbedürfnisseBedürfnisse, um langfristig die Bedürfnisse der ersten Schicht zu befriedigenmeist erfüllt (Kündigungsschutz, Weiterbildung, Altersversorgung – aber der-zeit gefährdet⇒ großer „Motivations“druck auf Arbeitnehmer)

3. Soziale Bedürfnisse oder KontaktbedürfnisseBedürfnisse nach Zugehörigkeit, Zusammenhalt, Gruppenintegration, Liebeusw.meist erfüllt (Teamarbeit, Gruppenbildung, Information – aber Mobbing)

4. Ichbezogene BedürfnisseStreben nach Achtung, Prestige, Wertschätzung, Status, (sozialem) Erfolggegenwärtiger Ansatz zur Motivation der Mitarbeiter (Status-Symbole, Be-zahlung, Beförderung)

5. Bedürfnisse nach Selbstverwirklichung (etwas schwammig)Streben nach freier Entfaltung, Erprobung der Fähigkeiten in allen Bereichendes LebensViele streben danach (Einfluss, Macht, Vollmacht) – aber der Weg dorthinführt über „Leichen“

Abbildung 5.1: Maslowsche Bedürfnispyramide

Zwei-Faktoren-Theorie

Die so genannte Zwei-Faktoren-Theorie oder Motivation-Maintenance-Theorievon Frederick Herzberg, Bernard Mausner und Barbara Synderman (Herzberget al. [1959]) resultiert aus der Befragung tausender von Mitarbeitern unterschied-licher Unternehmen.


Dabei wird zwischen Hygienefaktoren (Dissatisfier) und Motivationsfaktoren (Sa-tisfier) unterschieden. Die Erfüllung von Hygienefaktoren wird von den Mitarbei-tern erwartet. Ein Fehlen schafft schlechte Arbeitsbedingungen, Unzufriedenheitetc. Die Erfüllung von Motivationsfaktoren ist dagegen die Ursache für Zufrie-denheit, 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 nurStatistiken, nicht aber Individuen berücksichtigen.

Beispiele

Es gibt Mitarbeiter, denen sind Freizeit und Freiheit wichtiger als Einkommen undStatus.

Es gibt Hungerstreikende, die ignorieren Bedürfnisse der ersten Schicht zur Erfül-lung von Bedürfnissen einer höheren Schicht. Ein Beispiel dafür ist der Hunger-streik, der z. B. von Mahatma Ghandi sehr erfolgreich eingesetzt wurde, um dieenglische Vorherrschaft in Indien zu beenden.

Es gibt Mitarbeiter, die Angst vor eigenen Entscheidungen haben und sich nurunter permanenter Kontrolle wohl fühlen.


5.6 Individualpsychologischer Ansatz

(vgl. Kupper [1993])

Bessere Ergebnisse als die Motivationstheorien versprechen Erkenntnisse der In-dividualpsychologie, die von Alfred Adler 1907 begründet wurde (Adler [1907]).

Als Projektleiter müssen sie kein Diplompsychologe sein, ein wenig Basiswis-sen schadet dagegen nichts. Sie sollten in der Lage sein, sich in die Psyche IhrerMitarbeiter hineinzuversetzen, sie zu verstehen, mit ihnen zu fühlen.

Nahziele und Grundmotivation

Jeder Mensch hat seinen spezifischen Lebensstil. Dieser ist im wesentlichen durchfolgende 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 an-derer Menschen in Konflikt. Es können fünf Nahziele identifiziert werden, unterdenen Fehlverhalten und -handlungen eines Menschen ablaufen. Diese Nahzielelaufen 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 „dieUmwelt“ abzuwälzen.

Beispiel

„Ich konnte das nicht erledigen, weil mein Rechner defekt war.“ Aber der Rechnervon Kollege Meyer war frei und geeignet.


Regelmäßige Krankheit bei wichtigen Terminen (psychische Probleme drückensich in somatischen Problemen aus). „Ich konnte das nicht erledigen, da ich jakrank war.“

Aufmerksamkeit erregen

Der Mitarbeiter will durch seine Handlungen oder sein Verhalten Aufmerksamkeiterregen 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än-dig zu wiedersprechen.

Um derartige Verhaltensweisen zu interpretieren, sollte man sich fragen: „Waspassiert, 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 Aufmerksam-keit gesucht und gefunden⇒ Steigerung der Selbstwertgefühls. „Warum sucht erAufmerksamkeit? 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). DerChef verlangt mehr Sorgfalt, der Mitarbeiter reagiert mit Dienst nach Vorschrift.

Der Machtkampf kann auch in Aufgabenverweigerung gipfeln (wichtige Unterla-gen werden nicht weitergereicht, Daten gelöscht etc.), um zu beweisen, dass manunabkömmlich ist. Dieser Beweis dient wiederum der Hebung des Selbstwertge-fühls („Ohne mich geht es nicht!“).

Rache

Ein Mitarbeiter, der einen Machtkampf verloren hat, greift oft zum Mittel derRache.

Beispiele

Ein Sohn bricht alle Ausbildungen ab, die sein Vater finanziert (da er nicht studie-ren durfte, da er dann gesellschaftlich besser gestellt wäre als sein Vater) und liegtdem Vater mit 35 Jahren noch auf der Tasche.

Ein Mitarbeiter verpatzt eine Demo (z. B. Absturz mit blauem Bildschirm bei derWindows 98-Präsentation), um seinem Chef schwer zu schaden.


Resignation

Wenn auch Rache nichts mehr hilft, resigniert ein Mensch meist. Er arbeitet nichtmehr zum Nutzen des Unternehmens, sondern sitzt nur noch seine Zeit ab.

Beispiele

„Unfähige“ Abteilungsleiter werden auf Posten ohne Aufgabengebiet abgescho-ben, Mitarbeiter werden in der Planung nicht mehr berücksichtigt und/oder erhal-ten überflüssige Aufgaben usw.

5.7 Die Wechselbeziehungen im Verhalten von Chefund Mitarbeiter

fehlt


Kapitel 6

Dokumentation

6.1 Einführung

Es gibt viele Standards zu diesem Thema: IEEE Dokumentationsstandard, DIN66230, 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 unentbehr-lich

– 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 allge-meinverständlich ausdrücken(Microsoft stellt zum Übersetzen der englischen Texte und But-ton/Menu-Bezeichner Germanisten und keine Informatiker ein)

6.2 Welche Arten von Dokumentation sind brauch-bar?

Es gibt wenig Erfahrungsmaterial.

1983 veröffentlichte Guimares eine Untersuchung, bei der Personen, die Softwarezu ändern und zu warten hatten, nach der Nützlichkeit der ihnen übergebenenDokumentation befragt wurden (Guimares [1983]).


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, einProgramm 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 selbstals Kommentare dienen).Beispiel:AnzahlButtonClicks = AnzahlButtonClicks + 1

anstelle vonB = B+1

– Der Zweck jeder Klasse, Methode, Funktion, Prozedur etc. sollte beschriebenwerden.

– Methodenparameter und Attribute sollten beschrieben werden, wenn sienicht selbsterklärend sind (aussagekräftige Namen!).

– Programme sollten lesbar sein:sinnvolle Einrückungen und Leerzeilen; Strukturierung des Quelltextesdurch Unterteilung in Hauptkommentare, unter Kommentare, Anmerkungenetc.

– Inline-Dokumentation am besten unter Zuhilfenahme von automatischenDokumentations-Tools (Javadoc, ASDoc, Eiffel, LATEX, Spezialsoftware –evtl. auch selbst geschrieben) ist einer separaten Dokumentation vorzuzie-hen.Grund: Die Dokumentation kann relativ einfach und sollte auch stets aktuellgehalten werden.

– Am Anfang jeder Datei sollten Verwaltungsinformationen stehen:


• 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 eben-

falls• Hilfestellungen durch andere Internetbenutzer ist einfacher• Umlaute bereiten keine Probleme (gilt auch für Variablen- und Metho-

dennamen)


Literatur

A. Adler [1907]: Studie über Minderwertigkeit von Organen, Ur-ban & und Schwarzenberg, http://www.archive.org/stream/studieberminder00adlegoog, Berlin, Wien

R. Albin [2010]: Der große Prostata-Irrtum – Ein beliebter Tumortest ist in Wahr-heit eine Katastrophe für das Gesundheitssystem, Süddeutsche Zeitung, Sei-te 16, 12. März 2010

A. J. Albrecht [1979]: Measuring application development productivity, Procee-dings 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 Allgemei-ne, Jahrgang 2006, 27. September 2006

H. Balzert [1998]: Lehrbuch der Software-Technik – Software-Management,Software-Qualitätssicherung, Unternehmensmodellierung, Band 2, SpektrumAkademischer 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, Com-munications of the ACM, Jahrgang 41, Seiten 13–17, März 1998

Beta-Verteilung [2006]: Beta-Verteilung, http://glossar.hs-augsburg.de/Beta-Verteilung

S. Biskamp [1998]: Jahr-2000-Tools gezielt eingesetzt, InformationWeek, Jahr-gang 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 COCO-


MO II, Prentice Hall

D. Borchers [2004]: Verursacherbedingt verspätet, c’t Magazin für Computertech-nik, Jahrgang 2004, Nr. 22, Seiten 92–97

D. Bouyssou, D. Vanderpooten [2011]: Bernard Roy – From Graph Theory toMultiple 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 Prosta-ta-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. BrockhausGmbH, Mannheim

Brockhaus [1991b]: Brockhaus-Enzyklopädie – Pes-Rac, Band 17, F.A. Brock-haus GmbH, Mannheim

I. Bronstein, K. Semendjajew [1980]: Taschenbuch der Mathematik, F.A. Brock-haus GmbH, Leipzig

F. Brooks [1986]: No silver bullet - essence and accident in software enginee-ring, Proceedings of the IFIP Tenth World Computing Conference, Seiten1069–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, Über-wachung und Steuerung von Entwicklungsvorhaben, Publicidis MCD, Mün-chen/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, Communicationsof the ACM, Jahrgang 40, Nr. 6, Seiten 53–61, Juni 1997

T. DeMarco [1998]: Der Termin, Carl Hanser Verlag, München


T. DeMarco [2001]: Spielräume, Carl Hanser Verlag, München

T. DeMarco, T. Lister [1985]: Programmer performance and the effects of theworkplace, In: Proceedings of the 8th international conference on Softwa-re engineering, ICSE ’85, Seiten 268–272, Los Alamitos, CA, USA, IEEEComputer Society Press

T. DeMarco, T. Lister [1991]: Wien wartet auf Dich! Der Faktor Mensch imDV-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, Jahrgang2005, 18. Juli 2005

dpa [2006]: Zwei Drittel der Manager machen sinnlose Reisen, Süddeutsche Zei-tung, Jahrgang 2006, Nr. 272, Seiten V2/11, 25./26. November 2006

Dreiecksverteilung [2006]: Dreiecksverteilung, http://glossar.hs-augsburg.de/Dreiecksverteilung

H.-H. Dubben, H.-P. Beck-Bornholdt [2010]: Der Hund der Eier legt – Erkennenvon Fehlinformation durch Querdenken, Rowohlt Taschenbuch Verlag, Rein-beck 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 & SohnVerlagsgesellschagt mbH

Fremdwörterduden [2001]: Duden – Das Fremdwörterbuch, Band 5, Dudenver-lag, 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. Aus-gabe

P. Gartner [1999]: Die Drei-Punkt-Schätzmethode zur Kalkulation des Projekt-aufwands, Projektmanagement, Jahrgang 1999, Nr. 4, Seiten 33–37

W. Gellert, H. Kästner (Hg.) [1979]: Lexikon der Mathematik, VEB Bibliographi-sches Institut Leipzig, Leipzig, 2. Ausgabe


E. M. Goldratt [2002]: Die Kritische Kette – Das neue Konzept im Projektmana-gement, 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 ProcessImprovement, Prentice-Hall International Inc., Englewood Cliffs, New Jersey

F. E. Grubbs [1962]: Attempts to validate certain PERT statistics or ’picking onPERT’, 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, Okto-ber 1983

U. Gulba [2004]: Vabanque – Vermeidung von Risiken in IT-Projekten, iX Ma-gazin für professionelle Informationstechnik, Jahrgang 2004, Nr. 6, Seiten98–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, Wi-ley, New York

M. Hoffmeyer [2006]: Gerangel um das große Ganze, Süddeutsche Zeitung, Jahr-gang 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 mea-surement – IFPUG functional size measurement method, International Orga-nization for Standardization, Genf

I. Jacobson, G. Booch, J. Rumbaugh [1999]: The unified software developmentprocess, 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, Ol-denburg, http://books.google.de/books?id=vfo6Mrurw3IC

I. Jansen, G. Neumann [1997]: Abenteuerlustig ins nächste Jahrtausend, Informa-tionWeek, Jahrgang 3, Seiten 36–38, Juli 1997

M. Kanter, S. Zagata-Meraz [2007]: Hewitt Associates’ research shows impact


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-ACMcomputer conference, IRE-AIEE-ACM ’59 (Eastern), Seiten 160–173, NewYork, NY, USA, ACM

H. Kellner [2001]: Die Kunst, DV-Projekte zum Erfolg zu führen, Carl HanserVerlag, 2. Ausgabe

Klein, Vikas, Zehetner [2005]: Projektmanagement: Mit der Critical-Chain-Methode die Projektlaufzeit entscheidend verkürzen, Der Controlling-Bera-ter, 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 WesleyLongman, Inc., Amsterdam, 2. Ausgabe

H. Kuchling [1976]: Physik, Nachschlagebücher für Grundlagenfächer, VEBFachbuchverlag Leipzig, Leipzig, 13. Ausgabe

H. Kunisch-Holtz [1998]: Die Komplettlösung als Dienstleistung, Information-Week, 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. Aus-gabe

K. Lewin, R. Lippitt, R. White [1993]: Patterns of aggressive behavior inexperimentally created, Journal of Social Psychology, http://books.google.co.uk/books?id=vdvXOxzbiNwC&pg=PA200, Okto-ber 1993

D. G. Malcolm, J. H. Roseboom, C. E. Clark, W. Fazar [1959]: Application ofa technique for research and development program evaluation, OperationsResearch, Jahrgang 7, Seiten 646–670, September/Oktober 1959

manager-magazin [2003]: Stolpe(r)gefahr, manager-magazin.de, 8. Septem-ber 2003

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.


uni-regensburg.de/systemsw/win95/y2k.htm, 08. Juni 1999

R. W. Miller [1963]: Schedule, Cost and Profit Control with PERT – A com-prehensive Guide for Program Management, MacGraw-Hill Book Company,Inc., New York

S. N. Mohanty [1981]: Software cost estimation: Present and future, SoftwarePractice and Experience, Jahrgang 11, Nr. 2, Seiten 103–121

E. A. Nekolla, J. Griebel, G. Brix [2005]: Einführung eines Mammographie-screeningprogramms in Deutschland – Erwägungen zu Nutzen und Risiko,Radiologie, Jahrgang 45, Seiten 245–254

G. Neumann [1999]: Inkompatibel, IT-Anbieter verstehen ihre Kunden nicht, In-formationWeek, Seiten 36–46, Juli 1999

B. News [2011]: Erfolgsfaktor betrieblich Präven-tion, http://www.burda-news.de/content/erfolgsfaktor-betriebliche-praevention, 31. Mai 2011

J. K. Obermaier [1993]: Effiziente Speicherverwaltung für Datenbanksysteme aufParallelrechnern, 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, Gesellschaftzur Förderung Anwendungsorientierter Betriebswirtschaft und Aktiver Lern-methoden 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, Novem-ber 1955

S. Pausch [2011]: Gehaltsverzicht – NBA wittert Verschwörung, Berliner Mor-genpost, 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 Technokratenim 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, Pro-


ceedings of IEEE Wescon, August 1970

J. Rubner [1990]: Wissenschaftler – die Hilfsarbeiter der Industrie, SüddeutscheZeitung, 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üh-ren, delegieren und motivieren (CD-ROM), Schmitt Wirtschaftsberatungsge-sellschaft, 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-Zu-sammenarbeit unterstützt“ – Interview mit Barry Boehm, Projekt Manage-ment 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 MA-NAGEMENT, 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, http://www.projektmagazin.de/glossar/gl-0825.html

Wikipedia [2006a]: No Silver Bullet – Wikipedia, The Free Ency-clopedia, http://en.wikipedia.org/w/index.php?title=No_Silver_Bullet&oldid=75515227, 21. September 2006


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, Diefreie 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 enzyklo-pädie, //de.wikipedia.org/w/index.php?title=Itztalbr%C3%BCcke_(Eisenbahn)&oldid=81634018, 6. Oktober 2011

Wikipedia [2011c]: Program Evaluation and Review Technique — Wi-kipedia, 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


Projektmanagement - Wintersemester 2012/2013

Documents

Transcript of Projektmanagement - Wintersemester 2012/2013