An accessible and comprehensive introduction to Earned Value (EV). [It] makes extensive use of graphical charts, instead of mathematical formulae, and is suitable for readers with no prior knowledge of the subject. Key topics are the fundamental principles of EVM, its history and current usage, and special considerations for applying it to software development projects.

Enjoy!

• Earned Value in two sentences: Earned Value in a Nutshell
• Introduction, from a Agile perspective: Agile Charts
• Introduction, from a classic Earned Value Management (aerospace/DoD) perspective: Software Tech News article (was also re-printed in the PMI’s Measurable News)
• A comprehensive 30 page article, compatible with both the agile and traditional approaches to Earned Value.
• Video: “An animated graphical introduction to Earned Value” -  I’ll be publishing a link shortly.  Check back here in July or subscribe to this site’s RSS feed to be notified when it becomes available.
• “Starter kit” spreadsheet (released with the kind permission of my employer): Starter Kit
• Guidelines for successfully using the starter kit: Rules of the Green Line
• Finally, if you’re interested in an agile project management tool with automatic earned value, check out Tactyle.  I designed it according to the principles described in this blog.

Earned Value teaches us that the only valid measure is to compare actual cost with actual progress.   This may seem a bit like “comparing apples with oranges” – we seem to be comparing things that are not the same.  The trick is, before we compare them, we convert them both to the same numerical units.   That’s what makes the comparison possible and enables all the predictive goodness of EVM.

(Thanks to Glen Alleman for inspiring this brief post, with his comments here).

The basic principle

When you’re part way through the project, you want the green line to give an accurate trend.  That way, you can used it for planning and making decisions.  If it was significantly inaccurate, then it wouldn’t be much use to you.

Actions

So, how do you make sure that it is as accurate as (practically) possible?  Here are suggestions that I’ve come up with, after about 5 years with this style of “lite” Earned Value.  These suggestions are specific to software development projects using agile(ish) processes.

1. Aim for an approximately linear project structure.  In other words, try to have each month of the project containing approximately the same mix of design, build and test.  Don’t load all the design into the front of the project (waterfall style) because that undermines the predictive power of EV.  EV predictions work best when the nature of the work is roughly the same in all stages of the project – something that is (approximately) achievable with agile processes.
2. Know your test strategy.  From an EV perspective, the nicest approach is to achieve the agile ideal of spreading the testing work uniformly throughout the project. But I recognise that some projects, to a lesser or greater degree, do need a User Acceptance Testing phase at the end.  That can be dangerous from an EV perspective, because it offers a temptation to consider things “done” even when their quality is not known.  In the worst case, this can get ugly: you think you’ve finished everything, and both your red and green lines are at 90-something percent.  But then you start UAT – which unearths lots of problems. As you fix the problems your cost keeps on rising, up and up way past 100%.  Ouch!  That’s why it’s much better to test as you go, if you can.  If you can’t, put aside a bucket of time and money to accommodate defect result ion during UAT.
3. A task only counts towards the green line when it’s complete.  Partially complete tasks don’t count at all.  This is the most conservative approach and therefore, I strongly believe, the most realistic.  If, as discussed above, you must have a UAT phase at the end, you should still do at least some testing at the time that you develop the feature, so you know whether it’s “done”.
4. The green line is always based on estimated task sizes.  You must NEVER tweak the Earned Value numbers for completed tasks to match how long they actually took.  That completely screws things up, because now your past is measured in “actuals” but your future is measured in “estimates” – so you lose all ability to predict the future from the past. To re-iterate, the green line must be based on estimated task sizes.
5. If you add new scope during the project, make the estimated sizes for new tasks consistent with tasks already in the project.  E.g. say you are measuring task sizes in “points”, and you are thinking of adding a 10 point task. When you add it, do a little sanity check to see, “Is it really the same size as the 10 point tasks that we already have?”.  You want all “10 point tasks” to be roughly the same size, regardless of when you added them to the project.
6. If you split a task, reallocate its original points to the sub-tasks. For instance if you divide an epic user story into several smaller ones, make sure that the total point value of the small stories equals the value of the original epic.  I.e. chopping up a task mustn’t change the total number of points in the project.
7. Don’t worry about “derived requirements”, don’t even track them.  Derived requirements are those (hopefully) little things that are not stated in the planned scope, but which turn out to be essential to implementing it.  I often visualise them as little gaps in the stated requirements – implicitly and unavoidably part of the project, but not foreseen in our planning. For Earned Value purposes, the easiest way to handle these is to not track them at all.  Just implement them as necessary, without entering them in your Earned Value system/tool/spreadsheet. For a discussion of why this makes sense, see my STN and Encylopedia articles.

I hope you find these suggestions useful.  “Lite” approaches to Earned Value are still evolving, and are not yet well documented.  So, suggestions for improving this list are most welcome.

• Link to online copy. As of 27 June 2011, you can purchase just the EV article (without having to buy the whole encyclopedia.) 
• Hard copy of the whole encyclopedia (about 120 articles on other topics, in addition to my one on Earned Value.  Each article is about 30 pages and all are peer reviewed by experts in the relevant field.)

I’m sorry but I cannot provide copies of the article here, since the copyright is held by the publisher.  By the way, I make no money from the sale of the article, so I hope you’ll consider me reasonably unbiased when I say that it’s well worth reading.  (Well, OK, about as unbiased as an author can be about his own work!).

To those who’ve seen my Earned Value talk with the animated interactive charts, this article does include some important details which I could not fit into the talk – in particular how to obtain objective "progress" numbers, and a discussion of how Earned Value relates to the critical path on software projects.

The article also forms a “bridge” between the purely graphical approach, which I use throughout my talk, and the numerical/mathematical approach which is the norm in the EV community.  As such, I believe it is one of the few pieces of writing on Earned Value which brings together all four of the following viewpoints:

• Agile project management
• "Traditional” (non-agile) project management
• An intuitive graphical “feel” for the subject
• The standard mathematical formulae of Earned value

I hope you find it to be balanced, reasonably comprehensive and, most  importantly of all, useful.

Marcin Niebudek wrote an article, in which he adds a budget line to an agile burn chart, measuring both in percentages.  Nice to see I’m not the only one doing that. (Even if he does draw the chart up the "wrong" way ;-)

Updates

June 2011: another interesting one from Glen Alleman, on the relationship between the ANSI standard criteria and simple/agile EV.

July 2011: A nice burn chart example from the folks at Atomic Object.  It doesn’t include the cost line, and I’d prefer if it did, but it does offer a clean solution to some of the challenges of charting change.

I’m looking forward to being part of an interesting conference, and hopefully helping to lift the profile of EVM in New Zealand.

Link to presentation abstract

( The abstract’s reference to “Number 8 wire” may be unclear to overseas readers :-)  The phrase simply means “New Zealand ingenuity”, in this part of the world.)

This is particularly important when describing it to people outside EVM’s traditional strongholds of defense and aerospace.  Outside those areas, EVM is under-utilised, and I suspect much of the reason is due to its apparent complexity.  I’ve been an EVM fan for about 5 years now, and I still come across unfamiliar acronyms.  If EVM is to be more widely used, it has to be presented in a way that is accessible to a wide audience.

Here’s what I came up with:

EVM, Distilled to a Pair of Simple Rules

Expanding on Rule 1

We compare actual cost with actual progress because that is the only comparison which bears any relationship to the final actual cost of the project(*). In projects run without EVM, it is common to compare actual cost with planned cost instead.  That simply tells you whether you are spending money as fast as you planned – a fairly useless thing to know if don’t know how much progress you’ve achieved for your money.   Another flawed alternative is to compare actual progress to planned progress.  That can be misleading – you may be making enough progress, but overspending (e.g. on overtime) to keep up with the schedule.

We make the comparison numerically because that’s the best way to get an objective comparison, minimising the subjective bias that tends to creep into our personal assessments of project status.  Making a numerical comparison necessitates one of EVMs most distinctive features: cost and progress must be measured in the same units.  Traditional EVM solves this by measuring progress in dollars, which is counter-intuitive for the uninitiated.  In the ‘lite’ EVM approach which I advocate on this site, cost and progress are both measured as percentages so they can be compared easily.

Expanding on Rule 2

Rule 2 necessitates another of EVM’s distinctive features: to predict the future from the past, we must measure the size of past and future tasks in the same way.  Because estimated size is our only measure of size for future tasks, we must also use it as our measure of size for completed tasks.  I.e. our progress to date is calculated as the sum of the estimated sizes of all completed tasks (not their actual sizes).

But the biggest challenge with rule 2 is psychological,  not technical.  When a project is going badly, we want to believe that the future will be better than the past.  We instinctively convince ourselves that we can catch up.  Sometimes that’s true (as long as our corrective action is appropriate), but sometimes it’s not. The great thing about EVM is that it provides an objective measure, independent of our tendency to kid ourselves. That objectivity can feel uncomfortable at times — particularly on those occasions when we actually are kidding ourselves :-)

But look at it this way: the impartial prediction provided by EVM is actually a good thing.  How many times have you been on a project where you knew it was doomed, but those around you (or more likely, above you ;-) kept insisting it was going to be OK?   With their heads buried in the sand, the project probably got even worse(**).  But what would have happened if they had used EVM instead, and if they had followed rule #2? They may well have responded to the problem with something more productive than denial.

EVM actually helps you respond to problems in a productive way.  It gives you the bad news relatively early (e.g. approx 20% into the project).  If you get the bad news that early, you can usually do something about it.  After you’ve done so, EVM can show  how well your corrective action is, or isn’t, working.

My point with rule 2 is that  it’s not enough to simply wish, hope or believe that the future will go more smoothly than the past. For example, it’s not enough to hope future tasks will be completed at their estimated costs, if EVM shows consistent overrun in the past.  That’s just kidding yourself.  Instead, you have have to actually take meaningful corrective action.

If you’re serious about project management, you must be serious about obtaining an accurate and impartial assessment of project status.  Earned Value is the best way to get it.

Feedback Please

Do you find these two rules useful?   How could I explain them better?

If you are not currently using EVM, do these rules help to explain what all the fuss is about?

If you are using traditional EVM, do you feel these rules fairly represent the “heart” of what you are doing?  Or are they off-target, or merely stating the obvious?

Footnotes

(*) An exception would be if you really can cancel-after-any-phase.  In that case, you know what your final cost will be – it will be your pre-arranged project cost. (You just don’t know the final scope, unless you predict it with EVM.)  Another exception would be if you have linear planned progress and guaranteed constant team size. In that case, cost is directly proportional to elapsed time, so you can use your linear planned progress as a proxy for actual cost.  I believe that many Agile processes implicitly assume that at least one of these exceptions applies. It would be better to make the assumption explicit, to more readily detect cases when it doesn’t apply.

(**) To be clear, no, this paragraph is not a reference to any of my current colleagues or bosses. The now-historical situations that inspired it shall remain nameless ;-)

I’d like to suggest an answer.  Let’s illustrate it with an example.  Consider an agile project that’s been estimated at 375 points in size. (To my non-agile readers, “points” are just a relative measure of task/feature size.  So for instance, a 20 point feature is estimated to require twice as much work as a 10 point one.  In this project, all the features add up to 375  points).

Also, imagine that our sample project is scheduled to take 12 weeks and we are now half way through the project. After 6 weeks, the team has completed 132 points’ worth of work.   The team leader reports that they are a little behind, since by this time they should have finished 187 points (half of 375).  After speaking with  everyone on the team, he is confident that they can make up the lost ground.

Question: how much faster will they have to work, if they are to finish the project on time? Will they have to work 10% faster than they have so far?  20% faster? 30% faster?

Get your own gut-feel for the answer, then scroll down.

The answer is eighty four percent.  To deliver on time, the team has to produce 84% more output, per week, than they did in the past.  That’s almost double.

Most teams, I suspect, don’t realise just how much faster they need to go.  We look at the status, and think,”Well, we’re a little behind, but it’s not too bad.”  We might even crunch some numbers.  In this example above, the team should have completed 50% of the work, but they have only done 35%.  You look at the figures, see 50 and 35, do the subtraction, and end up with 15%.  That doesn’t seem to bad.  15% is not very much, and seems well within our abilities to compensate for – perhaps with a little extra work, and good intentions to “work smarter”.

But we’re fooling ourselves.  We are forgetting two things:

1. The gap is not 15% of the project, it is 15 percentage points out of the 50 percentage points we are supposed to have by now.  15 / 50 is actually a 30% deficit.  So we are further behind than we think.
2. Not only are we further behind than we think, but catching up is harder than we expect.  We look at the remainder of the project and think, “We just have to go a little faster than we planned”.  That’s true enough, but we forget that “faster than planned” really equals “much, much faster than we have actually been going”.  After all, we do not have to achieve an improvement relative to the plan, we have to achieve an improvement relative to reality!

It is these two factors which mean that it requires an 84% speedup to compensate for a “15%” gap.

An example to do in your head

In the example above, I deliberately used numbers than were hard to manipulate in your head.  (Well, at least, they were hard to manipulate in mine ;-)

So here’s a really simple formulation of a similar problem, just so you can convince yourself than I’m not talking rubbish:

Again, imagine a project at the half-way point.  This time, the team has done exactly one third of the work, i.e. 33%.  Think of it this way: in their progress to date, they have done one on third of the work in half the time.  To finish on schedule, they must now do two thirds of the work in the other half of the time.  They must do twice as much work in the same amount of time – a 100% increase in speed.

Conclusion

Teams can’t speed up by 84% or 100%.  It just doesn’t happen. (At least, not when holding costs constant – and generally, not even when spending extra.)

When projects fall behind, our intuition lets us down. We have to rely on sound data and analysis instead.  I believe the best answer is to use Earned Value analysis.  A simple Earned Value chart like this goes along way to correcting our faulty assumptions.

Thanks for the generous re-print policy of Software Tech News, here is a copy of the article:

EarnedValueForAgileProjects.pdf

It was also re-printed by the PMI, in this 2009 issue of Measurable News.

(If you are looking for the same material, but addressed to an agile audience rather than an ANSI/EIA-748 audience, see ‘Agile Charts‘.)