The short answer
Software adoption fails for one reason far more often than any other: the new tool makes the day longer for the person using it, so that someone else can have better data. No amount of training fixes that.
Test it in one minute
Time the task as it is done today. Then time it in the new system.
If the second number is bigger, you have your answer, and every other explanation being offered in meetings is a distraction.
The four real causes
It is slower than what it replaced. Photographing a paper job sheet and sending it on WhatsApp takes about eight seconds. Any system that takes longer than that competes badly, whatever else it does.
It was designed for the report, not the task. Somebody wanted better management information, so fields were added. Each field is a few seconds of somebody's day, and none of them help that person.
It does not work where the work happens. No signal on site. Gloves. An old phone. Bright sunlight. Software designed at a desk fails in the field.
Nobody who does the job was asked. Not consulted in a meeting, watched doing the work. These are different things and only the second one is useful.
What to do about a tool already rejected
In order
- Watch three people do the task the old wayDo not ask them about it. Watch and time it.
- Time the same task in the new system
- Count the fields that exist for reporting rather than for the taskRemove every one you can live without.
- Ask what breaks it in the real environmentSignal, gloves, noise, light, battery.
- Decide honestly whether it can be fixed or should be replaced
Do not mandate it
Building the other way round
Start with the person doing the work and make their task faster. The management information arrives as a by-product, because the data is being captured anyway.
That inverts how most internal software is specified, and it is why we start internal tool projects by asking what the person on site does today rather than what the office wants to see.
Common questions
Is it a training problem?
Almost never. If people need training to do something they already know how to do, the software has made it harder. Training is what organisations reach for when they do not want to accept that the tool is wrong.
How do I get buy-in before rolling something out?
Do not ask people whether they want it. Watch them do the task now, and time it. If your new process is slower than what you timed, it will not be adopted whatever anyone said in the meeting.
Should we mandate it?
You can, and you will get compliance rather than use: minimum entries, made up data, and the real work still happening somewhere else. That is worse than no system, because now your reports are confidently wrong.