Project Cost Estimation: Simple, but Unforgiving

The CFO wants a number for the ERP project before the next board meeting, in ten days. The integrator has sent one range, the vendor another, and nobody has listed the deliverables yet. This is exactly the setting where unforgiving project cost estimates are born.

The method to avoid that trap is simple. Applying it is what takes discipline.

Overrun statistics cited come from public studies by McKinsey and Panorama Consulting; contingency percentages are benchmarks drawn from PlanAxion's practice.

According to the study by McKinsey and the University of Oxford of more than 5,400 IT projects, large projects run 45% over budget and 7% over time on average, while delivering 56% less value than predicted.

Why is project cost estimation simple, but unforgiving?

Project cost estimation is simple because it rests on three familiar moves, break down, price and validate, and unforgiving because an underestimate is paid for in overruns, amputated scope or an abandoned project. There is nothing mysterious about the method. What is almost always missing is the time people agree to spend on it.

A technology change first requires choosing the solution according to your objectives, then naming its major components: software packages, processes, organizational change, hardware, infrastructure, integrations. Until those components are written down, any number is an opinion.

The cost of a bad estimate is documented. McKinsey observes that 17% of IT projects go so badly they threaten the very existence of the company, with overruns above 200%. And Panorama Consulting's 2026 ERP Report finds that more than a quarter of organizations exceeded their budget, mostly because of additional technology discovered mid-project.

How do you break a project into deliverables to estimate its cost?

You estimate a project deliverable by deliverable, attaching to each one its cost drivers, resource types, effort and hourly rates, because ten small blocks are far easier to price than one big one. A deliverable that stretches over months always hides unstated assumptions.

For each deliverable, identify the cost driver or drivers that weigh the most: number of interfaces, volume of data to convert, number of sites, number of reports. Attach an effort metric, then split that effort by resource type. Finally, find out the real hourly rates for each, internal and external alike.

Do not do this alone, and do not do it at the last minute. Involve the experts for each component, ideally the people who will form the project team. A team that prepared the estimate sticks to it; a team handed a finished estimate starts doubting it in week one.

This breakdown has a side benefit: it becomes the backbone of your IT project plan. Deliverables, effort and resources are already there; all that remains is to place them in time.

How do you apply contingency and reach consensus on the budget?

Contingency is applied component by component, according to each one's specific risk, and the budget becomes credible only when the experts who prepared it and the project sponsor agree on the number. A single percentage applied to the whole flattens the risks and protects the most uncertain components poorly.

Here are the benchmarks we use to frame the discussion:

• 45% average budget overrun and 7% schedule overrun for large IT projects (McKinsey and University of Oxford, 2012).
• 56% less value delivered than predicted (McKinsey and University of Oxford, 2012).
• +15% cost overrun for every additional year of planned duration (McKinsey and University of Oxford, 2012).
• 17% of IT projects become "black swans" with overruns above 200% (McKinsey and University of Oxford, 2012).
• More than a quarter of organizations over budget, unexpected additional technology as the leading cause (Panorama Consulting, 2026 ERP Report).
• US$450,000 median project cost, with more than half of organizations within budget (Panorama Consulting, 2025 ERP Report).
• 10 to 15% contingency on a well-known component, 25 to 40% on a component the organization has never delivered (PlanAxion benchmarks).

Consensus matters as much as precision. It is built between the expert group that priced the work and the sponsor who will pay for it, and it grounds their mutual commitment. When a third party is involved, that consensus becomes the basis of the contract.

The total often exceeds what the sponsor hoped for. Do not lower the number because it displeases. If the calculation is rigorous, defend it, then offer honest levers: reduce scope, change the approach or spread the project over a longer period.

A Drummondville manufacturer that trims 20% off an estimate to please the board will find those 20% again in change requests, with interest.

An estimate you shave to get it approved is no longer an estimate: it is a promise you already know you cannot keep.

How do you validate the accuracy of a cost estimate?

You validate an estimate by comparing it with a second estimate prepared independently, or with the actual costs of a comparable project that was completed successfully. The gaps reveal forgotten assumptions and underpriced items before the project reveals them for you.

If you can afford it, have two estimates prepared in parallel by teams that do not talk to each other. Otherwise, compare against history: that is why the actual costs of past projects must be kept.

McKinsey calls this practice reference-class forecasting, and cites a healthcare provider that stopped a one-billion-dollar project after finding it was twice as long and twice as expensive as any comparable project in the database.

Finally, document the assumptions behind every number. A change request takes minutes to price when the starting assumptions are written down, and endless meetings when they are not. That documentation is also your best tool to eliminate uncertainty in your project as phases progress.

Mind the perimeter: the integrator's quote covers only part of the bill. We have detailed the real cost of an ERP project in Quebec, including internal time, data migration and stabilization, items no vendor estimate includes on its own.

How much time should you invest in project cost estimation?

Enough to break down the work, price it with the experts, apply contingency per component and validate by comparison, which typically means two to four weeks for a mid-sized project, based on PlanAxion observations. That is very little next to a 45% overrun.

Preparing a good estimate is relatively easy. Underestimating is extremely costly. The trade-off is simple: invest the time now, or pay for it later, with the project's credibility thrown in.

Frequently asked questions

How much contingency should you apply to a project cost estimate?

Apply a separate contingency to each component according to its own risk, rather than one global percentage. In PlanAxion's practice, a component the organization knows well gets 10 to 15%, while a component it has never delivered gets 25 to 40%. The weighted total then reflects the project's real risk profile, not a reassuring average.

Why do IT projects exceed their budgets so often?

According to McKinsey and the University of Oxford, large IT projects run 45% over budget on average, and every additional year of duration adds 15% in overruns. Panorama Consulting identifies unexpected additional technology needs as the leading cause in 2026. In both cases the root is the same: components discovered after the estimate was done.

Who should take part in estimating a project's costs?

The experts for each component of the solution, ideally the future members of the project team, together with the sponsor who will approve the budget. A team that priced the deliverables itself respects the estimate and doubts its realism less. The project manager coordinates the exercise but should never do it alone in an office.

How do you validate a cost estimate without a second team?

Compare it with the actual costs of comparable past projects, inside your organization or in public reports such as Panorama Consulting's, which puts the median ERP project cost at US$450,000 in 2025. Keep the history of your own projects systematically: it is the cheapest and most reliable reference database there is.