|
|
Let's start with a quiz. Suppose your project is to build 20 houses. You estimate it will cost $100,000 to build each house. You have built 10 houses so far. However, the actual cost of building each house was $150,000. What is the project's Earned Value?
How do you track and measure progress in your IT projects? Maybe you're of the "it's fine don't worry" school of project status reporting. That is, no tracking of hours worked or tasks completed and the boss is happy to go with your opinion of project status - or at least what you say your opinion is. If you're of this school then Earned Value and every other method of objective status reporting will seem like a bureaucratic nightmare. In our house building example you had to count how many houses had been built in order to work out the Earned Value. In an IT project the equivalent is to count how many tasks you've done.
(What's your answer to the quiz - $1,000,000, $1,500,000 or something else...?)
This Project Management Training Course covers how to track and report progress in I.T. projects.
What if you've built ten and a half houses, do you count the half built house as having any Earned Value? Some would say no, some would say yes, some would have a more complicated answer, but half a house is clearly significant in the context of a 20 house project. But in software projects there are usually hundreds or thousands of work tasks. There will be relatively very few started-not-finished tasks. Giving them zero Earned Value is the norm and only slightly understates progress.
Did you answer $1,500,000 to the quiz? We've built 10 houses at an actual cost of $150,000 each. If so, afraid you're wrong. Earned Value ignores actual cost. The Earned Value is $1,000,000. Earned Value is work completed at its budgeted (i.e. estimated) cost - 10 x $100,000.
Does saying Earned Value is $1,000,000 tell us any more than saying that 10 houses have been finished? No it doesn't. That's because all the houses had the same estimated cost. But in a project where the bits of work are of different sizes, Earned Value will give us a good measure of the value of the work finished.
|
|
So we've finished ten houses, so what? Earned Value doesn't tell us they cost 50% more than expected, which is rather significant information. True. But there are other measures in the Earned Value stable which would tell us about the cost overrun.
And although we have finished 10 houses and have an Earned Value of $1,000,000, if we should have finished 11 houses by now and should have an Earned Value of $1,100,000, then clearly we are behind schedule. Earned Value does not tell us that either. But if we compare actual Earned Value to planned Earned Value we can see if we are on schedule.
We can then draw a pretty graph showing the actual Earned Value vs the planned Earned Value - in our case actual Earned Value sagging somewhat below planned Earned Value - and another graph showing our 50% cost overrun.
Imagine you are in the design phase of a software project. You have completed half of the planned tasks (and these tasks were estimated to cost 50% of the total design phase cost). Our Earned Value is obviously 50% of the total. Furthermore, the plan says you should have completed 50% of the tasks by now. So comparing actual Earned Value to planned Earned Value says we're doing great, we're bang on schedule! And let's assume the costs are also exactly as predicted.
However, has the work we have done so far produced any saleable product? Have we actually earned any value?
Ten finished houses clearly have an "earned value". If you have built half a nuclear submarine it, arguably, has some value. But a half finished design in a software project?
And if you are not very careful a focus on Earned Value can lead you to overlook the fact that there is still a lot more work to do than you originally thought. If the plan originally had 100 tasks in it and you've done 50, it looks like you're half way through but, whoops, there are now 120 tasks in the plan. Your actual Earned Value may equal your planned Earned Value but your project is nevertheless in trouble. Earned Value management can take your eye off this "plan growth" ball if you're not very careful.
As we saw with the house project, if all the tasks are of equal size saying Earned Value is $1,000,000 tells you no more than saying you have built 10 houses. It's when the tasks have differing costs that Earned Value adds most value.
But think about a software project. Most of the cost is simply people's time. Progress will be measured by how many work tasks are completed rather than how much cash has been spent on licenses or whatever.
Also, Earned Value will give more credit to tasks done by more expensive people. A 20 hour task done by a $100 an hour person is worth twice as much as a 20 hour task done by a $50 and hour person. Except that it isn't really, is it? If you're producing widgets, producing a $100 widget does earn more value than producing a $50 widget. But in a software project does a task done by an expensive person represent more progress than a task done by a less expensive person? Measuring the "cost" of tasks in hours rather than money would overcome this problem.
In a software project tasks could vary is size from, say, 1 hour to 80 hours of work. Imagine the first 50 tasks in the plan are 1 hour tasks and the second 50 are 80 hour tasks, and that you have finished the 50 1 hour tasks. Simple task counting could lead you to believe you've done half the work - which clearly you haven't. Earned Value would tell you that you hadn't done anything like half the work.
However, in any given phase of a software project these various sized tasks will tend to be evenly distributed throughout the phase. So, if you've done half of the tasks you probably have done half of the work. So in practice Earned Value will tell you little or nothing more than simple task counting.
And even in the case above, if the plan says you should have done 50 1 hour tasks by now and you have, task counting will tell you, quite rightly, that you are on schedule.
In physical build projects jobs have to be done in sequence. You can't build the penthouse flat until you've built the lower floors. But in a software project you have much more freedom to do tasks in whatever order you like. So, you can cherry pick. Start all the easy tasks ahead of schedule and push the difficult ones into the future. Easy does not mean lower estimated cost. If you have two 30 hour tasks one could be a lot easier to get done than the other. If you bring forward and complete all the easy tasks Earned Value metrics will show you're doing great (until you can no longer put off doing the chewy tasks and they start to overrun). Earned Value metrics will not tell you whether you are doing tasks in the right order. Earned Value will not alert you to cherry picking.
We see that our software project is like our house building project: counting the number of houses built or the number of tasks done is just as useful as measuring "Earned Value". "Earned Value" in quotes because nobody except the cognoscenti understand what Earned Value is. And saying the ratio of actual Earned Value to planned Earned Value is 1 - as it should be - sounds very reassuring to the boss even though he has no idea what you're talking about. (And does not make him aware there's a lot more work still to be done than you originally thought!)
So, in software projects Earned Value adds little or no value over and above counting tasks completed. But everyone can understand what actual tasks completed vs planned tasks completed means.
The Earned Value universe has its own Laws of Physics. Arcane metrics such as TCPI measure the state of things. If TCPI is 0.89 is that a good thing or a bad thing? If your company and your customers all live in the Earned Value universe then you'll all know what this means. But you've got no idea, have you? Or if you have, I bet you're customer or user hasn't.
I have met Project Office staff who report Earned Value but are unable to say what it means or how it is derived. I've even had someone say sniffily "we don't count tasks any more, we use Earned Value". [You have to count tasks completed to work out Earned value!] People don't understand Earned Value. But everyone can understand: "we've done 900 tasks but we should have done 1000" and "the 900 tasks took 15% more hours to do than we expected".
In software projects we questioned whether tasks completed really means value has been earned. Earned Value conveys a warm, cosy feeling that something real has been achieved, something of capitalisable value has been produced. Arguably in a software project until you've finished the project and proved that the software works no value has been earned.
And don't software projects have that other characteristic we mentioned earlier - plan growth - in spades? If you're building 20 houses the value you will earn is very clear - 20 houses. If you change the plan so that you will build 25 houses you will earn more value - 25 houses. But if your software project originally had 2000 tasks in the plan and you change the plan to have 2500 tasks does that mean you will be earning more value? Probably not. It probably just means you got the plan wrong. You have to do more work, complete more tasks, to deliver the same "value". Even a user change request probably isn't adding real value - it's just correcting an error or omission in the User Requirements document.
Earned Value tells you how much work has been done (though not whether the right work has been done). But when reporting the status of software projects the more important thing to report is how much work is still left to be done. You may well have thought that system test would require 1000 testing tasks to be done, but if the test manager discovers that the quality is much worse than expected there could still be 1000 tasks left to do even if 1000 tasks have already been done!
For those people who do not inhabit the Earned Value universe (in which everyone knows from birth what an SV of 0.84, a CV of 1.15 and a TCPI of 0.9 says about the project) we can devise measures that even the uninitiated can understand that will tell us more about the status of a software project.
In a software project we should report, amongst other things:
In software projects nobody really knows how much work will be involved until the project
is finished. (And even then they don't really know - the cost of fixing the bugs can be as much
as the project cost in the first place - or more.) So you must keep revising your estimate as you
go along to give the boss at least your current best guess - this should be more
reliable than any of your previous guesses. (For "guess" please read "scientifically produced
cost and schedule estimate".)
Copyright M Harding Roberts 2007 2008
This Project Management Course describes how progress can be tracked and controlled and how status can be reported in software projects. The principle of Earned Value is incorporated, but measures that are more user friendly are described. The course also covers how to make estimates and schedules more accurate; how to manage quality in such a way that system test doesn't take longer than expected; and a host of other things.
Please click here for the free
Project Management Book
by Mike Harding Roberts.
Towards a Project-Centric World
Project Management Proverbs, Saying, Laws and Jokes
So You Want To Be A Project Manager?
Free Online Project Management Book
Quality Management in Software Development Projects
The Tale of Three Project Managers
Copyright M Harding Roberts
www.hraconsulting-ltd.co.uk
Earned Value is a useful concept in project management. Earned Value measures the amount
of work completed. Earned Value metrics can be used to predict cost to completion. Earned Value management
in I.T. software development projects is discussed in this project management article on Earned Value.
Earned Value project management course
Earned Value in Software Project Management
Earned Value project management training
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course