Controlling von Projekten Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle

Rudolf Fiedler Controlling von Projekten Rudolf Fiedler Controlling von Projekten Mit konkreten Beispielen aus der Un...

Author: Rudolf Fiedler

361 downloads 3005 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Rudolf Fiedler Controlling von Projekten

Rudolf Fiedler

Controlling von Projekten Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle 5., erweiterte Auflage Mit 215 Abbildungen

PRAXIS

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

1. Auflage 2001 2., Auflage 2003 3., Auflage 2005 4., Auflage 2008 5., erweiterte Auflage 2010 Alle Rechte vorbehalten © Vieweg +Teubner | GWV Fachverlage GmbH, Wiesbaden 2010 Lektorat: Christel Roß | Maren Mithöfer Vieweg+Teubner ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.viewegteubner.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-0889-9

Vorwort

Die Bedeutung des Projektcontrollings hat in den letzten Jahren durch komplexer werdende Projekte mit hohem Termin- und Kostendruck zugenommen. Projektrelevantes Controllingwissen benötigt nicht nur der Controller, sondern im besonderen Maße auch das Management und die Projektverantwortlichen. Über das reine Projektmanagement hinausgehende Grundkenntnisse des Projektcontrollings sind ebenso für viele Projektmitarbeiter zur Voraussetzung für die erfolgreiche Bewältigung ihrer Aufgaben geworden. Mit dem vorliegenden Buch wird das Ziel verfolgt, den Projektverantwortlichen, Projektmitarbeitern und Controllern eine zugleich theorieorientierte und praxisfundierte Beschreibung des Projektcontrollings und seiner wesentlichen Instrumente an die Hand zu geben. Sie sollen Anregungen für die Lösung ihrer täglichen Probleme in den Projekten erhalten. Das Buch wendet sich auch an Studierende, die sich an der Hochschule mit der systematischen Projektabwicklung beschäftigen. Es wurde Wert auf eine leicht verständliche Darstellung gelegt. Viele Abbildungen und Praxisbeispiele tragen dazu bei, dass sich der Leser rasch mit der Thematik vertraut machen kann. Der Aufbau des Lehrbuchs entspricht der folgenden Abbildung. Sie erscheint auch in der Kopfleiste jeder Seite, um dem Leser die Orientierung zu erleichtern.

1. Überblick über das Projektcontrolling 2. Strategisches Projektcontrolling Projektplanung, Projektkontrolle, Projekt-Scorecard,

3. Operatives Projektcontrolling 3.1 Projektplanung 3.2 Projektkontrolle Ziele, Organisation, Phasen, Aufgaben, Aufwand, Termine, Ressourcen, Kosten, Risikocontrolling

Leistung, Termine, Kosten, Projekterfahrungen, Berichtswesen, Kennzahlen

4. DV-Unterstützung

V

Vorwort Kap. 1 gibt einen Überblick über Projektcontrolling und Projektmanagement. Angesprochen werden die Aufgaben und Ziele des Projektcontrollings sowie die Abgrenzung zum Projektmanagement. Kap. 2 behandelt das Projektcontrolling aus strategischer Sicht. Es geht vor allem um Instrumente zur Auswahl und Priorisierung in einem Multiprojektumfeld, aber auch um den Einsatz der ProjektScorecard für die Projektauswahl und Projektsteuerung. Kap. 3 bildet den Schwerpunkt des Buchs. Es beschreibt das operative Projektcontrolling. Im Sinne eines ganzheitlichen Lösungsansatzes orientieren sich die Ausführungen zur Projektplanung an den Lebenszyklusphasen eines Projektes. Die Planungssicht wird um die Aspekte der Steuerung und Kontrolle ergänzt. Neben der allgemeinen Aufgabenbeschreibung für das operative Projektcontrolling stehen praktische Instrumente im Mittelpunkt. In Kap. 4 werden DV-Tools für das Projektcontrolling beschrieben und beurteilt. Herausgearbeitet werden auch die Einsatzmöglichkeiten eines Führungsinformationssystems für die Projektdatenanalyse. In der aktuellen 5. Auflage wurden noch mehr Praxisbeispiele aus unterschiedlichen Branchen und Betriebstypen integriert. Sie stehen jetzt nicht mehr in einem separaten Kapitel, sondern verdeutlichen direkt nach der allgemeinen Beschreibung einer Methode deren Anwendung im konkreten Unternehmen. Die Praxisbeispiele sind kursiv gedruckt und werden am Rand mit einem Icon gekennzeichnet. Für die schnelle Orientierung werden weitere Icons für Hinweise auf Definitionen, Literatur- und Internetquellen und Tipps verwendet. Außerdem werden die Aufgaben, die das Projektcontrolling übernehmen kann, besonders gekennzeichnet. In das vorliegende Lehrbuch flossen Anregungen vieler Personen ein, die auf diese Weise zum Gelingen beitrugen. Ihnen allen möchte ich danken. Besonderen Dank schulde ich Heinz-Georg Boßmann und Thomas Brunschede, Dr. Gerald Butterwege, Andreas Döring, Mehtap Kara, Andreas Klein, Sabina Rosemann und Barbara Veit. Sie haben Praxisbeispiele trotz ihrer hohen Arbeitsbelastung verfasst. Heinz-Georg Boßmann und Thomas Brunschede von der Le Bihan Consulting GmbH verdeutlichten die Anwendungsmöglichkeiten von OPX2 für das strategische Projektcontrolling. VI

Vorwort Dr. Gerald Butterwege von der Bissantz & Company GmbH zeigte, wie der Delta Master die Analyse der Projektdaten komfortabel unterstützt. Andreas Döring erläuterte anschaulich die im Projektcontrolling verwendeten Instrumente bei der Lufthansa Systems GmbH (Systemhaus). Mehtap Kara beschrieb ausführlich das Projektcontrolling, insbesondere das Projektberichtswesen im Produktbereich Instrumentation Systems der Robert Bosch GmbH (Kfz-Zulieferunternehmen). Andreas Klein stellte differenziert das Ergebnis- und Kostencontrolling im Projektgeschäft der Outokumpu Technology GmbH (Anlagenbau) dar. Sabina Rosemann von der MIS AG (Softwareanbieter und Beratungsunternehmen) beleuchtete speziell die Einsatzmöglichkeiten eines Führungsinformationssystems für die Analyse der Projektdaten. Barbara Veit von der Zurich Gruppe Deutschland (Versicherung) verdeutlichte das strategische Initiativen- und Projektmanagement. Sie beschrieb die beteiligten Organisationseinheiten, den Planungsprozess und das Reporting. Wertvoll für den Autor waren vor allem die Diskussionen mit Praktikern bei der Durchführung von Seminaren über Projektcontrolling und Projektmanagement. Auch Praxisprojekte zwischen Unternehmen und der Hochschule boten eine hervorragende Plattform des Erfahrungsaustausches. Für Verbesserungsvorschläge ist der Autor immer dankbar. Anregungen können über die E-Mail-Kennung [email protected] weitergegeben werden. Der interessierte Leser kann weitere Informationen über Projektmanagement und Projektcontrolling unter den Adressen x www.projektcontroller.de, x www.projektmagazin.de und x www.competence-site.de im Internet abrufen. Seminare über Projektcontrolling und Projektmanagement werden unter www.projektcontroller.de angeboten. Würzburg, im November 2009

Prof. Dr. Rudolf Fiedler

VII

Inhaltsverzeichnis Vorwort .................................................................................................. V Abbildungsverzeichnis .........................................................................XI

1

1.1 1.2 1.3 1.4

Überblick über das Projektcontrolling 1 Projekt und Projektmanagement............................................... 2 Controlling.............................................................................. 10 Projektcontrolling ................................................................... 11 Zusammenfassung .................................................................. 34

2

Strategisches Projektcontrolling 35 2.1 Strategische Projektplanung ................................................... 36 2.1.1 Überblick....................................................................... 36 2.1.2 Grobe Vorselektion ....................................................... 38 2.1.3 Bewertung der Attraktivität........................................... 39 2.1.3.1 Nutzwertanalyse 40 2.1.3.2 Portfolios 49 2.1.3.3 Wirtschaftlichkeitsverfahren 53 2.1.4 Analyse der Abhängigkeiten ......................................... 63 2.1.5 Analyse der Ressourcenverfügbarkeit und Projektauswahl .............................................................. 66 2.2 Strategische Projektkontrolle.................................................. 70 2.3 Projekt-Scorecard ................................................................... 73 2.4 Zusammenfassung .................................................................. 82

3

Operatives Projektcontrolling 83 3.1 Operative Projektplanung ....................................................... 84 3.1.1 Überblick....................................................................... 84 3.1.2 Projektziele ................................................................... 85 3.1.3 Aufbauorganisation ....................................................... 86 3.1.4 Projektphasen ................................................................ 87 3.1.5 Projektaufgaben und Projektstruktur............................. 92 3.1.6 Projektaufwand ............................................................. 98 3.1.7 Terminplanung ............................................................ 106 3.1.8 Ressourcenplanung ..................................................... 126 3.1.9 Kosten- und Erlösplanung........................................... 133 3.1.10 Risikomanagement und -controlling ........................... 151

IX

Inhaltsverzeichnis 3.2 Operative Projektkontrolle.................................................... 168 3.2.1 Überblick..................................................................... 168 3.2.2 Leistungskontrolle....................................................... 173 3.2.3 Terminkontrolle .......................................................... 180 3.2.4 Kostenkontrolle........................................................... 187 3.2.5 Auswertung der Projekterfahrungen ........................... 200 3.2.6 Berichtswesen und Dokumentation............................. 202 3.2.6.1 Berichtswesen in einem Produktbereich der Robert Bosch GmbH 210 3.2.6.2 Berichtswesen der Outokumpu Technology GmbH 224 3.2.6.3 Berichtswesen der Zurich Gruppe Deutschland 232 3.2.6.4 Fortschrittsbericht der Lufthansa Systems 234 3.2.7 Kennzahlen ................................................................. 240 3.3 Zusammenfassung ................................................................ 244

4

DV-Unterstützung 247 4.1 Projektmanagementsoftware................................................. 248 4.1.1 SAP R/3 ...................................................................... 251 4.1.2 MS-Project .................................................................. 253 4.1.3 Einführung einer Projektmanagementsoftware ........... 255 4.2 Führungsinformationssysteme.............................................. 257 4.2.1 Aufbau des Führungsinformationssystems der MIS AG....................................................................... 261 4.2.2 Projektdatenanalyse mit dem Delta Master................. 264 4.3 Zusammenfassung ................................................................ 272

Literaturverzeichnis Stichwortverzeichnis

X

273 279

Abbildungsverzeichnis Abb. 1: Abb. 2: Abb. 3: Abb. 4: Abb. 5: Abb. 6: Abb. 7: Abb. 8: Abb. 9: Abb. 10: Abb. 11: Abb. 12: Abb. 13: Abb. 14: Abb. 15: Abb. 16: Abb. 17: Abb. 18: Abb. 19: Abb. 20: Abb. 21: Abb. 22: Abb. 23: Abb. 24: Abb. 25: Abb. 26: Abb. 27: Abb. 28: Abb. 29: Abb. 30: Abb. 31: Abb. 32: Abb. 33: Abb. 34: Abb. 35: Abb. 36: Abb. 37: Abb. 38: Abb. 39: Abb. 40:

Projektarten .............................................................................. 2 Projektkriterien der Versicherungskammer Bayern ................. 4 Übersicht der Projekt-Kategorien der Outokumpu Technology GmbH................................................................... 5 Das „magische Dreieck“ des Projektmanagements.................. 8 Ursachen für das Scheitern von Projekten ............................... 9 Anforderungen an den Projektleiter ....................................... 10 Aufgaben des Projektcontrollings .......................................... 12 Stellung des Projektcontrollings ............................................ 14 Aufgaben des Projektcontrollings .......................................... 15 Bausteine des Einzel- und Multiprojektcontrollings .............. 16 Träger des Projektcontrollings ............................................... 19 Aufgabenschwerpunkte des Projektcontrollers ...................... 20 Leitbild für den Projektcontroller........................................... 21 Aufgaben von Projektleiter und Projektcontroller ................. 22 Anforderungen an den Projektcontroller................................ 23 Hierarchische Einbindung des Projektcontrollers .................. 23 Differenzierung der Controllingstellen .................................. 24 Informationsaustausch und Abstimmung über Meetings ....... 24 Matrix-Projektorganisation .................................................... 25 Organisatorische Einbindung des Projektcontrollings im Produktbereich Instrumentation Systems.......................... 26 Anteil der Kosten von Projektplanung, Projektkontrolle und Projektinformation am Gesamtbudget ............................ 32 Überblick über die strategische Projektplanung..................... 36 Prozess der strategischen Projektauswahl .............................. 38 Systematische Vorgehensweise bei der Zielfindung.............. 41 Gewichtete Zielstruktur.......................................................... 41 Analyse möglicher Zielkonflikte............................................ 42 Zielgewichtung mit der Präferenzmatrix................................ 43 Ausgangsmatrix ..................................................................... 44 Quadrierte Matrix................................................................... 44 Normalisierte Matrix.............................................................. 45 Vergleich der Zielgewichte.................................................... 45 Nutzwertanalyse..................................................................... 46 Verantwortlichkeitsmatrix in OPX2 ...................................... 48 Projektbewertung in OPX2 .................................................... 48 Projektpriorisierung in OPX2 ................................................ 49 Priorisierung von Aufgaben ................................................... 50 Priorisierung der Projekte durch paarweisen Vergleich......... 50 Portfolio für Forschungs- und Entwicklungsprojekte ............ 51 Risikoportfolio ....................................................................... 53 Wirtschaftlichkeitsverfahren für die Projektauswahl ............. 53

XI

Abbildungsverzeichnis Abb. 41: Abb. 42: Abb. 43: Abb. 44: Abb. 45: Abb. 46: Abb. 47: Abb. 48: Abb. 49: Abb. 50: Abb. 51: Abb. 52: Abb. 53: Abb. 54: Abb. 55: Abb. 56: Abb. 57: Abb. 58: Abb. 59: Abb. 60: Abb. 61: Abb. 62: Abb. 63: Abb. 64: Abb. 65: Abb. 66: Abb. 67: Abb. 68: Abb. 69: Abb. 70: Abb. 71: Abb. 72: Abb. 73: Abb. 74: Abb. 75: Abb. 76: Abb. 77: Abb. 78: Abb. 79: Abb. 80: Abb. 81: Abb. 82: Abb. 83: Abb. 84:

XII

Gewinnsituation im Ausgangsfall .......................................... 54 Erlöseinbußen bei einer Projektverlängerung ........................ 55 Gewinnsituation bei einem zusätzlichen Projekt.................... 55 Gewinnsituation nach der Optimierung ................................. 56 Monetäre Bewertung des „magischen Dreiecks“................... 56 Break-Even-Analyse .............................................................. 57 Das Kennzahlensystem Return on Investment....................... 59 Ermittlung des Kapitalwerts................................................... 61 Berechnung des Net Present Value ........................................ 62 Einfluss der Projekte auf den Unternehmenswert .................. 63 Einflussmatrix ........................................................................ 64 Portfolio zur Analyse der Abhängigkeiten............................. 64 Ausgewogenheit des Projektportfolios................................... 66 Ablauf des Zero Base Budgeting ........................................... 67 Ergebnisniveaus für das Projekt „Vernetzung“...................... 68 Budgetschnitt ......................................................................... 69 Überblick über die strategische Projektkontrolle ................... 70 Arten der strategischen Kontrolle .......................................... 71 Attraktivitäts-Portfolio ........................................................... 72 Wirkungen einer Balanced Scorecard .................................... 74 Perspektiven der Balanced Scorecard .................................... 75 Aufbau der Balanced Scorecard............................................. 76 Ableitung der Projekt-Scorecard............................................ 77 Gewichtung der Perspektiven und Ziele ................................ 78 Ermittlung der Zielerreichung................................................ 78 Darstellung der Projektsituation............................................. 79 Cockpitchart einer Projekt-Scorecard .................................... 81 Überblick über die operative Projektplanung......................... 84 Faktoren für den Projekterfolg in einzelnen Phasen .............. 88 DV-System zur Beschreibung der Projektphasen .................. 90 Auszug aus einer Know-how-Datenbank zur Beschreibung von Prozessschritten........................................ 91 Auszug aus der Dokumentation eines Prozessschrittes.......... 91 Projektneutrale Kalkulation ................................................... 92 Schrittweise Konkretisierung der Projektplanung.................. 94 Zuordnung von technischer Struktur und Projektstrukturplan................................................................. 95 Wertorientierter Projektstrukturplan ...................................... 97 Wertermittlung für ein Arbeitspaket ...................................... 98 Ablauf der Delphi-Methode ................................................. 100 Aufwandsverteilung in Softwareprojekten........................... 101 Relative Anteile von Aufwand und Zeitdauer...................... 102 Function-Point-Kurve .......................................................... 103 Terminplanung..................................................................... 106 Netzplanverfahren................................................................ 107 Netzplan (generiert mit MS-Project).................................... 108


Berechnung der frühesten Vorgangszeitpunkte ................... 110 Berechnung der spätesten Vorgangszeitpunkte.................... 110 Beschriftungsalternativen für Netzplanknoten..................... 111 Einplanung einer Managementreserve ................................. 112 Steuerung des Projektportfolios mit der Managementreserve ............................................................. 113 Netzplan für die Ermittlung des Reduktionspotenzials........ 115 Bestimmung des Reduktionspotenzials................................ 115 Zahl der Kommunikationsbeziehungen in einer Gruppe...... 117 Einfluss der Gruppengröße auf die Projektdauer ................. 118 Wirkung zusätzlicher Ressourcen ........................................ 119 Erlösveränderung in Abhängigkeit der Projektdauer ........... 120 Abhängigkeit der Kosten von der Vorgangsdauer ............... 121 Mehrkosten durch Verkürzung eines Vorgangs................... 122 Berechnung der mittleren Beschleunigungskosten .............. 122 Bestimmung der minimalen Dauer eines Arbeitspakets ...... 123 Auswirkungen zusätzlicher Ressourcen............................... 124 Ressourcenbelastungsdiagramm .......................................... 126 Kapazitätsbelastungsdiagramm mit verfügbarer Kapazität.. 127 Verfügbare Personalstunden pro Monat............................... 128 Funktionsmatrix ................................................................... 130 Ressourceneinplanung in MS-Project .................................. 130 Kapazitätsausgleich.............................................................. 131 Systematik der Auslastungsplanung .................................... 133 Abrechnungsfluss der Budgetierung .................................... 134 Daten für die Projektkostenkalkulation................................ 135 Einteilung der Mitarbeiter in Kategorien ............................. 136 Errechnung eines Standardstundensatzes............................. 136 Projektkostenkalkulation...................................................... 138 Retrograde Projektkalkulation ............................................. 138 Vereinfachte Kalkulationsstruktur ....................................... 139 Stufen der Deckungsbeitragsrechnung................................. 140 Projektkostenplanung........................................................... 141 Zusammensetzung des aktuellen Gesamtbudgets ................ 142 Kostenschätzung .................................................................. 143 Ermittlung der Liquidität ..................................................... 144 Liquiditätsverlauf in einem Entwicklungsprojekt ................ 145 Ablauf der Cash Flow-Planung............................................ 146 Grafische Darstellung der Cash Flow-Analyse .................... 147 Integration der Daten aus Projekttätigkeit und Nichtprojekttätigkeit in die Unternehmensrechnung..... 150 Bausteine des Risikomanagements und -controllings .......... 152 Detaillierung der Projektstruktur.......................................... 154 Klassifizierung von Projektrisiken in einer Risk Map ......... 155 Praxisbeispiel für die Projektrisikobewertung ..................... 156 Möglichkeiten der Risikosteuerung ..................................... 157

XIII


XIV

Möglichkeiten der Risikovorbeugung.................................. 157 Risikomanagementplan........................................................ 158 Überwachung von Einzelrisiken .......................................... 158 Gesamtrisiko eines Projektes ............................................... 159 Differenzierung des Gesamtrisiko nach Risikoklassen ........ 160 Formblätter für eine systematische Risikoanalyse ............... 161 Auszug aus ProRisk ............................................................. 165 Verkürzte Darstellung einer Risiko-Analyse ....................... 167 Überblick über die operative Projektkontrolle ..................... 168 Elemente der Projektsteuerung und -kontrolle..................... 169 Auszug aus dem System ZZMA .......................................... 171 Projektsteuerung mit Prognosedaten.................................... 172 Bestandteile der Projektkontrolle und -steuerung ................ 173 Beispiel für die Ermittlung des Leistungsfortschritts........... 174 Ermittlung des Projektfortschritts ........................................ 175 Kreislauf der Leistungserbringung....................................... 177 Tatsächlicher Leistungsfortschritt........................................ 177 Projektfortschrittsbericht in MS-Project .............................. 180 Balkenplan mit Time-to-Completion ................................... 181 Termin-Trenddiagramm....................................................... 182 Kurvenverläufe im Termin-Trenddiagramm........................ 182 Zusammenspiel von Terminplan und MeilensteinTrendanalyse basierend auf MS-Project .............................. 183 Praktisches Beispiel zur Meilenstein-Trendanalyse............. 184 Kosten-Trenddiagramm ....................................................... 185 Zeit-/Kosten-Trenddiagramm .............................................. 186 Kostenkontrolle.................................................................... 187 Kumulierte Ist- und Plankosten............................................ 188 Beispieldaten für die Earned Value Analyse........................ 191 Diagramm für die Earned Value Analyse ............................ 192 Kostenabweichung als Fieberkurve ..................................... 193 Leistungsabweichung als Fieberkurve ................................. 193 Kosten- und Leistungsindex mit Abweichungskorridor ...... 194 Trompetenkurve................................................................... 195 Berechnung der voraussichtlichen Gesamtkosten mit unterschiedlichen Annahmen für die Restkosten........... 197 Multiprojektcontrolling mit der Earned Value Analyse....... 197 Earned Value Analyse mit MS Project ................................ 199 Ursachen für aufgetretene Probleme .................................... 200 Bewertung der Projektkomplexität ...................................... 202 Verdichtung der Informationen im Bericht.......................... 203 Ausnahmebericht mit Ampelfunktion.................................. 204 Inhalte des Fortschrittsberichts ............................................ 205 Deckblatt eines Fortschrittsberichts ..................................... 206 Voraussichtliche Gesamtabweichung des Aufwands........... 207 Beschreibung eines Berichts ................................................ 208

Abbildungsverzeichnis Abb. 173: Zwei Auszüge aus einer beispielhaften „elektronischen Projektakte“................................................ 210 Abb. 174: Berichte, Berichtsgremien und Berichtshäufigkeit .............. 211 Abb. 175: Darstellung des Projekt-Cockpits......................................... 212 Abb. 176: Regelmeetingbericht ............................................................ 215 Abb. 177: Ampelfarbenbelegung.......................................................... 216 Abb. 178: Belegung der Ampelfarben nach vorgegebenen Regeln ...... 217 Abb. 179: Wochenbericht ..................................................................... 218 Abb. 180: Dokumentation von Änderungen ......................................... 220 Abb. 181: Änderungserfolgsrechnung .................................................. 221 Abb. 182: Schematisierter Ablaufplan der Controlling-Aktivitäten ..... 224 Abb. 183: Kategorien für Projektberichte............................................. 226 Abb. 184: Deckblatt Projektmonatsbericht ........................................... 228 Abb. 185: Projektkostenbericht ............................................................ 229 Abb. 186: Einzelpostenbericht.............................................................. 230 Abb. 187: Stundenbericht ..................................................................... 231 Abb. 188: Planungs- und Reportingdimensionen der Zurich Gruppe Deutschland ................................................. 233 Abb. 189: ProControl-Client (1 von 4) ................................................. 236 Abb. 190: ProControl-Client (2 von 4) ................................................. 236 Abb. 191: ProControl-Client (3 von 4) ................................................. 237 Abb. 192: ProControl-Client (4 von 4) ................................................. 237 Abb. 193: ProControl-Frühwarnsystem (1 von 2) ................................ 239 Abb. 194: ProControl-Frühwarnsystem (2 von 2) ................................ 239 Abb. 195: Kennzahlenarten .................................................................. 240 Abb. 196: Schema für die Definition einer Kennzahl........................... 241 Abb. 197: Kennzahlen für das Projektcontrolling................................. 242 Abb. 198: Vergleich des Moduls PS von SAP R/3 und MS-Project..... 250 Abb. 199: Integrationsbeziehungen des Moduls PS.............................. 251 Abb. 200: Darstellung der Projektstruktur im PS-Modul von SAP R/3 ............................................................................... 252 Abb. 201: Projektplanung und -steuerung mit SAP R/3 bei der Outokumpu Technology GmbH............................... 253 Abb. 202: Zentrale Planungsmaske in MS-Project ............................... 254 Abb. 203: Systematische Bewertung und Auswahl von Projektmanagementsoftware mit der Nutzwertanalyse........ 256 Abb. 204: Datenanalyse mittels „Dice“ ................................................ 258 Abb. 205: Datenanalyse mittels „Slice“................................................ 259 Abb. 206: Datenanalyse mittels „Drill-Down“ ..................................... 259 Abb. 207: Datenanalyse mittels „Roll-Up“........................................... 259 Abb. 208: Datenversorgung eines MIS................................................. 260 Abb. 209: Wesentliche Hypercubes für die Analyse ............................ 261 Abb. 210: Hypercubes Projektcontrolling und Ressourcen .................. 263 Abb. 211: Hyperbrowser im Delta Master............................................ 265 Abb. 212: Abweichungsanalyse für die Earned Value-Kennzahlen ..... 266

XV

Abbildungsverzeichnis Abb. 213: Portfoliodarstellung der Leistungs- und Kostenabweichung ............................................................... 268 Abb. 214: Identifikation auffälliger Arbeitspakete ............................... 270 Abb. 215: Identifikation der Verursacher einer Abweichung ............... 271

XVI

1

Überblick über das Projektcontrolling

„Die Aufgabe des Projektcontrollers ist es nicht, alle Lösungen für die Projekte des vergangenen Jahres zu kennen.“

Sie erwerben in diesem Kapitel ein Grundverständnis für Projektcontrolling. Zunächst wird erläutert, wann man von einem Projekt sprechen kann und welche Aufgaben und Ziele das Projektmanagement hat. Auch die wesentlichen Faktoren für den Projekterfolg werden angesprochen. Ausgehend vom Begriff des allgemeinen Unternehmenscontrollings werden die Aufgaben des Projektcontrollings beleuchtet. Insbesondere die Zusammenhänge zwischen Projektmanagement, Controlling und Projektcontrolling werden geklärt. Dabei werden auch die Schnittstellen zum Projektmanagement und zum Controlling deutlich. Außerdem beschäftigen Sie sich mit der Frage, wer für das Projektcontrolling zuständig sein kann, wie es in die Aufbauorganisation eingeordnet wird, welche Anforderungen man an einen Projektcontroller stellen sollte und was bei der Einführung eines Projektcontrollings zu beachten ist.

1

1 Überblick über das Projektcontrolling

1.1

Projekt und Projektmanagement

Viele Unternehmen sehen sich neuen Aufgabenstellungen gegenüber. Ursache sind die Internationalisierung, die häufigen Produktwechsel und der Zwang zu permanenter Veränderung. Dies wird besonders in sehr dynamischen Branchen wie der Unterhaltungselektronik deutlich. Gab es dort vor 30 Jahren fast nur nationale Anbieter mit vergleichsweise einfachen Produkten, findet man heute weltweit tätige Hersteller, die technisch hoch anspruchsvolle Produkte vermarkten. Die Unternehmen müssen darüber hinaus ständig Neuerungen präsentieren: kleinere Geräte, leistungsfähigere Technik, zeitgemäßes Erscheinungsbild usw. Der Anteil der Routineaufgaben nimmt durch diese Einflüsse ab, während zunehmend komplexe und neuartige Aufgaben anstehen, die in Form von Projekten abgewickelt werden müssen.

Was ist ein Projekt? Beispiele typischer Projekte sind in der Abb. 1 aufgeführt. Dort werden die unterschiedlichen Projekte auch nach Projektart, Projektgröße und Projektkomplexität unterteilt. Projektgröße

Organisation

Forschung und Entwicklung

Investition

1

2

3

Projektkomplexität 1 2 3

Anschaffung einer komplexen Anlage Bau einer neuen Werkhalle Gründung eines Produktionswerks Entwicklung eines neuen PKW Entwicklung eines Medikaments Entwicklung eines Software-Moduls Optimierung von Prozessen Zertifizierung nach ISO 9000 Organisation eines Firmenjubiläums 1 = groß; 2 = mittel; 3 = klein

Abb. 1: Projektarten

2

1.1 Projekt- und Projektmanagement

Von einem Projekt spricht man, wenn bestimmte Merkmale erfüllt sind: Zeitliche Begrenzung Im Unterschied zu Daueraufgaben besitzen Projekte einen genau festgelegten Anfang und ein definiertes Ende. Sie sind meist zeitkritisch. Insbesondere bei Entwicklungsprojekten hängt der Unternehmenserfolg davon ab, dass ein neues Produkt schnell und mit hoher Qualität auf den Markt kommt. Finanzielle und personelle Restriktionen Das Kostenbudget und die Anzahl der im Projekt mitarbeitenden Personen sind beschränkt. Auch Räume, Hard- und Softwareausstattung und andere Ressourcen stehen nur in einem begrenzten Umfang zur Verfügung. Man muss deshalb genau überlegen, welche Mitarbeiter und Ressourcen in welcher Menge benötigt werden, um die Projektziele zu erreichen. Auch die voraussichtlich anfallenden Kosten sind zu bestimmen. Festgelegtes Ziel Ohne Ziel kein Projekt! Probleme entstehen, wenn am Anfang eines Projektes keine messbaren Ziele definiert werden. Man ist also gut beraten, die Projektziele zusammen mit dem Management genau festzulegen und schriftlich zu fixieren. Aus den Zielen leiten sich die Maßnahmen ab. Bereichsübergreifende Teamarbeit Projekte zeichnen sich darin aus, dass mehrere Stellen aus meist unterschiedlichen Fachbereichen beteiligt sind. Die Arbeit eines Teams aus verschiedenen Spezialisten führt zu sehr wirksamen und bei allen Beteiligten akzeptierten Lösungen. Häufig wird für das Projekt eine zeitlich begrenzte eigene Organisation neben der normalen Hierarchie eingerichtet. Großer Umfang Planung, Steuerung und Kontrolle von Projekten verursachen einen hohen Aufwand, den man nur bei besonders umfangreichen Vorhaben investieren sollte. Hohe Unsicherheit und großes Risiko Typisch für viele Projekte ist, dass man anfangs nicht weiß, ob die angestrebten Ziele überhaupt erreicht werden können. Häufig wird der Zeitrahmen nicht eingehalten, die Kosten werden weit überschritten, oder man ist nicht in der Lage, die erhoffte Leistung zu erbringen.

3


Eine Definition des Begriffs Projekt ist auch in der DIN 69901 niedergelegt. Dort heißt es: 'HILQLWLRQ

Ein Projekt ist „ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist“. In der Praxis fehlen häufig eindeutige Kriterien für Projekte. Teilweise wird jede größere Aufgabe als Projekt bezeichnet. Manchmal hilft man sich auch mit einfachen Vereinbarungen: x x

Jedes Vorhaben über 50.000 € ist ein Projekt. Wenn mindestens zwei Bereiche beteiligt sind, handelt es sich um ein Projekt.

Es ist Aufgabe des Projektcontrollings, eindeutige Regeln für ein Projekt zu erarbeiten. Ein Beispiel dafür sind die Kriterien, welche das zentrale Projektcontrolling der Versicherungskammer Bayern vorgibt.17 Kriterien

A Großprojekt

B Projekt

C Kleinprojekt

Projektkosten in Tsd. EUR

> 2.500

250 – 2.500

25 - 250

Projektdauer in Monaten

>18

9 – 18

4

3–4

1–2

Komplexität/ Risiko

sehr groß

groß

gering

Bedeutung

sehr groß

groß

mittel

Maßnahmen können im Umfang durchaus Projektcharakter haben (z.B. Mailingaktionen). Es fehlt aber die neuartige Aufgabenstellung.

Abb. 2: Projektkriterien der Versicherungskammer Bayern Auftraggeber von A- und B-Projekten ist immer der Vorstand. Der Projektleiter muss für A-Projekte zu 100 Prozent, für B-Projekte zu mehr als 50 Prozent freigestellt werden. Die Zurich Gruppe Deutschland verwendet den Begriff der Initiative und versteht darunter alle wertigen Vorhaben, die zur Ausrichtung, Erneuerung und Performancesteigerung des Unternehmens dienen. Projekte sind nach diesem Verständnis nur eine Teilmenge der Initiativen. 17

4

Ferrarese, N., Controlling in der Multiprojektumgebung, Seminar Kostencontrolling in Projekten, 20.9.02 in Köln, Management Circle.


Projektcontrolling

PS

Projektcontrolling

PS

zwei- bis dreimonatlich keine

Projektcontrolling

PS

bei Bedarf

Projektcontrolling

PS

keine

CO

keine

CO

keine

CO

keine

Liste aller Änderungen

monatlich

Realisierungsplanung

Projektberichte

PS

Cash Flow-Planung

SAP R/3

Projektcontrolling

Risikoanalyse

Zuständigkeit

Kundenaufträge über eine Mio.€ Kundenaufträge von 100.000 bis eine Mio.€ Kundenaufträge unter 100.000 € Kundenaufträge in der Gewährleistungsphase Ersatzteilaufträge

Startkalkulation

Projekt Kategorie

Führen im Auftragsbestand

Bei der Outokumpu Technology GmbH gilt für alle Kundenaufträge, dass sie innerhalb der kaufmännischen Systeme als Projekt angelegt werden, so dass die Erfassung der direkten Kosten, der Eigen- und Fremdleistungen sowie der Erlöse gewährleistet ist. Zur Überwachung der Projekte aus dem Auftragsbestand gilt eine Klassifizierung, die sich generell nach der Auftragsgröße bemisst (vgl. Abb. 3).

X

X

X

X

X

X

X

X

X

X

X X X

Angebotsprojekte

UnternehmensControlling F&E-Projekte UnternehmensControlling Gemeinkosten-Projekte UnternehmensControlling

Abb. 3:

Übersicht der Projekt-Kategorien der Outokumpu Technology GmbH

Eine Festlegung kann außerdem entsprechend der Komplexität des Projektes, beispielsweise danach, ob Partner an der Abwicklung beteiligt sind, erfolgen. Kleine Aufträge unter 100.000 € werden aufgrund ihrer kurzen Abwicklungszeit nur zum Auftragsstart beplant und bei Abrechnung buchhalterisch realisiert. In diesem Fall findet im Projektcontrolling keine aktive Überwachung statt. Projekten von 100.000 € bis unter eine Million € wird ein Projektcontroller zugeordnet, und sie unterliegen der monatlichen Bericht-

5


erstattung, d. h., über sie wird bei Bedarf oder im zwei- oder mehrmonatigem Rhythmus berichtet. Für Kundenprojekte ab einem Auftragswert von einer Million € gilt die anteilige bilanzielle Realisierung entsprechend des Fertigstellungsgrades. D. h., die kontinuierliche Schätzung des Projektergebnisses erhält eine besondere Bedeutung, da im Gegensatz zu den vorgenannten Auftragsgruppen das Unternehmensergebnis zeitnah durch die Auftragssituation beeinflusst wird. Es erfolgt neben der aktiven Überwachung und der kontinuierlichen Schätzung des Projektergebnisses eine Cash Flow-Betrachtung, eine Planung des Realisierungsfortschritts sowie eine regelmäßige Risikoanalyse. In dieser Kategorie der wichtigsten Projekte zählt der Projektcontroller zum Projektkernteam. Die Projekte sollten auch in Kategorien eingeteilt werden. Im Beispiel der Versicherungskammer Bayern sind das je nach Bedeutung A-, B- und C- Projekte. Die Zurich Gruppe Deutschland definiert Projekte für Prozessoptimierung, Personalentwicklung, Optimierung der Finanzsteuerung, Optimierung des Vertriebs u.a. Eine gut durchdachte Projektkategorisierung ermöglicht die Sammlung und Auswertung von Informationen und Erfahrungswerten, die für Projekte einer Kategorie gelten. Das erleichtert die Planung und liefert durch den Vergleich der Projekte einer Kategorie auch aussagefähige Informationen für die Kontrolle (Benchmarking). Bei der Durchführung von Projekten tauchen Fragen auf wie: x x x x

Welche und wie viele Mitarbeiter werden benötigt? Stehen zu jeder Zeit genügend Mitarbeiter zur Verfügung? Welche Kosten fallen an? Welche Auswirkungen haben Terminverzögerungen bei einzelnen Aufgaben auf das gesamte Projekt?

Um diese und andere Fragen kurzfristig beantworten zu können, müssen die Verantwortlichen zu jeder Zeit einen Überblick über das Projekt haben. Die Grundlage dafür bildet das Projektmanagement. Wie wichtig systematisches Projektmanagement für den Projekterfolg ist, zeigt die Erfahrung aus vielen abgeschlossenen Projekten: x Projekte werden zunehmend komplexer; deswegen erreicht man die gesetzten Ziele oft nicht. Das zeigt sich vor allem in Großprojekten. Der Airbus A400M ist ein militärisches Transportflugzeug, das von der Airbus GmbH entwickelt wird, um unter

6


x

x

anderem die deutsch-französische Transall zu ersetzen. 2009 war das Projekt 5 Milliarden € über dem Budget und drei bis vier Jahre hinter dem Zeitplan. Außerdem war das Flugzeug 12 Tonnen zu schwer.18 Vor allem Forschungs- und Entwicklungsprojekte sind mit einem erheblichen Risiko behaftet. Von 100 dieser Projekte sind 57 technisch, aber nur zwölf wirtschaftlich erfolgreich. Die Trefferquote geht dabei von Branche zu Branche weit auseinander. Für Forschungs- und Entwicklungsprojekte in der Pharmaindustrie lautet das Verhältnis 1000 zu eins, in Elektronikunternehmen 100 zu eins, in der Telekommunikation, in der Medienund Softwarebranche zehn zu eins.19 Viele Projekte sind fehlerträchtig. Die Standish Group stellte in ihrem viel beachteten „Chaos Report“ fest, dass 31 Prozent aller Softwareprojekte vorzeitig abgebrochen werden.20 Ein erheblicher Teil der in Softwareprojekten erstellten Programme kann erst nach erheblichen Modifikationen oder überhaupt nicht genutzt werden. So hatte das Projekt „Fiskus“, in dem eine einheitliche Verwaltungssoftware für 700 Finanzämter erstellt werden sollte, nach zwölf Jahren Entwicklungszeit nur zwei kleine Programmteile als Testversion, 1,6 Millionen Zeilen weitgehend nutzloser Programmcode und 50.000 Seiten Dokumentation vorzuweisen.21

Was versteht man unter Projektmanagement? Die DIN 69901 beschreibt Projektmanagement wie folgt: „Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projektes.“

'HILQLWLRQ

Projektmanagement umfasst also das x

WAS eines Projektes (alle Führungsaufgaben; das sind nach der klassischen Managementlehre Planung, Kontrolle, Organisation und Personalführung), z. B.:

18

The New York Times, 11. Juni 2009. Eglau, H. u. a., Durchstarten zur Spitze – McKinseys Strategien für mehr Innovation, Frankfurt 2000, S. 10. Die Studie ist unter www.standishgroup.com einsehbar. Die Zeit, Nr. 30, 15. Juli 2004, S. 25.

19 20 21

7


x

Vereinbarung der Projektziele, Planung, Steuerung und Kontrolle der personellen und finanziellen Ressourcen sowie des Projektfortschritts;

WER eines Projektes (Organisation), z. B.: Wahl eines geeigneten Organisationsmodells, Festlegung des Projektteams, Organisatorische Einbindung der Projektgruppe in die Unternehmenshierarchie, Einrichtung der Entscheidungsinstanzen (Lenkungsausschuss);

x

WIE eines Projektes (Instrumente, Techniken, Methoden), z. B.: Festlegung der Techniken für die Terminplanung, Methoden für die Termin- und Kostenkontrolle, DV-Tools zur Planung und für das Berichtswesen.

Projektmanagement beinhaltet nicht die Aktivitäten, die das zu lösende Problem selbst betreffen, insbesondere nicht die fachlichen Beiträge zur Problemlösung, sondern das Management des Problemlösungsprozesses.

Welche grundlegenden Ziele verfolgt man mit Projektmanagement? Projektmanagement dreht sich immer um die Ziele des „magischen Dreiecks“: Dauer

Wirtschaftlicher Erfolg

Leistung

Abb. 4: Das „magische Dreieck“ des Projektmanagements x x x

8

Sachziele geben die gewünschte Leistung und Qualität an. Terminziele beschreiben das gewünschte Projektende und bestimmte Zwischentermine. Kostenziele legen Obergrenzen für die Projektausgaben fest. Bei Projekten für einen externen Auftraggeber muss die Betrachtungsweise auf den wirtschaftlichen Erfolg ausgeweitet werden.


Die drei Ziele beeinflussen sich gegenseitig. Muss man z. B. den Fertigstellungstermin verkürzen, ist es erforderlich, mehr Personal einzusetzen oder Überstunden anzuordnen. In beiden Fällen steigen die Kosten. Man kann alternativ aber auch die Leistung reduzieren. In kaum einem Projekt wird man alle Teilziele im selben Maße erreichen können. Deswegen ist es notwendig, vor Projektbeginn Zielpräferenzen festzulegen. Dies erleichtert auch die Steuerung des Projektes.

Welche Erfolgsfaktoren muss Projektmanagement berücksichtigen? Systematisches Vorgehen im Rahmen eines auf das Unternehmen abgestimmten Projektmanagements ist eine wichtige Voraussetzung, um Projekte erfolgreich abzuwickeln. In der betrieblichen Praxis treten oft gerade deswegen Probleme auf, weil Projektmanagement nicht konsequent angewendet wird. Das verdeutlichen diverse Studien (vgl. z. B. Abb. 5). Schlechte Kommunikation Unklare Anforderungen und Ziele Kompetenzstreitigkeiten, Egoismen Fehlende Ressourcen Mangel an qualifizierten Mitarbeitern Fehlende Projektmanagement-Erfahrung Fehlende Unterstützung des Managements Unzureichende Projektplanung Mangelhaftes Stakeholder Management Fehlende Projektmanagementmethodik Technische Anforderungen zu hoch Ϭй

ϭϬй ϮϬй ϯϬй ϰϬй ϱϬй ϲϬй ϳϬй

Abb. 5: Ursachen für das Scheitern von Projekten22 Die erfolgreiche Projektabwicklung erfordert neben einem angemessenen Methodeneinsatz vor allem eine gute Kommunikation und Teamgeist (vgl. Abb. 5). Zu diesen „weichen Faktoren“, die für den Erfolg eines Projekts entscheidend sind, gehören auch die Beziehungen innerhalb des Projektteams und zur Außenwelt oder die Art und Weise des miteinander Umgehens. Die Wichtigkeit dieser Faktoren kann durch die so genannte „Eisberg-Theorie“ ausgedrückt werden. Sie besagt, dass 22

GPM, PA Consulting Group (Hrsg.), Ergebnisse der Projektmanagement Studie 2007.

9


entsprechend dem unsichtbaren Teil eines Eisbergs 7/8 des Projekterfolgs von den Beziehungen zwischen den Projektbeteiligten abhängen und nur 1/8 von der Sachebene, z. B. den eingesetzten Instrumenten. Auch wenn diese Theorie auf den ersten Blick extrem erscheint, zeigt sie doch den Stellenwert des „menschlichen Faktors“. Die Qualität des Projektmanagements wird maßgeblich durch den Projektleiter beeinflusst. Er muss Fachwissen und methodische Kenntnisse aufweisen, aber vor allem die „weichen Erfolgsfaktoren“ im Griff haben (vgl. Abb. 6). Fachwissen

Instrumente

Psychologie

Projekterfolg

Methodik

Erfahrung

Abb. 6: Anforderungen an den Projektleiter 1.2

Controlling

Controlling unterstützt die Unternehmensführung bei der Planung und Kontrolle und sichert die Versorgung des Managements mit entscheidungsrelevanten Informationen.23 Dazu gehört die Gestaltung der genannten Aufgabenbereiche, also die Schaffung von Strukturen und Prozessen (so genannte systembildende Funktion des Controllings). Man muss z. B. regeln, welche Pläne zu erstellen sind und wie deren Einhaltung kontrolliert werden kann. Es müssen auch die Verantwortlichkeiten, also z. B. die für den einzelnen Plan zuständige Organisationseinheit, festgelegt werden. Außerdem sind die anzuwendenden Instrumente zu bestimmen.

23

10

Fiedler, R., Gräf, J., Einführung in das Controlling, 3. Aufl., München, Wien 2010 (in Vorbereitung).

1.3 Projektcontrolling

Controlling hat zudem die Aufgabe, zwischen Planung, Kontrolle und Informationsversorgung zu koordinieren (so genannte systemkoppelnde Funktion des Controllings).24 Die Daten der Planung sind z. B. so aufzubereiten, dass eine Kontrolle möglich wird. Auch innerhalb der Planung und Kontrolle sind Abstimmungen erforderlich. Es muss z. B. der Absatzplan mit dem Produktionsplan und dieser wiederum mit dem Investitionsplan koordiniert werden. Eine weitere, sehr wesentliche Abstimmung hat zwischen der strategischen Sichtweise, also der langfristigen Zielsetzung, und der operativen Perspektive zu erfolgen. 1.3

Projektcontrolling

Die DIN 69901 beschreibt das Projektcontrolling als Regelkreis: „Sicherung des Erreichens der Projektziele durch: Soll-Ist-Vergleich, Feststellung der Abweichungen, Bewerten der Konsequenzen und Vorschlagen von Korrekturmaßnahmen, Mitwirkung bei der Maßnahmenplanung und Kontrolle der Durchführung“.

'HILQLWLRQ

Die folgende Übersicht enthält einige konkrete Aussagen verschiedener Autoren zu den Aufgaben des Projektcontrollings.

Hügler, G.25

Solaro, D. u. a.26 Alter, R.27

24

25 26 27

x Aufbau und Pflege eines Systems zu Projektplanung und Projektkontrolle x Einrichten des Projektberichtswesens x Abstimmungsaufgaben bei der Zielbildung x Planung der Kosten und des Finanzmittelbedarfs x Soll-Ist-Vergleiche und Abweichungsanalyse x Berichterstattung und Organisation von Projektmeetings x Rentabilitätsberechnungen, Liquiditätsberechnungen x Mitlaufende Kalkulation, Restkostenschätzung x Risikoanalyse und Risikobewertung x Projektorientiertes Rechnungswesen, Berichtswesen x Beurteilung von Projektalternativen x Mitwirkung bei der Erstellung des Abschlussberichts

/LWHUDWXU

Hórvath, P., Controlling, 11. Aufl. München 2008. Küpper, H., Controlling. Konzeption, Aufgaben und Instrumente. 5. Aufl. Stuttgart 2008. Hügler, G., Controlling in Projektorganisationen, München 1988. Solaro, D. u. a., Projekt-Controlling, Stuttgart 1979. Alter, R., Integriertes Projektcontrolling, Gießen 1991.

11

1 Überblick über das Projektcontrolling x Mitwirkung bei der Erarbeitung von Projektzielen o Informationsbereitstellung o Koordination und Moderation o Handhabung von Zielkonflikten x Unterstützung des Risikomanagements x Mitwirkung bei der Festlegung der Projektorganisation x Entwicklung und Einrichtung eines Planungs-, Kontrollund Informationssystems x Mitwirkung bei der Maßnahmenplanung x Durchführung der Kostenplanung x Detaillierung der Ressourcen- und Terminplanung x Überwachung von Kosten, Leistungen und Terminen x Durchführung der Abschlusskontrolle und Abschlussdokumentation x Pflege und Weiterentwicklung des Projektmanagementsystems Krüger, A., x Mitwirkung bei der Projektstrukturierung x Prüfung der Arbeitspakete Schmolke, G., Vaupel, x Unterstützung der Personalführung x Koordination von Teilplänen R.29 x Gewährleistung einer richtlinienkonformen Projektplanung x Überwachung der im Projekt realisierten Wertschöpfung x Sicherstellung der Informationsversorgung x Mitwirkung bei der Gestaltung des Berichtswesens x Sicherstellung der Übereinstimmung von Verantwortung und Kompetenz der Projektbeteiligten x Hilfe bei der Auswahl projektbezogener Anreizsysteme Hilpert, N., x Projekte begleiten, indem der Projektleiter entlastet wird Rademacher, x Sicherstellung der Transparenz des Projektgeschehens x Unterstützung der Planung G., Sauter, x Unterstützung der wirtschaftlichen Projektabwicklung 30 B. x Entwicklung und Pflege von Methoden und Hilfsmitteln Koreimann, x Laufende Überwachung der Projekte x Beratung der Projektinstanzen D.31 x Definition der Kontrollobjekte x Finanzcontrolling steht gleichberechtigt neben dem Inhaltscontrolling

Daum, A., Lawa, D.28

Abb. 7: Aufgaben des Projektcontrollings

28 29 30 31

12

Daum, A., Lawa, D., Projekt-Controlling: Aufgaben und Instrumente, in: Steinle, C., Bruch, H. (Hrsg.), Controlling. Stuttgart 1998, S. 909. Krüger, A., Schmolke, G., Vaupel, R., Projektmanagement als kundenorientierte Führungskonzeption, Stuttgart 1999, S. 214 ff. Hilpert, N., Rademacher, G., Sauter, B., Projekt-Management und ProjektControlling im Anlagen- und Systemgeschäft, Frankfurt 2001, S. 11 ff. Koreimann, D., Projekt-Controlling, Weinheim 2005, S. 65 ff.


Die Daimler AG beschreibt die Aufgaben für die Stelle des Projektcontrollers wie folgt (gekürzter Auszug): Beim Projekt-Controller liegt der Fokus auf einem (oder mehreren) Projekt(en). Er unterstützt den Projektleiter sowohl im FinanzControlling des Projekts als auch in der Früherkennung von Chancen, Gefahren und Risiken für das Projekt, wofür er Analysen bereitstellt und Verbesserungsmöglichkeiten vorschlägt. Verantwortung, Aufgaben und Kompetenzen des ProjektControllers: • • • • • • •

unterstützt das Erreichen der Projektziele, erstellt die Kostenplanung und führt das Leistungs-, Terminund Kosten-Controlling durch, erhebt Ist-Daten der Projekte, wertet aus und prognostiziert, schafft Transparenz im Projekt und im projektrelevanten Umfeld, unterstützt das Risikomanagement für das Projekt, führt ein an der Projektlaufzeit orientiertes Berichtswesen ein und liefert Input. Sorgt für den kurzfristigen Aufbau und Abbau eines Controllingsystems und für die Weitergabe der Lessons Learned.

Die Aussagen aus der DIN 69901, der Literatur und dem Unternehmensbeispiel verdeutlichen, dass sich ein Projektcontrolling nicht auf die Planung und Kontrolle der Kosten beschränkt. Der Servicecharakter eines Projektcontrollings, das alle Projektmanagementaufgaben unterstützt, ist deutlich erkennbar. Für das Verständnis ist es wichtig, die Stellung des Projektcontrollings zum allgemeinen Unternehmenscontrolling und zum Projektmanagement herauszuarbeiten (vgl. Abb. 8). 32

32

Die Begriffe Einzelprojektcontrolling, Multiprojektcontrolling und strategisches Projektcontrolling werden nicht einheitlich verwendet. Üblich ist es auch, das strategische Projektcontrolling als strategisches Multiprojektcontrolling oder Portfolio-Controlling zu bezeichnen.

13


Strategisch

Strategisches Projektcontrolling (Portfolio-Controlling)

Strategisch

Operatives Multiprojektcontrolling

Operativ

EinzelProjektcontrolling

Operativ

CONTROLLING

PROJEKTMANAGEMENT

PROJEKT-

CONTROLLING Abb. 8: Stellung des Projektcontrollings Projektcontrolling gewährleistet die Verbindung der Projektplanung, -steuerung und -kontrolle mit dem Unternehmenscontrolling. Dies ist wichtig, da die Daten der Projekte in erheblichem Maße den Erfolg und die Liquidität eines Unternehmens beeinflussen. Projektcontrolling kann dabei als Spezialfunktion des Unternehmenscontrollings neben Vertriebs-, Beschaffungs-, Produktions-, Logistik-, Forschungs- und Entwicklungs-, Personal-, DV- sowie Finanz- und Investitionscontrolling gesehen werden. Projektcontrolling unterstützt die Projektleitung bei der Wahrnehmung ihrer Führungsaufgaben im Rahmen des Projektmanagements (vgl. Abb. 9). Es kümmert sich zum einen um die grundlegende Gestaltung der Strukturen und Prozesse, die für eine effiziente Projektabwicklung erforderlich sind. Dafür sind die Aufgaben, die durch das Projektcontrolling wahrgenommen werden, festzulegen. Außerdem sollten auch diejenigen Stellen eindeutig bestimmt werden, welche diese Aufgaben wahrnehmen. Neben dem Projektcontroller kann z. B. auch ein Project Office, das Qualitätsmanagement oder der Vertrieb Projektcontrollingaufgaben übernehmen. Zudem muss man klären, mit welchen Instrumenten Projekte abgewickelt werden und welche Informationen bereit zu stellen sind. Auf der Basis der festgelegten Strukturen kann sich das Projektcontrolling in vielfältiger Weise um die Koordination und laufende Unterstützung der Projektmanagementaufgaben kümmern. Die Kontrolle beginnt bereits zu Beginn der Planung (Planungskontrolle) und schafft so die Grundlage für die Durchführungskontrolle.

14


Strategisches P.controlling Planung Kontrolle Prozessgestaltung Multiprojektcontrolling

Planung Kontrolle

Prozessgestaltung

Aufgaben Prozessgestaltung Planung Kontrolle Einzelprojektcontrolling Verantwortliche Aufgaben Instrumente Verantwortliche Aufgaben Informationen Instrumente Verantwortliche Koordination Informationen Instrumente Koordination Informationen

Koordination

Abb. 9: Aufgaben des Projektcontrollings Zu unterscheiden sind Einzelprojektcontrolling, operatives Multiprojektcontrolling und strategisches Projektcontrolling: •

Ziel des Einzelprojektcontrollings ist es, das Projektmanagement so zu unterstützen, dass das Projekt bezüglich der Eckpfeiler Qualität und Funktionalität, Kosten und Zeit erfolgreich abgewickelt wird. Ein ganzheitlicher Lösungsansatz für das Einzelprojektcontrolling orientiert sich an den Lebenszyklusphasen des Projektes und stellt den Verantwortlichen sowohl phasenspezifische (z. B. zur Angebotskalkulation oder für den Projektabschlussbericht) wie auch phasenübergreifende Instrumente (wie z. B. Projektstrukturpläne oder Werkzeuge zur Projektadministration und -information) zur Verfügung.

•

Während das Einzelprojektcontrolling auf die Gesamtlaufzeit eines Projektes bezogen und damit kalenderunabhängig ist, werden beim operativen Multiprojektcontrolling mehrere Projekte (Projektgruppen bzw. die Projektgesamtheit) mit unterschiedlichen Terminen und Fertigstellungsständen für eine Abrechnungsperiode zusammengefasst betrachtet (vgl. Abb. 10). Ziel ist es, die Projektprogramm- und Projektablaufplanung unter Beachtung

der Kapazitätsgegebenheiten, der Kosten- und Finanzwirkungen sowie möglicher weiterer Nebenbedingungen (z. B. strategische Ziele des Unternehmens)

15


zu einem gemäß den Bereichs- bzw. Unternehmenszielen bestmöglichen Gesamtgefüge zu koordinieren. Einzelprojektcontrolling - Fokus: Projekt -

Multiprojektcontrolling - Fokus: Periode Projektgruppen

Projektgesamtheit

Planung

Planung

Planung

Ressourcen, Kosten/Ergebnis ...



Kontrolle

Kontrolle

Kontrolle




Abb. 10: Bausteine des Einzel- und Multiprojektcontrollings Die wesentlichen Herausforderungen des Multiprojektcontrollings liegen in der

16

Periodisierung der Erfolgs- und Liquiditätsdaten für die Projekte. In der Praxis zeigt sich, dass zwar mit Projektbeginn eine erste Verteilung der Projektinformationen auf die Perioden vorgenommen wird, es aber Probleme bei der laufenden Aktualisierung dieser Informationen gibt. Ursachen dafür sind der enorme Arbeitsaufwand (z. B. aufgrund der hohen Detaillierung der Planung), die mangelnde Unterstützung durch geeignete DV-Werkzeuge oder die fehlenden Informationen zum Projekt, weil z. B. die neuesten Verträge bzw. Vereinbarungen dem Planenden nicht vorliegen. Koordination der Ressourcen. Dazu gehören die Transparenz über die verfügbaren Ressourcen, ihre spezifischen Fähigkeiten und ihr Auslastungsgrad im Betrachtungszeitraum. Nicht selten zeigt es sich, dass es z. B. Projektmitarbeiter gibt, die ständig zu 150 Prozent ausgelastet sind, während andere noch freie Kapazitäten haben, weil ihre Fähigkeit und/oder ihre tatsächliche Auslastung nicht transparent sind. Verdichtung der Ergebnis-, Finanz- und Risikoinformationen der Einzelprojekte zur Projektgruppe bzw. der Projektgesamtheit. Voraussetzung dafür ist, dass die Projekte ab einer bestimmten Verdichtungsebene in einer vergleichbaren Struktur geplant werden und zeitnah aggregierbar sind. Hier fehlen häu-


fig eine gemeinsame Planungsmethodik sowie eine einheitliche DV-Unterstützung. Die Instrumente des Multiprojektcontrollings sind im Prinzip die gleichen wie beim Einzelprojektcontrolling, nur mit dem Unterschied, dass mehrere Projekte gleichzeitig bzw. zu einer Gruppe verdichtet betrachtet werden. •

Projektcontrolling beschränkt sich nicht auf die rein operativen Projektaspekte, sondern sollte sich in Form des strategischen Projektcontrollings auch um strategische Aufgabenstellungen des Projektmanagements kümmern. Dazu gehört insbesondere die Bereitstellung von Informationen und Instrumenten zur effektiven Projektbewertung und Projektauswahl.

Zusammenfassend kann Projektcontrolling wie folgt charakterisiert werden: Projektcontrolling unterstützt das Projektmanagement bei der Gestaltung und laufenden Abstimmung der strategischen und operativen Projektmanagementaufgaben, insbesondere bei der Projektplanung und -kontrolle. Projektcontrolling sichert so die Rationalität des Projektmanagements.33

Definition

Projektcontrolling wird bei Lufthansa Systems wie folgt beschrieben: „Maßnahmen zur Beurteilung von Einzelprojekten, namentlich auch um Projektabbruchentscheidungen, aber auch Projektbeschleunigungen (mit entsprechenden Kostenerhöhungen) zu fundieren“. Im Einzelnen werden bei Lufthansa Systems die folgenden Aufgaben als essentiell für das Projektcontrolling angesehen: •

Projektplanung Die Aufgliederung des Projekts in Phasen und in Arbeitspakete steht im Vordergrund. Bei der Bildung von Arbeitspaketen werden analoge Prinzipien wie bei der Bildung von Kostenstellen angewendet (Aufgabenverantwortlicher, hinreichendes Arbeitspaketvolumen, Beeinflussbarkeit u. a.).

33

In Anlehnung an Weber, der konstatiert: „Controlling hat grundsätzlich die Aufgabe, die Rationalität des Managements zu sichern.“ Vgl. Weber, J., Blum, H., Logistik-Controlling - Konzept und empirischer Stand, in: Weber, J., Kunz, J. (Hrsg.), Empirische Controllingforschung, Wiesbaden 2003, S. 229.

17


•

Stufung der Projektplanungsmaßnahmen Es hat sich bewährt, zunächst Kernbestandteile des Projektes zu erfassen, während Randarbeitspakete erst nachfolgend im Projektplan ausgearbeitet und verfeinert werden.

•

Projektkontrolle Es werden Plan- und Istzahlen verglichen sowie die noch zu erbringenden Aufwände prognostiziert. Diese Daten werden auch zum Aufbau von Projekterfahrungsdatenbanken verwendet.

•

Projektsteuerung Die Steuerung orientiert sich an den zeitlichen Meilensteinen, bei denen vordefinierte Projektziele erreicht sein müssen (= Leistungscontrolling). Darüber hinaus erfolgt zu diesen Zeitpunkten eine Budgetkontrolle, um auch von außen rechtzeitig steuernd in den Projektablauf eingreifen zu können.

Zusätzlich werden die Projekte ab einer bestimmten Größenordnung einer standardisierten Wirtschaftlichkeitsrechnung unterzogen. Die projektbezogene Wirtschaftlichkeitsrechnung dient als Vorphase der wesentlich komplexeren Investitionsrechnung. Die Investitionsrechnung ist eine Entscheidungsrechnung für neue Investitionen und Maßnahmen, die zur Veränderung des Erfolgs (Einzahlungen, gesparte Auszahlungen) und der Kapitalintensität beitragen. Die Aufgaben des Projektcontrollings bei der Outokumpu Technology GmbH gliedern sich im Wesentlichen in die Beratungsfunktion gegenüber dem Projektverantwortlichen und die Berichtspflicht gegenüber dem Management. Hinsichtlich der operativen Unterstützung des Projektleiters und aller beteiligten Fachdisziplinen nimmt der Projektcontroller die Aufbereitung aller relevanten Informationen wahr, um eine Umsetzung in die neueste Erwartungsrechnung für die Projekterfolgskennzahlen zu gewährleisten. Er hat darüber hinaus die Aufgabe, Abweichungen zu überwachen und wichtige Informationen dergestalt aufzubereiten, dass möglichst eine Umsetzung im Claim-Management gegenüber dem Kunden erfolgen kann. Der Projektcontroller ist darüber hinaus Ansprechpartner für alle Mitglieder des Projektteams hinsichtlich kostenrelevanter Fragen. Er versorgt somit alle an budgetrelevanten Entscheidungen beteiligten Personen mit den notwendigen Informationen. Zur Darstellung aller Projektdaten des Auftragsbestands für die Periodenabschlüsse sowie zur Steuerung des Unternehmens- bzw. 18


der Spartenergebnisse sind Aktivitäten des Multiprojektcontrollings gefragt. Hinzu kommen die Informationen, die in Steuerungsgremien zur Information aller beteiligten Interessenvertreter benötigt werden. Für beide Aufgabengebiete wurden spezifische Berichte entwickelt, die in späteren Abschnitten erläutert werden.

Wer ist für das Projektcontrolling zuständig? Ab einer bestimmten Projektanzahl und -größe werden spezielle Stellen nötig sein, die Projektcontrollingaufgaben hauptberuflich erfüllen (vgl. Abb. 11). Manche Aufgaben des Projektcontrollings übernehmen auch andere Abteilungen, wie Qualitätssicherung, Vertrieb und Organisation. Unternehmen, die aus Kostengründen keine eigenen Stellen für Projektcontroller einrichten wollen, können auf externe Controller zurückgreifen. Dieses „Controlling auf Zeit“ wird oft von Unternehmensberatern angeboten.

TR Ä G E R D E S PC

Selbstcontrolling PC durch die Projektmitarbeiter

FremdControlling PC durch Spezialisten

Selbstcontrolling PC durch den Projektleiter

Internes Controlling

Internes Controlling

Externes Controlling

PC durch eigene Controller

PC durch andere Abteilungen

PC durch externe Controller

PC = Projektcontrolling

Abb. 11: Träger des Projektcontrollings Muss der Projektleiter anstelle des Controllers selbst die Projektcontrollingaufgaben erfüllen, sollte zumindest darauf geachtet werden, dass er das notwendige betriebswirtschaftliche Verständnis hat und die wichtigsten Controllinginstrumente beherrscht. 19


Grundsätzlich ist es sinnvoll, wenn auch Projektleiter und Projektmitarbeiter im Sinne eines Selbstcontrollings Projektcontrollingaufgaben wahrnehmen.

Wie sieht das Leitbild des Projektcontrollers aus? Der Projektcontroller kann mit einem Arzt verglichen werden. Während der Arzt ein langes gesundes Leben seiner Patienten erreichen möchte, arbeitet der Controller für eine dauerhafte positive Unternehmensentwicklung. Arzt wie Controller helfen und unterstützen bei Entscheidungen. Sie bieten oft keine fertigen Lösungen an. Wichtig ist für beide Berufe, dass man ihnen großes Vertrauen entgegenbringt. Auch die Aufgabenschwerpunkte beider Berufe sind vergleichbar. Nachdem eine Krankheit erkannt wurde, muss die Diagnose erfolgen. Sie und die Therapie müssen im Mittelpunkt aller Bemühungen stehen (vgl. Abb. 12). Ein Großteil der Aufgaben eines Controllers in der betrieblichen Praxis besteht oftmals jedoch in der aufwändigen Selektion und Aufbereitung von Daten. Es bleibt zu wenig Zeit, um Daten zu analysieren, Abweichungsursachen zu diagnostizieren und Maßnahmen vorzuschlagen. Nicht so:

Sondern so:

Tipp Diagnose, Therapie 30% Aufbreitung von Daten 70%

Aufbereitung von Daten 30%

Diagnose, Therapie 70%

Abb. 12: Aufgabenschwerpunkte des Projektcontrollers Der gute Arzt wird vorbeugende Maßnahmen ergreifen, damit eine Krankheit gar nicht erst ausbrechen kann. Auch der Projektcontroller sollte sein Augenmerk vor allem auf die Zukunft des Projektes legen. Er muss sich um die vorbeugende Verhinderung von Abweichungen kümmern. Der Projektcontroller hat die Frage „Warum kann das Projektergebnis sinken, und was ist zu tun, um das Planziel zu erreichen?“ zu stellen und zu beantworten. Die Information, dass 20


das Projektergebnis vier Prozent unter dem Plan liegt, ist demgegenüber weniger interessant. Der Projektcontroller sollte sich auch mit strategischen Fragestellungen beschäftigen und strategische Wandlungsprozesse begleiten. Er koordiniert außerdem die Umsetzung der strategischen Unternehmensziele in mittel- und kurzfristige Projektmaßnahmen und prüft, ob die operativen Projektentscheidungen im Einklang mit der Strategie sind. Im Tagesgeschäft wird schnell die Auswirkung einer Entscheidung auf Kundenbeziehungen und Marktanteile vergessen. Zusammenfassend ist zu fordern, dass der Projektcontroller eine Dienstleistung erbringen muss. Er leistet für das Management und die Projektleitung einen Service und ist betriebswirtschaftlicher Berater.34 Insofern gilt das allgemeine Controller-Leitbild der International Group of Controlling (IGC) 35 nicht nur für den Unternehmenscontroller, sondern auch für den Projektcontroller. In Abb. 13 wurde es für den Projektcontroller angepasst. Projektcontroller gestalten und begleiten den Projektmanagement-Prozess der Zielfindung, Planung und Steuerung und tragen damit Mitverantwortung für die Zielerreichung. Das heißt: • Projektcontroller sorgen für Strategie-, Ergebnis-, Finanz-, Prozesstransparenz und tragen somit zu höherer Wirtschaftlichkeit der Projekte bei. • Projektcontroller koordinieren Teilziele und Teilpläne ganzheitlich und organisieren projektübergreifend das zukunftsorientierte Projektreporting. • Projektcontroller moderieren und gestalten den Projektmanagementprozess der Zielfindung, der Planung und der Steuerung. • Projektcontroller leisten den dazu erforderlichen Service der Daten- und Informationsversorgung. • Projektcontroller gestalten und pflegen die Projektcontrollingsysteme.

Abb. 13: Leitbild für den Projektcontroller

Aufgabenteilung zwischen Projektleiter und Projektcontroller Der Projektcontroller kann dem Projektleiter die Entscheidung nicht abnehmen. Während der Projektleiter das wirtschaftliche Projekter34 35

Deyhle, A., Controller-Praxis. Führung durch Ziele, Planung und Controlling, Bd. 1: Unternehmensplanung und Controller-Funktion, 9. Aufl., Gauting 1992. www.controllerverein.de/wasistct/leitbild/leitbild.html, Stand: 14.9.2002.

21


gebnis, die Leistung und die Einhaltung der Projekttermine zu verantworten hat, ist der Projektcontroller vor allem für die Transparenz der Daten zuständig. Im Idealfall versteht der Controller den Projektleiter und liefert daher die richtigen Informationen für die Projektsteuerung (vgl. Abb. 14).36

Dauer

Projektleiter verantworten das Ergebnis

Projektcontroller verantworten die Transparenz Wirtschaftlicher Erfolg

Leistung

Abb. 14: Aufgaben von Projektleiter und Projektcontroller

Welche Qualifikation sollte der Projektcontroller aufweisen? Vor allem Kommunikationsfähigkeit, persönliches Engagement und eine ausgeprägte analytische Begabung zeichnen den erfolgreichen Projektcontroller aus. Da dies typische Qualifikationen einer Führungskraft sind, ist die Controllingarbeit eine hervorragende Voraussetzung für eine Karriere im Management. Der erfolgreiche Einzelprojektcontroller benötigt darüber hinaus Fachkenntnisse des Projektmanagements und vor allem Erfahrungen in der Abwicklung von Projekten. Deswegen ist es auch vorteilhaft, wenn frühere Projektleiter als Projektcontroller installiert werden. Sie kennen die typischen Probleme und werden als kompetenter Ansprechpartner akzeptiert. Abb. 15 zeigt persönliche und fachliche Anforderungen, wie man sie vielfach den Stellenannoncen für Projektcontroller entnehmen kann.

36

22

Deyhle, A., Management & Controlling Brevier, Bd. 1, Manager & Controller im Team, 7. Aufl., Wörthsee-Etterschlag 1977, S. 154.

1.3 Projektcontrolling Persönliche Anforderungen Persönliches Engagement Teamfähigkeit Analytische Fähigkeiten Selbstständiges Arbeiten Kommunikationsfähigkeit Durchsetzungsvermögen

Fachliche Anforderungen Erfahrung in der Abwicklung von Projekten Kenntnisse des Projektmanagements Beherrschung der Controllinginstrumente Erfahrung im Aufbau, in der Pflege und in der Weiterentwicklung von Informationssystemen

Abb. 15: Anforderungen an den Projektcontroller

Wie sind Projektcontroller hierarchisch einzuordnen? Eine sinnvolle Regelung besteht darin, dass der Projektcontroller disziplinarisch dem Leiter des Geschäftsbereichs, der für das Projekt verantwortlich ist, untersteht. Zu begründen ist dies damit, dass der Geschäftsbereichsleiter die Gesamtverantwortung trägt. Dazu müssen ihm alle Stellen untergeordnet sein. Außerdem soll der Projektcontroller nicht als Fremdkörper empfunden werden. Die fachliche Weisungsbefugnis sollte jedoch bei einem vorgesetzten Controller angesiedelt sein. Das ist auch notwendig, damit die Einheitlichkeit des Controllings im Unternehmen gewährleistet ist (vgl. Abb. 16). Diese Alternative wird als „dotted-line-Prinzip“ bezeichnet (in Organigrammen wird die fachliche Weisungsbefugnis häufig mit einer gestrichelten Linie skizziert). Zentrales Controlling

Leitung

... ProjektControlling

Geschäftsbereich 1

Geschäftsbereich 2

PersonalControlling

Geschäftsbereich 3 Dezentrales Controlling

... PersonalControlling Projekt 1

Projekt 2

ProjektControlling

Projekt 3

Abb. 16: Hierarchische Einbindung des Projektcontrollers Bei größeren Unternehmen, die regelmäßig viele Projekte abwickeln, ist es vorteilhaft, spezialisierte Stellen für die verschiedenen Ebenen des Projektcontrollings einzurichten (vgl. Abb. 17): 23


Zentrales Projektcontrolling

Gewährleistung der Projektkultur, Unterstützung der Projektauswahl

Multiprojektcontrolling

Abstimmung parallel laufender Projekte Fokus: Periode

Unterstützung konkreter Einzelprojekte Fokus: Projektlaufzeit

Einzelprojektcontrolling

Abb. 17: Differenzierung der Controllingstellen Die Abstimmung zwischen den verschiedenen Ebenen erfolgt über turnusmäßige Meetings, an denen die Projektcontroller beteiligt sind. Ziel

Teilnehmer

Ergebnis

Turnus

Projektportfolioplanungsrunde

Erstellung und Priorisierung des Projektportfolios

Vorstand, Bereichsleiter, zentrales Projektcontrolling

Priorisiertes Projektportfolio

Einmal pro Jahr

Projektausschusssitzung

Status Projektportfolio, Freigabe neuer Projekte

Vorstand, Bereichsleiter, Multiprojektcontrolling

Aktuelles Projektportfolio

Zweimal pro Jahr

Projektsteuerkreis

Status des Einzelprojekts

Bereichsleiter, Einzelprojektcontrolling, Projektleiter

Eskalationsentscheidungen

Monatlich

Teambesprechung

Status des Einzelprojekts

Einzelprojektcontrolling, Projektleiter, Projektteam

Aufgabenverteilung, Maßnahmen

Jede Woche

Abb. 18: Informationsaustausch und Abstimmung über Meetings In der Praxis findet man sehr unterschiedliche Formen der Einordnung des Projektcontrollings. Die Outokumpu Technology GmbH liefert ihren Kunden in der Prozessindustrie individuelle Lösungen aus dem Bereich des Großanlagenbaus. Die Kundenprojekte haben Auftragswerte bis über 100 Mio. €, die Abwicklungszeiten können sich über mehrere Jahre erstrecken. Das Controlling der Kundenaufträge erfolgt innerhalb einer eigenständigen Abteilung des Projektmanagements. Das Projektmanagement seinerseits ist zusammen mit den Ingenieurfachab-

24


teilungen im Bereich Auftragsabwicklung organisiert. Da sich in der Regel zwischen 15 und 30 Großprojekte zeitgleich im Auftragsbestand befinden, erfordert die Abwicklung ein spezialisiertes Projektführungsteam. Dieses Team setzt sich aus den Funktionen Projektleiter, Projektkaufmann, dem Engineering-Manager, dem Projektcontroller und dem Baustellenleiter zusammen. Die MatrixOrganisation des Unternehmens verdeutlicht Abb. 19. Ingenieurtechnik

Beschaffung

Projektmanager Projekt A

Projektverantwortung

Bereich Projektmanagement

Verfahrenstechnik

Projektmanager Projekt B Projektmanager Projekt C Projektmanager Projekt D Fach- und Disziplinarverantwortung

Abb. 19: Matrix-Projektorganisation Der Projektleiter ist für die gesamte Projektabwicklung verantwortlich, d. h., er nimmt neben der Termin- und Kostenverantwortung insbesondere auch die fachübergreifende Koordination aller Projektmitarbeiter aus den verschiedenen Fachabteilungen wahr. Die jeweiligen Fachabteilungsleiter stellen die geeigneten Mitarbeiter bei und gewährleisten die fachliche Ausführung aller Lieferungen und Leistungen. Die Aufgaben des Projektcontrollings gliedern sich im Wesentlichen in die Beratungsfunktion gegenüber dem Projektverantwortlichen und die Berichtspflicht gegenüber dem Management. Hinsichtlich der operativen Unterstützung des Projektleiters und aller beteiligten Fachdisziplinen nimmt der Projektcontroller die Aufbereitung aller relevanten Informationen wahr, um eine Umsetzung in die neueste Erwartungsrechnung für die Projekterfolgskennzahlen zu gewährleisten. Er hat darüber hinaus die Aufgabe, Abweichungen zu überwachen und wichtige Informationen dergestalt aufzubereiten, dass möglichst eine Umsetzung im Claim-Management gegenüber dem Kunden erfolgen kann. Der Projektcontroller ist darüber hinaus

25


Ansprechpartner für alle Mitglieder des Projektteams hinsichtlich kostenrelevanter Fragen. Er versorgt somit alle an budgetrelevanten Entscheidungen beteiligten Personen mit den notwendigen Informationen. Im Produktbereich Instrumentation Systems der Robert Bosch GmbH ist das Projektcontrolling fester Bestandteil im Projektmanagement. Wie man in Abb. 20 erkennt, ist das Projektcontrolling fachlich und disziplinarisch dem Projektmanagement unterstellt. Dabei erbringt das Projektcontrolling sowohl für die Geschäftsleitung als auch für die Projektleiter einen Service, indem es die Projektleiter bei der Datenaufbereitung unterstützt und der Geschäftsleitung zur Unternehmenssteuerung entscheidungsrelevante Daten präsentiert. Außerdem kann das Projektcontrolling aufgrund der räumlichen Nähe zu den Projektleitern die operativen Tätigkeiten der einzelnen Projektleiter verfolgen und gleichzeitig über die projektspezifischen Abläufe informieren. Sparte

Geschäftsbereiche

Kraftfahrzeug

...

Car Multimedia

... ...

Produktbereiche

Abteilungen

Car Radio

Forschung & Entwicklung

Instrumentation System Projektmanagement

Einkauf

Driver Information Vertrieb & Marketing

Projektleiter Projektcontrolling

Abb. 20: Organisatorische Einbindung des Projektcontrollings im Produktbereich Instrumentation Systems (vereinfachte Darstellung) Bei der Lufthansa Systems GmbH sind grundsätzlich drei verschiedene organisatorische Ebenen am Projektcontrolling beteiligt: Zentrales Controlling, Vertrieb und die Profit-Center. Während das 26


„Zentrale Controlling“ als Stabsstelle mit zentralen Funktionen angelegt ist, sind der Vertrieb einerseits und die produzierenden Profit-Center auf der anderen Seite als Matrix miteinander verknüpft und tragen bzgl. des Projektcontrollings grundsätzlich gemeinsame Verantwortung. • •

•

Aufgaben des zentralen Controllings: Controlling aller Projekte der Kategorie A und B sowie ausgewählter, abgestimmter Projekte der Kategorie C. Aufgaben des Vertriebs: Monitoring des mit dem Projektleiter vereinbarten Deckungsbeitrages und Kostenrahmens sowie sonstiger Punkte laut Projektvereinbarung. Aufgaben der Profit-Center: projektbezogenes Controlling des Deckungsbeitrags, Überwachung des zu erwartenden Kostenrahmens pro Projekt, Überprüfung der regelmäßigen Zuordnung von Erträgen zu Projekten, Monatliche Kontrolle der Terminsituation pro zugeordnetem Projekt, Prüfung aller restlichen Items aus der Projektvereinbarung.

Die Aufgabenschwerpunkte und somit auch die Aufgabenteilung des Controllings ändern sich projektphasenbezogen. Zu allen Zeitpunkten sind jedoch immer das zentrale Controlling, der Vertrieb, die Profit-Center und Projektmanager oder Angebotsmanager in den Controllingprozess involviert. Angebotsphase Während der Angebotsphase liegt die Hauptverantwortung beim Vertrieb. Er hat dabei folgende Aufgaben zu bewältigen: • •

•

•

Zuordnung des Projektes zu einem verantwortlichen ProfitCenter, Abstimmung des Leistungsumfangs, der Kosten und Preise mit dem Projektleiter oder einer vom verantwortlichen ProfitCenter benannten Person, Einbindung des Profit-Center-Leiters in die weiteren Projektphasen und Freigabe des Projektes an das verantwortliche Profit-Center, Weiterleitung aller bis zu diesem Zeitpunkt entstandenen controllingrelevanten Daten an das verantwortliche Profit-Center (dezentrales Controlling). 27


Projektinitialisierung/Projektstart Beim Projektstart geht die Hauptverantwortung für das Controlling auf den Profit-Center-Leiter über. Zu diesem Zeitpunkt hat er noch folgende Verfahrensschritte durchzuführen: • • • •

endgültige Festlegung aller das Projekt betreffenden Verantwortlichkeiten, Abstimmung der Projektstrukturpläne (eindeutige Kosten- und Ertragssammler im SAP-System für ein Projekt) zwischen Vertrieb und dezentralem Controlling, eindeutige Zuordnung dieser Projektstrukturpläne zum Projekt und zu den Profit-Centern, Abschluss einer Projektvereinbarung. Bei C-Projekten muss außerdem festgelegt werden, ob ein zentrales Projektcontrolling erforderlich ist.

Projektdurchführung Während der Projektdurchführung wiederum liegt die Hauptaufgabe des Controllings beim Projektleiter. Er hat dafür Sorge zu tragen, dass alle controllingrelevanten Daten des Projektes an die beteiligten Controllingstellen weitergeleitet werden. Im Wesentlichen sind hierfür die folgenden Arbeitsschritte vorgesehen: • •

Projektleiter erstellt den monatlichen Statusbericht, Projektleiter leitet den Statusbericht an das verantwortliche Profit-Center weiter.

Der Projektleiter berichtet auch an das zentrale Controlling.

Wie sollte ein Projektcontrolling eingeführt werden? Die Einführung des Projektcontrollings ist ein eigenes Projekt. Das Vorgehen beinhaltet folgende Schritte und Aufgaben: Projektauftrag • Bildung eines Projektteams mit Projektleiter, • Festlegung der Zielsetzung und Termine, • Frühe Information des Betriebsrats und der Mitarbeiter. Ist-Erhebung • Realistische Beschreibung der Ausgangssituation: - Existiert ein funktionierendes Rechnungswesen?

28


- Wie gut ist das Projektmanagement ausgebaut? - Gibt es eine institutionalisierte Planung? - Sind bereits Controllingstellen eingerichtet? • Feststellung möglicher Widerstände: Gibt es unterschiedlichen Sachverstand, Unstimmigkeiten über den Ablauf, persönliche Aversionen, mangelnde Akzeptanz der neuen Rollen- und Machtverteilung, begrenzte Ressourcen? Soll-Konzept •

• • • • •

• • • •

Definition des Aufgabenumfangs: Welche Aufgaben soll der Projektcontroller sofort wahrnehmen? Was muss er nicht beachten? Die Einführung eines Projektcontrollings sollte „engpassbezogen“ erfolgen. Nicht von Anfang an ein ausgefeiltes allumfassendes Projektcontrolling anstreben, sondern zunächst diejenigen Teile realisieren, die am wichtigsten sind. Festlegung der Arbeitsteilung zwischen Projektcontrolling und den anderen Abteilungen, die Controllingaufgaben wahrnehmen sollen. Auswahl der Instrumente für das Projektcontrolling (z. B. Earned Value Analyse, vgl. Abschnitt 3.2.4). Bestimmung der bereit zu stellenden Informationen. Festlegung der hierarchischen Eingliederung des Projektcontrollers. Einbindung der betroffenen Abteilungen und Stellen (Controlling, Qualitätssicherung, Vertrieb, Projektleiter). Sie sollten die Gelegenheit erhalten, ihre Erfahrungen einfließen zu lassen und an der Konzeption mitzuwirken. Planung der Maßnahmen zur Beseitigung von Widerständen (Informationen liefern, miteinander reden, Kompromisse aushandeln). Suche geeigneter Projektcontroller. Erstellung eines Projektcontrollinghandbuchs mit dem groben Konzept. Erforderliche Schulung der Projektleiter und Projektcontroller.

Einführung •

Erstmalige Anwendung des Projektcontrollings bei einem sorgfältig ausgesuchten Projekt mit einem qualifizierten und aufge-

29


• • •

schlossenen Projektleiter und mit Unterstützung durch die Unternehmensleitung. Auswertung der Erfahrungen und Modifikation des Projektcontrollingkonzepts. Weitere Verbreitung des Projektcontrollings und laufende Anpassung. Regelmäßiger Erfahrungsaustausch zwischen Projektleiter und Projektcontroller.

Die Aufgaben, die das Projektcontrolling wahrnimmt, und die verwendeten Methoden müssen sich am Reifegrad des Projektmanagements orientieren. Das Capability Maturity Modell unterscheidet fünf Stufen in der Entwicklung des Projektmanagements:37 1. Initial Prozesse für die Projektabwicklung sind nicht festgelegt. Der Projekterfolg hängt vom einzelnen Projektleiter ab. Probleme werden durch ad-hoc-Maßnahmen gelöst. Projektergebnisse sind kaum vorhersehbar. 2. Managed Ein grundlegendes Vorgehensmodell für Projekte existiert. Erfahrungen abgeschlossener Projekte werden dokumentiert und für die Planung neuer Projekte angewandt. Restkosten und Restdauer sind einigermaßen zuverlässig vorherzusagen. Die Projektergebnisse schwanken jedoch noch stark. Ein grundlegendes Qualitätssicherungssystem ist etabliert. 3. Defined Die Projektmanagementprozesse sind unternehmensweit eingeführt und messbar. Kosten und Zeiten sind zuverlässig zu prognostizieren. Die Projekte sind transparent und überprüfbar. 4. Quantitatively Managed Für alle Projekte werden quantitative Ziele vorgegeben und überwacht. Alle relevanten Projektdaten sind verfügbar. Sie werden regelmäßig analysiert und zur Optimierung der Projektprozesse verwendet. 37

30

Software Engineering Institute (Hrsg.), CMMI for Services, Version 1.2, Februar 2009, S. 27 ff. Kneuper, R., CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration, 2. Auflage, Heidelberg 2006.


5. Optimizing Die gesamte Organisation ist bestrebt, Schwachstellen aufzudecken und seine Prozesse zu verbessern. Liegt ein geringer Reifegrad des Projektmanagements vor, wird sich das Projektcontrolling auf Kostenplanung und Kostenkontrolle konzentrieren. Bei zunehmender Entwicklung des Projektmanagements wird das Projektcontrolling weitere Aufgaben übernehmen und differenziertere Methoden einsetzen. Im anzustrebenden Idealzustand existieren auch ein strategisches Projektcontrolling und ein Multiprojektcontrolling; einzelne Projekte mit hoher Bedeutung werden umfassend durch Projektcontroller unterstützt.38 Die Lufthansa Systems GmbH hat bei der Einführung des Projektcontrollings die Erfahrung gemacht, dass es entscheidend ist, die Projektleiter von der Wichtigkeit des Projektcontrollings zu überzeugen und Arbeitshilfen zu schaffen, die den Overhead für die Projektleiter begrenzen. Möglich wird dies einerseits durch die Etablierung einer durchgängigen, verständlichen, wirtschaftlichen Projektsteuerungsphilosophie sowie durch die Nutzung von Standardwerkzeugen wie Exchange, Excel, Word und an den Stellen, wo es absolut notwendig ist, durch den Einsatz von MS-Project und auch SAP. Die Projektverfolgung darf für den Projektleiter keinen zusätzlichen Aufwand bedeuten. Das bedeutet, alle notwendigen Daten (bis auf die Prognosedaten) müssen von vorgelagerten Systemen möglichst automatisiert geliefert werden. Auch das Berichtswesen muss sich direkt aus den Projektverfolgungsdaten des Projektleiters ableiten. Berichte sollten ebenfalls soweit wie möglich automatisiert erzeugt werden.

Wie kann der Nutzen eines Projektcontrollings begründet werden? Der monetäre Nutzen eines Projektcontrollings ist kaum exakt zu quantifizieren. Es ist jedoch offensichtlich, dass die Unterstützung eines Projekts durch den Projektcontroller in der Regel zu geringeren Kosten und zu reduzierter Dauer im Vergleich zu einem Projekt ohne Projektcontrolling führen wird. Dabei wird der Nutzen des Projektcontrollings durch zwei Effekte beeinflusst, die man gegenüber den Projektverantwortlichen auch kommunizieren sollte, um 38 Koreimann, S., Projekt-Controlling. Weinheim 2005, S. 181 f.

31


einer Abwehrhaltung gegenüber dem Projektcontrolling vorzubeugen: 1. Nach Einführung des Projektcontrollings verursachen die frühen Phasen des Projekts einen höheren Aufwand. Eine Begründung dafür ist, dass der Projektcontroller eine sorgfältige Planung einfordern wird. Die bessere Projektvorbereitung hat aber zur Folge, dass in späteren Phasen des Projekts weniger Fehler auftreten und Änderungen seltener erforderlich sein werden. Das führt unter dem Strich zu einer besseren Zielerfüllung und zu geringeren Kosten für die Projekte. Eine Kosteneinsparung zwischen zehn und 20 Prozent dürften realistisch sein.

Anteil in %

2. Auch der zusätzliche Aufwand für die Arbeit des Controllers muss berücksichtigt werden. Nach einer Untersuchung aus dem Jahre 1980 bewegt sich der Anteil der Kosten für Projektplanung, Projektkontrolle und Projektinformation je nach Projektgröße zwischen vier und 0,5 Prozent des Projektbudgets (siehe Abb. 21).39 Projektcontrolling nimmt nur einen Teil dieser Aufgaben wahr. Deswegen dürfte der Kostenanteil tatsächlich geringer sein.

4,0 %

0,5 % 1 Mio.

Projektbudget

100 Mio.

Abb. 21: Anteil der Kosten von Projektplanung, Projektkontrolle und Projektinformation am Gesamtbudget Die Unternehmensberatung Horváth & Partners führt regelmäßig Benchmarks für das Unternehmenscontrolling durch. Eine 39

32

Schmitz, H., Windhausen, M., Projektplanung, Düsseldorf 1980, S. 159.


Erkenntnis ist, dass die Kosten für den Controllingbereich im Durchschnitt bei 0,35 Prozent des Umsatzes liegen.40 Mittelgroße Unternehmen haben durch ihre Größennachteile höhere Kosten, ebenso junge, schnell wachsende Unternehmen. Geht man davon aus, dass die Prozesse des Projektcontrollings weniger strukturiert sind und es weniger Routine gibt, dürfte der relative Aufwand für das Projektcontrolling etwas höher anzusiedeln sein. Er nähert sich damit den Angaben aus der Abb. 21 für große Projekte, so dass durch Projektcontrolling zusätzliche Kosten von ca. 1,5 bis zwei Prozent des Projektbudgets anfallen dürften. Entscheidend ist die Erkenntnis, dass in der Summe aller Projekte eine erhebliche Zeit- und Kostenersparnis mit Projektcontrolling erzielbar ist. Es gilt die Erkenntnis: „Projektcontrolling kostet Geld. Kein Projektcontrolling kostet noch mehr Geld!“

Tipp

Die folgenden Ausführungen orientieren sich an Abb. 9. In Kap. 2 wird zunächst das strategische Projektcontrolling behandelt. Berücksichtigung findet dabei auch die Projekt-Scorecard. Kap. 3 beschreibt, inwiefern das operative Projektcontrolling die Projektplanung und Projektkontrolle unterstützt. Es werden jeweils die wesentlichen Aufgaben, Instrumente und Informationen sowie die Zuständigkeit des Projektcontrollings aufgeführt. Eine explizite Differenzierung zwischen Einzelprojekt- und Multiprojektcontrolling erfolgt in Kap. 3 nicht mehr, da die überwiegende Zahl der Instrumente in beiden Bereichen genutzt werden kann. Das abschließende Kap. 4 beinhaltet Möglichkeiten der DV-Unterstützung.

40

Michel, U., Esser, J., Wohin entwickelt sich der Finanzvorstand? FAZ v. 27. Februar 2006, S. 22.

33


1.4 • •

• •

• • •

•

• •

34

Zusammenfassung Projekte werden zunehmend komplexer, das Fehlerpotenzial steigt und die Risiken nehmen zu. Deswegen ist Projektmanagement notwendig. Projektmanagement umfasst alle Leitungsaufgaben und Instrumente für die Planung, Kontrolle und Organisation eines Projekts. Gegenstand des Projektmanagements ist auch die Personalführung der am Projekt beteiligten Personen. Der Projekterfolg wird vor allem durch die so genannten weichen Faktoren beeinflusst. Das Projektcontrolling gestaltet die Projektmanagementstrukturen und -prozesse und unterstützt die Projektleitung umfassend. Zu unterscheiden ist das strategische Projektcontrolling vom Multiprojektcontrolling und vom Controlling einzelner Projekte. Aktives Projektcontrolling zeichnet sich dadurch aus, dass man versucht Abweichungen vorherzusehen und vor ihrem Auftreten Gegenmaßnahmen einzuleiten. Die Aufgaben des Projektcontrollings werden vom Projektleiter und speziellen Stellen (vor allem dem Projektcontroller, aber auch vom Qualitätsmanagement u. a.) wahrgenommen. Der Projektleiter ist für das wirtschaftliche Projektergebnis, die Leistung und die Einhaltung der Projekttermine verantwortlich. Der Projektcontroller unterstützt den Projektleiter als „betriebswirtschaftlicher Berater“. Er ist vor allem für die Transparenz der Daten zuständig. Der fachliche Vorgesetzte des Projektcontrollers ist im Idealfall ein zentraler Controller. Disziplinarisch untersteht er demjenigen Bereichsverantwortlichen, der die Gesamtverantwortung für das Projekt trägt. Die Einführung eines Projektcontrollings ist ein eigenes Projekt, das sorgfältig geplant werden sollte. Projektcontrolling verursacht Mehraufwand. Per Saldo erzielt man jedoch eine Reduzierung der Projektdauer und des Gesamtaufwands.

2

Strategisches Projektcontrolling

„Wer nicht an die Zukunft denkt, der wird bald große Sorgen haben.“ Konfuzius

Sie erfahren in diesem Kapitel die wesentlichen Aufgaben der strategischen Projektplanung, die durch das Projektcontrolling zu unterstützen sind. Dabei werden die Vorgehensweise bei der Projektauswahl und die dabei verwendeten Instrumente, wie die Portfoliotechnik, die Nutzwertanalyse und Verfahren zur Bestimmung der Wirtschaftlichkeit, erläutert. Zudem wird beleuchtet, inwiefern mit der Managementmethode der Projekt-Scorecard Projekte priorisiert und gesteuert werden können. Den Abschluss bilden Betrachtungen zur strategischen Kontrolle.

35

2 Strategisches Projektcontrolling

2.1

Strategische Projektplanung

2.1.1 Überblick

INPUTINFORMATIONEN

Was? Woher? Strategische Unternehmensziele Strategische Planung Projektvorschläge Leitung, Fachbereiche, Kunden

AUFGABEN

Welche? Grobe Vorselektion Bewertung der Attraktivität

Analyse der Abhängigkeiten Analyse der Ressourcenverfügbarkeit

OUTPUTINFORMATIONEN

Was? Liste der genehmigten und priorisierten Projekte

Womit? Wirtschaftlichkeitsrechnungen, Nutzwertanalyse, Präferenzmatrix, Portfoliotechnik, Risikoanalyse, Projekt-Scorecard Abhängigkeitsmatrix Mitarbeitereinsatzplan, Budgetierung

Wohin? Strategische Kontrolle, Einzelprojekt- und Multiprojektcontrolling,

Abb. 22: Überblick über die strategische Projektplanung Grundlage der strategischen Projektplanung sind die Unternehmensziele. Projekte müssen mit den strategischen Zielen harmonieren, die deswegen die wesentlichen Auswahlkriterien liefern. Ein Unternehmen mit dem strategischen Ziel schnelles Wachstum durch Ausweitung des Marktanteils wird Projekte anders beurteilen als ein Unternehmen, das die Gewinnmaximierung durch Kostensenkung verfolgt. Strategische Projekte wie die Entwicklung von Nachfolgeprodukten werden von der Unternehmensleitung top down in den Planungsprozess eingesteuert. Zusätzlich formulieren die Fachbereiche bottom up Projektwünsche, die für die Erreichung ihrer Ziele erforderlich sind. Dabei ist sicherzustellen, dass Projektideen nicht von 36

2.1 Strategische Projektplanung

vornherein abgeblockt oder bevorzugt werden. Jeder Vorschlag sollte zunächst die gleiche Chance haben. Ansonsten besteht die Gefahr, dass sinnvolle Vorhaben nicht realisiert werden. Bei BMW muss für jeden Projektantrag ein Projektsteckbrief ausgefüllt werden. Er spezifiziert die strategische Bedeutung, Marktrisiken, technische Risiken und betriebswirtschaftliche Risiken. Nur wenn dieser Steckbrief durch ein Gremium, das sogenannte Innovations-Council, geprüft wurde, wird der Projektantrag in die Datenbank möglicher Projekte eingesteuert. In der Zurich Gruppe Deutschland gibt das zentrale Controlling Planungs- und Auftragsverfahren für Projekte vor. Der Anstoß der Planung der Projekte erfolgt nach der Erstellung des strategischen Plans, also im zweiten Quartal eines jeden Jahres. Im sogenannten Initiativenauftrag wird das vorgesehene Projekt genau beschrieben. Er ist Voraussetzung und Maßstab für die Durchführung eines Projekts. In ihm sind die zu erreichenden Ziele in einer überprüfbaren Form festgelegt, so dass eine Erfolgskontrolle unterjährig im Rahmen des Reporting erfolgen kann. Weitere Inhalte sind, neben Zielsetzung und Zweck, vorgesehene Meilensteine, Risiken, Termine, Verantwortliche, Ressourcenbedarf, Kosten und natürlich der zu erwartende Nutzen, der auch in einer entsprechenden Wirtschaftlichkeitsberechnung hinterlegt wird. Letztere informiert über die monetären Effekte und Konsequenzen der Initiative. Die Berechnung der Wirtschaftlichkeit eines Projekts erfolgt mit der Kapitalwertmethode (vgl. Abschnitt 2.1.3.3). Treten unterjährig Engpässe bei den vom Gesamtvorstand vorgegebenen Kostenbudgets und Ressourcen auf, bedarf es einer Priorisierung. Die Grundlage für die Festlegung von „Vorfahrtsregelungen“ für Projekte stellen die strategischen und wirtschaftlichen Bewertungen der Projekte dar. Anzustreben ist eine Gesamtbetrachtung aller Projekte. Deswegen sollte man auch die bereits genehmigten und die laufenden Projekte in die Analyse einbeziehen. Es kann durchaus sein, dass schon genehmigte Vorhaben aufgrund der nachfolgenden Bewertung nicht realisiert werden. Kritisch ist es immer, bereits laufende Projekte zu stoppen. Trotzdem muss diese Möglichkeit vorgesehen werden, wenn die Projektziele nicht mehr erreichbar sind. Vor allem in Entwicklungsprojekten ist es unerlässlich, ein mögliches Scheitern des

37


Projektes möglichst früh zu erkennen, um den Schaden zu begrenzen. Nachdem die Projektvorschläge formuliert wurden, liegt eine Liste von Projekten vor, die im Regelfall nicht alle in der nächsten Planperiode bearbeitet werden können. Aufgabe des strategischen Projektcontrollings ist es deswegen, Informationen für die Bewertung der gewünschten Projekte bereitzustellen und damit die Entscheidung über die Auswahl, die Priorisierung und den Freigabezeitpunkt neuer sowie den Abbruch laufender Projekte zu unterstützen. Abb. 23 zeigt den Prozess zur Bestimmung des Projektportfolios, der in den folgenden Abschnitten näher beschrieben wird.41 Gesammelte Projektideen

S T

Filter 1: grobe Vorselektion Filter 2: Bewertung der Attraktivität, Analyse der Abhängigkeiten 3 2 1

2 1

R A T E

Filter 3: Analyse der Ressourcenverfügbarkeit Planung und Realisierung der Projekte

G I E

Abb. 23: Prozess der strategischen Projektauswahl 2.1.2 Grobe Vorselektion Um die Anzahl der zu bewertenden Projekte zu begrenzen, ist eine grobe Vorselektion sinnvoll. Es muss geprüft werden, ob Projektvorschläge den strategischen Zielsetzungen offensichtlich widersprechen. Auch die Machbarkeit ist zu hinterfragen.

41

38

Eine ähnliche Vorgehensweise wird vorgeschlagen bei Archer, N., Ghasemzadeh, F., An integrated framework for project portfolio selection, International Journal of Project Management, 17 (1999) 4, S. 207 – 216.


In dieser Phase sollten Muss-Projekte definiert werden. Dabei handelt es sich um Vorhaben, die z. B. aufgrund gesetzlicher Vorschriften unumgänglich sind. Die Deklarierung als Muss-Projekt ist restriktiv zu handhaben. Keinesfalls sollten besondere „Lieblingsprojekte“ einzelner Bereiche oder des Managements von vornherein als Muss-Projekt eingestuft werden. Andernfalls wird der beschriebene Prozess zur Projektauswahl unterminiert, und die Realisierungschancen für wichtige Projekte werden eingeschränkt. Der Anteil der Muss-Investitionen sollte zehn Prozent nicht überschreiten.

Tipp

2.1.3 Bewertung der Attraktivität Diejenigen Projekte, welche die Vorselektion überstanden haben, werden hinsichtlich ihrer Attraktivität für das Unternehmen detailliert bewertet. Unter der Attraktivität sollen all jene Faktoren verstanden werden, die aus Unternehmenssicht für die Realisierung eines Projektes sprechen. Konkret handelt es sich um: • • • • • •

Strategische Bedeutung (Wettbewerbsvorteile, Kundenorientierung), Dringlichkeit, Wirtschaftlichkeit, Risiko, Kosten (Entwicklungskosten, Folgekosten), Ressourcenbedarf.

Manche Unternehmen beschränken sich ausschließlich auf die Analyse der Wirtschaftlichkeit. Diese eindimensionale Nutzenbewertung führt nicht zum optimalen Projektportfolio. Die Attraktivität der Projekte sollte immer unter Einbeziehung der betroffenen Bereiche beurteilt werden, um die Akzeptanz der Ergebnisse zu gewährleisten. Das Projektcontrolling hat die Aufgabe, Hilfestellung beim Einsatz von Bewertungsinstrumenten zu geben und die Konsistenz der zur Beurteilung herangezogenen Daten zu prüfen.

3UoMeNtFontUoOOeU

XnteUVtt]t

Die ROHDE & SCHWARZ GmbH & Co. KG ist ein mittelständisches Unternehmen der Messtechnik, Informations- und Kommunikationstechnik. Ein Gremium, bestehend aus dem Geschäftsführer, dem Leiter Controlling und dem Leiter des strategischen Marketings entscheidet über neue Entwicklungsprojekte. Die Vorselektion der Projekte erfolgt durch Produktmanager und Fachgebietsleiter. Sie 39


informieren das Entscheidungsgremium über die technischen Faktoren und die voraussichtliche Wirtschaftlichkeit (Kosten, Erlöse, Rentabilität und Break-Even-Punkt, vgl. zu den Verfahren Abschnitt 2.1.3.3). Projekte werden nur dann genehmigt, wenn Sie eine bestimmte Mindestrendite überschreiten und eine vorgegebene Amortisationszeit nicht unterschreiten Eine Gesamtbetrachtung aller Einflussfaktoren für den Projekterfolg kann man mit der Nutzwertanalyse durchführen. Das Instrument eignet sich auch, um während der Projektabwicklung Lösungsalternativen zu bewerten. Instrumente zur Bestimmung der Attraktivität sind auch Portfolios und Wirtschaftlichkeitsrechnungen. Des Weiteren hilft die Risikoanalyse, das Erfolgspotenzial der Projekte abzuschätzen. 2.1.3.1 Nutzwertanalyse Eine gute Entscheidungsgrundlage kann man sich mit der Nutzwertanalyse erarbeiten. Sie erlaubt eine Gesamtbeurteilung aller relevanten Attraktivitätskriterien. Für die Bewertung der Attraktivität eines Projektes reicht es nicht aus, nur „harte“ Bewertungskriterien wie Kosten oder die Rentabilität heranzuziehen. Es müssen auch die qualitativen Einflussgrößen der Attraktivität, wie z. B. strategische Bedeutung und Dringlichkeit berücksichtigt werden.

Wie wird die Nutzwertanalyse durchgeführt? In der Nutzwertanalyse wird ein Punktwert für jedes Projekt ermittelt. Dieser Punktwert ist ein Indikator für die Erfüllung der Unternehmensziele und damit für den Nutzen eines Projektes. Die Nutzwertanalyse wird in sechs Schritten durchgeführt: 1. 2. 3. 4. 5.

Ziele bestimmen und Ziele gewichten Punkte für die Projekte vergeben Gewichte mit den zugehörigen Punkten multiplizieren gewichtete Punktgesamtsumme ermitteln Sensitivität des Ergebnisses analysieren

Entscheidend ist eine sorgfältige Zielbestimmung. Die Ziele der Nutzwertanalyse müssen zusammen mit dem Top-Management aus den strategischen Zielen des Unternehmens abgeleitet werden. Abb. 24 verdeutlicht eine systematische Vorgehensweise für die Ermittlung der Ziele. Da die Schritte zur Zielfindung auch für die Planung

40


einzelner Projekte relevant sind, werden sie im Folgenden beschrieben. Suche nach Zielideen

Auswahl und Dokumentation

Aufstellung der Zielstruktur

ZIELFINDUNGSPROZESS

Gewichtung der Ziele

Analyse der Zielbeziehungen

Quantifizierung der Ziele

Abb. 24: Systematische Vorgehensweise bei der Zielfindung Die Suche nach Zielideen kann mit Kreativitätstechniken unterstützt werden. Grundsätzlich sind Leistungs-, Kosten- und Terminziele zu unterscheiden. Auch eine Unterteilung in finanzielle, kunden- und prozessbezogene Ziele kann sinnvoll sein. Die gefundenen Ziele sollte man in Ober- und Unterziele strukturieren (vgl. Abb. 25). Attraktivität des Projektes

100

Strategische Bedeutung

Dringlichkeit 30

Kosten 20

Kundenzufriedenheit

20

10

Entwicklungskosten

10

Wettbewerbsvorteile

Risiko 40

10

Folgekosten 30

Abb. 25: Gewichtete Zielstruktur

41


Die Analyse der Zielbeziehungen darf nicht vergessen werden. Zielkonflikte stellen ein großes Potenzial für mögliche Probleme und Risiken dar. Deshalb müssen konkurrierende Ziele frühzeitig identifiziert werden. Ein mögliches Verfahren dazu ist, dass die einzelnen am Projekt beteiligten Gruppen (z. B. Nutzer, Auftraggeber, Entwickler) getrennt ihre Ziele definieren.42 Die schaubildliche Darstellung der Gruppenziele verdeutlicht schnell gegensätzliche Ziele. In Abb. 26 sieht man (vgl. Linie 1), dass die von den Nutzern gewünschte Funktionsvielfalt der Einhaltung des begrenzten Projektbudgets und einer guten Kosten-Nutzen-Relation entgegensteht. Außerdem bieten die Standardkomponenten, welche die Entwickler einsetzen wollen, nicht die von den Nutzern gewünschte hohe Leistungsfähigkeit (vgl. Linie 2 in Abb. 26). Nutzer der Projektleistung

Auftraggeber 1

Funktionsvielfalt

Einhaltung der Termin- und Kostenziele

Zukunftssicherheit

Gute Kosten-Nutzen-Relation

Anpassung an sich ändernde Bedingungen

Einfluss auf Projektsteuerung Einfache Pflege der Projektleistung

Hohe Leistungsfähigkeit

Entwickler 2

Stabile Projektanforderungen Freie Wahl der Vorgehensweise Nutzung vorhandener Komponenten

Abb. 26: Analyse möglicher Zielkonflikte Ziele sollte man in einem weiteren Schritt quantifizieren, damit der Grad der Zielerreichung messbar ist. Das Ziel Mindestrentabilität 15 Prozent ist aussagekräftiger als hohe Rentabilität. Außerdem müs-

42

42

Boehm, B., Port, D., Al-Said, M., Avoiding the Software Model-Clash Spiderweb, o.O. 2000.


sen für jedes Ziel ein Verantwortlicher und der Zeitpunkt der Zielerreichung genannt werden. Man kann nicht alle Ziele in der gleichen Intensität verfolgen. Deswegen ist eine Gewichtung der verschiedenen Teilziele sinnvoll. Dazu reicht bei einfachen Zielstrukturen eine direkte Gewichtung wie in Abb. 25 aus. Hat man jedoch eine Vielzahl unterschiedlicher Ziele, sollte man auf die Präferenzmatrix zurückgreifen (vgl. Abb. 27). Sie erleichtert die Gewichtung durch paarweisen Vergleich aller Ziele. 17,8

3

4

Kundenzufriedenheit

a

a 3,6

0

7

c

Wettbewerbsvorteile

b

a

c 21,4

2

5

c

c 7,2

1

6

e 10,7

5

2

e

4

3

f

g

c g g

f 14,3

g

f

f

Folgekosten

a

e c

Entwicklungskosten

d

a

d

Dringlichkeit

g

Risiko g

25,0

1

6

g

Wirtschaftlichkeit

Ziel Häufigkeit Rang Gewicht (Summe =100)

Gewicht =

Summe der Gewichte Summe der Ränge

x

umgedrehter Rang

Abb. 27: Zielgewichtung mit der Präferenzmatrix In Abb. 27 wurde das Ziel Kundenzufriedenheit (= a) viermal als das wichtigere eingestuft (werden mehrere Ziele gleich oft genannt, muss zwischen diesen Zielen eine Rangfolge aufgestellt werden). Dies ergibt bei den sieben vorgegebenen Zielen den dritten Rang. 43


Das Gewicht dieses Ziels (= 17,8) errechnet sich aus der Summe der Gewichte (= 100) dividiert durch die Summe der Ränge (= 28) multipliziert mit dem umgedrehten Rang von Ziel a (= 5). Zur Bestimmung der Zielgewichte kann alternativ zur Präferenzmatrix auch die Methode Analytical Hierarchy Process43 verwendet werden. Dafür wird zunächst eine Matrix der Ziele erstellt. Jedes Ziel wird mit jedem anderen Ziel verglichen. Dabei kann im Unterschied zur Präferenzmatrix festgelegt werden, um wie viel wichtiger ein Ziel gegenüber einem anderen ist. Verwendet wird eine Skala von eins bis neun. In Abb. 28 ist die Dringlichkeit viermal so wichtig wie das Risiko. Strategische Bedeutung

Dringlichkeit

Risiko


1/1

1/2

3/1

Dringlichkeit

2/1

1/1

4/1

Risiko

1/3

1/4

1/1

Abb. 28: Ausgangsmatrix Die Matrix der Abb. 28 wird im zweiten Schritt quadriert. Der Wert 3,00 in Zeile 2, Spalte 2 errechnet sich z. B. wie folgt aus Abb. 28: ͳ ͳ ሺͳ ൈ ͳሻ ൅ ൬ ൈ ʹ൰ ൅ ሺ͵ ൈ ሻ ͵ ʹ Strategische Bedeutung

Dringlichkeit

Risiko


3,00

1,75

8,00

Dringlichkeit

5,33

3,00

14,00

Risiko

1,16

0,66

3,00

Abb. 29: Quadrierte Matrix

43

44

Saaty, Th., Fundamentals of Decision Making with the Analytic Hierarchy Process, Pittsburgh 2000.


Im dritten Schritt werden die Reihensummen berechnet und deren Anteil an der Gesamtsumme von 39,90 ermittelt. Man erhält dadurch in der letzten Spalte der Abb. 30 die vorläufigen Zielgewichte. Strategische Bedeutung

Dringlichkeit

Risiko

Reihensumme

Gew ichte


3,00

1,75

8,00

12,75

0,319548872

Dringlichkeit

5,33

3,00

14,00

22,33

0,559649123

Risiko

1,16

0,66

3,00

4,82

0,120802005

39,90

Abb. 30: Normalisierte Matrix

1,00000000

Das Ergebnis kann optimiert werden, indem man die Ergebnismatrix der Abb. 30 erneut quadriert und die Gewichte errechnet. Dies führt zu folgenden Gewichtungsfaktoren (Spalte zwei der Abb. 31): Gewichte 1. Durchlauf 2. Durchlauf

Differenz

0,319548872

0,319621018

-0,000072146

0,559649123

0,558419705

0,001229418

0,120802005

0,121959277

-0,001157272

Abb. 31: Vergleich der Zielgewichte Die Berechnung stoppt, wenn der Unterschied der Zielgewichte von zwei aufeinander folgenden Rechenschritten minimal ausfällt. Der letzte Schritt des Zielfindungsprozesses beinhaltet die Auswahl und verbindliche Dokumentation der endgültigen Zielstruktur. Das Ergebnis der gesamten Nutzwertanalyse ist in Abb. 32 dargestellt. Projekt a wird als Muss-Projekt keiner detaillierten Bewertung unterzogen. Es wird auf jeden Fall realisiert. Für die restlichen Projekte wird je Ziel mit Punkten von eins bis zehn beurteilt, inwiefern das jeweilige Ziel erfüllt wird. Durch Multiplikation der Punkte mit den Zielgewichten erhält man einen Wert, der über alle Ziele summiert wird. Das Resultat zeigt die Attraktivität der Projekte: Projekt b erfüllt aufgrund der höheren Punktesumme die Ziele besser als Projekt c. Projekt d weist nur eine geringe Attraktivität auf. Das Ergebnis der Nutzwertanalyse ermöglicht es also, Prioritäten für einzelne Projekte zu ermitteln. Dies ist vor allem dann interessant,

45


wenn über die Zuteilung knapper Ressourcen entschieden werden muss. Alternativen Ziele

Projekt a

Muss-Projekt Kann-Ziele

G

Kundenzufriedenheit Wettbewerbsvorteile Dringlichkeit Entwicklungskosten Folgekosten Risiko Wirtschaftlichkeit

18 4 21 7 11 14 25

Summe

P

100

ja GxP

Projekt b P

nein GxP

10 7 3 5 7 9 6

180 28 63 35 77 126 150 659

Projekt c P

nein GxP

3 10 4 2 5 4 5

54 40 84 14 55 56 125 428

Projekt d P

nein GxP 1 3 6 2 5 4 4

18 12 126 14 55 56 100 381

G = Gewichte; P = Punkte (1 Punkt: geringe Erfüllung; 10 Punkte sehr gute Erfüllung); 700 bis 1.000 Punkte: hohe Attraktivität; 400 bis 699 Punkte: mittlere Attraktivität.

Abb. 32: Nutzwertanalyse Sinnvoll ist es, eine Mindestpunktesumme festzulegen. Projekte, deren Nutzwert über diesem Wert liegt, können genehmigt werden. Die Gewichtung der Ziele und der Zielerfüllungsgrade ist subjektiv. Deswegen ist es ratsam, die Nutzwertanalyse für verschiedene Szenarien durchzuführen und die Bandbreite der möglichen Ergebnisse zu ermitteln (Sensitivitätsanalyse). Ändert sich trotz einer anderen Zielgewichtung oder geänderter Punkte für die Zielerfüllung das Ergebnis nicht wesentlich, so ist das Resultat der Bewertung sehr zuverlässig. Ein zentraler Vorteil der Nutzwertanalyse ist, dass man eine nachvollziehbare und allgemein akzeptierte Entscheidungsgrundlage hat. Das setzt voraus, dass die Nutzwertanalyse möglichst gemeinsam mit allen betroffenen Mitarbeitern erstellt wird.

46


Bei der Coca-Cola Erfrischungsgetränke AG44 bewertet ein Vertreter des jeweiligen Fachbereichs seine Projekte gemeinsam mit der Abteilung Corporate Relations anhand der sechs Kriterien 1. 2. 3. 4. 5. 6.

operativer Nutzen (Einsparungen in €), Risiko, Fähigkeit andere Abfüller zu integrieren, Abhängigkeit zu anderen Projekten, strategische Bedeutung und interner Ressourcenbedarf.

Es können zwischen einem und zehn Punkten vergeben werden. Die Werte für die ersten fünf Kriterien werden addiert. Vom Ergebnis subtrahiert man den Wert für den internen Ressourcenbedarf. Dieser Punktwert ist ein Kriterium für die Priorisierung der Projekte. Systemtechnisch wird für die Bewertung eine MS Excel-Anwendung eingesetzt. Die Ergebnisse können auch mit Bubble-Charts dargestellt werden. Die Erfahrung bei der Coca-Cola Erfrischungsgetränke AG zeigt, dass durch gemeinsame Meetings mit den anderen Fachbereichen und die Abstimmung mit der Abteilung Corporate Relations die Projekte realistisch bewertet werden. Dazu tragen auch die zusätzliche monetäre Bewertung des operativen Nutzens und die Abschätzung der internen Ressourcen durch die IT-Abteilung bei. Der Prozess der Projektpriorisierung wird auch von Projektmanagementsystemen wie OPX2 von Planisware unterstützt. Dort wird Genehmigungsprozess als Workflow abgebildet. Für jeden Prozessschritt wird dokumentiert, welche Personen in welcher Form Aufgaben und Verantwortung übernehmen. Die Hinterlegung der Verantwortlichkeiten erfolgt über eine spezielle Verantwortlichkeitsmatrix (vgl. Abb. 33). Der Workflow beginnt mit der Anlage eines neuen Projektantrags. In eine entsprechende Bildschirmmaske trägt der Antragsteller alle für diesen ersten Schritt im Beantragungsprozess relevanten Informationen ein. Sobald er seine Eingabe abgeschlossen hat, stößt er automatisch den nächsten Prozessschritt an. Die entsprechend verantwortlichen Personen werden nun z.B. per Mail oder direkt in

44

Wieder, G., Das Projektportfolio strategisch steuern Projektpriorisierung bei der Coca-Cola Erfrischungsgetränke AG, Projektmagazin 3/2006, www.projektmagazin.de, S. 6.

47


OPX2 darüber informiert, dass ein neuer Antrag gestellt wurde und welche Aufgabe nun von ihnen erwartet wird.

Abb. 33: Verantwortlichkeitsmatrix in OPX2 Für die Definition neuer Strategien stehen drei Bewertungsgruppen zur Verfügung: Risiken, Chancen und finanzielle Kriterien. Abb. 34 zeigt am Beispiel der Strategie „Verbesserung der Wettbewerbsfähigkeit“ (Competition) die Gewichtung der Kriterien „Konkurrenzbedingte Notwendigkeit“ (mit Faktor 10 gewichtet) und Risiko (mit Faktor -2 gewichtet). Im Projektantrag P0127 wird mit Punkten dokumentiert, inwiefern die beiden Kriterien der Strategie erfüllt sind. Strategie: Competition

Bewertung des Projektantrag P0127

Abb. 34: Projektbewertung in OPX2 Auf Grundlage der oben definierten Strategie wird ein Projektranking erstellt. Für die Priorisierung eines Projekts wird folgende Formel verwendet: ሺ‫ ݈ܼ݁݁݅ ݄݈݁ܿ݅ݐ݂݄ܽܿݏݐݎ݅ݓ ݃݊ݑݐݎ݁ݓ݁ܤ‬൅ ‫݋݇݅ݏ݅ݎݐ݉ܽݏ݁ܩ ݃݊ݑݐݎ݁ݓ݁ܤ‬ሻ ܵ‫݁ݐ݄ܿ݅ݓ݁ܩ ݎ݁݀ ݁݉݉ݑ‬ ሺʹͷ ൈ ͳͲ ൅ ሺെʹሻ ൈ ʹ͹ሻ ൌ ʹͶǡͷ ͺ

48


Abb. 35 zeigt das aus der Bewertung resultierende Ranking. Das betrachtete Projekt P0127 steht auf Rang 1. Die Gesamtchance wird mit 79 Punkten angegeben, das Risiko ist mit 27 Punkten relativ gering, der ROI beträgt 14,7 Prozent.

Abb. 35: Projektpriorisierung in OPX2 2.1.3.2 Portfolios

Wie wird die Portfoliotechnik eingesetzt? Mit Portfolios beurteilt man im Überblick geplante oder sich in Bearbeitung befindende Projekte bezüglich bestimmter Kriterien. Damit bilden sie eine gute Grundlage für strategische Entscheidungen. Portfolios können auch eingesetzt werden, um die Projektattraktivität zusätzlich zur Nutzwertanalyse zu verdeutlichen. Dafür wählt man zwei wichtige Attraktivitätskriterien aus, z. B. wie in Abb. 36 die Dringlichkeit und die strategische Bedeutung, und positioniert die Projekte im Portfolio. Anschließend kann das Management die Projekte vor dem Hintergrund der strategischen Unternehmensziele analysieren und notwendige Änderungen diskutieren.

Wie sieht ein Portfolio zur Priorisierung von Projekten aus? Bei der Versicherungsgruppe Münchner Verein wird ein Portfolio zur Beurteilung der Dringlichkeit und Bedeutung von Projekten verwendet.45 Ausgangspunkt der Konzeption ist eine allgemeine Empfehlung, wie man unterschiedliche Aufgaben unter Zeitdruck abarbeiten soll (vgl. Abb. 36). 45

May, G., Chrobok, R., Priorisierung des unternehmerischen Projektportfolios. zfo (2001) 2, S. 108-114.

49


Strategische Bedeutung der Aufgabe

hoch Auf Termin legen (3. Priorität)

Sofort selbst erledigen (1. Priorität)

Papierkorb (eliminieren)

Delegieren (2. Priorität)

niedrig niedrig

hoch

Dringlichkeit der Aufgabe

Abb. 36: Priorisierung von Aufgaben In Anlehnung an Abb. 36 werden alle Projekte nach ihrer Dringlichkeit und strategischen Bedeutung in einem Portfolio positioniert (vgl. Abb. 37). Um für ein konkretes Projekt die strategische Bedeutung und die Dringlichkeit zu bestimmen, kann man jeweils eine Präferenzmatrix erstellen (das Instrument wird in Abb. 27 erklärt).

67 2 a

Projekt a Projekt b

33 1 c

Projekt c

0 0 d

Projekt d

Prozent Anzahl Ziel

100 3 b

b b c

a b

a


100%

b erste Priorität

a

c d Dringlichkeit 0 0 a

Projekt a

67 2 b

Projekt b

100 3 c

Projekt c

33 1 d

Projekt d

100%

b c c

c b

Abb. 37: Priorisierung der Projekte durch paarweisen Vergleich

50

d


Durch paarweisen Vergleich jedes anstehenden Projekts mit jedem anderen errechnen sich Bedeutung und Dringlichkeit aller Vorhaben. Projekte mit hoher Dringlichkeit und strategischer Bedeutung erhalten die erste Priorität. Bei Projekten im rechten unteren Quadranten ist zu prüfen, ob man sie nicht auf externe Dienstleister übertragen kann. Kann-Projekte, die weder dringlich, noch strategisch bedeutsam sind, sollten im Regelfall überhaupt nicht ausgeführt werden.

Was sagt ein Risiko-/Attraktivitätsportfolio aus? Die Unternehmensberatung Arthur D. Little schlägt ein Projektportfolio vor, um die vielversprechendsten Entwicklungsvorschläge zu identifizieren.46 Beurteilungsmaßstab ist das Verhältnis von Attraktivität und Risiko (vgl. Abb. 38). Die Kreisgröße in Abb. 38 gibt den Anteil eines Projekts am Projektbudget wieder. niedrig

7

1

Risiko

6

2

„So what?Projekte“ 5

4 „Dead ducks“ hoch niedrig

„HeißeProjekte“ 3 „VabanqueProjekte“

Attraktivität

hoch

Abb. 38: Portfolio für Forschungs- und Entwicklungsprojekte Attraktivität Die Attraktivität eines Projektes legt man fest, indem Umsatz- und Ertragspotenziale, Marktvolumen, Marktwachstum, Differenzierungspotenzial oder die Dauerhaftigkeit des Wettbewerbsvorsprungs beurteilt werden. Die Attraktivität beeinflusst die Projektauswahl erheblich. Innovative Projekte, die technologisch bestechen, werden abgelehnt, wenn deren Attraktivität gering ist. Umgekehrt realisiert man ein Projekt, 46

Sommerlatte, T., F&E-Controlling aus strategischer und operativer Perspektive, in: Steinle, C., Bruch, H. (Hrsg.), Controlling, Stuttgart 1998, S. 694-707.

51


sobald ein hohes Ertragspotenzial gegeben ist, auch wenn es sich lediglich um eine marginale Produktverbesserung handelt. Risiko Zu unterscheiden sind technische und wirtschaftliche Risiken (vgl. dazu auch Abschnitt 3.1.10 über das Risikocontrolling). Das technische Risiko für eine Software ist z. B. hoch, wenn eine wenig erprobte Entwicklungsumgebung eingesetzt werden muss. Das wirtschaftliche Risiko besteht darin, dass Prognosen über Marktwachstum oder Ertragspotenziale unsicher sind. Bei Henkel unterscheidet man sechs Risikobereiche: technologisches Know-how, potenzielle Nutzungsdauer, Wettbewerbssituation, Sicherheit der technischen Zielerreichung, Sicherheit der wirtschaftlichen Zielerreichung und Time-to-Market.47 Das Portfolio in Abb. 38 weist besonders auf Ungleichgewichte und damit auf notwendige Veränderungen hin. Befinden sich z. B. viele Projekte im Quadranten mit hohem Risiko und hoher Attraktivität (Vabanque-Projekte), muss man sich überlegen, wie das Risiko der betroffenen Projekte reduziert werden kann und inwiefern neue risikobehaftete Projekte überhaupt noch in Angriff genommen werden dürfen. Die Airbus GmbH verwendet das Portfolio der Abb. 38 für Forschungs- und Entwicklungsprojekte. Das Unternehmen gewährleistet ein ausgeglichenes Risiko dadurch, dass 80 Prozent des Forschungs- und Entwicklungsbudgets in weniger als zehn Projekten mit geringem Risiko gebunden sind. Fünf Prozent der Mittel verteilen sich auf 50 hoch riskante Projekte.48 Die BMW AG verwendet ein Portfolio, das den Risikoaspekt sehr stark berücksichtigt (vgl. Abb. 39).

47

48

52

Gerhardt, W., Knobel, C., Portfoliomanagement zur effizienten Auswahl von Projekten, in: Boutellier, R., Völker, R., Voit, E. (Hrsg.), Innovationscontrolling, München, Wien 1999, S. 89. Henning, J., Was muss ein erfolgreiches F + E-Controlling leisten?, in: Boutellier, R., Völker, R., Voit, E. (Hrsg.), Innovationscontrolling, München, Wien 1999, S. 40.


Markt-Risiken

hoch

Check (Market Research)

Stop

Stop

Push

Check

Stop

Push

Push

niedrig niedrig

Check (Feasibility Study)

Technische Risiken

hoch

Abb. 39: Risikoportfolio 2.1.3.3 Wirtschaftlichkeitsverfahren Neben strategischen Erwägungen spielt vor allem die Wirtschaftlichkeit eine entscheidende Rolle bei der Projektauswahl. Abb. 40 zeigt im Überblick die gängigen Verfahren. In der Praxis besteht die größte Schwierigkeit in der Beschaffung zuverlässiger Daten, weniger in der Anwendung der Verfahren. Kostenvergleich

statische Verfahren Wirtschaftlichkeitsverfahren

Gewinnvergleich Rentabilitätsrechnung Amortisationsrechnung

dynamische Verfahren

Kapitalwertmethode Interne Zinsfußmethode

Abb. 40: Wirtschaftlichkeitsverfahren für die Projektauswahl

53


Wie führt man eine Gewinnvergleichsrechnung durch? Um die Vorteilhaftigkeit eines Projektes zu ermitteln, ist eine reine Kostenbetrachtung im Regelfall unzureichend. Für die Entscheidung, welches von zwei Projekten die höhere Priorität genießt oder ob ein neues Projekt bei begrenzten Ressourcen begonnen wird, sind der Gewinn (bei internen Projekten können auch eingesparte Kosten angesetzt werden) und der Deckungsbeitrag (Erlöse minus direkt zurechenbarer variabler Kosten) die besseren Kriterien. Schließlich werden Projekte deswegen bearbeitet, um das Unternehmensergebnis zu optimieren. Allerdings reichen bei knappen Ressourcen Informationen über den voraussichtlichen Gewinn eines Projektes nicht aus. In diesem Fall müssen die Auswirkungen eines zusätzlichen Projektes auf die laufenden Projekte mit in die Betrachtung einbezogen werden. Dies soll am folgenden Beispiel verdeutlicht werden: Ein Unternehmen wickelt vier Projekte ab. Dem Management sind folgende Plandaten bekannt (vgl. Abb. 41): Projekt P1 P2 P3 P4

Erlöse Restliche Dauer 2.000 € 4 Wochen 4.000 € 6 Wochen 10.000 € 8 Wochen 20.000 € 12 Wochen Erwarteter Gesamterlös: Gesamte Restkosten: Erwarteter Gewinn:

Restkosten 500 € 2.000 € 4.000 € 6.000 € 36.000 € 12.500 € 23.500 €

Abb. 41: Gewinnsituation im Ausgangsfall Zur Disposition steht ein sehr profitables Projekt P5. Es würde 14 Wochen dauern, 25.000 € Erlös und voraussichtliche Kosten von 7.000 €, also einen Gewinn von 18.000 € bringen. Zur Realisierung müsste man auch auf Ressourcen zurückgreifen, die für die anderen Projekte benötigt werden. Bei oberflächlicher Betrachtung würde das neue Projekt aufgrund der sehr positiven Datenlage begonnen, ohne im Einzelnen die Auswirkungen auf bereits laufende Projekte zu berücksichtigen. Notwendig wäre es aber in diesem Fall, eine gesamtheitliche Betrachtung anzustellen. Dafür sind zusätzliche Daten darüber, mit welchen Erlöseinbußen/zusätzlichen Erlösen eine Verlängerung/

54


Verkürzung der jeweiligen Projektlaufzeit verbunden ist, hilfreich.49 Verlängert sich die Projektdauer, bedeutet dies oft geringere Erlöse, weil Vertragsstrafen fällig werden oder weil sich der Markteintritt verspätet. Diese Informationen werden in der folgenden Tabelle angezeigt: Projekt

P1 P2 P3 P4 P5

Erlöse

2.000 € 4.000 € 10.000 € 20.000 € 25.000 €

Restliche Dauer 4 Wochen 6 Wochen 8 Wochen 12 Wochen 14 Wochen

Erlöseinbuße pro Woche Verspätung 5% 15 % 20 % 25 % 10 %

Zusätzlicher Erlös pro Woche Verkürzung 10 % 10 % 10 % 10 % 5%

Restkosten 500 € 2.000 € 4.000 € 6.000 € 7.000 €

Abb. 42: Erlöseinbußen bei einer Projektverlängerung Nach eingehender Analyse der Auswirkungen von P5 auf die anderen Projekte, deren Dauer sich durch die zusätzliche Inanspruchnahme der Ressourcen verändert, ergeben sich folgende Daten (vgl. Abb. 43): Projekt P1 P2 P3 P4 P5

Erlöse

Restliche Dauer (bei 5 Projekten) 2.000 € 4 Wochen 2.800 € 8 Wochen 6.000 € 10 Wochen 5.000 € 15 Wochen 25.000 € 14 Wochen Erwarteter Gesamterlös: Gesamte Restkosten: Erwarteter Restgewinn:

Restkosten 500 € 2.000 € 4.000 € 6.000 € 7.000 € 40.800 € 19.500 € 21.300 €

Abb. 43: Gewinnsituation bei einem zusätzlichen Projekt Die Analyse zeigt, dass sich durch die zusätzliche Bearbeitung des angebotenen Projektes P2 und P3 jeweils um zwei Wochen und P4 um drei Wochen verlängern würden. Das Gesamtergebnis verschlechterte sich in diesem Fall um 2.200 €. Unter diesen Bedingungen wäre P5 abzulehnen.

49

Devaux, S., Total Project Control. A Manager´s Guide to Integrated Project Planning, Measuring and Tracking, New York u. a. 1999, S. 8 ff.

55


Durch eine Veränderung der Ausgangsdaten kann man versuchen, die Situation zu optimieren. In der nächsten Tabelle (vgl. Abb. 44) wurde die Dauer von P5 auf 16 Wochen verlängert, dafür können knappe Ressourcen vermehrt für P4 eingesetzt werden. Dies führt zu einer geringeren Dauer von P4 und damit zu einer Verbesserung des Gesamtergebnisses von ursprünglich 23.500 € auf 26.300 €. Projekt

Erlöse

Restliche Dauer (bei 5 Projekten) 2.000 € 4 Wochen 2.800 € 8 Wochen 6.000 € 10 Wochen 15.000 € 13 Wochen 20.000 € 16 Wochen Erwarteter Gesamterlös: Gesamte Restkosten: Erwarteter Restgewinn:

P1 P2 P3 P4 P5

Restkosten 500 € 2.000 € 4.000 € 6.000 € 7.000 € 45.800 € 19.500 € 26.300 €

Abb. 44: Gewinnsituation nach der Optimierung Die Berechnung der Erlöseinbußen/Mehrerlöse, die aus einer Verlängerung/Verkürzung der Projekte resultieren, ermöglicht es, die drei Einflussfaktoren des „magischen Dreiecks“ gemeinsam in einer einheitlichen monetären Größe zu betrachten (vgl. Abb. 45). Dies erleichtert Entscheidungen, weil man z. B. schnell erkennt, ob sich eine Verkürzung der Projektdauer lohnt. Die dadurch erzielten zusätzlichen Erlöse müssen nur den Mehrkosten, die durch Überstunden oder teure externe Mitarbeiter entstehen können, gegenübergestellt werden. Termine (Mehr- oder Mindererlös in € bei einer Änderung der Plandauer)

Kosten (in €)

Leistung (Erlös in €)

Abb. 45: Monetäre Bewertung des „magischen Dreiecks“

56


Wie führt man Break-Even-Analysen durch? Eine häufig verwendete Variante des Gewinnvergleichs ist die Break-Even-Analyse. Sie zeigt, ab welcher Absatzmenge, welchem Erlös oder Zeitpunkt mit der Projektleistung Gewinn erzielt wird (vgl. Abb. 46). Erlöse, Kosten

geplanter Kostenverlauf

Zeit Meilenstein

Break-Even-Punkt (Gewinnschwelle)

Markteintritt

Marktaustritt

Amortisationsdauer (Pay Back Periode)

Abb. 46: Break-Even-Analyse Um die Menge, ab der Gewinn erzielt wird zu errechnen, verwendet man die Formel: ‫ ݔ‬ൌ

‫ܭ‬௙ ‫ ݌‬െ ݇௩

Definition

Alternativ kann der Umsatz bestimmt werden, ab dem der Gewinn größer null ist: ‫ݔ‬௣ ൌ

‫ܭ‬௙ ͳെ

݇௩ ‫݌‬

x = Break-Even-Menge, xp = Break-Even-Umsatz, Kf = fixe Kosten, kv = variable Kosten/Stück, p = Preis

Der Break-Even-Punkt und die daraus abgeleitete Amortisationsdauer sind wichtige Kriterien für die Entscheidung, ob sich ein Projekt lohnt. 57


Mit der Break-Even-Analyse können auch die Auswirkungen von Budgetüberschreitungen in der Entwicklungsphase auf den geplanten Gewinn simuliert werden. In Abb. 46 erkennt man z. B., dass durch die eingezeichneten ungeplanten Mehrkosten der Entwicklung, die am Meilenstein festgestellt wurden, bis zum Marktaustritt kein Gewinn mehr zu erzielen ist. Die Break-Even-Analyse hilft auch abzuschätzen, ob bei einer Verzögerung der Entwicklung und dem dadurch verspäteten Markteintritt noch genügend Zeit zur Verfügung steht, um die Gewinnzone zu erreichen. Somit liefert die Break-Even-Analyse eine Entscheidungsgrundlage für den Abbruch von Projekten. Trotz der vereinfachten Annahmen (z. B. lineare Verläufe der Erlöse und Kosten) ist die Break-Even-Analyse für die langfristige Erfolgseinschätzung von Entwicklungsvorhaben sehr vorteilhaft. Sie fördert ein langfristiges Denken über das reine Projekt hinaus. Ein Änderungsvorschlag wird nicht nur isoliert aus der Sicht von Vertrieb, Produktion oder Controlling beleuchtet. Es ist vielmehr immer die Ergebniswirkung ersichtlich. Diskussionen werden dadurch versachlicht.

Wie führt man eine Rentabilitätsrechnung durch? Mit Kosten- und Gewinnvergleichen kann man die relative Vorteilhaftigkeit einer Alternative gegenüber einer anderen ermitteln. Um zu entscheiden, ob ein Projekt überhaupt sinnvoll ist, muss dessen Rentabilität berechnet werden (alternativ können auch die Amortisationsdauer, der Kapitalwert oder der interne Zinsfuß Verwendung finden). Dabei wird der zusätzliche durchschnittliche Jahresgewinn, der durch das Projekt erzielt werden kann, zum zusätzlich gebundenen Kapital in Beziehung gesetzt. Definition

ܴ݁݊‫ ݐ¡ݐ݈ܾ݅݅ܽݐ‬ൌ

‫ ݊݊݅ݓ݁ܩ‬ൈ ͳͲͲ ‫݈ܽݐ݅݌ܽܭ‬

Sind Erlöse nicht zurechenbar, verwendet man stattdessen die Kostenersparnis, die durch ein Projekt erzielt werden kann. Um die durchschnittliche Kapitalbindung zu ermitteln, setzt man häufig 50 Prozent des Wiederbeschaffungswertes des eingesetzten Equipments an. Nur wenn die für ein Vorhaben errechnete Rentabilität über einem vorgegebenen Prozentsatz liegt, der sich in der Praxis oft zwischen 12 Prozent und 15 Prozent bewegt, wird das Projekt genehmigt.

58


Der Rentabilitätsvergleich kann durch Berücksichtigung des Umsatzes aufschlussreicher werden. Man errechnet den so genannten Return on Investment (ROI) als Spitzenkennzahl eines Systems einzelner Kennziffern, die sich gegenseitig ergänzen (vgl. Abb. 47). Auch Abhängigkeiten zwischen den Kennzahlen werden deutlich. Dadurch können verschiedene Szenarien simuliert werden, die zu einem geforderten ROI führen. Verkaufserlöse

Return on Investment

Deckungsbeitrag

-

Gewinn

-

variable Kosten

Umsatzrendite

÷

fixe Kosten

x

Umsatz

Kapitalumschlag

÷

Vorräte

Bilanzsumme

Anlagevermögen + Umlaufvermögen + RAP

+ Forderungen + Liquide Mittel +

RAP = Rechnungsabgrenzungsposten

Aktive RAP

Abb. 47: Das Kennzahlensystem Return on Investment

Wie führt man eine Amortisationsrechnung durch? Durch den Amortisationsvergleich wird die Zeit der Rückgewinnung des eingesetzten Kapitals ermittelt. Die Investitionsentscheidung hängt von der so genannten Amortisationsdauer (Pay-off-Periode) ab. Sie zeigt das Risiko auf, das mit einer Investition verbunden ist. Je länger es dauert, bis die investierten Mittel zurückgeflossen sind, desto größer ist das Risiko. ‫ ݎ݁ݑܽ݀ݏ݊݋݅ݐܽݏ݅ݐݎ݋݉ܣ‬ൌ

‫ݖݐܽݏ݈݊݅݁ܽݐ݅݌ܽܭ‬ ‫ݏ݃݊ݑ݈݄ܽݖ݊݅ܧ‬üܾ݁‫݄ܿݏݎ‬ü‫ݎ݄ܽܬ ݋ݎ݌ ݁ݏݏ‬

Definition

Ein Projekt ist positiv zu beurteilen, wenn die Amortisationsdauer unter der zulässigen Amortisationszeit liegt. Von mehreren Alternativen ist diejenige mit der kürzesten Amortisationsdauer zu wählen.

59


Wie errechnet man den Kapitalwert? Die Kapitalwertmethode gehört, wie die interne Zinsfußmethode, zu den dynamischen Verfahren. Bei Ihnen wird im Gegensatz zu den statischen Verfahren der Zeitpunkt einer Ein- oder Auszahlung durch eine entsprechende Abzinsung berücksichtigt. Verwendung finden beide Verfahren vor allem dann, wenn sich die durch ein Projekt verursachten Ein- und Auszahlungen im Zeitablauf ändern. Definition

௡

‫ ݐݎ݁ݓ݈ܽݐ݅݌ܽܭ‬ൌ ෍ሺ‫ܧ‬௧ െ ‫ܣ‬௧ ሻ ൈ ௧ୀଵ

At = Auszahlung im Jahre t, I = Kapitalisierungszinsfuß, A0 = Anschaffungsauszahlung im Jahre 0

ͳ െ ‫ܣ‬଴ ሺͳ ൅ ݅ሻ௧

Et = n =

Einzahlung im Jahre t Zahl der Nutzungsjahre

Zur Errechnung des Kapitalwerts kann man auch wie in Abb. 48 vorgehen. Ein Projekt ist lohnend, wenn der Kapitalwert größer Null ist. Von mehreren Alternativen ist diejenige mit dem höchsten Kapitalwert zu wählen. Da die Daten für eine Kapitalwertrechnung unsicher sind, sollte die Rechnung differenziert werden. Für die wesentlichen Einflussfaktoren des Kapitalwerts • • • •

Einzahlungen, Auszahlungen, Zins und Investitionssumme am Anfang

sollten pessimistische, wahrscheinliche und optimistische Annahmen getroffen werden. Die so entstehenden Kapitalwerte zeigen die Spannbreite der möglichen Ergebnisse. Man kann auch einen gewichteten Kapitalwert nach folgender Formel errechnen: Definition

ͳ ൈ ‫ܭ‬௣ ൅ Ͷ ൈ ‫ܭ‬௪ ൅ ͳ ൈ ‫ܭ‬௢ ͸ Kp = pessimistischer Kapitalwert, Kw = wahrscheinlicher Kapitalwert, Ko = optimistischer Kapitalwert

60

2.1 Strategische Projektplanung Kapitalrückfluss (Einzahlungen oder Einsparungen) pro Periode ermitteln und mit einem festgelegten Zinssatz abzinsen. Wenn die Summe der abgezinsten Kapitalrückflüsse (= Einspareffekt) unbedeutend ist, kann die aufwändige Ermittlung des Kapitalbedarfs entfallen, da das Projekt voraussichtlich nicht wirtschaftlich sein wird.

Kapitalrückflüsse

¦

...

t1

Kapitalbedarf (Auszahlungen) pro Periode ermitteln und abzinsen.

t2

t3

tn

Kapitalbedarf

¦

... t1

Kapitalwert ermitteln: Summe der abgezinsten Kapitalrückflüsse R - Summe der abgezinsten Kapitalbedarfe B - Anschaffungsauszahlung A

t4

t2

t3

t4

tn

Kapitalwert ¦ R

A ¦ B

Abb. 48: Ermittlung des Kapitalwerts Bei der BASF Pharma AG verwendet man zur Beurteilung von Entwicklungsprojekten den diskontierten Net Present Value (NPV), der große Ähnlichkeit mit dem Kapitalwert hat. 50 Für einen Planungszeitraum von zehn bis 15 Jahren wird die jährlich erwartete Differenz der Kosten und Umsätze ermittelt, abgezinst und summiert. Bereinigt man das Ergebnis um die Investitionskosten, erhält man den NPV. Es werden verschiedene Szenarien mit jeweils eigenem NPV gebildet (vgl. Abb. 49). Der NPV jedes Szenarios wird mit einer geschätzten Eintrittswahrscheinlichkeit gewichtet. Die Summe der NPV aller Szenarien ergibt den erwarteten Gesamt-NPV. Er muss positiv sein. Mit der wertorientierten Projektbeurteilung wurde die Zahl der Projekte bei der BASF Pharma AG von 30 auf 23 verringert. Damit standen Ressourcen für andere Vorhaben zur Verfügung. Weitere Konsequenzen waren: •

Die Diskussion in den einzelnen Projektteams wurde versachlicht.

50

Lechner, F., Wertorientierte Projektwahl, dargestellt am Beispiel der Pharmabranche, in: Boutellier, R., Völker, R., Voit, E. (Hrsg.), Innovationscontrolling, München, Wien 1999, S. 136 ff.

61


•

Die Risiken und Chancen der Projekte wurden sorgfältiger analysiert.

Problematisch war der hohe Zeitaufwand für die Ermittlung und Aufbereitung der Grunddaten. optimistisch pessimistisch Abbruch

Abbruch

Beginn

Abbruch

A

NPV 1 * P1

B

NPV 2 * P2

C

NPV 3 * P3

D

NPV 4 * P4

E

NPV 5 * P5

Meilenstein

Summe NPV

P

Eintrittswahrscheinlichkeit

A

Projektszenario

Abb. 49: Berechnung des Net Present Value

Wie führt man die interne Zinsfußmethode durch? Bei der internen Zinsfußmethode wird derjenige Zinsfuß gesucht, der zu einem Kapitalwert von Null führt. Definition

௡

෍ ሺ‫ܧ‬௧ െ ‫ܣ‬௧ ሻ ൈ ௧ୀଵ

At i

= =

Auszahlung im Jahre t, Kapitalisierungszinsfuß,

ͳ ൌͲ ሺͳ ൅ ݅ሻ௧ Et = n =

Einzahlung im Jahre t Zahl der Nutzungsjahre

Ein Projekt ist wirtschaftlich, wenn der Kapitalisierungzinsfuß i über der geforderten Mindestverzinsung liegt. Von mehreren Alternativen ist diejenige mit dem höchsten internen Zinsfuß zu wählen.

Wie wird der Beitrag zum Unternehmenswert gemessen? Der wirtschaftliche Nutzen eines Projektes kann mit dem Gewinnkonzept (Gewinn-, Kostenvergleich, Amortisationsrechnung), mit

62


dem Renditekonzept (Rentabilität, Kapitalwert, interner Zinsfuß) und auch anhand des Überrenditekonzepts ermittelt werden. Dabei muss der Erfolg höher als die Kapitalkosten (Fremdkapitalkosten + Eigenkapitalkosten + Risikokosten) sein.51 Gängige Verfahren sind Discounted Cash Flow (DCF), Economic Value Added (EVA) und Cash Flow Return on Investment (CFROI). Abb. 50 zeigt, wie ein Projekt den Economic Value Added beeinflussen kann.

EVA

Operatives Ergebnis

Umsatz

Steuern

Herstellkosten

-

Vertriebskosten

Kosten Vermögen Kapitalkosten

x Kapitalkostensatz

+

Verwaltungskosten

PR OJ E K T

Net Operating Profit (NOPAT)

FuEkosten Sonstige Kosten

Abb. 50: Einfluss der Projekte auf den Unternehmenswert 2.1.4 Analyse der Abhängigkeiten In der betrieblichen Realität beeinflussen sich Projekte in unterschiedlicher Art und Weise:52 • • •

51

52

Innovationszusammenhang: Ein Projekt schafft die konzeptionellen Voraussetzungen für andere. Integrationszusammenhang: Ein Projekt muss zusammen mit anderen Projekten realisiert werden, um das Gesamtziel zu erreichen. Investitionszusammenhang: Ein Projekt hat Auswirkungen auf die Kosten anderer Projekte.

Ossadnik, W., Wolf, D., Kossen, K., Optimierte Projektsteuerung durch wertorientierte Produktlebenszyklusrechnungen. Controlling 21. Jg. 2009, H. 2, S.118-125. Kargl, H., Projektcontrolling, HMD (2001) 217, S. 14-21.

63


Die Abhängigkeiten müssen aufgezeigt werden, da sie zusammen mit der Attraktivität die Priorisierung festlegen. Bei der Münchner Verein Versicherungsgruppe wird folgendes Verfahren zur Analyse der Projektinterdependenzen eingesetzt:53 Mit paarweisen Vergleichen in einer Einflussmatrix (vgl. Abb. 51) ermittelt man die gegenseitigen direkten Abhängigkeiten. Wirkung Wirkung von

auf

Beeinflusste Projekte Projekt a

Einflussnehmende Projekte

Projekt a Projekt b Projekt c Projekt d Summe Beeinflussung

1 1 1 3

Projekt b Projekt c

1 1

Summe Projekt d Einfluss

1

1

1

1

0 3 1 2 6

Abb. 51: Einflussmatrix Stellt man einen Einfluss fest, trägt man am jeweiligen Kreuzungspunkt eine 1 ein. In der Abb. erkennt man, dass Projekt b von Projekt d abhängt und selbst die Projekte a, c und d beeinflusst. Um das Verfahren einfach zu halten, wird nicht nach der Intensität der Einflussnahme unterschieden. Im Beispiel wären theoretisch 12 Abhängigkeiten möglich (Anzahl Projekte x (Anzahl Projekte – 1)). Da in Summe nur sechs Abhängigkeiten auftreten, kann man von einem durchschnittlichen Vernetzungsgrad sprechen. Das Ergebnis der Einflussmatrix wird für die Präsentation und Analyse in ein Portfolio übertragen (vgl. Abb. 52).

Beeinflussung

hoch

a Passive Projekte

Kritische Projekte

c Träge Projekte

d

b

Aktive Projekte

(1. Priorität)

gering gering

Einflussnahme

hoch

Abb. 52: Portfolio zur Analyse der Abhängigkeiten 53

64

May, G., Chrobok, R., Priorisierung des unternehmerischen Projektportfolios, zfo (2001) 2, S. 108-114.


Im Portfolio sind vier Bereiche zu unterscheiden: 1. Aktive Projekte Projekte im rechten unteren Quadranten nehmen Einfluss auf andere Projekte, sind aber selbst unabhängig. Sie erhalten deswegen eine hohe Bearbeitungspriorität, um die reibungslose Bearbeitung der abhängigen Projekte zu gewährleisten. 2. Kritische Projekte Projekte rechts oben weisen eine hohe Vernetzung auf. Einflussnahmen und Abhängigkeiten sind gleichermaßen hoch. Dadurch steigt deren Komplexität und Risiko. Sie sollten besonders sorgfältig analysiert und erst nach Bearbeitung der aktiven Projekte eingesteuert werden. 3. Passive Projekte Sie sind in hohem Maße abhängig von anderen Projekten, nehmen selbst aber kaum Einfluss. Passive Projekte sollten erst mit zeitlichem Abstand zu den übrigen Projekten begonnen werden. 4. Träge Projekte Der Quadrant links unten enthält Projekte mit einem geringen Vernetzungsgrad. Sie sind unkritisch. Ihre Priorität wird stark davon abhängen, wie die Attraktivitätskriterien (Wirtschaftlichkeit, strategische Bedeutung) bewertet wurden. Die Einflussanalyse liefert zusammen mit der Beurteilung der Attraktivität eindeutige Hinweise für die Priorisierung der Projekte. Vergleicht man das Beispiel in Abb. 52 mit Abb. 37 und Abb. 32, so lassen sich folgende Aussagen treffen: • •

• •

Erste Priorität erhält Projekt b. Es beeinflusst viele andere Projekte, hat hohe strategische Bedeutung und ist dringlich. Auch die Gesamtattraktivität ist hoch (vgl. Abb. 32). Projekt d ist weder bedeutsam noch dringlich, auch die übrigen Attraktivitätskriterien werden nur in geringem Maße erfüllt. Deswegen ist zu prüfen, ob dieses Projekt nicht besser aus dem Portfolio genommen wird. Sollte Projekt b realisiert werden, erhält es die zweite Priorität, da es als aktives Projekt andere Vorhaben beeinflusst, aber selbst nicht von anderen Projekten abhängt. Projekt c nimmt aufgrund der Dringlichkeit die dritte Stelle ein. Vorhaben a ist als Muss-Projekt auf jeden Fall zu realisieren. Da a eine geringe Dringlichkeit aufweist und zuerst die auf a Einfluss nehmenden Projekte starten sollten, wird Projekt a mit der niedrigsten Priorität belegt. 65


2.1.5 Analyse der Ressourcenverfügbarkeit und Projektauswahl Aufgrund der Priorisierung ergibt sich eine „Hitliste“ der effektivsten Projekte. Beginnend mit dem an Position eins stehenden Projekt können nun die finanziellen Mittel und die erforderlichen Ressourcen zugeteilt werden. Dabei reicht eine grobe Zuordnung, differenziert nach Qualifikationsprofilen. Sinnvoll ist es, die verfügbaren knappen Ressourcen entlang der Zeitachse zu ermitteln und einzuplanen. Damit nicht einzelne Projektarten, typischerweise sind das oft DVProjekte, den größten Teil der Mittel verbrauchen, kann es sinnvoll sein, Obergrenzen der Budgetzuteilung festzulegen. Bei der Versicherungskammer Bayern wurde beinahe das gesamte Budget durch IT-Projekte aufgebraucht. Als man dies erkannte, wurden drei Projektklassen gebildet und Obergrenzen für deren Anteil am Gesamtbudget festgelegt (vgl. Abb. 53). Für alle Projekte zur Erschließung neuer Märkte werden maximal 20 Prozent des Gesamtbudgets, für IT-Projekte 60 Prozent und für Projekte zur Verbesserung der Geschäftsprozesse 20 Prozent ausgegeben. Klasse 1: Projekte zur Erschließung neuer Märkte

Klasse 3: IT–Projekte - Data Warehouse - Neue Controllingsysteme

- Neue Produkte - Aktionen am Markt Klasse 2: Organisationsprojekte - Prozessoptimierung - Rationalisierung

Abb. 53: Ausgewogenheit des Projektportfolios Die Prüfung der Ressourcen- und Mittelverfügbarkeit kann zum Ergebnis führen, dass das bis dahin geplante Projektportfolio aufgrund von Ressourcenengpässen oder nicht ausreichendem Budget zu überarbeiten ist. Manche Projekte können vielleicht nicht zum vorgesehenen Termin gestartet werden, bei anderen wird man den Leistungsumfang kürzen.

66


Wie kann man das Budget auf Projekte verteilen? Das zur Senkung von Gemeinkosten verwendete Zero Base Budgeting kann auch auf Projekte übertragen werden. 54 Die Methode wird eingesetzt, um ein Gesamtbudget auf einzelne Projekte mit unterschiedlichen Leistungsniveaus zu verteilen. Die einzelnen Schritte des ZBB sind aus Abb. 54 ersichtlich. Vorbereitung (ca. 2 Wochen)

Festlegung der Projektziele und Untersuchungsbereiche Festlegung interner Entscheiseinheiten und deren Ziele

Bestimmung von Ergebnisniveaus für jede Abteilung

Analyse und Planung (ca. 14 Wochen)

Ermittlung von Verfahren zur Zielerreichung, Kostenermittlung

Definition von Entscheidungspaketen

Festlegung einer Rangordnung

Entscheidung über Mitteleinsatz und Budgetschnitt

Maßnahmenplanung (ca. 10 bis 12 Wochen)

Festlegung konkreter Maßna hmen

Rea lisierung und Überwachung (dauernd)

Erarbeitung, Überwachung der Budgetvorgaben

Abb. 54: Ablauf des Zero Base Budgeting 54

Mörsdorf, M., Konzeption und Aufgaben des Projektcontrolling, München 1998.

67


Die Entscheidungseinheiten in Schritt zwei der Abb. 54 entsprechen einzelnen Projekten. Für jedes vorgeschlagene Projekt sind drei verschiedene Ergebnisniveaus zu beschreiben sowie deren Aufwand festzulegen (vgl. Abb. 55): Ein Minimalniveau, das auf jeden Fall erreicht werden muss, sowie ein Normal- und ein Maximalniveau mit den gegenüber der Minimalleistung zusätzlich anfallenden Aufwendungen. Jedes Ergebnisniveau eines Projekts bildet ein so genanntes Entscheidungspaket. Ergebnisniveau

Beschreibung

Personaleinsatz

Sachmittel

Investitionsmittel

300 Std.

50.000 €

0€

B1

Minimal

Datenträgeraustausch

B2

Normal

Gemietete 50 MBitLeitung

-200 Std.

+150.000 €

+20.000 €

B3

Maximal

100 MbitStandleitung

+/-0 Std.

+300.000 €

+100.000 €

Abb. 55: Ergebnisniveaus für das Projekt „Vernetzung“ Abb. 55 zeigt die Definition der Leistungsniveaus für das Projekt B „Vernetzung“. Um die Mindestanforderungen zu erfüllen, reicht ein Datenträgeraustausch. Dafür fallen 50.000 € für Sachmittel und 300 Personalstunden an. Investitionen sind nicht nötig. Das normale Leistungsniveau wird mit einer gemieteten 50 MBit-Leitung erreicht. Gegenüber dem minimalen Leistungsniveau sind 200 Personalstunden weniger erforderlich, also insgesamt nur 100 Stunden. Die Kosten für Sachmittel belaufen sich auf zusätzliche 150.000 €, insgesamt auf 200.000 €. Darüber hinaus sind Investitionen von 20.000 € nötig. Die Entscheidungspakete aller Projekte werden in eine Rangordnung gebracht. Dabei müssen die Entscheidungspakete mit niedrigen Entscheidungsniveaus zuerst berücksichtigt werden (vgl. Abb. 56).

68

Projekt A

Projekt C

C3 A3 A2 B1

C2 Budgetschnitt

B3

B2

C3

A1

B2 B1

C2

A1

C1

C1

Genehmigte Entscheidungspakete

Projekt B

Kosten

Kosten


Abb. 56: Budgetschnitt Für die Vernetzung wird zuerst das minimale Niveau B1 eingeplant. Da noch genügend finanzielle Mittel vorhanden sind, entscheidet man sich für eine gemietete 50 MBit-Leitung und plant entsprechend die dafür zusätzlich erforderlichen Beträge ein. Das Gesamtbudget ist danach aufgebraucht. Es erfolgt der Budgetschnitt. Alle unterhalb des Budgetschnitts liegenden Entscheidungspakete werden realisiert. Zusammenfassend ist festzustellen, dass aus einer systematischen und planvollen Bestimmung des Projektportfolios im Rahmen der strategischen Projektplanung erhebliche Vorteile resultieren: • • • •

Die Projektauswahl steht im Einklang mit der Unternehmensstrategie. Die Anzahl der Projekte wird auf die wirklich wichtigen beschränkt. Es stehen einheitliche Beurteilungskriterien für die Projekte zur Verfügung. Die Gefahr, dass man knappe Ressourcen verschwendet, wird reduziert.

Die vorgestellten Methoden liefern nur die Entscheidungsgrundlage. Die letztendliche Projektauswahl muss immer das Management treffen.

69


2.2

Strategische Projektkontrolle

INPUTINFORMATIONEN

Was? Planungsprämissen, genehmigte Projekte, aktuelle Projektinformationen

AUFGABEN

Welche? Prämissenkontrolle Durchführungskontrolle

Woher? Strategische Planung, Einzelprojekt- und Multiprojektcontrolling

Womit? Balanced Scorecard, Checklisten, Portfoliotechnik

Strategische Überwachung

OUTPUTINFORMATIONEN

Was? Geänderte Prämissen, neue Projektprioritäten, abzubrechende Projekte

Wohin? Strategische Planung, Einzelprojekt- und Multiprojektcontrolling

Abb. 57: Überblick über die strategische Projektkontrolle Die strategische Kontrolle unterscheidet sich von der operativen Kontrolle (vgl. Abschnitt 3.2) dadurch, dass sie auch die Ziele selbst prüft. Es wird geprüft, ob die richtigen Projekte gemacht werden. Zu unterscheiden sind drei unterschiedliche Arten strategischer Kontrolle55: • Prämissenkontrolle, • Durchführungskontrolle und • strategische Überwachung. Die Prämissenkontrolle greift kurz nach der Strategieformulierung zum Zeitpunkt t1 (Abb. 58). Sie untersucht die für eine Strategie zugrunde gelegten Annahmen. Falsche Prämissen können in der 55

70

Steinmann, H., Schreyögg, G., Management. Grundlagen der Unternehmensführung, 6. Aufl., Wiesbaden 2005, S. 279 ff.

2.2 Strategische Projektkontrolle

strategischen Planung zu einer Fehlselektion bei der Zusammenstellung des Projektportfolios führen. Es gilt, sie möglichst schnell aufzuzeigen, damit nicht die falschen Projekte gestartet werden. Die Durchführungskontrolle setzt mit der Umsetzung der Strategie zum Zeitpunkt t2 laut Abb. 58 ein. Sie begleitet die Projektauswahl und überwacht die Projektdurchführung im Sinne eines Multiprojektcontrollings. Dazu werden messbare Zwischenziele (Meilensteine) definiert, deren Ist-Ergebnisse man mit der ursprünglichen Zielsetzung vergleicht. Bei signifikanten Abweichungen sind Gegenmaßnahmen einzuleiten. Sinnvoll ist es, für die Kontrolle nicht erst die tatsächlichen Ist-Daten abzuwarten, sondern frühzeitig Prognosedaten für einen vorausschauenden Soll-Wird-Vergleich zu generieren. Damit ist man in der Lage, mögliche Abweichungen bereits im Vorfeld zu vermeiden. Strategische Überwachung

Durchführungskontrolle

Prämissenkontrolle t0

t1 Strategieformulierung

t2 Strategieimplementierung

Abb. 58: Arten der strategischen Kontrolle

Wie kann man die Durchführungskontrolle mit dem Portfolio unterstützen? Für die Kosten- und Terminkontrolle im Rahmen des strategischen Multiprojektcontrollings eignet sich auch die Portfoliotechnik. Man

71


kann mittels des Attraktivitäts-Portfolios in Abb. 59 Schwerpunkte für die Überwachung von Projekten ermitteln.56 Die Projekte werden nach ihrer Technologie- und Marktattraktivität bewertet und kontrolliert. Eine hohe Technologieattraktivität ist dann gegeben, wenn ein Projekt wesentlichen Einfluss auf zukünftige Produktgenerationen nimmt. Die Entwicklung der ersten UTMSMobiltelefone ist ein Beispiel für ein derartiges Projekt. Vorhaben mit einer hohen technologischen und wirtschaftlichen Attraktivität werden als Renner bezeichnet. Sie müssen aufgrund ihrer Bedeutung besonders sorgfältig beobachtet werden.

Technologieattraktivität

hoch

1

3 2

4

„DRÜCKER“

„RENNER“

6

5

„SCHLÄFER“

7 „ZIEHER“

niedrig niedrig

Marktattraktivität

hoch

Legende: Kreisgröße spiegelt den Anteil am gesamten Projektbudget wider. Keine Überschreitung

Kostenüberschreitung

Terminüberschreitung

Kosten- und Terminüberschreitung

Abb. 59: Attraktivitäts-Portfolio Spielen die Kosten eine große Rolle, wird man sich auf die so genannten Drücker konzentrieren, da sie erhebliche investive Vorleistungen verursachen. Bei den Ziehern handelt es sich meist um Projekte, die bei frühzeitiger Markteinführung hohe Gewinne gewähr56

72

Möhrle, M., Das FuE-Programm-Portfolio: Ein Instrument für das Management betrieblicher Forschung und Entwicklung, technologie & management 37 (1988) 4, S. 12 ff.

2.2 Strategische Projektkontrolle

leisten. Entsprechend wichtig ist eine möglichst kurze Entwicklungsdauer (Time to Market). Ansonsten kann es passieren, dass durch Konkurrenten die höchsten Gewinne abgeschöpft werden und sich die erheblichen Vorleistungskosten für das Projekt nicht mehr amortisieren. Deswegen ist der Controllingschwerpunkt bei diesen Projekten die Terminsituation. Projekte mit einem geringen technologischen und wirtschaftlichen Nutzen sind die Schläfer. Solche Vorhaben sollten möglichst vermieden bzw. einer intensiven Kostenkontrolle unterzogen werden. Das Portfolio in Abb. 59 enthält zusätzliche Informationen. Die Kreisgröße gibt den Anteil der Projektkosten am Gesamtbudget an. Die Kreisfarbe spiegelt Termin- und Kostenüberschreitungen wider. Weist z. B. ein wichtiges „Zieher-Projekt“, wie in Abb. 59, signifikante Terminüberschreitungen auf, ist dies besonders kritisch einzustufen. Es gibt Fehlentwicklungen, die weder von der Prämissen- noch von der Durchführungskontrolle erfasst werden. In diesem Fall greift die strategische Überwachung. Sie ergänzt die beiden erstgenannten Kontrollen und funktioniert wie ein Radar, das eine ungerichtete, flächendeckende Kontrolle durchführt. Die strategische Kontrolle ist besonders schwierig. Wesentliche Probleme sind: • •

•

2.3

Strategische Ziele können oft nur unzureichend überprüft werden, weil sie qualitativer Natur und damit schlecht messbar sind. Die strategische Planung ist Aufgabe der Unternehmensführung. Eine Kontrolle auf dieser Ebene ist naturgemäß heikel, weil der Eindruck entstehen könnte, dass man die Kompetenz des Managements in Frage stellt. Strategische Planung ist langfristig angelegt. Planung und Kontrolle sind deshalb zwangsläufig großen Unsicherheiten unterworfen. Projekt-Scorecard

Die Projekt-Scorecard ist eine auf die Belange der Projektarbeit angepasste Balanced Scorecard. Deshalb sollen zunächst Ziele und Aufbau dieser Methode kurz beschrieben werden.

73


Welche Ziele verfolg man mit einer Balanced Scorecard? Die Balanced Scorecard ist ein umfassendes Managementsystem zur Erarbeitung, Umsetzung und Steuerung der Unternehmensstrategie. Damit unterstützt sie die Operationalisierung und Implementierung der Strategie bis in die einzelnen Projekte und ermöglicht auch eine wirksame Erfolgskontrolle (vgl. Abb. 60).

Vision

T ak tisch e P lan u n g b is 1 Jah r

Strategie

S tra te g ie

Taktische Planung 1 Jahr

bis Einzelprojekte

Operative Umsetzung (Projekte)

Abb. 60: Wirkungen einer Balanced Scorecard Unternehmen und deren Projekte werden oft einseitig aufgrund vergangenheitsorientierter finanzieller Daten gesteuert. Erforderlich wäre aber auch die Berücksichtigung immaterieller und intellektueller Größen, wie z. B. der Mitarbeiterqualifikation57. Die Balanced Scorecard behebt diesen Mangel. Sie ist als ausgewogener Berichtsbogen konzipiert. Angestrebt wird eine Balance zwischen • • •

intern (z. B. Qualität) und extern (z. B. Kundenzufriedenheit) orientierten Größen, vergangenheitsorientierten Größen (z. B. Rentabilität) und Frühindikatoren (z. B. Qualifikation der Mitarbeiter), objektiv quantifizierbaren (z. B. Termintreue) und subjektiven (z. B. Mitarbeiterzufriedenheit) Kennzahlen.

Informationen werden für die vier unterschiedlichen Perspektiven bereitgestellt, die in Abb. 61 aufgeführt sind.

57

74

Kaplan, R., Norton, D., Balanced Scorecard. Strategien erfolgreich umsetzen, Stuttgart 1997, S. 57.

2.3 Projekt-Scorecard

Balanced Scorecard

Abb. 61: Perspektiven der Balanced Scorecard

Wie sieht eine Balanced Scorecard aus? Um den Erfüllungsgrad der strategischen Ziele zu messen, werden in der Balanced Scorecard Kennzahlen definiert und die gewünschten Zielwerte quantifiziert. Daraus leitet man die erforderlichen operativen Maßnahmen und Projekte ab. Die Kennzahlen müssen in einen Ursache-Wirkungs-Zusammenhang gebracht werden (vgl. Abb. 62). Ein Beispiel könnte wie folgt aussehen: Das Unternehmen verfolgt das Ziel, Marktführer zu sein. Als Messgröße wird das Umsatzwachstum gewählt. Zielwert ist ein jährliches Wachstum von mindestens 15 Prozent. Dieses Ziel ist nur mit zufriedenen Kunden erreichbar. Messgröße dafür ist ein Kundenzufriedenheitsindex, der regelmäßig auf Basis von Kundenbefragungen ermittelt wird. Man möchte 90 Prozent zufriedene Kunden. Die Kundenzufriedenheit wird wiederum von der Qualität beeinflusst. Deswegen sollen mindestens 95 Prozent aller Aufträge ohne Reklamationen abgewickelt werden. Dies ist nur mit sehr motivierten Mitarbeitern möglich. Es wird ein Mitarbeiterzufriedenheitsindex definiert, den man aufgrund monatlicher Mitarbeiterbefragungen berechnet. Angestrebt wird ein Indexwert von 95 Prozent. Die Steuerung erfolgt anhand der Zielerreichung. Deswegen müssen regelmäßig die aktuellen Kennzahlenwerte in die Balanced Scorecard eingearbeitet werden. Treten Abweichungen zu den Vorgaben auf, erfolgt eine Ursachenanalyse, und Gegenmaßnahmen werden eingeleitet.

75


Perspektiven

Finanzen

Kunden

Prozesse

Mitarbeiter

Ziele

Kennzahlen

Zielwerte

Rentabilität

Return on Investment

18 %

Budgeteinhaltung

Istkosten/Sollkosten

15 %

Neukunden

Neukunden/alle Kunden

10 %

Kundenzufriedenheit

Kundenzufriedenheitsindex

90 %

Termintreue

In Time Aufträge/alle Aufträge

98 %

Qualität

Aufträge ohne Reklamation/alle Aufträge 95 %

Entwicklungszyklen

Anzahl Jahre für Neuentwicklungen

Mitarbeiterzufriedenheit

Mitarbeiterzufriedenheitsindex

Absentismus

Fehlzeiten/Sollarbeitszeit

5%

Fluktuation

Kündigungen/Anzahl Mitarbeiter

5%

Ursache-Wirkungs-Beziehungen Rentabilität

Budgeteinhaltung

Kundenzufriedenheit

Termintreue

Qualität

Umsetzungsquote

3 95 %

Fluktuation

Absentismus Mitarbeiterzufriedenheit

Abb. 62: Aufbau der Balanced Scorecard

Wie unterstützt die Projekt-Scorecard die Projektauswahl? Die Unternehmens-Scorecard kann zu den bereits in Kap. 2 vorgestellten Verfahren verwendet werden, um Projekte auszuwählen und zu priorisieren. Die projektrelevanten Ziele der Balanced Scorecard sollten dafür identifiziert und soweit erforderlich um zusätzliche projektspezifische Beurteilungskriterien, wie z. B. den Ressourcenverbrauch, ergänzt werden. Dadurch entsteht eine spezielle ProjektScorecard (vgl. Abb. 63). Im Rahmen der Projektauswahl wird für die zu bewertenden Projekte ein voraussichtlicher Erfüllungsgrad je Ziel der Projekt-Scorecard geschätzt. Es lässt sich dann über eine Punktbewertung ähnlich wie in Abb. 65 eine Gesamtpunktsumme als Indikator für die Erfüllung der Projekt-Scorecardziele ermitteln. Die Projekt-Scorecard lenkt die Aufmerksamkeit der Projektleitung im Rahmen der Planung auf alle wichtigen Zielgrößen. Eine Einengung des Blickfelds auf die Größen des magischen Dreiecks oder sogar nur auf finanzielle Ziele wird verhindert, wenn folgende Fragen gestellt und beantwortet werden:

76


• • • •

Wie erreicht man den finanziellen Erfolg des Projekts? Wie ist das Projektteam zu fördern und zu führen, damit alle Mitglieder die erforderliche Motivation und Qualifikation haben? Wie müssen die Prozesse (das Projektmanagement) ausgelegt sein, um die geforderte Projektleistung innerhalb der Terminziele zu erbringen? Wie muss mit dem Kunden kommuniziert werden, um die Ziele zu realisieren?

Ziele der BalancedScorecard des Unternehmens

Projektspezifische Ziele

Ziel a Ziel b

Ziel c Ziel d Ziel e

Projekt-Scorecard

Ziel f Ziel g

Ziel h Ziel i

Ziel a Ziel j

Ziel d Ziel k

Ziel f

Ziel h

Ziel j Ziel k

Abb. 63: Ableitung der Projekt-Scorecard

Wie hilft die Projekt-Scorecard bei der Projektsteuerung? Die Projekt-Scorecard kann auch für die Projektsteuerung eingesetzt werden. Die Erfüllung der Ziele in der Projekt-Scorecard wird mittels einer Punktbewertung ermittelt. Dafür werden zunächst die Perspektiven und die zugehörigen Ziele gewichtet (vgl. Abb. 64).

77

2 Strategisches Projektcontrolling Gewichtung der Perspektiven Finanzen 25 % Gewichtung der Ziele

Kunden 30 %

Mitarbeiterzufriedenheit 70 %

Prozesse 20 %

Absentismus 30 %

Mitarbeiter 25 %

Abb. 64: Gewichtung der Perspektiven und Ziele Der Zielerreichungswert von 7,75 (=77,5 Prozent) für die gesamte Projekt-Scorecard in Abb. 65 errechnet sich wie folgt: Ziele

Gewicht

Finanzen Rentabilität V-Ist/Plan-Budget Gesamt Kunden Kundenzufriedenheit Gesamt Prozesse Termintreue Qualität Gesamt Mitarbeiter Mitarbeiterzufriedenheit Absentismus Gesamt Gesamtwertung der BSC

25% 80% 20% 30% 100% 20% 50% 50% 25% 70% 30%

Zielwerte 18,0% 100,0%

90,0%

98% 95%

95,0% 5,0%

Aktuell

Abweichung

17,8% 130,0%

92,0%

88% 90%

80,0% 9,0%

-1,1% -30,0%

2,2%

-10,2% -5,3%

-15,8% -80,0%

Punkte 9 4

10

8 9

6 0

Gewichtete Punktzahl

Gesamtwertung

7,2 0,8 8

2,00

10 10

3,00

4 4,5 8,5

1,70

4,2 0 4,2

1,05 7,75

Abb. 65: Ermittlung der Zielerreichung 1. Ermittlung der Abweichung zwischen geplantem Zielwert und aktuellem Wert (z. B. -1,1 Prozent für das Ziel „Rentabilität“). 2. Bewertung der Abweichung mit Punkten von null bis zehn. Maximal zehn Punkte werden vergeben, wenn das Ziel sehr gut erfüllt wurde. 3. Multiplikation der Punkte mit den Gewichten der jeweiligen Kennzahl (z. B. 9 Punkte x 0,8 für das Ziel „Rentabilität“).

78


4. Summierung der gewichteten Punkte je Perspektive. Für die finanzielle Perspektive resultieren z. B. 8 Punkte, sie wird also zu 80 Prozent erfüllt. 5. Multiplikation der Punktsumme mit dem Gewicht der Perspektive (z. B. 8 Punkte x 0,25 für die Finanzperspektive). 6. Addition der Punkte aller Perspektiven zur Gesamtpunktsumme der Scorecard (es wurden 7,75 von zehn Punkten erreicht).

Wie wird die aktuelle Situation dargestellt? Monatlich aktualisierte und aussagekräftig aufbereitete Daten der Projekt-Scorecard bieten eine hervorragende Entscheidungsgrundlage für das Management. Üblicherweise erfolgt die Darstellung der Projektsituation kompakt mit den Ampelfarben in übersichtlichen Tabellen und mit Netzdiagrammen (vgl. Abb. 66). Zielerreichung 1. Quartal 2. Quartal

Ziele

Finanzen 10

Finanzen Rentabilität V-Ist/Plan-Budget Gesamt

8

1. Quartal 2. Quartal

6

Kunden

4

Kundenzufriedenheit Gesamt

2

Prozesse

Mitarbeiter

Termintreue Qualität Gesamt

0

Kunden

Mitarbeiter Mitarbeiterzufriedenheit Absentismus Gesamt

Prozesse

Gesamtwertung

grün

gelb

rot

Abb. 66: Darstellung der Projektsituation

Worauf ist beim Einsatz der Projekt-Scorecard zu achten? Die Projekt-Scorecard • • • •

erfordert eine besondere Informationskultur, die erst gelernt und dann gelebt werden muss; muss jederzeit flexibel änderbar sein; ist in regelmäßigen Abständen zu aktualisieren; sollte sich auf das Wesentliche beschränken;

79


•

ist das Instrument, mit dem man täglich arbeitet; neue Vorschläge müssen grundsätzlich auf ihre Zielauswirkung diskutiert und bewertet werden.

Ein Geschäftsbereich der Siemens AG hat in drei Zeitmonaten mit einem Aufwand von 400 Personentagen eine Projekt-Scorecard eingeführt.58 Darin enthalten ist die Unterstützung durch externe Berater und die Erstellung einer Anwendung, die mit Excel realisiert wurde. Die Vorgehensweise der Einführung war wie folgt: • • • • • •

•

Vorbereitende Gespräche mit der Geschäftsführung; Start-Meeting, in dem das gesamte Management über das Vorhaben informiert wurde; Interviews und Studium von Unterlagen, um die ScorecardPerspektiven zu konkretisieren. Dauer: zwei Wochen; Erster Managementworkshop zur Überarbeitung der bisher erfassten strategischen Aussagen. Außerdem wurden die Ursache-Wirkungs-Zusammenhänge erstellt. Dauer: drei Tage; Arbeitsteams erarbeiteten Kennzahlen für die Ziele der Ursache-Wirkungskette. Dauer: drei Wochen; Zweiter Managementworkshop für die Besprechung der Kennzahlen, die von den Arbeitsteams definiert wurden. Vorteilhaft war, dass zu diesem Workshop bereits eine einfache DV-Lösung vorlag. Dauer: ein Tag; Weitere Teamarbeit und dritter Managementworkshop zur Abrundung und Genehmigung der geleisteten Arbeit.

Wichtige Erfahrungen waren: • • •

•

Die Scorecard muss in die existierenden Planungs- und Kontrollsysteme eingebunden werden. Festzulegen ist, welche Führungskennzahlen durch die Scorecard abgelöst werden. Die Scorecard muss mit Maßnahmen verknüpft werden. Die Scorecard sollte alltägliches Arbeitsinstrument sein. In Meetings und Geschäftsdurchsprachen müssen die Konsequenzen von Entscheidungen immer auch vor dem Hintergrund der Scorecard beleuchtet werden. Die Scorecard ist durch eine einfach zu handhabende IT-Lösung zu unterstützen. Abb. 67 zeigt das mit Excel realisierte Cockpit Chart. Die Führungsgrößen werden auf weiteren Excel-Sheets im Detail dargestellt.

58 Töpfer, A., Das Management der Werttreiber, FAZ Juli 2000, S. 266 ff.

80


Finanzperspektive Erfolgsfaktor

Führungsgröße

F

Kapitalgeber

Geschäftswertbeitrag

Q

Kapitalgeber

Geldsaldo

Q

Kapitalgeber

EBIT

M

Kapitalkosten

Erhaltene Anzahlungen

M

Kapitalkosten

Forderungsbestand

M

Status

Trend

Status

Trend

Status

Trend

Kundenperspektive Erfolgsfaktor

Führungsgröße

F

Volumen

Marktentwicklung

Q

Volumen

Angebotsvolumen

M

Preisqualität

Deckungsbeiträge

M

Neue Geschäfte

Auftragseingang, Umsatz, Ergebnis

M

Kundenzufriedenheit

Liefertreue, Lieferfähigkeit, Lieferqualität

M

Prozessperspektive Erfolgsfaktor

Führungsgröße

F

Vorakquisition

Anzahl Gespräche

M

Akquisition

Angebotsvolumen

Q

Akquisition

Hitrate

Q

Fehlleistung

Mehrkosten

M

Produktivität

Wertschöpfung

Q

F: Ergebungsfrequenz M: monatlich Q: quartalsweise HJ: halbjährlich

Mitarbeiterperspektive Erfolgsfaktor

Führungsgröße

F

Innovationsfähigkeit

Ideenspeicher

Q

Wissenstransfer

Job Rotation

HJ

Motivation

Vorschläge, Umsetzung

Q

Status

Trend

Status: Rot: Plan nicht erfüllt Gelb: Plan erfüllt Grün: Plan mit Sicherheitsreserve erfüllt

Abb. 67: Cockpitchart einer Projekt-Scorecard

81


2.4 •

•

•

• • •

•

82

Zusammenfassung Das Projektcontrolling hat im Rahmen der strategischen Projektplanung die Aufgabe, Informationen für die Bewertung der Projektattraktivität, der Projektabhängigkeiten sowie über die verfügbaren Ressourcen bereit zu stellen. Es unterstützt damit die Projektauswahl und Projektpriorisierung. Instrumente für die strategische Projektplanung sind Portfolios, Wirtschaftlichkeitsverfahren, Nutzwert-, Abhängigkeits- und Risikoanalysen, Zero Base Budgeting, Budgets und Mitarbeitereinsatzpläne. Um die Wirtschaftlichkeit eines Projektes zu beurteilen, verwendet man z. B. Break-Even- und Rentabilitätsanalysen sowie dynamische Verfahren wie die Kapitalwertmethode. Im Rahmen der wertorientierten Unternehmensführung wird auch der Einfluss der Projekte auf den Economic Value Added bestimmt. Bei der Entscheidung über die Annahme eines zusätzlichen Projekts ist immer die Auswirkung auf laufende Projekte zu berücksichtigen. Mit Hilfe des Zero Base Budgeting kann man knappe Budgetmittel auf Teilprojekte und Projekte aufteilen. Die Balanced Scorecard ist eine umfassende Managementmethode, welche die Umsetzung der strategischen Ziele gewährleistet. Sie bildet die Grundlage für die Projekt-Scorecard, die sowohl für die Auswahl als auch die Steuerung und Überwachung der Projekte Verwendung findet. Die strategische Kontrolle überwacht die im Rahmen der strategischen Planung getroffenen Prämissen und die Strategieumsetzung.

3

Operatives Projektcontrolling

„Nur das ist ein schlechter Plan, der keine Veränderungen zulässt.“ Publius Syrus, 1. Jh. v. Chr., römischer Dichter „Die Stärke des Managements liegt im intelligenten Reagieren auf Veränderungen“. Robert McNamara

Sie lernen in diesem Kapitel die einzelnen Schritte der operativen Projektplanung und Projektkontrolle kennen und erfahren, welche Unterstützung das Projektcontrolling dabei leisten kann. Neben der Erörterung der Frage, welche gestaltenden und koordinierenden Aufgaben das Projektcontrolling wahrnehmen kann, werden wichtige Instrumente gezeigt, die im Rahmen eines Projektcontrollings zum Einsatz kommen. Des Weiteren werden die Bedeutung einer systematischen Sicherung der im Projekt gewonnenen Erfahrungen erläutert und Hinweise für ein aussagefähiges Berichtswesen gegeben.

83

3 Operatives Projektcontrolling

3.1

Operative Projektplanung

3.1.1 Überblick Nach der Auswahl eines Projektes im Rahmen des strategischen Projektcontrollings und der endgültigen Freigabe muss die Abwicklung im Detail geplant werden. Die Einstellung „Planung ist der Ersatz des Zufalls durch den Irrtum“ verhindert bei komplexen Projekten die Erreichung der Projektziele und lässt sie oft scheitern. Sorgfältige Projektplanung ist ein wesentlicher Schlüssel zum Projekterfolg. Schnittstellen zum strategischen Projektcontrolling und zur Projektkontrolle, die einzelnen Planungsschritte und wesentliche Instrumente sind in der folgenden Abb. aufgeführt. INPUTINFORMATIONEN

Was? Genehmigte Projekte

Woher? Strategisches Projektcontrolling

AUFGABEN

Welche? Zielsetzung Projektorganisation Phasenplanung Aufgabenplanung Terminplanung Aufwandsplanung Ressourcenplanung Kostenplanung Risikoanalyse

Womit? Präferenzmatrix Funktionendiagramm Projektphasenbeschreibung Projektstrukturplan, Vorgangsliste Netzplan, Balkenplan Schätzverfahren Kapazitätsbelastungsdiagramm, Personalauslastungsplan Kosten- und Liquiditätsrechnung Checklisten, Riskmap

Was? Geplante Projekte

Wohin? Projektsteuerung und -kontrolle

OUTPUTINFORMATIONEN

Abb. 68: Überblick über die operative Projektplanung Die Projektplanung ist kein einmaliger Prozess am Anfang eines Vorhabens, sondern sie muss auch projektbegleitend durchgeführt werden: • 84

anfangs ist ein grober Plan für das gesamte Projekt notwendig,

3.1 Operative Projektplanung

• •

mit zunehmendem Projektfortschritt wird der Plan detaillierter ausgearbeitet, dauerhafte Änderungen, die während des Projektes auftreten, führen zu einer Anpassung des Plans.

Projektcontrolling darf sich nicht auf die Ermittlung der Projektkosten beschränken, sondern muss alle Phasen der Planung unterstützen und adäquate Informationen bereitstellen. Im Folgenden werden die Aufgaben, Methoden und Instrumente der Projektplanung laut Abb. 68 im Überblick beschrieben. Es wird jeweils angegeben, welche Unterstützung das Projektcontrolling leisten kann. In Anlehnung an Abb. 9 wird in gestaltende Maßnahmen und Koordinationsaufgaben unterschieden. Betrachtet werden sowohl Koordinationsaufgaben des Controllings einzelner Projekte wie auch des Multiprojektcontrollings. 3.1.2 Projektziele Die Freigabe eines Projektes mündet in den Projektauftrag. Neben der Projektabgrenzung, der Zusammensetzung des Projektteams, der Nennung des Projektleiters, des Gesamtbudgets und des Endtermins müssen dort vor allem die Projektziele dokumentiert werden. Die Vorgehensweise zur Zielerarbeitung wurde bereits in Kap. 2.1.3.1 beschrieben.

Welche Aufgaben nimmt das Projektcontrolling wahr? Das Projektcontrolling sollte die grundsätzlichen Regelungen für die Zielplanung erarbeiten. Dazu gehört die verbindliche Vorgabe, dass kein Projekt ohne eindeutige Zielvereinbarungen gestartet wird. Auch die Zuständigkeiten für die Zieldefinition sollten festgelegt und geeignete Instrumente, wie z. B. die Präferenzmatrix für die Zielgewichtung (vgl. Abb. 27), empfohlen werden. Die Ziele einzelner Projekte hat der Projektcontroller zu prüfen: • • • • • •

3UoMeNtFontUoOOeU

XnteUVtt]t

Sind die Ziele schriftlich fixiert? Sind die Ziele messbar? Ist das Vorhaben machbar? Kennen die Beteiligten die Ziele? Werden die Ziele akzeptiert? Gibt es Zielkonflikte?

85


Insbesondere sich widersprechende Ziele zwischen Auftraggeber und Auftragnehmer müssen vor Projektbeginn aufgedeckt werden. Darüber hinaus kann der Projektcontroller den Projektleiter bei der Kommunikation der Ziele unterstützen. Nur wenn alle Beteiligte die Ziele kennen und auch verstehen, ist ein zielorientiertes Handeln möglich. 3.1.3 Aufbauorganisation Zu bestimmen ist eine geeignete Organisationsform für das Projekt. Davon hängen die Kompetenzen des Projektleiters ab. Wählt man eine Stabsprojektorganisation, hat der Projektleiter keine Weisungsbefugnisse. Er ist eher ein „Kümmerer“ und Koordinator. Für wichtige Projekte wird man deswegen auf andere Organisationsformen zurückgreifen. Bei der Matrixprojektorganisation wird die vorhandene Linienorganisation durch Projekte überlagert. Der Projektleiter hat fachliche Weisungsbefugnisse, wenn es um die Belange des Projekts geht. Disziplinarisch bleiben die Projektmitarbeiter ihren Fachvorgesetzten in der Linie unterstellt. Bei einer reinen Projektorganisation werden die für das Projekt benötigten Ressourcen aus ihrer Linienabteilung herausgelöst und vom Tagesgeschäft entlastet. Der Projektleiter ist fachlicher und disziplinarischer Vorgesetzter mit weitreichenden Kompetenzen. Unter Leistungsaspekten ist diese Organisationsform zu präferieren. Allerdings ist sie in aller Regel aufwendiger zu realisieren als eine Matrixprojektorganisation. In der Unternehmenspraxis gibt es vielfältige Mischformen zwischen den drei „reinen“ Alternativen. Zusätzlich zur Wahl der Organisationsform sind die Projektteams zu bilden und Hauptaufgaben auf Mitarbeiter zu verteilen. Außerdem erfordern größere Projekte einen Lenkungsausschuss, der mit Mitgliedern des Managements besetzt ist und die wichtigen Entscheidungen im Projekt trifft. Weitere Ausschüsse werden je nach Bedarf eingerichtet. In Kap. 5.1.3 wird am Beispiel der Versicherungsgesellschaft Deutscher Herold beschrieben, welche Organisationseinheiten Projekte planen und steuern.

Welche Aufgaben nimmt das Projektcontrolling wahr? 3UoMeNtFontUoOOeU

XnteUVtt]t

86

Das Projektcontrolling kann Kriterien (z. B. Größe, Komplexität, Bedeutung des Projekts) für die Wahl der Projektorganisation erarbeiten. Zudem wird der Projektleiter unterstützt, um die für das Projekt erforderlichen Personen zu finden. In der Matrixorganisation tritt


manchmal das Problem auf, dass die Mitarbeiter nicht in ausreichendem Maße von ihren Fachabteilungsaufgaben entlastet werden. Der Projektcontroller achtet deshalb frühzeitig darauf, dass Vereinbarungen zwischen Projektleiter und Fachbereichsleitung zur Freistellung der Mitarbeiter getroffen und eindeutig dokumentiert werden. 3.1.4 Projektphasen Neben der Aufbau- ist die Ablauforganisation eines Projektes zu bestimmen. Es geht vor allem um eine sinnvolle Unterteilung in Phasen. Die Phasen sind auch deswegen von Bedeutung, weil nach deren Abschluss jeweils festgelegt wird, ob und wie das Projekt weiter zu bearbeiten ist. Neben standardisierten Phasenschemata für unterschiedliche Projektformen gibt es vor allem in größeren Unternehmen mit umfangreichem Projektgeschäft eigene verbindliche Vorgehensmodelle. Eine typische Unterteilung eines Projektes ist die in Konzeption, Planung, Realisierung und Abschluss. Die Konzeption beinhaltet vor allem die Zielsetzung für das Projekt, die Prüfung möglicher Alternativen und eine Kontrolle der Ressourcenverfügbarkeit. Die Phase endet mit einer Entscheidung über den Projektstart. Im Rahmen der Planung wird der Projektverlauf detailliert vorausgedacht. Geplant werden insbesondere die einzelnen Aufgaben und die dafür erforderlichen Ressourcen sowie anfallende Kosten. Während der Realisierung wird die zur Zielerfüllung nötige Leistung erbracht. Dabei ist ein wesentlicher Erfolgsfaktor eine kontinuierliche Überwachung und Steuerung des Ressourceneinsatzes, der Kosten und der Leistung. Die Abschlussphase beinhaltet eine systematische Betrachtung des Projektverlaufs, um Erkenntnisse für nachfolgende Projekte zu gewinnen, die Übergabe des Projektergebnisses an den Auftraggeber und die Auflösung des Projektteams. Die Erfolgsfaktoren in den Projektphasen wurden im Rahmen einer empirischen Studie in den USA, in der 586 Projektmanager befragt wurden, von denen 418 antworteten, dokumentiert.59 Sie werden in der folgenden Abb. 69 im Überblick dargestellt. 59

Pinto, J., Slevin, D., Critical Success Factors across the Project Life Cycle, in: Pinto, J., Trailer, J. (Hrsg.), Project Control, Newtown 1999, S. 91 ff.

87

Aufwand


Mission

Beziehung zum Kunden

Mission

Mission

Unterstützung durch das TopManagement

Technische Rahmenbedingungen

Führung

Mission

Problemlösungsverhalten

Beziehung zum Kunden

Einverständnis des Kunden

Zeit

Wichtigkeit des Zeitplanung Projekts Technische Rahmenbedingungen Beziehung zum Kunden

Abb. 69: Faktoren für den Projekterfolg in einzelnen Phasen

Tipp

Man erkennt in Abb. 69, dass während des gesamten Projektes von der Konzeption bis zum Abschluss die Mission, also das Ziel des Projektes, allen Beteiligten völlig klar sein muss. In allen Phasen spielt auch die Beziehung zum Kunden eine überaus wichtige Rolle. Die Projektverantwortlichen müssen dem Kunden zuhören, um seine tatsächlichen Wünsche zu erkennen, und mit ihm kommunizieren. Bei der Planung ist es wichtig, das Einverständnis des Kunden für die Ideen und Planungsvorschläge des Projektteams zu gewinnen. Die Kommunikation mit dem Kunden muss dabei kontinuierlich aufrechterhalten werden. Die Planungsphase ist immer dann erfolgreich, wenn ein Projekt als wichtig eingestuft wird. Die Projektmitarbeiter dürfen ihr Projekt nicht als Routineaufgabe oder als überflüssiges Vorhaben auffassen.

88


Für die Realisierung ist ein sorgfältig ausgearbeiteter Zeitplan nötig. Er dient der Projektleitung und den Projektmitarbeitern als ständige Checkliste, um den aktuellen Stand der Arbeiten zu prüfen. Die Führung des Projekts durch den Projektleiter hat in allen Phasen hohe Bedeutung. Während der Realisierung beeinflusst dieser Faktor den Projekterfolg aber in besonderem Maße. Die technischen Rahmenbedingungen spielen während der Realisierung und des Abschlusses eine große Rolle. Angemessenes Equipment und qualifiziertes Personal müssen in ausreichendem Maß und ausreichender Qualität vorhanden sein.

Welche Aufgaben nimmt das Projektcontrolling wahr? Das Projektcontrolling sollte ein Standardphasenschema empfehlen. Im Rahmen der Begleitung einzelner Projekte ist sicherzustellen, dass auf dieser Grundlage soweit möglich einheitlich geplant wird. In der Baubranche gibt es sogar eine extern vorgegebene und verbindlich einzuhaltende Vorgehensweise. Sie ist in der Honorarordnung für Architekten und Ingenieure (HOAI) geregelt.

3UoMeNtFontUoOOeU

XnteUVtt]t

Die Projektplanung wird erleichtert, wenn die einzelnen Phasen angemessen standardisiert und beschrieben sind. Je Phase sind folgende Informationen sinnvoll: • • • • • • • •

Aufgaben, Risiken, durchschnittliche Dauer, Input, Ergebnis, benötigte Ressourcen, empfohlene Instrumente, Kostentreiber.

Voraussetzung für die allgemeingültige Beschreibung der Projektphasen ist, dass die definierten Projekttypen auf einer akzeptabel abstrakten Ebene vergleichbar sind. In der Regel wird man innerhalb der gebildeten Projektkategorien Gemeinsamkeiten finden, die man zentral dokumentieren kann. Das Projektcontrolling hat des Weiteren darauf zu achten, dass die bereitgestellten Informationen und Empfehlungen auch wirklich verwendet werden. Dies gelingt nur, wenn die verantwortlichen 89


Projektleiter von der Vorteilhaftigkeit überzeugt werden können und die im Phasenschema hinterlegten Informationen regelmäßig gepflegt und angepasst werden. Ideal ist es, wenn man die gesammelten Erkenntnisse in einem DVSystem zur Verfügung stellt. Abb. 70 zeigt das Beispiel einer Bildschirmmaske. Die Spalten enthalten einen standardisierten Workflow mit den Verantwortlichen und deren Aufgaben im Projekt. Für jede Aufgabe kann in der linken Menüleiste die vom System anzuzeigende Detailinformation ausgewählt werden. Kunde

Vertrieb

Projektleiter

Projektcontroller

Risiken Durchschnittliche Dauer Input Ergebnis Benötigte Ressourcen Vorhandene Instrumente Kostentreiber

Abb. 70: DV-System zur Beschreibung der Projektphasen Die ehemalige MIS AG, heute als Infor Global Solutions Deutschland AG bekannt, ist ein Unternehmen, das Software und betriebswirtschaftliche Beratung für Planung, Reporting, Konsolidierung und Datenanalyse anbietet. Es hat den Prozess für die Einführung von Business Intelligence Systemen ausführlich beschrieben und im Intranet zur Verfügung gestellt (vgl. Abb. 71 und Abb. 72). Auf Basis der definierten Prozesse wird eine projektneutrale Kalkulation erstellt (vgl. Abb. 73). Für jeden Projektaufgabe wird festgelegt, wie stark diese die Ressourcen bindet und welche direkten Kosten erfahrungsgemäß auf sie entfallen. Diese Planung erfolgt differenziert nach Projekttypen.

90


Abb. 71: Auszug aus einer Know-how-Datenbank zur Beschreibung von Prozessschritten

Abb. 72: Auszug aus der Dokumentation eines Prozessschrittes

91


Abb. 73: Projektneutrale Kalkulation Für die projektindividuelle Kalkulation gibt der Anwender an, welchem Projekttyp sein Projekt entspricht. Mit Auswahl des Projekttyps werden die projektneutralen Kalkulationen angezeigt. Es besteht nun die Möglichkeit, die Werte als Vorschlag in die Projektkalkulation zu kopieren und individuell anzupassen. Die Eingaben erfolgen an dieser Stelle immer auf der tiefsten Ebene. Die Berechnungsalgorithmen für Aggregationen und Kennzahlen sind zentral hinterlegt und werden automatisch nach der Eingabe neuer Werte durchgeführt. 3.1.5 Projektaufgaben und Projektstruktur Im Projektstrukturplan werden alle Aufgaben, die für die Erfüllung der Projektziele notwendig sind, strukturiert aufgezeigt. Er beschreibt damit die zu erbringende Leistung und gliedert sie in überschaubare Einheiten. Die Gliederung des Projektstrukturplans kann funktionsorientiert oder objektorientiert sein. In der Praxis wird man in der Regel eine Mischgliederung wählen. Da ein übergeordneter Knoten immer die Summe der ihm untergeordneten Aufgaben zeigt, dient der Projektstrukturplan auch zur Kontrolle, ob Leistungen vergessen wurden.

92


Die unterste Gliederungsebene des Projektstrukturplans, die so genannten Arbeitspakete, bildet die Basis für alle nachfolgenden Planungs- und Kontrollaktivitäten. Deshalb müssen die Arbeitspakete sorgfältig definiert werden. Sie sollten vollständig einem Mitarbeiter oder einer organisatorischen Einheit übertragen werden können. Dabei muss man beachten, dass die Arbeitspakete nicht zu umfangreich werden. Deren Kosten- und Zeitanteil sollte sich zwischen zwei Prozent und fünf Prozent des Gesamtprojekts bewegen. Die Dauer der Arbeitspakete kann sich auch an der Berichtshäufigkeit orientieren. Als Faustregel gilt: Berichtsintervall mal 1,5. Wenn also alle vier Wochen berichtet wird, sollte die Dauer der Arbeitspakete sechs Wochen nicht übersteigen. Mit fein gegliederten Arbeitspaketen von kurzer Dauer gewinnt man eine erhöhte Aussagekraft über den Status im Projekt. Darüber hinaus wird die Schätzung des voraussichtlichen Aufwands erleichtert, und Risiken kann man eher erkennen. Auch Planänderungen sind mit geringem Aufwand durchführbar, weil man sich nur auf diejenige, klar abgegrenzte Einheit im Projektstrukturplan konzentrieren muss, die von der Änderung betroffen ist.

Tipp

Die Arbeitspakete können wohl für die Schätzung des Aufwands weiter unterteilt werden. Grundsätzlich sollten sie jedoch die kleinste Planungseinheit sein. Eine weitere Gliederung würde auch den Handlungsspielraum des verantwortlichen Mitarbeiters zu stark einschränken. Im Projektstrukturplan sind Meilensteine zu definieren. Dabei handelt es sich um wichtige Orientierungspunkte, an denen das bisher Geleistete einer Prüfung unterzogen und die weitere Vorgehensweise im Projekt festgelegt wird. Fein terminierte Meilensteine sind also vorgeplante „Deadlines“, die eine zu starke Abweichung vom Plan verhindern, da die für eine Aufgabe investierte Energie immer kurz vor dem Terminende stark zunimmt. Sie erleichtern darüber hinaus die Fortschrittskontrolle. Für Meilensteine können verschiedene Kategorien vorgegeben werden, z. B. Statusmeilensteine, vertragliche Verpflichtungen oder Zahlungen. Eine besondere Art von Meilensteinen sind die Quality Gates. Ein Quality Gate darf erst durchschritten werden, wenn genau definierte Kriterien erfüllt sind. Die Kriterien sollten bereits vor Projektbeginn vereinbart werden. Es ist nicht sinnvoll und auch kaum möglich, für ein komplexes Projekt den kompletten Strukturplan mit allen Einzelheiten aufzu93


stellen. Man sollte stattdessen die Feinplanung delegieren.60 Ausgehend von den Projektphasen und den dazugehörigen Meilensteinen am Anfang und Ende jeder Phase wird zunächst ein grober HighLevel-Plan erstellt. Er bildet den Rahmen für die von den verschiedenen Projektteams selbstständig zu erarbeitenden und zu verantwortenden Low-Level-Pläne. Die so aufgestellten Detailpläne müssen natürlich mit dem High-Level-Plan abgestimmt werden. Die Abb. 74 verdeutlicht die schrittweise Konkretisierung der Planung. 1. Phasenschema mit Meilensteinen M1 Konzeption 2. High Level Plan

3. Low Level Pläne

M2

M3 Planung

M4 Realisierung

M3

M5 Abschluss

M4

Schnittstelle beachten!

Abb. 74: Schrittweise Konkretisierung der Projektplanung Die Low-Level-Pläne bilden die Grundlage für die detaillierte Planung der Termine, Aufwände, Ressourcen und Kosten. Man sollte Verantwortliche benennen, die sowohl an der HighLevel-Planung wie auch an der Ausarbeitung der Detailpläne beteiligt werden und deshalb die erforderlichen Kenntnisse für die Koordinierung der Schnittstellen besitzen.


XnteUVtt]t

Da die Aufgabenstruktur vieler Projekte vergleichbar ist, sollte das Projektcontrolling einen Standardprojektstrukturplan erarbeiten. Er enthält all diejenigen Standardaufgaben, die typischerweise in einem Projekt einer bestimmten Kategorie vorkommen. Die Anpas60

94

Krüger, A., Schmolke, G., Vaupel, R., Projektmanagement als kundenorientierte Führungskonzeption, Stuttgart 1999, S. 86 ff.


sung an ein neues Projekt ist schnell durchführbar, indem einfach die nicht benötigten Arbeitspakete entfernt und neue dazu gefügt werden. So erhält man in kurzer Zeit einen aktuellen Plan mit Ausgangsdaten für die Termin- und Kostenplanung. Außerdem dient der Standardprojektstrukturplan quasi als Checkliste, die sicher stellt, dass keine Aufgaben vergessen werden. Zudem wird ein einheitlicher und damit zwischen Projekten vergleichbarer Aufbau des Projektstrukturplans gewährleistet. Bei der Outokumpu Technology GmbH sind die technische und die controllingorientierte Projektstruktur vorgegeben. Der Projektstrukturplan ist die zentrale Basis für alle Aspekte des Projektcontrollings. Die Anlagenstruktur wird für das Engineering verwendet. Die Koordination zwischen den beiden Strukturplänen zeigt Abb. 75. Anlagenstruktur

Projektstrukturplan (PSP)

Gesamtanlage

Teilanlage Ausrüstung Stückliste Motor Schrauben Dichtungen

Projekt

Teilanlage Projektphase (Büro, Baustelle etc.) Kostengruppe (Disziplin) Kostenelement

Abb. 75: Zuordnung von technischer Struktur und Projektstrukturplan Im Produktbereich Instrumentation Systems des Geschäftsbereichs Car Multimedia der Robert Bosch GmbH existieren Teilprozesse für die Angebotsphase und die Entwicklungsphase eines zu entwickelnden Kombiinstrumentes. Dort werden alle Arbeitspakete, die zur Erstellung eines Kombiinstrumentes erforderlich sind, nach Subphasen aufgeführt. Die Mitwirkung des Fachbereiches ist ebenfalls phasenzugehörig dokumentiert. Das Projektcontrolling formuliert des Weiteren Regeln für den Umfang des Projektstrukturplans sowie die Definition der Arbeitspakete 95


Tipp

und Meilensteine. Als Anhaltspunkt für den Umfang des Projektstrukturplans kann man folgende Empfehlung heranziehen: Die erste Gliederungsebene sollte maximal zehn Gliederungspunkte enthalten, die zweite maximal 25, die dritte maximal 100 und die vierte maximal 400. Selbst für komplexe Projekte dürften höchstens sechs Gliederungsebenen ausreichen. Das Projektcontrolling kann auch formale Standards für die Definition von Projektstrukturplänen vorgeben: • • • • • •

Eine Aktivität muss immer aus einem Hauptwort und einem Verb bestehen, z. B. „Bremsen prüfen“. Ein Meilenstein ist als Ereignis zu formulieren, z. B. „Bremsen geprüft“. Die erste Ebene ist mit Großbuchstaben zu schreiben, um die Übersichtlichkeit zu erhöhen. Auf der ersten Ebene dürfen keine Arbeitspakete erscheinen. Die erste Ebene umfasst immer die gleichen, zentral vorgegebenen Standardvorgänge. Es sind höchstens sechs Gliederungsebenen zulässig.

Das Projektcontrolling hat im Rahmen der Koordination die korrekte Definition der Meilensteine dahingehend zu prüfen, ob sie mit dem Projektauftrag korrespondieren oder vertraglich zugesicherte Leistungstermine berücksichtigen. Außerdem muss die Vollständigkeit des Projektstrukturplans begutachtet werden. Technisch orientierte Projektleiter übersehen schnell vertriebliche und organisatorische Aufgaben. Der Projektcontroller unterstützt darüber hinaus die Abstimmung der Rahmen- und Detailpläne.

Warum ist ein wertorientierter Projektstrukturplan vorteilhaft? Neben dem klassischen Projektstrukturplan kann es für manche Projekte sinnvoll sein, einen wertorientierten Projektstrukturplan zu erstellen (vgl. Abb. 76).61 Damit ist es möglich, den Einfluss der einzelnen Arbeitspakete auf den Erlös eines Projektes abzuschätzen. Entsteht das Problem, die Leistung reduzieren zu müssen, weil Ressourcen fehlen und Zeitverzug droht, hat man einen Anhaltspunkt, bei welchen Arbeitspaketen dies mit dem geringsten Verlust mög-

61

96

Devaux, S., Total Project Control. A Manager´s Guide to Integrated Project Planning, Measuring and Tracking, New York u. a.1999, S. 49 ff.


lich wäre. Die Methodik soll am Beispiel der folgenden Abb. dargestellt werden: 10 Mio. €

Entwicklung eines neuen Mountainbikes 10 Mio. €

Anforderungen analysieren

Kunden analysieren

Design erstellen

10 Mio. €

Prototyp bauen

10 Mio. €

Prototyp testen

10 Mio. €

Arbeitsplan erstellen

Wettbewerber untersuchen

Abb. 76: Wertorientierter Projektstrukturplan Zunächst ist zwischen Kann- und Muss-Aktivitäten zu unterscheiden. Muss-Aktivitäten werden einerseits vom Controlling verpflichtend vorgeschrieben. Dabei handelt es sich z. B. um Qualitätssicherungsmaßnahmen oder Tests. Andererseits sind das solche Arbeitspakete, ohne die das Projekt nicht zu Ende geführt werden kann. Ohne das Design ist z. B. keine Entwicklung möglich, auch ein Prototyp und Arbeitspläne sind unerlässlich, um das Mountainbike in Abb. 76 zu produzieren. Der Wert einer Muss-Aktivität entspricht immer dem Erlös für das gesamte Projekt. Kann-Aktivitäten sind optional. Ihren Wert bestimmt man durch die Frage: Welchen Erlös erzielen wir, wenn das betrachtete Arbeitspaket gestrichen würde? Die Analyse der Wettbewerber ist im Beispiel als Kann-Aktivität definiert. Durch Befragung von Vertriebsspezialisten und die Untersuchung bereits abgeschlossener ähnlicher Projekte wird versucht herauszufinden, welche Konsequenzen eine Entwicklung ohne Analyse der Wettbewerber hätte. Als Ergebnis erhält man die Information, dass in 30 Prozent der Fälle keine Auswirkungen festzustellen sind. In 50 Prozent der Fälle treten Probleme auf, wie Zeitverzug oder Mehrkosten. Insbesondere durch die Verzögerung der Markteinführung muss man mit reduzierten Erlösen von fünf Mio. € rechnen. In den restlichen 20 Prozent der Fälle ist sogar mit einem völligen Erlösausfall zu kalkulieren. Daraus resultiert das in Abb. 77 dargestellte Ergebnis.

97


Reduzierte Erlöse

A

10 Mio. x 30 % = 3,0 Mio. €

B

5 Mio. x 50 % = 2,5 Mio. €

C

0 Mio. x 20 % = 0,0 Mio. € Summe = 5,5 Mio. €

Wert des Arbeitspakets: 10 Mio. € - 5,5 Mio. € = 4,5 Mio. €

Abb. 77: Wertermittlung für ein Arbeitspaket Es wird deutlich, dass ohne das Arbeitspaket Kundenanalyse das gesamte Projekt nur noch einen Erlös von 5,5 Mio. € erzielen würde. Das Arbeitspaket repräsentiert also einen Wert von 10 Mio. € – 5,5 Mio. € = 4,5 Mio. €. 3.1.6 Projektaufwand Der Projektaufwand wird auf Basis der Leistungsbeschreibung der einzelnen Arbeitspakete geschätzt. Er ist Grundlage für die weitere Planung. Dabei kann man zwei unterschiedliche Vorgehensweisen wählen. Bei einer ressourcengesteuerten Planung wird der Aufwand für jedes Arbeitspaket ermittelt. Durch die genaue Zuordnung von Ressourcen ergibt sich dann rechnerisch die Dauer der Arbeitspakete aufgrund des Zusammenhangs Definition

‫ ݀݊ܽݓ݂ݑܣ‬ൌ ‫ ݎ݁ݑܽܦ‬ൈ ‫݊݁ܿݎݑ݋ݏݏܴ݁ ݈݄ܽݖ݊ܣ‬

Ergänzt man für alle Arbeitspakete deren logische Verknüpfung (Vorgang B beginnt z. B. erst, nachdem Vorgang A abgeschlossen ist) erhält man auch den Endtermin des Projekts. Diese Art der Planung ist dann sinnvoll, wenn die Ressourcen den Engpass bilden. Außerdem muss es möglich sein, die Ressourcen eindeutig und zuverlässig den einzelnen Arbeitspaketen zuzuordnen. Projekte mit einer hohen Planungsunsicherheit bezüglich der einsetzbaren Ressourcen und strikt vorgegebenen Terminen sollten deshalb termingesteuert geplant werden. Ausgehend von der Schätzung des Pro98


jektaufwands plant man die Termine der Arbeitspakete so ein, dass ein gewünschter Projektendtermin erreicht wird. Die notwendigen Ressourcen lassen sich rechnerisch ermitteln. Die folgenden Ausführungen orientieren sich an der Planungsreihenfolge termingesteuerten Planung. In der Praxis greift man häufig auf Expertenschätzungen zurück, um den Aufwand zu quantifizieren. Dabei dominiert die Einzelschätzung. Sie sollte von einem anerkannten Spezialisten durchgeführt werden, der mit Hilfe einer Drei-Punkt-Schätzung den Aufwand bestimmen kann. Bei dieser Methode werden drei Schätzwerte für den Aufwand abgegeben: • • •

optimistische Aufwandsschätzung Ap, wahrscheinliche Aufwandsschätzung Aw, pessimistische Aufwandsschätzung Ao.

Der Gesamtaufwand A ergibt sich nach folgender Formel: ‫ ܣ‬ൌ

ͳ ൈ ‫ܣ‬௣ ൅ Ͷ ൈ ‫ ܣ‬௪ ൅ ͳ ൈ ‫ ܣ‬௢ ͸

Definition

Bei der Mehrfachbefragung wird eine interdisziplinär zusammengesetzte Gruppe von Experten konsultiert. Aus den unterschiedlichen Schätzwerten bildet man einen Durchschnitt, der meist bessere Ergebnisse liefert als die Einzelschätzung. Bekannt ist in diesem Zusammenhang die so genannte Delphi-Methode. Dabei geben mehrere Personen Schätzwerte anonym ab. Die Ergebnisse werden ausgewertet und, sofern sie zu weit auseinander liegen, den Experten als Grundlage einer erneuten Schätzung vorgelegt. Der Ablauf der Methode ist in Abb. 78 dargestellt.

99

3 Operatives Projektcontrolling Moderator erläutert das Projekt

Moderator verteilt Schätzformulare Experten füllen Schätzformulare anonym aus Moderator fasst die Schätzungen mit Begründung zusammen Experten überarbeiten ihre Schätzungen

Schätzungen ähnlich ?

Nein

Ja Moderator bildet Durchschnittswert aus den Schätzungen

Abb. 78: Ablauf der Delphi-Methode Im Folgenden werden weitere Verfahren zur Schätzung des Projektaufwands erläutert: Analogiemethoden: • •

,nteUnet

Multiplikatormethoden: •

www.dasma.de www.sei.cmu. edu

100

Der Aufwand wird aus vergleichbaren Projekten abgeleitet. Voraussetzung sind ein systematisches Sammeln und Speichern von Erfahrungsdaten abgeschlossener Projekte und die Verfügbarkeit erfahrener Schätzer.

•

Für das Arbeitspaket werden die zu erbringende Leistung und der Aufwand pro Leistungseinheit festgelegt. Multiplikation der geschätzten Gesamtleistung mit dem Aufwand pro Leistungseinheit.


•

Beispiel für das Verputzen beim Bau eines Hauses: - Aufwand pro Leistungseinheit: 1 qm/Stunde, - geschätzte Gesamtleistung: 500 qm, - Gesamtaufwand: 500 Personenstunden für das Arbeitspaket Verputzen.

Prozentsatzmethoden: • • •

Man verwendet die durchschnittliche phasenbezogene Aufwandsverteilung vergangener Projekte. Voraussetzung ist eine phasenbezogene Dokumentation der angefallenen Stunden. Beispiel: Die folgende Tabelle enthält den anteiligen Aufwand bei Softwareprojekten in Abhängigkeit der Programmgröße und der Komplexität. Dem Beispiel liegt die Entwicklung eines öffentlichen Vermittlungssystems bei der Siemens AG zugrunde.62

Aufwandsverteilung Anforderungsanalyse Systementwurf Programmentwurf Codierung Systemintegration Anforderungsanalyse Mittelschwere Systementwurf SoftwareProgrammentwurf entwicklung Codierung Systemintegration Anforderungsanalyse Komplexe Systementwurf SoftwareProgrammentwurf entwicklung Codierung Systemintegration Alle Werte in Prozent

Einfache Softwareentwicklung

sehr klein 6 15 25 39 15 7 16 25 34 18 7 17 26 30 20

klein

Programmgröße mittel groß

6 15 23 38 18 7 16 24 32 21 7 17 25 28 23

6 15 23 35 21 7 16 23 31 23 7 17 24 26 26

sehr groß 6 15 22 34 23 7 16 22 29 26 7 17 23 24 29

6 15 22 34 23 7 16 21 27 29 7 17 22 22 32

Abb. 79: Aufwandsverteilung in Softwareprojekten Aus Abb. 79 kann man für ein sehr kleines, einfaches Projekt entnehmen, dass sechs Prozent des Gesamtaufwands auf die Anforderungsanalyse entfallen. Schätzt man den Aufwand für 62

Burghardt, M., Einführung in Projektmanagement, Berlin 1995, S. 93 f.

101


diese Phase auf 120 Stunden, wird der voraussichtliche Gesamtaufwand für das Projekt 2.000 Stunden betragen. Kennt man durch die systematische Analyse abgeschlossener Projekte den durchschnittlichen Projektaufwand wie in Abb. 79, lassen sich schon frühzeitig während der Projektabwicklung Abweichungen erkennen, so dass das Projektcontrolling steuernd eingreifen kann. Sieht man z. B., dass die Testphase bei Projekten mit hoher Reklamationsquote einen vergleichsweise geringen Anteil am voraussichtlichen Gesamtaufwand hat, sind Maßnahmen für ausführlichere Tests zu initiieren. Im Rahmen eines Benchmarking können zusätzlich projektübergreifende Vergleiche bezüglich der Verteilung des Aufwands erfolgen. Die Aussagen lassen sich durch die Erfassung weiterer Informationen verfeinern. Eine Schwachstelle der Projektbearbeitung kann z. B. deutlich werden, wenn auch die durchschnittliche Zeitdauer der Projekte bekannt ist. Bei der Analyse der Abb. 80 fällt auf, dass sich die Aufteilung der Zeitdauer von derjenigen des Aufwands unterscheidet. Dies könnte daran liegen, dass für die Analysephase zu wenige Ressourcen bereitgestellt wurden. Die Gründe hierfür sind im Rahmen eines Projektcontrollings weiter zu untersuchen.

Aufwand

Analyse

A = 15 %

Z = 20 %

Entwurf

A = 28 %

Z = 25 %

Realisierung

Integration

A = 27 %

A = 15 %

Z = 20 %

Z = 10 %

Systemtest

A = 15 %

Z = 25 %

A = Aufwand, Z = Zeitdauer

Abb. 80: Relative Anteile von Aufwand und Zeitdauer63

63

102

Burghardt, M., Einführung in Projektmanagement, Berlin 1995, S. 93 f.


,nteUnet

www.ifpug.org

Function-Points

Function-Point-Methode:64 Das Function-Point-Verfahren hat sich speziell für die Aufwandsund Kostenschätzung bei EDV-Vorhaben bewährt. Diesem Verfahren liegt die Annahme zugrunde, dass der Aufwand für die Entwicklung eines Programms von verschiedenen Einflussgrößen (der Verflechtung mit anderen Anwendungen, der Komplexität der abzubildenden Geschäftsvorfälle usw.) abhängt. Durch die Bewertung dieser Einflussfaktoren nach einem genau spezifizierten Verfahren erhält man für bereits abgeschlossene, repräsentative Projekte so genannte Function-Points. Für jedes Projekt der Vergangenheit werden die Function-Points zusammen mit dem Aufwand in ein Koordinatensystem eingetragen. Diese Daten bilden die Grundlage für die statistische Ermittlung der Function-Point-Kurve (siehe Abb. 81). Für ein anstehendes Projekt werden nun die Function-Points errechnet. Über die zuvor ermittelte Kurve kann der Aufwand in Personenmonaten abgelesen werden.

Personenmonate

Abb. 81: Function-Point-Kurve Eine wichtige Voraussetzung für die Anwendbarkeit der geschilderten Methoden ist, dass man vergleichbare Projekte bearbeitet. Je mehr sich neue Projekte von den bisher abgewickelten unterscheiden, desto weniger kann man auf standardisierte Methoden zurückgreifen.

64

Litke, H.-D., Projektmanagement, 2. Aufl., München, Wien 1993, S. 117 ff., sowie Daum, A., Lawa, D., Projekt-Controlling: Aufgaben und Instrumente, in: Steinle, C., Bruch, H. (Hrsg.), Controlling, Stuttgart 1998, S. 894 ff.

103



XnteUVtt]t

Tipp

Das Projektcontrolling erarbeitet Empfehlungen zur Bestimmung des Projektaufwands. Folgende Hinweise sind zu beachten: • • • • •

• •

Basis der Aufwandsschätzung sind die Arbeitspakete. Der Aufwand sollte zusammen mit dem für das Arbeitspaket zuständigen Mitarbeiter ermittelt werden. Für eine realistische Aufwandsschätzung ist es vorteilhaft, auf Erfahrungen aus abgeschlossenen Projekten zurückzugreifen. Eine detaillierte Projektstrukturierung erleichtert die Aufwandsschätzung. Fehlschätzungen muss man einer konstruktiven Analyse unterziehen. Auf keinen Fall dürfen negative Konsequenzen angedroht werden. Dies führt sonst zwangsläufig zu sehr sicherheitsorientierten Schätzungen mit hohen Puffern. Eine realistische Aufwandsplanung wird damit unmöglich. Auch der Aufwand für das Projektmanagement und die Qualitätssicherung muss berücksichtigt werden. Bei großer Unsicherheit und hohem Projektrisiko sollten Zuschläge in Form von Puffern nicht versteckt, sondern nur in separat ausgewiesenen Positionen vermerkt werden (vgl. Abb. 88).

Der Projektcontroller unterstützt die Projektplanung, indem er Schätzworkshops moderiert. Er prüft auch die Aufwandsschätzung daraufhin, ob sie plausibel, realistisch und vollständig ist. Bei oberflächlicher Schätzung besteht die Gefahr, dass der Projektleiter den Aufwand zu niedrig ansetzt. Die folgende Kalkulation zeigt am Beispiel eines fünf Wochen dauernden Projekts, um welche Positionen der gemeldete Nettoaufwand ergänzt werden muss, um den tatsächlichen Aufwand zu erhalten: Nettoaufwand laut Aufwandsschätzung Projektleitung (in der Regel 8 bis 15 Prozent): 10 Prozent Sonstiger Grundaufwand für 5 Mitarbeiter: - Wochenplanung: 0,5 Stunden/Woche und Mitarbeiter - Besprechungen: 3,0 Stunden/Woche und Mitarbeiter - Aufwandserfassung: 0,5 Stunden/Woche und Mitarbeiter - Gesamt: 4,0 Stunden/Woche und Mitarbeiter Schätzungenauigkeit (in der Regel 10 bis 15 Prozent): 10 Prozent Risikozuschlag: Gesamt: PT = Personentage

104

250,0 PT 25,0 PT

12,5 PT 25,0 PT 10,0 PT 322,5 PT


ProCalc ist ein bei Lufthansa Systems entwickeltes Tool zur aktivitätenbezogenen Aufwandsschätzung. Hierbei werden Aktivitäten identifiziert, die während der Projektabwicklung durchgeführt werden, und man schätzt, wie viel Aufwand jede einzelne Aktivität verursacht. Diese Methode erweiterte man bei der Lufthansa Systems um die Möglichkeit, Unsicherheiten, Einflüsse und Risiken mit einzubeziehen. Für die Schätzung bedeutet dies, dass mehrere (100 bis 1000) unterschiedliche Projektszenarien auf Basis der von der Projektleitung definierten Unsicherheiten und Risiken simuliert werden. Als Ergebnis liegt dann eine Verteilungskurve vor, die aufzeigt, mit welcher Wahrscheinlichkeit welcher Aufwand zu erwarten ist. Die bei Lufthansa Systems durchzuführende aktivitätenbezogene Schätzung dauert bis zu einem Tag und läuft wie folgt ab: 1. Im Rahmen der Schätzklausur werden die Aktivitäten ermittelt, die aus der aktuellen Sicht der Projektleitung später im Ist auf die Projektnummern im SAP-System gemeldet werden. Aktivitätenchecklisten bieten hierbei wertvolle Anhaltspunkte. 2. Pro Aktivität wird der minimale, maximale und der wahrscheinlichste Aufwand geschätzt. Basis sind Annahmen über die Randbedingungen der Projektarbeit, z. B. die Erfahrung des Projektteams mit der Programmiersprache, die Geschäftsprozesse, die Stabilität der Entwicklungsumgebung oder die Qualität und Stabilität der Ausschreibungsunterlagen. 3. In der gleichen Art und Weise wie die Personalaufwände werden auch die nicht aufwandsabhängigen Kosten, wie z. B. Reisekosten (international), Seminarkosten, Infrastrukturkosten, berücksichtigt und separat ausgewiesen. 4. Sind diese Rahmenbedingungen unklar (z. B. das Team ist noch nicht benannt), hat dies Auswirkungen auf die in Punkt zwei geschätzten Aufwände. Durch die Festlegung von Einflüssen und Risikofaktoren sowie deren Zuordnung zu den Aktivitäten werden diese Unsicherheiten bei der Schätzung berücksichtigt. Auch hier liefern wiederum Checklisten wichtige Anhaltspunkte. 5. Im Anschluss an obige Aktivitäten werden durch das Tool 100 bis maximal 1000 unterschiedliche Projektszenarien simuliert. Jedes Szenario stellt ein mögliches Ist dar, basierend auf den gemachten Annahmen. An der durch das System ProCalc erstellten Wahrscheinlichkeitskurve lässt sich dann z. B. ablesen, welcher Aufwand angesetzt werden muss, um eine 75-prozentige Sicherheit zu erzielen. 105


6. Auf Wunsch können im Anschluss die verschiedenen Rahmenbedingungen und der Funktionsumfang variiert werden. („Waswäre-wenn-Analysen“). 7. Sollten weiterhin große Unsicherheiten bestehen, kann die Schätzung von Beratern noch mittels einer anderen Methode, der Analogieschätzung, verifiziert werden. Die transparente Dokumentation aller Annahmen, Risiken und Randbedingungen in ProCalc dient als wichtige Argumentationshilfe gegenüber den internen Vertriebsstellen oder dem Kunden und hilft, auf kurzfristig geänderte Vorgaben schnell reagieren zu können. 3.1.7 Terminplanung Für die Terminplanung sind die logischen Abhängigkeiten zwischen den Arbeitspaketen in einer Vorgangsliste festzulegen (vgl. Abb. 82 oben). Nr. im Strukturplan 1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3

Arbeitspaket

Vorgänger

Projektteam bilden Ziele festlegen Projektplan erstellen Genehmigung der Planung Erhebung und Analyse Würdigung Genehmigung der Analyse Konzept erarbeiten Konzept präsentieren Genehmigung Soll-Konzept Systembau Einführung Projekt abgeschlossen

1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2

Abb. 82: Terminplanung 106

Dauer (Wochen) 1 1 2

Verantwortliche Stelle Projektleiter Projektleiter Projektleiter

4 2

Organisation Organisation

5 1

Organisation Organisation

8 3

DV-Abteilung Organisation


Daraus ergibt sich die Bearbeitungsreihenfolge. Danach ist die Dauer aller Arbeitspakete so zu bestimmen, dass der gewünschte Endtermin erreicht werden kann. Die Darstellung der Terminplanung erfolgt überwiegend mit Balkenplänen. Der Terminplan in Abb. 82 zeigt die Dauer und zeitliche Zuordnung aller Arbeitspakete und Teilprojekte. Dazu sind auch Meilensteine eingeplant, wie z. B. in Zeile 5 „Genehmigung der Planung“. Die Verbindungslinien des Balkenplans verdeutlichen die Abhängigkeiten aus der Vorgangsliste. Eine Alternative zu Balkenplänen ist das Netzplandiagramm. Es verdeutlicht Beziehungen sowie technische, wirtschaftliche und logische Abhängigkeiten zwischen den Arbeitspaketen. Ein Netzplan ist vor allem dann hilfreich, wenn man die Auswirkung von Änderungen im Rahmen der Planoptimierung simulieren möchte. Auch die hohe Transparenz von Zeitreserven spricht für den Netzplan. Im Folgenden wird deshalb ein kurzer Überblick über die Netzplantechnik gegeben. Es existieren unterschiedliche Techniken der Netzplanerstellung. Die heutigen DV-gestützten Projektmanagementsysteme arbeiten jedoch überwiegend mit dem Vorgangsknotennetzplan (vgl. Abb. 83 und Abb. 84). Netzplanverfahren

Darstellung

Beispiel

Vorgangspfeilnetz Die Vorgänge werden beschrieben und durch Pfeile dargestellt

Graben

Rohre

ausheben

verlegen

CPM

Vorgangsknotennetz Die Vorgänge werden beschrieben und durch Knoten dargestellt

Graben ausheben

Rohre verlegen

PDM

Rohre verlegt

PERT

Ereignisknotennetz Die Ereignisse werden beschrieben und durch Knoten dargestellt

Graben ausgehoben

Abb. 83: Netzplanverfahren65 65

CPM = Critical Path Method, PDM = Precedence Diagramming Method, PERT = Program Evaluation and Review Technique

107

108 1U

Einführung 'DXHU :RFKHQ

'DXHU :RFKHQ

1U

Systembau

1U

'DXHU 7DJH

1U

Projekt abgeschlossen

1U

'DXHU 7DJH

1U

1U

'DXHU :RFKHQ

Genehmigung Soll-Konzept

1U

'DXHU 7DJH

'DXHU :RFKH

1U

Konzept präsentieren

1U

'DXHU :RFKHQ

Projektplan erstellen

Genehmigung der Analyse 1U

Konzept erarbeiten

'DXHU :RFKHQ

Erhebung und Analyse

'DXHU 7DJH

Genehmigung der Planung

1U

'DXHU :RFKHQ

'DXHU :RFKH

Würdigung

Ziele festlegen

'DXHU :RFKH

1U

Projektteam bilden


Abb. 84: Netzplan (generiert mit MS-Project)

Der Netzplan zeigt den kritischen Weg und Vorgänge mit Pufferzeiten. Auf dem kritischen Weg liegen all jene Vorgänge, die sich nicht verzögern dürfen (sie haben einen Puffer von Null), weil sich sonst der geplante Projektendtermin nicht einhalten lässt. Ein we-


sentliches Ziel der Netzplantechnik ist es, solche Vorgänge zu identifizieren. Um den kritischen Weg eines Netzplans zu bestimmen, müssen folgende Daten errechnet werden: Frühester Anfang (FAZ in Abb. 85 und Abb. 86): Frühester Termin, an dem ein Vorgang beginnen kann. Frühestes Ende (FEZ in Abb. 85 und Abb. 86): Frühester Termin, an dem ein Vorgang enden kann. Spätester Anfang (SAZ in Abb. 85 und Abb. 86): Spätester Termin, an dem ein Vorgang beginnen kann, ohne das Projektende zu verzögern. Spätestes Ende (SEZ in Abb. 85 und Abb. 86): Spätester Termin, an dem ein Vorgang enden kann, ohne das Projekt zu verzögern. Pufferzeit (vgl. zur Ermittlung Abb. 85 und Abb. 86): Zeit, um die sich ein Vorgang gegenüber seinem frühesten Termin verspäten darf, ohne den Abschlusstermin des Projekts zu beeinflussen. Abb. 85 und Abb. 86 verdeutlichen an einem Beispiel, wie die Pufferzeit für einen Knoten ermittelt wird. Zunächst bestimmt man durch die Vorwärtsrechnung den FAZ und den FEZ. Dafür werden alle Vorgänger, die mit dem betrachteten Knoten verknüpft sind, identifiziert. Das Maximum der FEZ aller Vorgängerknoten (38) wird als FAZ übertragen. Addiert man dazu die Dauer (8), so erhält man die FEZ (46). Durch die Rückwärtsrechnung werden SEZ und SAZ festgelegt. Von den SAZ aller direkten Nachfolger wählt man diejenige als SEZ des betrachteten Knotens aus, die am kleinsten ist (55). Zieht man davon die Dauer (8) ab, so resultiert die SAZ. Den Puffer errechnet man nun entweder als Differenz zwischen FAZ (38) und SAZ (47) oder als Differenz zwischen FEZ (46) und SEZ (55). Bei Arbeitspaketen, die auf dem kritischen Weg liegen, sind die früheste und die späteste Lage identisch.

109


Vorwärtsrechnung

35

FAZ = max. (35; 38; 30) FEZ = FAZ + Dauer 38

38

46 8 Legende: FAZ Puffer FEZ

30

SAZ Dauer SEZ

Abb. 85: Berechnung der frühesten Vorgangszeitpunkte

Rückwärtsrechnung

SEZ = min. (60; 55; 58) SAZ = SEZ - Dauer

Legende:

38

9

46

47

8

55

60

55

FAZ Puffer FEZ SAZ Dauer SEZ

58

Abb. 86: Berechnung der spätesten Vorgangszeitpunkte Da der manuelle Aufbau eines Netzplanes sehr aufwendig ist, empfiehlt sich der Einsatz eines DV-gestützten Projektmanagementsystems. Der Netzplan lässt sich damit individuell aufbereiten. Wie Abb. 87 zeigt, können die Knoteninhalte mit unterschiedlichen Informationen belegt werden (Dauer, Beginn- und Endzeitpunkte, Kosten, zuständige Mitarbeiter u. a.). Beispielsweise beinhaltet der zweite Knoten in Abb. 87 Informationen über die Bezeichnung des Vorgangs, seinen Beginn und sein Ende, die Nummer im Projektstrukturplan und einen Hinweis auf fällige Auszahlungen. Damit kann man schnell erkennen, welche Auswirkungen die zeitliche Verschiebung eines Arbeitspakets auf die Liquidität hat.

110


Planung

Planung

Planung

1 Monat

5.000 €

12.2.01

14.3.01

Nr. 1

5.000 €

Maier

12.2.07

Nr. 2

12.3.07

Nr. 4

Kritisch!

Legende der Knoteninhalte: Bezeichnung, Dauer, Kosten, Verantwortlicher, Beginn

Bezeichnung, Beginn, Ende, PSP-Nr., Zahlungstermin

Bezeichnung, Vorgänger, Kosten, Nachfolger, Notiz

PSP-Nr.: Nummer des Arbeitspakets im Projektstrukturplan

Abb. 87: Beschriftungsalternativen für Netzplanknoten

Welche Aufgaben nimmt das Projektcontrolling wahr? Als gestaltende Maßnahme muss das Projektcontrolling eine Terminplanung mit ausreichendem Detaillierungsgrad für jedes Projekt verbindlich fordern. Ergänzend sollten Empfehlungen für den Einsatz von Balkenplänen und Netzplandiagrammen formuliert werden. Hinweise auf geeignete DV-Instrumente gewährleisten eine effiziente und einheitliche Terminplanung. Der Projektcontroller kann auch die Machbarkeit des Terminplans prüfen. Insbesondere sollte er darauf achten, ob genügend Ressourcen zu den geplanten Zeitpunkten bereit stehen. Es ist auch sicher zu stellen, dass die Ressourcen projektübergreifend entsprechend der Projektprioritäten optimal eingesetzt werden.

3UoMeNtFontUoOOeU

XnteUVtt]t

Ein besonderes Augenmerk sollte der Projektcontroller auf die eingeplanten Puffer richten.

Worauf sollte man bei der Planung mit Puffern achten? Bei der Termin- und Aufwandsplanung ist eine möglichst realitätsnahe Schätzung durch die Arbeitspaketverantwortlichen erforderlich. Die wahrscheinliche Dauer der Arbeitspakete wird jedoch oft um komfortable Puffer erweitert, um das Risiko der Zeitüberschreitung zu minimieren. Obwohl dies wenigstens teilweise zu einem früheren Abschluss gegenüber der geplanten Dauer führen müsste, füllen die Aktivitäten fast immer die vorgesehene Dauer aus oder überschreiten sie. Bekannt ist dieses Phänomen als Gesetz von Parkinson: „Work expands to fill time available“.

111


Besser als der versteckte Einbau vieler kleiner Puffer ist es, einen realistischen Gesamtplan um eine Managementreserve zu erweitern (vgl. Abb. 88).66 Planung mit versteckten Puffern B

C E

A D

Planung mit Managementreserve B

C

A

E D Möglicher Zusatzerlös 5 Mio.

Abb. 88: Einplanung einer Managementreserve Damit kann man auch quantifizieren, welche Vorteile durch die Nichtinanspruchnahme des Puffers erzielbar sind. Die Einsparungen könnten teilweise als Incentive an die Mitarbeiter weitergegeben werden. Das wiederum motiviert das Projektteam, die Managementreserve möglichst wenig in Anspruch zu nehmen. Um versteckte Puffer zu vermeiden, sollte allen an der Projektplanung Beteiligten bewusst sein, dass ein Zeitplan keine exakte Vorausschau ist, sondern ein Hilfsmittel, um kritische Entwicklungen zu identifizieren. Die Critical Chain-Methode unterstützt eine Planung ohne versteckte Puffer. Sie soll die Nachteile der klassischen Projektplanung vermeiden:

112

•

Zeiteinsparungen werden oft nicht weitergereicht. Endet ein Arbeitspaket A früher als geplant, so startet das nachfolgende Arbeitspaket B trotzdem erst zum ursprünglich geplanten Termin. Bei der Critical Chain-Methode würde man zehn Tage, drei Tage und einen Tag vor Abschluss von A die Verantwortlichen für Arbeitspaket B darauf hinweisen, dass man früher abschließen wird. So kann sich das Team von Arbeitspaket B auf den

66

Devaux, S., Total Project Control. A Manager´s Guide to Integrated Project Planning, Measuring and Tracking, New York u. a.1999, S. 117 f.


•

•

früheren Beginn vorbereiten. Man spricht auch vom sogenannten „Staffellaufprinzip“. Dieses Vorgehen erfordert, dass oberstes Ziel eine möglichst schnelle Projektabwicklung ist. Bei der klassischen Projektplanung werden Ressourcen oft in mehreren Projekten parallel eingeplant. Dadurch geht viel Produktivität verloren. Bei der Critical Chain-Methode darf eine bestimmte Ressource parallel laufenden Arbeitspaketen nicht zugeordnet werden. Um verdeckte Puffer zu vermeiden, werden die Mitarbeiter aufgefordert, den Aufwand nicht mit einer Wahrscheinlichkeit von 90 Prozent, sondern nur mit 50 Prozent zu schätzen. Zeitüberschreitungen werden mit dem gemeinsamen Puffer für das gesamte Projekt aufgefangen.

Die IBM Global Services steuert das gesamte Projektportfolio anhand einer mit Kosten bewerteten Managementreserve.67 Gegenübergestellt werden die reservierten Managementreserven und die kumulierte Inanspruchnahme (vgl. Abb. 89). Dazu wird gezeigt, wie viel der gesamten Managementreserve durch Projekte, die ihre Plankosten überschreiten, und durch solche, die bisher nur ihre eigene Managementreserve verwenden, verbraucht wird. 30 25 20 15 10 5 0 Jan

Feb

Mär

Ap r

Mai

Jun

Jul

Aug

Sep

Gesamte reservierte Managementreserve Gesamte beanspruchte Managementreserve Beanspruchte Managementreserve durch Projekte mit Kostenüberschreitung Beanspruchte Managementreserve durch Projekte ohne Kostenüberschreitung

Abb. 89:

67

Steuerung des Projektportfolios mit der Managementreserve

Krusch, M., Mit Risk-Management zum unternehmerischen Erfolg, Vortrag auf dem Kongress Projektmanagement von ManagementCircle am 10.11.2004.

113


Was sollte man bei der Reduktion der Dauer beachten? Der Projektcontroller kann auch Entscheidungsgrundlagen liefern, mit denen eine geforderte Verkürzung der Projektdauer kostenminimal möglich wird. Ein neues Produkt soll entwickelt werden. Die ursprüngliche Planung sah eine Dauer von 30 Wochen vor, das Budget belief sich auf 3,5 Mio. €. Man erwartete Erlöse von 11,5 Mio. €. Der Vertrieb erkannte, dass ein großer Konkurrent ein ähnliches Produkt in kürzerer Zeit anbieten wollte. Die Projektleitung erhielt deswegen die Weisung, die Entwicklung um drei Wochen zu verkürzen. Es stellen sich in dieser Situation zwei Fragen, die im Folgenden beantwortet werden sollen: 1. Welche Arbeitspakete verkürzen das Gesamtprojekt? 2. Wie beeinflussen diese Arbeitspakete den wirtschaftlichen Erfolg, also Erlöse und Kosten? Ziel muss es sein, die Projektdauer so zu reduzieren, dass der wirtschaftliche Erfolg möglichst wenig leidet. 1. Welche Arbeitspakete führen zur Verkürzung der Projektdauer? Der Projektleiter identifiziert diejenigen Arbeitspakete, durch deren Wegfall eine höchstmögliche Verkürzung der gesamten Projektdauer möglich wird. Das sind solche, die auf dem kritischen Weg liegen. Devaux beschreibt zudem eine interessante, sehr differenzierte Methode, um herauszufinden, in welchem Maße sich eine Verkürzung einzelner Arbeitspakete auf die Projektdauer auswirkt.68 Dafür wird im Netzplan nicht nur der verfügbare Puffer ausgewiesen, sondern auch die Zeit, um die sich bei einer entsprechenden Verkürzung des Arbeitspakets die gesamte Projektdauer verringert. Diese Information wird im Folgenden als Reduktionspotenzial bezeichnet. Man ermittelt es nach folgender Vorschrift: • •

68

114

Für ein Arbeitspaket außerhalb des kritischen Wegs ist das Reduktionspotenzial Null. Liegt ein Arbeitspaket auf dem kritischen Pfad und existieren keine parallelen Vorgänge, ist das Reduktionspotenzial der Dauer des Arbeitspakets gleich zu setzen. Devaux, S., Total Project Control. A Manager´s Guide to Integrated Project Planning, Measuring and Tracking, New York u. a.1999, S. 138 ff.

3.1 Operative Projektplanung •

• •

Liegt ein Arbeitspaket auf dem kritischen Pfad und gibt es dazu parallele Vorgänge, entspricht das Reduktionspotenzial dem Minimum folgender zwei Größen: a) Dauer des betrachteten kritischen Arbeitspakets, b) Puffer desjenigen parallelen Vorgangs mit dem geringsten Puffer. Das Reduktionspotenzial eines kritischen Arbeitspakets kann maximal so groß wie seine Dauer sein. Um parallele Vorgänge zu bestimmen, werden alle Vorgänger und alle Nachfolger eines Arbeitspakets ermittelt. Arbeitspakete, die weder Vorgänger noch Nachfolger sind, laufen parallel.

Der folgende Netzplan und die Tabelle zeigen am Beispiel die Ermittlung des Reduktionspotenzials (siehe Abb. 90 und Abb. 91). D 5

A 15

F 5

I

12

0

9

4

C 0

10

H 0

B 11

E 6

J

13

8

0

10

0

G 6

10

6

Legende Bezeichnung Dauer Puffer

Abb. 90: Netzplan für die Ermittlung des Reduktionspotenzials Arbeitspaket

Dauer

A

15

C F H J

10 12 13 10

Vorgänger

A A,C,D A,C,D,F A,B,C, D,E,F, G,H,I

Nachfolger B,C,D E,F,G H,I,J F,I,H,J I,H,J J

Parallele Vorgänge Name min. Puffer

Reduktionspotenzial 15

D,B,E,G, B,E,G B,E,G,I

5 6 4

5 6 4 10

Abb. 91: Bestimmung des Reduktionspotenzials 115


Die Arbeitspakete A, C, F, H und J sind kritisch. Für sie ist das Reduktionspotenzial zu bestimmen. Arbeitspakete A und J haben keine parallelen Vorgänge, deswegen entspricht das Reduktionspotenzial ihrer Dauer von 15 und 10 Zeiteinheiten. Für Arbeitspaket C wurden die vier parallelen Vorgänge D, B, E und G ermittelt. Dabei weist D mit 5 Zeiteinheiten den geringsten Puffer auf. Er ist gleichzeitig das Reduktionspotenzial für C. Analog ermitteln sich die Werte für die Arbeitspakete F und H. Für eine maximale Verkürzung des Projekts bietet sich Arbeitspaket A an. Gelingt es, A zu eliminieren, so wird sich das gesamte Projekt um 15 Zeiteinheiten verringern. Soll das Projekt nur sechs Zeiteinheiten gekürzt werden, stehen die Arbeitspakete A, F und J zur Auswahl. In diesem Fall ist zu beachten, dass manche Arbeitspakete kostengünstiger (vgl. das Konzept der mittleren Beschleunigungskosten) verkürzt werden können als andere. Die Verkürzung der Dauer erfolgt in der Regel durch einen vermehrten Personaleinsatz (=Ressourcen). Zusätzliche Ressourcen verändern die Dauer der Arbeitspakete jedoch in unterschiedlichem Maße. Im Folgenden soll deshalb die Frage geklärt werden, wie sich der Einsatz zusätzlicher Ressourcen auf die Dauer eines Arbeitspakets auswirkt.

Wie wirkt sich der Einsatz zusätzlicher Ressourcen auf die Dauer eines Arbeitspakets aus? Man konnte empirisch nachweisen, dass es eine optimale Anzahl von Teammitgliedern gibt.69 Wird die Teamgröße darüber hinaus erweitert, so steigen die Dauer und der Aufwand für die Erledigung einer Aufgabe. Der Zusammenhang wird im Folgenden skizziert. Mit zunehmender Gruppengröße steigt die Zahl der möglichen Kommunikationsbeziehungen K überproportional an. Sie errechnen sich nach der Formel Definition

‫ ܭ‬ൌ ‫ݎ݃݊݁݌݌ݑݎܩ‬öß݁ ൈ

69

116

ሺ‫ݎ݃݊݁݌݌ݑݎܩ‬öß݁ െ ͳሻ ʹ

Schnupp, P. & C. Floyd: Software – Programmentwicklung und Projektorganisation. Berlin, New York 1979. Brooks, F., The Mythical Man-Month. Essays on Software Engineering, Anniversary Edition, Addison-Wesley 1995.


Abb. 92 verdeutlicht den Zusammenhang: Bei drei Teammitgliedern existieren drei Kommunikationsbeziehungen, bei sechs Mitarbeitern schon 15. Ausgehend von der Annahme, dass bei einer Teamgröße von drei Mitarbeitern zwei Stunden Besprechung pro Woche erforderlich sind, ergibt sich bei einer Wochenarbeitszeit von 40 Stunden eine Restarbeitszeit von 38 Stunden. Bei sechs Mitarbeitern reduziert sich die produktive Restarbeitszeit schon auf 30 Stunden. Diesen Sachverhalt kann man auf die Dauer eines Vorhabens übertragen (siehe rechte Spalte in der Abb. 92). Gruppengröße

K

Besprechungsdauer

Produktive Restarbeitszeit (40 Std./Woche)

Projektdauer

3 4 6 7 9 10 11

3 6 15 21 36 45 55

2 Stunden 4 Stunden 10 Stunden 14 Stunden 24 Stunden 30 Stunden 37 Stunden

38 Stunden 36 Stunden 30 Stunden 26 Stunden 16 Stunden 10 Stunden 3 Stunden

D = 0,351 * Aufwand D = 0,278 * Aufwand D = 0,222 * Aufwand D = 0,220 * Aufwand D = 0,278 * Aufwand D = 0,400 * Aufwand

Abb. 92: Zahl der Kommunikationsbeziehungen in einer Gruppe Zugrunde gelegt wird die bereits bekannte Beziehung ‫ ݀݊ܽݓ݂ݑܣ‬ൌ ‫ ݎ݁ݑܽܦ‬ൈ ‫ݎ݁ݐܾ݅݁ݎܽݐ݅ܯ ݈݄ܽݖ݊ܣ‬

Durch Umformen erhält man ‫ ݎ݁ݑܽܦ‬ൌ

‫݀݊ܽݓ݂ݑܣ‬ ‫ݎ݁ݐܾ݅݁ݎܽݐ݅ܯ ݈݄ܽݖ݊ܣ‬

Die Menge der produktiv einsetzbaren Mitarbeiter wird durch Multiplikation der Anzahl Mitarbeiter mit der produktiven Restarbeitszeit ermittelt, so dass die Formel ‫ ݎ݁ݑܽܦ‬ൌ

‫݀݊ܽݓ݂ݑܣ‬ ‫ ݎ݁ݐܾ݅݁ݎܽݐ݅ܯ ݈݄ܽݖ݊ܣ‬ൈ ܴ݁‫ ݊݅ ݐ݅݁ݖݏݐܾ݅݁ݎܽݐݏ‬Ψ

Definition

entsteht. Für den Ausgangsfall mit drei Mitarbeitern errechnet sich folgendes Ergebnis für die produktive Restarbeitszeit: ܲ‫ ݐ݅݁ݖݏݐܾ݅݁ݎܽݐݏܴ݁ ݁ݒ݅ݐ݇ݑ݀݋ݎ‬ൌ

͵ͺ ܵ‫݊݁݀݊ݑݐ‬ ൈ ͳͲͲ ൌ ͻͷΨ ͶͲ ܵ‫݊݁݀݊ݑݐ‬

117


Setzt man diesen Wert in die Formel zur Ermittlung der Dauer ein, so erhält man den Faktor 0,351, der mit dem Aufwand gewichtet werden muss: ‫ ݎ݁ݑܽܦ‬ሺ‫ܦ‬ሻ ൌ

ͳ ൈ ‫ ݀݊ܽݓ݂ݑܣ‬ൌ Ͳǡ͵ͷͳ ൈ ‫݀݊ܽݓ݂ݑܣ‬ ሺ͵ ൈ Ͳǡͻͷሻ

Aus der rechten Spalte der Abb. 92 ist zu entnehmen, dass ein zusätzlicher Mitarbeitereinsatz zunächst zu einer Reduzierung der Projektdauer führt. Bei sieben Mitarbeitern ist die Projektdauer am kürzesten. Setzt man jetzt weitere Mitarbeiter ein, steigt die Projektdauer sogar an. Abb. 93 verdeutlicht diesen Sachverhalt grafisch. Sie zeigt, dass die Dauer bei vier Mitarbeitern genauso lang wie bei neun Mitarbeitern ist. Zu beachten ist auch, dass durch den fünften, sechsten und siebten Mitarbeiter die Dauer nur noch wenig reduziert wird. 5

Dauer

4

3

2

1

0 2

3

4

5

6

7

8

9

10

11

Anzahl Mitarbeiter

Abb. 93: Einfluss der Gruppengröße auf die Projektdauer Vergleicht man das vorliegende Modell mit der Projektrealität, so ist Folgendes einschränkend zu beachten: • •

118

Es wird davon ausgegangen, dass jeder mit jedem kommuniziert. Durch organisatorische Regelungen, insbesondere durch Arbeitsteilung, ist dies in Projekten nicht erforderlich. Das Modell berücksichtigt andererseits solche Kommunikationsbeziehungen nicht, die für die Pflege der sozialen Beziehungen anfallen.


Return On Investment (ROI)

Patterson und Fenoglio bestätigen die bisherigen Erkenntnisse. Sie beschreiben die Wirkung des Ressourceneinsatzes auf die Dauer und den Return on Investment (ROI; vgl. Abb. 47) eines Projektes.70 Bei zunehmendem Personaleinsatz verkürzt sich die Dauer, und der ROI steigt (vgl. Abb. 94). Ab ca. 14 Mitarbeitern führt eine zusätzliche Ressource nur zu einer geringen zusätzlichen Verkürzung der Zeit, der ROI verbessert sich kaum. Ab 17 Mitarbeitern verlängert sich die Dauer, und der ROI geht zurück. 7 6 5 4

n=25

3 2

n=7

1 0

10

20

30

40

50

Dauer in Monaten

Abb. 94: Wirkung zusätzlicher Ressourcen Zusammenfassend kann man feststellen, dass die Projektdauer nicht in gleichem Maße sinkt, wie zusätzliche Mitarbeiter eingesetzt werden. In bestimmten Fällen steigt sogar der erforderliche Zeitbedarf. Die folgende Regel wird also bestätigt: “Adding manpower to a late project makes the project later!”

Tipp

2. Wie beeinflussen Arbeitspakete den wirtschaftlichen Erfolg? Aus der Menge der für die Verkürzung der Projektdauer in Frage kommenden Arbeitspakete wird bei jenen die Leistung reduziert, bei denen dadurch das Gesamtergebnis des Projektes möglichst wenig sinkt. Die Daten dafür kann der Projektcontroller zur Verfügung stellen. Basis seiner Überlegungen ist die Erkenntnis, dass jedes Arbeitspaket einen bestimmten Wert für das gesamte Projekt hat 70

Patterson, M., Fenoglio, J., Leading Product Innovation: Accelerating Growth in a Product-Based Business. New York 1999, S. 228 ff.

119


(vgl. Abb. 76).71 Wenn es gelingt, diesen Wert zu bestimmen, hat man einen Anhaltspunkt, bei welchen kritischen Arbeitspaketen die Leistung ohne großen Wertverlust für das gesamte Projekt verringert werden kann. Um den Nutzen eines Arbeitspakets zu quantifizieren, wird zunächst dessen Wert wie in Abb. 77 bestimmt. Wenn dieser Wert um • •

die kalkulierten Kosten des Arbeitspakets nach Verkürzung und die reduzierten Erlöse, die dadurch entstehen, dass das Arbeitspaket das gesamte Projekt verlängert (Abb. 95 zeigt, dass bei einer Dauer von 30 Wochen Erlöse von zehn Mio. € erzielt werden. Eine Verlängerung um eine Woche verursacht Erlöseinbußen von zwei Mio. €, eine Verkürzung um eine Woche bringt Zusatzerlöse von 500.000 €),

korrigiert wird, so erhält man den zusätzlichen Gewinn oder Verlust (=Nettonutzwert), der durch die Verkürzung eines Arbeitspakets entsteht. 12 11 10

8

- zwei Mio.

7 6

+ eine Woche

Erlöse in Mio.

9

5 4 3 2 1

27

28

29

30

31

32

33

34

35

Dauer in Wochen Abb. 95: Erlösveränderung in Abhängigkeit der Projektdauer 71

120



Erhöht z. B. ein Arbeitspaket den Wert des Projekts um 2,5 Mio. € und verursacht es voraussichtlich Kosten von 950.000 €, ergibt sich zunächst ein Nettonutzwert von 1,55 Mio. €. Weiß man darüber hinaus, dass bei Wegfall des Arbeitspakets das Projekt um drei Wochen verkürzt werden könnte und eine Woche Reduktion der Projektdauer Zusatzerlöse von 0,5 Mio. € erbringt, so verändert sich der Nettonutzwert auf 50.000 €. Erbrächte man die Leistung des Arbeitspakets nicht, so würde der Wert des gesamten Projekts lediglich um 50.000 € sinken. Das betrachtete Arbeitspaket wäre also ein guter Ansatzpunkt, um die Projektdauer aus Erlössicht zu verkürzen.

Wie kann man die Kosten einer Reduzierung der Arbeitspaketdauer ermitteln?

Kosten

Theoretisch existiert eine optimale Dauer, bei der die Kosten minimal sind. Verkürzt man ein Arbeitspaket über diesen Punkt hinaus, steigen die direkten Kosten (durch Überstundenlöhne, Einsatz teurer externer Mitarbeiter u. a.) an. Gleichzeitig sinken die indirekten Kosten. Es werden z. B. die in Anspruch genommenen Kapazitäten (Räume, Anlagen) früher frei. In Summe überwiegt die Kostenerhöhung (vgl. Abb. 96). Die Kostenerhöhung wird vereinfacht in Abb. 97 als lineare Gerade dargestellt. vgl. Abb. 97

Gesamte Kosten

Kmin

Direkte Kosten Indirekte Kosten

Dmin

Dopt

Dmax .

Dauer

Abb. 96: Abhängigkeit der Kosten von der Vorgangsdauer

121


Kosten

Geht man von einem optimal geplanten Projekt aus, so kann mit der folgenden Formel die Wirkung einer Verkürzung der Vorgangsdauer auf die Kosten ausgedrückt werden. Der Zusammenhang ist auch unter dem Begriff der mittleren Beschleunigungskosten bekannt.

Kmax

Kmin

Dmin

Dopt

Dauer

Abb. 97: Mehrkosten durch Verkürzung eines Vorgangs72

Definition

‫ ݊݁ݐݏ݋݇ݏ݃݊ݑ݃݅݊ݑ݈݄݁ܿݏ݁ܤ ݁ݎ݈݁ݐݐ݅ܯ‬ൌ

Kmax Kmin Dmin Dopt

= = = =

‫ܭ‬௠௔௫ െ ‫ܭ‬௠௜௡ ‫ܦ‬௢௣௧ െ ‫ܦ‬௠௜௡

maximale Kosten eines Vorgangs bei minimaler Zeitdauer minimale Kosten eines Vorgangs bei optimaler Zeitdauer minimale Zeitdauer Zeitdauer bei optimaler Planung

Abb. 98: Berechnung der mittleren Beschleunigungskosten Die Projektlaufzeit soll um drei Wochen verkürzt werden. Es kommt dafür das Arbeitspaket A in Frage. Arbeitspaket A könnte unter 72

122

Schmitz, H., Windhausen, M., Projektplanung und Projektcontrolling. Planung und Überwachung von besonderen Vorhaben. Düsseldorf 1980, S. 89 f.


normalen Bedingungen in zwei Monaten, schnellstens jedoch in zwei Wochen abgeschlossen sein. Dabei entstünden Mehrkosten von 20.000 € gegenüber der normalen Zeitdauer. Die gesamten Kosten würden sich dann auf 80.000 € belaufen. Die zusätzlichen Kosten berechnen sich in diesem Fall wie folgt: ‫ ܣ ݊݁ݐݏ݋݇ݏ݃݊ݑ݃݅݊ݑ݈݄݁ܿݏ݁ܤ ݁ݎ݈݁ݐݐ݅ܯ‬ൌ

ͺͲǤͲͲͲ െ ͸ͲǤͲͲͲ ͺെʹ

Aus der Formel errechnet man Mehrkosten von 3.333 € pro Woche. Eine Verkürzung um drei Wochen verursacht also zusätzliche Kosten von 9.999 €.

Wie kann man die Kosten zusätzlicher Ressourcen quantifizieren? Um die Beschleunigungskosten zu ermitteln, muss man die maximale Verkürzung der Dauer eines Arbeitspakets und die entsprechenden Kosten bestimmen. Das kann man mit folgender Schätzmethode unterstützen: Festgelegt wird, um wie viel sich durch eine Verdopplung des Personaleinsatzes die Dauer eines Arbeitspakets verkürzen lässt (Ressourcenelastizität). Zusätzliche Ressourcen über das geplante Maß hinaus führen natürlich zu Mehrkosten. Diese Mehrkosten kann man quantifizieren.73 Zugrunde gelegt wird dabei ein linearer Kostenverlauf über die Zeitdauer. Überstundenzuschläge oder Prämien für Mehrarbeit werden nicht berücksichtigt. ‫ ݊݁ݐݏ݋݇ݎ݄݁ܯ‬ൌ ‫ ݊݁ݐݏ݋݇ݐ݉ܽݏ݁ܩ‬െ ݊‫݊݁ݐݏ݋݈݇݊ܽܲ ݈݁ܽ݉ݎ݋‬ ‫ ݊݁ݐݏ݋݇ݐ݉ܽݏ݁ܩ‬ൌ ሺʹ ൈ ݈ܲܽ݊݇‫݊݁ݐݏ݋‬ሻ ൈ ሺ

Definition

݊‫ݎ݁ݑ݈ܽ݀݊ܽܲ ݈݁ܽ݉ݎ݋‬ ሻ ‫݇ݎ݁ݒ‬ü‫ݎ݁ݑ݈ܽ݀݊ܽܲ ݁ݐݖݎ‬

Abb. 99: Bestimmung der minimalen Dauer eines Arbeitspakets Eine Verdopplung des Personaleinsatzes führt nach der angegebenen Formel nicht zu einer Verdopplung der Kosten. Gegenzurechnen ist immer die Kosteneinsparung durch die reduzierte Projektdauer. Je mehr Zeit eingespart wird, desto weniger zusätzliche Kosten fallen 73


123


an. Wenn bei einem kritischen Arbeitspaket, das ursprünglich acht Wochen dauern und 100.000 € kosten sollte, eine Verdopplung des Ressourceneinsatzes zu einer verkürzten Dauer von sechs Wochen führt, errechnen sich daraus Mehrkosten von 50.000 €. ‫ ݊݁ݐݏ݋݇ݎ݄݁ܯ‬ൌ ‫ ݊݁ݐݏ݋݇ݐ݉ܽݏ݁ܩ‬െ ݊‫݊݁ݐݏ݋݈݇݊ܽܲ ݈݁ܽ݉ݎ݋‬ ͸ ‫ ݊݁ݐݏ݋݇ݎ݄݁ܯ‬ൌ ሺʹ ൈ ͳͲͲǤͲͲͲ ̀ሻ ൈ ൬ ൰ െ ͳͲͲǤͲͲͲ ̀ ͺ

Wie kann man den zusätzlichen Gewinn quantifizieren? Neben den Mehrkosten muss der zusätzliche Erlös durch eine Verkürzung der Projektlaufzeit berücksichtigt werden. Die folgende Abb. 100 führt das Beispiel aus Abb. 91 fort. Es ergeben sich bei der angeführten Ressourcenelastizität folgende Daten: A Arbeitspaket

B Dauer

A C F H J

15 10 12 13 10

C Plankosten 70.000 € 80.000 € 90.000 € 90.000 € 80.000 €

D Reduktionspotenzial 15 5 6 4 10

E Ressourcenelastizität 3 2 5 4 0

F Verkürzte Plandauer 12 8 7 9 10

G Mehrkosten 42.000 € 48.000 € 15.000 € 34.615 € 80.000 €

H Zusätzlicher Gewinn 1.458.000 € 952.000 € 2.485.000 € 1.965.385 € -

Abb. 100: Auswirkungen zusätzlicher Ressourcen Ein Einsparungsziel von drei Wochen wird am besten durch die Verkürzung derjenigen Arbeitspakete mit den geringsten Zusatzkosten bzw. dem höchsten zusätzlichen Gewinn erreicht. Durch die Verdopplung des Ressourceneinsatzes bei Arbeitspaket F erzielt man z. B. eine Einsparung von fünf Wochen (vgl. Spalte E). Die Mehrkosten belaufen sich auf 15.000 € (vgl. Spalte G). Sie errechnen sich wie folgt (vgl. zur Berechnung Abb. 99): ‫ ݊݁ݐݏ݋݇ݎ݄݁ܯ‬ൌ ሺʹ ൈ ͻͲǤͲͲͲ ̀ሻ ൈ ൬ ‫ ݊݁ݐݏ݋݇ݎ݄݁ܯ‬ൌ ͳͷǤͲͲͲ ̀

͹ ൰ െ ͻͲǤͲͲͲ ̀ ͳʹ

Angenommen, eine Woche Verkürzung des Projektes würde Mehrerlöse von 500.000 € erbringen (vgl. Abb. 95). Dann errechnet sich nach Abzug der Mehrkosten von 15.000 € ein zusätzlicher Gewinn von 2.485.000 €:

124

3.1 Operative Projektplanung ܼ‫ݏݑ‬ä‫ ݊݊݅ݓ݁ܩ ݎ݄݈݁ܿ݅ݖݐ‬ൌ ሺͷ ൈ ͷͲͲǤͲͲͲ €ሻ െ ͳͷǤͲͲͲ €

Sofort sieht man, dass auch die Verkürzung der anderen Arbeitspakete zusätzlichen Gewinn brächte. Damit hat man Hinweise für die Optimierung der Projektdauer. Im Beispiel bietet sich Arbeitspaket F an. Zu beachten ist, dass die Obergrenze der Zeiteinsparung immer das Reduktionspotenzial bildet. Aus wirtschaftlichen Gründen sollte jedoch die durch die Ressourcenelastizität erzielbare Verringerung der Dauer nicht überschritten werden. Arbeitspaket J stellt einen Sonderfall dar. Trotz einer Verdopplung des Ressourceneinsatzes lässt sich die Projektdauer nicht reduzieren. Die Daten des vorgestellten Konzepts bieten auch eine fundierte Grundlage, um zu entscheiden, für welche kritischen Arbeitspakete vordringlich knappe Ressourcen einzusetzen sind. Kennt man den Einfluss eines Arbeitspakets auf die Projektdauer und den Mehr/Mindererlös für eine Verkürzung/Verzögerung des Projektes, hat man einen Anhaltspunkt, bei welchen Aktivitäten es sich lohnt, knappe Ressourcen zu verwenden. Außerdem ist dann jedem Projektmitarbeiter bewusst, welche finanziellen Konsequenzen eine Verzögerung des gerade bearbeiteten Arbeitspakets hätte. Zusammenfassend ist festzustellen, dass für fundierte Entscheidungen folgende Analysen erforderlich sind: 1. Bestimmung des Reduktionspotenzials für alle kritischen Arbeitspakete durch Beantwortung der Frage: Um wie viele Wochen kann die gesamte Projektlaufzeit durch das betrachtete Arbeitspaket reduziert werden? 2. Bestimmung des zusätzlichen Erlöses bei einer Verkürzung der Projektdauer und des Mindererlöses bei einer Verlängerung der Projektdauer. 3. Ermittlung der Ressourcenelastizität für jedes kritische Arbeitspaket, indem man feststellt, um wie viele Wochen sich das Arbeitspaket durch die Verdopplung des Ressourceneinsatzes verkürzt, sowie Kalkulation der Mehrkosten, die bei einer Verdopplung des Ressourceneinsatzes entstehen. 4. Errechnung des zusätzlichen Gewinns.

125


3.1.8 Ressourcenplanung Unter Ressourcen versteht man Mitarbeiter, Material und Sachmittel. Von besonderer Bedeutung für die Projektplanung sind die Mitarbeiter. Deswegen muss man deren Einsatz für das Projekt sorgfältig und systematisch planen. Die Ressourcenplanung erfordert je Mitarbeitergruppe (eine Gruppe beinhaltet Mitarbeiter gleicher Qualifikation) die folgenden Arbeitsschritte: 1. Ermittlung des Personalbedarfs, 2. Ermittlung der zur Verfügung stehenden Personalkapazität, 3. Vergleich von Kapazität und Bedarf sowie Kapazitätsausgleich.

Was ist bei der Ermittlung des Personalbedarfs zu beachten? Für jedes Arbeitspaket muss möglichst konkret angegeben werden, welche Mitarbeiter benötigt werden. Im Einzelnen sind folgende Fragen zu beantworten: • • • •

Welche Qualifikation müssen die Mitarbeiter besitzen? Wie viele Mitarbeiter sind nötig? Wie lange sind die Mitarbeiter einzusetzen? Wann müssen sie zur Verfügung stehen?

Mit einem Ressourcenbelastungsdiagramm (vgl. Abb. 101) kann man für jede benötigte Qualifikation deren Bedarf über der Zeitachse verdeutlichen.

Ressourcenbedarf

6

2

5 4

4

3

6

1

6

1

2

3

0 1

2

3

4

5

6 5

6

7

8

9

10

Zeit in Wochen

Abb. 101: Ressourcenbelastungsdiagramm Abb. 101 zeigt, dass drei Wochen nach Projektstart für die Arbeitspakete drei, vier und zwei jeweils zwei Einheiten einer bestimmten

126


Ressource (z. B. Mitarbeiter der Qualitätssicherung) benötigt werden. Die Kapazitätsbelastung kann für die Beantwortung unterschiedlicher Fragestellungen verwendet werden. So ist es für das Multiprojektcontrolling sinnvoll, auch Projekte und deren Bedarf an Mitarbeitern aus bestimmten Organisationseinheiten zu verdeutlichen. Bei termingesteuerter Planung resultiert der Personalbedarf des Kapazitätsbelastungsdiagramms unmittelbar aus dem geschätzten Aufwand und der vorgegeben Dauer. In diesem Fall muss anschließend geprüft werden, ob die erforderlichen Ressourcen auch zur Verfügung stehen.

Wie ermittelt man die freie Personalkapazität? Die vorhandene Personalkapazität wird im Kapazitätsbelastungsdiagramm durch eine Linie eingezeichnet, welche die verfügbare Kapazität dokumentiert. Abb. 102 verdeutlicht, dass zum Zeitpunkt drei die vorhandene Kapazität nicht ausreicht, um den Kapazitätsbedarf zu decken.

Ressourcenbedarf

6

2

5 4

4

3

6

2 1

6

1 3

0 1

2

3

4

5

6 5

6

7

8

9

10

Zeit in Wochen

Abb. 102: Kapazitätsbelastungsdiagramm mit verfügbarer Kapazität Die Personalkapazität hängt von der zeitlichen Verfügbarkeit der Mitarbeiter ab, für deren Bestimmung zwei Informationen vorliegen müssen: 1. Durchschnittlich zur Verfügung stehende Arbeitszeit eines Mitarbeiters pro Monat (Nettoarbeitszeit), 2. Inanspruchnahme des Mitarbeiters für Routineaufgaben und andere Projekte. 127


1. Ermittlung der Nettoarbeitszeit Die Nettoarbeitszeit errechnet sich z. B. wie folgt: = =

Anzahl Tage pro Jahr: Samstage und Sonntage Feiertage Vorläufige Arbeitszeit Urlaub Weiterbildung, Sonderurlaub u.ä. Durchschnittliche Krankheitstage Normalarbeitszeit

365 Tage 104 Tage 11 Tage 250 Tage 30 Tage 6 Tage 6 Tage 208 Tage

Zusätzlich kann man weitere Zeitabzüge berücksichtigen: • •

Sachliche Verteilzeiten, die z. B. Behinderungen des Arbeitsablaufs durch fehlendes Material oder andere Störungen des Arbeitsprozesses berücksichtigen; persönliche Verteilzeiten, die ungeplante Pausen während der Arbeitszeit (z. B. Gespräche im Kollegenkreis, Geburtstagsfeiern) beinhalten.

Für Verteilzeiten wird häufig ein Wert zwischen 15 und 20 Prozent der Normalarbeitszeit angesetzt. Um die verfügbare Arbeitszeit schnell zu ermitteln, kann man eine Tabelle wie in Abb. 103 verwenden.74 Std./ Woche 40 39 38 37 36 35 34 33 32

Std./ Tag 8,0 7,8 7,6 7,4 7,2 7,0 6,8 6,6 6,4

Std./Jahr netto 1664,0 1622,4 1580,8 1539,2 1497,6 1456,0 1414,4 1372,8 1331,2

Std./Monat netto 138,7 135,2 131,7 128,3 124,8 121,3 117,9 114,4 110,9

Abb. 103: Verfügbare Personalstunden pro Monat In diesem Beispiel rechnet man durchschnittlich mit 250 Tagen pro Jahr und 42 Tagen Urlaubs- und Fehlzeiten, also mit einer Normal74

128

Burghardt, M., Einführung in Projektmanagement, München, Erlangen 1995, S. 123.


arbeitszeit von 208 Tagen im Jahr. Bei einer 35-Stunden-Woche stehen 121,3 Stunden netto pro Monat zur Verfügung: ሺʹͲͺ ܶܽ݃݁ ൈ ͹ ܵ‫݊݁݀݊ݑݐ‬ሻ ൌ ͳʹͳǡ͵ ܵ‫݊݁݀݊ݑݐ‬ ͳʹ ‫݁ݐܽ݊݋ܯ‬

Für sehr kurze Projekte kann es erforderlich sein, nicht mit Durchschnittswerten zu planen, sondern die verfügbaren Stunden differenziert für jeden Monat zu errechnen. Auch in internationalen Projekten muss man u. U. unterschiedliche Ansätze für die verfügbaren produktiven Stunden zugrunde legen. In den USA stehen im Entwicklungsbereich 1.900 Stunden/Jahr zur Verfügung, in Österreich 1.780 und in Deutschland 1.560.75

Tipp

Die Nettoarbeitszeit wird in der bereits in Abschnitt 3.1.6 erwähnten Planungsformel wie folgt berücksichtigt: ‫ ݀݊ܽݓ݂ݑܣ‬ൌ ‫ ݎ݁ݑܽܦ‬ൈ ‫ ݊݁ܿݎݑ݋ݏݏܴ݁ ݈݄ܽݖ݊ܣ‬ൈ ࡿ࢚࢛࢔ࢊࢋ࢔Ȁࡹ࢕࢔ࢇ࢚

Definition

Bei einem geschätzten Aufwand von 10.000 Stunden, einer vorgegebenen Dauer von zehn Monaten und einer Arbeitszeit von 100 Stunden pro Monat ergibt sich ein Personalbedarf von zehn Mitarbeitern. 2. Inanspruchnahme des Mitarbeiters für Routineaufgaben und andere Projekte Um sich über die freie Personalkapazität immer aktuell informieren zu können, ist es sehr hilfreich, die verplanten Mitarbeiterkapazitäten projektübergreifend in einer zentralen Datenbank zu dokumentieren. Einen groben Überblick über die Einplanung der Mitarbeiter und deren Aufgaben im Projekt liefert auch eine Funktions- oder Verantwortungsmatrix (vgl. Abb. 104). Sie lässt erkennen, welche Mitarbeiter in welchem Umfang für ein bestimmtes Arbeitspaket eingeplant sind. Mitarbeiter 2 ist in Abb. 104 z. B. zu 40 Prozent seiner Arbeitszeit für Arbeitspaket 5 und zu 30 Prozent für Arbeitspaket 3 verplant. 30 Prozent sind also noch frei.

75

Burghardt, M., Einführung in Projektmanagement, 3. Aufl., München, Erlangen 2001, S. 344.

129


Im Schnittpunkt von Zeilen und Spalten könnte man zusätzlich durch Symbole verdeutlichen, welche Kompetenzen (Planung, Ausführung, Kontrolle) ein Mitarbeiter hat. Bereich A Abteilung 2

Abteilung 1 MA 2

MA 3

MA 4

MA 5

MA 6

AP 5

0,4

0,8

0,5

AP 2

0,3

AP 1

Projekt A

AP 3

Projekte

AP 4

Projekt B

AP 6

MA 1

AP = Arbeitspaket, MA = Mitarbeiter

Abb. 104: Funktionsmatrix DV-gestützte Projektmanagementtools unterstützen die Einplanung von Mitarbeitern innerhalb eines einzelnen Projektes und projektübergreifend (Abb. 105).

Abb. 105: Ressourceneinplanung in MS-Project

130


MS-Project zeigt z. B. im zeitlichen Ablauf den Aufwand, den die Mitarbeiter in den einzelnen Arbeitspaketen und Projekten leisten sollen. Daraus kann man seine Arbeitsbelastung errechnen.

Wie erfolgt der Ausgleich von Kapazität und Bedarf? Als Ergebnis der Kapazitätsbedarfsplanung erhält man die Kapazitätsbelastung wie in Abb. 102. Stehen die benötigten Kapazitäten zu einem bestimmten Zeitpunkt nicht zur Verfügung, muss der Spitzenbedarf durch einen Kapazitätsausgleich abgebaut werden (vgl. Abb. 106). Ziel ist es, dass das Angebot und die Nachfrage nach Ressourcen übereinstimmen. Dafür gibt es mehrere Möglichkeiten: • • • • •

Zeitliche Verschiebung der Vorgänge in Phasen geringer Kapazitätsbelastung wie in Abb. 106 dargestellt, intensivere Nutzung der Kapazitäten, Erhöhung der zeitlichen Verfügbarkeit der Kapazitäten, z. B. durch Überstunden, Einplanung zusätzlicher Kapazitäten, z. B. durch Nutzung externer Dienstleister, Einsatz anderer Verfahren, z. B. besserer Betriebsmittel.

Ressourcenbedarf

6 5

2

2

4

2

4

6

3 2 1

6

1 3

0 1

2

3

4

5

6 5

6

7

8

9

10

Zeit in Wochen

Abb. 106: Kapazitätsausgleich

Welche Aufgaben nimmt das Projektcontrolling wahr? Das Projektcontrolling sollte die realistische Ermittlung und zentrale Dokumentation der freien Kapazitäten sicherstellen. Damit wird auch eine ungleichmäßige Ressourcenauslastung vermieden. In der Praxis kommt es immer wieder vor, dass einige Mitarbeiter zu

3UoMeNtFontUoOOeU

XnteUVtt]t

131


mehr als 100 Prozent ausgelastet sind, während andere noch freie Kapazitäten haben. Die für ein Projekt zur Verfügung stehende Zeit eines Mitarbeiters wird manchmal zu optimistisch gesehen. Gründe sind: • • •

Es wird die gesamte Bruttoarbeitszeit eingeplant. Offiziell abgeschlossene Projekte binden weiterhin Kapazitäten des Mitarbeiters. Urlaub und Krankheitstage werden übersehen.

Das Projektcontrolling sollte dazu beitragen, diese Probleme aufzudecken. Erkennt der Projektcontroller Engpässe, muss er dafür sorgen, dass diese frühzeitig kommuniziert und beseitigt werden. Es ist vor allem bei knappen Ressourcen erforderlich, dass eine projektübergreifende Koordination des Mitarbeitereinsatzes erfolgt. Wertvoll ist es in dieser Situation, wenn die Prioritäten der Projekte bekannt sind (vgl. Abschnitt 2.1). Der Projektcontroller sollte auch dafür Sorge tragen, dass die einzelnen Mitarbeiter nicht in zu vielen Projekten eingesetzt werden. Verplant man den Mitarbeiter in mehr als fünf Projekten, sind der Koordinierungsaufwand und die durch den Wechsel zwischen den verschiedenen Aufgaben bedingten „geistigen Rüstzeiten“ zu hoch. Wenn ein Mitarbeiter mit weniger als 20 Prozent zur Verfügung steht, ist sein Interesse für das Projekt gering. In einer Projektmatrixorganisation, bei der ein Mitarbeiter neben dem Projekt auch noch sein Tagesgeschäft erledigen muss, ist von vornherein sicherzustellen, dass er in seiner Fachabteilung auch im erforderlichen Umfang entlastet wird. Geschieht das nicht, wird der Mitarbeiter schnell überfordert, mit der Folge, dass seine Motivation im Projekt sinkt. Um diese Situation zu vermeiden, kann der Projektcontroller einen Kontrakt zwischen Projektleiter und den Abteilungsleitern anregen, in dem diese sich verpflichten, die Mitarbeiter entsprechend ihrer Projekteinplanung vom Tagesgeschäft freizustellen. Es sollte darin auch geregelt werden, wie der Ausfall für die Fachabteilung kompensiert werden kann. Der Projektcontroller sollte des Weiteren dafür sorgen, dass die nötigen Ressourcen nicht nur mengenmäßig bereit stehen, sondern auch die erforderliche Qualifikation besitzen.

132


Die Planung des Stundenaufwands wird bei der Outokumpu Technology GmbH durch die Projektcontroller in Zusammenarbeit mit dem Projektleiter personenbezogen erstellt. Planung durch Projektleiter/ Projektcontroller Planung durch Kostenstellenleiter

verfügbare Ressourcen

zusätzliche Ressourcen (Ausleihe) Kapazitätsanpassung (Ausleihe, Anwesenheit)

Stundenplanung Angebote/FuE/ Gemeinkostenprojekte

Stundenplanung Kundenprojekte

Personaleinsatzplanung

Ja

Bedarf > Kapazität Nein

Abb. 107: Systematik der Auslastungsplanung Hieraus ergibt sich die Auslastungsplanung der einzelnen Abteilungen. Die verantwortlichen Abteilungsleiter müssen die erforderlichen Kapazitäten durch den Einsatz von Eigen- und Fremdpersonal bereitstellen. Aus der Summe der Kundenaufträge und internen Projekte resultieren die entsprechenden Auslastungen der Fachabteilungen, der Geschäftsbereiche sowie der Gesellschaft insgesamt (vgl. Abb. 107). 3.1.9 Kosten- und Erlösplanung Die rechnungswesenrelevanten Daten aller geplanten Projekte müssen in das Gesamtbudget des Unternehmens integriert werden. Der grundsätzliche Abrechnungsfluss ist in Abb. 108 aufgeführt. Man erkennt, dass die Projekte Einfluss nehmen auf die Planung der Kostenstellenkosten, die Kostenträgerplanung (=Plankalkulation), die Planung des internen Unternehmensergebnisses und letztendlich auf die Gewinn- und Verlustrechnung (G+V) sowie auf die Planbilanz. Auch der Finanzplan, der die Liquidität eines Unternehmens verdeutlicht, wird durch die von den Projekten verursachten Auszahlungen und Einzahlungen beeinflusst. Im Folgenden wird beschrieben, wie die voraussichtlichen Projektkosten kalkuliert werden (in Abb. 108 allgemein als Kostenträgerplanung bezeichnet).

133


Erfolgsplan/Plan-G+V

Planbilanz

Erlöse - var. Kosten = Deckungsbeitrag - fixe Kosten = Betriebsergebnis

Passiva

Anlagevermögen Umlaufvermögen

Eigenkapital Fremdkapital

Herstellkosten + Verw.-Gemeinkosten + Vertr.-Gemeinkosten + Sondereinzelkosten = Selbstkosten

Kosten- und Leistungsrechnung Finanzplan

Aktiva

Kostenträgerplanung

Einzahlungen - Auszahlungen

Zuschlags- /Verrechnungssätze

Betriebsergebnis + Austauschergebnis bilanziell/kalk. + Abgrenzungsergebnis + neutrales Ergebnis = Unternehmensergebnis - Steuern EEV = Jahresüberschuss

Ergebnisplan

Kostenstellenplanung Kostenarten

var.

fix

= Finanzbedarf/ -überschuss

Pro j e k t p l an u n g

Abb. 108: Abrechnungsfluss der Budgetierung


XnteUVtt]t

Die Projektkostenplanung basiert auf funktionierenden Strukturen des Rechnungswesens und Controllings. Je besser diese Basis ausgestaltet ist, desto aussagefähiger und zuverlässiger sind auch die Daten über die voraussichtlichen Projektkosten. Die Kalkulation wird in Abhängigkeit des Projektfortschrittes sukzessive verfeinert. Während zu Beginn auf der Grundlage einer groben Aufwandsermittlung Kosten geschätzt werden müssen, kann man mit zunehmender Projektdauer genauere Kalkulationen durchführen, da die Datengrundlage für die Kostenbestimmung differenzierter und zuverlässiger wird. Für die Kostenplanung ist eine enge Zusammenarbeit von Projektleiter und Projektcontroller erforderlich. Abb. 109 verdeutlicht, dass der Projektleiter die Mengenangaben, wie Anzahl Personalstunden, vorgibt. Mit Hilfe der wertmäßigen Daten aus dem Rechnungswesen können die Plankosten ermittelt werden.

134

3.1 Operative Projektplanung Planaufwand des Projekts

Daten des Rechnungswesens Stundensätze

Personalstunden

Materialpreise

Materialien

Verrechnungssätze der Kostenstellen Angebote

Zuschlagssätze

x

Leistungen von Kostenstellen

Plankosten des Projekts Personalkosten + Materialkosten Kostenstellen= + kosten

Extern zu beziehende Leistungen

+ Externe Kosten

Sonstiger Aufwand (Reisen u.a.)

+ Sonstige Kosten

Integration in das Budget des Unternehmens

= Direkte Projektkosten + Gemeinkosten = Projektgesamtkosten

Abb. 109: Daten für die Projektkostenkalkulation Für Entscheidungen ist es zweckmäßig, zunächst nur die direkt und eindeutig dem Projekt zurechenbaren Kosten zu kalkulieren und erst in einem weiteren Schritt die allgemeinen Gemeinkosten des Unternehmens zu berücksichtigen. Damit kann schnell die Frage beantwortet werden, welche Kosten entfallen, wenn das Projekt oder das Arbeitspaket nicht ausgeführt wird.

Wie ermittelt man die Personalkosten? In vielen Projekten entfällt der größte Kostenanteil auf das Personal. Für die Personalkostenermittlung ist es nicht praktikabel, mit den tatsächlichen Lohn- und Gehaltssätzen zu arbeiten. Besser ist es, auf Standardsätze zurückzugreifen, die das Rechnungswesen bereitstellt. Bei der Ermittlung der Standardlohn- und -gehaltskosten stuft man die Mitarbeiter in Kategorien ein (vgl. Abb. 110). Es ist darauf zu achten, dass die Anzahl der verschiedenen Kategorien möglichst klein gehalten wird (max. zehn). Für jede Kategorie wird vom Controlling ein einheitlicher Stundensatz errechnet (vgl. Abb. 111). Verzichten sollte man auf willkürliche, nach unternehmenspolitischen Gesichtspunkten festgelegte Stundensätze, weil dadurch die Kalkulation nicht mehr aussagekräftig ist und sie ihre Lenkungsfunktion für das Projekt verliert.

135

3 Operatives Projektcontrolling Kategorie 1 2 3 4 5

Mitarbeiter Geschäftsführer, Bereichsleiter Projektmanager, Abteilungsleiter Leitende Techniker, Gruppenleiter Untergeordnete Techniker, Einkäufer Sekretärinnen

Abb. 110: Einteilung der Mitarbeiter in Kategorien Abb. 111 zeigt die kostenstellenbezogene Errechnung eines Stundensatzes. Tage pro Jahr 365 - Samstage und Sonntage 104 - Feiertage 10 - Urlaub 30 - Krankheitstage 15 Normalarbeitszeit 206 - Verteilzeit (15 %) 31 Anwesenheitszeit (35-Stunden-Woche) 1.225 + Überstunden 20 - Weiterbildung 80 Produktivzeit 1.165 x Anzahl Mitarbeiter 60 Produktivzeit gesamt 69.900 Gesamtkosten der Kostenstelle 15 - direkt verrechenbare Kosten 5 Abzudeckende Kosten 10 Stundenverrechnungssatz 143

Tage Tage Tage Tage Tage Tage Tage Stunden Stunden Stunden Stunden Mitarbeiter Stunden Mio. € Mio. € Mio. € €

Abb. 111: Errechnung eines Standardstundensatzes

Wie berücksichtigt man Gemeinkosten? Während z. B. Personal- und Materialkosten in einem direkten Bezug zu den Projektleistungen stehen und genau geplant werden, ist dies bei vielen anderen Kosten nicht der Fall. Kosten für die Nutzung des Kopierers, von Büroräumen, der Kantine oder für allgemeine Verwaltungsleistungen werden nicht direkt für das Projekt erfasst. Entweder, weil dies gar nicht möglich ist (welcher Gehaltsanteil des Pförtners entfällt auf ein bestimmtes Projekt?) oder weil der Erfassungsaufwand zu hoch wäre. Diese Gemeinkosten verrechnet man deshalb pauschal über prozentuale Zuschläge auf die direkt zurechenbaren Projektkosten.

136


Des Weiteren existieren Gemeinkosten, die anfallen, wenn für das Projekt innerbetriebliche Leistungen erforderlich sind. Benötigt man z. B. die Kostenstelle Qualitätssicherung, wird die zeitliche Inanspruchnahme mit dem Verrechnungssatz der Qualitätssicherung multipliziert, um die entstehenden Kosten auf das Projekt zu verrechnen. Verrechnungssätze plant das Controlling. Man ermittelt dafür die aufgrund der geplanten Kostenstellenleistungen anfallenden Gesamtkosten (Gehälter und Sozialkosten aller Mitarbeiter der Kostenstelle, Raumkosten, Abschreibungen, Energie- und Instandhaltungskosten ) und dividiert sie durch die Beschäftigung der Kostenstelle (z. B. geplante Leistungsstunden für Projekte, Anzahl geplante Maschinenstunden). Werden Gemeinkosten über pauschale Zuschläge errechnet, sollte man darauf achten, dass die Zuschlagssätze nicht zu hoch ausfallen. Dies kann die Genauigkeit der Kalkulation beeinträchtigen. Wenn die Zuschläge über 20 Prozent betragen, was aufgrund der großen Bedeutung der indirekten Kosten durchaus möglich ist, sollte man eine leistungsorientierte Verrechnung über die Prozesskostenrechnung in Erwägung ziehen.76

Wie sieht eine Projektkostenkalkulation aus? Die folgende Abb. 112 zeigt am Beispiel, wie die verschiedenen Kostenpositionen in der Kalkulation für ein Arbeitspaket berücksichtigt werden.

76

Fiedler, R., Gräf, J., Einführung in das Controlling, 3. Aufl., München, Wien 2010 (in Vorbereitung).

137

3 Operatives Projektcontrolling Einheit Menge Direkte Materialkosten Messingblech St. Leiterplatten St. Sonstiges Materialgemeinkosten Direkte Gehaltskosten Ingenieure Std. Techn. Zeichner Std. Prüfer Std. Fertigungsgemeinkosten Montage Std. Qualitätssicherung Std. Externe Engineeringkosten Std. Summe Verwaltungs- und Vertriebskostenzuschlag (10 %) Selbstkosten

Preis/ Einheit

Kosten

10 € 80 € 5%

1.500 € 4.000 € 3.000 € 425 €

10 20 4

120 € 75 € 130 €

1.200 € 1.500 € 520 €

3 4 4

110 € 120 € 500 €

330 € 480 € 2.000 € 14.955 € 1.496 € 16.451 €

150 50

Abb. 112: Projektkostenkalkulation Alternativ zu einer progressiven Ermittlung der Projektkosten wie in Abb. 112 kann auch retrograd in Form einer Deckungsbeitragsrechnung kalkuliert werden. Projekt C Kundenpreis - Variable Projekteinzelkosten Deckungsbeitrag I - Fixe Projekteinzelkosten Projektergebnis I - Projektgemeinkosten Projektergebnis II - Sonstige Gemeinkosten Projektergebnis III (Vollkosten)

200.000 € 153.000 € 47.000 € 2.800 € 44.200 € 4.200 € 40.000 € 25.402 € 14.598 €

Abb. 113: Retrograde Projektkalkulation Das Beispiel in Abb. 113 verdeutlicht, dass nach Abzug der von der Leistung abhängigen und direkt durch das Projekt verursachten Kosten ein Deckungsbeitrag von 47.000 € übrig bleibt. Davon werden die direkt dem Projekt zurechenbaren, nicht von der Projektleistung, sondern nur von der Zeit abhängigen Kosten (z. B. Leasingkosten oder Mietkosten) abgezogen. Man erhält das Projektergebnis I. Wird diese Position um Projektgemeinkosten (z. B. anteilige Kosten eines zentralen Projektbüros) bereinigt, resultiert das Projektergebnis II in 138


Höhe von 40.000 €. Es dient zur Deckung der Gemeinkosten des Unternehmens und zur Gewinnerzielung. Die Kalkulation der Outokumpu Technology GmbH ermittelt auf Grundlage der Kundenbestellung die Kosten für Festpreisaufträge oder Aufwandsaufträge (vgl. Abb. 114). Nach einem standardisierten Schema werden mechanische und elektrische Ausrüstungen, Materialien und Leistungen für Bau und Montage, Nebenkosten für Reisen, Versicherungen und Steuern detailliert kalkuliert. Schließlich werden auch die zur Abwicklung notwendigen Eigen- und Fremdleistungen geschätzt. Diese werden an Hand von Kostensätzen bewertet und in die Kalkulation eingebracht. Die Vorgaben aus der Startkalkulation bilden die Soll-Werte für alle erforderlichen Lieferungen und Leistungen. Planerlös - Kosten Lieferungen Apparate, Behälter, Kanäle Maschinen Package Units Rohrleitungen Elektrotechnik Instrumentierung etc. Bauarbeiten Stahlbau Montage Nebenkosten Transport Verpackung Reisekosten Versicherungen etc. Leistungen Paketbasis - Risikovorsorge - Leistungen (stundenbasiert) +/- Finanzergebnis = Projektergebnis

Abb. 114: Vereinfachte Kalkulationsstruktur Die Projektergebnisse fließen in die Deckungsbeitragsrechnung ein (vgl. Abb. 115). Eine verursachungsgerechte Zurechnung der Kosten zu Aufträgen erfolgt nur für die variablen Kosten. Die Fixkosten werden den einzelnen Kostenträgern wie Auftrag, Business Line und Gesellschaft zugewiesen (vgl. Abb. 115).

139

Projektkostenrechnung

3 Operatives Projektcontrolling Planerlös (Auftragswert) - Auftragseinzelkosten = Bruttoertrag (Summe der Projektergebnisse)

Unternehmensrechnung

- Kosten für technische/kaufmännische Abwicklung = Deckungsbeitrag I - Kosten der Business Line (Overheadkosten) = Deckungsbeitrag II - Kosten der Gesellschaft (Overheadkosten) = Ergebnis

Abb. 115: Stufen der Deckungsbeitragsrechnung

Wie sollte man die Projektkosten

differenzieren?

Kosten werden pro Arbeitspaket geplant und über die verschiedenen Ebenen des Projektstrukturplans bis zu den Gesamtprojektkosten kumuliert (vgl. Abb. 116). Zur Überprüfung der Plausibilität ist es sinnvoll, die Kosten auch „von oben nach unten“ zu schätzen und die analytisch geplanten Kosten gegenüberzustellen. Eine Schlüsselung von Kosten, die durch mehrere Arbeitspakete gemeinsam verursacht sind, sollte vermieden werden. Man kann sonst nicht mehr erkennen, welche Kosten wegfallen, wenn ein Arbeitspaket gestrichen wird. Deshalb sind die auf jeder Verdichtungsstufe zusätzlich anfallenden Kosten separat auszuweisen. Ein Beispiel soll diesen Sachverhalt verdeutlichen: Für die Arbeitspakete A (15.000 € geplante Kosten) und B (25.000 € geplante Kosten) muss zusätzlich eine CAD-Software geleast werden. Die Kosten betragen 10.000 €. Bei herkömmlicher Verrechnung würden die 10.000 € entsprechend der Inanspruchnahme der Leasingsoftware durch die Arbeitspakete auf diese verteilt werden.

140

3.1 Operative Projektplanung 15000+130000

Gesamtprojekt

10000+40000

Teilaufgaben

Arbeitspakete

15000

5000+75000

25000

35000

40000

Materialkosten Personalkosten Kosten für externe Leistungen Sonstige Kosten

Abb. 116: Projektkostenplanung So entfielen z. B. zusätzlich 6.000 € auf A und 4.000 € auf B. Müsste man nun entscheiden, ob Arbeitspaket A bei einem externen Dienstleister für 19.000 € in Auftrag gegeben werden soll, ginge man von eigenen Gesamtkosten in Höhe von 21.000 € für A aus, die bei externer Leistungserbringung nicht anfielen. In Wirklichkeit würde jedoch die Leasinggebühr immer in voller Höhe zu bezahlen sein, so dass die Kosten bei externer Leistungsvergabe nur um 15.000 € reduziert werden könnten. Kalkulierte Kosten Kosten für 60 Prozent Nutzung des CAD-Systems Direkte Gesamtkosten

Falsche Rechnung 15.000 € 6.000 € 21.000 €

R Externes Angebot Gewinn/Verlust

19.000 € + 2.000 €

Realistische Rechnung 15.000 € 15.000 €

R 19.000 € - 4.000 €

Ebenfalls sinnvoll ist eine Trennung in leistungsunabhängige (fixe) und leistungsabhängige (variable) Kosten, um Auswirkungen einer

141


vom Kunden gewünschten Mehrleistung schnell abschätzen zu können. Vorteilhaft kann eine weitere Differenzierung der Kalkulation in Basisbudget und verschiedene Zusatzbudgets sein (siehe Abb. 117). 77 Budget-Übertragung

Budget für Änderungen des Auftragswerts

Kostenübertragung zwischen Arbeitspaketen (Leistungsverschiebung), z.B. Übergang von Eigenleistung auf Fremdleistung

Forderungen aufgrund von nachträglichen Leistungsveränderungen

Zusatz-Budget Vorgaben für sonstige ungeplante Änderungen, z.B. für Preissteigerungen

Basis-Budget Kosten laut Auftragskalkulation

Abb. 117: Zusammensetzung des aktuellen Gesamtbudgets Jedes Zusatzbudget kann separat kontrolliert und gesteuert werden. Bei Budgetüberschreitungen sind die Ursachen genauer feststellbar.

Wie kann der Projektleiter die Projektkosten selbst schätzen? Damit der Projektleiter die Zuverlässigkeit der Kalkulation frühzeitig erkennt, sollte er regelmäßig eigene Kostenschätzungen durchführen. Am besten ermittelt er für ein optimistisches, wahrscheinliches und pessimistisches Szenario die Eintrittswahrscheinlichkeit der Kosten. Auf dieser Grundlage kann er erkennen, ob das ursprüngliche Budget überschritten wird. Gegenmaßnahmen können rechtzeitig eingeleitet werden. Die Abb. 118 verdeutlicht die Vorgehensweise am Beispiel. Sie enthält die gewichtete Schätzung des Projektleiters, die Hochrechnung aufgrund des erreichten Leistungsfortschritts und der aufgelaufenen Istkosten sowie die kalkulierten Werte der Projektkosten zu verschiedenen Zeitpunkten.

77

142

Siepert, H., Projektcontrolling im Großanlagenbau, in: Männel, W. (Hrsg.), Handbuch Kostenrechnung, Wiesbaden 1992, S. 1003 f.


Wahrscheinlichkeit Optimistisch Kosten Gesamt Wahrscheinlichkeit WahrKosten scheinlich Gesamt Wahrscheinlichkeit Pessimistisch Kosten Gesamt Schätzung des Projektleiters

August September Oktober 30 % 20 % 5% 800 € 1.000 € 1.200 € 240 € 200 € 60 € 40 % 60 % 80 % 1.200 € 1.300 € 1.300 € 480 € 780 € 1.040 € 30 % 20 % 15 % 1.400 € 1.400 € 1.400 € 420 € 280 € 210 € 1.140 € 1.260 € 1.310 €

Leistungsfortschritt Kumulierter Istwert Kosten laut Hochrechnung

20 % 240 € 1.200 €

50 % 575 € 1.150 €

80 % 960 € 1.200 €

Kalkulierter Wert gesamt

1.100 €

1.100 €

1.100 €

Abb. 118: Kostenschätzung Die Werte der Schätzung und der Hochrechnung liegen von Anbeginn über der ursprünglichen Kalkulation. Bereits im ersten Monat August ist zu erkennen, dass der kalkulierte Wert nicht zu halten ist. Der ursprünglichen Kalkulation von 1.100 € stehen die Prognose aufgrund des Leistungsfortschritts und der bereits verbrauchten Kosten in Höhe von 1.200 € und die Schätzung des Projektleiters von 1.140 € gegenüber.

Wann ist eine Liquiditätsplanung nötig? Größere Projekte, die mit erheblichen Ausgaben verbunden sind, können die Liquidität eines Unternehmens beeinflussen. Deswegen sind schon bei der Planung die voraussichtlichen Zahlungsflüsse zu verdeutlichen. Bereits bei der Kostenplanung sollte man eine Differenzierung in ausgabenwirksame und ausgabenunwirksame Kosten vornehmen. Es muss frühzeitig klar sein, zu welchen Zeitpunkten große Beträge fällig werden. Sind die exakten Auszahlungen nicht bekannt, kann man durch pauschale Korrekturen der Kosten die tatsächlichen Zahlungsflüsse schätzen. In die Betrachtung der Zahlungsmittelabflüsse sollten Risiken, wie sie z. B. Konventionalstrafen darstellen, einbezogen werden. 143


Auch die Einzahlungen können vorherbestimmt werden. Bei Aufwandsprojekten erfolgen die Zahlungen des Kunden oft mit einem Zeitverzug zwischen 30 und 60 Tagen nach Anfall des Aufwands. Bei Festpreisprojekten regelt der Vertrag die Einzahlungen abhängig vom Leistungsfortschritt. Abb. 119 zeigt, wie durch Addition der Ein- und Auszahlungen der Liquiditätsverlauf ermittelt wird. 9000

Auszahlungen kumuliert

8000 7000 6000

EUR

5000 4000

Liquidität kumuliert

3000 2000

2400 2000

1000

1600

0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Zeit

11000

800 400 0 -400

10000

-800

Einzahlungen kumuliert

9000 8000 7000

EUR

1200

6000 5000 4000

-1200

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Zeit

-1600 -2000 -2400 -2800 -3200

Liquiditätsbedarf

3000 2000 1000 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Zeit

Abb. 119: Ermittlung der Liquidität Es ist darauf zu achten, dass das Maximum des Liquiditätsdefizits möglichst schon in der ersten Hälfte des Projektes unterschritten wird. Eine oft genutzte Kennzahl für die Einschätzung der Liquidität ist der Cash Flow. Er zeigt den Finanzmittelüberschuss eines Projektes und wird vereinfacht wie folgt ermittelt: Jahresüberschuss + Abschreibungen + Rückstellungen = Cash Flow Tipp

Erkennt man, dass es im Laufe des Projektes zu Zahlungsschwierigkeiten kommt, können Vorgänge mit genügend Puffer, die hohe Auszahlungen verursachen, so verschoben werden, dass die „finanzielle Kapazität“ nicht überschritten wird. Der Verlauf der Liquidität bestimmt die Höhe der Finanzierungskosten. Sie sind als weitere Kostenart im Projekt-Budget zu berücksichtigen. In Entwicklungsprojekten bietet sich eine Gesamtbetrachtung des Liquiditätsverlaufs bis zum Ende des Lebenszyklus mit Hilfe der Break-Even-Analyse an (vgl. Abb. 120).

144


Auszahlungen, Einzahlungen

Zeit Markteintritt

Liquiditätsausgleich

Marktaustritt

Liquiditätsbedarf (Finanzierungszeitraum)

Abb. 120: Liquiditätsverlauf in einem Entwicklungsprojekt Bei der Outokumpu Technology GmbH erstellt das Projektcontrolling für jeden in der Abwicklung befindlichen Auftrag mit einem Auftragswert über eine Mio. € eine Cash Flow-Planung, die monatlich aktualisiert wird (vgl. Abb. 121). Mit Hilfe einer selbst entwickelten Software werden alle Zahlungsströme, die das entsprechende Projekt betreffen, geplant und verfolgt. Die Liquiditätskontrolle der Großprojekte liefert einen wesentlichen Beitrag zur Liquiditätssteuerung der Gesellschaft. Innerhalb der Planung werden jeweils die Kosten entsprechend der Kalkulationsstruktur aufgeführt (vgl. Abb. 114). Der Zeitraum der Fälligkeit der Kosten jedes Gewerks wird ebenso angegeben wie die Verteilung der Kosten in diesem Zeitraum auf Basis des Abwicklungsterminplans. Auf diese Weise wird für jede Gruppe eine charakteristische Kostenkurve ermittelt, die in Abhängigkeit der erfahrungsgemäß typischen Verteilung progressiv, degressiv oder normalverteilt verlaufen kann. Durch das Überlagern aller Kostenkurven ergeben sich für Startkalkulation, Vorgabe und Erwartung Kostenverläufe, die Auskunft über zukünftige Zahlungsausgänge geben. Für den Fall, dass große Auftragspakete an einen oder mehrere Unterlieferanten gehen, werden die dafür fälligen Kosten manuell geplant. Die Vorgehensweise mit statistischen Verteilungen aus den Erfahrungen abgewickelter Aufträge folgt einem Kompromiss zwischen erforderlicher Genauigkeit und dem notwendigen Arbeitsaufwand.

145


Zahlungsströme Zahlungseingänge Zahlungsausgänge

Soll

Ist Soll-Ist- und Soll-Erwartet-Vergleich

Anpassung der Cash-Flow-Planung Tabellarische Darstellung

Liquiditätsanalyse

Zinsermittlung Grafische Darstellung

Abb. 121: Ablauf der Cash Flow-Planung In weiteren Arbeitsschritten werden alle monatlich angefallenen Zahlungsströme registriert. D. h., sowohl die eingegangenen Kundenzahlungen wie auch die getätigten Auszahlungen für das betroffene Projekt werden für den Berichtsmonat erfasst und im Zeitverlauf als kumulierte Werte dargestellt. Auf Basis der Istwerte extrapoliert das System den zukünftigen Verlauf über die Restabwicklungsdauer bis zu den endgültigen Gesamtwerten der einzelnen Kostengruppen. Die Liquiditätsanalyse für die einzelnen Monate erlaubt dementsprechend eine Über- oder insbesondere Unterdeckung der Auftragskosten zu identifizieren. Darüber hinaus wird mit kalkulatorischen Zinssätzen ein monatliches und ein kumuliertes Finanzergebnis ermittelt. In grafischer (vgl. Abb. 122) und in tabellarischer Form folgt eine Gegenüberstellung der Planwerte aus der Startkalkulation, der neuen Vorgabe und der erwarteten Zahlungen sowie der tatsächlich geleisteten Zahlungen. Die Systematik erlaubt also sowohl einen Soll-Ist-Vergleich für die vergangenen Monate wie auch den SollErwartet-Vergleich für die kommenden Monate.

146


Abb. 122: Grafische Darstellung der Cash Flow-Analyse

147


Wie werden die Projekterlöse und der -gewinn geplant? Für den Ausweis der Projekterlöse gibt es zwei Verfahren: •

•

Nach der Completed Contract-Methode werden die Erlöse erst realisiert, wenn die Leistung gemäß den vertraglichen Vereinbarungen erbracht wurde. Dauert ein Projekt vier Jahre, wird erst nach dem vierten Jahr der Gewinn ausgewiesen. Dies führt zu einer hohen Ergebnissicherheit, allerdings ist eine periodengerechte Darstellung der Leistungsfähigkeit des Unternehmens nicht gewährleistet. Die Percentage of Completion-Methode weist Erlöse und Gewinne entsprechend dem Leistungsfortschritt aus. Damit ist der periodengerechte Ausweis der Gewinne möglich. Allerdings führt das Verfahren aufgrund der Schätzung des Leistungsfortschritts zu unsicheren Ergebnissen. Die Percentage of Completion-Methode wird vor allem im Rahmen der Rechnungslegungsvorschriften von IFRS und US-GAAP78 angewandt.

Um starke Schwankungen beim Ausweis der Ergebnisse zu vermeiden, ist im Regelfall die Percentage of Completion-Methode zu wählen. Sie stellt hohe Ansprüche an die Projektkosten- und Projekterlösrechnung. Außerdem muss der Leistungsstand im Projekt bekannt sein (Methoden zur Bestimmung des Projektstatus werden in Abschnitt 3.2.2 beschrieben). Nach deutschem Recht müssen außerdem einige Bedingungen erfüllt sein: • • • •

Das Projekt kann in sinnvolle Teilabschnitte gegliedert werden. Die anteiligen Gewinne für die Teilabschnitte können zuverlässig ermittelt werden. Es ist schnell feststellbar, wenn Verluste drohen. Die Nichtanwendung der Methode führt zu einer Beeinträchtigung des Einblicks in die Ertragslage. Das ist regelmäßig bei Projekten mit einer Dauer von mehr als zwei Jahren der Fall.

Nicht anwendbar ist die Percentage of Completion-Methode bei Projekten mit Risiken außerhalb des normalen Geschäftsrisikos.

78

148

IFRS: International Financial Reporting Standards GAAP: General Accounted Accepted Principles


Die Outokumpu Technology GmbH plant und verfolgt entsprechend der Bilanzierungsregelungen der IFRS die Fertigstellungsgrade von Kundenaufträgen ab einem Auftragswert von einer Million €. Zur Ermittlung des Leistungsstands (Percentage of Completion) wird aus Gründen der Praktikabilität die Methode der angefallenen Kosten angewendet, d.h. es wird ein Prozentsatz ermittelt, der das Verhältnis zwischen gebuchten und geplanten Kosten wiedergibt. Die Durchführung der Percentage of Completion-Planung erfolgt mit Hilfe einer Excel-basierten Eigenentwicklung, die an das zuvor dargestellte Prinzip der Cash Flow-Analyse angelehnt ist (vgl. Abb. 121). Wiederum wird eine Kosten differenziert für Gewerke, Eigenleistungen und Arbeitspaketvergaben geplant. Im Gegensatz zur Cash Flow-Analyse erfolgt die Bewertung der Eigenleistung lediglich in Höhe eines Planaktivierungssatzes und nicht in Höhe des Vollkostensatzes. Die geplanten Gesamtkosten werden auf die Monate verteilt. Grundlage dafür sind Erfahrungen aus abgeschlossenen Projekten. Die kumulierten Istkosten werden der Summe aus bereits realisierten Istkosten und bis zum Projektende geplanten Kosten gegenübergestellt. Auf diese Weise kann der Projektfortschritt bis zur aktuellen Periode ermittelt und für die zukünftigen Perioden mit ausreichender Genauigkeit extrapoliert werden, so dass für die periodengerechte Planung des Unternehmensergebnisses wichtige Daten geliefert werden können.

Wie erfolgt die Integration der Projekterlöse und -kosten? Alle Ergebnis- und Finanzinformationen aus der Projekttätigkeit und der Nichtprojekttätigkeit müssen in einem in sich konsistenten Gesamtsystem einer integrierten Unternehmensplanung und -analyse zusammengeführt werden. Für das Berichtswesen muss es möglich sein, die Daten in unterschiedlichen Verdichtungen zu zeigen. Hilfreich dafür sind Führungsinformationssysteme (vgl. Abschnitt 4.2). Abb. 123 verdeutlicht, dass der Erfolg und die Liquidität für jedes einzelne Projekt über alle Perioden der gesamten Projektlaufzeit erkennbar sein müssen. Für die Unternehmensrechnung müssen jedoch die Kosten, Auszahlungen und Erlöse für das Gesamtprojekt anteilsmäßig auf die jeweiligen Geschäftsjahre verteilt werden.

149


Durch die stufenweise Verdichtung der Projektdaten des betrachteten Geschäftsjahres über die Projekthierarchie gelangt man zum Projektgesamtergebnis des Geschäftsjahres. Es wird ergänzt um die Kosten und Erlöse aus der Nichtprojekttätigkeit. Damit ist eine Gesamtbetrachtung des Unternehmens bezüglich des internen Ergebnisses, des externen Erfolgs, der Bilanz und Finanzrechnung möglich. Die Analyse des Ergebnisses über alle Verdichtungsstufen hinweg kann aussagekräftige Informationen für die Projektsteuerung liefern. Bilanz Interne Ergebnisrechnung

Gewinn- und Verlustrechnung

Finanzrechnung

P

Erfolg/Liquidität projektübergreifend (Projektgruppe I-II) periodenbezogen (Periode 1)

Erfolg/Liquidität projektbezogen (Projekte 1- 4) periodenbezogen (Periode 1)

Erfolg/Liquidität P11 projektbezogen (Projekte 1- 4) periodenübergreifend (Periode 1-3)

Leistungen

PG I

Produkte

PG II

Kostenstellen

P11

+

P12

P21

P12

+ P22

Projekttätigkeit

P13

P13

P14

P14

+ P24 + P34 Nichtprojekttätigkeit

Abb. 123: Integration der Daten aus Projekttätigkeit und Nichtprojekttätigkeit in die Unternehmensrechnung Bei der MIS AG sind die Projektdaten mit der Unternehmensrechnung integriert. Verändert ein Anwender z. B. die Projektmaterialkosten, werden auch die Ergebnisrechnung des betroffenen Bereiches sowie die Gewinn- und Verlustrechnung (GuV) des Unternehmens aktualisiert. Ebenso wie die Ergebnisdaten werden auch die Finanzinformationen, die auf detaillierter Projekt- oder Kostenstellenebene erfasst wurden, berücksichtigt. Der Cash Flow wird automatisch ermittelt.

150


3.1.10 Risikomanagement und -controlling Hamel und Prahalad belegen, dass sich das Management in weniger als drei Prozent seiner verfügbaren Zeit mit Risikomanagement beschäftigt.79 Risikobehafteten Vorhaben wird oft zu wenig Aufmerksamkeit geschenkt. Während das gesamte Management in endlosen Sitzungen über das nächste Jahresbudget diskutiert, wird die Entscheidung über die Einführung einer komplexen Software mit einem Investitionsvolumen von mehreren Millionen € in wenigen Wochen getroffen. Die große Bedeutung des Risikomanagements für Unternehmen wird auch durch diverse gesetzliche Vorschriften belegt, die ein Risikomanagementsystem fordern. Bereits 1998 wurde das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) verabschiedet. Es verpflichtet börsennotierte Aktiengesellschaften, ein Risikomanagementsystem einzurichten, um Entwicklungen, die den Fortbestand des Unternehmens gefährden, möglichst frühzeitig zu erkennen. Das Management muss also bei seinen Entscheidungen die Unternehmensrisiken mit der nötigen Sorgfalt berücksichtigen. Mittlerweile gibt es weitere Vorschriften (Basel II, Sarbanes-OxleyAct, Risikoberichterstattungspflicht nach HGB, Prüfungsstandard zur Risikofrüherkennung des Instituts der Deutschen Wirtschaftsprüfer), die von den Unternehmen ein Risikomanagement verlangen. Projekte sind schon definitionsgemäß mit hohen Risiken behaftet (vgl. S. 3). Deswegen ist sorgfältiges und systematisches Risikomanagement im Projektgeschäft besonders wichtig. Das Projektcontrolling sollte die strategische Projektauswahl unter Risikogesichtspunkten unterstützen und zusätzlich dafür Sorge tragen, dass die wichtigen Risiken vor Beginn eines jeden Projektes analysiert und während der Projekabwicklung laufend beobachtet werden.

,nteUnet

www.risknet.de

3UoMeNtFontUoOOeU

XnteUVtt]t

Die elementaren Bausteine eines Risikomanagements sind in Abb. 124 aufgeführt und werden im Folgenden beschrieben.

79 Hamel, G., Prahalad, C., Wettlauf um die Zukunft, Berlin 1997.

151

3 Operatives Projektcontrolling Risikokultur Risikomanagementorganisation Identifikation von Risiken Bewertung der Risiken Maßnahmen Laufende Überwachung Risikomanagementorganisation Risikokultur

Abb. 124: Bausteine des Risikomanagements und -controllings

Was beinhaltet die Risikokultur? Die Einstellung des Managements und der Mitarbeiter gegenüber Risiken ist die Basis eines wirksamen Risikomanagements. Vorteilhaft ist es, wenn die Unternehmensleitung risikopolitische Grundsätze formuliert und sich auch selbst danach richtet. Risiken müssen bewusst wahrgenommen und kommuniziert werden. Keinesfalls dürfen negative Konsequenzen für denjenigen entstehen, der auf Risiken hinweist. Risikomanagement darf aber keinesfalls zu einem Übermaß an Kontrollen führen. Projektleiter sollten weder risikoignorant noch zu risikopenibel sein.

Wer ist für Risikomanagement zuständig (Aufbauorganisation)? In größeren Unternehmen existiert oft eine eigene Stabsabteilung für Risikomanagement. Gibt es keinen zentralen Risikomanager, sollte das Controlling an der Konzeption, Einführung und Weiterentwicklung eines Risikomanagementsystems für Projekte mitwirken. Das Projektcontrolling stellt bereits bei der Auswahl der Projekte die Berücksichtigung von Risikoaspekten sicher. Es achtet außerdem im Rahmen des operativen Risikomanagements darauf, dass der Projektleiter auf der Grundlage des etablierten Risikomanagementsystems die Risiken für sein konkretes Projekt analysiert.

152


Wie sieht der Risikomanagementprozess aus (Ablauforganisation)? Der Risikomanagementprozess beinhaltet mindestens folgende Schritte: 1. Risiken identifizieren, 2. Risiken bewerten, 3. Maßnahmen planen, 4. Risiken überwachen. 1. Risiken identifizieren „Wir unterstellen folgende Entwicklung“, lautet eine Standardaussage. Nach Risiken wird in diesem Fall nicht konsequent gesucht. Oft findet man auch eine gewisse Betriebsblindheit. Dabei wäre es notwendig, systematisch nach Risiken zu fahnden und dabei in unterschiedlichen Szenarien zu denken. Vor einer Risikoanalyse müssen die Projektziele deutlich definiert werden. Um Risiken zu erkennen, ist es außerdem sehr hilfreich, wenn man auf Erkenntnisse aus früheren Projekten zurückgreifen kann. Dies erfordert eine systematische Sicherung der Projekterfahrungen. Die gewonnenen Erfahrungen können in Checklisten einfließen. Sie beinhalten die wichtigsten Risikofaktoren übersichtlich und nach Risikogruppen gegliedert. Die folgende Aufstellung enthält einige Fragen aus einer solchen Checkliste: Technische Risiken • Sind alle Komponenten technisch kompatibel? • Besitzen wir die notwendige Ausrüstung? • Haben wir bereits Erfahrung mit der Entwicklungsumgebung? Betriebswirtschaftliche Risiken • Ist die Bonität des Kunden in Ordnung? • Gibt es Währungsrisiken? • Ist die Liquidität gesichert? • Gibt es genügend Puffer in der Kalkulation? Personelle Risiken • Besitzen die Mitarbeiter die notwendige Qualifikation? • Haben wir genügend Mitarbeiter zur Verfügung? • Können wir auf externe Mitarbeiter zurückgreifen? Umwelt-Risiken • Steht das Management hinter dem Vorhaben? • Gibt es Einwände des Betriebsrates? • Gibt es wichtige Mitarbeiter, die gegen das geplante Projekt sind?

153

3 Operatives Projektcontrolling •

Sind nationale Mentalitäten zu berücksichtigen?

Zulieferungs-Risiken • Haben wir zuverlässige Lieferanten? • Können wir kurzfristig auf andere Lieferanten ausweichen? Zeit-Risiken • Haben wir genügend Puffer eingeplant? • Könnte es nicht beeinflussbare Einwirkungen geben (schlechtes Wetter, Streik)?

Wenn die Wahrnehmung neuer Risiken schwierig ist, hilft es auch, die Projektstruktur zu verfeinern. In Abb. 125 wurde die Phase der Detaillierung und Realisierung in einzelne Prozessschritte unterteilt. Bereits bei dieser groben Gliederung erkennt man, dass bei der Durchführung der Tests Qualitätsrisiken drohen und auch die Abbildung der Prozesse wegen der Abhängigkeit von externen Beratern kritisch ist.

Organisation/ Konzeption

Detaillierung/ Realisierung

Test durchführen

Qualitätsrisiken

Schnittstellen realisieren

Produktionsvorbereitung

Prozesse abbilden

Produktivbetrieb

Grunddaten abbilden

Abhängigkeit von externen Spezialisten

Abb. 125: Detaillierung der Projektstruktur Die gefundenen Risiken sollten möglichst ausführlich verbal beschreiben werden, um die folgende Bewertung vornehmen zu können. 2. Risiken bewerten Die Projektverantwortlichen sehen das Risiko oft unscharf. Ihnen fehlt das richtige Risikomaß. Typisch ist der Ausspruch: „Da könnte was auf uns zukommen“. Eine nähere Beschreibung erfolgt nicht. Der Controller hat in dieser Situation die Aufgabe, eine hinreichend objektive Risikobewertung zu gewährleisten.

154


Grundlage der Risikobewertung ist ein Katalog der identifizierten Risiken, der um die Ursachen, die Häufigkeit des Auftretens und eine Einschätzung der Auswirkungen ohne Risikovorsorge ergänzt werden muss. Risiko

Ursache

fehlerhafte Codierung

unzureichende Qualifikation der Mitarbeiter

Eintrittswahrscheinlichkeit Auswirkung hoch

kritische Terminüberschreitung

Der Risikokatalog sollte in einem weiteren Schritt um die bereits vorhandenen Maßnahmen zur Risikominimierung ergänzt werden. Alle Risiken aus dem Risikokatalog sind nach ihrer Eintrittswahrscheinlichkeit und den Auswirkungen zu klassifizieren. Dabei werden in der Projektpraxis die exakten mathematisch-statistischen Methoden wie Value at Risk („mit einer Wahrscheinlichkeit von 95 Prozent werden die Kosten nicht höher als 1 Mio. € sein“) kaum Anwendung finden. Meist genügen gröbere Verfahren. Häufig anzutreffen ist eine Punktbewertung der Auswirkungen und der Eintrittswahrscheinlichkeit eines Risikos. Die Visualisierung erfolgt üblicherweise mit der Risk Map (vgl. Abb. 126). Aus der Risk Map lassen sich hohe, mittlere und geringe Risiken ablesen. Eintrittswahrscheinlichkeit

= Risiko = Restrisiko

hoch mittel

hoch

hoch

gering

mittel

100.000 €

gering

gering

mittel

hoch möglich

gering gering

mäßig

hoch

Auswirkung

Abb. 126: Klassifizierung von Projektrisiken in einer Risk Map Das in Abb. 126 eingetragene Risiko hat eine hohe Auswirkung auf das Projekt, wenn es eintritt. Zudem wurde eine mittlere Eintrittswahrscheinlichkeit geschätzt. Dies ergibt insgesamt noch ein hohes Risiko. 155


Für die Risikobewertung von Projekten der Regierung von Australien wird folgendes Verfahren angewandt (vgl. Abb. 127): 80 5

5 Auswirkung bei Überschreitung der Projekt muss abgebrochen werden Kostenziele Geschätzte Gesamtkosten geschätzte Kosten > 10 Mio $ Auswirkung bei Überschreitung der keine Verlängerung möglich Terminziele Projektdauer Projektlaufzeit > 24 Monate Auswirkung bei Überschreitung der das Geschäft des Kunden muss Qualitätsziele eingestellt werden

Eintrittswahrscheinlichkeit 5 Art der Festlegung der Kostenziele das Budget ist offensichtlich unzureichend Art der Festlegung der Terminziele es gibt keinen klaren Terminplan Art der Festlegung der Qualitätsziele

Qualitätsanforderungen sind nicht bekannt

Bewertung 4 3 2

... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

1 zusätzliche Mittel verfügbar geschätzte Kosten < 100.000 $ Fertigstellungstermin nicht wichtig Projektlaufzeit < 6 Monate keine erkennbare Wirkung

4

Auswirkungen

Auswirkungen

3

2 Bewertung 4 3 2

... ... ... ... ... ... ... ... ...

1 das Budget wurde aufgrund ähnlicher Projekte festgelegt der Terminplan wurde aufgrund ähnlicher Projekte festgelegt Qualitätsanforderungen wurden genau festgelegt

1

1

2

3

4

5

Eintrittswahrscheinlichkeit Kosten

Termine

Qualität

Abb. 127: Praxisbeispiel für die Projektrisikobewertung • •

• •

80

156

Die Eintrittswahrscheinlichkeit und die Auswirkungen von Kosten-, Termin- und Qualitätsrisiken werden anhand einer Skala von eins bis fünf bewertet. Die jeweiligen Punkte für Eintrittswahrscheinlichkeit und Auswirkung werden getrennt nach Kosten-, Termin- und Qualitätsrisiken multipliziert. Es gilt folgende Bewertung: o geringes Risiko: eins bis fünf Punkte, o mittleres Risiko: sechs bis zehn Punkte, o signifikantes Risiko: elf bis 15 Punkte, o hohes Risiko: 16 bis 25 Punkte. Das Gesamtrisiko ergibt sich aus der höchsten Punktzahl von Kosten-, Termin- und Qualitätsrisiko. Im Beispiel der Abb. 127 liegt ein mittleres Gesamtrisiko vor. Für geringe und mittlere Risiken werden keine besonderen Maßnahmen getroffen.

Baccarini, D., Archer, R., The risk ranking of projects: a methodology, International Journal of Project Management, (2001) 19, S. 139-145.


3. Maßnahmen planen Geringe Risiken und manche Risiken mittlerer Stärke wird man im Regelfall akzeptieren, da sich der Aufwand für Maßnahmen nicht lohnt. Für ausgewählte mittlere, aber vor allem für Risiken mit gravierenden Auswirkungen und einer hohen Eintrittswahrscheinlichkeit sind vorbeugende Maßnahmen vorzubereiten, damit das Risiko vermindert oder sogar vermieden wird (vgl. Abb. 128). Maßnahmen

vorbeugen

akzeptieren

Risikokategorien geringe Risiken

vermindern vermeiden

mittlere Risiken

übertragen

hohe Risiken

korrigieren

Abb. 128: Möglichkeiten der Risikosteuerung Nicht zu vergessen sind die verschiedenen Möglichkeiten der Risikoübertragung. Risiken können z. B. durch vertragliche Vereinbarungen an den Auftraggeber zurückgegeben werden. Abb. 129 zeigt weitere Möglichkeiten der Verminderung, Vermeidung und Übertragung von Risiken. Risiken übertragen An Dritte weitergeben

Risiken vermindern/ vermeiden Puffer im Terminund Ressourcenplan Risikozuschlag in der Kalkulation

An den Auftraggeber zurückgeben Lieferanten, Unterauftragnehmer

Versicherungen

Einsatz qualifizierter Mitarbeiter Zusätzliche Reviews Qualifizierungsmaßnahmen

Abb. 129: Möglichkeiten der Risikovorbeugung81

81 Rinza, P., Projektmanagement, Düsseldorf 1985, S. 67.

157


Für Risiken mit schwerwiegenden Auswirkungen sind auch Korrektivmaßnahmen zu planen. Sie greifen dann, wenn trotz aller Vorkehrungen das Risiko eintritt. Korrektivmaßnahmen sind in aller Regel sehr kostenintensiv, deshalb wird man sie nur in Ausnahmefällen erarbeiten. Ein bekanntes Beispiel, bei dem viele Unternehmen aufwändige Korrektivmaßnahmen planten, war die Jahr-2000Umstellung. Maßnahmen verursachen in der Regel einen Mehraufwand für das Projekt. Das Management muss deshalb die kostenintensiven Maßnahmen genehmigen. Grundlage dafür ist ein Risikomanagementplan wie in Abb. 130, der zeigt, ob sich eine Maßnahme auch lohnt. Dort werden Risikokosten von 50.000 € ausgewiesen (100.000 € x 50 %). Die Maßnahmen in Form von Schulungen und des Einsatzes von externen Spezialisten würden 15.000 € kosten. Dadurch könnten die Risikokosten auf 20.000 € reduziert werden (100.000 € x 20 %). Die Maßnahme würde sich also lohnen. Risikobewertung vor Risikobewertung nach Maßnahmen der Maßnahme der Maßnahme AusWahrschein- RisikoWahrschein- RisikoUrsache Maßnahme Kosten wirkung lichkeit kosten lichkeit kosten 100.000 € Umfangreiche Geringe 15.000 € 20% 20.000 € 50% 50.000 € Schulung, exKonventionalQualifikation terne Spezialisten strafe

Risikoidentifikation Risiko Fehlerhafte Codierung

Abb. 130: Risikomanagementplan 4. Risiken überwachen Die schwerwiegenden Einzelrisiken sollten kontinuierlich überwacht werden. Dafür kann der Statusbericht um eine Grafik wie in Abb. 131 ergänzt werden. 9

Risikokennzahl

8 7 6 5 4 3 2 1 0 Mrz

Apr

Mai

Jun

Datum

Abb. 131: Überwachung von Einzelrisiken

158

Jul

Aug

Sep


Die Risikokennzahl in Abb. 131 wird aus der Riskmap (vgl. Abb. 126) entnommen. Bei hoher Auswirkung und hoher Eintrittswahrscheinlichkeit beträgt die Risikokennzahl z.B. neun. Zusätzlich sollte das Gesamtrisiko eines Projektes ausgewiesen werden. Abb. 132 verdeutlicht eine mögliche Vorgehensweise für die Berechnung. Risiko 1 Risiko 2 Risiko 3 Risiko 4 Risiko 5 Risiko 6 Risiko 7 Risiko 8 Risiko 9 Risiko 10 Gesamt

W

A

2 3 1 2 2 1 3 2 2 1

3 2 1 2 1 1 3 3 1 1

Ergebnis 6 6 1 4 2 1 9 6 2 1 38

Gesamtrisiko: 38/10 = 3,8 (max. 9) W: Eintrittswahrscheinlichkeit des Risikos A: Auswirkung des Risikos

Abb. 132: Gesamtrisiko eines Projektes Die zehn Einzelrisiken des Projektes werden ermittelt, addiert und aus dem Ergebnis der Mittelwert gebildet. Daraus resultiert ein Risikowert von 3,8. Das Gesamtrisiko könnte maximal bei neun liegen. Das Projekt besitzt also ein mittleres Risiko. Die Methode kann man verfeinern. Z. B. könnte eine zusätzliche Gewichtung für die hohen und mittleren Risiken eingeführt werden. Dadurch würden hohe Risiken besonders hervorgehoben. Zudem könnten wie im IT-Bereich der RWE AG Risikoklassen gebildet und das Gesamtrisiko separat pro Risikoklasse ausgewiesen werden (vgl. Abb. 133).

159

3 Operatives Projektcontrolling Projektanforderungen ϭϬ ϴ

Umfeld und Markt

ϲ

Projektteam

ϰ Ϯ Ϭ

Externe Projektpartner

Kunde

Kalkulation

Abb. 133: Differenzierung des Gesamtrisiko nach Risikoklassen

Wie kann die Risikoanalyse systematisch durchgeführt werden? Die Analyse des Risikos eines Projektes bzw. einzelner Arbeitspakete kann systematisch in folgenden Schritten ablaufen: • • • • • • • •

Festlegung der einzelnen Planungsschritte, Aufzeigen kritischer Bereiche, Erkennen potentieller Probleme (Risiken), Bestimmung von Auswirkung und Wahrscheinlichkeit der Risiken, Ermittlung möglicher Ursachen, Planung vorbeugender Maßnahmen, Erarbeitung von Korrektiv-Maßnahmen für besonders kritische Risiken, Einrichten eines Warnsystems (Auslöser der KorrektivMaßnahmen).

Mittels der drei Formblätter in Abb. 134 ist eine systematische Risikoanalyse mit vertretbarem Aufwand zu gewährleisten.

160

Nummer

Nummer

Welche Aufgaben werden von wem bis wann erledigt?

Planungsschritte

Was könnte schiefgehen? Wie hoch ist die Eintrittswahrscheinlichkeit W? Wie gravierend sind die Auswirkungen A? (1= gering 2 = mittel 3 = hoch)

Welche Aufgaben sind kritisch? Wo wird etwas Neues probiert? Wo führen Fehlschläge zu bedeutsamen Konsequenzen?

Welche Maßnahmen könnten die Ursache beseitigen? Wie könnte man vorbeugen? Wer übernimmt bis wann die Verantwortung?

Potentielle Probleme

W

Auslöser

Vorbeugende Maßnahmen

Verantwortung

Seite 3

W A

Seite 1

Verantwortung

Seite 2

Anmerkungen

Kritische Bereiche

Welche Ursachen könnte das Problem haben? Wie hoch ist die Eintrittswahrscheinlichkeit W?

Mögliche Ursachen

Welche Konsequenzen hat es, wenn das Problem trotzdem eintritt? Wie kann man den Schaden gering halten? Wieviel kostet die Korrektiv-Maßnahme? Wer übernimmt die Verantwortung für Auslösung der Maßnahme?

Korrektiv-Maßnahmen


Abb. 134: Formblätter für eine systematische Risikoanalyse

161

Nummer


Die Risikoanalyse ist bei Lufthansa Systems-Projekten Standard und deswegen in jedem Fall durchzuführen. Mit der Risikoanalyse beurteilt der Angebots- oder Projektmanager vordefinierte und gewichtete Risikofaktoren. Ergebnis ist die Risikoklasse, bei der nach „hoch“, „mittel“ und „niedrig“ unterschieden wird. Ein hohes Projektrisiko ist Anlass für den Vertrieb und die verantwortliche Profit-Center-Leitung, folgende Aspekte zu berücksichtigen: • • • •

Vertragsform: Festpreis/Werkvertrag statt Aufwandsvertrag, Risikoaufschlag bei der Preisgestaltung, Durchführung einer Wirtschaftlichkeitsanalyse, sorgfältige Angebotsschätzung.

Die Risikoanalyse liegt in der Verantwortung der Angebots- oder Projektmanager. Für die Beurteilung der einzelnen Risikofaktoren kann der Vertrieb oder die verantwortliche Profit-Center-Leitung hinzugezogen werden. Für die Risikoanalyse wird das selbst erstellte Excel-Sheet „ProRisk“ verwendet (vgl. Abb. 135). Alle Felder, die ausgefüllt werden sollen, sind dunkelgrau gekennzeichnet. Alle anderen Felder sind geschützt und können nicht geändert werden. 1. Zunächst sind in einer Kopfzeile die Angebotsnummer und der Angebotsname zur Identifikation einzutragen. 2. Die Gewichtung der einzelnen Risikofaktoren wird fest vorgegeben und kann vom Anwender nicht geändert werden. Somit wird die Vergleichbarkeit der Risikoanalysen von verschiedenen Angeboten gewährleistet. Alle Risikofaktoren sind bestimmten Risikobereichen zugeordnet. Diese Risikobereiche sind wie folgt gewichtet: Umfeld des Kunden 25 Lösung von Lufthansa Systems 25 Projektorganisation 20 Projektteam Lufthansa Systems (intern und extern) 15 Abhängigkeiten 15 Jeder einzelne Risikofaktor dieser Risikobereiche muss bewertet werden. 3. Zur Beurteilung des Risikos muss der Anwender je Risikofaktor das Risiko als „Risiko niedrig“ – „Risiko mittel“ – „Risiko hoch“ bewerten. Zur besseren Beurteilung des Risikos steht für jeden Risikofaktor eine Einteilungshilfe, an der sich der Anwen162


der orientieren kann, zur Verfügung. Je nach Bewertung in die Klassen „niedrig“ – „mittel“ – „hoch“ wird der Risikowert jedes Risikofaktors berechnet. Dazu wird die Gewichtung des Risikofaktors mit dem jeweiligen Risikowert multipliziert („Risiko niedrig“ entspricht dem Multiplikationsfaktor 1; „Risiko mittel“ entspricht dem Multiplikationsfaktor 2; „Risiko hoch“ entspricht dem Multiplikationsfaktor 3). Beispiel: Die Gewichtung des Risikofaktors „Einstellung des Kunden“ ist 5. Nimmt der Projektmanager an, dass der Kunde negativ gegenüber der Lufthansa Systems eingestellt ist, so bewertet er diesen Risikofaktor mit „Risiko hoch“. Daraus errechnet sich der Risikowert: 5 * 3 = 15. Das Ergebnis der Multiplikation wird in der Spalte „Risikowert“ angezeigt. Nimmt der Angebotsmanager an, dass der Kunde positiv eingestellt ist, so ergibt sich der Risikowert: 5 * 1 = 5. 4. Die Summe der Risikowerte aller Risikofaktoren ergibt den Gesamtrisikowert des Angebotes. Der Gesamtrisikowert wird besonders gekennzeichnet. Aufgrund dieses Gesamtrisikowertes werden das Risiko des Angebotes oder Projektes und die entsprechende Risikoklasse ermittelt. Folgende Risikoklassen sind vorgesehen: - Gesamtrisikowert < 100: - Gesamtrisikowert < 130: - Gesamtrisikowert < 150: - Gesamtrisikowert < 200: - Gesamtrisikowert < 220: - Gesamtrisikowert d 300: - Gesamtrisikowert > 300:

Das Formblatt ist nicht korrekt ausgefüllt. Das Angebot hat die Risikoklasse „niedrig“. Das Angebot hat die Risikoklasse „niedrig“ (Tendenz mittleres Risiko). Das Angebot hat die Risikoklasse „mittel“. Das Angebot hat die Risikoklasse „mittel“ (Tendenz hohes Risiko). Das Angebot hat die Risikoklasse „hoch“. Das Formblatt ist nicht korrekt ausgefüllt.

Ergibt sich ein Gesamtrisikowert zwischen 100 und 150, so wird das Risiko als niedrig eingeschätzt. Bei einem Gesamtrisikowert zwischen 151 und 220 wird das Risiko als mittel und bei einem 163


Gesamtrisikowert zwischen 221 und 300 als hoch beurteilt. Ergibt sich ein Gesamtrisikowert von 130 bis 150, so wird das Risiko des Projektes zwar als niedrig eingestuft, jedoch wird dem Projektmanager empfohlen, weitere Informationen einzuholen bzw. Details zu klären und die Risikobeurteilung zu wiederholen, da das Risiko gegen „mittel“ tendiert. Analoges gilt für den Bereich des Gesamtrisikowertes zwischen 200 und 220. 5. Der Projektmanager muss zur korrekten Beurteilung des Risikos alle Risikofaktoren berücksichtigen. Besitzen nicht alle Risikofaktoren eine Bewertung, so wird eine Fehlermeldung generiert, die darauf hinweist, dass alle Faktoren zu bewerten sind. 6. Bei Abschluss der Risikoanalyse hat der Projektmanager zusätzlich die Möglichkeit, Bemerkungen zur Beurteilung der Risikoklasse anzugeben. Er kann z. B. auch sein „Bauchgefühl“ zur Beurteilung des Risikos beschreiben.

164


Einstellung des Kunden, der Ansprechpartner, der Entscheider

5

...

Lösung von LSY

Leistungsumfang

5

Projektteam LSY (intern und extern)

2

5

Abhängigkeiten

...

x

10

4

Niedrig: Vorgehensmethode von LSY kann von Projektmitgliedern verwendet werden. Mittel: Projektmitglieder haben Erfahrung mit der zu verwendenden Vorgehensmethode. Hoch: Projektmitglieder haben keine Erfahrung mit der zu verwendenden Vorgehensmethode.

10

Niedrig: Ressourcenplan ist vollständig ausgearbeitet. Mittel: Die Verfügbarkeit der Ressourcen ist teilweise nicht sichergestellt. Hoch: Die Verfügbarkeit der Ressourcen ist nicht sichergestellt.

6

Niedrig: Projektleiter ist der Angebotsmanager. Mittel: Projektleiter ist nicht der Angebotsmanager, hat aber bereits ähnliche Projekte geleitet. Hoch: Projektleiter ist nicht der Angebotsmanager, hat noch keine Projektleitererfahrung mit ähnlichen Projekten.

10

Niedrig: Keine Lieferanten/Supportstellen involviert. Mittel: Eine oder mehrere Lieferanten/Supportstellen involviert. Hoch: Ein Lieferant, eine Supportstelle liefert eine erfolgskritische Sache (HW- oder SW-Produkt).

...

x

...

x

...

2

... Abhängigkeit von Lieferanten und Supportstellen (Produkte, Hardware, Sonstige, ..)

...

Niedrig: Klare, vollständige Beschreibung des Leistungsumfangs ist Bestandteil des Angebots. Mittel: Klare Beschreibung des Leistungsumfangs, aber nicht ausreichend dokumentiert. Hoch: Unklare, unvollständige Beschreibung des Leistungsumfangs.

...

... Person des Projektleiters

Vorbewertung – soll eine Hilfestellung zur Risikowert Beurteilung des Risikos geben Niedrig: Einstellung positiv ggü. LSY; Kunde hat Verständnis für LSY-Lösung. Mittel: 15 Einstellung unentschlossen und zögerlich; Kunde hat wenig Verständnis für LSY-Lösung. Hoch: Einstellung negativ/kritisch ggü. LSY; Kunde versteht die LSY-Lösung nicht.

...

... Staffing

x

...

...

VorgehensProjektorganisation methode

Risiko hoch

Umfeld des Kunden

Risiko mittel

Risikofaktor

Risiko niedrig

Bereich

Gewichtung

Kurzanleitung: Bitte die Angebotsnummer eintragen und jeden Risikofaktor in der entsprechenden Spalte beurteilen (niedrig, mittel, hoch). Die Spalte Vorbewertung kann als Hilfestellung bei der Beurteilung des Risikos dienen. Die auszufüllenden Felder sind grau markiert. Alle anderen Felder dürfen nicht verändert werden. Grundsätzlich sollte je Zeile (d.h. je Risikofaktor) ein Kreuz oder ein beliebiges Zeichen eingetragen werden. Werden je Zeile mehrere Kreuze eingetragen, so wird automatisch das größte Risiko angenommen. Sind alle Risikofaktoren beurteilt, dann wird der Eintrag „Bitte alle Risikofaktoren bewerten“ nicht mehr angezeigt.

...

x

... 5

x

...

...

...

Abb. 135: Auszug aus ProRisk

165


Das Risikomanagement der Outokumpu Technology GmbH erfasst die Problembereiche eines Projektes und stellt deren Auswirkungen auf die Kosten fest. Sie wird erstmalig in der Phase der Angebotskalkulation und in der Auftragsabwicklung regelmäßig durchgeführt. Der erste Schritt der Risikoanalyse besteht in der Identifikation aller Risiken, die im Projektverlauf auftreten können. Dies erfolgt mit Hilfe von Risikochecklisten und Erfahrungswerten. Die Risiken werden in Form von Fragen beschrieben, die mit „ja“ beantwortet werden, wenn die Ursache für ein Risiko nicht vorliegt. Wird die Frage hingegen mit einem „nein“ beantwortet, liegt eine Ursache vor, die zu einem potentiellen Risiko führen kann oder schon geführt hat. Die dritte Antwortmöglichkeit „irrelevant“ ist zu verwenden, wenn eine Frage für das entsprechende Projekt nicht relevant ist. Im Anschluss werden die Risiken den einzelnen Positionen der Angebotskalkulation zugeordnet. Um eine Bewertung des Risikos zu ermitteln, ist eine realistische Eintrittswahrscheinlichkeit anzunehmen. Multipliziert mit den kalkulierten Kosten der jeweiligen Position ergibt sich der Wert des jeweiligen Risikos, der in die Kalkulation mit einfließt. Zu Beginn eines Projektes existieren viele qualitative Risiken, d.h. Risiken, deren Kostenauswirkungen noch nicht absehbar sind. Diese nehmen im Projektverlauf mit zunehmendem Kenntnisstand ab. Zum einen können einige Risiken auf Grund ihrer Lage im Projekt nicht mehr eintreten. Zum anderen lassen sich bestimmte Risiken mit zunehmendem Kenntnisstand besser bewerten. Aus diesem Grund muss die Risikoanalyse regelmäßig überarbeitet werden, um die aktuelle Kostenerwartung zum Projektabschluss darzustellen. Aufgabe des Auftragscontrollings ist hier die Erfassung der aktualisierten Daten für die Ermittlung der Vorgabe und der Vorausschau (vgl. Abb. 136). Ein Vergleich mit den Ergebnissen des Vorberichts zeigt die eingetretenen Veränderungen der Einzelpositionen auf. Das System OPX2 unterstützt bei der Projektpriorisierung die Bewertung der Chancen und Risiken eines Projekts. Dazu müssen Kriterien im System hinterlegt und gewichtet worden sein. Man markiert jeweils die zutreffenden Kriterien. Die Bewertung des Kriteriums und die Kalkulation der Gesamtbewertung für den Projektantrag erfolgen automatisch auf Grundlage der hinterlegten Gewichtung.

166


Abb. 136: Verkürzte Darstellung einer Risiko-Analyse 167


3.2

Operative Projektkontrolle

3.2.1 Überblick INPUTINFORMATIONEN

Was? Geplante Projekte

Woher? Operative Projektplanung

AUFGABEN

Welche? Leistungskontrolle

Womit? Prognosen, Methoden der Leistungsmessung, Kennzahlen Time-at-Completion, TerminTrenddiagramm, Portfoliotechnik, Kennzahlen Cost-at-Completion, KostenTrenddiagramme, Earned Value Analyse, Portfoliotechnik, Kennzahlen Know-How-Datenbank, Kennzahlen Kennzahlen, Projektmanagementsoftware, Führungsinformationssysteme

Terminkontrolle

Kostenkontrolle

Erfahrungssicherung Berichtswesen

OUTPUTINFORMATIONEN

Was? Planabweichungen, Abweichungsursachen, Maßnahmen

Wohin? Strategische und operative Projektplanung

Abb. 137: Überblick über die operative Projektkontrolle Grundlage der Projektsteuerung und -kontrolle sind die Pläne der laufenden Projekte. Die Projektkontrolle beinhaltet folgende Aufgaben (vgl. Abb. 138): • • • •

168

Ermittlung der Istdaten, Gegenüberstellung der entsprechenden Plandaten, Untersuchung der aufgetretenen Abweichungen mit dem Ziel, deren Ursachen herauszufinden, und gegebenenfalls Planung und Einleitung von Gegenmaßnahmen.

3.2 Operative Projektkontrolle

Ergebnis der Projektsteuerung und -kontrolle sind Maßnahmen zur Beseitigung von Planabweichungen. Dies kann eine Anpassung der Pläne oder eine Einflussnahme auf die Istdaten bedeuten. Leistungen, Termine und Kosten sollten im Rahmen von Abweichungsanalysen immer zusammen betrachtet werden. Liegt z. B. eine Kostenüberschreitung vor, kann dies durch unwirtschaftliches Handeln bedingt sein. Genauso gut könnte der Grund aber in einer unplanmäßigen Mehrleistung liegen, oder es wurden teure Überstunden angeordnet, um die Projektdauer zu verkürzen.

Maßnahmen Ursachenanalyse Plan-Ist-Vergleich Istdaten Plandaten

Abb. 138: Elemente der Projektsteuerung und -kontrolle Für die effiziente Projektsteuerung und -kontrolle sind eine systematische Erfahrungssicherung und ein aussagefähiges Berichtswesen erforderlich.

Worauf sollte der Projektcontroller bei den Istdaten achten? Basis der Kontrolle ist neben einer sorgfältigen Planung eine regelmäßige, korrekte und zeitnahe Erfassung der Istdaten. Im Idealfall existiert ein zentrales System, in dem alle projektrelevanten Daten gespeichert sind. Besonders wichtige Daten sind die Rückmeldungen des geleisteten Aufwands. Die Projektmitarbeiter müssen die erbrachten Stunden täglich oder mindestens wöchentlich auf Projekte und Arbeitspakete kontieren. Grundsätzlich sollten folgende Punkte beachtet werden:

169

3 Operatives Projektcontrolling Tipp

•

• • •

Frühzeitig muss geklärt werden, wie und welche Daten der Finanzbuchhaltung für das Projektberichtswesen genutzt werden können. Plan- und Istdaten müssen in der gleichen Feinheit vorliegen. Sie dürfen außerdem nicht zu detailliert sein. Turnusmäßige Sitzungen (wöchentlich) ermöglichen einen realistischen Einblick in die Projektsituation. Permanente Kommunikation erleichtert die Projektsteuerung. Dabei ist der persönliche Kontakt der E-Mail vorzuziehen. „Management by walking around“ ist oft die beste Methode, sich über den Leistungsfortschritt zu informieren.

ZZMA ist eine bei der Lufthansa Systems GmbH entwickelte SAPAnwendung, mit der man die Arbeitszeiten der einzelnen Mitarbeiter, die über ein Zeiterfassungssystem aufgenommen werden, und die für Einzelaktivitäten im Projekt geleisteten Zeiten aufeinander abstimmt (vgl. Abb. 139). Es dient damit einerseits zur Einrichtung von Projekten und Projekttätigkeiten und andererseits der Zuordnung der Stunden der Mitarbeiter auf die vom Projektleiter geplanten Tätigkeiten. Auch eventuell notwendige Rechnungskommentare können angegeben werden. Des Weiteren hat der Projektleiter mit der ZZMA ein Steuerungsinstrument, das es ihm ermöglicht, PlanIst-Abgleiche zu fahren und nach deren Kontrolle die in ZZMA gespeicherten Aufwandsdaten an das SAP-System weiterzuleiten. Prinzipieller Ablauf 1. Der Projektleiter richtet in ZZMA ein Projekt mit allen identifizierenden Daten ein (Kopfdaten). Er definiert alle Aktivitäten zum Projekt und gibt diese ebenfalls in ZZMA ein. Er ordnet der jeweiligen Projektaktivität Mitarbeiter zu und benennt für den Vertretungsfall seinen Stellvertreter. 2. Der Projektmitarbeiter ordnet seine bereits im Zeiterfassungssystem gespeicherten Stunden den jeweiligen Projektaktivitäten zu. Nach Ende einer Periode – in ZZMA i.d.R. ein Monat – gibt er seine Zeitdatenzuordnung frei. 3. Der Projektleiter überprüft die Stundenzuordnung der Mitarbeiter und veranlasst notwendige Korrekturen. 4. Der Mitarbeiter nimmt die Korrekturen vor und bewirkt eine erneute Freigabe der Daten. 5. Der Projektleiter wertet die ZZMA-Daten aus, führt einen Monatsabschluss durch und sorgt für die korrekte Verbuchung der Aufwandsdaten im SAP-System. 170


6. Der Profit-Center-Leiter nutzt die ZZMA-Daten für Auswertungen über erbrachte Stunden seiner Mitarbeiter in den diversen Projekten und zur Abgrenzung von produktiven gegenüber den nicht produktiven Stunden. 7. Nach Monatsabschluss sind Änderungen an der Zeiterfassung nicht mehr möglich. So genannte Parkstunden (Stunden, die keiner Aktivität zugeordnet wurden) werden in das Erfassungsblatt des Folgemonats übertragen und müssen dort einer Aktivität zugeordnet werden.

Abb. 139: Auszug aus dem System ZZMA

Warum ist eine Prognose der Istdaten wichtig? Da Istdaten teilweise erst spät verfügbar sind, dauert es in manchen Fällen zu lange, bis Maßnahmen eingeleitet werden können. Deswegen sollten neben den Istdaten auch Prognosedaten zur Verfügung gestellt werden. Sie erlauben ein frühzeitiges Gegensteuern, so dass Planabweichungen im Idealfall nicht mehr auftreten. Abb. 140 zeigt den einfachen Fall, dass ausgehend vom aktuellen Termin der Pro-

171


jektfortschritt aufgrund der Entwicklung in der Vergangenheit linear fortgeschrieben wird. Man erkennt, dass bei gleichbleibenden Bedingungen der geplante Projektendtermin nicht einzuhalten ist. Verfahren zur Prognose der voraussichtlichen Gesamtkosten und der voraussichtlichen Gesamtdauer werden in Abschnitt 3.2.4 behandelt. Projektfortschritt 100 %

Prognose Plan

Ist

Aktueller Termin

Geplantes Ende

Prognostiziertes Ende

Abb. 140: Projektsteuerung mit Prognosedaten Besser als eine einfache Trendfortschreibung ist die realistische Schätzung der restlichen Dauer (Time-to-Completion, vgl. Abb. 147).

Was ist bei der Ursachenanalyse zu beachten? Stellt man den Ist- die Plandaten gegenüber, werden im Regelfall Abweichungen auftreten. Handelt es sich um kritische Abweichungen, durch die wichtige Projektziele gefährdet sind, muss die Projektleitung die Ursachen herausfinden. Dabei ist es wichtig, sich nicht mit oberflächlichen Antworten zufrieden zu geben. Nach der Methode der „Fünf Warum“ sollte der Projektcontroller mindestens fünfmal nach den Ursachen einer Abweichung fragen, bevor er sich mit den Antworten zufrieden gibt.82 Erst dann kann er die wahren Gründe für eine Abweichung erkennen, ohne die die Erarbeitung geeigneter Gegenmaßnahmen nicht möglich ist.

82 Ohno, T., Das Toyota-Produktionssystem, Frankfurt u. a. 1993, S. 43.

172


Was ist bei Gegenmaßnahmen zu beachten? Die Ursachenanalyse ermöglicht es, geeignete Gegenmaßnahmen einzuleiten. Dabei ist immer auf die unterschiedlichen Wirkungen einer Maßnahme zu achten. Beispielsweise kann der Einsatz zusätzlicher Mitarbeiter wegen der notwendigen Einarbeitung kurzfristig nachteilig sein. Außerdem wurde schon darauf hingewiesen, dass die Erhöhung der Mitarbeiterzahl nicht im gleichen Maße eine Verkürzung der Projektdauer bewirkt und im Einzelfall sogar kontraproduktiv wirkt. Die folgenden Ausführungen beleuchten die Kontrolle und Steuerung der • • •

Leistungen (Aufgabeninhalte, Qualität), Termine und Projektkosten.

PR O J E K T P LAN U N G

Berichtswesen, Dokumentation

PROJEKTCONTROLLING

Zusätzlich werden die Auswertung der Projekterfahrungen und das Berichtswesen sowie Kennzahlen als wesentliche Grundlagen für die Projektsteuerung besprochen (vgl. Abb. 141).

Terminkontrolle

Leistungskontrolle Plan

Kostenkontrolle

Ist

Ist Plan

Auswertung der Projekterfahrungen

Abb. 141: Bestandteile der Projektkontrolle und -steuerung 3.2.2 Leistungskontrolle

Wie kann die erbrachte Leistung festgestellt werden? Naheliegend ist es, die mit einem Arbeitspaket beauftragten Mitarbeiter nach ihrer Leistung zu befragen. Dabei besteht allerdings die Gefahr, dass der erreichte Fertigstellungsgrad zu hoch bewertet wird („Fast-schon-fertig-Syndrom“). Bis kurz vor Projektende glauben 173


die Arbeitspaketverantwortlichen, die geplante Leistung erfüllen zu können, obwohl eine nicht mehr auszugleichende Planabweichung vorliegt. Um diesen Nachteil zu vermeiden, kann man alternative Methoden zur Ermittlung des Leistungsfortschritts einsetzen, die auch zur Kontrolle der Leistungsangaben herangezogen werden können. Sie werden im Folgenden anhand des Beispiels in Abb. 142 beschrieben. Terminplan A

B

C

D

Legende: Leistungsfortschritt 25% Meilenstein: E

F

aktueller Zeitpunkt

Aktuelle Daten Aufwand Kosten Plan gesamt 10 Plan A bis C 5 6 Ist 6 Rest

10.000 5.000 6.000 6.000

Abb. 142: Beispiel für die Ermittlung des Leistungsfortschritts Um den Leistungsfortschritt zu bestimmen, kann man z. B. die bereits erreichten Meilensteine zählen und in Bezug zur Gesamtzahl der Meilensteine setzen (Meilensteinmethode). Im Beispiel der Abb. 142 wurde einer von vier Meilensteinen erreicht. Es ergibt sich eine Leistung von 25 Prozent. Dieses Verfahren bringt nur dann zufrieden stellende Ergebnisse, wenn die Meilensteine genügend differenziert und bezüglich des Aufwands für vergleichbare Projektabschnitte vorliegen. Der Vorteil liegt in der einfachen Anwendbarkeit und dem geringen Ermittlungsaufwand. In manchen Unternehmen wird der Istaufwand durch den Planaufwand für das gesamte Projekt dividiert. Im Beispiel führt dies zu einem Fortschrittsgrad von 60 Prozent (6 Wochen / 10 Wochen x 100). Auch diese Methode ist sehr einfach. Das Ergebnis ist aber dann nicht korrekt, wenn der Aufwand kein Indikator für die Leistung ist. Das dürfte bei den meisten Projekten der Fall sein. 174


Die 0/50/100-Methode bewertet die noch nicht gestarteten Arbeitspakete mit einem Leistungsfortschritt von null Prozent, begonnene mit 50 Prozent und abgeschlossene mit 100 Prozent. Der entsprechende Teil des geplanten Projektaufwands wird als erwirtschafteter Wert gut geschrieben. Im Beispiel ist Arbeitspaket A abgeschlossen, so dass der gesamte Planaufwand von zwei verbucht wird (vgl. Abb. 143). Obergrenze für den erwirtschafteten Wert ist im Übrigen immer der geplante Aufwand. Selbst bei einem Istaufwand von drei würden nur zwei Einheiten gut geschrieben. Arbeitspaket C wurde begonnen, deswegen werden 0,5 Einheiten, eben die Hälfte des Planaufwands, verbucht. Insgesamt ergibt sich ein Leistungsfortschritt von 45 Prozent, da 4,5 der zehn geplanten Einheiten erwirtschaftet wurden. Man hofft, dass sich der Fehler, der durch die undifferenzierte Leistungszuordnung von 50 Prozent auftritt, über das gesamte Projekt wieder ausgleicht. Manche Arbeitspakete werden erst zu 25 Prozent abgearbeitet sein, andere zu 75 Prozent, im Mittel stimmt dann die Annahme. Arbeitspaket A B C D E F Gesamt

Planaufwand 2 2 1 2 1 2 10

Fortschritt 100 % 100 % 25 % 0% 0% 0% 45 %

Erwirtschafteter Wert 2 2 0,5 0 0 0 4,5

Abb. 143: Ermittlung des Projektfortschritts Eine pessimistische Variante ist die 0/100-Methode, bei der noch nicht begonnene und bereits laufende Arbeitspakete mit null Prozent und abgeschlossene Vorgänge mit 100 Prozent bewertet werden. Für das Beispiel erhält man einen Leistungsfortschritt von 40 Prozent. Besser als die vergangene Leistung zu schätzen, ist es erfahrungsgemäß, die noch zu erbringende Leistung zukunftsorientiert zu bestimmen. Empfohlen wird deshalb die Ermittlung eines leistungsmäßigen Fortschrittsgrads (FG) nach folgender Formel: ‫ ܩܨ‬ൌ

‫ ݀݊ܽݓ݂ݑܽݐݏܫ‬ൈ ͳͲͲ ܸ‫݀݊ܽݓ݂ݑܽݐ݉ܽݏ݁ܩ ݎ݄݈݁ܿ݅ݐ݄ܿ݅ݏݏݑܽݎ݋‬

Definition

175


Der voraussichtliche Gesamtaufwand wird hierbei ermittelt, indem man den Restaufwand für die noch zu erledigenden Arbeitspakete realistisch schätzt und dazu den bisher erreichten Istaufwand addiert. Dies führt im Beispiel zu einer Leistung von 50 Prozent (6 / 12 x 100). Dieses Verfahren wird auch als Effort-Expended-Methode bezeichnet. Ähnlich ist die Cost-to-Cost-Methode. Die Formel lautet: ‫ ܩܨ‬ൌ

Definition

‫ ݊݁ݐݏ݋݇ݐݏܫ‬ൈ ͳͲͲ ܸ‫݊݁ݐݏ݋݇ݐ݉ܽݏ݁ܩ ݎ݄݈݁ܿ݅ݐ݄ܿ݅ݏݏݑܽݎ݋‬

Verwendung findet auch folgende Formel: Definition

‫ ܩܨ‬ൌ ൬ͳ െ

ܴ݁‫݀݊ܽݓ݂ݑܽݐݏ‬ ൰ ൈ ͳͲͲ ݈ܲܽ݊ܽ‫݀݊ܽݓ݂ݑ‬

Als Ergebnis erhält man in diesem Fall einen Fortschritt von 40 Prozent (1 – (6 / 10)) x 100. In manchen Projekten ist es möglich, direkt die Restleistung zu schätzen. Dann kann der Leistungsfortschritt über folgende Beziehung ermittelt werden: Definition

‫ ܩܨ‬ൌ ͳͲͲ Ψ െ ܴ݁‫ ݊݅ ݃݊ݑݐݏ݈݅݁ݐݏ‬Ψ


XnteUVtt]t

Tipp

176

Das Projektcontrolling kann Regelungen aufstellen, die eine möglichst realistische Leistungsschätzung mit für den Projektleiter vertretbarem Aufwand ermöglichen. Im Idealfall wird der Projektfortschritt weitgehend automatisch mit Hilfe der oben erwähnten Methoden ermittelt, so dass der Projektleiter nur noch die Plausibilität prüfen muss. Unabhängig von der verwendeten Methode hat der Projektcontroller darauf zu achten, dass der Leistungsfortschritt in regelmäßigen Besprechungen, in denen er auch anwesend ist, diskutiert wird. Dies bietet eine gute Möglichkeit, aufgetretene Leistungsabweichungen zu analysieren und Maßnahmen zu erarbeiten. Die Häufigkeit von Besprechungen zur Feststellung des Projektfortschritts hängt von der Projektlaufzeit und der Hierarchieebene ab: • •

wöchentlich bei kurzen Projekten, sonst monatlich; häufige Treffen auf niedriger Ebene werden ergänzt um wenige Meetings auf hoher Ebene.


Wo liegen Ursachen einer falschen Leistungseinschätzung? Ein typischer Projektablauf ist in Abb. 144 dargestellt:83 Mitarbeiter Produktivität Geplante Leistung

Qualität

Erbrachte Leistung

Leistungsdefizit wird beseitigt

Fehlerfreie Leistung

Leistungsdefizit wird erkannt

Abb. 144: Kreislauf der Leistungserbringung Die am Anfang geplante Leistung wird von den Projektmitarbeitern mit unterschiedlicher Produktivität und Qualität erbracht. Meist wird ein Teil der Leistung Qualitätsmängel aufweisen, die man erst nach einer gewissen Zeit entdeckt. Dann sind Nacharbeiten erforderlich. Sie haben oft zur Folge, dass für die restlichen fünf Prozent des noch zu erbringenden Aufwands mehr als 20 Prozent der Zeit nötig sind. Unerfahrene Mitarbeiter erkennen diesen Sachverhalt nicht. In der Regel schätzen sie deswegen die Leistung zu optimistisch. Der Zusammenhang kann auch mit Abb. 145 erklärt werden:

Tatsächlicher Leistungsfortschritt Angenommener Leistungsfortschritt

Abb. 145: Tatsächlicher Leistungsfortschritt Der Leistungsfortschritt wird bei realistischer Schätzung durch die 45-Grad-Linie in Abb. 145 repräsentiert. Dabei stimmen tatsächlicher Leistungsfortschritt und geschätzter Leistungsfortschritt überein. Je mehr unentdeckte Qualitätsmängel vorhanden sind, desto 83

Cooper, K., The Rework Cycle: Benchmarks for the Project Manager, Project Management Journal 24.1 (1993), S. 47 ff.

177


stärker ist die Linie nach unten gebogen. Man erkennt, dass bei zunehmender Zahl unentdeckter Qualitätsmängel die Differenz zwischen angenommenem und tatsächlichem Leistungsfortschritt zunimmt. Grundsätzlich kann man folgenden Zusammenhang feststellen: Je geringer die Qualität in einem Projekt ist und je länger es dauert, bis Qualitätsmängel entdeckt werden, • •

desto größer ist die Lücke zwischen tatsächlichem und angenommenem Fortschritt; desto unsicherer ist man, wie groß der tatsächliche Leistungsfortschritt ist.

Das Projektcontrolling hat deshalb die Aufgabe, Mängel in der Beurteilung des Leistungsfortschritts aufzudecken und Maßnahmen zur Vermeidung von Fehlschätzungen vorzuschlagen. Ansatzpunkte sind zum einen die Reduzierung von Qualitätsdefiziten und zum anderen die Minimierung des Zeitverzugs, der eintritt, bis ein Fehler aufgedeckt wird.

Welche Verfahren unterstützen die Kontrolle der Leistungen? Leistung und Qualität im Projekt werden mit Reviews inhaltlich oder formell nach vorgegebenen Prüfkriterien kontrolliert. Audits sind dagegen ausschließlich prozessbezogen. Mit ihnen werden Arbeitsprozesse geprüft. Gebräuchlich sind verschiedene Review-Formen, wie z. B. Walkthrough und Inspection. Bei einem Walkthrough wird anhand von Beispielen und Testfällen die Funktionalität mit dem Ziel analysiert, Schwachstellen aufzudecken. Mit dieser speziellen Methode prüft man z. B. in Softwareprojekten die Programmfunktionen. Die Prüfgruppe sollte bis zu fünf Mitglieder umfassen und auch die Anwender einbeziehen. Anhand von Testfällen werden die Funktionen der Software gedanklich durchgespielt. Inspections sind vergleichbar einer internen Revision. Der Projektstatus wir durch Inspektoren umfassend geprüft und bewertet. Inspektoren können externe Berater sein oder Mitarbeiter des Unternehmens, wie z. B. Projektcontroller. Sie dürfen nicht dem Projektteam angehören. Die Inspektoren erfragen vom Projektteam grundlegende Daten wie den Fortschritt der Arbeitspakete, geschätzte Restaufwendungen oder durchgeführte Änderungen und prüfen diese Daten. Oft greift man auf Checklisten zurück. Der Projektleiter darf die Aussagen des Projektteams nicht beeinflussen. Das Ergeb178


nis der Prüfung kann mit einem Performance-Index verdeutlicht werden.

Was kann man gegen kritische Leistungsdefizite unternehmen? Das Projektcontrolling kann organisatorische Regelungen installieren, um einem gravierenden Leistungsverzug bei wichtigen Projekten schnell entgegenzuwirken. Eine Möglichkeit stellen Sofortmaßnahmen dar. Mit ihnen erhält ein Projekt vorübergehend höchste Priorität, um z. B. ein Leistungsdefizit fristgerecht zu beheben. Damit die Sofortmaßnahme Wirkung entfaltet, sind folgende Regeln strikt einzuhalten: • • • • • •

Tipp

Anordnungen im Rahmen einer Sofortmaßnahme müssen sich deutlich von allen anderen Dokumenten abheben. Die Genehmigung kann nur von einer hohen Stelle erteilt werden. Zu jedem Zeitpunkt darf höchstens eine Sofortmaßnahme in Kraft sein. Für jede Bearbeitung einer Sofortmaßnahme müssen Eingang und Ausgang mit Datum und Unterschrift versehen werden. Wenn nötig, müssen alle anderen Arbeiten unterbrochen werden, um die Sofortmaßnahme zu erledigen. Auch hohe Kosten sind in Kauf zu nehmen.

Wie kann der Leistungsfortschritt dargestellt werden? Der Projektcontroller muss dafür Sorge tragen, dass der Projektfortschritt transparent dargestellt wird. Projektmanagementsoftware bietet verschiedene Möglichkeiten, den Projektfortschritt mit Balkenplänen zu verdeutlichen. Abb. 146 zeigt z. B. den derzeit gültigen Plan und den Projektfortschritt der Arbeitspakete (schwarzer Balken).

179

3 Operatives Projektcontrolling Aktueller Zeitpunkt: 25. Juni

Arbeitspaket 9

1 Planung 1.1 Projektteam bilden 1.2 Ziele festlegen 1.3 Projektplan erstellen 1.4 Genehmigung der Planung 2 Analyse 2.1 Erhebung und Analyse 2.2 W ürdigung 2.3 Genehmigung der Analyse 3 Soll-Konzept 3.1 Konzept erarbeiten 3.2 Konzept präsentieren 3.3 Genehmigung Soll-Konzept 4 Realisierung 4.1 Systembau 4.2 Einführung 4.3 Projekt abgeschlossen

10

März 11

12

13

14

April 15 16

17

18

Mai 19 20

21

22

23

Juni 24

25

26

27

Juli 28 29

30

31

August 32 33

34

35

September 36 37 38

3

09.04.

21.05.

02.07.

17.09.

Abb. 146: Projektfortschrittsbericht in MS-Project Der Vorgang „Konzept erarbeiten“ ist hinter dem Plan zurück. Der schwarze Balken müsste eigentlich bis zum aktuellen Zeitpunkt, dem 25. Juni, reichen. Wenn im vorliegenden Fall die Pufferzeit des Arbeitspakets geringer als der Zeitverzug wäre, müsste der Projektleiter geeignete Gegenmaßnahmen einleiten. 3.2.3 Terminkontrolle

Wie können die Termine kontrolliert werden? Analog zu einem leistungsmäßigen Fortschrittsgrad kann ein zeitlicher Fortschrittsgrad ermittelt werden: Definition

ܼ݁݅‫ ܩܨ ݎ݄݈݁ܿ݅ݐ‬ൌ

‫ݎ݁ݑܽ݀ݐݏܫ‬ ൈ ͳͲͲ ܸ‫ݎ݁ݑܽ݀ݐ݉ܽݏ݁ܩ ݄݈݁ܿ݅ݐ݄ܿ݅ݏݏݑܽݎ݋‬

Die voraussichtliche Gesamtdauer errechnet sich aus der Istdauer zuzüglich der realistisch geschätzten voraussichtlichen Restdauer (Time-to-Completion). Aufgrund der bisher verbrauchten Zeit und der restlichen Zeit bis zur Projektfertigstellung wird ermittelt, ob der Zeitplan einzuhalten ist. Time-to-Completion sollte für jedes Arbeitspaket in regelmäßigen Abständen auf der Grundlage des bisher erreichten Projektstandes geschätzt werden. Am besten befragt man dazu die betroffenen Projektmitarbeiter. Auf keinen Fall führt die einfache Fortschreibung der ursprünglich geplanten Zeiten zu einem

180


realistischen Endtermin. Der Balkenplan in Abb. 147 verdeutlicht die Kennzahl Time-to-Completion. Time-to-Completion

Arbeitspaket Zeit Projekt- Gegenwart start

Geplanter Endtermin

Voraussichtlicher Endtermin

Abb. 147: Balkenplan mit Time-to-Completion Die voraussichtliche Gesamtdauer ist auch mit der Methode der Earned Value Analyse ermittelbar (vgl. Abschnitt 3.2.4).

Welchen Nutzten bringt das Termin-Trenddiagramm? In Projekten besteht, wie bereits in Abb. 145 verdeutlicht, die Gefahr, dass man den Leistungsfortschritt und damit auch die Terminsituation zu optimistisch darstellt. Das Termin-Trenddiagramm zeigt sich anbahnende Terminverzögerungen frühzeitig. Korrekturmaßnahmen können eingeleitet werden. Der Balkenplan ermöglicht dagegen nur eine Momentaufnahme der Projektsituation. Die Veränderungen eines Plantermins im Zeitablauf werden nicht ersichtlich. Das Diagramm in Abb. 148 zeigt auf der Abszisse die Berichtsmonate während des Projektes und auf der Ordinate die aktuellen PlanFertigstellungstermine. Zu jedem Berichtsmonat wird abgefragt, ob sich der zuletzt geschätzte Plan-Endtermin halten lässt. Ist dies nicht der Fall, wird der neue Plan-Endtermin eingetragen. Ansteigende Linien im Diagramm zeigen Verzögerungen an, waagrechte Linien bedeuten, dass sich im Vergleich zum Vormonat keine Änderung ergeben hat, sinkende Linien verdeutlichen eine Verkürzung der Plandauer. Wenn die Linie eines Arbeitspakets auf die im Diagramm eingezeichnete Winkelhalbierende trifft, ist die Aufgabe erfüllt. Abb. 148 verdeutlicht, dass bereits die Planung nicht rechtzeitig zu Ende geführt wurde. Sie sollte ursprünglich Mitte Mai abgeschlossen sein, konnte jedoch erst Ende Juli fertig gestellt werden. Dadurch verzögerten sich auch die davon abhängenden Aufgaben. Der 181


Projektleiter hätte die zeitliche Verzögerung der Analyse und des Entwurfs eigentlich schon zum Berichtstermin fünf erkennen müssen. Tatsächlich erfolgten die Aktualisierungen jedoch erst in den Monaten sechs und acht. Das Projektcontrolling muss in diesem Fall die verspätete Anpassung hinterfragen, um zukünftig eine schnellere Reaktion zu gewährleisten. 9 Entwurf 8

Geplante Endtermine

7 Analyse 6 Planung

5 4 3 2 1 0

1

2 3 4 5 6 Aktuelle Berichtstermine

7

8

9

Abb. 148: Termin-Trenddiagramm Kurvenverläufe im Termin-Trenddiagramm lassen sich grundsätzlich wie folgt interpretieren: Kurvenverlauf

Interpretation

permanent steigend

zu optimistische Terminplanung

permanent fallend

Planung mit zu hohen Puffern

abwechselnd steigender und fallender Verlauf

hohe Unsicherheit der Terminaussagen

entgegen gerichteter Verlauf zweier abhängiger Vorgänge

mindestens ein Arbeitspaket wurde unrealistisch geplant

Abb. 149: Kurvenverläufe im Termin-Trenddiagramm

182


Termin-Trenddiagramme können für einzelne Arbeitspakete, Teilprojekte, Meilensteine (man spricht dann von MeilensteinTrenddiagrammen) und Projekte erstellt werden. Die manuelle Anfertigung von Termin-Trenddiagrammen ist sehr aufwändig, deshalb sollte man auf ein DV-Tool zurückgreifen. Praktikable Systeme sind Prin(z) der project-it GmbH und GRANEDA der NETRONIC Software GmbH. Die Systeme bieten auch Standardschnittstellen zu MS-Project oder SAP R/3. Oft wird auch ein Tabellenkalkulationsprogramm verwendet.

,nteUnet

www.netronic.de www.project-it.de

Im Produktbereich Instrumentation Systems der Robert Bosch GmbH werden die wichtigsten geplanten Meilensteine (so genannte Ecktermine eines Projektes) aus dem MS-Project MasterTerminplan entnommen. Der Projektleiter benötigt die Informationen zur Meilenstein-Terminplanung, um ein Erreichen der Meilensteine und damit den Projekterfolg bewerten zu können. Die Terminsteuerung wird durch ein DV-System unterstützt. Es unterscheidet im Terminplan zwischen Soll-, Plan- und Ist-Terminen: In der Spalte „Plan-Termin“ sind die aktuell geplanten Meilensteintermine einzutragen. Sobald der Terminplan genehmigt und mit den Beteiligten abgestimmt ist, werden die geplanten MeilensteinTermine in die „Soll-Spalte“ übernommen. Wenn sich ein Termin im Lauf des Projektes verschiebt, dann ist der jeweilige Termin in der Spalte „Plan-Termin“ zu aktualisieren. Wird ein Meilenstein erreicht, so ist der tatsächliche Freigabetermin in die „Ist-Spalte“ einzugeben. Aus dem Meilenstein-Terminplan wird die MeilensteinTrendanalyse generiert (vgl. Abb. 150 und Abb. 151).

Abb. 150: Zusammenspiel von Terminplan und MeilensteinTrendanalyse basierend auf MS-Project

183


Die Meilenstein-Trendanalyse beinhaltet ebenfalls die wichtigen Ecktermine eines Projektes aus dem Meilenstein-Terminplan und ist ein Vergleich zwischen Basisplan (Urplan) und überarbeitetem Plan. Sie wird im Projekt-Cockpit graphisch abgebildet und hat zum Ziel, mögliche Terminverschiebungen aufzuzeigen. Das Meilensteinraster ist für alle Projekte einheitlich und entspricht den Eckterminen aus dem Zielprozess des Produktbereiches. Die Projektleiter verwenden die Meilenstein-Trendanalyse auch für die Darstellung der Terminsituation der Entwicklungsprojekte vor dem Projektsteuerkreis. Das Instrument wird eingesetzt, um auf Probleme in der Terminierung und der Terminerreichung hinzuweisen. Die folgende Abb. 151 zeigt einen konkreten Fall.

Abb. 151: Praktisches Beispiel zur Meilenstein-Trendanalyse Die Produktanforderung des Kunden zum Serienproduktionsstart hat sich ständig verschoben. Graphisch kann man das an der Linie entlang der Diagonalen erkennen. Ab Januar 2001 wird deutlich, dass sich die Kurve „Abschluss der Produktentwicklung“ analog zur Linie „Einfrieren der Produktanforderung“ verschiebt (parallele Linien). Der Abstand zwischen den Linien stellt die Mindestentwicklungsdauer bis zur abschließenden Qualifizierung dar. Durch den konstanten Endtermin „Produktionsstart“ kommt es zu einer Annäherung der beiden Termine „Abschluss Produktentwicklung“ 184


und „Produktionsstart“. Aufgrund des abgebildeten Trends war frühzeitig erkennbar, dass es zur Terminkollision zum Produktionsstart kommen würde. Im konkreten Beispiel wurde mit dem Kunden im Februar 2001, als der Trend zur Kreuzung der beiden oberen Meilensteinlinien offensichtlich war, eine Vereinbarung zur Reduzierung der Qualifizierung zum Serienstart getroffen. Somit war sichergestellt, dass der Kunde zufrieden stellend beliefert werden konnte.

Was ist ein Kosten-Trenddiagramm? Trägt man auf der Ordinate nicht die Termine, sondern die geplanten Kosten ab, so erhält man ein Kosten-Trenddiagramm. Es zeigt, wie sich die voraussichtlichen Gesamtkosten für die einzelnen Teilprojekte und Arbeitspakete während des Projektes verändern (vgl. Abb. 152). ?

Geplante Gesamtkosten in Tausend €

900 Entwurf

800 700 600

Analyse

500 400 Planung 300 200 100 0

1

2 3 4 5 6 Aktuelle Berichtstermine

7

8

9

Abb. 152: Kosten-Trenddiagramm

Wie ist ein Zeit-/Kosten-Trenddiagramm aufgebaut? In Trenddiagrammen können auch Termin- und Kosteninformationen kombiniert werden. Abb. 153 zeigt die Gegenüberstellung des

185


planmäßigen und tatsächlichen Verhältnisses zwischen Kosten- und Zeitverbrauch. 140% 120%

Kostenverbrauch

100% 80%

Istkosten

60% Plankosten

40% 20% 0% 0%

20%

40%

60%

80%

100%

120%

140%

Zeitverbrauch

Abb. 153: Zeit-/Kosten-Trenddiagramm Bei 90 Prozent der geplanten Dauer sollten 80 Prozent der Kosten angefallen sein. In diesem Punkt entsprechen sich die Plan- und Istdaten.


XnteUVtt]t

Das Projektcontrolling erarbeitet Richtlinien für die Terminkontrolle. Es kann z. B. gefordert werden, dass eine monatliche Schätzung der Kennzahl Time-to-Completion erfolgt. Zusammen mit dem Projektleiter wird der Projektcontroller Abweichungen der Termine analysieren und Maßnahmen planen. Der Projektcontroller kann den Projektleiter auch vor Fehlinterpretationen der Termin- und Kostensituation bewahren. Bei oberflächlicher Betrachtung der Abb. 153 ergibt sich an dem Punkt, an dem 80 Prozent der geplanten Zeit verstrichen sind, eine zufrieden stellende Situation. In Wirklichkeit überschreitet das Projekt jedoch sowohl das Zeit- wie auch das Kostenbudget. Ursache der Fehlinterpretation ist die Tatsache, dass die den Istkosten zugrunde liegende Leistung nicht berücksichtigt wurde. Man hätte mit dieser Information bereits zu einem früheren Zeitpunkt die Kostenüberschreitung erkennen müssen.

186


ABWEICHUNG

Plankosten

Zusatzkosten aus Vertragsänderungen Kosten laut Kalkulation

Noch zu erwartende Restkosten Disponierte Kosten Angefallene Istkosten

Voraussichtliche Gesamtkosten

3.2.4 Kostenkontrolle Im Rahmen der Kostenkontrolle werden die geplanten Kosten der Arbeitspakete oder des Projekts mit den voraussichtlichen Istkosten verglichen. Die Istkosten setzen sich aus den bis zum gegenwärtigen Zeitpunkt angefallenen und den bereits disponierten Kosten (z. B. für bereits bestelltes Material) zusammen. Dazu addiert man die geschätzten Restkosten, die aufgrund der noch zu erbringenden Leistung bis Projektende anfallen werden. Ziel ist es, im Vergleich zwischen den gesamten Plankosten und den voraussichtlichen Istkosten bis Projektende Hinweise auf drohende Budgetüberschreitungen zu erhalten und Unwirtschaftlichkeiten aufzudecken (vgl. Abb. 154).

Abb. 154: Kostenkontrolle84

Welche Aufgaben nimmt das Projektcontrolling wahr? Die Kostenkontrolle übernimmt in der Regel der Controller. Unterstützt wird er vom Projektleiter, der dafür verantwortlich ist, dass die Ressourcenverbräuche, insbesondere die geleisteten Arbeitsstunden, zeitnah und der Realität entsprechend vorliegen.

3UoMeNtFontUoOOeU

XnteUVtt]t

Das Projektcontrolling sorgt für ein funktionierendes Erfassungssystem der laufenden Kosten, analysiert Kostenabweichungen mit geeigneten Methoden und schlägt Maßnahmen zur Kostensenkung vor. Im Folgenden soll die Earned Value Analyse als aussagekräftiges Verfahren zur integrierten Kosten- und Leistungskontrolle beschrie84

Schmitz, H., Windhausen, M., Projektplanung und Projektcontrolling – Planung und Überwachung von besonderen Vorhaben, Düsseldorf 1986, S. 125.

187


ben werden. Ausgangsüberlegung ist die Tatsache, dass Kostendiagramme wie in Abb. 153 und Abb. 155 nur Plan- und Istkosten zeigen und damit eine aussagekräftige Interpretation von Kostenabweichungen erschweren. 90000 80000

WůĂŶŬŽƐƚĞŶ /ƐƚŬŽƐƚĞŶ

70000

Kum. Kosten in €

60000 50000 40000 30000 20000 10000 0 Januar

Februar

März

April

Mai

Juni

Juli

August

Abb. 155: Kumulierte Ist- und Plankosten Betrachtet man Abb. 155, so lassen sich zunächst bis April höhere Istkosten erkennen. Schließt man Falschbuchungen aus, können folgende Ursachen dafür verantwortlich sein: •

•

unwirtschaftliche Projektabwicklung, die wiederum durch einen unplanmäßig hohen Aufwand (es sind mehr Arbeitsstunden angefallen als geplant) oder durch den Einsatz von Mitarbeitern mit sehr hohen Stundensätzen bedingt sein kann, vorzeitiger Abschluss eingeplanter Aufgaben.

Später fällt die Istkostenkurve unter die Plankosten. Mögliche Gründe dafür sind: •

•

besonders wirtschaftliche Projektabwicklung, die man durch einen geringeren Aufwand (es sind weniger Arbeitsstunden angefallen als geplant) oder durch den Einsatz von Mitarbeitern mit sehr niedrigen Stundensätzen begründen kann, unplanmäßige Minderleistungen.

Man kann aus Abb. 155 nicht entnehmen, ob die Abweichung im August auf einen geringeren Leistungsfortschritt oder eine besonders wirtschaftliche Leistungserbringung zurückzuführen ist. Wenn 188


die Istkosten wie in Abb. 155 geringer als die Plankosten sind, kann sogar ein überhöhter Kostenverbrauch vorliegen; nämlich dann, wenn gleichzeitig wesentlich weniger Leistungen als geplant erbracht wurden. Das Beispiel verdeutlicht, dass die Kostenkontrolle auch den Leistungsstand mit einbeziehen muss. Dies erreicht man durch den Ausweis von Sollkosten für jedes Arbeitspaket. Das sind diejenigen Kosten, die für eine gegebene Leistung planmäßig anfallen dürfen (Plankosten pro Leistungseinheit x Istleistung). Man spricht auch vom so genannten Earned Value.

Was versteht man unter Earned Value Analyse? Durch die Gegenüberstellung von Plan-, Soll- und Istkosten werden Abweichungsursachen differenzierter erkannt. Mit diesem auch als Earned Value Analyse bezeichneten Verfahren lassen sich folgende Fragen beantworten: • • • • •

Wie hoch sind die tatsächlichen Kosten der erbrachten Leistung? (Istkosten)? Wie hoch dürften die Kosten der erbrachten Leistung laut Plan sein? (Sollkosten)? Wie hoch dürften die Kosten bei der geplanten Leistung sein? (Plankosten)? Verläuft das Projekt wirtschaftlich (Istkosten – Sollkosten)? Wird die geplante Leistung erbracht (Sollkosten – Plankosten)?

,nteUnet

www.valuationopinions.com/

Die folgende Aufstellung zeigt im Überblick die Kennzahlen der Earned Value Analyse. Istkosten kumuliert Begriff 2 Actual Cost Begriff 3 Actual Cost of Work Performed (ACWP) Berechnung Istkosten pro Leistungseinheit x Istleistung kumuliert Sollkosten Begriff 2 Begriff 3 Berechnung

Earned Value Budgeted Cost of Work Performed (BCWP) Plankosten pro Leistungseinheit x Istleistung kumuliert

Plankosten kumuliert Begriff 2 Budgeted Cost of Work Scheduled (BCWS) Berechnung Plankosten pro Leistungseinheit x Planleistung kumuliert

189


Plankosten gesamt Begriff 2 Budget at Completion (BAC) Berechnung Plankosten pro Leistungseinheit x Planleistung gesamt Leistungsabweichung absolut Begriff 2 Schedule Variance (SV) Berechnung Sollkosten – Plankosten Kostenabweichung absolut Begriff 2 Cost Variance (CV) Berechnung Istkosten – Sollkosten oder Sollkosten – Istkosten Leistungsindex Begriff 2 Schedule Performance Index (SPI) Berechnung Sollkosten / Plankosten x 100 Kostenindex Begriff 2 Berechnung

Cost Performance Index (CPI) Istkosten / Sollkosten x 100

Auf der Grundlage der Earned Value Analyse können weitere Kennzahlen erarbeitet werden: Voraussichtliche Gesamtdauer Begriff 2 Time-at-Completion (TAC) Berechnung Gesamte Plandauer / (Sollkosten / Plankosten) Voraussichtliche Restdauer Begriff 2 Time-to-Completion (TTC) Berechnung Time-at-Completion – Istdauer Voraussichtliche Gesamtkosten Begriff 2 Cost-at-Completion Begriff 3 Estimate at Completion (EAC) Berechnung Gesamte Plankosten * (Istkosten / Sollkosten) oder Gesamte Plankosten / (Sollkosten / Istkosten) Voraussichtliche Restkosten Begriff 2 Cost-to-Completion Begriff 3 Estimate to Completion (ETC) Berechnung Cost-at-Completion – Istkosten

190


Ein Beispiel soll im Folgenden die Ermittlung und Analyse der Kennzahlen verdeutlichen (vgl. Abb. 156): Monat

Kumulierte Istkosten

Kumulierte Plankosten

Kumulierte Sollkosten

1

945 €

1.035 €

945 €

2

1.785 €

2.160 €

1.785 €

3

2.730 €

3.364 €

2.730 €

4

3.720 €

4.759 €

3.720 €

5

5.115 €

6.244 €

4.375 €

6

6.555 €

7.797 €

5.055 €

7

7.905 €

9.349 €

6.505 €

8

9.300 €

10.992 €

8.300 €

9

10.605 €

12.724 €

9.255 €

Abb. 156: Beispieldaten für die Earned Value Analyse Ein Arbeitspaket, dessen gesamte Plankosten sich auf 76.500 € belaufen, soll nach neun Monaten untersucht werden.85 Zu diesem Zeitpunkt liegen folgende Kostendaten vor: kumulierte Sollkosten 9.255 €, kumulierte Istkosten 10.605 €, kumulierte Plankosten 12.724 €. Die Plandauer beträgt zwölf Monate. Die folgende Abb. 157 zeigt den Verlauf der kumulierten Ist-, Sollund Plankosten. Die Differenz von Ist- und Sollkosten verdeutlicht denjenigen Teil der Gesamtabweichung, der durch einen unplanmäßigen Ressourcenverbrauch verursacht wurde. Ursachen können entweder geänderte Kostensätze oder ein gegenüber der Planung geänderter Input für die Leistungserstellung sein. Der Unterschied zwischen Plan- und Sollkosten ist ein Indikator für unplanmäßigen Leistungsfortschritt (in Abb. 157 mit Leistungsabweichung gekennzeichnet).

85

Coenenberg, A. u. a., Abweichungsanalyse bei Projekten im F&E-Bereich, in: Männel, W. (Hrsg.), Handbuch Kostenrechnung, Wiesbaden 1992, S. 767 ff.

191

3 Operatives Projektcontrolling 14000

Kumulierte Kosten

12000

Kumulierte Istkosten

10000 8000

Kumulierte Plankosten

6000

Kumulierte Sollkosten

Leistungsabweichung

4000 2000 0 1

2

3

4

5

6

7

8

9

10

Monat

Abb. 157: Diagramm für die Earned Value Analyse Aus dem Beispiel können folgende Schlussfolgerungen gezogen werden: • Von Projektbeginn an bleibt der Fortschritt hinter dem geplanten Ablauf zurück. • Das Projekt ist bis April wirtschaftlich, da die Istkostenkurve weitgehend identisch mit der Sollkostenkurve verläuft. • Zwischen April und September laufen Ist- und Sollkostenkurve dramatisch auseinander, so dass eine erhebliche Kostenabweichung entsteht. Die Istkosten für die erbrachte Leistung sind höher, als dies eigentlich sein dürfte. • Zum gegenwärtigen Zeitpunkt (Monat September) ist der erreichte Leistungsstand deutlich teurer erbracht worden als ursprünglich kalkuliert. Zugleich liegt ein erhebliches Leistungsdefizit vor.

Welche zusätzlichen Darstellungen sind möglich? Zusätzlich zur kumulierten Darstellung der absoluten Plan-, Ist- und Sollkosten können die jeweiligen monatlichen Leistungs- und Kostenabweichungen errechnet werden. ‫ ݃݊ݑ݄ܿ݅݁ݓܾܽ݊݁ݐݏ݋ܭ‬ൌ ‫ ݊݁ݐݏ݋݇ݐݏܫ‬Ȃ ܵ‫݊݁ݐݏ݋݈݈݇݋‬ ‫ ݃݊ݑ݄ܿ݅݁ݓܾܽݏ݃݊ݑݐݏ݅݁ܮ‬ൌ ܵ‫ ݊݁ݐݏ݋݈݈݇݋‬െ ݈ܲܽ݊݇‫݊݁ݐݏ݋‬

Es lassen sich damit weitere Auswertungen in Form von „Projektfieberkurven“ erstellen, die für das Beispiel zeigen, dass sowohl die 192


Kosten als auch die Leistungen abweichen (vgl. Abb. 158 und Abb. 159). 1.600 1.400

Kostenabweichung (Istkosten - Sollkosten)

1.200 1.000 800 600 400 200 0 1

2

3

4

5

6

7

8

9

-200

Monate

Abb. 158: Kostenabweichung als Fieberkurve Monate

200 -300

1

2

3

4

5

6

7

8

9

Leistungsabweichung (Sollkosten - Plankosten)

-800 -1.300 -1.800 -2.300 -2.800 -3.300 -3.800

Abb. 159: Leistungsabweichung als Fieberkurve Der positive Wert der Kostenabweichung in Abb. 158 zeigt eine Unwirtschaftlichkeit, der negative Wert der Leistungsabweichung in Abb. 159 weist auf einen Leistungsrückstand hin. Für ein Management-Informationssystem bietet es sich an, jeweils einen Index für die Kostenentwicklung und die Leistungsentwicklung zu ermitteln: 86

86

Der Kostenindex wird vielfach auch wie folgt errechnet:

193

3 Operatives Projektcontrolling ‫ ݔ݁݀݊݅ݏ݃݊ݑݐݏ݅݁ܮ‬ൌ ‫ ݔ݁݀݊݅݊݁ݐݏ݋ܭ‬ൌ

ܵ‫݊݁ݐݏ݋݈݈݇݋‬ ൈ ͳͲͲ ݈ܲܽ݊݇‫݊݁ݐݏ݋‬

‫݊݁ݐݏ݋݇ݐݏܫ‬ ൈ ͳͲͲ ܵ‫݊݁ݐݏ݋݈݈݇݋‬

Für das Beispiel in Abb. 156 ergeben sich folgende Werte: ‫ ݔ݁݀݊݅ݏ݃݊ݑݐݏ݅݁ܮ‬ൌ ‫ ݔ݁݀݊݅݊݁ݐݏ݋ܭ‬ൌ

ͻǤʹͷͷ ̀ ൈ ͳͲͲ ൌ ͹ʹǡ͹Ͷ Ψ ͳʹǤ͹ʹͶ ̀

ͳͲǤ͸Ͳͷ ̀ ൈ ͳͲͲ ൌ ͳͳͶǡͷͻ Ψ ͻǤʹͷͷ ̀

Um einen Euro Wert zu schaffen müssen im Beispiel 1,14 € ausgegeben werden. Weiterhin wird ein „Korridor“ bestimmt, innerhalb dessen sich die Kosten- und Leistungsabweichungen eines Projekts bewegen dürfen, ohne dass ein Eingreifen der Projektleitung notwendig wäre (Management by Exception). In Abb. 160 übersteigt die Leistungsabweichung bereits zum Berichtsmonat Februar die Toleranzschwelle von zehn Prozent. Zu diesem Zeitpunkt wäre die Analyse einzuleiten. 140

Abweichung in Prozent

120

100

80

60

40 Kostenindex Leistungsindex

20

0 1

2

3

4

5

6

7

8

9

Monate

Abb. 160: Kosten- und Leistungsindex mit Abweichungskorridor

Sollkosten / Istkosten x 100. Ein Wert unter 100 zeigt in diesem Fall eine Unwirtschaftlichkeit im Projekt.

194


Ein Problem von Toleranzschwellen wie in Abb. 160 ist, dass nicht berücksichtigt wird, wie weit das Projekt bereits fortgeschritten ist. Die kumulierten Abweichungen bis Februar dürfen aber größer sein als diejenigen bis September, da eine Differenz zu Beginn des Jahres noch gut kompensiert werden kann. Die sogenannte Trompetenkurve vermeidet diese Schwierigkeit. Sie zeigt anschaulich auf, ab wann Abweichungen zum Problem werden (vgl. Abb. 161). 40,0% Kostenabweichung

30,0%

Leistungsabweichung

20,0% + 10 %

10,0% 0,0% 1

2

3

4

5

6

7

8

9

10

11

12 - 10 %

-10,0% -20,0% -30,0% -40,0%

Abb. 161: Trompetenkurve Die Kurve in Abb. 161 zeigt den Verlauf des Leistungs- und Kostenindex. Für das Projektende wurde eine maximale Abweichung von sieben Prozent vorgegeben. Die zulässige Abweichung von 34,6 Prozent für den Monat eins errechnet sich mit der Formel ܲ‫ כ ݖ݊ܽݎ݈݁݋ݐ݀݊݁ݐ݆݇݁݋ݎ‬ඨ

ͳʹ ܽ݇‫ݐܽ݊݋ܯ ݎ݈݈݁݁ݑݐ‬

Die Leistungsabweichung wäre erst nach dem Monat drei angezeigt worden. In Abb. 160 hätte man bereits nach Monat eins die starre Schwelle überschritten. Auf der Grundlage der bisher erörterten Kennzahlen ist es möglich, die voraussichtlichen Gesamtkosten und die voraussichtliche Gesamtdauer für das Beispiel in Abb. 156 zu bestimmen: 87 ܸ‫ ݎ݁ݑܽ݀ݐ݉ܽݏ݁ܩ ݄݈݁ܿ݅ݐ݄ܿ݅ݏݏݑܽݎ݋‬ൌ

87

݈ܲܽ݊݀ܽ‫ݎ݁ݑ‬ ‫ݔ݁݀݊݅ݏ݃݊ݑݐݏ݅݁ܮ‬

Alternativ kann man die Voraussichtliche Gesamtkosten auch mit folgender Formel errechnen: Istkosten + (Plankosten gesamt – Sollkosten) x Kostenindex 87.658 € = 10.605 € + (76.500 € - 9.255 €) * 114,59 %.

195


ͳ͸ǡͷ ‫ ݁ݐܽ݊݋ܯ‬ൌ

ሺͳʹ ‫݁ݐܽ݊݋ܯ‬ሻ ͻǤʹͷͷ ̀ ሻ ሺ ͳʹǤ͹ʹͶ ̀

ܸ‫ ݊݁ݐݏ݋݇ݐ݉ܽݏ݁ܩ ݄݈݁ܿ݅ݐ݄ܿ݅ݏݏݑܽݎ݋‬ൌ ݈ܲܽ݊݇‫ ݐ݉ܽݏ݁݃ ݊݁ݐݏ݋‬ൈ ‫ݔ݁݀݊݅݊݁ݐݏ݋ܭ‬ ͺ͹Ǥ͸ͷͺ ̀ ൌ ͹͸ǤͷͲͲ ̀ ൈ

ͳͲǤ͸Ͳͷ ̀ ͻǤʹͷͷ ̀

Die Anwendbarkeit der Formel für die voraussichtlichen Gesamtkosten setzt voraus, dass sich die bisherige tatsächliche Wirtschaftlichkeit im Projekt nicht verändert und die Performance zukünftig wie geplant realisieren lässt. Trifft diese Annahme nicht zu, so können die voraussichtlichen Gesamtkosten auch wie folgt errechnet werden: •

Möchte man zeigen, wie sich die Gesamtkosten entwickeln, wenn sich die geplante Wirtschaftlichkeit wieder einstellt und die ursprünglich geplante Performance für den Rest des Projektes erreicht wird, kann folgender Zusammenhang verwendet werden: ‫ ݊݁ݐݏ݋݇ݐݏܫ‬൅ ሺ݈ܲܽ݊݇‫ ݐ݉ܽݏ݁݃ ݊݁ݐݏ݋‬െ ܵ‫݊݁ݐݏ݋݈݈݇݋‬ሻ ͳͲǤ͸Ͳͷ ̀ ൅ ሺ͹͸ǤͷͲͲ ̀ െ ͻǤʹͷͷ ̀ሻ ൌ ͹͹ǤͺͷͲ ̀Ǥ

•

Sollen die die tatsächliche Wirtschaftlichkeit und die tatsächliche Performance bis zum Projektende zugrunde gelegt werden, verwendet man folgenden Zusammenhang: 88 ‫ ݊݁ݐݏ݋݇ݐݏܫ‬൅ ሺ݈ܲܽ݊݇‫ ݐ݉ܽݏ݁݃ ݊݁ݐݏ݋‬െ ܵ‫݊݁ݐݏ݋݈݈݇݋‬ሻ ൈ ͳͲǤ͸Ͳͷ ̀ ൅ ሺ͹͸ǤͷͲͲ ̀ െ ͻǤʹͷͷ ̀ሻ ൈ

‫ݔ݁݀݊݅݊݁ݐݏ݋ܭ‬ ‫ݔ݁݀݊݅ݏ݃݊ݑݐݏ݅݁ܮ‬

ͳͳͶǡͷͻ Ψ ൌ ͳͳ͸ǤͷͶͲ ̀ ͹ʹǡ͹Ͷ Ψ

Abb. 162 fasst zusammen, mit welchen Annahmen die Restkosten in die Berechnung der voraussichtlichen Gesamtkosten einfließen.

88

196

Gerechnet wurde nicht mit den gerundeten, sondern mit den exakten Indexwerten.


Wirtschaftlichkeit bisherige

geplante

Leistung bisherige

x

Plankosten gesamt * Kostenindex

x

Istkosten + (Plankosten gesamt – Sollkosten)

x

Istkosten + (Plankosten gesamt – Sollkosten) * Kostenindex / Leistungsindex

geplante

x

x

x

Abb. 162: Berechnung der voraussichtlichen Gesamtkosten mit unterschiedlichen Annahmen für die Restkosten

Welche Aussagen liefert die Earned Value Analyse für ein Multiprojektcontrolling? Die Earned Value Analyse ist nicht nur für einzelne Arbeitspakete und Projekte anwendbar, sie liefert dem Management auch einen Überblick über die Projektsituation im Unternehmen. Abb. 163 verdeutlicht, dass zum gegenwärtigen Zeitpunkt unternehmensweit ein Leistungsverzug von –4,08 Prozent vorliegt. Allein mit den Projekten H und I ist über die Hälfte der Leistungsabweichung zu erklären. In den Projekten B, F und G wurde entgegen der Gesamtsituation mehr geleistet, als der Plan vorschrieb. Das Gesamtbudget für alle Projekte wird um 1,31 Prozent unterschritten, obwohl in den Projekten B, C, F und H zu viele Kosten entstanden. Die vorliegenden Daten bieten einen guten Einstiegspunkt für vertiefte Analysen im Rahmen des Projektcontrollings. Projekt

A B C D E F G H i Gesamt

PlanSollkosten kosten kumuliert kumuliert

800 € 600 € 400 € 700 € 1.000 € 500 € 650 € 780 € 950 € 6.380 €

760 € 650 € 350 € 650 € 930 € 520 € 700 € 700 € 860 € 6.120 €

Leistungsabweichung absolut Leistungsindex

Leistungs- Ist- kosten Kostenabweichung kumuliert abweichung

-40 € 50 € -50 € -50 € -70 € 20 € 50 € -80 € -90 €

700 € 670 € 400 € 620 € 900 € 550 € 650 € 710 € 840 € 6.040 € -260,0 € 95,9%

-60 € 20 € 50 € -30 € -30 € 30 € -50 € 10 € -20 €

Plankosten gesamt

1.000 € 1.200 € 650 € 950 € 1.500 € 600 € 780 € 900 € 1.200 € 8.780 €

Cost-atCompletion

Plandauer gesamt

Time-atCompletion

921 € 11 12 1.237 € 8 7 743 € 9 10 906 € 15 16 1.452 € 20 22 635 € 17 16 724 € 14 13 913 € 16 18 1.172 € 13 14 8.702 € Alle Kosten in Tausend Euro.

Kostenabweichung absolut Kostenindex

-80,0 € 98,7%

Abb. 163: Multiprojektcontrolling mit der Earned Value Analyse 197


Wie kann man die Probleme der Datenbeschaffung lösen? Grundsätzlich gibt es drei entscheidende Aufgaben bei einer Earned Value Analyse:89 1. Definition geeigneter Arbeitspakete 2. Erfassung des Fortschrittsgrads der Arbeitspakete 3. Ermittlung der Istkosten

Tipp

Definition geeigneter Arbeitspakete Sind die Arbeitspakete sehr klein, so ist der Aufwand für die Datenerfassung hoch. Dagegen kann bei zu grober Definition die Leistung nicht mit genügender Genauigkeit gemessen werden. Als Orientierung für die optimale Dauer eines Arbeitspakets kann der Zyklus der Lohn- und Gehaltsabrechnung, die ja die wichtigsten Kostendaten liefert, herangezogen werden. In der Regel dürfte daher eine Arbeitspaketdauer von ca. einem Monat günstig sein. Erfassung des Fortschrittsgrads der Arbeitspakete Erfasst man für jedes Arbeitspaket den Fortschritt exakt, so dauert die Datenermittlung sehr lange. Oft reicht bereits eine gröbere Schätzung nach einer der Methoden, die in Abschnitt 3.2.2 behandelt wurden (z. B. 0/100- oder Meilenstein-Methode). In der Praxis hat man vor allem in Entwicklungsprojekten Schwierigkeiten, die erbrachten Leistungen als Grundlage für die Sollkostenermittlung zu erfassen. Als Lösung bietet es sich an, die Restkosten aufgrund der noch für das Projekt zu erstellenden Leistung zu schätzen und sie von den gesamten Plankosten zu subtrahieren:

Definition

ܵ‫ ݊݁ݐݏ݋݈݈݇݋‬ൌ ݈ܲܽ݊݇‫ ݐ݉ܽݏ݁݃ ݊݁ݐݏ݋‬െ ݃݁‫݊݁ݐݏ݋݇ݐݏܴ݁ ݁ݐݖݐ¡݄ܿݏ‬

Unrealistisch ist es, vom ursprünglichen Projektbudget einfach die angefallenen Kosten abzuziehen und die Differenz dann als Restkosten auszuweisen.

89

198

Brandon, D., Implementing Earned Value easily and effectively. Project Management Journal 19.2 (1998), S. 113.


Ermittlung der Istkosten Die aktuellen Istkosten sind nur für die Ermittlung der Kostenabweichung erforderlich. Leistungsdefizite lassen sich bereits bei vorliegendem Fortschrittsgrad und Plankosten errechnen. Oft reicht es, die Kostenabweichungen nicht für jedes Arbeitspaket, sondern lediglich für das gesamte Projekt auszuweisen. Nur wenn in der Gegenüberstellung zwischen Ist- und Sollkosten Unwirtschaftlichkeiten auf Projektebene festgestellt werden, erfolgt eine genaue Analyse der Arbeitspakete. In manchen Unternehmen liegen aber selbst auf Projektebene keine aktuellen Istkosten vor. In diesem Fall bietet es sich an, wenigstens die verbrauchten Arbeitsstunden zu erfassen. Multipliziert man diese Größe mit dem Stundensatz, am besten differenziert nach der Qualifikation der eingesetzten Mitarbeiter, erhält man einen Anhaltspunkt für die wahrscheinliche Höhe der aufgelaufenen Kosten. Im Übrigen ist es auch möglich, für die Earned Value Analyse anstelle von Kostenwerten nur den Aufwand in Personenstunden im Ist, Soll und Plan zu verwenden.

Welche Unterstützung bietet Projektmanagementsoftware? Viele Systeme bieten mittlerweile Funktionalitäten für die Earned Value Analyse. Unterschiedliche Begrifflichkeiten erschweren allerdings das Verständnis. Die Interpretation der Ergebnisse setzt genaue Kenntnisse des Systems voraus. Zudem sind z. B. in MSProject Kostendaten für jedes Arbeitspaket erforderlich, damit Kosten- und Leistungsabweichungen ausgewiesen werden. Abb. 164 zeigt eine Earned Value Analyse, die mit MS-Project erstellt wurde. Dabei steht IKAA für die Istkosten der abgeschlossenen Arbeit (kumulierte Istkosten), SKAA für die Sollkosten der abgeschlossenen Arbeit (Sollkosten) und SKBA für die Sollkosten der budgetierten Arbeit (kumulierte Plankosten).

199


Abb. 164: Earned Value Analyse mit MS Project Für den Donnerstag ist in Abb. 164 sowohl eine Kostenabweichung (1.780 € – 1.620 € = 160 €) wie auch eine Leistungsabweichung (1.620 € – 3.240 € = –1.620 €) ausgewiesen. Die Unwirtschaftlichkeit ist in voller Höhe auf den Projektleiter zurückzuführen. Der Leistungsverzug verteilt sich auf Geschäftsführer (900 € – 1.800 € = –900 €) und Projektleiter (720 € – 1.440 € = –720 €). Eine genauere Analyse der Kostenabweichung im System würde zeigen, dass der Stundensatz des Projektleiters entgegen der Planung nicht bei 180 €, sondern bei 220 € liegt. 3.2.5 Auswertung der Projekterfahrungen Trotz des Zeitdrucks nach Abschluss eines Projekts sollten sich die Projektbeteiligten mindestens noch einmal treffen, um den Projektablauf zu analysieren. Ziel ist es, Erkenntnisse für nachfolgende Projekte zu gewinnen. Dabei sind nicht nur die negativen, sondern auch die positiven Faktoren hervorzuheben. Auf keinen Fall darf es zu einem Tribunal kommen. Zu beantworten sind insbesondere folgende Fragen:90 • • • • • 90

200

Welche Erfahrungen wurden an den Schnittstellen zu Lieferanten, Kunden, zum Betriebsrat und zu Fachabteilungen gemacht? Wie war die Qualität der Teamarbeit? Wie zweckmäßig war die Vorgehensweise? Wurden die richtigen Instrumente eingesetzt? War die Aufgaben- und Kompetenzverteilung sinnvoll? Hilpert, N., Rademacher, G., Sauter, B., Projekt-Management und ProjektControlling im Anlagen- und Systemgeschäft, Frankfurt 2001, S. 108 ff.


Zu erheben sind auch die Ursachen der aufgetretenen Probleme. Eine einfache Möglichkeit dafür ist in Abb. 165 dargestellt.

Vermeidbar

Kaum vermeidbar Nicht vermeidbar

Personelle Ursachen Demotivation, mangelnde Ausbildung, Überlastung Fluktuation, ungeeignete Mitarbeiter Krankheit

Technische Ursachen Planungsfehler, mangelnde Toolnutzung

Organisatorische Ursachen unklare Kompetenzen, personelle Engpässe

zusätzliche Anforderungen, fehlender Support technologische Grenzen

ungeplanter Lieferant, räumliche Aufteilung, Termindruck Änderung der Verträge, Konkurs von Lieferanten

Abb. 165: Ursachen für aufgetretene Probleme91 Die Problemursachen werden daraufhin untersucht, ob sie vermeidbar, kaum vermeidbar oder nicht vermeidbar gewesen wären. Insbesondere Maßnahmen für vermeidbare Probleme sind Erfolg versprechend, um künftige Projekte reibungslos abzuwickeln. Im Idealfall fließen all diese Informationen in eine zentrale Know-howDatenbank. Sinnvoll ist es, möglichst schnell nach Projektende ein erstes Meeting zur Informationssammlung anzusetzen, das durch eine zweite Sitzung ergänzt wird, in der man die Ergebnisse bespricht. Neben den abschließenden Treffen sollte man vor allem für Projekte mit einer langen Dauer regelmäßige „Lessons-learned-Meetings“ einrichten.

Welche Aufgaben nimmt das Projektcontrolling wahr? Der Projektcontroller unterstützt den Projektleiter bei der Vorbereitung und Durchführung der Abschlussmeetings. Er fasst die gewonnenen Erfahrungen in einem Abschlussbericht zusammen und unterbreitet Vorschläge zur Verbesserung der Projektabwicklung. Besonders interessant sind solche Erkenntnisse, die man bei der Bearbeitung zukünftiger Projekte verwerten kann, z. B. in welchen Phasen der Aufwand besonders groß ist und wo man mit verbesserten Methoden und Werkzeugen erhebliche Einsparungen erzielen kann. Die Erfahrungen dienen auch zum Aufbau neuer und zur Modifikation vorhandener Checklisten.

91

3UoMeNtFontUoOOeU

XnteUVtt]t

Burghardt, M., Einführung Projektmanagement, München, Erlangen 1995.

201


Wie kann man ein Benchmarking der Projekte vornehmen? Um Problembereiche in der Projektabwicklung aufzudecken, aber auch zur Motivation der Projektverantwortlichen können gleichartige Projekte einem Benchmarking unterworfen werden. Kennzahlen wie die Planabweichung ((Istwert – Planwert) / Planwert), die Fluktuationsquote oder der Overhead-Anteil (nicht projektbezogene Kosten / Gesamtkosten) lassen Rückschlüsse auf Verbesserungspotenziale in einzelnen Projekten zu. Ein besonderes Problem bei einem Benchmarking ist das Erkennen der gegenüberzustellenden Projekte. Eine Klassifizierung nach der Komplexität und Neuartigkeit hilft, die in das Benchmarking einzubeziehenden Projekte zu identifizieren.92 Die Einteilung nach der Komplexität könnte mit der Nutzwertanalyse unterstützt werden (vgl. Abb. 166). Man muss dafür zunächst Kriterien, welche die Komplexität beeinflussen, definieren. Die Kriterien werden gewichtet. Auf dieser Basis beurteilt man die Erfüllung der Komplexitätskriterien bezüglich jedes einzelnen Projektes. So ergibt sich pro Projekt eine Summe aller Punkte. Projekte mit nahe beieinander liegenden Punktwerten gehören einer Komplexitätsklasse an. Kriterien

Gewicht

Erfüllungs-

Kom-

grad

plexität

- Anzahl beteiligter Fachbereiche

30

8

240

- Unterschiedlichkeit der beteiligten Personen

10

5

50

- Anzahl zu erstellender Komponenten

40

4

160

- Technische Besonderheiten

20

6

120

Gesamt

570

Abb. 166: Bewertung der Projektkomplexität Projekte, die ähnlich komplex und neuartig sind, werden gegenübergestellt. Weitere Kriterien, die für die Identifikation vergleichbarer Projekte zugrunde gelegt werden können, sind z. B. gleiche Auftraggeber, gleiche Struktur oder Zuordnung zu gleichen organisatorischen Einheiten.

92

202

Krüger, A., Schmolke, G., Vaupel, R., Projektmanagement als kundenorientierte Führungskonzeption. Stuttgart 1999, S. 220 ff.


3.2.6 Berichtswesen und Dokumentation Die Qualität der Informationsbereitstellung ist entscheidend für die Steuerung und Kontrolle der Projekte. Das Projektberichtswesen muss vor allem drei Kriterien erfüllen: 1. Aktualität •

•

Nur aktuelle Daten ermöglichen aktives Controlling. SollIst-Vergleiche der Leistungs-, Kosten- und Terminsituation müssen z. B. kurz nach Monatsabschluss bzw. nach Erreichen eines Meilensteins vorliegen. Um Aktualität zu gewährleisten, kann man das Berichtswesen nach der Genauigkeit unterteilen: Ungenaue, aber schnell verfügbare „Eilberichte“ ergänzen genaue, aber erst später verfügbare Endberichte.

2. Empfängerbezogenheit •

Je nach Empfänger müssen Berichtsdaten unterschiedlich verdichtet vorliegen: „Die Geschäftsführung erfährt wenig über viel, die Projektleiter erfahren viel über wenig“. Projektleiter

Lenkungsausschuss

Summe

Summe

Geschäftsführung

Summe

Abb. 167: Verdichtung der Informationen im Bericht •

Auch die Darstellung muss sich am Empfänger orientieren. Übersichtliche Tabellen und Diagramme für die Fachabteilung und die Geschäftsführung, komplexe Zahlendarstellungen nur auf Wunsch oder für den Experten.

3. Entscheidungsorientierung •

Um den Bericht interessant zu machen, sollten möglichst nur vom Empfänger beeinflussbare Daten aufgenommen werden und solche, die er für seine Entscheidungen benötigt. Abweichungen sollte man deshalb im Bericht immer einem Verantwortungsbereich zuordnen. 203


•

Viele Berichte sind heute mit Informationen überladen. Ein Bericht darf keine überflüssigen Daten enthalten. Der Grundsatz lautet: „So knapp wie möglich, aber so umfangreich wie nötig“.

Wie sollte das Berichtswesen unterteilt sein? Um die genannten Kriterien zu erfüllen, bietet es sich an, die Berichte in Abweichungs-, Sonder- und Standardberichte zu unterteilen: Abweichungsberichte lenken die Aufmerksamkeit auf Sachverhalte, die einen besonderen Handlungsbedarf erforderlich machen. Sie müssen damit nicht regelmäßig zur Verfügung gestellt werden. Abweichungsberichte werden mittlerweile von vielen DV-Systemen automatisch generiert, um beachtenswerte Datenkonstellationen zu signalisieren. Der Benutzer stellt in der Software Schwellwerte ein, bei deren Überschreiten Hinweissignale ausgegeben werden (vgl. auch Abb. 160 und Abb. 161). Typisch sind so genannte Ampelfunktionen. Liegt eine Abweichung innerhalb der definierten Toleranzschwellen, wird die Farbe grün gewählt. An der Grenze werden Daten gelb und außerhalb des Toleranzbereichs rot angezeigt. Abb. 168 zeigt einen Abweichungsbericht mit Ampelfunktion. Die Toleranzschwelle wurde auf zehn Prozent gesetzt.

Analyse Feinkonzept Realisierung Schulung

Soll 12.000 20.000 21.000 14.000

Abweichung Ist absolut in % 14.000 2.000 17% 22.000 2.000 10% 20.000 -1.000 -5% 13.500 -500 -4%

rot gelb grün

Abb. 168: Ausnahmebericht mit Ampelfunktion Sonderberichte werden nur auf Wunsch geliefert. Ursache für die Anforderung eines solchen Berichts kann z. B. sein, dass Zeitverzögerungen bei einem Entwicklungsprojekt im Detail begründet werden müssen. Standardberichte werden routinemäßig erstellt. Ihr Inhalt ist fest vorgegeben. Es ist geregelt, wer, wann, von wem den Bericht erhält. Eine zentrale Rolle für die Projektsteuerung spielt der Fortschrittsbericht. Fortschrittsberichte sind Standardberichte, welche die Projektausschüsse periodisch in kurzer und prägnanter Art über den Projektstand informieren sollen.

204


Berichtsgegenstand des Fortschrittsberichts sind die Arbeitspakete, Teilprojekte und Meilensteine. Aus den einzelnen Berichtspunkten muss man erkennen, ob alles wie geplant abläuft, welche Abweichungen und welche Probleme existieren oder sich entwickeln könnten. Der Fortschrittsbericht enthält folgende Inhalte (vgl. Abb. 169): • • • • • •

Stand der Arbeiten (Fertigstellungsgrad) und Qualität, Terminsituation, Aufwand, Kosten, Risiken, aufgetretene Probleme und erforderliche Maßnahmen.

Wichtige Aussagen des Fortschrittsberichts sollten auch verbal kommentiert werden. Der Umfang der Kommentierung muss dem Sachverhalt angemessen sein und Fehlinterpretationen von Zahlen vermeiden helfen.

Wie könnte der Fortschrittsbericht aufgebaut sein? Abb. 169 verdeutlicht den Aufbau eines standardisierten Fortschrittsberichts. Ein Deckblatt zeigt die wesentlichen Daten im kompakten Überblick. Die folgenden Seiten dokumentieren die Situation im Detail. Risiko Kosten Aufwand Termine Leistung/Qualität Maßnahmen Probleme Deckblatt . Probleme . Maßnahmen . Leistung/ Qualität

. Termine . Aufwand . Kosten . Risiko

Abb. 169: Inhalte des Fortschrittsberichts

205


Das Deckblatt eines Fortschrittsberichts sollte auf einen Blick die Situation eines Projekts verdeutlichen. Abb. 170 zeigt einen Gestaltungsvorschlag. Wenn die Gesamtsituation (siehe linke Spalte) gut ist, erübrigt sich für den eiligen Leser die Beschäftigung mit den Details des Berichts. Im Beispiel der Abb. 170 ist es dagegen erforderlich, sich weitere Informationen zu beschaffen. Rechts neben der Darstellung der Gesamtsituation erkennt man, dass Termine, Aufwand und Kostenziele signifikant abweichen.

Fortschrittsbericht Projektbezeichnung: ........................ Anlass: Gesamt

Periodischer Bericht Qualität

Plan V-Ist Abweichung Beurteilung Projektleiter:

Projektnummer: ........................... Meilenstein erreicht

Datum .......................... Problembericht

Termin

Aufwand

Kosten

75 Wochen 90 Wochen +15 Wochen

850 P.Wochen 905 P.Wochen +55 P.Wochen

750.000 EUR 800.000 EUR +50.000 EUR

Risiko

Beurteilung Projektcontroller:

Weiteres Vorgehen: Maßnahme 1: ..................................................................................... Maßnahme 2: ..................................................................................... Maßnahme 3: .....................................................................................

Wer? ....................... ....................... .......................

..................................................... Datum, Unterschrift Projektleiter

.................................................... Datum, Unterschrift Controller

V-Ist = voraussichtliches Ist

Bis wann? ....................... ....................... .......................

P.Wochen = Personenwochen

Abb. 170: Deckblatt eines Fortschrittsberichts Für Termine, Aufwand und Kosten werden zudem Planwerte bis Projektende und die die voraussichtlichen Istwerte (auch als Timeat-Completion oder Cost-at-Completion bezeichnet) gegenübergestellt. Aus der Differenz ist die voraussichtliche Abweichung am Projektende ersichtlich. Wenn man weitere Details erfahren möchte, blättert man auf die entsprechende Seite im Bericht (vgl. Abb. 171). Dort wird z. B. der zeitliche Verlauf der voraussichtlichen Abweichung des Aufwands am Projektende in Prozent nach folgender Formel dargestellt: ሺ‫ ݀݊ܽݓ݂ݑܽݐ݉ܽݏ݁ܩ ݎ݄݈݁ܿ݅ݐ݄ܿ݅ݏݏݑܽݎ݋ݒ‬െ ݃݁‫݀݊ܽݓ݂ݑܽݐ݉ܽݏ݁ܩ ݎ݁ݐ݈݊ܽ݌‬ሻ ൈ ͳͲͲ ݃݁‫݀݊ܽݓ݂ݑܽݐ݉ܽݏ݁ܩ ݎ݁ݐ݈݊ܽ݌‬

206


8,00%

Abweichung Auf wand

6,00%

4,00%

2,00%

0,00% Jan

Feb

Mär

Apr

Mai

Jun

Jul

-2,00%

-4,00%

-6,00% Vergangene Monate seit Projektstart Jan Voraussichtlicher Gesamtaufwand Planaufwand gesamt Abweichung Aufwand

815 850 -4,12%

Feb 830 850 -2,35%

Mär 850 850 0,00%

Apr 875 850 2,94%

Mai 895 850 5,29%

Aktueller Monat Jul 885 905 850 850 4,12% 6,47%

Jun

Abb. 171: Voraussichtliche Gesamtabweichung des Aufwands Es wird in Abb. 171 deutlich, dass bis März sogar ein Minderverbrauch prognostiziert wurde. Die Situation verschlechterte sich aber zunehmend. Ohne Maßnahmen wird man gegenwärtig mit 55 Personenwochen zusätzlichem Aufwand rechnen müssen. Die vorhandenen Ressourcen dürften deshalb nicht ausreichen.

Wie häufig wird der Fortschrittsbericht erstellt? Regelmäßige Fortschrittsberichte schaffen Vertrauen in die Qualität des Projektmanagements. Wichtig ist dabei die Festlegung einer angemessenen Berichtshäufigkeit. Um bei den Kosten einen „Kostenblindflug“ zu vermeiden, sind möglichst kurze Berichtsintervalle anzustreben, jedoch nicht so kurz, dass die Differenzen an Bedeutung und Aussagefähigkeit verlieren. Als Daumenregel gilt, dass die Berichtshäufigkeit etwa fünf Prozent der Projektdauer betragen soll. Dies führt bei einem zweijährigen Projekt zu einem rechnerischen Berichtsintervall von fünf Wochen. Da die Unternehmen jedoch in der Regel einen monatlichen Berichtsrhythmus eingeführt haben, bietet sich in diesem Fall ein monatlicher Fortschrittsbericht an.

Tipp

207


Was sollte beim Aufbau des Berichtswesens beachtet werden? Um die angesprochenen Kriterien für ein gutes Berichtswesen zu erfüllen, ist eine Analyse des Informationsbedarfs zusammen mit den Berichtsempfängern nötig. Daraus muss für jeden Bericht eine eindeutige Beschreibung abgeleitet werden (vgl. Abb. 172). Inhalt: Daten: Zeithorizont: Darstellung: Vorlagetermin: Empfänger:

Leistungen, Termine und Kosten; Probleme und Maßnahmen für das Projekt Ist-, Plan- und Solldaten Aktueller Monat und Gesamtprojekt Zahlentabellen und Liniendiagramme Bis zum fünften Werktag des Folgemonats Lenkungsausschuss

Abb. 172: Beschreibung eines Berichts

Welche Inhalte sollte der Abschlussbericht aufweisen? Nach Projektende wird ein Abschlussbericht erstellt, der die Ergebnisse darstellt und den Ablauf des Projekts dokumentiert. Mindestens folgende Gliederungspunkte sollten enthalten sein: • • • • •

Management Summary mit einer Zusammenfassung der wesentlichen Ergebnisse; Status der geplanten Leistungen, Kosten und Termine; Erklärung der Planabweichungen; Erfahrungen und wichtige Punkte; Empfehlungen.

Wie werden die Projektdaten dokumentiert? Bereitzustellen sind wichtige Projektdokumente (Projektauftrag, Pflichtenheft, Projektorganisation, Projektstrukturplan, Terminpläne) und Protokolle der Projektbesprechungen mit den Beschlüssen. Zusätzlich zu empfehlen ist eine Projektchronologie, die im Überblick den zeitlichen Ablauf wichtiger Entscheidungen, Probleme und Maßnahmen festhält. Sinnvoll ist zudem eine kompakte Zusammenstellung der Projekterfahrungen, so dass diese auch in Folgeprojekten genutzt werden können (vgl. Abschnitt 3.2.5). Durch das Aufzeigen und Bewerten bedeutsamer Unterschiede zwischen der Planung und dem Istverlauf bei Kosten, Leistungen und Termi-

208


nen wird ein Lernprozess unterstützt, der hilft, spätere Projekte effizienter abzuwickeln. Die wesentlichen Unterlagen sollten zentral in einer Projektakte, die jedem Beteiligten zugänglich ist, gesammelt werden. Die Projektakte gliedert sich in die • •

Führungsakte mit den Führungsinformationen und Arbeitsergebnisakte mit Zeichnungen, Tabellen, Berichten, Präsentationsunterlagen.

Vor allem bei großen Projekten empfiehlt sich eine elektronische Projektbibliothek. Dies ist ein Dateisystem, das alle im Projektablauf anfallenden Dokumente speichert und verwaltet. Vorteile sind der erleichterte Änderungsdienst, die transparente Dokumentation und die einfache Ermittlung des Projektstands. Für die Projekte der MIS AG gibt es einen Informationspool, in dem das Projektteam alle projektrelevanten Informationen ablegen kann (vgl. Abb. 173). Dies können z. B. Dokumentationen, Protokolle, Präsentationen, Terminübersichten oder Aufgabendokumente sein. Die Gliederungsstruktur der "elektronischen Projektablage“ entspricht dem Standardvorgehensmodell, auf dessen Basis bereits kalkuliert wurde und in dessen Struktur allgemeingültige Informationen und Hilfsmittel in der Know-how-Datenbank hinterlegt sind.

209


Abb. 173: Zwei Auszüge aus einer beispielhaften „elektronischen Projektakte“ 3.2.6.1 Berichtswesen in einem Produktbereich der Robert Bosch GmbH Abb. 174 zeigt eine Übersicht über diejenigen Berichte, die man im Produktbereich Instrumentation Systems des Geschäftsbereichs Car Multimedia der Robert Bosch GmbH erzeugt und von denen einige im Folgenden näher beschrieben werden.

210


Empfänger Berichtsersteller

Berichtsart

Berichtszweck

Berichtsturnus

Geschäftsleitung

Projektcontrolling und Produktbereichscontrolling

Ampelchart, Produktbe- Multiprojektsicht über den Produktbereich zur reichs-Cockpit aller strategischen EinflussProduktbereiche nahme

monatlich

Produktbereichsleitung

Projektcontrolling und Produktbereichscontrolling

Multiprojektsteuerung, Ampelchart, Kenntnissetzung über Meilensteinübersicht, Änderungsmanagement, die Gesamtsituation Darstellung der Forschungs- und Entwicklungskosten

zweiwöchentlich

Projektsteuerkreis

Projektleiter und Projektcontrolling

Projekt-Cockpit, Regelmeetingbericht, Terminplan

Einzelprojektsteuerung im Produktbereich

monatlich

Projektleitung

Projektleiter und Projektcontrolling

Projekt-Cockpit, Regelmeetingbericht, Terminplan

Einzelprojektsteuerung im Produktmanagement

monatlich

Abb. 174: Berichte, Berichtsgremien und Berichtshäufigkeit Projekt-Cockpit Das Projekt-Cockpit ist das zentrale Steuer- und Reportinginstrument für den Projektleiter (vgl. Abb. 175). Dort ist der gesamte Projektstatus graphisch dargestellt. Das Projekt-Cockpit hat zum Ziel, Kosten, Erlöse, Ressourcen, Termine und die Qualitätsrealisierung im Ist und Plan darzustellen und auf mögliche Trends hinzuweisen. Die Daten des Projekt-Cockpits werden monatlich aktualisiert. Der Projektcontroller unterstützt den Projektleiter bei der Datenaufbereitung und stellt ihm die Daten aus SAP R/3 zur Verfügung. Der Projektleiter stellt das Projekt-Cockpit monatlich dem Projektsteuerkreis vor.

211

212

SAP Projektverfolgung Meilensteine (Plan, Ist)

Organisation, Status

Entwicklungskosten (Plan, Budget, Ist, Obligo) Kosten für Neuteile (Plan, Budget, Ist, Obligo) Kosten im Werk (Plan, Budget, Ist, Obligo)

Projektdaten

MS-Project - Terminplan

Cycletime-Punkte (Plan, Ist)

Betriebsergebnis

Manuelle Datenbeschaffung

Qualitätsbewertung

Ressourceneinsatz (Plan, Ist)

Absatz, Umsatz, Betriebsergebnis, Stoff, Wertschöpfung, Deckungsbeitrag

Projektrechnung


Abb. 175: Darstellung des Projekt-Cockpits


Projektleiter und Projektcontroller prüfen die Daten gemeinsam auf Plausibilität. Wie man Abb. 175 entnehmen kann, zeigt das ProjektCockpit folgende Projektsteuergrößen auf: Auf der linken Seite werden über einen vom Projektcontroller monatlich durchgeführten manuellen Download aus dem Modul PS des SAP-Systems die Projektkosten zum Zweck der Kostenverfolgung (Plan gegenüber Ist) dargestellt. Budgetüberschreitungen können damit aufgezeigt und deren Ursachen näher analysiert werden. Verfolgt werden die Größen Entwicklungs-, Muster- und Werkzeugkosten. Der oberste mittlere Bereich gibt einen Auszug der zugehörigen Projektrechnung wieder, der zu den wichtigen Meilensteinen aktualisiert werden muss. Die Projektrechnung ist eine klassische Deckungsbeitragsrechnung, in der das Betriebsergebnis über die gesamte Projektlaufzeit ermittelt wird. Datenlieferant ist die Controllingabteilung, da eine Gesamtsicht zur Erstellung der Projektrechnung erforderlich ist. Die Darstellung des Projektfortschritts mit Hilfe von Projektcycletime-Punkten ist in der mittleren Spalte in der Mitte des ProjektCockpits realisiert. Die Daten stammen aus der zugehörigen Meilenstein-Terminplanung. Die Sachfortschrittskontrolle stellt für den Entwickler und Projektleiter wohl die wichtigste Kontrollaufgabe dar. Die Kernfrage der Sachfortschrittskontrolle ist immer, ob zu den aufgewendeten Kosten die äquivalente Leistung vorliegt. Im Produktbereich wird zur Bestimmung des Projektfortschritts die 0/100-Methode angewendet, d. h., nur zu 100 Prozent abgeschlossene Arbeitspakete werden dem Projekt gutgeschrieben (vgl. Abschnitt 3.2.2). Der Fortschritt wird monatlich geprüft. Die Beurteilung, d. h. die Punktevergabe je Arbeitspaket, liegt im Ermessen des Projektleiters. Die Meilenstein-Trendanalyse wird im mittleren Feld unten dargestellt. Das rechts oben integrierte Mitarbeitereinsatzdiagramm soll den graphischen Verlauf der Plan- und Ist-Daten aus der Ressourcenplanung und -verfolgung darstellen. Dabei wird auf Mitarbeiterunterbzw. Mitarbeiterüberdeckungen hingewiesen. Die Plan- und Istwerte überträgt der Projektleiter aus dem Planungstool zur Ressourcenplanung in das Mitarbeiter-Eingabeblatt des Projekt-Cockpits. Im Anschluss erfolgt eine automatische Datenübertragung in die Graphik. Das rechts außen in der Mitte positionierte Qualitätsbewertungsdiagramm zeigt den graphischen Verlauf der tatsächlichen Erfüllung derjenigen Meilensteintermine, die eine Qualitätsbewertung vorse-

213


hen. Deren Erfüllung ist zwingend erforderlich, um in die nächste Projektphase eintreten zu können. Dabei wird überprüft, wie oft Qualitätsbewertungen durchgeführt worden sind und wie viele davon mit Erfolg bzw. Nichterfolg abgeschlossen haben. Das Betriebsergebnis-Diagramm auf dem unteren, rechts außen angeordneten Feld verdeutlicht den Verlauf des Ist-Betriebsergebnisses aus der Projektrechnung. Man kann es in Prozent über die gesamte Laufzeit beobachten und sich bei Fehlentwicklungen Rationalisierungspotentiale zur Aufbesserung überlegen. Regelmeetingbericht Der vorliegende Projektbericht (vgl. Abb. 176) dient als Berichtsund Steuerungsdokument für den Projektleiter. Er verdeutlicht in übersichtlicher Form alle wesentlichen Daten zum Status des Projektes in Ampelsystematik. Aufgezeigt werden hier die Stati Kunde, Termine, Qualitätsbewertung (QB), Ressourcen, Entwicklungs- und Werkzeugkosten (EEKO/EWAK) und das Betriebsergebnis (BE). Daneben gibt der Regelmeetingbericht auch Auskunft über aktuelle Aktivitäten, die im Projekt durchzuführen sind. Außerdem werden auftretende Projektrisiken während der Projektlaufzeit und die dafür vorgesehenen Maßnahmen dokumentiert. Abschließend werden Hinweise auf die Projektentwicklung gegeben. Dieser Bericht gewährleistet die Einheitlichkeit der Projektdarstellung über alle Projekte. Die Statusinformationen werden monatlich in der Projekthistorie festgehalten, damit zum einen die Dokumentationspflicht erfüllt ist und zum anderen aus den Fehlern und Erfolgen der Vergangenheit für andere Projekte profitiert werden kann. Die Statusinformationen des Regelmeetingberichts werden für das Multiprojektmanagement im so genannten Ampelchart aufbereitet. Der Projektcontroller prüft die Daten auf Plausibilität. Der Projektleiter berichtet sie monatlich vor dem Projektsteuerkreis.

214

Y

Problem / Risiko

Maßnahme / Sonderaktion

Aktueller Projektfortschritt (Festlegungen, Aktivitäten):

Der Ressourcenbedarf ist abgeschätzt. Aber zu wenig Entwickler sind verfügbar

Status EEKO +EWAK

:

Verantwortlich

G

G

Status Termine

01.03.2005 G

i.O

Status BE

Y

G

zum Erstmuster mit EMPB

Status Ressourcen

Status QB

02.12.2002

Terminziel sind realistisch!

Y

M1 :

zum nächsten Meilenstein 25

zur aktuellen Woche

Lastenheft ist lückenhaft Die Anforderungen sind nicht vollständig bekannt

Status Kunde

Berichtshorizont

KW:

Regel-Meeting Bericht (PSS)

Projekt:

Bosch CM-IS

erledigt bis

Trend:

20.06.2002

Letzte Änderung

G

G

PrL: Mustermann, P-Nr.: 10111


Abb. 176: Regelmeetingbericht

215


In Abb. 177 wird die Bedeutung der Ampelfarben in den Kategorien Kunde, Qualitätsbewertung, Termine, Entwicklungs- und Werkzeugkosten, Betriebsergebnis und Ressourcen erklärt. Die Einstufung der Farben erfolgt nach subjektiver Einschätzung des Projektleiters. Rot

Gelb

Grün

Kunde

Probleme in der Zusammenarbeit; Einwirken der Geschäftsleitung erforderlich

Die Probleme in der Zusammenarbeit können durch den Projektleiter behoben werden.

Gute Zusammenarbeit mit dem Kunden; der Kunde ist zufrieden.

Qualitätsbewertung (QB)

Letzte QB wurde nicht bestanden; es findet eine Wiederholung statt

Bestehen der zukünftigen QB kritisch; wird aber nicht gesetzt, da laut Vereinbarung mit der Geschäftsleitung nur das Ergebnis der letzten QB dargestellt werden soll

Letzte QB bestanden

Termine

Termine sind überschritten; Unterstützung der Geschäftsleitung erforderlich

Termine sind überschritten; der Projektleiter hat mit dem Kunden neue Termine abstimmen können.

Termine verlaufen nach Plan

Ressourcen

Ressourcen sind zu knapp und keine Einstellung möglich; Entscheidung der Geschäftsleitung erforderlich

Ressourcen sind zu knapp; es konnten andere Mitarbeiter kurzfristig für das Projekt intern gewonnen werden.

Ressourcen sind ausreichend

Entwicklungsund Werkzeugkosten (EEKO/EWAK)

Werte liegen über Plan und werden voraussichtlich über Plan bleiben (z. B. keine Kompensation über Kundenzahlungen möglich)

Werte liegen über Plan, werden aber bis Projektende wieder im Plan liegen (z. B. Erhöhung wegen Kundenänderungen)

Beide Werte sind unterhalb oder im Plan.

Betriebsergebnis (BE)

Der Prozentwert liegt unterhalb der festgelegten Mindestgrenze.

Der Prozentwert liegt zwischen der festgelegten Unter- und Obergrenze.

Der Prozentwert liegt über der festgelegten Obergrenze.

Abb. 177: Ampelfarbenbelegung Auch die Gesamtsituation des Projektes wird mit Ampelfarben verdeutlicht. Die Regeln für die Belegung können vom Kunden vorgegeben werden. Abb. 178 zeigt ein konkretes Beispiel für solche Regeln.

216


Ampelfarbe

Regel

rot

Projektziel nicht mehr erreichbar; Auswirkungen auf Gesamtprojekt Projektziel wird nicht erreicht; mit Auswirkungen in Teilbereichen Projektziel wird nicht erreicht; derzeitige Maßnahmen greifen nicht; Chancen erkennbar

gelb

Projektziel kann durch eingeleitete Maßnahmen erreicht werden, jedoch sind Risiken vorhanden Projektziel wird durch eingeleitete Maßnahmen erreicht; permanente Überprüfung Projektziel wird mit abgesicherten Maßnahmen erreicht

grün

Projektziel wird sicher erreicht; Maßnahmen sind nicht notwendig Projektziel wird genau erreicht Projektziel wird übertroffen

Abb. 178: Belegung der Ampelfarben nach vorgegebenen Regeln Wochenbericht Der Wochenbericht ist eine Variante des Regelmeetingberichtes. Er ist auf Wunsch des Kunden Daimler AG entstanden und kann natürlich auch bei anderen Kunden Anwendung finden. Dieser Wochenbericht ist aber nicht obligatorisch für das Einzelprojektcontrolling. Er stellt vielmehr einen Bedarfsbericht dar, der vom Kunden gefordert und vom Projektcontrolling entsprechend seinen Wünschen individuell angepasst werden kann. An dieser Stelle kann man erkennen, dass das Projektcontrolling innovativ ist und den Reportinganforderungen des Kunden gerecht werden will. Das Reportingtool bietet viel Spielraum für die Anpassung der Berichte. Der Wochenbericht ermittelt den Status im Gegensatz zum Regelmeetingbericht auf der Grundlage der Daten aus den Fachbereichen. Deswegen beruht die Einschätzung der verschiedenen Stati nicht allein auf der subjektiven Einschätzung des Projektleiters, sondern berücksichtigt die Meinung der anderen Projektbeteiligten. Der Wochenbericht setzt sich aus zwei Vorlagen zusammen. Abb. 179 gibt den Gesamtstatus auf einen Blick wieder und wird aus der Eingabevorlage der Fachbereiche automatisch generiert.

217

Status Teilprojekt zum Aktuellen Termin

218

Beurteilung des Teilprojektes basierend auf drei Zeithorizonten

Status Teilprojekt zum nächsten Meilenstein

Status Teilprojekt zum Erstmusterprüfbericht


Abb. 179: Wochenbericht


Berichtet wird zweiwöchentlich an den Kunden durch den Projektleiter. Der Projektcontroller unterstützt wieder bei der Datenaufbereitung. Änderungserfolgsrechnung Die Änderungserfolgsrechnung ist ein weiterer Bestandteil der Projektmappe und besteht aus den Berichten in Abb. 180 und Abb. 181. Sie unterstützt das Änderungsmanagement im Projekt und sammelt, dokumentiert und bewertet alle Informationen über Kosten, Investitionen und Erlöse nach Auftragsvergabe vom Kunden. Somit kann die Auswirkung jeder Änderung, ob intern oder extern veranlasst, auf das Projektergebnis bewertet werden. Wenn eine Änderung keinen positiven Beitrag zur Ergebnisverbesserung aufweist, ist sie abzulehnen.

219


Abb. 180: Dokumentation von Änderungen

220


Abb. 181: Änderungserfolgsrechnung 221


Abb. 180 zeigt, welche Änderungen mit welchen Stati zu welchen Kosten geplant sind. Abb. 181 veranschaulicht, wie sich die geplanten Projektkosten unter Berücksichtigung der Änderung entwickeln. Gegenübergestellt werden die mit dem Kunden abgestimmten Planerlöse und die Wirkung auf das Betriebsergebnis. Diese Änderungserfolgsermittlung je Projekt dient zur Generierung des Multiprojektberichtes Änderungserfolgsmanagement (vgl. nächste Seite). Der Projektcontroller berichtet monatlich an die Geschäftsleitung über den zugehörigen Multiprojektreport. Um steuernd in das Änderungsmanagement eingreifen zu können, selektiert das Projektcontrolling monatlich all diejenigen Änderungsumfänge, für die noch keine Erlösdaten eingetragen sind und/oder deren Abstimmung mit dem Kunden drei Monate nach Datum des Änderungseintrages noch nicht abgeschlossen ist, geordnet nach Kunden und Projekten. Der Projektcontroller sammelt die Daten ein, um ein vollständiges Änderungsmanagement zu gewährleisten und damit die notwendigen Entscheidungen durch das Management zu erleichtern. Die zugehörigen Projektmappen können jederzeit online geöffnet werden, falls nähere Informationen erforderlich sind und der Gesamtstatus für die Geschäftsleitung nicht ausreichend ist. Der jeweils aktuelle Änderungsstatus dient auch dem Projektteam bei Steuerkreis-Meetings zur Darstellung des zeitnahen und wirtschaftlich erfolgreichen Änderungsmanagements sowie zur Anpassung des Projektauftrags, um z. B. zusätzliches Entwicklungsbudget zu erhalten. Desweiteren dient er den Ressourcen-Ownern zur Sicherstellung der Ressourcen und der Gegenfinanzierung erbrachter Mehrleistungen bei Überschreitungen der genehmigten Budgets. Im Folgenden werden die Reports für das Multiprojektcontrolling dargestellt. Die Multiprojekt-Übersichten, die durch das Projektcontrolling generiert werden, enthalten die wichtigsten Projektstammdaten sowie die wesentlichen Erfolgskennzahlen der Projekte. Berichtet wird in einem monatlichen Rhythmus an die Geschäftsleitung auf den verschiedenen Hierarchiestufen. Ampelchart Die Daten der Einzelprojekte mit der Ampelstellung und dem Kommentar aus dem Regelmeetingbericht werden auf die Multiprojektebene verdichtet. Aufgezeigt werden alle Entwicklungsprojekte mit ihren zugehörigen Steuergrößen in der Ampelsystematik. Bei roten und gelben Projektstati müssen die zugehörigen Ursachen erläutert und die vorgesehenen Maßnahmen aus dem Regelmeetingbericht zur Problembeseitigung dargestellt werden. Hinweise auf die 222


nächsten wichtigen Meilensteintermine und deren Realisierbarkeit werden ebenfalls durch Ampelfarben verdeutlicht. Das Management kann auf Grundlage des Ampelcharts die kritischen Projekte anzeigen lassen und diese gesondert verfolgen. Damit ist es in der Lage, mit einem Blick die Probleme und Erfolge im Projektmanagement zu erkennen. Das Projektcontrolling berichtet im monatlichen Rhythmus an die Produktbereichs- und die Geschäftsbereichsleitung und stellt die Daten für die Entscheider auf den weiteren Hierarchiestufen zur Verfügung. Änderungserfolgsmanagement Die Änderungsübersicht zeigt die intern oder extern verursachten Änderungen über alle Projekte im Projektmanagement. Über die eingebauten Filterfunktionen lassen sich unterschiedlichste Auswertungen erzeugen, z. B. dass ein Änderungsangebot seit mehr als drei Monaten beim Kunden ist und noch keine Abstimmung mit ihm über die Auftragsvergabe vorliegt. Obwohl die Geschäftsleitung den Status des Änderungsmanagements monatlich erhält, ist das Änderungserfolgsmanagement ein typischer Bedarfsbericht, da der Report den Wünschen der Geschäftsleitung anhand der Filterfunktionen entsprechend angepasst wird, um verschiedene Aussagen generieren zu können. Der Projektcontroller stellt die Summe der Änderungskosten und -erlöse ebenfalls monatlich den Berichtenden für die Geschäftsbereichsleitung zur Verfügung. Meilensteinübersicht Aufgezeigt werden die wichtigsten Termine der Meilensteinterminplanung über alle Projekte, um auf Terminüberschreitungen rechtzeitig hinzuweisen oder Termine frühzeitig mitzuteilen, bei denen die Anwesenheit der Geschäftsleitung erforderlich ist, wie z. B. bei Qualitätsbewertungen von Projektentwicklungen zu bestimmten Projektphasen. Um Signalfunktionen zu erfüllen, bedient man sich hier ebenfalls der Ampelsystematik. Außerdem wird eine Vorschau auf die nächsten Meilensteintermine pro Projekt gezeigt. Schließlich werden die Produktionsstarttermine der jeweiligen Projekte nach Entwicklungsabschluss dokumentiert und vom Projektcontroller monatlich an die Geschäftsleitung des Produktbereiches berichtet.

223


3.2.6.2 Berichtswesen der Outokumpu Technology GmbH Zeitlicher Ablauf Um eine aktuelle und mit den Periodenabschlüssen synchronisierte Darstellung des Auftragsbestandes zu gewährleisten, hat sich eine Festlegung von Aktivitäten innerhalb des Monatsablaufs bewährt (vgl. Abb. 182).

Erfassung Stundenschreibung

Aktualisierung Kapazitä tsplan Kostenstellen

Verteilung Auswertungen an Projektmanager

Aktualisierung Projektstundenplanung

27. Vormonat

5. Arbeitstag

7. Arbeitstag

27. Lfd. Monat

Aktualisierung Kostenerwartung in SAP

Monatsabschluss in SAP (HGB)

Endgültiger Monatsabschluss

30. Vormonat

1. Arbeitstag

6. Arbeitstag

Projekt Statusbericht 19.-25.lfd. Monat

Erstellung IAS/US-GAAP-Abs chluss

Offizieller Monatsbericht

2. Arbeitstag

7. Arbeitstag

ProjektReviewMeetings 10.-19. Lfd. Monat

Controlling Besprechung 25.-28. Lfd. Monat

Abb. 182: Schematisierter Ablaufplan der Controlling-Aktivitäten Über den gesamten Monatsverlauf werden die Drittkosten sowie die Stundenplanungen für alle Aufträge kontinuierlich aktualisiert. Vor dem Ende der Periode werden die im Monat angefallenen Stundenleistungen und die aktualisierten Stundenplanungen aus den entsprechenden Datenbeständen an den Auftragsbestand innerhalb des SAP-Systems übertragen. Eine Durchsicht aller Projekte erfolgt am letzten Arbeitstag eines Monats. Im Anschluss werden die Abschlüsse gemäß HGB und IAS innerhalb des Rechnungswesens und Unternehmenscontrollings vorgenommen. Nach Abgabe des Monatsberichts werden die Projektleiter mit einem Berichtspaket über den Stand ihrer Projekte informiert und entsprechend der Festlegung mit dem Leiter Projektmanagement zur Berichterstattung aufgefordert. Die Projektcontroller leisten Unterstützung bei der Erstellung der Projektberichte, die nach einem einheitlichen Format erstellt werden, welches Teil der Unterlagen für die Steuerungsgremien ist. Im Anschluss an diese Auftragsdurchsprachen wird in einer Controllingbesprechung die Abstimmung zwischen den beteiligten Abteilungen, dem Projektcontrolling, der kaufmännischen Projekt224


abwicklung sowie dem Unternehmenscontrolling durchgeführt. Dies dient der Koordination der kaufmännischen Aufgaben und darüber hinaus der Vorbereitung von Quartals- und Jahresabschlüssen. Reporting und Kennzahlen Die im Projektcontrolling verfolgten und geplanten Daten entsprechen der schon in der Kalkulation geplanten Struktur von Kennzahlen: • • • • • •

Planerlös (im Kundenauftrag fix mit Ausnahme von Change Orders), auftragsdirekte Drittkosten (entsprechend der Kalkulation nach Kostengruppen), Leistungen (Eigen- und Fremdleistungen, stundenbasiert oder pauschal ermittelt), Risikovorsorge (gemäß der individuellen Risikoanalyse), Deckungsbeitrag, Projekt- und Finanzergebnis (gemäß Cash Flow-Planung).

Entsprechend dieser Kennzahlenstruktur werden die jeweiligen Werte der Startkalkulation mit den Vorgabewerten nach Berücksichtigung von Change Orders sowie den aktuellen Erwartungswerten verglichen. Abweichungen werden absolut sowie als Prozentwerte analysiert. Zur Darstellung der Fortschrittssituation werden angefallene Kosten, Leistungen und Bestellwerte sowie offene Positionen ausgewiesen. Ein Schwerpunkt der Controlling-Aktivitäten liegt in der Steuerung von Ressourcen, also der Planung und Verfolgung der Eigen- und Fremdleistungen innerhalb der Projekte. Hierzu ist innerhalb der operativen Projektsteuerung eine enge Verknüpfung von Kosteninformationen und Stundenleistungen notwendig. Berichtsmodell des Projektcontrollings Zur Information der unterschiedlichen Interessengruppen innerhalb und in Ausnahmefällen auch außerhalb der Organisation wurde ein mehrstufiges Reportingmodell etabliert (vgl. Abb. 183). Die Adressaten sollen durch standardisierte und gezielte Information in die Lage versetzt werden, sich eine schnelle und aktuelle Übersicht der Entwicklung zu verschaffen. Neben den innerhalb des SAP-Standard-Informationssystems zur Verfügung stehenden Berichten hat es sich als notwendig erwiesen, weitere Projektberichte zur Verfügung zu haben. Aus diesem Grund wird bis heute eine Reihe von selbst entwickelten Reports genutzt, die integrierte Informationen aus allen eingesetzten Modulen für die Aufgaben der Projektsteuerung zur Verfügung stellen. 225


Zielgruppe

Bericht

Kenngrößen

Geschäftsführung

Übersicht aller Aufträge in Abwicklung und in Gewährleistung

Steuerungsgremium

Projektbericht

Projektleitung

Projektbericht, Bericht nach Kostengruppen, Bericht nach Stundenbudgets, Cash Flow, u. a. Budgetberichte, Auslastung der Disziplin

Auftragswert, Drittkosten gesamt, Risikovorsorge, Gesamtstunden, Auftragsergebnis, Vorgabegröße, Erwartungswert, Änderungen zur Vorperiode siehe oben, zusätzliche Informationen zu Änderungen und zum Abwicklungsfortschritt siehe oben, zusätzliche Informationen zu Einzelbudgets, Änderungen, Fortschrittswerten sowie Kurztext

Bereichs- und Abteilungsleitung Projektcontrolling

alle Berichte, Arbeitsberichte zur Analyse von Einzelpositionen für Kosten, Erlöse und Stundenleistungen

insbesondere Daten zur Budgetsituation und Auslastung alle Informationen der Abwicklung aus den Bereichen Planung, Beschaffung, Buchhaltung, Änderungsdienst, Stundenmanagement, u. a.

Abb. 183: Kategorien für Projektberichte

Berichte Der Projektmonatsbericht (vgl. Abb. 184) findet bei großen Aufträgen Anwendung und dient im Wesentlichen zur Information der Steuerungsgremien. Bestandteil sind eine zusammenfassende Projektbeschreibung sowie Daten zum Arbeitsfortschritt, zu Meilensteinen, Finanzstatus und Auftragsgarantien auf einem Deckblatt sowie eine einseitige Darstellung der Kennzahlen des Projektcontrollings. Für den Fall, dass Partner an der Auftragsabwicklung beteiligt sind, wird die Zusammenfassung der Kennzahlen für jeden Beteiligten separat erstellt sowie ein Summenblatt für den Gesamtprojektstatus beigefügt. Hierdurch wird eine einheitliche Projektübersicht unabhängig von verschiedenen Währungen oder Berichtsformaten gewährleistet.

226


Im Projektkostenbericht (vgl. Abb. 185) werden im Unterschied zum Monatsbericht neben den wichtigsten Kenngrößen für Drittkosten auch alle Kostengruppen dargestellt. Eine Variante des Berichts liefert zusätzlich eine Aufspaltung der Leistungen nach Fachdisziplin. Dieser Bericht liefert den Projektverantwortlichen eine schnelle Gesamtübersicht und erste Anhaltspunkte über Einzelabweichungen, die dann in detaillierteren Reports untersucht werden können. Der Einzelpostenbericht (vgl. Abb. 186) generiert Informationen über alle Planänderungen, Kostenbuchungen sowie Bestellpositionen pro Kalkulationsposition. Er stellt somit das wichtigste Werkzeug dar, um Einzelabweichungen abschließend zu analysieren. Mittels der in SAP zur Verfügung stehenden Verzweigung zum Einzelvorgang können Buchungs- oder Bestellbelege sowie Eingaben von Planwerten angezeigt und entsprechenden Bearbeitern zugeordnet werden. Zur Analyse der Leistungen in Projekten existieren verschiedenste Stundenberichte (vgl. Abb. 187), die eine detaillierte Untersuchung von Stundenleistungen pro Disziplin, Einzelpersonen und Periode zulassen. Auch hier finden die Kennzahlen für Budget, Vorgabe sowie Erwartungswert analog zur Kostenanalyse Anwendung.

227


Abb. 184: Deckblatt Projektmonatsbericht

228


Abb. 185: Projektkostenbericht 229


Abb. 186: Einzelpostenbericht

230


Abb. 187: Stundenbericht 231


3.2.6.3 Berichtswesen der Zurich Gruppe Deutschland Um Transparenz über den Fortschritt aller Initiativen93 zu haben, gibt es regelmäßig ein übergreifendes Reporting, welches vom zentralen Controlling entwickelt und verantwortet wird. Es dient als Grundlage für die Entscheidungsprozesse über alle Initiativen. Der Berichtsrhythmus in der Zurich Gruppe Deutschland variiert zwischen monatlich und quartalsweise. Für die internationalen Initiativen erfolgt das Reporting des Initiativenfortschritts im monatlichen Rhythmus. Die Initiativen berichten direkt – in enger Abstimmung mit den Sponsoren – an das zuständige Project Office. Dort erfolgt eine Weiterverarbeitung und Aggregation der Informationen an das zuständige Steering Committee. Die Entscheidungen aus dem Steering Committee sowie der Report über das gesamte Initiativenbündel94 wird dann an das zentrale Controlling weitergegeben. Initiativenbündel, die keine Instanz „Steering Committee“ haben, berichten direkt an das zentrale Controlling. Bei den internen Initiativen erfolgt ein quartalsweises Reporting über das Project Office direkt an das zentrale Controlling. Im zentralen Controlling werden dann alle Informationen aus den einzelnen internationalen und nationalen Initiativenbündeln zu einem managementorientierten Report für den Gesamtvorstand zusammengefasst. Der Report enthält insgesamt zwei Dimensionen. Im Fokus stehen zunächst die finanziellen und wirtschaftlichen Kennzahlen. Zu den Größen zählen Verbesserungen des operativen Ergebnisses (BOP = Business Operating Profit; NIAT = Net Income after Tax), die im Rahmen einer Wirtschaftlichkeitsberechnung ermittelt werden (vgl. Abb. 188). Daneben stehen sämtliche organisatorische Effekte, die über den gesamten Sachfortschritt der Initiative, die Realisierungswahrscheinlichkeit, Schnittstellen sowie den Fortschritt der einzelnen Meilensteine, Risiken, Termine, etc. Auskunft geben. 93

94

232

Unter Initiativen versteht man in der Zurich Gruppe Deutschland alle wertigen Vorhaben, die zur Ausrichtung, Erneuerung und Performancesteigerung des Unternehmens dienen. Projekte sind nach diesem Verständnis nur eine Teilmenge der Initiativen. Ein Initiativenbündel umfasst themenverwandte, sich gegenseitig ergänzende Initiativen/Projekte, die abgestimmt werden müssen. Es gibt sieben Initiativenbündel: z. B. Prozessoptimierung, Personalentwicklung, Optimierung des Produktportfolios.


Durch diesen Ansatz wird der von den einzelnen Initiativen zu erstellende Report auf die wesentlichen Punkte konzentriert. Für die oben genannten Aspekte sind Planwerte, Status, Prognose und Istwerte anzugeben. Das Project Office prüft die einzelnen Fortschrittsberichte der Initiativen und erstellt eine managementorientierte Zusammenfassung über das Initiativenbündel inkl. einer übergreifenden Einschätzung. Auf dieser Grundlage generiert dann das zentrale Controlling regelmäßig ein Reporting über sämtliche Initiativen und Bündel, in dem alle Berichte der einzelnen Project Offices über die jeweiligen Initiativenbündel zusammengestellt und analysiert werden. Es obliegt dem zentralen Controlling, weitere Betrachtungen vorzunehmen, auf Widersprüchlichkeiten hinzuweisen, Handlungsvorschläge zu erarbeiten und die Gesamtwirkung von Programmen und Bündeln nachvollziehbar darzustellen. Der Empfänger dieser Entscheidungsvorlage ist, wie bereits erwähnt, der Gesamtvorstand. Planung und Reporting in zwei Dimensionen:

finanzielle Wirkung gemessen in NIAT-/BOP-Impact und weiteren Größen

organisatorische Voraussetzungen Meilensteine, Termine, Tätigkeiten

Plan wird auf Monatsebene für das laufende Jahr und auf Quartalsebene für Folgejahre festgeschrieben.

Monatliche Gesamteinschätzung zum Status jeder Initiative (inkl. Realisierungswahrscheinlichkeit).

Monatlicher Plan/Forecast-Vergleich auf Gesamtjahresende.

Monatliches Update zum inhaltlichen Fortschritt und zur Termineinhaltung auf Meilensteinbasis.

Plan/Ist-Vergleich jeweils auf Monatsbasis für das laufende Jahr.

Abb. 188: Planungs- und Reportingdimensionen der Zurich Gruppe Deutschland

233


3.2.6.4 Fortschrittsbericht der Lufthansa Systems ProControl ist das bei Lufthansa Systems eingesetzte Tool zur Erstellung von Projektstatusberichten. Es stellt das zentrale Bindeglied zwischen der Erfassung von Aufwänden, Kosten und Erträgen im SAP-System und der Verfolgung der zugrunde liegenden Leistungen in den einzelnen Projekten dar. ProControl erhält Informationen aus den Projektverfolgungsunterlagen des Projektleiters und den Projektstrukturplan-Elementen des SAP-Systems. Alle Informationen aus ProControl stehen dem Projektleiter direkt über den ProControl Client zur Verfügung. Alle anderen Controllinginstanzen benutzen das ProControl-Frühwarnsystem. Technischer Aufbau des Systems Um eine universelle Nutzbarkeit des Tools ProControl zu gewährleisten, wurde darauf geachtet, nur Standardkomponenten zu verwenden, die auf allen PC-Clients bei Lufthansa Systems vorhanden sind. Eingesetzt werden MS Excel, MS Exchange und MS Access. ProControl selbst besteht aus zwei Komponenten: 1. ProControl-Client Mit ihm werden die Stamm- und Bewegungsdaten für die Statusberichte gepflegt. Außerdem dient er zur Anzeige und zum Druck der Statusberichte. 2. ProControl-Server Er speichert auf einer zentralen Datenbank alle Statusberichte, kommuniziert mit dem SAP-System, handelt die UserVerwaltung und füttert das Frühwarnsystem mit Daten. Die Kommunikation zwischen ProControl-Client und ProControlServer wird über das zentrale Mailingsystem MS Exchange sichergestellt. ProControl-Client (vgl. Abb. 189 bis Abb. 192) Der ProControl-Client unterstützt die Projektleiter bei der Erstellung von standardisierten Statusberichten für Projekte bzw. Teilprojekte. Er übernimmt die Kommunikation mit dem ProControl-Server via Mail-System und stellt von diesem gelieferte Eingabemasken und Statusberichte zur weiteren Bearbeitung bereit. Der erste Schritt bei der Erstellung eines Projektstatusberichts ist die Projektdefinition. Dazu stellt der ProControl-Client auf Anforderung eine Maske zur Verfügung, die man zunächst unter dem jeweiligen

234


Projektnamen speichert. In dieser neuen Projektmappe definiert man das Projekt/Teilprojekt und hinterlegt die Projektplanung. Das Senden der Projektdefinition an den ProControl-Server veranlasst diesen, die Eingaben zu prüfen und das Projekt nach Möglichkeit anzulegen. Falls das Anlegen des Projektes scheitert, erhält der Projektleiter nur eine Fehlerliste. Im Erfolgsfall dagegen bekommt der Projektleiter eine Nachricht und eine Projektmappe mit den aktuellen Istwerten. Nach der Projektdefinition, auf Anforderung und nach jedem Monatsabschluss wird dem Projektleiter automatisch eine Projektmappe mit den aktuellen Istwerten und Prognosen zugesandt. Nach einer Überprüfung und ggf. Änderung der Prognosen und einer Ergänzung der Daten für die externen Mitarbeiter kann der Statusbericht angefordert werden. Der Projektstatusbericht besteht aus Projektdefinition, Projektplanung, aktuellen Istwerten und Summary I bis III. Aus ihm sind alle durch den Projektleiter anzugebenden Kennzahlen und Werte ersichtlich. Der Projektstatusbericht dient als Unterlage, um den Projektfortschritt mit dem Projektleiter zu besprechen. Ist der Projektstatusbericht fertiggestellt und sollen keine weiteren Änderungen daran vorgenommen werden, so muss der Projektleiter den Bericht bestätigen. Mit der Bestätigung wird der Bericht vom ProControl-Server archiviert und ist dann nicht mehr änderbar. Alle archivierten Projektstatusberichte sind im Frühwarnsystem abrufbar. Neben der Erstellung und Verwaltung von Projektstatusdaten benötigt ProControl zusätzliche Verwaltungsinformationen. Es handelt sich um die Pflege von Stellvertreterinformationen und um einige wenige Client-bezogene Einstellungen auf dem PC. In der Stellvertreterliste kann der Projektleiter bis zu zehn Stellvertreter benennen, die für seine Projekte die Statusberichte anfordern und bearbeiten dürfen. Diese Liste kann jederzeit geändert und durch Senden an den ProControl-Server aktiviert werden. Beim erstmaligen Start des ProControl-Client müssen die Programmeinstellungen, vor allem das Verzeichnis für die Arbeitsmappen und der Excel-Pfad, überprüft werden. Zu beachten ist hierbei insbesondere, dass die ProControl-MailAdresse nur auf Anweisung des Systemadministrators geändert werden darf, da sonst der Kommunikationsweg zwischen ProControlServer und ProControl-Client gestört würde.

235


Abb. 189: ProControl-Client (1 von 4)


236




237


ProControl Frühwarnsystem (vgl. Abb. 193 bis Abb. 194) Das Frühwarnsystem ermöglicht den Nutzern einen Überblick über alle freigegebenen Projektstatusberichte und zeigt die wesentlichen Projektkennzahlen im Überblick. Grundlage der Darstellung sind die Daten, die im SAP-System gespeichert sind, und die Informationen, die die Projektleiter aufgrund ihrer Kenntnis über Projektstatus und Projektfortschritt als Prognose eingegeben haben. Das Frühwarnsystem vergleicht die betriebswirtschaftlichen Kennzahlen eines Projekts mit dem Projektplan und stellt die Abweichung farblich dar. Über eine Definition von Grenzwerten lässt sich diese Kennzeichnung beeinflussen. Voraussetzung für das Anfordern von Projektdaten ist ein aktives Mail-System. Der ProControl-Server sendet die neuen/alle Projektinformationen für den angegebenen Account bzw. das angegebene CompetenceCenter, wenn vom Administrator die Freigabe für den entsprechenden Bereich vorliegt. Der Ampelbildschirm reagiert kontextsensitiv. So können mittels Mausführung vom Projektleiter hinterlegte, projektbezogene Informationen sichtbar gemacht werden. Der dazugehörige Projektstatusbericht kann mit einem Klick auf den aktuellen Bericht angelegt und geöffnet werden. Wenn detaillierte Informationen zu den Projekten angefordert werden, kann für jedes einzelne Projekt jeder gewünschte Projektstatusbericht hinzugezogen werden. Damit hat auch der Profit-CenterLeiter die Möglichkeit, Projektdefinitionen, die Projektplanung, aktuelle Istwerte und Summary I bis III direkt einzusehen. Da an dieser Stelle auf die konkreten Projektstatusberichte zugegriffen wird, sind alle durch den Projektleiter angegebenen Kennzahlen und Werte ersichtlich. Zusätzlich kann der zeitliche Verlauf der betriebswirtschaftlichen Kennzahlen durch Klick auf die entsprechenden Werte aufgerufen werden. Die Grafik ermöglicht einen schnellen Überblick über die zeitliche Entwicklung des Projekts.

238


Abb. 193: ProControl-Frühwarnsystem (1 von 2)

Abb. 194: ProControl-Frühwarnsystem (2 von 2) 239


3.2.7 Kennzahlen Berichte sollten aussagefähige Kennzahlen enthalten. Sie ermöglichen die kompakte Darstellung schwer zu überblickender Datenmengen. Im zeitlichen Vergleich und durch Gegenüberstellung mit anderen Projekten oder einem Planwert erhält man Anhaltspunkte für Maßnahmen. Man kann folgende Arten von Kennzahlen unterscheiden (vgl. Abb. 195): Kennzahlen

Absolute Kennzahlen

Verhältniszahlen

Einzelwerte

Gliederungszahl

Geleistete Stunden

Personalkosten / Gesamtkosten

Summen

Beziehungszahl

Projektkosten 2007

Deckungsbeitrag / Umsatz

Differenzen

Indexzahl

Deckungsbeitrag

Kosten Mai / Kosten April Ist-Kosten / Plan-Kosten

Mittelwerte Durchschnittlicher Auftragswert pro Kunde

Abb. 195: Kennzahlenarten Neben absoluten Kennzahlen eignen sich vor allem Verhältniszahlen für ein aussagekräftiges Reporting. Gliederungszahlen beinhalten eine Teilgröße (z. B. Personalkosten), die auf die Gesamtheit (z. B. Gesamtkosten) bezogen wird. Besonders aussagekräftig sind Beziehungszahlen. Sie verknüpfen zwei unterschiedliche Größen, zwischen denen eine sachliche Beziehung besteht (z. B. Deckungsbeitrag und Umsatz). Indexzahlen verdeutlichen zeitliche Entwicklungen. Auch ein Quotient aus Ist- und Planzahlen kann als Index bezeichnet werden.

240


Folgende Fragen helfen, die richtigen Kennzahlen zu finden: • • • • •

Können wir Daten verwenden, die schon für andere Zwecke gesammelt werden? Kann die Kennzahl schnell zur Verfügung gestellt werden? Sind die Kennzahlen allgemein verständlich und sind sie leicht vergleichbar mit anderen Bereichen im Unternehmen oder anderen Unternehmen? Gibt es neben Spätindikatoren (Istkosten, Istdauer) genügend Kennzahlen, die als Frühindikator wirken (Cost-at-Completion, Time-at-Completion, Kundenzufriedenheit)? Spiegelt die Kenngröße ein wichtiges Unternehmensziel wider?

Tipp

Worauf sollte man bei der Kennzahlenbildung achten? Kennzahlen müssen verstanden werden. Allen muss klar sein, was die Kennzahl bedeutet und welches Ziel damit verfolgt wird. Deshalb ist es wichtig, eine Kennzahl eindeutig zu dokumentieren. Abb. 196 zeigt ein Beispiel für eine umfassende Kennzahlenbeschreibung. Die erste Zeile enthält das Ziel, das mit der Kennzahl gemessen werden soll. Ziel Kennzahl

Wirtschaftlichkeit (Istkosten - Sollkosten) x 100 Sollkosten

Bezeichnung

Kostenabweichung

Verantwortlich

Projektcontrolling

Datenquellen

Angaben des Projektleiters zum Status, Kostendaten des Controllings

Darstellung

Tabelle: Ist und Soll, Abweichung Diagramm: Zeitliche Entwicklung Ist und Soll

Zeithorizont

Projektstart bis aktueller Monat

Empfänger

Lenkungsausschuss

Vorlagetermin

Bis zum 5. Werktag des Folgemonats

Grüner Bereich

Abweichung < 6 Prozent

Roter Bereich

Abweichung > 10 Prozent

Abb. 196: Schema für die Definition einer Kennzahl 241


Welche Kennzahlen sind für Projekte geeignet? Neben den bereits im Rahmen der Wirtschaftlichkeitsverfahren (vgl. Abschnitt. 2.1.3.3) und der Earned Value Analyse (vgl. Abschnitt 3.2.4) erwähnten Größen, können folgende Kennzahlen verwendet werden (vgl. Abb. 197): Kennzahl

Produktivität: Planabweichung: Plantreue: Fremdanteil: Kostenanteil: Produktivanteil: Kostenanteil der Qualitätssicherung: First Pass Yield: Overheadanteil: Projektmanagementanteil: Fluktuationsquote: Erfahrungsstand: Aufwandsanteil je Phase: Zeitanteil je Phase: Terminenge: Termintreue: Fortschrittsgrad: Umsetzungsquote: Kapazitätsauslastung: Mitarbeiterzufriedenheit: Kundenzufriedenheit:

Formel Ergebnismenge Gesamtaufwand Istwert – Planwert Planwert Istwert Planwert Externe Mitarbeiter Gesamtanzahl Mitarbeiter Kosten einer Kostenart Gesamtkosten Produktivstunden Gesamtstunden Qualitätssicherungskosten Gesamtkosten Arbeitspakete ohne Nacharbeit insgesamt fertig gestellte Arbeitspakete Nicht projektbezogene Kosten Gesamtkosten Mitarbeiter für Projektmanagement Gesamtzahl Mitarbeiter Anzahl der Ab- und Zugänge Mitarbeiterbestand Summe aller Praxisjahre Gesamtanzahl Mitarbeiter Aufwand einer Phase Gesamtaufwand Dauer einer Tätigkeit Gesamtdauer Anzahl zeitkritischer Vorgänge Gesamtanzahl Vorgänge Fertiggestellte Arbeitspakete ohne Verzug insgesamt fertig gestellte Arbeitspakete siehe Abschnitt 3.2.2 realisierte Maßnahmen beschlossene Maßnahmen ausgelastete Kapazität verfügbare Kapazität mittels einer Umfrage ermittelter Prozentwert mittels einer Umfrage ermittelter Prozentwert

Abb. 197: Kennzahlen für das Projektcontrolling 242


Für IT-Projekte der Swiss Life AG werden u. a. folgende Kennzahlen eingesetzt: 95 Die fünf wichtigsten Projekte („Big 5“) steuert man anhand der zentralen Kennzahlen Kostenentwicklung, Meilensteineinhaltung, Risikoentwicklung und Ressourcenverfügbarkeit. Weitere Kennzahlen sind der Innovationsgrad (Anteil strategischer Projekte im Portfolio), die Verteilungseffizienz (Anteil interner Ressourcen an strategischen Projekten), das Projektrisiko (Anteil aller Projekte mit Status gelb und rot) und Kennzahlen der Earned Value Analyse.

Welche Aufgaben nimmt das Projektcontrolling wahr? Die Aufgabe des Projektcontrollers besteht zum einen in der Gestaltung eines aussagefähigen und wirkungsvollen Berichtswesens und zum anderen in der laufenden Sammlung, Aufbereitung und Dokumentation aller relevanten Informationen für die Projektsteuerung. Dabei ist es hilfreich, auf DV-gestützte Informationssysteme zurückzugreifen. Insbesondere Führungsinformationssysteme erleichtern die flexible, aussagekräftige Auswertung und die schnelle, wirtschaftliche Aufbereitung der Daten.

95

3UoMeNtFontUoOOeU

XnteUVtt]t

Baumöl, U., Hoffmann, N., Stettler, J., Koordination von Projekt- und LinienControlling in IT-Bereichen am Beispiel der Swiss Life AG, Controlling & Management, 51 (2007) H. 4, S. 261.

243


3.3 • • • •

•

•

•

•

•

244

Zusammenfassung Die Planung ist kein einmaliger Prozess am Anfang eines Vorhabens. Sie muss projektbegleitend durchgeführt und vom Projektcontrolling unterstützt werden. Projektcontrolling erarbeitet Regeln für die Zielplanung, prüft und kommuniziert die Ziele. Projektcontrolling empfiehlt ein Standardphasenschema und stellt Informationen über die verschiedenen Phasen bereit. Projektcontrolling erarbeitet Standardstrukturpläne und prüft den Projektstrukturplan mit den Arbeitspaketen und Meilensteinen. Ergänzend kann ein wertorientierter Strukturplan angelegt werden, der den Einfluss der Arbeitspakete auf den Erlös eines Projektes offen legt. Projektcontrolling erarbeitet Empfehlungen zur Bestimmung des Projektaufwands, moderiert Schätzworkshops und prüft den geschätzten Aufwand auf Vollständigkeit und Plausibilität. Dafür werden Informationen über den Aufwand abgeschlossener Projekte systematisch ausgewertet. Projektcontrolling achtet darauf, dass eine Terminplanung erstellt wird, und empfiehlt dafür Instrumente und DV-Tools. Es prüft die Machbarkeit des Terminplans und hilft bei der projektübergreifenden Abstimmung. Projektcontrolling unterstützt Entscheidungen über die optimale Verkürzung der Projektdauer durch Ermittlung des Nettonutzwerts oder der mittleren Beschleunigungskosten der Arbeitspakete. Es kann auch diejenigen Arbeitspakete bestimmen, bei denen sich eine Zeitverkürzung besonders lohnt. Projektcontrolling sollte dafür sorgen, dass die Auslastung der Ressourcen realistisch ermittelt und zentral dokumentiert wird. Es prüft die Ressourcenplanung nicht nur quantitativ, sondern auch qualitativ. Projektcontrolling kalkuliert auf der Grundlage der vom Projektleiter bereit gestellten Plandaten die Projektkosten für jedes Arbeitspaket. Es differenziert die Kosten nach: - direkt vom Projekt verursachten Kosten und anteilig verrechneten Unternehmensgemeinkosten, - einem Arbeitspaket direkt zurechenbaren Kosten und von mehreren Arbeitspaketen gemeinsam verursachten Kosten, - fixen und variablen Kosten, - Basisbudget und Zusatzbudgets.

3.3 Zusammenfassung

•

• •

•

•

•

• •

•

Zur Sicherheit sollte der Projektleiter selbst laufend die Kosten schätzen. Zusätzlich ist eine Kostenprognose, welche die bereits verbrauchten Kosten und den Leistungsfortschritt berücksichtigt, sinnvoll. Projektcontrolling ermittelt bei größeren Projekten, die mit erheblichen Ausgaben verbunden sind, den Mittelzu- und Mittelabfluss (Liquidität). Gegenstand der Projektkontrolle ist die Erfassung der Istleistung, Istkosten und Istdauer, deren Vergleich mit dem Plan, die Ursachenanalyse aufgetretener Abweichungen sowie die Planung von Maßnahmen. Neben den Istdaten sollten zusätzlich Prognosedaten bereitgestellt werden, um ein vorausschauendes Controlling zu ermöglichen. Auch realistische Schätzwerte über die Projektentwicklung in der Zukunft sind erforderlich (Restaufwand, Cost-toCompletion, Time-to-Completion). Um die erbrachte Leistung zu erfassen, kann man die Mitarbeiter befragen, erfüllte Meilensteine zählen, mit den Methoden 0/50/100 und 0/100 gestartete, abgeschlossene und nicht abgeschlossene Arbeitspakete identifizieren und bewerten oder einen leistungsmäßigen Fortschrittsgrad ermitteln. Alle Verfahren liefern nur Anhaltspunkte. Deswegen sind regelmäßige Besprechungen des Leistungsfortschritts sehr wichtig. Um die Unsicherheit bei der Schätzung des Leistungsstands zu verringern und die Projektdauer zu reduzieren, ist eine Minimierung von Nacharbeiten anzustreben. Wichtig ist es auch, Qualitätsmängel frühzeitig aufzudecken. Eine wirksame organisatorische Regelung, um einem gravierenden Leistungsverzug bei wichtigen Projekten entgegenzuwirken, sind Sofortmaßnahmen. Das Termin-Trenddiagramm stellt eine sinnvolle Ergänzung des Balkenplans dar. Es zeigt die Veränderung der Plantermine im Zeitablauf und lässt sich anbahnende Terminverzögerungen frühzeitig erkennen. Ein Vergleich von Plan- und Istkosten sagt wenig aus, wenn keine Information über den Leistungsfortschritt vorliegt. Ergänzend müssen deshalb Sollkosten errechnet werden. Damit erhält man eine planmäßige Bewertung der Istleistung. Es sind fundierte Aussagen über den Stand der Leistung und des Kostenverbrauchs möglich. Außerdem erlaubt das Verfahren eine Abschätzung der voraussichtlichen Gesamtdauer und der Gesamtkosten. 245


• •

•

•

• •

• •

246

Die Earned Value Analyse liefert nicht nur für einzelne Projekte, sondern auch für das Multiprojektcontrolling wertvolle Aussagen. In manchen Projekten ist es nicht möglich, die erbrachte Leistung zu quantifizieren. In diesem Fall können die Sollkosten errechnet werden, indem man die geschätzten Restkosten von den gesamten Plankosten subtrahiert. Nach Abschluss der Projekte sollten die aufgetretenen Probleme und die Erfahrungen systematisch ausgewertet werden. Damit können wertvolle Erkenntnisse für nachfolgende Projekte gewonnen werden. Multiprojektcontrolling setzt voraus, einen Maßstab für die Vergleichbarkeit der Projekte zu finden. Eine Möglichkeit ist die Gruppierung aller Projekte nach deren Komplexität und ihrer Neuartigkeit. Das Projektberichtswesen muss aktuelle, empfängerbezogene und entscheidungsrelevante Informationen bereitstellen. Fortschrittsberichte informieren die Projektausschüsse periodisch in kurzer und prägnanter Art über den Projektstand. Nach Projektende wird ein Abschlussbericht erstellt, der die Ergebnisse darstellt und den Ablauf des Projekts festhält. Die Projektdokumentation enthält wichtige Projektunterlagen und Protokolle der Besprechungen mit den Beschlüssen sowie die gesammelten Projekterfahrungen. Die Analyse der Projekte wird mit Kennzahlen wirkungsvoll unterstützt. Sie sollten sorgfältig ausgewählt und dokumentiert werden.

4

DV-Unterstützung

„EDV-Systeme verarbeiten, womit sie gefüttert werden. Kommt Mist rein, kommt Mist raus.“ André Kostolany

Sie erfahren in diesem Kapitel, wie man Projekte mit DV-Tools unterstützen kann. Es wird auf Projektmanagementsoftware wie MS-Project und SAP R/3, Modul PS eingegangen. Außerdem werden Führungsinformationssysteme hinsichtlich ihrer Einsetzbarkeit für die Aufbereitung und Analyse der controllingrelevanten Projektinformationen beschrieben.

247

4 DV-Unterstützung

4.1

Projektmanagementsoftware

Die Planung und Steuerung auch kleiner Projekte wird mit Projektmanagementsystemen wesentlich effizienter. Die Projektverantwortlichen im Unternehmen können aus einem großen Programmangebot auswählen. Die Software besitzt einen vielfältigen Funktionsumfang, ist leistungsfähig, benutzerfreundlich und kostengünstig in der Anschaffung. Solche Systeme generieren automatisch Projektberichte in unterschiedlichen Verdichtungsstufen, weisen den Benutzer auf kritische Vorgänge hin, zeigen Pufferzeiten und warnen bei inkonsistenten Eingaben, z. B. wenn die Kapazität begrenzter Personalressourcen überschritten wird. Durch Simulationen kann die Projektplanung optimiert werden. Man erkennt schnell die Auswirkungen von Terminveränderungen.

Was ist bei Projektmanagementsoftware zu beachten? Projektplanungssoftware stellt höhere Anforderungen an den Nutzer als ein Tabellenkalkulations- oder Textverarbeitungsprogramm. Eine intensive Auseinandersetzung mit dem System ist auf jeden Fall erforderlich. Zu bedenken sind folgende Hinweise: Tipp

• •

• • •

248

Mitarbeiter, die mit dem System umgehen, sollten zu Beginn geschult werden. Der Anwender muss grundlegende Kenntnisse des Projektmanagements besitzen und auch inhaltlich mit dem im System abzubildenden Projekt vertraut sein. Keinesfalls darf die Arbeit mit einer Projektmanagementsoftware dem Praktikanten oder Auszubildenden übertragen werden. Die Projektmanagementsoftware ist das Instrument des Projektleiters. Die Projektdaten müssen sorgfältig eingegeben und konsequent gepflegt werden. Die Software reduziert in erster Linie nicht die Zeit für die Projektplanung, sondern sie verbessert deren Qualität. Die Abwicklung von Projekten mit einem Projektmanagementsystem muss organisatorisch geplant und eindeutig geregelt werden. Hier ist das Projektcontrolling gefordert. Aufgrund der angebotenen Funktionsfülle sollten Planungsstandards vereinbart werden. Z. B. können die verbindlichen Tabellen vorgegeben und Feldbezeichnungen, Balkenarten und Drucklayouts voreingestellt werden.

4.1 Projektmanagementsoftware

•

Besonders negativ ist eine Situation, in der die Projektteams mit vielen unterschiedlichen Systemen umgehen. Der Grundsatz lautet: „Lieber ein weniger gut geeignetes System einsetzen als mehrere Topprogramme.“

Welche Systeme gibt es? Der Markt für Systeme zur Projektplanung, Projektsteuerung und Projektkontrolle bietet eine sehr große Zahl von Produkten an, die es dem Anwender erschweren, sich einen Überblick zu verschaffen. Bekannte Systeme sind (Anbieter in Klammern) z. B.: Artemis (Artemis International GmbH), MS Project (Microsoft GmbH), OPX2 (Planisware), PAVONE Project Management (PAVONE AG), Planta (PLANTA Projektmanagement-Systeme GmbH), Project Scheduler (Scitor GmbH), Primavera Project Planner (Inteco GmbH), Powerproject (ASTA Development GmbH), SAP R/3 Modul PS (SAP AG).

,nteUnet

www.manage mentsoftware.de

Die Vielzahl der Programme kann in drei Kategorien eingeteilt werden: 1. Dateibasierte Systeme Der Vorteil von Systemen wie MS Project liegt in der einfachen Bedienbarkeit, der problemlosen Installation, den einfachen Schnittstellen zu Office-Programmen und den vielen Funktionen. Nachteilig ist, dass nur eine begrenzte Zahl von Projekten gemeinsam verwaltet werden kann. Außerdem ist es schwierig, die bereits in den zentralen Systemen wie SAP R/3 vorhandenen Daten zu nutzen. 2. Datenbankgestützte Systeme Ein typischer Vertreter ist das Modul PS der SAP AG. PS ist Bestandteil der integrierten Standardsoftware R/3 und kann deswegen nicht isoliert eingesetzt werden. Im Rahmen von SAP Enterprise wird auch cProjects angeboten. Es handelt sich um eine Weiterentwicklung von PS. Der Vorteil datenbankgestützter Projektmanagementsoftware liegt in der Integration mit den Modulen der zentralen Systeme. Die Verwaltung vieler Projekte bereitet keine Probleme, die Datensicherung ist gut gelöst. Allerdings ist die Bedienung weniger einfach als bei dateibasierten Systemen. Auch die Schnittstellen zu den Office-Programmen sind weniger komfortabel oder nicht

249

4 DV-Unterstützung

vorhanden. Die Implementierung und Pflege solcher Systeme verursacht aufgrund der Komplexität einen hohen Aufwand. 3. Webbasierte Systeme Zunehmend gibt es Angebote, die Projekte über im Internet zur Verfügung gestellte Systeme zu planen und deren Daten zu verwalten. Damit kann die Anschaffung einer eigenen Projektmanagementsoftware überflüssig werden. Vorteilhaft ist der weltweite Zugriff auf die Projektdaten und die Möglichkeit, viele Projekte zu verwalten. Kritisch dürfte die geringe Performance einer Internetverbindung sein. Auch Aspekte des Datenschutzes und der Datensicherung können gegen diese Lösung sprechen. Anbieter solcher Systeme sind z. B. (Anbieter in Klammern) projectplace (Projectplace GmbH), ProjectControl (weburi.com GmbH), Projectile (Information Desire Software GmbH). ,nteUnet

www.project-it.de www.netronic.de

Zu erwähnen sind noch Zusatztools, welche die Defizite der etablierten Projektmanagementsysteme ausgleichen wollen. Ein Beispiel ist die einfache Software Prin(z) der project-it GmbH. Das System ist speziell an MS Project angepasst. Dessen Projektpläne können eingelesen und z. B. zu Termin-Trenddiagrammen verarbeitet werden. Graneda der Netronic Software GmbH besitzt ebenfalls Schnittstellen zu Projektmanagementprogrammen und erstellt z. B. Netzpläne, Balkenpläne, Projektstrukturpläne, Meilenstein-Trenddiagramme. Im Folgenden sollen das bekannte MS-Project von Microsoft und das PS-Modul von SAP R/3 beschrieben werden. Abb. 198 zeigt zunächst einen Vergleich der wichtigsten Unterschiede. Kriterium Sicherheit

Integration Anwendungsschwerpunkt Benutzerfreundlichkeit Ressourcenverwaltung Datenhaltung Funktionsangebot Berichtswesen Flexibilität Kosten

SAP R/3 ausgefeiltes Sicherheitskonzept, hoher Datenschutz sehr hoch Management einer großen Projektzahl restriktiv für den Benutzer zentral für alle Projekte datenbankorientiert, sehr große Datenmengen möglich zufriedenstellend projektübergreifend Voraussetzung: SAP R/3 sehr hoch

MS-Project nur geringe Sicherheits- und Datenschutzvorkehrungen keine direkte Integration Management von bis zu 40 Projekten sinnvoll intuitive, spontane Bedienung nur für wenige Projekte dateiorientiert, nur für kleinere Datenmengen ausgelegt gut einzelprojektbezogen als Einzelsystem nutzbar gering

Abb. 198: Vergleich des Moduls PS von SAP R/3 und MS-Project

250


4.1.1 SAP R/3 Das Modul PS ist Bestandteil des Systems R/3 von SAP. Damit PS lauffähig ist, benötigt man eine Datenbank, das SAP-Basissystem, das eigentliche Projektmanagementmodul PS sowie weitere Module aus den Bereichen Controlling und Finanzbuchhaltung. PS ist auch mit den anderen SAP R/3-Modulen integriert (vgl. Abb. 199). Vertrieb (SD) • Kundendaten

Investitionsmanagent (IM) • Anlageinvestitionsprogramm

Einkauf (MM)

Projektsystem (PS)

• Material-/Leistungsstamm • Lieferzeit • Einkaufsinfosatz

Kostenrechnung (FI) • • • •

Kostenstelle Kostenart Leistungsart Profit Center

Treasury (FI) • Finanzposition

Produktion (PP) • Arbeitsplatz • Stückliste

Buchhaltung (FI) • Sachkonto • Kontenplan

Instandhaltung/Serice (PM)

Personal (HR) • Qualifikationsprofil

Abb. 199: Integrationsbeziehungen des Moduls PS SAP unterstützt auch die unternehmensübergreifende Kommunikation auf der Basis der Internettechnologie. Alle am Projekt beteiligten Parteien (Lieferanten, Auftraggeber, Partnerunternehmen) haben Zugriff auf die relevanten Projektinformationen.96 Ein typisches Szenarium könnte wie folgt aussehen: • • •

Der Projektleiter stellt im SAP-System die zu exportierenden Projektinformationen zusammen und benachrichtigt den Auftraggeber per E-Mail. Der Auftraggeber meldet sich auf dem Web-Server des Auftragnehmers an, liest, kommentiert und ändert ggf. die Daten. Der neue Stand wird in das SAP-System zurückgestellt.

SAP bietet mit dem Open Project System eine Schnittstelle zum Datenaustausch zwischen dem PS-Modul und MS-Project an. Damit sind u. a. folgende Möglichkeiten gegeben:

96

Link, C., Open Project System. The SAP Interface between SAP R/3 PS and Microsoft Project, in: Empug (Hrsg.), 3. Microsoft User Conference, Stuttgart 2000, S. 17-1 ff.

251

4 DV-Unterstützung

• • •

Bearbeitung von PS-Projekten ohne Anbindung an das SAPSystem (Projektstrukturplan, Netzplan, Anordnungsbeziehungen, Meilensteine); Anlegen von PS-Projekten mit MS-Project; Präsentation von PS-Projekten mit MS-Project.

Abb. 200: Darstellung der Projektstruktur im PS-Modul von SAP R/3 Bei der Outokumpu Technology GmbH spielt das Modul PS von SAP R/3 eine zentrale Rolle (siehe Abb. 201). Innerhalb dieses Moduls werden die auftragsbezogenen Daten verarbeitet. Damit sind die Mitarbeiter des Projektcontrollings in der Lage, alle Kundenaufträge zu überwachen und zu steuern. Durch die zentrale Stellung und den daraus resultierenden Verknüpfungen mit anderen Bereichen ist sichergestellt, dass Änderungen auftragsbezogener Daten, die in einem Modul erfasst werden, auch in allen anderen Modulen registriert werden. Da diese Daten alle im PS-Modul zusammenlaufen, kann von hier aus immer auf vollständiges, aktuelles und korrektes Datenmaterial zugegriffen werden.

252


Bedarfsanforderungen

Modul PM

Modul MM

techn. Struktur

Beschaffung/Versand Budget

Zuordnung Equipment zur Kalkulationsposition

Bestellwert

Modul PS

Startkalkulation, Change Orders, Änderungen

Projekt-Controlling

Rechnung Ist-Kosten (Abbau Obligo)

Projektrückstellungen

Vollkostensätze

Modul CO GK-Controlling

Manuelle Dateneingabe

Gemeinkostenaktivierung Ist-Stunden (Eigenleistungen)

Modul FI Finanzbuchhaltung

Budget-Stunden (Eigenleistungen)

Modul S.I.S.

System Datentransfer

Stundenmanagement

Abb. 201: Projektplanung und -steuerung mit SAP R/3 bei der Outokumpu Technology GmbH Zentrales Controlling-Instrument der Lufthansa Systems ist das SAP-System. Das Modul PS wird jedoch nicht genutzt. Dies liegt daran, dass wesentliche Anforderungen aus dem Projektsteuerungsbereich mit PS nicht abgedeckt werden können bzw. viel zu komplex abgewickelt werden müssten. Um dennoch ein sauberes Projektcontrolling zu ermöglichen, wurden bei Lufthansa Systems mehrere Tools entwickelt, die einerseits die vorhandenen technischen Ressourcen nutzen und andererseits hinreichend einfach sind, um gerade die Projektleiter nicht zu sehr mit Verwaltungsaufgaben zu belasten. Schwerpunktmäßig werden heute ein Kalkulationstool, ein Werkzeug zur Risikoanalyse, ein toolgestütztes Berichtswesen und ein SAP-basiertes Werkzeug zur Erfassung, Verfolgung und zum Abgleich von Aufwänden eingesetzt. 4.1.2 MS-Project MS Project läuft auf den bekannten PC-Betriebssystemen wie Windows XP, Windows Vista oder Windows 7. Datenübergaben in die anderen MS Office-Programme sind ohne Probleme möglich. MSProject kann an die Anforderungen des Nutzers angepasst werden. Mittlerweile existiert eine Reihe von Beratungsunternehmen, die diesbezüglich ihre Dienste anbieten.

253

4 DV-Unterstützung

Abb. 202 zeigt die zentrale Maske für die Eingabe der Vorgänge und der Termine in MS-Project.

Abb. 202: Zentrale Planungsmaske in MS-Project MS Project stellt wie SAP R/3 viele Instrumente bereit, die im Projektmanagement Verwendung finden. Die Bedienerfreundlichkeit ist jedoch höher. Hervorzuheben sind die Teammanagementfunktionen, die den Datenaustausch zwischen den Projektbeteiligten erleichtern sowie die einfache Erstellung von Berichten, Balken- und Netzplänen. Nur begrenzte Möglichkeiten bietet das System in der gemeinsamen Ressourcenverwaltung für unterschiedliche Projekte. MS Project gibt es in zwei Varianten: • •

Einzelplatzversion für die Planungs- und Kontrollaufgaben des Projektleiters; Project Server für den unternehmensweiten Einsatz und den Austausch von Informationen zwischen den Projektbeteiligten. Dieses System bietet zusätzlich eine webbasierte Oberfläche für Teammitglieder, Projektbüro und Management, den Project Server für die zentrale Datenverwaltung und Groupwarefunktionen sowie den SQL-Server als relationales Datenbanksystem.

Mit Hilfe von Project Server kann der Projektmitarbeiter Daten mit dem Projektleiter und anderen Projektbeteiligten austauschen:

254


• • •

Rückmelden von Zeiten, Fertigstellungsgrad u. a.; Anlegen neuer Aufgaben; Information des Projektleiters über Arbeitszeiten.

Ein typisches Szenarium mit Project Server könnte wie folgt aussehen: • • •

Der Projektleiter will den Projektstatus aktualisieren. Deswegen versendet er aus MS-Project heraus Anfragen an die Projektmitarbeiter. In seiner Posteingangsbox findet der Projektmitarbeiter die Nachricht. Nach der Beantwortung sendet er sie zurück. Der Projektleiter entscheidet nach Prüfung, ob die Statusmeldung des Mitarbeiters den Projektstand in MS-Project automatisch aktualisieren soll.

Ein umfassendes System auf der Basis von Microsoft Project Server aufzubauen, ist mit hohem Aufwand verbunden. Vor allem die Technologie der Serveranwendung von MS Project ist anspruchsvoll. 4.1.3 Einführung einer Projektmanagementsoftware Vor der Einführung der Projektmanagementsoftware sollte man die Projektmanagementprozesse optimieren. Es ist außerdem genau zu definieren, für welche Aufgaben die Projektmanagementsoftware verwendet werden soll. Wird dies vernachlässigt, besteht die Gefahr, dass die vielen Einsatzmöglichkeiten und Ansichten einer Projektmanagementsoftware zu einer Überforderung der Mitarbeiter führen. Es reicht auch nicht, sich nur um die Software zu kümmern. Die Akzeptanz des Projektmanagements muss gleichzeitig verbessert werden. Zu Beginn des Einführungsprozesses müssen die Anforderungen an die Software erfasst und gewichtet werden. Nach Sichtung des Marktangebots kann man mittels der Nutzwertanalyse eine Vorauswahl treffen (vgl. Abb. 203). Die in Frage kommenden Systeme müssen dann einem ausführlichen Test unterzogen werden. Schließlich folgt die Entscheidung, welches System angeschafft werden soll.

255

4 DV-Unterstützung

Projektmanagementsoftware Software Software Software A B C

Kriterien Muss-Kriterium Datenaustausch mit SAP

erfüllt

erfüllt

erfüllt

Kann-Kriterien

G

P

GxP

P

GxP

P

GxP

Kosten - Kaufpreis - Folgekosten

10 5 5

10 4

50 20

5 7

25 35

5 7

25 35

PM-Funktionalitäten - Projektstrukturplan - Netzplan - Kostenplanung - Earned Value - Trendanalysen - Berichtsgestaltung - Personalisierung

50 5 2 5 10 5 15 8

10 4 5 4 3 7 2

50 8 25 40 15 105 16

7 2 4 2 3 2 5

35 4 20 20 15 30 40

7 10 3 4 7 2 2

35 20 15 40 35 30 16

Organisatorische Kriterien - Schulungsaufwand - Akzeptanz bei den Projektleitern - Integration in IT-Landschaft

25 2 15 8

8 7 1

16 105 8

4 6 3

8 90 24

4 4 2

8 60 16

Marktrelevante Kriterien - Internationalisierung - Verbreitung bei Geschäftspartnern

15 5 10

6 9

30 90

6 3

30 30

2 1

10 10

Summe

100

G = Gewicht

578

406

355

P = Punkte (maximal 10)

Abb. 203: Systematische Bewertung und Auswahl von Projektmanagementsoftware mit der Nutzwertanalyse

256


Im Rahmen der Einführung von MS Office Project bei der Versicherungsgesellschaft Münchner Verein wurden folgende Regelungen getroffen:97 • • • • • •

Nur der Projektleiter bedient das System. Man beschränkte sich auf fünf verbindliche Tabellen. Feldbezeichnungen, Balkenarten und Drucklayouts wurden voreingestellt. Es wurde ein zentraler Ressourcenpool eingerichtet. Die Anwender wurden intensiv geschult und betreut. Man verabredete aufgrund der Funktionsfülle verbindliche Planungsstandards.

Eine wichtige Erkenntnis war, dass man immer wieder auf den Projektleiter zugehen muss, um ihm Hilfe für den Tooleinsatz anzubieten. 4.2

Führungsinformationssysteme

Führungsinformationssysteme (auch als Managementinformationssysteme oder MIS bezeichnet) unterstützen den Controller und das mittlere Management vor allem bei der Berichterstellung und Analyse. Wichtige Kennzeichen eines Führungsinformationssystems sind: • • • •

•

97

sehr komfortable Bedienung im Vergleich zu den operativen Basissystemen; weitreichende grafische Darstellungsmöglichkeiten der Daten; schnelle Auswertung auch umfangreicher Datenbestände (im Unterschied zu Tabellenkalkulationsprogrammen); vorgefertigte Analysefunktionen für Simulationen, Definition von Abweichungstoleranzen, automatische Warnpunkte beim Überschreiten einer Toleranzgrenze, ABC-Analysen, Definition wichtiger Kennzahlen, vielfältige Datenvergleiche (Soll-IstVergleich, Objektvergleich, Bildung von Indexreihen), Prognosemöglichkeiten; mehrdimensionale Datenanalysen, die auf dem sogenannten OnLine Analytical Processing (OLAP) basieren. Campana, C., Schott, E., Haffner, S., MS Project 2002 im Praxistest. Projektmagazin 8(2002), S. 2 ff. (www.projektmagazin.de). Vgl. auch Blaurock, E., Beispiele aus dem Praxiseinsatz: Nutzen und Grenzen von Microsoft Project 2002. Projektmagazin 8 (2002), S. 5 ff. (www.projektmagazin.de).

257

4 DV-Unterstützung

Die Daten werden im Rahmen von OLAP multidimensional gespeichert und ausgewertet. Bedeutsame Dimensionen können z. B. Projekte, Projektleiter oder Kunden sein. Betriebswirtschaftliche Kenngrößen (wie etwa Kosten oder Deckungsbeitrag) werden für die unterschiedlichen Dimensionen analysiert. Die Elemente einer Dimension sind in der Regel in Hierarchien angeordnet. Eine mögliche Hierarchie lautet z. B. Unternehmen, Projektgruppe, Projekt, Teilprojekt, Arbeitspaket. Entlang einer Hierarchie werden die einzelnen Kennzahlen untersucht. Die für eine Analyse zur Verfügung stehenden Dimensionen werden als Datenwürfel (sogenannte Hypercubes) dargestellt. Um Daten zu analysieren, verändert der Anwender die Sicht auf den Würfel. Dafür stehen verschiedene Techniken zur Verfügung: Durch das Rotieren des Datenwürfels (auch als „Dice“ bezeichnet) können die interessierenden Dimensionen dargestellt werden. Im Beispiel der Abb. 204 werden Daten zuerst differenziert für Projekte und Länder und nach dem Drehen des Würfels für Projekte und Monate angezeigt.

Geographie

•

Projekt

Projekt kt

Zeit

Abb. 204:Datenanalyse mittels „Dice“ •

258

Schnitte durch den Würfel erlauben die Konzentration auf besonders interessante Datenelemente. Für diese Technik wird auch der Begriff „Slice“ verwendet. In Abb. 205 wählt man zunächst die Sicht auf ein einzelnes Projekt. Die Daten werden zeitlich und geographisch nicht differenziert. Danach schaut man sich alle Projekte, die in einem bestimmten Land angesiedelt sind an. Zum Schluss interessiert ein bestimmtes Projekt in einem Land zu einem gewählten Zeitpunkt.

4.2 Führungsinformationssysteme

Projektsicht z.B. Projektmanager für IT-Projekte weltweit

Ad-hoc Sicht z.B. Projektleiter für IT-Projekt in USA

Projekt

alle Regionen gesamter Zeitraum ein Projekt (Filter)

Geographie

Geographie

Geographie

Regionale Sicht z.B. Gebietsleiter für USA

Projekt

Projekt

ein Projekt (Filter) ein Monat (Filter) eine Region (Filter)

alle Projekte gesamter Zeitraum eine Region (Filter)

Abb. 205: Datenanalyse mittels „Slice“ •

Mittels „Drill-Down“ bewegt man sich innerhalb einer Hierarchie von verdichteten zu detaillierten Hierarchieebenen bis hinunter zu den Basiselementen. Unternehmen

Projekte

Projektgruppe A

Projekt A1

Projektgruppe B

Projekt A2

Projekt B1

Drill Down

Projektgruppen

Alle Projekte

Projekt B2

Abb. 206: Datenanalyse mittels „Drill-Down“ •

Mit „Roll-Up“ werden zunächst die Detaildaten angeschaut, um dann sukzessive verdichtete Ebenen in den Fokus zu nehmen. Unternehmen

Projekte

Projektgruppe A

Projekt A1

Projekt A2

Projektgruppe B

Projekt B1

Roll Up

Projektgruppen

Alle Projekte

Projekt B2

Abb. 207: Datenanalyse mittels „Roll-Up“

259

4 DV-Unterstützung

Führungsinformationssysteme nutzen die Daten der operativen Basissysteme. Im Idealfall greifen sie auf ein Data Warehouse zu; das ist eine Datenbank, die regelmäßig mit für betriebswirtschaftliche Auswertungszwecke transformierten und vorselektierten Daten der operativen Systeme versorgt wird (vgl. Abb. 208). Operative Basissysteme

Projektmanagement

Einkauf Vertrieb Kunden

Externe Daten

Datenhaltungsebene

T r a n s f o r m a t i o n

Data Warehouse

Data Warehouse

Auswertungsebene

Führungsinformationssystem

Tabellenkalkulation

Abb. 208: Datenversorgung eines MIS Führungsinformationssysteme werden im Projektumfeld immer noch selten eingesetzt, obwohl sie hervorragend für die Bereitstellung, den Vergleich und die Analyse wichtiger Kennzahlen im Multiprojektcontrolling geeignet sind. Die Daimler AG nutzt z. B. das System der MIS AG für folgende Aufgaben:98 • • • •

Abstimmung von Kapazitäten und Bereichskosten mit den Projekten; Aufbereitung von aussagekräftigen Soll-Ist-Vergleichen; Ermittlung von Prognosewerten über die voraussichtlichen Projektergebnisse; Information über die Einflussmöglichkeiten zur Steuerung des Projektbudgets.

Eine zentrale Rolle spielt bei der Daimler AG das Controlling der Projektkosten und -erlöse. Auf der Grundlage des Projektfortschritts 98

260

Rosemann, S., Funke, T., Prozess-, Projekt- und Bereichssteuerung, Dimensionen 1 (2000), S. 17 f.


wird das voraussichtliche Projektergebnis prognostiziert. Der Anwender kann verschiedene Maßnahmen simulieren. Die Auswirkungen auf verdichteter Ebene werden ihm dann sofort präsentiert. 4.2.1 Aufbau des Führungsinformationssystems der MIS AG Das Daten- und Berechnungsmodell zur Unterstützung von Planung und Analyse ist unter Anwendung einer multidimensionalen Datenbank erstellt. Für die einzelnen Themenbereiche wurden Hypercubes modelliert (vgl. Abb. 209). Diese bestehen aus jeweils unterschiedlichen Dimensionen. StandardLeistungsprofile Vorschlag zur Kalkulation

Projektkalkulation

Ressourcen

Überleitung zum Bereichsergebnis z Inanspruchnahme von internen Leistungen z

Übergabe der genehmigten Projekte

Inanspruchnahme

Unternehmenscontrolling

Bereichscontrolling

Projektcontrolling

Abstimmung

Übergabe der Kostensätze

- Anlagen - Verbindl. - usw.

Kostenstellen AFA

Zeiterfassung

Reisekostenabrechnung

Finanzbuchhaltung

Kostenrechnung

Anlagenbuchhaltung

Usw.

Transaktionssysteme

Abb. 209: Wesentliche Hypercubes für die Analyse Der Hypercube Unternehmenscontrolling zur Abbildung der GuV-/ Bilanz- und Cash Flow-Rechnungen auf Unternehmensebene besteht z. B. aus den Dimensionen: • • • • •

Währungen (wie z. B. Dollar, Euro), Rechtseinheiten, Partner-Rechtseinheiten (relevant zur Abbildung von Leistungsverflechtungen), Datenarten (wie z. B. Plan, Ist, Abweichung, Simulation), Perioden (Jahre und Monate),

261

4 DV-Unterstützung •

Berichtspositionen (Abbildung der GuV, Bilanz und Cash FlowRechnungen sowie zusätzlicher Kennzahlen).

Zwischen den einzelnen Hypercubes bestehen Verbindungen, die den Datentransfer sicherstellen. Für die Informationen aus den verschiedenen Transaktionssystemen sind entsprechende Schnittstellen vorgesehen. Auf die jeweiligen Strukturen der Hypercubes wird an dieser Stelle nur anhand der Dimensionen des Hypercubes Projektcontrolling und des Hypercubes Ressourcen näher eingegangen. Die Abb. 210 zeigt ein Beispiel für mögliche Verdichtungspfade der Projekt- bzw. Ressourceninformationen. Über die möglichen parallelen Verdichtungen besteht die Möglichkeit, einmal erfasste Daten in verschiedene Summen zu aggregieren. So können z. B. Projektdaten sowohl nach dem Projekttyp, dem Projektleiter, dem Kunden als auch der Region verdichtet werden.

262

Summe Branchen (1-n Branchen)

Summe Geschäftsbereiche (1-n Geschäftsbereiche)

(1-n Projekte) Branche (1-n Kunden)

(1-n Projekte)

(1-n Projekte)

Kunde

Geschäftsbereich (1-n Projekttypen)

Projektleiter

Mögliche parallele Verdichtungen

Projekttyp

Projekt

Summe Welt (1-n Kontinente)

Kontinent (1-n Länder)

Land (1-n Regionen)

Region (d. Kunden) (1-n Projekte)

Konzern (1-n Rechtseinheiten)

Rechtseinheit (1-n Niederlassungen)

Rechtseinheit (1-n Niederlassungen) Konzern (1-n Rechtseinheiten)

Niederlassung (1-n Ressourcen)

Skill Typ (1-n Ressourcen)

Konzern (1-n Rechtseinheiten)

Rechtseinheit (1-n Niederlassungen)

Niederlassung (1-n Ressourcen)

Typ of Experience (1-n Ressourcen)

Mögliche parallele Verdichtungen

Niederlassung (1-n Teams)

Team (1-n Ressourcen)

Ressource


Abb. 210: Hypercubes Projektcontrolling und Ressourcen

263

4 DV-Unterstützung

,nteUnet

www.bissantz. de

4.2.2 Projektdatenanalyse mit dem Delta Master Ein komfortables System zur Datenanalyse, Berichterstattung und Planung ist DeltaMaster der Bissantz & Company GmbH. Die Software enthält eine große Bibliothek von Analyseverfahren, unter anderem Rangfolgen, ABC-, Portfolio-, Zeitreihen- und Bewegungsanalysen sowie Methoden zur Datenmustererkennung (Data Mining). Mit speziellen Formen der Visualisierung macht DeltaMaster Zusammenhänge transparent und präsentiert sie in informationsdichten „Cockpits“ auf dem Bildschirm. DeltaMaster greift auf OLAP-Datenbanken zu, in denen die Projektdaten mehrdimensional und meist in Hierarchien hinterlegt sind. Jede Dimension entspricht einem Kriterium, nach dem man die verfügbaren Kennzahlen (z. B. Kosten, Leistungseinheiten, Anzahl der Projekte) untersuchen möchte. Die Software erlaubt es, beliebige Merkmalskombinationen einzustellen und so gezielt Ausschnitte aus dem gesamten Projektgeschäft zu untersuchen, auch verdichtet. Einen grafischen Überblick verschafft der sogenannte Hyperbrowser. Er legt nicht nur die Datenstruktur offen, sondern färbt die Elemente entsprechend einer beliebigen Kennzahl ein. In Abb. 211 wurde auf diese Weise die kumulierte Kostenabweichung visualisiert. Anhand der Farbe (rot oder blau) und ihrer Intensität erkennt der Projektcontroller sehr schnell, in welchen Bereichen es große negative oder positive Abweichungen gegeben hat. In Abb. 211 sind z.B. in Projekt 1 sowie in Projekten, in denen der Projektleiter 1 (PL1) und der Mitarbeiter 1 (MA1) tätig sind, besonders hohe Kosten angefallen. Ausgehend von diesen Erkenntnissen wird der Anwender weitere Kennzahlen abrufen und Analysen anstellen.

264


Abb. 211: Hyperbrowser im Delta Master

265

4 DV-Unterstützung

Die Tabelle in Abb. 212 ist nach der Earned Value-Methode modelliert und gibt die Daten des Beispiels in Abb. 163 wieder.

Abb. 212: Abweichungsanalyse für die Earned Value-Kennzahlen

266


Zusätzliche Visualisierungen, die DeltaMaster direkt in die Zellen einblendet, verdeutlichen die Zusammenhänge und machen die Werte auch optisch vergleichbar. Bei den kleinen Säulengrafiken handelt sich um sogenannte Sparklines: stark verkleinerte Zeitreihendiagramme, die mit sehr wenig Platzverbrauch illustrieren, wie sich die jeweilige Kennzahl im Laufe der Zeit entwickelt hat. Damit behält der Projektcontroller die aktuellen steuerungsrelevanten Kennzahlen im Blick und hat gleichzeitig zu Vergleichszwecken die historischen Daten im direkten Zugriff. Um die Ergebnisse in solchen oder ähnlichen Übersichten genauer zu analysieren, steht die Methodenbibliothek bereit. In Abb. 213 sind die Projekte in eine Portfoliodarstellung eingeordnet, welche die kumulierten Abweichungen der Leistungseinheiten und der Kosten gegenübergestellt. Die Parameter, die für solche Methoden benötigt werden, schlägt das System auf Basis der vorliegenden Daten selbsttätig vor, um möglichst rasch ein verwertbares Ergebnis zu liefern. Der Projektcontroller übernimmt die Vorgaben oder passt sie nach eigenen Bedürfnissen an. Noch weiter geht die Automation der Datenanalyse beim Data Mining: Diese Methoden führen die Anwender automatisch zu bemerkenswerten Datenkonstellationen, die sie sonst nur durch langwierige eigene Recherchen entdeckt oder vielleicht ganz übersehen hätten.

267

4 DV-Unterstützung

Abb. 213: Portfoliodarstellung der Leistungs- und Kostenabweichung

268


Im Beispiel der Abb. 214 hat DeltaMaster untersucht, ob es Merkmale gibt, bei denen sich die Kostenabweichungen auffällig anders verteilen als die Leistungsabweichungen. Dies ist etwa bei den Arbeitspaketen 3010010 und 9010010 gegeben, wie man am Muster der Balken schnell erkennt. Die Arbeitspakete sind aber nur eines von vielen Kriterien in der Projektcontrolling-Anwendung; ohne Systemhilfe müsste man sie alle einzeln untersuchen und würde dabei meist nur ohnehin Bekanntes entdecken. Ein weiteres Beispiel ist die „Navigation“. Diese Methode ermittelt automatisch die Ursachen von Abweichungen. Dabei kommen Heuristiken zum Einsatz, mit denen DeltaMaster beurteilt, welche Dimensionen (Merkmale) einen besonders guten Erklärungsbeitrag leisten. In Abb. 215 deckt die Software durch sukzessive Verfeinerung (Drill-Down) auf, dass 89,3 Prozent der festgestellten Kostenabweichung von Projekt 1 herrühren, dass 78,8 Prozent der Gesamtabweichung auf den Mitarbeiter MA1 zurückgehen und dass sich 52,6 Prozent mit Differenzen im Teilprojekt der Fachkonzepterstellung erklären lassen. Zur Kommunikation der Ergebnisse und zum Erstellen und Pflegen von Plänen hält DeltaMaster weitere Funktionen bereit.

269

4 DV-Unterstützung

Abb. 214: Identifikation auffälliger Arbeitspakete 270


Abb. 215: Identifikation der Verursacher einer Abweichung 271

4 DV-Unterstützung

4.3 • • •

272

Zusammenfassung Die Nutzung eines DV-gestützten Projektmanagementsystems ist ratsam. Wichtig ist ein einheitlicher, organisatorisch geregelter Einsatz. Zu unterscheiden sind datenbank- und dateiorientierte sowie webbasierte Projektplanungs- und Projektverwaltungssysteme. Führungsinformationssysteme unterstützen die entscheidungsund empfängerorientierte Aufbereitung und Analyse der Projektinformationen.

Literaturverzeichnis

Alter, R., Integriertes Projektcontrolling, Gießen 1991. Archer, N., Ghasemzadeh, F., An integrated framework for project portfolio selection, International Journal of Project Management, 17 (1999) 4, S. 207 – 216. Baccarini, D., Archer, R., The risk ranking of projects: a methodology, International Journal of Project Management, (2001) 19, S. 139 – 145. Baumöl, U., Hoffmann, N., Stettler, J., Koordination von Projekt- und Linien-Controlling in IT-Bereichen am Beispiel der Swiss Life AG, Controlling & Management, 51 (2007) H. 4, S. 258 ff. Blaurock, E., Beispiele aus dem Praxiseinsatz: Nutzen und Grenzen von Microsoft Project 2002. Projektmagazin 8 (2002), S. 5 ff. (www.projekt-magazin.de). Boehm, B., Port, D., Al-Said, M., Avoiding the Software Model-Clash Spiderweb, o.O. 2000. Brandon, D., Implementing Earned Value easily and effectively. Project Management Journal 19.2 (1998), S. 110 ff. Brooks, F., The Mythical Man-Month. Essays on Software Engineering, Anniversary Edition, Addison-Wesley 1995. Burghardt, M., Einführung in Projektmanagement, Berlin, München 1995. Burghardt, M., Einführung in Projektmanagement, 3. Aufl., München, Erlangen 2001. Campana, C., Knöss, A., Schott, E., Pilottest MS Project 2000 bei der Deutschen Bank AG, Frankfurt 2000. Campana, C., Schott, E., Haffner, S., MS Project 2002 im Praxistest. Projektmagazin 8(2002), S. 2 ff. (www.projekt-magazin.de). Carl, N., Fiedler, R., Jórasz, W., Kiesel, M., Grundkurs Betriebswirtschaftslehre. Eine kompakte Einführung für praktisch tätige Ingenieure, Informatiker oder Mathematiker, Braunschweig, Wiesbaden 2001. Coenenberg, A. u.a., Abweichungsanalyse bei Projekten im F&E-Bereich, in: Männel, W. (Hrsg.), Handbuch Kostenrechnung, Wiesbaden 1992, S. 767 ff. Cooper, K., The Rework Cycle: benchmarks for the Project Manager, Project Management Journal 24.1 (1993), S. 47 ff. GPM, PA Consulting Group (Hrsg.), Ergebnisse der Projektmanagement Studie 2007.

273

Literaturverzeichnis Daum, A., Lawa, D., Projekt-Controlling: Aufgaben und Instrumente, in: Steinle, C., Bruch, H. (Hrsg.), Controlling. Stuttgart 1998, S. 894 – 925. Devaux, S., Total Project Control. A Manager´s Guide to Integrated Project Planning, Measuring and Tracking, New York u.a.1999. Deyhle, A., Management & Controlling Brevier, Bd. 1, Manager & Controller im Team, 7. Aufl., Wörthsee-Etterschlag 1977. Deyhle, A., Controller-Praxis. Führung durch Ziele, Planung und Controlling, Bd. 1: Unternehmensplanung und Controller-Funktion, 9. Aufl., Gauting 1992. Die Zeit, Nr. 30, 15. Juli 2004, S. 25. Drexl, A., Kolisch, R., Sprecher, A., Koordination und Integration im Projektmanagement, Zeitschrift für Betriebswirtschaft, 68 (1998), S. 275 – 295. Eglau, H. u.a., Durchstarten zur Spitze – McKinseys Strategien für mehr Innovation, Frankfurt 2000. Ferrarese, N., Controlling in der Multiprojektumgebung, Seminar Kostencontrolling in Projekten, 20.9.02 in Köln, Management Circle. Fiedler, R., Gräf, J., Einführung in das Controlling, 3. Aufl., München, Wien 2010 (in Vorbereitung). Gerhardt, W., Knobel, C., Portfoliomanagement zur effizienten Auswahl von Projekten, in: Boutellier, R., Völker, R., Voit, E. (Hrsg.), Innovationscontrolling, München, Wien 1999, S. 86 – 101. Hamel, G., Prahalad, C., Wettlauf um die Zukunft, Berlin 1997. Henning, J., Was muss ein erfolgreiches F + E-Controlling leisten?, in: Boutellier, R., Völker, R., Voit, E. (Hrsg.), Innovationscontrolling, München, Wien 1999, S. 40. Hilpert, N., Rademacher, G., Sauter, B., Projekt-Management und ProjektControlling im Anlagen- und Systemgeschäft, Frankfurt 2001. Hórvath, P., Controlling, 11. Aufl. München 2008. Hügler, G., Controlling in Projektorganisationen, München 1988. Kaplan, R., Norton, D., Balanced Scorecard. Strategien erfolgreich umsetzen, Stuttgart 1997. Kargl, H., Projektcontrolling, HMD (2001) 217, S. 14 – 21. Kneuper, R., CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration, 2. Auflage, Heidelberg 2006.

274

Literaturverzeichnis Koreimann, D., Projekt-Controlling, Weinheim 2005. KPMG (Hrsg.), Integriertes Risikomanagement, Berlin 1998. Krüger, A., Schmolke, G., Vaupel, R., Projektmanagement als kundenorientierte Führungskonzeption, Stuttgart 1999. Krusch, M., Mit Risk-Magament zum unternehmerischen Erfolg, Vortrag auf dem Kongress Projektmanagement von ManagementCircle am 10.11.2004. Küpper, H., Controlling. Konzeption, Aufgaben und Instrumente, 5. Aufl. Stuttgart 2008. Lachnit, L., Controllingkonzeption für Unternehmen mit Projektleistungstätigkeit: Modell zur systemgestützten Unternehmensführung bei auftragsgebundener Einzelfertigung, Großanlagenbau und Dienstleistungsgroßaufträgen, München 1994. Lechner, F., Wertorientierte Projektwahl, dargestellt am Beispiel der Pharmabranche, in: Boutellier, R., Völker, R., Voit, E. (Hrsg.), Innovationscontrolling, München, Wien 1999, S. 136 ff. Link, C., Open Project System. The SAP Interface between SAP R/3 PS and Microsoft Project, in: Empug (Hrsg.), 3. Microsoft User Conference, Stuttgart 2000, S. 17-1 ff. Litke, H.-D., DV-Projektmanagement: Zeit und Kosten richtig einschätzen, München, Wien 1996. Litke, H.-D., Projektmanagement, 2. Aufl., München, Wien 1993, S. 117 ff. sowie Daum, A., Lawa, D., Projekt-Controlling: Aufgaben und Instrumente, in: Steinle, C., Bruch, H. (Hrsg.), Controlling, Stuttgart 1998, S. 894 ff. May, G., Chrobok, R., Priorisierung des unternehmerischen Projektportfolios. zfo (2001) 2, S. 108 – 114. Menke, U., Projektcontrolling bei der FAG AG. Vortrag vom 5. Juni 2002 an der Fachhochschule Würzburg-Schweinfurt. Michel, U., Esser, J., Wohin entwickelt sich der Finanzvorstand? FAZ v. 27. Februar 2006, S. 22. Möhrle, M., Das FuE-Programm-Portfolio: Ein Instrument für das Management betrieblicher Forschung und Entwicklung, technologie & management 37 (1988) 4, S. 12 ff. Mörsdorf, M., Konzeption und Aufgaben des Projektcontrolling, München 1998. Müser, H. Controlling im Großanlagenbau, in: Reichmann, T. (Hrsg.): Controlling-Praxis, Erfolgsorientierte Unternehmensführung, München 1988, S. 338 – 353.

275

Literaturverzeichnis Nastansky, L., Haberstock, P., Der Einsatz Groupwarebasierter Multiprojektmanagement-Systeme im Controlling, Kostenrechnungspraxis 10 (1999), S. 487 – 493. Ohno, T., Das Toyota-Produktionssystem, Frankfurt u.a. 1993. Ossadnik, W., Wolf, D., Kossen, K., Optimierte Projektsteuerung durch wert-orientierte Produktlebenszyklusrechnungen. Controlling 21. Jg. 2009, H. 2, S.118-125. O.V., Handelsblatt Karriere vom 28.02.1997. Page-Jones, M., Praktisches DV-Projektmanagement: Grundlagen und Strategien; Regeln, Ratschläge und Praxisbeispiele, München, Wien 1991. Patterson, M., Fenoglio, J., Leading Product Innovation: Accelerating Growth in a Product-Based Business, New York 1999. Piechota, S., Neue Trends im Bereich MIS, Jahrbuch Finanz- und Rechnungswesen, Zürich 2001. Pinto, J., Slevin, D., Critical Success Factors across the Project Life Cycle, in: Pinto, J., Trailer, J. (Hrsg.), Project Control, Newtown 1999, S. 91 ff. Rinza, P., Projektmanagement, Düsseldorf 1985. Rosemann, S., Funke, T., Prozess-, Projekt- und Bereichssteuerung, Dimensionen 1 (2000), S. 17 f. Saaty, Th., Fundamentals of Decision Making with the Analytic Hierarchy Process, Pittsburgh 2000. Schlagheck, B., Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling: Grundlagen – Konstruktion – Anwendungsmöglichkeiten, Wiesbaden 2000. Schmitz, H., Windhausen, M., Projektplanung und Projektcontrolling – Planung und Überwachung von besonderen Vorhaben, Düsseldorf 1986. Schnupp, P. & C. Floyd: Software – Programmentwicklung und Projektorganisation. Berlin, New York 1979. Siepert, H., Projektcontrolling im Großanlagenbau, in: Männel, W. (Hrsg.), Handbuch Kostenrechnung, Wiesbaden 1992, S. 1003 ff. Software Engineering Institute (Hrsg.), CMMI for Services, Version 1.2, Februar 2009, S. 27 ff. Solaro, D. u.a., Projekt-Controlling, Stuttgart 1979.

276

Literaturverzeichnis Sommerlatte, T., F&E-Controlling aus strategischer und operativer Perspektive, in: Steinle, C., Bruch, H. (Hrsg.), Controlling, Stuttgart 1998, S. 694 – 707. Steinmann, H., Schreyögg, G., Management. Grundlagen der Unternehmensführung, 6. Aufl., Wiesbaden 2005. Töpfer, A., Das Management der Werttreiber, FAZ Juli 2000, S. 266 ff. Weber, J., Blum, H., Logistik-Controlling - Konzept und empirischer Stand, in: Weber, J., Kunz, J. (Hrsg.), Empirische Controllingforschung, Wiesbaden 2003, S. 227 – 223. Weber, J., Controllership versus Controlling, Controlling, (1997) 3, S. 182. Wieder, G., Das Projektportfolio strategisch steuern Projektpriorisierung bei der Coca-Cola Erfrischungsgetränke AG, Projektmagazin 3/2006, www.projektmagazin.de, S. 6.

277

Stichwortverzeichnis

E A Abhängigkeiten 63 Abschlußbericht 208 Abweichungsbericht 204 Actual Cost of Work Performed 190 Amortisationsrechnung 59 Anforderungen an den Controller 22 Aufbauorganisation 86 Aufwandsschätzung 104

B Balanced Scorecard 73 Berichtswesen 225 Break-Even-Analyse 57 Budget at Completion 190 Budgeted Cost of Work Performed 190 Budgeted Cost of Work Scheduled 190

C Completed Contract Methode 148 Controller-Leitbild 21 Controllingphasen 168 Cost Performance Index 190 Cost Variance 190 Cost-to-Completion 190 Cost-to-Cost-Methode 176

D Datenmodell eines MIS für das Projektcontrolling 261 Dezentrale Projektplanung 93 Durchführungskontrolle 70

Earned Value Analyse 189 Effort-Expended -Methode 176 Ermittlung des Personalbedarfs 126 Exception Reporting 204

F Fixe Kosten 141 Fortschrittsgrad 176

G Gemeinkosten 136 Gewichtete Zielstruktur 41

I Interne Zinsfußmethode 62

K Kapitalwertmethode 60 Kostenindex 193, 194 Kosten-Trenddiagramm 185

L Leistungsfortschritt 174 Leistungsindex 194 Leistungskontrolle 174

M Magisches Dreieck 8, 9 Methoden und Tools 253 MS Office Solution EPM 254 Multiprojektcontrolling 16 Multiprojektcontrolling 15

N Nutzwertanalyse 256

279

Stichwortverzeichnis

O Operative Projektkontrolle 169 Organisation des Projektcontrollings 23

P Percentage of Completion Methode 148, 149 Prämissenkontrolle 70 Projektaufwandsschätzung 104 Projektcontroller 20 Projektcontrolling 11 Projektcontrolling bei der Lufthansa Systems GmbH 26 Projektdefinition 6 Projektkontrolle 168 Projektkostenkalkulation 135 Projektmanagement 7 Projektplanung 84 Projektressourcen 126 Projekt-Scorecard 77 Projektstatusberichte 234 Projektziele 85

R Rentabilität 58 Ressourcenplanung 126 Return on Investment (ROI) 59 Risikoanalyse 162 Risikomanagementplan 158 Risikoübertragung 157 Risikoüberwachung 159 Risk Map 155

280

S SAP R/3 251 SAP R/3, Modul PS 250 Schätzmethoden 101 Schedule Performance Index 190 Schedule Variance 190 Sofortmaßnahme 179 Sollkosten 189 Standardbericht 204 Standardstrukturplan 95 Strategische Projektkontrolle 70 Strategische Projektplanung 36

T Terminkontrolle 180 Termin-Trenddiagrammen 183 Time-to-Completion 180 Time-to-Completion 172

V Variable Kosten 141

W Wertorientierte Strukturplan 97 Wirtschaftlichkeit 53

Z Zeit-/Kostendiagramm 186 Zielkonflikte 42

Controlling von Projekten Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle

Controlling von Projekten: Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle, 5. Auflage

Controlling von Projekten

Integriertes Wissens- und Innovationsmanagement: Mit Fallstudien und Beispielen aus der Unternehmenspraxis (Lehrbuch)

Vieweg Verlag - Controlling von Projekten 4. Auflage

Leitidee Daten und Zufall: Von konkreten Beispielen zur Didaktik der Stochastik

Schallabsorber und Schalldämpfer - Innovative akustische Konzepte und Bauteile mit praktischen Anwendungen und konkreten Beispielen 2.Auflage

Schallabsorber und Schalldämpfer: Innovative akustische Konzepte und Bauteile mit praktischen Anwendungen in konkreten Beispielen, 2. Auflage

Psychosomatische Aspekte der Adipositas

Aktuelle vertrags- und urheberrechtliche Aspekte der Erstellung, des Vertriebs und der Nutzung von Software (German Edition)

Rechtsmedizinische Aspekte der Notfallmedizin

Aktuelle Aspekte der Pathogenese und Therapie der Schizophrenie

Basiswissen Gleich- und Wechselstromtechnik: Mit ausführlichen Beispielen

Aspekte der Morphosyntax und Tonologie im Buli: mit Schwerpunkt auf dem Buli von Wiaga

Von der Generation und Geburt der Metallen

Gesundheit aus der Apotheke Gottes. Ratschläge und Erfahrungen mit Heilkräutern

Alle Zeit der Welt

Alle Lust der Welt

Marktsegmentierung in der deutschen Unternehmenspraxis

Alle Lust Der Welt

Alle in einem Boot-Ökumene-und der Preis der Einheit

Alle Zeit der Welt

Rheumatologie aus der Praxis: Kurzlehrbuch der entzundlichen Gelenkerkrankungen mit Fallbeispielen

Statik der Flächentragwerke: Einführung mit vielen durchgerechneten Beispielen

Management von Netzwerkorganisationen: Beitrage aus der

Ethisch und rechtlich konformes Verhalten von Fuhrungskraften und Mitarbeitern: Ein Leitfaden mit Mustertexten und Beispielen

Der Mann aus der Vergangenheit

Der Prophet aus der Wueste

Der Mann aus der Vergangenheit

Der Dämon aus der Tiefe

Der Tod aus der Urne

Controlling von Projekten Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle