Every troubled ERP project I have been brought in to fix looks different from the outside. Different software, different industry, different explanation for why it went sideways. Strip away the specifics, though, and the same handful of decisions show up again and again. After more than 50 implementations — a meaningful share of them rescues — the pattern stopped surprising me. It became the thing I now watch for before it happens instead of after.
This is not a piece about how to fix a project that is already in trouble. I wrote that one already. This is what the fixing taught me, looked at from enough distance to see the shape of it.
The decision that mattered was made early, and quietly
By the time I am called in, everyone involved wants to talk about the last three months — the missed date, the blown budget, the executive who is now paying attention. But the decision that actually determined the outcome was almost never made in that window. It was made in week two or three, in a requirements workshop nobody thought was consequential, when a shortcut got taken because the alternative felt like it would slow things down.
The shortcut is rarely dramatic. It is usually something like: requirements were gathered from the people who manage the process rather than the people who run it every day. That single choice compounds for months before anyone can see it, because the resulting system is technically correct and only becomes operationally wrong once real volume and real exceptions hit it.
“On track” and “actually on track” are different claims
Every project I have rescued had a status report that said green right up until it didn't. That is not usually dishonesty. It is optimism applied to a plan that was already fiction, repeated often enough that it started to feel true to the people saying it.
The lesson I keep relearning is that a status report measures activity, not readiness. Tasks can close on schedule while the thing the business actually needs — a process that works the way the business works, not the way the system was built — quietly falls further behind. The projects that avoid rescue are the ones where someone senior enough is willing to say, in month two, that the plan does not match reality, even when that is an unwelcome thing to say to an executive sponsor.
Scope does not get cut. It gets deferred, and deferred is a loan
Nearly every rescue I have done involved a “phase two” that had quietly absorbed every hard decision the team did not want to make during phase one. Deferred scope is not resolved scope — it is a loan against the go-live date, and it comes due with interest, usually during user acceptance testing when someone from finance or operations opens a screen and says the process in front of them is not how the business actually works.
The projects that hold up treat scope decisions as decisions, made once, with someone accountable for the tradeoff. The projects that end up needing a rescue treat scope as something to negotiate later, with whoever is still in the room.
What I build differently now
None of this changed the technical side of how I run implementations. It changed where I spend my attention. I sit in requirements sessions with the people who do the work, not only the people who manage it. I insist on an honest, boring status conversation every two weeks rather than a dashboard, and I would rather deliver an uncomfortable update in month two than a surprising one in month five. And I do not let scope questions sit open past the milestone where they were supposed to be answered — better to make the tradeoff now, in the light, than to inherit it later as an emergency.
This is also, plainly, why I have not built Sequente Cloud around a staffing model. A junior team executing a plan cannot make the judgment call to interrupt a schedule and say the plan is wrong. That call has to come from whoever is senior enough to be believed, and it has to come early enough to matter. That is the entire argument for staying personally engaged on every engagement through cutover, not just the ones that are already in trouble.
Across the implementations I have led, client retention has held at 98% and the average client sees roughly 3x return on the engagement. I do not think that comes from avoiding hard projects. It comes from treating the early, unglamorous decisions with the seriousness that the last three months of a troubled project eventually force on everyone anyway — just earlier, when it is still cheap to get right.
If you are heading into an ERP project and want a second set of eyes on where the early decisions are being made, I am happy to talk it through.