Working and used are different states
The most common quiet failure is a system that does exactly what was specified and that nobody opens. It is a design and trust problem, and it is entirely predictable.
The predictor is simple: were the people who do the work involved before the build, or told about it afterwards?
Involve them at the start
- Ask what the tedious part of their job actually is — it is often not what management assumes
- Show them the review interface before it is built, as a sketch
- Change it based on what they say, visibly
- Let two of them use it first and tell the others
A system the team helped shape gets defended. A system delivered to them gets tolerated until the first error, then abandoned.
Address the obvious fear directly
People wonder whether this is about replacing them. Not saying anything does not stop them wondering; it just leaves them to conclude the worst.
Say plainly what the intention is. If it is capacity rather than headcount, say so and mean it. If it is not, say that too — people find out either way, and the manner of finding out determines everything.
Make version one genuinely faster
- Fewer clicks than the current process, not more
- Inside the tool they already use
- No new login
- Obviously correct on the common case, from the first day
A first version that is slower than the manual process will not get a second chance, however good the roadmap is.
Measure adoption, not just accuracy
Usage rate, suggestion acceptance rate and the proportion still doing it the old way. Those numbers tell you whether the project worked far better than any accuracy figure.
If usage is low and accuracy is high, the problem is the interface or the trust, and both are fixable if you notice.