Projektstyrning - Kunskapsområden - Utbildningar/seminarier - Litteratur - Kunder - Allianser - CV - Länkar - Kontakt

EARNED VALUE - an introduction

Earned value is a technique that originated within US Department of Defense (DOD) to get control over all the projects they had going, mainly through outside contractors. Cost overruns and late delivery was the norm, rather than the exception. Many projects were never delivered.
Earned value is a technique that will make it possible to track the results and to make estimates of final cost (cost at completion) and time of delivery.
Basically the technique compares the tasks that were planned to be completed at each point in time during the project to the actual completed tasks at that time. The measurement is usually in monetary terms (units of currency), as this is most often the common denominator within a project with different kinds of inputs (time, material etc).
The actual completed tasks are compared to the planned tasks and the associated cost of these tasks is compared to the planned cost of these tasks.
The basics with an example
Say for example that you are running a project that has been estimated to be finished in 12 months and a total cost of one million.
Reviews are scheduled every three months.
At the first review after 3 months your plan was that three tasks should have been completed to the planned cost of 300,000. However, you have at that time only achieved 2 of the 3 tasks. The actual cost, however, is on plan, that is you have spent 300,000.
Superficially this does not look to bad, or does it?

Using Earned Value terminology the facts are:
   • PV (Planned Value, the planned cost of tasks planned to be completed at review time): 300,000 
   • EV (Earned Value, the planned cost of tasks actually completed at review time): 200,000
   • AC (Actual Costs, the total cost incurred at the time of review): 300,000
From these facts the following can immediately be derived:
   • SV (Schedule Variance, that is the difference between the planned value (PV) and earned value (EV) achieved): EV-PV = 200,000 – 300,000 = -100,000. This means that the project is behind plan by 100,000.
   • SPI (Scheduling Performance Index) = EV / PV = 200,000 / 300,000 = 0.67 or 67 %. This means that we have only accomplished 0.67 of every monetary unit that was planned.
   • CV (Cost Variance, that is the difference between the earned value (EV) and actual costs (AC) incurred): EV – AC = 200,000 – 300,000 = -100,000.
   • CPI (Cost Performance Index) = EV / AC = 200,000 / 300,000 = 0.67 or 67 %. This means that we have only got 0.67 for each monetary unit that was spent.

These calculations can be used to determine both the Estimated cost At Completion (EAC) and when the project will be finished.
If the project continues with the same cost efficiency rate of 67% it means that the project will need 50% more budget to complete the work. The Budget At Completion (BAC) was 1,000,000. With a CPI of 0.67 the EAC (Estimated cost At Completion) will be BAC / CPI = 1,000,000 / 0.67 = 1,500,000.
In the same way the project will take 50% longer time, that is 18 months as the original plan was to complete the project in 12 months. (12 / 0.67 = 18). This time it is the Scheduling Performance Index (SPI) that is used to calculate the date of completion.
The estimations of final cost and when the project will be finished is in this case done under the assumption that the track record so far will continue in the future. Normally a deeper analysis must be made to determine if anything unusual has occurred to impact the current status and if this was a one time occurrence (e.g. there was a fire in the office) or if it is probable that similar events will happen in the future also (wrong estimates, more work, bottle necks etc).

Ten musts to implement Earned Value in all projects
According to the texts on Earned Value there are some a number of Musts to implement Earned Value. The top 10 of these are (see Fleming and Koppelman, 1998[1]):
1 Define Work Scope. You must define 100 % of the project’s work scope using a WBS.
2 Create an Integrated Bottom-Up Plan. You must combine critical processes. Including defined scope, schedule, and estimated resources, into an integrated bottom-up plan of detailed measurement cells called Control Account Plans (CAPs). The performance measurement will take place within the detailed CAPs and the total project’s performance is the summation of what was reflected in the detailed CAPs. In essence, each project CAP is a subproject of the total project.
3 Formally Schedule CAPs. Each of the defined CAPs must be planned and scheduled with a formal scheduling system. This scheduled work will constitute the projects PV (planned value).
4 Assign Each CAP to an Executive for Performance. Each of the defined CAPs must be assigned to a permanent functional executive for performance. This assignment effectively commits the executive to oversee the performance of each CAP.
5 Establish a Baseline that Summarizes CAPs. A total project performance measurement baseline must be established, which represents the summation of the detailed CAPs. Must include all defined CAPs plus any management (contingency) reserves.
6 Measure Performance Against Schedule. Periodically, you must measure the project’s schedule performance against its planned master project schedule.
7 Measure Cost Efficiency Against the Costs Incurred. You must periodically measure the project’s cost performance efficiency rate, which represents the relationship between the project’s earned value performance and the costs incurred to achieve the earned value.
8 Forecast Final Costs Based on Performance. Periodically, you must forecast the project’s final  cost requirements based on its performance against the plan.
9 Manage Remaining Work. You must continuously manage the project’s remaining work. The improvements in performance must come from future work.
10 Manage Baseline Changes. You must continuously maintain the project’s baseline by managing all changes to the baseline.


[1] Quentin W. Fleming and Joel M. Koppelman, CROSSTALK The Journal of Defense Software Engineering, July 1998, pp 19-23