It is one of the favourite subjects in every PMI exam, since its introduction in the 1960s by the DoD it is mandatory for all projects with US authorities, in nearly each large company there is a Project Management software in use that is also fit to handle it: the Earned Value Management technique (EVM). The “superb” benefits of the integrated view on project cost, schedule, and performance is all but undisputed. However, many project managers are afraid of the assumed high effort of implementation and maintenance.
Today I’d like to tell you about two examples that show why Earned Value Management is not as popular as it should in projects here in Germany, and how, in these cases, reservations have been overcome and implementation was completed successfully. I’d first like to mention that I’m a “fan” of this method, just because it is universal and uncomplicated to use, and because it provides a valid status determination as well as forecasts for Project Management with a few simple formulas.
Why Earned Value Management often is not used
Let’s start with the general obstacles I’ve regularly found in many projects:
- Ignorance: Though every CAPM or PMP learned the formulas by heart, in most cases understanding to use them as a Best Practice with their Project Management is missing. Even if adequate tools are available their use is considered unnecessary overhead. This reminds me of company leaders who manage accounting balance sheet for the tax authorities, but do not realize what they could learn from them…
- Ignorance: The Earned Value Management related capabilities of available tools are often unknown or inadequately explored before deciding not to use them. No doubt these sophisticated special applications have a lot of features, but I don’t use all the features of my spread sheet or word processing software either…
- Ignorance: Not every company has a Project Management super-application in place, but very few project managers know how to use even MS Project or a simple Excel worksheet to implement a quite efficient Earned Value Management. They would rather a continue cutting wood with a dull saw then to just sharpen the saw once…
- Ignorance: Even if an Earned Value Management approach is chosen for a project, the project manager often has to condense his findings to the simple stop light colours (RAG) because management wouldn’t understand his Earned Value Management KPIs. Management shrugging off responsibility and a lack of effective buy-in is has been proven to be the second most critical cause of troubled projects…
The list can be continued, but the root cause can be tackled easily and cheaply with a little training. Once they get a taste of it, a type of self-dynamic is developed which, if not lost again in routine and stress, delivers impressive results. This can be seen in the following two field studies.
Cases of successful Earned Value Management implementation
In the first case study I was called to a troubled project, status and future unknown. As in former days when practicing for the exam my team collected all data and facts, and supplemented with a reliable 3-point estimation of the remaining work. Each 
single work package and case was assessed. We quickly managed to calculate the aggregated Earned Value Management KPIs for the third and fourth WBS level, thus being able to give a verified overall status, a profound preview, and a first detailed analysis of the main issue areas. From there on, a daily progress tracking, a forecast of when the SLAs will be met, and a detailed resource requirement determination was possible for all open cases. Project risk became calculable, and substantial decisions were enabled.
The second case was at a big company with a sophisticated Project Management infrastructure. The executives demanded that all projects were to be reported and all key figures aggregated centrally. During the year prior to my involvement in the project, they sporadically supplied a data cemetery within the headquarters with information, but with no feedback to the projects, while at ground level people helped themselves with their tools of the trade.
Revisiting the reporting within the project and to the headquarters resulted in the initiation of data aggregation streamlining, the elimination of many project internal Excels sheets and their replacement with structured and evidence-loaded evaluations from the central system. Only the smart determination of the granularity level for Earned Value Management reduced the unloved overhead by more than 20%. More synergies derived from less and shorter teleconferences (fewer things to clarify) and less redundancy in decentral controlling instances… leaving more time for the essentials !
Earned Value Management in agile environment
Some may say Earned Value Management is only fit for classic project controlling but not for agile development, where other methods for measuring progress and performance like Burn-down or Development Speed apply. But because at most projects I actually do not find a pure agile working “by the book”, and additionally management and Steering Committee rather “tick” classical, I like to merge the advantages of both approaches (see also my article “How Project Management and Agile together create increased Benefit”), though that might cause a little “translation work”.
In this case agile developments happens in a frame of a superior, classical planning (instead of a Scrum-of-Scrums). But a work package remains a work package though called “Backlog Item” in Agile. And therefore I can also analyze work packages handled agile with the Earned Value Management.
Actually I have a time box for each Backlog Item (e.g. count of sprints agreed for all of the Backlog Item’s User Stories), and the related cost, estimated with agile-fit methods, at hand. Just like in classical project management I can distribute these on the Earned Value Management’s time axis – the Planned Value (PV) is done. The Actual Cost (AC) I receive as usual from hours reporting and invoices.
Only the Earned Value (EV) requires a little thinking as I need the degree of completion to calculate it. In Agile using a classical phase scheme is not feasible of course. With short-time Backlog Items it is suggested to use the 0%-50%-100% method: open – in progress – done. With larger Backlog Items the “Themes” method from Feature-driven Development has shown to be effective: The item comprises many User Stories, of which the complexity is rated in „Story Points“ from 1 to 3 or 5 Points or per Planning Poker in the Planning Meeting. Stories completed receive a credit of their Points, and these cumulated in relation to the Backlog Item’s total count of Points reflects the completion status for the EV.
No epilogue this time – I assume the examples provide plenty incentives for reflections and tries …