The pattern is familiar enough to be a genre.
The build went well. The pilot was genuinely impressive. Somebody demonstrated it in a management meeting and the room was pleased. Then it went quiet. Four months later it is still there, still working, still not being used by anybody except the two people who were in the pilot.
It is not eighty per cent finished in any technical sense. The software does what it was built to do. What is missing is not code.
The last twenty per cent is other people's habits
Every process you automate belongs to somebody. They have a way of doing it, built over years, that accommodates things you have not heard about. Switching to your version means giving up a routine that currently works for one that might.
The pilot succeeded partly because it was a pilot. The two people in it were volunteers, they were being paid attention to, someone answered their questions the same day and they knew it mattered whether they liked it. None of that is true for the twelve people in the rollout.
What the rollout meets instead is a reasonable question nobody has a designated answer to. What do I do when it errors? Does this replace the spreadsheet or do I keep both? Who fixes it if it is wrong at four o'clock on a Friday? Absent an answer, people do the sensible thing and keep the old way going alongside. Now the process runs twice, costs more than it did before and everybody quietly concludes the project did not work.
Three causes, in the order we usually find them
Nobody owns it after handover. The project had a sponsor. Live systems need an owner, which is a different and much less exciting role: fields the questions, decides the edge cases, notices when it stops running. Without one, the first minor fault becomes permanent, because it belongs to nobody.
The old path is still open. If the spreadsheet still exists, people under pressure will use the spreadsheet. Not out of resistance. Because it is Thursday and they know it works. A cutover has to actually cut over, with a date and a decision behind it. Running both "for a while" is how a while becomes a year.
It was built for the process rather than for the person. The automation handles the process correctly and makes somebody's actual day slightly worse. It needs data entered earlier than it used to be, or it produces a report in a format they then reformat. This is the one that hides best, because the process metrics look fine. Nobody has asked the person whether their job got easier.
What we do differently now
Smallest useful thing first. Not a pilot of the full system. One complete, real piece of work that somebody uses on Monday and would miss on Tuesday. If they would not miss it, we learn that for the cost of a small build rather than a large one.
Name the owner before we start. By name. If nobody in the business will own it, that is important information about whether it should be built.
Agree the switch-off date at the beginning. Along with what happens to the old method. This is a conversation everybody would rather have later. Later is when it is hardest.
Ask the person, not the process. Two weeks in: is your job easier? Not is the automation running. The metric that matters is whether somebody's day improved, because that is the only reason anyone adopts anything.
The uncomfortable part
Almost every stalled automation we are asked to look at is technically fine.
That should be encouraging. It usually is not, because it means the fix is not another sprint. It is an owner, a date and a conversation with the people who were supposed to use it about what actually happens at four o'clock on a Friday.
Cheaper than a rebuild. Harder to schedule.