Controlling von Projekten

Rudolf Fiedler Controlling von Projekten Leserstimmen zu vorangegangenen Auflagen: „Sehr gut strukturierter Überblic...

Author: Rudolf Fiedler

109 downloads 2257 Views 9MB 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

Leserstimmen zu vorangegangenen Auflagen: „Sehr gut strukturierter Überblick zum Thema Projektcontrolling mit allen Aspekten. Durch die Praxisbeispiele gelingt der Übergang von der Theorie zum tatsächlichen Doing.“ Prof. Dr. Eduard Heindl, HS Furtwangen

„Dieses Buch werde ich meinen Studenten empfehlen, weil es einen prägnanten Überblick über das Controlling von Projekten gibt.“ Prof. Dr. Reinhard J. Weck, HS Wismar

„Das Buch ‘Controlling von Projekten’, das sich durch Aufbau, Inhalt und Darstellungsform deutlich positiv von anderen Controllingbüchern abhebt, ist eine sehr wertvolle Informationsquelle für Praktiker und Studierende.“ Prof. Dr. Dr. Bernd Schneider, HS Niederrhein

Rudolf Fiedler

Controlling von Projekten Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle 4., verbesserte Auflage Mit 209 Abbildungen

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

Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.

1. Auflage 2001nen unter dem Titel „Theorie und Praxis relationaler Datenbanken“ 2. Auflage 2003 3. Auflage 2005 4., verbesserte Auflage 2008 Alle Rechte vorbehalten © Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2008 Lektorat: Sybille Thelen / Andrea Broßler Der Vieweg Verlag ist ein Unternehmen von Springer Science+Business Media. www.vieweg.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.

Konzeption und Layout des Umschlags: Ulrike Weigel, www.CorporateDesignGroup.de Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Umschlagbild: Nina Faber de.sign, Wiesbaden Printed in Germany ISBN 978-3-8348-0375-7

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 großer 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 Balanced Scorecard Risikocontrolling

3. Operatives Projektcontrolling 3.1 Projektplanung 3.2 Projektkontrolle Ziele, Organisation, Phasen, Aufgaben, Aufwand, Termine, Ressourcen, Kosten- und Erlöse

Leistung, Termine, Kosten, Projekterfahrungen, Berichtswesen

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 Balanced Scorecard und des Risikocontrollings 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 4. 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 die Praxisbeispiele trotz ihrer hohen Arbeitsbelastung verfasst.

VI

Vorwort Heinz-Georg Boßmann und Thomas Brunschede von der Le Bihan Consulting GmbH verdeutlichten die Anwendungsmöglichkeiten von OPX2 für das strategische Projektcontrolling. 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 Zürich 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 Informationen über Projektmanagement und Projektcontrolling unter den Adressen • www.projektcontroller.de, und • www.competence-site.de im Internet abrufen. Seminare über Projektcontrolling und Projektmanagement werden unter www.projektcontroller.de angeboten. Würzburg, im September 2007

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............................................... 1 Controlling.............................................................................. 10 Projektcontrolling ................................................................... 11 Zusammenfassung .................................................................. 33

2

Strategisches Projektcontrolling 35 2.1 Strategische Projektplanung ................................................... 36 2.1.1 Überblick....................................................................... 36 2.1.2 Grobe Vorselektion ....................................................... 41 2.1.3 Bewertung der Attraktivität........................................... 41 2.1.3.1 Nutzwertanalyse 42 2.1.3.2 Portfolios 49 2.1.3.3 Wirtschaftlichkeitsverfahren 53 2.1.3.4 Risikocontrolling 63 2.1.4 Analyse der Abhängigkeiten ......................................... 79 2.1.5 Analyse der Ressourcenverfügbarkeit und Projektauswahl ....................................................... 81 2.2 Strategische Projektkontrolle.................................................. 86 2.3 Projekt-Scorecard ................................................................... 89 2.4 Zusammenfassung .................................................................. 98

3

Operatives Projektcontrolling 99 3.1 Operative Projektplanung ..................................................... 100 3.1.1 Überblick..................................................................... 100 3.1.2 Projektziele ................................................................. 101 3.1.3 Aufbauorganisation ..................................................... 102 3.1.4 Projektphasen .............................................................. 103 3.1.5 Projektaufgaben und Projektstruktur........................... 108 3.1.6 Projektaufwand ........................................................... 116 3.1.7 Terminplanung ............................................................ 125 3.1.8 Ressourcenplanung ..................................................... 146 3.1.9 Kosten- und Erlösplanung........................................... 155 3.2 Operative Projektkontrolle.................................................... 176 3.2.1 Überblick..................................................................... 176

IX

Inhaltsverzeichnis 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.6.1

Leistungskontrolle....................................................... 181 Terminkontrolle .......................................................... 188 Kostenkontrolle........................................................... 196 Auswertung der Projekterfahrungen ........................... 209 Berichtswesen und Dokumentation............................. 212 Berichtswesen in einem Produktbereich der Robert Bosch GmbH 218 3.2.6.2 Berichtswesen der Outokumpu Technology GmbH 232 3.2.6.3 Berichtswesen der Zürich Gruppe Deutschland 240 3.2.6.4 Fortschrittsbericht der Lufthansa Systems 242 3.2.7 Kennzahlen ................................................................. 249 3.3 Zusammenfassung ................................................................ 253

4

DV-Unterstützung 257 4.1 Projektmanagementsoftware................................................. 258 4.1.1 SAP R/3 ...................................................................... 261 4.1.2 MS-Project .................................................................. 263 4.2 Einführung einer Projektmanagementsoftware..................... 265 4.3 Führungsinformationssysteme.............................................. 267 4.3.1 Aufbau des Führungsinformationssystems der MIS AG....................................................................... 269 4.3.2 Projektdatenanalyse mit dem Delta Master................. 272 4.4 Zusammenfassung ................................................................ 280

Literaturverzeichnis Stichwortverzeichnis

X

281 287

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:

Projektarten................................................................................. 2 Projektkriterien der Versicherungskammer Bayern.................... 4 Übersicht der Projekt-Kategorien der Outokumpu Technology GmbH ................................................. 6 Das „magische Dreieck“ des Projektmanagements .................... 8 Einflussfaktoren für den Projekterfolg...................................... 10 Aufgaben des Projektcontrollings............................................. 13 Stellung des Projektcontrollings ............................................... 13 Bausteine des Einzel- und Multiprojektcontrollings................. 15 Aufgaben des Projektcontrollings............................................. 16 Träger des Projektcontrollings.................................................. 19 Aufgabenschwerpunkte des Projektcontrollers......................... 20 Aufgaben von Projektleiter und Projektcontroller .................... 21 Controllerleitbild....................................................................... 22 Anforderungen an den Projektcontroller................................... 22 Hierarchische Einbindung des Projektcontrollers..................... 23 Aufgabenteilung im Projektcontrolling .................................... 23 Matrix-Projektorganisation ....................................................... 24 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 Verantwortlichkeitsmatrix in OPX2 ......................................... 37 Projektbewertung in OPX2 ....................................................... 38 Projektpriorisierung in OPX2 ................................................... 39 Ausgewogenheit des Projektportfolios ..................................... 39 Prozess der strategischen Projektauswahl................................. 40 Systematische Vorgehensweise bei der Zielfindung................. 43 Gewichtete Zielstruktur ............................................................ 43 Analyse möglicher Zielkonflikte .............................................. 44 Zielgewichtung mit der Präferenzmatrix .................................. 45 Ausgangsmatrix ........................................................................ 46 Quadrierte Matrix ..................................................................... 46 Normalisierte Matrix................................................................. 46 Vergleich der Zielgewichte....................................................... 47 Nutzwertanalyse ....................................................................... 48 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. 40: 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 ..................................................... 60 Berechnung des Net Present Value........................................... 62 Einfluss der Projekte auf den Unternehmenswert..................... 63 Bausteine des Risikocontrollings.............................................. 64 Detaillierung der Projektstruktur .............................................. 66 Klassifizierung von Projektrisiken in einer Risk Map .............. 68 Praxisbeispiel für die Projektrisikobewertung .......................... 68 Beurteilung zusätzlicher Risikofaktoren................................... 69 Möglichkeiten der Risikosteuerung .......................................... 70 Möglichkeiten der Risikovorbeugung....................................... 70 Formblätter für eine systematische Risikoanalyse .................... 72 Auszug aus ProRisk .................................................................. 76 Verkürzte Darstellung einer Risiko-Analyse ............................ 78 Einflussmatrix........................................................................... 79 Portfolio zur Analyse der Abhängigkeiten................................ 80 Ablauf des Zero Base Budgeting .............................................. 83 Ergebnisniveaus für das Projekt „Vernetzung“......................... 84 Budgetschnitt ............................................................................ 84 Überblick über die strategische Projektkontrolle...................... 86 Arten der strategischen Kontrolle ............................................. 87 Attraktivitäts-Portfolio.............................................................. 88 Wirkungen einer Balanced Scorecard....................................... 90 Perspektiven der Balanced Scorecard ....................................... 91 Aufbau der Balanced Scorecard................................................ 91 Ableitung der Projekt-Scorecard............................................... 92 Gewichtung der Perspektiven und Ziele ................................... 93 Ermittlung der Zielerreichung................................................... 94 Darstellung der Projektsituation ............................................... 95 Cockpitchart einer Projekt-Scorecard ....................................... 97 Überblick über die operative Projektplanung ......................... 100 Faktoren für den Projekterfolg in einzelnen Phasen ............... 104 DV-System zur Beschreibung der Projektphasen ................... 106 Auszug aus einer Know-how-Datenbank zur Beschreibung von Prozessschritten ............................................................... 107 Auszug aus der Dokumentation eines Prozessschrittes........... 107 Projektneutrale Kalkulation .................................................... 108 Schrittweise Konkretisierung der Projektplanung .................. 110 Gliederung eines Standardstrukturplans ................................. 111 Zuordnung von technischer Struktur und Strukturplan........... 112

Abbildungsverzeichnis Abb. 85: Abb. 86: Abb. 87: Abb. 88: Abb. 89: Abb. 90: Abb. 91: Abb. 92: Abb. 93: Abb. 94: Abb. 95: Abb. 96: Abb. 97: Abb. 98: Abb. 99: Abb. 100: Abb. 101: Abb. 102: Abb. 103: Abb. 104: Abb. 105: Abb. 106: Abb. 107: Abb. 108: Abb. 109: Abb. 110: Abb. 111: Abb. 112: Abb. 113: Abb. 114: Abb. 115: Abb. 116: Abb. 117: Abb. 118: Abb. 119: Abb. 120: Abb. 121: Abb. 122: Abb. 123: Abb. 124: Abb. 125: Abb. 126:

Aufbau des Zielprozesses Angebot mit Übergang zum Entwicklungszielprozess ............................................... 113 Wertorientierter Projektstrukturplan ..................................... 115 Wertermittlung für ein Arbeitspaket ..................................... 116 Ablauf der Delphi-Methode .................................................. 118 Aufwandsverteilung in Softwareprojekten............................ 119 Relative Anteile von Aufwand und Zeitdauer....................... 120 Function-Point-Kurve ........................................................... 121 Terminplanung ...................................................................... 125 Netzplanverfahren................................................................. 126 Netzplan (generiert mit MS-Project)..................................... 127 Berechnung der frühesten Vorgangszeitpunkte .................... 129 Berechnung der spätesten Vorgangszeitpunkte..................... 129 Beschriftungsalternativen für Netzplanknoten...................... 130 Einplanung einer Managementreserve .................................. 131 Steuerung des Projektportfolios mit der Managementreserve .............................................................. 133 Projektziele des Beispiels...................................................... 133 Erlösveränderung in Abhängigkeit der Projektdauer ............ 135 Abhängigkeit der Kosten von der Vorgangsdauer ................ 136 Mittlere Beschleunigungskosten. .......................................... 137 Netzplan für die Ermittlung des Reduktionspotenzials ......... 139 Bestimmung des Reduktionspotenzials................................. 139 Zahl der Kommunikationsbeziehungen in einer Gruppe....... 141 Einfluss der Gruppengröße auf die Projektdauer .................. 142 Wirkung des Ressourceneinsatzes auf die Projektdauer und den ROI................................................................................. 143 Auswirkungen zusätzlicher Ressourcen................................ 144 Ressourcenbelastungsdiagramm ........................................... 147 Kapazitätsbelastungsdiagramm mit verfügbarer Kapazität... 148 Verfügbare Personalstunden pro Monat................................ 149 Funktionsmatrix .................................................................... 151 Ressourceneinplanung in MS-Project ................................... 151 Kapazitätsausgleich............................................................... 152 Systematik der Stundenplanung in Kundenaufträgen ........... 154 Systematik der Auslastungsplanung...................................... 154 Abrechnungsfluss der Budgetierung ..................................... 155 Daten für die Projektkostenkalkulation................................. 156 Einteilung der Mitarbeiter in Kategorien .............................. 157 Errechnung eines Standardstundensatzes.............................. 157 Projektkostenkalkulation....................................................... 159 Ausschnitt einer Projektkalkulation auf Basis einer Standardvorlage ........................................................... 160 Beispiel einer Angebotsübersicht.......................................... 161 Retrograde Projektkalkulation .............................................. 162 Vereinfachte Kalkulationsstruktur ........................................ 163

XIII

Abbildungsverzeichnis Abb. 127: Abb. 128: Abb. 129: Abb. 130: Abb. 131: Abb. 132: Abb. 133: Abb. 134: Abb. 135: Abb. 136: Abb. 137: Abb. 138: Abb. 139: Abb. 140: Abb. 141: Abb. 142: Abb. 143: Abb. 144: Abb. 145: Abb. 146: Abb. 147: Abb. 148: Abb. 149: Abb. 150: Abb. 151: Abb. 152: Abb. 153: Abb. 154: Abb. 155: Abb. 156: Abb. 157: Abb. 158: Abb. 159: Abb. 160: Abb. 161: Abb. 162: Abb. 163: Abb. 164: Abb. 165: Abb. 166: Abb. 167: Abb. 168: Abb. 169:

XIV

Stufen der Deckungsbeitragsrechnung.................................. 164 Projektkostenplanung............................................................ 165 Zusammensetzung des aktuellen Budgets............................. 166 Kostenschätzung ................................................................... 167 Ermittlung der Liquidität....................................................... 168 Liquiditätsverlauf in einem Entwicklungsprojekt ................. 169 Ablauf der Cash Flow-Planung ............................................. 169 Grafische Darstellung der Cash Flow-Analyse ..................... 171 Integration der Daten aus Projekttätigkeit und Nichtprojekttätigkeit in die Unternehmensrechnung...... 174 Überblick über die operative Projektkontrolle ...................... 176 Elemente der Projektsteuerung und –kontrolle ..................... 177 Auszug aus dem System ZZMA ........................................... 179 Projektsteuerung mit Prognosedaten..................................... 180 Schritte der Projektkontrolle ................................................. 181 Beispiel für die Ermittlung des Leistungsfortschritts............ 182 Ermittlung des Projektfortschritts ......................................... 183 Kreislauf der Leistungserbringung........................................ 185 Tatsächlicher Leistungsfortschritt ......................................... 186 Projektfortschrittsbericht in MS-Project ............................... 188 Balkenplan mit Time-to-Completion .................................... 189 Termin-Trenddiagramm........................................................ 190 Kurvenverläufe im Termin-Trenddiagramm......................... 191 Zusammenspiel von Terminplan und MeilensteinTrendanalyse basierend auf MS-Project ............................... 192 Praktisches Beispiel zur Meilenstein-Trendanalyse.............. 193 Kosten-Trenddiagramm ........................................................ 194 Zeit-/Kosten-Trenddiagramm ............................................... 195 Kostenkontrolle..................................................................... 196 Kumulierte Ist- und Plankosten............................................. 197 Beispieldaten für die Earned Value Analyse......................... 200 Diagramm für die Earned Value Analyse ............................. 201 Kostenabweichung als Fieberkurve ...................................... 202 Leistungsabweichung als Fieberkurve .................................. 202 Kosten- und Leistungsindex mit Abweichungskorridor........ 204 Trompetenkurve .................................................................... 204 Berechnung der voraussichtlichen Gesamtkosten mit unterschiedlichen Annahmen für die Restkosten............ 206 Multiprojektcontrolling mit der Earned Value Analyse........ 207 Earned Value Analyse mit MS Project ................................. 209 Ursachen für aufgetretene Probleme ..................................... 210 Bewertung der Projektkomplexität........................................ 212 Ausnahmebericht mit Ampelfunktion................................... 213 Inhalte des Fortschrittsberichts ............................................. 215 Deckblatt eines Fortschrittsberichts ...................................... 215 Beschreibung eines Berichts ................................................. 216

Abbildungsverzeichnis Abb. 170: Zwei Auszüge aus einer beispielhaften „elektronischen Projektakte“................................................. 218 Abb. 171: Berichte, Berichtsgremien und Berichtshäufigkeit ............... 219 Abb. 172: Darstellung des Projekt-Cockpits.......................................... 220 Abb. 173: Regelmeetingbericht ............................................................. 223 Abb. 174: Ampelfarbenbelegung........................................................... 224 Abb. 175: Belegung der Ampelfarben nach vorgegebenen Regeln ....... 225 Abb. 176: Wochenbericht ...................................................................... 226 Abb. 177: Dokumentation von Änderungen .......................................... 228 Abb. 178: Änderungserfolgsrechnung ................................................... 229 Abb. 179: Schematisierter Ablaufplan der Controlling-Aktivitäten ...... 232 Abb. 180: Kategorien für Projektberichte.............................................. 234 Abb. 181: Deckblatt Projektmonatsbericht ............................................ 236 Abb. 182: Projektkostenbericht.............................................................. 237 Abb. 183: Einzelpostenbericht............................................................... 238 Abb. 184: Stundenbericht ...................................................................... 239 Abb. 185: Planungs- und Reportingdimensionen der Zürich Gruppe Deutschland .................................................. 241 Abb. 186: ProControl-Client (1 von 4) .................................................. 244 Abb. 187: ProControl-Client (2 von 4) .................................................. 244 Abb. 188: ProControl-Client (3 von 4) .................................................. 245 Abb. 189: ProControl-Client (4 von 4) .................................................. 245 Abb. 190: ProControl-Frühwarnsystem (1 von 3) ................................. 247 Abb. 191: ProControl-Frühwarnsystem (2 von 3) ................................. 248 Abb. 192: ProControl-Frühwarnsystem (3 von 3) ................................. 248 Abb. 193: Kennzahlenarten.................................................................... 249 Abb. 194: Schema für die Definition einer Kennzahl ............................ 250 Abb. 195: Kennzahlen für das Projektcontrolling.................................. 251 Abb. 196: Vergleich des Moduls PS von SAP R/3 und MS-Project...... 260 Abb. 197: Integrationsbeziehungen des Moduls PS............................... 261 Abb. 198: Darstellung der Projektstruktur im PS-Modul von SAP R/3 ................................................................................ 262 Abb. 199: Projektplanung und –steuerung mit SAP R/3 bei der Outokumpu Technology GmbH............................................ 263 Abb. 200: Zentrale Planungsmaske in MS-Project ................................ 264 Abb. 201: Systematische Bewertung und Auswahl von Projektmanagementsoftware mit der Nutzwertanalyse ......... 266 Abb. 202: Datenversorgung eines MIS.................................................. 268 Abb. 203: Wesentliche Informationsbausteine zur quantitativen Analyse............................................................ 269 Abb. 204: Projekt- und Ressourcendimensionen ................................... 271 Abb. 205: Hyperbrowser im Delta Master ............................................. 273 Abb. 206: Abweichungsanalyse für die Earned Value Kennzahlen....... 274 Abb. 207: Portfoliodarstellung der Leistungs- und Kostenabweichung. 276 Abb. 208: Identifikation auffälliger Arbeitspakete ............................... 278 Abb. 209: Identifikation der Verursacher einer Abweichung ............... 279

XV

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

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 1

1 Überblick über das Projektcontrolling

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 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 Unterneh-

2

1.1 Projekt- und Projektmanagement

menserfolg 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. Oft umfangreich Planung, Steuerung und Kontrolle von Projekten verursachen einen hohen Aufwand, den man nur bei besonders umfangreichen Vorhaben investieren sollte. Mit Unsicherheit und Risiko behaftet 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: Definition

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: • •

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

1

4

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


Die Zürich 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. 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). 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 Berichterstattung, 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.

5

Projektcontrolling

PS

monatlich

Projektcontrolling

PS

Projektcontrolling

PS

zwei- bis dreimonatlich keine

Projektcontrolling

PS

bei Bedarf

Projektcontrolling

PS

keine

CO

keine

CO

keine

CO

keine

Liste aller Änderungen

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

Realisierungsplanung

Projektberichte

Cash Flow-Planung

SAP R/3

Risikoanalyse

Zuständigkeit

Startkalkulation

Projekt Kategorie

Führen im Auftragsbestand


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

Bei der Durchführung von Projekten tauchen Fragen auf wie: • 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. Man kann feststellen, dass:

6


• •

•

Projekte zunehmend komplexer werden; vor allem Forschungs- und Entwicklungsprojekte mit einem erheblichen Risiko behaftet sind. 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 Medien- und Softwarebranche zehn zu eins;2 viele Projekte fehlerträchtig sind. Die Standish Group stellte in ihrem viel beachteten "Chaos Report" 1994 fest, dass 31 Prozent aller Softwareprojekte vorzeitig abgebrochen werden.3 Bis heute besteht das Problem, dass ein erheblicher Teil der in Softwareprojekten erstellten Programme erst nach erheblichen Modifikationen oder überhaupt nicht genutzt werden kann. 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 weitgehend nutzlosen Programmcode und 1,6 Millionen Seiten Dokumentation vorzuweisen.4

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

Definition

Führungsaufgaben sind nach der klassischen Managementlehre Planung, Kontrolle, Organisation und Personalführung. Dazu muss die Informationsversorgung sichergestellt werden. Projektmanagement umfasst also das •

WAS eines Projektes (alle Aufgaben, die im Rahmen der Planung, Kontrolle, Personalführung und Informationsversorgung anfallen), z. B.: − Abgrenzung der Projektaufgaben,

2

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.

3 4

7

1 Überblick über das Projektcontrolling − −

•

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); − − −

•

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 Ziele verfolgt man mit Projektmanagement? Projektmanagement dreht sich immer um die drei Ziele des "magischen Dreiecks": Dauer

Wirtschaftlicher Erfolg

Leistung

Abb. 4: Das "magische Dreieck" des Projektmanagements • • •

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 Be-


trachtungsweise 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 Faktoren beeinflussen den Projekterfolg? 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. Weitere Erfolgsfaktoren erkannten US-Wissenschaftler, die 650 Projekte untersuchten und folgende Kardinalfehler bei der Projektabwicklung identifizierten:5 • • • • • • •

Die Organisation ist nicht auf das Projekt abgestimmt. Risiken bleiben unberücksichtigt. Es mangelt an Teamgeist und Identifikation mit dem Projekt. Das Team wird nicht an der Terminplanung beteiligt. Entscheidungen werden verzögert. Notwendige Änderungen des Plans kommen zu spät. Vor allem aber: Die Befugnisse des Projektleiters sind zu gering.

Erfolgreiche Projektabwicklung erfordert neben Fachwissen und einem angemessenen Methodeneinsatz auch die Berücksichtigung psychologischer Aspekte.

5 Handelsblatt Karriere vom 28.02.1997.

9


Fachwissen

Instrumente

Psychologie

Projekterfolg

Methodik

Erfahrung

Abb. 5: Einflussfaktoren für den Projekterfolg Für den Erfolg eines Projekts sind vor allem die "weichen Faktoren" entscheidend. Hierzu gehören 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 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". 1.2

Controlling

Welche Aufgaben hat das Controlling? Das Management und auch die ausführenden Abteilungen sind vor allem im großen Unternehmen stark spezialisiert. Durch diese Arbeitsteilung entsteht ein hoher Abstimmungsbedarf. Controlling hat primär die Aufgabe, zwischen Planung, Kontrolle und Informationsversorgung zu koordinieren (so genannte systemkoppelnde Funktion des Controllings).6 Manche Autoren erweitern das Aufgabenspektrum um Organisation und Personalführung.7 Die Daten der Planung sind z. B. so aufzubereiten, dass eine Kontrolle möglich 6 7

10

Hórvath, P., Controlling, 10. Aufl. München 2006. Küpper, H., Controlling. Konzeption, Aufgaben und Instrumente. 4. Aufl. Stuttgart 2005.

1.3 Projektcontrolling

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. Wichtig ist auch 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. Natürlich 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. 1.3

Projektcontrolling

Welche Aufgaben hat das 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".

Definition

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

Hügler, G.8

8

• Aufbau und Pflege eines Systems zu Projektplanung und Projektkontrolle • Einrichten des Projektberichtswesens • Abstimmungsaufgaben bei der Zielbildung • Planung der Kosten und des Finanzmittelbedarfs • Soll-Ist-Vergleiche und Abweichungsanalyse • Berichterstattung und Organisation von Projektmeetings

Literatur

Hügler, G., Controlling in Projektorganisationen, München 1988.

11


Solaro, D. u. a.9 Alter, R.10 Daum, A., Lawa, D.11

• • • • • • •

• • • • • • • • •

Krüger, A., Schmolke, G., Vaupel, R.12

Hilpert, N., Rademacher, G., Sauter, B. 13

9 10 11 12 13

12

• • • • • • • • • • • • • • •

Rentabilitätsberechnungen, Liquiditätsberechnungen Mitlaufende Kalkulation, Restkostenschätzung Risikoanalyse und Risikobewertung Projektorientiertes Rechnungswesen, Berichtswesen Beurteilung von Projektalternativen Mitwirkung bei der Erstellung des Abschlussberichts Mitwirkung bei der Erarbeitung von Projektzielen o Informationsbereitstellung o Koordination und Moderation o Handhabung von Zielkonflikten Unterstützung des Risikomanagements Mitwirkung bei der Festlegung der Projektorganisation Entwicklung und Einrichtung eines Planungs-, Kontrollund Informationssystems Mitwirkung bei der Maßnahmenplanung Durchführung der Kostenplanung Detaillierung der Ressourcen- und Terminplanung Überwachung von Kosten, Leistungen und Terminen Durchführung der Abschlusskontrolle und Abschlussdokumentation Pflege und Weiterentwicklung des Projektmanagementsystems Mitwirkung bei der Projektstrukturierung Prüfung der Arbeitspakete Unterstützung der Personalführung Koordination von Teilplänen Gewährleistung einer richtlinienkonformen Projektplanung Überwachung der im Projekt realisierten Wertschöpfung Sicherstellung der Informationsversorgung Mitwirkung bei der Gestaltung des Berichtswesens Sicherstellung der Übereinstimmung von Verantwortung und Kompetenz der Projektbeteiligten Hilfe bei der Auswahl projektbezogener Anreizsysteme Projekte begleiten, indem der Projektleiter entlastet wird Sicherstellung der Transparenz des Projektgeschehens Unterstützung der Planung Unterstützung der wirtschaftlichen Projektabwicklung Entwicklung und Pflege von Methoden und Hilfsmitteln

Solaro, D. u. a., Projekt-Controlling, Stuttgart 1979. Alter, R., Integriertes Projektcontrolling, Gießen 1991. 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.

1.3 Projektcontrolling Koreimann, D.14

• • • •

Laufende Überwachung der Projekte Beratung der Projektinstanzen Definition der Kontrollobjekte Finanzcontrolling steht gleichberechtigt neben dem Inhaltscontrolling

Abb. 6: Aufgaben des Projektcontrollings Die Aussagen verdeutlichen, dass sich ein Projektcontrolling nicht auf die Planung und Kontrolle der Kosten beschränken darf. Der Servicecharakter eines Projektcontrollings, das alle Projektmanagementaufgaben unterstützt, wird erkennbar. Auch die DIN 69901 beschreibt die Aufgaben des Projektcontrollings sehr umfassend. Für das Verständnis ist es wichtig, die Stellung des Projektcontrollings zum allgemeinen Unternehmenscontrolling und zum Projektmanagement herauszuarbeiten (vgl. Abb. 7). 15

Strategisch

Strategisches Projektcontrolling (Portfolio-Controlling)

Strategisch

Operatives Multiprojektcontrolling

Operativ

EinzelProjektcontrolling

Operativ

CONTROLLING

PROJEKTMANAGEMENT

PROJEKT-

CONTROLLING Abb. 7: Stellung des Projektcontrollings Projektcontrolling garantiert auf der einen Seite die Verbindung der Projektplanung, -steuerung und -kontrolle mit dem Unternehmens14 15

Koreimann, D., Projekt-Controlling, Weinheim 2005, S. 65 ff. Die Begriffe Einzelprojektcontrolling, Multiprojektcontrolling und strategisches Projektcontrolling werden nicht einheitlich verwendet. Üblich ist es auch, das strategische Projektcontrolling als strategisches Multiprojektcontrolling oder Portfoliocontrolling zu bezeichnen.

13


controlling. 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-, DVsowie Finanz- und Investitionscontrolling gesehen werden. Projektcontrolling unterstützt andererseits die Projektleitung bei der Wahrnehmung ihrer Führungsaufgaben im Rahmen des Projektmanagements. Es kümmert sich in diesem Sinne um die grundlegende Gestaltung der Strukturen und Prozesse, die für eine effiziente Projektabwicklung erforderlich sind, und in vielfältiger Weise um die Koordination der Projektmanagementaufgaben (vgl. Abb. 9). Zu unterscheiden sind Einzelprojektcontrolling, Multiprojektcontrolling und strategisches Projektcontrolling:

14

•

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.16 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 Multiprojektcontrolling mehrere Projekte (Projektgruppen bzw. die Projektgesamtheit) mit unterschiedlichen Terminen und Fertigstellungsständen für eine Abrechnungsperiode zusammengefasst betrachtet (vgl. Abb. 8). 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)

16

Kellner, H., Die Kunst, DV- Projekte zum Erfolg zu führen: Budgets – Termine – Qualität, München, Wien 1994, S. 11.


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. 8: Bausteine des Einzel- und Multiprojektcontrollings Die wesentlichen Herausforderungen des Multiprojektcontrollings liegen in der − 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-

15


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.

Abb. 9 gibt den Rahmen für die Aufgaben eines Projektcontrollings vor. Bei der Einführung eines Projektcontrollings ist festzulegen, wie sich das Projektcontrolling im konkreten Unternehmen positioniert. 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 Zusammenfassend kann Projektcontrolling wie folgt charakterisiert werden: Definition

16

Projektcontrolling unterstützt das Projektmanagement bei der Gestaltung und laufenden Abstimmung der strategischen und operativen Projektmanagementaufgaben, insbesondere bei der Projektplanung und -kontrolle.


Die folgenden Ausführungen orientieren sich an Abb. 9: In Kap. 2 wird zunächst das strategische Projektcontrolling behandelt. Berücksichtigung finden dabei auch das Risikocontrolling und die ProjektScorecard. Beide Instrumente können im strategischen und operativen Projektcontrolling verwendet werden. 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. 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.). •

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 Zeit-

17


punkten 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. der Spartenergebnisse sind Aktivitäten des Multi-Projektcontrollings 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. 10). Manche Aufgaben des Projektcontrollings übernehmen auch andere Abteilungen, wie Qualitätssicherung, Ver18


trieb 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. 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. Grundsätzlich ist es sinnvoll, wenn auch Projektleiter und Projektmitarbeiter im Sinne eines Selbstcontrollings Projektcontrollingaufgaben wahrnehmen.

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. 10: Träger des Projektcontrollings

Welche Aufgaben hat der Projektcontroller? 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.

19


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. 11). 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:

Diagnose, Therapie 30%

Tipp Aufbreitung von Daten 70%

Sondern so:

Aufbereitung von Daten 30%

Diagnose, Therapie 70%

Abb. 11: Aufgabenschwerpunkte des Projektcontrollers Der gute Arzt wird vorbeugende Maßnahmen ergreifen, damit eine Krankheit gar nicht erst ausbrechen kann.17 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 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 außerdem, ob die operativen Projektentscheidungen im Einklang mit der Strategie sind. Im Tagesgeschäft wird schnell die Auswirkung einer Entscheidung auf Kundenbeziehungen und Marktanteile vergessen. 17 Fiedler, R., Einführung in das Controlling, 2. Aufl., München 2001, S. 6.

20


Wie arbeitet der Projektleiter mit dem -controller zusammen? Der Projektcontroller kann dem Projektleiter die Entscheidung nicht abnehmen. Während der Projektleiter das wirtschaftliche Projektergebnis, 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. 12).18

Der Projektcontroller verantwortet die Transparenz von: Der Projektleiter verantwortet: - Ergebnis - Leistung - Kosten

- Ergebnis - Leistung - Kosten

Abb. 12: Aufgaben von Projektleiter und Projektcontroller 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.19 Dies wird auch im aktuellen Controller-Leitbild der International Group of Controlling (IGC) deutlich (vgl. Abb. 13):20

18 19 20

Deyhle, A., Management & Controlling Brevier, Band 1, Manager & Controller im Team, 7. Aufl., Wörthsee-Etterschlag 1977, S. 154. 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

1 Überblick über das Projektcontrolling Controller gestalten und begleiten den Management-Prozess der Zielfindung, Planung und Steuerung und tragen damit Mitverantwortung für die Zielerreichung. Das heißt: • Controller sorgen für Strategie-, Ergebnis-, Finanz-, Prozesstransparenz und tragen somit zu höherer Wirtschaftlichkeit bei. • Controller koordinieren Teilziele und Teilpläne ganzheitlich und organisieren unternehmensübergreifend das zukunftsorientierte Berichtswesen. • Controller moderieren und gestalten den Managementprozess der Zielfindung, der Planung und der Steuerung so, dass jeder Entscheidungsträger zielorientiert handeln kann. • Controller leisten den dazu erforderlichen Service der betriebswirtschaftlichen Daten- und Informationsversorgung. • Controller gestalten und pflegen die Controllingsysteme.

Abb. 13: Controllerleitbild

Welche Qualifikation sollte der Projektcontroller aufweisen? 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. 14: Anforderungen an den Projektcontroller Abb. 14 zeigt persönliche und fachliche Anforderungen, wie man sie vielfach den Stellenannoncen für Projektcontroller entnehmen kann. Die persönliche Qualifikation entspricht derjenigen, die auch eine Führungskraft aufweisen sollte. Häufig ist die erfolgreiche Controllingarbeit eine hervorragende Voraussetzung für eine Karriere im Management. Vorteilhaft ist es, wenn frühere Projektleiter als Projektcontroller installiert werden. Sie kennen die typischen Probleme und werden als kompetenter Ansprechpartner akzeptiert.

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 Leiter die Gesamtverantwortung trägt. Dazu müssen ihm alle

22


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. 15). 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. 15: Hierarchische Einbindung des Projektcontrollers Bei größeren Unternehmen, die regelmäßig viele Projekte abwickeln, ist es vorteilhaft, das Projektcontrolling zu differenzieren (vgl. Abb. 16): Zentrales Projektcontrolling

Multiprojektcontrolling

Gewährleistung der Projektkultur, Unterstützung der Projektauswahl Abstimmung parallel laufender Projekte Fokus: Periode

Einzelprojektcontrolling

Unterstützung konkreter Einzelprojekte Fokus: Projektlaufzeit

Abb. 16: Aufgabenteilung im Projektcontrolling 23


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 Ingenieurfachabteilungen 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. 17. Ingenieurtechnik

Beschaffung

Projektmanager Projekt A

Projektverantwortung

Bereich Projektmanagement

Verfahrenstechnik

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

Abb. 17: 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.

24


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

25

1 Überblick über das Projektcontrolling Sparte

Geschäftsbereiche

Kraftfahrzeug

...

Car Multimedia

... ...

Produktbereiche

Abteilungen

Car Radio

Forschung & Entwicklung

Instrumentation System Projektmanagement

Einkauf

Driver Information Vertrieb & Marketing

Projektleiter Projektcontrolling

Abb. 18: 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 "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,

26

1.3 Projektcontrolling − Ü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). 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 Profit-Center, damit keine n:m-Beziehungen ermöglicht werden,

27


•

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 nach Absprache auch an das zentrale Controlling.

Wie sollte ein Projektcontrolling eingeführt werden? Die Einführung des Projektcontrollings ist ein eigenes Projekt. Insofern sind auch die Instrumente des Projektmanagements zu verwenden. Das Vorgehen beinhaltet: 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? - 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 • Aufgabenumfang definieren: 28

1.3 Projektcontrolling −

• •

• • • •

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. Hierarchische Eingliederung des Projektcontrollers festlegen 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. Maßnahmen zur Beseitigung von Widerständen planen (Informationen liefern, miteinander reden, Kompromisse aushandeln) Geeignete Projektcontroller suchen 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 aufgeschlossenen 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:21 1. Initial Prozesse für die Projektabwicklung sind nicht festgelegt. Der Projekterfolg hängt vom einzelnen Projektleiter ab. Probleme werden 21

Kneuper, R., CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration, 2. Auflage, Heidelberg 2006.

29


durch ad-hoc-Maßnahmen gelöst. Projektergebnisse sind kaum vorhersehbar. 2. Repeatable 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. 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. 5. Optimized 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.22 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 über22 Koreimann, S., Projekt-Controlling. Weinheim 2005, S. 181 f.

30


zeugen 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: 1. Nach Einführung des Projektcontrollings verursachen die frühen Phasen des Projekts einen höheren Aufwand. Das sollte man gegenüber den Projektverantwortlichen auch kommunizieren, um einer Abwehrhaltung gegenüber dem Vorhaben vorzubeugen. Eine Begründung dafür ist, dass der Projektcontroller eine sorgfältige Planung einfordern wird. Die bessere Projektvorbereitung führt aber dazu, 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. 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. 19).23 Projektcontrolling nimmt nur einen Teil dieser Aufgaben wahr. Deswegen dürfte der Kostenanteil tatsächlich ge23

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

31


Anteil in %

ringer sein. Die Unternehmensberatung Horváth & Partners führt regelmäßig Benchmarks für das Unternehmenscontrolling durch. Eine Erkenntnis ist, dass die Kosten für den Controllingbereich im Durchschnitt bei 0,35 Prozent des Umsatzes liegen.24 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 Routineprozesse 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. 19 für große Projekte, so dass durch Projektcontrolling zusätzliche Kosten von ca. 1,5 bis zwei Prozent des Projektbudgets anfallen dürften.

4,0 %

0,5 % 1 Mio.

Projektbudget

100 Mio.

Abb. 19: Anteil der Kosten von Projektplanung, Projektkontrolle und Projektinformation am Gesamtbudget

Tipp

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!"

24

32

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

1.4 Zusammenfassung

1.4 • •

• •

• • •

•

• •

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.

33

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, Verfahren zur Bestimmung der Wirtschaftlichkeit und die Risikoanalyse 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

INPUT

2.1.1 Überblick Was?

AUFGABEN

Bewertung der Attraktivität

Wirtschaftlichkeitsrechnungen, Nutzwertanalyse, Portfoliotechnik, Risikoanalyse, Balanced Scorecard.

Analyse der Abhängigkeiten

Abhängigkeitsmatrix

Analyse der Ressourcenverfügbarkeit

Budgetierung, Mitarbeitereinsatzplan.

Was? Liste mit genehmigten und priorisierten Projekten

INSTRUMENTE

Grobe Vorselektion

OUTPUT

Woher?

Strategische Unternehmensziele Strategische Planung Projektvorschläge Leitung, Fachbereiche.

Wohin? Einzelprojekt- und Multiprojektcontrolling, Strategische Kontrolle.

Abb. 20: Überblick über die strategische Projektplanung Grundlage der strategischen Projektplanung sind die Unternehmensziele, die wesentliche Auswahlkriterien für die Projekte liefern. Die Projekte müssen mit den strategischen Zielen harmonieren. 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 vornherein abgeblockt oder bevorzugt werden. Jeder Vorschlag sollte zunächst die gleiche Chance haben. Ansonsten besteht die Gefahr, dass sinnvolle Vorhaben nicht realisiert werden.

36

2.1 Strategische Projektplanung

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 Zürich 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. 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.

Abb. 21: Verantwortlichkeitsmatrix in OPX2 37


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 OPX2 darüber informiert, dass ein neuer Antrag gestellt wurde und welche Aufgabe nun von ihnen erwartet wird. Für die Definition neuer Strategien stehen drei Bewertungsgruppen zur Verfügung: Risiken, Chancen und finanzielle Kriterien. Abb. 22 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. 22: Projektbewertung in OPX2 Auf Grundlage der oben definierten Strategie wird ein Projektranking erstellt. Für die Priorisierung eines Projekts wird folgende Formel verwendet: (Bewertung wirtschaftliche Ziele + Bewertung Gesamtrisiko) / Summe der Gewichte (25*10 + (-2)*27) / 8 = 24,5 Abb. 23 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.

38


Abb. 23: Projektpriorisierung in OPX2 Zu Beginn der Projektportfolioplanung sollte die aktuelle Verteilung des Projektbudgets auf Geschäftsbereiche und Projektarten betrachtet und angepasst werden. Damit nicht einzelne Projektarten, typischerweise sind das oft DV-Projekte, 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 Projektklassen gebildet und Obergrenzen für deren Anteil am Gesamtbudget festgelegt (vgl. Abb. 24): Klasse 1: Projekte zur Erschließung neuer Märkte - Neue Produkte - Aktionen am Markt

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

Klasse 2: Organisations– projekte - Prozessoptimierung - Rationalisierung

Abb. 24: Ausgewogenheit des Projektportfolios Anzustreben ist eine Gesamtbetrachtung aller Projekte. Deswegen sollte man auch die bereits genehmigten und die laufenden Projekte 39


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 Projektes möglichst früh zu erkennen, um den Schaden zu begrenzen. Nachdem alle 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. 25 zeigt den Prozess zur Bestimmung des Projektportfolios.41

STRATEGISCHE PLANUNG Sammlung der Projektvorschläge Filter 1: grobe Vorselektion Filter 2: Bewertung der Attraktivität, Analyse der Abhängigkeiten 3 2 1 2 1

Priorisierte Projekte Filter 3: Analyse der Ressourcenverfügbarkeit Ausgewählte, priorisierte Projekte

Abb. 25: Prozess der strategischen Projektauswahl

41

40

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.


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

41

2 Strategisches Projektcontrolling Projektcontroller

unterstützt

Das Projektcontrolling hat die Aufgabe, Hilfestellung beim Einsatz von Bewertungsinstrumenten zu geben und die Konsistenz der zur Beurteilung herangezogenen Daten zu prüfen. 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. Mit dieser Methode können auch die "weichen" Faktoren einbezogen werden. 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. Abb. 26 verdeutlicht eine systematische Vorgehensweise für die Zielfindung.

42


ZIELFINDUNGSPROZESS

er gd un ell ur fst ukt Au lstr Zie An Zie alys lbe e d z ieh er un ge n

g tun ch e i l w Ge r Zie de

A Do usw ku ah me l u nt nd ati on

Suche nach Zielideen

Quantifizierung der Ziele

Abb. 26: 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. 27). Attraktivität hoch 100

Strategische Bedeutung 22

Kundenzufriedenheit 18 hoch

Wettbewerbsvorteile hoch 4

Dringlichkeit hoch 21

Kosten niedrig

18

Risiko gering

14

Wirtschaftlichkeit hoch 25

Entwicklungskosten niedrig 7

Folgekosten niedrig

11

Abb. 27: Gewichtete Zielstruktur Wichtig ist auch die Analyse der Zielbeziehungen. Zielkonflikte stellen ein großes Potenzial für mögliche Probleme und Risiken dar. Deshalb müssen konkurrierende Ziele frühzeitig identifiziert werden.

43


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. 28 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. 28). 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. 28: 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üssen 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. 27 aus. Hat man jedoch eine Vielzahl unterschiedlicher 42

44

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


Ziele, sollte man auf die Präferenzmatrix zurückgreifen (vgl. Abb. 29). Sie erleichtert die Gewichtung durch paarweisen Vergleich aller Ziele. In Abb. 29 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. 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). 17,8

3

4

a

Kundenzufriedenheit hoch

3,6

7

0

b

Wettbewerbsvorteile hoch

21,4

2

5

c

Dringlichkeit hoch

a c a

c

7,2

6

1

d

c

Entwicklungskosten niedrig

5

2

e

Folgekosten niedrig

4

3

f

Risiko gering

g

f g

c g

f g

f 14,3

a

e c

e 10,7

a

d

g g

25,0

1

6

g

Wirtschaftlichkeit hoch

Ziel Häufigkeit Rang Gewicht (Summe =100)

Gewicht =

Summe der Gewichte x Summe der Ränge

umgedrehter Rang

Abb. 29: Zielgewichtung mit der Präferenzmatrix 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 43

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

45


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. 30 ist die Dringlichkeit viermal so wichtig wie das Risiko. Strategische Bedeutung

Dringlichkeit

Risiko

Strategische Bedeutung

1/1

1/2

3/1

Dringlichkeit

2/1

1/1

4/1

Risiko

1/3

1/4

1/1

Abb. 30: Ausgangsmatrix Die Matrix der Abb. 30 wird im zweiten Schritt quadriert. Der Wert 3,00 in Zeile 2, Spalte 2 errechnet sich z. B. wie folgt aus Abb. 30: (1*1)+(1/2*2)+(3*1/3). 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. 31: Quadrierte Matrix 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. 32 die vorläufigen Zielgewichte. Strategische Bedeutung

Dringlichkeit

Risiko

Reihensumme

Gewichte


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. 32: Normalisierte Matrix

46

1,00000000


Das Ergebnis kann optimiert werden, indem man die Ergebnismatrix der Abb. 32 erneut quadriert und die Gewichte errechnet. Dies führt zu folgenden Gewichtungsfaktoren (Spalte zwei der Abb. 33): Gewichte 1. Durchlauf 2. Durchlauf 0,319548872 0,319621018 0,559649123 0,558419705 0,120802005 0,121959277

Differenz -0,000072146 0,001229418 -0,001157272

Abb. 33: 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 Nutzwertanalyse in Abb. 34 verdeutlicht, dass Projekt a als Muss-Projekt keiner detaillierten Bewertung zu unterziehen ist. Es wird auf jeden Fall realisiert. Projekt b erfüllt aufgrund der höheren Punktesumme die Ziele besser als Projekt c. Projekt d weist nur eine geringe Attraktivität auf. 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.

47

2 Strategisches Projektcontrolling Alternativen Ziele

Projekt a

Projekt b

Projekt c

Projekt d

ja

nein

nein

nein

Muss-Projekt Kann-Ziele Kundenzufriedenheit Wettbewerbsvorteile Dringlichkeit Entwicklungskosten Folgekosten Risiko Wirtschaftlichkeit Summe

G 18 4 21 7 11 14 25 100

P

GxP

P 10 7 3 5 7 9 6

GxP 180 28 63 35 77 126 150 659

P

GxP

P

GxP

3 10 4 2 5 4 5

54 40 84 14 55 56 125

1 3 6 2 5 4 4

18 12 126 14 55 56 100

428

381

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

Abb. 34: Nutzwertanalyse Projekte, deren Nutzwert über der zentral vorgegebenen Mindestpunktesumme liegt, können genehmigt werden. In Abhängigkeit der Punktzahlen kann man auch Prioritäten für einzelne Projekte ermitteln. Dies ist vor allem dann interessant, wenn über die Zuteilung knapper Ressourcen entschieden werden muss. 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. 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. operativer Nutzen (Einsparungen in €), 2. Risiko, 3. Fähigkeit andere Abfüller zu integrieren, 4. Abhängigkeit zu anderen Projekten, 5. strategische Bedeutung und 6. interner Ressourcenbedarf. 44

48

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


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. Zusätzlich schätzt die IT-Abteilung die erforderlichen Personalressourcen. 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. 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. 35 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. 35).

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. 35: Priorisierung von Aufgaben In Anlehnung an Abb. 35 werden alle Projekte nach ihrer Dringlichkeit und strategischen Bedeutung in einem Portfolio positioniert (vgl. Abb. 36). 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. 29 erklärt).

Projekt B

33 1 c

Projekt C

0 0 d

Projekt D

Ziel

100 3 b

Anzahl

Projekt A

Prozent

67 2 a

a b b

c b

a


100%

b 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

d

Abb. 36: Priorisierung der Projekte durch paarweisen Vergleich Durch paarweisen Vergleich jedes anstehenden Projekts mit jedem anderen errechnen sich Bedeutung und Dringlichkeit aller Vorhaben. Projekte mit hoher Dringlichkeit und strategischer Bedeutung 50


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. 37). Die Kreisgröße in Abb. 37 gibt den Anteil eines Projekts am Projektbudget wieder. niedrig

7

1 6

2

Risiko

„So what?Projekte“

„Heiße-Projekte“

5

4 „Dead ducks“

3 „VabanqueProjekte“

hoch niedrig

Attraktivität

hoch

Abb. 37: 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, sobald ein hohes Ertragspotenzial gegeben ist, auch wenn es sich lediglich um eine marginale Produktverbesserung handelt.

46

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

51


Risiko Zu unterscheiden sind technische und wirtschaftliche Risiken (vgl. dazu auch Kap. 2.1.3.4). 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. 37 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. 37 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:

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. 38: Risikoportfolio 2.1.3.3 Wirtschaftlichkeitsverfahren Neben strategischen Erwägungen spielt vor allem die Wirtschaftlichkeit eine entscheidende Rolle bei der Projektauswahl. Abb. 39 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 Wirtschaftlichkeitsrechnungen

Gewinnvergleich Rentabilitätsrechnung Amortisationsrechnung

dynamische Verfahren

Kapitalwertmethode Interne Zinsfußmethode

Abb. 39: Wirtschaftlichkeitsverfahren für die Projektauswahl

Wie führt man eine Gewinnvergleichsrechnung durch? Um die Vorteilhaftigkeit eines Projektes zu ermitteln, ist eine reine Kostenbetrachtung im Regelfall unzureichend. Für die Entschei53


dung, 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. 40): 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. 40: 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/ Verkürzung der jeweiligen Projektlaufzeit verbunden ist, hilfreich.49 49

54

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


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. 41: 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. 42): 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. 42: 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. Durch eine Veränderung der Ausgangsdaten kann man versuchen, die Situation zu optimieren. In der nächsten Tabelle (vgl. Abb. 43) 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 55


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. 43: 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. 44). 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. 44: Monetäre Bewertung des "magischen Dreiecks"

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. 45).

56


Erlöse, Kosten ungep

V Meilenstein

er

r ten de ehrkos lante M

lu

st

b

e

i re

ch

a pl ge

klun Entwic

r eE nt

g

geplanter Kostenverlauf

se lö

Zeit Break-Even-Punkt (Gewinnschwelle)

Markteintritt

Marktaustritt

Mengenmäßiger Break-Even-Punkt x=

Definition

Kf p - kv

Wertmäßiger Break-Even-Punkt xp =

Kf 1 – (kv : p )

X = Break-Even-Menge

Kf = fixe Kosten

Xp = Break-Even-Umsatz

kv = variable Kosten/Stück p = Preis

Abb. 45: Break-Even-Analyse Mit der Break-Even-Analyse können die Auswirkungen von Budgetüberschreitungen in der Entwicklungsphase auf den geplanten Gewinn simuliert werden. In Abb. 45 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.

57


Somit liefert die Break-Even-Analyse eine Entscheidungsgrundlage für den Abbruch von Projekten. Sie fördert auch ein langfristiges Denken über das reine Projekt hinaus. Außerdem zwingt sie zur Zusammenarbeit zwischen Vertrieb, Controlling und anderen Bereichen. Diskussionen werden versachlicht, weil die Ergebniswirkung jedes Vorschlags diskutiert werden kann. 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.

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

Rentabilität =

Gewinn * 100 Kapital

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. 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. 46). Auch Abhängigkeiten zwischen den Kennzahlen werden deutlich. Dadurch können verschiedene Szenarien simuliert werden, die zu einem geforderten ROI führen.

58


Erlös Deckungsbeitrag Gewinn Umsatzrentabilität

:

-

Vorräte

x Umsatz Kapitalumschlag

: Kapital

Variable Kosten

Fixe Kosten

Umsatz ROI

-

Anlagevermögen + Umlaufvermögen

+ Forderungen + Aktive RAP + Liquide Mittel

Abb. 46: 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. Amortisationsdauer

=

Kapitaleinsatz Einzahlungsüberschüsse/Jahr

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.

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

59


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. n Kapitalwert = ∑ (Et - At) * 1/(1+i)t – A0 t=1

Definition

At i A0

= = =

Auszahlung im Jahre t, Et = Einzahlung im Jahre t Kapitalisierungszinsfuß, n = Zahl der Nutzungsjahre Anschaffungsauszahlung im Jahre 0

Zur Errechnung des Kapitalwerts geht man wie folgt vor: 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.50

Kapitalrückflüsse

∑

... t1

Kapitalbedarf (Auszahlungen) pro Periode ermitteln und abzinsen.

t2

t3

t4

Kapitalbedarf ∑

... t1

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

tn

t2

t3

t4

tn

Kapitalwert ∑ R

A ∑ B

Abb. 47: Ermittlung des Kapitalwerts Ein Projekt ist lohnend, wenn der Kapitalwert größer Null ist. Von mehreren Alternativen ist diejenige mit dem höchsten Kapitalwert zu wählen.

50

60

Müller, A., von Thienen, L., e-Profit: Controlling-Instrumente für erfolgreiches e-Business, Kiel 2001, S. 170.


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: 1x

pessimistischer Kapitalwert

+ 4x

wahrscheinlicher Kapitalwert

+1x

optimistischer Kapitalwert

6

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. 51 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. 48). 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.

51

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. 48: 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

n ∑ (Et - At) * 1/(1+i)t = 0 t=1 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.

62


Wie wird der Beitrag eines Projektes zum Unternehmenswert gemessen? Der wirtschaftliche Nutzen eines Projektes kann mit dem Gewinnkonzept (Gewinn-, Kostenvergleich, Amortisationsrechnung), mit dem Renditekonzept (Rentabilität, Kapitalwert, interner Zinsfuß) und auch anhand des Überrenditekonzepts ermittelt werden. Dabei muss die Rendite höher als die Kapitalkosten (Fremdkapitalkosten + Eigenkapitalkosten + Risikokosten) sein. Gängige Verfahren sind Discounted Cash Flow (DCF), Economic Value Added (EVA) und Cash Flow Return on Investment (CFROI). Abb. 49 zeigt, wie ein Projekt den Economic Value Added beeinflussen kann.

EVA

Operatives Ergebnis

Umsatz

Steuern

Herstellkosten

-

Vertriebskosten

Kosten Vermögen Kapitalkosten

x Kapitalkostensatz

+

Verwaltungskosten

PROJEKTE

Net Operating Profit (NOPAT)

FuEkosten Sonstige Kosten

Abb. 49: Einfluss der Projekte auf den Unternehmenswert 2.1.3.4 Risikocontrolling 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.

Internet

www.risknet.de

Trotzdem wird in manchen Unternehmen risikobehafteten Vorhaben zu wenig Aufmerksamkeit geschenkt. Während das gesamte Management in endlosen Sitzungen über das nächste Jahresbudget diskutiert, wird die Entscheidung über den Bau eines neuen Lagers mit

63


einem Investitionsvolumen von mehreren Millionen € in wenigen Wochen getroffen. Hamel und Prahalad belegen, dass sich das Management in weniger als drei Prozent seiner verfügbaren Zeit mit Risikomanagement beschäftigt.52 Projektcontroller

unterstützt

Das Projektcontrolling sollte die strategische Projektauswahl unter Risikogesichtspunkten unterstützen. Zusätzlich sind die wichtigen Risiken vor Beginn eines jeden Projektes zu analysieren und während der Projekabwicklung laufend zu beobachten. Die elementaren Bausteine eines Risikocontrollings sind in Abb. 50 aufgeführt und werden im Folgenden beschrieben. Risikokultur Risikomanagementorganisation Identifikation von Risiken Bewertung der Risiken Maßnahmen Risikomanagementprozess Risikokultur

Abb. 50: Bausteine des Risikocontrollings

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.

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

64


Wer ist für Risikomanagement zuständig? An der Konzeption, Einführung und Weiterentwicklung eines Risikomanagementsystems sollte das Controlling mitwirken. In größeren Unternehmen kann es auch eine eigene Stabsabteilung für Risikomanagement geben. 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.

Wie sieht der Risikomanagementprozess aus? Der Risikomanagementprozess beinhaltet mindestens folgende Schritte: 1. Risiken identifizieren, 2. Risiken bewerten, 3. Maßnahmen planen.

Wie kann man Projektrisiken 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?

65

2 Strategisches Projektcontrolling 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? • 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. 51 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

Te sts

Detaillierung/ Realisierung

Sc hn itts

du rc h fü h ren

tel

Produktions- vorbereitung

Gr Pro un dd ze ate sse na len ab bb bild rea ilde en lisi n ere n

Qualitätsrisiken

Abb. 51: Detaillierung der Projektstruktur 66

Produktiv- betrieb

Abhängigkeit von externen Beratern


Auf der Basis der in Checklisten dokumentierten Risiken und der wahrzunehmenden Projektaufgaben können Projektleiter, Controller und Fachexperten gesamt- und teilprojektbezogene Risiken erkennen. Zusätzlich müssen die jeweiligen Arbeitspaketverantwortlichen die Detailrisiken möglichst ausführlich verbal beschreiben.

Wie kann man Projektrisiken 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. 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. EUR 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. 52). Aus der Risk Map lassen sich hohe, mittlere und geringe Risiken ablesen.

67

2 Strategisches Projektcontrolling Eintrittswahrscheinlichkeit hoch mittel

hoch

hoch

gering

mittel

100.000 €

gering

gering

mittel

hoch möglich

gering gering

mäßig

Auswirkung

hoch

Abb. 52: Klassifizierung von Projektrisiken in einer Risk Map Für die Risikobewertung von Projekten der Regierung von Australien wird folgendes Verfahren angewandt (vgl. Abb. 53): 53

Auswirkung bei Überschreitung der Kostenziele Geschätzte Gesamtkosten Auswirkung bei Überschreitung der Terminziele Projektdauer Auswirkung bei Überschreitung der Qualitätsziele

5 Projekt muss abgebrochen werden geschätzte Kosten > 10 Mio $ keine Verlängerung möglich Projektlaufzeit > 24 Monate das Geschäft des Kunden muss eingestellt werden

Eintrittswahrscheinlichkeit 5 das Budget ist offensichtlich unzureichend es gibt keinen klaren Terminplan

Art der Festlegung der Kostenziele Art der Festlegung der Terminziele Art der Festlegung der Qualitätsziele

Qualitätsanforderungen sind nicht bekannt

Bewertung 4 3 2

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

Bewertung 4 3 2

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

5

Auswirkungen

Auswirkungen

si gn

4

m itt

3

ge rin ge s

2

1

Budget wurde ... ... ... das aufgrund ähnlicher

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

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

1

le re s

1

ho

ifi

Ri s

Ri si

ka n

te

he

s

s

R is ik

Ri si

o

ko

ik o

ko

2

3

4

5

Eintrittswahrscheinlichkeit

Abb. 53: Praxisbeispiel für die Projektrisikobewertung

53

68

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


•

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. 53 liegt ein mittleres Gesamtrisiko vor. Für geringe und mittlere Risiken werden keine besonderen Maßnahmen getroffen. Das Management erhält die Bewertung zusätzlicher Risikofaktoren als Grafik (vgl. Abb. 54). Damit können weitere Haupteinflussgrößen für Risiken identifiziert werden.

•

• • •

Finanzierung Komplexität der Leistung Interesse der Stakeholder Beziehung zum Kunden Erfahrung des Kunden Verfügbare Projektinformationen Gefährliche Materialien Ort der Abwicklung Neuartigkeit des Produktes

0

1

2

3

4

5

Abb. 54: Beurteilung zusätzlicher Risikofaktoren

Welche Maßnahmen können ergriffen werden? 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 Eintrittswahrscheinlich69


keit sind vorbeugende Maßnahmen vorzubereiten, damit das Risiko vermindert oder sogar vermieden wird (vgl. Abb. 55). Maßnahmen

vorbeugen

akzeptieren

Risikokategorien geringe Risiken

vermindern vermeiden

mittlere Risiken

übertragen

hohe Risiken

korrigieren

Abb. 55: 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. 56 zeigt weitere Möglichkeiten. 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. 56: Möglichkeiten der Risikovorbeugung54 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 Unterneh54 Rinza, P., Projektmanagement, Düsseldorf 1985, S. 67.

70


men aufwändige Korrektivmaßnahmen planten, war die Jahr-2000Umstellung.

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. 57 ist eine systematische Risikoanalyse mit vertretbarem Aufwand zu gewährleisten.

Wie kann man das Risiko mit der Projekt-Scorecard verknüpfen? In Abschnitt 2.3 wird die Projekt-Scorecard als Instrument der Projektauswahl und -steuerung diskutiert. Es ist sinnvoll, das Risikomanagement in die Projekt-Scorecard zu integrieren. Denkbar wäre eine eigene fünfte Perspektive für das Risikomanagement. Einfacher erscheint es jedoch, das Gesamtrisiko als weiteren Erfolgsfaktor in der Prozessperspektive zu berücksichtigen.

71

72

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. 57: Formblätter für eine systematische Risikoanalyse

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. 58). 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 25 Lösung von Lufthansa Systems 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 73


Risikofaktor eine Einteilungshilfe, an der sich der Anwender 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 ≤ 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 74


zwischen 151 und 220 wird das Risiko als mittel und bei einem 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.

75


Einstellung des Kunden, der Ansprechpartner, der Entscheider

5

...

Lösung von LSY

Leistungsumfang

5

Projektteam LSY (intern und extern)

2

5

Abhängigkeiten

...

x

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

...

x

... 5

x

...

Abb. 58: Auszug aus ProRisk

76

10

...

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

...

...


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. 59). 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. 77


Abb. 59: Verkürzte Darstellung einer Risiko-Analyse 78


2.1.4 Analyse der Abhängigkeiten In der betrieblichen Realität beeinflussen sich Projekte in unterschiedlicher Art und Weise:55 • 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. 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:56 Mit paarweisen Vergleichen in einer Einflussmatrix (vgl. Abb. 60) ermittelt man die gegenseitigen direkten Abhängigkeiten. Wirkung von

Wirkung auf

Einflussnehmende Projekte

Projekt a Projekt b Projekt c Projekt d Summe Beeinflussung

Beeinflusste Projekte Summe Projekt a Projekt b Projekt c Projekt d Einfluss 1 1 1 3

1 1

1

1

1

1

0 3 1 2 6

Abb. 60: 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 Vernet-

55 56

Kargl, H., Projektcontrolling, HMD (2001) 217, S. 14-21. May, G., Chrobok, R., Priorisierung des unternehmerischen Projektportfolios, zfo (2001) 2, S. 108-114.

79


zungsgrad sprechen. Das Ergebnis der Einflussmatrix wird für die Präsentation und Analyse in ein Portfolio übertragen (vgl. Abb. 61).

Beeinflusste Projekte

100%

0%

a Passive Projekte Kritische Projekte

c Träge Projekte 0%

d

b

Aktive Projekte (erste Priorität) 100%

Einflussnehmende Projekte

Abb. 61: Portfolio zur Analyse der Abhängigkeiten 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.

80


Die Einflussanalyse liefert zusammen mit der Beurteilung der Attraktivität eindeutige Hinweise für die Priorisierung der Projekte. Vergleicht man das Beispiel in Abb. 61 mit Abb. 36 und Abb. 34, 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. 34). 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 seiner 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.

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. Die Versicherungskammer Bayern bildet z. B. drei Projektklassen. 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. 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 81


zu überarbeiten ist. Manche Projekte können vielleicht nicht zum vorgesehenen Termin gestartet werden, bei anderen wird man den Leistungsumfang kürzen. Mörsdorf beschreibt, wie man das Leistungsniveau der Projekte in Abhängigkeit der verfügbaren Mittel mit Hilfe des Zero Base Budgeting (ZBB) bestimmen kann.57

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

57

82

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


Vorbereitung (ca. 2 Wochen)

Festlegung der Projektziele und Untersuchungsbereiche Festlegung interner Entscheidungseinheiten und deren Ziele Bestimmung von Ergebnisniveaus für jede Abteilung

Analyse und Planung (ca. 14 Wochen)

Ermittlung von Verfahren zur Erreichung der Ziele, Ermittlung der Kosten Definition von Entscheidungspaketen

Festlegung einer Rangordnung

Entscheidung über Mitteleinsatz und Budgetschnitt

Maßnahmenplanung (ca. 10 bis 12 Wochen)

Festlegung konkreter Maßnahmen

Realisierung und Überwachung (dauernd)

Erarbeitung, Überwachung der Budgetvorgaben

Abb. 62: Ablauf des Zero Base Budgeting Die Entscheidungseinheiten in Schritt zwei der Abb. 62 entsprechen einzelnen Projekten. Für jedes vorgeschlagene Projekt sind drei verschiedene Ergebnisniveaus zu beschreiben sowie deren Aufwand festzulegen (vgl. Abb. 63): 83


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 16 GBitLeitung

-200 Std.

+150.000 €

+20.000 €

B3

Maximal

32 Gbit-Standleitung

+/-0 Std.

+300.000 €

+100.000 €

Abb. 63: Ergebnisniveaus für das Projekt "Vernetzung" Abb. 63 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 16 GBit-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.

Projekt A

Projekt C

C3 A3 A2 B1

A1

Abb. 64: Budgetschnitt 84

C2 Budgetschnitt

B3

B2

C3

B2 B1

C2

A1

C1

C1

Genehmigte Entscheidungspakete

Projekt B

Kosten

Kosten

Die Entscheidungspakete aller Projekte werden in eine Rangordnung gebracht. Dabei müssen die Entscheidungspakete mit niedrigen Entscheidungsniveaus zuerst berücksichtigt werden (vgl. Abb. 64).


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 16 GBit-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 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.

85


OUTPUT

Strategische Projektkontrolle Was?

Woher?

Planungsprämissen, Strategische Planung, Liste mit genehmigten Projekten, Einzelprojekt- und aktuelle Projektinformationen. Multiprojektcontrolling. Prämissenkontrolle Durchführungskontrolle

Balanced Scorecard, Checklisten, Portfoliotechnik

Strategische Überwachung

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

INSTRUMENTE

AUFGABEN

INPUT

2.2

Wohin? Strategische Planung, Einzelprojekt- und Multiprojektcontrolling.

Abb. 65: Überblick über die strategische Projektkontrolle Zu unterscheiden Kontrolle58: • • •

sind drei unterschiedliche Arten strategischer Prämissenkontrolle, Durchführungskontrolle und strategische Überwachung.

Die Prämissenkontrolle greift kurz nach der Strategieformulierung zum Zeitpunkt t1 (Abb. 66). Sie untersucht die für eine Strategie zugrunde gelegten Annahmen. Falsche Prämissen können in der 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. 66 ein. Sie begleitet die Projektauswahl 58

86

Steinmann, H., Schreyögg, G., Management. Grundlagen der Unternehmensführung, 5. Aufl., Wiesbaden 2000, S. 221 ff.

2.2 Strategische Projektkontrolle

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-Ist-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. 66: 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 kann mittels des Attraktivitäts-Portfolios in Abb. 67 Schwerpunkte für die Überwachung von Projekten ermitteln.59 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 UTMS59

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.

87


Mobiltelefone 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 Terminüberschreitung

Kostenüberschreitung Kosten- und Terminüberschreitung

Abb. 67: 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ährleisten. 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.

88


Das Portfolio in Abb. 67 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. 67, 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 sind60: • 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. 2.3

Projekt-Scorecard

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

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. 68).

60

Serfling, K., Controlling, 2. Aufl., Stuttgart, Berlin, Köln 1992, S. 342.

89


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. 68: 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 Mitarbeiterqualifikation61. 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. 69 aufgeführt sind.

61

90

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


Balanced Scorecard

Abb. 69: 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. 70). Perspektiven Ziele

Kennzahlen

Zielwerte Ursache-Wirkungs-Beziehungen Rentabilität

Finanzen

Rentabilität Umsatz

ROI Umsatzzunahme

18,0 % 15,0 % Umsatz

Neukunden Kundenzufriedenheit

Neukunden/alle Kunden Kundenzufriedenheitsindex

Prozesse

Termintreue Qualität Entwicklungszyklen

In Time Aufträge/alle Aufträge 98 % Aufträge ohne Reklamation/alle Aufträge 95 % Anzahl Jahre für Neuentwicklungen 3%

Termintreue

Mitarbeiterzufriedenheit Absentismus Fluktuation

Mitarbeiterzufriedenheitsindex Fehlzeiten/Sollarbeitszeit Kündigungen/Anzahl Mitarbeiter

95 %

Absentismus

Mitarbeiter

10 % 90 %

5% 5%

Neukunden

Kundenzufriedenheit

Qualität

Entwicklungszyklen

Fluktuation

Mitarbeiterzufriedenheit

Frühindikatoren

Kunden

Abb. 70: Aufbau der Balanced Scorecard

91


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, der aufgrund monatlicher Mitarbeiterbefragungen berechnet wird. 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.

Wie unterstützt die Projekt-Scorecard die Projektauswahl? Die Unternehmens-Scorecard kann alternativ 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 Projekt-Scorecard (vgl. Abb. 71).

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. 71: Ableitung der Projekt-Scorecard

92


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. 73 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: • 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?

Wie hilft die Projekt-Scorecard bei der Projektsteuerung? Die Projekt-Scorecard sollte auch für die Projektsteuerung eingesetzt werden. Die Erfüllung der Ziele in der Projekt-Scorecard kann man mittels einer Punktbewertung ermitteln. Dafür werden zunächst die Perspektiven und die zugehörigen Ziele gewichtet (vgl. Abb. 72). Gewichtung der Perspektiven Finanzen 25 % Kunden 30 % Prozesse 20 %

Gewichtung der Ziele Mitarbeiterzufriedenheit 70 % Absentismus 30 %

Mitarbeiter 25 %

Abb. 72: Gewichtung der Perspektiven und Ziele 93


Der Zielerreichungswert von 7,75 für die gesamte Balanced Scorecard in Abb. 73 errechnet sich wie folgt: Gewicht

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

Zielwerte

Aktuell

Abweichung

Punkte

Gewichtete Punktzahl

Gesamtwertung

25% 80% 20%

18,0% 100,0%

17,8% 130,0%

-1,1% -30,0%

9 4

7,2 0,8 8

2,00

30% 100%

90,0%

92,0%

2,2%

10

10 10

3,00

4 4,5 8,5

1,70

4,2 0 4,2

1,05

20% 50% 50% 25% 70% 30%

98% 95%

95,0% 5,0%

88% 90%

80,0% 9,0%

-10,2% -5,3%

-15,8% -80,0%

Gesamtwertung der BSC

8 9

6 0

7,75

Abb. 73: 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 mittels eines Punkteschemas. 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 * 0,8 für das Ziel "Rentabilität"). 4. Summierung der gewichteten Punkte je Perspektive. 5. Multiplikation der Punktsumme mit dem Gewicht der Perspektive (z. B. 8 Punkte * 0,25 für die Finanzperspektive). 6. Addition der Punkte aller Perspektiven zur Gesamtpunktsumme der Balanced Scorecard (im Beispiel wurden 7,75 von 10 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. 74).

94


Zielerreichung 1. Quartal 2. Quartal

Ziele

Finanzen 10,0

Finanzen Rentabilität Umsatzsteigerung Gesamt

8,0 6,0

Kunden

1. Quartal 2. Quartal

4,0

Neukunden Kundenzufriedenheit Gesamt

2,0

Prozesse

Mitarbeiter

Termintreue Qualität Gesamt

0,0

Kunden

Mitarbeiter Mitarbeiterzufriedenheit Absentismus Fluktuation Gesamt

Prozesse

Gesamtwertung

grün

gelb

rot

Abb. 74: 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; • 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.62 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

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

95


•

• •

•

Erster Managementworkshop zur Information und Modifikation 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 Maßnahmen sollten konsequent umgesetzt 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. 75 zeigt das mit Excel realisierte Cockpit Chart. Die Führungsgrößen werden auf weiteren Excel-Sheets im Detail dargestellt. Die Verknüpfung erfolgt mit entsprechenden Links.

96


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. 75: Cockpitchart einer Projekt-Scorecard

97


2.4 •

•

•

• •

• •

•

98

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. Zunehmend gewinnen im Rahmen der wertorientierten Unternehmensführung dynamische Verfahren, die auf der Kapitalwertmethode aufbauen, an Bedeutung. Bei der Entscheidung über die Annahme eines zusätzlichen Projekts ist immer die Auswirkung auf laufende Projekte zu berücksichtigen. Risikoanalysen unterstützen die Projektauswahl. Die Risiken müssen auch für die operative Projektplanung und im Rahmen der laufenden Projektüberwachung identifiziert und bewertet werden. 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.

99

3 Operatives Projektcontrolling

3.1

Operative Projektplanung

OUTPUT

Was?

Woher?

Genehmigte Projekte

Strategisches Projektcontrolling

Zielsetzung

Präferenzmatrix

Projektorganisation

Funktionendiagramm

Risikoanalyse

Checklisten, Riskmap

Phasenplanung

Projektphasenbeschreibung

Aufgabenplanung

Projektstrukturplan, Vorgangsliste

Terminplanung

Netzplan, Balkenplan

Aufwandsplanung

Schätzverfahren

Ressourcenplanung

Kapazitätsbelastungsdiagramm, Personalauslastungsplan

Kostenplanung

Kosten-, Liquiditätsrechnung

Was? Geplante Projekte

INSTRUMENTE

AUFGABEN

INPUT

3.1.1 Überblick Die operative Projektplanung umfasst vor allem die Planung einzelner Projekte. Schnittstellen zum strategischen Projektcontrolling und zur Projektkontrolle, die einzelnen Planungsschritte und wesentliche Instrumente sind in der folgenden Abb. aufgeführt.

Wohin? Projektsteuerung und -kontrolle

Abb. 76: Überblick über die operative Projektplanung 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. Dabei ist die Planung kein einmaliger Prozess am Anfang eines Vorhabens, sondern sie muss projektbegleitend durchgeführt werden: • Anfangs ist ein grober Plan für das gesamte Projekt notwendig, • in der Folge werden zusätzlich detaillierte Pläne für die einzelnen Phasen aufgestellt. Da die Planung sukzessive verfeinert wird, durchläuft man den Planungszyklus oder Teile davon mehrmals.

100

3.1 Operative Projektplanung

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. 76 im Überblick beschrieben (ausgeklammert wird nur die Projektrisikoanalyse; sie wurde bereits in Abschnitt 2.1.3.4 behandelt). 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 Multiprojektcontrollings wie auch des Controllings einzelner Projekte. 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 Zielvereinbarungen gestartet wird. Auch die Zuständigkeiten für die Zieldefinition sollten festgelegt und geeignete Instrumente, wie z. B. die Präferenzmatrix (vgl. Abb. 29), empfohlen werden. Die Ziele einzelner Projekte hat der Projektcontroller zu prüfen: • 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?

Projektcontroller

unterstützt

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 101


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. 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 aufwändiger 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. 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? Projektcontroller

unterstützt

102

Das Projektcontrolling kann Kriterien (z. B. Größe, Komplexität, Bedeutung des Projekts) für die Wahl der Projektorganisation erarbeiten. Im Rahmen der Planung 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.63 Sie werden in der folgenden Abb. 77 im Überblick dargestellt.

63

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.

103

Aufwand


Mission

s lus ch

n Ko

on pt i ze

Mission Unterstützung durch das TopManagement

Beziehung zum Kunden

s Ab

Pl an u

ng

Realisierung

Einverständnis des Kunden

Wichtigkeit des Projekts

Mission

Technische Rahmenbedingungen

Führung

Mission

Problemlösungsverhalten

Beziehung zum Kunden

Zeit

Zeitplanung Technische Rahmenbedingungen Beziehung zum Kunden

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

Tipp

Man erkennt in Abb. 77, 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.

104


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

Projektcontroller

unterstützt

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 Entwicklung von Standards ist, dass die definierten Projekttypen auf einer akzeptabel abstrakten Ebene vergleichbar sind. Manchmal wird eingewendet, dass aufgrund der Neuartigkeit der Projekte keine standardisierten Vorgaben möglich sind. Selbst in diesem Fall wird man jedoch immer Gemeinsamkeiten finden, die man zentral dokumentieren kann.

105


Das Projektcontrolling hat des Weiteren darauf zu achten, dass die bereitgestellten Informationen und Empfehlungen auch wirklich verwendet werden. Dies gelingt nur, wenn die verantwortlichen 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. 78 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. 78: DV-System zur Beschreibung der Projektphasen Die MIS AG, ein Unternehmen, das Software und betriebswirtschaftliche Beratung für Planung, Reporting, Konsolidierung und Datenanalyse anbietet, hat den Prozess für die Einführung von Business Intelligence Systemen beschrieben (vgl. Abb. 79 und Abb. 80). Auf Basis der definierten Prozesse wird eine projektneutrale Kalkulation erstellt (vgl. Abb. 81). Für jeden Projektschritt wird festgelegt, wie stark dieser die Ressourcen bindet und welche direkten Kosten erfahrungsgemäß auf ihn entfallen. Diese Planung erfolgt differenziert nach Projekttypen.

106


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

Abb. 80: Auszug aus der Dokumentation eines Prozessschrittes

107

3 Operratives Projekktcontrolling

Abb b. 81: Projekktneutrale Ka alkulation Fürr die projekttindividuelle Kalkulation n gibt der An nwender an, welcheem Projekttyp yp sein Projeekt entsprich ht. Mit Ausw wahl des Proj ojekttypss werden diee projektneu utralen Kalku ulationen ang gezeigt (vgl. Abschhnitt Fehler! Verweisqueelle konnte nicht n gefund den werden.)). Es bessteht nun die Möglichkeitt, die Werte als a Vorschla ag in die Proj ojektkalkkulation zu kopieren un nd individuelll anzupassen n. Die Eingaaben erfo folgen an dieeser Stelle im mmer auf derr tiefsten Ebeene. Die Berrechnunngsalgorithm men für Aggrregationen und u Kennzah hlen sind zenntral hinterlegt und werden auto omatisch nacch der Einga abe neuer W Werte durrchgeführt. 3.1.5 Projekta aufgaben und d Projektstrruktur Im Projektstruk kturplan werden alle Auffgaben, die für f die Erfülllung derr Projektzielle notwendig sind, stru ukturiert auffgezeigt. Err beschhreibt damit die d zu erbrin ngende Leisttung und glieedert sie in üüberschhaubare Einheiten. Diee Gliederung g des Projek ktstrukturplan ns kann fun nktionsorien ntiert odeer objektorientiert sein. Auch eine Mischglieder M rung ist zulässsig. Da ein übergeo ordneter Knoten immer die Summee der ihm unterP geoordneten Auffgaben zeigtt, dient der Projektstrukt turplan auchh zur Kon ntrolle, ob Leistungen L veergessen wurrden.

108


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. Der Leistungsstand in einem angearbeiteten Arbeitspaket ist nur schwer zu bestimmen. Deswegen gewinnt man mit fein gegliederten Arbeitspaketen von kurzer Dauer 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. Sorgfältig festgelegte Meilensteine nutzen den so genannten "Deadline-Effekt". Er besagt, dass die für eine Aufgabe investierte Energie immer kurz vor dem Terminende stark zunimmt. Fein terminierte Meilensteine sind also vorgeplante "Deadlines", die eine zu starke Abweichung vom Plan verhindern. 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 109


Kriterien erfüllt sind. Die Kriterien, sollten bereits vor Projektbeginn vereinbart werden.

Was sollte bei einer dezentralen Planung beachtet werden? Es ist nicht sinnvoll und auch kaum möglich, für ein komplexes Projekt den kompletten Strukturplan mit allen Einzelheiten aufzustellen. Man sollte stattdessen die Feinplanung delegieren.64 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. 82 verdeutlicht die schrittweise Konkretisierung der Planung. 1. Phasenschema mit Meilensteinen M1 Konzeption 2. High Level Plan

M2

M3 Planung

M4 Realisierung

M3

M5 Abschluss

M4

2. Low Level Pläne

Abb. 82: Schrittweise Konkretisierung der Projektplanung Die Low-Level-Pläne bilden die Grundlage für die detaillierte Planung der Termine, Aufwände, Ressourcen und Kosten.

64

110

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


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.

Welche Aufgaben nimmt das Projektcontrolling wahr? Da die Aufgabenstruktur vieler Projekte vergleichbar ist, sollte das Projektcontrolling einen Standardprojektstrukturplan erarbeiten. Die Anpassung an ein neues Projekt ist schnell durchführbar, indem einfach die nicht benötigten Arbeitspakete entfernt und neue dazugefügt werden. So erhält man schnell einen aktuellen Plan mit Ausgangsdaten für die Termin- und Kostenplanung.

Projektcontroller

unterstützt

Die folgende Abb. 83 zeigt im Überblick die Gliederung der Ebenen des Standardstrukturplans für das Projektgeschäft der FAG Kugelfischer AG & Co. KG.

0000

1. Ebene - Projekt

2. Ebene - Teilprojekt

3. Ebene - Maßnahme

1000

2000

2100

3000

4000

2200

2110

4. Ebene - Einzelschritt 2120

5. Ebene - Netzplan

Schritt 1

Schritt 2

Schritt 3

Abb. 83: Gliederung eines Standardstrukturplans65

65

Menke, U., Projektcontrolling bei der FAG AG. Vortrag vom 5. Juni 2002 an der Fachhochschule Würzburg-Schweinfurt.

111


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. 84. Anlagenstruktur

Projektstrukturplan (PSP)

Gesamtanlage Gesamtanlage Teilanlage Teilanlage Ausrüstung Stückliste

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

Motor Schrauben

Kostenelement Kostenelement

Dichtungen

Abb. 84: Zuordnung von technischer Struktur und Projektstrukturplan Im Produktbereich Instrumentation Systems des Geschäftsbereichs Car Multimedia der Robert Bosch GmbH existieren zwei Zielprozesse, wobei einer die Angebotsphase und der andere die Entwicklungsphase (siehe Abb. 85) eines zu entwickelnden Kombiinstrumentes wiedergibt. In einem Zielprozess, der in einem Sachfortschrittsplan abgebildet wird, sind alle Arbeitspakete, die zur Erstellung eines Kombiinstrumentes erforderlich sind, nach Subphasen aufgeführt. Die Mitwirkung des Fachbereiches ist ebenfalls phasenzugehörig dokumentiert.

112

QB0

M0.1 Entscheid Anbgebotsbearbeitung

M0.1

Angebotserstellung

Ecktermin intern/extern

Qualitätsbewertung mit Entscheidung

M0.3 Auftrag Im Haus

M0.3

M1

M1 ProjektStart (Entwicklungskick-off Meeting)

Projekt Vorbereitungsphase

Entwicklungs-Zielprozess

Steuerung und Bewertung über Checkliste

AngebotsPräsentation und Verhandlung

Angebotspräsentation

M0.2

M0.2 Entscheid Angebotsabgabe

Meilenstein mit Entscheidung

Angebotsbekanntmachung

Legende: M1

M0 Anfrage Sichtung (BUM)

M0

Angebotsprozess

....


Abb. 85: Aufbau des Zielprozesses Angebot mit Übergang zum Entwicklungszielprozess

113


Tipp

Das Projektcontrolling formuliert des Weiteren Regeln für den Umfang des Projektstrukturplans sowie die Definition der Arbeitspakete 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. 86).66 Damit ist es möglich, den Einfluss der einzelnen Arbeitspakete auf den Erlös eines Projektes abzuschätzen. 66

114

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


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öglich 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. 86: 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. 86 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 wird? 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 115


der Fälle ist sogar mit einem völligen Erlösausfall zu kalkulieren. Daraus resultiert das in Abb. 87 dargestellte Ergebnis.

Ke

in e

Ä

g run nde

E der

rlös

Reduzierte Erlöse K ei

ne

e

A

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

B

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

C

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

Erlö se

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

Abb. 87: 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 geschätzt. Durch die genaue Zuordnung von Ressourcen ergibt sich dann rechnerisch die Dauer der Arbeitspakete aufgrund des Zusammenhangs Aufwand = Dauer * Anzahl Ressourcen 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 der Aufwand relativ genau quantifiziert werden kann. Außerdem muss es möglich sein, die Ressourcen eindeutig und zuverlässig den einzelnen Arbeitspaketen zuzuordnen. Gerade in einer Matrixprojektorganisation werden jedoch die Mitar116


beiter oft kurzfristig für Linienaufgaben abgezogen. Projekte mit einer hohen Planungsunsicherheit bezüglich der einsetzbaren Ressourcen sollten deshalb vorzugsweise termingesteuert geplant werden. Ausgehend von der Schätzung des Projektaufwands plant man die Termine der Arbeitspakete so ein, dass ein gewünschter Projektendtermin erreicht wird. Die notwendigen Ressourcen ergeben sich. Es genügt oft eine grobe prozentuale Zuordnung einer Ressource zum Projekt. Bei dieser Vorgehensweise kann man Ressourcen bei Umplanungen auch flexibel verschieben. Die folgenden Ausführungen orientieren sich an der Planungsreihenfolge dieser Alternative.

Welche Methoden der Aufwandsschätzung gibt es? In der Praxis greift man häufig auf Expertenschätzungen zurück. Dabei dominiert die Einzelschätzung. Sie sollte von einem anerkannten Spezialisten durchgeführt werden, der mit Hilfe einer DreiPunkt-Schätzung den Aufwand bestimmen kann. Bei dieser Methode werden drei Schätzwerte für den Aufwand abgegeben: • • •

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

Der Gesamtaufwand A ergibt sich nach folgender Formel: A = 1/6 (Ao + 4 Aw + A p)

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. 88 dargestellt.

117

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 der Schätzungen

Abb. 88: Ablauf der Delphi-Methode Im Folgenden werden weitere Verfahren zur Schätzung des Projektaufwands im Überblick skizziert: Analogiemethoden: • Vergleich mit abgeschlossenen Projekten • Erfahrung des Schätzers ist wichtig • Voraussetzung ist ein systematisches Sammeln und Speichern von Erfahrungsdaten abgeschlossener Projekte Internet

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

118

Multiplikatormethoden: • 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: • Verwendung der durchschnittlichen Aufwandsverteilung vergangener Projekte auf die einzelnen Phasen. • 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.67 Programmgröße sehr klein mittel groß sehr klein groß Aufwandsverteilung 2 kloc 8 kloc 32 kloc 128 kloc 512 kloc Anforderungsanalyse 6 6 6 6 6 Einfache Systementwurf 15 15 15 15 15 SoftwareProgrammentwurf 25 23 23 22 22 entwicklung Codierung 39 38 35 34 34 Systemintegration 15 18 21 23 23 Anforderungsanalyse 7 7 7 7 7 Mittelschwere Systementwurf 16 16 16 16 16 Software23 22 21 Programmentwurf 25 24 entwicklung Codierung 34 32 31 29 27 Systemintegration 18 21 23 26 29 Anforderungsanalyse 7 7 7 7 7 Komplexe Systementwurf 17 17 17 17 17 SoftwareProgrammentwurf 26 25 24 23 22 entwicklung 30 28 26 24 22 Codierung Systemintegration 20 23 26 29 32 Alle Werte in Prozent

Abb. 89: Aufwandsverteilung in Softwareprojekten Aus Abb. 89 kann man für ein sehr kleines, einfaches Projekt mit bis zu 2.000 Lines of Code (= 2 kloc) entnehmen, dass sechs Prozent des Gesamtaufwands auf die Anforderungsanalyse entfallen. Schätzt man den Aufwand für 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. 67

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

119


89, 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. 90 fällt auf, dass sich die Aufteilung der Zeitdauer von derjenigen des Aufwands unterscheidet. Dies kann 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

A = 15 %

A = 28 %

A = 27 %

A = 15 %

A = 15 %

Z = 20 %

Z = 25 %

Z = 20 %

Z = 10 %

Z = 25 %

Analyse

Entwurf

Realisierung

Systemintegration

Zeit

Systemtest

A = Aufwand, Z = Zeitdauer

Abb. 90: Relative Anteile von Aufwand und Zeitdauer68 Internet

www.ifpug.org

Function-Point-Methode:69 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 Entwick68 69

120

Burghardt, M., Einführung in Projektmanagement, Berlin 1995, S. 93 f. 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.


Function-Points

lung 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. 91). Für ein anstehendes Projekt werden nun die Function-Points errechnet. Über die zuvor ermittelte Kurve kann der Aufwand in Personenmonaten abgelesen werden.

Abb. 91: Function-Point-Kurve

Personenmonate

Ist einem Unternehmen der Aufwand für die Ermittlung der Function-Point-Kurve zu hoch, kann sie auch von Software- und Beratungsunternehmen bezogen werden. Allerdings ist in diesem Fall die Aussagekraft stark eingeschränkt. 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.

121



unterstützt

Das Projektcontrolling erarbeitet Empfehlungen zur Bestimmung des Projektaufwands. Folgende grundsätzliche Hinweise sollten beachtet werden: • •

Tipp

• • •

• •

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. 98).

Der Projektcontroller unterstützt die laufende Projektabwicklung, 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 mit den oben behandelten Schätzmethoden ermittelte Nettoaufwand ergänzt werden muss, um den tatsächlichen Aufwand zu erhalten:

122

3.1 Operative Projektplanung 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

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 einen halben bis ganzen 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.

123


4. Sind diese Rahmenbedingungen unklar (z. B. das Team ist noch nicht benannt), hat dies erhebliche 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. 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.

124


3.1.7 Terminplanung Für die Terminplanung sind die logischen Abhängigkeiten zwischen den Arbeitspaketen in einer Vorgangsliste festzulegen. 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. 92 zeigt die Dauer und zeitliche Zuordnung aller Arbeitspakete und Teilprojekte. Dazu sind auch Meilensteine eingeplant, wie z. B. in Zeile 5 "Genehmigung Projektplan". Die Verbindungslinien des Balkenplans verdeutlichen die Abhängigkeiten aus der Vorgangsliste. Vorgangsliste Nr. im PSP 1 2 3 4 5 6 7 8 9

Nr. 1

Vorgang

Vorgänger

Projektteam bilden Ziele festlegen Projektablauf planen Erhebung, Analyse Würdigung Soll-Konzept Systembau Schulung Einführung

1 2 3 4 5 6 6 7,8

Vorgangsname 1 Planung

2

1.1 Projektteam bilden

3

1.2 Ziele festlegen

4

1.3 Projektablauf planen

5 6

1 1 2 4 2 6 8 2 1

Projektleiter Projektleiter Projektleiter Projektteam Projektteam Projektteam DV-Abteilung Personalabteilung DV-Abteilung

rz April Mai Juni Juli August September 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

1.4 Genehmigung Projektplan

17.04.

2 Analyse

7

2.1 Erhebung und Analyse

8

2.2 Würdigung

9

Dauer Verantwortliche Stelle (Wochen)

2.3 Zwischenpräsentation

10

3 Soll-Konzept

11

4 Abschlußpräsentation

12

5 Realisierung

13

5.1 Systembau

14

5.2 Schulung

15

5.3 Einführung

29.05.

10.07.

Abb. 92: Terminplanung 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 125


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

Wie erstellt man einen Netzplan? Es existieren unterschiedliche Techniken der Netzplanerstellung. Die heutigen DV-gestützten Projektmanagementsysteme arbeiten jedoch überwiegend mit dem Vorgangsknotennetzplan (vgl. Abb. 93 und Abb. 94). 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. 93: Netzplanverfahren70 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 wesentliches Ziel der Netzplantechnik ist es, solche Vorgänge zu identifizieren. Um den kritischen Weg eines Netzplans zu bestimmen, müssen folgende Daten errechnet werden:

70

126

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

Dauer Nr.

Arbeitspaket

Legende:


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

127


Frühester Anfang (FAZ in Abb. 95 und Abb. 96): Frühester Termin, an dem ein Vorgang beginnen kann. Frühestes Ende (FEZ in Abb. 95 und Abb. 96): Frühester Termin, an dem ein Vorgang enden kann. Spätester Anfang (SAZ in Abb. 95 und Abb. 96): Spätester Termin, an dem ein Vorgang beginnen kann, ohne das Projektende zu verzögern. Spätestes Ende (SEZ in Abb. 95 und Abb. 96): Spätester Termin, an dem ein Vorgang enden kann, ohne das Projekt zu verzögern. Pufferzeit (vgl. zur Ermittlung Abb. 95 und Abb. 96): Zeit, um die sich ein Vorgang gegenüber seinem frühesten Termin verspäten darf, ohne den Abschlusstermin des Projekts zu beeinflussen. Abb. 95 und Abb. 96 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.

128


Vorwärtsrechnung

35

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

38

46 8 Legende: FAZ Puffer FEZ

30

SAZ Dauer SEZ

Abb. 95: Berechnung der frühesten Vorgangszeitpunkte

Rückwärtsrechnung

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

Legende: FAZ

Puffer FEZ

SAZ

Da uer SEZ

38

9

46

47

8

55

60

55

58

Abb. 96: 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. 97 zeigt, können die Knoteninhalte mit unterschiedlichen

129


Informationen belegt werden (Dauer, Beginn- und Endzeitpunkte, Kosten, zuständige Mitarbeiter u. a.). Beispielsweise beinhaltet der zweite Knoten in Abb. 97 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. 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. 97: Beschriftungsalternativen für Netzplanknoten


unterstützt

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. Ein besonderes Augenmerk sollte der Projektcontroller auf die eingeplanten Puffer richten.

130


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". Besser als der versteckte Einbau vieler kleiner Puffer ist es, einen realistischen Gesamtplan um eine Managementreserve zu erweitern (vgl. Abb. 98).71 Planung mit versteckten Puffern B

C E

A D

Planung mit Managementreserve B

C

A

E D Möglicher Zusatzerlös 5 Mio.

Abb. 98: 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.

71

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

131


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: • 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 10 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 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.72 Gegenübergestellt werden die reservierten Managementreserven und die kumulierte Inanspruchnahme (vgl. Abb. 99). 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.

72

132

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

3.1 Operative Projektplanung 35 30 25 20 15 10 5 0 Jan

Feb

Mär

Apr

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. 99:

Steuerung des Projektportfolios mit der Managementreserve

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 Mountainbike 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. € (vgl. Abb. 100). Der Vertrieb erkannte, dass ein großer Konkurrent ein ähnliches Mountainbike in kürzerer Zeit anbieten wollte. Die Projektleitung erhielt deswegen die Weisung, die Entwicklung um drei Wochen zu verkürzen, ohne dass Mehrkosten entstehen. Die folgende Abb. zeigt die neuen Planungsparameter. Dauer (27 Wochen)

Kosten (3,5 Mio. €)

Leistung (Erlös: 11,5 Mio. €)

Abb. 100: Projektziele des Beispiels Die Zielsetzung der Geschäftsführung, die Entwicklungsdauer bei gleichbleibenden Kosten und konstanter Leistung zu verkürzen, ist

133


nicht realistisch. Zugrunde liegt wahrscheinlich die Annahme, dass im ursprünglichen Projektplan genügend Puffer vorhanden seien. Bei einer sorgfältigen Vorgehensweise darf man davon jedoch nicht ausgehen. Es gibt in diesem Fall nur die Möglichkeit, die Leistung zu verringern oder/und das Budget zu erhöhen. Erste Möglichkeit: Reduktion der Leistung Eine Verkürzung der Dauer bei gleich bleibendem Budget ist im Regelfall, wenn keine größeren Puffer vorliegen, nur bei gleichzeitiger Verringerung der Leistung machbar. Der Projektleiter prüft also in unserem Fall zuerst, inwiefern er mit einer Reduktion der Leistung die neue Zielsetzung erreichen kann.

Wie erkennt man geeignete Arbeitspakete für eine Reduktion der Leistung? 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. Aus der Menge der kritischen Arbeitspakete wird er bei jenen die Leistung reduzieren, bei denen dadurch der Gesamterlös 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 (vgl. Abb. 86).73 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. 87 bestimmt. Wenn dieser Wert um • die kalkulierten Kosten des Arbeitspakets und • die reduzierten Erlöse, die dadurch entstehen, dass das Arbeitspaket das gesamte Projekt verlängert (Abb. 101 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 €), 73

134



korrigiert wird, so erhält man den Nettonutzwert des Arbeitspakets. 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 zu verkürzen. 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. 101: Erlösveränderung in Abhängigkeit der Projektdauer Wird die Leistung reduziert, um trotz der reduzierten Projektlaufzeit die Kosten nicht zu erhöhen, müssen die Auswirkungen konsequent durchdacht werden. Wenn im Beispiel das Mountainbike mit fehlerhaften Bremsen ausgeliefert wird, weil man die Erprobungsphase gestrichen hat, zieht dies sehr weitreichende Konsequenzen nach sich. In vielen Fällen wird es deswegen sinnvoller sein, anstatt einer

135


Leistungsreduktion eine Kostenerhöhung in Kauf zu nehmen. Der Projektcontroller sollte deswegen auf die Möglichkeit hinweisen, die Dauer durch Inkaufnahme möglichst geringer Mehrkosten zu reduzieren. Diese Entscheidungsalternative wird im Folgenden betrachtet. Zweite Möglichkeit: Erhöhung des Budgets

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. 102). Die Kostenerhöhung wird vereinfacht in Abb. 103 als lineare Gerade dargestellt. Vgl. Abb. 103

Gesamte Kosten

Kmin

Direkte Kosten Indirekte Kosten

Dmin

Dopt

Dmax .

Dauer

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

Wie kann man ein Projekt kostenminimal verkürzen? 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.

136


Mittlere Beschleunigungskosten = = = = =

Definition

Dopt – Dmin

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

Kosten

Kmax Kmin Dmin Dopt

Kmax – Kmin

Kmax

Kmin

Dmin

Dopt

Dauer

Abb. 103: Mittlere Beschleunigungskosten74 Folgende Vorgehensweise für die Verkürzung der Projektdauer bietet sich an: • Bestimmung der Vorgänge auf dem kritischen Pfad • Grobe Ermittlung der Beschleunigungskosten • Bildung einer Hitliste der Vorgänge mit den geringsten Beschleunigungskosten • Verkürzung der Projektdauer bei den Vorgängen mit den geringsten Beschleunigungskosten Grundsätzlich sollte das Management Mehrkosten dann akzeptieren, wenn Projektleiter und Projektcontroller glaubhaft nachweisen kön74

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

137


Tipp

nen, dass damit ein zusätzlicher Gewinn erzielbar ist. Der Grundsatz lautet: "spend money to make money". In Entwicklungsprojekten wie im Beispiel des Mountainbikes ist dieser Fall gegeben. Angenommen eine Verringerung der Projektdauer von 30 auf 29 Wochen erbringt Mehrerlöse von 500.000 €, die dadurch notwendige Verkürzung eines kritischen Arbeitspakets um eine Woche erfordert zusätzliche Kosten von 100.000 €, dann erhöht sich der zusätzliche Gewinn trotz Kostensteigerung um 400.000 €.

Wie erkennt man nach der Methode von Devaux geeignete Arbeitspakete für die Zeiteinsparung? Devaux beschreibt eine interessante, sehr differenzierte Methode, um herauszufinden, in welchem Maße sich eine Verkürzung einzelner Arbeitspakete auf die Projektdauer auswirkt.75 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: • 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. • 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. 75

138



Der folgende Netzplan und die Tabelle zeigen am Beispiel die Ermittlung des Reduktionspotenzials (siehe Abb. 104 und Abb. 105). 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. 104: 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. 105: Bestimmung des Reduktionspotenzials 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 um 15 Zeiteinheiten zu reduzieren, so wird sich 139


auch 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. Außerdem wird sich durch den zusätzlichen Einsatz einer bestimmten Anzahl von Ressourcen die Dauer der Arbeitspakete in unterschiedlichem Maße verändern. Im Folgenden sollen deshalb zwei Fragen geklärt werden: 1. Wie wirkt sich der Einsatz zusätzlicher Ressourcen auf die Dauer eines Arbeitspakets aus? 2. Wie kann die Auswirkung eines zusätzlichen Ressourceneinsatzes quantifiziert werden?

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

K = Gruppengröße * (Gruppengröße - 1) / 2

Abb. 106 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. 106). 76

140

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.


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 0 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. 106: Zahl der Kommunikationsbeziehungen in einer Gruppe Zugrunde gelegt wird die bereits bekannte Beziehung Aufwand = Dauer * Anzahl Mitarbeiter. Durch Umformen erhält man Dauer = Aufwand / Anzahl Mitarbeiter. Die Menge der produktiv einsetzbaren Mitarbeiter wird durch Multiplikation der Anzahl Mitarbeiter mit der produktiven Restarbeitszeit ermittelt, so dass die Formel Dauer = Aufwand / Anzahl Mitarbeiter * Restarbeitszeit in %

Definition

entsteht. Für den Ausgangsfall errechnet sich dann folgendes Ergebnis: Anzahl Mitarbeiter Produktive Restarbeitszeit Dauer (D)

=3 = 38 Stunden / 40 Stunden = 0,95 = [1 / (3 * 0,95)] * Aufwand = 0,351 * Aufwand

Aus der Abb. 106 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. 107 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.

141

3 Operatives Projektcontrolling 5

Dauer

4

3

2

1

0 2

3

4

5

6

7

8

9

10

11

Anzahl Mitarbeiter

Abb. 107: Einfluss der Gruppengröße auf die Projektdauer Vergleicht man das vorliegende Modell mit der Projektrealität, so ist Folgendes einschränkend zu beachten: • 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. 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. 46) eines Projektes.77 Bei zunehmendem Personaleinsatz verkürzt sich die Dauer, und der ROI steigt (vgl. Abb. 108). 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.

77

142

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


Return On Investment (ROI)

7 6 5 4 3

n=25

2 1

n=7

0 0

10

20

30

40

50

Dauer in Monaten

Abb. 108: Wirkung des Ressourceneinsatzes auf die Projektdauer und den ROI Zusammenfassend kann festgestellt werden, dass die Projektdauer nicht in gleichem Maße sinkt, wie zusätzliche Mitarbeiter eingesetzt werden. In bestimmten Fällen steigt sogar der erforderliche Zeitbedarf. Insofern kann die Gültigkeit eines bekannten Ausspruchs bestätigt werden:

Tipp

"Adding manpower to a late project, makes the project later!"

Wie kann man die Wirkung zusätzlicher Ressourcen quantifizieren? Eine exakte Ermittlung der Auswirkungen vermehrten Personaleinsatzes ist kaum möglich. Deswegen hilft man sich mit folgender Schätzmethode: 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.78 Zugrunde gelegt wird dabei ein linearer Kostenverlauf über die Zeitdauer. Überstundenzuschläge oder Prämien für Mehrarbeit werden nicht berücksichtigt. 78


143


Definition

MK = GK - PK GK = (2 x PK) x (VW / PD) MK GK PK VW

= = = =

Mehrkosten Gesamtkosten des Projekts normale Plankosten des Arbeitspakets verkürzte Plandauer bei einer Verdopplung des Personaleinsatzes PD = normale Plandauer

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 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 €. Mehrkosten = = = =

Gesamtkosten – normale Plankosten des Arbeitspakets [(2 x 100.000 €) x (6 / 8)] – 100.000 € 150.000 € – 100.000 € 50.000 €

Diesen Mehrkosten ist der zusätzliche Erlös durch eine Verkürzung der Projektlaufzeit gegenüberzustellen. Für das Beispiel in der Abb. 105 ergeben sich jetzt 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. 109: 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 144


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: [(2 * 90.000 €) * 7 / 12] – 90.000 € = 15.000 €. Angenommen, eine Woche Verkürzung des Projektes würde Mehrerlöse von 500.000 € erbringen (vgl. Abb. 101). Dann errechnet sich nach Abzug der Mehrkosten von 15.000 € ein zusätzlicher Gewinn von 2.485.000 €: 5 * 500.000 € – 15.000 € = 2.485.000 €. 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.

Wie kann man den Einsatz knapper Ressourcen steuern? 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: 145


1. Identifikation der Arbeitspakete, die auf dem kritischen Pfad liegen. 2. 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? 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. 4. Kalkulation der Mehrkosten, die bei einer Verdopplung des Ressourceneinsatzes entstehen. 5. Bestimmung des zusätzlichen Erlöses bei einer Verkürzung der Projektdauer und des Mindererlöses bei einer Verlängerung der Projektdauer. 6. Errechnung des zusätzlichen Gewinns. 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: • • • •

146

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?


Anzahl Ressourcen

Mit einem Ressourcenbelastungsdiagramm (vgl. Abb. 110) kann man für jede benötigte Qualifikation deren Bedarf über der Zeitachse verdeutlichen. Abb. 110 zeigt, dass zum Zeitpunkt drei für die Arbeitspakete drei, vier und zwei jeweils zwei Einheiten einer bestimmten 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.

2

4 6

6

1 0

3

6

5

Zeit Abb. 110: Ressourcenbelastungsdiagramm 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. 111 verdeutlicht, dass zum Zeitpunkt drei die vorhandene Kapazität nicht ausreicht, um den Kapazitätsbedarf zu decken.

147

Anzahl Ressourcen


2

4 6

6

1 0

3

6

5

Zeit Abb. 111: 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. 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.

148


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. 112 verwenden.79 Std./ Woche 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26

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

Std./Jahr gesamt 2000 1950 1900 1850 1800 1750 1700 1650 1600 1550 1500 1450 1400 1350 1300

Std./Jahr produktiv 1664 1622 1581 1539 1498 1456 1414 1373 1331 1290 1248 1206 1165 1123 1082

Std./Monat Brutto 167 163 158 154 150 146 142 138 133 129 125 121 117 113 108

Std./Monat Netto 139 135 132 128 125 121 118 114 111 107 104 101 97 94 90

Abb. 112: Verfügbare Personalstunden pro Monat In diesem Beispiel rechnet man durchschnittlich mit 250 Tagen pro Jahr und 42 Tagen Urlaubs- und Fehlzeiten. Bei einer 35 Stundenwoche stehen 146 Personenstunden brutto [(250 Tage / 12 Monate) * 7 Stunden proTag] und 121 Stunden netto [(208 Tage / 12 Monate) * 7 Stunden proTag] 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.80

79 80

Tipp

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

149


Die Nettoarbeitszeit wird in der bereits auf Seite 116 erwähnten Planungsformel wie folgt berücksichtigt: Definition

Aufwand = Dauer * Anzahl Ressourcen * Stunden/Monat

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. 113). Bei Angabe der verplanten Kapazität lässt sie erkennen, welche Mitarbeiter in welchem Umfang für ein bestimmtes Arbeitspaket eingeplant sind. Im Schnittpunkt von Zeilen und Spalten kann man zusätzlich durch Symbole verdeutlichen, welche Kompetenzen (Planung, Ausführung, Kontrolle) ein Mitarbeiter hat. DV-gestützte Projektmanagementtools unterstützen die Einplanung von Mitarbeitern innerhalb eines einzelnen Projektes und projektübergreifend. MS-Project zeigt z. B. im zeitlichen Ablauf den Aufwand, den die Mitarbeiter in den einzelnen Arbeitspaketen und Projekten leisten sollen (Abb. 114).

150

3.1 Operative Projektplanung Bereich A Abteilung 1 MA 2

MA 3

MA 4

MA 5

MA 6

AP 5

0,4

0,3

0,8

0,5

AP 2 AP 1

Projekt A

AP 3

Projekte

AP 4

Projekt B

AP 6

MA 1

Abteilung 2

AP = Arbeitspaket, MA = Mitarbeiter

Abb. 113: Funktionsmatrix

Abb. 114: Ressourceneinplanung in MS-Project

Wie erfolgt der Ausgleich von Kapazität und Bedarf? Als Ergebnis der Kapazitätsbedarfsplanung erhält man die Kapazitätsbelastung wie in Abb. 111. Stehen die benötigten Kapazitäten zu einem bestimmten Zeitpunkt nicht zur Verfügung, muss der Spitzenbedarf durch einen Kapazitätsausgleich abgebaut werden (vgl. 151


Anzahl Ressourcen

Abb. 115). 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. 115 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.

2

2

2

4

6

6

1 0

3

6

5

Zeit Abb. 115: Kapazitätsausgleich


unterstützt

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

152


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 auch das 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. 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. Die Planung des Stundenaufwands wird bei der Outokumpu Technology GmbH durch die Projektcontroller in Zusammenarbeit mit dem Projektleiter erstellt und auf Basis der geleisteten und noch ausstehenden Leistungen personenbezogen durchgeführt (vgl. Abb. 116). Systemseitig wird eine Fortschreibung der Erwartungswerte auf Ebene der Budgets pro Disziplin ermittelt. Hierbei geht die 153


Plan-Ist-Abweichung aus dem aktuellen Monat in die Gesamterwartung als neue Gesamtabweichung ein. Eine manuelle Anpassung im Rahmen einer Planrevision ist dennoch in Abhängigkeit der Erwartung jederzeit möglich. Stundenverbrauch Stundenverbrauch

Stundenplanung Stundenplanung

Tagebuchblatt Tagebuchblatt

ausstehendeLeistung Leistung ausstehende

Stundenerwartung Stundenerwartung

Verbrauch++Planung Planung Verbrauch

Stundenbudget Stundenbudget

Leistungsplanung anpassen

Ja

Stunden

Erwartung > Budget

Gesamtplan Gesamtplan

Nein

Budget anpassen

Kostenträger Kostenträger

Verbrauch

PSP-Element PSP-Element

Planung Budget-Stunden Manuelle Dateneingabe

Budget

System Datentransfer

Abb. 116: Systematik der Stundenplanung in Kundenaufträgen Auf Basis der in den Projekten geplanten Leistungen werden die benötigten Disziplinen mit der Leistungsanforderung beaufschlagt. Hieraus ergibt sich eine Auslastungsplanung der einzelnen Abteilungen, die von den Verantwortlichen durch den Einsatz von Eigenund Fremdpersonal abgeleistet werden muss. Aus der Summe der Kundenaufträge und internen Projekte resultieren die entsprechenden Auslastungen der Fachabteilungen, der Geschäftsbereiche sowie der Gesellschaft insgesamt (vgl. Abb. 117). Planung durch Projektleiter


Planung Kostenstellenleiter

Kundeprojekte Kundeprojekte

PersonalPersonaleinsatzplanung einsatzplanung

verfügbare verfügbare Ressourcen Ressourcen

zusätzlicheRessourcen Ressourcen zusätzliche (Ausleihe) (Ausleihe)

Kapazitätsanpassung Kapazitätsanpassung


Angebote/F&E/GK-Proj. Angebote/F&E/GK-Proj.

Ja

Bedarf > Kapazität Nein

(Ausleihe,Anwesenheit) Anwesenheit) (Ausleihe,

Abb. 117: Systematik der Auslastungsplanung

154


3.1.9 Kosten- und Erlösplanung Die rechnungswesenrelevanten Daten aller geplanten Projekte müssen in die Budgetierung integriert werden. Der grundsätzliche Abrechnungsfluss ist in Abb. 118 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. 118 allgemein als Kostenträgerplanung bezeichnet). Erfolgsplan/Plan-G+V

Planbilanz

Kostenträgerplanung

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

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

Kosten- und Leistungsrechnung Finanzplan

Aktiva

Passiva

Anlagevermögen Umlaufvermögen

Eigenkapital Fremdkapital

Herstellkosten

Einzahlungen - Auszahlungen

Zuschlags- /Verrechnungssätze

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

Ergebnisplan

Kostenstellenplanung Kostenarten

var.

fix

= Finanzbedarf/ -überschuss

Projektplanung Abb. 118: Abrechnungsfluss der Budgetierung

Welche Aufgaben nimmt das Projektcontrolling wahr? 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.

Projektcontroller

unterstützt

155


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. 119 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. 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.)

+ Sonstiger Koste

Integration in die Budgetierung des Unternehmens

= Direkte Projektkosten + Gemeinkosten = Projektgesamtkosten

Abb. 119: 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 156


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. Für jede Kategorie wird vom Controlling ein einheitlicher Stundensatz errechnet. Es ist darauf zu achten, dass die Anzahl der verschiedenen Kategorien möglichst klein gehalten wird (max. zehn). Kategorie 1 2 3 4 5

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

Abb. 120: Einteilung der Mitarbeiter in Kategorien 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. Abb. 121 zeigt die kostenstellenbezogene Errechnung eines Stundensatzes. Tage pro Jahr – Samstage und Sonntage – Feiertage – Urlaub – Durchschnittliche Krankheitstage Normalarbeitszeit – Verteilzeit (7%) = Anwesenheitszeit (bei 35 Std.woche) + Überstunden – Weiterbildung Produktivzeit x Anzahl Mitarbeiter Produktivzeit gesamt Gesamtkosten der Kostenstelle (anteilig) – direkt verrechenbare Kosten Abzudeckende Kosten Stundenverrechnungssatz

365 104 10 30 15 206 14 1344 20 80 1284 60 77040 15 5 10 130

Tage Tage Tage Tage Tage Tage Tage Std. Std. Std. Std. MA Std. Mio. Mio. Mio. €

Abb. 121: Errechnung eines Standardstundensatzes

157


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

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

158

Fiedler, R., Einführung in das Controlling. 2. Aufl., München, Wien 2001, S. 202 ff.

3.1 Operative Projektplanung Einheit

Menge

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

Preis/ Einheit 10 € 80 €

Kosten

5%

1.500 € 4.000 € 3.000 € 425 €

120 € 75 € 130 €

1.200 € 1.500 € 520 €

110 € 120 € 500 €

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

Abb. 122: Projektkostenkalkulation Die MIS AG verwendet für die Kalkulation ihrer Beratungsprojekte ein standardisiertes System, das für vorgegebene Projekttypen bereits den typischerweise anfallenden Personalaufwand enthält. Auf Basis der definierten Prozesse wird eine projektneutrale Kalkulation erstellt (vgl. Abb. 123). Für jeden Projektschritt wird festgelegt, wie stark dieser die Ressourcen bindet und welche direkten Kosten erfahrungsgemäß auf ihn entfallen. Es besteht die Möglichkeit, die Werte als Vorschlag in die Projektkalkulation zu kopieren und individuell anzupassen.

159


Abb. 123: Ausschnitt einer Projektkalkulation auf Basis einer Standardvorlage

160


Auf Basis der Projekteckdaten sowie der (alternativen) Kalkulationen können verschiedene Auswertungen und Berichte angezeigt werden (vgl. Abb. 124).

Abb. 124: Beispiel einer Angebotsübersicht

161


Alternativ zu einer progressiven Ermittlung der Projektkosten wie in Abb. 122 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. 125: Retrograde Projektkalkulation Das Beispiel in Abb. 125 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 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. 126). 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.

162

3.1 Operative Projektplanung 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. 126: Vereinfachte Kalkulationsstruktur Die Projektergebnisse fließen in die Deckungsbeitragsrechnung ein (vgl. Abb. 127). Eine verursachungsgerechte Zurechnung der Kosten zu Aufträgen erfolgt nur für die variablen Kosten. Die Fixkosten werden gemäß einer stufenweisen Deckungsbeitragsrechnung den einzelnen Kostenträgern wie Auftrag, Business Line und Gesellschaft zugewiesen (vgl. Abb. 127).

163

Projektkostenrechnung


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. 127: 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. 128). 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.

164


15000+130000

Gesamtprojekt

10000+40000

Teilaufgaben

Arbeitspakete

15000

5000+75000

25000

35000

40000

Materialkosten Personalkosten Kosten für externe Leistungen Sonstige Kosten

Abb. 128: 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

165


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. 129). 82 AKTUELLES GESAMTBUDGET Budget-Übertragung Kostenübertragung zwischen Arbeitspaketen (Leistungsverschiebung), z.B. Übergang von Eigenleistung auf Fremdleistung

Budget für Änderungen des Auftragswerts 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. 129: Zusammensetzung des aktuellen Budgets 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. 130 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. 82

166

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. 130: 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 167


schätzen. 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. In die Betrachtung der Zahlungsmittelabflüsse sollten Risiken, wie sie z. B. Konventionalstrafen darstellen, einbezogen werden. Abb. 131 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

8000 7000 6000 5000 4000

1

2

-800

Einzahlungen kumuliert

9000

EUR

1200

-1200

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. 131: 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. 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. 132).

168


Auszahlungen, Einzahlungen

Zeit Liquiditätsausgleich

Markteintritt

Marktaustritt

Liquiditätsbedarf (Finanzierungszeitraum)

Abb. 132: 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. 133). 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. Zahlungsströme

Soll

Zahlungseingänge Zahlungsausgänge

Ist

Soll-Ist- und Soll-ErwartetVergleich

Anpassung der Cash-Flow Planung

Tabellarische Darstellung Liquiditätsanalyse

Zinsermittlung Grafische Darstellung

Abb. 133: Ablauf der Cash Flow-Planung

169


Innerhalb der Planung werden jeweils die Kosten entsprechend der Kalkulationsstruktur aufgeführt. 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. 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. 134) 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.

170


Abb. 134: Grafische Darstellung der Cash Flow-Analyse

171


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-GAAP83 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: • • • •

Es ist möglich, das Projekt in sinnvolle Teilabschnitte zu gliedern. 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. 83

172

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. 133). Wiederum wird eine Kostenplanung für Gewerke, Eigenleistungen und Paketvergaben vorgenommen und dementsprechend der Ist-Kostenanfall ermittelt. Im Gegensatz zur Cash Flow-Analyse erfolgt die Bewertung der Eigenleistung lediglich in Höhe eines Planaktivierungssatzes und nicht in Höhe des Vollkostensatzes. Wiederum analog der Cash Flow-Analyse werden auf Basis der statistischen Kostenverteilungen die monatlichen Kosten geplant. Die geplanten und die bereits realisierten Kosten werden nun kumuliert und den Gesamtkosten 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 zu einem in sich konsistenten Gesamtsystem einer integrierten Unternehmensplanung und -analyse zusammengestellt werden. Sie sind deswegen in das interne Unternehmensergebnis, die Gewinn- und Verlustrechnung und die Liquiditätsrechnung zu überführen. 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.3). Die Abb. 135 verdeutlicht, dass der Erfolg und die Liquidität für jedes einzelne Projekt über alle Perioden der gesamten Projektlaufzeit erkennbar sein müssen.

173


Auf der nächsten Stufe ist die Zuordnung der periodenübergreifenden Projektinformationen auf das Geschäftsjahr des Unternehmens erforderlich. Für ein Projekt, das z. B. 18 Monate dauert, sind die Kosten, Auszahlungen und Erlöse anteilsmäßig auf die Geschäftsjahre zu verteilen. Durch die stufenweise Verdichtung über die Projekthierarchie gelangt man zum Projektgesamtergebnis des Geschäftsjahres. Es wird ergänzt um die Kosten und Ergebnisse der anderen Unternehmensleistungen, der Kostenstellen und der Produkte. Damit ist eine Betrachtung des gesamten 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

Externe Erfolgsrechnung

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

P13

P22

Projekttätigkeit

P13

P14

P14

P24

P34

Nichtprojekttätigkeit

Abb. 135: 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 GuV des Unternehmens aktualisiert. Die Definition 174


der Verdichtungspfade trägt man bei der Konfiguration der Anwendung ein. Ebenso wie die Ergebnisdaten werden auch die Finanzinformationen, die auf detaillierter Projekt- oder Kostenstellenebene erfasst wurden, in die Bewegungsbilanz eingestellt. Die noch fehlenden Daten zu Bilanzbewegungen sind auf Ebene der Rechtseinheiten zu ergänzen. Auf Basis der GuV, der Bewegungs- sowie Anfangsbilanz (= Endbestand der Vorperiode) werden die Endbestände sowie auch die Cash Flow-Rechnungen automatisch ermittelt. GuV, Bilanz und Cash Flow-Rechnungen bilden die Grundlage für die Ermittlung weitergehender Ertrags-, Rentabilitäts- und Liquiditätskennzahlen sowie von Indikatoren zur Feststellung des Unternehmenswertes.

175


3.2

Operative Projektkontrolle

Was?

Operative Projektplanung

Leistungskontrolle

Prognosen, Methoden der Leistungsmessung, Kennzahlen

Terminkontrolle

Time-to-Completion, TerminTrenddiagramm, Portfoliotechnik, Kennzahlen Cost-to-Completion, Kosten-Trenddiagramme, Earned Value Analyse, Portfoliotechnik, Kennzahlen Befragungen, Know-howDatenbank, Kennzahlen Kennzahlen, Projektmanagementsoftware, Führungsinformationssysteme

Kostenkontrolle

Erfahrungssicherung Berichtswesen

OUTPUT

Woher?

Geplante Projekte

Was? Planabweichungen, Maßnahmen

INSTRUMENTE

AUFGABEN

INPUT

3.2.1 Überblick

Wohin? Strategische und operative Projektplanung,

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

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.

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

3.2 Operative Projektkontrolle

n Ko st e

in e

Te rm

Le i

st u

ng e

n

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. 137: 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. In manchen Projekten bereitet die Datenbeschaffung jedoch erhebliche Probleme. Im Idealfall existiert ein zentrales System, in dem die Projektmitarbeiter die geleisteten Stunden täglich oder mindestens wöchentlich auf Projekte und Arbeitspakete kontieren. Grundsätzlich sollten folgende Punkte beachtet werden: • 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.

Tipp

177

3 Operatives Projektcontrolling •

Frühzeitig muss geklärt werden, wie und welche Daten der Finanzbuchhaltung für das Projektberichtswesen genutzt werden können.

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. 138). 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. 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. 178


Abb. 138: 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. 139 zeigt den einfachen Fall, dass ausgehend vom aktuellen Termin der Projektfortschritt 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 werden in Abschnitt 3.2.4 behandelt.

179


Projekt fortschritt 100 %

Prognose Plan

Ist

Aktueller Termin

Geplantes Ende

Prognostiziertes Ende

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

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.84 Erst dann kann er die wahren Gründe für eine Abweichung erkennen, ohne die die Erarbeitung geeigneter Gegenmaßnahmen nicht möglich ist.

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ätz84 Ohno, T., Das Toyota-Produktionssystem, Frankfurt u. a. 1993, S. 43.

180


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

PR O J E K T P LAN U N G

Berichtswesen, Dokumentation

PROJEKTCONTROLLING

Die folgenden Ausführungen orientieren sich an den Eckpunkten des "magischen Dreiecks" des Projektmanagements (vgl. Abb. 140):

Terminkontrolle

Leistungskontrolle Plan

Ist

Kostenkontrolle Ist Plan

Auswertung der Projekterfahrungen

Abb. 140: Schritte der Projektkontrolle • • •

Leistungen (Aufgabeninhalte, Qualität), Termine, wirtschaftliches Ergebnis, insbesondere Kosten.

Zusätzlich werden die Auswertung der Projekterfahrungen und abschließend das Berichtswesen als wesentliche Grundlage für die Projektsteuerung besprochen. 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 die Arbeitspaketverantwortlichen, die geplante Leistung erfüllen zu

181


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. 141 beschrieben. Terminplan Legende: Leistungsfortschritt 25% Meilenstein:

A B C D E

F aktueller Zeitpunkt

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

10.000 5.000 6.000 6.000

Abb. 141: Beispiel für die Ermittlung des Leistungsfortschritts Ein einfaches Verfahren ist, die bereits erreichten Meilensteine zu zählen und in Bezug zur Gesamtzahl der Meilensteine zu setzen (Meilensteinmethode). Im Beispiel der Abb. 141 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 *100). Auch diese Methode ist sehr einfach. Das Ergebnis ist aber oft nicht korrekt. 182


Eine weitere Methode bewertet die noch nicht begonnenen Arbeitspakete mit einem Leistungsfortschritt von null Prozent, angearbeitete mit 50 Prozent und abgeschlossene mit 100 Prozent (0/50/100Methode). Obergrenze für den erwirtschafteten Wert ist der geplante Aufwand. Im Beispiel resultiert eine Leistung von 45 Prozent, da 4,5 der zehn geplanten Zeiteinheiten 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 (vgl. Abb. 142). 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. 142: Ermittlung des Projektfortschritts Eine pessimistische Alternative 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: Istaufwand * 100 Leistungsmäßiger FG =

Definition

Voraussichtlicher Gesamtaufwand

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 *

183


100). Dieses Verfahren wird auch als Effort-Expended-Methode bezeichnet. Ähnlich ist die Cost-to-Cost-Methode. Die Formel lautet: Definition

Istkosten * 100 Leistungsmäßiger FG = Voraussichtliche Gesamtkosten

Verwendung findet auch folgende Formel: Definition

Restaufwand Leistungsmäßiger FG = (1 –

) * 100 Planaufwand

Als Ergebnis erhält man in diesem Fall einen Fortschritt von 40 Prozent (1 – (6 / 10)) * 100. Bei den meisten der besprochenen Methoden geht man davon aus, dass die Leistung mit dem angefallenen Aufwand korrespondiert. Da diese Übereinstimmung nicht in jedem Projekt gilt, muss die Anwendbarkeit im konkreten Fall geprüft werden. In manchen Projekten ist es möglich, direkt die Restleistung zu schätzen. Dann kann der Leistungsfortschritt über folgende Beziehung ermittelt werden: Definition

100 % - Restleistung in %


unterstützt

184

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.

Tipp

Zu viele Treffen verursachen Desinteresse und Verstimmung.

Wo liegen Ursachen einer falschen Leistungseinschätzung? Ein typischer Projektablauf ist in Abb. 143 dargestellt:85

Mitarbeiter

Produktivität

Qualität

Erbrachte Leistung

Geplante Leistung

Erkanntes Leistungsdefizit

Fehlerfreie Leistung

Verstecktes Leistungsdefizit

Abb. 143: 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. 144 erklärt werden:

85

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

185


Tatsächlicher Leistungsfortschritt Angenommener Leistungsfortschritt

Abb. 144: Tatsächlicher Leistungsfortschritt Der Leistungsfortschritt wird bei realistischer Schätzung durch die 45-Grad-Linie in Abb. 144 repräsentiert. Dabei stimmen tatsächlicher Leistungsfortschritt und geschätzter Leistungsfortschritt überein. Je mehr unentdeckte Qualitätsmängel vorhanden sind, desto 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 186


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 Ergebnis 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: • 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.

Tipp

187


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. 145 zeigt z. B. den derzeit gültigen Plan und den Projektfortschritt (schwarzer Balken). Nr. 1

Vorgangsname 1 Planung

2

1.1 Projektteam bilden

3

1.2 Ziele festlegen

4

1.3 Projektablauf planen

5

1.4 Genehmigung Projektpla

6

Aktueller Zeitpunkt 26. Juni 17.04.

2 Analyse

7

2.1 Erhebung und Analyse

8

2.2 Würdigung

9

rz April Mai Juni Juli August September 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

2.3 Zwischenpräsentation

10

3 Soll-Konzept

11

4 Abschlußpräsentation

12

5 Realisierung

13

5.1 Systembau

14

5.2 Schulung

15

5.3 Einführung

29.05.

10.07.

Abb. 145: Projektfortschrittsbericht in MS-Project Der Vorgang "Soll-Konzept" ist hinter dem Plan zurück. Der schwarze Balken müsste eigentlich bis zum aktuellen Zeitpunkt, dem 26. 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

Istdauer * 100 Zeitlicher FG

= Voraussichtliche Gesamtdauer

188


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 realistischen Endtermin. Der Balkenplan in Abb. 146 verdeutlicht die Kennzahl Time-to-Completion. Time-to-Completion

Arbeitspaket Zeit Projekt- Gegenwart start

Geplanter Endtermin

Voraussichtlicher Endtermin

Abb. 146: 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. 144 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. 147 zeigt auf der Abszisse die Berichtsmonate während des Projektes und auf der Ordinate die aktuellen PlanFertigstellungstermine. Zu jedem Berichtsmonat wird abgefragt, ob 189


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

Entwurf

Geplante Endtermine

8 7

Analyse

6 Planung

5 4 3 2 1 0

1

2 3 4 5 6 Aktuelle Berichtstermine

7

8

9

Abb. 147: Termin-Trenddiagramm Abb. 147 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 Projektleiter hätte die zeitliche Verzögerung der Analyse und des Entwurfs eigentlich schon zum Berichtstermin fünf erkennen müssen. Tatsächlich erfolgte die Aktualisierung jedoch erst im Monat sechs. Das Projektcontrolling muss in diesem Fall die verspätete Anpassung hinterfragen, um zukünftig eine schnellere Reaktion zu gewährleisten. Kurvenverläufe im Termin-Trenddiagramm lassen sich grundsätzlich wie folgt interpretieren:

190

3.2 Operative Projektkontrolle 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. 148: Kurvenverläufe im Termin-Trenddiagramm 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.

Internet

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

Im Produktbereich Instrumentation Systems des Geschäftsbereichs Car Multimedia der Robert Bosch GmbH werden die wichtigsten geplanten Meilensteine (so genannte Ecktermine eines Projektes) aus dem MS-Project Master-Terminplan übernommen. Die Grundlage für den Master-Terminplan stellen die für den Produktbereich entwickelten Zielprozesse für die Angebots- und die Entwicklungsphasen von Kombiinstrumenten dar. 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 System, den TMG Innovations Manager™, unterstützt. Es unterscheidet im Terminplan nach Vorgabe der konzernweiten Standards zwischen Soll-, Plan- und IstTerminen: 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. 191


Wenn sich ein Termin im Lauf des Projektes verschiebt (z. B. wegen Funktionsänderungen, Ressourcenengpässen, etc.), 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 Meilenstein-Trendanalyse generiert (vgl. Abb. 149 und Abb. 150).

Abb. 149: Zusammenspiel von Terminplan und MeilensteinTrendanalyse basierend auf MS-Project 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 Abbildung Abb. 150 zeigt einen konkreten Fall.

192


Abb. 150: 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" und "Produktionsstart". Durch den abgebildeten Trend 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.

193


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. 151).

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. 151: Kosten-Trenddiagramm

Wie ist ein Zeit-/Kosten-Trenddiagramm aufgebaut? In Trenddiagrammen können auch Termin- und Kosteninformationen kombiniert werden. Abb. 152 zeigt die Gegenüberstellung des planmäßigen und tatsächlichen Verhältnisses zwischen Kosten- und Zeitverbrauch. Bei 90 Prozent der geplanten Dauer sollten 80 Prozent der Kosten angefallen sein. In diesem Punkt entsprechen sich die Plan- und Istdaten.

194


140% 120%

Kostenverbrauch

100% 80%

Istkosten

60%

Plankosten

40% 20% 0% 0%

20%

40%

60%

80%

100%

120%

140%

Zeitverbrauch

Abb. 152: Zeit-/Kosten-Trenddiagramm

Welche Aufgaben nimmt das Projektcontrolling wahr? 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.

Projektcontroller

unterstützt

Der Projektcontroller kann den Projektleiter auch vor Fehlinterpretationen der Termin- und Kostensituation bewahren. Bei oberflächlicher Betrachtung der Abb. 152 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.

195


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 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. 153).

Abb. 153: Kostenkontrolle86


unterstützt

Die Kostenkontrolle übernimmt in der Regel der Controller. Unterstützt wird er vom Projektleiter, der dafür verantwortlich ist, dass die geleisteten Arbeitsstunden zeitnah und der Realität entsprechend vorliegen. Das Projektcontrolling sorgt für ein funktionierendes Erfassungssystem der laufenden Kosten, analysiert Kostenabweichungen mit geeigneten Methoden und schlägt Maßnahmen zur Kostensenkung vor.

86

196

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


Im Folgenden soll die Earned Value Analyse als aussagekräftiges Verfahren zur integrierten Kosten- und Leistungskontrolle beschrieben werden. Ausgangsüberlegung ist die Tatsache, dass Kostendiagramme wie in Abb. 152 und Abb. 154 häufig nur Plan- und Istkosten zeigen und damit eine aussagekräftige Interpretation von Kostenabweichungen erschweren. 90000 80000

Istkosten Plankosten

70000

Kum. Kosten

60000 50000 40000 30000 20000 10000 0 Januar

Februar

März

April

Mai

Juni

Juli

August

Abb. 154: Kumulierte Ist- und Plankosten Betrachtet man Abb. 154, 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 an-

197


•

gefallen als geplant) oder durch den Einsatz von Mitarbeitern mit sehr niedrigen Stundensätzen begründen kann, unplanmäßige Minderleistungen.

Man kann in Abb. 154 nicht erkennen, ob die Abweichung im August auf einen geringeren Leistungsfortschritt oder eine besonders wirtschaftliche Leistungserbringung zurückzuführen ist. Wenn die Istkosten wie in Abb. 154 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 * Istleistung). Man spricht auch vom so genannten Earned Value. Internet

www.valuationopinions.com/ www.acq.osd. mil/pm

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 wichtige 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)?

Die folgende Aufstellung zeigt im Überblick die Kennzahlen der Earned Value Analyse. In Klammern stehen die englischen Bezeichnungen.

198


Istkosten kumuliert Begriff 2 Actual Cost Begriff 3 Actual Cost of Work Performed (ACWP) Berechnung Istkosten pro Leistungseinheit * Istleistung Sollkosten Begriff 2 Begriff 3 Berechnung

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

Plankosten kumuliert Begriff 2 Earned Value Begriff 3 Budgeted Cost of Work Scheduled (BCWS) Berechnung Plankosten pro Leistungseinheit * Planleistung kumuliert Plankosten gesamt Begriff 2 Budget at Completion (BAC) Berechnung Plankosten pro Leistungseinheit * 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 * 100 Kostenindex Begriff 2 Berechnung

Cost Performance Index (CPI) Sollkosten / Plankosten * 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)

199

3 Operatives Projektcontrolling 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 Voraussichtliche Gesamtkosten – Istkosten

Ein Beispiel soll im Folgenden die Ermittlung und Analyse der Kennzahlen verdeutlichen (vgl. Abb. 155): Ein Arbeitspaket, dessen gesamte Plankosten sich auf 76.500 € belaufen, soll nach neun Monaten untersucht werden.87 Zu diesem Zeitpunkt liegen folgende Kostendaten vor: Sollkosten 9.255 €, Istkosten 10.605 €, kumulierte Plankosten 12.724 €. Die Plandauer beträgt zwölf Monate. Monat 1 2 3 4 5 6 7 8 9

Istkosten 945 € 840 € 945 € 990 € 1.395 € 1.440 € 1.350 € 1.395 € 1.305 €

Kumulierte Kumulierte Kumulierte Istkosten Plankosten Plankosten Sollkosten Sollkosten 945 € 1.035 € 1.035 € 945 € 945 € 1.125 € 2.160 € 840 € 1.785 € 1.785 € 2.730 € 1.204 € 3.364 € 945 € 2.730 € 3.720 € 1.395 € 4.759 € 990 € 3.720 € 5.115 € 1.485 € 6.244 € 655 € 4.375 € 6.555 € 1.553 € 7.797 € 680 € 5.055 € 7.905 € 1.553 € 9.349 € 1.450 € 6.505 € 9.300 € 1.643 € 10.992 € 1.795 € 8.300 € 12.724 € 955 € 9.255 € 10.605 € 1.733 €

Abb. 155: Beispieldaten für die Earned Value Analyse Die folgende Abb. 156 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ön-

87

200

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


nen entweder geänderte Kostensätze oder ein gegenüber der Planung geänderter Input für die Leistungserstellung sein. 14.000 Kum. Istkosten Kum. Plankosten Kum. Sollkosten

12.000

LA

Kum. Kosten

10.000

8.000

6.000

Ko

ich we nab ste

g un

4.000

2.000 LA = Leistungsabweichung

0 1

2

3

4

5

6

7

8

9

Monat

Abb. 156: Diagramm für die Earned Value Analyse Der Unterschied zwischen Plan- und Sollkosten ist ein Indikator für unplanmäßigen Leistungsfortschritt (in Abb. 156 mit LA für Leistungsabweichung gekennzeichnet). 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.

201


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. Kostenabweichung: Leistungsabweichung:

Istkosten – Sollkosten Sollkosten – Plankosten

Es lassen sich damit weitere Auswertungen in Form von "Projektfieberkurven" erstellen, die für das Beispiel zeigen, dass sowohl die Kosten als auch die Leistungen abweichen (vgl. Abb. 157 und Abb. 158). Kostenabweichung (Istkosten - Sollkosten) 1.600 1.400 1.200

Kosten

1.000 800 600 400 200 0 1

2

3

4

5

6

7

8

9

-200

Monate

Abb. 157: Kostenabweichung als Fieberkurve Leistungsabweichung (Sollkosten - Plankosten)

Monate

200 -300 1

2

3

4

5

6

7

8

-800

Kosten

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

Abb. 158: Leistungsabweichung als Fieberkurve

202

9


Der positive Wert der Kostenabweichung in Abb. 157 zeigt eine Unwirtschaftlichkeit, der negative Wert der Leistungsabweichung in Abb. 158 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: Leistungsindex = Sollkosten / Plankosten * 100 Kostenindex88 = Istkosten / Sollkosten * 100

Für das Beispiel in Abb. 155 ergeben sich folgende Werte: Leistungsindex = = Kostenindex = =

9.255 € / 12.724 € * 100 72,74 % 10.605 € / 9.255 € * 100 114,59 %

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. 159 übersteigt die Leistungsabweichung bereits zum Berichtsmonat Februar die Toleranzschwelle. Zu diesem Zeitpunkt wäre die Analyse einzuleiten.

88

Der Kostenindex wird vielfach auch wie folgt errechnet: Sollkosten / Istkosten * 100. Ein Wert unter 100 zeigt in diesem Fall eine Unwirtschaftlichkeit im Projekt.

203


Kosten- und Leistungsindex 140

Kostenindex 120

Index in %

100 80 60

Leistungsindex

40 20 0 1

2

3

4

5

6

7

8

Monate

Abb. 159: Kosten- und Leistungsindex mit Abweichungskorridor Ein Problem von Toleranzschwellen wie in Abb. 159 ist, dass nicht unterschieden wird, in welchem Monat man sich befindet. Die kumulierten Abweichungen bis Februar dürfen aber größer sein als diejenigen bis November, da eine Differenz zu Beginn des Jahres noch gut kompensiert werden kann. Die sogenannte Trompetenkurve vermeidet diese Schwierigkeit. Sie zeigt anschaulich auf, ab wann unterjährige Abweichungen zum Problem werden und mit welchen Jahresendwerten man dann realistisch rechnen muss (vgl. Abb. 160). 12,0%

7,0%

+ 2,0 %

2,0%

Jan

Feb

Mrz

Apr

Mai

Jun

Jul

Aug

Sep

Okt

Nov

Dez

- 2,0 % ‐3,0%

‐8,0%

Abb. 160: Trompetenkurve 204

9


Die Kurve in Abb. 160 zeigt die Kennzahl Budgetabweichung: (Sollkosten – Istkosten kumuliert) Sollkosten Für das Jahresende wurde eine maximale Abweichung von zwei Prozent vorgegeben. Die zulässige Abweichung von 2,4 Prozent für den Monat August errechnet sich mit der Formel

√(12/aktueller Monat) * Jahresendtoleranz Nach einer zufriedenstellenden Entwicklung der Budgetsituation bis Mai wird im Juni die untere Schwelle durchbrochen. Die negative Entwicklung ist bereits im April zu erkennen. Eine monatlich vorgegebene starre Schwelle, wie sie bei Ampelfarben üblich ist, hätte diesen negativen Trend nicht gezeigt. Die Ampel wäre noch im Mai auf Grün geschaltet worden. 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. 155 zu bestimmen: Voraussichtliche Gesamtdauer = Plandauer gesamt / Leistungsindex 16,5 Monate = 12 Monate / (9.255 € / 12.724 €) Voraussichtliche Gesamtkosten = Plankosten gesamt * Kostenindex89 87.658 € = 76.500 € * (10.605 € / 9.255 €)

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 Projek-

89

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

205


tes erreicht wird, kann folgender Zusammenhang verwendet werden: Voraussichtliche Gesamtkosten = Istkosten + (Plankosten gesamt – Sollkosten) 77.850 € = 10.605 € + (76.500 € - 9.255 €). Sollen die die tatsächliche Wirtschaftlichkeit und die tatsächliche Performance zugrunde gelegt werden, verwendet man folgenden Zusammenhang: Voraussichtliche Gesamtkosten = Istkosten + (Plankosten gesamt – Sollkosten) * Kostenindex / Leistungsindex

•

116.540 € = 10.605 € + (76.500 € - 9.255 €) * 114,59 % / 72,74 %.90

Abb. 161 fasst die drei Möglichkeiten zusammen, mit welchen Annahmen die Restkosten in die Berechnung der voraussichtlichen Gesamtkosten einfließen. Wirtschaftlichkeit bisherige Plankosten gesamt * Kostenindex

Leistung bisherige

x

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

geplante

x x

x

geplante x

x

Abb. 161: 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. 162 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.

90

206

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


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 (vgl. Abb. 162). Projekt

A B C D E F G H i Gesamt

Plankosten kum.

Sollkosten kum.

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

Leistungsabweichung

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

Istkosten kum.

700 € 670 € 400 € 620 € 900 € 550 € 650 € 710 € 840 € 6.040 € -260 € 95,92

Kostenabweichung

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

Plankosten gesamt

Cost-atCompletion

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

Dauer 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 € 98,69

Abb. 162: Multiprojektcontrolling mit der Earned Value Analyse

Wie kann man die Probleme der Datenbeschaffung lösen? Grundsätzlich gibt es drei entscheidende Aufgaben bei einer Earned Value Analyse:91 1. Definition geeigneter Arbeitspakete 2. Erfassung des Fortschrittsgrads der Arbeitspakete 3. Ermittlung der Istkosten 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. 91

Tipp

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

207


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

Sollkosten = gesamte Plankosten – geschätzte Restkosten

Unrealistisch ist es, vom ursprünglichen Projektbudget einfach die angefallenen Kosten abzuziehen und die Differenz dann als Restkosten auszuweisen. 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.

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

208


genaue Kenntnisse des Systems voraus. Zudem sind z. B. in MSProject Kostendaten für jedes Arbeitspaket erforderlich, damit Kosten- und Leistungsabweichungen ausgewiesen werden. Abb. 163 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).

Abb. 163: Earned Value Analyse mit MS Project Für den Donnerstag ist in Abb. 163 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

Warum ist die Analyse abgeschlossener Projekte sinnvoll? 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 209


auch die positiven Faktoren hervorzuheben. Auf keinen Fall darf es zu einem Tribunal kommen. Zu beantworten sind insbesondere folgende Fragen:92 • Welche Erfahrungen wurden an den Schnittstellen zu Lieferanten, Betriebsrat, zum Kunden und zu anderen Abteilungen 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? Zu erheben sind auch die Ursachen der aufgetretenen Probleme. Eine einfache Möglichkeit dafür ist in Abb. 164 dargestellt. 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.

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, fehlende Teile

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

Abb. 164: Ursachen für aufgetretene Probleme93 92

210

Hilpert, N., Rademacher, G., Sauter, B., Projekt-Management und ProjektControlling im Anlagen- und Systemgeschäft, Frankfurt 2001, S. 108 ff.


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.

Projektcontroller

unterstützt

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.

Wie kann man vergleichbare Projekte identifizieren? 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.94 Die Einteilung nach der Komplexität könnte mit der Nutzwertanalyse unterstützt werden (vgl. Abb. 165). 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.

93 94

Burghardt, M., Einführung Projektmanagement, München, Erlangen 1995. Krüger, A., Schmolke, G., Vaupel, R., Projektmanagement als kundenorientierte Führungskonzeption. Stuttgart 1999, S. 220 ff.

211


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. 165: 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. 3.2.6 Berichtswesen und Dokumentation Die Qualität der Informationsbereitstellung ist entscheidend für die Steuerung und Kontrolle der Projekte.

Welche Kriterien sollte das Projektberichtswesen erfüllen? 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 Monatsbeginn bzw. nach Abschluss 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 Projektleitung erfährt wenig über viel, die Arbeitspaketverantwortlichen erfahren viel über wenig". 212


•

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. • 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". • Abweichungen sollten im Bericht immer einem Verantwortungsbereich zugeordnet werden.

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. 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. 166 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. 166: Ausnahmebericht mit Ampelfunktion

213


Sonderberichte werden nur auf Wunsch erstellt. 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. Abb. 167 verdeutlicht den Aufbau eines standardisierten Fortschrittsberichts. Ein Deckblatt zeigt die wesentlichen Daten im kompakten Überblick. Die folgenden Seiten dokumentieren die Situation im Detail.

Welche Funktion haben Fortschrittsberichte? Fortschrittsberichte sind Standardberichte, welche die Projektausschüsse periodisch in kurzer und prägnanter Art über den Projektstand informieren sollen. Basis des Fortschrittsberichts ist der Projektstrukturplan. Aus den einzelnen Berichtspunkten muss man erkennen, ob alles wie geplant abläuft, welche Abweichungen und welche Probleme existieren oder sich entwickeln können. Der Fortschrittsbericht enthält folgende Inhalte (vgl. Abb. 167): • • • • •

durchgeführte Arbeiten, Stand der Arbeiten (Time-toCompletion, Fertigstellungsgrad), Terminsituation, Vergleich zwischen geplantem und verursachtem Aufwand (Cost-to-Completion sowie Soll-, Ist- und Plankosten), aufgetretene Probleme und Risiken, 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. 167 verdeutlicht den Aufbau eines Fortschrittsberichts. 214


Risiko Kosten Termine Leistung/Qualität Maßnahmen Probleme Deckblatt . Probleme . Termine . Maßnahmen . Kosten . Leistung/ . Risiko Qualität

Abb. 167: Inhalte des Fortschrittsberichts Das Deckblatt eines Fortschrittsberichts sollte auf einen Blick die Situation eines Projekts zeigen. Abb. 168 zeigt einen Gestaltungsvorschlag.

Statusbericht Projektbezeichnung: ........................ Anlass: Gesamt

Periodischer Bericht Qualität

Plan V-Ist Abweichung Beurteilung Projektleiter:

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

40 Wochen 39 Wochen -1 Woche

Datum ..........................

Problembericht

Aufwand

65 Wochen 80 Wochen +15 Wochen

Kosten

100.000 EUR 105.000 EUR +5.000 EUR

350 Punkte 360 Punkte +10 Punkte

Beurteilung Projektcontroller:

Weiteres Vorgehen: Maßnahme 1: ..................................................................................... Maßnahme 2: ..................................................................................... Maßnahme 3: ..................................................................................... ..................................................... Datum, Unterschrift Projektleiter

Risiko

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

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

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

Abb. 168: Deckblatt eines Fortschrittsberichts

215


Wie häufig wird der Fortschrittsbericht erstellt? Tipp

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.

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. 169). 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. 169: 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. 216


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. Durch das Aufzeigen und Bewerten bedeutsamer Unterschiede zwischen der Planung und dem Istverlauf bei Kosten, Leistungen und Terminen 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. 170). 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.

217


Abb. 170: Zwei Auszüge aus einer beispielhaften "elektronischen Projektakte" 3.2.6.1 Berichtswesen in einem Produktbereich der Robert Bosch GmbH Abb. 171 zeigt eine Übersicht über diejenigen Berichte, die im Produktbereich Instrumentation Systems des Geschäftsbereichs Car Multimedia der Robert Bosch GmbH erzeugt werden.

218

3.2 Operative Projektkontrolle Berichtsersteller

Berichtsart

Berichtszweck

Berichtsturnus

Geschäftsleitung

Projektcontrolling und Produktbereichscontrolling

Ampelchart, Produktbereichs-Cockpit aller Produktbereiche (wird in diesem Praxisbeitrag nicht weiter erläutert)

Multiprojektsicht über den Produktbereich zur strategischen Einflussnahme

monatlich

Produktbereichsleitung

Projektcontrolling und Produktbereichscontrolling

Ampelchart, Meilensteinübersicht, Änderungsmanagementchart, Darstellung von Forschungs- und Entwicklungskosten

Multiprojektsteuerung, Kenntnissetzung über Gesamtsituation zur operativen Einflussnahme

zweiwöchentlich

Projektsteuerkreis

Projektleiter und Projektcontrolling

Projekt-Cockpit, Regelmeetingbericht, Terminplan

Einzelprojektsteuerung im Produktbereich

monatlich

Projektleitung

Projektleiter und Projektcontrolling

Projekt-Cockpit, Regelmeetingbericht, Terminplan

Einzelprojektsteuerung im Projektmanagement

monatlich

Abb. 171: Berichte, Berichtsgremien und Berichtshäufigkeit Projekt-Cockpit Das Projekt-Cockpit ist das zentrale Steuer- und Reportinginstrument für den Projektleiter (vgl. Abb. 172). Dort ist der gesamte Projektstatus graphisch dargestellt. Dazu werden Bestandteile des Ampelcharts (vgl. unten) verwendet. Für alle Projektstati im ProjektCockpit, die auf Gelb oder Rot stehen, sind vom Projektleiter Sonderaktionen und Maßnahmen zu treffen. Die Erfassung und Verfolgung dieser Sonderaktionen erfolgt im Regelmeetingreport (vgl. Abb. 173). 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.

219

220

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. 172: Darstellung des Projekt-Cockpits


Projektleiter und Projektcontroller prüfen die Daten gemeinsam auf Plausibilität. Wie man Abb. 172 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 von Projektcycletime-Punkten ist in der mittleren Spalte in der Mitte des Projekt-Cockpits 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. Voraussetzung zur Anwendung der Fortschrittsmessung ist das Definieren von Arbeitspaketen. Sie sind im Zielprozess dokumentiert, der wiederum mit dem Terminplan in MS-Projekt synchronisiert wurde. Im Produktbereich wird die Methode mit absolutem Fertigstellungsgrad angewendet, d. h., nur zu 100 Prozent abgeschlossene Arbeitspakete werden dem Projekt gutgeschrieben. 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 PMFRess™ 95 in das MitarbeiterEingabeblatt des Projekt-Cockpits. Im Anschluss erfolgt eine automatische Datenübertragung in die Graphik. 95

PMFRess™ ist das Planungstool zur Ressourcenplanung der Firma Vector.

221


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 vorsehen. 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. 173) 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.

222

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. 173: Regelmeetingbericht

223


In Abb. 174 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. 174: Ampelfarbenbelegung Die Einstufung der Farben erfolgt nach subjektiver Einschätzung der Projektbeteiligten. Für die Ampelfarbenbelegung können z. B. die folgenden, von einem Kunden tatsächlich gewünschten Regeln vorgegeben werden: 224


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. 175: Belegung der Ampelfarben nach vorgegebenen Regeln Wochenbericht Der Wochenbericht ist eine Variante des Regelmeetingberichtes. Er ist auf Wunsch des Kunden Daimler Chrysler 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. 176 gibt den Gesamtstatus auf einen Blick wieder und wird aus der Eingabevorlage der Fachbereiche automatisch generiert.

225

Status Teilprojekt zum Aktuellen Termin

226

Abb. 176: Wochenbericht

Beurteilung des Teilprojektes basierend auf drei Zeithorizonten

Status Teilprojekt zum nächsten Meilenstein

Status Teilprojekt zum Erstmusterprüfbericht



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. 177 und Abb. 178. 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.

227


Abb. 177: Dokumentation von Änderungen

228


Abb. 178: Änderungserfolgsrechnung 229


Abb. 177 zeigt, welche Änderungen mit welchen Stati zu welchen Kosten geplant sind. Abb. 178 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. Des Weiteren 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 Regelmeeting230


bericht zur Problembeseitigung dargestellt werden. Hinweise auf die 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.

231


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. 179).

Erfassung Stundenschreibung

Aktualisierung Kapazitäts-Plan Kostenstellen

Verteilung Auswertungen an Projekt-Manager

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-GAAPAbschluss

Offizieller Monatsbericht

2. Arbeitstag

7. Arbeitstag

ProjektReviewMeetings 10.-19. Lfd. Monat

ControllingBesprechung 25.-28. Lfd. Monat

Abb. 179: 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 Control232


ling-Besprechung eine Abstimmung zwischen den beteiligten Abteilungen, dem Projektcontrolling, der kaufmännischen Projektabwicklung 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. 180). Die Adressaten sollen durch standardisierte und gezielte Information in die Lage versetzt werden, sich eine schnelle und aktuelle Übersicht der Entwicklung zu verschaffen.

233


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. 180: Kategorien für Projektberichte Neben den innerhalb des SAP-Standard-Informationssystems zur Verfügung stehenden Berichten hat es sich insbesondere zum Zeitpunkt der Einführung von SAP R/3 mit dem Release 3.0 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. Berichte Der Projektmonatsbericht (vgl. Abb. 181) 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, 234


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. Im Projektkostenbericht (vgl. Abb. 182) 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. 183) 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. 184), 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.

235


Abb. 181: Deckblatt Projektmonatsbericht 236

3.2 Operative Projek ktkontrolle

Abbb. 182: Projeektkostenberricht 237


Abb. 183: Einzelpostenbericht

238

3.2 Operative Projek ktkontrolle

denbericht Abbb. 184: Stund 239


3.2.6.3 Berichtswesen der Zürich Gruppe Deutschland Um Transparenz über den Fortschritt aller Initiativen96 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 Zürich Gruppe Deutschland variiert zwischen monatlich und quartalsweise. Für die internationalen Initiativen erfolgt das Reporting des Initiativenfortschritts im monatlichen Rhythmus. Die Initiativen berichten zunächst 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ündel97 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. 185). 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. 96

97

240

Unter Initiativen versteht man in der Zürich 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 lfd. Jahr und 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 lfd. Jahr.

Abb. 185: Planungs- und Reportingdimensionen der Zürich Gruppe Deutschland

241


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. 186 bis Abb. 189) 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

242


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.

243


Abb. 186: ProControl-Client (1 von 4)


244




245


ProControl Frühwarnsystem (vgl. Abb. 190 bis Abb. 192) 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 gewünscht 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.

246


Abb. 190: ProControl-Frühwarnsystem (1 von 3)

247




248


3.2.7 Kennzahlen Die 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 unterscheidet verschiedene Arten von Kennzahlen (vgl. Abb. 193). 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. 193: Kennzahlenarten Gliederungszahlen beinhalten eine Teilgröße (Personalkosten), die auf die Gesamtheit (Gesamtkosten) bezogen wird. Besonders aussagekräftig sind Beziehungszahlen. Sie verknüpfen zwei Größen, zwischen denen eine sachliche Beziehung besteht. Indexzahlen verdeutlichen zeitliche Entwicklungen. Auch ein Quotient aus Istund Planzahlen kann als Index bezeichnet werden.

249


Worauf sollte man bei der Kennzahlenbildung achten? Folgende Fragen helfen, die richtigen Kennzahlen zu finden: Tipp

• • • • •

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?

Kennzahlen müssen eindeutig dokumentiert werden. Abb. 194 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) * 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. 194: Schema für die Definition einer Kennzahl

250


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. 195): 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 PM 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. 195: Kennzahlen für das Projektcontrolling 251


Für IT-Projekte der Swiss Life AG werden u. a. folgende Kennzahlen eingesetzt: 98 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.


unterstützt

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.

98

252

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.

3.3 Zusammenfassung

3.3 • • • •

•

•

•

•

•

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.

253


•

• •

•

•

•

• •

•

254

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, 0/100 und 0/20/80 gestartete, abgeschlossene und nicht abgeschlossene Arbeitspakete identifizieren und bewerten oder einen leistungsmäßigen Fortschrittsgrad ermitteln. Alle Verfahren sind ungenau. 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.

3.3 Zusammenfassung

• •

•

•

• •

• •

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 entscheidungsorientierte 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 sehr vereinfacht. Sie sollten sorgfältig ausgewählt und dokumentiert werden.

255

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 Informationen für das Projekt beschrieben.

257

4 DV-Unterstützung

4.1

Projektmanagementsoftware

Bereits seit den 60er Jahren werden vereinzelt DV-gestützte Projektmanagementsysteme für die Abwicklung von Großprojekten eingesetzt. Die damaligen Programme liefen auf dem Großrechner, verursachten hohe Kosten und boten wenig Bedienungskomfort. Auch der Funktionsumfang war gering. Mittlerweile sind PCgestützte Projektmanagementsysteme weit verbreitet. Die Planung und Steuerung auch kleiner Projekte wird damit 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?

Tipp

258

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: • 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. Vor allem am Anfang ist ein Mehraufwand einzukalkulieren. • 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. • Mitarbeiter, die mit dem System umgehen, sollten zu Beginn geschult werden. • Die Abwicklung von Projekten mit einem Projektmanagementsystem muss organisatorisch geplant und eindeutig geregelt werden. Hier ist das Projektcontrolling gefordert. Besonders ne-

4.1 Projektmanagementsoftware

gativ 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). Die Vielzahl der Programme kann in drei Kategorien eingeteilt werden:

Internet

www.manage mentsoftware.de

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 vorhanden. Die Implementierung und Pflege solcher Systeme verursacht aufgrund der hohen Komplexität einen hohen Aufwand. 259

4 DV-Unterstützung

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). Internet

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, MeilensteinTrenddiagramme. Im Folgenden sollen das bekannte MS-Project von Microsoft und das PS-Modul von SAP R/3 beschrieben werden. Abb. 196 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. 196: Vergleich des Moduls PS von SAP R/3 und MS-Project

260


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. 197). 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. 197: 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.99 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. Dabei werden die operativen Daten nicht automatisch angepasst.

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: 99

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.

261

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. 198: 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. 199). 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.

262


Bedarfsanforderungen

ModulPM PM Modul

ModulMM MM Modul

techn.Struktur Struktur techn.

Beschaffung/Versand Beschaffung/Versand Budget

Zuordnung Equipment zu Kalkulationsposition

Bestellwert (dynamisches Obligo)

ModulPS PS Modul

Startkalkulation, Change Orders, int. Änderungen

Projekt-Controlling Projekt-Controlling

Rechnung Ist-Kosten (Abbau dyn. Obligo)

Vollkostensätze

ModulCO CO Modul

GK-Controlling GK-Controlling

Manuelle Dateneingabe

Projektrückstellungen GK-Aktivierung

Ist-Stunden (Eigenleistungen)

ModulFI FI Modul

Finanzbuchhaltung Finanzbuchhaltung

Budget-Stunden (Eigenleistungen)

ModulS.I.S. S.I.S. Modul

Stundenmanagement Stundenmanagement

System Datentransfer

Abb. 199: 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 oder Windows Vista. Datenübergaben in die anderen MS Office-Programme sind ohne Probleme möglich. MS-Project kann mit der Programmiersprache VBA an die Anforderungen des Nutzers angepasst werden. Mittlerweile existiert eine Reihe von Beratungsunternehmen, die diesbezüglich ihre Dienste anbieten.

263

4 DV-Unterstützung

Abb. 200 zeigt die zentrale Maske für die Eingabe der Vorgänge und der Termine in MS-Project.

Abb. 200: 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 auf Basis des Microsoft Explorer Daten mit dem Projektleiter und anderen Projektbeteiligten austauschen: 264


• • •

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 aufzubauen, ist mit hohem Aufwand verbunden. Vor allem die Technologie der Serveranwendung von MS Project ist anspruchsvoll. Vor der Einführung ist genau zu definieren, für welche Aufgaben die Projektmanagementsoftware eingesetzt werden soll und welche Informationen erforderlich sind. Es besteht sonst die Gefahr, dass die vielen Einsatzmöglichkeiten, Ansichten und Berechtigungen in MS Project zu einer Überforderung der Mitarbeiter führen. Schließlich reicht es nicht, sich nur um die Software zu kümmern. Die Akzeptanz des Projektmanagements muss gleichzeitig verbessert werden. Eine gute Vorgehensweise ist es, ein zunächst einfaches System sukzessive zu erweitern. 4.2

Einführung einer Projektmanagementsoftware

Vor der Einführung der Projektmanagementsoftware sollte man die Projektmanagementprozesse optimieren. Danach müssen die Anforderungen an die Software erfasst und gewichtet werden. Nach Sichtung des Marktangebots kann mittels der Nutzwertanalyse eine Auswahl getroffen werden. Diese in Frage kommenden Systeme müssen dann einem ausführlichen Test unterzogen werden. Schließlich folgt die Entscheidung, welches System angeschafft werden soll.

265

4 DV-Unterstützung Pr ojektmanagementsoftware Kriterien

Software A

Software B

Software C

erfüllt

erfüllt

erfüllt

Muss-Kriterium Da tenaustausch mit SAP Kann-Kriterien

G

P

GxP

P

GxP

P

G xP

Kosten - Kaufpreis - Folgekosten

10 5 5

10 4

50 20

5 7

25 35

5 7

25 35

PM-Funktionalitäten - Projektstrukturplan - Netz plan - 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

Or ganisatorische Kriterien - Schulungsaufwand - Akz eptanz bei den Projektleitern - Inte gration 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 - Inte rnationalisierung - 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. 201: Systematische Bewertung und Auswahl von Projektmanagementsoftware mit der Nutzwertanalyse Man sollte festlegen, für welche Aufgaben die Projektmanagementsoftware eingesetzt werden soll und welche Daten der Software erforderlich sind. Es besteht sonst die Gefahr, dass die vielen Einsatzmöglichkeiten, Ansichten und Berechtigungen zu einer Überforderung der Mitarbeiter führen. Schließlich reicht es nicht, sich nur um die Software zu kümmern. Die Akzeptanz des Projektmanagements muss gleichzeitig verbessert werden.

266

4.2 Einführung einer Projektmanagementsoftware

Im Rahmen der Einführung von MS Office Project bei der Versicherungsgesellschaft Münchner Verein wurden folgende Regelungen getroffen:100 • 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.3

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. 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. Führungsinformationssysteme nutzen die Daten der operativen Basissysteme. Meist greifen sie auf eine Datenbank zu, die regelmäßig mit für betriebswirtschaftliche Auswertungszwecke transformierten und vorselektierten Daten der operativen Systeme versorgt wird (vgl. Abb. 202). Wichtige Kennzeichen eines Führungsinformationssystems sind: • sehr komfortable Bedienung im Vergleich zu den operativen Basissystemen; • weitreichende grafische Darstellungsmöglichkeiten der Daten; 100 Campana, C., Schott, E., Haffner, S., MS Project 2002 im Praxistest. Pro-

jektmagazin 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).

267

4 DV-Unterstützung

DatenhaltungsEbene

Operative Ebene Projektmanagement

Einkauf Vertrieb Kunden

Externe Daten

T r a n s f o r m a t i o n

AuswertungsEbene MIS

Data Data Warehouse Warehouse

Meta Data

Berichte

Tabellenkalkulation

Abb. 202: Datenversorgung eines MIS • •

• •

schnelle Auswertung auch umfangreicherer 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; Ursachenanalysen auf der Basis hierarchisch aufgebauter Kennzahlenbäume; mehrdimensionale Datenanalyse.

Die DaimlerChrysler AG nutzt z. B. das System der MIS AG für folgende Aufgaben:101 • Abstimmung von Kapazitäten und Bereichskosten mit den Projekten; • Aufbereitung von aussagekräftigen Soll-Ist-Vergleichen; 101 Rosemann, S., Funke, T., Prozess-, Projekt- und Bereichssteuerung, Dimen-

sionen 1 (2000), S. 17 f.

268

4.3 Zusammenfassung

• •

Ermittlung von Prognosewerten über die voraussichtlichen Projektergebnisse; Information über die Einflussmöglichkeiten zur Steuerung des Projektbudgets.

Eine zentrale Rolle spielt bei der DaimlerChrysler AG das Controlling der Projektkosten und -erlöse. Auf der Grundlage des Projektfortschritts wird das voraussichtliche Projektergebnis prognostiziert. Der Anwender kann verschiedene Maßnahmen simulieren. Die Auswirkung auf verdichteter Ebene werden ihm dann sofort präsentiert. 4.3.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 (Datenbanken) modelliert (vgl. Abb. 203). 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

Projektcontrolling

Unternehmenscontrolling

Bereichscontrolling

Übergabe der Kostensätze

Abstimmung

Kostenstellen AFA

Zeiterfassung

Reisekostenabrechnung

Finanzbuchhaltung

Kostenrechnung

„Spiegel“: - Anlagen - Verbindl. EK usw.

Anlagenbuchhaltung

usw.

Transaktionssysteme

Abb. 203: Wesentliche Informationsbausteine zur quantitativen Analyse

269

4 DV-Unterstützung

Der Hypercube zur Abbildung der GuV-/Bilanz- und Cash FlowRechnungen auf Unternehmensebene (Baustein: Unternehmenscontrolling) besteht z. B. aus den Dimensionen: • Währungen (wie z. B. Dollar, Euro), • Rechtseinheiten, • Optionale Partner-Rechtseinheiten (relevant zur Abbildung von Leistungsverflechtungen), • Datenarten (wie z. B. Plan, Ist, Abweichung, Simulation), • Perioden (Jahre und Monate), • 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 der Projekte (= Bestandteil des Hypercubes "Projektcontrolling") und der Ressourcen (= Bestandteil des Hypercubes "Ressourcen") näher eingegangen. Informationen zu den sonstigen Strukturen des Lösungsbeispiels finden sich in den Abb. der nachfolgenden Kapitel. Die Abb. 204 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.

270

Land (1-n Regionen)

(1-n Projekte) Branche (1-n Kunden)

Summe Branchen (1-n Branchen)

(1-n Projekte)

(1-n Projekte)

Geschäftsbereich (1-n Projekttypen)

Summe Geschäftsbereiche (1-n Geschäftsbereiche) Summe Welt (1-n Kontinente)

Kontinent (1-n Länder)

Region (d. Kunden) (1-n Projekte)

Kunde

Projektleiter

Mögliche parallele Verdichtungen

Projekttyp

Projekt

Konzern (1-n Rechtseinheiten)

Konzern (1-n Rechtseinheiten)

Rechtseinheit (1-n Niederlassungen) Rechtseinheit (1-n Niederlassungen)

Rechtseinheit (1-n Niederlassungen) Konzern (1-n Rechtseinheiten)

Niederlassung (1-n Ressourcen)

Typ of Experience (1-n Ressourcen)

Niederlassung (1-n Ressourcen)

Skill Typ (1-n Ressourcen)

Mögliche parallele Verdichtungen

Niederlassung (1-n Teams)

Team (1-n Ressourcen)

Ressource

4.3 Zusammenfassung

Abb. 204: Projekt- und Ressourcendimensionen

271

4 DV-Unterstützung

Internet

www.bissantz. de

4.3.2 Projektdatenanalyse mit dem Delta Master Ein komfortables System zur Datenanalyse, Berichterstattung und Planung ist DeltaMaster von 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 sogenannte OLAP-Datenbanken (Online Analytical Processing) 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. 205 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. Von diesen ausgehend, wird er dann weitere Kennzahlen abrufen und Analysen anstellen.

272

4.3 Zusammenfassung

Abb. 205: Hyperbrowser im Delta Master

273

4 DV-Unterstützung

Die Tabelle in Abb. 206 ist nach der Earned Value Methode modelliert und gibt die Daten des Beispiels in Abb. 162 wieder.

Abb. 206: Abweichungsanalyse für die Earned Value Kennzahlen

274

4.3 Zusammenfassung

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

275

4 DV-Unterstützung

Abb. 207: Portfoliodarstellung der Leistungs- und Kostenabweichung

276

4.3 Zusammenfassung

Im Beispiel der Abb. 208 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. 209 deckt die Software durch sukzessive Verfeinerung (Drill-in) 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.

277

4 DV-Unterstützung

Abb. 208: Identifikation auffälliger Arbeitspakete 278

4.3 Zusammenfassung

Abb. 209: Identifikation der Verursacher einer Abweichung 279

4 DV-Unterstützung

4.4 • • •

280

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. Managementinformationssysteme unterstützen die entscheidungs- und 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.

281

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, Band 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., Einführung in das Controlling, 2. Aufl., München, Wien 2000. 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, 10. Aufl. München 2006. 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. Kellner, H., Die Kunst, DV-Projekte zum Erfolg zu führen: Budgets - Termine - Qualität, München, Wien 1994. Kneuper, R., CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration, 2. Auflage, Heidelberg 2006.

282

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, 4. Aufl. Stuttgart 2005. 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üller, A., von Thienen, L., e-Profit: Controlling-Instrumente für erfolgreiches e-Business, Kiel 2001. Müser, H. Controlling im Großanlagenbau, in: Reichmann, T. (Hrsg.): Controlling-Praxis, Erfolgsorientierte Unternehmensführung, München 1988, S. 338 – 353.

283


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. 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. Serfling, K., Controlling, 2. Aufl., Stuttgart, Berlin, Köln 1992. Siepert, H., Projektcontrolling im Großanlagenbau, in: Männel, W. (Hrsg.), Handbuch Kostenrechnung, Wiesbaden 1992, S. 1003 ff. Solaro, D. u.a., Projekt-Controlling, Stuttgart 1979. 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, 5. Aufl., Wiesbaden 2000.

284


Töpfer, A., Das Management der Werttreiber, FAZ Juli 2000, S. 266 ff. 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.

285


Stichwortverzeichnis Fortschrittsgrad 185

G A Abhängigkeiten 79 Abschlussbericht 216 Abweichungsbericht 213 Amortisationsrechnung 59 Anforderungen an den Controller 22 Aufbauorganisation 102 Aufwandsschätzung 123

B Balanced Scorecard 89 Berichtswesen 233 Break-Even-Analyse 56

C Completed Contract Methode 172 Controller-Leitbild 22 Controllingphasen 176 Cost-to-Cost-Methode 184

D Datenmodell eines MIS für das Projektcontrolling 270 Dezentrale Projektplanung 110 Durchführungskontrolle 86

E Earned Value Analyse 198 Economic Value Added (EVA) 63 Effort-Expended -Methode 184 Einflussmatrix 79 Ermittlung des Personalbedarfs 146 Exception Reporting 213

F Fixe Kosten 165

Gemeinkosten 158 Gewichtete Zielstruktur 43

I Interne Zinsfußmethode 62

K Kapitalwertmethode 59, 60 Kostenindex 203

L Leistungsfortschritt 182 Leistungsindex 203 Leistungskontrolle 182

M Magisches Dreieck 8 Methoden und Tools 263 MS Office Solution EPM 264 Multiprojektcontrolling 14, 15

N Nutzwertanalyse 266

O Operative Projektkontrolle 177 Organisation des Projektcontrollings 23

P Percentage of Completion Methode 172, 173 Prämissenkontrolle 86 Projekt 2 Projektaufwandsschätzung 122

287

Stichwortverzeichnis Projektcontroller 20, 22 Projektcontrolling 11, 16 Projektcontrolling bei der Lufthansa Systems GmbH 26 Projektdefinition 5 Projektkontrolle 176 Projektkostenkalkulation 156, 159 Projektmanagement 7 Projektphasen 103 Projektplanung 100 Projektressourcen 146 Projekt-Scorecard 92 Projektstatusberichte 242 Projektziele 101

R Rentabilität 58 Ressourcen 146 Ressourcenplanung 146 Restaufwand 184 Return on Investment (ROI) 59 Risikoanalyse 73 Risikoübertragung 70 Risk Map 68

S SAP R/3, Modul PS 260, 261 Schätzmethoden 119 Sollkosten 198 Standardbericht 214 Standardstrukturplan 111 Strategische Projektkontrolle 86 Strategische Projektplanung 36

T Terminkontrolle 188 Time-to-Completion 180, 188

V Variable Kosten 165

W Wertorientierte Strukturplan 115 Wirtschaftlichkeit 53

Z Zeit-/Kostendiagramm 195 Zielkonflikte 44

288

Controlling von Projekten

Vieweg Verlag - Controlling von Projekten 4. Auflage

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

Softwarequalitat in PHP-Projekten

Perspektiven einer neuen Engagementkultur: Praxisbuch zur kooperativen Entwicklung von Projekten

Risikomanagement in Projekten