After hours of unsuccessful internet trawling, I am looking for comments and advice regarding Earned Value calculation.
As far as I am aware, there are two main accepted methods of calculating Earned Value (or Budgeted Cost of Work Performed):
1) %Complete * Budget At Completion
2) Sum of Planned Work completed so far
The first of these takes the %Complete figure as calculated using the formula %Complete = Actuals (to date) / Estimate At Completion. The second involves adding together the planned (budgeted) value for all completed tasks. I am aware that the second method can also be amended to reflect pro-rated and weighted %complete for each task but for the purposes of my project, these must be excluded. I also include the MS Project type method in the first description.
My first impression of these formulae is that the first one gives a true indication of value based on effort. So, for example, if a task is 99% complete, this is recognised as being “virtually complete” as far as Earned Value goes. The second method works on the principles that a) you haven’t done it until you’ve done it, and b) until and unless you’ve done it, it’s not worth anything.
In principle, I can see the obvious merits of both of these methods. For example, many concurrent deliverables may all be 99% complete and given only a very low amount of additional effort is required to complete all of them, it is better to indicate this than to ignore it. In this case, the first method is better as earned value will be much closer to reality (i.e. 99% instead of 0). However, take a single major deliverable that is 99% complete but has no use unless it is finished. If at the last moment it does not get accepted and requires major alteration, it remains useless (and therefore arguably valueless) until the issues are resolved. In this case the second method is better as it does not set any expectation.
In large programmes with significant parallelism, the distinction between which method of calculation is better becomes far less clear and becomes far more dependant on the granularity of the plan on which earned value is being calculated. For example, if Earned Value is calculated at the lowest level of task across a programme, the first method may inflate earned value in the event that a lot of rework is required. Similarly, the second method may result in large bursts of productivity as each project delivers its respective (final version) deliverables which suddenly go from 0% to 100% for the purposes of earned value calculation. If it is calculated at a more visionary level (perhaps using rolled up plans as part of a larger plan) then value earned in each project may not be recognised at all using the second method but if matrix reporting is required (e.g by release, by project, by domain/stage) the calculation at such a low level becomes very difficult and the first method once again proves far easier.
As far as I can surmise, the high level advantages and disadvantages are as follows:
WORK COMPLETED METHOD
Advantages –
- Does not assume value until each task is confirmed as complete – useful for waterfall tasks and projects where value is paramount (e.g. where instalments are paid linked to progress)
Disadvantages –
- Does not provide realistic progressive information for concurrent (parallel) tasks
- Becomes very complicated for large programme and projects, especially for “production line” programmes that include matrix reporting (and planning) structures
% COMPLETED METHOD –
Advantages –
- Provides a better indication of progress for longer term tasks and especially parallel tasks
- Far simpler to calculate for large programmes and projects
Disadvantages –
- May inflate earned value when rejections take place and additional work is required
This is not an exhaustive list but covers some of the main points.
If anyone can share any brilliance regarding this topic I would be most interested and grateful.
