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!!” (fromwww.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.

I recently managed a project for a new client of mine where a significant cultural issue came into the picture. Let me share it with you. The project involves integrating a number of my client’s products (lets call this company “A”) to one of their customers (lets call it “B”) in France. My client is based in another European country and the resource center, providing much of the deployment resources is based in yet another European country. In total I have about five different nationalities working on my project and located in 4 different countries.

One of the immediate impact is difficulties of communications:

My team of 15-20 people is based in 3 different countries, face to face meeting are hard to organise and so a lot of the communication is done by emails, conference calls or direct one to one calls. There is no facility to create a project workspace on the company’s intranet.
The working language with the customer is english but it does no go without difficulties. The langage barrier is pretty obvious and being bilingual helps as I am able to sometimes switch to french to ensure that the communication is clearly received and interpreted.
All this is actually a fairly standard set of issues in multi-lingual, multi-location projects. And with good-will things get done and we all overcome the language barrier and get one with the communications difficulties.

There is however a larger issue that surfaced on this project about culture, not related to country or individuals but linked to the project management culture, or the different pratices around project delivery between the two companies.

Some few background information to set the scene on this particular case:

The end customer has been already buying from my client but this time they had very specific requirements about how the project should be delivered, its documentation, its test phases and on top of that some very strong “non-functional” requirements that happened to be rather unusual in comparison to my client’s standard delivery practices.
My client has a fairly standard system integration project delivery approach for their product, meaning that the work packages to deliver follow a standard description, this is particularly true for: documentation, installation and acceptance procedures. All these are in the quality system and known to all project staff.
The end customer has a very strong set of project delivery requirements and the attention for details is significant.
None of the parties involved is using PMBOK as a reference.

What company “A” is used to do? … and not.

Company A is used to do standard deployment of its products. This means following a set of procedures and practices to build hardware, install its product, configure systems and follow a standard acceptance procedure. This is what they do all year long and in a lot of countries. The product is good, leader in its area and the deployment fairly standardised.

What company A does not do very often is the deployment of custom solutions, with complex requirements impacting the deployment of products and hardware such as backup and security requirements, with special software development requirement, with more than one product to be delivered. When it comes to this level of complexity then company A is faced with the nasty symptom of “my experience kills my creativity and adaptation”, indeed, because company A is mastering its standard procedures for deployment, it is such a habit that doing something different becomes actually very difficult. The adaptation is very difficult because complex solutions integration has not been addressed as a specific process.

What company “B” wants?

Company “B” is the customer of the project. What they want is documented in a big pile of documents – the contract – and signed by both parties. The contract has specific sections describing how they want to the project to be delivered: what are the documents they are expecting, what are the test phases the project should go through. They also have some technical requirements that are pretty unusual for company “A”.

Culture mix and shock?

The two companies project management culture meet with this project. And the encounter is painful because they do not share the same experience and habits on how to deliver projects. What “B” expects is not what “A” is usually doing and because company “A” did not see this adaptation as being a pre-requisite to the project from the outset the adaptation is happening as we go along, as we learn during the project. Obviously this does not go without troubles, delays and re-work. This could have been partially avoided if this was recognised as a particular challenge from the outset, at pre-sales stage, this would have required also that the quality department of company “A” to be involved to assess impacts on the processes but also on the resources needs for the project. Indeed with increased complexity of solutions deployment comes requirements for differents skills for the project, for example, there is no test manager skills in company “A” as testing is done by deployment engineer, but with complex solutions comes complex testing and standard tests, product based are just not good enough anymore. Examples like this are legions and all related to the same issue: both companies do not talk the same language as far as project management is concerned and adaptation to higher project delivery expectations is not an easy task.

Fixing this

There is no quick fix. When it comes to the fundamentals of how we do things there is no quick fix. And the solution is not only down to the project but involved more fundamental changes within the organisation: in the quality system, in the skills of the workforce, on the standard project procedures and it could also impact the company’s organisation as well, to better fit this type of project.

The likely output if a set of new procedures, guidelines, in other words everything that describe how company “A” does things for this type of project.

Once this is done there is still an exercise to be done: mapping company “A” project approach to company “B” project approach. Because both company has then got pretty strict discipline it is necessary to map them the make links between items like milestones, documentation, test phases.

There is therefore no quick fix and none of them, or very few of them could be implemented as part of the project because this scope of work was not identified in the original scope, and the change required cannot be fully implemented as part of the project.

What could be an outline action plan to implement those changes?

Suggested action plan

1. Review what I call the projects “topology”, i.e. identify the type of projects that company “A” has to deliver (this needs also to look into future projects). Identify projects and group them into groups.

2. Look at the “organisational process assets” – everything company “A” uses for its project and identify

3. Design for each group of project a custom (or not) delivery process (what are the main project phases, inputs and outputs, skills required, etc…). Look at what company “B” and others are doing in this area.

4. Identify actions needed to implement these new processes within the organisation. Needless to say: get backing up from management.

5. Implement it: update standard documentation and templates, recruit new skills, train people to the new processes, implement organisation changes. This is the hard part!

6. Finally, map with company “B” processes. At this stage this should be easy.