It’s not earned; it’s accrued. It’s not value, it’s cost. Big difference.
There are many proponents of the concept of “earned value” for software projects. Many of them are consulting companies and those that work on US government projects. I think earned value management (EVM) is bunk. The concept has merit but the implementation is fatally flawed.
EVM is a way to measure software project progress by comparing the amount of money spent to date to the amount projected and to the work completed. If you are spending less money than planned for the work being delivered, you are under budget. If you spend more money than planned for the work output, you are over budget.
You could be ahead of or behind the scheduled time. EVM’s focus is budget not time or quality so you’ll need to determine schedule and quality status using other metrics.
You can see why the EVM concept appeals to consulting firms. They want credit for the work completed, that is, value delivered, so they can send invoices and receive payments. EVM works great for them. What about the rest of us?
“Value” and “Cost” are not the same thing.
Problems begin with the term “value”. Many software applications have little or no value until they are largely complete. At times, they have no value even then due to changes in the marketplace or the underlying technology.
Whether real value is created or not, costs are accrued. The project cost keeps going up regardless of the value of the deliverables. Measuring cost is comparatively simple. Measuring value is guesswork.
Another problem is the degree of done or the level of completeness. Software components are designed, written, tested, integrated, verified, validated and accepted. How much value is accrued at each stage? Truth is, there is no repeatable way to know. If you wait until the ‘accepted’ stage, the earned value curve will have a classic hockey stick shape. That’s useless.
Projects accrue value above or below the accrued costs. Individual components of the software accrue value in various ways. Some components accrue high initial value while others accrue value more slowly over time, if at all.
Software value is not the same as cost. Tracking projects costs is a good idea. Estimating earned value is a complex and flawed means of measuring project progress. Don’t rely on it. Have you used EVM?
You can’t come late to the party then complain about the terminology. The “value” in Earned Value is Budgeted Cost for Work Performed. It is exactly that the budget that is earned for performing the work. Scott Ambler tried this approach as well and is equally mis-informed
The ‘earning” if of budget not business value. The business value, assuming you can actually measures that in some way on the balance sheet, is a separate and distinct thing, not related with EV. Never was, never will be.
The “value” in earned value is like asking the teenager – if I give you $20 to mow the lawn, and you finish the mowing (and other little details) in the time allotted on a Saturday morning, then my $20 was “earned” to 100%. I got what I paid for,
The “emotional” value of having a clean and green lawn (according the Stephen Covey) is separate and distinct from the exchange of the $20 from my hand to our sons pocket.
if he didn’t mow all the grass, weed wack all the fence line, edge the front sidewalk, and put the mower back with fuel in the tank within one day (sun up to sun down), then the $20 I paid him (my budget) did not get “earned” the BCWP
BCWP = BCWS x “physical percent complete.”
It’s as simple and as complex as than. Not “business value,”
If you will take the time to look at the formula for BCWP = BCWS x Physical Percent Complete you’ll see that Actual Cost is not in that formula.
Cost and Value are not the same as you say. They are separate in EV
To follow up on Glen’s explanation, looking at this from the perspective of a contractor, earned value is based not on my costs, but on my selling price to the client. (Their real or perceived value of the products/services I am selling)
So if you are a software developer, your “earned value” is what you sell your products or services for, not what they cost you to produce. (Hopefully, if you are to remain in business, your costs are lower than your selling price) Now, what the “value” of your products or services to your client is probably not known by you, nor ever will be. All you need to know is that your clients/customers see sufficient value in the products/services you provide that they are willing to pay the price you are asking. And that to stay in business, your cost must remain below your selling price.
BR,
Dr. PDG, Jakarta
http://www.build-project-management-competency.com
I have used evm since many years and I think it’s a very good technique. The concept of “value” is objective and well defined, the main characteristic to oversee projects.
A lot depends on context. So both the original post and the comments are correct.
There are two issues here.
Firstly, let’s assume that estimated effort turns out to be 100% correct. Then from the point of view of the “customer” of the project, EV represents delivered value only when there is a linear relationship between activity progress and value delivered. If the activity is to process a set of discrete items (e.g. to clean shoes or to debug independent programs or to relocate widgets to where they will be used) then this is the case. If you get 50% of the way through you have processed 50% of the objects so you have delivered 50% of the value, and EV is therefore an excellent proxy. But when there is a non-linear relationship, EV is a poor proxy. Say for example that the relocation of widgets example was actually not focused on getting the widgets to the right place but on freeing up the place where the widgets are right now so that a tenancy agreement could be terminated. Then no value is delivered until 100% of the widgets have been moved.
But secondly, let’s assume an inaccurate estimate of effort. (And as with most IT projects, let’s assume an underestimate.) Now suppliers love EV as a basis of charging customers. You can charge a customer and recover all your costs as you incur the costs. Once you hit 100%, assuming you aren’t able to walk away with the money, leaving the customer in the lurch, then there are two options. Maybe you then complete the work at no charge. Well you have enjoyed a fantastic cash flow advantage – you’ve been paid at a faster rate than you have delivered “value” from a customer perspective (which would be activity progress). Or maybe you negotiate an increase in the price of your service to pay for the outstanding work. So either way, you are “underpenalized” because you get your reward before you deserve it. Under this scenario, if I was the customer the term “earned value” would r-e-a-l-l-y grate because I would not see it that way, I would see it as accrued cost.
Robert, this is a great insight. Thank you for sharing! Your logic is a justification for using multiple metrics when determining project state. There is no single metric that can us how well (or poorly) we are doing.
Robert,
I know this is late. But a few corrections here may be helpful.
(1) ” EV represents delivered value only when there is a linear relationship between activity progress and value delivered.” Not true. EV measures the percentage of “value” earned from the planned budget. The simplest EV calculation is EV (BCWP) = PV (BCWS) x Physical Percent Complete. I planned to “earn” $100 at this point for 10 drawings each budgeted for $10. I complete only 8 drawings on the day I planned to complete 10, so I only get 80% physical percent complete and therefore “earned” $80 of my planned $100.
If you get 50% of the way through and have processes 50% of the objects you only get 50% of the value IF you planned 50% of the budget for those 50% of the objects.
(2) Your second conjecture is also wrong. Cost recovery is am Actual Cost (AC)(ACWP) calculation. “earning the value,” is NOT connected to the cost of that value BCWP = BCWS x Physical Percent Complete.
You may want to look for some guidance on how EV “actually” works at sources where EV is defined. This way, your two conjectures will be improved with the facts.