Why Most ERP Projects Deliver Less Than Promised

The business case was compelling. Eighteen months to positive ROI. £420,000 in annual efficiency savings across finance, operations, and procurement. A single system of record. Real-time reporting. No more spreadsheets.

Three years after go-live, the finance team still reconciles manually at month-end. The procurement module is partially live. The reporting pack is still assembled by hand. The efficiency savings that were quantified in the business case have not been measured since implementation completed. Nobody is sure they materialised.

The ERP is used. It is not delivering what was promised. And the gap between the business case and the lived reality has been quietly absorbed into the organisation rather than formally acknowledged.

This pattern is not an exception. It is the norm. Most ERP projects deliver less than promised. Not because the software is bad or the implementation team was incompetent, but because the business case model and the implementation model are both constructed to produce optimistic projections that the project's actual dynamics make impossible to achieve.

The Common Belief

ERP projects that underdeliver do so because they ran over budget, took too long, or didn't fully implement the planned modules. Fix the project delivery and the ROI follows.

This frames the problem as an execution failure. Better programme management, more rigorous scope control, more effective change management — these would have produced the promised return.

Why That Belief Is Wrong

The delivery failure and the ROI failure are separate problems with separate causes. Better project delivery does produce some improvement in outcomes. But even perfectly delivered ERP projects frequently underdeliver on their business cases.

The reason is that ERP business cases are built on assumptions about adoption, process change, and efficiency gains that the implementation model does not actually deliver.

The business case assumes that when the system goes live, people use it. In practice, adoption is partial. The finance team uses the accounting module. Procurement uses the purchase order module. But the workflow automations that were supposed to eliminate manual steps are configured differently from how the business process actually works. The reports that were supposed to replace the spreadsheet don't produce the data in the format anyone needs. The integration with the CRM that was supposed to close the quote-to-cash loop was descoped in month six.

Every efficiency saving in the business case was predicated on something that was either not delivered, not adopted, or not working as expected.

What Actually Happens

ERP business cases fail for a consistent set of reasons that have nothing to do with the quality of the software.

The optimism problem. Business cases for significant capital investments are written to get approval. The people writing them have an interest in approval. Efficiency savings are estimated generously. Benefits are included even where the pathway to realisation is unclear. Costs and risks are underestimated. This is human nature, not fraud — but it produces business cases that require nearly perfect execution to deliver, and ERP projects are never perfectly executed.

The descoping problem. As the project runs long and over budget, difficult decisions are made about scope. Modules that were planned for go-live are deferred. Integrations that were in scope are cut. Workflow automations that required significant configuration effort are simplified or removed. Each descoping decision has a rationale — preserve the go-live date, control cost, reduce risk. Each decision also removes a piece of the business case.

By the time the system goes live, the business case has been quietly disassembled, piece by piece, through a series of individually justifiable decisions that nobody tracked against the original ROI model.

The adoption problem. Implementation methodologies focus on technical delivery. The system is configured, tested, and deployed. Training is delivered. The go-live happens. What the implementation does not deliver is genuine adoption — the sustained behaviour change that turns a new system into a new way of working.

People revert to familiar processes. The spreadsheet that the system was supposed to replace continues running "just in case." The approval workflow that the system was supposed to automate is bypassed when it slows things down. The data entry that was supposed to happen in the system happens in the old system and gets batch-uploaded.

None of this is visible to the implementation team. It happens after they have moved to the next project.

The measurement gap. ERP benefits are almost never measured against the original business case after go-live. The project team disbands. The programme manager moves on. The benefits realisation process that was planned as part of the project is quietly deprioritised. Without measurement, the gap between promised and delivered benefits accumulates invisibly.

Real-World Example

Company: Calloway Building Products
Industry: Specialist building materials distribution
Size: 160 staff, £31M revenue
Problem: ERP business case delivered approximately 35% of projected benefits three years post-go-live

What happened:

Calloway's ERP business case projected £680,000 in annual efficiency savings, with an implementation cost of £540,000 and a fourteen-month payback period.

Three years after go-live, the finance director commissioned an independent review. The findings were uncomfortable.

Of the £680,000 projected annual savings:

• £180,000 from procurement automation: The procurement module was live but the automation workflows had been simplified during implementation to meet the go-live date. Two of the four planned automation steps still required manual intervention. Actual saving: £65,000.

• £220,000 from finance process efficiency: Month-end close had reduced from nine days to seven days. The two-day saving was partially offset by new reconciliation processes required because the CRM integration had been descoped. Actual saving: £80,000.

• £140,000 from inventory management: The inventory module was live but three of the five warehouse locations were not using it consistently. Inventory was being managed partly in the system and partly in the legacy spreadsheet. Actual saving: £30,000.

• £140,000 from reporting efficiency: The management reporting module required significant manual input because the CRM data was not in the system. The reporting pack still took approximately the same time to produce as before. Actual saving: £15,000.

Total actual annual savings: £190,000. Against a projected £680,000. A £490,000 annual shortfall.

Outcome:

The payback period, recalculated against actual savings, was fifty-six months — not fourteen. The system was used. It was not the transformative investment the business case described.

The Cost of Ignoring It

Capital misallocation: A business that believes its ERP is delivering ROI when it is not will continue to invest in extending and maintaining a system on the basis of a value proposition that does not exist. Capital that could be deployed elsewhere is absorbed by an underperforming asset.

Competitive disadvantage: The efficiency gains the business case promised were not theoretical. They reflected real inefficiencies in operations, finance, and procurement. Those inefficiencies remain. The businesses that have genuinely improved their operational efficiency have a competitive cost advantage that compounds annually.

Board and investor confidence: When a business cannot produce reliable management reporting from its operating system, the quality of the information flowing to the board and to investors is degraded. Decisions are made on assembled data rather than system data. This creates risk in the governance process.

The sunk cost anchor: The belief that the ERP "will deliver the benefits once fully adopted" persists for years beyond the point when it is credible. The sunk cost of the original investment creates an anchor that prevents objective assessment of whether to continue investing in the platform or to make a different choice.

What Good Looks Like

ERP projects that deliver their business cases are characterised by a smaller set of expected benefits, delivered more reliably, rather than a large set of expected benefits delivered partially.

In practice, this means:

Benefits tied to specific system capabilities, not to projected behaviour change. "We will save £200,000 by eliminating the manual procurement approval process" is a specific, testable benefit. This is also why ERP projects take so much longer than promised — the more the business case depends on behaviour change rather than concrete system features, the harder it is to deliver on the promised timeline. It depends on one thing: the system implementing the procurement approval process correctly. "We will save £200,000 by improving procurement efficiency" is not specific. It depends on undefined behaviour change that may or may not occur.

Descoping tracked against the business case. Every scope reduction should be evaluated for its impact on the original ROI model. If a descoped item was load-bearing for a projected benefit, the benefit should be removed from the business case. The board should approve the revised business case, not just the descoping decision.

Benefits measured, not assumed. A benefits realisation plan should survive the project team. The hidden cost of failing to do this is that enterprise software costs more to change than to buy — when the post-go-live reality doesn't match the business case, the system is already locked in and expensive to modify. Someone should own the measurement of each projected benefit for twelve months post-go-live, with a formal review against the original business case.

ENTMAZ Perspective

ERP business cases underdeliver because the implementation model and the ROI model make incompatible assumptions. The ROI model assumes full adoption of all planned functionality. The implementation model produces partial adoption of reduced scope. The gap between them is the missing return.

ENTMAZ's model changes this in a structural way. There is no partial adoption because there is no phased configuration. The business model is compiled from the business description, and the system reflects the entire operating model from the first day. There is no descoping process because there is no implementation project to manage scope within.

The business case is simpler: the system models your business. The question is not whether adoption will be sufficient to realise the benefits. The question is whether the compiled model is accurate. That is a verifiable question with a verifiable answer.

Conclusion

Most ERP projects deliver less than promised because the business case and the implementation are two separate things built on different assumptions. The business case assumes success. The implementation produces reality. The gap between them is absorbed silently.

The solution is not better programme management. It is a more honest business case and an implementation model that is structurally aligned with delivering what was promised — which means not starting with a promise the implementation model cannot keep.

Key Takeaways

• ERP business cases are structurally optimistic — they are written to secure approval, not to accurately predict outcomes
• Scope reductions during implementation silently disassemble the business case, piece by piece, through individually justifiable decisions that nobody tracks against ROI
• Adoption failure is the invisible ROI killer — systems that are live but not genuinely used deliver a fraction of projected efficiency savings
• Benefits are almost never measured against the original business case after go-live; the gap between promised and delivered accumulates without formal acknowledgement
• The solution is specific, testable benefits tied to concrete system capabilities — not projected behaviour change — and measurement that survives the project team