Clarity of Purpose

When the word Earned Value is used in the same sentence as Software Development, it appears to trigger a visceral response in some. There many definition of Earned Value on the web. Most a flawed in some way. Some are seriously flawed, some are wrong. Along with this are many mis-understandings of what Earned Value is, what it's purpose is, and how it is applied to project. Some of this mis-understandings are just that. Some are mis-informed, so appear to intentionally be mis-informed. Meaning "I don't want to know how it actually works, I want to use my definition because it supports my agenda."

So let's start at the top. Applying EV to software projects works, has worked and is working as we speak. Not observing EV working on software projcts, doesn't mean it doesn't work.

Now if you can't make it work, haven't ever seen it work, or don't know how to make it work, or don't know anyone that can help you make it work, or aren't convinced you're even interested in making it work, then don't try EV on your software project. Stop reading right now, go back to what you were using.

It may well be your project is not ready for EV. It may be you're not ready for EV. It may be you and your project are not right for EV. You may never be right for EV.

But don't assume that EV doesn't work for software.

What Should Management Know About Earned Value?

First the "value" in Earned Value is not the same as the "value" in business value. The "value" in Earned Value is not the same as "story points," Use Cases, the value discussion between the agile development teams and the customer or any notion like that.

The Value in Earned Value (BCWP) is how efficient are we spending the Budget (BCWS). Earned Value make no judgement of the "value" to the customer. This "value" (the business value) is very subjective. Very much at the whim of the market, the financial decision makers, the politics of the organization, and all sorts of other "human" foibles.

So What Does Earned Provide Us?

1. Visibility to the budget efficiency - If I spend a dollar, do I get a dollars worth in return?
2. What work is on the critical path and how is the budget efficiency for that work?
3. Where is the budget assigned and how is it being spent?
4. What corrective actions are needed to put the budget efficiency back on track?

Staining the Deck EV Example

Earned Value measures are the measures of "earned" a value compared to the "budgeted" value.Here's how that works in a real live example at our house in Colorado.

If I budgeted $1,200 for the staining of our deck. And this job was to be performed in 3 weeks, starting April 25th and end May 13th, how can I tell if the deck staining project is on budget and on time. The actual deck is about 900 square feet, so let's look at an Earned Value paradigm of this project.

If I naively assume the staining job is linear in both cost and work effort, than at the end of the first week, there should be 300 sf of staining complete and the contractor should have consumed $400 of labor and materials (we didn't separate labor from materials, since this is a naive example).

I'll add one more twist to this deck straining from real life here in Colorado. I want to use the deck while it is being stained. So when the first third of the deck is stained (assuming is dries really fast) I want to sit on it over the week end. I don't want the deck un usable for three weeks. We've got a Kentucky Derby Party, Saturday May 7th and a few neighbors coming over.

So I come home from the office on that first Friday May 6th (assuming he started on Monday) to see the following:

• 250 sf was stained
• $400 of labor and materials was accured. (EV needs accrual accounting)

As an EV Program Controls Manager, what can I learn?

• We're right on budget (planned $400, spent $400)
  
• We're behind on the work by 50sf (planned 300 sf, did 250 sf)
  

But actually we are over budget, because the square footage planned to be complete is 300 sf for a cost of $400. Unless the contractor is going to do the remaining 50 sf for free, it will cost more, So I'm both over budget and behind schedule.

He's behind schedule, because the remaining 50 sf needs to be done sometime and over budget because to do that remaining 50 sf, someone has to pay and it ain't me. The Kentucky Derby Party members are going to be short 50 sf of party space. Since neighbors on both side are Program Managers and work EV projects, they're going to ask "what's your get to green plan, you're behind schedule and over budget, pass the Pinot Noir, and what horse did you pick?

So what does this mean to an IT project?

Let's not assume we care about the software development method. OK, we like Scrum, let's use Scrum. I like Scrum and use it where ever possible.

But let's put on our business management hat. I have a budget of $120,000 for developing an application and budgeted 3 months for the work. This application has planned for 90 features - all relatively the same effort. That pencils out to be something like 60 work days (assuming 20 per month which is not always the case and why MSFT Project males a crappy EV engine), and that pencils outs for two people to be 960 works hours (assumes 8 hours days) and $125/hour per person per day. These are well paid developers, cause we're in Boulder and they are retired IBM'ers and expect to be paid what they are worth. (I can see IBM Global Services from this deck).

So now I come home from my office to have a look at the application (with all the naive assumptions of linear work effort and linear work productivity). And I've assumed that what is produced at the end of the first month I can actually put to work in my day job (not the Derby Party).

But what do I find?

• The code that was developed is missing some features that I was told were going to be there after the first month. Let's say there 1,200 features for the whole system, and using our naive assumption 30 of those would be in place, 100% usable at the end of the first month. Just like those agile developers assured my they would be. Remember I have $120,000 for this little application and 3 months to get it done.
• Well the status review and demonstration shows me I have 25 features. I got to pick which ones didn't make it into the release, just like a good Scrum product owner would.
• My retired IBM'ers spent the planned number of hours and didn't raise their rates, so there is an invoice sitting on the table on my newly stained deck for $40,000.

But now I do the math.

• Budget looks like what I was told. $40,000 per month for 3 months (20 days per month) for $120,00 Budget at Completion (BAC).
• But where's my 30 features. I know I agreed they could drop 5 of the them when they did their weekly reviews. But how are those missing 5 going to get done? The developers are working at their planned pace, not to fast, not too slow, but just as planned. And not they're 5 features behind schedule, and on budget for the 30 features, but not for the 25 features.
• Each feature is now diluted (reverse dilution actually). If I pencil out the cost per feature of the planned features it comes to $1,333.33 per feature. But with only 25 features delivered they actually cost $1,411 oer feature at the end of the first month.
• Well that's a problem. They've spent what they planned to spend, but under delivere by 5 features. So to supply the 5 features, which I agreed to postpone but drop, they'll have to spend more money.

Now at the 2nd week we have similar results:

• First instead of the planned 30 features (again assuming niavely they are all equal, with equal work effort), they need to produce 35 features.
• But since the budget for the last week was spent as planned, they'll have to do those 35 features for the planned budget of $40,000 which means they will get paid only $1,142 per feature instead of the expected 1,333 per feature. This is called "margin erosion" in all the businesses I've worked.
• Those great developer caught up and did those 35 features and kept on budget - they only spent $40,000 in the month as planned, so now we're back even on time and on cost.

But since we're doing accural accounting in the best GAP manner, they have "under absorbed" on cost to the tune of $190 per feature to date after the 2nd accounting period.

At the end of the 3rd month, there is another situation.

• All the planned 30 features for the 3rd month are done on time and for the agreed on cost of $120,000.
• But when we pull together all the features\, there is one of those pesky "system integration" problems, that requires for more work. Of course this work takes money.
• We now have over spent, we're late - not by much - but a few days, and finally I get all the features I wanted for a little bit more than I planned and a little bit late.

That's how we use Earned Value. But who cares, you say? You could use Story Points in the same way. You could monetize the story points you say. yea you could do that, but here's the rub. There are other aspects of Earned Value missing from the simple Story Point measures.

• Earned Value provides forecasting calculations like the To Complete Performance Index TCPI), that tells you how much you need to improve your efficiency to keep the schedule.
• The Estimate At Completion (EAC) calculation that will forecast what this is going to cost if you keep going the way your going.

Yes, you could do the same with Story Points. And that's the Point. The units of measure of Earned Value are Dollars (currency). If and only If (IFF) you use the Earned Value formulas, the agile development processes of Scrum, with Story Points, charts (burn down, burn up doesn't matter) with the proper scales looks just like those sen in Earned Value.

Here's the Punch Line

Once the development team doesn't deliver the planned outcomes for the planned cost at the planned time, something has to give. Either we're late against the plan, or we're unfavorable to the budget, or both. Now that we know this some corrective action can take place. But the critical piece here is we know it.

Unlike the "burn down" charts found in some agile team which tracks features and not money, EV tracks both schedule variance and the cost variance. Project Managers and those providing the funding are interested in both.

Earned Value and Agile Software Development - at the work management level - are a match made in heaven. Look here for examples of how to do this Successfully Integrating Agile with Earned Value Management and Earned Value + Agile = Success.

Don't buy the mis-informed notion that EV can't be used on IT projects. It's not true. I say that with the conviction of an EV practitioner on software intensive programs using agile methods for development.

But unlike those little dead red herrings tossed out there to argue with, EV projects and for that matter any project that would be considered credible must have - and I emphasize MUST - answer the following 5 Immutable questions:

It's number 5 that agile can measures in "story points," but that is just part of the measurement.

• What is the impact of the "missed" work? Work that was planned but not delivered at the planned time?
• What is the cost of this "missed" work. If the work is going to be done, but the budget was spent on the previous work and the "missed" work didn't show up, who's going to pay? How much over budget are we?
• How much will is cost to get caught up with the work we missed?
• Add to that "rework," how much will it cost in total?

One straight forward way to do this is to apply the 11 criteria (out of the 32 found in ANSI-748B) to your project.

The Final Piece of Advice

• Don't apply Earned Value and Earned Value Management if you don't know what you're doing. You'll fail. You'll then enter that realm of bitching about how EV can't be applied to IT projects and join the ranks of those failing to ask favorite Talking Heads line from Once in  Life Time (1984)  "how do I work this?" (along with "that's not my beautiful wife!")
• Don'y apply Earned Value is you don't have a credible understanding of what "done" looks like, have some kind of budget for done, know what your productivity for getting to done is, can measures progress toward done in some units meaningful to the decisions makers, and have some sense of what the hell is happening on the project on a short term basis to answer the question how long am I willing to wait before I find out I'm late?
• And for God's sake don't even let anyone talk you into proceeding with a naive/fictitious schedule and estimate committed to far too early in the project, and then blame EV for problems.
• Get real, grow a pair, and be a credible project manager and look around to see how Earned Value is being applied on software intensive projects with success. Ask question, explore a little, seek advice from practitioners of this craft and stop listening to the un-informed.

And as we say here in the space and defense business.

OK we're done for now, everyone back to work.

I know this has been a long post. EV is simple, but mis-understood, mis-applied, and many times simply used to counter what ever arguement someone is makig for their tool or process in the absence of understanding that EV has tangible benefits when applied correctly.

Here some more background

• The Simple Problem of Schedule Performance
• A Gentle Introduction to Earned Value Management
• Techncial Performance Measures