Medecins Sans Frontieres Doctors Without Borders

Join the Community

Project Manager

Australia's online resource for project management professionals


Reporting earned value on IT projects

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:

  1. The sub-task elements are identical in terms of cost and duration;
  2. The total number of sub-task elements are known at the commencement of the task; and
  3. 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:

  1. Each sub-task element (laying a brick) is identical with respect to its time and cost to lay;
  2. 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
  3. 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:

  1. Sub-task elements (for example, portions of computer code) are NOT identical in respect of time, effort and cost to produce;
  2. 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
  3. 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:

Earned value for IT projects

OR for effort based recording:

Earned value for IT projects

OR for cost based recording:

Earned value for IT projects

This option provides an infinitely granular assessment of progress that if fully defensible when presenting to project boards and the like.

Guy Wilmington is a leading portfolio, program and project manager dedicated not only to meeting his clients' needs through P3 Management Services, but also to building the profession by sharing his insights on various topics. He has twice been awarded the title of ACT Project Director of the Year by the Australian Institute of Project Management (AIPM).
has written 11 articles for us.


Need a Gravatar (the image next to your comments)? Visit

Comments from the community

  • Hi Guy,

    Your Completion likelihood formula are as defensible as the unsubstantiated guess as to the probability of completion used in the calculation (‘completion likelihood’ in the formula). In other words there is no validity in the formulae; it is based on a contemporary guess (which is no better than assigning an arbitrary % complete).

    Your middle option (Weighted Milestones) is fully defensible (but not necessarily correct) because the percentage allocations are determined before the cost baseline is established and before any work is done and the allocations should accurately represent the estimate. The consequences are schedule performance is an apples for apples comparison, cost performance may show localised variance until the activity is complete if the distribution was incorrect. Remember no AC or EV is accumulated until the milestone is signed off as accomplished and localised variations tend to self-correct (these are allocation errors, not performance variance for the whole work package). This option is useful on iterative builds (or sprints).

    For most small work packages and/or activities where there is no derivative to allow the use a quantitative ‘brick’ type of measure (typical in most IT projects) the arbitrary percentages work perfectly well, 0/100 for indeterminate tasks such as testing (ie when you don’t know you are finished until you are finished – the last test can fail…) and 50/50 for everything else.

    By ‘small’ I mean something less than 5% of the time or cost of the project (preferably both) is a small work package. Provided all three components are accumulated on the same basis the EV performance information is again perfectly valid.

    There’s more on this at