Project Cost Estimation: Simple, Yet Unforgiving

The CFO needs a figure for the ERP project before the next board meeting in ten days. The integrator sent one range, the vendor sent another, and no one has listed the deliverables yet. This is exactly the kind of situation that leads to unforgiving project cost estimates.

The method to avoid this trap is simple. It is the application that requires discipline.

The overrun statistics cited come from public studies by McKinsey and Panorama Consulting; the contingency percentages are benchmarks drawn from PlanAxion’s practice.

According to a study conducted by McKinsey and the University of Oxford on over 5,400 IT projects, large projects go over budget by an average of 45% and over schedule by 7%, while delivering 56% less value than expected.

Why is project cost estimation simple, yet unforgiving?

Project cost estimation is simple because it relies on three known actions—breaking down, costing, and validating—and unforgiving because an underestimation is paid for in overruns, reduced scope, or abandoned projects. There is nothing mysterious about the method. What is almost always missing is the time we are willing to dedicate to it.

A technological change first requires choosing a solution based on your objectives, then naming its major components: software packages, processes, organizational changes, hardware, infrastructure, and integrations. Until these components are written down, any figure is just an opinion.

The cost of a poor estimate is well-documented. McKinsey observes that 17% of IT projects go so wrong that they threaten the very existence of the company, with overruns exceeding 200%. And the 2026 ERP Report from Panorama Consulting indicates that more than a quarter of organizations went over budget, primarily due to additional technologies discovered along the way.

How do you break a project down into deliverables to estimate costs?

You estimate a project deliverable by deliverable, associating each with its cost drivers, resource types, effort, and hourly rates, because it is much easier to cost ten small blocks than one big one. A deliverable that stretches over months always hides unspoken assumptions.

For each deliverable, identify the cost driver(s) that carry the most weight: number of interfaces, volume of data to convert, number of sites, number of reports. Associate a metric of effort with them, then distribute that effort by resource type. Finally, find out the actual hourly rates for each, both internal and external.

Do not do this exercise alone, or at the last minute. Involve the experts for each component, ideally those who will form the project team. A team that has prepared the estimate will stick to it; a team that receives it ready-made will doubt it from the very first week.

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

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

Contingency is applied component by component, according to the risk specific to each, and the budget only becomes credible when the experts who prepared it and the project sponsor agree on the figure. A single percentage applied to the whole levels out risks and does a poor job of protecting the most uncertain components.

Here are the quantitative 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 compared to forecasts (McKinsey and University of Oxford, 2012).
• +15% cost overrun for each additional year of planned duration (McKinsey and University of Oxford, 2012).
• 17% of IT projects become "black swans" with over 200% overruns (McKinsey and University of Oxford, 2012).
• More than a quarter of organizations are over budget, with unforeseen additional technologies cited as the primary cause (Panorama Consulting, 2026 ERP Report).
• $450,000 USD median project cost, with over half of organizations staying within budget (Panorama Consulting, 2025 ERP Report).
• 10% to 15% contingency for a well-understood component, 25% to 40% for a component the organization has never implemented before (PlanAxion benchmarks).

Consensus is just as important as precision. It is built between the group of experts who provided the estimates and the sponsor who will pay, and it forms the basis of mutual commitment. When a third party is involved, this consensus becomes the foundation of the contractual agreement.

It often happens that the total exceeds what the sponsor was hoping for. Do not lower the figure just because it is unwelcome. If the calculation is rigorous, defend it, then propose honest levers: reduce the scope, change the approach, or spread the project over a longer period.

A manufacturer in Drummondville that cuts 20% from an estimate to please the board will find those 20% back in change requests, with interest.

An estimate that is trimmed 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 to a second, independently prepared estimate, or to the actual costs of a comparable, successfully completed project. Discrepancies reveal forgotten assumptions and undervalued line items before the project reveals them for you.

If you have the resources, have two estimates prepared in parallel by teams that do not communicate. Otherwise, compare with historical data: this is why you must keep records of actual costs from past projects.

McKinsey calls this practice reference class forecasting and cites a healthcare provider that halted a billion-dollar project after realizing it was twice as long and twice as expensive as any comparable project.

Finally, document the assumptions behind every figure. A change request can be priced in minutes when the initial assumptions are written down, and in endless meetings when they are not. This documentation is also your best tool for eliminating project uncertainties as you move through the phases.

Watch the scope: the integrator's quote only covers part of the bill. We have detailed the actual costs of an ERP project in Quebec, including internal time, data migration, and stabilization—items that no vendor estimate includes by default.

How much time should be invested in cost estimation?

Enough to break down the work, estimate with experts, apply contingency by component, and validate through comparison—which typically represents two to four weeks for a mid-sized project, according to PlanAxion’s observations. That is a small price to pay compared to a 45% budget 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 as an added cost.

Frequently asked questions

What contingency should be applied to a project cost estimate?

Apply a separate contingency to each component based on its specific risk, rather than a flat global percentage. In PlanAxion’s practice, a well-understood component receives 10% to 15%, while a component never before implemented receives 25% to 40%. The weighted total then reflects the project's true risk profile, not a reassuring average.

Why do IT projects go so far over budget?

According to McKinsey and the University of Oxford, large IT projects exceed their budgets by an average of 45%, and each additional year of duration adds 15% to the overrun. Panorama Consulting identifies the unforeseen need for additional technologies as the primary cause in 2026. In both cases, the root cause is the same: components discovered after the estimate was made.

Qui devrait participer à l’estimation des coûts d’un projet ?

Les experts de chaque composante de la solution, idéalement les futurs membres de l’équipe de projet, avec le promoteur qui approuvera le budget. Une équipe qui a chiffré elle-même les livrables respecte l’estimation et doute moins de son réalisme. Le gestionnaire de projet coordonne l’exercice, mais il ne devrait jamais le faire seul dans son bureau.

Comment valider une estimation de coûts sans deuxième équipe ?

Comparez-la aux coûts réels de projets antérieurs comparables, dans votre organisation ou dans des rapports publics comme celui de Panorama Consulting, qui situe le coût médian d’un projet ERP à 450 000 $ US en 2025. Conservez systématiquement l’historique de vos projets : c’est la base de données de référence la moins chère et la plus fiable qui existe.