The best way to estimate the cost of IT services

Every now and again I get involved in discussions about what is the best way to estimate the cost of IT services. Should you have a dedicated calculation team that makes all the cost estimates, or should you train the whole project management community and all senior delivery staff to make good cost estimates. It is a question I have been struggling with for the past decade.

The best answer is: It depends. But there are some universal truths on this subject:

1. One estimate is no estimate
2. An estimate always contains uncertainty
3. Don't mix a cost estimate with a price offering

 

One estimate is no estimate

If you make one estimate you have no way of validating the quality of that estimate, so you always need a second estimate to validate that quality. The best practice is to make at least two estimates in a different way:

• Top-down versus bottom-up
• Activity based versus benchmarked deliverables

Each estimation technique has strengths and weaknesses. Using at least two different approaches helps to reduce the effect of the weaknesses in the used approaches. It also exposes the risk areas where there are large differences between the different approaches. The risk areas that are exposed by comparing two different estimates made in a different way are usually the ones you need to apply more strict risk management.

An estimate always contains uncertainty

How often do you encounter cost estimates that are presented as absolute truth? A good estimate should at least be a three-point estimate:

• Worst case
• Expected case
• Best case

In the IT industry I see a tendency to use the best case estimate as a starting point for actually carrying out the IT service. In doing that, you are almost a 100% certain that the execution of the service will be worse than the estimate. In using the worst case estimate you will see that the people involved in running the service will not perform at their best, because there is plenty of slack in the estimate. If the estimate is used in competition you run the risk of not getting the work because other competitors took more risk in their estimate. But in order to be able to decide on the risk profile, you need to know the uncertainties that are part of your estimate.

Don't mix a cost estimate with a price offering

A lot of estimates in commercial organizations like mine are the basis for a price offering to a customer. Don't mix these two things up. An estimate is the best estimation from an engineering point of view of the units that make up the service offering and the associated cost of a combination of a solution for a contract and the way the contract will be staffed. Both the solution and the staffing can be influenced by commercial arguments, but the resulting cost price calculation is a clear and realistic engineering result.

A price offering is a financial structure that is optimized to win the deal. An important input for this process is the set of acceptance criteria or the required pricing structure from the client. It does not need to have a relation with the cost estimate.

The best way to estimate the cost of IT services

Creating a good cost estimate is a skill. You can only develop a skill if you practice it enough. That would favor a (small) dedicated estimating team. You can only do a good estimate if you have knowledge of the subject you want to estimate. That would favour to train the whole project management community and all senior delivery staff.

I firmly believe in the three truths above so we combined them to a simple and elegant estimating process. Let the experts make an estimate and let the Pricing Office make a parametric estimate. If you combine those sensibly you have an estimate that contains information about the uncertainties and compensates for the "non-standard" elements of a project, because each project has - by nature - always non-standard elements. The estimates are made by subject matter experts, the pricing is done by sales and financial experts, thus ensuring that estimating and pricing do not get mixed up. This process is represented by the diagram below:

I have written a paper for the 2011 UKSMA conference on this subject. You can access it here.