I've come across Scott Ambler's statement from the Dr. Dobbs article again. Rereading it for the nth time, I'm still struck by the fundamental misunderstanding of the term "value" between Earned Value and Business Management. Scott proffers.
The fundamental problem with EVM is that it has very little to do with earning value and everything to do with managing against what often proves to be naive/fictitious schedules and estimates committed to far too early in the project. Although EVM is interesting project management theory, and I have no doubt that it may work in some non-IT domains, it proves to be a really bad project management strategy in practice for IT development projects.
From my Formal Logic book sitting on the dusty shelf, this is the Fallacious Comparison or the Improper Comparison argument. Flaws and Fallacies in Statistical Thinking, Stephen K. Campbell, is a nice source for these things.
Ignoring for the moment that fallacious statement of "naive/fictitios schedules." If there were such schedules as the baseline for EV, then the project is doomed from day one, and those creating and those accepting those schedules should be excorted from the building. Using bad management as the basis of an argument is, who should I say this - nonsense. Get real. Bad Management is just that, Bad Management.
The "value" in business value is just that value to the business. This is almost always measured in units meaningful to the business - money connected to some investment process. This value can be captured through many sources. Return on Investment, Internal Rate of Return, Balanced Scorecard Critical Success Factors, Key Performance Parameters. Things like that. Numbers that appear on the balance sheet. Numbers reported at board meetings.
The "value" in Earned Value is the "earned budget" from the baselined plan of the budget for the planned work. The Value in EV is simple. These numbers are most often money as well, but the color of that money can be different than the money reported on the balance sheet. Many times this money comes from allocated budget to the project - "blue" money as we say in our domain. It can come from "green" money (customer money) as well. Construction uses the term "hard money
It's just that.
- We budgeted $234,000 for a set of features (capabilities).
- We defined the period of performance over which we planned to spend this $234,000.
- Over this period of performance, we decided to measure physical percent complete in some form of tangible evidence.
- Let's say at 50% of the time we planned to spend $115,000 of our budget.
- We also pre-defined what it means to be 50% "done" at 50% of the time.
- When we get to that point in time - the 50% mark - we take an actual measurement of the physical percent complete, using the pre-defined tangible evidence.
- It turns out that evidence shows 45% of the planned 50% is actually done. It's not for the lack of trying, so we've spend the planned 50% of the budget. The $115,000 of the budget.
- Rats, we didn't "earn" what we planned to "earn."
Our Earned Value says:
BCWP = BCWS x 0.45 = $234,000 x 0.50 = $105,3000
our plan was
BCWP = BCWS x 0.50 = $234,000 x 0.50 = $117,000
We didn't make our plan. We underperformed against plan is a common plan. We're unfavorable to plan is another. With this information and the collection of the actual costs for performing this work - which may or may not be equal to the budgeted cost for the work, we can forecast both the schedule performance and the cost performance of the further project activities in units of "money."
There are issues with EV for sure. First is the schedule variance is measured in money. This is overcome by the Earned Value Engine (the system that produces the reports, maintains the Baseline, and other little details) using labor spreads and labor absorbtion rates.
But this performance is not connected to the "business value" of the tangible evidence of the outcomes from the work. Attempts to connect the Business Value with Earned Value is simply not the right paradigm. Don't do it. Stop doing it if you're thinking of doing it. Ignore the advice of those suggesting EV should be Business Value, or EV is not Business Value and that is a problem. It's not a problem, it's irrelevant.
This approach by the way is not uncommon, Michael Hatfield made a similar error in Earned Value Means Measuring Progress Against Plan Cost Not Actual Cost, Managing Projects with Earned Value, and The Value of Earned Value.
Why Is This Important?
As Agile enters to Enterprise IT domain and more so Agile entering the government funded Enterprise IT, Agile will start to encounter Earned Value guided by ANSI-748B. As this proceeds we really do need to get the facts straight when we start to discuss the applicability of Agile and EV to the same Enterprise IT project.
