A pilot goes brilliantly. Everyone in the room agrees it should go wider.
Nine months later it is still in that room.
I have watched this happen in banking, in insurance, in public sector, in manufacturing. Different countries, different budgets, different vendors. The same nine months.
For a long time I thought each one was its own story. They are not. They stall at the same joint every time, and it is never the joint anyone is looking at.
Where it actually stops
Not the technology. The technology is usually fine, and in the pilot it was obviously fine, which is why the pilot went brilliantly.
It stops at the handover between two systems that nobody owns.
Something leaves system A. Something needs to arrive in system B. And in between there is a step that exists only in a person's habit. Someone checks a thing. Someone forwards a thing. Someone knows that on Thursdays it goes the other way.
That step is not in the process documentation. It is frequently not known to the people who commissioned the work. It is often not known to the person doing it, in the sense that they could not describe it if you asked, because it stopped being a decision years ago and became a reflex.
The pilot did not touch that step. Pilots are chosen precisely because they are clean. That is what makes them pilots.
Then the rollout arrives at the joint, and the joint is where all the real complexity was stored the whole time.
Why the vendor conversation never finds it
Because everyone in that conversation is qualified to talk about the thing on either side of the joint, and nobody is qualified to talk about the joint.
The system A people know system A. The system B people know system B. The procurement conversation is about capability, and both capabilities are genuinely present.
The joint has no owner, no budget line, and no diagram. So it does not come up. So the estimate is wrong, not by a margin but by a category.
One thing needs saying plainly here, because this kind of piece usually goes wrong at exactly this point.
The people are not the problem. I have never once walked into a stalled rollout and found lazy staff or an incompetent team. What I find, consistently, is capable people carrying an undocumented step that the organisation depends on and does not know exists. That is not a failure of theirs. That is a gap in the system that they have been quietly absorbing, often for years, usually without being thanked for it.
The gap is the problem. The people are the ones who have been holding it together.
Five things I now do differently
Ranked by how much they change the outcome.
1. Map the joints before mapping the capabilities.
Most discovery starts with what each system can do. That produces an accurate document that predicts nothing.
Start instead with every point where work changes hands. Between two systems. Between two teams. Between a system and a person. Those points are where the estimate lives.
The question that finds them is not "what does this system do". It is "what happens to this after you finish with it, and how do you know it arrived".
2. Ask what happens when it goes wrong, not what happens when it works.
The happy path is documented. The happy path is what the pilot tested.
The exceptions are where the undocumented work lives, and the exceptions are the majority of the actual labour. Ask about the last time something did not arrive. Ask who noticed. Ask how they noticed. The answer is almost always a person, and almost never a system.
That answer is your real scope.
3. Pilot the ugliest case, never the cleanest.
This one costs political capital and it is worth every unit of it.
A pilot on the clean case proves the technology works, which nobody seriously doubted. A pilot on the ugly case proves whether the rollout is possible, which is the only open question.
The instinct to pilot the clean case is understandable. It produces a good demo. It also produces a number that is wrong by a factor, and that number is what the whole plan gets built on.
4. Find the person who has been absorbing the gap, and ask them.
There is almost always one. They are rarely senior. They are usually the reason nothing has fallen over yet.
They can tell you in twenty minutes what a discovery workshop will not reach in three weeks, because they are not describing the process, they are describing what actually happens.
Two conditions. Ask genuinely, and make it obvious that naming the workaround is not naming a fault. If it lands as an audit, you get the official answer, and the official answer is the one already in the documentation and already wrong.
5. Write down what the automation will not do.
This is the cheapest item on the list and the one most often skipped.
Every rollout has a boundary. Past that boundary a person decides. If that boundary is not written, two things happen. People assume it sits further out than it does, and then trust collapses the first time something crosses it unhandled.
Naming the boundary early costs one paragraph and buys the entire credibility of the thing.
What this predicts
If you are looking at a stalled rollout right now, I would bet on this order.
The pilot ran on a clean case. The clean case has no handover in it, or has one that happens to be automated already. The wider set does. Nobody has costed that, because the joint is invisible from both sides and belongs to neither.
Which means the fix is usually not a better model, a different vendor, or more budget for the same shape of work. It is a much smaller and much less exciting piece of work at a specific seam, done first.
I hold that at maybe seventy percent. It is the pattern I keep finding. It is not a law.
What actually changes when it works
The thing that makes a rollout stick is not that it does more. It is that the people around it stop having to check whether it worked.
That sounds minor. It is the entire difference between a tool that is used and a tool that is tolerated.
Checking is invisible labour. It does not show up on any dashboard. It quietly consumes the exact capacity the rollout was supposed to give back, and it continues right up until the seam is genuinely closed and people believe it is closed.
So the honest measure is not throughput. It is whether anyone still keeps a private spreadsheet on the side.
If they do, it is not finished. And they are not being difficult. They are being correct, because at some point the seam bit them and nobody has shown them why it will not again.
Your turn
Think of one process where work changes hands in your organisation. What is the undocumented step in the middle, and who has been quietly carrying it? One line.
If this was useful
I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. Find me on X, GitHub, and the work at next8n.com.
Top comments (0)