After having written about the fundamentals of work breakdown structures, I will finally get to earned value (hooray!). Since there is quite a lot to cover, I won't waste precious words on too much of an introduction. I will instead jump into a short review of what the purpose of earned value (EV) is.
Earned value is, at it's core, an expression of how far a given project has progressed. It is expressed either as a unit of value (such as total units to be produced) or in how much of the budget has been earned. To give a very simple example, consider a project that has a budget of USD 200.000. We have a percentage of completion (POC) of 40%. The earned value for the project will then be: USD 80.000.
In other words we have earned 80.000 out of the original budget of 200.000.
Now how is that useful?
Well if we look at the amount already spent, we might see that we have already spent USD 110.000. If that was the case, then we would have a clear indication that the project would exceed the budget. Conversely if we had only spent USD 60.000 to earn USD 80.000 we would be justified in expecting the project to go under budget.
If we didn't use earned value, we would simply see that the project had a budget of USD 200.000 and we had spent USD 110.000. We wouldn't be able to see if this was good or bad. If we had the percentage of completion we might have an intuitive feeling of how it went, but we wouldn't be able to quantify it.
Of the three factors in the equation (EV, budget and POC), EV is the result and the budget should be quite certain. The factor with the least degree of certainty is always the percentage of completion. I have often seen projects where the POC hasn't moved for half a years reporting, and then suddenly take a leap and double in a single month. This would mean that in all the reporting where the POC didn't move there was no progress on the project. This was not the case (luckily). So what was the problem?
The project manager didn't have a reliably, objective way to estimate the POC. Therefore the EV was of significant less use than it could have been (but still quite useful).
So the problem comes in estimating the POC. This is where I have found that a solid work breakdown structure (or at the very least a list of milestones) comes in handy.
If you assign 100% completion to level 0 (the project goal), and then break that up on level 1, splitting those 100% out on the different objectives (and then continue this process until you're all the way down to the bottom of the hierarchy), then you end up with a list of work packages that each have a percentage of completion attached to them. It may be as few as five different work packages or milestones, or it may be as many as 70-100. When each work pack has been completed, you have earned that much of the overall completion for the project. For simple projects, this could merely be equal to how much of the budget each work package represents, or it could be a number defined by the project manager before project start-up.
Obviously this works better with a larger number of work packages, since the progression will be a lot smoother. But even with fewer WBS' (or even just a list of activities) this can actually work quite well; the important thing is just, that the fewer work packages or activities there are, the more important it is to get a secondary input from the project manager.
In a project with a 100 work packages, where each one had been assigned 1% completion (how lucky for us), then we would be fairly certain of the POC when 35 work packages had been completed.
Let us say we had five activities instead in the project and assigned each of them 20%. When the first two had been completed we would estimate that the project was 40% complete. The problem is that the POC would make 'jumps' of 20% with no numbers in between. We would then get the PM's input on this, and he would then, hopefully, estimate somewhere in the range of 35%-55%.
It is obvious that the controlling would be more precise, and therefore normally better, in the first example. But my definite experience is, that we would still be able to do a great deal of controlling in the second example as well. I have normally had the experience that the project managers ability to estimate the POC (coupled with a basic framework) is reasonably good.
The most basic way to add the value of a work package to the POC is to say that when it is completed, it's value is added to the total POC. But for larger work packages, that stretch over longer periods of time, it can often lead to a more precise POC if you add some of the value when the work package is begun. Different preferences prevail for different projects, and indeed for different controllers. I have often found a 40/60 split of the value of the workpack to be the best (i.e. 40% of the workpack value is added on start-up and the remaing 60% is added at completion of the workpack).This includes a reasonable progress when the work is started, but the completion still has almost two thirds of the value.
Finally I would like to go through a bit of the math for earned value controlling, especially in simpler projects.
EV = Earned Value
PV = Planned Value
AC = Actual Cost (sometimes ACWP = Actual Cos of Work Performed)
This indicates that the project is over budget already.
This gives an indication of the project is performing.
If is less than one, the project is below budget. If it is above one, there is an indication of budget overrun.
To express how much the current trend is compared to the budget simply multiply the budget on:
The same rules apply when comparing EV to PV:
This indicates that the project is behind schedule.
This gives an indication of the project is performing schedule-wise.
Finally:
There are, of course, a lot of other formulas for controlling based on earned value, but with simpler projects, I have found it best to keep the controlling relatively simple as well. Most importantly since you can get a very accurate picture with little work, but also because you should take care to avoid 'over-controlling' on a simple amount of input. You end up making conclusion, based on analysis that overinterpret.
In my next article I will broach the subject of earned value for projects that have a slightly higher degree of complexity, and some of the tools you can use to deliver more detailed controlling on those.
No comments:
Post a Comment