The programme is not stuck on a bug. It is stuck on a question nobody will answer
By the time a group calls us, the symptoms are familiar. The rollout stopped after the second entity. Two subsidiaries are live and quietly running parallel spreadsheets. A third has refused a go-live date twice without saying why.
The steering committee is usually looking for a technical culprit, because a technical culprit is a comfortable answer. It is almost never the real one. What has actually happened is that a decision belonging to the executive committee got pushed down into a configuration workshop, where nobody had the authority to settle it, so it was settled by default and the default is now in production.
A rescue that only fixes code will hand you the same deadlock in six months, with a larger sunk cost. The first deliverable is therefore not a fix. It is a written statement of what is actually blocking, and who owns each blocking decision.
Most of what you paid for is worth keeping
This is the part that surprises people, and it is the reason we do not start by proposing a re-implementation. In most stalled programmes the majority of the build is sound. The problem is that nobody in the room can currently tell you which parts, and that uncertainty is what keeps everything frozen.
So we audit what actually runs in each entity, not what the documentation claims, and sort it into three piles: what works and stays, what is patching a process that was never defined, and what should never have been built.
Restarting from zero is occasionally the right answer. It is far more often the answer given by whoever wants the next contract. We will tell you which one you are looking at, and we will tell you in writing.
Why it broke at the second entity and not the first
Almost every stalled multi-entity rollout stalls in the same place. Entity one goes live and everyone declares victory, because entity one is where the design was built and the design fits it perfectly.
Entity two is where the assumptions get tested. It turns out the same word meant two things. It turns out one subsidiary posts at a different moment in the flow. It turns out the chart of accounts was harmonised on paper and not in practice.
Those are not defects. They are unarbitrated differences, discovered late, at the worst possible moment, by people without the mandate to resolve them. A rescue that does not force that arbitration back up to the level where it belongs is just a delay.
What you get, and what you can show a board
A rescue has to survive contact with a steering committee, so the output is built for that room, not for a technical backlog.
You get an audit of what runs in each entity, a verdict on what is recoverable and what is not, the list of decisions that have to be taken and by whom, and a phased plan with points where you can legitimately stop and reassess rather than a single all-or-nothing restart.
You also get the uncomfortable version. If the programme is not recoverable on its current terms, we say so early, while the budget to do something about it still exists.
We will work alongside the partner who built it
Usually there is an incumbent integrator, and usually the relationship is tense. Replacing them is not automatically the fix, and it often costs a year of context that nobody has budgeted to rebuild.
We are frequently brought in to arbitrate rather than to displace: to name the decisions nobody has been able to settle, and to give both sides a shared account of what is actually true about the system.
What we will not do is deliver cosmetic customisation to keep the peace. That is how the programme got here.
