What is EVM?
It is a means to provide objective measures of cost and schedule performance throughout a project life-cycle. It is very different to simply looking at planned versus actual spend (£ / $) data.
The key purpose of earned value management is to inform a project team’s decision making and to highlight cost and schedule issues early, allowing time for recovery action to be taken. The principles behind the method represent best practice in planning and control in project-based management.
EVM was first adopted by the United States Department of Defense in 1967 and today is at the heart of the project control systems, for example, by the governments of the UK, USA and Australia, to help manage the performance of contractors engaged on major development contracts. It is also widely used in other industries such as Construction, Oil & Gas and others in the UK and elsewhere.
In simple terms, Earned Value itself is the contract (or authorised) budget value of work successfully accomplished on a project. Earned Value data is expressed in budget terms (using the currency of the local environment), which is one of the reasons why it has been misunderstood in the past – it’s not a financial tool, it is a tool for project management.
So why is much of EVM data expressed using budget values (even schedule data)? The data is converted to a single unit of measure so that planned and ‘actual’ cost and schedule data can be compared literally side by side, for example graphically as below. This is to inform our understanding of ‘performance‘ against these two primary goals of project management. Traditional methods of representing project data (such as simply comparing planned to actual spend) often contain no aspect of performance, which at best can be a significant weakness – at worst it can even be completely misleading. It’s the main reason for the big focus in the earned value world on the word integration (of cost and schedule data structures etc) – this is critical to making EV work.
In the above chart, the task (or project) is behind schedule and over budget, often expressed as Cost Variance (Earned Value less Actual Cost) and Schedule Variance (Earned Value less Planned Value). This can also be expressed in other more useful ways, as described in the worked example below.
The following shows the basics of how EV works in practice, using a simple one task example:
Imagine we have a work package to design a new widget (made up of a number of activities) with a budget of 1000 hours, having defined all the activities and estimated the effort (i.e. hours) required for each. We expect the work package to take 12 weeks. At the end of week 6, we planned to have completed 55% of the workscope (by effort), i.e. 55% of the total activities within the work package, as the sum of the hours of the activities planned to be completed at the end of week 6 = 550 hours. The 550 hours can also be translated into cost (£ or $) using average cost rates. This is what is referred to as planned value or BCWS (at end of week 6).
At the end of week 6 we could perhaps find:
- the planned value (BCWS) = 550 hours
- however, on assessing actual progress (using activities completed, known as the 0/100 method) we can calculate that we have only completed activities worth 350 hours of the total task’s budget***
- we find our actual expenditure of those same completed activities to be 480 hours.
In earned value language, this gives us Planned Value of 550 hours, Earned Value of 350 hours, and Actual cost (in hours) of 480.
What can we derive from this? A number of things: at its most basic we are behind schedule (earned is less than planned) and we are over budget (actual is greater than earned). We can also do a number of other things such as calculate cost and schedule performance indices: cost performance index (CPI) and schedule performance index (SPI), where a CPI/SPI of 1.0 equals performance to plan; less than 1.0 is performance less than plan.
In this example, our CPI would be (350/480) 0.73 and our SPI would be (350/550) 0.64. Such metrics could be produced across a project, say at work package level.
*** N.B. there are many ways of measuring progress and calculating EV – this is just one example – and a full discussion of this topic itself is outside the scope of a simple worked example (we favour 0/100 over all other methods to assure maximum objectivity) .
So, what do we do with this EV data?
In the past, it has often been mistakenly believed that EV data is only produced for financial reasons or for reporting to customers – this is totally wrong. The most important use of this data is by all those in a project team who are responsible for managing work (using EV data via structures such as the work breakdown structure) to understand their cost and schedule performance, throughout the project lifecycle. The aim is to highlight (cost and schedule) issues early, thus providing the maximum time to minimise their impact and provide a realistic opportunity to develop recovery plans where necessary.
The second thing we can do is to use the data to provide a means of forecasting out-turn on projects – the most commonly used being:
- Estimate of costs at completion (for the total task: EAC), which for the above example = total budget: 1000 / CPI (.73) = 1,371 hours !!
- Estimate of forecast total duration for the task = current plan: 12 weeks / SPI (.64) = just under 19 weeks (although this is a very rough estimate that should be reviewed against project schedules for work remaining)
and for those who dismiss the above, history is littered with projects that displayed (performance) characteristics similar to the above – very very few came in on budget or on schedule (without significantly relaxing the scope of work) – if you know of one please let us know.
The production of EV data requires that a performance measurement baseline, drawn directly from the project plan, comprising of the following:
- The Performance Measurement Baseline (PMB). The PMB consists of a time-phased aggregation of the (human and material) resources (expressed in budgetary terms) required to execute the work scope of the project, usually in a Work Breakdown Structure (WBS) and within which we would perform EV analysis. The PMB is often shown as a cumulative X/Y curve (as in the above diagram) – this is the ‘baseline’ against which cost and schedule performance is compared using EVM metrics. The full PMB should also include and define how Earned Value will be measured and taken through the life of the project.
- Objective Measures of Progress progress must be assessed periodically – there are many ways of doing this and the important rule (backed up by a mass of evidence) is that the more subjective the methods are, the less reliable the EV data is likely to be and the greater room there is for unwanted ‘surprises’ downstream – (we support complete objectivity in progress measurement, and can show that this is possible. Many other methods have been proposed over the years, often being too complex or leading to unreliable EV results).
- Actual Costs – Labour and Materials: Actual cost data must then be gathered against by the elements in the PMB – this requires that business systems and processes enable useful and timely capture of actual cost data, via the structures that are employed in the EVM system – not something that falls naturally from all business systems.
EV was not developed simply to report status to customers – it may be used in this way, but if this is the only way it is seen, a huge degree of the value of using the method will be lost.
The objective is to embed EV data into the practice of daily management of the project, leading to an improvement in decision-making based upon an informed analysis of real status against cost and schedule goals, at the working levels of the project.
For organisations implementing Earned Value Management, the challenge lies not just in the mechanics of the method, but more often in the cultural change required to underpin an EV based project control system.
Additionally, when most organisations first attempt to use EVM, they typically find that it highlights weaknesses or gaps in the project planning and control processes and capabilities. For example:
- a robust baseline needs to be developed as soon as possible after contract award – this task alone challenges many organisations – and then it must be maintained
- the planning process must identify all major project deliverables clearly, within the PMB, not just the functional effort assumed to be required to deliver a project
- objective measures of physical progress must be assessed routinely
- business systems and processes need to provide data in a timely manner (e.g. costs) and need to be structurally compatible with the needs of the EVM system
- and finally, let’s be honest – decades of evidence shows that when allowed to, people will find limitless numbers of ways to manipulate EV results to hide bad news, usually in the mistaken hope of giving themselves time to make the ‘issue’ go away – typically what this does is to reduce the focus, resource and effort on the issue, quite possibly until it becomes irreversible. The good news is that this can be spotted quite easily and prevented, if we choose to.
The above question has raged in some environments for many years. EV gives objective measures of status against the cost and schedule goals of a project – there are no more primary or fundamental goals in project management. Assuming an organisation follows the principles that underpin good practice in EVM systems, it provides important data to project teams, without which teams can operate in a vacuum regarding their performance, or even worse, they could operate in an environment of false optimism that does not see the level of challenge or issues in their project, until it is too late to make a real impact on the same – something that occurs far too often in projects.
Earned Value is not just worth it – it is a fundamental tool to being in control in large scale risky development programmes.
Customers increasingly require contracts to be pro-actively controlled to assure delivery on time, to budget and to specification. Customers look for confidence in the project status information being supplied, and are increasingly achieving this by defining contractual agreements that require EV to be used by their suppliers.
The major considerations include:
- defining and communicating your EV requirement including the incorporation of the Integrated Baseline Review process
- assessing the merits of payment by EV
- determining appropriate data access and reporting requirements
- defining and agreeing on performance review cycles and processes
The purpose of an Integrated Baseline Review (IBR) is to assess a set of EV processes and to confirm the completeness and fitness-for-purpose of the project’s Performance Measurement Baseline. Where it is important to have confidence at an early stage that the baseline plan for a project is realistic, an Integrated Baseline Review may be deployed.
If you are required to perform an Integrated Baseline Review, it will require preparation and the attention of those who will participate in the review. As a minimum, the following should be agreed / prepared before the review:
- agreement on the specific objectives of the review and exit criteria
- the scope and timing of the review and how it will be conducted
- documentation and personnel to be made available at the review.
IBRs are often preceded by some form of readiness review – given that an IBR should be held as soon as possible and practical following contract award, the scheduling and resourcing of these activities needs to be considered urgently from contract award onward.
Email today to find out more on how to conduct a successful Integrated Baseline Review.
Like to see how we can help you with EVM:
- EVM Glossary of Terms
- Online – instructor led online EVM course.
- On-site and Web Based Training for groups.
- Slideshare – Worked Example
External Links, Downloads and References
For more information on the principles of Earned Value Management and how it is applied.
- UK MoD Commercial Policy Guideline No.8 – Earned Value Management – Commercial Issues (Nov 2004)
- US NDIA ANSI 748 – A Standard for Earned Value Management Systems – Intent Guide (Jan 2005)