How to make earned value work on your project
Download the Companion Earned Value Analysis Presentation
EVA requires project managers to track project actual start and finish dates while comparing actual costs to the project baseline. By adopting EVA on your projects, you will reinforce good project management principles. This presentation provides an informative overview of the process.
Earned value analysis (EVA) appears to be a compelling technique to use on projects to better understand and manage performance. Companies embracing earned value prepare procedures and may provide some basic training. Project managers are then told to start using earned value, with the management expectation that project results will soon improve. Usually about a year later reality sets in. No improvement is achieved, project management costs are up, and people are complaining about all of the ‘extra paperwork.’
The company then either decides to drop the use of earned value or brings in a consultant to help figure out what corrective actions should be taken to get earned value ‘back on track.’ The presenter has been the consultant for companies, and this paper will cover the top ten items that must be present on any project for the use of earned value to be successful. Suggested actions that should be applied to ensure the project can easily and successfully use earned value will also be covered.
This paper will first provide a quick review of earned value terminology and formulas. Key metrics to monitor when using earned value analysis will be discussed. The top ten items needed on projects when implementing earned value will be covered in detail. By the end of this paper, hopefully, you will realize this paper really isn't just about using earned value analysis, but really covers the more important topic of having a complete and integrated project plan in place, which is a cornerstone before using earned value management.
Introduction and Background
So, how is your project going? This is a question project managers are frequently asked by management and the customer. One technique often used by project managers is to plot the plan spend curve and the actual cost expenditures curve as shown in Exhibit 1 below. The curve looks good, but what can you tell about the health of this project based on this graph? Is the project team accomplishing the planned work and doing it for less money? Or is the team behind schedule? The point is: this curve does not provide sufficient information to communicate how the project is going!
This paper will explain the terminology, formulas, and key metrics to monitor when using earned value analysis. In addition, the different techniques commonly used to evaluate progress will be described, along with the top ten items needed on projects when implementing earned value.
EVA Terminology and Calculations
Let's start out by clarifying the terminology associated with earned value, because many people incorrectly use the terms below interchangeably, and they are distinct. The terms are (Lukas, 2008, p.1):
- Earned Value Analysis (EVA) — a quantitative project management technique for evaluating project performance and predicting final project results, based on comparing the progress and budget of work packages to planned work and actual costs.
- Earned Value Management (EVM) — a project management methodology for objectively measuring project performance using an integrated schedule and budget based on the project WBS.
- Earned Value Management System (EVMS) — the process, procedures, tools, and templates used by an organization to do earned value management.
The point is that you can do earned value analysis calculations on any project, but unless you have complete earned value management in use on your project, it will be extremely unlikely to obtain correct results. In order to easily use EVM, your organization really needs to have an earned value management system in place.
Earned Value Definitions
Earned value analysis uses three key pieces of project information: the planned value, actual cost, and earned value, which are shown in Exhibit 2 below. The first two terms are not new, they are the plan spend curve and the actual cost expenditures curve many project teams have been using for years.
Planned Value (PV) is the budgeted cost for the work scheduled to be done. This is the portion of the project budget planned to be spent at any given point in time. This is also known as the budgeted cost of work scheduled (BCWS).
Actual Costs (AC) is simply the money spent for the work accomplished. This is also known as the actual cost of work performed (ACWP).
Earned Value (EV) is the percent of the total budget actually completed at a point in time. This is also known as the budgeted cost of work performed (BCWP). EV is calculated by multiplying the budget for an activity or work package by the percentage progress:
EV = % complete x budget
For example, if a Work Package is the installation of 500 new computers in an office, and 350 computers are installed, the Work Package progress is 70% complete (350/500). If the budget for this Work Package is US$200,000, the earned value is US$140,000 (0.70 x $200,000).
An effective method to show the relationship between PV, EV, and AC is shown in Exhibit 3 below.
Earned Value Calculations
With the terms PV, EV, and AC defined, along with how to determine progress, some key calculations can easily be done, which provide important information on how the project is doing. The formulas for earned value calculations are:
|• Cost Variance: CV = EV – AC||• Cost Performance Index: CPI = EV/AC|
|• Schedule Variance: SV = EV – PV||• Schedule Performance Index: SPI = EV/PV|
A CPI value of 0.83 implies that for every project dollar spent, only US$0.83 in earned value was accomplished. A CPI of less than one and a negative CV indicates project cost performance is below the plan.
A SPI value of 1.05 implies that for every dollar of work the project had planned to accomplish at this point in time, US$1.05 worth of work was actually done. A SPI greater than one and a positive SV indicates more work has been accomplished than was planned. Note how this is worded, since a SPI > 1.0 does not necessarily mean you are ahead of schedule! You can accomplish more work than planned by working on non-critical path Work Packages. You need to look at the critical path to determine whether you are ahead, on or behind schedule.
Exhibit 4 shows the Planned Value, Actual Cost, and Earned Value for a project. Note that when the planned spend curve is compared to the actual spent, it shows a variance of +US$15. An uneducated observer is likely to conclude the project team is accomplishing the planned work and doing it for less money.
However, analyzing the project using earned value gives a different picture. Reading from the graph shows a cost variance of -US$5 and a schedule variance of -US$20. The project team has accomplished (“earned”) $US30. However, at this point in time, the schedule plan was to accomplish US$50 of work. Therefore, the project team is US$20 behind in schedule work. In addition, the actual cost for the work accomplished was US$35 and the budget for the work accomplished was only US$30. This means the project team has overspent for the work done. The bottom line Earned Value Analysis clearly demonstrates this project is in trouble!
On projects, determining realistic progress for Work Packages (WP) can be difficult, but is essential for ensuring the earned value analysis is accurate and meaningful.
So, how much work was accomplished? This is a common question project managers ask team members. Too often, progress is reported in a qualitative manner. One frequent expression is: “I'm almost complete” or “I'm 90% done.” After weeks of hearing that same progress report, the project manager begins to suspect that just maybe the person responsible for the Work Package really doesn't know how much progress has been made.
Quantitative techniques are obviously much better than qualitative (subjective) techniques for measuring project progress. One thing to keep in mind when measuring project progress is that it's an estimate! Many people spend too much time trying to generate a very exact number, especially when using quantitative techniques. The key is to make it ‘fit for use.’ Don't spend exorbitant amounts of time determining exact numbers on a small Work Package. Focus your efforts on the larger value Work Packages. Remember that measuring progress is an estimate, and that the inherent errors on each Work Package will tend to cancel out as you roll up the progress numbers to the project level.
Since the types of Work Packages on a project vary, no single progress reporting method is suitable. The seven most common methods for reporting project progress are described below (Lukas, 2002, pp 2–3).
Quantitative progressing techniques are:
- Units completed — tasks that involve repeated production of easily measured pieces of work, when each piece requires approximately the same level of effort.
- Incremental milestones — Work Packages (WP) that can easily be divided into a series of tasks handled in sequence. The work is divided into separate, measurable tasks, and completing each task is considered achieving an ‘incremental milestone.’ Progress is earned only when reaching each milestone.
- Start-finish — used with low value and/or short duration activities without readily definable intermediate milestones. Either no or some limited progress is ‘earned’ when the activity is started, and 100% progress is earned at the completion of the activity.
Qualitative (subjective) progressing techniques are:
- Level of effort (LOE) — used when it's very difficult to measure what work was accomplished for the budget spent. My preferred approach with LOE assumes the progress is equal to the actual costs divided by the budget. For example, if the project manager's budget on a project is US$20,000, and US$10,000 has been charged to the project, then the progress is calculated as 50%. However, some publications use a different approach and set the EV = PV.
- Individual judgment — used for complex work not easily measured by other methods. Even though this is subjective, getting multiple opinions on the work accomplished by knowledgeable team members helps establish a reasonable estimate on progress.
Two other progressing techniques commonly used are listed below. They can be either quantitative and/or qualitative, depending on how they are used. The techniques are:
- Combination techniques — good for complex work occurring over a long time period and use two or more of the other progressing techniques. An example would be installing a building foundation. The excavation progress would be units completed (cubic yards of earth removed), the formwork incremental milestones, and pouring the concrete start-finish (0%/100%).
- Apportioned relationship — has a direct intrinsic performance relationship to another discrete Work Package, which is called the ‘measurement base.’ For determining progress, the apportioned Work Package progress is the same value as the measurement base Work Package.
Forecasting Using Earned Value
SPI: A Barometer on Schedule Performance
Exhibit 5 shows a useful graph, which is a plot of the project SPI versus time. A SPI greater than 1.0 implies the team is accomplishing more work than planned, and a SPI less than 1.0 indicates the team is accomplishing less work than planned. You need to be careful when using SPI, because you really can't determine the project health without knowing how the team is doing against the critical path in the project schedule. A team can achieve an SPI > 1.0 by working on non-critical path activities. Therefore, it is possible to have an SPI > 1.0 and be behind schedule! You need to look at the project float to determine the complete schedule performance for the project.
Exhibit 5 is from an actual project (Lukas, 2003, p. 7), and like many projects, the SPI for the first few reporting periods is less than 1.0, since the team is in start-up mode and project activities are just being started. A SPI of less than 1.0 can happen early in the project when start-finish progressing is being used for many of the Work Packages. However, if the SPI does not move toward 1.0 after the first few reporting periods, it is an indication of possible schedule problems and therefore probably time to start taking corrective action.
Using CPI To Determine Final Project Cost
The Cost Performance Index is an excellent indicator of the cost efficiency for completed work. One main use of CPI is forecasting the final project cost. Before listing the common formulas used, a few terms need to be defined (PMI, 2008, p.184):
- Estimate to Complete (ETC) - the expected additional cost needed to complete the project.
- Estimate at Completion (EAC) - The expected total cost of the project when the defined scope of work is completed.
- Budget at Completion (BAC) - The total approved budget when the scope of the project is completed (including any project contingencies).
Most techniques for forecasting EAC include some adjustment of the original cost estimate based on project performance to date. The three common formulas are:
- EAC1 = AC + (BAC - EV). This formula is called the ‘mathematical’ or ‘overrun to date’ formula in some textbooks. However, using the term ‘overrun to date’ is misleading because the project could be under on costs and ahead of schedule. This formula assumes the plan will be met for the remaining work (CPI = 1.0), and yields the most optimistic EAC when a project is not doing well.
- EAC2 = BAC/CPI. This formula is called the ‘cumulative CPI’ in some textbook and assumes the entire project will be done at the same cost performance (current CPI does not change).
- EAC3 = AC + ((BAC - EV) / (CPI x SPI)) or BAC/(CPI x SPI). This formula considers both cost and schedule impact on the EAC, and usually yields the most pessimistic EAC for a project not doing well. Note that these two calculations are not equivalent! From my experience, the ‘simplified’ formula works as well or better on many projects.
Exhibit 6 shows the relationship of BAC, ETC, and EAC. Note that the project cost contingency is not spread as part of the Planned Value curve. Contingency is a provision in the project plan (extra cost and time) to mitigate the typical (but undefined) unplanned events that happen on projects — to cover ‘known unknowns.’ When calculating the ETC and EAC, some thought should be given as to whether an adjustment is needed for the remaining contingency.
To Complete Performance Index
Another useful evaluation tool is the ‘To Complete Performance Index’ (TCPI), which provides a forecast of the required performance level, expressed as the CPI, which must be achieved on the remaining work in order to meet the project financial goal. The TCPI calculation can look at either the current authorized budget or the current estimate-at-completion.
TCPI provides a “sanity check” for the project manager on whether the required CPI for the rest of the project is realistically obtainable. Of the two formulas, looking at the CPI required to complete the project based on the estimate-at-completion is probably more meaningful. The two TCPI formulas are (PMI, 2008, p.185):
Research has shown the cumulative CPI will stabilize as early as the 20% completion point of the project, and “researchers found the cumulative CPI does not change by more than 10% once a contract is 20% complete; in most cases, the cumulative CPI only worsens as a contract proceeds to completion” (Christensen, 1994, p.19). This may be too pessimistic, but once 30% completion is reached, it's reasonable to expect the CPI won't change by more than 10% unless the project is stopped and re-planned. For example, if the project CPI is 0.80 at 30% completion, the best you can expect is a final CPI of 0.88, which means your budget will overrun by at least 13.6% (1/0.88).
Making Earned Value Work
There are many project maturity models in use today and many use a five-level format, where level 1 is chaos, level 2 is some rudimentary project management techniques in use, but inconsistently across projects, and level 3 is having a process and procedures in use across all projects. If your organization is not at least at maturity level 3, you should not attempt implementing earned value across the organization. Here is an analogy. If you are just learning to dive, you would dive off a board close to the water surface to learn the basics. If you're new to diving, you would not start with the 10-meter diving height unless you are looking to fail! The same applies to the use of earned value analysis. If you don't have a project organization with a maturity level of 3 or higher, trying to apply EVA will only lead to failure.
Listed below are the top ten items needed on projects when implementing earned value:
- Project Requirements
- Work Breakdown Structure
- Change Management Process
- Integrated Project Plan
- Correct Schedule and Budget
- Schedule and Budget Contingency
- Contingency Management
- Cost Collection System
- Accurate Reported Progress
- Management Support
1 – Project Requirements
A project is undertaken to deal with a specific opportunity or problem. Therefore, every project has a specific objective such as ‘meet new Environmental Protection Agency (EPA) air emission standards.’ Requirements define the project product — what will be created and used by the client as a result of doing the project.
Unfortunately, all too often a client starts a project, and engages a project team who immediately starts working with the client to define the scope of the project. For example, a client may hire a project team to install a water spray scrubber to meet EPA emission rules, and the project team immediately jumps into action and starts the design of equipment, structural supports, and ductwork without stepping back to ask the more pertinent question of whether the equipment will really solve the problem. In this case, the problem is reducing specific air emissions and the customer already picked the ‘how’ (the water spray scrubber), which may not meet the real need because requirements, including types of contaminants and final concentration levels, were not defined.
Not having project requirements can be a delicate issue and you obviously have to be sensitive in how you broach this subject with the client. As Exhibit 8 shows, without requirements, the link to developing a quality WBS is broken. In order to help ensure a successful project, the project team must work with and support the client in documenting the project requirements. Some people may object to this, believing that the role of the project team is to deliver the requirements as defined by the client. But keep in mind that nobody looks good on a bad project, and that's the probable outcome if the project proceeds without documented requirements.
In some cases, the client may have some partial requirements and issues a request for proposal (RFP) so the project team can deliver the product the client wants. However, in many cases, clients do not have project experience, or are too busy with other work assignments to take time to fully develop requirements. The client may also list the ‘how’ instead of the ‘what’ in the RFP. For example, stating a 1,000 square foot (SF) cafeteria is needed is a ‘how,’ and instead should have stated the ‘what’ of needing a cafeteria for a peak of 100 people. The danger here is that the project team may deliver the functionality, cost, and schedule and still have an unhappy client, who now has a product that really isn't what they need. A 1,000 SF cafeteria probably won't suffice for 100 people and most likely will not meet local occupancy codes. So, who do you think will get blamed? The project team has to invest the time to work with the client to ensure the requirements are completely captured and accurately reflect what is needed to meet the project objectives.
2 – Work Breakdown Structure
The WBS is the key project plan document. As shown in Exhibit 9, without a complete WBS, the schedule and budget will not accurately reflect what it will take to successfully complete the project. A good technique when responding to a RFP is including in the proposal scope of services the project WBS. Unfortunately, most often what you see is a long narrative on what the service provider will do for the client. A narrative that provides a detailed description of what will be done can be useful, but it's even more important to include the WBS!
The other issue that can occur is when the project manager prepares a WBS, and the team really doesn't see the value and provides at best minimal cooperation. The project manager must ‘talk up’ the value of using the WBS and make it clear this will be the foundation document for the project. Otherwise, the WBS won't be maintained and quickly becomes obsolete.
In addition, the WBS should be checked against the requirements to ensure requirements are not missed. One method to avoid this is using a WBS dictionary and including a field that lists the requirements covered by each WBS element. The work breakdown structure (WBS) should also be checked to see if it includes deliverables that do not relate back to the requirements. If this occurs, the items may not be needed and should be considered for deletion.
3 – Change Management Process
There can be several issues here, the most serious not having a change management process in use for the project. Change management must be addressed in the project plan, and includes the procedure for handling scope and variance changes, the forms to record and evaluate change requests, the review and approval process for changes, and the process to ensure changes are incorporated into the current plan so the earned value calculations remain relevant.
The second potential problem area can be changes that occur but are not recognized. The issue can be design team members who decide to add scope items to ‘improve’ the final product and don't realize there will be added cost and/or time incurred during execution. The best way to catch this is for the project manager to get out and talk to team members to hear what's going on and identify where ‘extras’ might be creeping into project scope.
The change management process should be used to allocate contingencies and reserves to project Work Packages. When a change is approved, the budgets for the affected Work Packages are changed:
Current Work Package Budget = Original Budget + Approved Changes
With the computer software available today, making changes to the PV spending curve is very easy. When a change is approved, the plan has changed and the PV spending curve should be modified.
4 – Integrated Project Plan
Once your WBS is established, the project schedule can be prepared. One frequent problem is the project team creating schedule tasks that do not relate back to the WBS. The project schedule should have tasks corresponding to each WBS Work Package. However, there can be a few exceptions to this rule. For example, it may not make sense showing a schedule task for ongoing project administrative functions, such as safety inspector.
The project estimate is also prepared once the WBS is established. By definition, the Work Package level is where work is authorized, performance monitored, and costs collected. The project estimate should have for each Work Package a statement of work (what's expected) plus an authorized budget. It's also important to have performance responsibility for each Work Package assigned to just one individual. This makes the obtaining of status information much easier for the project manager.
By preparing the project schedule and estimate that matches back to the WBS, you have created a project plan that gives you cost and schedule integration! The next step is to measure how much progress has been accomplished on your project. Once the progress is determined, you will be able to easily perform earned value analysis on your project.
5 – Correct Schedule and Budget
The author reviews schedules for clients on a frequent basis, and frequently the schedule is incorrect. Common mistakes include breaks in the schedule logic, improper relationships, and misuse of constraints. Budget and estimating errors can also happen for numerous reasons, including miscommunication, quantity errors, or use of incorrect rates. The key here is having a quality control process in place, which should include review of project plan deliverables such as the schedule and estimate by experienced project personnel. Mistakes happen, so it's important to have a process in place to catch as many mistakes as possible before the project plan is finalized.
6 – Schedule and Budget Contingency
Most projects include a cost contingency, which is defined as an allowance for ‘known unknowns’ such as rework, estimating uncertainty, unforeseen events, or problems. When you prepare your planned value (PV) spending curve you really don't know when (or if) you will spend the contingencies. Therefore, the PV spending curve for the project should reflect the project sub-total without contingencies or other allowances such as inflation. One good method for showing available project contingencies is drawing a horizontal line for the approved project budget on the cost versus time graph. The difference between this line and the PV spending curve at project completion is the remaining cost contingencies (refer back to Exhibit 6).
How many people preparing a schedule include a schedule contingency? The recommendation is to include a task called “Project Contingency” just before the project complete milestone, as shown in Exhibit 10 below.
A main reason for having a schedule contingency is to buffer changes to the completion date (Lukas, 2007, p. 3). When a schedule is updated, the completion date will probably change based on actual progress. However, project customers can find it frustrating when the project team gives them a new completion date every time the schedule is updated. A better approach is to adjust the project contingency task duration up or down based on actual progress, which will result in the project completion date staying constant. With this approach, the project completion date is only changed when the project team deems it appropriate.
7 – Contingency Management
Another good tool to use with change management is the contingency drawdown curve, shown in Exhibit 11 below.
This gives an indication regarding how much cost and schedule contingency remains on the project (Lukas, 2003). In the example shown, extrapolating the schedule and cost contingency indicates the project will use up all of the schedule contingency well before completing the project, but the cost contingency probably will not be completely used based on performance to date.
8 – Cost Collection System
Earned value will not work unless you can obtain accurate actual costs for your project. Companies with multiple cost systems in use make cost collection and reporting extremely difficult. A limitation of cost systems is that they only show actual costs for invoices received and/or paid. Any work that is contracted and any purchased items will typically have invoices that lag by a month or more from when the work was actually done. Therefore, using information from your cost system for earned value calculations can be very misleading! To get around this problem, use an “adjusted actual cost” column for reporting actual costs (AC). Adjusted actual cost uses the actual cost from your cost system, plus your estimate for outstanding invoices for work accomplished, which are called accruals. The project plan should include the procedure for reporting costs. This includes the frequency of reporting costs and how ‘adjusted actual’ costs will be determined and reported.
9 – Accurate Reported Progress
Earned value is considered a ‘quantitative technique’ for evaluating project performance. However, it really hinges on how progress is reported. Earlier in this paper the various progressing techniques were described. Earned Value works best when the progressing techniques are quantitative, such as units completed or incremental milestones. One important gauge is to look at how much of the project is using the level of effort (LOE) progressing technique. If LOE is 10% or more of the total budget, there is a good chance you really are not getting an accurate measurement of the project progress.
Using qualitative techniques for reporting project progress also allows for team bias to creep into the reported progress. Reporting progress that is behind plan brings unwanted attention to a person as being a ‘problem.’ The obvious easier approach is to make sure your reported progress is on or ahead of plan. However, this may just postpone the inevitable negative news if you really are behind plan.
10 – Management Support
The final item needed to make earned value work is management support for the process and not having management pressure to influence the reported results. Management may have various reasons for wanting to influence what is reported. It can be company targets for the quarter that ‘must’ be met related to project incentives, or just the normal human behavior of trying to avoid ‘bad news’ in the hope the problem performance can be reversed.
Earned Value Standards
In 1967, using earlier work by the U.S Air Force, the Department of Defense (DOD) issued the Cost/Schedule Control System Criteria (C/SCSC), which imposed 35 criteria on a contractor's management control system for cost or incentive contracts. The C/SCSC is often referred to as earned value, but EV is only one of the many techniques embodied in the criteria.
In 1995, the National Defense Industrial Association (NDIA) started rewrite of the criteria to make it more compatible with the needs of private industry. The result was the American National Standard Institute-Electronic Industries Association ANSI/EIA 748 standard. The NDIA subcommittee received approval from ANSI and the standard was issued in June 1998. The DOD accepted the ANSI/EIA 748 standard for application to all DOD projects in August 1999.
Reading this standard will provide you with a better understanding of implementing earned value on projects. The ANSI Standard 748 covers earned value management system (EVMS) criteria and contains 32 criteria in five groups as listed below.
- Group 1: Organization (5)
- Group 2: Planning, Scheduling and Budgeting (10)
- Group 3: Accounting Considerations (6)
- Group 4: Analysis (6)
- Group 5: Revisions (5)
Earned value is the most effective technique for providing information on project performance. It communicates scope, schedule, and cost status information to project stakeholders. The most common reason given for not using Earned Value Analysis is “I haven't got the time.” So here's the good news: if you have prepared your project plan properly, Earned value analysis takes essentially no additional effort! The key is having complete requirements and a good project plan, which includes the work breakdown structure (WBS) to fully document scope and a schedule and cost estimate that are integrated into the WBS. Having these in place means you are using earned value management! On the flip side, if your project does not have these items in place, doing earned value analysis will give you inaccurate and misleading results and won't be worth the time and effort.
Properly used, earned value is a flexible process that provides timely information on the project's health. Effective use of earned value concepts can provide a competitive edge in successfully delivering projects. Give it a try on your next project!
Christensen, D. S. (1994). Using Performance Indices to Evaluate the Estimate at Completion. The Journal of Cost Analysis, Society of Cost Estimating and Analysis, p. 19.
Lukas, J. (2008). Earned Value Analysis: Why it Doesn't Work, AACEi Annual Meeting, Toronto, Canada.
Lukas, J. (2007). Is Your Schedule Correct? Common Scheduling Mistakes and How to Avoid Them, PMI® Global Congress 2007—North America, Atlanta, Georgia.
Lukas, J. (2003). Introducing Earned Value Analysis into an Existing Project, Inside Project Management, ElementK Journals.
Lukas, J. (2002). Making Dependable Project Process Measurements, Inside Project Management, ElementK Journals.
Lukas, J. (2002). Take Control of your Project with Earned Value Analysis, Inside Project Management, ElementK Journals, April 2002.
Lukas, J. (2002). Tips for Effectively Using EVA Regarding Contingencies and Actual Costs, Inside Project Management, ElementK Journals.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® guide) — Fourth edition. Newtown Square, PA: Author.
© 2012, Joseph Lukas
Originally published as a part of the 2012 PMI Global Congress Proceedings—Vancouver, Canada