Earned Value is Necessary But Not Sufficient

    The use of Earned Value in construction, government, and defense programs is common practice. Some SOX IT organizations have discovered the benefits of EV. But using the EV variables - Cost Variance, Schedule Variance, Cost Performance Index, and Schedule Performance Index alone is necessary but not sufficient.
    The consumption of money, the passage of time, and the measures of Percent Complete must be combined with the assessment of the technical performance of the produced product or service. The units of measure in the Earned Value Standard ANSI/EAI-748B are Quantitative. They are also measured in Dollars. This is a problem in any work that is producing something new. Something that is not like laying bricks, painting airplanes, or pouring concrete. In the "development" world there are several other issues as well:

• The work is usually not repetitive, development programs are not like production or manufacturing.
• The baseline requirements may be changing over the period of performance of the project. Changing for all the right reasons. «If they are changing for the wrong reasons, that's another whole problem»

So, we need a Qualitative measure of performance for the project. Some notion of technical compliance or Technical Performance Measurement must be added to make Earned Value sufficient for project "management" work, not just project performance reporting. This is the difference between Driving in the Rear View Mirror and Driving out the front Windshield.
    Here's why:

When the end of the period of performance arrives, be it a week, a few weeks, but hopefully not more than a month or two, and the planned budget has been spent, and the planned duration has elapsed, was the produced produce or service "on specification?"

If not, then several things result:

• There is rework
• There is more money needed to complete the product or service
• The features need to be de-featured
• The customer needs to be convinced to take the product or service "as is"

In all cases more money and more time is needed (expect that last one) to get the product or service to the planned level of performance.
    So the Earned Value performance indicators are in fact not showing the actual state of the product or service. It is over budget (more money for rework, repair, or completion) and over schedule (more time needed to rework or repair). Or and this is a subtle outcome that comes home to bite you every time, the undelivered features get pushed into a future release, WITHOUT the associated budget or resources - since these have been spent on the current period of performance (iteration, release, workpackage, what ever).
    This is called mortgaging the future for the failures of today. It's called "we'll make it up in system test." NOT.

In the End Cost, Schedule and Technical Performance are Inseperable
    There are numerous posting, articles, "magic bean" purveyors claiming that the Iron Triangle is dead. Not True, Never was True, Can Not be True.
    If you spend the money, and spend the time, and the result is not 100% what was ordered (or at least within the tolerance of error), then it's going to take more money and or more time, probably both. And most probably this effort and money is unbudgeted and unplanned.
    So what to do?:

• Define what done looks like in units of cost, time, and technical performance
• Ask "how long a, I willing to wait before I find out we're late?"
• Never speak about effort, only speak about measurable results. Never speak about output, only speak about outcomes.

These outcomes and results, must have predefined units of measure for compliance with the planned result. These units must be meaningful to the customer as well.

One Last Comment
    There are some that equate agile burn down charts with Earned Value. This is not correct - unless the burn down charts include cost, schedule, and technical performance. Other than that, the two charts have two coordinates and lines that change shape with the passage of time, so that's the only way they are related.
    This is a popular myth in the agile community for some reason. And has been propagated by several "Thought Leaders," in error. It'd be wonderful if they were related, but they're not. So more work still remains to educate the both communities about the subtle behaviors of Earned Value in the presence of agile discussions.