Projectcontrolling, Earned Value Management

Kennen Sie in der Rolle des Projektmanagers die Problematik, dass es manchmal schwer fällt, den tatsächlichen Status zu reporten?
Kennen Sie die Situation, dass der Fertigstellungsstatus eines Arbeitspaketes die 50% relativ schnell erreicht und mit fortschreitendem Projektverlauf die Schritte immer kleiner werden? Dass häufig ab 70% sogar im einstelligen Bereich gepokert wird?
Fällt es Ihnen schwer die drei Bereiche Fortschritt des Projektumfanges, den Zeitplan und den Budgetplan in Einklang zu bringen?
Oder kennen Sie die Situation, dass der Projektsponsor Sie nach einer Prognose fragt und Sie mit einem unguten Gefühl eine Schätzung abgeben?

Dieser Artikel geht den genannten Problemen auf den Grund und zeigt mögliche Lösungsansätze auf. Hierzu wird ein Projektszenario skizziert. Es wird Schritt für Schritt abgearbeitet. Jeder Schritt wird erläutert, so dass ein Nacharbeiten möglich ist.

Konkret erinnere ich mich an ein Projekt mit vier Teilprojektleitern und einem Umfang von mehreren Jahren, indem mir eine Teilprojektleiterfunktion übertragen wurde. Jeder Teilprojektleiter hat für die Planung seines Teilprojektes ein anderes Werkzeugt benutzt.

In der Vergangenheit habe ich es häufig erlebt, dass Projektmanager Excel-Listen mit teils guten und teils weniger guten Ergebnissen verwandt haben. Ein generelles Problem bei Excel-Lösungen besteht darin, dass sich Abhängigkeiten der Aufgaben und Ressourcen nur sehr umständlich verwalten lassen. Ebenso lassen sich das Projekt und der Fortschritt grafisch schwierig abbilden. Um den Verwaltungsaufwand gering zu halten, ist es sinnvoll, die Komplexität zu reduzieren und mit einem gewissen Augenmaß das Projekt zu steuern. Der Trade-off, dass die Abhängigkeiten einerseits nur rudimentär abgebildet und die grafische Darstellungen andererseits auf einer groben Ebene abgebildet werden müssen, hat zur Folge, dass Auswirkungen von Entscheidungen häufig nicht sofort ersichtlich sind.

In diesem Projekt entschied ich mich dazu die Projektmanagementsoftware Microsoft einzusetzen. Nach dem Studium der Onlinehilfe und diverser Youtube Videos konnte ich recht schnell ein passables Ergebnis für die Planung erzielen. Wofür ich zu diesem Zeitpunkt noch keine Lösung hatte, war die Frage nach der Projektsteuerung. Aufgaben werden verschoben, dauern länger, fangen später an, Prioritäten ändern sich, etc.

Da das gesamte Projekt klassisch aufgebaut war, kam ein agiler und leichtgewichtiger Prozess (Scrum) von vornherein nicht in Frage. In dem Unternehmen konnte mir keine Person eine geeignete Hilfestellung anbieten. Weder die internen Kollegen noch die externen Berater. Mehrere Kollegen rieten mir, das Controlling des Teilprojektes nur grob durchzuführen. Ein Kollege sagte mir:, „Das ist alles viel zu umständlich und komplex. Wenn ich jede Aufgabe nachhalten würde, käme ich gar nicht zum Arbeiten.“

Ich entschied mich für die Methode, die ich häufig schon selbst angewandt und in anderen Projekten angetroffen habe, die Steuerung des Teilprojektes mit Excel und dem Bauch.

In der Zwischenzeit hatte die Gesamtprojektleitung den von mir angefertigten Plan adaptiert und um sämtliche im Projekt anfallende Aufgaben erweitert. Bereits nach den ersten zwei Wochen existierten in dem Unternehmen diverse unterschiedliche Planungen und Planungsstände. Die Realität wurde von keinem der Pläne abgebildet.

Die Statusmeetings mit der Geschäftsführung waren herausfordernd. Jeder Teilprojektleiter hatte ein anderes Reporting und seine eigene Strategie, die erzielten Erfolge der letzten Woche zu kommunizieren. Es gab keine einheitlichen Standards. Der Geschäftsleitung fiel es sichtlich schwer, die genannten Status in den wöchentlichen Meetings zu interpretieren. Im Nachhinein bewundere ich die Leidensfähigkeit der Geschäftsführung.

Das Projekt wurde trotz aller Widrigkeiten mit einer vertretbaren Verzögerung durchgeführt. Dieses Ziel wurde durch das sehr starke Engagement der Mitarbeiter, der Reduzierung des Projektumfangs, erheblichem finanziellen Mehraufwand und ein wenig Glück erreicht.

Die spannende Frage ist aber, wie hätte man das gleiche Projekt strukturierter und transparenter durchführen können, so dass Ressourcen zielgerichteter eingesetzt worden wären und ohne dass der ein oder andere Kollege das Projekt vorzeitig verließ? Mit dem Wissen und dem konsequenten Einsatz des essentiellen Handwerkszeugs eines gut ausgebildeten Projektleiters!

Betrachtet man die Situation aus einer nüchternen Perspektive ist der Fehler bei der Gesamtprojektleitung zu sehen. Sie hätte erkennen müssen, dass es keine ausreichenden Standards im Unternehmen gibt und dass ein fundiertes Coaching für die Teilprojektleiter sinnvoll investiertes Geld gewesen wäre.

Nachdem ich mich intensiv mit dem Lehrstoff zur Zertifizierung des Project Management Professional (PMP)® auseinander gesetzt habe, musste ich zwangsläufig an das von mir beschriebene Projekt denken. Mir wurde sehr schnell klar, dass die Teilprojektleiter zwar über ausreichendes Fachwissen und Erfahrung im Bereich Projektmanagement verfügten, aber dass das theoretische Hintergrundwissen im Bereich Projektmanagement fehlte. Gerade diese Lücke hat dazu beigetragen, dass das Controlling des Projektes ein großes Potenzial nach oben aufwies.

Aus meiner Sicht hätte der konsequente Einsatz des Earned Value Managements die Transparenz erheblich erhöht. Der Geschäftsleitung wäre es sicher einfacher gefallen, die jeweiligen Status zu interpretieren. Mit Sicherheit wären die Auswirkungen der ein oder anderen Entscheidung schneller ersichtlich gewesen.

Das Earned Value Management ist ein Messverfahren welches für die drei Bereiche, Projektumfang (Scope), Zeitplan (Time) und Kosten (Cost) angewandt werden kann. Das Verfahren ermöglicht es dem Projektleiter folgende Fragen schnell und Präzise zu beantworten.

• Ist-Situation
  Was war geplant?
  Wie hoch sind die aktuellen Kosten?
  Welchen Wert haben wir bereits erschaffen?
  Welche Abweichungen haben wir bezüglich der Kosten und der Zeit?
• Prognose
  Was wird das Projekt voraussichtlich kosten?

Anmerkung: Sobald ein Projekt gestartet wurde, wird häufig der Zeitaufwand über den Kostenaufwand gestellt, bzw. der Projektmanager hat keine Budgetverantwortung. Es herrscht die Meinung vor, dass die „Internen“ eh da sind und bezahlt werden müssen. In diesem Fall kann das Earned Value Management anstatt der Kosten den Zeitverbrauch in den Mittelpunkt stellen.

Ich habe folgende Ansprüche an diesen Artikel:

• Darstellung der essentiellen Planungsschritte am Beispiel eines übersichtlichen Projektes mit einer Projektmanagementsoftware
• Aufzeigen, wie das Controlling des Projektes mit der Software durchgeführt werden kann
• Aufbereiten der Werte für das Earned Value Management
• Aufzeigen, dass die Anwendung des Earned Value Managements in einem vertretbaren Aufwand einen erheblichen Mehrwert bietet
• Interpretation der Ergebnisse

Szenario

Ein Projektleiter erhält für die Durchführung eines Projektes einen Project Auftrag. Dieser gibt ihm vor, die interne Preisauskunftsplattform an ein Vergleichsportal einer externen Firma anzuschließen. Ihm werden

• ein Softwareentwickler (Stundensatz 65,00€) und
• ein Tester (Stundensatz 60,00€) zur Verfügung gestellt.

Projektplanung

Für die Planung habe ich eine Open-Sorce-Software verwandt. Wenn man sich mit den Tücken dieser Software auseinander gesetzt hat, funktioniert diese Software für kleine Projekte recht gut. Mit ein wenig Übung kann die Software auch für die Steuerung von Projekten eingesetzt werden. Der wesentliche Mehrwert besteht hier für mich in der einfachen grafischen Aufbereitung des Projektes in Form des Gantt-Diagrammes.

Die Software bietet von Haus aus sämtliche Werte für das Earned Value Management. Ich für meinen Teil habe mich mit diesen Zahlen schwer getan. Sie weichen nicht unerheblich von meinen Zahlen ab. Daher habe ich für diesen Bereich wieder auf Excel zugegriffen.

1. Schritt – Bestimmen der Arbeitspakete

Der Projektmanager bricht mit seinem Team die Aufgabenstellung in steuerbare Arbeitspakete herunter. Folgende Pakete werden identifiziert:

1. Konzeption
2. Entwicklung, Datenbereitstellung
3. Entwicklung, Modul Datenmapping
4. Entwicklung, Modul Datenübertragung
5. Tests
6. Korrekturen
7. GoingLive

2. Schritt Festlegen der Abhängigkeiten und der Dauer

Nachdem die Arbeitspakete definiert wurden, werden die Abhängigkeiten bestimmt und deren Aufwand festgelegt. Bei den Schätzungen mit dem Team wurde die folgende Tabelle aufgestellt.

Die folgende Grafik zeigt die Planung für das hier vorgestellte Projekt. Auf der linken Seite werden die Aktivitäten mit Namen, Aufwand dem jeweiligen Vorgänger beschreiben. Die rechte Seite stellt das Projekt als Gantt-Diagramm auf der Zeitachse grafisch dar.

Die Aufgabe „Korrekturen“ bildet eine Besonderheit. Die Aufgabe beginnt nach dem Start der Tests und endet in der Regel vor dem Ende der Tests. Daher startet sie mit einer Verzögerung von einem Tag zusammen mit der Aufgabe Tests. Der GoingLive kann erst erfolgen wenn die Freigabe durch die Tests erteilt wurde.

3. Schritt, Zuordnen der Ressourcen und Bestimmen der Kosten

Der Projektmanager verfügt über das Wissen, welche Ressourcen ihm zur Verfügung stehen und was die jeweiligen Ressourcen kosten. Durch die Zuordnung der Ressourcen zu den Arbeitspaketen erhält der Projektmanager eine Budgetschätzung.

Die nachfolgende Grafik zeigt die Zuordnung der Ressourcen auf und beantwortet Ihnen implizit die Frage nach den Kosten.

Basierend auf dieser Planung wird das Projekt Kosten in höhe von 8980,00€ verursachen (exklusive des Projektmanagement).

Der GoingLive wird für den 23.06. festgelegt.

Baselines Scope, Time und Costs

Nach der Durchführung dieser Planungsschritte wird die Baseline des Planes abgespeichert. Die Baseline ist die eingefrorene Ursprungsplanung gegen die die späteren Zahlen in den Bereichen Scope, Time und Costs verglichen werden.

• Die Baseline Scope beinhaltet alle abzuarbeitenden Aktivitäten. Diese werden in dem aktuellen Szenario der Einfachheit halber nicht verändert.
• Die Baseline Time gibt Auskunft über den Plan und Ist-Zustand des Fortschrittes bezogen auf die Zeit.
• Die Baseline Costs gibt Auskunft über den Plan und Ist-Zustand des Fortschrittes bezogen auf die Kosten.

Bevor das Projekt gestartet wird, sollte der Projektmanager eine Aufstellung seiner Planwerte (PV, Planned Value) erarbeiten. Z. B. wird der Projektmanager am Ende der ersten Woche einen Statusbericht abgeben, in dem er Ist- und Planwerte gegenüber stellt. Hierzu ist es notwendig, die Planwerte für die Reportingtermine zu kennen. Da die von mir hier benutzte Software dieses Feature nicht bietet, behelfe ich mir mit einem kleinen Umweg. In den Spalten füge ich die Spalte SV – Schedule Varianz ein und setze das Projekt auf jeden Reportingtermin. Die SV gibt die Abweichung zwischen Earned Value (EV) und Planned Value an. Wird der EV nicht verändert (kein Projektfortschritt eingetragen), zeigt der SV den PV an. Siehe Screenshoot.

Der grüne Strich zeigt das Status-Datum an. Da die oberste Aktivität sämtliche Aktivitäten aggregiert, ist dieser der PV für den ersten Report am 06.06. zu entnehmen. Die folgende Tabelle gilt für das skizzierte Projekt:

Projektdurchführung

Wie bereits erwähnt, habe ich es schon häufig erlebt, dass ein Status von 50% schnell erreicht ist und danach das Pokern anfängt. Folgende Wortwechsel sind typisch.
PM: „Wir sind aktuell bei 65%, wo stehst Du heute?“
Entw: „Ich hatte da eine Herausforderung, ich würde die 65% so stehen lassen.“
Der Entwickler weiß, dass er eigentlich gar nicht bei 65% steht und hofft, in der nächsten Woche aufholen zu können.
PM: „Wir haben in der letzten Woche auch keinen Fortschritt gemeldet, Du musst doch in der Zwischenzeit etwas erreicht haben?“.
Entw: „Ja, habe ich, aber ich sehe da keine 65%, eher sogar weniger.“
PM: „Ich muss aber einen Fortschritt reporten!“
Entw: „Ok, dann nimm 67%.“
PM: „Ok, danke, dann kann ich wenigstens einen kleinen Fortschritt reporten.“
Der Projektleiter berichtet einen kleinen Fortschritt und das Ergebnis entspricht noch weniger dem tatsächlichen Status als davor.

In meiner Zeit als Softwareentwickler hatte ich des Öfteren mit einem Projektleiter zusammenarbeiten müssen, der nie nach Angaben in Prozent fragte. Seine Standardfragen waren: „Was hast Du an Aufwand generiert und was schätzt Du noch an Restaufwand?“ Aus dieser Angabe hat er in seinem Reporting einen Prozentwert ermittelt. Der Vorteil besteht darin, dass diese Schätzung wesentlich genauer ist und Abweichungen sehr schnell erkannt werden.

Gerade bei größeren Projekten ist es die Regel, dass die Planungsphase noch nicht final abgeschlossen ist, während bereits die Durchführung startet. In dem vorliegenden Szenario gibt es keine Überschneidung.

Reporting 1. Woche

Es ist Freitag, die ersten vier Tage sind vergangen. Der Projektleiter hat die Aufgabe, dem Management am Nachmittag die Ist-Zahlen zu den Bereichen Time und Costs sowie eine Prognose zu präsentieren. Folgende Informationen hat ihm sein Team für die erste Woche zur Verfügung gestellt.

1. Schritt, eintragen der gemessenen Werte in die Software

Addiert man den Ist-Aufwand, sieht man, dass der Entwickler in der ersten Woche 42 h für das Projekt gearbeitet hat. Ausgehend von einer Planung für 40 h hat der Entwickler 2 Überstunden generiert. Des Weiteren fällt auf, dass die erste Aufgabe (Konzeption) noch nicht wie geplant abgeschlossen wurde und zusätzlich 8 h mehr Zeit benötigt. Dafür wurde bereits mit der Arbeit an der zweiten Aufgabe (Entwicklung, Anpassung der Datenbereitstellung) begonnen. Diese wird voraussichtlich ebenfalls mehr Zeit benötigen.

Als erfahrener Projektmanager weiß ich, dass gerade am Anfang Schätzungen noch eine gewisse Toleranz aufweisen. Das Projekt scheint etwas teurer zu werden. Bei dem Zeitplan bin ich mir nicht wirklich sicher. Beide Aufgaben benötigen mehr Zeit, hingegen konnte ich die zweite Aufgabe schon vorzeitig anfangen. Das Gantt-Diagramm sorgt hier für mehr Klarheit.

Der Projektmanager überträgt die vorhandenen Werte in seine Software und erhält folgendes Bild. Der schwarze Strich in den Aufgaben zeigt die geleistete Arbeit. Die Balken für die Aufgaben wurden verlängert. Die grauen Striche unter den Balken der Aktivitäten zeigen die in der Baseline gespeicherte Ausgangsplanung. Bezogen auf das Gantt-Diagramm wird der Going-Live um zwei Tage nach hinten verschoben. Es ist aber auch ersichtlich, dass die Arbeit, die in der ersten Woche geleistet wurde, in der zweiten Woche anfällt.

2. Schritt, aktualisieren des Status-Datums und Replanung

Das Status-Datum wird auf den Reportingtag (06.06.) gesetzt. Zu sehen am grünen senkrechten Strich.
Die erste Aufgabe wird neu geplant. Das Ergebnis ist eine Restaktivität von 8 h in der zweiten Woche.
Die zweite Aufgabe wird vorgezogen gestartet, die Dauer wird verlängert. Der Verzug im Zeitplan bleibt aktuell noch bestehen.

3. Schritt, das Reporting

Die Frage, die sich jetzt stellt, ist die nach dem managementtauglichen Report. Was reportet der Projektleiter dem Management? Was ist für das Management interessant?

Der von mir für dieses Projekt eingesetzte Projektmanager wird folgendes Berichten:

Zusammenfassung:

PM: Das ist der erste Statusbericht zu diesem Projekt. Daher kann eine Aussage zur Tendenz noch nicht getroffen werden. Die gemessenen Kosten sind etwas höher als erwartet. Wir liegen ebenfalls etwas hinter dem Zeitplan. In der nächsten Woche werden wir sehen, wie sich das Projekt tendenziell entwickelt.

In Zahlen:

PM: Der Performance Index für die Kosten liegt bei 0,79. Das bedeutet, dass für jeden eingesetzten Euro 0,79 € als Gegenwert erbracht wurden. Aus heutiger Sicht würde das Projekt ca. 11.400,00 € kosten. Das wären Mehrkosten von ca. 2.400,00 €.

Bezogen auf die Zeit fällt der Index etwas besser aus. Er liegt bei 0,83. Ein Index von 1 würde dem Planwert entsprechen. Ich schlage vor, dass wir die nächste Woche abwarten und danach entscheiden, ob Gegenmaßnahmen bezüglich der Livestellung eingeleitet werden sollen.

Das nachfolgende Chart zeigt die Entwicklung des Projektes auf.

Abgesehen von der Tatsache, dass sowohl die Kosten als auch die Zeit leicht hinter den Erwartungen sind, kann davon ausgegangen werden, dass für das Management diese Art von Reports verständlich sind. Des Weiteren sendet der Projektmanager ein klares Signal: Mein Projekt ist transparent, ich bin kompetent und habe alles im Griff!

Die Zahlen für das Reporting

Grundlage des Reporting bilden vier Zahlen.

1. PV, Planned Value
   Das ist der Planwert jeweils zum Stichtag des Reporting. Der Wert wurde am Ende der Planungsphase ermittelt. Er beträgt für den 06.06. 2.600,00 €.
2. BAC, Budget at Completion
   Das ist das Gesamtbudget des Projektes. Dieser Wert wird nur bei einer Replanung verändert. Er beträgt 8.980,00 €. Theoretisch könnte der Projektmanager bereits nach dem Feststellen der Abweichung einen Change Request stellen und das Projekt neu planen. In diesem Projekt wird kein Change Request gestellt.
3. AC, Actual Costs
   Dieses sind die tatsächlich angefallenen Kosten. Sie setzen sich aus den angefallenen Stunden x Stundensatz zusammen und betragen 2730,00 €. Der Spalte Ist-Kosten können sie entnommen werden.
4. EV, Earned Value
   Der EV ist der erhaltene Gegenwert bezogen auf die Ursprungsplanung. Der EV errechnet sich aus dem Grad der Fertigstellung x Planwert. Die von mir verwendete Software bietet leider keine Spalte mit den benötigten Werten, so dass ich mit Abschluss der Planung die Planwerte für die Aktivitäten exportieren muss. Achtung: Die Multiplikation des Grades der Fertigstellung auf Gesamtprojektebene mit dem Gesamtplanwert spiegelt nicht den tatsächlichen EV wieder. Ein Grund ist z. B. in den unterschiedlichen Stundensätzen zu sehen.

Der EV errechnet sich wie folgt:

Folgende Werte werden mit diesen Zahlen errechnet:

1. CPI, Cost Performance Index
   Der CPI setzt den EV zu den Kosten in das Verhältnis. Er gibt den Wirkungsgrad aus Kostensicht wieder. Die Kalkulation: CPI = EV/AC.
   CPI = 2.151,50 / 2.730,00
   CPI = 0,79
   Er besagt, dass aus bezogen auf den Ausgangsplan mit einem eingesetzten Euro nur 0,79 Euro erreicht wurden.
2. SPI, Schedule Performance Index
   Da die Kosten in einer direkten Relation zur Zeit stehen kann von den anfallenden Kosten ein Rückschluss auf die Zeit getroffen werden. Die Kalkulation: SPI = EV/PV
   SPI = 2.151,50 / 2.600,00
   SPI = 0,83
   In diesem Fall sagt der SPI aus, dass sich das Projekt leicht verzögern wird. (ev. noch erklären um wie viel? Was bedeutet 0.83 in Zeit?) Diese Aussage deckt sich exakt mit der Darstellung im Gantt-Diagramm.
3. EAC, Estimate at Completion
   Mit dem EAC wird eine Prognose abgegeben, wie hoch die für das Projekt zu erwartenden Gesamtkosten aus Sicht des aktuellen Zeitpunktes sind. Der Wert des EAC ist das Pendant zum BAC.
   Für die Berechnung des EACs existieren vier unterschiedliche Formeln. Sie werden je nach Projektsituation eingesetzt. Die folgende Formel wird standardmäßig verwendet und ist für das skizzierte Szenario ausreichend.
   Kalkulation: EAC = BAC / CPI.
   EAC = 8.980,00 / 0,79
   EAC = 11.394,56 €
   Diese Formel ist relativ einfach herzuleiten. Sie basiert auf dem Dreisatz und geht davon aus, dass 8.980,00 € 79% entsprechen. Demnach sind 11.394,56 € die zu erwartenden 100%.
4. ETC, Estimate to Complete
   Mit dem ETC wird der zu erwartende Restaufwand, ausgehend vom aktuellen Zeitpunkt, beziffert. Er errechnet sich aus den zu erwartenden Gesamtkosten (EAC) abzüglich der bereits entstandenen Kosten (AC).
   ETC = EAC – AC
   Der ETC wird in dem Szenario nicht explizit erwähnt. In der Darstellung des Charts nutze ich ihn als “Verbindungslinie” zwischen den aktuellen Kosten (AC) und den zu erwartenden Gesamtkosten (EAC).

Reporting 2. Woche

Die zweite Woche ist vergangen, der Projektmanager erhält von seinem Team die nachfolgenden Zahlen:

Wie hat sich das Projekt entwickelt? Zur Konzeption existiert immer noch ein Restaufwand von 8 h. Dieser behindert nicht den Fortschritt des Projektes. Die Aktivitäten Datenbereitstellung und Datenmapping wurden erfolgreich abgeschlossen. Die Tests konnten bereits vorgezogen beginnen. Der erfahrene Projektmanager sieht, dass die leichte Zeitverzögerung recht gut aufgeholt wurde. Diese wurde mit einem entsprechenden Aufwand an Überstunden erkauft. Wie sieht das Projekt in der Gantt-Darstellung aus und was sagen die Zahlen?

Nachdem die Werte in der Software übernommen wurden, bestätigt sich der Eindruck. Der GoingLive zum 23.06. scheint wieder möglich.

Welche Kennzahlen hat das Projekt am 13.06.?

PV = Für den 13.06. wurde ein Wert von 5.200,00 € geplant.
BAC = Unverändert bei 8.980,00 €.
AC = Für den Entwickler und die Tester sind Kosten in Höhe von 5.960,00 € angefallen.
EV = Der erhaltene Gegenwert liegt bei 5.024,00 €
CPI = 0,84 = 5.024 / 5.600
SPI = 0,97 = 5.024 / 5200
EAC = 10.653,03 € = 8.980 / 0,84

Was berichtet der Projektmanager dem Management?

Zusammenfassung:

PM: Das ist der zweite Statusbericht zu diesem Projekt. Die Kosten überschreiten immer noch leicht das veranschlagte Budget. Im Vergleich zum letzten Bericht haben wir eine Verbesserung erzielt. Der GoingLive zum geplanten Termin ist realistisch. Im Vergleich zum letzten Report ist der Verzug kaum nennenswert.

In Zahlen:

PM: Der Performance Index für die Kosten liegt bei 0,84. Er hat sich im Vergleich zum letzten Bericht um 5% verbessert. Aus heutiger Sicht wird das Projekt ca. 10.700,00 € kosten. Das sind im Vergleich zum letzten Bericht ca. 700,00 € weniger und 1.700,00 mehr als ursprünglich angenommen.

Der Zeitindex hat sich auf 0,97 verbessert. Im Vergleich zum letzten Report ist das ist ein Performancezuwachs von 15 %.

Das nachfolgende Chart zeigt die Entwicklung des Projektes auf.

Reporting 3. Woche

Die letzte Projektwoche vor dem GoingLive ist vergangen, das Team berichtet folgende Werte:

Dem Chart ist zu entnehmen, dass sämtliche Aufgaben erfolgreich abgeschlossen wurden. Es existiert immer noch ein Restaufwand zur Konzeption. Dieser verhindert den GoingLive nicht. Diese Aktivität wird nach dem GoingLive vervollständigt. Mit Sicherheit wird der Index für die Performance keine 1 anzeigen. Dieser Restaufwand ist u. A. dafür verantwortlich.

Nachdem die Werte in der Software übernommen wurden, ergibt sich folgendes Diagramm.

Welche Kennzahlen hat das Projekt am 20.06.?

PV = Für den 20.06. wurde ein Wert von 8.460,00 € geplant. Das ist das geplante Budget (BAC verringert um die Kosten der Aktivität des GoingLive)
BAC = Unverändert bei 8.980,00 €.
AC = Für den Entwickler und den Tester sind Kosten in Höhe von 10.420,00 € angefallen.
EV = Der erhaltene Gegenwert liegt bei 8.044,00 €
CPI = 0,77 = 8.044 /10.420
SPI = 0,95 = 8.044 / 8460
EAC = 11.632,47 € = 8.980 / 0,77

Was berichtet der Projektmanager dem Management?

Zusammenfassung:

PM: Das ist der letzte Statusbericht zu diesem Projekt. Die Kosten überschreiten das veranschlagte Budget. In der letzten Woche sind mehr Projektstunden angefallen als geplant. Der Zeitplan kann gehalten werden. Der GoingLive ist für den nächsten Montag geplant.

In Zahlen:

PM: Der Performance Index für die Kosten liegt bei 0,77. Das Projekt wird mit ca. 11.600,00 € 23% teurer als veranschlagt.

Der Zeitindex liegt bei 0,95. Dieses ist auf eine Restaktivität zurückzuführen, die den GoingLive nicht verhindert. Sie wird nach dem GoingLive abgeschlossen.

Das nachfolgende Chart zeigt die Entwicklung des Projektes auf. Den Graphen ist zu entnehmen, dass das Projekt noch nicht abgeschlossen ist. Dieses begründet sich darin, dass der der GoingLive noch aussteht.

Fazit

Während ich mir die theoretischen Grundlagen dieser Methode angeeignet habe, bin ich immer wieder auf Anwendungsbeispiele gestoßen, die so einfach waren, dass er mir schwer fiel, die Brücke zum realistischen Einsatz zu schlagen. Des Weiteren stellte ich mir die Frage, ob der Aufwand, der durch den Einsatz einer Projektmanagementsoftware entsteht, den Nutzen für ein reales Projekt aufwiegt. Ich bin zu der Überzeugung gekommen, dass der Einsatz einer entsprechenden Software einen wesentlichen Mehrwert bietet und dass sich der vermeindlich zusätzliche Aufwand schnell amortisiert. Wenn ich an das ein oder andere Projekt zurück denke, mag ich mir gar nicht vorstellen, wie viel einfacher das Leben nicht nur für mich in der Rolle des Projektmanagers sondern auch für das Management gewesen wäre.

Fakt ist, dass das Reporting nur so gut ist, wie die Ausgangsplanung und die Zahlen, die geliefert werden. Erfahrungsgemäß gehört es nicht zu den Lieblingsaufgaben eines Softwareentwicklers seine Zeiten zu tracken und diese dem Projektmanagement offen zu legen. An dieser Stelle liegt der Ball bei der Projektleitung, das Vorgehen offen zu kommunizieren und die Zahlen konsequent einzufordern. Ebenfalls erfordert die Etablierung eines solchen Vorgehens eine Veränderung der Projektkultur hin zur Transparenz.

Schlussendlich liegt ein Großteil der Verantwortung beim Projektmanager und seiner aus meiner Sicht Verpflichtung zur kontinuierlichen Weiterbildung.

Friedrich Behnk