Earned value is a measure that represents how much of a system has actually been developed, as opposed to how much time or how many resources have been expended. Earned value is a measure of the completed work expressed as a percentage of the budget planned for the completed work.
Earned value makes more effective performance measuring possible. For example, in Robert R. Kemps book "Fundamentals of Project Performance Management," [Ref 6]
the three principal data elements (budget, actual cost, and earned value) that impact performance are compared. The book states that, "Earned value
is the key element because it represents progress of work." The book goes on to define how earned value can be compared to the budget and actual cost data elements to more effectively measure project progress.
The difference between the budget and earned value calculated by subtracting budget from earned value provides a schedule variance.
A negative schedule variance indicates that less work was accomplished than was planned. It represents the value of the work that did not get done. Similarly subtracting actual costs from earned value provides a cost variance
. A negative value indicates that the project has incurred more cost than planned. "To be comparable, all three data elements must relate to the same work and the same time period." [Ref 6]
Figure 6 shows the difference between the planned budget and the actual progress. Without the earned value measure, this project looks like it is delivered on time and slightly over budget. Introducing the earned value measure shows that the project is actually behind schedule because not all the planned components were delivered. Also the cost overrun is larger. Comparisons between earned value, and percent of calendar time used can spot problems throughout all phases of the project.
Cost/Schedule Performance in Terms of Earned Value
Although earned value is often used on large government procurement projects, its application to software projects has been limited. This is due to the difficulty in determining the relative size (i.e., value) of the deliverables required to develop a system.
Testable requirements lends itself to solving the problems of applying earned value concepts to software, because it is flexible enough to size both the system and the progress to-date based on measuring the percentage of work completed. Paul J. Solomon, Northrop Grumman Corporation, recommends in his article, "Managing Software Projects with Earned Value"
, that "testable requirements be the primary basis for measuring earned value during the testing and rework phases of software development." [Ref 7]
Mr Solomon offers the following example to illustrate the concept of applying testable requirements to the earned value measure:
Assume that a work release of a software development component is budgeted with 500 hours for its completion milestone. Also, the work release includes 100 testable requirements with a targeted functionality of 80 percent. In other words, it is estimated that 80 requirements will be tested successfully and 20 requirements will not be tested successfully, and will be deferred to the next release.
If the release is delivered with 72 requirements tested successfully (90 percent of 80 requirements), then the earned value would be 450 hours (90 percent of the 500 budgeted). The shortage in functionality may result in closing the release and replanning the remaining work. In this example, it is recommended that the rework to attain the remaining functionality and the residual budget of 50 hours be transferred to the next planned work release.