Ein Plädoyer für Earned Value Management im Projekt
Ein Plädoyer für Earned Value Management im Projekt
Sie gehört zu den Lieblingsthemen in jedem PMI-Examen, ist seit über 50 Jahren bei fast allen Projekten für US-Ministerien Pflicht und fast jedes größere Unternehmen nutzt eine PM-Software, die auch auf ihre Anwendung ausgelegt ist: Das Earned Value Management (EVM) bzw. die Earned Value Analysis (EVA). Der geniale Nutzen aus der integrierten Betrachtung von Projektkosten, -Terminen und -Performance ist meiner Meinung nach unbestreitbar. Trotzdem scheuen viele Projektmanager den (vermeintlichen) Aufwand ihrer Implementierung und Pflege.
Das finde ich schade, denn ich bin ein Fan dieser Controlling-Methode – gerade, weil sie sich so universell und unkompliziert einsetzen lässt und mit ein paar einfachen Formeln valide Statusbestimmungen und Prognosen ermöglicht. Heute möchte ich Ihnen zum einen zeigen, warum EVM sich hierzulande nicht der ihr zustehenden Beliebtheit erfreut, und Ihnen zum anderen anhand von zwei Beispielprojekten zeigen, wie man die Vorbehalte gegenüber EVM leicht überwinden und diese erfolgreich nutzen kann.
Warum EVM häufig nicht angewendet wird
Zunächst eine kurze Übersicht zu den allgemeinen Hindernissen, die ich in vielen Projekten durchgängig angetroffen habe:
- Unkenntnis: Obwohl jeder CAPM oder PMP die Formeln auswendig gelernt hat, fehlt vielen das Verständnis, um sie als Best Practice zu nutzen. Auch wenn geeignete Werkzeuge da sind, wird deren Einsatz oft als überflüssiger Overhead angesehen. Das erinnert an den Unternehmer, der seine Buchhaltung nur für’s Finanzamt macht und dabei übersieht, was er aus ihr alles lesen könnte…
- Unkenntnis: Die EVM-bezogenen Möglichkeiten der ohnehin zur Verfügung stehenden Tools sind meist unbekannt bzw. werden nicht adäquat evaluiert – sodass sie auch nicht genutzt werden. Natürlich haben mächtige Spezial-Applikationen jede Menge Features, aber meine Textverarbeitung oder Tabellenkalkulation setze ich ja auch nicht mit allen ihren Funktionen ein…
- Unkenntnis: Nun steht nicht jedem Projektmanager eine ausgeklügelte Projektmanagement-Software zur Verfügung, aber nur wenigen ist bekannt, wie man auch mit MS-Project oder einem einfachen Excel schnell eine recht effiziente EVM einrichten kann. Lieber weiter mühsam mit der stumpfen Axt Holz spalten, statt diese zu schärfen…
- Unkenntnis: Selbst wenn im Projekt ein EVM-Ansatz gewählt wird, muss der Projektmanager in seinem Berichtswesen die Aussagen seines Controllings oft auf die berühmte Ampel eindampfen, weil das Management die KPIs nicht verstehen würde. Das Wegschieben von Verantwortung und das Fehlen eines effektiven Management Buy-in ist nachgewiesen die zweitwichtigste Ursache für Projekte in Schieflage…
Die Liste ließe sich problemlos fortführen, dabei kann man gegen die breite Unkenntnis schon mit einer kleinen Schulung sehr einfach und kostengünstig etwas tun. Ist dann der Appetit geweckt, entwickelt sich meist eine Eigendynamik, die – wenn Routine und Stress sie nicht wieder ersticken – erstaunliche Ergebnisse liefert. So auch in den beiden folgenden Beispielprojekten.
Beispiele erfolgreicher EVM-Einführungen
Im ersten Fall wurde ich zu einem gefährdeten Projekt gerufen: Status und Zukunft unklar. Wie weiland in den Examens-Übungen sammelte mein Team alle Daten und Fakten und ergänzte sie um belastbare 3-Punkt-Schätzungen der Restaufwände. Jedes einzelne Arbeitspaket und jeder gemeldete Case wurden aufgenommen. Für die dritte und vierte Ebene des Projektstrukturplans hatten wir in kurzer Zeit die aggregierten EVM-Kennzahlen berechnet, sodass schnell der belegte Gesamtstatus und eine fundierte Vorschau vorlagen und eine erste Detailanalyse in den Haupt-Problemfeldern durchgeführt werden konnte. Für alle offenen Cases war fortan eine tagesgenaue Verfolgung der Fortschritte, ein Forecast bis zum Erreichen der SLAs und eine genaue Bestimmung des Ressourcenbedarfs möglich. Die Risiken des Projekts wurden kalkulierbar und fundierte Entscheidungen möglich.
Das Ziel des zweiten Projekts war die Einrichtung eines zentralen Dashboards für die Kennzahlen aller Projekte. Das Unternehmen war groß und besaß eine ausgefeilter PM-Infrastruktur. In dem Jahr bevor ich dieses Projekt übernahm, war in der Zentrale ein unregelmäßig belieferter Datenfriedhof ohne Rückmeldung ins Projekt entstanden, während im Projekt mit Bordmitteln gehandwerkt wurde. Ein Review des Berichtswesens im Projekt und zur Zentrale initiierte ein Streamlining in der Datenaggregation, den Wegfall vieler projektinterner Excels, die ersetzt wurden durch strukturierte und aussagekräftige Auswertungen aus dem Zentralsystem. Allein die sinnvolle Bestimmung des Granularitätslevels für die EVM reduzierte den ungeliebten Overhead um über 20%, weitere Synergien ergaben sich aus weniger und kürzeren Telefonkonferenzen (geringerer Klärungsbedarf) und weniger Redundanzen in dezentralen Controllinginstanzen. Es blieb also mehr Zeit für’s Wesentliche!
Earned Value Management im agilen Umfeld
Nun mag manch einer einwenden, EVM eigne sich nur für klassisches Projektcontrolling, nicht aber für agile Entwicklung, wo es andere Fortschrittsmessmethoden wie Burn-down und Entwicklungsgeschwindigkeit gibt. Weil ich aber in den meisten Projekten eben kein rein agiles Vorgehen "by the book" antreffe und zudem das Management bzw. der Lenkungskreis eher klassisch "tickt", verbinde ich gerne die Vorteile beider Ansätze miteinander (siehe auch meinen Beitrag "Wie Projektmanagement und Agilität zusammen mehr Nutzen bringen"), auch wenn das etwas Übersetzungsarbeit verlangt.
Dabei findet agile Entwicklung im Rahmen übergeordneter, klassischer Planung (anstelle z.B. eines Scrum of Scrums) statt. Aber Arbeitspaket bleibt Arbeitspaket, auch wenn es im Agilen "Backlog Item" heißt. Und demnach kann ich auch agil bearbeitete Arbeitspakete mit der EVM analysieren.
Konkret habe ich für jedes Backlog Item einen Zeitraum (z.B. Anzahl von Sprints, die ich für alle User Stories des Items vereinbart habe) und die dazugehörigen Kosten vorliegen (übrigens auch mit agilen Methoden geschätzt). Diese Kosten kann ich also genau wie im Klassischen auf dem Zeitstrahl der EVM verteilen – fertig ist der Planned Value (PV). Die Actual Cost (AC) erhalte ich wie im Klassischen aus den Stundenabrechnungen und Rechnungen.
Nur der Earned Value (EV) erfordert etwas Nachdenken, benötige ich zu seiner Berechnung doch den Fertigstellungsgrad. Das geht im Agilen halt nicht über einen klassischen Phasenbezug. Bei kurzen Backlog Items bietet sich die Methode 0%-50%-100% an: nicht angefangen – in Arbeit – fertig. Bei größeren Backlog Items hat sich die Methode "Themenpark" aus dem Feature-driven Development bewährt: Das Item umfasst viele User Stories, deren Komplexitäten mit "Story Points" von eins bis drei oder fünf Points oder per Planungspoker in der Schätzklausur bestimmt werden. Abgearbeitete Stories erhalten eine Gutschrift ihrer Points, und die gibt kumuliert im Verhältnis zur Gesamtpunktzahl des Backlog Items den Fertigstellungsgrad für den EV wider.
Kein Nachwort diesmal – ich finde dass die Beispiele genug Anreiz zum Nachdenken und Ausprobieren geben …
Roland Wanner
03.10.2018