Managing project cost

Cost management, conceptually at least, is fairly simple—set a budget and meet it.

The reality, however, is far from simple, as terminology, accounting policies, estimating, scope control and procurement all add complexity to the process. In no other project management discipline are there so many stakeholders, differing opinions, politics, bias and tool complexities. This post considers some of those complexities.

Terminology use and the lack of consistency with industry standards is one area of confusion when we consider cost management. We see the budget called ‘planned’ in one company, ‘baseline’ in another, ‘agreed cost plan’, ‘target cost’ and many other variations also used, even between different business units of the same company.

Then again we see the forecast cost or estimate at completion also called ‘planned’ or ‘cost plan’ or similar. Work breakdown structure (WBS) we use for representing scope, but the term is also used in accounting software to describe cost control accounts and in scheduling tools to describe outline structure. It is no wonder people get confused.

One of the first things we do when entering a new client environment is provide a translation guide between industry standards (e.g. PMBOK) and their terminology, just so we can understand.

Then there is the quagmire of funding and budgeting policies and politics. Some companies lock in budgets early in a project lifecycle. Some use the business case, others formal funding requests. Some remove internal labour for budgeting, others budget by financial year. The concept of budget at completion is difficult for some, particularly in Government.

Some organisations struggle with the concept of a forecast, particularly one which is over budget and try to design processes to change budgets to align with forecasts. That’s a crazy concept, but one which arises where funding needs to match forecasts, confusing the concept of maintaining a budget. In such environments, earned value is impossible.

Requirements to separate capital and operational expenditure for tax reasons can also make things difficult for project managers as well as price versus cost when outsourced.

At what level of detail should a project manager go to manage cost? Formally, it should be at a control account level, for example, below project level at the level at which there is a point of accountability for a major scope element. It needs to be at the level which is ‘just right’, not too detailed but not too high either.

And that goes to the heart of why one doesn’t manage cost in MS Project. A tool such as MS Project is arguably okay for developing an estimate to complete but one struggles trying to align actual costs and manage budgets. We find a spreadsheet for cost management is far more appropriate. MS Project is quite handy for calculating earned value, however.

There is some complexity with collecting actual costs. Setting up accounting systems, timesheeting or allocating labour actuals is reasonably involved, as is the accrual process (realised costs that are yet to hit the accounting system). Many project managers don’t understand basic accounting principles, e.g. actual costs are recorded on invoice receipt, not payment.

Internal labour is probably one of the harder areas of actual cost to collect as visibility of wages and rates becomes an issue. Active tracking of who is booking what is a key aspect of cost management by the project manager.

We find that in IT, estimating is generally done quite poorly. More often than not there is a disconnect between the schedule, resource model and cost model. For a forecast of the total cost, one needs to add the actual cost to the estimate to complete. The estimate to complete therefore must be a maintained estimate, updated at least monthly. That is where many project managers find things difficult.

Another area relating to the estimate that is misunderstood is contingency. We are amazed to hear comments such as “we have run out of contingency”. To complete any project one must add the raw estimate to contingency, regardless of budgets. Any forecast that has $0 for contingency is wrong. Research we have seen indicates that, for IT projects, somewhere between 20-30% is more appropriate.

Contingency is needed to fund risk response plans, the impact of realised risks and response plans for issues. It often includes some additional dollars and time to reflect uncertainty.

If one can maintain a budget, and one can maintain a forecast, then basic cost reporting can be done, both ‘year to date’ and at ‘completion’. Any project where the forecast cost is unknown is in trouble. Similarly, any project where scope isn’t managed is in trouble as a budget reflects a statement of scope. Spending the budget and delivering half the scope is just as bad as blowing the budget to deliver all the scope—its just a different perspective.

Agile is very popular due to the belief that schedule and budget are fixed. The reality is that it is scope that is the variable. Add another build iteration or two and the schedule and budget won’t look so good.

Project managers then need to consider the limitations of the tools. Apart from the obvious spreadsheet risk—that formulas might be wrong—project managers will need to deal with accounting and timesheeting system limitations. When asked about earned value, considered the Holy Grail by some, we often push back on organisations. Considered the highest level of cost management maturity, it shouldn’t be considered until a budget can be maintained, scope change managed, actual costs aligned to control packages and scheduling done properly.

Tools such as MS Project do not calculate earned value correctly ‘out of the box’, so innovations are needed. For further details read our whitepaper on Simple Earned Value.

So managing costs is conceptually easy but doing it properly isn’t. If you find this all a bit overwhelming you could consider managing man-hours instead. Logically, if a high labour project is managed well from a man-hour perspective, then the costs should follow.

We undertook such an approach on a vendor/customer project where price sensitivities negated our ability to manage costs. Pleasingly, we delivered under budget (or so we were told)!