Every ERP Program Gets a Curveball. Your Job Is to Know What Not to Lose.

At kickoff, the plan looks complete. The steering committee has signed off on the business case. The Gantt chart has a go-live date circled in the last quarter of next year. There’s a change management plan, a cutover runbook, a data migration strategy, a rollback plan, a business continuity annex, a vendor SLA with penalty clauses. Every risk on the register has an owner and a mitigation. It looks, to everyone in the room, like a program that has accounted for what could go wrong.

It hasn’t. It can’t. Life and business are far more uncertain than we like to think, and no amount of planning buys that uncertainty back.

The list that doesn’t save you

Wills. Inheritance planning. Succession plans. Insurance. Premium service tiers. Security products. Savings. Backups. Disaster recovery. Service continuity. Contingency plans. We build all of this — in our personal lives and in our programs — because we sense, correctly, that events outside our control are coming. In an ERP program the same instinct shows up as parallel runs, rollback windows, penalty-backed SLAs, escrow agreements for source code, and a risk register reviewed monthly.

All of it is worth having. None of it prevents the event. It only changes how much damage the event does when it lands, and how fast you recover. That distinction matters more than most sponsors realise when they’re signing off the budget for it.

What actually lands, in a real program

You don’t need a hypothetical. If you’ve sponsored or sat close to an ERP program for more than a year, you’ve seen at least one of these:

The vendor gets acquired mid-build. Licensing terms you negotiated eighteen months ago no longer apply, and the two consultants who understood your configuration best leave with the acquisition.

A council election lands six months before go-live. Half the elected body that approved the $4M business case is gone. The new councillors ask, reasonably, why the organisation is spending this much on a system nobody explained to them.

Data migration starts, and twelve years of manual workarounds surface — spreadsheets, side databases, informal approval chains nobody documented because they worked well enough to never get looked at. The “current state” the whole program was scoped against turns out not to have existed.

The CEO who owned the business case retires, is moved on, or is pushed out. The incoming CEO didn’t choose this system, didn’t sign the case, and doesn’t yet see why it’s their problem to finish.

A regulatory change lands mid-build — a new reporting requirement, a changed Local Government Act obligation — and scope that was locked down nine months ago no longer matches what has to be delivered on go-live day.

None of these are edge cases. On an eighteen-month program, one of them is close to guaranteed.

What the curveball actually does

The instinct is to treat each of these as a crisis to be absorbed so the original plan can resume. That’s the wrong frame. These events are likely to shape what your program is destined to become. Sometimes they work in your favour — a forced re-scope after a budget shock is often what finally strips out the requirements nobody actually needed, the ones that were in the business case because someone was afraid to say no.

But they will still disrupt your plan. That’s not a failure of planning. That’s what plans are for — to be the thing that gets revised when reality shows up, not the thing you defend against reality.

Baseline, destination, compass

The sponsors who come through these programs intact are not the ones whose plans survived. Their plans didn’t survive either. What they held onto was three things:

Their baseline — the honest state of the organisation before the program started, not the flattering version written into the business case to get it funded.

Their destination — the actual outcome the program was funded to deliver. Not the go-live date. Go-live is a milestone. The destination is the operational and financial outcome that was the reason the spend was approved in the first place, and it should still be legible eighteen months later, after the scope has changed three times.

Their compass — a governance rhythm that keeps measuring real progress against that destination, not task completion against the original Gantt chart. This is what a steering committee exists to do, and it’s where most of them quietly fail: they track whether last month’s tasks were closed, not whether the program is still converging on the outcome it was funded for. A status report that is all green and a program that is drifting from its destination can coexist for a long time. That’s the risk.

Uncertain events will happen. They will disrupt your program, shake your team’s confidence, and there will be very little you can do about the event itself once it has landed. What’s in your control is whether you keep moving toward the destination with growing humility, or whether you spend your energy defending a plan that facts have already overtaken.

What this means for you as sponsor

Expect the plan to be wrong by month six. Not might be — will be. Build that expectation into how you hold the program, not just into the contingency line in the budget.

When a curveball lands, ask what it does to the destination before you ask what it does to the schedule. A slipped date is a scheduling problem. A destination that’s quietly moved out of reach is a sponsorship problem, and only you can catch it.

Stop defending the original timeline once events have overtaken it. Defending a timeline that no longer reflects reality is usually about protecting a decision you made, not about protecting the program.

Don’t let your only signal be the RAG status your vendor or delivery team prepared. That’s their narrative of the program, produced by the people with the greatest incentive to keep it green. If that’s your only compass, you don’t have one.

Hold humility, not control. The instinct under disruption is to grip tighter and demand a recovered plan that looks like the original. The more useful response is to accept the drift honestly, re-baseline against the real destination, and keep going.

None of this is about buying better software or negotiating a tighter vendor contract. It’s about whether you, as sponsor, can tell the difference between your plan drifting and your program failing — and whether there is someone in the room whose only job is to watch for that difference before the cost of not seeing it becomes too high.