Hat jemand etwas ähnliches beobachtet oder weiß gar Abhilfe?

Wenn Abwesenheiten in den Ressourcenkalendern gepflegt werden, erhält man eine gute Übersicht über die Verfügbarkeit der Ressourcen; sind die Ressourcen zudem Teams oder Skills zugeordnet, auch über diese Gruppen (Gruppieren in einer Ressourcenansicht). Zum anderen wird aber der Ressourcenkalender auch zur Terminierung von Vorgängen verwendet, wenn die Ressource einem Vorgang zugeordnet wird. Ist innerhalb der Laufzeit des Vorgangs die Ressource an einem Tag nicht verfügbar, wird die Laufzeit um einen Tag verlängert und der Endtermin verschoben. Sind dem Vorgang noch andere Ressourcen zugeordnet, wird aber nur für die Ressource mit der Abwesenheit der Einsatz um einen Tag verlängert, für die anderen Ressourcen ändert sich die Einsatzdauer nicht. Das Enddatum des Vorgangs wird verschoben, da alle Ressourcen ihre Arbeit erledigt haben müssen, bevor der Vorgang endet. In diesem Falle bekommt man die Situation, dass der Einsatz der Ressourcen in einem Vorgang unterschiedlich endet und abhängige nachfolgende Vorgänge verschoben werden.

Solche Situationen helfen nicht, die Übersichtlichkeit des Projektplanes zu wahren. Ein typischer Fall für „Project hat mir alle Termine durcheinander gewirbelt”! Abhilfe muss hier entweder manuell geschaffen werden, indem die Arbeit in dem Vorgang geändert wird (viel Aufwand), oder man kann für den Vorgang die Terminierung über den Ressourcenkalender abschalten. (Informationen zum Vorgang: Reiter Spezial, Kalender auswählen und Option „Terminplanung ignoriert Ressourcenkalender” aktivieren) Leider wird bei dieser Option die Arbeit von Ressourcen, die in dem Zeitraum des Vorgangs nicht verfügbar sind (aber zugeteilt) in der Ansicht „Ressource Grafik” nicht als Überlastung angezeigt. Ein kleiner Mangel, mit dem man leben kann, ist die Überlastung doch deutlich erkennbar. (Es muss in der Grafik natürlich die Option „Verfügbarkeitslinie anzeigen” aktiviert sein.)

Ist geplant, die Abwesenheit einer Ressource über den Ressourcenkalender zu pflegen, sollte man tunlichst jeder Ressource ihre eigenen Aufgaben sprich Vorgänge geben, oder anders ausgedrückt, sollte jedem Vorgang nur eine Ressource zugeordnet sein. Dieses Vorgehen schafft nicht nur Klarheit und Transparenz in der Planung, es ermöglicht auch die Auswirkungen von Abwesenheit einfacher nachzuvollziehen und notwendige Maßnahmen zu planen. Ist es notwendig, einem Vorgang mehrere Ressourcen zuzuordnen (z.B. gemeinsame Trainings), sollte für diesen Vorgang die Ressourcenterminierung abgeschaltet werden. Ähnliche Überlegungen gelten für lang dauernde, administrative Vorgänge im Projektplan, da eine Abwesenheit der Ressource automatisch die Dauer verlängert und diese Vorgänge dann plötzlich den Endtermin des Projektes bestimmen. Wer also nicht umgehend die Arbeit oder den Endtermin anpassen möchte, kann diese Option nutzen.

Allerdings kenne ich auch viele Projekte, in denen es nicht sinnvoll ist, für jede Ressource eigene Vorgänge zu erstellen. Diese Situation tritt ein, wenn ein Team mit gleichen Qualifikation (z.B. Entwickler oder Tester) eine Vielzahl kleiner und kleinster Aufgaben zu bearbeiten hat. Wie kann ich Abwesenheit also abbilden, wenn es nicht sinnvoll ist (oder es mir zu aufwändig ist), jede einzelne Aufgabe im Projektplan abzubilden und ich mehrere Ressourcen pro Vorgang plane? Bewährt hat sich bei Verwendung eines Ressourcenpools (Datei basiert oder in einer Project Server Umgebung ) Abwesenheitszeiten in einem eigenen Abwesenheitsprojekt zu pflegen. Für die Zeit der Abwesenheit wird ein Vorgang eingetragen, dem die Ressource zu 100% zugeordnet wird. Die Abwesenheit wird als Arbeit angezeigt, Überlastungen durch Abwesenheit lassen sich einfach erkennen und manuell beheben, ohne dass Termine automatisch verschoben werden. Meist unternimmt man bei einem Tag Abwesenheit nichts, da solche kleinen Abweichungen innerhalb des Teams ohne Planung ausgeglichen werden. Wer die Funktion „Kapazitätsabgleich” anwenden will, sollte Vorgänge für Abwesenheit mit der Priorität 1000 versehen, damit diese Vorgänge nicht mit abgeglichen werden.

Beim Einsatz von Project Server 2007 braucht noch nicht einmal ein eigenes Abwesenheitsprojekt angelegt und gepflegt zu werden, da dort Abwesenheitszeiten definiert sind und vom Mitarbeiter selbst als „Administrative Zeiten” eingegeben werden können. Voraussetzung hierfür ist die Benutzung des nur auf dem Server verfügbaren Features “Arbeitszeittabelle”. Vor- und Nachteile dieser Möglichkeiten werde ich in einem folgenden Beitrag diskutieren.

Eine Eigenheit von Microsoft Project sei noch erwähnt, wenn Abwesenheit im Ressourcenkalender gepflegt wird und Vorgänge „feste Dauer” haben. Project bildet die Abwesenheit intern wie eine Unterbrechung ab, was zur Folge hat, dass diese Unterbrechung bestehen bleibt, wenn die Abwesenheit wieder rückgängig gemacht wird. Helfen kann man sich hier, indem die Vorgangsart vor der Änderung des Ressourcenkalenders auf „feste Arbeit” gesetzt wird. Dann sind Änderungen des Ressourcenkalenders reversibel. Ein kleines Makro kann hier helfen, die Vorgangsart im Projekt auf „feste Arbeit” zu setzten. Nur darf man halt nicht vergessen, dieses vor der Pflege der Kalender zu zu starten.

Bei all diesen kleinen „Fallstricken” halte ich es immer noch für die beste Lösung, Urlaub und Abwesenheiten als Arbeit in einem eigenen Abwesenheitsprojekt zu pflegen. Damit bleibt die Entscheidung, welche Konsequenzen im Konfliktfall gezogen werden sollen, allein beim Projektmanager. Einen Vorteil hat ein eigenes Abwesenheitsprojekt auch noch: Mit ein bisschen Geschick beim Formatieren und strukturieren des Projektes (ein Sammelvorgang je Ressource) kann man einen schönen Balkenplan mit der Abwesenheit aller Mitarbeiter ausdrucken und an die Wand hängen.

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.

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.

Im zweiten Teil geht es darum, wie man eben dieses Feld mit Hilfe einer eingebetteten Excel-Tabelle für eine detaillierte Materialkosten-Kalkulation nutzbar machen kann, und um die Frage, wann und warum besser Material- oder Kostenressourcen verwendet werden sollten.

Die Personalkosten in einem geplanten Projekt werden von Project auf der Basis von Kostensatztabellen automatisch berechnet. Wie aber finden andere Kostenarten - fix oder pro Zeiteinheit - Eingang in die Kalkulation? Project 2003 bietet hierfür „Materialressourcen” an, die flexibel zugeordnet werden können und sich - wie wir noch sehen werden - auch für ganz andere Dinge als „Material” verwenden lassen; Project 2007 darüber hinaus Kosten- und Budgetressourcen.

Wodurch unterscheiden sich Materialressourcen von solchen des Typs „Arbeit”? Es sind drei Merkmale, die eine Materialressource kennzeichnen. Materialressourcen

• sind zeitlich unbegrenzt verfügbar, d. h., sie haben keinen Kalender
• sind hinsichtlich der verfügbaren Kapazität unbegrenzt, d. h., es gibt keine maximalen Einheiten
• können sowohl fix als auch pro Zeiteinheit zugeordnet werden

Vielleicht haben Sie schon bemerkt, daß diese Besonderheiten recht wenig mit dem zu tun haben, was einem bei dem Begriff „Material” einfällt. Und in der Tat können schon bei Project 2003 Materialressourcen zur Planung von ganz verschiedenen Kostenarten - etwa Reisekosten - benutzt werden.

Wenn man in den aktuellen Versionen von Project Materialkosten auf diese Weise darstellen kann, warum sollte man dann überhaupt noch mit dem Feld Feste Kosten arbeiten? Das hängt davon ab, in welchem Detaillierungsgrad Sie die Kosten planen und dokumentieren wollen. Sie können eine Materialressource „Farbe und Malermaterial” definieren, aber wenn Sie jede Art von Malerbedarf, jeden Farbeimer und jeden Pinsel als eigene Ressource anlegen wollen, wird Ihre Ressourcenplanung zu einem Alptraum werden.

In diesem Fall ist es sinnvoller, die Kalkulation einem Programm zu überlassen, das dafür geschaffen ist - Microsoft Excel -, und einfach das Resultat der Berechnungen an das Feld Feste Kosten zu übergeben. Die schon etwas betagte, aber nach wie vor nützliche Technik hierfür heißt OLE: Object Linking and Embedding. Keine Angst vor Akronymen - hier wird natürlich nicht nur erklärt, was es heißt, sondern auch, wie es geht. Ich beschreibe hier nur den Fall eines eingebetteten Excel-Objekts, es funktioniert aber auch mit einer als Datei gespeicherten Excel-Tabelle.

Zuvor möchte ich jedoch wenigstens auf zwei Probleme bzw. Schwächen dieser Lösung hinweisen. Verglichen mit der Planung von Materialressourcen

• bläht die Verwendung von eingebetteten OLE-Objekten die Datei auf
• ist die Detaillierung nur auf der Ebene des jeweiligen Vorgangs sichtbar (in den Einsatzansichten sind es nur wieder „Feste Kosten”)

Bleiben wir bei unserem Beispiel der Malerarbeiten. Die detaillierte Kalkulation der Materialkosten ist Ihnen wichtig. Erstellen Sie also für den betreffenden Vorgang eine eingebettete Excel-Tabelle und verknüpfen Sie die Summe mit dem Feld „Feste Kosten”.

• Wählen Sie in Project eine Vorgangsansicht und lassen Sie die Tabelle „Kosten” anzeigen
• Teilen Sie die Ansicht, so daß im unteren Bildschirmauschnitt die Ansicht „Vorgang: Maske” angezeigt wird.
• Klicken Sie in dem grauen Bereich des unteren Ausschnitts mit der rechten Maustaste und wählen Sie als Detailansicht OBJEKTE. Achten Sie darauf, daß dieser Ausschnitt aktiv ist!
• Führen Sie den Menübefehl EINFÜGEN / OBJEKT aus und wählen Sie in der Liste der Objekte „Microsoft Excel Arbeitsblatt” aus. Klicken Sie auf OK.
• Sie können nun in dem Arbeitsblatt wie gewohnt Texte, Zahlen und Formeln eingeben. Wenn das Excel-Objekt aktiv ist, sind die Menüs und Symbolleisten die von Microsoft Excel.
• Erstellen Sie die Tabelle und summieren Sie an beliebiger Stelle die Materialkosten.
• Markieren Sie die Zelle mit der Summe und kopieren Sie sie in die Zwischenablage.
• Markieren Sie nun in der Vorgangstabelle das Feld Feste Kosten für den betreffenden Vorgang.
• Führen Sie den Menübefehl BEARBEITEN / INHALTE EINFÜGEN aus, wählen Sie VERKNÜPFUNG EINFÜGEN und unter „Als” TEXTDATEN
• Die Fixkosten sind nun verknüpft mit der Summenzelle der eingebetteten Excel-Tabelle. Sobald Sie in der Tabelle Preise oder Stückzahlen ändern, werden die Fixkosten neu berechnet. Die Excel-Tabelle wird im Projektplan gespeichert und kann nur als Objekt in dem entsprechenden Vorgang bearbeitet werden.

Diese Vorgehensweise funktioniert auch mit längst verblichenen Versionen von Project und natürlich auch mit einer im Dateisystem gespeicherten (also nicht nur eingebetteten) Excel-Tabelle. Falls die Aktualisierung der Veknüfpfung einmal nicht automatisch erfolgt, können Sie sie mit dem Befehl BEARBEITEN / VERKNÜPFUNGEN / JETZT AKTUALISIEREN anstoßen.

Sie sollten Material- oder Kostenressourcen benutzen, wenn Sie

• vorwiegend Kostenklassen darstellen wollen
• Kosten detailliert in den Einsatzansichten darstellen und auswerten wollen

Sie sollten verknüpfte Excel-Tabellen verwenden, wenn es Ihnen darum geht,

• komplexe Kostenberechnungen durchzuführen
• bereits vorhandene Kalkulationsergebnisse zu übernehmen
• für einzelne Vorgänge (das können auch Sammelvorgänge sein!) sehr detaillerte Fixkosten zu planen

In der nächsten Folge geht es um Kostensatztabellen und die Berechnung von Selbstkosten bzw. fakturierbaren Kosten.

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

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.

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.

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.

Was jedoch kaum einer weiß ist, daß Microsoft Project weitaus mehr als diese 120 Icons zu bieten hat. Allerdings können diese nicht interaktiv, sondern nur per VBA verwendet werden. Nicht weniger als 544 Symbole stehen zur Verfügung - aber wie sehen sie aus?

Zugewiesen werden sie in einem Makro über ihre FaceId. Was liegt also näher, als ein Makro zu schreiben, daß alle Icons in einer eigenen Symbolleiste anzeigt? Anschließend können Sie die betreffende ID bequem als Tooltip anzeigen lassen, indem Sie die Maus auf das Symbol positionieren, um dann die ID in Ihrem eigenen Code zu verwenden.

So geht es:

Sub CreateCommandBarIcons()
‘ Eine Symbolleiste mit allen verfügbaren Icons erstellen
Dim cb As CommandBar
Dim ct As CommandBarControl

Set cb = CommandBars.Add(”Symbolleistenschaltflächen”)
cb.Visible = True

For i = 1 To 544
Set ct = cb.Controls.Add(msoControlButton)
With ct
.TooltipText = Str(i)
.FaceId = i
End With
Next i

End Sub

Und so sieht es aus:

Argumente und Aussagen, die EVA sei sehr aufwändig, stammen nach meiner Erfahrung aus dem Umstand, dass meist zu wenig Aufwand in die Planung der Projekte gesteckt wird und die Möglichkeiten von Project, die es hier bietet, nicht ausreichend genutzt werden. Eine unabdingbare Voraussetzung für die EVA ist eine Ressourcen- und Kostenplanung in Project (siehe hierzu die Beiträge von Gerd Rupprecht in diesem Blog), und ich habe schon viele Projekte gesehen, die noch nicht einmal für die Ressourcenplanung die Möglichkeiten von des Programms nutzen.

Kurz rekapituliert die wichtigsten Begriffe der EVA und die entsprechenden Felder in Project:

Aus diesen Werten lassen sich alle anderen Werte der EVA und die Key-Indikatoren berechnen:

Für beide Kennzahlen gilt: ein Wert größer 1 bedeutet, das Projekt ist besser als die Planung, (also schneller als der Terminplan und/oder mit günstigeren Kosten), ein Wert kleiner 1 heißt, die Performance des Projekte hinkt der Planung hinterher.

Der erste Punkt, der zu diskutieren ist, ist die Art- und Weise, wie in Project der Basisplan gespeichert wird, und die Konsequenzen, die sich aus Änderungen des Projektplanes nach dem Speichern des Basisplans ergeben. Ich meine hier nicht Änderungen durch Aktualisierung des Planes, sondern Änderungen durch Change Requests (CR) oder durch die weitere Detaillierung von Vorgängen, die zu Beginn des Projektes noch weit in der Zukunft lagen und nur grob geplant waren. Beide Änderungen müssen Teil des Basisplans werden, um die EV-Methode konsequent anwenden zu können.

Project speichert einen Basisplan in jedem einzelnen Vorgang, auch Sammelvorgang und Projektsammelvorgang. Die Berechnung der EV-Werte erfolgt in Project daher auf jedem einzelnen Vorgang, unabhängig davon, was in untergeordneten Vorgängen passiert. Das hat den Vorteil, dass eine detaillierte Vergleichsanalyse zum Basisplan auf allen Ebenen möglich ist und verschiedenste Termin- und Kostenabweichungen sichtbar werden. Sinnvoller Weise nutzt man für die EVA nur den Projektsammelvorgang und Sammelvorgänge der ersten Stufe.

Müssen jetzt neue Vorgänge ergänzt werden (durch einen CR z. B.), muss dieser in die EVA integriert werden. Es verbietet sich, einen kompletten Basisplan neu zu speichern, da alle bisherigen Abweichungen dann egalisiert wären. Project bietet die Möglichkeit, einen Basisplan nur für selektierte Vorgänge zu speichern, aber wenn der Basisplan nur für die Vorgänge gespeichert wird, werden die Basispläne der darüber liegenden Sammelvorgänge nicht geändert, und damit werden die Änderungen bei der EVA nicht berücksichtigt. Es gibt noch die Möglichkeiten, beim selektiven Speichern Optionen für das Rollup des Basisplans auszuwählen, aber bei beiden Optionen werden die aktuellen Anfangs- und Endtermine in die darüber liegenden Sammelvorgänge hochgezogen, und Abweichungen der Anfangs- und Endtermine gegenüber der ursprünglichen Planung gehen damit verloren.

Daher habe ich diese Optionen nie aktiviert, obwohl die EVA von Project weiterhin vernünftige Ergebnisse liefert.

Aber es gibt noch weitere Punkte in der EVA, die diskutiert werden müssen.

Alle hier vorgeschlagenen Lösungen basieren auf der Nutzung von benutzerdefinierten Kostenfeldern für den PV und EV. Wie das genau geht, wird im 2. und 3. Teil dargestellt.

Eines seiner Hauptinteressen gilt dem Earned Value Management, das er in vielen Projekten eingesetzt hat und von dessen Nutzen er sich überzeugen konnte. Passend zu unserem derzeitigen Schwerpunktthema Kostenplanung und -controlling liefert Hartmut de Jong in einer dreiteiligen Serie das nötige Hintergrundwissen, um diese Methode auch in Microsoft Project systematisch und zuverlässig anwenden zu können.

Der erste Teil behandelt die Rolle des Basisplans (und seiner Tücken) für die Umsetzung der EVA in Project.

Renke Holert beschreibt in seinem Allocatus-Blog derlei Hindernisse bei der täglichen Arbeit mit Project und auch, wie man sie los. wird Hier geht’s direkt zum Artikel.

Gleich, ob Sie evaluieren wollen, ob diese Lösung in Ihr Unternehmen und Ihre “Planungslandschaft” paßt, oder ob Sie sich bereits für die Einführung von EPM entschieden haben - eine blauäugige Installation des Servers und der erforderlichen Basiskomponenten (Sharepoint, SQL Analysis Services etc.) führt nach meiner Erfahrung meist nicht zu dem gewünschten Ergebnis und läuft auf eine zeitraubende und kostspielige Neuinstallation hinaus.

Die Standardkonfiguration des Project Servers ist durchaus praxistauglich und sollte als Basis für eine Evaluierung dienen. Auf mittlere Sicht sind jedoch unternehmensspezifische Anpassungen unumgänglich. Die Verwaltung des Servers erfordert neben guten Windows- und SQL Server-Administrationskenntnissen auch ein gerüttet Maß an Planungs-KnowHow und ein vertieftes Verständnis der EPM-Komponenten und ihres Zusammenspiels.

Das EPM Starterpaket unterstützt Sie bei der fachgerechten Installation und Konfiguration und schafft die Voraussetzungen für eine zügige Evaluierung bzw. Produktivsetzung des unternehmensweiten Projektmanagements mit Microsoft Project. Nach der erfolgreichen Inbetriebnahme stehe ich Ihnen selbstverständlich weiter für Beratung, Training und Customizing zur Verfügung.

Leistungen: Installation und Konfiguration des Servers , des Portfolio Analyzers und eines Project Professional Clients; Einweisung in die wichtigsten administrativen Aufgaben; gemeinsame Festlegung der Server- Grundeinstellungen; Anlegen eines Enterprise Resource Pools und des RSP-Codes; Kalendereinrichtung; Anpassung der Enterprise Global und Bereitstellung zusätzlicher Tabellen, Ansichten, Gruppierungen und Filter.

Dauer: 2 Tage

Preis: 2.500,00 € incl. Project Server / Office Project 2007 Evaluierungsversion, Reisekosten und Spesen, zzgl. ges. MwSt.

Im Preis nicht enthalten sind Hardware und Software-Lizenzen, die über das Evaluierungspaket hinausgehen.