15.5 months is the median, not the horror story

The median ERP implementation now runs 15.5 months, according to Panorama Consulting's 2024 ERP Report - and that figure is the ordinary result, not the cautionary tale. The projects that reach the trade press are the lawsuits and the smoking go-lives. The quieter, more common problem is that a routine, on-plan implementation still freezes your commerce and loyalty roadmap for well over a year, and historically returns less than half the benefits it was sold on.

Why should the median worry you more than the disasters?

Horror stories are survivorship-visible. A payroll run that pays people the wrong amount, a distribution centre that cannot ship, an integrator on the receiving end of a lawsuit - those get written up precisely because they are rare enough to be news. We walked through one in the go-live that sued its integrator. The median project makes no news at all, and that is the point: 15.5 months is what happens when nothing goes especially wrong. Half of all implementations take longer. In 2023, roughly 42% of projects still overran their planned schedule. So the honest planning assumption for a competent, well-governed programme is not "a few months" and not "the occasional catastrophe" - it is "the better part of two years, with a coin-flip on whether even that holds." Budgeting a normal ERP project as a short effort is the actual planning error, and it is a common one.

For a brewer or a CPG business, translate 15.5 months into your own calendar rather than the integrator's Gantt chart. Two summer peaks or two festive seasons can pass entirely inside a single implementation window, each one run on frozen pricing, frozen promotions and whatever manual scaffolding the commercial team could improvise. The cost of the programme is not only its budget line; it is the commercial moves you could not make while it ran.

What does the ERP clock do to the layer above it?

Order capture, loyalty, returnables, delivery scheduling and trade analytics sit on top of the financial ledger, not inside it. During an implementation that dependency turns into two concrete taxes. The first is freeze windows: master data, pricing tables, org hierarchy and tax logic get locked months before cutover, and every downstream feature that touches them waits. The second is dependency queuing - each route-to-market change now sits behind the ERP's critical path, because no one will risk destabilising the ledger for a loyalty tweak or a new depletion report. Neither tax appears as a line item on the programme budget; both appear as calendar time your competitors are free to use.

The result is the pattern we described in the 12-month purchase of a 6-week feature: work that is genuinely small in engineering terms inherits the timeline of the largest programme in the building. Field teams do not wait politely for this. They route around it, and the workaround is almost always a spreadsheet, which is the whole argument behind why Excel is your real route-to-market platform. A frozen ERP does not stop the business; it just relocates the business to somewhere you cannot govern it.

Why do the normal projects still under-deliver?

Because the schedule slips and the benefits case slips with it. Historically, around two-thirds of organizations realized under half of the benefits they anticipated - a striking number, given that the benefits case is what justified the spend in the first place. On cost, the 2024 data shows 33% of implementations exceeded budget, and the reported causes describe scope discovered mid-flight rather than planned upfront:

Read those three together and the story is consistent: the work that overruns is the work nobody scoped, because it only becomes visible once integration starts and the real data structures meet the real business rules. None of this is incompetence. It is the base rate. A programme can hit every governance milestone and still land squarely in this distribution, which is why treating the median as a failure to be coached away misreads the problem entirely.

The benefits erode through a predictable mechanism, too. Process redesign - the part that actually produces the savings - is the first thing deferred when the schedule tightens, so the new system goes live wrapped around the old ways of working. Users revert to familiar habits, the promised automation stays switched off behind a change-management backlog, and the business case quietly becomes a reporting exercise rather than a scorecard anyone is held to. By the time anyone measures realized value, the baseline has drifted and the honest answer is "we are not sure," which in practice reads as "less than we hoped."

So what do you actually do about it?

You stop coupling route-to-market velocity to the ledger's clock. The financial core can take 15.5 months to re-platform if it genuinely must; order capture, loyalty and returnables do not have to inherit that cadence. Keep the SAP financial core in place and run the customer-facing capabilities on a separate, event-driven layer that ships on its own schedule - the shape we lay out in our platform architecture. That is a direction rather than a weekend project, and it is the subject of most of the rest of this blog.

The next ERP cycle is already on a roadmap somewhere in your organization, whether or not it has a charter yet. The question that matters is not whether it will run long - the base rate says it will - but whether your route-to-market roadmap is chained to it when it does. Decide that while the coupling is still an architecture choice and not a freeze-window email. When the 15.5-month median lands, the difference between a frozen year and a shipping year will already have been designed in.