Is Earned Value Management valuable?

Eric Brown talks about Earned Value Management. I know that this is a respected practice recommended by the PMBOK amongst others. I have had more than my fair share of disagreements about the need to implement EVM.

I have one fundamental problem with EVM: it takes too long to track this information. I find that for the vast majority of projects that I or one of my PMs run, the team ends up tracking too much information for too little real benefit. I define benefit as the team delivering more working software features in production faster.

As Eric points out, one needs to track the following

1. Planned Work – What work is scheduled to be completed?
2. Cost Estimate for Planned Work – What is the cost estimate for the scheduled work?
3. Actual Work – What work has been completed?
4. Cost Estimate for Completed Work – What is the cost estimate for the work that has been completed?
5. Actual Costs – What costs have actually been incurred?
6. Variances – Cost difference, Schedule difference, Estimate Difference.

If you compare this to a Scrum burn-down chart, or a cumulative flow diagram, you’ll see there is a good deal of time that needs to be spent on overhead, instead of where management focus should be: identifying and removing constraints to the team delivering value. Also, I find this type of management information is too easily used (sometimes inadvertently) by the business to beat up IT on why variances between estimates and actuals are so large. What the business really cares about is seeing software features which they value working in production. Once you have a good idea of a team’s velocity, leave it at that. The velocity — or the number of features that you delivered last iteration — enables a good prediction of what will be delivered next iteration. Even if this does not work to plan, the business is generally very happy with getting a working set of features in production on time and within spec.

With the resources — be they money, manhours or a technical environment — you are using on implementing EVM, consider investing this in your team delivering software directly.

Technorati Tags: ,


4 Responses to “Is Earned Value Management valuable?”

  1. Eric Brown Says:

    Good points about EVM taking resources to track and implement….I agree…to a point. I think there are ways to implement EVM using scalable methods. There isn’t necessarily a need to implement a full-blow EVM system for a small/short project but it would still be good to know the value that the project is bringing…using a scalable EVM methodology is perfect in this situation.

    Good post.

  2. robinallenson Says:

    Thanks for the reply. (I should say I enjoy your blog and read it regularly). I would love to hear about scalable ways of implementing EVM. The (agile) alternatives that I have seen and used have been very powerful for me.

  3. John Rusk Says:

    Picking up on Eric’s point, here’s an example: . It’s an “agil-ized” version of EVM, at the very simplest end of the scalable EVM scale. EVM-ers will (hopefully) recognise it as very minimalistic EVM; agilists will recognise it as a burn chart with cost information added.

    With this approach, it only takes us about 10 minutes per week to keep all our tracking information up to date.

    In response to Eric’s 5 things to track, here’s how we track them:

    1. Planned Work. -> We bascially just use a big task list.
    2. Cost Estimate for Planned Work -> We record an estimate against each task
    3. Actual Work -> We deliberately short-cut this one. Each week we record the total number of hours worked on the project by each person. That’s it. There is deliberately no breakdown of actuals by task.
    4. Cost Estimate for Completed Work -> We track completion simply by recording the week in which each task was completed.
    5. Actual Costs -> Nothing over and above #3 above.
    6. Variances -> No formulas, variances are simply (and very readably) implied by the graph.

  4. robinallenson Says:

    Thanks for the great comment John and sorry for the delay in replying. I think adding cost information to a burn down chart (or whatever your one-stop-shop metric of choice is) is an excellent way to go. Looking back on my comment to Eric, I recognise that much of this comes from own lack of needing to track cost information in this way. The guys that we work with for our agile development are all internal in this case, so cost information always takes second place.

    I love the idea of taking just 10 minutes a week to keep the tracking information up to date. This is also what we do. It frees up a lot more time for getting software working in production.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: