Earned Value Analyse mit Microsoft Project (3)

10. August 2009 | Von hdj | Kategorie: Methoden, Schwerpunkt

In den ersten beiden Artikeln dieser Serie zur Earned Value Analyse (EVA) mit Microsoft Project habe ich gezeigt, wie mit Hilfe von benutzerdefinierten Feldern die Berechnung des Planned Value (PV) und Earned Value (EV) nach unterschiedlichen Methoden des Fertigstellungsstatus (z.B. 0/100-Methode) erfolgen kann. Mit diesen beiden Werten lässt sich die erste Kennzahl - der Schedule Performance Index (SPI = EV / PV)) - berechnen, der ein Maß für die terminliche Abweichung des aktuellen Projektstatus gegenüber dem Basisplan liefert. In diesem dritten Teil möchte ich einige Besonderheiten diskutieren, die bei der Ermittlung der Actual Cost (AC) - der Ist-Kosten - zu beachten sind, die in die zweite Kennzahl dem Cost Performance Index (CPI = EV / AC) eingeht und die besagt, in welchem Maße meine Kosten von der Planung abweichen. Verglichen werden hierbei die Ist-Kosten mit den geplanten Kosten der bisher erreichten Leistung (Earned Value), nicht das bis zu diesem Zeitpunkt verplante Budget.

Die tatsächlichen Kosten eines Projektes festzuhalten, klingt erst einmal nach einer einfachen Fleißarbeit; nicht einfach dagegen ist die Abgrenzung der Kosten zu einem bestimmten Statusdatum - und das vielleicht jede Woche aufs Neue. Die Kosten einfach aus dem Finanzsystem zu ziehen, ist richtig und sinnvoll zum Abschluss eines Projektes. Leider erfolgt die Verbuchung von Rechnungen aber nie synchron zum Projektfortschritt. Selbst wenn ein externer Berater umgehend zum Monatsende seine Rechnung schickt, dauert es - wenn die Prozesse sehr schnell sind -, zwei Wochen bis die Kosten in der Fibu auftauchen. Bis dahin liegt aber jeder Statusbericht schon lange bei den Leitungsgremien.

Eine gut funktionierende Zeiterfassung ist für die Rückmeldung der Aufwände nach meiner Erfahrung eine notwendige Voraussetzung, um Earned Value Analysen zeitnah machen zu können (und wenn die Auswertung zu spät kommt, braucht sie eh niemand mehr). In den Vorüberlegungen zur EVA muss ich mir gut überlegen, welche Kosten ich in die Ermittlung des CPI einbeziehe und mit welcher Häufigkeit der Status bestimmt werden soll. Ich plädiere für differenzierte Lösungen, die mir einerseits aktuelle Daten in kurzen Zeitabständen liefern, andererseits aber korrekte Daten zu bestimmten Berichtszyklen oder auch Meilensteinen.

Wenn ich eine zeitnahe Rückmeldungen der Ist-Aufwände habe, fallen die Ist-Kosten aber kontinuierlich an, während der EV erst nach Abschluss der Aktivität zu 100% gutgeschrieben wird (s. Diskussion im Teil 2 dieser Serie). Damit ergibt sich eine systematische Abweichung zwischen EV und AC, die zu Diskussionen führt, da die AC tendenziell größer sind als der EV. Diese Ungenauigkeit wird verkraftbar, wenn die Dauer der Aktivitäten nicht zu lang ist (5 - 10 Arbeitstage) und das Projekt in eine ausreichende Anzahl von Aktivitäten strukturiert ist.

Um diese Abweichung zu umgehen, habe ich auch schon Konzepte umgesetzt, die für die Berechnung des CPI nur Aktivitäten einbeziehen, welche abgeschlossen sind. Am besten definiert man in diesem Fall einen Status „rechnerisch abgeschlossen” - ein benutzerdefiniertes Attribut -, das manuell gesetzt wird, wenn alle Kosten für diese Aktivitäten sicher erfasst sind. Ein wenig verkompliziert solch ein Verfahren die EVA, da ein eigener EV für die Berechnung des CPI definiert werden muss, unterbindet aber alle Diskussionen um Unschärfen in der Methode.

In Microsoft Project übernehmen die Felder Aktuelle Arbeit bzw. Aktuelle Kosten die Rolle der Ist-Werte. Will man die Daten direkt im Projektplan erfassen, müssen sie für jede Zuordnung in jedem Vorgang eingegeben werden. Dies kann in der Ansicht Vorgang Einsatz oder auch Ressource Einsatz für die Periode Woche oder sogar Tag gemacht werden. Allerdings muss man hierbei sorgfältig achtgeben, dass die Vorgangsart auf Feste Dauer festgelegt ist. Ansonsten fängt Microsoft Project an, sämtliche Endtermine (und verknüpften Termine) zu ändern, denn die Verbleibende Arbeit wird auf den Rest der Aktivität verteilt und bei der Vorgangsart Feste Arbeit oder Feste Einheit führt dies unweigerlich zur Änderung des Endtermins. Dieses Vorgehen erfordert nicht nur die Rückmeldung auf der Basis von Aktivitäten durch die Mitarbeiter, sondern verursacht auch viel Aufwand und braucht viel Umsicht bei der Pflege des Projektplans. Nur mit der Project Server Lösung und der dort implementierten Rückmeldung über die Arbeitszeittabellen halte ich diesen Weg für gangbar, aber eine Erfassung der Aufwände je Vorgang erfordert einen sorgfältig strukturierten Projektplan, sollen die Mitarbeiter bei dem Ausfüllen ihrer Zeitmeldung nicht verzweifeln. Der Vorteil ist, dass die aktuellen Kosten dann aus dem Projektplan genommen werden können und alle in Microsoft Project definierten Kennzahlen zur Kostenabweichung sinnvoll sind.

In meinen Projekten habe ich immer eine Zeiterfassung bevorzugt, bei der die Rückmeldeebene an die Situation angepasst definiert wurde. Noch habe ich kein Projekt kennengelernt, bei dem ein Vergleich von Plan und Ist in der Ebene von Detail-Aktivitäten gemacht wurde. Das Management interessierte sich nur für Abweichungen auf der Ebene Projekt und der Projektleiter war mit dem Vergleich auf der Ebene der Arbeitspakete zufrieden. Eine Rückmeldung nur auf der Ebene Projekt ist im Standard der Project Server Lösung bereits vorgesehen. Damit lassen sich einfache Auswertungen ohne eigene Programmierung konfigurieren.

Bei der von mir favorisierten Lösung werden Ist-Aufwände und Ist-Kosten nicht direkt im Projektplan fortgeschrieben, sondern in eigenen Datenstrukturen gehalten. Die Aktuelle Arbeit und Aktuellen Kosten im Projektplan ergeben sich nur aus dem Fertigstellungsgrad der Aktivitäten und entsprechen am ehestem dem Earned Value, nicht den tatsächlichen Kosten. Bei diesen Verfahren müssen sowohl im Projektplan als auch in den Rückmeldungen die Kontierungsebenen eindeutig abgebildet werden. Meist nutze ich dazu die Arbeitspakete und ordne jeden Vorgang (mit einem benutzerdefinierten Textfeld) genau einem Arbeitspaket zu. In den Rückmeldeformularen werden die gleichen Arbeitspakte abgelegt, auf die die Teammitglieder ihre Rückmeldungen buchen können. Ein paar Makros helfen dabei, dieses System bei geringem manuellen Aufwand konsistent zu halten.

Für die Berechnung des CPI kopiere ich den EV aus dem Projektplan in eine Excel-Tabelle und ebenso die Ist-Kosten aus der Zeit- und Kostenerfassung. Die Berechnung der Kennzahlen wie SPI, CPI und andere ist dann einfach in Excel zu erledigen und auch die Darstellung in aussagekräftigen Grafiken.

eva-3_2

In der Excel Tabelle lässt sich auch die Entwicklung der Kennzahlen über die Zeitachse darstellen, denn in Project selber können immer nur die Werte zum aktuellen Statusdatum abgelesen werden. Hier bietet Excel eine einfache und sinnvolle Ergänzung. Der Aufwand, die Daten in Excel zu übernehmen, ist nur gering, 15 Minuten zur Übernahme der aktuellen Daten in eine vorbereitete Tabelle reichen allemal. Der Aufwand aktuelle Daten in ausreichender Qualität zu bekommen, übersteigt die Zeit zur Erstellung einer repräsentativen Darstellung um ein Vielfaches.

Mein Fazit:

Mit dem Einsatz von benutzerdefinierten Feldern lassen sich mit Microsoft Project Earned Value und Planned Value einfach und zuverlässig entsprechend der gewünschten Methode der Fertigstellung (0/100-Methode) ermitteln. Der Aufwand hierzu ist - einen strukturierten Projektplan mit Ressourcen- und Kostenplanung vorausgesetzt - nur sehr gering. Grenzen hat Project meiner Meinung nach bei der Erfassung der Ist-Aufwände und Ist-Kosten. Hier machen sich die Algorithmen, die über die Restarbeit das Ende der Vorgänge terminieren, unangenehm bemerkbar, so sinnvoll sie in anderen Situationen sein mögen. Aber bei der Abschätzung von Fertigstellungsterminen sehe ich den Einsatz des Projektleiters und des Teams viel mehr gefragt als ein Programm. Mit einer parallelen Ist-Erfassung kann man sich hier sehr gut helfen.

Earned Value Management ist dann hilfreich, wenn ich die grundlegenden Ideen nutze und meinen Projektplan sauber strukturiere und auf die Lieferung meiner Projektobjekte ausrichte. Nicht die Kennzahl ist eigentlich wichtig - sie ist nur ein Indikator, genauer hinzuschauen -, sondern ein gutes Projektmanagement.

Tags: , , ,

Schreiben Sie einen Kommentar

Comment Spam Protection by WP-SpamFree