Projektplanung realisieren mit Project 2007

4 4 Terminplansteuerung bei mehreren Projekten Wir haben im vorherigen Kapitel den systematischen Aufbau eines Projektplanes darge- stellt. Das singuläre Projekt ist die „Keimzelle“ jedes Projektmanagements, darauf baut alles auf. Im einzelnen Projekt entsteht die Qualität der Daten, auch und gerade, wenn viele Projekte eine Rolle spielen und die Daten aller Projekte des Unternehmens insgesamt be- trachtet und ausgewertet werden sollen. Es nützt die tollste Server-Technologie nichts, wenn die Daten aus den einzelnen Projekten Schrott sind. Der methodisch kluge Aufbau eines Projektes besteht in der richtigen „Mischung“ von Vorgängen, die vom Programm berechnet werden können, und Fixterminen. Bei Änderun- gen soll das Programm die Termine und die anderen Daten (z. B. Ressourcenauslastung) bei „normalen“ Vorgängen neu berechnen und damit die geänderte Datenlage anzeigen und Fixtermine, die den Projektplan stabilisieren und deren Änderung nur durch einen Eingriff der Projektleitung (und nicht durch das Programm) möglich ist. Alle wichtigen Übergänge im Projekt – zwischen den Projektphasen, von einem Unternehmen zum nächs- ten oder auch von einer Abteilung zu anderen – müssen als Meilensteile fest vereinbart, d. h., in Project fixiert werden. Im Gegensatz dazu müssen alle inhaltlichen Aktivitäten, die sich in der eigenen Planungshoheit befinden, variabel sein hinsichtlich Termin- und Res- sourcenänderungen. Dieses methodische Prinzip findet seine analoge Fortsetzung, wenn man mit mehreren Pro- jekten arbeitet. All das, was wir bisher für die Projektphasen und ihre Übergänge entwi- ckelt haben, gilt sinngemäß bei mehreren Projekten für ihre Struktur und ihre Abhängig- keiten untereinander. Projektorientiertes Arbeiten in Unternehmen führt schnell von einigen Projekten zu vielen. Es gibt mannigfache Gründe, mit mehreren Projekten zu arbeiten. Einmal weil es ganz ein- fach viele Entwicklungen, z. B. neuer Produkte oder neuer Technologien, gibt, die als Pro- jekte vorangebracht werden. Zum anderen kann man auch ein großes Projekt in mehrere Teilprojekte aufteilen, wobei jeder Projektleiter seinen Teil als Projektplan verantwortlich pflegt. Wie man den Inhalt und Umfang eines Projektes definiert, ist ja frei, und da mögen einzelne Projektphasen schon als eigenständige Projekte gelten oder Teile eines Gesamt- 111 4 Terminplansteuerung bei mehreren Projekten projektes (man denke an Entwicklungen im Maschinen- und Anlagebau) schon so umfang- reich sein, dass man sie als eigenständige Projekte ansehen will oder aus organisatorischen Gründen ansehen muss. Gerade wenn man große Projekte in Teilprojekte aufgliedert, blei- ben die Abhängigkeiten von Vorgängen in einem Projekt von Ergebnissen in einem ande- ren Projekt bestehen. Umgekehrt – sozusagen von oben betrachtet – besteht das gesamte Projektportfolio eines Unternehmens oder einer Organisation aus mehr oder weniger großen Projekten, die wie- der in Teil- oder Unterprojekte aufgeteilt sein mögen. (Die Einteilung in Programme, z. B. Organisations-, Produkt- oder interne Technologieentwicklungsprojekte, ordnet die Projek- te inhaltlich, nicht strukturell.) Manche Unternehmen siedeln ihr Projektmanagement auf unterschiedlichen organisatori- schen Ebenen an: Die oberste Ebene ist verantwortlich für den Kundenkontakt und verein- bart feste Meilensteine mit den Stakeholdern. Die Termine müssen mit der operativen Ebe- ne, die intern das Projekt realisiert, kommuniziert werden und vice versa. Auch dies führt technisch zu mehreren oder vielen Project-Dateien, die spezifische Verknüpfungen haben. Bei der Gesamtprojektplanung mit dem Project Server 2007 können Lieferumfänge (Deli- verables) definiert werden. Diese stellen wichtige Auslieferungen des Projektes zu einem bestimmten Zeitpunkt dar. In den Windows SharePoint Services (WSS) können diese allen Beteiligten mitgeteilt werden, sie können sowohl im WSS als auch aus den Projektplänen in Project definiert werden. Wir zeigen hier die Anwendung in Abschnitt 4.4, Arbeiten mit Lieferumfängen. Unabhängig von der Ursache für die Existenz vieler Projekte in einer Organisation können die Projekte folgende strukturellen Zusammenhänge bzw. Abhängigkeiten haben: 1. Verschiedene Projekte können als Teil eines (größeren) Projektes betrachtet werden. Diese Projekte sind dann in MS Project Teilprojekte, die in einem Masterplan zusam- mengeführt werden können. Diesen Punkt behandeln wir zunächst. 2. Es bestehen Abhängigkeiten zwischen den Projekten in dem Sinne, dass (Zu-)Lieferun- gen aus einem Projekt Voraussetzung sind für die Weiterführung anderer Projekte. Dies sind Abhängigkeiten zwischen Projekten, die in MS Project als projektübergrei- fende Vorgangsbeziehungen abgebildet werden können. Die Kunst dabei ist, die Ter- mine aus anderen Projekten und gegebenenfalls Terminplankonflikte anzuzeigen, aber die Termine im eigenen Projekt nicht automatisch durch das Programm verschieben zu lassen. Die Entscheidungsgewalt muss immer beim Projektleiter, nicht beim Programm liegen. Dies behandeln wir im gleichnamigen Abschnitt. 3. Aus organisatorischen Gründen gibt es öfter eine sogenannte Multi-Level-Terminpla- nung. In der Praxis verhandelt eine Ebene die Termine, z. B. mit den Kunden. Diese Termine werden als Vorgaben der zweiten Ebene, die intern das Projekt durchführt, mitgeteilt, die diese in Ihren Projekten berücksichtigen muss. Sie vergibt evtl. noch Un- teraufträge an eine dritte Ebene mit gegenseitiger Terminkommunikation. Die unterge- ordnete Ebene muss die Zielerreichung wichtiger Meilensteine – aber natürlich auch Abweichungen – wieder an die übergeordnete Eben zurückmelden. Das Ganze muss 112 4.1 Teilprojekte und Masterplan vor Terminkonflikten warnen und natürlich Änderungsschleifen für die Beteiligten er- möglichen. Dies behandeln wir unter der Überschrift „Multi-Level-Terminplanung mit Kapselungen“. 4. Für die Project Server 2007-Benutzer gibt es die Möglichkeit, Lieferumfänge aus einem Projekt in einem anderen Projekt anzuzeigen. Dies ist an den Begriff der „Deliverables“ angelehnt, wie er sich im PMBOK Guide1 inhaltlich durchzieht. Lieferumfänge aus Pro- jekten, die für andere wichtig sind, können allen Berechtigten in den Windows Share- Point Services (WSS) mitgeteilt und können auch in den Project-Plänen definiert und angezeigt werden. Dies behandeln wir im Abschnitt „Arbeiten mit Lieferumfängen“. 5. Die Projektverantwortlichen in einer Organisation konkurrieren grundsätzlich um die Mitarbeiter, die in mehreren Projekten eingesetzt werden. Dies wird in MS Project durch einen gemeinsamen Ressourcenpool – sei er datei- oder serverbasiert – auf den die Projekte zugreifen, gelöst. Die Ressourceneinsatzplanung für mehrere Projekte be- handeln wir im Ressourcenkapitel (Kapitel 5). Der Prozess der projektübergreifenden Terminplansteuerung Eingangswerte: Die Projekteinzelpläne, technische, organisatorische, terminliche Abhängigkeiten zwi- schen den Projekten, Definition der Liefergegenstände. Methoden und Verfahren: Optional: Einfügen der Einzelpläne in einen Gesamtplan. Optional: Projektübergreifende Vorgangsbeziehungen einrichten. Optional: Die Input-Meilensteine aus anderen Projekten kapseln, wenn keine auto- matischen Verschiebungen durch andere Projekte gewünscht werden. Optional nur bei Einsatz des Project Servers 2007: Definieren und Anzeigen der Lieferumfänge. Ausgangswerte: Der optimierte Gesamtplan. Terminpläne, welche die Abhängigkeiten zwischen den Einzelprojekten berücksichtigen. Anzeige der Lieferumfänge. Abbildung 4.1 Prozess projektübergreifende Terminplansteuerung 1A Guide to the Project Management Body of Knowledge (PMBOK Guide), Dritte Ausgabe, PMI, Newton Square, Pennsylvania 2004 113 4 Terminplansteuerung bei mehreren Projekten 4.1 Teilprojekte und Masterplan Die Anlage von Teilprojekten und ihre Zusammenfassung in einem Masterplan ist sozusa- gen eine logische Fortsetzung des Projektstrukturplanes (PSP), der in Project mit der Funktion der Gliederung herausgearbeitet wird. Während die Gliederung in Sammelvor- gänge und Untervorgänge Projektphasen und jeweils untergeordnete Detailebenen in ei- nem Projektplan darstellt, enthält das Gesamtprojekt die Teilprojekte als jeweils separate Projekte. Dies kann aus Gründen der Übersichtlichkeit und des besseren Handlings der (kleineren) Teilprojekte nützlich sein. Ein zwingender Grund, ein größeres Projekt in Teil- projekte aufzuspalten, ist, wenn jeweils ein anderer (Teil-)Projektleiter verantwortlich ist und diese ihre Teilprojektpläne selbstständig unter eigener Verantwortung führen sollen. (Bitte pro Project-Datei bzw. pro Projekt immer nur ein verantwortlicher Bearbeiter!) Die Projekte, die in einen Masterplan eingebunden werden, können wiederum Teilprojekt- pläne enthalten, in diese können wiederum Teilprojekte eingefügt werden etc. Die Grenze ist eigentlich nur die Übersichtlichkeit für den Benutzer, und diese sollte immer das höchs- te Ziel sein.

Josef Schwab Projektplanung realisieren mit Project 2007 Das Praxisbuch für alle Project-Anwender ISBN-10: 3-446-41342-1 ISBN-13: 978-3-446-41342-9 Vorwort Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41342-9 sowie im Buchhandel. Vorwort Dieses Buch will all jenen eine Hilfestellung geben, die Projekte mit Microsoft Project pla- nen und durchführen. Das Tool ist ein Hilfsmittel, das die Arbeit erleichtern soll. Und ohne die Unterstützung eines rechnergestützten Systems ist die Datenflut, zumindest in größeren Projekten, nicht mehr zu bewältigen. Andererseits ist Projektmanagement mehr als eine Datensammlung, nämlich ein zielgerichtetes wirtschaftliches Handeln, das versucht, unter der Bedingung der Unsicherheit – Planung plant in die Zukunft, und die ist grundsätzlich unsicher – die eingesetzten Mittel so produktiv und effektiv wie möglich einzusetzen. Da- zu hat die ökonomische Theorie und die Praxis der Projektarbeit eine mehr oder weniger nützliche Wissensbasis erarbeitet – genannt sei als Beispiel nur die Netzplantechnik –, die man sich zunutze machen kann, ja muss, um sich überflüssigen Aufwand und Irrwege zu ersparen. Die Toolanwendung bedarf dieses Hintergrundwissens des Anwenders, um nicht beim vollkommen unproduktiven Termine-Tippen und Balken-Malen stehen zu bleiben, sondern um für die Projektarbeit eine Basis zu entwickeln, die das Entstehen von kriti- schen Vorgangsfolgen kennt und deshalb optimale Lösungswege vorschlagen kann – auch bei Änderungen und Störungen, die sich in Projekten zwangsläufig ergeben. Kurz: Dieses Buch will zeigen, wie durch die Anwendung des Programms auf Basis der Methoden des Projektmanagements eine wirkliche Hilfestellung für die Projektarbeit mög- lich ist. Damit wendet es sich an alle Projektleiter und deren Mitarbeiter, die Projekte in- haltlich planen und die Durchführung überwachen wollen und dabei Microsoft Project ein- setzen. Es soll sowohl für die Anwender, die dateibasiert auf ihrem Client arbeiten – viel- leicht in Zusammenarbeit mit Ihren Kollegen im Netzwerk –, als auch für die Projektleiter, die in Ihrem Unternehmen mit einem Project Server arbeiten, nützlich sein. Die Differen- zen, die sich aus den unterschiedlichen Umgebungen ergeben, werden jeweils erläutert. Sie sind für die inhaltliche Projektarbeit aber meines Erachtens nicht so gravierend, um nicht beide Gruppen von Anwendern gemeinsam ansprechen zu können. Dieses Buch wendet sich nicht an die Mitarbeiter, die den Project Server installieren und administrieren, und es lässt die Projektarbeit mittels Web Access und die Features der Team-Kommunikation mit den Windows sharepoint Services außen vor. Dies wird in einem späteren Band zu Project Server 2007 und Project Portfolio Server 2007 behandelt. XI Vorwort Die Gründe dafür, dass im vorliegenden Buch die speziellen Project-Server-Anwendungen nicht behandelt werden, sind vielfältig. Einmal haben sich beide Gebiete enorm ausge- weitet, so dass es nur ein unhandlicher dicker Wälzer geschafft hätte, beide zu vereinen. Vor allem aber liegt die Trennung in der Sache selbst begründet: Hier methodisches Pro- jektmanagement, dort doch mehr serverbasierte Unternehmenslösungen, Anpassungen und Informationsvermittlung. Und damit hat man auch unterschiedliche Zielgruppen: Warum sollen Projektmanager, die vorrangig am inhaltlichen und methodischen Aufbau ihrer Plä- ne arbeiten, sich für die Installation und Administration des Project Servers interessieren? Auch im Enterprise Projekt Management entstehen die Daten im Einzelprojekt. In diesem Buch wollen wir zeigen, wie diese Projekte sinnvoll aufgebaut und auch projektüber- greifend geplant werden können – wir behandeln z.B. die Mehrprojekttechnik und auch die Kontrolle des Ressourceneinsatzes über mehrere Projekte, unabhängig ob Datei- oder Ser- ver-basiert. Aber wir legen Wert auf die inhaltlich sinnvolle Reihenfolge: Der methodisch richtige Aufbau der Einzelprojekte ist die Voraussetzung für Multiprojekttechnik und pro- jektübergreifende bzw. unternehmensweite Ressourceneinsatzplanung. Die Einzelprojekte liefern die Daten für die Auswertungen auf dem Project Server und die über den Server vermittelte Teamkommunikation. Und wenn diese Daten – mal vorsichtig ausgedrückt – qualitativ nicht ganz hochwertig sind, kann das, wozu anschließend diese Daten verwendet werden, ebenfalls qualitativ nicht so hochwertig sein. Deshalb geht es mir in diesem Buch darum, die wissens- und methodenbasierte Anwen- dung des Tools in den Projekten zu zeigen. Dies verbessert die Informationsbasis sowohl für die Manager der Einzelprojekte als auch für das Management des Projekt-Portfolios des Unternehmens, die dann mit Hilfe dieser Informationen notwendige und unabhängige Entscheidungen treffen müssen. Nach wie vor müssen die Menschen entscheiden, die Fra- ge ist nur, auf welcher Informationsbasis. Dieser Band versteht sich zwar auch als ein Update auf die Programmversion Microsoft Project 2007, aber wie bei jedem Buch über eine neue Version, nehme ich das zum Anlass, meine in der Zwischenzeit gesammelten neuen Erfahrungen und auch meinen Lernprozess in die Ausführungen und Übungen einzubringen. Es wäre ja schlimm, wenn es in den vier Jahren seit dem letzten Buch1 keine Entwicklung gegeben hätte. Wie immer muss und will ich betonen, dass ich auf vielen Schultern stehe, und dass die hier dargestellten Methoden, Lösungsverfahren und praktischen Tipps aus vielen Quellen kommen. Als Erstes muss ich den Teilnehmern meiner Seminare danken, die mich auf vie- le Probleme in der Praxis ihrer Anwendungen aufmerksam machten (das ist immer der ers- te Schritt: Das Problem wahrnehmen) und manchmal auch schon Lösungsansätze erarbei- tet haben oder später mit mir kommunizierten. Seminarteilnehmer sind ein gnadenloses Testlabor für die Software, aber auch für den Trainer. Auch auf dem Diskussionsforum, das meiner Homepage angegliedert ist, waren und sind viele intelligente Fragen und einige gute Antworten gepostet. 1 „Projektplanungen realisieren mit MS Project 2003 und Project Server 2003“, Hanser Verlag, München 2005 XII Vorwort Dann gilt natürlich mein besonderer Dank den Unternehmen, die sich in das Abenteuer ei- ner Beratung durch mich gewagt haben. Ich will und kann keine konkreten Namen nennen, meist unterliegt das ja der Verschwiegenheitspflicht. Aber mit dem Angebot der Enterprise Project Management-Lösung mit Project und Project Server ist natürlich der Bedarf an Beratung und Unterstützung gewachsen. Das ist gut so, nicht nur für die Berater, sondern auch für die Unternehmen, so sie vernünftig beraten werden. Die Komplexität der Aufgabe (sowohl im engeren IT-Bereich als auch im Know-how des methodischen Projektmanage- ments), ein unternehmensweites Projektmanagement einzuführen, erfordert Spezialwissen und Erfahrung aus mehreren solcher Projekte. Und diese Aufgabe erfordert auch eine Ar- beitsteilung: Unternehmen, die die Lösung ihrer eigenen IT-Abteilung oder sonst jeman- dem im eigenen Hause zumuten wollten, haben schon viel Lehrgeld bezahlt. Dennoch werden Kollegen vom Fach hier erkennen, dass die (neuen) Kapitel über Multi- projekttechnik, die Kostenplanung in Microsoft Project und auch die Earned-Value-Analy- se mit dem Programm aus Beratungsaufträgen heraus entstanden sind. Das ist der Sinn sol- cher Ausführungen: Erfahrungen weitergeben. Bei einem meiner Partner will ich eine Ausnahme machen und mich persönlich bedanken. Das ist Jürgen Sturany, PMP, inzwischen mein Freund geworden. Bei der Planung und Steuerung seiner mehrere hundert Millionen Euro schweren komplexen technischen Kun- denprojekte in der Erdölindustrie hat er das Programm bis jenseits der Grenzen schon aus- gereizt und mir dabei in der Praxis gezeigt, dass ein konsequenter Tooleinsatz mit einem klugen Kopf dahinter eine unverzichtbare Hilfe für die Projektarbeit ist und einen wirkli- chen, von allen Beteiligten wahrgenommenen Nutzen für Planung und Durchführung be- deutet. Nachdem ich staunend seine Pläne studiert hatte, formulierte er seine weiteren Wünsche in die Richtung, die Grenzen des Programmeinsatzes noch weiter hinauszuschie- ben. Dabei waren dann auch manchmal meine Grenzen erreicht. Aber wir hatten (und ha- ben) mehr als eine für beide Seiten produktive Diskussion, weil theoretische Kenntnisse der Möglichkeiten des Tooleinsatzes (in denen er ein Consulting durch mich wünschte) und fachliche, auf einem sicheren methodischen Hintergrund verstandene praktische lang- jährige Erfahrungen bei ihm eine geistige Konfrontation auslösten und dann oft eine Syn- these eingingen. Ich habe von ihm viel gelernt. Bedanken will ich mich auch bei meinem Kollegen Max Appru. Seit vielleicht zwei Jahren haben wir eine intensive Kommunikation; er ist für mich so etwas wie mein Alter Ego ge- worden. Mit einer wirklich bewundernswerten Geduld erträgt er meine Launen. Nebenher installiert er – auch das mit bewundernswerter Geduld –diverse Project Server mit allem, was dazugehört, in heterogenen Umgebungen unter manchmal schwierigen Bedingungen. Er hat, auch durch diese Arbeitsteilung mit mir, viel zu diesem Buch beigetragen. Mein Sohn, mit meiner Tätigkeit als Berater und Autor aufgewachsen, steht hoffentlich bald vor seinem Diplom als Volkswirt.

Josef Schwab Projektplanung realisieren mit Project 2007 Das Praxisbuch für alle Project-Anwender ISBN-10: 3-446-41342-1 ISBN-13: 978-3-446-41342-9 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41342-9 sowie im Buchhandel. Inhalt Vorwort ............................................................................................................................... XI Ein schneller Zugang........................................................................................................XV 1 Grundlagen............................................................................................................... 1 1.1 Was ist ein Projekt? ................................................................................................................. 1 1.2 Projektplanung......................................................................................................................... 3 1.2.1 Ihr Plan entsteht im Kopf …...................................................................................... 3 1.2.2 … vom Kopf in das Programm … ............................................................................. 3 1.2.3 … und dann in die Realität! ....................................................................................... 5 1.2.4 Wie werden die Termine berechnet?.......................................................................... 7 1.3 Viele Projekte und viele Beteiligte? ...................................................................................... 14 1.3.1 Mehrprojekttechnik.................................................................................................. 14 1.3.2 Dateibasiertes Arbeiten versus Project-Server-Lösung............................................ 16 1.3.3 Gründe für den Servereinsatz................................................................................... 17 1.4 Die Kommunikationsstruktur des Project Servers ................................................................. 20 2 Arbeiten mit Microsoft Project.............................................................................. 23 2.1 Eine kurze Bedienungsanleitung ........................................................................................... 23 2.1.1 Befehle ausführen .................................................................................................... 24 2.1.2 Symbolleisten anpassen ........................................................................................... 25 2.1.3 Auswahl über das Menü .......................................................................................... 26 2.1.4 Auswahl über das Kontextmenü .............................................................................. 27 2.1.5 Befehlsausführung über Symbole ............................................................................ 28 2.1.6 Vorgang löschen ...................................................................................................... 29 2.1.7 Rückgängigmachen, mehrmals ................................................................................ 29 2.1.8 Änderungen hervorheben......................................................................................... 30 2.1.9 Weitere nützliche Symbole ...................................................................................... 30 2.2 Ansichten, Tabellen und Masken .......................................................................................... 31 2.2.1 Ansichten ................................................................................................................. 31 2.2.2 Tabellen ................................................................................................................... 33 2.2.3 Masken .................................................................................................................... 35 V Inhalt 2.2.4 Kombinierte Ansichten.............................................................................................36 2.2.5 In den Ansichten verlaufen? .....................................................................................38 2.3 Die Grundeinstellungen in Project .........................................................................................39 2.3.1 Bevor Sie beginnen …..............................................................................................39 2.3.2 Anfangstermin ..........................................................................................................39 2.3.3 Projektkalender.........................................................................................................41 2.3.4 Neuen Kalender erstellen..........................................................................................43 2.3.5 Kalender-Optionen ...................................................................................................48 2.3.6 Datei-Eigenschaften..................................................................................................51 2.4 Arbeiten mit dem Project Server............................................................................................53 2.4.1 Anmeldung am Server ..............................................................................................53 2.4.2 Speichern als Projekt ................................................................................................56 2.4.3 Projekt öffnen/auschecken/einchecken .....................................................................57 2.4.4 Als Datei speichern...................................................................................................59 2.4.5 Project-Datei importieren .........................................................................................60 2.4.6 Veröffentlichen.........................................................................................................62 2.4.7 Zusammenfassung ....................................................................................................65 3 Terminmanagement .............................................................................................. 67 3.1 Terminplanung .......................................................................................................................68 3.1.1 Definition der Vorgänge ...........................................................................................69 3.1.2 Die Dauer .................................................................................................................71 3.1.3 Gliederung ................................................................................................................74 3.1.4 Anordnungsbeziehungen ..........................................................................................78 3.1.5 Meilensteine .............................................................................................................89 3.1.6 Anzeige der Vorgangstreiber....................................................................................90 3.1.7 Projektprozesse methodisch erfassen........................................................................91 3.1.8 Projektprozesse – einige Beispiele ...........................................................................93 3.2 Ergebnis der Planung: Berechnete Termine .........................................................................100 3.3 Fortgeschrittene Features der Vorgangsplanung ..................................................................101 3.3.1 PERT-Analyse (Drei-Punkte-Schätzung) ...............................................................101 3.3.2 Spezielle Terminberechnungen...............................................................................106 3.4 Termineinschränkungen und feste Termine .........................................................................111 3.4.1 Stichtage .................................................................................................................113 3.4.2 Termineinschränkungen .........................................................................................115 3.4.3 Konfliktanalyse.......................................................................................................120 3.5 Terminplansteuerung............................................................................................................122 3.6 Planungsqualität ...................................................................................................................123 3.6.1 Zeitreserven ............................................................................................................124 3.7 Die gekapselte Projektstruktur .............................................................................................127 4 Terminplansteuerung bei mehreren Projekten ................................................. 133 4.

Josef Schwab Projektplanung realisieren mit Project 2007 Das Praxisbuch für alle Project-Anwender ISBN-10: 3-446-41342-1 ISBN-13: 978-3-446-41342-9 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41342-9 sowie im Buchhandel. 9 9 Earned-Value-Analyse (Ertragswertmethode) Einerseits hat man in der Projektüberwachung die Informationen zu den zeitlichen Abwei- chungen, die Abweichungen der Termine, auf der anderen Seite die Abweichungen der Kos- ten. Daran können sich viele Fragen stellen, die beide Zielgrößen („in time“ und „in budget“) in eine Beziehung bringen. Ein rein zeitlicher Verzug wäre ja einfach damit zu erklären, dass weniger Aufwand betrieben wurde, wenn die bisher angefallenen Kosten auch geringer als geplant sind. Ein Fortschritt, der dem geplanten Fortschritt entspricht oder ihn gar übertrifft, könnte mit einer unvertretbaren Kostensteigerung erkauft worden sein. Das Verhältnis von Aufwand (hier in Kosten bemessen) und Ertrag (hier der Fortschrittsgrad als erreichtes Er- gebnis) interessieren die in der Praxis stehenden Projektmanager und – vielleicht noch mehr – die Stakeholder. Eine Methode, die Daten entsprechend auszuwerten und mit Indikatoren eindeutige Signale zu geben, ist die Earned-Value-Analyse, auch Kostenanalyse oder Fertig- stellungswertmethode genannt; in MS Project mit Ertragswertmethode übersetzt. Die Earned-Value-Analyse setzt die Größen Fortschrittsgrad laut Plan (so weit müssten wir theoretisch sein = Planwert), wirklicher Fortschritt (so viel haben wir bisher wirklich erreicht = Fertigstellungswert) und mit welchen Kosten (das haben wie bisher dafür auf- gewendet = Istkosten) in ein rechnerisches Verhältnis. Die Relationen dieser Werte zuein- ander werden durch berechnete Indikatoren signifikant angezeigt und sollen auf einen Blick erkennen lassen, wie sich die Leistung und die Kosten bisher entwickelt haben. Wei- terhin kann durch Prognosewerte errechnet und angezeigt werden, wie sich das Projekt oder der Vorgang entwickeln würde, wenn es aufgrund der bisherigen Daten so weitergin- ge wie bisher. Besonders für die Anhänger der Methoden des PMI spielt die Earned-Value-Analyse eine entscheidende Rolle bei der Projektüberwachung. Der PMBOK Guide (dritte Ausgabe von 2004)1 widmet sich in seinem 7. Kapitel „Kostenmanagement in Projekten“ ausführlich der 1 A Guide to the Project Management Body of Knowledge (PMBOK Guide), Herausgeber: Project Man- agement Institute, Inc., Newton Square, Pennsylvania, 3. Ausgabe, USA 2004 447 9 Earned-Value-Analyse (Ertragswertmethode) Steuerung der Kosten und stellt dieses Verfahren, dort als „Fertigstellungsmethode“ über- setzt, ausführlich dar (dort S. 171 ff.). Leider ist die Verwendung der Begriffe in verschiedenen Werken zur Earned-Value- Analyse (in Zukunft als EVA abgekürzt) ebenso uneinheitlich wie die Bezeichnung für das Verfahren selbst. Auch der PMBOK Guide wechselte die Begriffe in seinen jeweiligen Auflagen. Insgesamt ist das Bemühen zu erkennen, von den doch schwierigen und ange- staubten traditionellen Begriffen der EVA wegzukommen zu denen der modernen Kosten- rechnung.2 Da ich hier die Anwendung der Earned-Value-Analyse in MS Project, Version 2007 (gibt allerdings keinen gravierenden Unterschied zur Version 2003 außer den modernisierten Begriffen), darstellen werde, die dort Ertragswertmethode genannt wird, verwende ich hier zunächst immer die Begriffe des Programms (unten als MSP = Microsoft Project ab- gekürzt). Zum besseren Verständnis (hierin bin ich mir allerdings nicht so sicher) versuche ich, auch jeweils die gebräuchlichen englischen Begriffe und die des PMBOK Guides da- zuzuschreiben, als Übersetzung sozusagen. Für die Leser, denen dann von den vielen Be- griffen und Varianten schwindelig wird, hier eine kurze Tabelle, die versucht, die Begriffe zu sortieren: Deutsch Deutsch Deutsch P Englisch Englisch Englisch traditionell MSP MBOK traditionell MSP PMBOK SKBA = GW = PV = BCWS = PV = PV= Sollkosten der Geplanter Geplanter Wert Budget Cost Planned Planned berechneten Wert of Work Sched- Value Value Arbeit uled SKAA = EW = EV = BCWP = EV = EV = Sollkosten der Ertragswert Fertigstellungs- Budget Cost Earned Value Earned abgeschlossenen wert of Work Value Arbeit Performed IKAA = IK (IKAA) = AC = ACWP = AC = AC = Istkosten der Istkosten Aktuelle Actual Cost ACWP Actual Cost abgeschlossenen Kosten; of Work Arbeit Istkosten Performed Lassen Sie sich also von den Begriffen nicht verwirren. Die Earned-Value-Analyse ist eine Auswertung zu einem bestimmten Stichtag während der Laufzeit eines Vorganges oder eines Projektes. Der Schlüsselbegriff des Earned Values bringt zum Ausdruck, dass man den wirklich realisierten Fortschritt (= erreichten Wert) zu einem bestimmten Zeitpunkt feststellt und in Βeziehung setzt sowohl zu dem Fortschritt, wie er laut Plan rechnerisch hätte erreicht sein sollen, und den bis dahin angefallenen Kosten. 2 Noch traditionell (und ausführlich), aber mit Hinweis auf die Änderung der Terminologie: Harold Kerz- ner: Projektmanagement. Bonn 2003, Kapitel 15, „Kostenkontrolle“ (Hinweis auf die geänderten Begrif- fe: S. 517) 448 9.1 Die Grundlagen Zu jedem Stichtag während der Laufzeit eines Projektes lässt sich berechnen, wie viel Fortschritt bei einem Vorgang oder für eine Projektphase oder das ganze Projekt man theo- retisch hätte erreichen müssen; das ist der Geplante Wert (= GW). Kurz, aber nicht falsch: So weit müsste man theoretisch sein! Wenn also z. B. der Stichtag genau in der Mitte der Laufzeit eines Vorganges liegt, müssten wir 50% erledigt haben. Da die Earned-Value- Analyse ihre Daten immer in Kosten rechnet, wären für diesen Vorgang bis zu diesem Stichtag rechnerisch 50% der geplanten Kosten (Plankosten = PK) angefallen. Also der Geplante Wert ist der Prozentsatz der geplanten gesamten Kosten, welcher der hinter uns liegenden Dauer bis zum Stichtag in Prozent der gesamten Vorgangslaufzeit entspricht. (Traditionell wird das mit SKBA = Sollkosten der berechneten Arbeit bzw. BCWS = Bud- get Cost of Work Scheduled bezeichnet.) Der wirklich erreichte Fortschritt zu diesem Zeitpunkt wird ja selten genau der Wert sein, wie er zu diesem Zeitpunkt geplant war. Das wäre ja der ideale Verlauf. Der wirkliche Fortschritt muss gemessen und in das Tool eingegeben werden. Der zu diesem Zeitpunkt wirklich erreichte Fortschritt, in Kosten berechnet, stellt den erreichten Wert dar, das ist der Ertragswert = EW bzw. der Earned Value = EV. Kurz, aber nicht falsch: So viel ha- ben wir wirklich erreicht! Für die Kostenanalyse müssen alle Werte in Kosten dargestellt werden, schon wegen der Kompatibilität der Größen. (Traditionell wird das mit SKAA = Sollkosten der abgeschlossenen Arbeit bzw. BCWP = Budget Cost of Work Performed be- zeichnet.) Der Ertragswert stellt das dar, was man als Fortschritt misst, hier in MS Project in den Feldern % Abgeschlossen oder Physisch % Abgeschlossen erfasst. Da in es früheren Versionen nur das Feld % Abgeschlossen gab und z.B. Rückmeldungen der Ressourcen (auch die Rückmeldungen über den Web Access des Project Servers, siehe Band 2) in die- ses Feld eingehen, ist dies die wahrscheinlich am meisten verwendete Art der Fortschritts- erfassung. Aber Achtung, das Feld % Abgeschlossen stellt in MS Project rein den Fort- schritt in der Zeit, der Dauer, dar: das prozentuale Verhältnis der Aktuellen (hinter uns lie- genden) Dauer zur gesamten Dauer (ausführlich siehe Kapitel 8, Abschnitt „Arbeit über- wachen“). Es ist offensichtlich, dass das nicht unbedingt dem sachlichen, dem wirklichen Fortschritt entspricht. Deshalb gibt es seit der Version 2003 in Project das Feld Physisch % Abgeschlossen, in das man den sachlichen Fortschritt eintragen kann bzw. muss, da es nicht berechnet wird. Je nach der Art der Fortschrittsmessung kann man in Project die Be- rechnungsart der Ertragswertmethode auf eines der beiden Felder des Fortschrittsgrades einstellen. (Die Einstellungen und die daraus folgenden Unterschiede werden dargestellt in Abschnitt 9.5, Abschnitt „Earned Value mit Physisch % abgeschlossen“ dargestellt). Die Voreinstellung für die Berechnung des Ertragswertes EW ist das Feld % Abgeschlossen. Nun hat man den bisher realisierten Wert, den Ertragswert, aber mit wie viel Aufwand, mit wie viel Kosten, hat man das erreicht? Aus dem bisherigen Aufwand (Arbeitskosten, Mate- rialkosten, feste Kosten) kann man die Istkosten errechnen, und das sind die IK = IKAA = Istkosten der abgeschlossenen Arbeit.