Earned value in intermediate projects

Now that the basics for earned value in projects with simpler complexity is out of the way, I feel it is time to move on to the basics for projects that are not so straightforward. In the previous article we looked at projects, whose main concern was cost development, and how our anticipated final cost looked compared to the original budget.

This kind of view is effective for all types of projects, but some projects have additional aspects that needs to be addressed as well.

Consider for instance a project with a critical time component. It might be a project that needs to be finished before the competitors finish similar projects (such as the development of new cell phones) or before a given date (this could be the completion of a new production system that needs to be operational before Christmas sales). In both of these projects, time will be a a vastly important factor, and some times even more so than cost.

In this article I will look at ways to reflect this in the monitoring of the project, using the earned value method and combining it with a few other tools.

The first thing we need to clarify is that when we have scheduled all the work-packages for our projects (all the goals that needs to be met before we can say the project is completed), some of them cannot be started right away. Manufacturing cannot begin before the design is complete, for instance. As we plan out all the work-packs, it will quickly become apparent that there will be a dependency in our network of goals (or tasks). An example, for a project with 10 work-packs, could be depicted like this:

If we made the (unrealistic) assumption that the completion of each work-pack would take the same amount of time to complete, we can see that the minimum time needed to complete the project would be the road that requires the maximum consecutive work-packs to be completed. In this case it would be:

We call this our critical path. The reason for this is that if we encounter any delays along this path, then the entire project will be delayed. If we have delays on the other two paths then we wouldn't necessarily have to delay completing the project. So in a project where time is of the essence, the critical path becomes a vitally important factor to monitor as well.

This is something we should definitely observe when using earned value to monitor our project. There are different ways of doing this, depending on how elaborate the project set-up is, and what your preferences are. I prefer a simplistic one, where you weigh the value of all work-packs on the critical higher more than you would have if you hadn't looked at schedule as a critical factor. In the simpler projects we could, with a high degree of accuracy, use the budgeted cost of each work-pack as a key for distributing the earned value. In projects where schedule is critical, we would do the same initially. Then we would redistribute some value away from the work-packs not on the critical path, and place it on the work-packs on the critical path.

Furthermore I have found it to be a good idea to place a slight overemphasis on the work-packs that the highest amount of dependencies in the project; such as A and B, on which all following work-packs depend.

This added emphasis on work-packs with schedule-critical elements will ensure that if the project is neglecting these work-packs, then the project will fall behind the planned value (PV). This in turn, should raise a red flag with the controller.

It would also be a prudent measure for a controller to keep an eye on the current length of the critical path, as an added measure of control, to make sure that the schedule is not slipping.

The last issue I am going to touch upon, when using earned value in time-critical projects, is that you should always keep your eye out for the possibility that the critical path might change in the project. If we imagine a scenario where one of the work-packs not on the original critical path, suddenly experience an issue that delays is seriously, we might end up with a new critical path. In the example from before, if work-pack C suddenly tripled in time consumption, the new critical path would be A-B-C-D-I-J.

Though this does not happen often, I have seen it happen enough times to keep an eye out for it (such as last-minute changes to a long-lead item or a vendor delaying a delivery due to an external event).

If the critical path changes, you do not necessarily need to change the earned value assigned to the work-packs, but you should make sure that there is sufficient focus on the new critical path, and set up a routine for controlling that helps you identify further threats to the schedule along the new critical path.

To round it all up, I think the basis for using earned value properly in projects (and in project controlling) is to ensure that you have proper planning. This goes both for simple projects and more complex ones; if you don't have a proper work breakdown structure or list of activities, or you haven't spent enough time assigning the correct values to the work-packs, then your controlling will suffer.

Earned value in simpler projects

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.

Controlling in an imperfect environment

The companies I have been in, have rarely had an organisation that followed the textbook rules for implementing projects. The larger the company, the more formal the project organisation, but even in an organisation that implemented projects with a budget of tens of millions of dollars, I have run into some fundamental challenges. This could be lack of a proper WBS structure, lack of detailed budgets or purely technical project managers, with little understanding of project management theories.

Whatever the reasons, the consequences are the same; the lessons from formalised economic education, and controlling theories, normally assume a more or less perfect world. When faced with the harsh realities, I have often had to find out how I could maximize my controlling within the existing organisational structures. Some changes can be implemented relatively easily, such as asking for monthly forecasts or having the PM deliver a monthly percentage of completion for the project. Other changes are require longer periods to implement, and often need to be anchored at a management level. This could be the inclusion of contingency in budgets, to deliver more detailed budgets, the use of weighted milestones or a WBS structure.

If we reach back and look at some of the input I mentioned in my articles on soft and hard data, I will list an overview of what I have typically found to be useful in even simple project organisations:

There is a lot of controlling to be done on the basis of these, but in the interest of sparing you from reading ten pages of calculations, and their merits in controlling, I will only show those that has most often yielded positive results.

If this is less than one, then it is an indication that the project is in danger of a budget overrun.

I typically do not raise this as a red flag before it reaches 0.85 in the earlier stages of the project (i.e. POC less than 50%).

If this is higher than one, it means that the project will have to spend more per month than it has previously done. Like all other indicators, this in itself is not a problem, but it should prompt further investigation, as it suggests that the project schedule is slipping. This is one of the most common inconsistencies I have seen in PM reporting; the schedule is slipping, but the project manager has an (unrealistic) expectation of being able to catch up, by working a bit harder. This a typical consequence of best-case planning, and definitely somewhere I focus a lot. Normally this will also be reflect if we look at the current year exclusively:

If we use the above formula as an indication of whether the forecast (and schedule) for the current year is slipping, I have normally found it as a good indication of whether the entire project faces the same problems.

Finally I would like to include two softer indicators, that have, none the less, proved quite useful for me:

1. If the anticipated end date is moved further into the future, then you should expect tan increase in the AFC. Maintaining a project organisation is associated with continuous cost, and open projects have a tendency to attract costs.
2. If the time remaining is less than 15% of total project duration, I would expect ETC to be less than 10% of the AFC. The reason for this is that projects typically follow an S-curve, and at the end of the curve the rise in accumulated costs is significantly slower than earlier in the project.

If any of the two indicators above 'trip', then I wouldn't raise it as a red flag, but more likely I would contact the PM and present him with my data, and see if there is an explanation for it.

If any of you have any experience with, or ideas on, implementing changes in an existing PM organisation or on other focus areas for controlling, I would be very interested in hearing about them.

My next article will be more generic, and in it I will try to discuss some of the general merits of controlling. I will, as per usual, put it in the context of experiences, in this case where there has been a clear (and positive) effect of controlling.