5 ways to improve IT project cost management

The often quoted 2003 Chaos report from the Standish Group indicated an average cost blowout of 43% on IT projects; other studies such as Jorgensen and Molokken put it more at 30%. Either way, there is almost a cynical expectation within organisations and senior management that costs will blow out on IT projects.

As a comparison, in engineering and construction projects, cost blowouts are the exception rather than the norm. It is recognised that maturity in planning, estimating, risk and cost management is quite high in these industries. It should also be recognised that these industries have a defined cost focused role in the quantity surveyor. In IT projects there is no quantity surveyor: the cost and estimating roles are spread between the project manager, project support staff, sponsor, finance and sometimes business analysts.

IT projects are typically governed by steering committees, comprising managers from the business who sometimes lack experience in project estimating and cost management. We see basic errors like confusing forecast and budget, focusing on year-to-date rather than at-completion cost. We see confusion between budget and funding approval processes, scope changes without budget change, limited consideration of earned value and so on. We see senior managers referring to contingency as ‘fat’, cultures where contingency is unable to be included in estimates or where contingency gets ‘used up’ or removed from projects.

Learning from other industries in terms of estimating and cost management techniques will help, but recognition of the unique nature of IT projects is needed to adapt these techniques to address the fundamental differences, so here are five keys to estimating and cost management on IT projects. (Note: WBS or Work Breakdown Structure means the breakdown of project scope, not a schedule hierarchy.)

1. Vary estimating techniques depending on the nature of the WBS element

There are many theories on estimating, covering approaches such as Timeboxing (defining time and resourcing to suit), Delphi technique (getting a number of independent estimates), Heuristics (published ratios, e.g. 30% planning: 30% build: 40% testing), Parametric modelling (e.g. Functional Point Analysis) and the good old Guesstimate. What it isn’t clear is that different techniques are appropriate for different scope elements.

While requirements are more often than not estimated using Timeboxing, elements such as testing are better estimated using modelling based on scope, e.g. man hours per test case x number of test cases.

Many IT projects have streams of activities in parallel, for example at the same time technology is being designed—so too should the business processes. In a similar way that multi-storey building schedules are defined by the ‘critical trade’ floor cycle, so too can IT projects be planned based on the critical activity with non-critical activities fitting into similar time frames. Hence the non-critical activities will more often than not be estimated through Timeboxing.

Ideally, two independent estimating methods should be used for each WBS element, then a reconciliation made.

2. Detailed plan, estimate and control by WBS element

One of the issues faced by many IT projects is that the schedule, labour model and cost control systems are not integrated. One of the recognised ways to integrate these systems is by tying them together using the WBS code, that is relate scheduled tasks to a WBS code, relate labour models to a WBS code and relate cost accounts to a WBS code.

Each WBS element should have a detailed schedule, focusing on dependencies—inputs and outputs—as well as the usual tasks, milestones, predecessors, resources etc. Each WBS schedule forms part of the jigsaw puzzle that makes up the master schedule.

If resourced, man hours can be extracted by WBS element, then scaled up to form the resource model. If no resources exist in the schedule then at least dates can align with the resource model. The resource model can then be rated up, added to fixed costs in a financial model and an overall estimate formed. The same model would then be adapted for forecasting an estimate to complete as the project progresses.