Throughout the project management discipline, earned value has become synonymous with progress reporting. I suggest, however, that it is impractical for use in IT projects and propose alternative means for gauging and reporting progress of tasks/deliverables for IT projects.
Features of earned value
Without repeating the various publications on earned value, the key characteristics of a project that are required to make earned value an effective proxy for progress reporting are:
- The sub-task elements are identical in terms of cost and duration;
- The total number of sub-task elements are known at the commencement of the task; and
- The resources used to undertake the sub-task are easily exchangeable.
By way of example, let’s look at the classic case of earned value at work: building a brick wall. Here:
- Each sub-task element (laying a brick) is identical with respect to its time and cost to lay;
- The total number of sub-task elements (bricks to be laid) is known at the commencement of the task so that at any point in time one can determine the percentage of the task is complete (bricks laid ÷ total bricks) and the accrued value of the completed sub-tasks (bricks laid x cost of a brick) which, when compared with the expected amount of sub-task elements completed (planned bricks laid); and the amount paid so far for the task enables one to calculate the various earned value parameters; and
- The resource to undertake the sub-tasks (bricklayers) are generally in good supply and it doesn’t matter that much which bricklayer you use. As such, if one bricklayer underperforms, one can exchange him/her for another bricklayer to complete the task.
Relevance for IT projects
In the introduction we stated that earned value was an impractical means for measuring progress for IT projects. The reason is that tasks within IT projects do NOT have the classical elements necessary for effective earned value management. That is:
- Sub-task elements (for example, portions of computer code) are NOT identical in respect of time, effort and cost to produce;
- The number of sub-task elements (portions of computer code) needed to complete the task are NOT known at the commencement of the task/project; and
- The resources needed to undertake the sub-tasks are NOT exchangeable. Indeed, should one have to exchange a resource part-way during a task one generally has to start afresh.
Regardless of the metrics gathered one can not with any degree of certainty determine at any point of time during the project the earned value of the work already undertaken.
Alternative earned value reporting
Option 1: Do nothing
One approach is not to attempt to assess the progress of tasks within an IT project. Rather, one should just note whether a task is complete or not. While this is possibly the most accurate method, given the point about lack of exchangeability or resources noted above, it is possibly the least useful as far as reporting progress to project boards and the like.
Option 2: Approximate
One approach that we see quite often is where a task is assigned a set of miniature milestones, each of which is given a nominal percentage completion equivalency. For example:
- Design outlined—10%
- Design drafted—15%
- Design agreed—20%
- Code ready for review—70%
- Code ready for testing—80%
- Code successfully tested—90%
- Code implemented—100%
This approach provides more granularity than Option 1 but there are still large jumps between the completion of the design and the completion of the coding. Furthermore, the percentages assigned to each milestone are arbitrary and can be subject to challenge by stakeholders and/or the project board.
Option 3: Completion likelihood
Under this option, percentage complete is determined by multiplying the planned percentage complete and the likelihood of completion on time according the following formula:
OR for effort based recording:
OR for cost based recording:
This option provides an infinitely granular assessment of progress that if fully defensible when presenting to project boards and the like.