1. Stop configuring
The instinct is to push through because stopping feels like losing time. Resuming configuration on the foundation that failed is the single most common reason a rescue does not work.
Customers
We are called into stalled ERP implementations regularly, usually on somebody else's product. Twenty-seven of forty-one recovered to a working state. The fourteen that did not are the more instructive number, and they had things in common.
Tell us where the project is and what has slipped. We will say honestly whether it is recoverable.
Customers
Almost every successful recovery followed the same sequence, and the hardest part is the first step.
The instinct is to push through because stopping feels like losing time. Resuming configuration on the foundation that failed is the single most common reason a rescue does not work.
Not a questionnaire — an actual diagnostic. Data worse than anyone knew was the primary cause in 24% of stalls and was nearly always discovered during load rather than during a nominal assessment phase.
Derived from a quarter of real data rather than reconstructed from the original interviews. This is where the surprises that stalled the project originally get surfaced deliberately.
One person per area, able to decide across departments within a day. No internal owner with authority was the primary cause in 19% of stalls.
A new plan built on what is actually true, including what has to be thrown away. Customers find this harder than the technical work, because it makes sunk cost explicit.
Median 11 weeks from engagement to a working state. The ones that took longest were those where the organisation wanted to skip to this step.
These are more useful than the twenty-seven, and they clustered into three patterns.
Six of the fourteen. Not a lack of engagement — sponsors attended every meeting — but no single person who could settle a cross-departmental question about approval thresholds or chart structure. Every decision escalated and stalled again.
A rescue cannot supply organisational authority. Where we identified this and it did not change, we withdrew rather than continuing to bill against a project that was going to stall again.
Four. The project had consumed enough budget and political capital that re-baselining honestly was impossible — admitting that eighteen months of configuration had to be discarded was a conversation nobody in the room could have.
These usually ended with the project continuing on its original path and failing again some months later.
Four, and this is the rarest cause by some distance — consistent with our finding that software incapability is the primary cause of only about 4% of stalls generally. In each case the mismatch had been visible in week one of the original selection and nobody had wanted to say so.
We will not quote a rescue without looking first, because nobody honestly can. A paid assessment establishes what state the existing work is in, what is salvageable, and whether the causes are addressable at all.
That assessment produces a written recommendation, and roughly one in five concludes that the project should be stopped rather than rescued. We would rather deliver that conclusion in week two than bill against something that will stall again.
Rescues themselves start at $15,000 and are quoted after the assessment on a fixed scope with written exclusions.
Of the forty-one, the ones that recovered fastest were those where somebody raised the alarm in month three rather than month eight. The failure patterns are visible early and the cost of addressing them compounds. If your project feels wrong and you cannot say why, that instinct is usually worth acting on.
Questions
A rescue can fix data, requirements, and sequencing. It cannot supply an organisation with authority to decide.