The Price of Speed Is Always Paid. The Question Is by Whom.

“ERP projects can be delivered within months.”

Most executives have heard this line. It usually comes from a vendor presentation or an implementation partner’s proposal, and sometimes from a peer who says their council got it done in a year. It is appealing because it promises that the disruption will be short, the benefits will arrive sooner and the budget will stay contained.

It is also true, in a narrow sense. ERP projects can be delivered within months.

But at what cost?

How projects are speed up

No hidden technique makes a project faster. There are only three levers, and every experienced project manager knows them.

Deploy more resources. You add more consultants, more contractors and more of your own staff taken off their day jobs.

Reduce scope. You go live with less: fewer modules, fewer integrations and fewer reports, with the rest pushed to “phase two.”

Optimise dependencies. You run in parallel what should run in sequence. Testing overlaps with build, training starts before the system is stable, and data migration runs alongside configuration.

Each lever works, and none of them is free. Each one also adds its own overheads and risks.

More resources mean more coordination and more handovers, and more people who understand one piece but not the whole. Reduced scope creates workarounds, manual processes and a phase two that often never gets funded. Optimised dependencies mean that when one thing slips, everything connected to it slips too, and there is no buffer left to absorb it.

The dynamic behind the date

For a sponsor, the useful question is why the pressure to go fast exists at all, more than how to go fast.

Sometimes the reason is real. The old system is losing vendor support, a regulatory deadline is fixed, or the organisation cannot afford another year of manual reconciliation. Those are good reasons, and they belong in the decision.

More often the reasons are quieter.

The date has been announced. It is in the corporate plan or has been reported to Council, and elected members have repeated it. Moving it now feels like an admission.

The vendor proposed it. A short timeline wins the tender, and whoever proposed it rarely carries the consequences of it.

The sponsor wants it done. ERP projects are long, draining and politically exposed, and a faster finish looks like relief.

None of these is unreasonable. But notice what they have in common. None of them is about the organisation being ready. Each is about something else: reputation, a commitment already made, or the wish to have the difficult thing behind us.

When speed is chosen for these reasons, the project starts serving the date rather than the date serving the project.

Who actually pays

This is where the dynamic becomes clear.

The decision to speed up is made at the top, but its cost rarely lands there.

It lands on the finance officer doing month-end close by hand because the reports were descoped. It lands on the payroll team running a shadow spreadsheet because parallel testing was cut to one cycle. It lands on the depot supervisor whose crew was trained on a system that changed two weeks later. It lands on the next budget, which absorbs the phase two that was promised, and on the next executive, who inherits the workarounds.

Much of it also lands later. The go-live date is celebrated when it happens. The cost appears over the following six to eighteen months, as staff turnover, rework, audit findings and quiet loss of trust in the system. By then the project has closed, the vendor has moved on, and the connection between the decision and its consequence is hard to trace.

This is why speeding up feels cheaper than it is. The saving is visible and immediate, while the cost is spread out, delayed and paid by someone else.

What this asks of the sponsor

I am not arguing against speed. There are times when moving fast is the right call and waiting is the expensive option. What I am arguing for is honesty about the trade.

Before you approve a compressed timeline, three things should be on the table.

Why are we actually speeding up delivery? Is it the organisation’s reason or someone’s reason? Would it survive being said out loud at a Council meeting?

What is the real cost of speeding up? The real cost includes the added resources in the contract, the descoped work, the removed buffers and the risk taken on by staff who will run the system on day one.

Who is going to pay the price, and what will the ultimate cost be? Name the teams, and name the budget year. If the answer is “someone else, later,” you have not saved anything. You have moved the cost somewhere you will not see it.

A sponsor who can answer these questions has made a decision. A sponsor who cannot has only agreed to a date.

Here are some questions to ponder.

When the timeline on your project was set, who in the room was accountable for what it would cost to hit it?

If your project is running faster than planned, do you know what was given up to make that possible?

And when the price of speed finally arrives, will it be paid by those who chose it?