EVM for Mere Mortals

In all my years working on IT projects, I think I’ve observed more silliness around the topic of Earned Value Management — or EVM, for those in the know — than on any other subject I can think of.

The many varieties of dysfunction that people exhibit towards this project management tool tend to place them in one of the following categories:

• Those who have no idea what it is but are sure they don’t need it;

• Those who view EVM as a necessary evil, like some sort of pagan god periodically demanding a ritual sacrifice from its followers;

• Those who treat EVM numbers as powerful omens foreshadowing their fates, as if massaging the numbers to change the resulting stoplight colors could actually positively influence the outcomes of their projects;

• Those who rely on amulets and talismans to keep the evil EVM from their doors — such as estimates that seem to always fall just a hair under the threshold that would trigger a hard and fast requirement for it;

• Those high priests and priestesses of EVM who use a familiarity with its mystical language and calculations as an avenging force to root out and punish the unbelievers.

In practice, I’ve found much of this behavior to be based on a lack of understanding about what EVM is, how it works, and what it is good for. So let me try to cast a few rays of light into the darkness that often surrounds this subject.

The Case for EVM

The easiest way to understand the problem that EVM is trying to solve is by describing the all-too-frequently observed characteristics of an IT project without EVM. The typical scenario is that the project is reported by everyone involved to be in good shape until it nears its planned completion date, at which point it enters the dreaded “almost done” state, and then stays there for what seems like (and often actually is) an eternity, before being finally brought to some sort of dreary conclusion, usually through forced removal of life support.

In other words, the problem can be stated thusly: there is a strong human predisposition to assume, with the consumption of budget and the passing of time, that actual project progress is proceeding at the same pace. Sadly, facts recorded at project completion have repeatedly failed to demonstrate this correlation.

The Essence of EVM

Here is the best analogy I’ve been able to come up with to explain how EVM works. Let’s say that you are flying from Los Angeles to New York in order to serve as best man at your friend’s wedding. You fill up the plane’s gas tank, you figure out what time you have to get there, and you take off.

OK. You’ve been up in the air for an hour. The land below is skimming by at a reassuring rate. The needle on the gas tank shows that you’ve got plenty of gas left. Life is good, right? What could go wrong?

Well, two things, actually:

1. You could get there an hour late, thus missing the ceremony, in which case you may as well have stayed home.

2. You could run out of gas before you get there, in which case you would plummet to a fiery death.

Since neither of these outcomes appears desirable, you might look for some reassurance that you will avoid them both. So what additional data do you need? Two things:

1. You need to know your speed, so you can calculate when you will arrive.

2. You need to know your mileage, or the miles per gallon you are achieving, to know whether your fuel supply will get you to your destination.

EVM is simply a way of calculating these two pieces of data for a project. The first is called schedule performance, and is the equivalent of speed. The second is called cost performance, and is the equivalent of mileage (since a project’s budget is equivalent to a plane’s fuel).

For an airplane, of course, progress can be measured in miles traveled. For a project, progress is measured by tasks completed. And, since, unlike miles, all tasks are not of the same size, you need to factor in the size of each task as well.

Oh, and one more thing: since we lack any absolute units of measurement for project progress (no easy equivalent to miles in our analogy), our performance numbers are calculated as indices, in which we compare our actuals to our plan. So a value of 1.00 means that we are precisely on our plan. A value greater than 1 means that we are doing better than our plan. A value of less than 1 means that we are not doing as well as we had planned.

That’s pretty much the whole thing in a nutshell.

Those Confusing Formulae

Here is where most people run off the rails and become convinced that if they never hear of EVM again, it will be too soon.

Feel free to skip this section if it makes your head spin. It’s not all that important, unless you’re the person who will actually be doing the EVM calculations.

Here are the key terms used:

Budgeted Cost of Work Performed (BCWP): The amount of work actually completed so far, measured in terms of the total budgeted (i.e., planned) cost for all tasks completed to date.

Budgeted Cost of Work Scheduled (BCWS): The amount of work we had planned to complete by now (measured in terms of the total budgeted costs for all of the tasks that were planned to be completed by this date).

Actual Cost of Work Performed (ACWP): The amount of money we’ve actually spent to get us this far.

And here are the two key formulas:

Schedule Performance Index (SPI) = Budgeted Cost of Work Performed (BCWP) / Budgeted Cost of Work Scheduled (BCWS). In other words, how much work we’ve actually done at this point, divided by how much work we had planned to get done.

Cost Performance Index (CPI) = Budgeted Cost of Work Performed (BCWP) / Actual Cost of Work Performed (ACWP). In other words, how much we had planned to spend on the work we’ve completed, vs. how much we’ve actually spent.

One other point may be helpful: if most of your costs are in labor, and most of your labor is paid at roughly the same rate, then you can substitute hours for dollars in your calculations and still achieve essentially the same results.

Implementation Tips

Here are a few simple tips for an effective EVM implementation.

1. The work in your project should be broken down into relatively discrete tasks (roughly one to two weeks in duration). If you end up with one or more large, amorphous tasks, then you have just reproduced essentially the same problem statement that we started with, only at a slightly lower level.

2. Each task should produce a deliverable whose completeness can be easily and objectively determined. In other words, there should not be a lot of room for debate about whether a particular task is done yet or not: otherwise you are liable to find out at the end of the project that tasks you thought were “done” are really still in varying states of completion.

3. Your project team needs to take ownership of the EVM numbers and the results of the calculations. In practice, the only way I know to achieve that is to have the entire team review their EVM numbers on a weekly basis.

Reacting to EVM Variations

I’ve seen cases where any sort of variation from CPI and SPI numbers between 0.99 and 1.01 resulted in general panic and manning of the lifeboats, but more discriminating responses are generally called for. Small and short-term variations from SPI and CPI numbers of 1.00 probably need no special attention. More sizable variations should typically elicit responses along the lines indicated below, based on the particular combination of SPI and CPI variations you have.

CPI > 1 and SPI < 1:

Your resources are performing well, but you are not getting as many as planned: you need to make resources more available (e.g., by providing more people and/or overtime).

CPI > 1 and SPI > 1:

Life is good: you can assign some resources to other tasks and still complete on time and under budget, or you can keep your current resources and finish ahead of schedule and under budget. (On the other hand, management will probably think you’re padding your estimates on the next project, and so will trim them accordingly.)

CPI < 1 and SPI < 1:

You are getting the resources you planned, but they are not performing as well as you had planned: you will need to de-scope or improve performance (to correct SPI & CPI), or acquire additional resources (to correct SPI).

CPI < 1 and SPI > 1:

You are on schedule, but only because you are applying more resources than planned. You will need to de-scope or improve performance to avoid going over budget.

The Agile Controversy

One question that often arises is whether it is valid or necessary to apply EVM to Agile projects.

Let’s think about this for a minute. In order to implement EVM we need to break our work down into discrete tasks… each task needs to have a discrete deliverable that can be readily determined to be done or not… we need to objectively track our progress against our backlog of tasks yet to be completed… we’re more concerned with the quantity of work completed than which specific tasks were completed….

Hmmm…. In Agile, we break our work down into features, and features into tasks… we deliver those features on a regular basis, with short delivery cycles… the team has a “definition of done” for each feature… the backlog is dynamic… we regularly track features delivered vs. features still in our backlog….

Oh. Wait a minute. I get it. Agile is essentially a form of EVM for software projects.

So the Agile vs. EVM controversy should be a non-issue. If an agile project needs to feed data into a more traditional EVM system, then that should be easy to arrange.

If All You Have is a Hammer…

Not every project management issue is a nail that can be driven into place with the hammer of EVM.

For one thing, it is no substitute for identifying your critical path through your project, which will identify those tasks that must be completed on time in order for the project as a whole to be completed on time. If you are 90% done, with a perfect SPI and CPI, but you have been avoiding all the tasks on your critical path, then you may still be a year away from completing your year-long project.

Also, EVM is meaningless unless you first have a well defined project scope and work breakdown structure. If you don’t know your destination, or don’t know the route you’re going to take, then knowing your speed and mileage won’t really help to get you there on time and within your budget.