Projektmanagement - Cosmopolitan University

Transcription

Vorlesung
Projektmanagement
Sommersemester 2006
Wolfgang Kowarschick
Fachhochschule Augsburg
Draft (29. Juni 2006)
2
Inhalt
1 Definitionen
1.1
5
Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.1.1
Definition (von W. Kowarschick) . . . . . . . . . . . . .
6
1.1.2
Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Funktionalität und Qualität sowie Strategische Ziele . . . 10
Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.3
1.2
1.3
Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2
Aufgaben des Projektmanagements . . . . . . . . . . . . 14
1.2.3
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 15
Projekterfolg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.1
1.4
Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . 12
Wie vermeidet man einen Misserfolg? . . . . . . . . . . . 21
Vergleich von Projekten mittels Euro-Tagen . . . . . . . . . . . . 26
2 Projektverlauf
2.1
29
Verschiedene Phasenmodelle . . . . . . . . . . . . . . . . . . . . 31
2.1.1
Die Spezifikationsphase: Was soll gemacht werden? . . . 32
2.1.2
Designphase (Entwurfsphase) . . . . . . . . . . . . . . . 37
2.1.3
Fertigungsphase (Entwicklung) . . . . . . . . . . . . . . 45
2.1.4
Einführungsphase . . . . . . . . . . . . . . . . . . . . . . 46
2.1.5
Review . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.1.6
Die Nutzungs- und Aufarbeitungsphase . . . . . . . . . . 47
2.2
Wasserfall- und Spiralmodell . . . . . . . . . . . . . . . . . . . . 49
2.3
V-Modell XT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3
3 Schätzung
3.1
3.2
57
Die Schätzgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.1.1
Divide et Impera . . . . . . . . . . . . . . . . . . . . . . 59
3.1.2
Akzeptierbare Abweichungen . . . . . . . . . . . . . . . 60
Dreipunkt-Schätzung . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.1
Erwartungeswert und Standardabweichung . . . . . . . . 68
3.3
Zentraler Grenzwertsatz der Statistik . . . . . . . . . . . . . . . . 69
3.4
Schätzverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.5
3.4.1
Die Function-Point-Methode . . . . . . . . . . . . . . . . 71
3.4.2
COCOMO . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.4.3
Die Güte von Schätzverfahren . . . . . . . . . . . . . . . 77
Was ist ein Personenmonat? . . . . . . . . . . . . . . . . . . . . 79
4 Planung
85
4.1
Projektpläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2
Grobplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3
4.4
4.5
4.2.1
Tätigkeitensammlung . . . . . . . . . . . . . . . . . . . . 87
4.2.2
Work-Breakdown-Structure . . . . . . . . . . . . . . . . 88
Feinplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.1
Netzpläne . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.3.2
Balkendiagramme . . . . . . . . . . . . . . . . . . . . . 98
Ressourcen-Management . . . . . . . . . . . . . . . . . . . . . . 102
4.4.1
Personalplanung . . . . . . . . . . . . . . . . . . . . . . 102
4.4.2
Bedarfsplanung der Betriebsmittel . . . . . . . . . . . . . 104
4.4.3
Kostenplanung . . . . . . . . . . . . . . . . . . . . . . . 107
4.4.4
Kalender . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Projektkontrolle (Controlling) . . . . . . . . . . . . . . . . . . . 108
4
Kapitel 1
Definitionen
Fremdwörterduden (2001):
Projekt: Plan, Unternehmung, Entwurf, Vorhaben
managen: leiten, zustandebringen, geschickt bewerkstelligen, organisieren
Brockhaus (1991):
Projekt (lat. proiectum „das nach vorn Geworfene“):
geplante oder bereits begonnene Unternehmung, Vorhaben
Projektmanagement:
Gesamtheit der Planungs-, Leitungs- und Kontrollaktivitäten, die bei zeitlich
befristeten Vorhaben (d. h. Projekten) anfallen.
Oyen, Schlegel (1986):
Projekt (Frese 1980):
Projekte umfassen Aufgaben, die durch folgende Merkmale gekennzeichnet
sind:
– zeitliche Befristung
– Komplexität
– relative Neuartigkeit
Management (Rogers 1975, Terry 1961):
Planung, Organisation, Führung, Kontrolle der Aktivitäten im Hinblick auf
eine effiziente (besonders wirtschaftliche, wirksame) und ökonomische (wirtschaftlich sparsame) Zielerreichung (Rogers, 1975).
Management ist ein eindeutig identifizierbarer Prozess, bestehend aus den
Phasen Planung, Organisation, Durchführung, Kontrolle, der über den Einsatz von Mensch zur Formulierung und Erreichung von Zielen führt (Terry,
1961).
Projektmanagement (Schröder 1971):
Projektmanagement ist die verantwortliche Leitung der Planung, Projektierung, Durchführung und Kontrolle öffentlicher wie auch industrieller Vorhaben.
Kellner, Hedwig (1994):
Merkmale eines Projektes:
5
–
–
–
–
es ist ein einmaliges Vorhaben
es ist zeitlich begrenzt
es ist ein komplexes Vorhaben
es macht die Zusammenarbeit von Menschen aus unterschiedlichen
Fachgebieten notwendig
– es sind neuartige und unbekannte Probleme zu lösen
– es steht unter besonderem Risiko
– es hat ein eigenes Budget
– während der Projektarbeit stehen die Mitarbeiter und der Leiter unter
besonderem Druck
Projektmanagement:
alle Tätigkeiten, die das ausführende Arbeiten im Projekt erst ermöglichen
DIN 69901:
Projekt:
Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer
Gesamtheit gekennzeichnet ist, wie z. B.
– Zielvorgabe
– zeitliche, finanzielle oder andere Bedingungen
– Abgrenzung gegenüber anderen Vorhaben
– projektspezifische Organisation
Projektmanagement (PM):
Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für
die Abwicklung eines Projektes.
1.1 Projekte
1.1.1 Definition (von W. Kowarschick)
Ein Projekt (englisch: Project) ist ein zeitlich begenztes, eigenständiges, komplexes Vorhaben mit klaren Vorgaben bezüglich Funktionalität und Qualität und mit
eigenem, meist begrenztem Budget.
Die Realisierung eines Projektes wird von einem Auftraggeber finanziert und einem Auftragnehmer übertragen. Der Auftragnehmer nimmt dazu ein Projektteam
und (anderere) geeignete Ressourcen zuhilfe.
Das Projektergebnis wird nach Projektende von Benutzern eingesetzt. Es kann
überdies Auswirkungen auf weitere Personen haben: die Betroffenen.
Auftraggeber, Auftragnehmer, Projektteam und Benutzer sind die so genannten
Projektbeteiligten. Im weiteren Sinne zählen auch die Betroffenen dazu.
6
– Ein Projekt ist ein einmaliges Vorhaben.
⇒ Neuartige, unbekannte Probleme sind zu lösen.
⇒ Großes Risiko im Vergleich zum Tagesgeschäft.
⇒ Risikomanagement ist die zweitwichtigste Aufgabe des Projektmanagements.
– Ein Projekt ist ein komplexes Vorhaben.
⇒ Verschiedene Techniken, Methoden und Spezialisten müssen eingesetzt
und koordiniert werden.
– 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.
⇒ Der Auftraggeber legt die Dauer fest; der Auftragnehmer akzeptiert
oder lehnt ab.
⇒ Es gibt definierte Start-, Zwischen- und Endtermine; diese werden vom
Auftragnehmer festgelegt; Meilensteine werden mit dem Auftraggeber
abgesprochen.
– Ein Projekt hat ein eigenes, begrenztes Budget.
⇒ Der Auftraggeber trägt die Kosten; der Auftragnehmer akzeptiert oder
lehnt ab.
⇒ Kosten und Nutzen müssen gegeneinander aufgewogen werden.
(die gilt sowohl für Auftraggeber als auch für Auftragnehmer und Benutzer – auch sollte das Projektergebnis nicht auf Kosten Unbeteiligter
gehen).
⇒ „Wer zahlt, schafft an.“ – Falsch!
Die Ziele müssen vorher schriftlich vereinbart werden; Änderungen an
den Zielen müssen ebenfalls schriftlich vereinbart werden. Von Anfang
an sollte bei der Finanzierung ein finanzieller Puffer für spätere Änderungswünsche eingeplant werden.
– Ein Projekt hat einen Auftraggeber und einen Auftragnehmer
⇒ Auftraggeber und Auftragnehmer einigen sich, unter Berücksichtigung der Wünsche der späteren Benutzer, über realistische Projektziele
(Funktionalität, Qualität, Projektdauer und Projektkosten) – Vorgaben
vom Auftraggeber; Vorschläge, Annahme oder Ablehnung durch Auftragnehmer.
7
– Ein Projekt wird von einem Projektteam realisiert.
⇒ Der Auftragnehmer wählt geeignete Mitarbeiter und insbesondere einen
geeigneten Projektleiter. Dieser sollte möglichst früh (in den allerersten
Projektphasen) an Projketdefinitionen beteiligt werden.
⇒ Ein großes Projekt kann in mehrere Teilprojekte mit eigenen Teams
und Teilprojektleitern untergliedert werden. Einen Gesamtprojektleiter
(Projektmanager) gibt es dennoch.
⇒ Mitarbeiterführung ist die wichtigste Aufgabe des Projektmanagements.
– Ein Projekt verbraucht Ressourcen (Material etc.).1
⇒ Der Auftragnehmer wählt geeignetes Material, Lizenzen, etc. um das
Projektziel, d. h. die Realisierung der Funktionalitäten in der geforderten Qualität unter Berücksichtigung der Zeit- und Kostenvorgaben, zu
erreichen.
⇒ Die Ressourcen müssen stets zur rechten Zeit in der richtigen Menge
am richtigen Ort sein.
– Das Projektergebnis wird nach Projektende von Benutzern eingesetzt
⇒ Die Wünsche des Benutzers müssen bei der Projektplanung berücksichtigt werden. Ein Projektergebnis, das nicht akzeptiert wird, ist selten für
den Auftraggeber von großem Nutzen.
⇒ Das Projektergebnis eines erfolgreichen Projektes sollte für alle Beteiligten von Nutzen sein: Auftraggeber, Auftragnehmer und Benutzer und
es sollte Betroffenen nicht schaden.
Zitat aus Informationweek, 7/99 „Inkompatibel, IT-Anbieter verstehen ihre Kunden nicht“, S. 37:
Unterschätzte Anwender: IT-Abteilungen wissen, dass die Zufriedenheit der internen Anwender und der Kunden für die Beurteilung
ihrer Leistung wichtig sind; die Hersteller halten die Meinung der
User für unerheblich.
Auf S. 40 im selben Artikel bewerten 350 Anwender die Benutzerfreundlichkeit der IT-Systeme (Rang 2, Vorjahr Rang 3) und den Feedback der Anwender im eigenen Betrieb (Rang 6, Vorjahr Rang 9) als
sehr wichtige Technikaspekte.
Die Hersteller sind ganz anderer Meinung: Rang 11 und Rang 15.
– Das Projektergebnis hat Auswirkungen auf Betroffene (z. B. Anwohner an
einem neuen Flughafen).
1
Von einem rein funktionalen Standpunkt aus gesehen, ist ein Mitarbeiter auch nur eine Ressource, die vom Projekt verbraucht wird (immerhin geht ein Teil seiner gesamten Lebenszeit
für das Projekt drauf). Gegenüber den Mitarbeitern sollte man zwischen Ressource und Personal allerdings tunlichst unterscheiden.
8
⇒ Die negativen Auswirkungen auf Betroffene müssen so minimal wie
möglich gehalten werden.
⇒ Prozesskosten, Entschädigungszahlungen etc. müssen berücksichtigt
werden.
1.1.2 Ziele
Ein Projekt verfolgt neben den vier vertraglich festgelegten Zielen Funktionalität,
Qualität, Kosten und Zeit normalerweise auch strategische Ziele, wie Verbesserung des Arbeitsablaufs, Steigerung der Mitarbeitermotivation oder der Kundenzufriedenheit. Diese Ziele können allerdings häufig weder präzise definiert werden noch ist es am Ende möglich, definitiv zu entscheiden, in welchem Maße sie
erreicht wurden. Das wesentliche strategische Ziel dürfte jedoch immer sein, dass
das Projektergebnis für alle Beteiligten in irgendeiner Form von Nutzen ist.
Jedes Projekt basiert auf zwei Ecksäulen: Ziele (was?) und Ressourcen (wie?).
Die formalen Ziele legt der Auftraggeber (in Abstimmung mit den Auftragnehmer) fest und die Ressourcen der Auftragnehmer (oft macht der Auftraggeber
allerdings auch bezüglich der Ressourcen Vorgaben). Beide Vertragsparteien verfolgen i. Allg. auch noch strategische Ziele mit einem Projekt.
Ressourcen
strategische
Ziele
strategische
Ziele
Auftragnehmer
Auftraggeber
Funktionalität
Qualität
Zeit
Projektziele
Kosten
Beispiele für Projekte:
– Asterix und Kleopatra: Bau eines Palastes für Cäsar (Goscinny and
Uderzo (1968))
– Ich baue ein Haus
– Falls erfolgreich: Folgeprojekt: Ich ziehe um
– Entwicklung eines elektronischen Aufsatzdienstes für mehrere bayerische Hochschulen
– Erstellung einer Multimediapräsentation für ein Unternehmen
9
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
Projekte basieren i. Allg. nicht auf dem Prinzip Hoffnung:
„Fangen wir mal an und sehen dann, ob was dabei rauskommt.“
(Ausnahme: Grundlagenforschungsprojekte)
⇒ Am Anfang müssen klare und erreichbare Ziele formuliert werden (Analyse,
Spezifikation, Pflichtenheft, evtl. Vorprojekte).
⇒ Am Ende muss entschieden werden können, inwieweit diese Ziele erreicht
wurden, d. h., inwieweit das Projekt erfolgreich war.
Die Ziele sollten einen konkreten Nutzen für den Auftraggeber mit sich bringen
(das gilt selbst für die Grundlagenforschung: das „Menschheitswissen“, das als
Basis fü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 soll
das Ergebnis sein (Qualität). Strategische Ziele werden i. Allg. nicht formuliert.
Asterix und Kleopatra
– Funktionalität: Palast für Cäsar
– Qualität: rechtwinklige Stufen, Steine fallen nicht von der Decke, Türen
klemmen nicht, prunkvoll
– strategische Ziele: Nachweis, dass Ägypter nicht dekadent sind; Gewinn einer Wette
Auftraggeber und Auftragnehmer erwarten sich vom Projektergebnis einen Gewinn oder anderen Nutzen.
Das Projektergebnis sollte die gewünschte Funktionalität (und nur diese!) in der
gewünschten Qualität aufweisen.
⇒ ständige Überwachung des Funktionsumfangs
10
⇒ Qualitätstests
Um wirklich von Nutzen zu sein (d. h. Gewinn abzuwerfen), sollte das Projekt
nicht nur funktionierende, sondern auch qualitativ hochwertige Ergebnisse liefern. Gegenbeispiel Windows-Software: häufig viel Funktionalität in schlechter
Qualität. Gutes Marketing oder Monopol ⇒ trotzdem Gewinn.
Es gilt leider nicht „hohe Qualität ⇒ hoher Gewinn“. Oftmals wird der Gewinn
vergrößert mit der Verminderung der Qualität (z. B. CD-ROM heute meist ohne
Staubschutz, da billiger als mit Staubschutz; VHS war viel schlechter als Video
2000, aber dennoch erfolgreicher – erst SVHS reicht an die Qualität von Video
2000 heran).
Bei der Festlegung der Ziele müssen Auftraggeber und Auftragnehmer die Wünsche der späteren Benutzer berücksichtigen. Ein Produkt, das am Benutzer vorbeientwickelt wurde, wird sicherlich kein Erfolg. Das heißt, von Anfang an sollte
der Benutzer in die Projektplanung mit einbezogen werden!
Zeit
Spezifikation: Zeitplan
Auftraggeber: möchte nur begrenzte Zeit warten
(Asterix: genau 3 Monate)
Zeitplan und zur Verfügung stehende Zeit müssen in Einklang gebracht werden:
⇒ eventuelle Abstriche an Funktionalität/Qualität oder mehr Ressourcen
⇒ höhere Kosten
Reale Zeiten und Zeitplan müssen im Einklang gehalten werden:
⇒ ständige Überwachung des Zeitplanes
Auch geringe Zeitüberschreitungen haben evtl. Katastrophen zur Folge, z. B.,
wenn der Konkurrent schneller war oder wenn ein multimedialer Ausstellungskatalog erst nach der zugehörigen Ausstellung fertiggestellt wird oder wenn der
Projektleiter von Krokodilen gefressen wird.
Kosten
Spezifikation: Kostenschätzung
Auftraggeber: stellt i. Allg. nur begrenzte Mittel zur Verfügung
Kostenschätzung und zur Verfügung stehende Mittel müssen in Einklang gebracht
werden
⇒ ständige Überwachung des Budgets (Budgetüberschreitung hat evtl. Katastrophe wie z. B. Konkurs zur Folge)
11
Anmerkung
Nicht alle Auftraggeber erwarten die vollständige Erfüllung aller Projektziele.
Special-Effects-Firmen (SFX-Firmen), wie die Firmen ILM (Flubber, 4 Monate
Zeit) oder Digital Domain (Titanic, 25 Mio Dollar, Nachverhandlungen 40 Mio
Dollar ⇒ 4 Mio Dollar + 31 Mitarbeiter Verlust), müssen auf Verlangen der Hollywood Filmstudios entweder on time (d. h. im vorgegebenen Zeitraum) oder on
budget (d. h. im Rahmen des vorgegebenen Budgets) arbeiten (am besten natürlich
beides).
1.1.3 Ressourcen
Wesentlicher Projektbestandteil von Anfang an: der Ressourcenplan.
Es muss insbesondere abgeschätzt werden können, ob die Projektziele überhaupt
erreichbar sind.
Funktionalität/Qualität, Zeitplan und Kostenplan müssen mit Ressourcenplan in
Einklang gebracht werden.
Ressource „Mensch“:
Welche und wie viele Spezialisten werden benötigt?
Achtung: Jede Person ist für Ihr Arbeitsgebiet ein „Spezialist“, das gilt beispielsweise auch für einfache Schreibkräfte, Sklaven (Asterix) und „minderqualifizierte“ Mitarbeiter – in einem guten Team erbringt jede Person die maximale Leistung entsprechend ihren Fähigkeiten.
Ein Witz von einem unbekannten Autor bringt das sehr schön zum Ausdruck:
Bei einer Firma werden 5 Kannibalen als Sekretäre angestellt.
Bei der Begrüßung der Kannibalen sagt der Chef:
„Ihr könnt jetzt hier arbeiten, verdient gutes Geld und könnt zum
Essen in unsere Kantine gehen. Also lasst die anderen Mitarbeiter
in Ruhe.“
Die Kannibalen geloben, keine Kollegen zu belästigen.
Nach vier Wochen kommt der Chef wieder und sagt: „Ihr arbeitet
sehr gut. Nur uns fehlt seit gestern eine Putzfrau, wisst Ihr was aus
der geworden ist?“
Die Kannibalen antworten alle mit nein und schwören mit der Sache
nichts zu tun haben. Als der Chef wieder weg ist fragt der Boss
der Kannibalen: „Wer von euch Affen hat die Putzfrau gefressen?“
Meldet sich hinten der letzte ganz kleinlaut: „Ich war es.“
Sagt der Boss: „Du Idiot, wir ernähren uns seit vier Wochen von
Teamleitern, Abteilungsleitern und Projekt-Managern, damit keiner
etwas merkt und du Depp musst die Putzfrau fressen...!!!“
12
Die Mitarbeiterführung ist und bleibt die wesentliche Aufgabe eines jeden
Projektleiters/-managers.
Ressource „Hardware“:
Was für Maschinen, Geräte, Rechner, Steine (Asterix) etc. werden benötigt?
Ressource „Software“:
Was für Programme werden benötigt?
Ressource „Verbrauchsmaterial“
Steht benötigtes Büromaterial bereit? Gibt es eine „Kaffeekasse“ für die Verpflegung von Gästen? (Mitarbeiter verwalten ihre eigene Kaffeekasse). Und
so weiter.
Ressource „Informationen“:
Was für Informationsquellen (Bücher, Internet, Hotline, Archive) werden benötigt?
Ressource „Infrastruktur“:
Was für Räumlichkeiten, welcher Verwaltungsapparat, welche Wartungsverträge, welche Telekommunikationsmöglichkeiten (Videokonferenzing!) etc.
werden benötigt?
Ressource „Rechte“:
Für viele Multimediaobjekte müssen Lizenzgebühren gezahlt, d. h. Verwertungsrechte oder andere Rechte erworben werden.
„Unterauftragnehmer“:
Fremdfirmen, andere Abteilungen, Consultants etc. können als externe „Unterauftragnehmer“ zur Erfüllung der Projektziele beitragen.
Wenn irgendwelche Ressourcen zu den geplanten Kosten oder während des geplanten Zeitraums nicht zur Verfügung stehen, müssen eventuell Abstriche an den
formalen Funktionalität, Qualität, Zeit oder Kosten gemacht werden (an den strategischen Zielen werden i. Allg. keine Abstriche gemacht).
Ressourcenplan und realer Ressourcenverbrauch müssen stets im Einklang gehalten werden.
1.2 Projektmanagement
1.2.1 Definition
Unter Projektmanagement verstehe ich, ein Projekt hinsichtlich der Ecksäulen formale Ziele („Qualität und Funktionalität“, „Kosten“, „ Zeit“) und Ressourcen zu
13
führen, zu planen, zu organisieren und zu kontrollieren.
Zu diesem Zweck werden i. Allg. ein verantwortlicher (Gesamt-)Projektleiter und
eventuell mehrere Teilprojektleiter (d. h. Leiter von Teilprojekten) bestimmt.
1.2.2 Aufgaben des Projektmanagements
Die wichtigste Aufgabe eines Projektleiters ist die Menschenführung. Außerdem
muss er das Projekt planen und organisieren:
– Projektziele sind unter Beteiligung des (zukünftigen) Projektleiters frühzeitig zwischen Auftraggeber und Auftragnehmer abzustimmen und schriftlich
in verbindlicher Form (Vertrag) präzise festzuhalten. Änderung an den Projektzielen müssen ebenfalls stets schriflich in verbindlicher Form festgelegt
werden.
– Der Projektleiter muss die Spezifikation durch genaue Projektpläne (Kostenpläne, Zeitpläne, Ressourcenpläne, Aufgabenaufteilung etc.) absichern!
– Im laufenden Projekt muss die Einhaltung dieser Pläne fortwährend
kontrolliert werden, um frühzeitig Risiken zu erkennen, die zu echten Problemen werden:
• Werden die vereinbarten Funktionen (und nur diese!) von den Entwicklern in der vereinbarten Qualität erstellt (Qualitätstests)?
• Werden die Zeitpläne eingehalten?
Sind Zwischenergebnisse zu den erwarteten Terminen (Meilensteinen)
fertig?
• Werden die Kostenpläne eingehalten?
• Entwickelt sich der Ressourcenverbrauch wie geplant; werden die Ressourcen optimal eingesetzt?
Rechtzeitige Lieferungen der benötigten Hard- und Software, keine
Überschreitungen der gesetzten Limits, wie z. B. Rechenkontingente,
zufriedene Mitarbeiter (sehr wichtig, da unzufriedene Mitarbeiter sehr
teuer sind) etc.
– Nach Abschluss des Projektes weist der Projektleiter im Rahmen einer Projektabnahme nach, dass:
•
•
•
•
das Produkt alle geforderten Funktionen der Spezifikation enthält
das Produkt in der vereinbarten Qualität erstellt wurde
das Budget nicht überschritten wurde
die Termine eingehalten werden
14
Nach der Menschenführung ist die zweitwichtigste Aufgabe des Projektleiters,
Vorkehrungen für rechtzeitige und richtige Reaktionen bei Planabweichungen zu
treffen und bei allen Abweichungen dann auch rechtzeitig und richtig steuernd
einzugreifen (Risikomanagement).
Gäbe es mit Sicherheit keine Abweichungen, bräuchte man keinen Projektleiter,
sondern nur einen Projektplaner.
Der Projektleiter muss über das nötige Wissen, die nötigen Kompetenzen und die
nötigen Menschenkenntnisse verfügen, um angemessene Entscheidungen treffen
zu können.
Der Projektleiter muss allerdings nicht über soviel Fachwissen verfügen, um selbst
aktiv an der Entwicklung mitwirken zu können. Bei den allermeisten Projekten ist
er bereits mit der Projekt-Leitung (d. h. Führung, Organisation, Problemlösungen
etc.) zu mehr als 100% ausgelastet.
Murphys Gesetze
– Alles dauert länger als geplant, kostet mehr als geplant und leistet weniger
als geplant.
Grund:
– meist menschliches Versagen
Deshalb:
– Nach Abschluss des Projektes: „Erfahrung reflektieren“, um dieselben Fehler nicht ein zweites Mal zu machen (Fehleranalyse).
Konfuzius: „Wer einen Fehler macht und nichts daraus lernt, macht einen
zweiten.“
1.2.3 Zusammenfassung
Wesentliche Aufgaben des Projektleiters:
1. Menschenführung
2. Risikomanagement (Murphy lebt)
3. Planung und Kontrolle
1.3 Projekterfolg
Wann ist ein Projekt erfolgreich?
Wenn man Projektleiter fragt: Misserfolge gibt es nicht!
Daher meine Definitionen:
15
Projekterfolg aus neutraler Sicht (juristische Sicht)
Die neutrale Sichtweise kann nur die schriflichen Vereinbarungen zwischen Auftraggeber und -nehmer zur Grundlage haben.
erfolgreich:
Ein Projekt ist erfolgreich, wenn alle vertraglich festgelegten Ziele erfüllt
wurden: Zu den vorgegebenen Terminen und im Rahmen des vorgegebenen
Budgets wird die geforderte Funktionalität in der geforderten Qualität geliefert.
sehr erfolgreich:
Ein erfolgreiches Projekt ist sehr erfolgreich, wenn die Anforderungen (Erwartungen) teilweise übertroffen wurden, d. h., wenn die gewünschten Ergebnisse früher geliefert werden können und/oder wenn die Kosten geringer waren als geplant (kein „Dezemberfieber“) und/oder die geplante Funktionalität
in höherer Qualität realisiert werden konnte und/oder – in Absprache mit den
Auftraggebern – wenn ein erweiterter Funktionsumfang in mindestens der geforderten Qualität realisiert werden konnte.
gescheitert:
Ein Projekt ist gescheitert, wenn ein oder mehrere Produktziele nicht erreicht
wurden.
Vertraglich können auch andere Erfolgsmodelle definiert werden: Zum Beispiel
Hollywood Filmstudios: on time oder on budget. In diesem Fall ist ein Projekt erst
dann gescheitert, wenn es sowohl den Zeit-, als auch den Finanzrahmen überzieht.
Projekterfolg aus Sicht eines Projektbeteiligen (Auftraggeber, -nehmer, Benutzer, Projektleiter . . .)
erfolgreich:
Ein Projekt ist erfolgreich, wenn das Ergebnis für den jeweiligen Projektbeteiligten von Nutzen ist, d. h., wenn z. B. der Nutzen (z. B. späterer Gewinn)
die Kosten wie geplant deutlich übersteigt oder allgemeiner, wenn die strategischen Ziele des Projektbeteiligten erfüllt wurden. Dies gilt selbst dann,
wenn einzelne Projektziele verfehlt worden sind.
sehr erfolgreich:
Ein erfolgreiches Projekt ist sehr erfolgreich, wenn der Nutzen die Erwartungen deutlich übersteigt.
weniger erfolgreich:
Ein Projekt ist weniger erfolgreich, wenn das (evtl. zu spät gelieferte oder zu
teurere oder zu schlechte) Produkt immer noch von Nutzen ist, d. h., wenn
16
die strategischen Ziele nur teilweise, nicht aber im gewünschten Maß erreicht
werden.
gescheitert (erfolglos):
Ein Projekt ist gescheitert, wenn das (evtl. gar nicht vorhandene) Ergebnis
nutzlos für den Projektbeteiligten ist.
katastrophal gescheitert:
Ein Projekt ist katastrophal gescheitert, wenn das Ergebnis den Projektbeteiligten ruiniert.
Projekterfolg aus Sicht der Betroffenen
erfolgreich:
Ein Projekt ist erfolgreich, wenn das Ergebnis den Betroffenen nicht ernstlich
schadet.
Fazit: Wirklicher Projekterfolg (aus nicht-juristischer Sicht)
erfolgreich:
Ein Projekt ist für einen Beteiligten (Auftraggeber, Auftragnehmer, Benutzer)
erfolgreich, wenn das geplante Kosten/Nutzen-Verhältnis erzielt wird (Dieses
Verhältnis muss natürlich kleiner als 1 sein.)
sehr erfolgreich:
Ein Projekt ist für einen Beteiligten sehr erfolgreich, wenn das geplante Kosten/Nutzen-Verhältnis deutlich übertroffen wurde (d. h. deutlich kleiner als
geplant ist).
weniger erfolgreich:
Ein Projekt ist für einen Beteiligten weniger erfolgreich, wenn das echte Kosten/Nutzen-Verhältnis zwar nicht erzielt surde, aber zumindest kleiner als 1
ist.
gescheitert:
Ein Projekt ist für einen Beteiligten gescheitert, wenn das echte Kosten/Nutzen-Verhältnis größer 1 ist, aber keinen Ruin für den Beteiligten bedeutet.
katastrophal gescheitert:
Ein Projekt ist für einen Beteiligten katastrophal gescheitert, wenn es ihn
ruiniert.
Ein (sehr) erfolgreiches Projekt, das Betroffenen einen größeren Schaden zufügt,
ist aus Sicht der Betroffenen gescheitert oder sogar katastrophal gescheidert.
17
Beispiel
Abwasser auf Kosten der Allgemeinheit ungeklärt in Flüsse ablassen.
Wenn Betroffene mit ihren Klagen Erfolg haben, kann sich das Blatt auch für ein
zunächst erfolgreiches Projekt später in das Gegenteil umkehren (Schadensersatzzahlungen etc.).
Wie mann an diesen Definitionen sieht, kann man den wirklichen Projekterfolg
nur dann bestimmen, wenn man Kosten und Nutzen gleichermaßen geplant hat
(vgl. hierzu Teil IV in DeMarco and Lister (2003)).
Häufig sieht die Planung jedoch so aus:
Kosten: 1.237.534,13 Euro
Nutzen: Das müssen wir haben.
Goldratt definiert die strategischen Ziele eines gewinnorientierten Unternehmens
folgendermaßen (Goldratt (2003)):
1. Gewinn machen bzw. steigern (heute und in Zukunft)
2. sicheres und befriedigendes Umfeld für Belegschaft schaffen (heute und in
Zukunft)
3. Markt zufrieden stellen (heute und in Zukunft)
Was heißt „Gewinn steigern“?
1. Nettogewinn steigern
Nettogewinn = Einnahmen − Ausgaben > 0
(unter Berücksichtigung der Inflation)
2. Rendite steigern
Rendite = Gewinn / Investition
3. Cashflow steigern
Cashflow = Menge des verfügbaren („flüssigen“) Geldes für Investitionen etc.
Geldmittel werden dem Cashflow entzogen durch:
– Lagerbestände
– Infrastruktur (Gebäude etc.)
– laufende Projekte
Achtung: ein länger andauernder negativer Cashflow führt i. Allg. zur Insolvenz, auch wenn der Gewinn und Rendite stimmen.
Beispiele
– Titanic (der Film): sehr erfolgreich für den Auftraggeber, trotz Kosten von
200 Mio Dollar (100 Mio geplant) sowie 6 Monate Verzug.
18
Aus Sicht von Digital Domain: weniger erfolgreich, wenn man den Prestigegewinn durch den Film berücksichtigt, oder gescheitert, wenn man die
Verluste berücksichtigt (4 Millionen Dollar + 31 Mitarbeiter Verlust). (Quelle:?)
– Bahnhof Canfranc (Scheytt (1998))
Gebäude: 241m langer „Palast“, 1853 Planungsbeginn, 1882 Bewilligung (6
Jahre Bauzeit, 60000 Pesetas Subvention/km, Steuerfreiheit auf Baumaterialien), 1928 Einweihung (46 Jahre reale Bauzeit), wegen unterschiedlicher
Spurbreiten und fehlender Elektrifizierung auf spanischer Seite: für Auftraggeber ein Flop, d. h. gescheitert! (Allerdings nicht katastrophal gescheitert,
da die beteiligten Staaten Spanien und Frankreich daran nicht Konkurs gegangen sind.)
– Oppenheimer, Robert (22.4.1904 - 18.2.1967; Krebs)
Juli 1943: Direktor der Forschungslaboratorien in Los Alamos (New Mexiko)
Projekt: Bau der ersten Atombombe („Manhattan Project“)
Budget: unbegrenzt; zum Schluss mehr als 2 Milliarden Dollar
Zeit: genau 19 Monate
Team: die besten Physiker Amerikas
Das Projekt wurde erfolgreich abgeschlossen: funktionierendes Ergebnis genau zum angestrebten Termin („Tag X“).
21 und 24 Tage nach Projektende wurde das Ergebnis in Hiroshima und
Nagasaki eingesetzt. Für das amerikanische Militär war das Projektergebnis
ein voller Erfolg; für die Betroffenen – die Bewohner von Hiroshima und
Nagasaki und später für die ganze Menschheit (Wettrüsten) – war das Projekt
katastrophal gescheitert (gerade weil es formal erfolgreich war).
Oppenheimer war kurze Zeit ein Nationalheld. Während des Projektes hat
er allerdings einen Mitarbeiter bei einem Atomunfall verloren (das erste Opfer einer Atombombe). Später widersetzte sich Oppenheimer dem Bau der
Wasserstoffbombe ⇒ Untersuchungsverfahren wegen angeblicher kommunistischer Gesinnung, 1954 Ausschluss von allen Staatsgeheimnissen und
öffentlichen Ämtern, 1963 Rehabilitation
Aussagen von Oppenheimer:
• „Wir entwickeln das Ding nur, für ihren Einsatz tragen andere die Verantwortung.“
• „Manchmal glaube ich, dass wir trotz aller unserer Intelligenz vom
Raubtier abstammen.“
(Quelle: 19. Auflage des Brockhaus, Film „Die Schattenmacher")
19
– Betty Dong, Pharmazeutin an der Universität von Kalifornien in San Franzisko
Untersuchung über Heilungswirkung verschiedener Varianten des synthetischen Hormons Levothyroxin bei Schilddrüsenerkrankungen.
Projektergebnis: alle vier untersuchten Präparate wirken bei den meisten Patienten gleich gut.
Einer der Auftraggeber, die Firma Boots, erklärte die Studie für fehlerhaft
(d. h. als Misserfolg) und verbot die Veröffentlichung. Boots stellte das teuerste und meistverschriebene der vier untersuchten Präparate her.
Gutachter des Journals of the American Medical Association konnten keine
Fehler in der Studie finden. Das Ergebnis wurde erst später, als die Geschichte publik wurde, veröffentlicht. Kosten für Versicherungen und Kranke: 365
Millionen Dollar.
(Quelle: SZ, 13.4.99, Wissenschaftler – die Hilfsarbeiter der Industrie)
Bemerkung
Für das Scheitern eines Projektes aus der Sicht des Auftraggebers ist nicht notwendigerweise der Projektleiter verantwortlich. Wenn dieser zu den gegebenen
Terminen und im Rahmen des vorgegebenen Budgets die geforderte Funktionalität liefert, das Ergebnis aber trotzdem für den Auftraggeber nutzlos ist, lag bereits
ein Planungsfehler vor (z. B. Brücke ohne Straße). Allerdings sollte der Projektleiter schon von Anfang an, d. h. auch während der Planungsphase, verantwortlich
am Projekt beteiligt sein. In diesem Fall wäre er auch mitverantwortlich für das
Scheitern des Projektes.
H.G. Gemünden („Erfolgsfaktoren des Projektmanagements“, 1990)
Trotz dieser schönen Definitionen ist Erfolg schwer zu messen, da es keine normierten Erfolgsmaße und keine einheitliche Sichtweise gibt und auch nicht geben
kann.
Gemünden schlägt eine systematische Differenzierung nach folgenden Gesichtspunkten vor:
Objekt:
Erfolgsbestimmung wird umso schwieriger, je komplexer, innovativer, dynamischer und konflikthaltiger ein Projekt ist.
Eigenschaft:
Man muss technische, wirtschaftliche, soziale Kriterien etc. berücksichtigen
(z. B. auch Auswirkungen auf Mitmenschen oder die Natur).
Maßstab:
Man benötigt konkrete Maßstäbe zum Messen dieser Kriterien.
20
Perspektive:
Der Standpunkt des Beurteilenden (Projektleiter, Auftraggeber, Benutzer,
Gutachter) kann ganz unterschiedliche Ergebnisse liefern.
Phase:
Zu unterschiedlichen Zeitpunkten (während Projektphase bzw. Nutzungsphase) kommen die Beurteilenden zu unterschiedlichen Ergebnissen.
zeitlicher Bezug:
kurzfristiger Misserfolg, aber langfristiger Erfolg oder kurzfristiger Erfolg,
aber langfristiger Flop.
Frage
Ist „Titanic“ für Digital Domain ein erfolgreiches Projekt (Prestigegewinn, Folgeaufträge) oder ein erfolgloses Projekt (4 Mio + 31 Mitarbeiter Verlust) gewesen?
Das wird sich erst im Laufe der Zeit herausstellen!
1.3.1 Wie vermeidet man einen Misserfolg?
Ein erfolgreiches Projekt zu leiten, sollte das Ziel eines jeden Projektleiters sein.
Erfolgreich heißt dabei: erfolgreich aus Sicht des Projektleiters, des Auftragnehmers, des Auftraggebers und des Benutzers und – sofern ein ethisches Verantwortungsbewustsein besteht – aus Sicht der Betroffenen.
Aber auch weniger erfolgreiche oder nur relativ kurzzeitig erfolgreiche Projekte
werden eventuell noch akzeptiert.
Darum: Wie vermeidet man Misserfolge (und erst recht) Katastrophen?
1. Regel
Es gibt kein Patentrezept!
(F. Brooks, 1986: „There is no Silver Bullet“)
2. Regel
Der Projektleiter muss „einfach“ für jedes (managebare) Risiko, das für sein Projekt zum Problem werden kann, rechtzeitig Strategien zur Minderung der Auswirkungen und/oder Strategien zur Reaktion, falls das Risiko zum echten Problem
wird, entwickeln. Falls ein Risiko zum echten Problem wird, muss er rechtzeitig
und richtig reagieren.
Numerobis: „In Ägypten haben wir gegen die Zeit, gegen den Personalmangel
und gegen die Römer zu kämpfen. Vor allem gegen den Architekten Pyradonis,
meinen Konkurrenten.“
Leider lassen sich nicht alle möglichen Probleme vorhersagen oder gar beseitigen.
Man sollte sich die tückischen Fallen aber von vorne herein klar machen, um
21
wenigstens möglichst viele dieser Risiken zu vermeiden oder zumindest deren
Auswirkungen abzumildern.
Für das Management heißt das im Wesentlichen einen fähigen Projektleiter –
wie Numerobis? – einzusetzen und glasklare Projektziele zu formulieren, die sich
nachträglich nur kontrolliert ändern.
Der Projektleiter sollte sich möglichst auf die Erfüllung der Projektziele konzentrieren (können), d. h., dem Begriff „erfolgreich“ sollte die neutrale Sicht zugrunde gelegt werden (auch wenn das nicht immer zu vertreten ist – siehe Oppenheimer).
Typische Risiken aus der Sicht des Projektleiters (Beispiele)
Im Folgenden werden Beispiele für Risiken angegeben, die ein Projekt scheitern
lassen können, wenn sie nicht rechtzeitig bedacht werden.
Abhilfe: frühzeitige und realistische Planungen, rechtzeitiges „Gegensteuern“
– falsche Funktionalität
• Benutzer akzeptieren System nicht
• überzogene Funktionalität
∗ Der Auftraggeber möchte eine „eierlegende Wollmilchsau“
∗ neue Techniken sollen eingesetzt werden, die noch gar nicht das
Stadium der Forschung hinter sich gelassen haben
• nicht-realisierbare Funktionalität
• Inflation der Anforderungen (= ausufernde Änderungswünsche während der Projektlaufzeit)
– Qualitätsprobleme
• überzogene Qualität
• nicht-realisierbare Qualität
z. B.: Ein System mit 100% Ausfallsicherheit soll erstellt werden.
Forderungen wie Ausfallzeit unter 30 Min/Jahr sind dagegen, bei entsprechenden Kosten, schon realisierbar:
99,99 % Ausfallsicherheit =
ˆ max. 53 Min Ausfall/Jahr
99,999 % Ausfallsicherheit =
ˆ max. 5 Min Ausfall/Jahr
• falsche oder fehlende Qualitätssicherung
– kritisches Zeitmanagement
• Mitarbeiter werden krank oder haben Urlaub.
• Mitarbeiter verlassen den Betrieb (Mitarbeiterfluktuation).
• Ein guter Mitarbeiter/Projektleiter arbeitet in normalen Zeiten höchstens 4 Tage a 6 Stunden (= 24 Stunden) pro Woche aktiv für das Projekt
(Asterix: Arbeiter arbeiten zu langsam).
22
• Für jede Aufgabe muss ein Puffer eingeplant werden (wegen Krankheit,
Lieferschwierigkeiten, Systemausfall etc.; Pyradonis behindert Steinnachschub).
• Pausen kosten Zeit (Microsoft-Lösung: Win95-Buttons für bevorzugte
Abfertigung in Kantine).
• Telekommunikation kostet Zeit: Jedes Telefonat, jede E-Mail reißt
einen Wissensarbeiter aus seiner „Denkarbeit“ – es dauert danach jeweils ca. 10 Minuten seine Gedanken danach wieder auf die eigentliche
Arbeit zu konzentrieren (sich zu „vertiefen“).
• Konkurrenz schneller (evtl. mit weniger Funktionalität oder Qualität).
• inhärent falscher Zeitplan („politischer Zeitplan“, „agressive Zeitplanung“)
– kritische Kostenplanung (bei Asterix nicht gegeben, Geld ist reichlich da)
• Spezialisten kosten Geld.
(Es kann billiger sein, einen Profi zu 1000 Euro/Tag zu holen, als einen
Amateur zu 100 Euro/Tag.)
• Geeign98–100etes Material kostet Geld.
• Lizenzen und andere Rechte kosten Geld.
• Repräsentatives Management und andere „produktspezifische“ Aufgaben kosten Geld (Bewirtung von Gästen, Präsentationen etc.).
• Puffer- und Ausfallzeiten kosten Geld.
• Konkurrenz billiger (evtl. mit weniger Funktionalität oder Qualität).
– falsches Ressourcenmanagement
• Unzufriedene Mitarbeiter können jedes Projekt zu Fall bringen
(Mobbing, zuviel Kontrolle, zu wenig Kontrolle etc.)
⇒ Menschenführung (ganz wesentlich)
(Asterix: Arbeiter wollen weniger Peitschenhiebe)
• Kommunikationsprobleme
• zu knappe Ressourcen
(Rechnerzeiten, Kopierkontingente, Raumnot etc., Asterix: zu wenig
Sklaven; Lösung: Zaubertrank)
• unwirtschaftlicher Einsatz von Ressourcen
(Mensch, Material, Infrastrukturen, Information)
• Verfügbarkeit von Ressourcen ist nicht sichergestellt
(Asterix: Steine fehlen ⇒ Problem trotz Zaubertank)
• falsche Ressourcen
(unfähige Mitarbeiter, die für das Tagesgeschäft nicht geeignet und daher verfügbar sind; nicht-erweiterbare Multimediarechner ohne Sound23
•
•
•
•
karten, unausgereifte Entwicklungswerkzeuge etc.)
geringe Produktivität der (falschen oder auch unmotivierten) Mitarbeiter
„Ressourcenklau“ zwischen rivalisierenden Projekten
Auftraggeber oder Lieferant liefert benötigte Ressourcen zu spät
Sabotage
– Spezifikationskollaps
• In der Spezifikation werden zu Projektbeginn, da sich die Beteiligten
Parteien nicht einigen können, keine konkreten Angaben zu Anforderungen gemacht (nur Luftblasen). Wolkige Spezifikation ist möglich,
wolkige Entwicklung nicht ⇒ irgendwann kommt es zum Crash.
– Probleme von außen (schwer abwendbar)
• höhere Gewalt (Konkurs des Auftraggebers, Streik, Umweltkatastrophen)
• Spionage
• Konkurrenz hat mehr „Marktmacht“
– Sonstiges
• Koordinationsprobleme
• Missverständnisse zwischen Auftragnehmer und Auftraggeber
• lückenhafte Verträge
Projekte scheitern meist an Menschen:
– Management
– Projektteam (Projektleiter und Projektmitarbeiter)
– Auftraggeber
– externe Partner
Typische zwischenmenschliche Probleme:
– Manager kümmern sich nicht um Projektinterna, treffen aber Entscheidungen.
– Angst vor Versagen ⇒ zuviel Kontrolle.
– Angst vor Sympathieverlust ⇒ zu wenig Kontrolle.
– nutzlose Meetings aufgrund von Profilierungssucht.
– irreale Kosten-/Zeitschätzungen, weil Auftragnehmer das Projekt unbedingt
oder überhaupt nicht haben will.
24
– Pläne werden über die Köpfe der Betroffenen hinweg erstellt.
– DV-Spezialisten ignorieren Belange von Normalbenutzern („Diese Idioten
verstehen sowieso nichts davon“).
– Mitarbeiter, Partner etc. verstehen sich nicht!
(wahllos zusammengewürfelte Teams)
– Neid („Eigentlich wäre ich an der Reihe gewesen, Projektleiter zu sein“ etc.)
– Mobbing
– Sabotage durch unzufriedene Mitarbeiter, Projektleiter, Konkurrenten (Pyradonis) oder Benutzer
– etc.
Projektrisiken gibt es viele. Am Besten ist es natürlich, alle managebare Risiken
auch zu managen. (Ein Risiko wie z. B. „Ein Asteroid vernichtet einen Großteil
der Menschheit“ ist nicht managebar und kann daher ignoriert werden.)
Es ist aber schon viel gewonnen, wenn wesentliche Kernrisiken berücksichtigt
werden. Kernrisiken zeichnen sich durch hohe Eintrittswahrscheinlichkeit und hohe Kosten aus, wenn sie wirklich eintreten.
Urs Gulba (1995) nennt folgende Top-Risiken in Softwareprojekten:
– Dynamische Anforderungen (= andauernde Veränderung der Anforderungen)
– schlechte Projektplanung und -schätzung
– mangelhafte Kommunikation
– fehlende oder unzureichende Qualitätssicherung
– unreife Softwaretechniken sowie unzulängliche Entwicklungsmethoden und
-werkzeuge
Tom DeMarco und Timothy Lister (DeMarco and Lister (2003)) geben folgende
fünf Kernrisiken an:
– inhärent fehlerhafter Zeitplan
– Inflation der Anforderungen (ausufernde Anforderungen)
– Mitarbeiterfluktuation
– Spezifikationskollaps
– geringe Produktivität
Es fällt auf, das in beiden Quellen jeweils nur ein Problem genannt wird, das die
Arbeitsleistung betrifft. Die anderen Risiken können Sie durch harte Arbeit Ihres
25
Teams und kompetente Erledigung Ihrer Projektleitertätigkeit nach Vertragsabschluss kaum mehr beeinflussen.
Wesentliche Kernprobleme bestehen schon frühzeitig. Das heißt, viele Kernrisiken müssen schon sehr früh berücksichtigt werden, da sie sonst schon früh zu
echten Problemen werden (auch wenn das häufig erst spät, viel zu spät erkannt
wird).
Ein klassisches Beispiel ist der erste Versuch des Toll-Collect-Projektes. Um den
Auftrag zu erhalten, hat das Konsortium eine Projektlaufzeit von weniger als einem Jahr veranschlagt. „Im Vorfeld nach anstehender Bundestagswahlen einigte
man sich auf elf Monate“ (Borchers (2004)). Dass diese Zeitspanne für ein derart
komplexes Projekt viel zu kurz war, dürfte selbst jedem Laien klar sein.
1.4 Vergleich von Projekten mittels Euro-Tagen
Ein billiges Projekt mit langer Laufzeit beindet eventuell mehr Kapital, als ein
teures Projekt mit kurzer Laufzeit. Um den Wert eines Projektes abschätzen zu
können, reicht es daher nicht, den später erwarteten Gewinn zu berücksichtigen.
Man sollte auch den Effekt auf den Cashflow betrachten. Goldratt schlägt vor,
dies mit Hilfe des künstlichen Maßes „Euro-Tage“ zu tun (Goldratt (2002), TOC
(2005)).
Wenn ein Projekt 1000 Euro einen Monat lang bindet, entspricht dies laut Goldratt einer Investition von 1000 Euro · 30 Tage = 30 000 Euro-Tage. Verschiedene
Euro-Tag-Investitionen werden einfach aufaddiert.
Nehmen wir an, unser Projekt hätte eine Laufzeit von 3 Monaten. Jeder Monat
koste uns 1000 Euro, anschließend verdienen wir monatlich 500 Euro mit dem
Projektergebnis. Das heißt, wir investieren 3000 Euro und müssen insgesamt 9
Monate (= 3 Monate Projektlaufzeit + 6 Monate Verdienst am Projektergebnis)
warten, bis wir die Investition wieder „herein“geholt haben. Nach 9 Monaten haben wir also genauso viel Geld zur Verfügung als davor. Erst jetzt verdienen wir
mit dem Projekt Geld.
Wir hatten allerdings neun Monate lang Geld gebunden (dem Cashflow entzogen),
welches wir anderweitig für evtl. bessere Investitionen hätten verwenden können.
Wie groß war nun die Auswirkung auf den Cashflow?
Unsere Investition betrug 3000 Euro, nach 9 Monaten hatten wir das Geld wieder.
Das entspricht einer Investition von 3000 Euro · 9 · 30 Tage = 810 000 Eurotage,
man spricht auch von Investitions-Euro-Tagen.
Diese Rechnung ist allerdings etwas grob, da wir die 3000 Euro ja nicht sofort am
26
ersten Tag investiert hatten und auch nicht 9 Monate lang auf jeden Cent verzichten mussten. Bei genauerer Rechnung ergibt sich folgende Investitionssumme:
1. Monat: 1000 Euro investiert
30 Tage · 1000 Euro = 30 000 Euro-Tage, Summe: 30 000 Euro-Tage
2. Monat: weitere 1000 Euro investiert
3. Monat: weitere 1000 Euro investiert
4. Monat: 500 Euro verdient ⇒ noch 2500 Euro investiert
30 Tage · 0 Euro = 0 Euro-Tage,
Summe: 405 000 Euro-Tage
10. Monat: 500 Euro verdient ⇒ 500 Euro Gewinn
Das heißt, wir verdienen erst nach 10 Monaten Geld, haben dafür aber 9 Monate lnag Investitionsmittel in Höhe von 405 000 Euro-Tagen verzichtet. Wenn wir
das Geld für diese Zeit anders (besser) angelegt hätten, hätten wir evtl. früher
mehr Geld verdient. Das heißt, wir können erst dann von einem echten Reingewinn sprechen, wenn wir mir dem Projekt nicht nur das Geld, sondern auch die
verlorenen Euro-Tage wieder verdient haben.
Die Rechnung der so genannten Durchsatz-Euro-Tage, d. h. der Euro-Tage, die
wir durch das Projekt gewinnen, beginnt ab dem Zeitpunkt, ab dem wir erstmals
einen echten Gewinn einfahren. Bei unserem Projekt ist das der 10. Monat. Die
Durchsatz-Euro-Tage werden geanuso wie die Investitions-Euro-Tage berechnet:
10. Monat: 500 Euro Gewinn
30 Tage · 500 Euro = 15 000 Euro-Tage,
11. Monat: weitere 500 Euro Gewinn
13. Mona:t weitere 500 Euro Gewinn
27
(26 Tage · 3500 Euro = 94 500 Euro-Tage, Summe: 409 000 Euro-Tage)
Das heißt, am Ende des 16. Monats (genauer: 4 Tage zuvor) haben wir so viele Durchsatz-Euro-Tage verdient, wie wir Investitions-Euro-Tage zuvor verloren hatten. Bis dahin haben wir außerdem 3500 Euro mit unserem Projekt verdient. Über den Zeitraum von 7 Monaten entspricht das einer Investitionskraft
von 420 000 Euro-Tagen. Diese Investitionskraft hätten wir auch gehabt, wenn wir
das Projekt gar nicht gestartet hätten und das auch noch früher. (Inflationsbereinigt hätten wir sogar noch ein paar Tage länger warten müssen, bis wir unsere
ursprüngliche Investitionskraft wieder hergestellt hätten).
Welche Bedeutung hat also der 17. Monat für unser Projekt? Das ist der Zeitpunkt,
ab dem wir wirklich neues Geld verdienen, das wir zusätzlich investieren oder
verleben können. Das Magazin TOC Times sagt: „. . . the project Flushes – we
really return the investment in both money and opportunity lost “ TOC (2005).
Allerdings nützen die ganzen schönen Prognosen nichts, wenn die Schätzungen
der Projektdauer, der Kostenverläufe und der erwarteten Gewinne schlecht oder
gar vollkommen unseriös sind.
Andererseits macht einem die Berücksichtigung der Euro-Tage erst klar, welche
Kosten eine große Zeitverzögerung wirklich verursacht. Es wird nicht nur der
Reingewinn geschmälert (wenn sich das neue Handy beispielsweise nur noch ein
halbes Jahr verkaufen lässt und nicht, wie geplant, ein ganzes Jahr, da es zu spät
auf den Markt gekommen ist). Es wird auch die Investitionskraft, d. h. der Cashflow, empfindlich geschmälert.
Fazit
Wenn man die Auswahl zwischen mehreren Projekten hat, sollte man bei der Entscheidung, welche davon realisiert werden sollten, nicht nur die Kosten und den
später erhofften Gewinn, sondern auch die Auswirkungen auf die Investitionskraft, d. h. die Investitions- und die Durchsatz-Euro-Tage berücksichtigen.
28
Kapitel 2
Projektverlauf
„Ein Fußmarsch von 1000 Meilen beginnt mit dem ersten Schritt.“
(chinesisches Sprichwort)
Jede menschliche Tätigkeit lässt sich in Phasen einteilen (aufstehen, waschen,
anziehen, frühstücken, zur Arbeit fahren etc.)
Ebenso lässt sich jedes Projekt in Phasen unterteilen (Spezifikationsphase, Designphase, Fertigungsphase, Einführungsphase)
Prinzipiell ist es möglich, zwei Phasen überlappen zu lassen (Nahrungsaufnahmephase + Informationsphase = frühstücken + Zeitung lesen)
Auch in Projekten könnte man mehrere Phasen einander überlappen lassen. Zum
Beispiel könnte man mit der Einführungsphase (Aufstellen von Hardware beim
Benutzer, Installation von Basissoftware etc.) begonnen werden, bevor die Fertigungsphase vollständig abgeschlossen ist. Im Falle von Terminproblemen wird
man manchmal auch so vorgehen.
Allerdings ist es sicherer, eine Phase vollständig abzuschließen und dann erst mit
der nächsten zu beginnen.
Ein sehr schönes Beispiel lieferte im Sommersemester 2005 der Bau des neuen Schülegebäudes. Die erste Planungsfirma hatte das Handtuch geworfen, eine
zweite Planungsfirma übernahm den Job. Während diese Firma die Anschlüsse
von Steckdosen, Netzwerk etc. plante, wurden bereits die zugehörigen Leerrohre
auf der Baustelle einbetoniert. Den Mitarbeitern des Fachbereichs Informatik, die
an der Planung beteiligt waren, standen veraltete Pläne zur Verfügung, in denen
sich z. B. Türen an anderen Stellen als aktuell geplant befanden. Aber das war
sowieso egal, da ja auf der Baustelle bereits Fakten geschaffen wurden.
Besser ist es i. Allg. jede Phase vollständig abzuschließen, bevor die nächste begonnen wird. Während einer Phase können allerdings verschiedene Aufgaben
(Vorgänge) parallel bearbeitet werden.
Das Ende einer Phase wird auch als Meilenstein bezeichnet. Dabei unterscheidet
man zwischen internen Meilensteinen, die nur innerhalb des Projektteams von Bedeutung sind, und den externen Meilensteinen, bei denen die Teilergebnisse dem
Auftraggeber präsentiert werden und mit ihm das weitere Vorgehen abgestimmt
wird.
29
Projektstart
Meilenstein 1
Meilenstein 2
Projektende
Prinzipielles Vorgehen
Phase n:
– Dauer n
– Budget n
– Funktionalität und Qualität n
– Pläne n
→ Produkt n (Meilenstein am Ende der Phase n)
Review n mit Entscheidung:
– weiter: Phase n + 1 wird gestartet (bzw. Projektende, wenn Phase n + 1
nicht existiert)
– zurück: Phase n (oder sogar frühere Phase) wird wiederholt
– Projektabbruch (da sinnvolle Ziele nicht mehr erreicht werden können)
Bei einem Review können auch Projektziele (Kosten, Zeit, Funktionalität, Qualität) geändert werden. Dies solte jedoch stets schriftlich mit Zustimmung aller
Beteiligten erfolgen (Änderungsmanagement).
Dieses Vorgehen garantiert, dass die Phase n zur Zufriedenheit aller (oder zumindest der Mehrheit) abgeschlossen wird oder dass das Projekt wegen unüberwindbaren Problemen, Unwirtschaftlichkeit oder Ähnlichem vollkommen gestoppt
wird.
Projektdauer = Σ(Dauer n + Dauer Review n)
Projektkosten = Σ(Kosten n + Kosten Review n)
Für die Planung hat die Einleitung in Phasen überdies den Vorteil, dass Dauer
und Kosten genauer abgeschätzt werden können:
geschätzte Projektdauermin =
P
(geschätzte Dauer n inkl. Review · rn,min)
P
′
geschätzte Projektkostenmin = (geschätzte Zeit n inkl. Review · rn,min
)
P
geschätzte Projektdauermax = (geschätzte Dauer n inkl. Review · rn,max )
P
′
geschätzte Projektkostenmax = (geschätzte Zeit n inkl. Review · rn,max
)
30
wobei r∗ und r∗′ Risikofaktoren sind. Aufgabe des Risikomanagements ist es, für
′
′
rn,min und rn,min
sinnvolle Werte kleiner 1 und für rn,max und rn,max
sinnvolle
Werte größer 1 zu schätzen.
Vorteile des Phasenmodells
– Das Projekt dümpelt nicht vor sich hin, da man immer erreichbare Ziele vor
Augen hat.
– Die Zeit, Budget- und Zielplanung kann schrittweise erfolgen. Man stattet
das Projekt zunächst nur mit einem Budget für die ersten ein, zwei Phasen
aus und entscheidet dann, ob man mit dem eigentlichen Projekt starten will.
– Zu jedem Meilenstein/Review-Zeitpunkt wissen alle Beteiligten, wo das
Projekt steht. Allerdings zaubern Projektleiter und -mitarbeiter bei Reviews
oft ganz schön.
– Bei jedem Review kann eine formale Änderung alter Projektziele erfolgen
(Change Management). Schlimmstenfalls kann entschieden werden, mehrere Phasen zu wiederholen (z. B. weil der Hardwarehersteller der Zielplattform Pleite gegangen ist – in derart krassen Fällen sollte allerdings nicht erst
eine Review-Phase abgewartet werden).
2.1 Verschiedene Phasenmodelle
Es gibt kein „einzig richtiges“ Phasenmodell!
Welche Phasen notwendig sind, welche Meilensteine gesetzt werden sollten,
hängt immer vom aktuellen Projekt ab.
Prinzipiell gibt es bei Softwareprojekten fünf große Abschnitte (aber keine normierten Begriffe dafür):
1. Spezifikationsphase (Projektziele: Was soll erreicht werden?)
2. Designphase (Wie werden die Projektziele erreicht?)
3. Fertigungsphase (Realisierung der Projektziele)
4. Einführungsphase (Übergabe der Projektergebnisse an den Auftraggeber/die
Benutzer)
5. Aufarbeitungsphase (+ Nutzungsphase)
Nach Abschluss der Einführungsphase ist das Projekt eigentlich abgeschlossen.
Allerdings sollte man die Erfahrungen, Erfolge und Fehler in einer abschließenden
Aufarbeitungsphase reflektieren, um daraus für ein nächstes Projekt zu lernen.
31
Die Nutzungsphase ist nicht mehr Bestandteil des Projektes. In dieser Phase anfallende Arbeiten, wie z. B. Wartungstätigkeiten, gehören zum Tagesgeschäft (obwohl viele Projektarbeiten leider oft in die Wartung verlegt werden, um den Termin formal einhalten zu können).
Ein erfolgreiches Projekt kann ein oder mehrere Folgeprojekte initiieren. Das
heißt, in die Nutzungsphase (eventuell sogar schon in frühere Projektphasen) können die Planungsphasen der Nachfolgeprojekte fallen.
Diese fünf Grobphasen können je nach Projekt unterschiedlich umfangreich und
in unterschiedliche Teilphasen gegliedert sein.
2.1.1 Die Spezifikationsphase: Was soll gemacht werden?
Ziel dieser Phase ist es festzulegen, was gemacht werden soll. Zunächst startet ein
Projekt meist ohne konkrete Vorstellungen, ohne Projektleiter und Projektmanagement.
Typische Phasen während der Spezifikationsphase:
Initialisierungsphase, Planungsphase, Bedarfsermittlung, Vorstudie
Zunächst muss die Projektidee geboren werden. Das kann ganz spontan im Schlaf
passieren, oder man sucht gezielt nach neuen Projektideen mit Hilfe einer Vorstudie oder Bedarfsermittlung (Brainstorming etc.).
Am Anfang ist die Idee!
Orientierung (Informationsphase)
– Welche Bedürfnisse bestehen (z. B. Benutzerbefragungen)?
– Welche Probleme oder Engpässe bestehen (Problemanalyse)?
– Wo ist eine Marktnische (Übersichtsanalyse)?
Untersuchung
→ Gibt es Lösungsmöglichkeiten für die erkannten Probleme?
– Ist zumindest eine Lösung realisierbar (Konzeptanalyse)?
– Nutzt die Lösung dem Auftraggeber (grobe Kosten-/Nutzenschätzung)?
– Ist eine Lösung der Probleme wirtschaftlich notwendig?
Eine Bedarfsermittlung wird normalerweise vom Auftraggeber alleine durchgeführt, eine Vorstudie wird dagegen oft als Auftragsarbeit an eine andere Firma
32
(z. B. Beraterfirma) vergeben. Es ist von Vorteil, wenn der zukünftige Projektleiter
in dieser Phase schon aktiv beteiligt ist.
Eventuell wird während einer Bedarfsermittlung auch schon ein Rahmenkonzept
erstellt (z. B. Orientierung an unternehmensweitem Datenmodell, Zusammenstellung potentieller Anwendungen). Es ist sogar möglich, schon Rahmenpläne zu
erstellen (Teilprojekte mit Zielen, einzusetzende Ressourcen etc.).
Vorstudien sind eigentlich selbst wieder Projekte mit dem Ziel, die Machbarkeit
eines größeren Projektes zu analysieren und ein Rahmenkonzept sowie
Rahmenpläne zu erstellen. Während der „Designphase“ kann eine so genannte
Systemanalyse durchgeführt werden, während der „Fertigungsphase“ werden ein
oder mehrere Konzepte erstellt, und während der „Einführungsphase“ wird ein
Konzept ausgewählt und eine Entscheidung für das eigentliche Projekt getroffen.
Review
Genehmigung einer Anforderungsliste, von Ausschreibungsunterlagen, eines Lastenheftes (= grobes Pflichtenheft), eines Rahmenkonzeptes und von Rahmenplänen oder Ähnlichen sowie Beschluss, die nächste Phase zu beginnen.
Akquisitionsphase
Diese Phase erfolgt, sobald sie wissen dass Sie ein Projekt durchführen wollen,
Ihnen aber die Mittel dafür fehlen (vor allem, wenn Sie nicht selbst der Auftraggeber sind). Die Phase kann sich direkt an die Informationsphase anschließen oder
auch erst nach Verabschiedung irgendeiner Grobspezifikation erfolgen.
Wenn Sie zuwenig Geld haben, müssen Sie Projektpartner und/oder Geldgeber
finden.
Typische Projektpartner: andere Abteilungen, externe Unternehmen anderer Branchen, europäische Unternehmen derselben Branche etc.
Typische Geldgeber: der Aufsichtsrat, der Abteilungsleiter, ein anderes Unternehmen (wenn Sie z. B. einer Technologietransferstelle angehören), der bayerische
Staat (Existenzgründerdarlehen etc.), die EU (Esprit etc.).
Probleme
Die Akquisitionsphase kann sehr lange dauern (manchmal ein Jahr und mehr,
Canfranc: 30 Jahre).
Die ursprünglichen Projektziele können dabei völlig über den Haufen geworfen
werden.
Die zugeteilten Geld- und Zeitmittel können oft rein politischer Natur sein („Hier
haben Sie eine Million, lösen Sie das Problem in 15 Monaten!“).
33
Als potentieller Projektleiter sollten Sie von Anfang an bei der Akquise beteiligt
sein. Es gibt nichts Schlimmeres, als zum Projektleiter eines undurchführbaren
Projektes ernannt zu werden (völlig überzogene Ziele bezüglich Funktionalität,
Qualität, Zeit und/oder Kosten).
Während der Akquisitionsphase werden oftmals mehr oder weniger detaillierte
Pläne ausgearbeitet (Phasenpläne mit Meilensteinen, Kostenpläne, Ressourcenpläne etc.). Doch Vorsicht! Die Pläne der Akquisitionsphase sind oft politischer
Natur. Es gibt Projekte, bei denen heißt es am Ende der Akquisitionsphase: „Jetzt
haben wir die Fördergelder. Was machen wir damit?“
Review
Genehmigung der Finanzierung. Jetzt kann oft schon mit gutem Gewissen ein
Projektvertrag zwischen Auftragsnehmer und -geber geschlossen werden (wenn
bereits „belastbare“ Rahmenkonzepte, ein Lastenheft o. Ä. vorliegen).
Definitionphase (Konzeptphase)
Spätestens in dieser Phase muss ein verantwortlicher Projektleiter bestimmt werden.
In den ersten Teilphasen der Spezifikationsphase werden normalerweise nur grobe
Zielvorstellungen formuliert (Lastenheft). Spätestens wenn klar ist, dass ein Projekt gestartet werden soll, müssen die Ziele genau definiert und verbindlich festgelegt werden. Ein Pflichtenheft oder eine Spezifikation muss geschrieben werden.
Diese muss genau spezifizieren, was zu tun ist, welche Normen einzuhalten sind,
wer für was verantwortlich ist (auch der Auftraggeber hat Pflichten!), wie Probleme kommuniziert werden etc.
Zunächst sollten Funktionalität und Qualität festgelegt werden. Dabei müssen
„messbare“ Erfolgskriterien festgelegt werden.
Beispiel „Aufsatzdienst Elektra“
Der Aufsatzdienst Elektra soll druckbare Aufsätze in einer Qualität besser als Fax
per Internet ausliefern.
Die Bearbeitung einer Bestellung durch eine Fachkraft dauert am Rechner nicht
mehr als 20 Sek/Seite.
Und so weiter.
Beispiel „Internetpräsentation für die FH Augsburg“
– läuft auf allen Browsern
– insbesondere kann jede Seite mit jedem HTML-2.0-konformen Browser betrachtet werden (auch Lynx, andere ASCII-Browser, Braille-Zeilen etc.)
34
– Barrierefreiheit
– läuft auch ohne JavaScript (wird wegen Sicherheitsproblemen oft sogar via
Proxy herausgefiltert)
– und so weiter
Auch strategische Ziele können formuliert werden. Die Erfüllung derartiger Ziele kann allerdings meist nicht nachgewiesen werden – dann muss man auf die
Aufnahme in das Pflichtenheft verzichten.
Anschließend sollten Kosten und Zeit geschätzt und die anderen Ziele eventuell
angepasst werden.
Bei größeren Projekten werden teilweise Kosten- und Zeitpläne nur für die nächsten Schritte genauer spezifiziert und für spätere Schritte dagegen zunächst nur
grob festgelegt (höhere Fehlertoleranz).
Achtung
Im Pflichtenheft sollte nicht stehen, wie etwas zu realisieren ist. (Grobe) Vorgaben bezüglich der Ressourcen können allerdings über die Ziele gemacht werden
(z. B.: Software muss mit vorhandener Software kompatibel sein – Das ist Bestandteil der Funktionalität. Das Projekt hat 3 Mitarbeiter – Das ist Bestandteil
der Kostenvorgabe: Es wird Geld für 3 Mitarbeiter und 2 Rechner zur Verfügung
gestellt. Das heißt aber nicht, dass nicht 6 Halbtagskräfte eingestellt werden dürften. Und so weiter.)
Der Auftragnehmer sollte über die Ressourcenplanung selbstständig entscheiden
können. Bei Inhouse-Ressourcen kommt es dabei allerdings häufig zu Problemen,
wenn die Ressourcen auch von anderen Projekten oder Gruppen benötigt werden
(z. B. Netzspezialisten, Hardware etc.).
Review
Genehmigung des Pflichtenheftes und Beschluss, die Designphase zu starten. Spätestens jetzt sollte ein Projektvertrag zwischen Auftraggeber und -nehmer geschlossen werden.
Die Spezifikationphase kann sich in mehrere Teilphasen untergliedern. Dabei
kann es, muss es aber nicht zu Zwischenreviews kommen.
Die Definitionsphase sollte allerdings immer mit einem Review beendet werden.
Dort werden sich Auftraggeber und Auftragnehmer spätestens einig, ob das Projekt gestartet wird und was dabei genau herauskommen soll.
Spätestens jetzt liegt ein offizieller Starttermin für das Projekt fest.
35
Vorbereitungsphase
Nun ist der Projektleiter spätestens gefordert, detaillierte Pläne zu erstellen sowie sich nach geeigneten Mitarbeitern und anderen Ressourcen umzuschauen: Er
weiß jetzt genau, was zu tun ist.
Im Allgemeinen sollten die Pläne – zumindest in groben Zügen – bereits vorliegen. Auch ist oft schon ein Teil der zukünftigen Mitarbeiter bekannt und ein Teil
der benötigten Ressourcen vorhanden.
An der Feinarbeit kommt der Projektleiter allerdings nicht vorbei. Und zwar schon
bevor die Designphase beginnt.
Bei der Erstellung von Plänen kann Ihnen ein PM-Tool von Nutzen sein.
Die Arbeit abnehmen kann Ihnen ein derartiges Werkzeug allerdings nicht,
denken müssen Sie!
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. Es
gibt es oft keine dedizierte Feinplanungsphase – daher spreche ich auch von Vorbereitungsphase. Die Grobplanung kann schon im Rahmen der früheren Teilphasen erfolgt und genehmigt worden sein. Oder die Feinplanung liegt vollkommen
in der Verantwortung des Projektleiters und bedarf deshalb überhaupt keines formalen Reviews, sondern nur eines internen Reviews durch den Projektleiter. Falls
er dabei jedoch gravierende Zielkonflikte entdeckt, muss er vor Beginn der Designphase den Auftraggeber informieren, um eventuell die Ziele neu zu definieren
oder das Projekt abzubrechen.
Review
Eine Vorbereitungsphase zwischen Zielformulierung und echtem Projektstart (Beginn der Designphase) gibt es dennoch fast immer. Diese Phase bedarf – da sie
sich meist nur mit Planung und Ressourcenbeschaffung befasst – nicht unbedingt
36
eines formalen Reviews, da es den Auftraggeber meist nicht interessiert, mit welche Ressourcen das Projekt durchgeführt wird. Auch hier gilt aber, dass zumindest der Projektleiter oder ein Projektverantwortlicher (der nicht notwendigerweise auch der Projektleiter sein muss, sondern auch eine ranghöhere Person des
Auftraggebers sein kann) am Ende der Vorbereitungsphase Bilanz ziehen muss:
Kann das Projekt starten oder nicht? Wenn nein, wird wiederum der Auftraggeber
informiert.
Fazit: Meist handelt es sich beim Vorbereitunsphasen-Review um ein projektinternes Review.
2.1.2 Designphase (Entwurfsphase)
Spätestens jetzt startet das Projekt offiziell. Es sollte einen griffigen Namen und
am besten ein griffiges Logo haben.
Die Designphase ist die wesentlichste Phase, da sie das Fundament für das spätere
Produkt legt. Gravierende Fehler aus der Designphase können später kaum noch
ausgebügelt werden, außer wenn das Projekt im Sinne des Spiralmodells (siehe
Abschnitt 2.2) realisiert wird.
Wesentlich Ziel der Designphase: Festzulegen wie das Pflichtenheft realisiert
wird? (Dort steht nur was realisiert werden soll.)
Typische Aufgaben in der Designphase
– Entwicklung von Datenmodellen, Schnittstellendefinitionen, Ablaufplänen
etc.
– Entwicklung von Storyboards
– (grobes) Mediendesign (Screendesign, Audiodesign etc. )
– Erstellung von Funktionsmodellen, Simulation etc.
– rapid Prototyping (evtl. schon in Vorstudie)
– Tests: Auswahl von geeigneter Zielhardware, -software, Programmiersprachen, Datenbanksysteme etc.
– Beginn der Dokumentation!!!!
(Das Pflichtenheft ist Bestandteil der Dokumentation)
– Verfahren für
• Wartung, Versionspflege
• Backup und Recovery
• Qualitätssicherung und Tests
37
Datenschutz, Datensicherheit
Urheberrechte, Lizenzvereinbarungen
Installation in Zielumgebung
Umstellung von bisherigem Verfahren auf neues
(Bayerische Vereinsbank: Multimediaschulung für Windows NT)
• Schulung
•
•
•
•
Der Projektleiter muss entscheiden, welche Designmethoden und Designwerkzeuge eingesetzt werden (z. B. objektorientierte Modellierung gemäß UML), wer
welche Designaufgaben übernimmt, bis wann das Design steht etc.
Außerdem muss er mit der Soll-Ist-Überwachung beginnen: Wie weit weicht das
Projekt vom Plan ab? Gegebenfalls muss er gegensteuern. Darüberhinaus muss er
die Schätzungen für die Folgephasen verfeinern.
Hausbau ohne zentimetergenaue Baupläne: undenkbar!
Softwareentwicklung ohne Datenmodell und Design: der Regelfall!
(siehe S. 98 Kellner (1994)).
Wunschziel: Das Design beschreibt das Produkt so konkret, dass es nur noch kodiert werden muss. (Alternative: Spiralmodell; siehe Abschnitt 2.2)
Probleme
– Man kann keine „Lines of Code“ vorweisen.
– Die Projektdauer wird in Augen des Auftraggebers „künstlich“ verlängert.
– Der Auftraggeber will Ergebnisse sehen.
– Es blinkt und blitzt nichts.
– „Denken ist keine Arbeit.“
– Der „Hacker“ unter den Entwicklern will endlich richtig programmieren. Er
weiß eh, wie’s geht.
– Schlechte Projektleitung.
– Mangelhafte Kompetenz/Kreativität der Beteiligten.
– Sich an ein Design zu halten.
– Zeit drängt ⇒ „lieber anfangen“
Bei vielen Firmen ist Hacking verboten (wird trotzdem gemacht).
Grund: Firmen machen sich sonst von Hackern abhängig.
Unwartbarer Code kann nur weggeworfen und neu geschrieben werden.
Design wir oft nicht ernst genommen. Es gehört halt zu einem Projekt dazu (Kellner: Höflichkeitsakt). Man hält sich aber nicht das Design, sondern fügt es der
38
Projektdokumentation bei. Kellner: „Da ist alles sauber abgeheftet und stört nicht
bei der Arbeit.“
Designfehler sind verdammt teuer.
Beispiel: Y2K-Problem (Year-2000 problem)
Zweistellige Darstellung: 99 + 1 = 00 ⇒ 1999 + 1 = 1900
Hauptproblem: Finden von Problemcode in vielen Millionen Zeilen von Code
(LOC).
Hilfsprogramme: 90 000 DM pro 100 000 LOC
Erfolgsgarantie < 100 %
⇒ oftmals werden 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 30
Jahren wesentlich, da Speicher knapp war. Deshalb war das Y2K-Problem unvermeidbar.“ zieht nicht. In zwei Byte passen mehr als 65000 Jahre. Selbst in einem
Byte bringt man 256 Jahre unter. Das heißt: Zwei Byte für 100 Jahre bedeutet
Speicherplatzverschnitt.
Fazit: Es handelt sich ausschließlich um ein schlechtes Design, weil diese Art der
Datumsdarstellung allgemein üblich war und ist.
Weitere Datums-Probleme:
Unix: 1. 1. 1970 + 231 sec = 18. 1. 2038
DOS: 1980 − 2108 (Garantie bis 2035 – Danach ist laut Redmont DOS tot)
Windows95 (ohne Patch): – 2000 (2003 = C3)
Windows95 (mit Patch): Garantie bis 2036
weitere 4-Byte-Speicherplatz-Datums-Normen: ISO, Europa etc.
Problemlösung: 8 Byte =
ˆ 1018 sec = 3 · 1011 Jahre
Wenn die Menschheit nicht länger als die Dinosaurier leben (200 Mio Jahre) reichen 7 Byte :-)
Anmerkung
Es gibt viele verwandte Probleme wie z. B. das 49,7-Tage-Problem (4-Byte-Zähler
für millisekundengenaue Timer beginnen nach 4 294 967 296 Millisekunden =
49,7 Tagen wieder bei Null), Dow-Jones-Index > 10 000, GPS-Datum zählt nur
1024 Tage, fängt dann wieder bei Null an etc.
39
Beispiel Kuka Roboter GmbH: Roboter fielen alle 49,7 Tage für mehrere Stunden
aus. Der Fehler wurde allerdings meist erst nach 99,4 Tagen entdeckt, da Roboter
normalerweise immer Samstags installiert werden, um den Arbeitsablauf nicht zu
behindern (⇒ 49,7 Tage später ist ein Sonntag).
Geschätzte Kosten der Designfehler für das Y2K-Problem
(Quelle: CACM, Vol. 41, March 1998)
USA: 8.465.060 Personenmonate, $70.753.562.795 Kosten für Y2K-spezifische
Softwareprobleme
Weitere $125 Milliarden um Datenbanken und Data Warehouses zu reparieren.
Weitere Schätzungen
(Quelle: Information Week, 3/97, Abenteuerlustig ins nächste Jahrtausend,
S.36–38)
Juli 1997, Anpassung von DV an Y2K-Problem in deutschen Unternehmen:
4 % Planungsphase
13 % mit Korrekturen begonnen
21 % sehen keine Probleme
28 % sind unentschlossen
34 % noch keine Aktion geplant
Viele Unternehmen und Behörden behandelten das Y2K-Problem lange Zeit als
Randproblem, das sich irgendwie von selbst lösen sollte. Eine Mehrheit der Unternehmen hatte kein Budget für die Umstellung eingeplant.
Rund 30% alle Computersysteme waren nicht Jahr-2000-kompatibel.
Giga Information Group: Viele Firmen werden das Jahr 2001 nicht mehr erleben.
(So schlimm ist es dann doch nicht gekommen).
Kosten
(Quelle: Information Week, 1-2/98)
Spezialisten 1000 DM/Tag (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 (zu billig)
Kosten: $1 pro Programmcodezeile (LOC), $600 Milliarden weltweit,
IT-Abteilungen werden ca. 15 % mehr Personal benötigen
40
Hohe Reenineering-Kosten ⇒ IT-Ersatzinvestitionen werden in den kommenden
Jahren reduziert.
Erfahrungsgemäß werden nur 14 % aller größeren Entwicklungsvorhaben fristgerecht fertiggestellt.
Beispiel ARAG
(Quelle: Information Week, 1–2/98, S.30–33)
1989 provisorische Umstellung (da 10-Jahres-Policen für 1990 nicht mehr erfasst
werden konnten).
Seit 1996 Analyse einer dauerhaften Umstellung.
Abschluss des Projektes: 2005 – bis dahin kann man mit den Provisorien von 1989
leben.
„Externer“ Betreuer der Umstellung: Alldata, IT-Tochter der ARAG
Lösung, um 3800 Datenbanken nicht auch noch neu aufbauen zu müssen:
– Vierstellige Jahreszahlen werden in zweistellige Felder gepackt.
– Saubere Lösungen werden später angestrebt.
Die Alldata benötigt etwa 20 PJ um 4,6 Millionen Zeilen Code zu prüfen. Kosten:
5,6 Millionen Mark =
ˆ 1,20 DM/LOC. Diese Umstellungskosten sind sehr günstig,
da neuere Schätzungen von $1,50/LOC = 2,70 DM/LOC ausgehen.
Grund: Nur 250 000 Zeilen „Problemcode“. Der Rest konnte automatisch umgestellt werden.
Projektleiter: „Je älter ein Programm, desto spannender wird’s.“
Die Alldata gibt keine vertragliche Garantie auf 100 % richtige Umstellung. Die
Tests geschehen nicht in Simulationen, sondern in der Praxis.
BHF-Bank
(Quelle: Information Week, 1-2/98 S. 30 – 31, 34 – 35)
Umstellung von 6000 individuell entwickelte Anwendungen
(obige Kostenschätzung: 6000 · 20 h = 80 PJ)
Umstellung durch verschiedene Dienstleiter + eigene Mannschaft
Probleme: Suche nach Datumsfeldern in 10 Millionen LOC
Abnahmetests bei Projektende
Filetransfer von und zu Partnerunternehmen (Schnittstellendefinitionen)
41
Kosten:
ca. 15 Millionen Mark (grobe Schätzung; exaktes Volumen ist unbekannt; die Bank muss auf jedem Fall zahlen)
Projektleiter Moses: „Wenn wir als Bank zwei Tage nicht am elektronischen Zahlungsverkehr hängen, dann sind wir aus dem Geschäft.“
Notfallpläne: zusätzliche Mitarbeiter werden von anderen Projekten abgezogen
Vorbeugung gegen Notfälle: Cleanmanagement
Das heißt, dass ein Programm, das den Jahr-2000-Abnahme-Test bestanden hat,
bis zum Ende des Tests nicht mehr verändert werden darf (Ausnahme: neue
Jahr-2000-Probleme).
⇒ In Einzelfällen können andere Bugs monatelang nicht behoben werden.
Phase I (1996):
Strategie und Bestandserfassung
Phase II (1996/97): Detail-Analyse und Planung
Phase III (1997/98): Implementierung
Phase IV (1998/99): Gesamtintegrationstests
Beispiel für Designentscheidungen
Sortierverfahren: Welches ist für mein Problem geeignet?
Bubblesort:
Führe Folgendes solange durch, bis alle Nachbarn in der richtigen Reihenfolge stehen:
Gehe die ganze Objektliste durch:
Wenn zwei Nachbarn in der falschen Reihenfolge stehen, vertausche sie.
Beobachtung
– Dieser Algorithmus hängt von keiner Computersprache ab.
⇒ Die zu verwendende Sprache kann (relativ) unabhängig von den zu verwendenden Algorithmen gewählt werden.
– Der Algorithmus legt sich noch nicht auf eine Datenstruktur fest (Array,
verkettete Liste, Director-Propertylist, sortierter Baum, SQL-Tabelle).
– Der Algorithmus legt sich noch nicht auf einen Elementtyp fest (Integer,
String, Record etc.).
– Der Algorithmus legt sich noch nicht auf einen Vergleichsoperator fest (Integervergleich, Stringvergleich etc.)
42
– Der Algorithmus hat eine mathematisch bestimmbare Komplexität, abhängig von der Anzahl n der zu sortierenden Elemente:
best case: n − 1 Vergleiche, Worst Case: n · (n − 1) Vergleiche,
im Mittel O(n2 ) Vergleiche.
Es gibt noch viele weitere Sortierverfahren:
Quicksort
Hauptspeicherverfahren, Mittel O(n · log n), worst case O(n2 ) (oft bei bereits
sortierten Mengen)
Mergesort
auch für Datenmengen, die nicht in den Hauptspeicher passen geeignet, Mittel + worst case O(n · log n)
parallele Sortierverfahren
noch Forschungsgegenstand theoretisches Optimum O(log n) – noch kein Algorithmus bekannt; O(log 2 n) theoretische machbar, aber nur bei aberwitzig
vielen Prozessoren; Algorithmus O(n) für n 5 ein paar Milliarden (= alle
praktischen Fälle) mit konstanter Anzahl Prozessoren ist bekannt.
Quicksort ist im Mittel um einen konstanten Faktor schneller als Mergesort, kann
diese Geschwindigkeit aber nicht garantieren. Bubblesort ist für sehr kleine Datenmengen (< 100 Elemente) das schnellste Verfahren. Quicksort und Bubblesort
sortieren „in place“, d. h. ohne Zusatzspeicher.
Im Laufe der Designphase muss eine Entscheidung getroffen werden, welches
Verfahren verwendet wird.
Einflussfaktoren: Anzahl der zu sortierenden Elemente, verfügbare Datenstrukturen, verfügbare Software (Wiederverwendung), garantierte Antwortzeiten etc.
Beispiel: 1 000 000 Elemente zu sortieren, 1 000 000 Vergleiche pro sec.
O(n2 ): 1012 Vergleiche ⇒ 106 Sekunden · const1 = 11, 6 Tage · const1
O(n · log n): 106 · 20 Vergleiche ⇒ 20 Sekunden · const2
O(n): 106 Vergleiche pro CPU ⇒ 1 Sekunde · const3
O(log2 n): 40 Vergleiche pro CPU ⇒ 40 Mikrosekunden · const4
Quicksort kann wegen Worst-case-Komplexität keine Antwortzeiten garantieren,
Mergesort schon!
Aufgrund solcher and ähnlicher Probleme müssen Entscheidungen vor dem Programmieren getroffen werden. Während der Entwicklung wird oft nur mit geringen Datenmengen gearbeitet – da funktioniert auch der Bubblesort – die böse
Überraschung kommt dann im Realbetrieb.
43
Rucksack-Programmierung
Ohne sauberes Design kommt es während der Entwicklung und noch mehr während des laufenden Betriebs im Rahmen der Wartung zur so genannten Rucksack-Programmierung: Wenn ein im Design übersehener Sonderfall zu Problemen führt, wird ein Rucksack zum Code hinzugefügt: if <Sonderfall> then
<Rucksack> else <alter Code>. Viele Rucksäcke machen ein Programm unwartbar.
Teilphasen
Auch die Designphase kann in mehrere Teilphasen (mit Reviews) unterteilt werden:
– Entwicklung von Basiskonzepten
– Auswahl geeigneter Hardware, Software-Tools, Algorithmen etc.
(Vergleich von 20 objektorientierten Datenbanksystemen,
Vergleich von verschiedenen Präsentationstools,
Leistungsmessungen verschiedener Kompressions-Algorithmen,
Bestimmung der Qualität verschiedener Druckformate
etc.)
– Implementierung eines Prototypen (rapid Prototyping)
– Erstellung des endgültigen Designs (Datenmodelle, Storyboards etc.)
– usw.
Review
Am Ende der Designphase muss ein Review erfolgen.
Die Ergebnisse des Designs müssen dem Auftraggeber vorgestellt werden, insbesondere, wenn diese ernsthafte Änderungen an einen oder mehreren Projektzielen
zur Folge haben.
Die Entscheidung, die dann getroffen wird lautet wie immer:
weiter (mit oder ohne Zieländerung (z. B. niedrigere Kosten)):
Das Projekt wird gemäß Design realisiert.
zurück (mit oder ohne Zieländerung (z. B. höhere Kosten)):
Das Design wird überarbeitet.
stop:
Das Projekt wird ergebnislos beendet.
44
Es muss allen Beteiligten klar sein, dass im nächsten Schritt Designänderungen
nur noch schwer durchzuführen sind – und sehr teuer werden können. Jetzt ist
jede Struktur, jede Oberfläche, jedes Modul, jeder Datentransfer definiert. Es darf
nicht sein, dass während der Fertigungsphase neue Module und Datenstrukturen
entstehen (Ausnahme: Changemanagement).
Beispiel Hausbau
Solange nur Architektenpläne gezeichnet werden, kann eine Wand ganz einfach
verschoben oder ein zusätzliches Leerrohr eingezogen werden.
Wenn die Wände aber mal stehen, sind Veränderungen nur mit zusätzlichen Kosten möglich.
2.1.3 Fertigungsphase (Entwicklung)
In dieser Phase wird das Produkt realisiert.
Funktionsbeschreibungen und Design liegen vor, „Kreativität“ ist nicht mehr gefragt, „gute Ideen“ schaden meist mehr, als dass sie nützen.
Es kommt allerdings immer wieder zu Überraschungen:
– Probleme treten auf, die im Design nicht berücksichtigt wurden.
– Der Auftraggeber hat neue Wünsche (hier sind Diplomatie und starke Nerven vom Projektleiter gefordert).
– Das Team folgt nicht dem Design (schlechtes Design?, schlechte Menschenführung?, Design nur Show für Management?).
Aktivitäten in der Entwicklungsphase
– Einrichten der Entwicklungsumgebung
– Entwicklung von Software
– Erstellung von MM-Objekten (Audio, Video, Bild, Text)
– Erstellung des Gesamtsystems
– Testen des Produktes (Funktionalität + Qualität)
– Realisierung von Datensicherheit, Datenschutz, Backup und Recovery etc.
– Schreiben des Benutzerhandbuches und anderer Dokumentationen wie
Schulungsunterlagen, Systemhandbuch, Installationsanleitung etc.
– Vorbereitung der Projektübergabe (Systemumstellung, Abnahme durch den
Auftraggeber etc.)
45
Auch hier kann es wieder viele Teilphasen geben:
– Erstellung von MM-Objekten und Systemkomponenten
– Integrations- und Dokumentationsphase
– Qualitätssicherung
– α-Testphase
– β-Testphase
– γ-Testphase
Reviews
Am Ende der gesamten Fertigungsphase liegt folgendes vor:
– Das fertige Produkt
– Die fertige Dokumentation (Benutzerhandbuch, Systemhandbuch etc.)
– Nachweise über Projekterfolg in Hinblick auf die Ziele Funktionalität, Qualität, Termine und Kosten
– Ausgebildete Betreuer und/oder Benutzer
– Anweisungen für:
• Installation
• Wartung + Versionspflege
• Datenschutz + Datensicherheit
• Backup + Recovery
• etc.
– Detailpläne für Einführung und Umstellung
Der Review dient dazu, aufgrund dieser Unterlagen zu entscheiden, ob das Produkt eingesetzt wird und ab 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
46
– Erstellung von Mängellisten (Mängel gibt es jetzt immer noch)
– Übergabe an die Benutzer, das Rechenzentrum, die Systembetreuer
– Umstellung (inklusive Unterstützung durch Projektteam bis zum erfolgreichen Abschluss der Umstellung)
– Analyse während des Realbetriebs (auch für CD-ROM-Produktionen)
• Wird das Produkt korrekt genutzt?
• Wird es akzeptiert?
• Wird der erwartete Nutzen (voraussichtlich) erreicht?
• Greifen die Maßnahmen zu
∗ Benutzerunterstützung (Online-Hilfe!!!)
∗ Datenschutz und Sicherheit
∗ Qualitätssicherung
∗ etc.
– Schulung
Daneben müssen Projektabschlussarbeiten durchgeführt werden:
– Abnahmeprotokoll
• Abschlussbericht + Erfahrungsbericht
• Testbericht
• Nachweis des Projekterfolges
• Nachkalkulation (abschließender Soll/Ist-Vergleich)
– Analyse von Planabweichungen (Ursachen?)
– Auflösung des Projektteams
2.1.5 Review
Im Review findet die Abnahme durch den Auftraggeber statt.
Achtung: Die Abnahmekriterien müssen bereits vorher schriftlich vereinbart worden sein. Insbesondere muss klar sein, welche Testergebnisse vorliegen müssen.
2.1.6 Die Nutzungs- und Aufarbeitungsphase
Während der Nutzungsphase müssen Wartungs- und/oder Pflegearbeiten durchgeführt werden.
Wartung: Beseitigung von Problemen
47
Pflege:
Weiterentwicklung
Grady (1992):
– Auf 10 Fehler, die vor der Produktfreigabe durch Testen gefunden wurden, kommt ein Fehler, der nach der Freigabe gefunden wird (z. B.: „Zeitsprung“-Fehler wie Y2K)
– Es dauert die 4- bis 10-fache Zeit, um in einem umfangreichen, im Einsatz
befindlichen Software-Produkt einen Fehler zu finden und zu beheben, als in
einem Produkt kurz vor oder kurz nach der Freigabe.
Schlechte Entwicklungsarbeit
⇒ Fehlerkorrekturen während der Wartung (korrigierende Aktivitäten)
Sehr schlechte Entwicklungsarbeit
⇒ Neu- oder Umentwicklungen während der Wartung (sehr schlecht, aber leider
weit verbreitet)
Software, die erstmals freigegeben wurde, arbeitet normalerweise ineffizient, da
sie noch nicht optimiert wurde.
⇒ Optimierung während der Wartung (perfektionierende Aktivitäten)
Änderungen in der technischen Umgebung (z. B. neue HW), der Funktionen (z. B.
durch Gesetzesänderungen), der Oberflächen etc.
⇒ Anpassung während der Pflege (anpassende Aktivitäten)
Achtung: Wartung und Pflege machen einen Großteil des Aufwands während
des Lebenszyklusses eines Produktes aus: 2/3 – 4/5 (67 %–80 %) des Gesamtaufwands. Quelle
Aufarbeitungsphase
Für den Projektleiter ist das Projekt beendet. Für Pflege und Wartung ist meist
jemand anders zuständig.
Allerdings sollten er oder besser noch das ehemalige Team das Projekt noch einmal aufarbeiten.
Es gibt drei wesentliche Fragen, die beantwortet werden sollten:
1. Was leistet das Produkt, und was sollte es leisten?
2. Wie wurde im Projekt geschätzt und geplant? Wie wurden Termine und Budget eingehalten?
3. Wie war und ist die Zufriedenheit von Benutzern, Auftraggeber, Management,
Team, Projektleiter und externen Partnern?
Achtung: Es geht nicht um Anschuldigungen und Rechtfertigungen.
48
Neubewertung
Nach längerer Zeit (sechs bis zwölf Monaten) kann das Projektergebnis noch einmal neu bewertet werden.
– Hat sich der erwartete Nutzen eingestellt?
– Wenn nein, warum nicht?
Allerdings wird dies meist nicht gemacht:
– Es seien keine Kapazitäten frei (Personal und Zeit).
– Es sei viel zukunftsorientierter nach vorne zu blicken.
– Ändern kann man es sowieso nichts mehr.
Ja! Aber – man kann viele Problemen in zukünftigen Projekten vermeiden.
In seinem Roman „Der Termin“ (DeMarco (1998) erfindet Tom De Marco den Job
„Manager der Software-Metrik-Gruppe“, einen „Software-Archäologen“. Dessen
Aufgabe ist es, alle möglichen Informationen über alte Projekte „auszugraben“,
um damit die Schätzungen für aktuelle und zukünftige Projekte deutlich zu verbessern.
Der Projektmanager Tompkins verliert dadurch seinen persönlichen Assistenten,
weil dieser die besten Beziehungen zu den meisten Mitarbeitern im Unternehmen
hat. Der Berater des Projektmanagers gibt einen triftigen Grund dafür an, diesen
Verlust zu akzeptieren:
„Wir verlieren ihn nicht, wir geben ihm nur einen Job, bei dem er alle seine Talente
einsetzen kann. Das ist unsere Aufgabe als Manager. Mitarbeiter dort einzusetzen,
wo sie ihre Fähigkeiten und Talente am wirkungsvollsten einbringen können. Das
ist es, was Management wirklich bedeutet.“
2.2 Wasserfall- und Spiralmodell
Das im letzten Abschnitt vorgestellte Modell wird in der FachliteraturWasserfallund Spiralmodell Wasserfallmodell genannt. Dieser Begriff geht auf W. W. Royce
(Royce (1970)) zurück (vgl. Wasserfall-Modell (2005)). Er verwendet zwar nicht
den Begriff „waterfall model“, die von ihm verwendete Grafik erinnert aber an
einen Wasserfall.
Royce definiert dabei die Phasen: System Requirements, Software Requirements,
Analysis, Program Design, Coding, Testing and Operations.
Das von mir im letzten Abschnitt vorgestellte Wasserfallmodell ist im Prinzip wie
folgt aufgebaut (graphisch angelehnt an Royce):
49
weiter
Phase 1
Review 1
weiter
Phase 2
zurück
Review 2
stop
weiter
Phase 3
zurück
Review 3
stop
weiter
Phase 4
zurück
Review 4
stop
zurück
stop
Das Wasserfallmodell hat einen prinzipiellen Nachteil. Wenn am Ende einer
großen und damit langen und teuren Phase im Review ein Problem entdeckt wird,
kosten ein oder gar mehrere Schritte zurück viel Zeit und Geld.
Schon Royce hatte gefordert, den Schritt von einer Phase zur nächsten (heute Review genannt) mindestens zweimal zu durchlaufen. Er schlug auch vor, einzelne
Phasen je nach Komplexität mehrfach zu durchlaufen.
Später hat Barry Boehm den Gedanken, einzelne Phasen mehrfach zu durchlaufen, weiterentwickelt (Boehm (1988)). Sein Modell wird durch eine Spirale visualisiert, in der bestimmte Phasen immer wieder durchlaufen werden und dabei auf
die Ergebnisse des letzten Zykluses zurückgreifen. Barry Boehm nennt das Modell daher auch „Spiralmodell“. Er schlägt folgende vier Phasen vor, die zyklisch
mehrmals durchlaufen werden:
1. Klärung der Ziele, Anforderungen und Randbedingungen
2. Risikoanalyse, Erstellung eines Prototypen
3. Implementierung und Test
4. Review (Auswertung des aktuellen Zykluses, Planung des nächsten Zykluses
oder Projektende/-abbruch)
50
Ph. 1d
Ph. 1c
Ph. 1b
Ph. Ph. Ph. Ph.
4d 4c 4b 4a
Ph. 1a
Ph. 3a
Ph. Ph. Ph. Ph.
2a 2b 2c 2d
Ph. 3b
Ph. 3c
Ph. 3d
Am Modell von Boehm fällt auf, dass er ein großer Verfechter von Risikomanagement und Prototyping ist. Prinzipiell lässt sich jedoch sein Vorschlag auf jedes
Wasserfallmodell anwenden. Die Vorteile liegen auf der Hand: Ein Rückschritt
um eine oder gar mehrere Phasen ist wesentlich billiger und weniger zeitintensiv
als beim Wasserfallmodell. Design-Entscheidungen werden schrittweise getroffen und anschließend gleich überprüft. Auftretende Probleme werden frühzeitig
erkannt.
Ich schlage daher folgendes Modell vor: Nach Abschluss der Spezifikationsphase
(d. h., wenn eine Spezifikation vorliegt), werden Design und Fertigungsphase im
Sinne des Spiralmodells zyklisch durchgeführt.
In jedem Zyklus werden folgende Schritte durchgeführt:
1. Design
2. Implementierung
3. Test
Nach jedem Schritt wird ein internes Review durchgeführt, nach jedem Zyklus
oder einer gewissen Anzahl von Zyklen wird jeweils ein großes Review mit dem
Auftraggeber durchgeführt (Meilenstein).
Heutzutage hat sich im Projekt-Management ein neues Modewort etabliert: agil.
Man spricht von agilem Projekt-Management, agilen Prozessen etc. Das Wort agil
steht dabei für leicht, flexibel.
Der erste Vertreter des agilen Software-Entwicklungsprozesses war das Extreme
Programming von Kent Beck (Beck (2000)). Weitere Modelle, wie z. B. der Rational Unified Process, folgten.
51
Allen gemeinsam ist es, kurze Iterationszyklen einzusetzen. Also kann mit Fug
und Recht behauptet werden, dass das Spiralmodell von Boehm eine der wesentlichen Grundlagen des agilen Projektmanagements eingeführt hat.
2.3 V-Modell XT
(geschützte Marke der Bundesrepublik Deutschland)
Dieses Kapitel basiert auf dem Aufsatz: Bundesrepublik Deutschland (2004).
Das V-Modell definiert einen Leitfaden zum Planen und Durchführen
von Entwicklungsprozessen unter Berücksichtigung des gesamten System-Lebenszykluses:
– Es definiert die zu erstellenden Projektergebnisse.
– Es legt Verantwortlichkeiten eines jeden Projektbeteligten fest (Auftragnehmer + Auftraggeber).
– Es regelt detailliert „Wer“ „Wann“ „Was“ in einem Projekt zu tun hat (auch
die Kooperation zwischen Auftraggebern und -nehmern).
– Andere Richtlinien (ISO-Standards, Verfahrensanweisung CPM der Bundeswehr, Vorgänger V-Modell 97) sind weniger konkret, aber noch im Gebrauch.
– Für Projekte in Unternehmen und Einrichtungen des öffentlichen und militärischen Bereichs gedacht, sowie für Behörden und Dienststellen des Bundes
und der Bundeswehr.
– Auch für kleine mittelständische Unternehmen geeignet.
– Vertragsgrundlage, Arbeitsanleitung, Kommunikationsbasis
– Anwendbar auf möglichst viele Projektkonstellationen (Anpassung an konkretes Projekt heißt Tailoring).
– Zweistufiges Verfahren für Pflege und Erweiterung des V-Modells selbst;
Innovationszyklen in vergleichsweise kurzen Abständen.
(Fast) jedes Projekt, das gemäß dem V-Modell durchgeführt wird, besteht aus zwei
Projekten: einem Projekt aus Sicht des Auftraggebers (AG) und einem Projekt aus
Sicht des Auftragnehmers (AN). Für Projektphasen, die von beiden gemeinsam
beendet werden, müssen jeweils bestimmte, während der Projektphase vom AN
oder AG erstellte Dokumente von beiden akzeptiert werden.
52
AG
AN
Projekt 2
definiert
AG
AN
Projekt 1
genehmigt
AG
Anforderungen 3
festgelegt
AG
Projekt
4
ausgeschrieben
AN
Angebot 5
abgegeben
AG
AN
Änderungsplan
festgelegt
14
AG
AN
Projekt 6
beauftragt
AG
AN
Abnahme
erfolgt 13
Verifizierung
Validierung
System
spezifiziert
AN
7
System
entworfen
AG
AN
Projekt
15
abgeschlossen
AN
Lieferung 12
durchgeführt
AN
8
System
integriert
AN
Feinentwurf 9
abgeschlossen
Spezifikation und Zerlegung
AN
11
AN
Systemelemente
realisiert
10
Realisierung und Integration
Zyklen möglich (über Änderungspläne)
Dieser allgemeine Phasenplan kann durch Tailoring für ein bestimmtes Projekt
konkretisiert werden. Zum Beispiel kann ein Projekt mit zwei Zyklen definiert
werden:
1. Zyklus: Entwicklung eines Prototyps
2. Zyklus: Entwicklung des eigentlichen Systems
Besonderheiten des V-Modell XT
– eine Systementwicklung = zwei V-Modell-Projekte
(Systementwicklungsprojekt eines Auftraggebers +
Systementwicklungsprojekt eines Auftragnehmers)
– Schnittstellen zwischen beiden Projekten sind genau beschrieben
– Ausschreibung enthält Lastenheft + Vorgaben für Projekthandbuch
53
Projekt 1
genehmigt
Projekt
definiert
Prototyp
Projekt 6
beauftragt
2
Anforderungen
3
festgelegt
4
Projekt
ausgeschrieben
Abnahme
erfolgt 13
Änderungsplan
14
festgelegt
System
Projekt 6
beauftragt
Abnahme
erfolgt 13
15
Projekt
abgeschlossen
Abbildung 2.1: Phasenplan eines Systementwicklungs-Projektes mit Prototyp-Entwicklung aus Sicht des Auftraggebers (Tailoring-Ergebnis)
– Angebot enhält vertragsrelevante Teile des Projekthandbuches + Qualitätssicherungshandbuch
– Angebotsannahme endet mit Vertrag
– Pflichtenheft = Gesamtsystem-Spezifikation
– Projektstatusberichte: Projektfortschritt, -planung, Steuerungsmaßnahmen,
Qualitätssicherung, Problem- /Änderungslisten
– Lenkungsausschuss + Änderungsgruppen: beide Parteien sind vertreten
– Zwischen- + Endprodukte werden durch Lieferung an den Auftraggeber
übermittelt
– Validierung (Eignung des Produktes bezogen auf Einsatzzweck, „Are we
building the right product?“)
Verifikation (Produkt stimmt mit Spezifikation überein, „Are we building the
product right?“)
– Abnahmeerklärung des Auftraggebers nach Lieferung
– Projektabschlussbericht des Auftragnehmers
54
– bei notwendigen Änderungen kann zu früheren Phasen zurückgesprungen
werden (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)
55
56
Kapitel 3
Schätzung
Schätzungen (Zeit, Kosten und auch Ressourcen) werden immer schon in den
ersten Projektphasen (spätestens in der Definitionsphase) erstellt und benötigt.
Diese primären Schätzungen werden allerdings laufend angepasst.
Hauptproblem: In den frühen Phasen eines Projektes kann der Aufwand
aufgrund sehr vieler unbekannter Größen meist nicht genau abgeschätzt werden.
Andererseits will der Auftraggeber wissen, was es kostet und wann es fertig ist.
1. Lösung: Man legt sich nicht fest
⇒ kein Projekt
2. Lösung: Man sagt irgendein Datum und irgendeinen Preis
⇒ politische Daten, die nichts mit dem Projekt zu tun haben
⇒ vermutlich große Abweichungen
3. Lösung: standardisierte oder individuelle Schätzmethoden
Hr. Abraham, Vorstand der deutschen Lufthansa: „Prognosen sind besonders dann
schwierig, wenn sie sich auf die Zukunft beziehen.“
1. Grundregel: Schätzungen sind keine Weissagungen, d. h. keine verbindlichen
Voraussagen.
2. Grundregel: Je ferner die Zukunft, desto schwieriger sind die Schätzungen
Die Schätzungen werden während des Projektes laufend überwacht und so früh
wie möglich korrigiert. Also nicht erst am Ende der Projektlaufzeit nachsehen,
was noch zu tun ist und dann eine Verlängerung um 12 Monate beantragen.
3.1 Die Schätzgrößen
Die Zielparameter Zeit, Kosten sowie Funktionalität und Qualität beeinflussen die
Schätzung.
57
Funktionalität
Qualität
+
+
-
-
+ +
-
Zeit (Dauer)
Kosten
Wenn an einem Parameter gedreht wird, hat das einen Einfluss auf einen oder
mehrere andere Parameter.
Im Teufelsquadrat von Sneed (1987) ist die Produktivität eines Entwicklungssystems als viereckige Fläche dargestellt. Der Flächeninhalt muss (in weiten Teilen) konstant bleiben, auch wenn die Ziele geändert werden, da die Produktivität
i. Allg. durch keine wie auch immer geartete Maßnahmen kurzfristig verbessert
werden kann (Produktivitätsverbesserungen sind nur mit langer Vorlaufzeit möglich (DeMarco (1998)). Das heißt, wenn zum Beispiel mehr Funktionalität in weniger Zeit erstellt werden soll, leidet darunter die Qualität und die Kosten steigen
(Überstunden, bessere Werkzeuge, externe Profis etc.).
Noch eine Warnung: Es ist insbesondere nicht möglich, die Produktivität eines
Teams durch Vergrößerung beliebig zu steigern, da der Kommunikationsaufwand
wächst. Es gibt nicht nur bei Parallelrechnern keinen optimalen Speedup, sondern auch bei parallel arbeitenden Menschen. Eine Vergrößerung eines Teams hat
zudem zunächst einen negativen Effekt: Neue Mitglieder müssen eingearbeitet
werden, alte Mitglieder werden dadurch von ihrer eigentlichen Arbeit abgehalten. Außerdem gilt grundsätzlich: Ein überbesetztes Team leistet stets weniger als
ein richtig besetztes. Das heißt aber nicht, dass die optimale Teamgröße sich im
Verlauf des Projektes nicht ändern kann. Im Allgemeinen ist es gut, ein Projekt
mit einem kleinen Team zu beginnen und dann, wenn alles spezifiziert ist und
es nur noch um Routine-Arbeiten geht, zu vergrößern. An einem Neubau arbeiten zunächst auch nur ein paar Architekten und Bauingenieure, bevor eine große
Anzahl von Bauarbeitern loslegt.
58
Für die Schätzungen hat das folgende Auswirkungen: Bei mindestens einem
Parameter sollte man einen Fehlerpuffer einplanen („on time“ oder „on budget“
– evtl. auch „on time and on budget“ mit optionalen Anteilen bei Funktionalität
und/oder Qualität).
3.1.1 Divide et Impera
Der Pötzseil-Case
(siehe Kupper (1993))
„Pötzseil“ ist im Kölner Sprachgut das Seil, an dem der Eimer in einem Brunnen
herabgelassen wird. Der Test verläuft wie folgt: Ein längeres Seil wird in zwei
gleichlange Teile zerschnitten. Die eine Hälfte wird in 5-8 unterschiedlich lange
Teile zerschnitten.
1. Test:
Länge des halben Seils schätzen.
2. Test:
Länge der Einzelstücke schätzen und Summe bilden.
3. Test:
Länge der Einzelstücke nacheinander schätzen, nach jeder Schätzung
wird die richtige Länge verraten. Anschließend wird wieder die Summe
gebildet.
Ergebnis: „Divide et impera“ (teile und herrsche) führt zum Ziel; Erfahrung verbessert das Ergebnis deutlich. (Studentenresultate einfügen)
Gewicht des Eifelturms
π·Daumen-Schätzungen von Studenten, die die PM-Vorlesung von W. Kowarschick besuchen, streuen sehr weit (100 t bis 100.000.000 t).
(gute) Schätzung
Zusammengedrückt nimmt der Eifelturm eine Fläche von ca. 2m · 2m ein, Höhe
ca. 300m, Stahl: 7,874 t/m3
⇒ Gewichtsschätzung: 300m · 2m · 2m · 7, 874 t/m3 = 9448, 8 t
Realität (Eiffelturm (2006))
Original-Gewicht: 7300 t (=4
ˆ kg/cm2 =
ˆ Erwachsener auf Sitzfläche eines Stuhls)
heutiges Gewicht: 10.000 t (wg. Beton statt Stahl ⇒ Rückbau geplant)
Original-Höhe:
312,27 m (mit Flagge)
heutige Höhe:
324,00 m (mit Antenne)
59
3.1.2 Akzeptierbare Abweichungen
Man sollte seine Schätzungen gleich von Anfang an mit einem
Unsicherheitsfaktor versehen. Wie sagt Goldratt in jedem seiner Bücher?
„Murphy lebt!“
Außerdem sollte (muss) die Planung möglichst feingranular, d. h. phasen-weise
bzw. vorgangsweise erfolgen. Feingranulare Schätzungen sind viel genauer als
grobe Gesamtschätzungen (vgl. Pötzsei-Case).
Die Schätzungen für spätere Phasen werden i. Allg. einen größeren Unsicherheitsfaktor enthalten. Diese dürfen allerdings nicht als Freibrief verstanden werden.
Schätzungen müssen von Anfang an sorgfältig durchgeführt werden.
Am Anfang von Kapitel 2 hatten wir folgende Schätzformeln eingeführt:
P
geschätzte Projektdauermin = (geschätzte Dauer n inkl. Review · rn,min)
P
′
geschätzte Projektkostenmin = (geschätzte Zeit n inkl. Review · rn,min
)
P
geschätzte Projektdauermax = (geschätzte Dauer n inkl. Review · rn,max )
P
′
geschätzte Projektkostenmax = (geschätzte Zeit n inkl. Review · rn,max
)
Beispiel
′
′
= 1,05)
= 0,95, r1,max
Phase 1: +/- 5 % Kostenabweichung (r1,min
′
′
= 1,07)
= 0,93, r2,max
′
′
= 1,10)
= 0,90, r3,max
..
.
Phase 10:
′
′
= 0,80, r10,max
+/- 20 % Kostenabweichung (r10,min
= 1,20)
Das heißt, bei gegebenen Gesamtprojektkosten von beispielsweise 100 000 Euro
liegt für jede Phase eine Kostenmarge fest:
Phase 1: 5000 Euro +/- 250 Euro
Phase 2: 30 000 Euro +/- 2 100 Eur
Phase 3: . . .
Außerdem sollte der prozentuale Anteil des Aufwands der einzelnen Phasen vom
Gesamtaufwand geschätzt werden.
Phase 1: 5 % des Gesamtaufwands
Phase 2: 30 % des Gesamtaufwands
Phase 2.1: 10 % des Gesamtaufwands
60
Phase 2.2: 20 % des Gesamtaufwands
Phase 3: . . .
Damit können Abweichungen, die sich in einer Projektphase ergeben, auf das
Gesamtprojekt fortgeschrieben werden.
Beispiele (Quelle: vermutlich Information Weeks)
Bertelsmann:
Definition: 30 %
Design:
30 %
Codierung: 15–20 %
Test:
20–25 %
Hewlett-Packard:
Definition: 18 %
Design:
19 %
Codierung: 34 %
Test:
29 %
Solange der Projektleiter im Rahmen der vorgegebenen Zeit- und Kostenmargen
bleibt, gibt es wenig Grund gegenzusteuern. Bei günstigerem Abschneiden kann
er sogar einen Überschuss in die nächste Phase mitnehmen. Bei Annäherung an
die Obergrenze muss er allerdings Maßnahmen ergreifen, damit er diese Grenze
nicht überschreitet. Eine sich abzeichnende Grenzüberschreitung muss sofort zu
einem außerordentlichen Zwischenreview führen.
Bei jedem Review sollten neue Schätzungen für die Restphasen auf Basis der
bisherigen Erfahrungen stattfinden. Sind beispielsweise die Kosten bisher um 3 %
überschritten worden und wird der geschätzte prozentuale Zusammenhang zwischen den einzelnen Phasen nicht geändert, so heißt das, dass die Schätzkosten
für die Folgephasen ebenfalls um je 3 % erhöht werden müssen (sonst müssen
evtl. nur die geschätzten Gesamtkosten korrigiert werden).
Andererseits können nach einem Review die Unsicherheitsintervalle i. Allg. nach
unten korrigiert und die Schätzungen des prozentualen Anteils der Einzelphasen am Gesamtaufwand verbessert werden. Daraus ergeben sich neue (minimale,
zu erwartende und maximale) Gesamtkosten, die vom Geldgeber (Auftraggeber
oder Management des Auftragnehmers) akzeptiert oder abgelehnt (d. h. Projektabbruch) werden müssen.
Beachten Sie, dass für alle Schätzungen sowohl eine Abweichung nach oben, als
auch nach unten eingeplant wurde. Viele Projektleiter interpretieren Schätzungen
allerdings anders. Alles kostet mindestens soviel und dauert mindestens so lange
wie geschätzt. Das heißt, es kostet nie weniger und dauert nie kürzer als geschätzt.
Höhere Kosten und längere Laufzeiten kommen dagegen sehr oft vor.
Die Gründe für dieses Schieflage sind meist gar nicht unseriöse Schätzungen, sondern die Angst, beim nächsten Projekt weniger Geld bzw. Zeit zu bekommen,
wenn man zugibt, dass die Schätzungen (augenscheinlich) zu „großzügig“ waren. Wenn die Unternehmer nichts gegen dieses Angst unternehmen, dann kostet
61
sie das viel Geld. Ein gesundes Unternehmen weiß, dass die Realität in beiden
Richtungen von einer Schätzung abweichen kann, nach oben und nach unten!
Ein typisches Negativbeispiel dafür, dass diese Erkenntnis nicht immer vorhanden ist, ist das berüchtigte Dezemberfieber z. B. in Einrichtungen des öffentlichen Dienstes: Wenn zugewiesene Gelder in einem Jahr nicht vollständig aufgebraucht werden, geht der Geldgeber davon aus, dass der Bedarf prinzipiell zu hoch
geschätzt wurde – und kürzt die Mittelzuweisungen in den Folgejahren entsprechend. Aus diesem Grund werden spätestens im Dezember alle noch vorhandenen
Geldmittel für irgendetwas ausgegeben, nur damit die Zuweisungen im nächsten
Jahr nicht gekürzt werden.
Aufgrund der Tatsache, dass es bei der hier vorgestellten Art der Schätzung verschiedene Schätzwerte gibt (Minimum, Erwartungswert, Maximum), sollten auch
die Schätzungen dreifach durchgeführt werden.
Projektkosten/dauer unter optimalen Bedingungen
Projektkosten/dauer unter normalen Bedingungen
Projektkosten/dauer unter schwierigen Bedingungen (worst case ohne Katastrophen)
3.2 Dreipunkt-Schätzung
Mit Ausnahme von PERT (Quelle?) basieren die etablierten Projektmanagement-Methoden auf der so genannten Ein-Punkt-Schätzung: Für jede zu schätzende Dauer und jeden zu schätzenden Kostenfaktor wird ein Wert geschätzt –
und dann für bare Münze genommen.
Das wirkliche Leben ist jedoch anders. Murphy lebt! Wenn man mich fragt, wie
lange ich von zu Hause zu meinem Arbeitsplatz braucht, antworte ich 20 Minuten.
Nur – eigentlich sind es nie genau 20 Minuten. Mal schaffe ich es in 15 Minuten
(alle Ampeln grün, kein Laster hält mich auf), das andere Mal stehe ich im Stau
auf der B17 und komme erst nach einer Stunde an.
Welche Schätzung soll ich also verwenden?
– 15 Minuten?
(Das schaffe ich höchstens zweimal im Jahr.)
– 20 Minuten?
(Das schaffe ich oft, manchmal geht es schneller, meist dauert es ein paar
Minuten länger)
62
– 60 Minuten?
(Das schaffe ich so gut wie immer, meist bin ich aber viel schneller)
Wenn man einen Mitarbeiter fragt, wie lange er für einen Vorgang braucht, hängt
die Antwort von seiner Erfahrung ab. Ein Anfänger würde im obigen Fall mit 15
Minuten rechnen. Er sieht die möglichen Probleme, die ihn behindern, noch nicht
und fällt mit dieser Schätzung erst einmal auf die Nase. Ein Profi antwortet „30
Minuten“, wenn es sich um einen nicht so wichtigen Vorgang handelt. Bei einem
wichtigen Vorgang antwortet er „60 Minuten“, weil er sich sicher ist, dass er ihn
in dieser Zeit auch erledigen kann.
Und sein Chef und dessen Chef schlagen vorsichtshalber jeder nochmal 30 Minuten drauf, für den Fall, dass der Big-Boss das Ganze um 20 % kürzt. Uns so
kommt zum Schluss eine Schätzung von 96 Minuten zu Stande.
Das Problem ist, das der Profi die von ihm oder seines Chefs genannte Zeit, d. h.
die gesamten 96 Minuten, auch nutzen wird, da ansonsten die Schätzungen für
unglaubwürdig gehalten würden (vgl. Dezemberfieber).
Erschwerend kommt hinzu, dass er für die Ereldigung mehr Zeit als notwendig hat
und deshalb leicht dem Studentensyndrom erliegt (Abbildung 3.1, vgl. Goldratt
(2002))
Wenn im letzten Drittel etwas schief geht, dauert die Realisierung noch länger als
geschätzt, obwohl bereits sehr viel Puffer in der Schätzung enthalten war.
Aus langjähriger Erfahrung kann ich Goldratts Beobachtungen bestätigen: Eine
Diplomarbeit wird normalerweise erst am Stichtag, häufig sogar erst 5 Minuten
vor der angegebenen Uhrzeit abgegeben – oder es wird eine Verlängerung beantragt. Es kommt schon mal vor, dass eine Arbeit einige Tage „zu früh“ abgegeben
wird. Aber es passiert nur äußderst selten, dass sie einen Monat vor dem Stichtag
fertig ist. Und das ist auch nur dann der Fall, wenn ein anderer triftiger Grund für
diese Eile vorliegt (Student hat Zusage für Arbeitsplatz o.Ä.).
Wie löst man nun dieses Problem?
Tom de Marco (DeMarco and Lister (2003)) und Eliyahan Goldratt (Goldratt
(2002) schlagen vor, Unsicherheiten explizit zu managen.
An Stelle eines einzigen Wertes werden für jeweils drei Schätzwerte ermittelt.
– bester Fall (best case)
– normaler Fall (normal case)
– schlechtester Fall (worst case)
Mit diesen Werten kann die Dichtefunktion einer Wahrscheinlichkeitsverteilung
festgelegt werden. Goldratt und de Marco verwenden Dichtefunktionen, die gut
durch die Beta-Verteilung beschrieben werden können. Aber auch die einfachere
Dreiecksverteilung leistet gute Dienste (vgl. Gartner (1999)).
63
Arbeitseifer
Oh, jetzt wird’s
aber knapp
anfängliche
Begeisterung
Ist ja noch Zeit!
Ende
Start
2/3 Zeit
1/3 Arbeit
Zeit
1/3 Zeit
2/3 Arbeit
Abbildung 3.1: Studentensyndrom
Dichte der Dreiecksverteilung
(vergleiche Dreiecksverteilung (2006))
Es seien a, b, c ∈ R mit a < b und c ∈]a, b[. Dann ist die Dichte der Dreiecksverteilung folgendermaßen definiert (vgl. Abbildung 3.2):

2(x−a)


 (b−a)(c−a) für a ≤ x ≤ c
2(b−x)
f(x) :=
für c < x ≤ b
(b−a)(b−c)



0
sonst
Dichte der Beta-Verteilung
(vergleiche Beta-Verteilung (2006))
Es seien a, b, α, β ∈ R mit a < b und α, β ≥ 1. Dann ist die Dichte der Beta-Verteilung folgendermaßen definiert (vgl. Abbildung 3.2):
64
Abbildung 3.2: Beta-Verteilung und Dreiecksverteilung
f(x) :=

 (x−a)α−1 ·(b−x)β−1
B(α−β)(b−a)α+β−1
0
für a ≤ x ≤ b
sonst
Dabei ist die Beta-Funktion folgendermaßen definiert:
B(α, β) :=
Z1
0
tα−1(1 − t)β−1 dt =
Γ(α) · Γ(β)
Γ(α + β)
Die Beta-Funktion kann also durch die Gammafunktion, das ist die Verallgemeinerung der Fakultätsfunktion n!, ausgedrückt werden (Bronstein and Semendjajew (1980)).
Unabhängig davon, welche Wahrscheinlichkeitsverteilung man verwendet, sagt
diese aus, dass Wolfgang spätestens nach 60 Minuten mit Sicherheit in der FH
ist. Dies ebtspricht allerdings nicht der Realität. Wolfgang kann auch einen Unfall ahben und erst Tage oder Wochen später oder auch gar nicht mehr kommen.
Während man extrem lange Verzögerungen theoretisch auch mit extrem langgezogenen Beta-Verteilungen modellieren kann wird der Fall, dass ein Vorgang und
damit evtl. das ganze Objekt beendet wird von den vorgestellten Vereiltungsfunktionen nicht erfasst.
65
Tom de Marco DeMarco and Lister (2003) schlägt vor, den vollständigen Projektabbruch als ein explizites Risiko zu modellieren.
Im Folgenden gehen wir jedoch davon aus, dass die Dauer eines Vorgangs mit
einer Dreipunktschätzung (d. h. mit einer Dreiecks oder Beta-Verteiltung) hinreichend genau beschrieben werden kann.
Welche Informationen hält diese Beschreibung für uns bereit? Um diese Frage
zu beantworten, muss man sich ein wenig genauer mit den Eigenschaften von
Wahrscheinlichkeits-Verteilung befassen.
Zu jeder stetigen Dichte f(x) gibt es die Wahrscheinlichkeitsverteilungs-Funktion
F (x):
Rx
P (X ≤ x) := F (x) :=
f(t) dt
−∞
Für die Dreiecksverteilung gilt (Dreiecksverteilung (2006)):


0
für x < 0



2

(x−a)
0 +
für a ≤ x ≤ c
(b−a)(c−a)
F (x) :=
2
(b−x)


1 + (b−a)(b−c) für c < x ≤ b




1
für b < x
Damit kann man nun berechnen, wie wahrscheinlich es ist, dass Wolfgang spätestens nach 20 Minuten in der FH ist (a = 15, b = 60, c = 20)
F (20) = 0 +
(20 − 15)2
25
1
=
= =
ˆ 11, 1 %
(60 − 15)(20 − 15)
45 · 5
9
Es ist schon erstaunlich, dass ich es im Schnitt nur jede zweite Woche wirklich in
20 Minuten oder weniger schaffe (wenn man diese Verteilung zu Grunde legt).
Man kann die Frage auch umkehren. Wie viel Fahrtzeit muss ich einplanen, damit
ich in 50 % oder gar 95 % der Fälle rechtzeitig ankomme?
Dies kann mit Hilfe der Umkehrfunktion F −1 für die Verteilungsfunktion F berechnet werden:
(
√
für p ≤ m
a + (b − a) mp
−1
p
F (p) :=
b − (b − a) (1 − m)(1 − p) für p > m
c−a
wobei m := b−a
F −1(p) wird p-Quartil genannt.
Das 50 %-Quartil und das 90, %-Quartil berechnen sich für unser Beispiel wie
folgt:
66
5
1
m = 20−15
60−15 = 45 = 9
r
1
F −1(0, 5) = 60 − (60 − 15) (1 − )(1 − 0, 5)
9
r
8 1
= 60 − 45
·
9 2
= 30
r
1
−1
F (0, 95) = 60 − (60 − 15) (1 − )(1 − 0, 95)
9
r
8
· 0, 05
= 60 − 45
9
= 50
Um also in 50 % der Fälle rechtzeitig in die FH zu kommen, müsste ich 30 Minuten Fahrtzeit einplanen. Und 50 Minuten Fahrzeit ergeben sich, wenn ich bei 95 %
aller Fahrten rechtzeitig in die FH zu kommen wollte.
Die Realität sieht allerdings anders aus. Staus passieren in der Früh nur sehr selten.
Die folgende Beta-Verteilung beschreibt die Situation daher besser:
Abbildung 3.3: Beta-Verteilung
Leider lassen sich die Verteilungsfunktion und die zugehörige Umkehrfunktion
der Beta-Verteilung nicht mit geschlossenen mathematischen Formeln beschreiben, sondern müssen algorithmisch (z. B. mit Fixpunktiteration) ermittelt werden.
67
Tools wie Mathcad stellen allerdings geeignete Funktionen zur Verfügung (Statistik (2006))
Für die obige Beta-Verteilung ergeben sich folgende Werte:
F (20)
= 0, 284
−1
F (0, 5) = 23
F −1(0, 95) = 35
(50 %-Quartil)
(95 %-Quartil)
Das heißt, in knapp 30 % der Fälle schaffe ich es wirklich in 20 Minuten oder
weniger. Wenn ich 23 Minuten einplane, bin ich in 50 % aller Fälle pünktlich.
Gehe ich sagar 35 Minuten vor einem geplanten Termin aus dem Haus, komme
ich nur noch in 5 % der Fälle zu spät. Diese Zeiten treffen die Realität ganz gut.
3.2.1 Erwartungeswert und Standardabweichung
Das 50 %-Quartil kann relativ gut mit dem Erwartungswert abgeschätzt werden.
50 %-Quartil und Erwartungswert unterscheiden sich allerdings je unsymetrischer
die Verteilung ist.
Erwartungswert einer Dreiecksverteilung:
a+b+c
3
Erwartungswert einer Beta-Verteilung:
µ(xD ) =
µ(xB ) =
αb + βa
α+β
Für unser Beispiel ergibt sich:
15 + 60 + 20
= 31, 7 ≈ 30
3
1, 74 · 60 + 6, 91 · 15
µ(xB ) =
= 24, 1 ≈ 23
1, 74 + 6, 91
µ(xD ) =
(50 %-Quartil)
(50 %-Quartil)
Die Streuung um diesen Erwartungswert wird mit Hilfe der Standardabweichung
berechnet:
q
b−a
c−a
σ(xD ) =
2(1 − m + m2 ), wobei m =
6
b−a
s
αβ
b−a
σ(xB ) =
α+β α+β+1
Für unser Beispiel ergibt sich:
68
σ(xD ) =
60 − 15
6
s
2(1 −
60 − 15
σ(xB ) =
1, 74 + 6, 91
r
12
1
+ ( )) = 10, 1
9
9
1, 74 · 6, 91
= 5, 8
1, 74 + 6, 91 + 1
3.3 Zentraler Grenzwertsatz der Statistik
Zur Abschätzung der Gesamtdauer einer Folge von Vorgängen, bei denen die jeweilige Einzeldauer mit Hilfe irgendwelchen Verteilungen (Dreieecksverteilung,
Beta-Verteilung etc.) geschätzt wird, kann mit dem zentralen Grenzwertsatz der
Statistik (Bronstein and Semendjajew (1980)) erfolgen.
Dieser besagt, dass unter bestimmten Voraussetzungen, die Summe einer Menge
von Zufallsgrößen X1 , . . . , Xn angenähert normalverteilt sind. Der Erwartungswert, die Varainz und die Standardabweichung dieser Normalverteilung können
dabei wie folgt abgeschätzt werden:
!
n
n
X
X
µ(Xi )
=
µ
i=1 ! i=1
n
n
X
X
=
V ar(Xi )
V ar
i=1
i=1
und, da die Standardabweichung die Wurzel aus der Varianz ist:
! v
u n
n
X
uX
σ
= t (σ(Xi ))2
i=1
2·σ
3·σ
etc.
n
X
!
i=1
!
n
X
i=1
i=1
v
u n
uX
= t (2 · σ(Xi ))2
v i=1
u n
uX
= t (3 · σ(Xi ))2
i=1
Der Erwartungswert der Summe ist gleich der Summe der Erwartungswerte und
die Varianz der Summe ist die Summe der Varianzen. Besonders interessant ist,
dass die Standardabweichung der Summe die Wurzel aus der Summe der Quadrate
der einzelnen Standardabweichungen
ist. Dieser Wert ist i. Allg. deutlich kleiner
P
als die Summe σ(Xi ) der einzelnen Standardabweichungen.
69
Man kann davon ausgehen, dass jedes „normale“ Projekt die Voraussetzungen
(Bronstein and Semendjajew (1980)) des Zentralsatzes erfüllt: Die Unsicherheiten
der Dauer der einzelnen Vorgänge sind voneinander unabhängig, die Vorgangsdauern sind gleichmäßig (d. h. es gibt keine Vorgänge, die einen Großteil des Gesamtprojektes ausmachen), es gibt „zahlreiche“ Vorgänge etc.
Standardabweichung
Mit Hilfe der Standardabweichung kann die Unsicherheit einer Abschätzung
quantifiziert werden. Für eine Normalverteilung gilt dabei die 67/95/99,7-Regel: Mit einer Wahrscheinlichkeit von 67 % liegt der Schätzwert (d. h. in unserem Fall die Gesamtdauer) im Intervall ±1σ um den Erwartungswert herum. Mit
95 % liegt er im Bereich [µ − 2σ, µ + 2σ] und mit 99,7 % liegt er im Bereich
[µ − 3σ, µ + 3σ]. Das heißt, in 0,15 % aller Fälle dauert ein Projekt länger als
µ + 3σ.
Um für eine Folge Vi von (kritischen) Vorgängen abzuschätzen, bis zu welchem
Zeitpunkt alle Vorgänge mit 99,85 % Wahrscheinlichkeit beendet sind, geht man
daher folgendermaßen vor:
1. Man ermittelt für alle Vorgnänge Vi den jeweiligen Erwartungswert µi und
die Standardabweichung σi ;
2. Man berechnet den Erwartungswert und
die Stadnardabweichung der SumqP
Pn
n
2
mer der Vorgänge: µ = i=1 µi , σ =
i=1 σi ;
3. Man berechnet den Wert µ + 3σ.
3.4 Schätzverfahren
Schätzungen können umso genauer ausfallen, je mehr vergleichbare Projekte oder
Situationen bekannt sind.
Hausbau: Kosten für ein Einfamilienhaus können mit einer Genauigkeit von weniger 1000 Euro (=
ˆ ca. 1 %) angegeben werden.
Umzug nach Berlin:
Abweichungen um mehrere 10 % sind möglich.
1. Flug zum Mond/Mars:
Gesamtkosten können erst spät abgeschätzt werden.
Es gibt Methoden zum Schätzen von Aufwand (Kosten, Zeit und Ressourcen), die
auf den Daten von vergleichbaren, bereits abgeschlossenen Projekten relativ gute
Schätzungen für neue Projekte ermöglichen.
70
3.4.1 Die Function-Point-Methode
Diese Methode wurde von Alan Albrecht bei IBM in den späten 70er Jahren entwickelt. Sie basiert auf Analogieschluss und Gewichtung. (Quellen)
Grundidee: Ein SW-Vorhaben wird in verschiedene Grundfunktionen zerlegt:
– externe Eingaben
– externe Ausgaben
– externe Abfragen
– externe Schnittstelle
– logische Datenbestände
Dann wird für jede Grundfunktion Art (siehe oben), Umfang (z. B. LOC) und
Komplexität (leicht, mittel, schwer) festgelegt. Abhängig von einer firmenspezifischen Function-Point-Funktion f(Art, Umfang, Komplexität) werden jeder
Grundfunktion so genannte Function-Points zugeordnet.
Aus der Summe der Functionpoints kann der Gesamtaufwand abgeschätzt werden.
Function Points
bereits abgeschlossene
Projekte
statistischer Mittelwert
Max
6000
5000
Mittel
4000
Min
3000
2000
1000
100 200
300 400
500 600
Personenmonate
Vorteile:
– Die Kurve wird mit jedem abgeschlossenen Projekt genauer.
– Man hat ein robustes Schätzwerkzeug zur Verfügung.
– Man kann auch 3-Punkt-Schätzungen (Min, Mittel, Max) vornehmen.
Nachteile:
– Die Daten vieler vergleichbarer Projekte (ähnliche Aufgaben,
ähnliche Anzahl Mitarbeiter) müssen zur Verfügung stehen.
71
– Die Aufwandsschätzung (z. B. LOC) je Grundfunktion ist zu Anfang des Projektes oft problematisch.
– Die Anzahl der Personenmonate ist ein problematisches Maß (genaue Begründung folgt noch).
– Trotz aller mathematischer Korrektheit sind statistische Methoden auch nur Schätzmethoden. Und Schätzungen können falsch
sein
3.4.2 COCOMO
COCOMO: Constructive Cost Model
COCOMO wurde in den späten Siebzigern von Barry Boehm entwickelt (Boehm
(1981)) und hat sich seitdem zu einem der wichtigsten Schätzmethoden gemausert. In den Neunzigern wurde eine gründlich überarbeitete Version II vorgestellt
(Boehm et al. (2000)).
COCOMO wurde für das Wasserfallmodell konzipiert.
COCOMO II kommt auch mit iterativen Modellen, wie dem Spiralmodell, dem
Rational Unified Process (?) etc. zurecht.
Bei COCOMO werden drei Arten von Projekten unterschieden:
organic:
kleines Projekt (< 50 KSLOC), kleines Team, erfahrende Programmierer, stabile Entwicklungsumgebung
semi-detached: größeres Projekt (50 – 300 KSLOC), Programmierer mit unterschiedlichen Erfahrungsleveln; Mittelding zwischen organic und
embedded
embedded:
relativ groß (> 300 KSLOC), schwierige Nebenbedingungen,
größere Unsicherheit, höherer Innovationsgrad
Alle Schätzungen von COCOMO basieren auf den so genannten Kilo Source Lines of Code (KSLOC). Man findet auch die Bezeichnung Kilo Delivered Source
Instructions (KDSI). Das sind die Anzahl der ausgelieferten Befehle (Schleifen,
Zuweisungen, Vergleiche), nicht einfach die Anzahl der Befehlszeilen (Lines of
Code = LOC). In COCOMO II können auch Function Points, Use Cases etc. zur
Schätzung herangezogen werden. Diese werden durch das so genannte Backfiring
in KSLOC umgerechnet. Allerdings sind diese Werte häufig nicht sonderlich stark
korreliert (Seibert (2005)).
Für jede Projektart können die Anzahl der benötigten Personenmonate, die Entwicklungszeit und die Teamgröße mittels einfacher Formeln aus den geschätzten
KSLOC ebenfalls abgeschätzt werden.
72
Für die Schätzmethode werden in Basic COCOMO folgende Zahlen verwendet:
organic
semi-detached
embedded
PM
Dauer
2, 4 · KSLOC1,05
2, 5 · PM0,38
PM/Dauer t 0, 7 · KSLOC0,651
3, 6 · KSLOC1,20
2, 5 · PM0,32
3, 0 · KSLOC1,12
2, 5 · PM0,35
Anzahl Mitarb.
Bei der Schätzung gemäß Intermediate COCOMO werden neben der Anzahl der
ausgelieferten Codezeilen weitere Kostentreiber berücksichtigt.
Die Projektdauer wird mit folgenden Formeln ermittelt:
PM | Dauer
organic
semi-detached
embedded
3, 2 · KSLOC1,05 · f
2, 5 · PM0,38
2, 8 · KSLOC1,20 · f
2, 5 · PM0,32
3, 0 · KSLOC1,12 · f
2, 5 · PM0,35
Der Effort Adjustment Factor f wird dabei durch Multiplikation von „Gewichten“
für weitere Kostentreiber ermittelt. Für jeden von fünfzehn Kostentreiber wird der
Aufwand geschätzt und gemäß der nachfolgenden Tabelle gewichtet (deutsche
Übersetzung von W. Kowarschick):
73
Kostentreiber
Produktmerkmale
Erforderliche
System-Zuverlässigkeit
Datenbankgröße
Komplexität des Produktes
Plattformmerkmale
Anforderungen an Laufzeitperformanz
Hauptspeicherbedarf
Änderungshäufigkeit der Systemumgebung
Anforderungen an Antwortzeiten
Personalmerkmale
Analysefähigkeiten
Softwareentwicklungsfähigkeiten
Erfahrungen im
Anwendungsgebiet
Erfahrungen mit der
Systemumgebung
Erfahrungen mit der
Programmiersprache
Projektmerkmale
Verwendung von SoftwareEntwicklungstools
Einsatz von SoftwareEngineering-Methoden
Anforderungen an Entwicklungsdauer
sehr
gering
gering
normal
hoch
sehr
hoch
extrem
hoch
0,75
0,88
1,00
1,15
1,40
0,70
0,94
0,85
1,00
1,00
1,08
1,15
1,16
1,30
1,65
1,00
1,11
1,30
1,66
1,06
1,15
1,21
1,30
1,56
0,87
1,00
1,00
0,87
1,00
1,07
1,15
1,46
1,29
1,19
1,13
1,00
1,00
0,86
0,91
0,71
0,82
1,42
1,17
1,00
0,86
0,70
1,21
1,10
1,00
0,90
1,14
1,07
1,00
0,95
1,24
1,10
1,00
0,91
0,82
1,24
1,10
1,00
0,91
0,83
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 teil dabei ein Projekt in sechs Phasen ein:
– Analyse (Requirements)
– Grobentwurf (Product Design)
– Feinentwurf (Detailed Design)
74
– 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 Points, UML Use Cases etc. können ebenfalls zu Schätzung herangezogen werden. Die zugehörigen Schätzwerte werden durch das so genannte Backfiring in KSLOCs umgerechnet. Allerdings sind die Umrechnungstabbelen noch
nicht sehr ausgereift.
Bei der Entwicklung von Software kann die Wiederverwendung von Code berücksichtigt werden.
Es werden drei Modelle unterschieden:
Application Composition Model:
für frühe Projektphasen
Early Design Model:
ebenfalls für frühe Projektphase, aber vorrangig für Evaluation von Architekturen und Entwicklungsstrategien, wenn viele Details des zu schätzenden
Projektes noch unbekannt sind
Post-Architecture Model:
für detaillierte Schätzungen nach der Entwurfsphase
Zur Abschätzung der Projektaufwandes in Personenmonaten (PM) und der Projektdauer in Monaten (M) werden in COCOMO II ähnliche Funktionen wie in
COCOMO verwendet, allerdings mit anderen Parametern (Formeln wurden vereinfacht – ohne Wiederverwendung von Code und Entwicklungszeitverkürzung):
PM = A · KSLOCE · f
M = C · PMF
(Projektaufwand)
(Projektdauer)
wobei
A = 2, 94
B = 0, 91
C = 3, 67
D = 0, 28
E = B + 0, 01 ·
5
X
Fj
j=1
F = D + 0, 2 · (E − B)
gesetzt wird. Die fünf Faktoren Fj werden projektabhängig aus den folgenden
Organisationsfaktoren enrmittelt:q
75
Organisationsfaktoren
– Erfahrungen im Produktbereich
– Entwicklungsfelxiblität
– Ausgereiftheit des Entwurfs
– Stakeholder-Zusammenhalt
– Software-Prozessreife
Der Effort Adjustment Factor f wird wieder durch Multiplikation von „Gewichten“ für weitere Kostentreiber ermittelt. Dabei wurden in COCOMO II einige Kostentreiber leicht modifiziert und deren Anzahl etwas erhöht (deutsche Übersetzung
gemäß Seibert (2005)). Die Gewichte wurden gegenüber COCOMO neu justiert.
Produktfaktoren
– Erforderliche Zuverlässigkeit
– Datenbankgröße
– Produkt-/Modulkomplexität
– Wiederverwendbarkeit
– Dokumentationsumfang
Plattformfaktoren
– Rel. Rechnerzeitnutzung
– Rel. Hauptspeichernutzung
– Plattform-Änderungsdynamik
Personalfaktoren
– Systemanalysefähigkeit
– Programmierfähigkeit
– Anwendungserfahrung
– Plattformerfahrung
– Sprach- und Tool-Erfahrung
– Personelle Kontinuität
Projektfaktoren
– Nutzung von SW-Tools
76
– Standortübergreifende Teamarbeit
– Verfügbar Projektdauer
Für das Post-Architecture Model kommen alle siebzehn Kostentreiber zum Einsatz, für die Schätzungen der ersten Projektphasen werden nur sieben und teilweise andere Kostentreiber berücksichtigt.
Die ursprünglichen Formeln von COCOMO II wurden auf Basis von 160 Projekten ermittelt. Diese Basis ist im Laufe der Zeit auf 250 Projekte angewachsen.
Für COCOMO-Varianten ist die Zahl der zugrundeliegenden Projekte dagegen
teilweise noch recht gering. (Seibert (2005))
Beispiel: COCOTS zur Schätzung der Kosten für Evaluation, betriebsspezifischen
Anpassung und Integration von Standardsoftware basierte im Jahr 2005 auf lediglich 20 Projekten.
COCOMO II wird laut Aussage von Barry Boehm laufend weiter entwickelt. Die
Umrechnungstabellen von Function Points in KSLOC sind noch großen Änderungen unterworfen. Auf die Frage, ob Backfiring bereits praktisch eingesetzt werden
kann, antwortete Barry Boehm im Jahr 2005: „Wir arbeiten daruf hin, haben aber
ähnliche Hürden zu überwinden, wie sie die Funktionspunktleute früher hatten.“
(Seibert (2005))
3.4.3 Die Güte von Schätzverfahren
Leider gibt es kein allgemeingültiges Verfahren, um präzise und verlässliche Vorhersagen zu machen Elzer (1994).
Faustregel: π · Daumen
„Schätze die Größe des Codes (LOC) und teile sie durch die vom Teamleiter
geschätzte Produktivität des Teams (LOC/PM)“
Diese Regel ist nicht schlechter, als viele kompliziertere Regeln (obwohl sie
nur einen Parameter berücksichtigt und nur einen linearen Zusammenhang beschreibt).
S.N. Mohanty hat 1981 Mohanty (1993) ein 36k-LOC-Projekt benutzt, um die
Vorhersagequalität von verschiedenen Kostenmodellen zu untersuchen. Die Ergebnisse sind erschütternd (und werden im Wesentlichen von Folgeuntersuchungen bestätigt):
77
Verfahren
1
2
3
Farr und Zagorski
Naval Air Dev. Center
Wolverton
Anzahl
Einflussgrößen
13
13
16
4
5
6
7
8
9
10
11
12
13
Simplified Wolverton
Kustanowitz
Aerospace
GRC
SDC
Price S
Walston and Felix
Aron
Schneider
Doty
15
5
4
4
12
10
2
4
keine Ang.
9
Kosten
(irgendwelche Einheiten)
370
2.000
900
1.200
1.360
900 – 1.350
1.600 – 2.700
1.350
1.240
1.200
1.330
580
550
870
650
Fazit
Der höchste Schätzwert ist 7,3 mal so hoch wie der niedrigste. Das sind eigentlich
keine brauchbaren Ergebnisse!
Prinzipiell sollte die Schätzung phasenweise erfolgen (siehe Pötzseil-Case) und
möglichst bekannte Werte aus vergleichbaren Projekten berücksichtigen (Analogieverfahren + Gewichtung, wie z. B. eine moderne Function-Point-Methode).
Außerdem sollten Schätzungen nicht vom Projektleiter allein, sondern von mehreren Experten vorgenommen werden (Expertenschätzung). Deren Schätzungen
sollten nicht zu weite auseinander liegen, da sonst vermutlich noch nicht alle Fakten bekannt sind und damit berücksichtigt werden (vgl. „Die fünf Weisen“).
Achtung: Die Chance, dass eine Schätzung mit einer Genauigkeit von +/- 10 %
stimmt, liegt in der Spezifikationsphase bei lediglich 2/3 (Ende der Orientierungsphase) bis 4/5 (Ende der Definitionsphase). Nach dem Ende
der Designphase liegt sie kontinuierlich bei ca. 9/10.
Schätzmethoden, wie die Function-Point-Methode, COCOMO etc., sind wesentlich genauer, wenn sie kalibriert werden, d. h., wenn die Schätzparameter der jeweiligen Methode durch mathematisch-statistische Analyse historischer Projektdaten an die Verhältnisse des jeweiligen Entwicklungsbereiches angepasst werden
(= Kalibrierung). Beispiel (Burghardt (1995)):
Analyse von 60 Projekten der Firma Siemens:
– COCOMO ohne Kalibrierung: ±20% in 45% der Fälle
78
– COCOMO mit Kalibrierung: ±20% in 95% der Fälle
3.5 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
– 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 besteht aus 1000 Ph effektiver Projektarbeit und nicht etwa aus
1600 = 200 · 8
Das heißt, man muss sich zunächst einmal darauf verständigen, was die Begriffe
PJ, PM, PW, PT und Ph eigentlich bedeuten.
Balzert (1998) berechnet die Bruttoarbeitszeit wie folgt:
– 37-Stundenwoche
– 5-Tagewoche
– 20,8 Arbeitstage/Monat
– 10 Monate/Jahr (wg. Urlaub und Krankheit)
⇒
–
–
–
–
1 PTbrutto = 37/5 h = 7, 4 h
1 PWbrutto = 37 h
1 PMbrutto = 7, 4 h · 20, 8 = 154 h (153, 92 h)
1 PJ = 10 · 153, 9 h = 1539 h
Die Nettoarbeitszeiten berechnet er einfach, indem er die 1539 h auf 12 Monate
verteilt:
– 1 PMnetto = 1539 h/12 = 128 h (128, 25 h)
– 1 PTnetto = 128, 25 h/20, 8 = 6, 2 h
– 1 PWnetto = 6, 2 h · 5 = 31 h
Dabei bleiben allerdings die Ausfallzeiten im Projekt wegen anderer Aufgaben
unberücksichtigt.
79
Ich führe daher zusätzlich den Begriff der Projektarbeitszeit ein:
– 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 auch folgende Arbeitszeiten möglich:
– 1 PTPAe = 8 h
– 1 PWPAe = 5 · 8 h = 40 h
– 1 PMPAe = 20, 8 · 8 h = 166 h
– 1 PJPAe = 10 · 160 h = 1887 h
Dies stimmt im Prinzip mit den von Balzert eingeführten Bruttoarbeitszeiten überein. Allerdings werden i. Allg. nur wenige Mitarbeiter von anderen Aufgaben entlastet. Vor allem im Critical-Chain-Projekt-Management. (siehe ??) ist es üblich,
Mitarbeiter, die an der so genannten kritischen Kette arbeiten, vollkommen von
anderen Aufgaben zu entlasten.
Mit welchen Begriffen man arbeitet ist letztlich egal, wenn sich alle Projektbeteiligten einig sind, was unter PJ, PM und PT zu verstehen ist. Auf eine stundengenaue Schätzung sollte man allerdings verzichten. Ein Mitarbeiter leistet an einem
12h-Tag i. Allg. weniger als an einem 8h-Tag (DeMarco (1998)).
Die Produktivität eines Programmierers wird heute meist in LOC/PM (LOC =
Lines of Code) oder NCSS/PM (NCSS = Non Commented Source Statements –
HP – schlecht, da Kommentare nichts zählen, aber wichtig sind) gemessen.1
Solange nicht bekannt ist, was PJ, PM, PW und PT genau bedeutet, kann die
Monatsproduktivität allerdings nicht in Jahres- oder Tagesproduktivitäten umgerechnet werden.
Die Produktivität wiederum ist wichtig, um z. B. den Bedarf an Mitarbeitern für
bestimmte Aufgaben zu ermitteln.
Beispiel
Aufgabe:
200 LOC-Programm erstellen
Produktivität: 25 LOC/(PT · MA)
1
(MA = Mitarbeiter)
Es gibt noch viele weitere Maße, wie ToolBook-Seiten/PT, AVI-Sec/PW etc.
80
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 Personenmonat andere Werte hat. Wenn man davon ausgeht, dass eine Person in einem
Jahr eine gewisse Leistung (z. B. 1000 LOC) erbringen kann, ergibt sich folgendes Bild:
1000 LOC/PJ
= 100 LOC/PMbrutto =
24 LOC/PWbrutto = 4, 8 LOC/PTbrutto = 0, 65 LOC/Phbrutto
1000 LOC/PJ
= 83, 3̄ LOC/PMnetto =
20 LOC/PWnetto = 4 LOC/PTnetto = 0, 54 LOC/Phnetto
1000 LOC/PJPA = 100 LOC/PMPA =
23, 5 LOC/PWPA = 5, 9 LOC/PTPA = 0, 98 LOC/PhPA
1000 LOC/PJPAe = 100 LOC/PMPAe =
24 LOC/PWPAe = 4, 8 LOC/PTPAe = 0, 60 LOC/PhPAe
Ich mag die Messung in Bruttozeiten (= 1 Jahr hat 10 Monate) lieber, da dann die
Zuordnung reale Zeit ↔ Projektzeit einfacher ist. August, Osterwoche, Pfingstwoche, 2 Wochen Weihnachten entfallen ⇒ Das reale Jahr hat auch 10 Monate,
in denen (voll) gearbeitet wird.
Außerdem ist mir die Messung in Projektarbeitszeiten (6 h/Tag, 16–17 Tage/Monat) lieber, als die übliche Vollarbeitszeiten, da auch diese Werte leichter
mit der Realität in Einklang zu bringen sind.
Wenn ich drei Aufgaben à 6 PTPA bearbeiten lasse und erhalte nach einem realen Monat das gewünschte Ergebnis, habe ich rein rechnerisch sogar etwas Zeit
gewonnen (da 18PTPA = 1, 125PMPA ).
Ein Mitarbeiter muss im Durchschnitt etwas mehr leisten als geplant, da Krankheit
und Dienstreisen den Durchschnitt drücken. Wenn man die üblichen Ferienmonate, wie oben angedeutet, intern als Nullarbeitszeiten rechnet, dann ist jede Arbeit,
die die Mitarbeiter in dieser Zeit leisten, eine „Mehrarbeit“, die mit anderen außerplanmäßigen Fehlzeiten gegengerechnet werden kann.
Alle anderen Definitionen von Personenmonaten etc. sind im laufenden Projekt
schwieriger mit der Realität abzugleichen, da die vom Mitarbeiter zu leistende
„Mehrarbeit“ (gegenüber den errechneten Werten) höher ist.
81
(größeres) 2. Problem
Wenn eine Person in einem Monat 1 PM Arbeit leistet, heißt das nicht, dass 2
Personen in einem halben Monat auch 1 PM Arbeit leisten.
Grund: Kommunikations-Overhead
Wenn n Personen gleichzeitig an einem Problem arbeiten, ergeben sich
n · (n − 1)/2 2-Personenkommunikationskanäle, außerdem gibt es 3-Personenkommunikation, 4-Personenkommunikation . . . und Teamkommunikation (Lagebesprechung etc.). Das heißt, der Kommunikationsoverhead wächst mit mindestens O(n2 ) mit der Anzahl der an einer Aufgabe beteiligten Personen.
Wenn beispielweise der Kommunikationsaufwand zwischen zwei Teammitgliedern bei durchschnittlich 10 %, d. h. 4 h/Woche liegt (da komplexe Teilaufgabe),
so ergibt sich folgendes Bild:
1 Person braucht 1, 0 Zeiteinheiten
2 Personen brauchen 0, 5̄ (= 1/(2 · 0, 9)) Zeiteinheiten
3 Personen brauchen 0, 41 (= 1/(3 · 0, 8)) Zeiteinheiten
9 Personen brauchen 0, 5̄ (= 1/(9 · 0, 2)) Zeiteinheiten
11 Personen werden gar nicht fertig :-)
Oder kurz: Viele Köche verderben den Brei!
Achtung: Diese Beobachtung besagt nicht, dass nicht mehrere unabhängige Teilaufgaben parallel ausgeführt werden können, um die Projektdauer
zu beschleunigen (z. B. Tests auf verschiedenen Zielplattformen oder
gleichzeitige Entwicklung von zwei unabhängigen Modulen wie Automotor und Fahrersitz).
Weitere Probleme bei der Bewertung, wieviele Arbeit von einer Person in einem
PM geleistet werden kann, sind:
1. Verschiedene Personen leisten in derselben Zeit verschieden viel.
2. Mitarbeiter bringen nicht jeden Tag volle Leistung (Schnupfen, private Probleme, Spannungen im Team, eine versaute Präsentation etc.).
3. Neulinge, die erst später in ein Projekt integriert werden, leisten weniger, da
sie sich erst einarbeiten müssen.
82
Zeit (in Tagen)
kommunikative
Arbeitsleistung je
Mitarbeiter
(innerhalb von 10 Tagen)
10
9
8
7
6
5
reale Arbeitszeit
theoretisches Optimum
4
produktive
Arbeitsleistung je
Mitarbeiter
(innerhalb von 10 Tagen)
3
2
1
0
4 5 6 7 8 9 10 11 Anzahl Mitarbeiter
1 MA: kostenoptimal
2 MA: bester Kompromiss aus Kosten und Zeit (evtl. 3 MA)
5 MA: zeitoptimal
1 2 3
4. Neulinge blockieren andere Mitarbeiter, d. h., auch erfahrene Projektmitarbeiter leisten weniger, wenn sie zusätzlich einen Neuling einarbeiten müssen.
5. Hilfskräfte können Projektmitglieder von Routineaufgaben, wie Kopieren,
E-Mail-Vorsortierung, Telefondienst etc. entlasten, ohne den Kommunikationsoverhead drastisch zu erhöhen.
83
84
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
(siehe Ampelaufgabe im Praktikum Multimedia-Programmierung).
– Planen lohne sich eh nicht, da ja doch alles anders komme.
– Planen behindere die Kreativität.
Nein: Planung ist kreativ, planloses Herumstochern im Nebel dagegen nicht.
Es gibt drei Möglichkeiten mit Planung umzugehen:
Erst handeln, dann denken
Es gibt viele (schlechte) Projektleiter, die Planung hassen und nur als Show für
das Management veranstalten, sich im Projektverlauf aber wenig darum scheren.
„Fangt schon mal an, den Papierkram machen wir später.“
Wenn man jedoch versucht Zeit zu sparen, indem man handelt bevor man denkt,
verbraucht man in der Summe viel mehr Zeit (spätere Fehlerbereinigung).
Denken statt Handeln
Es gibt aber auch (schlechte ) Projektleiter, die Planung zelebrieren: Alles wird
geplant und analysiert (PC-Tools); Alternative über Alternative wird untersucht,
nur getan wird nichts.
Erst denken, dann handeln: Storming, Norming, Performing
Saubere Planung besteht aus zwei Phasen, dann wird gehandelt:
Storming:
Ideensammlung; noch unstrukturiert (z. B. Brainstorming).
Norming:
Nun werden die Ideen sortiert und es wird geplant.
Performing: Schließlich werden die Pläne auch durchgeführt.
Brainstorming bedeutet, dass möglichst viele Ideen gesammelt werden, die nicht
bewertet werden (gut/schlecht etc.).
85
Die Stromingphase sollte lange genug dauern.
Die Planung von Projekten erfolgt normalerweise in drei Schritten:
grobe Projektplanung
z.B. Work Breakdown Structure
feinere Projektplanung
z.B. Netzpläne
Detailplanung
z.B. Balkendiagramme
Bei kleinen, übersichtlichen Projekten werden oft keine Netzpläne, sondern nur
eine einfache Grobplanung und Balkendiagramme erstellt.
4.1 Projektpläne
Alles muss geplant werden ⇒ viele Pläne. Diese sollten immer aktuell gehalten
werden – sonst sind sie nur Show und sind den Aufwand nicht wert, den man in
sie investiert hat.
Beispiele für Pläne
– Organisationsplan
Verantwortlichkeiten, Kompetenzen
– Kommunikationsplan, Berichts- und Informationswesen
Wer informiert wen wann worüber in welcher Form?
– Budget
Wieviel, wann, von wem, wofür?
– Arbeitspläne
Aufgaben (bzw. Vorgänge): Was, wann, wer?
– Personalpläne
Wer, was, wann, wann nicht (Urlaub etc.)?
– Schulungspläne
Projektteam, Anwender, Systembetreuer
– Ausstattungspläne
86
– Beschaffungspläne
– Testpläne
– Wartungspläne
– Kontrollpläne
Soll/Ist-Vergleiche, Review etc.
Ergebnis: stop/zurück/weiter
– Änderungspläne
– Abbruchplan
– etc.
4.2 Grobplanung
Bevor man Detailpläne erstellen kann, müssen erst einmal grobe Beschreibungen
der Aufgaben vorliegen. Man beachte, dass die Grobplanung eine gute Basis für
frühe Schätzungen darstellt.
4.2.1 Tätigkeitensammlung
Bei kleineren Vorhaben sollte man zunächst eine Tätigkeitensammlung erstellen.
Beispiel
Internetpräsentationen für die Firma Metzger Meier
– Festlegen der WWW-Seitenstruktur
(Welche Seiten, welche Beziehungen dazwischen etc.)
– Entwicklung eines Layouts
– Erstellen von Graphiken
– Anfertigen oder Beschaffen von Material
– Programmierung der Startseite
– Programmierung der Online-Bestellkomponenten
– etc.
Die Tätigkeitensammlung enthält noch keine Beziehungen zwischen der einzelnen Tätigkeiten. Es können allerdings schon Dauer, Kosten, verantwortliche Mitarbeiter etc. festgelegt werden.
87
4.2.2 Work-Breakdown-Structure
Größere Projekte sollten zunächst hierarchisch strukturiert werden.
Das kann sowohl nach Komponenten als auch nach Aktivitäten erfolgen.
Komponenten-Work-Breakdown-Structure
Internet−Präsentation
Metzgerei Meier
Startseite
Katalog
Bestellung
Fleisch Wurst Käse Sonstiges
Aktivitäten-Work-Breakdown-Structure
Internet−Präsentation
MM erstellen
WWW−Struktur
festlegen
Layout
festlegen
Material
beschaffen
WWW−Seiten
erstellen
Fotos
Videos Graphiken
Graphiken
erstellen
Startseite
erstellen
Katalog
erstellen
Bestell−
komponente
erstellen
Bei einer Planung können ruhig beide Hierarchien erstellt werden und die Schätzungen anhand beider Modelle erfolgen. Dabei sollten sich natürlich keine großen
Unterschiede ergeben, sonst war die Planung fehlerhaft. Im Allgemeinen sollte
88
erst der Komponenten-Breakdown und dann der (feinere) Aktivitäten-Breakdown
erfolgen.
4.3 Feinplanung
In der Aktivitäten-Work-Breakdown-Structure enthalten die Blätter die so genannten Vorgänge:
Ein Vorgang ist eine in sich abgeschlossene genau spezifizierte Aktivität, die innerhalb einer angemessenen Zeitdauer durchgeführt werden kann.
Für jeden Vorgang wird Folgendes festgelegt:
– Name des Vorgangs
– Zeitdauer
– Kosten
– Personal und weitere benötigte Ressourcen
Ergebnis, Kosten und Zeitdauer des Vorgangs müssen natürlich mit der Gesamtplanung und den Gesamtzielen vereinbar sein. Das heißt, die Summe der Vorgangskosten einer Projektphase sollten in etwa gleich den geschätzten Kosten für
diese Phase sein. Und die Gesamtdauer aller Vorgänge sollte der geschätzten Dauer entsprechen, wobei Vorgänge durchaus parallel ablaufen können.
Eine Projektphase besteht aus mehreren Vorgängen. Dabei kann und sollten die
Projektphasen ruhig in viele kleine Teilphasen untergliedert werden. Jede dieser
Teilphasen endet wie üblich mit einem Meilenstein und einem projektinternen
Review (nächste Teilphase ja/nein).
Da zu Meilensteinen immer ein definierter Zustand vorliegen muss, sollten sich
Teilphasen im Gegensatz zu Vorgängen nicht überlappen.
Meilensteine geben dem Projektleiter klare Anhaltspunkte für die Bewertung des
Projektfortschritts. Sie motivieren darüber hinaus das Projektteam („Das haben
wir schon geschafft!“).
⇒
1. Meilensteine müssen überprüfbar sein (Gegenbeispiel: „ Das Programm X ist
zu 50 % fertig“ ist nicht überprüfbar und damit kein geeigneter Meilenstein)
2. Meilensteine müssen kurzfristig sein (z. B. jeden Monat einer), sonst dümpelt
das Projekt evtl. lange vor sich hin ⇒ viele Meilensteine
3. Meilensteine sollten gleichverteilt sein (nicht 6 Meilensteine im ersten Jahr
und 18 im zweiten, besser 12 in jedem Jahr).
89
4.3.1 Netzpläne
Netzpläne dienen dazu, feinere Projektpläne auf der Basis von Vorgängen zu erstellen.
Es gibt mehrere Arten von Netzplänen. In der Praxis haben sich drei Basismethoden zur Erstellung von Netzplänen etabliert.
Vorgangspfeilnetzpläne (VPN; Vorgänge werden als Beziehungen modelliert)
Vorgang
Ereignisknotennetzpläne (EKN; Beziehungen zwischen Ereignissen = Ergebnissen von Vorgängen werden modelliert, z. B. Vorgang „Startseite erstellen“ =
ˆ Ereignis „Startseite wurde erstellt“).
Ereignis
Ereignis
Vorgangsknotennetzpläne (VKN; Beziehungen zwischen Vorgängen werden modelliert; ähnlich EKN).
Vorgang
Vorgang
Vorgangspfeil-Netzpläne (VPN) werden als historisch erste Darstellungsform der
Netzplantechnik angesehen. Diese Art der Darstellung wurde 1956 für die Critical-Path-Method entwickelt. Vorgangsknoten-Netzpläne (VKN) wurden 1957 im
Zusammenhang mit der Metra Potential Method (MPM) eingeführt. Im Jahr darauf wurden im Rahmen der Programm Evaluation und Review Technique (PERT)
die Ereignisknoten-Netzpläne (EKN) erstmals vorgestellt. Heute sind VPN und
EKN nur noch von geschichtlichem Interesse. Die Vorgangsknoten-Netzpläne
werden allgemein verwendet. Häufig spricht man auch (eigentlich fälschlicherweise) von PERT-Diagrammen oder PERT-Netzplänen, meint damit heute aber
stets VPNs und nicht die veralteten EKNs.
VPN: ursprünglich Critical Path Method (CPM)
EKN: ursprünglich Program Evaluation and Review Technique (PERT)
VKN: ursprünglich Metra Potential Method (MPM), heute Standard für alle Methoden
90
Anmerkung
– CPM arbeitet mit Einzeitschätzung
– PERT arbeitet mit Dreizeitschätzung (optimistisch, pessimistisch, wahrscheinlich)
Netzpläne enthalten neben den Vorgangs- und Ereignisbezeichnungen noch weitere Informationen:
Vorgangs- oder Ereignisnummer, frühster/spätester Starttermin/Endtermin,
Dauer etc.
Bei VPNs wird die Dauer direkt beim Vorgang notiert. Die Knoten enthalten eine
laufende Nummer sowie den frühesten und den spätesten Starttermin.
Bei EKNs wird die Dauer ebenfalls an den Beziehungspfeilen angebracht. Laufende Nummer, frühster und spätester Termin werden in den Knoten notiert.
In VKNs wird die gesamte Information (laufende Nummer, Bezeichnung, frühster und spätester Starttermin, Dauer und freie Pufferzeit, frühster und spätester Endtermin) in den Vorgangsknoten notiert. An den Pfeilen wird lediglich
die Art der Beziehung 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 ausgehend
vom ersten hin zu späteren Vorgängen mit Hilfe der Dauer und der Abhängigkeiten ermittelt. Dieser Vorgang wird Vorwärtsrechnung genannt. Dann können die
spätesten Start- und Endtermine ausgehend vom letzten Vorgang ermittelt werden.
Dieser Vorgang heißt Rückwärtsrechnung.
Ein kritischer Knoten ist ein Knoten, dessen frühster Starttermin gleich dessen
spätestem Starttermin ist. Jede Verzögerung, an der dieser Knoten beteiligt ist, hat
eine Verzögerung der gesamten Phase und damit des Gesamtprojektes zur Folge,
wenn man die verlorene Zeit nicht anderweitig wieder hereinarbeiten kann. In
einem VKN spricht man auch von kritischen Vorgängen.
Ein kritischer Pfad ist eine Liste oder gar ein ganzes Netz zusammenhängender
kritischer Knoten.
Pufferzeiten
Die Differenz zwischen frühestem und spätestem Starttermin (oder Endtermin)
eines Vorgangs heißt gesamte Pufferzeit (des aktuellen Vorgangs). Um diese Zeitspanne kann ein Vorgang verzögert werden, ohne das Gesamtprojekt zu verzögern.
Dabei kann es allerdings passieren, dass die Pufferzeiten nachfolgender Vorgänge
verringert werden.
91
VPN
MMDB−Testlizenzen
anschaffen (2)
6
2
6 6
3
MMDBs
installieren (3)
2
Testdaten
einspielen (5)
1
8 10
Phasenstart
(1)
5
11 11
4
Testszenario
entwickeln (4)
7
MMDB
testen und
auswählen (7)
2
6
13 13
Testszenario
implementieren (6)
3
8 8
92
EKN
2
Testlizenzen
angeschafft
6
6 6
2
3
MMDBs
installiert
8
8
5
Testdaten
eingespielt
1
9 11
1
2
7
MMDB
getestet und
ausgewählt
1
Phasenstart
0
3
0
7
4
Testszenario
entwickelt
7 8
3
13 13
6
Testszenario
implementiert
11 11
2
VKN
2
MMDBs
anschaffen
0
0
5
Testdaten
einspielen
0
6
6
6
2
8
8
0
0
6
6
0
8
10
1
2
9
11
1
Phasenstart
0
0
3
MMDBs
installieren
MMDB teste
und ausgewäh
0
0
11
11
93
4
Testszenario
entwickeln
0
1
7
1
8
8
nicht−kritisch
kritisch
<Nummer>
Vorgangsname
Meilenstein
fS
sS
D
gP
fE
sE
=
=
=
=
=
=
1
1
6
Testszenario
implementieren
7
8
fS
D
fE
sS
gP
sE
2
0
frühester Starttermin
Dauer
frühester Endtermin
spätester Starttermin
gesamte Pufferzeit
spätester Endtermin
3
0
11
11
Phasenende
13
0
1
13
0
1
Daneben kann man für die einzelnen Vorgänge auch noch die freie Pufferzeit berechnen. Das ist diejenige Zeit, um die der Start verzögert werden kann, ohne dass
die Pufferzeit eines Nachfolgevorgangs verringert wird. Die freie Pufferzeit eines
Vorgangs ist stets kleiner oder gleich als dessen gesamte Pufferzeit.
Für Vorgänge kann auch ein fixer Start- oder Endtermin vorgegeben werden. In
diesem Fall liefert die Vorwärts- und Rückwärtsrechnung eventuell negative Pufferzeiten. In diesem Fall spricht man von einem zeitinkonsistenten Netzplan.
Vorgangsknoten-Netzpläne
Die am meisten verbreitete Netzplanart stellen die Vorgangsknoten-Netzpläne dar.
Es werden vier Vorgangsbeziehungen unterschieden.
Normalfolge: Ende-Anfang (EA)
Anfangsfolge: Anfang-Anfang (AA)
Endfolge:
Ende-Ende (EE)
Sprungfolge: Anfang-Ende (AE)
Die Normalfolge EA sagt aus, dass der nächste Vorgang erst begonnen werden
darf, wenn der vorherige beendet wurde.
Beispiel
Design
EA
Implementierung
Mit der Implementierung kann evtl. auch schon etwas früher begonnen werden,
z. B. 5 Tage vor Ende des Designs.
Design
EA − 5T
Implementierung
Es ist auch möglich einen etwas späteren Start als das Ende des Design festzulegen.
Design
EA + 3T
Implementierung
Die Anfangsfolge sagt aus, dass ein zweiter Vorgang gleichzeitig mit dem ersten
anfangen muss.
Beispiel
Implementierung
auf der
Zielplattenform
AA
regelm. Backup
der
Zielplattform
94
oder die regelmäßigen Backups starten schon einen Tag vorher
Implementierung
auf der
Zielplattenform
AA−1T
regelm. Backup
der
Zielplattform
An Balkendiagrammen sieht man diese Beziehung deutlicher:
Implementierung auf Zielplattform
AA
Backups auf Zielplattform
...
Implementierung auf Zielplattform
AA−1T
Backups auf Zielplattform
...
Beachten Sie, dass der Anfang der relgelmäßigen Backups vom Anfang der Implementierung auf der Zielplattform abhängt und nicht umgekehrt. Mit Hilfe eines
Balkendiagramms (Gantt-Diagramm Abschnitt 4.3.2) kann man diesen Zusammenhang besser visualisieren. Die linke Seite des Balkens wird am Start-Datum
in einen Kalender eingetragen und die rechte Seite am Ende-Datum.
Die Endfolge EE sagt aus, dass ein zweiter Vorgang zusammen mit dem ersten
beendet wird.
95
Beispiel
Netzpläne
Übergabe
an
Kunden
EE
regelm. Backup
auf der
Zielplattform
Übergabe
an
Kunden
EE+1T
regelm. Backup
auf der
Zielplattform
Balkendiagramme
Übergabe an Kunden
EE
... Backups auf Zielplattform
Übergabe an Kunden
EE+1T
... Backups auf Zielplattform
Die Sprungfolge AE sagt aus, dass der zweite Vorgang erst beendet werden darf,
wenn der erste begonnen wurde.
96
Beispiel
Netzpläne
neue Anwendung
in
Betrieb
neue Anwendung
in
Betrieb
AE
AE+5T
alte Anwendung
in
Betrieb
alte Anwendung
in
Betrieb
Balkendiagramme
neue Anwendung In Betrieb ...
AE
... alte Anwendung in Betrieb
neue Anwendung In Betrieb ...
AE+5T
... alte Anwendung in Betrieb
Die alte Anwendung darf erst beendet werden, wenn die neue in den Einsatz
kommt.
Oftmals fallen Anfang und Ende von zwei Vorgängen nicht genau zusammen,
sondern unterscheiden sich um einige Tage. Wie in den Beispielen gesehen, notiert
dies wie folgt:
EA + 5 T: Vorgang 2 startet frühestens 5 Tage nach Ende von Vorgang 1
EA − 3 T: Vorgang 2 startet frühestens 3 Tage vor Ende von Vorgang 1
AA + 2 T: Vorgang 2 startet frühestens 2 Tage nach Start von Vorgang 1
97
AA − 1 T: Vorgang 2 startet frühestens 1 Tag vor Start von Vorgang 1
EE + 4 T: Vorgang 2 endet frühestens 4 Tage nach Ende von Vorgang 1
EE − 4 T: Vorgang 2 endet frühestens 4 Tage vor Ende von Vorgang 1
AE + 6 T: Vorgang 2 endet frühestens 6 Tage nach Start von Vorgang 1
AE − 2 T: Vorgang 2 endet frühestens 2 Tage vor Start von Vorgang 1
Man beachte, dass mit Hilfe von Addition und Subtraktion von Zeitabständen jede
Abhängigkeit zwischen zwei (endlichen) Vorgängen als Normalfolge, Anfangsfolge, Endfolge oder Sprungfolge notiert werden kann. Bei der Auswahl einer
geeigneten Folge kommt es also nicht auf formale, sondern nur auf praktische
Überlegungen an.
Anmerkung
Obwohl Netzdiagramme den zeitlichen Aspekt stark betonen, eignen sie sich auch
zur Kosten- und Ressourcenschätzung und -planung.
4.3.2 Balkendiagramme
Aus Netzplänen können verschiedene
(Gantt-Diagramme) abgeleitet werden.
so
genannte
Balkendiagramme
– Vorgangsbezogene Balkendiagramme:
In der Vertikalen werden die einzelnen Vorgänge angezeigt, auf den Balken
Zusatzinformationen wie ausführende Personen, Stellen etc.
– Personalbezogene Balkendiagramme:
In der Vertikalen werden alle Mitarbeiter gezeigt. Man sieht, wann ein Mitarbeiter welche Aufgaben durchführt.
– Ressourcenbezogene Balkendiagramme
– etc.
Balkendiagramme betonen den Zeitaspekt mehr als Netzdiagramme, da die Balkenlänge abhängig von der Dauer des zugehörigen Vorgangs gewählt wird. Die
für Netzpläne eingeführten Beziehungen (EA, AA, EE, AE) gibt es gleichermaßen für Balkendiagramme. (Die Beispiele des letzten Abschnittes waren eher auch
schon in Form von Balkendiagrammen angegeben.)
98
Nr.
Vorgangsname
Dauer
Anfang
Ende
S
1
Phasenstart
0 Tage
Mo 22.05.06
Mo 22.05.06
2
MMDBs anschaffen
6 Tage
Mo 22.05.06
Di 30.05.06
3
MMDBs installieren
2 Tage
Mi 31.05.06
Do 01.06.06
4
Testszenario entwicklen
7 Tage
Mo 22.05.06
Mi 31.05.06
5
Testdaten einspielen
1 Tag
Fr 02.06.06
Fr 02.06.06
6
Testszenario implementieren
3 Tage
Fr 02.06.06
Di 06.06.06
7
MMDBS testen und auswählen
2 Tage
Mi 07.06.06
Do 08.06.06
8
Phasenende
0 Tage
Do 08.06.06
Do 08.06.06
22. Mai '06
M
D
M
22.05.
D
F
S
S
29. Mai '06
M
D
M
D
F
S
05. Jun '06
M
D
M
D
F
S
Kowa
Kowa
Klever
Klever
Kowa, Klever
Kowa
08.06.
99
Projekt: MMDB2
Datum: Mi 28.06.06
S
Vorgang
Rollup: Vorgang
Externe Vorgänge
Kritischer Vorgang
Rollup: Kritischer Vorgang
Projektsammelvorgang
In Arbeit
Rollup: Meilenstein
Gruppenkopf
Meilenstein
Rollup: In Arbeit
Stichtag
Sammelvorgang
Unterbrechung
Seite 1
Abbildung 4.1: Gantt-Diagramm mit MS-Project erstellt
Inhalte der Knoten
Name
frühester Start, frühestes Ende, Dauer
spätester Start, spätestes Ende, gesamter Puffer
laufende Nummer,
freier Puffer
MMDBs anschaffen
30.05.06
6 Tage
22.05.06
30.05.06
Nr.: 2
Testszenario implementieren
MMDBs installieren
22.05.06
EA
31.05.06
01.06.06
2 Tage
0 Tage
31.05.06
01.06.06
0 Tage
0 Tage
Nr.: 3
EA
02.06.06
06.06.06
02.06.06
06.06.06
3 Tage
0 Tage
Nr.: 6
0 Tage
0 Tage
EA
EA
MMDBS testen und auswählen
Phasenstart
EA
Meilenstein: Mo 22.05.06
EA
Nr.: 1
07.06.06
08.06.06
07.06.06
08.06.06
Nr.: 7
EA
2 Tage
0 Tage
0 Tage
EA
Testszenario entwicklen
Testdaten einspielen
22.05.06
31.05.06
7 Tage
23.05.06
01.06.06
100
Nr.: 4
02.06.06
02.06.06
1 Tag
06.06.06
06.06.06
1 Tag
Nr.: 5
EA
1 Tag
2 Tage
EA
2 Tage
Phasenende
Meilenstein: Do 08.06.06
Nr.: 8
Projekt: MMDB
Datum: Mi 28.06.06
Kritisch
Sammelvorgang
Kritisch und extern
Nicht kritisch
Kritisch und eingefügt
Extern
Kritischer Meilenstein
Eingefügt
Projektsammelvorgang
Meilenstein
Kritisch und markiert
Kritisch und hervorgehoben
Kritischer Sammelvorgang
Markiert
Nicht kritisch und hervorgehoben
Seite 1
Abbildung 4.2: Netzplan mit MS-Project erstellt
0
1
3
1
V3
3
4
4
4
0
0
0
3
0
V5
EE+1T
7
7
6
8
2
2
0
0
0
3
3
4
3
6
6
2
3
Ende
0
0
10
10
V6
5
8
6
6
4
0
10
10
<Nummer>
Vorgangsname
fS
sS
Starttermin ist kritisch
Dauer ist unkritisch
Meilenstein
6
V4
3
kritisch
10
10
EA−1T
2
0
8
10
theoretisch
auch 5
EA−1T
V2
nicht−kritisch
7
AA+4T
Start
0
0
5
3
1
V1
D
gP
fE
sE
fS
D
fE
sS
gP
sE
=
=
=
=
=
=
frühester Starttermin
Dauer
frühester Endtermin
spätester Starttermin
gesamte Pufferzeit
spätester Endtermin
101
Nr. Name
Dauer
Anfang
Ende
Vorgänger
0 Phasenstart
0T
Mo 2.5.
1 Vorgang 1
3T
Mo 2.5.
Di 4.5. 0EA
2 Vorgang 2
3T
Mo 2.5.
Di 4.5. 0EA
3 Vorgang 3
3T
Mo 9.5.
Mi 11.5. 1EA, 2AA+4T
4 Vorgang 4
2T
Fr 6.5.
Mo 9.5. 1EA−1T, 2EA
5 Vorgang 5
2T
Mi 11.5.
Do 12.5. 3EE+1T, 4EA
6 Vorgang 6
4T
Mi 11.5.
Di 17.5. 3EA−1T
7 Phasenende
0T
Di 17.5.
Di 17.5. 5EA, 6EA
9. Mai 2005
2. Mai 2005
16. Mai 2005
S S MDMD F S S MDMD F S S MDMD F S S
Mo 2.5.
Abbildung 4.3: Beispiel für Netzplan- und Balkendiagramm aus einer alten Klausur
kritischer Vorgang
Vorgang
Puffer
Meilenstein
4.4 Ressourcen-Management
Bislang haben wir uns im Rahmen der Planung im wesentlichen mit den Beziehungen zwischen Vorgängen befasst. Implizit lag dabei die Annahme zu Grunde,
dass jederzeit unbegrenzte Ressourcen zur Verfügung stehen. Allerdings ist dem
im Allgemeinen leider nicht so. Aufgabe des Ressourcen-Management ist es, den
Bedarf an Ressourcen (Einsatzmittel) vorherzusagen und eine Einsatzoptimierung
zu erreichen, d. h. Engpässe und Leerläufe nach Möglichkeit zu vermeiden.
Ressourcen (auch Einsatzmittel genannt) sind:
– Personal
– Betriebsmittel (Hardware, Software etc.)
Man unterscheidet:
– termintreue Ressourcenplanung
„Wie viele Ressourcen brauche ich, um diese und jene Vorgänge bis zu diesen und jenen Terminen abzuschließen?“
– kapazitätstreue Ressourcenplanung
„Wann kann ich frühestens diese und jene Vorgänge bei gegebenen Ressourcen abschließen?“
4.4.1 Personalplanung
Folgende Gesichtspunkte müssen beachtet werden:
– verfügbare Personalkapazität
– Qualifikation
– zeitliche und örtliche Verfügbarkeit
– organisatorische Zugehörigkeit
– psychologische Aspekte („Never Change a Winning Team“; eine behinderte
Person in einem neuen Team erhöht die Erfolgschancen DeMarco and Lister
(1991) etc.)
Ziel der Personalplanung: optimaler Personaleinsatz über die gesamte Projektlaufzeit.
Beispiel „Spiel Aquaris“
Anhand des verfügbaren/eingeplanten Personals muss die Dauer von Vorgängen
(in Personentagen etc.) ermittelt werden. Der (zeitlich variable) Bedarf an MitDraft (29. Juni 2006)
102
Personal
3
Qualifika−
tion Informatiker
Vorgänge
Spiellogik
Grafiken
Animation
Spielsteuerung
4
Designer
1
Mechatronik eingeplantes
Personal
3
3
3
2
3
3
2
1
1
1
arbeitern kann nach qualifikationsorientierten sowie organisationsorientierten Gesichtspunkten ermittelt werden. Wenn Mitarbeiter gleichzeitig in mehr als einem
Projekt arbeiten, kann die Bedarfsplanung auch projektorientiert erfolgen.
Mitarbeiter
Problem 5 Designer
Spielsteuerung
Informatiker
Mechatroniker
Designer
Informatiker
Spiellogik
Designer
Animation
Informatiker Animation
Projektleiter
Spielsteuerung
Informatiker
Mechatroniker
Zeit
Abbildung 4.4: Qualifikationsorientierte Bedarfsplanung
Bei der qualifikationsorientierten Bedarfsplanung werden zu jedem Zeitpunkt die
Anzahl der benötigten MA mit bestimmter Qualifikation in ein Diagramm eingetragen (siehe Abbildung).
Bei der organisationsorientierten Bedarfsplanung werden die Mitarbeiter nicht
nach ihrer Qualifikation, sondern nach ihrer organisatorischen Zugehörigkeit
(Abt. 1, Abt. 2, Partner A, Partner B etc.) in ein Bedarfsdiagramm eingetragen.
Bei der projektorientierten Planung wird die Anzahl der Mitarbeiter eines jeden
Projektes in ein Bedarfsdiagramm eingetragen.
In allen Fällen kann man an derartigen Diagrammen Engpässe und Leerläufe ablesen (siehe Abbildung 4.5).
Im obigen Beispiel „Spiel Aquaris“ ergibt sich das Problem, dass keine 5 Designer
zur Verfügung stehen (siehe Abbildung 4.6).
103
Mitarbeiter
Engpass
Engpass
Leerlauf
Leerlauf
Leerlauf
Anzahl
Mitarbeiter
Zeit
Abbildung 4.5: Leerlauf und Engpässe
Designer
Anzahl
Designer
Zeit
Abbildung 4.6: Leerlauf und Engpässe am Beispiel des Projektes „Auqaris“
Man beachte, dass die Anzahl vorhandener Mitarbeiter (oder Spezialisten) über
die Zeit nicht notwendigerweise konstant ist.
Die eigentliche Aufgabe des Ressourcen-Management ist es, die zeitliche Abfolge von Vorgängen so abzuändern, dass Engpässe (d. h. Überstunden oder Einstellungen von weiterem Personal, Zukauf weiterer Ressourcen etc.) nach Möglichkeit vermieden werden. Im Wesentlichen werden dabei vorhandene Leerlaufzeiten
abgebaut. Primär sind dazu nicht-kritische Vorgänge geeignet, deren Erledigung
nach hinten – d. h. in die Leerlaufphasen – verschoben werden kann.
4.4.2 Bedarfsplanung der Betriebsmittel
Abhängig von der „Beständigkeit“ der Betriebsmittel unterscheidet man:
104
Termin
MA
V4
Anzahl
MA
V4
V2
V1
V3
V5
Zeit
Abbildung 4.7: Resultat der Vorgangsplanung
Termin
MA
Überstunden
Anzahl
MA
V4
V2
V1
V4
V3
V5
Zeit
Abbildung 4.8: Termintreue Personalplanung (Überstunden + zusätzliche Experten für V4)
105
Termin
MA
Anzahl
MA
V2
V1
V4
V3
V4
V5
Zeit
Abbildung 4.9: Kapazitätstreue Planung (keine Überstunden oder zusätzliche Experten für V4)
– verzehrbare Betriebsmittel (Büromaterial, Toner etc.)
– nicht-verzehrbare Betriebsmittel (Räume, Rechner, Software etc.)
Eine Betriebsmittelplanung ist nur dann notwendig, wenn Engpässe sehr wahrscheinlich sind. Ansonsten rentiert sich der zusätzliche Arbeitsaufwand nicht.
Für verzehrbare Betriebsmittel sollten genügend Finanzreserven vorgesehen werden, so dass fehlendes Material rechtzeitig nachbestellt werden kann. Nicht verzehrbare Betriebsmittel sollten in genügender Zahl bereitgestellt werden.
Wenn eine Betriebsmittelplanung notwendig sein sollte, so läuft diese im wesentlichen wie die Personalplanung ab. Man unterscheidet dabei zwischen:
– vorratseingeschränkter Einsatzplanung
Ein nicht-vergrößerbarer Vorrat eines (meist nicht-verzehrbaren) Betriebsmittel muss möglichst fair auf mehrere Nutzer aufgeteilt werden ⇒ Belegungspläne o. Ä.
– bedarfsbezogener Einsatzplanung
Zunächst wird von einem unbegrenzten Vorrat eines Betriebsmittels ausgegangen. Dann wird der eigentliche Bedarf zu den verschiedenen Zeiten ermittelt. Eventuell kann der Bedarf durch termintreue oder kapazitätstreue Auslastungsoptimierung verringert werden. Schließlich können die
Betriebsmittel gemäß dem errechneten Bedarf angeschafft werden.
– freier Einsatzplanung
Wenn keine Gefahr von Engpässen besteht, kann die Planung auf die SammDraft (29. Juni 2006)
106
lung von Benutzerbedürfnissen (oder -wünschen) beschränkt werden.
4.4.3 Kostenplanung
Die Kostenplanung erfolgt in Abhängigkeit von allen anderen Planungsaktivitäten.
Das Ziel ist immer auch eine projektumfassende Vollkostenrechnung, angefangen bei der Vorplanung, endend beim Abschlussbericht. Zu den ressourcenspezifischen Kosten (Ressourcenkosten) addieren sich noch die Gemeinkosten (wie
Büromiete, Löhne und Gehälter von Verwaltung und Management etc.), die sich
nicht spezifischen Projekten zuordnen lassen.
Für Personal muss zwischen normalen Stundensätzen und Überstundensätzen unterschieden werden. Diese können Gemeinkosten enthalten (Personalvollkosten)
oder nicht. Bei manchen Unternehmen (wie z. B. dem Staat) werden die Kosten für
alle Mitarbeiter derselben Qualifikation gemittelt (Personaldurchschnittskosten).
Das heißt, unterschiedliche Gehälter aufgrund von Leistungs- oder Familienzulagen o. Ä. werden projektunabhängig verrechnet.
Bei Betriebsmitteln entstehen Gemeinkosten (z. B. Büros), Festkosten (z. B. Neuanschaffung nicht-verzehrbarer Betriebsmittel) und laufende Kosten (z. B. Nachkauf aufgebrauchter verzehrbarer Betriebsmittel, Zeitschriften, Wartungsverträge
etc.)
Anmerkung
Auch Erlöse sind Kosten, und zwar negative Kosten.
4.4.4 Kalender
Wesentlich für alle Planungen sind die Kalender. Der wichtigste Kalender ist der
Projektkalender, in dem alle freien Tage (Samstage, Sonntage, Feiertage, Betriebsferien) eingetragen werden.
Daneben kann es beliebig viele Ressourcenkalender geben, in denen die Verfügbarkeit der einzelnen Ressourcen (Personal und Betriebsmittel) eingetragen wird.
Normalerweise enthalten die Ressourcenkalender lediglich mehr freie Tage als
der Projektkalender (Urlaub, Rechner auf CeBIT etc.). Allerdings gibt es auch
Ressourcen, die an ansonsten arbeitsfreien Tagen sinnvolle Arbeiten durchführen
können (Zement kann auch am Wochenende trocknen, 3D-Animationen können
auch über Weihnachten ohne Aufsicht gerendert werden etc.).
107
Manchmal sind auch spezielle Vorgangskalender wichtig, wenn z. B. bestimmte Vorgänge im Ausland stattfinden und der betriebsspezifische Projektkalender
daher keine Anwendung finden kann (sehr zum Leidwesen einiger Dienstreisender). Sollte ein PM-Tool keine Ressourcenkalender mit beliebig veränderbaren
Arbeitszeiten unterstützen, so können Wochenend- und Feiertagsarbeit auch mit
Vorgangskalendern modelliert werden.
4.5 Projektkontrolle (Controlling)
Projektkontrolle bedeutet, regelmäßig den aktuellen Stand des Projektes mit dem
geplanten Stand zu vergleichen (Soll-Ist-Vergleich) und bei wesentlichen Abweichungen frühzeitig gegenzusteuern.
Kontrolle ist ein wesentlicher Bestandteil der fortwährenden Planung (der selbst
auch geplant werden muss).
Insbesondere folgende Pläne sollten überwacht werden:
– Terminplan
– Kostenplan
– Qualitätskontrollplan
Bei der Kontrolle müssen dieselben Werkzeuge (SW-Tools etc.) zum Einsatz kommen, wie bei der Planung, um vergleichbare Werte zu erhalten.
Anforderungen an Pläne aus Sicht der Projektkontrolle:
– Jeder Vorgang endet mit einem „Produkt“, d. h., es it entscheidbar, ob der
Vorgang beendet wurde oder nicht.
– Vorgänge sind kurz (wenn möglich ein oder wenige Wochen).
– Ergebnisse sind in irgendeiner From messbar und damit vergleichbar.
Dringlichkeitslisten
Ein wichtiges Mittel zur Steuerung und Kontrolle von Projekten, sind die so genannten Dringlichkeitslisten (HotLists). In diese Listen werden dringende Tätigkeiten (mit Terminen) eingetragen, die sich nicht exakt in ein Balkendiagramm
bringen lassen oder die aus einem anderen Grund besonders beachtet werden müssen.
Die Dringlichkeitsliste sollte immer aktuell gehalten werden.
108
Tätigkeitsberichte
Um ein Projekt zu überwachen, kann man die so genannten Tätigkeitsberichte
einführen.
In einem (wöchentlichen) Tätigkeitsbericht trägt jeder Mitarbeiter ein, wie lange
er an welchem Vorgang gearbeitet hat.
Achtung: Tätigkeitsberichte sind unbeliebt und tragen manchmal zu einem
schlechteren Betriebsklima bei. Um wirklich Tätigkeitsberichte und keine Lügenberichte zu erhalten, sollten Sie folgendes beachten.:
– Entweder alle oder keiner (und nicht etwa nur die schlechteren Mitarbeiter).
– Keine minutengenaue Zeiterfassung. Eine Genauigkeit von 1 h oder höchstens 0,5 h reicht vollkommen.
– Machen Sie ihren Mitarbeitern klar, dass Sie wissen, dass die Mitarbeiter
höchstens 6 h an 4 Tagen pro Woche produktiv für das Projekt arbeiten können.
– Machen Sie ihren Mitarbeitern außerdem klar, dass die Erfassung von Überstunden für sie nur von Vorteil ist.
Tätigkeitsberichte haben mehrere Vorteile:
– Ihnen stehen aktuelle Zahlen (einschließlich aktualisierter Schätzungen) für
die weitere Planung zur Verfügung.
– Sie haben konkrete Zahlen für realistische Schätzungen von Folgeprojekten.
– Sie haben Daten, mit denen Sie gegenüber Betriebsrat („Warum soviele
Überstunden?’") und dem Management („Warum so wenig Projektarbeit?“)
argumentieren können.
Zeitdiagramme
Die Schätzungen, wie viele Tage ein Vorgang noch benötigt, können in ein so
genanntes Zeitdiagramm eintragen werden.
Der Schätzer von A hat für die berühmten letzten 10 % länger gebraucht, als für
den Rest. B war ein optimaler Schätzer (ein Pedant?). C wurde unterwegs optimistisch, erreichte dann jedoch das Ziel „nur“ zur anfangs geplanten Zeit. Und
D hatte zum Schluss eine Woche Verzögerung, nachdem er zwischenzeitig pessimistischer geschätzt hatte.
Earned-Value-Analyse
Gewöhnliche Kostenüberwachung vergleicht zu jedem Zeitpunkt die geplanten
(SOLL-Kosten) mit den angefallenen Kosten (IST-Kosten). Diese Zahlen spiegeln aber ein falsches Bild wieder. Wenn zum Zeitpunkt x beispielsweise die
109
Tätigkeitsbericht
Name: H. Meier
Projekt
Amun
Tätigkeit
Codierung
Design
Mo
Di
2
Fr
4
2
2
3
Interview Hr M.
2
Wartung
2
6
110
2
8
3
2
8
31
2
2
Allg. Meetings
Ausbildung
Literaturstudium
Sonst. (z.B. Verwaltung)
Summe
Überstunden
Do
4
4
Dienstgang
Ausfallzeiten
Krankheit, Arzt
Urlaub
sonst. Abwesenheit
Mi
Datum (Montag): 22. Juni 1998
Summe noch Tage Bemerkungen
2
12
20
unerwart. Probleme
6
9
1
8
6
-2
1
3
3
3
8
39
-1
Tabelle 4.1: Beispiel eines Tätigkeitsberichtes
ungeplant
A
B
C
D
8.
15.
22.
29.
6.
13.
20.
27.
3.
10.
17. 24.
1. Juni
geplante
Zeit
8.
15.
22.
29.
6. Juli
13.
20.
27.
3. Aug.
10.
17.
24.
tatsächliche Zeit
SOLL-Kosten gleich den IST-Kosten sind, aber erst 67 % der bis dahin geplanten Arbeit geleistet wurde, so liegt man nicht im Kostenrahmen, sondern hat ihn
um 50 % überzogen (3/3 der Kosten bei 2/3 der Arbeit).
Um derartige Probleme frühzeitig zu entdecken, wurde die so genannte Earned-Value-Analyse (Arbeitswert-Analyse) eingeführt.
Der Earned-Value (Arbeitswert) gibt den Wert der Arbeit an, die bis zum Stichtag
geleistet wurde. Dieser Wert entspricht den Kosten, die tatsächlich hätten entstehen dürfen. Im obigen Fall entspricht der Earned-Value lediglich 67 % der
SOLL-Kosten. Verglichen mit dem Earned-Value sind die IST-Kosten um den
Faktor 1,5 zu hoch.
Kennzahlen einer Earned-Value-Analyse
1. Budgetkosten der geplanten Arbeit (BCWS = Budgeted Cost of Work Scheduled)
BCWS bezeichnen die Kosten, die für die bis zum Zeitpunkt x geplante Arbeit
eingeplant waren: Sollkosten für geplante Arbeit.
2. Earned Value (BCWP = Budgeted Cost of Work Performed)
BCWP werden oft als Budgetkosten der geleisteten Arbeit bezeichnet. Sie
bezeichnen die Kosten, die für die bis zum Zeitpunkt x tatsächlich geleistete
Arbeit eingeplant waren: Sollkosten für geleistete Arbeit.
BCWP/BCWS entspricht dem Prozentsatz der geleisteten Arbeit (in unserem Beispiel z. B. 40 000/60 000 = 0, 67). Man kann auch die Differenz
111
von geleisteter und geplanter Arbeit bilden: BCWP − BCWS (in unserem
Fall 40 000 − 60 000 = −20 000). Dieser Wert heißt Leistungsabweichung
oder Planabweichung (SV). Negative Planabweichungen sagen – genauso wie
BCWP/BCWS-Werte < 1 – aus, dass man entweder dem Plan hinterherhinkt
oder dass man das vorgesehene Budget überschreitet.
3. Ist-Kosten der geleisteten Arbeit (ACWP = Actual Cost of Work Performed)
ACWP gibt an, wieviel Geld bislang wirklich ausgegeben wurde. Die Differenz BCWP−ACWP heißt Kostenabweichung (CV). Der Faktor (cost variance) ACWP/BCWP (= 1,5 in unserem Beispiel, da in unserem Beispiel ACWP
= BCWS angenommen wurde) kann verwendet werden, um eine neue Schätzung für die Projektgesamtkosten zu erstellen. Der Kehrwert BCWP/ACWP
(= 0,67 in unserem Beispiel) heißt Kostenentwicklungsindex (CPI). Ein Wert
>1 bedeutet eine gute Kostenentwicklung, ein Wert <1 zeigt Probleme an.
4. Abweichung bei Fertigstellung (VAC = variance at completion)
Die Abweichung bei Fertigstellung ist die Differenz aus den (geschätzten)
Gesamtkosten (EAC = estimated cost at completion) und dem Gesamtbudget
(BAC = budget at completion): VAC = EAC − BAC. Es gilt dabei dabei:
EAC = BAC · ACWP / BCWP
5. Geschätzte Restkosten bis zur Fertigstellung (ETC)
Die geschätzten Gesamtkosten (EAC) minus den bisherigen Kosten (ACWP)
sind die geschätzten Restkosten bis zur Fertigstellung (ETC = estimated cost
to completion).
An Tag X hätte die erst am Stichtag geleistete Arbeit bereits geleistet sein sollen.
112
Kosten
EAC
Restkosten
(ETC)
Istkosten
Kostenabweichung
zur Fertigstellung
(VAC)
Soll/Ist−Abweichung
(keine Aussagekraft)
ACWP
BAC
Kosten−
abweichung (CV)
Sollkosten
BCWS
Leistungs−
abweichung (SV)
Plankosten
BCWP
Zeit
X
Stichtag
Abbildung 4.10: Übersicht über die wesentlichen Earned-Value-Größen
113
114
Literatur
A SYMETRIX [1994]
ToolBook – OpenScript-Referenz, Springer-Verlag
BALZERT, H. [1996]
Lehrbuch der Software-Technik – Software-Entwicklung, Band 1, Spektrum
Akademischer Verlag GmbH, Heidelberg - Berlin
BALZERT, H. [1998]
Lehrbuch der Software-Technik – Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung, Band
2, Spektrum
Akademischer Verlag GmbH, Heidelberg - Berlin
B ECK , K. [2000]
Extreme Programming - Das Manifest, Band 2, Addison-Wesley
Beta-Verteilung [2006]
Beta-Verteilung,
Beta-Verteilung
http://glossar.fh-augsburg.de/
B OEHM , B. [1981]
Software Engineering Economics, Prentice Hall
B OEHM , B. [1988]
A Spiral Model of Software Development and Enhancement, In: IEEE Computer, 21(5), Seiten 61–72
B OEHM , B., A BTS , C., B ROWN , A. W., ET. AL . [2000]
Software Cost Estimation with COCOMO II, Prentice Hall
B ORCHERS , D. [2004]
Verursacherbedingt verspätet, In: c’t magazin für computertechnik, 2004(22),
Seiten 92–97
Bundesrepublik Deutschland [2004]
V-Modellr XT, Teil 1: Grundlagen des V-Modells, http://www.kbst.
bund.de/V-Modell/-,293/V-Modell-XT.htm
Brockhaus [1991]
Brockhaus-Enzyklopädie, Band 17, F.A. Brockhaus GmbH, Mannheim
B RONSTEIN , I., S EMENDJAJEW, K. [1980]
Taschenbuch der Mathematik, F.A. Brockhaus GmbH, Leipzig
115
B URGARTZ , D. [1995]
QM-Handbuch der Softwareentwicklung, Friedr. Vieweg & Sohn Verlagsgesellschagt mbH
B URGHARDT, M. [1995]
Projektmanagement – Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsvorhaben, Publicidis MCD, München/Erlangen, 3 edition
C USUMANO , M., S ELBY, R. [1997]
How Microsoft Builds Software, In: Communications of the ACM, 40(6), Seiten 53–61
D E M ARCO [1998]
Der Termin, Carl Hanser Verlag, München
D E M ARCO , T., L ISTER , T. [2003]
Bärentango, Carl Hanser Verlag, München
D E M ARCO , T., L ISTER , T. [1991]
Wien wartet auf Dich! Der Faktor Mensch im DV-Management, Carl Hanser
Verlag, München
Dreiecksverteilung [2006]
Dreiecksverteilung,
Dreiecksverteilung
http://glossar.fh-augsburg.de/
Fremdwörterduden [2001]
Duden – Das Fremdwörterbuch, Band 5, Dudenverlag, Mannheim, Leipzig,
Wien, Zürich, 7 edition
Eiffelturm [2006]
The official site of the Eiffel Tower, http://www.tour-eiffel.fr/
teiffel/uk/documentation/stucture/page/chiffr%es.
html
E LZER , P. F. [1994]
Management von Softwareprojekten, Friedr. Vieweg & Sohn Verlagsgesellschagt mbH
G ARTNER , P. [1999]
Die Drei-Punkt-Schätzmethode zur Kalkulation des Projektaufwands, In: Projektmanagement, (4), Seiten 33–37
G OLDRATT, E. M. [2002]
Die Kritische Kette. Das neue Konzept im Projektmanagement, Campus Verlag, Frankfurt, New York
116
G OLDRATT, E. M. [2003]
Das Ziel. Teil II., Campus Verlag, Frankfurt, New York
G OSCINNY, U DERZO [1968]
Asterix und Kleopatra, Delta Verlag GmbH, Stuttgart
G RADY, R. [1992]
Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall International Inc., Englewood Cliffs, New Jersey
G UIMARES , T. [1983]
Managing Application Progam Maintanance Expenditures, In: Communications of the ACM, 26(10), Seiten 739–746
G ULBA , U. [1995]
Unternehmensberatung, Kosten sparen mit Projektmanagementsoftware, In:
c’t magazin für computertechnik, 1995(10), Seiten 234–236
H EUER , G. C. G. [1979]
Projektmanagement, Vogel-Verlag, Würzburg
H UMPHREY, W. [1989]
Managing the Software Process, Addison-Wesley Publishing Company,
Massachusetts
J ESPEN , T. [1983]
Documentation – that most Onerous of Chores., In: Computer Design, Seiten
113 –
J UNGBLUTH , V. [1995]
Teamarbeit, Projektmanagement-Systeme im Vergleich, In: CT, 1995(10), Seiten 238–252
J UNGBLUTH , V. [1997a]
Teamwork, Einführung in die EDV-gestützte Projektplanung, In: CT, 1997(7),
Seiten 172–177
J UNGBLUTH , V. [1997b]
Alles im Griff, Projektmanagementsysteme im Vergleich, In: c’t magazin für
computertechnik, 1997(7), Seiten 178–189
J UNGBLUTH , V. [1998a]
Optimallösung: Krisenmanagement mit Projektplaungssystemen, In: c’t magazin für computertechnik, 1998(4), Seiten 140–143
J UNGBLUTH , V. [1998b]
Perfekt geplant, Projektmanagementsysteme im Vergleich, In: c’t magazin für
117
computertechnik, 1998(4), Seiten 144–158
K ELLNER , H. [1994]
Die Kunst, DV-Projekte zum Erfolg zu führen, Carl Hanser Verlag
K UPPER , H. [1993]
Zur Kunst der Projektsteuerung, R. Oldenbourg Verlag
L EWIN , K., L IPPITT, R., W HITE , R. [1993]
Patterns of Aggressive Behavior in Experimentally Created, In: Journal of
Social Psychology
M OHANTY, S. [1993]
Software Cost Estimation: Present and Future, In: Software Practice and Experience, 11, Seiten 103–121
M ÜLLER , S., S ONTOW, K. [1995]
Unternehmensberatung, Kosten sparen mit Projektmanagementsoftware, In:
c’t magazin für computertechnik, 1995(10), Seiten 234–236
OYEN , VOLKER UND S CHLEGEL , H. B. [1986]
Projektmanagement heute, Gabal, Gesellschaft zur Förderung Anwendungsorientierter Betriebswirtschaft und Aktiver Lernmethoden in Fachhochschule
und Praxis e.V.
P ITCHER , P. [1997]
Das Führungsdrama; Künstler, Handwerker und Technokraten im Management, Klett-Cotta, Stuttgart
WASSERFALL -M ODELL [2005]
Projektmagazin,
http://www.projektmagazin.de/glossar/
gl-0825.html
ROSENSTIEL , L UTZ [1974]
Motivation im Betrieb, Goldman, München
VON
ROYCE , W. W. [1970]
Managing the Development of Large Software Systems, In: Proceedings of
IEEE Wescon
RUMBAUGH , J., B LAHA , M., P REMERLANI , W., E DDY, F., L ORENSEN , W.
[1991]
Object-Oriented Modeling and Design, Prentice-Hall
RUMBAUGH , J., B LAHA , M., P REMERLANI , W., E DDY, F., L ORENSEN , W.
[1993]
Objektorientiertes Modellieren und Entwerfen, Hanser Verlag, Prentice-Hall
118
S CHEYTT, S. [1998]
Endstation Grössenwahn, In: ZUG – Für Menschen unterwegs (Deutsche
Bahn), Seiten 42–46
S EIBERT, S. [2005]
„Wir wollten ein Schätztool, das die Kunden-Lieferanten-Zusammenarbeit
unterstützt“ – Interview mit Barry Boehm, In: Projekt Management aktuell,
2005(1), Seiten 9–13
S NEED , H. [1987]
Software-Management, Müller GmbH, Köln
Statistik [2006]
Statistik, http://pm.fh-augsburg.de/statistik
[2005]
The TOC Times, http://www.goldratt.com/toctquarterly/
april2005.htm#dollardays
Z IELASEK , G OTTHOLD , D. [1995]
Projektmanagement, Springer-Verlag
119

Projektmanagement - Cosmopolitan University

Transcription

Similar documents

Projektmanagement - Hochschule Augsburg

Layout 3 - Koi Kurier

Veranstaltungstechnik • Veranstaltungswirtschaft

Gemalto .NETv3-Karte

Bitte lesen Sie sorgfältig die folgenden Hinweise!

Teil 2 - Medienpreis Mittelstand