Beside the process is not inside it.
Adoption looked acceptable. People genuinely used it. Nothing downstream changed, because the old route still worked.
Two routes and one of them is easier.
People route around the obstacle using a path that was left available.
In deployments we followed, some were still running both routes eighteen months later, and staff used the older one for anything unusual. Given two routes, the difficult cases go to the familiar one — so the new system handles what was already easy, and the total time barely moves.
The reporting looks fine. Logins are steady. A reasonable number of items pass through the new system each week, and the team using it describes it as helpful.
Eighteen months later the headcount is unchanged, the elapsed time is unchanged, and nobody can say what the deployment actually did.
What happened is that the system went in next to the process rather than inside it, and the process it was meant to replace never stopped running.
In the deployments we followed to production or abandonment, a small number still had both routes running eighteen months later. Every deployment that recorded a retirement date for the old process before going live reached production. Not one exception.
Why the old route keeps running
Nobody decides to keep it. It survives because switching it off requires somebody to say a date out loud, and saying a date creates a risk that belongs to whoever said it.
So it stays available “for now”, and for now becomes the arrangement.
The consequence is specific and it is worse than it sounds. Given two routes, people use the new one for the cases it handles cleanly and the old one for everything else. That is a rational allocation and it produces the exact opposite of what the deployment was for.
The new system takes the work that was already easy. The work that needed judgement continues exactly as it did.
In most of those cases, staff described it openly when asked. None of them thought they were doing anything wrong, because they were not — they were routing around an obstacle using a route that was left open.
What “inside the process” actually requires
The phrase is used loosely. In the deployments that worked, it meant four specific things, and each is a decision rather than a build.
The old route is closed on a date
Written before go-live, in the project charter, with a name against it. Not “once we are confident” — a date. Confidence is not a state anybody declares; it is a thing that arrives retrospectively or not at all.
The exceptions have somewhere to go that is not the old route
This is the one that makes closing the old route possible. If the only fallback for a difficult case is the manual process, the manual process cannot close.
A destination inside the new arrangement — a named queue, a person, a stated response time — is what converts “we still need the old way” into “we have a path for the hard ones.” That is the same requirement an agent has, for the same reason: what an agent needs.
The measure changes
If adoption is measured as logins and volume, both routes running looks like success. The measure that reveals the problem is what proportion of total cases went through the new route, including the ones that never touched it.
In several deployments nobody was counting the denominator, and the denominator is where the finding lives.
Somebody owns the transition, not just the system
A deployment has a technical owner. The transition needs one too — the person who decides when the old route closes and who handles the objections that arrive when it does.
In the deployments that ran both routes at eighteen months, that role did not exist in any of them.
The uncomfortable version
Running both processes is more expensive than running either one. The organisation maintains two paths, trains staff on both, and has automated the portion of the work that was least burdensome.
Every firm we spoke to about this described the deployment internally as a partial success. That description is what keeps it running, and it is why this failure mode is so durable — it never produces a moment where anybody has to admit something did not work.
What to do this quarter
If you have a system running alongside a process it was meant to replace:
- Count the denominator. What share of total cases went through the new route, including those that never reached it. If nobody knows, that is the first finding.
- Ask where the hard cases go. If the answer is the old process, the old process cannot close and everything else is secondary.
- Set a date. Then work backwards from it. A date creates the pressure that surfaces every objection at once rather than one per month.
- Name who owns the transition. Separately from who owns the system.
None of that is technical work, and in the deployments that got there it took weeks rather than quarters.
The counts, the method and the limits are in Where deployments stop, free to read in full.
If both routes are still open where you work, the readiness instrument names the stage that describes it. And if you already know what should be built, what we build and how.
Limits
The sample is not representative
Deployments in regulated operations, followed to production or abandonment, ones we were called into. That selects for organisations already aware something was wrong.
The retirement-date result is confounded
The cell where every deployment reached production is small, and small cells overstate their own certainty. Organisations confident enough to set a date may already have the conditions that produce a shipped system, and we cannot separate the two.
It does not establish cause
The correlation is strong and the mechanism is plausible. Neither is a causal claim.
Questions
Is running both routes not just sensible caution during rollout?
For a defined period, yes. What separates caution from drift is whether the period has an end date written down. In the cases still running both routes, none had one.
What if the new system genuinely cannot handle the hard cases?
Then its scope is narrower than the process, and that should be stated rather than absorbed. A system that handles most cases with a real path for the rest is a success. One that handles most cases while the old process still handles everything is not.
Our staff prefer the old way. Is that not a training problem?
Rarely. In the cases we examined, staff used the old route for cases the new one handled badly, which is judgement rather than resistance. Training people out of correct judgement is not the fix.
How long should a parallel run last?
Long enough to establish that the new route handles what it claims, which is usually weeks rather than quarters. The number matters less than that it exists and is written down.
What if closing the old route feels too risky?
That feeling is information. It usually means the exception path has not been built, and building it is the actual work — not more time in parallel.
Does this apply to systems that only advise?
Less directly. An advisory system sitting beside a process is a reference tool, which is fine. The failure mode described here begins when the deployment was expected to change what the process costs.
Govil, A. (2026). Beside the process is not inside it. The Field Report, XONIK.