The harder the data

In my last entry I wrote about my experiences with PM reporting, and their subjective evaluations in a project (forecasts, anticipated end date, percentage of completion etc.). All of these reportings I considered 'soft' data, because they were subjective estimates made by the Project Manager.

In this entry I will focus on another type of data, which I shall, conveniently, think of as 'hard' data. These are data about the project that are objective, and will rarely be subject of discussion. These include, but are not limited to:

• Cost spent (ACWP)
• Project start-up date.
• Original budget (original baseline cost), including breakdown on activities.
• Latest approved budget (baseline cost)
• Current project phase
• Costs committed, but not yet spent.

Other examples could be number of active WBS work-packs, number of total WBS work-packs, distribution of earned value on activities, percentage of projected budget released (with regards to funding).

From these costs alone, it is possible to control a lot with regards to the project, as long as it is coupled with historical data and a knowledge of typical project behaviour. In other words, knowledge of controlling. What I have typically found useful to look at, using purely hard data, are the following areas:

• Cost of completed activities compared to budget of the same activities.
• Phasing of the accumulated costs over time.
• Comparison to historical data.

I we look at the three bullets above, the first one should be the easiest to perform controlling on. It will give you a clear indication of whether or not the project has been able to keep it's budget so far. This will give you two very important indications, both of which are very straight-forward: most importantly, you can use the current development, compared to budget, to project how the project is going to progress, going forward. If it is under budget, then there's a good chance that it will continue to develop that way. If there is a budget overrun on completed activities, then this should definitely be a red flag when looking for early warnings of a total budget overrun¹.

The second indication is, that if the project is progressed significantly (for instance 50% of the budgeted costs have been spent), then it might be a good idea to include the current over- / underspending in the forecast, since it might be significant. For me a good rule of thumb has been that when the deviation equalled 10% of the total budget, I include it in my forecasts (or in my feedback to the project manager when asking him for the forecast, if he is responsible for preparing it).

The second bullet, the phasing of costs, I prefer to do graphically, with periods on the X-axis (typically months) and accumulated cost on the y-axis (in local currencies). This should, hopefully, give something that resembles the typical S-curve we would expect for projects. Some types of projects might not have this profile when it comes to spending, but then you should be able to do a comparison with similar projects that has either been executed in the past within the same organisation, or from similar projects done by others in the same type of business.

The last bullet seems obvious at first glance, but I have often found it hard to determine exactly what data to compare. Unless the company is selling turnkey projects within the same market, it is often hard to find projects that are easily comparable. I usually try to look for rules of thumb that applies to the projects overall, even if these may be very broad. To continue my extensive use of bullet point lists, here are some of the thumb-rules I have found useful:

• The ratio between cost spent on studies and cost spent on total project.
• Costs spent on documentation (as-built documentation for example) compared to budget size.
• The amount of costs (mainly man-hours) spent on project management.

The important point about the different methods of controlling using the hard data, is the amount of manual work that goes into controlling them. Comparing the completed activities with the budgeted costs should be a fairly simple task, once it is up and running (for instance if a work breakdown structure is used). This process should therefore be fairly automatic, and you should be able to quickly identify if there are any budget deviations that exceed your pre-set control limits (such as +/- 10%).

The second, the graphical depiction of the phased costs, is very quick to control, as long as it is used as a sanity check. If it shows something is wrong, it may take a while to determine what, if anything, is deviating, and if this is cause for any alarm.

Comparing to historical data is only something I would recommend doing if you have historical data that are easily comparable (1-to-1 projects, an easy way of finding out which costs relate to which phase etc.). It is all about finding the easiest way of doing the comparison, with minimal margins of error. For example; in practise I have found that comparing phases can be fairly simple from an 80/20 point-of-view. You simply look at the costs spent up until a decision gate was crossed, and treat all costs until that date as belonging to the same phase. This will, by it's very nature, not give you a 100% correct split, but I have found the uncertainty to be immaterial (from an empiric perspective).

My thoughts on controlling the 'hard' data is that it should be as automatic as possible, giving you a fast overview of which areas you should focus further on. It should, however, not take up half of your total time spent controlling projects. The main focus, and time spent, should be on comparing the information gained from the hard and the soft data. I will go into much greater detail in my next entry, which will be on exactly that topic.

1It is important to remember that an indication is not the same as a complete and final truth. There might be a perfectly valid reason for why these activities have gone over or under budget, but the remaining activities will not. An example could be that during the feasibility studies, a simpler, cheaper overall solution was identified, but it required extra cost be spent on studies to make sure it fulfilled the project success criteria.