Breakdown
The Pilot Went Well and Nothing Changed
A trial can prove the work can be done differently and still leave the business doing it the old way.
A pilot proves a task can be done a different way. It does not retire the way the task is done now. Unless you decide in advance what stops, who has the authority to stop it, and on what date, the trial ends and the old process simply continues.
Last spring somebody proposed a trial and you said yes. Three people used the new tool for six weeks, the write-up said it worked, and the review meeting ended with everyone agreeing it was promising. Twelve months later the invoices are still chased the same way, by the same person, in the same spreadsheet, and the trial account is still billing to somebody’s card every month.
What the pilot actually measured
A pilot answers one question well. Can this task be done a different way. It does not answer whether your business will do it that way, and the second question is usually the harder one.
For six weeks, the old process kept running. It had to. Invoices still needed collecting, and three people testing something new were not going to leave the money sitting there. So the spreadsheet stayed open, the Friday reminders still went out, and the new tool ran alongside all of it.
So the trial was extra work, carried by people who agreed to it because it was temporary and mildly interesting. That is a reasonable way to prove a capability. It is a poor way to judge a change, because you were watching the arrangement at its most expensive moment.
Why the old process kept running
The old way was not just habit. It was the safety net, and the net stayed up because nobody was asked to take it down.
Notice the asymmetry. The pilot had a start date, an owner, and a review on the calendar. The old process had none of those, because continuing needs no approval. Stopping needs a decision, a person willing to make it, and a real change to how somebody spends their Tuesday morning.
So when the six weeks ended, the default took over. In the review meeting everyone agreed the tool worked, which is not the same sentence as the spreadsheet stops on the fifteenth. The first sentence costs nothing to say. The second one has a name attached to it.
The person who would have to stop the old process is often the person who built it. Asking someone to retire their own routine, without telling them what fills that slot in their week, is a larger request than it sounds. That is less a technology problem than a question of what the person is left holding afterward.
What usually gets tried next
Extend the trial. Add a few more people. Bring in a different vendor. Write a rollout plan with training sessions, access requests, and an internal announcement.
Each of those is reasonable and few of them touch the seam. Extending the trial buys more evidence for a question you already answered. Adding people multiplies the parallel running, so the cost of testing rises while the decision stays unmade.
The rollout plan is the one worth examining. Open yours and look for a sentence naming which existing activity ends, on what date, by whose call. Most plans list what gets added: logins, training, a channel for questions. Very few list what gets removed. If the written process still describes the old route step by step, that is the route new people will learn, whatever the tool does.
What to write down before the trial starts
Three lines. What stops, who stops it, and when.
What stops has to be a concrete thing you could point at. The Friday chase-list email. The copy and paste from the bank feed into the tracker. The weekly status spreadsheet. Not manual effort will be reduced, because vague endings do not end.
Who stops it is a named person with the authority to make that call, and whose week visibly changes as a result. When is a date, movable for a stated reason. Written down, the pilot stops being a demonstration and becomes a rehearsal for a decision.
You can run the same test on a trial already going. Ask the three questions out loud. If nobody can answer, the trial is more likely to produce a report than a change.
Sometimes you cannot name what stops, and that is worth sitting with. It usually means the old process is carrying something nobody wrote down: the exceptions, and the judgment about when a reminder should become a phone call. Working out what technology should carry and what stays with a person is the part that belongs before the trial, not after it.
A pilot proves capability. It does not produce change, because change is a decision somebody has to be willing to make and to date. If the tool worked and nothing moved, the missing piece was almost certainly not technical. Before you approve the next trial, write the sentence: on this date, this person stops doing this thing. If you cannot write it, you are not running a pilot. You are running a demo with a longer timeline and a monthly bill.
See how we clarify the right path
See how we clarify the right path
About the author
Missy Ross
Missy Ross is the Founder and AI Architect of Vero Dawn, an AI architecture and solutions company that helps businesses see what could work better, determine the right solution, and bring it to life. Before founding Vero Dawn she spent 21 years in internal audit across banking and manufacturing, at Audit Director level.