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.