Earned Value Management – How to make it work for you
Using and Implementing Earned Value Management (EVM)
Earned Value Management is a means to produce objective periodic cost and schedule performance information throughout a project lifecycle. It is very different to simply looking at planned versus actual spend (£ / $) data.
The key purpose of EVM 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 and Oil & Gas, and many others today in the UK and elsewhere.
In simple terms, Earned Value is the contract (or authorised) budget value of work successfully accomplished on a project, usually to date. Earned Value data is commonly expressed using budget (and currency) values of the local environment (e.g. £ or $), which is one of the reasons why it has been misinterpreted in the past – it’s not a financial tool, it is a tool for project management.
So why is much of EVM data expressed in cost terms? The data is converted to a single unit of measure (e.g. £’s or $) so that planned and ‘actual’ cost and schedule data can be compared literally side by side, for example graphically as below, 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 sometimes be completely misleading. Hence the big focus in the earned value world on the word integration (of cost and schedule data and structures etc) – it’s critical to making EV work well.
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 summary task (made up of a number of activities) with a budget of 1000 hours to design a new widget, which we also expect to take 12 weeks to complete. At the end of week 6, we planned to have completed 55% (by effort) of the activities within the task, as we estimated those activities to consume 550 hours of our total budget – and those hours could be translated into cost (£ or $) data using average cost rates.
At the end of week 6:
- the planned value = total task budget * our planned percentage complete (55%) = 550 hours
- however, on measuring actual progress (perhaps using activities completed or drawings issued) we can calculate that we have completed activities worth 350 hours of the total task budget ***
- our actual expenditure of those same completed activities (in hours) was found to be 480
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 express schedule and cost performance (relative to plan) as ratios: cost performance index (CPI) and schedule performance index (SPI), where CPI/SPI of 1.0 indicates 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
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 in the project schedule, 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 EVM 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 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 a 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 onwards.
Email today to find out more on how to conduct a successful Integrated Baseline Review.
- On-site and Web Based Training – for in-house groups.
- Online – instructor led online EVM course.
- Consultany Support
- IBR Training Course
External Links, Downloads and References
For more information on the principles of Earned Value Management and how it is applied.
- US Department of Defence EVM
- PMI College of Performance Measurement
- NASA EVM
- Australian Department of Defence EVM
- 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)