Earned Value Analyse mit Microsoft Project (2)

13. Juli 2009 | Von hdj | Kategorie: Methoden, Neues

Im ersten Beitrag habe ich einige Besonderheiten bei der Speicherung des Basisplans und daraus resultierenden Folgen für die Berechnung von Planned- und Earned Value ausgeführt. In diesem Teil möchte ich darlegen, wie andere, wesentliche Eigenschaften des Earned Value-Managements (EVM) mit Microsoft Project abgebildet werden können.

Ein wesentlicher Erfolg des EVM beruht darauf, dass für den Earned Value (EV) nur Aktivitäten gut geschrieben werden, die auch wirklich fertig sind und damit der Druck auf die Fertigstellung erhöht wird. Damit wird es zum einen erforderlich, dass jede Aktivität ein nachprüfbares Ergebnis (Deliverable) hat, und zum anderen, dass dieses wirklich fertig ist und nicht doch noch Restarbeiten zu erledigen sind - zwei Bedingungen, die im Projektalltag häufig vernachlässigt werden. Im EVM wird daher bei der Pflege des Fertigstellungsgrades gerne die 0/100-Methode angewendet. Der EV einer Aktivität ist so lange 0 (0%), bis sie fertig gestellt ist, erst nach Fertigstellung beträgt er 100% der geplanten Kosten (Baseline Cost). Abwandlungen hiervon sind die 20/80 bzw. die 50/50-Methode: 20% (50%) der geplanten Kosten werden dem EV zugerechnet, wenn die Aktivität begonnen ist, die restlichen 80% (50%) kommen bei Fertigstellung hinzu. Die Berechnung des EV nach davon abweichenden Fertigstellungsgraden ist nur z. B. bei administrativen Vorgängen zulässig, die kein spezifisches terminiertes Ergebnis haben, aber für die Kapazitäts- und Kostenplanung in den Projektplan aufgenommen werden müssen und kontinuierlich gemäß Planung aktualisiert werden.

In Microsoft Project wird der EV entsprechend dem Fertigstellungsgrad der Aktivität berechnet. Durch die entsprechende Pflege der Fertigstellungsgrade (0% / 100% bzw. 20% / 100% oder auch 50% / 100%) können obige Regeln der Fertigstellung dargestellt werden, das schränkt aber das Reporting des Projektstatus (z. B. Abbildung von Restdauer / Restaufwand etc.) ein. Von verschiedenen Autoren wird vorgeschlagen, das Feld “%-Physisch abgeschlossen” für die EVA zu verwenden, was mittels der Ertragswert-Option einstellbar ist (EXTRAS / OPTIONEN / BERECHNEN).

Auswahl Ertragswertmethode

Damit ist aber ein zusätzlicher Status zu pflegen. Unabhängig davon wird der Planned Value aber immer berechnet, als wären alle Vorgänge bis zum Statusdatum genau in dem Fertigstellungsgrad, wie es der Plan ausweist (und wie es mit der Funktion auch „Aktualisieren wie berechnet” dargestellt wird). Damit würden PV und EV aber nach unterschiedlichen Methoden berechnet, was die Interpretation von Abweichung erheblich erschwert, denn auch eine Aktivität, die wie geplant bearbeitet wird, weist auf dem Weg bis zur Fertigstellung systematische Abweichungen zwischen PV und EV auf. Nach der 0/100 Methode z. B. ist der EV immer 0, bis die Aktivität abgeschlossen ist, der PV würde aber kontinuierlich wachsen. Um Abweichungen durch die Berechnung der Werte nach unterschiedlichen Methoden zu vermeiden, muss der PV auch so lange 0 bleiben, bis das geplante Ende erreicht ist. Erst dann darf er den 100% entsprechenden Wert bekommen.

Um dies zu erreichen, schlage ich 3 benutzerdefinierte Vorgangsfelder vor. Ein Textfeld, das die für diesen Vorgang angewandte Methode (0/100, 20/80 etc.) definiert, und 2 Kostenfelder, eines für den PV und eines für EV, in denen die Formeln zur Berechnung des PV und des EV hinterlegt werden. In den Kostenfeldern wird für die Sammelvorgänge das Rollup „Summierung” aktiviert.

Damit wird erreicht, dass PV und EV immer nur aus den untersten Aktivitäten berechnet und auf die oberen Ebenen kumuliert werden. Die Schwierigkeiten des Basisplan-Rollups für nachträglich erstellte Vorgänge in die Sammelvorgänge und den Projektsammelvorgang sind damit behoben. Sie brauchen nur noch den Basisplan selektiv für die neuen Vorgänge zu speichern, und schon werden sie in die EVA korrekt mit einbezogen.

Die Felder benenne ich EV-Methode mit einer Tabelle, die die zulässigen Methoden definiert, PV für den Planned Value und EV für den Earned Value

Kostenfeld PV

Switch([EV-Methode]=”none”;0;
[EV-Methode]=”as scheduled”;[SKBA];
[Geplanter Anfang]>[Statusdatum];0;
[Geplantes Ende]<=[Statusdatum];[Geplante Kosten];
[EV-Methode]=”0/100″;0;
[EV-Methode]=”20/80″;0,2*[Geplante Kosten];
[EV-Methode]=”50/50″;0,5*[Geplante Kosten];
True;0)

Kostenfeld EV

Switch([EV-Methode]=”none”;0;
[Aktuelles Ende]=[Ende];[Geplante Kosten];
[Aktueller Anfang]<>[Anfang];0;
[EV-Methode]=”as scheduled”;[SKAA];
[EV-Methode]=”0/100″;0;
[EV-Methode]=”20/80″;0,2*[Geplante Kosten];
[EV-Methode]=”50/50″;0,5*[Geplante Kosten];
True;0)

Die Switch-Funktion hat als Argumente eine Liste von Wertepaaren, bestehend aus je einem logischen Ausdruck und dem zugehörigen Wahr-Wert. Die Liste wird von links nach rechts bearbeitet. Sobald ein logischer Ausdruck “Wahr” ergibt, erhält das Feld den zughörigen Wert und die Bearbeitung wird beendet. Daher ist als letztes Wertepaar „True;0″ eingefügt, damit das Feld immer einen definierter Wert hat.

Die EV-Methode “none” habe ich eingeführt, um gezielt einzelne Vorgänge von der EV-Berechnung ausschließen zu können. Das kann hilfreich sein, wenn die zeitliche Zuordnung der Ist-Kosten nicht eindeutig ist (dazu mehr im 3. Teil). Die EV-Methode “as scheduled” benutzt die Berechnungsalgorithmen von Microsoft Project, wie sie für kontinuierliche Verwaltungsaufgaben, die keine konkret terminierten Ergebnisse haben, typisch und richtig ist. Diese Vorgänge aktualisiere ich im Projektplan auch immer mit der Funktion “Aktualisieren wie berechnet”.

Für alle anderen Methoden gilt für den Planned Value: wenn das Statusdatum nach dem geplanten Ende liegt, werden 100% der geplanten Kosten dem PV gutgeschrieben; wenn das geplante Startdatum nach dem Statusdatum liegt wird dem PV nichts gutgeschrieben. Die nächsten Wertepaare in der Switch-Funktion des PV werden also nur bearbeitet, wenn der Vorgang gemäß Basisplan begonnen sein müsste, aber noch nicht beendet sein soll. Hier sind nun die Werte für den PV, die in Arbeit sein sollten, entsprechend den unterschiedlichen Methoden modelliert. Analog ist die Berechnung des Earned Value aufgebaut. Nur vergleichen die Terminabfragen nicht geplante Termine mit dem Statusdatum, sondern testen, ob für “Aktueller Anfang” und “Aktuelles Ende” Werte gesetzt sind. Ist der aktuelle Anfang gesetzt, hat der Vorgang begonnen, unabhängig vom Fertigstellungsgrad, und ist das aktuelle Ende gesetzt, so ist der Vorgang abgeschlossen.

eva-2-02

Mit diesen beiden benutzerdefinierten Feldern werden PV und EV jetzt konsistent nach der gewählten Methode berechnet und Sie können einen SPI = EV/PV berechnen, der den terminlichen Status des Projektes wiedergibt und bei dem nicht über Effekte, die durch unterschiedliche Art der Berechnung von EV und PV entstehen, diskutiert werden muss. Die Berechnung des EV hat noch den Vorteil, dass abgeschlossene Vorgänge, die im Projektplan noch in der Zukunft liegen, vollständig zum EV beitragen, was bei der standardmäßigen Berechnung in Project nicht erfolgt. Dort wird der EV nur dann voll in die EV-Berechnung einbezogen, wenn der Vorgang auch vor dem Termin des Statusdatums endet.

Noch ein kleiner Zusatznutzen der eigenen EVA-Felder: gruppieren Sie die Vorgänge über das Feld EV-Methode, erhalten Sie eine Analyse ihrer Kostenstruktur nach den EV-Methoden. Sie sehen, welcher Anteil an den Gesamtkosten durch administrative Kosten entsteht und welche Kosten direkt für die Deliverables aufgewendet werden. Dazu ist keine eigene Kennzeichnung der Vorgänge mehr notwendig.

eva-2-03

Mit den hier vorgestellten Feldern haben wir die erste wichtige Kennzahl für unterschiedliche Methoden der EVA ermittelt. Wie meiner Meinung nach eine Lösung für die Ermittlung der aktuellen Kosten in Microsoft Project aussehen sollte, stelle ich im dritten Beitrag vor.

Tags: , ,

Schreiben Sie einen Kommentar

Comment Spam Protection by WP-SpamFree