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 PM 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 EVM 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 with a few simple formulas.
Why EVM 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 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 EVM 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 PM 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 EVM. They would rather a continue cutting wood with a dull saw then to just sharpen the saw once…
- Ignorance: Even if an EVM 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 EVM 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 EVM implantation
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 EVM 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 PM 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 EVM 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 !
EVM in agile environment
Some may say EVM 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 EVM.
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 EVM’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 …