Kritische Analyse des
Earned Value Managements
zum Controlling von technischen
(Software-) Projekten
Master-Thesis im Stud...
Inhaltsverzeichnis II
1 Inhaltsverzeichnis
1 Inhaltsverzeichnis..............................................................
Inhaltsverzeichnis III
Zusammenfassung und Fazit.............................................................................
Inhaltsverzeichnis IV
5.2 Lastenheft/Pflichtenheft ..........................................................................
Inhaltsverzeichnis V
6.5 Fazit...............................................................................................
Abbildungsverzeichnis VI
2 Abbildungsverzeichnis
Sofern es sich nicht um eigene Abbildungen handelt, wird im Text unter de...
Abbildungsverzeichnis VII
Abb. 36: Time Tracking in Jira, links Übersicht, rechts die Zeiterfassung von AP ..... 66
Abb. 3...
Tabellenverzeichnis VIII
3 Tabellenverzeichnis
Sofern es sich nicht um eigene Tabellen handelt, wird im Text unter der Tab...
Abkürzungsverzeichnis IX
4 Abkürzungsverzeichnis
Die weniger gängigen Abkürzungen und fachsprachlichen Abkürzungen sind hi...
Abkürzungsverzeichnis X
CPI Kosteneffizienz Cost Performance Index
CPM College of Performance Man-
gement
CV Kostenabweich...
Abkürzungsverzeichnis XI
Spice Software Process Improvement
and Capability Determination
(ISO/IEC 15504-5)
SV Planabweichu...
Einführung 1
1 Einführung
1.1 Darstellung des zu untersuchenden Problems
Das Earned Value Management (EVM) ist ein mächtig...
Einführung 2
das PMI das College of Performance Measurement (CPM) als Non Profit Organisation
gegründet. Auf den Internets...
Einführung 3
1.4 Problemzusammenhang / wissenschaftliche Relevanz
Das Earned Value Management ist eine weltweit eingesetzt...
EVM in der technischen Software-Entwicklung 4
2 EVM in der technischen Software-Entwicklung
2.1 Technische Softwareentwick...
EVM in der technischen Software-Entwicklung 5
2.3 Änderungen sind unvermeidlich
Eine weise Person soll angeblich mal gesag...
EVM in der technischen Software-Entwicklung 6
2.4 Kosten, Leistung und Zeit
Ein Projekt bewegt sich in seiner Lebensdauer ...
EVM in der technischen Software-Entwicklung 7
Abb. 3: Anforderung an die SW für die Hardware Fehlerbehandlung
Quelle: EN /...
EVM in der technischen Software-Entwicklung 8
Der aktuelle Abgasskandal, das sogenannte Dieselgate, des Volkswagenkonzerns...
EVM in der technischen Software-Entwicklung 9
Bild als (AC) bezeichnet, mit den Kosten, wie sie zur Bearbeitung der Arbeit...
Theoretischer Hintergrund und Forschungsstand 10
3 Theoretischer Hintergrund und Forschungs-
stand
Zur Durchführung des Ea...
Theoretischer Hintergrund und Forschungsstand 11
Die sieben Elemente des Business Case von PRINCE2™ sind29
 Wirtschaftlic...
Theoretischer Hintergrund und Forschungsstand 12
Die drei Vertreter im Projektlenkungsausschuss31
bei PRINCE2™ sind:
 Der...
Theoretischer Hintergrund und Forschungsstand 13
Der Auftragnehmer antwortet auf das Lastenheft mit einer Beschreibung, wi...
Theoretischer Hintergrund und Forschungsstand 14
den Abarbeitungsgrad genau dieser Arbeitspakete misst. Bei der Erstellung...
Theoretischer Hintergrund und Forschungsstand 15
=> Bei komplizierten Abhängigkeiten zwischen den Arbeitspaketen sowie bei...
Theoretischer Hintergrund und Forschungsstand 16
Objektorientierte Gliederung / Gliederung nach dem
Liefergegenstand
Bei d...
Theoretischer Hintergrund und Forschungsstand 17
3.4 Aufwandsabschätzung
Für die Ermittlung des Aufwandes der Arbeitspaket...
Theoretischer Hintergrund und Forschungsstand 18
Abb. 10: Routenplan von Lindau nach Konstanz
Quelle: Google Maps
Der Rout...
Theoretischer Hintergrund und Forschungsstand 19
Modellierung mit einer asymmetrischen Wahrscheinlich-
keitsdichtefunktion...
Theoretischer Hintergrund und Forschungsstand 20
Bei der optimistischen Schätzung ist klar, dass es aufgrund der regulator...
Theoretischer Hintergrund und Forschungsstand 21
Durch Integration ergibt sich daraus die Verteilungsfunktion wie folgt:
𝑭...
Theoretischer Hintergrund und Forschungsstand 22
Für die weiteren Analysen ist daher die standardisierte Betaverteilung au...
Theoretischer Hintergrund und Forschungsstand 23
Der Modus, also die Maximalstelle der [0,..,1] verteilten Dichtefunktion ...
Theoretischer Hintergrund und Forschungsstand 24
Abb. 14: PERT-Verteilungen für Min=90, Modus=120, Max=210 und λ = {2, 4, ...
Theoretischer Hintergrund und Forschungsstand 25
Verfügung, mit dem mit der heute zur Verfügung stehenden Tabellenkalkulat...
Theoretischer Hintergrund und Forschungsstand 26
möchte, dann muss der Fahrer E(X)=155 Minuten einplanen. Das gewünschte V...
Theoretischer Hintergrund und Forschungsstand 27
Einsatz der 4-Punkt-Abschätzung (Min, Modus, Max, λ)
Mit den aktuellen Ta...
Theoretischer Hintergrund und Forschungsstand 28
Zusammenfassung und Fazit
Die notwendigen Schätzpunkte für Mehrpunkt-Absc...
Theoretischer Hintergrund und Forschungsstand 29
3.5 Kernrisiken von Softwareprojekten
Seltsamerweise kennen alle die Prob...
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Masterthesis MBA Bernhard Wagner (online)
Nächste SlideShare
Wird geladen in …5
×

Masterthesis MBA Bernhard Wagner (online)

25 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
25
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Masterthesis MBA Bernhard Wagner (online)

  1. 1. Kritische Analyse des Earned Value Managements zum Controlling von technischen (Software-) Projekten Master-Thesis im Studiengang Business Administration in General Management Vorgelegt an der Allensbach University WHL School of Business and Economics Autor: Bernhard Wagner Nelkenweg 22 83104 Tuntenhausen T.: ++49 173 / 3567917 E-Mail: MasterThesis@WagnerBernhard.de Matrikelnummer: 873757 Gutachter: Prof Dr. Nikodemus Abgabetermin: 28. 09. 2016 Bearbeitungszeit: drei Monate
  2. 2. Inhaltsverzeichnis II 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis............................................................................................... II 2 Abbildungsverzeichnis ......................................................................................VI 3 Tabellenverzeichnis........................................................................................VIII 4 Abkürzungsverzeichnis.....................................................................................IX 1 Einführung........................................................................................................... 1 1.1 Darstellung des zu untersuchenden Problems ....................................................... 1 1.2 Überblick Quellenlage / Geschichte...................................................................... 1 1.3 Methodisches Vorgehen........................................................................................ 2 1.4 Problemzusammenhang / wissenschaftliche Relevanz ......................................... 3 1.5 Zentrale Untersuchungsfragen............................................................................... 3 2 EVM in der technischen Software-Entwicklung .............................................. 4 2.1 Technische Softwareentwicklung.......................................................................... 4 2.2 Software Engineering............................................................................................ 4 2.3 Änderungen sind unvermeidlich............................................................................ 5 2.4 Kosten, Leistung und Zeit ..................................................................................... 6 2.5 Konzepte des Earned Value Management............................................................. 8 3 Theoretischer Hintergrund und Forschungsstand......................................... 10 3.1 PRINCE2™ (Projects in Controlled Environments)........................................... 10 Produktbasierte Planung...................................................................................... 10 Business Case...................................................................................................... 10 Projektmanagement und Lenkungsausschuss...................................................... 11 3.2 Projektregelung / Projektcontrolling ................................................................... 12 Lastenheft versus Pflichtenheft ........................................................................... 12 3.3 Projektstrukturplan .............................................................................................. 13 Funktionsorientierte Gliederung.......................................................................... 14 Phasenorientierte Gliederung .............................................................................. 15 Objektorientierte Gliederung / Gliederung nach dem Liefergegenstand ............ 16 3.4 Aufwandsabschätzung......................................................................................... 17 Warum ist die Abschätzung des Aufwandes so schwierig? ................................ 17 Modellierung mit einer asymmetrischen Wahrscheinlichkeitsdichtefunktion.... 19 Dreiecksverteilung............................................................................................... 20 Beta-Verteilung ................................................................................................... 21 Einsatz der 3-Punkt-Abschätzung (Min, Modus, Max)....................................... 25 Einsatz der 4-Punkt-Abschätzung (Min, Modus, Max, λ)................................... 27
  3. 3. Inhaltsverzeichnis III Zusammenfassung und Fazit............................................................................... 28 3.5 Kernrisiken von Softwareprojekten..................................................................... 29 Fehlerhafter Zeitplan ........................................................................................... 29 Inflation der Anforderungen................................................................................ 30 Mitarbeiterfluktuation.......................................................................................... 30 Spezifikationskollaps........................................................................................... 30 Geringe Produktivität .......................................................................................... 31 Risikohöhe und Risikorückstellung..................................................................... 31 3.6 Kosten- und Budgetplanung................................................................................ 32 3.7 Ressourcen- und Projektterminplan .................................................................... 33 3.8 Das Projektmanagement als Regelkreis .............................................................. 34 3.9 Softwareentwicklungsprozesse............................................................................ 36 Wasserfallmodell................................................................................................. 37 V-Modell ............................................................................................................. 38 Scrum................................................................................................................... 39 Extreme Programming......................................................................................... 40 Résumé ................................................................................................................ 41 3.10 Zusammenfassung............................................................................................... 42 4 Das Earned Value Management....................................................................... 43 4.1 Reifegrad des Projektes und der Organisation .................................................... 43 4.2 Voraussetzungen der Earned Value Analysis...................................................... 44 4.3 Die vier Basiswerte der Earned Value Analysis.................................................. 45 4.4 Kennzahlen zur Fortschrittmessung der EVA..................................................... 47 4.5 Performance Kennzahlen in der EVA ................................................................. 48 4.6 Ermittlung des Fertigstellungsgrads POC ........................................................... 50 Ansätze aus der Literatur..................................................................................... 50 Projekterlöse in der Erfolgsrechnung .................................................................. 51 4.7 Vorhersage von Gesamtkosten- und Endtermins ................................................ 51 Prognostizierte Gesamtdauer............................................................................... 52 Prognostizierte Gesamtkosten ............................................................................. 52 4.8 Résumé ................................................................................................................ 54 5 Empirische Untersuchung ................................................................................ 55 5.1 Konzeption .......................................................................................................... 55 Produkt ................................................................................................................ 55 Organisationsstruktur .......................................................................................... 56 Technische und methodische Voraussetzungen .................................................. 57 Implementierung von Earned Value Management.............................................. 58
  4. 4. Inhaltsverzeichnis IV 5.2 Lastenheft/Pflichtenheft ...................................................................................... 59 5.3 Definition und Abschätzung der Arbeitspakete .................................................. 59 Abschätzung des Aufwandes............................................................................... 59 Wahl der Arbeitspaket-Risikoreserve.................................................................. 60 Projektstrukturplan / Releaseplanung.................................................................. 62 Realisierung des Projektstrukturplans in Jira ...................................................... 65 Ermittlung des Fertigstellungsgrads POC von Jira-Issues .................................. 66 Ermittlung des Fertigstellungsgrads POC von Jira-Stories................................. 69 Gehört das Management zum Earned Value? ..................................................... 71 5.4 Basisplan / Exceptionplan ................................................................................... 71 Planung der Zeitbasis des Projektes .................................................................... 72 Ressourcenplanung.............................................................................................. 73 5.5 Änderung projektexterner Kosten ....................................................................... 75 Währungsrisiken.................................................................................................. 76 Stundensatzrisiko................................................................................................. 76 Diskontierung, Cash-Flow und Investitionsrechnung ......................................... 77 Résumé ................................................................................................................ 77 5.6 Pflege der EVA-Daten......................................................................................... 77 Ermittlung der Ist-Kosten.................................................................................... 77 Ermittlung der BCWS oder warum konvergiert der SPI?................................... 79 Résumé ................................................................................................................ 79 5.7 Behandlung von Fehlern im Projekt.................................................................... 80 Was ist ein Fehler? .............................................................................................. 80 Schätzung des Aufwandes für die Behebung von Fehlern.................................. 80 Behandlung von Fehlern in der Gewährleistung mit EVM................................. 82 Behandlung von Fehlern durch Weiterentwicklung............................................ 84 Optimierung der Fehlerquellen............................................................................ 84 Résumé ................................................................................................................ 85 5.8 Milestone Trend Analysis.................................................................................... 86 5.9 Weitere EVM-Reports......................................................................................... 87 5.10 Multiprojektcontrolling und -management.......................................................... 88 5.11 Produktmanagement und Target Costing ............................................................ 90 5.12 Résumé ................................................................................................................ 90 6 Fazit und Ausblick............................................................................................. 91 6.1 Kap. 2: EVM in der technischen Software-Entwicklung .................................... 91 6.2 Kap. 3: Theoretischer Hintergrund und Forschungsstand................................... 91 6.3 Kap. 4: Das Earned Value Management ............................................................. 92 6.4 Kap. 5: Empirische Untersuchung....................................................................... 93
  5. 5. Inhaltsverzeichnis V 6.5 Fazit..................................................................................................................... 94 6.6 Ausblick............................................................................................................... 94 Literaturverzeichnis ........................................................................................................ i Eidesstattliche Versicherung ......................................................................................... v
  6. 6. Abbildungsverzeichnis VI 2 Abbildungsverzeichnis Sofern es sich nicht um eigene Abbildungen handelt, wird im Text unter der Abbildung die Quelle angegeben. Abb. 1: Spezifische Eigenschaften für eine Software Entwicklung.............................. 5 Abb. 2: Das „magische Dreieck“ aus Zeit, Kosten und Leistung ................................. 6 Abb. 3: Anforderung an die SW für die Hardware Fehlerbehandlung ......................... 7 Abb. 4: Das „magische Dreieck“; Kosten als intrinsischer Parameter ......................... 7 Abb. 5: Earned Value Management, hier Kostenanalyse.............................................. 8 Abb. 6: Earned Value Management, mit Kostengrenze.............................................. 11 Abb. 7: PSP mit funktionsorientierter Gliederung...................................................... 14 Abb. 8: PSP mit phasenorientierter Gliederung.......................................................... 15 Abb. 9: PSP mit objektorientierter Gliederung ........................................................... 16 Abb. 10: Routenplan von Lindau nach Konstanz ......................................................... 18 Abb. 11: Wahrscheinlichkeitsdichtefunktion einer Schätzung ..................................... 19 Abb. 12: Dreiecksfunktion, Dichte und Verteilungsfunktion ....................................... 20 Abb. 13: [0,..,1]-Beta-Verteilung, Dichte- und Verteilungsfunktion............................ 22 Abb. 14: PERT-Verteilungen für Min=90, Modus=120, Max=210 und λ = {2, 4, 8} . 24 Abb. 15: Risikohöhe...................................................................................................... 32 Abb. 16: Komponenten des Projektbudgets.................................................................. 33 Abb. 17: Das Projektmanagement als Regelkreis ......................................................... 34 Abb. 18: Projektmanagement als Dreigrößenregler...................................................... 35 Abb. 19: Wasserfallmodell mit Rücksprung................................................................. 37 Abb. 20: V-Modell XT, Entwicklungsprozess im Überblick........................................ 38 Abb. 21: SCRUM.......................................................................................................... 39 Abb. 22: Das „magische Dreieck“ für agile Entwicklung ............................................ 40 Abb. 23: Extreme Programming ................................................................................... 40 Abb. 24: ISO IEC 15504/Spice Reifegrade einer Entwicklung.................................... 44 Abb. 25: EVA, Absolute Kennzahlen zur Fortschrittsmessung.................................... 46 Abb. 26: Varianz von Kosten und Zeitplan aus Abb. 25 .............................................. 47 Abb. 27: Performance Index SPI und CPI von Kosten und Zeitplan aus Abb. 25 ....... 49 Abb. 28: Estimate At Completion der Kosten aus Abb. 25 .......................................... 53 Abb. 29: Generischer Werkstatttester von BOSCH...................................................... 56 Abb. 30: Organisationsstruktur des Modells-Projekts .................................................. 57 Abb. 31: Excel-Template zur Abschätzung des Aufwandes von Arbeitspaketen......... 59 Abb. 32: zusätzlicher Aufwand bei Unter- oder Überschätzung .................................. 61 Abb. 33: Releaseplanung der Userstories ..................................................................... 63 Abb. 34: PSP mit phasenorientierter, erster Gliederungsebene und objektorientierten, weiteren Teilbäumen...................................................................................... 64 Abb. 35: Gleiche Arbeitspakete in Excel und analog als Sub-Task in Jira................... 65
  7. 7. Abbildungsverzeichnis VII Abb. 36: Time Tracking in Jira, links Übersicht, rechts die Zeiterfassung von AP ..... 66 Abb. 37: Burndown Chart einer Etappe aus Jira........................................................... 68 Abb. 38: POC-Berechnung mit Hilfe von User Stories ................................................ 69 Abb. 39: POC-Berechnung aufgrund der Phasen des Projektes ................................... 70 Abb. 40: Phasenorientierter POC des Beispielprojektes............................................... 70 Abb. 41: EVM-Wochenplanung mit überlagerter Controlling-Monatsplanung ........... 72 Abb. 42: EVM Ressourcenplanung............................................................................... 74 Abb. 43: EVM-Wochenplanung mit Synchronisierung zum Controlling..................... 78 Abb. 44: Analyse der Fehlerbearbeitungszeit im Projekt ............................................. 81 Abb. 45: Verteilung von Fehlern nach Lieferung ......................................................... 82 Abb. 46: Analyse des Aufwandes nach Fehlerursachen ............................................... 85 Abb. 47: Analyse des Aufwandes für „False Defects“ von Mitarbeitern ..................... 85 Abb. 48: Milestone Trend Analysis zum Berichtstag 27. Sept ..................................... 86 Abb. 49: Daten für die Milestone Trend Analysis ........................................................ 86 Abb. 50: Ausschnitt der Milestone Trend Analysis aus Abb. 48.................................. 87 Abb. 51: Management View: Projektmarge und Fertigstellungsgrad........................... 87 Abb. 52: Management View: Das Zielkreuz für Cost- und Schedulevarianz............... 88 Abb. 53: Bullseye-View von SPI und CPI für mehrere Projekte.................................. 89
  8. 8. Tabellenverzeichnis VIII 3 Tabellenverzeichnis Sofern es sich nicht um eigene Tabellen handelt, wird im Text unter der Tabelle die Quelle angegeben. Tabelle 1: Analyse des Arbeitspaketes Lindau nach Koblenz........................................ 23 Tabelle 2: Abschätzung von Arbeitspaketen nach PERT-Methode ............................... 25 Tabelle 3: Mögliche Planungswerte nach der PERT-Methode ...................................... 26 Tabelle 4: Abschätzung von Arbeitspaketen mit Beta-Verteilung ................................. 27 Tabelle 5: Erreichung der Projektergebnisse Zeit, Kosten und Qualität ........................ 36 Tabelle 6: Eigenschaften der Entwicklungsprozesse für EVM ...................................... 42 Tabelle 7: Excel-Auszug der Jira-Daten......................................................................... 69 Tabelle 8: Feiertagsplanung............................................................................................ 72 Tabelle 9: Gewährleistung, Zuschlag und Freigabe des Budgets................................... 83
  9. 9. Abkürzungsverzeichnis IX 4 Abkürzungsverzeichnis Die weniger gängigen Abkürzungen und fachsprachlichen Abkürzungen sind hier in al- phabetischer Reihenfolge mit ihrer Auflösung in Deutsch bzw. Englisch angegeben, so- fern dies sinnvoll möglich ist. AG Auftraggeber Principal AN Auftragnehmer Agent ASIL Automotive Safety Integrity Level DoD Verteidigungsministerium der USA Department of Defense of the USA EV Fertigstellungswert Earned Value HW Hardware Hardware IPMA International Project Manage- ment Association OPC Office of Government Com- merce PC Plankosten Planned Cost for work actually done PI Leistungskennzahl Performance Indicator PM Projektmanagement Project Management SOW Leistungsbeschreibung Statement Of Work Abkürzung Auflösung Resolution ACWP / BV Ist-Kosten Actual Cost of Work Per- formed / Burned Value AP Arbeitspaket Work Package ASpice Automotive SPICE Automotive SPICE BAC1 Gesamtbudget Budget At Completion BCWP / EV Soll-Kosten bereits abge- schlossener Arbeit Budgeted Cost of Work Per- formed / Earned Value BCWS Plankosten Budgeted Cost of Work Scheduled BV / ACWP Ist-Kosten Burned Value / Actual Cost of Work Perfor- med C Kosten Cost CC Risikokosten / Vorhalte- kosten Contingency Cost CMMI Ein Reifegradmodell in der Softwareentwicklung Capability Maturity Model In- tegration 1 Mit dem Gesamtbudget kann sowohl das Gesamtbudget eines Arbeitspaketes wie auch das eines Pro- jektes gemeint sein.
  10. 10. Abkürzungsverzeichnis X CPI Kosteneffizienz Cost Performance Index CPM College of Performance Man- gement CV Kostenabweichung Cost Variance EAC Kostenschätzung zum Projektende Estimate At Completion (Cost) EVA Arbeitswertanalyse2 Earned Value Analysis EVM Arbeitswertmethode Earned Value Management EVMS Earned Value Management System (EVMS) GAAP General Accounted Accepted Principles GPM Deutsche Gesellschaft für Projektmanagement e. V. GuV Gewinn- und Verlustrech- nung profit and loss statement ICB Internationaler Projektma- nagement-Standard der International Project Ma- nagement Association IPMA International Competence Ba- seline IFRS International Financial Report- ing Standard MTA Meilensteintrendanalyse Milestone Trend Analysis OEM Erstausrüster Original Equipment Manufac- turer PE Geplante Ausgaben (Teil von BCWS) Planned Expenses (part of BCWS) PERT Programmevaluierungs- und Rückblicktechnik Programm Evaluation Review Technique PLC Geplante Lohnkosten (Teil von BCWS) Planned Labour Cost (part of BCWS) PMBOK Project Management Body Of Knowledge POC Fertigstellungsgrad Percent of Completion PRINCE2 PRojects In Controlled En- vironments3 PSP Projektstrukturplan work breakdown structure Q Qualität (auch Leistung) Quality (includes performance) SOP Produktionsbeginn Start Of Production SPI Zeiteffizienz Schedule Performance Index 2 Nach DIN 69901 ist Fertigstellungswert der korrekte deutsche Begriff für "Earned Value". 3 PRINCE2™ ist eine Projektmanagementmethode mit starker Verbreitung in Großbritannien, welche den erwarteten Nutzen des Projektes in den Vordergrund stellt.
  11. 11. Abkürzungsverzeichnis XI Spice Software Process Improvement and Capability Determination (ISO/IEC 15504-5) SV Planabweichung Schedule Variance SW Software Software T Zeit Time TOC Gesamtdauer Time At Completion TR Gesamtumsatz Total Revenue WBS Arbeitspaketaufteilung Work Breakdown Structure WC Gewährleistungskosten Warranty Cost WD Arbeitstage Work Days WP Arbeitspakete Work Package XP eXtreme Programmierung eXtreme Programming
  12. 12. Einführung 1 1 Einführung 1.1 Darstellung des zu untersuchenden Problems Das Earned Value Management (EVM) ist ein mächtiges Werkzeug des Projektmanage- ments zur kontinuierlichen Fortschrittsbewertung und Lenkung von Projekten. Der aktu- elle Fertigstellungsgrad des Projektes wird durch verschiedene Kennzahlen bzgl. Termin und Kosten wiedergegeben. Diese Kennzahlen geben die Abweichung gegenüber dem Planungsstand des Projektes an. Das zentrale Konzept des Earned Value Analyse (EVA) ist der Planwert der geleisteten Arbeit, sie wird daher im Deutschen auch als Arbeits- wertanalyse bezeichnet. Alle Untersuchungen in dieser Arbeit basieren auf der Annahme, dass der Leistungsum- fang (Qualität) und der Termin im Projekt extern vorgegeben sind und diese Rahmenbe- dingungen für die gesamte Projektlaufzeit gelten. Weiterhin wird angenommen, dass die Kosten für die zu erbringende geistige Arbeit die Kostenstruktur des Projekts dominiert. Diese definierenden Annahmen liegen typischerweise bei einer technischen Software- Entwicklung, z. B. im Embedded Bereich, vor. Die Wirksamkeit von verschiedenen Methoden des Projektmanagements und -control- lings für ein EMV einer technischen (SW-) Entwicklung wird in dieser Arbeit genauer untersucht, um hier den kompletten Projektregelkreis abzubilden. 1.2 Überblick Quellenlage / Geschichte Das Earned Value Management wurde Anfang der 60’er von der U.S. Navy als Programm Evaluation Review Technique (PERT)4 und PERT/cost entwickelt und ihre Zulieferer der Navy wurden zunehmend verpflichtet, die Kostenperformance ihrer Projekte als Earned Value zu berichten. Das amerikanische Department of Defence (DoD) hat die Methode als Cost/Schedule Control Systems Criteria (C/SCSC) mit 35 Minimumanforderungen an ein Projektma- nagement-System weiterentwickelt. Seit etwa 1965 ist sie die bevorzugte Controllingme- thode bei amerikanischen Projekten im öffentlichen Bereich. Hierzu gibt es eine Vielzahl von erarbeiteten Vorgaben bei amerikanischen Behörden5 . Seit den 90er Jahren steigt das Interesse an der EVM generell wieder an. Die notwendigen mathematischen Berechnun- gen können mittlerweile mit Hilfe von Computern mühelos durchgeführt werden und die Projekte werden umfangreicher und komplexer. Im Jahre 1996 wurden dann die 32 Earned Value Management System Kriterien (EVMS) in einer verständlicheren Form zusammengefasst6 und im Mai 1998 in die Norm ANSI/EIA 748 „Earned Value Management Systems (EVMS)“ als Industriestandard übernommen. Im Jahr 2000 hat das DoE in der Anweisung 413.3 die Verwendung von EVM nach der ANSI/EIA 748 vorgeschrieben. 2005 wurde dann die erste Version des EVM-Standards vom Project Management Institut (PMI) herausgegeben, die Anfang 2012 durch die zweite Version ersetzt wurde. Der internationalen Bedeutung von EVM entsprechend, hat 4 Vgl. PMI (2011): Earned Value Management, Kapitel 2.1.5 History of EVM Practice, S. 16-17 5 Vgl. Blaisdell, Rick (2015): Earned Value Management System (EVMS) 6 Vgl. NDIA ANSI EIA 748 (2005): A Standard for Earned Value Management Systems Intent Guide
  13. 13. Einführung 2 das PMI das College of Performance Measurement (CPM) als Non Profit Organisation gegründet. Auf den Internetseiten des CPM http://www.evmlibrary.org/ befindet sich eine sehr umfangreiche, aktuelle Sammlung von englischsprachigen Artikeln und Dokumen- ten zum Thema EVM, welche im Wesentlichen den Stand der amerikanischen Forschung und Wissenschaft wiederspiegelt. Weiterhin befindet sich unter http://www.mycpm.org/links/ eine umfangreiche Linksammlung zu weiteren Quellen. Die zumindest im amerikanischen Raum allgemein akzeptierten Methoden und Verfah- ren7 werden von den PMI auf der Internetseite http://www.pmi.org/PMBOK-Guide-and- Standards.aspx veröffentlicht. Da es für das EVM in Deutschland keine regulatorischen oder normativen Anforderungen wie im amerikanischen Raum für öffentliche Projekte gibt, ist es hier bei Weitem nicht so verbreitet. Auch die deutschsprachige wissenschaftliche Literatur8 referenziert häufig wieder auf das PMI, CPM und andere amerikanische Literatur. Die Deutsche Gesellschaft für Projektmanagement e. V. (GPM)9 , eine analoge Einrichtung zum amerikanischen PMI, beschäftigt sich kaum mit der EVM. Zusammenfassend kann man feststellen, dass die EVM in Deutschland zwar grundsätz- lich bekannt ist, in der Praxis jedoch aktuell nur selten Anwendung findet, dies ändert sich aber langsam. 1.3 Methodisches Vorgehen Zunächst werden die theoretischen Konzepte und Methoden, wie „Management by Exception“, verschiedene Arten von Projektstrukturplänen, das EVM selber, Mehrpunk- tabschätzungen und weitere Methoden in dieser Arbeit eingeführt. Diese Konzepte wer- den dann unter den Aspekt einer technischen (SW-) Entwicklung, bei der sowohl der Termin wie auch der Leistungsumfang (Qualität) extern vorgegeben sind, systematisch zusammengeführt und ihre Verwendbarkeit für EVM kritisch analysiert. Basierend auf den in der amerikanischen Literatur (PMI und CPM) beschriebenen EVM wird dargelegt, wie sich das EVM mit verschiedenen Methoden des Projektmanagements verbinden lässt und welche zusätzlichen Konzepte und Methoden dabei noch unterstüt- zend notwendig sind. Mit Hilfe dieser Methoden wird eine Gesamtlösung für technische (SW-) Projekte entwickelt, die dann anhand eines tatsächlich durchgeführten, technischen Softwareprojekts in der Automobilindustrie kritisch analysiert wird. Abschließend wird dargelegt, wie sich das Earned Value Projektmanagement sinnvoll zu einem Earned Value Programm- und Unternehmensmanagement erweitern lässt. Zum Schluss der Arbeit werden die Ergebnisse der einzelnen Kapitel im Fazit zusam- mengefasst und die Bedeutung des Reifegrads der Entwicklung und Organisation für eine erfolgreiche Implementierung von Earned Value Management dargestellt. 7 Vgl. PMBOK (2011): A Guide to the Project Management Body of Knowledge, welches im amerika- nischen Raum die allgemein akzeptierten Regeln des Projektmanagements enthält. 8 Vgl. Riederich Timo (2007): Die Bedeutung von Earned Value Management für die Steuerung von Produktentwicklungsprojekten“ S. 113..121. In dem sehr umfangreichen Literaturverzeichnis seiner Dissertation von S. 217-256 sind nur 6 von insgesamt 18 Titeln zum Thema EVM und EVA deutschsprachig. 9 Vgl. GPM Infocenter: Earned Value Analyse
  14. 14. Einführung 3 1.4 Problemzusammenhang / wissenschaftliche Relevanz Das Earned Value Management ist eine weltweit eingesetzte Technik des Projektmana- gements. Sie wird unter anderem vom Project Management Institut (PMI) in den College of Performance Management wissenschaftlich untersucht und ist aktuell in dem PMI- Standard „A Guide to the Project Management Body of Knowledge"10 enthalten. Weitere internationale Standards mit EVA und EVM sind: ANSI/EIA 748, AS 4815, C/SCSC, CABADA C/SPMS sowie die DIN 69901-5:2009-01. Das Projektcontrolling muss im Zuge der Globalisierung verschiedene Entwicklungsstan- dorte berücksichtigen und sich in das generelle Finanzcontrolling und Rechnungswesen des jeweiligen Unternehmens einfügen. Anpassungen des Projektes an Marktanforderun- gen und externe Störungen während der Projektlaufzeit sind unvermeidlich. Daher muss das Projektcontrolling aussagekräftige Informationen und Prognosen präzise und zeitnah für die Stakeholder zur Verfügung stellen. Die effektive und effiziente Abwicklung von Entwicklungsprojekten ist, neben der Marktorientierung der erzeugten Produkte, der wichtigste Erfolgsfaktor für die Innovati- onskraft eines Unternehmens und entscheidend für den zukünftigen Unternehmenserfolg. 1.5 Zentrale Untersuchungsfragen Die zentrale Frage dieser Untersuchung ist, welche organisatorischen, technischen und methodischen Voraussetzungen notwendig und sinnvoll sind, um das Earned Value Ma- nagement unter den Bedingungen einer technischen (Software-) Entwicklung mit norma- tiven und regulatorischen Anforderungen erfolgreich zum Projektcontrolling einzusetzen. Weiterhin wie sich das EVM bei festgelegtem Leistungsumfang und Fertigstellungster- min des Projektes sinnvoll mit Projektmanagementmethoden, insbesondere PRINCE2™, kombinieren lässt. Am Beispiel eines real durchgeführten Projektes wird empirisch untersucht, wie sich ein EVM in ein Projekt mit gegebenen organisatorischen Rahmenbedingungen implementie- ren lässt und welche Aussagekraft die Ergebnisse und Prognosen besitzen. Mit dem Er- gebnis dieser Untersuchung ist dann eine Einschätzung für andere technische (SW-) Projekte möglich, ob ein EVM für das Projektcontrolling11 und -Management dort sinn- voll eingesetzt werden kann und welche weiteren Maßnahmen bei der Implementierung in der Organisation noch unterstützend umgesetzt werden sollten. 10 Vgl. PMI (2011): Practice Standard for Earned Value Management und PMI 2011 Earned Value Man- agement 11 Controlling (deutscher Pseudoanglizismus in Anlehnung an engl. „to control“, steuern) ist ein Begriff der Wirtschaftslehre und wird hier als Teilfunktion des Projektmanagements verstanden. Das Projekt- controlling liefert die notwendigen Informationen zur Steuerung des Projektes.
  15. 15. EVM in der technischen Software-Entwicklung 4 2 EVM in der technischen Software-Entwicklung 2.1 Technische Softwareentwicklung Ein typischer Stellvertreter von technischer Software ist die Embedded Software (auf Deutsch: „eingebettete Software“), die in ein umgebendes technisches System integriert wird und mit diesem selbst in Wechselwirkung steht. Zwei Beispiele hierfür sind:  Steuergeräte die innerhalb eines Fahrzeugs verbaut wurden und dieses selber steuern.12  Diagnosesoftware („Werkstatttester“), welche Fehler innerhalb des Fahrzeuges sucht und Messdaten des Fahrzeuges für die Werkstatt bereitstellt. Die Funktionen der Software beziehen sich auf das umgebende technische System. Unter einer technischen Software wird jedoch nicht ein Textverarbeitungsprogramm verstan- den, welches das Betriebssystem und die Hardware nur für allgemeine Funktionennutzt. Die Software eines Motorsteuergeräts muss neben den rein funktionellen Ansprüchen (Regelung der Motorleistung und der Abgaswerte gemäß der gesetzlichen Anforderung) auch den Ansprüchen an funktionaler Sicherheit (keine ungewollte Beschleunigung des Fahrzeuges) genügen. Die Software des Motorsteuergeräts muss zum Produktionstermin des Fahrzeuges fertig sein. Das produzierte Fahrzeug muss in den Werkstätten diagnosti- ziert und gewartet werden können. Ein Fahrzeug ohne funktionierende, gesetzkonforme und funktional13 sichere Software für die Motorsteuerung ist schlicht unbrauchbar. 2.2 Software Engineering Allgemein sind insbesondere größere Softwareprojekte schwer zu kontrollieren, da der Umfang der zu erbringenden Gewerke von zu erbringender geistiger menschlicher Arbeit dominiert wird. Der genaue Umfang und der benötigte Ressourcenbedarf können beim Start eines anspruchsvollen Softwareprojektes14 nicht mit ausreichender Sicherheit fest- gelegt werden. Darum enthalten die aus einem Projektstrukturplan (PSP) hergeleiteten Arbeitspakete (AP), auf Englisch „workpackages“, ein hohes Maß an Unsicherheit. Im Projektmanagement gibt es seit einigen Jahren andere Vorgehensmodelle, wie z. B. die „Agile Entwicklung“ oder PRINCE2™ als Projektmanagement-Methode, neuerdings auch PRINCE2™ agil, um diesen Herausforderungen gerecht zu werden. Die Gründe für diese Sonderstellung von Softwareprojekten, im Vergleich zu anderen technischen Entwicklungsprojekten, sind vielfältig. Seit 1968 beschäftigt sich die Infor- matik im Bereich Software Engineering mit der Fragestellung, wie eine Entwicklung qua- litativ hochwertiger Software am besten durchgeführt wird15 und welche Eigenschaften hierfür, insbesondere bei mittleren und großen Softwareprojekten charakteristisch sind. 12 Steuern steht hier umgangssprachlich für Steuern- und Regeln, Der Unterschied zwischen Steuerung („open loop control“ oder offener Wirkungsablauf) und Regelung („closed loop control“ oder „ge- schlossener Wirkungsablauf“) ist im Rahmen dieser Untersuchung ohne Bedeutung. 13 Die hauptsächliche Sicherheitsanforderung eines Motors ist, dass er nicht ungewollt beschleunigen darf. Bei Automatikfahrzeugen wird z. B. in der Fahrt die Leistungsabgabe des Motors abgeregelt, wenn das Bremspedal länger als 5 Sekunden betätigt wird. 14 Als anspruchsvolles Softwareprojekt wird hier allgemein ein Softwareentwicklungsprojekt mit einem Budget von mehr als 1 Mio. € verstanden, wobei es auch auf den konkreten Einzelfall ankommt. 15 Vgl, Gumm, Sommer (2010): „Einführung in die Informatik“ Kapitel 12.1 Herausforderungen an die Softwareentwicklung, S. 828 ff
  16. 16. EVM in der technischen Software-Entwicklung 5 2.3 Änderungen sind unvermeidlich Eine weise Person soll angeblich mal gesagt haben: “Es gibt drei Gewissheiten im Leben: die Steuern, der Tod und dass Projekte ihre Zielsetzung ändern.“16 Nachdem die Projekt-Baseline und die Anforderungen mühsam durch den Projektleiter mit allen Stakeholdern abgestimmt wurden, ist es immer frustrierend zu sehen, dass kaum wenn das Projekt gestartet wurde, schon die Änderungen anfangen. Bei SW-Projekten wird in der agilen Entwicklung aus Änderungen schon fast eine Tugend gemacht. Aber warum sind Änderungen so unvermeidlich? i. Software ist komplex ii. Software ist abstrakt iii. Anforderungen sind unvollständig iv. Technologie ändert sich rasant vi.Technologie ist ein riesengroßer Bereich vii. Unvollständige Kennt- nisse in der Technologie v. „Best Practice“ sind nicht selbstverständlich ix. Die wiederkehrende Arbeit wird automatisiert viii. Software Entwicklung ist eigentlich Forschung x. Konstruktion ist tatsächlich Entwurf xi. Änderungen werden als einfach angesehen xii. Änderungen sind unvermeidlich Abb. 1: Spezifische Eigenschaften für eine Software Entwicklung Quelle: Eigene Darstellung in enger Anlehnung an die Kapitelstruktur von Stepanek Andere Projekte außerhalb der Softwareentwicklung weisen nur wenige oder keine dieser Eigenschaften17 auf, die Herr Stepanek detailliert in seinem Buch „Why Software Projects fails...“ untersucht. Die zwölf Kapitel in seinem Buch entsprechen in der obigen Abbil- dung den Kästchen. In der folgenden Analyse werden insbesondere die folgenden Ergebnisse benutzt:  Die Anforderungen (iii in der obigen Abb. 1) sind unvollständig. Bis zu 40 % der Anfor- derungen kommen erst ins Projekt nachdem die Entwicklung begonnen hat.18  Änderungen während der Projektzeit (xi in der obigen Abb. 1) werden als einfach ange- sehen.  Änderungen (xii in der obigen Abb. 1) sind als Folge in der Softwareentwicklung unver- meidlich. 16 Vgl, Fleming, Koppelman (2008): Earned Value Project Management, S. 107. 17 Vgl, Stepanek George (2013): Why Software Project Fails, Kapitel 2, S. 7..8 18 Vgl, Stepanek George (2013): Why Software Project Fails, Kapitel 2, S. 21
  17. 17. EVM in der technischen Software-Entwicklung 6 2.4 Kosten, Leistung und Zeit Ein Projekt bewegt sich in seiner Lebensdauer zwischen den drei Zielen Kosten, Leistung (Sachzielen) und Zeit (Termin). Diese drei Ziele beeinflussen sich gegenseitig und kön- nen deshalb in dem sogenannten „magischen Dreieck“ visualisiert werden. Kosten Zeit Magisches Dreieck LeistungEffektivität & Effizienz Rentabiltät Produktität Abb. 2: Das „magische Dreieck“ aus Zeit, Kosten und Leistung Zwischen Kosten, Leistungen und Zeit besteht ein Abhängigkeitsverhältnis19 , die Ände- rung eines Parameters wirken sich immer auch auf die beiden anderen Parameter aus. Wird z. B. der Fertigstellungstermin, also die Zeit verkürzt, muss die Produktivität durch überproportionalen Personaleinsatz (Überstunden) und dadurch mit insgesamt höheren Kosten gesteigert werden. Wenn die Kosten wiederum gesenkt werden sollen, muss der Umfang oder die Güte (Qualität) der Leistung reduziert werden. Eine reduzierte Güte wirkt sich auf die Effektivität und Effizienz des Projektes aus, wodurch es dann zeitlich länger dauert. Bei den meisten Projekten ist mindestens eine Spitze des Dreiecks sozusagen "festge- schrieben" und kann in dem Projekt nicht geändert werden. Bei technischen Projekten wird der funktionelle Leistungsumfang im Wesentlichen durch das umgebende System vorgegeben, bei einer Motorsteuerung kann bei der Regelung der Motorleistung kaum der Leistungsumfang reduziert werden. Die Qualität und eine Viel- zahl von Arbeitsprodukten wird durch zwingend anzuwendende Normen, wie z. B. die Sicherheitsnorm ISO 26262 „Road vehicles — Functional safety“ vorgegeben. 19 Vgl. Fischer, Möller, Schultze (): Controlling, Grundlagen, Instrumente und Entwicklungs-perspekti- ven, Kapitel 5.5 Kostenmanagement, S. 294 ff
  18. 18. EVM in der technischen Software-Entwicklung 7 Abb. 3: Anforderung an die SW für die Hardware Fehlerbehandlung Quelle: EN / ISO 26262-6:2011(E) auf Seite 5 In der obigen Tabelle der ISO 26262 wird festgelegt, welche Methoden für die Hardware- fehlerbehandlung, abhängig vom benötigten Automotive Safety Integrity Level (ASIL), anzuwenden sind. Da sich das benötigte Level „A“, .. , „D“ aus einer Gefährdungsanalyse ergibt, bleiben hier kein Freiheitsgrad bei den notwendigen Leistungen oder der Qualität. Der Termin „Start of Production“ (SOP) des umgebenden Systems determiniert auch den SOP-Termin des eingebetteten technischen Systems, welcher typischerweise einige Wo- chen vor dem Termin des umgebenden Systems liegt. Eine Verschiebung des SOP des umgebenden Systems hat ein Vielfaches an Folgekosten zur Folge, im Vergleich zu einer Steigerung der Produktivität in der Entwicklung, vgl. Abb. 1 auf Seite 5. Magisches Dreieck LeistungZeit Kosten Abb. 4: Das „magische Dreieck“; Kosten als intrinsischer Parameter Als Folge sind die Parameter Zeit (Fertigstellungstermin) und Leistung (Qualität) extrin- sische Parameter bei einer technischen (SW-) Entwicklung, damit also im Wesentlichen von außen fest vorgegeben. Damit ähneln technische Softwareprojekte strukturell dann Investitionsprojekten, wie etwa einen Brückenbau, bei dem der Leistungsumfang (die Brücke) früh stark determiniert ist und auch der Zeitpunkt in der Regel terminlich deter- miniert ist.20 20 Auch der Berliner Flughafen, der ursprünglich im Oktober 2011 starten sollte und dessen Fertigstel- lungstermin aktuell noch mit Ende 2017 angegeben wird, ist keine Ausnahme von dieser Regel. Die Nichteinhaltung des Termins hat zur Bezeichnung „Berliner Pannenflughafen“ geführt. Eine Kostenex- plosion bei Großprojekten wird jedoch in Allgemeinen leichter akzeptiert.
  19. 19. EVM in der technischen Software-Entwicklung 8 Der aktuelle Abgasskandal, das sogenannte Dieselgate, des Volkswagenkonzerns bestä- tigt eindrucksvoll diese Eigenschaft technischer Softwareprojekte.21 Der Versuch zu Las- ten der Qualität (also der zwingenden Anwendung von regulatorischen vorgegebenen Abgasnormen) die Stück- und Betriebskosten pro Fahrzeug durch Abschaltvorrichtungen („defeat devices“)22 zu sparen, wurde am Ende eindrucksvoll zu Lasten der Kosten gelöst. Die Entwicklungskosten eines neuen Motorsteuergerätes betragen grob geschätzt etwa 10 Millionen Euro. Die Rückstellung des Volkswagenkonzerns, aufgrund der Verfehlung von zwingenden Qualitätszielen (Einhaltung der Abgasnormen) betragen am 16. 04. 2016 vorläufig 16,2 Milliarden Euro23 , also mehr als das 1000-fache der Entwick- lungskosten. Insgesamt entsteht VW ein schwerer finanzieller Schaden und der Konzern erleidet ebenfalls einen hohen Reputationsverlust. 2.5 Konzepte des Earned Value Management Technische (Software-) Projekte im Sinne dieser Arbeit sind Projekte, bei denen im We- sentlichen nur die von zu erbringender geistiger Arbeit dominierten Kosten variabel sind. Die Aspekte Termin und Leistungsumfang sind extern fest vorgegeben und können vom Projektmanagement nicht wesentlich beeinflusst werden. Der Termin ist zu halten und die Funktionalität ist unter Beachtung der regulatorischen Anforderungen zu erbringen. Als internistische Regelgrößen bleiben damit „nur“ die Kosten als Regelparameter übrig. Daher ist es unter diesen Rahmenbedingungen naheliegend, ein Projektcontrolling aufzu- setzen, welches einerseits alle drei Dimensionen des magischen Dreiecks misst und die Abweichung darstellen und prognostizieren kann, gleichzeitig aber auch die Kosten als intrinsischen Parameter schätzen kann. Daher wird im Folgenden die Earned Value Ma- nagement (EVM) nicht nur als Instrument des Kostencontrollings eines Projekts verstan- den, sondern auch als Instrument des gesamten Projektcontrollings. Abb. 5: Earned Value Management, hier Kostenanalyse Die wesentliche Information zum Kostencontrolling mit der EVA bildet die Gegenüber- stellung der für die Fertigstellung von AP tatsächlich benötigten Ist-Kosten, im obigen Vgl. Zeit-Online (26.05.2016): Eröffnung verzögert sich wohl erneut 21 Vgl. Zeit-Online (10.06.2016): Der Abgasskandal 22 Vlg. EPA (19.09.2015): California Notify Volkswagen of Clean Air Act Violations 23 Vgl. Zeit-Online (10.06.2016): VW macht größten Verlust der Firmengeschichte
  20. 20. EVM in der technischen Software-Entwicklung 9 Bild als (AC) bezeichnet, mit den Kosten, wie sie zur Bearbeitung der Arbeitspakete ur- sprünglich geplant waren (BCWS). Die obere Abb. zeigt einen realen Projektablauf über 36 Wochen mit der typischen abgeflachten S-Kurve24 von Entwicklungsprojekte mit fes- tem Enddatum. Die geplanten und noch nicht abgearbeiteten Arbeitspakete sind am Anfang im Projekt- plan (PPC), in der oberen Abb. grün gezeichnet, enthalten. Hier sind das am Anfang 325 k€. Im Laufe der Zeit werden Arbeitspakete des Projektplans abgearbeitet und die erledigten Arbeitspakete werden aus dem grünen Feld (PPC) in das blaue Feld überführt und mit den tatsächlichen Kosten (AC) bewertet. Die Summe aus den bearbeiteten AP im blauen Bereich und den nicht bearbeiteten AP im grünen Bereich ist daher eine Schätzung für die Kosten am Projektende, in weiteren als Estimate at Completion (EAC) bezeichnet. Der aktuelle Kostenstand im Projekt kann an Earned Value, auch als Budget Cost for Work Scheduled (BCWS) bezeichnet, abgelesen werden. Hier werden die aktuell abge- arbeiteten oder teilweise abgearbeiteten Arbeitspakete mit ihren Plankosten bewertet. Liegt der „Earned Value“ BCWS oberhalb der aktuellen Kosten AC, liegt das Projekt vor seinem Kostenplan, im anderen Fall unterhalb seines Kostenplans. Die EVA kann entsprechende Aussagen für alle drei Elemente des magischen Dreiecks - Kosten, Zeit und Leistung- generieren. Da bei technischen SW-Projekten jedoch die Leis- tung und Zeit externe Parameter des Projektes sind, ist der verbleibende, intrinsische Pa- rameter Kosten der Aussagekräftigste zur Beurteilung des Projektverlaufes. In der Abb. 5 oben, die eine typische S-Kurve zeigt, sieht man ein kostentechnisch gut abgelaufenes Projekt: ab der KW 13 liegt der Earned Value immer oberhalb der aktuellen ausgegebenen Kosten (sunk cost). Am Ende, in der KW 36, entspricht der Earned Value dem initialen Projektbudget. Die tatsächlich verbrauchten Kosten (AC) liegen aber unter- halb des Earned Values (BCWS). Der Knick in der Kalenderwoche 17 resultiert aus einer erfolgten Neubewertung der erledigten Arbeitspakete. Die korrekte Bewertung des Abarbeitungsgrades von AP ist unabdingbare Voraussetzung für eine sinnvolle Verwendung des EVM für das Projektcontrolling. Dies gilt insbeson- dere in der SW-Entwicklung, in der Softwareentwickler bei der Bedeutung von „Fast Fer- tig“ stark zu Optimismus tendieren. Beim Schätzen des Restaufwandes nach 50 % der letztlich gebrauchten Zeit glauben Softwareentwickler häufig, dass sie bereits 90 % der Arbeitsergebnisse erreicht haben. Das liegt daran, dass dann der Lösungsweg bekannt ist, die Schwierigkeiten beim Umsetzen aber noch nicht gesehen werden. Insofern ist ein ge- wisser Reifegrad25 in der SW-Entwicklung und beim systematischen Testen notwendig. Die zu erzielenden Ergebnisse müssen geplant, systematisch nachverfolgt werden und die notwendigen Informationen für eine Earned Value Analyse (EVA) zur Verfügung stellen. 24 Vgl. Knott John (2013): The forgotten Art of Grapical Earned Value Management 25 Nach Meinung des Autors ist hierzu mindestens ein Reifegrad, entsprechend Automotive Spice Level 2 „Managed Process“ (ISO 15504), notwendig. Hier wird alles in dem Projekt systematisch geplant und nachverfolgt.
  21. 21. Theoretischer Hintergrund und Forschungsstand 10 3 Theoretischer Hintergrund und Forschungs- stand Zur Durchführung des Earned Value Management werden Methoden und Verfahren be- nötigt, die hier in den für diese Arbeit notwendigen Umfang eingeführt werden. 3.1 PRINCE2™ (Projects in Controlled Environments) Als allgemeine Projektmanagement-Methode wurde PRINCE2™ 1996 vom Office of Government Commerce (OGC) veröffentlicht. Neben PMBOK, Scrum und ICB26 zählt PRINCE2™ zu den weltweit führenden Projektmanagementmethoden. PRINCE2™ wird zunehmend populärer und entwickelte sich zum De-facto-Standard für Projektmanage- ment in Großbritannien. Die zentrale Projektdefinition von PRINCE2™ ist: „Ein Projekt ist eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wurde, ein oder mehrere Produkte in Übereinstimmung mit einem vereinbarten Business Case zu liefern.“27 . Hier werden im Vergleich zu anderen Projektmanagementmethoden, der Business Case und die Produkte in den Vordergrund gerückt. PRINCE2™ enthält nur wenige Techni- ken, welche mit der Ausnahme der produktbasierten Planung optional sind. Produktbasierte Planung Eine Produktbeschreibung ist eine Spezifikation des zu erstellenden Produktes, welche auch die zu erfüllenden Qualitäts- und Abnahmekriterien enthält. PRINCE2™ empfiehlt die produktbasierte Planung aus zwei wesentlichen Gründen:  Ein Projekt liefert Produkte, nicht Aktivitäten. Aktivitäten sind dazu da, Produkte zu schaffen.  Die Qualität eines Produkts können wir messen. Die Qualität einer Aktivität kann nur an der Qualität ihres Ergebnisses (dem Produkt) gemessen werden.28 Eine produktbasierte Planung, die auch analog bei Scrum mit der Definition of Done er- folgt, liefert für ein EVM viele Vorteile. Der Fertigstellungsgrad eines Produktes in der geforderten Qualität ist gut messbar. Die zuverlässige Errechnung eines Fertigstellungs- grades eines Produktes ist für die Berechnung des Earned Values bei der EVA eine not- wendige Voraussetzung. Business Case PRINCE2™ legt Wert auf den vereinbarten und dokumentierten Business Case des Pro- jektes. Der Business Case kann finanzieller Natur (zusätzliche Erträge oder vermiedene Kosten), strategischer Art (z. B, Entwicklung einer neuen Plattform) oder regulatorischer Art (z. B. die Einhaltung von Abgasnormen) sein. 26 ICB ist die Abkürzung für den Projektmanagement-Standard International Project Management Associ- ation Competence Baseline 27 Zitiert nach OGC (2009) S. 3 28 Zitiert nach Ebel (2011) Prince2:2009TM – für Projektmanagement mit Methode aus Kapitel „Produkt- basierte Planung/Productbase planning“ S. 174
  22. 22. Theoretischer Hintergrund und Forschungsstand 11 Die sieben Elemente des Business Case von PRINCE2™ sind29  Wirtschaftliche Gründe: Warum wird das Projektergebnis benötigt?  Optionen: Mögliche Projektalternativen werden aufgezeigt. Diese müssen genau be- leuchtet und die aktuelle Entscheidung entsprechend begründet werden.  Erwarteter Nutzen: Darstellung von erwarteten Erträgen und erzielbarem Mehrwert, der messbar sein muss. Diesen Nutzen muss der Auftraggeber beschreiben.  Risiken: Beschreibung der wichtigsten Risiken und deren Auswirkungen auf den Pro- jektverlauf.  Zeit und Kostenrahmen: Grobe Schätzung über die Höhe der Kosten, Anlaufzeitpunkt und Projektdauer.  Investitionsantrag: Zeigt das Gleichgewicht zwischen Entwicklungs-, Betriebs-, War- tungs- und Supportkosten gegenüber dem finanziellen Wert der Projektergebnisse über die Zeit auf. Da bei technischen SW-Projekten nur die Kosten ein intrinsischer Parameter30 des Pro- jektes sind, muss bei PRINCE2™ bei Phasenübergängen (Milestone) oder bei Abwei- chungen außerhalb der Toleranz geprüft werden, ob der Business Case noch erfüllbar ist und ein möglicher Abbruch des Projektes als Alternative in Betracht gezogen werden. Projektmanagement und Lenkungsausschuss Bei PRINCE2TM erhält der Projektleiter vom Projektlenkungsausschuss grundsätzlich ein Toleranzband für die Parameter Kosten, Leistung und Termin basierend auf dem Busi- nessplan. Innerhalb dieser Toleranzgrenzen ist der Projektleiter für die Koordination der täglichen Arbeit selber verantwortlich. Abb. 6: Earned Value Management, mit Kostengrenze In der obigen Abb. wird in der KW 23 die vereinbarte Kostengrenze, hier dargestellt als rote Linie, überschritten. Der Projektleiter wird das Seniormanagement (bei PRINCE2™ also den Lenkungsausschuss) mit Hilfe eines Ausnahmeberichtes (Exception Report) in- formieren. 29 Vgl. PRINCE2.COM: prince2-business-case-template 30 Vgl. Abb. 4: Das „magische Dreieck“; Kosten als intrinsischer Parameter auf S. 6
  23. 23. Theoretischer Hintergrund und Forschungsstand 12 Die drei Vertreter im Projektlenkungsausschuss31 bei PRINCE2™ sind:  Der Auftraggeber/Kunde erteilt den Auftrag für das Projekt, trägt die Kosten und pro- fitiert von den Ergebnissen.  Die Benutzer arbeiten mit den Ergebnissen des Projektes, nehmen das Ergebnis ab und sind vom Resultat positiv oder negativ betroffen.  Der Lieferant ist zuständig für den Mitarbeiter- und Materialeinsatz im Projekt und die Realisierung des Projektergebnisses. Dieser Projektlenkungsausschuss ist bei PRINCE2™ in letzter Instanz für das Projekt verantwortlich und kann weitere Maßnahmen veranlassen. In der Regel wird der Projekt- leiter einen Ausnahmeplan mit ihm abstimmen, um das Projekt fortführen zu können. Mit der Inkraftsetzung eines Exceptionplans32 wurde das obige Projekt in der KW 25 wie- der im vereinbarten Toleranzbereich geführt und kann dann planmäßig, entsprechend dem vereinbarten Exceptionplan, zu Ende geführt werden. Résumé Für das Earned Value Management ist hier wichtig, dass bei PRINCE2™ betriebswirt- schaftliche Überlegungen die Durchführung und die Weiterführung des Projektes steuern. Die Überprüfung des Business Case, als Reaktion auf Ausnahmeberichte des Projektlei- ters und bei Phasenübergen gehört zur regelmäßigen Aufgabe des Lenkungsausschusses. 3.2 Projektregelung / Projektcontrolling Eine effektive und effiziente Durchführung von Projekten bedingt einen Plan und ein Controlling, welches die Abweichungen von diesem Plan misst und die Information für das Projektmanagement zur Verfügung stellt. Das Projektmanagement kann dadurch kor- rigierend in den Ablauf des Projektes eingreifen. Da die Ergebnisse der Eingriffe der zeit- lich vorhergehenden Schritte wieder in das Projekt zurückgeflossen sind, ist es korrekter von einer Projektregelung und nicht von einer Projektsteuerung33 zu sprechen. Die Norm DIN IEC 60050-351 enthält eine Definition des Begriffs Regelung: „Die Regelung bzw. das Regeln ist ein Vorgang, bei dem fortlaufend eine Größe, die Regelgröße erfasst, mit einer anderen Größe, der Führungsgröße, verglichen und im Sinne einer Angleichung an die Führungsgröße beeinflusst wird.“ Lastenheft versus Pflichtenheft Der erste Plan, der vorliegt, ist der Business Case, dieser enthält neben den Zeit- und Kostenrahmen auch den erwarteten Nutzen. Der erwartete Nutzen wird vom Auftragge- ber/Kunde in einem Dokument als Anforderungen an das Projekt spezifiziert. Der Auf- traggeber beschreibt dabei detailliert alle seine Anforderungen in einem strukturierten Dokument und somit entsteht ein Anforderungskatalog oder auch Lastenheft. 31 Vgl. Triest (2009): PRINCE2 Gezielte Vorbereitung auf die Foundation und Practitioner-Prüfung, S. 28 32 Hier ist der Umfang der noch zu erbringenden Leistung verringert oder neu bewertet worden. 33 Bei einer Steuerung wird zwar das Verhalten des Systems beeinflusst, Rückwirkungen und Störungen beeinflussen die Steuerung selber jedoch nicht. Beispiel für eine Steuerung ist eine Zeitschaltuhr für eine Beleuchtung. Bei einer Regelung wird die Regelgröße wieder ins System zurückgeführt und be- einflusst das System selber. Beispiel für eine Regelung ist eine Heizung mit Thermostat.
  24. 24. Theoretischer Hintergrund und Forschungsstand 13 Der Auftragnehmer antwortet auf das Lastenheft mit einer Beschreibung, wie er sich vor- stellt, die Aufgabe konkret in dem Projekt umzusetzen. Dabei werden positive Ziele, was das Projekt am Ende erreicht haben wird und auch negative Ziele, was das Projekt nicht erreichen wird, systematisch schriftlich erfasst. Insbesondere wird hier der Liefergegen- stand34 als ein eindeutiges überprüfbares Produkt oder Ergebnis des Projektes festgehal- ten. Die Liste aller Lösungsspezifikationen wird als Pflichtenheft bezeichnet und bildet bei der Abnahme durch den Auftraggeber/Kunden am Ende das Maß für die Ermittlung des Erfüllungsgrades des Projektes. Die Unterteilung zwischen Lasten- und Pflichtenheft ist je nach Art des Projektes und der Beziehung Auftraggeber/Auftragnehmer unterschiedlich. Entscheidend ist jedoch, dass als Ergebnis die dokumentierten Anforderungen (die Requirements) eindeutig, wider- spruchsfrei, vollständig und testbar sind, um dadurch auch einen Erfüllungsgrad der An- forderungen ermitteln zu können. Da Änderungen an den Requirements unvermeidlich sind35 , ist es bei technischen Syste- men wichtig, eine Vor- und Rückwärtsverfolgung der Anforderungen über den gesamten Entwicklungsprozess sicherzustellen. Damit kann der Einfluss von Änderungen im Pro- jekt erkannt und kontrolliert eingesteuert werden. Ein wirksames EVM muss für die Be- wertung von Änderungen auf die Pläne und auf die Kennzahlen des Requirement Engineering zurückgreifen. 3.3 Projektstrukturplan Nachdem die Anforderungen an das Projektergebnis festgelegt wurden, wird der Projekt- umfang in plan-, mess- und kontrollierbare Teilaufgaben unterteilt und daraus der Pro- jektstrukturplan (PSP) als Herzstück eines jeden Projektes entwickelt. Angaben36 zu Kosten, Terminen, Qualität und Beschaffung basieren auf den in den PSP dokumentierten Anforderungen. Für die Erstellung und Pflege des PSP ist die Projektleitung verantwort- lich. Diese bindet dafür sinnvollerweise das gesamte Team ein, um die Erfahrung und das Know-how aller Beteiligten bei der Erstellung des PSP zu nutzen. Je feiner die Unterteilung in Arbeitspakete im PSP durchgeführt wurde, desto detaillierter sind später Aussagen über den aktuellen Projektstatus möglich37 . Die untersten Gliede- rungsebenen des so erzeugten Projektstrukturplans bilden die Arbeitspakete, die einer be- stimmten Person, Funktion oder Organisationseinheit zugeordnet werden können und deren Abarbeitung in Projektverlauf überprüft wird. Diese Arbeitspakete können zum Zweck der Abschätzung noch weiter unterteilt werden. Wichtig ist, dass alle Projekter- gebnisse im PSP enthalten sind. Das gilt auch dann, wenn der Projektstrukturplan noch nicht bis auf die untere Gliederungsebene der Arbeitspakete durchgeplant wurde. Der Projektstrukturplan (PSP) wird im Englischen als Work Breakdown Structure (WBS) bezeichnet. Er ist eine zwingende Voraussetzung38 für eine Anwendung der EVA39 , die 34 Vgl. PMBOK (2011): A Guide to the Project Management Body of Knowledge, S. 122 35 Vgl. Kapitel 2.3 Änderungen sind unvermeidlich, S. 2 36 Vgl. PMBOK (2011): A Guide to the Project Management Body of Knowledge, S 111 erster Absatz 37 Vgl. PMH: Projektmanagementhandbuch 38 Vgl. Riederich Timo (2007): Die Bedeutung der Earned Value Methode für die Steuerung von Produkt- entwicklungsprojekten, S. 121-124 39 Vgl. Flemming Kopplemann (2010): Earned Value Project Management, S. 58
  25. 25. Theoretischer Hintergrund und Forschungsstand 14 den Abarbeitungsgrad genau dieser Arbeitspakete misst. Bei der Erstellung des Projekt- strukturplans erhalten die einzelnen Elemente für die Projektlebensdauer eindeutige Be- zeichner40 , um Elemente über die Lebensdauer eindeutig identifizieren zu können. Es gibt die folgenden prinzipiellen Arten eines PSP, die häufig auch in Mischformen in Projekten auftauchen. Funktionsorientierte Gliederung Bei einem funktionsorientierte PSP erfolgt die Unterteilung der Aufgaben analog der Li- nienorganisation des Unternehmens. Abb. 7: PSP mit funktionsorientierter Gliederung Vorteile:  Die Berichtsstruktur entspricht der gewohnten organisatorischen und disziplinarischen Unterstellung und ist daher leicht von den Mitarbeitern nachvollziehbar.  Die Unterstrukturen entsprechen den entsprechenden Kompetenz- und Ressourcenbe- darf. Im obigen Beispiel ist der Anteil der Arbeitspakete von „2.1 Bootloader“, „2.2 Firmware“ und „2.3 Applikation“ aus den Teilbäumen leicht sichtbar.  Da Controlling-Informationen normalerweise entlang der Linie gesammelt werden, gibt es häufig auch historische Informationen aus analogen Projekten in der Organisation. Nachteile:  Bei länger laufenden Projekten kann sich, als Folge einer Umorganisation der Organisa- tionsstruktur, der Vorteil der gewohnten Linienorganisation auch in einen Nachteil wan- deln, wenn die Organisationsstruktur des Projektes dann nur noch die historische Linien- struktur widerspiegelt.  Abhängigkeiten von Arbeitsergebnissen, wie das „1.1 Layout“, welches die Bauteile auf der Leiterbahn platziert, von „3.1 Housing“, welches das umschließende Gehäuse und damit den zur Verfügung stehenden Bauraum der Bauteile definiert, werden nur auf der höchsten Projektebene zusammengeführt. Die Teilprojekte „1 Elektronik“ und „3 Me- chanik“ könnten fertig melden, obwohl die bestückte Leiterkarte eventuell nicht ins Ge- häuse passt. 40 Die einfachste Art ist die Elemente auf einer Hierarchieebene horizontal durchzunummerieren und diese Nummerierung pro vertikaler Ebene um eine Stelle zu erweitern, entsprechend der Gliederungsstruktur eines Buches. Wegfallende Elemente dürfen nicht neu vergeben werden. Im PMBOK (2011): A Guide to the Project Management Body of Knowledge wird das auf S. 132 als Projektstrukturcode bezeichnet. Projekt ECU 2. Software 1. Elektronik 3. Mechanik 2.1 Bootloader 2.2. Firmware 2.3 Applikation 1.1 Layout 3.1 Housing
  26. 26. Theoretischer Hintergrund und Forschungsstand 15 => Bei komplizierten Abhängigkeiten zwischen den Arbeitspaketen sowie bei länger laufenden Projekten ist ein funktionsorientierter PSP auf der 1. Ebene nicht wirk- lich sinnvoll und eher unüblich. Phasenorientierte Gliederung Bei Entwicklungsprojekten, bei denen explizit verschiedene Phasen durchlaufen werden, wird häufig der PSP nach diesen für die Fertigstellung des Endproduktes notwendigen Phasen gegliedert. Innerhalb der einzelnen Phasen selber kann dann wieder funktionsori- entiert oder objektorientiert untergliedert werden. Projekt ECU 2. System- gestaltung 1. Software- Spezifikation 3. Modul- gestaltung 4. Codierung 5. Modultest 6. Integrations- test 7. Validierung Abb. 8: PSP mit phasenorientierter Gliederung Vorteile:  Die einzelnen Phasen werden so übersichtlich dargestellt. Dies entspricht dem Vorgangs- modell „Wasserfall“.  Das Erreichen von Meilensteinen kann einfach in Reports dargestellt werden.  Die Verteilung der Aufwände auf die Phasen ist bei ähnlichen Projekten in gleichen Un- ternehmen ziemlich gleich. Größere Fehler in der Abschätzung der Unterelemente der Phasen können durch den Vergleich mit Altprojekten gut aufgedeckt werden.  Die Unterstrukturen der ersten Gliederungsebenen sind bei ähnlichen Projekte weitge- hend identisch und können in Form eines Template für verschiedene Projekte zur Verfü- gung gestellt werden. Nachteile:  Die Abhängigkeiten von Arbeitsergebnissen zum Erreichen von Funktionen werden nur am Ende der Phase sichergestellt.  Liegen nicht alle Arbeitsergebnisse der einen Phase vor, darf theoretisch nicht mit der nächsten Phase begonnen werden. Der kritische Pfad liegt also immer auf der Fertigstel- lung des letzten AP dieser Phase und stellt ein großes zeitliches Risiko dar.  In der Praxis wird aus Termingründen daher schon an AP von noch folgenden Phasen gearbeitet, um hier große zeitliche Verzögerungen im Projekt zu vermeiden. Dies führt dazu, dass sich das Projekt gleichzeitig in verschiedenen Phasen des Modells befindet, was den zugrundeliegenden Annahmen des Modells selbst widerspricht. Damit werden unterschiedliche Anforderungen an den Reifegrad der gleichen Projektdokumente aus den verschiedenen, parallel laufenden Phasen gestellt. Dies führt zu Zielkonflikten, die zusätzlich vom Projektmanagement aufgelöst werden müssen.  Nach dem Erfüllungsgrad bewertbare Arbeitsergebnisse liegen erst sehr spät im Projekt vor und maximieren eher die Schadenshöhe von Spezifikationsfehlern. => Bei größeren Projekten ist der Erfüllungsgrad bei gleichzeitig ablaufenden Phasen nur schwer zu messen.
  27. 27. Theoretischer Hintergrund und Forschungsstand 16 Objektorientierte Gliederung / Gliederung nach dem Liefergegenstand Bei der objektorientierten Gliederung steht das erzeugte Produkt im Zentrum der Betrach- tung. Das Produkt wird dabei in kleinere Teilprodukte unterteilt. Das PMBOK empfiehlt ausschließlich die Projektstrukturierung nach Liefergegenstand41 . Projekt ECU 2. Onboard Diagnose fertiggestellt 1. CE- Kennzeichen 3. Applikation 2.1. Protocolstack implementiert 2.2 FMEDA validiert 2.3 Diagnostic Coverage verifiziert Abb. 9: PSP mit objektorientierter Gliederung Vorteile:  Nach dem Erfüllungsgrad bewertbare, konkrete Arbeitsergebnisse liegen relativ früh im Projektablauf vor und reduzieren damit die Schadenshöhe von möglichen unbemerkten Spezifikationsfehlern.  Einzelne Teilprodukte/Funktionalitäten können, wenn sie nicht mehr umgesetzt werden sollen relativ leicht aus den PSP entfernt werden. Es bleibt trotzdem ein benutzbares Rest- projekt42 übrig.  Die Vorgehensweise ist analog zu Scrum, welches auf liefer- und verifizierbare Teilpro- dukte mit Akzeptanzkriterien in „Definition of Done“ abzielt. Nachteile:  Die Aufteilung nach Teilprodukten ist relativ kompliziert. Bei jedem Teilprodukt müssen für alle beteiligte Funktionen der jeweils zu erzeugende Anteil bestimmt werden. => Bei größeren, länger laufenden oder agilen, produktorientierten Projekten ist die objektorientierte Gliederung am effizientesten. Résumé Der Projektstrukturplan ist eine notwendige Grundvoraussetzung für die Anwendung von EVA43 , welches die Projektperformance vom Projektstart bis zum Projektende misst. Än- derungen an dem Projektumfang (Change Request) müssen zunächst in den PSP einge- pflegt werden, um damit die weiteren abgeleiteten Projektpläne anzupassen zu können. 41 Vgl. PMBOK: A Guide to the Project Management Body of Knowledge, S.127 ff 42 Vlg. Flemming und Koppelmann (2011): Earned Value Project Management, S. 61 „We never overun our project cost .. all unfinished work gets moved into next year’s projects.” Diese Option steht aller- dings für unsere technischen Projekte, nur sehr eingeschränkt zur Verfügung. 43 Vgl. Riederich Timo (2007): Die Bedeutung der Earned Value Methode für die Steuerung von Produkt- entwicklungsprojekten, S. 121-122.
  28. 28. Theoretischer Hintergrund und Forschungsstand 17 3.4 Aufwandsabschätzung Für die Ermittlung des Aufwandes der Arbeitspakete, die aus den erstellten PSP folgen, gibt es eine Vielzahl an Methoden44 : Fachurteil, analoge Schätzung, parametrische Schät- zung, Top-Down und Bottom-Up-Schätzung und viele andere mehr. Egal welche Ab- schätzungsmethode am Ende angewendet wird, sämtliche Prognosen über den Aufwand enthalten immer eine deutliche Unsicherheit.45 Softwareentwicklung ist eigentlich For- schung und deshalb ein riskantes Vorhaben, welches von Unsicherheiten geprägt ist46 , mit denen das Projektmanagement umgehen muss. Hier wird die Mehrpunktabschätzung als bevorzugte Methode für das EVM vorgestellt, weil diese neben einem Schätzwert für die Vorgangskosten auch noch ein Toleranzfeld für die Unsicherheit der Schätzung selber liefert. Die so ermittelte Unsicherheit wird in den weiteren Planungen als Vorgangsrisikoreserve für die Kosten und die benötigte Zeit benutzt. Prinzipiell sind aber alle Schätzverfahren für das EVM anwendbar, welche AP konkrete Kosten zuweisen können. Warum ist die Abschätzung des Aufwandes so schwierig? Ein brauchbares Ergebnis der Aufwandsabschätzung ist sehr wichtig, da auf der Basis dieser Aufwandsabschätzung der Businesscase kalkuliert und der Fertigstellungstermin des Projektes festgelegt wird. Von der Qualität dieser Aufwandsabschätzung hängt ab, ob das Projekt mit der abgegebenen Kosten- und Terminaussage gestartet wird. Zu hohe Kosten und/oder ein späterer Fertigstellungstermin können eine Beauftragung verhin- dern. Nach der Beauftragung hängen wiederum dann von dieser Aufwandsabschätzung der finanzielle Erfolg und die termingerechte Fertigstellung des Projekts ab. Das grundlegende Problem mit der Abschätzung des Aufwands von AP wird an einer einfachen allgemeinen Frage an einen erfahrenen Autofahrer, der in diesem Beispiel als Experte auftritt, erläutert. Die Frage lautet: Wie lange dauert morgen die Fahrt von Lindau nach Konstanz? Für diese inhaltlich relativ gut definierte Aufgabe gibt es zudem mit einem Routenplan eine gute objektive Datenbasis. Der Autofahrer ist diese Strecke schon häufiger gefahren und verfügt damit über entsprechende Erfahrung in der Umsetzung dieser Aufgabe. 44 PMBOK (2011): A Guide to the Project Management Body of Knowledge, in Kapitel 7.2.2 Kosten schätzen: Werkzeuge und Methode von S. 203 bis 205 45 Bei SW-Projekten die einen Reifegrad ab CMMI Level 2 „Managed“ wird eine Unschärfe der Abschät- zung von 20 % bis 25 % üblicherweise akzeptiert. Bei geringerem Reifegrad ist der Entwicklungspro- zess nur schwer vorherzusagen und der Zufall hat einen hohen Einfluss auf das erzielte Ergebnis. 46 Vgl. DeMarco und Lister 2003: Bärentango, S. 51
  29. 29. Theoretischer Hintergrund und Forschungsstand 18 Abb. 10: Routenplan von Lindau nach Konstanz Quelle: Google Maps Der Routenplan bietet drei unabhängige Möglichkeiten zur Realisierung der Aufgabe mit einer Zeitschätzung von jeweils etwas über 90 Minuten: 1. „über die Schweiz“, 2. „um den Überlingersee herum“ und 3. „mit der Fähre von Meersburg nach Konstanz“. Die Antwort des erfahrenen Autofahrers - als Experte - auf diese Frage ist detailliert: „Ca. 120 Minuten, aber manchmal schaffe ich es auch in 90 Minuten. Wissen Sie, ich versuche die Hauptverkehrszeiten zu vermeiden. In letzter Zeit bei den vielen Baustellen, da kann es auch schon mal gut 3 ½ Stunden dauern, wenn ich die Fähre nicht erwische. Wenn ich einen wichtigen Termin habe, dann plane ich mindes- tens 2 ½ Stunden ein.“ Die Frage wurde von dem Experten sorgfältig beantwortet und enthält dazu noch viele zusätzliche Informationen. Die Antwort hat nicht nur den wahrscheinlichsten Wert von 120 Minuten geliefert, sondern auch eine Spanne für die benötigte Fahrzeit genannt. Wenn alles gutgeht, braucht er 90 Minuten (als optimistischer Wert) und bei ungünstigen Rahmenbedingungen jedoch bis zu 210 Minuten (als pessimistischer Wert). Er erwartet jedoch mit einiger Sicherheit die Aufgabe in 180 Minuten erledigen zu können. In der Schätzung sind noch weitere Annahmen enthalten, wie z. B. die 90-Minuten Fahr- zeit sind nur möglich, wenn die Hauptverkehrszeiten gemieden werden können. In dem wahrscheinlichen Wert von 120 Minuten ist ein Risiko enthalten. Häufig kann man in 120 Minuten von Lindau nach Konstanz fahren. Wenn ein wichtiges Meeting an- gesetzt ist, dann geht der Autofahrer jedoch dieses Risiko nicht ein, sondern kalkuliert eine längere Fahrtdauer ein.
  30. 30. Theoretischer Hintergrund und Forschungsstand 19 Modellierung mit einer asymmetrischen Wahrscheinlich- keitsdichtefunktion Tom DeMarco hat Timothy Lister in seinem Buch Bärentango gezeigt, dass Schätzungen der Bearbeitungsdauer einer asymmetrischen Wahrscheinlichkeitsdichtefunktion unter- liegen. Das heißt, dass die Wahrscheinlichkeit, dass pessimistische Werte auftreten, deut- lich höher ist als die bei optimistischen Werten. Gleichzeitig hat Tom DeMarco die Idee aufgebracht, dass sich die absolute Fertigstellungswahrscheinlichkeit durch die Integra- tion der Fläche unter der Kurve berechnen lässt. Abb. 11: Wahrscheinlichkeitsdichtefunktion einer Schätzung Quelle: https://de.wikipedia.org/wiki/Drei-Zeiten-Methode Die drei Punkte optimistisch, realistisch und pessimistisch in der obigen Abb. spannen eine Wahrscheinlichkeitsdichtefunktion auf. Dass alles glatt läuft, ist genauso wahr- scheinlich, wie dass alles schief läuft - sprich relativ unwahrscheinlich mit 0 % relativer Wahrscheinlichkeit. Am wahrscheinlichsten ist der realistische Wert - wobei niemand genau sagen kann wie wahrscheinlich. Die Fläche unter der Kurve vom optimistischen Wert zu einem Wert (W) bezogen auf die Gesamtfläche ist die absolute Wahrscheinlichkeit. Beim optimistischen Wert liegt sie nahe 0 %, beim pessimistischen Wert nahe 100 %.47 Bei einer sinnvollen Schätzung des Erwartungswertes, liegt die Wahrscheinlichkeit für einen unterschätzten Aufwand ge- nauso hoch wie für einen überschätzten Aufwand und damit bei 50 %. Die Funktionsweise der Abschätzung ist in der Praxis ganz einfach. Geschätzt werden drei Werte für den Aufwand, welcher ein eingearbeiteter, durchschnittlicher Entwickler mit zwei Jahren Erfahrung zur Bearbeitung des Arbeitspaketes benötigt: optimistisch (Min) - Eine Schätzung, welcher Aufwand anfällt, wenn alles gut läuft. realistisch (Modus) - Eine Schätzung, welcher Aufwand am wahrscheinlichsten ein- trifft, also die Arbeit mit gewohntem Tempo abgearbeitet wird. pessimistisch (Max) - Eine Schätzung, welcher Aufwand anfällt, wenn dauernd Prob- leme auftreten. 47 Vgl. Müller (2016): „Speed4Projects“ -> 3-Punkt-Schätzung mit Wahrscheinlichkeit
  31. 31. Theoretischer Hintergrund und Forschungsstand 20 Bei der optimistischen Schätzung ist klar, dass es aufgrund der regulatorischen Anforde- rungen (hier die Straßenverkehrsordnung) eine untere Grenze gibt, die nicht unterschrit- ten werden darf. In die realistische Schätzung gehen die Erfahrungen des Experten ein, welche in der Vergangenheit mit ähnlichen Aufgaben gesammelt wurden. Bei der pessi- mistischen Schätzung muss man aufpassen, nicht in unrealistische Werte zu verfallen. Staus, Unfälle, Urlaubsverkehr sind sicher mögliche Ereignisse. Doch selbst der Ausfall einer Route, wie z. B. durch die Einstellung des Fährbetriebs, bietet Ausweichmöglich- keiten auf andere Strecken und wenn das Auto streikt, gibt es andere Alternativen z. B. in Form eines Mietwagens. Der Autofahrer kann bei schwerwiegenden Problemen mit der Bahn oder dem Schiff reisen und benötigt dafür ebenfalls ca. 3 ½ Stunden. Die Ver- fügbarkeit von Lösungsalternativen ist ein guter Indikator für eine obere Grenze. Globale externe Ereignisse, wie ein Hochwasser das sowohl den Bahnhof wie auch die Uferstraßen überschwemmt, sind nicht Teil der Aufwandsabschätzung, sondern gehören ins Risikomanagement. Dort kann analysiert werden, dass hierfür ein 30-jähriges Hoch- wasser notwendig ist, mithin die Wahrscheinlichkeit also 1/10.000 beträgt und dann eine Verzögerung von 1 Woche als Risikohöhe entsteht. Dreiecksverteilung Die einfachste Form einer asymmetrischen Wahrscheinlichkeitsdichtefunktion ist die Dreiecksverteilung. Sie wird gerne angewendet, wenn von einer Grundgesamtheit nur wenige Stichproben vorliegen und aus diesem Grund häufig dafür angewendet, um Ge- schäftsrisiken, wie hier auch die Abarbeitung von AP, zu modulieren. Die Dreiecksver- teilung bevorzugt den wahrscheinlichsten Wert. Abb. 12: Dreiecksfunktion, Dichte und Verteilungsfunktion Quelle: WikiCC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=182090 Die Dichtefunktion einer Dreiecksverteilung ist wie folgt definiert:48 𝒇( 𝒙) = { 𝟐(𝒙−𝒂) (𝒃−𝒂)(𝒄−𝒂) ; 𝒘𝒆𝒏𝒏 𝒂 ≤ 𝒙 < 𝒄 𝟐 𝒃−𝒂 ; 𝒘𝒆𝒏𝒏 𝒙 = 𝒄 𝟏 − 𝟐(𝒃−𝒙) (𝒃−𝒂)(𝒃−𝒄) ; 𝒘𝒆𝒏𝒏 𝒄 < 𝒙 ≤ 𝒃 (1) 48 Vgl. Wikipedia Dreiecksverteilung
  32. 32. Theoretischer Hintergrund und Forschungsstand 21 Durch Integration ergibt sich daraus die Verteilungsfunktion wie folgt: 𝑭( 𝒙) = { (𝒙−𝒂) 𝟐 (𝒃−𝒂)(𝒄−𝒂) ; 𝒘𝒆𝒏𝒏 𝒂 ≤ 𝒙 < 𝒄 𝒄−𝒂 (𝒃−𝒂) ; 𝒘𝒆𝒏𝒏 𝒙 = 𝒄 𝟏 − (𝒃−𝒙) 𝟐 (𝒃−𝒂)(𝒃−𝒄) ; 𝒘𝒆𝒏𝒏 𝒄 < 𝒙 ≤ 𝒃 (2) Der Parameter a ist der minimale Wert, b der maximale Wert und c der wahrscheinlichste Wert. Bei einer dreiecksverteilten Zufallsvariable X ergeben sich damit der Erwartungs- wert E(X) und die Varianz 𝝈 𝟐 (X) wie folgt: 𝑬( 𝑿) = 𝒂+𝒃+𝒄 𝟑 (3) 𝝈 𝟐( 𝑿) = (𝒂−𝒃) 𝟐+(𝒃−𝒄) 𝟐+(𝒂−𝒄) 𝟐 𝟑𝟔 (4) Der Modus oder Modalwert einer stetigen Zufallsvariable X ist ein Wert XModus, der für alle x∊ℝ gilt: f(XModus) ≥ f(X) (5) Der Modus, also die Maximalstelle der Dichtefunktion, XModus ist hier: 𝑿 𝑴𝒐𝒅𝒖𝒔 = 𝒄 (6) Beta-Verteilung Die Betaverteilung auf [a,..,b] ist eine kontinuierliche Wahrscheinlichkeitsverteilung über dem Intervall [a,..,b]. Außerhalb des Intervalls [a,..,b] wird sie durch f(x)=0 definiert. Sie wird zur Beschreibung von stetigen Zufallsgrößen verwendet, wenn keine ausreichenden Daten vorhanden sind. Die Dichtefunktion einer allgemeinen Betafunktion wird mit dem Parameter a als mini- malem Wert bzw. b als maximalem Wert mit a<b und α, β>0 mit dem Faktor 1 𝐵(𝑎, 𝑏, 𝑝, 𝑞)⁄ zu korrekten Normierung der Dichtefunktion wie folgt definiert:49 𝒇(𝒙)={ 𝟏 𝑩(𝒂,𝒃,𝜶,𝜷) (𝒙−𝒂) 𝜶−𝟏(𝒃−𝒙)ß−𝟏; 𝒂 <𝒙 <𝒃 𝒖𝒏𝒅 𝒂,𝜷> 𝟎 𝟎; 𝒔𝒐𝒏𝒔𝒕 𝒎𝒊𝒕 𝑩(𝒂,𝒃,𝜶,𝜷)= ∫ (𝒖−𝒂) 𝜶−𝟏(𝒃−𝒖) 𝜷−𝟏 𝒅𝒖 𝒃 𝒂 (7) Wird diese allgemeine Betafunktion mit dem Intervall [a,..,b] auf den Bereich [0,..,1] be- schränkt, ergibt sich die standardisierte Betaverteilung. Durch die Linear-Transformatio- nen 𝑎 + (𝑏 − 𝑎) ∗X (Skalierung und Verschiebung) einer [0,..,1] verteilten Zufallsvariablen X können alle Dichtefunktionen der allgemeinen Betaverteilungen auf dem Intervall [a,..,b] erzeugt werden. 49 Vgl. Wikipedia Betaverteilung
  33. 33. Theoretischer Hintergrund und Forschungsstand 22 Für die weiteren Analysen ist daher die standardisierte Betaverteilung ausreichend.50 𝒇(𝒙) = { 𝟏 𝑩(𝜶,𝜷) 𝒙 𝜶−𝟏(𝟏−𝒙)ß−𝟏; 𝟎 <𝒙 ≤𝟏 𝒖𝒏𝒅 𝒂,𝜷>𝟎 𝟎; 𝒔𝒐𝒏𝒔𝒕 𝒎𝒊𝒕 𝑩(𝜶,𝜷)= ∫ 𝒖 𝜶−𝟏(𝟏−𝒖) 𝜷−𝟏 𝒅𝒖 𝟏 𝟎 (8) Mit α, β >0, wobei der Faktor 1 𝐵(𝛼, 𝛽)⁄ wiederum der korrekten Normierung der Dich- tefunktion dient. Die Verteilungsfunktion ergibt sich damit als 𝑭(𝒙) = { 𝟎 ; 𝒇ü𝒓 𝒙 ≤ 𝟎, 𝟏 𝑩(𝜶,𝜷) ∫ 𝒖 𝜶−𝟏(𝟏−𝒖)ß−𝟏𝒙 𝟎 ; 𝒇ü𝒓 𝟎 <𝒙 ≤ 𝟏 𝒖𝒏𝒅 𝒂,𝜷> 𝟎 𝟏 ; 𝒇ü𝒓 𝒙 >𝟏 𝒎𝒊𝒕 𝑩(𝜶,𝜷)= ∫ 𝒖 𝜶−𝟏(𝟏−𝒖) 𝜷−𝟏 𝒅𝒖 𝟏 𝟎 (9) Durch eine geeignete Wahl der Parameter α und β ergeben sich verschiedene Formen der Dichte- und der Verteilungsfunktion. Abb. 13: [0,..,1]-Beta-Verteilung, Dichte- und Verteilungsfunktion Quelle: Wikipedia https://commons.wikimedia.org/w/index.php?curid=15404515 Bei einer im Intervall [0,..,1] betaverteilten Zufallsvariablen X ergeben sich damit der Erwartungswert E(X) und die Varianz 𝝈 𝟐 (X) wie folgt: 𝑬( 𝑿) = 𝜶 𝜶+𝜷 (10) 𝝈 𝟐( 𝑿) = 𝜶𝜷 (𝜶+𝜷+𝟏)(𝜶+𝜷) 𝟐 (11) 50 Vgl. Hochschule Augsburg: Beta_Verteilung Zunächst sieht man anhand der Definitionen sofort, dass jede Dichtefunktion einer standardisierten Betaverteilung auch eine Dichtefunktion einer allgemeinen Betaverteilung ist: 1) 𝑓𝐵𝑉(𝛼,𝛽)(𝑥) = 𝑓𝐵𝑉(𝛼,𝛽,0,1)(𝑥); nach der Definition der standardisierten Beta-Funktion Die Dichtefunktion der allgemeinen Betaverteilung kann durch Lineartransformationen aus entspre- chenden Dichtefunktionen der standardisierten Betaverteilung erzeugt werden. 2) 𝑓𝐵𝑉(𝛼,𝛽,𝑚𝑖𝑛,max)(𝑥) = 1 𝑚𝑎𝑥−𝑚𝑖𝑛 ∗ 𝑓𝐵𝑉(𝛼,𝛽)( 𝑥−𝑚𝑖𝑛 𝑚𝑎𝑥−𝑚𝑖𝑛 ); Für den ausführlichen Beweis der Gleichheit der Verteilungsfunktion wird hier auf die Internetseite der Hochschule Augsburg verwiesen.
  34. 34. Theoretischer Hintergrund und Forschungsstand 23 Der Modus, also die Maximalstelle der [0,..,1] verteilten Dichtefunktion ist: 𝑿 𝑴𝒐𝒅𝒖𝒔 = 𝜶−𝟏 𝜶+𝜷−𝟐 (12) Die Betaverteilung besitzt die Parameter α, β, welche aus den drei Werten unserer Ab- schätzung (min = Optimistisch, Modus = Realistisch und max= pessimistisch) errechnet werden. Mit einen Skalierungsfaktor λ≥0 (PERT hat λ=4 ) für die Höhe der Verteilung und 0 ≤ 𝑚𝑖𝑛 ≤ 𝑚𝑜𝑑𝑢𝑠 ≤ max 𝑢𝑛𝑑 min < 𝑚𝑎𝑥 wird der Mittelwert der Verteilung wie folgt definiert: 𝝁 = 𝒎𝒊𝒏+𝝀∗𝒎𝒐𝒅𝒆+𝒎𝒂𝒙 𝝀+𝟐 (13) Damit sind die Parameter α, β der Betaverteilung wie folgt bestimmt: 𝜶 = [ (𝝁−𝒎𝒊𝒏)(𝟐∗𝒎𝒐𝒅𝒖𝒔−𝒎𝒊𝒏−𝒎𝒂𝒙) (𝒎𝒐𝒅𝒖𝒔−𝝁)(𝒎𝒂𝒙−𝒎𝒊𝒏) ] (14) 𝜷 = 𝜶 [ 𝒎𝒂𝒙− 𝝁 𝝁−𝒎𝒊𝒏 ] (15) Der Modus oder Modalwert bezeichnet die Maximalstelle der Dichtefunktion, bei einer empirischen Häufigkeitsverteilung ist er der häufigste Wert: 𝑿 𝑴𝒐𝒅𝒖𝒔 = 𝒎𝒊𝒏 + (𝒎𝒂𝒙 − 𝒎𝒊𝒏) [ 𝜶−𝟏 𝜶+𝜷−𝟐 ] (16) Mit dieser Festlegung wird die Wahrscheinlichkeitsdichtefunktion aus der Einleitung auf Seite 17 wie folgt errechnet: (Min = 90, Modus = 120, Max = 210; jeweils in Minuten). Tabelle 1: Analyse des Arbeitspaketes Lindau nach Koblenz Symbol Formel λ = 2 λ = 4 λ = 8 𝝁 = 𝑬(𝑿) 𝑚𝑖𝑛 + 𝜆 ∗ 𝑚𝑜𝑑𝑢𝑠 + 𝑚𝑎𝑥 𝜆 + 2 135 130 126 𝜶 (𝜇 − 𝑚𝑖𝑛)(2 ∗ 𝑚𝑜𝑑𝑢𝑠 − 𝑚𝑖𝑛 − 𝑚𝑎𝑥) (𝑚𝑜𝑑𝑢𝑠 − 𝜇)(𝑚𝑎𝑥 − 𝑚𝑖𝑛) 1,5 2,0 3,0 𝜷 𝛼 [ 𝑚𝑎𝑥 − 𝜇 𝜇 − 𝑚𝑖𝑛 ] 2,5 4,0 7,0 𝝁 = (𝑿) 𝑚𝑖𝑛 ∗ 𝛽 + 𝑚𝑎𝑥 ∗ 𝛼 𝛼 + 𝛽 135 130 126 𝝈 𝟐 (𝑿) (𝑚𝑎𝑥 − min)2 𝛼𝛽 (𝛼 + 𝛽 + 1)(𝛼 + 𝛽)2 768,000 257,143 62,338 𝝈̅(𝑿) √∑ 𝝈𝑖 2 ∀𝑖 27,713 16,036 7,895 Es wird rechnerisch deutlich, das mit steigenden λ die Betaverteilung immer schmaler und höher um den Modus herum wird.
  35. 35. Theoretischer Hintergrund und Forschungsstand 24 Abb. 14: PERT-Verteilungen für Min=90, Modus=120, Max=210 und λ = {2, 4, 8} Quelle: https://www.riskamp.com/beta-pert#the-pert-distribution Drei der vier Parameter einer Betaverteilung sind durch das Minimum, den Modus und das Maximum aus der Expertenschätzung festgelegt. Für die Festlegung des vierten Pa- rameters gibt es mehrere Möglichkeiten: 1) Aufgrund einer eingehenden, empirischen, experimentellen Analyse wird in der PERT Me- thode λ = 4 angenommen, was oben dem mittleren Diagramm entspricht.51 Die PERT-Methode verwendet noch weitere Vereinfachungen, so wird 𝝁 = 𝑬( 𝑿) = 𝑴𝒊𝒏 + 𝟒∗𝑴𝒐𝒅𝒖𝒔 + 𝑴𝒂𝒙 𝟔 (17) und 𝝈 𝟐 (𝑿) = ( 𝑴𝒂𝒙−𝑴𝒊𝒏 𝟔 ) 𝟐 ; als Vereinfachung für α+β=652 (18) Die praktische Vereinfachung der Berechnung der Standardabweichung zu 𝜎(𝑋) = (𝑀𝑎𝑥 − 𝑀𝑖𝑛) 6⁄ ist nur hinreichend genau, wenn der Modus nicht in dem Bereich: Min ≤ Modus ≤ Min+0.13(Max - Min) und Min + 0.87(Max - Min) ≤ Modus ≤ Max liegt, sonst ist die Standardabweichung viel kleiner als (𝑀𝑎𝑥 − 𝑀𝑖𝑛) 6⁄ 53 . Das heißt, der Modus sollte immer weiter als 13 % von dem Minimum oder Maximum des Bereichs entfernt sein, damit die Vereinfachung zur Berechnung der Standardabweichung angewendet werden kann. Die Situation mit Modus weniger als 13% kommt in der Praxis vor, wenn ein Experte zur eigenen Absicherung einen sehr pessimistischsten Wert abschätzt.54 2) A posteriori kann der Parameter λ bestimmt werden, indem die initialen Abschätzungen und die tatsächlich gemessenen Werte in dem [0,..,1]-Bereich transformiert und in eine Histo- gramm aufgetragen werden. Damit steht für ähnliche Projekte ein ermittelter Parameter λ zur 51 Vgl. Golenko (1972): Statistische Methoden der Netzplantechnik, S. 53 52 Bemerkung: Aufgrund der in der Literatur nicht einheitlichen Darstellung erhält man, je nach Definition der Parameter der Betaverteilung, auch zuweilen α+β=4. 53 Vgl. Farnum and Stanton (1987): Some Results Concerning the Estimation of Beta Distribution Param- eters in PERT 54 In einem solchen Fall empfiehlt es sich, auch andere Lösungswege in Betracht zu ziehen, die dann eine Obergrenze definieren. Um bei dem Beispiel der Fahrt zu bleiben, kommen ab 3 ½ Stunden Fahrtzeit mit dem Auto auch andere Verkehrsmittel in Betracht. Wenn auch diese Verkehrsmittel, z. B. durch ein Hochwasser ausfallen sollten, dann ist fraglich, ob der Zweck der Reise überhaupt erreichbar ist.
  36. 36. Theoretischer Hintergrund und Forschungsstand 25 Verfügung, mit dem mit der heute zur Verfügung stehenden Tabellenkalkulation ist die Da- tenaufbereitung technisch kein Problem mehr. 3) Glenko-Ginzburg beschreibt eine Studie, die viele PERT Netzwerke untersucht hat, und fol- gert, dass der wahrscheinliche Wert praktisch nutzlos ist. Er wird in den meisten Projekten als 𝑀𝑜𝑑𝑒 = 𝑀𝑖𝑛 + (𝑀𝑎𝑥 − 𝑀𝑖𝑛) 3⁄ gesetzt, dies entspricht den Parametern α = 2, β = 3 und somit einer Betaverteilung(2, 3, Min, Max) die nach Meinung von Glenko-Ginzburg die PERT-Verteilung (Min, Modus, Max) ersetzen kann.55 Einsatz der 3-Punkt-Abschätzung (Min, Modus, Max) Die obigen Formeln werden jetzt benutzt, um eine Abschätzung des Aufwandes der Ar- beitspakete zu erhalten. Die AP können zum Zweck der Abschätzung und Einsatzplanung hierbei weiter in Teilaufgaben unterteilt werden. Die entscheidende Frage bei der Abschätzung ist, welche Sicherheit benötigt wird, sodass ein Arbeitspaket und das Projekt innerhalb der geplanten Zeit fertiggestellt werden. In noch folgendem Kapitel 3.5.1 „Fehlerhafter Zeitplan“ wird auf Seite 29 ausgeführt, dass ein fehlerhafter Zeitplan eines der Hauptrisiken der SW-Entwicklung ist. Es wird daher empfohlen, die benötigte Sicherheit für einen termingerechten Projektabschluss bereits im Businesscase gemeinsam mit den Stakeholdern festzulegen.56 Selbst bei einer 95 % Sicherheit werden immer noch 1 von 20 Projekten nicht zum geplanten Termin fertig werden. Die entscheidende Frage ist, welche Folgen das dann für die Stakeholder hat? Tabelle 2: Abschätzung von Arbeitspaketen nach PERT-Methode Zunächst einmal kann bei ID 1 in der Tabelle die Abschätzung des Beispiels einer Fahrt von Lindau nach Konstanz entnommen werden. Wenn man 50 % Terminsicherheit haben 55 Vgl. Farnum and Stanton (1987): Some Results Concerning the Estimation of Beta Distribution Param- eters in PERT 56 Der Projektleiter tut gut daran, die gewünschte Terminsicherheit bereits beim Start des Projektes fest- zulegen. Der Auftraggeber wird häufig der Meinung sein, dass er mit der Freigabe des Projektes die Verantwortung für die termingerechte Fertigstellung an den Auftragnehmer abgegeben hat. Das ist aber letztlich so nicht der Fall: der Auftraggeber trägt immer einen Anteil am Fertigstellungsrisiko, da er vom Ergebnis des Projektes profitieren will. Eine Ausnahme ist nur dann gegeben, wenn er eine ausrei- chende Konventionalstrafe zur Kompensation bei Terminüberschreitungen vereinbart hat.
  37. 37. Theoretischer Hintergrund und Forschungsstand 26 möchte, dann muss der Fahrer E(X)=155 Minuten einplanen. Das gewünschte Vertrau- ensniveau für die Arbeitspakete wird links neben dem Feld „Prop. Workpackages“ ein- gestellt und beträgt hier 67 %. Für eine 67 % Sicherheit, ergibt sich mit Hilfe der Varianz σ(X) = 15 Minuten, ein anzusetzender Planungswert von 162 Minuten57 . Dafür ist ein zusätzlicher Puffer von 7 Minuten einzuplanen. In der Spalte „Valid?“ wird geprüft ob 0≤Min<Modus<Max ist, sonst sind die Daten nicht korrekt. Die Vereinfachung bei PERT stellt die Grenze der Anwendbarkeit dar, falls der Modus zu nah an die Bereichsgrenze Min oder Max kommt wird das gekennzeichnet. Wenn die Anwendung der Vereinfachung fraglich ist, wird dies ebenso gelb dargestellt.58 Die Erwartungswerte werden jetzt aufsummiert und aus dem obigen Beispiel ergeben sich damit die folgenden Paare von Wahrscheinlichkeit und Planungswert, wie sie für ein tech- nisches Softwareprojekt Anwendung finden könnten. Tabelle 3: Mögliche Planungswerte nach der PERT-Methode Pla- nungs wert Wahr- schein- lichkeit Vorgang Vor- gangsri- siko- reserven Wahr- schein- lichkeit Projekt Projekt- risikore- serve Ohne Risikoreserve 2.382 50 % 0 50 % 0 Mit Vorgangsrisikoreserve 2.536 69% 155 69% 0 Mit Vorgangs- und Pro- jektrisikoreserve 2.606 69% 155 95% 70 Nur mit Projektrisikoreserve 2.449 50 % 0 69% 66 Mit Vorgangs- und Pro- jektrisikoreserve 2.449 69% 155 69% -87 Der Unterschied zwischen der Summe der Vorgangsrisikoreserve und der Projektrisiko- reserve ist, dass im Planungswert die Summen der Erwartungswerte der einzelnen Vor- gänge inklusive Vorgangsrisikoreserven summiert werden. Bei der Projektrisikoreserve wird die Varianz aus der Wurzel der Quadratsummen der einzelnen Varianzen als 𝝏(𝒙) = √∑ 𝑥𝑖 2 ∀𝑖 errechnet. Wie in Abb. 32 auf Seite 61 gezeigt wird, steigt bei der Unterschät- zung des Aufwandes der zusätzliche Aufwand überproportional an, daher ist es zweck- mäßig hier nicht als Vorgangsdauer den Erwartungswert, sondern den Erwartungswert zuzüglich einer Vorgangsrisikoreserve als Planungswert anzusetzen. Wenn diese Vorgangsrisikoreserve, also die Wahrscheinlichkeit der Fertigstellung inner- halb des Planwertes, zu gering gewählt wird, dann sind häufigere Umplanungen des Zeit- plans und eine sinkende Motivation der Mitarbeiter aufgrund zu häufiger Terminüberschreitung von AP die Folge. 57 Mit der Funktion NORM.INV (probability, E(X), σ(X)) von Excel lässt sich die Perzentile, bei An- nahme einer Normalverteilung, bequem berechnen. 58 Wenn Min(Modus-Min,Max-Modus)/Min(Modus-Min,Max-Modus)<33%, dann ist die Verwunderung der PERT-Schätzung des Mittelwertes fraglich, bei <20% sollte sie nicht mehr benutzt werden.
  38. 38. Theoretischer Hintergrund und Forschungsstand 27 Einsatz der 4-Punkt-Abschätzung (Min, Modus, Max, λ) Mit den aktuellen Tabellenkalkulationsprogrammen können die Parameter α, β und µ der Betaverteilung mit Hilfe der Formeln leicht berechnet werden. Insofern sind die Verein- fachungen der PERT-Schätzung heute technisch nicht mehr notwendig. Der Parameter λ der Schärfe (Güte) des wahrscheinlichen Wertes Modus kann bei der Schätzung von Min, Modus, Max mit abgeschätzt werden und so wird aus der 3-Punkt-Abschätzung eine 4-Punkt-Abschätzung. Mit einer Festlegung für den Schärfegrad einer Schätzung wie λ=2 „gering“, λ=4 „unter- durchschnittlich“, λ=6 „durchschnittlich (PERT)“, λ=9 „überdurchschnittlich“, λ=12 „hoch“ und λ=16 „sehr hoch“, ist nach etwas Übung die Festlegung von λ ohne zusätzli- chen Aufwand bei der Schätzung von Min, Modus, Max möglich. Für die gleichen Ar- beitspakete, wie aus Tabelle 2: Abschätzung von Arbeitspaketen nach PERT-Methode“ auf Seite 25 sieht eine 4-Punkt Abschätzung wie folgt aus. Tabelle 4: Abschätzung von Arbeitspaketen mit Beta-Verteilung Für die ersten drei Werte wird hier der Einfluss von λ auf die Werte des „Fahrt von Lindau nach Konstanz“-Beispiels dargestellt. Mit höheren λ also höher Vertrauen in die Schät- zung sinkt der notwendige Vorgangsrisikopuffer dabei erheblich. Auch der Fall mit der ID 4.1, der mit der PERT-Methode nicht sicher abschätzbar und darstellbar war, ist in der 4-Punkt Methode gut darstellbar. Offenbar schätzt der Experte die Zuverlässigkeit des Modus mit λ=12 als relativ hoch ein und schätzt nur ein geringes Risiko ein, dass es dreimal so lange dauern könnte. Der Erwartungswert der Vorgangs- dauer sinkt dadurch von 200 auf 171 und der notwendige Vorgangsrisikopuffer reduziert sich deutlich von 33 auf 15. Insgesamt reduziert sich der Planwert aus PERT von 233 um 46 auf noch 187 für die 4-Punkt Abschätzung. Da der Erwartungswert Ei(X) der einzelnen Arbeitspakete bekannt ist, ist auch der Erwar- tungswert des Projektes 𝑬 𝒑 = ∑ 𝐸𝑖∀𝑖 (𝑋𝑖) als Summe der Erwartungswerte der einzelnen Arbeitswerte bekannt. Damit können auch die Parameter α, β der Betaverteilung des Pro- jektes bestimmt werden. Klar ist der Min- und Max-Wert des Projektes ist die Summe der Min- und Max-Werte der einzelnen Arbeitspakete, damit liegen dann alle Parameter α, β der Betaverteilung des Projektes fest. Der Modus des Projektes ergibt sich in gleicher Weise als Summe der Modi der Arbeitspakete. Da α und β bekannt sind, kann λ= α + β - 2 für das Projekt leicht errechnet werden. Für das obige Beispiel ergibt sich λ=8,6 und somit kann das Vertrauen in den Modus des Projektes als „überdurchschnittlich“ bezeichnet werden.
  39. 39. Theoretischer Hintergrund und Forschungsstand 28 Zusammenfassung und Fazit Die notwendigen Schätzpunkte für Mehrpunkt-Abschätzungen können durch Befragung von Experten in Schätzklausuren einfach gewonnen werden. Eine Mehrpunkt-Schätzung liefert zusätzlich zu dem eigentlichen Schätzwert auch die Varianz der zugrundeliegenden Schätzung. Diese Varianz der Schätzung ist für mehrere Punkte sinnvoll und nützlich:  Mit der Varianz können statisch fundierte Aussagen über notwendige Aufwandsreserven für Arbeitspakete und das gesamte Projekt getroffen werden. Diese fundierte Darstellung hilft bei der Darstellung und Begründung der Arbeitspaket- und Projektrisikoreserven gegenüber den Stakeholdern. Eine Reduzierung der Reserven, z. B. durch politische Ein- flussnahme von Stakeholdern, führt darstellbar zur entsprechenden Reduzierung des Ver- trauensniveaus. Dieses Vertrauensniveau sollte, ebenso wie die Summe der Aufwände, in dem Businesscase enthalten sein.  Für die erste initiale Schätzung des Projektes und von AP steht häufig nicht viel Zeit zur Verfügung. Die Unsicherheit59 der ersten initialen Schätzung spiegelt sich dadurch in ei- nem breiten Schätzbereich (Max-Min) und einem niedrigen Wert von λ der Schärfe wie- der. Die Varianz der initialen Schätzung kann später inkrementell reduziert werden, indem die Arbeitspakete mit dem höchsten Anteil an der Varianz ausgewählt und dann genauer abgeschätzt werden. In der obigen Tabelle 4: Abschätzung von Arbeitspaketen mit Beta-Verteilung“ auf Seite 27 verursachen die beiden AP 4.1 und 5 zusammen 52 % der resultierenden Varianz. Insofern kann hier mit etwas zusätzlichem Abschätzaufwand die Qualität der Gesamtschätzung gesteigert werden. Résumé:  Die Mehrpunktabschätzung eines Projektes kann inkrementell, über die Ebenen des Pro- jektstrukturplan (PSP), verbessert werden. In der Abb. 9 auf Seite 16, kann z. B. zunächst nur das AP 2 „Onboard-Diagnose“ grob abgeschätzt werden. Diese erste Abschätzung des AP 2 wird später durch die Summe der Abschätzungen der Detailfunktionalitäten 2.1, 2.2 und 2.3 ersetzt. Das AP 2 bleibt im PSP bestehen, nur die Werte werden aus dem AP 2.1, AP 2.2 und AP 2.3 errechnet.  Die statisch genauere Betaverteilung sollte aufgrund der heute zur Verfügung stehenden technischen Mitteln zur Abschätzung benutzt werden. Die PERT-Vereinfachungen sind heute technisch nicht mehr notwendig.  Die so gewonnenen Daten sind eine fundierte Grundlage für die Ermittlung des Aufwan- des auf jeder Ebene des Projektstrukturplans und können inkrementell im Projektablauf verfeinert werden.  Die Schätzmethoden setzen definierte Aufgabenstellungen voraus und sind nicht nur in der technischen Softwareentwicklung anwendbar.  Mit den Parameter λ ist die Modellierung der Güte der Abschätzung möglich. Ein Auto- fahrer welcher die Strecke Lindau-Koblenz zum ersten Mal fährt, kann nur ein kleineres λ erreichen, als der Wochenendpendler welcher die Strecke 40-mal im Jahr fährt. 59 Warren Buffett: Risk comes from not knowing what you're doing.
  40. 40. Theoretischer Hintergrund und Forschungsstand 29 3.5 Kernrisiken von Softwareprojekten Seltsamerweise kennen alle die Probleme aus den Projekten der Vergangenheit, trotzdem werden bei neuen Projekten die gleichen Risiken nicht oder nur ungenügend60 berück- sichtigt. Risiken sind ein integraler Bestandteil aller Projekte.61 Beim Risikomanagement geht es darum, Vorkehrungen für nicht kontrollierbare Ereignisse zu treffen und Risiko- rückstellungen im Projekt zu bilden, um ein normales Maß von eintretenden Ereignissen behandeln zu können. Jeder, der an mehreren Softwareprojekten teilgenommen hat, kann schnell zwanzig bis dreißig Risiken aus der Vergangenheit benennen. Risiken aus vergangenen Projekten sollten auch bei neuen Projekten wieder betrachtet werden. DeMarco und Lister stellen in ihrem Buch „Bärentango“ fünf typische Kernrisiken von Softwareprojekten dar, wel- che den Hauptteil der notwendigen Rückstellungen bilden. Fehlerhafter Zeitplan Einer der häufigsten eintretenden Risiken eines Projektes ist ein fehlerhafter, unterschätz- ter Zeitplan. Fehler im Zeitplan wirken sich bei technischen Projekten immer auf die Kos- ten (Aufwand) aus, da die Qualität/der Leistungsumfang oder der Termin nicht wesentlich angepasst werden können. Für einen fehlerhaften Zeitplan gibt es zwei Hauptursachen:  Erstens wird der Umfang des durchzuführenden Projektes insgesamt unterschätzt. Die Tendenz Arbeitsaufgaben in der Abschätzung zu vernachlässigen, die dann doch später notwendig werden, ist höher, als die Tendenz Arbeitsaufgaben zu berücksichtigen, die sich später als unnötig erweisen. Probleme tauchen in der Regel erst bei der Fertigstellung von Arbeitsprodukten auf und werden daher in der Planung noch nicht berücksichtigt.  Zweitens wird eine valide initiale Planung durch optimistische Zusagen des Manage- ments beschnitten und Termine und Kosten aufgrund von Kundenwünschen festgelegt.62 Dies kann im Vorfeld nur durch einen soliden PSP mit substantiierten Arbeitsaufwänden vermieden werden, der auch gegen Einwände des Managements verteidigt werden kann.63 Wird ein PSP erst nach der Freigabe des Projektes und nach Festlegung des Termins er- stellt, ist die Zeitplanung letztlich pures Wunschdenken und eine deutliche Überschrei- tung des Temins wird die natürliche Folge sein.64 Im noch folgenden Kapitel 5.3 auf Seite 59 werden wirkungsvolle Maßnahmen aufge- zeigt, wie dieses Risiko mit EVM reduziert werden kann. 60 Vgl. De Marco und Lister (2003): Bärentango S. 60 .. 62 61 Risiken und Gewinn verhalten sich proportional zueinander. Ein Projekt mit großen Risiken hat auch die Chance etwas Neues auf den Markt zu bringen. Dies kann dem Unternehmen einen deutlichen Wett- bewerbsvorteil bringen. Vgl. De Marco und Lister S. 3 62 Vgl. DeMarco und Lister S 109 .. 112, welcher die Aussage herleitet „Wenn ein Projekt den Zeitplan nicht einhält, so geschieht das trotz, nicht wegen der Entwicklerleistung. 63 DeMarco und Lister S. 110: „Nimmt ein sieben Monatsprojekt schließlich zwölf Monate in Anspruch, gibt ein verärgertes oberes Management selten dem Zeitplan die Schuld; stattdessen sucht es die Schuld bei denen, die den Zeitplan – ganz gleich, wie lächerlich er war – hätten realisieren sollen. Tatsächlich aber trägt der fehlerhafte Zeitplan, nicht eine mangelhafte Leistung die Schuld an der Misere.“ 64 DeMarco und Lister führen auf S. 110 dazu aus: „Wird der Zeitplan ohne Rücksicht auf die Projektgröße festgelegt, ist eine Terminüberschreitung von 50 bis 80 Prozent wahrscheinlich.“

×