I’ve been looking for a way to describe the “essence” of Earned Value Management (EVM).  How can I describe the core of what EVM is about – without resorting to an impenetrable jungle of acronyms?

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 😉