I have managed many projects using Earned Value, and have been a Functional manager with many Cost Account Managers (CAMs) reporting to me. I have trained two engineering departments in different companies on its use, and even used it for my own purposes when not required by company process.
That said, here is the good, the bad, and the ugly.
When Cost Variance is used as an independent measurement tool, EVM is quite useful, and should be in every project managers bag of tricks. Even knowledge of the theory will help planning of the job.
It is a pretty independent measure of progress, and can be summed and compared against funding. It is a valuable way at looking at a project, and works best when combined with other methods. Projects that use this method in general end up closer to their budget than those that do not. It is easily switched on in most project management tools, and provides an independent and standard method that allows understanding of the results quickly. It also rolls up easily, such that the higher the level the roll up is, the more accurate the result is.
It is also a good way to reflect the value to the customer of the tasks at hand. If you are going into a design and 20 hours has been estimated for one task, and 1000 for another, this indicates a measure of the value of the two tasks. If you think that the numbers should be reversed, either you or the planner doesn't understand the problem. Engineers need to have some idea how much something is worth to the company and the customer, so they don't spend too much time perfecting something that will not add much value to the product. It is particularly useful if Technical Performance is critical (Make it go as fast as you can with 40 hours of labor).
And your cost performance index (CPI) provides an independent, sometimes unpleasant indication of how well you are doing. If Earned Value is implemented properly, you no longer have to do Estimates to Complete, which used to be a way of life before Earned Value was accepted. Using Earned Value, it is simple to a plan update, and the numbers can be rolled very easily. You always know how much effort is required to finish the job. Theoretically, anyway.
When used as a management method (rather than a reporting method), EVM is not so hot. Most engineers are not good negotiators, and program managers are experts at negotiation. Negotiation is what a program manager does all day. So a program manager can easily negotiate an engineer into a bad situation, without even trying. I have seen program managers base a whole program plan on something an engineer said when the engineer was simply trying to get out of the room, and back to “work”. Then the PM will string up the poor guy as events play out, making the engineer very defensive the next time, if there is one.
When a budget is allocated to a cost account manager, the experienced manager will use the entire budget to reduce the risk of their particular task – even if it can be done for far less. If someone bid four hours for a code change, would you hurry and do it in one hour? Or would you take the whole time to make extra sure? To the cost account manager, there is no incentive to accept risk, and return budget to the project, or to support cost reductions elsewhere by taking on more effort or risk. Since the metrics are determined by adherence to the plan, it is unlikely that the manager will do anything to reduce the cost of the project overall. Cost accounts inhibit interdepartment teamwork, I have seen it again and again. “ I have my budget, I can meet it, so why would I consider any plan changes whatsoever?” After a few go arounds, planners start cutting back the initial plan budgets to avoid this and creating large reserves – effectively defeating the EVM method.
I have beaten a budget many times, but never when formally using Earned Value. Underfunded tasks go over, and overfunded tasks simply spend their entire budget making sure. So you almost certainly overrun the budgets that are allocated.
Program Managers like treating the CAMs as isolated subcontractors. This is the world the PMs understand. But real innovation and schedule and budget smashing comes from interdisciplinary give and take. Once your budgets and CAMs are in place, this pretty much stops. So choosing the point in time to do this is very critical. Few in process improvements are realized using EVM.
I have seen many new updates to EVM to combat this effect, which is well known now. These revisions totally ignore that the problem was created by EVM itself.
Re-planning required for changes does implement a powerful discipline on plan changes, but assumes that the initial plan was perfect, and inhibits taking advantage of learning along the way. EVM plans are difficult, complicated, and require expensive engineers to create – engineers that would prefer to be doing something else. As a result, plan changes are rare, regardless of any opportunities or brick walls that turn up during development. Once budgets are allocated, they are rarely reduced or modified in any way. Just try it, and watch what happens. Lets say that something was to be done in software, but it turns out that a macro in an FPGA will work better and end up costing the program less? If you discover this after the budgets are allocated in EVM, good luck changing it. Never happen.
Earned value inhibits change, once underway – so does working to requirement documents. So they go hand in hand in locking in the program. So Earned Value and formal Requirements Management inhibits both scope creep (good) and actively working cost reductions and product improvements (bad). And the work to implement an in process product change, something that all successful products go through several times, is very ugly.
For serial design efforts, this works pretty well, if the job is staffed per the schedule requirements. The numbers tell you how your are doing. There are many ways of doing this, but EV gives you numbers that are backed up and universally understood. And they come out automatically.
This method provides metrics on individual performance that can be loaded into a tool like Fogbugz for prediction of future tasks.
If the task is not staffed per the dates needed, then Schedule Variance again provides an answer that is accurate - but not particularly useful, as explained below.
Simply put, Schedule Variance is not useful for parallel development efforts. If there is any parallelism at all in the project, then the summation of schedule variances has no meaning. Time is not fungible like money, unless all tasks are serial. There are many other, better ways to determine schedule performance and risk. Critical Chain, Fogbugz, Critical Path analysis. Use one of them.
If you must use EV Schedule Variance, identify the serial processes, and present SV on them as separate results.
Conventional EVM provides schedule performance based on work, not time. So you can tell if the resource completed the work in the number of hours predicted, but since it is not related to calendar dates or subsequent task links, this is only useful as a functional performance metric, and does not tell you whether you are ahead or behind schedule.
In other words, it will tell you if the person was able to complete the task in the right number of hours, but not whether he worked on the job before or after the deadline necessary to support the project schedule. It does quantify the persons efficiency. This may be useful to project future performance of the individual, but does not yield much information that is useful during the project.
The PMI Practice Standard for Earned Value Management mentions the use of time as a performance parameter, and this will provide much more useful information. That is, is the task being worked at the manloading needed to meet the schedule? This looks like a far better method to use in practice.