Earned Value Management System (EVMS)- a Qualitative Overview
Wikipedia defines the EVMS as
Earned value management (EVM), earned value project management, or earned value performance management (EVPM) is a project management technique for measuring project performance and progress in an objective manner.
The wiki page is chock full of details, that you should read. However, this article is more about a qualitative overview of the PV,EV and AC curves, and what an executive should be able be infer at a glance, without calculations.
Essentially, a project has 3 critical aspects, its scope, timelines(schedule) and costs. A project manager has to carefully balance the three legs of the stool to keep the project upright.
One of the challenges with maintaining this balance is that the 3 parameters have different units. Scope is unitless, Schedule is measured in the units of time and the cost is measured in units of currency or person hours(for projects where human cost is the largest chunk).
The promise of EVMS is that it converts everything to the same unit and the interplay is visible in the same chart, also known as the PV,EV,AC chart.
Let us first see a dummy project to see what it entails, and then see the various combinations and the possible interpretations. Note that the interpretations are situation dependent and the chart alone can not replace the insights that someone on the ground may have. However, aided with the chart, the communication becomes data driven and decisions become objective. So, let’s go!
Creating the chart
Planned Value
Roughly speaking, planned value is the value of tasks assigned at planning. The key assumption here is that the effort/cost of the task is proportional to its value. Also assuming that the coefficient of proportionality is one.
For a dummy project with 10 tasks planned as below:
Plotting the end dates on x axis and the cumulative planned value on the y axis, we get:
Earned Value
Now the project starts, and the tasks start proceeding. As is normal, things start to deviate from the plan (in terms of schedule at the moment). The value that we earn on completing a certain task (this is defined to be the same as the value assigned during the plan, i.e. the planned cost in the table below), with the value as estimated at planning time:
Plotting the above with x axis as actual end dates and cumulative planned value as y axis, we get:
Actual Cost
The efforts/costs for the project needed to complete the respective tasks may be as below.
The last 2 columns are the actual efforts that were needed to complete the project tasks.
Initial Interpretation when the Project is ongoing
Suppose it is day 17, and you see a curve like this:
Projecting EV linearly, to the point where it gets to the 32 units of value required to finish the project, you get the estimated delay at completion. like so:
To get to the value that was expected on day “17”, the estimated extra time required is the current delay (Schedule variance, SV)
Similarly, projecting the AC curve to the same date as expected completion gives you the AC at completion, and the difference will give you the cost variance at closure.
Formally:
Qualitative Interpretation
Since there are 3 lines, there are 6 relative positions of the lines with respect to each other. With regards to trend, actual graphs will be combinations of these 6, but that is beyond the scope of this article.
Please note that I assume that the plan is correct and interpretation is based on considering the PV line as reference. Errors in planning are not considered, because of non-specificity (that can be an excuse for almost any deviation)
The project is running behind schedule, but team is working more efficiently than expected. This is because the EV is below PV (late project), but AC is below EV (high efficiency).
The project is running behind schedule. More over, the team is working less efficiently than expected (or are stuck solving an unexpected issue). This is because the EV is below PV (late project), but AC is above EV. However, the efforts spent are still lower than planned (AC lower than PV), so there might be some resource contention thrown in.
The project is running behind schedule. More over, the team is working less efficiently than expected (or are stuck solving an unexpected issue). This is because the EV is below PV (late project), but AC is above EV. The efforts spent are higher than planned (AC above PV), so the project manager may be killing his team members to catch up, but they still can’t; or are stuck in an unexpected issue.
Finally, project is ahead of schedule as EV is above PV. The AC is below PV, and so the efforts are much less than expected to achieve even PV, let alone a higher EV. Padding in estimation during planning? Super efficient team? Cutting corners? New discovery that gives a short way to do the same thing?
The project is ahead of schedule as EV is above PV. The AC is above PV, and so the efforts are slightly more than expected to achieve PV, but achieved more a higher EV. Padding in estimation during planning? Efficient team? cutting corners? New discovery that gives a short way to do the same thing? Some other project got deprioritized?
The project is ahead of schedule as EV is above PV. The AC is above EV, and so the efforts more than expected to achieve PV, but achieved lower than expected EV. Tyrant Project Manager? Padding in estimation during planning? Efficient team? cutting corners? New discovery that gives a short way to do the same thing? Some other project got deprioritized?
And finally, a different use case
The project was running as if in an ideal world, and suddenly, EV and AC flatlined…. What happened here?
One possible reason is that the project team was reassigned to some other cause for a time ‘t’ and all progress stopped. when resuming work, it is expected that the EV/AC curves will follow a parallel trajectory to the PV curve!
The curve above is indicative of not enough granularity in planning. If your tasks are months long, or 100s of person hours, you lose the chance to see any progress on the chart, and by the time you get to it, it may be too late to recover. The standard recommendation is to keep tasks to about 18 person hours (for software and technology projects).
Let me know in the comments if there are other interpretations or combinations that I may have missed. Needless to say, the possibilities are endless, and I have just scratched the surface here.
