The Software Project That Was Meant to Take Eighteen Months
Enterprise resource planning implementations overrun on budget and schedule with striking consistency. The reasons are structural rather than technical, and the failures follow a repeatable pattern.
What Is Being Replaced
An enterprise resource planning system is the software backbone that runs a company core processes: general ledger, procurement, inventory, order management, manufacturing planning and payroll, all on a shared database.
Replacing one is not a software purchase. It touches nearly every process in the business simultaneously, because the whole point of the system is that those processes share data. That interconnection is the source of both the value and the risk.
An ERP implementation is a business process redesign that happens to involve software. Companies that treat it as an IT project are describing the wrong problem.
The Cost Structure
The licence or subscription fee is a minority of the total. The costs that dominate are the ones easiest to underestimate.
| Cost element | Typical treatment |
|---|---|
| Software licence or subscription | Visible, well estimated |
| System integrator fees | Large, often the biggest line |
| Internal staff time | Substantial, frequently uncosted |
| Data migration and cleansing | Consistently underestimated |
| Customisation and integration | Grows through the project |
| Training and change management | Cut first when budgets tighten |
| Post go live stabilisation | Rarely budgeted at all |
Internal staff time deserves particular attention. A serious implementation requires the company best process experts full time for a year or more. Those people still have day jobs, and the cost of backfilling them or of their normal work going undone is real spending that never appears in the project budget.
Configure or Customise
The central design decision is whether to adapt the business to the software or the software to the business.
Standard configuration is cheaper, faster and far easier to upgrade, at the cost of forcing process changes on people who have valid reasons for working the way they do. Heavy customisation preserves existing processes and creates a system that is expensive to maintain, difficult to upgrade and dependent on whoever wrote the modifications.
The pattern that causes trouble is starting with a commitment to standard configuration and then granting exceptions department by department, each individually reasonable, until the accumulated customisation is extensive and unplanned. The budget was set on the original commitment.
Data Is the Underestimated Problem
Migrating data from old systems into the new one consistently consumes more effort than planned, because it forces the company to confront the quality of records it has been tolerating for years.
Duplicate customer records, inconsistent product codes, inventory that exists in the system and not in the warehouse, and fields used for purposes they were never designed for all have to be resolved before migration. Every organisation believes its data is cleaner than it is.
Why Go Live Is the Dangerous Moment
The public failures of ERP implementations share a shape: the system goes live and the company cannot execute basic operations. Orders cannot be entered, shipments cannot be picked, invoices cannot be issued. There are well documented cases of manufacturers and distributors reporting material earnings impacts from exactly this.
The cause is usually that the cutover strategy left no fallback. A big bang approach, switching everything at once, is cheaper and faster than running old and new systems in parallel, and it removes the ability to retreat when something breaks. Phased rollouts cost more and preserve the option to stop.
Compounding this, training is the line item most often cut when the project runs late, so the system goes live with users who do not know how to operate it and a support function sized for steady state rather than for the first month.
What Distinguishes the Successes
Projects that go well tend to share features: executive sponsorship from the business rather than from IT, a genuine willingness to change processes rather than customise, phased rollout where the business allows it, data cleansing started long before implementation, and a budget that includes internal time and post go live support.
They also tend to define success as operational continuity rather than as hitting the original date, which sounds like lowered ambition and is the reason the shipments keep moving.
The Bottom Line
ERP overruns are so consistent that they should be treated as a base rate rather than as a series of unlucky projects. The costs that break budgets are internal time, data migration, accumulated customisation and post go live stabilisation, three of which are usually absent from the original case. The single decision that most affects the outcome is whether the company is genuinely prepared to change how it works, because the alternative is paying to rebuild its existing processes in more expensive software.