Earned Value: What are the critics saying?

PMPs (should) know about Earned Value Management (EV, EVM), it is THE Tools and Techniques for Cost Controls in the PMBOK.

For project managers not interested in being PMPs, Earned Value will come as yet another technique for project progress tracking and forecasting.

The objective of this post is to assess what are the things that earned value does not do or does not do well.

What is Earned Value?

If you have the PMBOK you will refer to pages 181 to 187. If you haven't then you will find plenty of articles on what is Earned Value. Here is my selection:

First what is earned value: www.projectsmart.co.uk/what-is-earned-value.html, or even better from them: www.projectsmart.co.uk/docs/earned-value.pdf

A good tutorial with a clear example: www.checkitweb.com/PDFfiler/EVTutorial.pdf

A simpler tutorial: www.hyperthot.com/pm_cscs.htm

Obviously Wikipedia has its entry: en.wikipedia.org/wiki/Earned_value_management

A lengthy but really good presentation is there: www.srs.gov/general/EFCOG/04Training/DOETutorials/Mod6MetandPerfMeas.pdf

If you really want to dig into it then you can always buy books or read online books such as this one on Google Books

"Bing it" or "Google it" and you will find plenty of resources.

How widely it is used?

This is a bit of a mystery to me (help!). I work in software development and systems integration, I never came across any UK company using it. Earned Value originated from the US government and I am not sure how much it spread in other countries and sectors. I have work for a FTSE100 consultancy for years and we never used it on projects, it was even never mentioned in our quality system. 

What are the critics saying?

Earned Value is however not the silver bullet for progress control and forecast. It has its critics and they come from a number of different side.

1. Critical path ignorant

One of the beauty of EV is the harsh simplicity of the performance indicators: less than one and it's bad for schedule (SPI) and money (CPI). For management it's great, with a couple of numbers they have some measurement of the project's health. But by doing so it discards some information that could be of importance. SPI will not differentiate between late tasks on the critical path and late tasks not on the critical path.

In Example 1 (See attached image), the WP2 task is not on the critical path, it has a one week float. It is delayed and instead of completing on week 6 it does on week 7. The delay uses the float, not more. The project SPI on week 6 is 0.36. 

In Example 2 (See attached image), it is WP3 - on the critical path - that is delayed by a week and then causes the same delay on the project. On week 6 the SPI is 0.69. 

Note: In both examples, we used a linear cost for PV and a 25/75 rule for EV.

So in Earned Value, the Schedule indicators only give a partial view of what you need to monitor as a project manager.

2. Schedule performance indicator does not work

Walt Lipke and Kym Henderson found out that however late your project is you will always end up with and SPI of 1. Their words: "EVM measures schedule performance not in units of time, but rather in cost, i.e. dollars.  After overcoming this mental obstacle, we later discover another quirk of EVM: at the completion of a project which is behind schedule, Schedule Variance (SV) is equal to zero, and the Schedule Performance Index (SPI) equals unity.  We know the project completed late, yet the indicator values say the project has …perfect schedule performance!!" (from www.earnedschedule.com)

Indeed. Look at Example 2. SPI on Week 8 is 1 even though the project is one week late.

Lipke and Henderson then developed the Earned Schedule system to replace the SPI and SV indicators. ES is built on EV but instead of being money based it is time based. Explore the ES website to go into details.

3. Quality ignorant

Earned value does not measure the quality of deliverables, or ultimately customer satisfaction. I honestly find this a harsh critic as EV was never designed to do so. Earned Value is focusing on schedule and cost performance, being specially reliable on the cost side - arguably the easier to implement.

4. Need to know everything before you start the project: not "agile" friendly

Lastly, a known complain is that to use Earned Value one actually need to know all work packages upfront in order to use it. Specially to use the BAC and other forecast indicators as this requires the total budget. Corollary: it does not like Agile where the scope (and so things to measure) is discovered with time. 

These are fair comments, however one can use EV techniques on project phases alone and not the full scope of the project. Thus allowing to use EV with rolling-wave planning approach.

Agile usually come with its own progress tracking and forecast tool, in Scrum we have the Burn Down charts. I don't really see the value using EV to replace methods specific tools, unless it is to compare status between projects.

 

5. It is "hard" to put in place

With EV you need to put a system in place to track costs and progress. You need to give a cost value to work packages and to track cost spending on this work package. Again, if you want to report on you are doing on the cost and schedule front then you ought to have something in place to do so, whereas you use Earned Value or not.

Tracking the "% completed" quickly come as a potential issue as well. In my example I used the 25/75 rule: when a Work Package has started I mark it 25% completed, this status will stay the same until the work has actually completed and where I mark the WP as 100% done. This is a very simple technique because it does not require to go deep inside the WP to actually figure out how much was completed. The downside is that, on small project, it gives SPI and CPI that are not very precise.

Thoughts?

I am happy to read your comments on this article and particularly about your practical experience about using EV.

AttachmentSize
Earned Value - Example 144.13 KB
Earned Value - Example 247.73 KB

Comments

Earned Value (EV) is a specific technique that can be used by more than just an Earned Value Management System (EVMS). It combines technical Performance as well as the Schedule and Cost as you mention in the article. It is important to understand that EV is a measure of the work that has been done. This is a point I feel is mostly overlooked or misunderstood. Ironically, EV isn't the only technique that is used in an EVMS system.

EV is great for Agile projects which is why they often use EV Burn Down Charts and they have proven to be a good application of EV in that environment. See Alistair Cockburn on Earned-value and burn charts. Basically I don't buy the EV is no good for Agile line since they make good use of it - whatever name they give it.

Contrary to popular myth you don't have to know absolutely everything about a project in minute detail to use Earned Value. Even the DoD gets Evolutionary Development and they demand the use of EV on projects. It's what Planning Packages are used for. You do need to know the total scope for the project, and you do need to have good change control to deal with changes to scope. In fact change control and baseline maintenance are vitally important for EV to work.

One thing for certain is the assigning of an EV Method isn't some arbitary task, but should be based on how the work package is expected to deliver it's technical performance over time and should be as objective as possible. If it is expected to be started and finished in one reporting cycle give it a 0-100. If it takes two give it 50-50. Any longer and you can give it another method such as PC, Weighted Milestones, Units Complete and so on.

EV techniques are about saying what has been achieved to date and helping us to predict when something will be completed and how much it is really going to cost.

As both a PMP and Scrum Master, I've worked in both Agile and traditional waterfall environments. I'm currently contracting for a U.S. Government Agency PMO. EVM works for reporting "progress" to Congress IF all of the work is definitized and the schedule is baselined. If either are not, it doesn't work. I see its validity when nothing tangible is being delivered and the project wants or needs continued funding.

As soon as you bring Agile into the picture, there is real opportunity to actually deliver something. Unfortunately, the GAO (Government Accountability Office) sees this as more of a Level Of Effort approach. They don't like that. They like to know up front what they are going to pay for something, even if that something is nothing.

I personally prefer Agile methods. I care less of the CPI and SPI at the end of the month. I care more that the customer is actually getting their highest priorities delivered.

Member since:
9 November 2008
Last activity:
8 weeks 6 days

Thanks for your comment.
You are pointing in your comment a fact that prevent further agile adoption: outsourcing. Indeed, I mostly work in Telecoms, IT and companies purchasing solutions are very much driven by business case and purchasing this means companies want to know the full price and feature set NOW (and argue later ;-) and this favor traditional approach with the scope being fully understood right at the beginning - very anti-agile.
I guess we need to work on ways to bridge the two worlds.

Thanks for the information. I have been curious how Scrum and EVM intersect.