Sie gehört zu den Lieblingsthemen in jedem PMI-Examen, bei fast allen Projekten für US Ministerien ist sie seit ihrer Einführung im DoD in den 1960ern Pflicht, fast jedes größere Unternehmen hat eine Projektmanagement-Software in Gebrauch, die auch auf ihre Anwendung ausgelegt ist: Die Earned Value Management Technik (EVM). Der „geniale“ Nutzen aus der integrierten Betrachtung von Projektkosten, -Terminen und -Performance ist sicher unbestritten. Und doch scheuen viele Projektmanager den vermeintlichen Aufwand ihrer Implementierung und Pflege.
Ich möchte Ihnen heute von zwei Beispielen erzählen, die zeigen, warum Earned Value Management sich hierzulande nicht der ihr zustehenden Beliebtheit erfreut, und wie man in diesen Fällen die Vorbehalte überwunden und die Nutzung erfolgreich betrieben hat. Ich möchte vorausschicken, dass ich ein „Fan“ der Methode bin, gerade weil sie sich so universell und unkompliziert einsetzen lässt und mit ein paar einfachen Formeln valide Statusbestimmungen und Prognosen für das Projektmanagement ermöglicht.
Warum Earned Value Management häufig nicht angewendet wird
Fangen wir daher mit den allgemeinen Hindernissen an, die ich vielen Projekten durchgängig angetroffen habe.
- Unkenntnis: Obwohl jeder CAPM oder PMP die Formeln auswendig gelernt hat, fehlt meist das Verständnis, sie als Best Practicein seinem Projektmanagement 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 Earned Value Management-bezogenen Möglichkeiten der zur Verfügung stehenden Tools sind meist unbekannt werden nicht adäquat evaluiert, bevor man sie nicht nutzt. 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 hat nicht jedes Unternehmen ein Projektmanagement-Super-System im Einsatz, aber nur wenigen Projektmanagern ist bekannt, wie man auch mit MS-Project oder einem einfachen Excel schnell eine recht effiziente EVM einrichten kann. Lieber wird mühsam mit stumpfer Säge Holz gemacht, statt sie zuerst mal zu schärfen…
- Unkenntnis: Selbst wenn im Projekt ein Earned Value Management-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 fehlendes, effektives Management Buy-in ist nachgewiesen zweitwichtigste Ursache für Projekte in Schieflage…
Die Liste ist fortführbar, aber gegen das Grundproblem kann man mit einer kleinen Schulung sehr einfach und kostengünstig etwas tun. Ist dann der Appetit geweckt, entwickelt sich meist eine Eigendynamik, die, wenn sie nicht in der Routine und im Stress wieder erstickt wird, erstaunliche Ergebnisse liefert. So auch in den beiden Praxisbeispielen.
Fallbeispiele erfolgreicher Earned Value Management-Einführung
Im einen 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 waren schnell die aggregierten Earned Value Management-Kennzahlen berechnet, so dass in kurzer Zeit der belegte Gesamtstatus und eine fundierte Vorschau gegeben 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.
Der andere Fall spielt in einem großen Unternehmen mit ausgefeilter Projektmanagement-Infrastruktur und der Forderung der Geschäftsleitung, die Kennzahlen aller Projekte zentral zu berichten und zu aggregieren. In dem Jahr vor Übernahme des Projekts durch mich 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 und Ersatz durch strukturierte und aussagekräftige Auswertungen aus dem Zentralsystem. Allein die sinnvolle Bestimmung des Granularitätslevels für die Earned Value Management 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. Mehr Zeit für’s Wesentliche !
Earned Value Management im agilen Umfeld
Nun mag manch einer einwenden, Earned Value Management 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 mein Beitrag „Wie Projektmanagement und Agilität zusammen mehr Nutzen bringen“), auch wenn das etwas „Übersetzungsarbeit“ mit sich bringt.
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 Earned Value Management 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 ja auch mit agilen Methoden geschätzt vorliegen. Diese Kosten kann ich also genau wie im Klassischen auf dem Zeitstrahl des Earned Value Management 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 1 bis 3 oder 5 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 meine, die Beispiele geben genug Anreiz zum Nachdenken und Ausprobieren … 🙂