I have watched this from both sides now. The model is fine. The workflow is fine. Six weeks later the team is still doing it the old way, and the project quietly stops being mentioned in the update.
Here is what actually goes wrong.
The pilot was chosen because it demos well
Someone picks a use case that looks good in a steering meeting. A chatbot. A summariser. Something visible.
Nobody picked it because it was the thing people complain about on a Monday. So even when it works, nothing in anyone's week gets easier, and there is no reason to change a habit.
Pick the task people already moan about. Relief drives adoption. Novelty does not.
Nobody was given the authority to change the process
This is the one I see most and the one almost nobody names.
A tool gets handed to a team, but the process it sits inside belongs to someone else. So the team can use the tool right up to the point where it would actually save time, and then they stop, because changing the next step is not theirs to change.
You did not delegate the work. You delegated the typing. If the person using the tool cannot also change the shape of the job, the saving never arrives.
No owner, so no one is embarrassed when it dies
Projects with a named owner get fixed when they wobble. Projects owned by a committee get discussed.
One person, named, whose week gets worse if it fails.
Nobody measured the task before
If you did not time the task before, you cannot prove it got faster, and the project becomes a matter of opinion. Opinions lose budget fights.
Time it before. Ten minutes with a stopwatch beats a dashboard built later.
What I would do instead
- One team, one task, one owner
- The task is one people already complain about
- Measure it before you touch anything
- Give the owner permission to change the process, not just the tool
- Let it run badly for two weeks with a human checking the output
That is unglamorous and it works. The interesting part of this job was never the model.