Adoption Is the Problem
Software rarely fails because it is bad. It fails because a proportion of the people expected to use it do not, and a system used by two thirds of a team is frequently worse than the thing it replaced.
Why partial adoption is worse than none
Because the record becomes unreliable.
A task system containing most of the work is a system nobody can trust, so people keep their own list alongside it, so the system contains even less. For a related reference, see read more.
A CRM with a third of the interactions logged is a CRM that misleads. Its value was being a record, and an incomplete record is worse than an acknowledged absence.
The failure compounds — every person who routes around it makes it less useful for everybody who did not.
Five reasons people route around it
It costs them more than it gives them. The commonest by far. Data entry benefits the manager and costs the person entering it, and nothing about that arrangement is stable.
It does not fit how the work happens. The tool encoded a process that is not the one in use.
It arrived without explanation. Announced, not argued for, and people comply with what they understand.
It duplicates something. Two places to record the same thing means one gets kept and the choice is not yours.
And it was imposed during pressure, when nobody has capacity for a new way of doing anything.
What predicts adoption
Whether the person entering data gets something back. A tool that gives the entrant a useful view of their own work is adopted; one that only feeds a report is not.
Whether it replaces something rather than adding. Something must be switched off, explicitly, and named.
Whether the people who will use it were asked before the purchase, which is a different question from being trained after it.
And whether the manager uses it. A system the manager does not open is a system that is optional, whatever the announcement said.
The rollout that works
One team, one month, with an explicit decision point at the end.
Switch off the replaced thing on a stated date. Running both indefinitely guarantees the old one wins.
Ask what is worse now, at week two, and act on one answer visibly.
And accept that some tools should be abandoned after the pilot. That is what the pilot was for, and an organisation that has never abandoned one after a trial is not really running trials.
The measurement
Proportion of the relevant work that is in the system, checked once a month for three months.
Not logins. Somebody opening a tool daily and recording nothing in it is a login statistic and an adoption failure.
The short version
- Software rarely fails because it is bad; it fails because a proportion of people do not use it, and partial adoption is worse than none
- An incomplete record misleads, and every person who routes around it makes it less useful for everybody else
- Five reasons: it costs the entrant more than it gives them, it does not fit the work, it arrived unexplained, it duplicates something, it landed during pressure
- Adoption is predicted by whether the entrant gets something back, whether something was switched off, whether users were asked before purchase, and whether the manager uses it
- Roll out to one team for one month with a decision point, and switch off the replaced thing on a stated date
- Measure the proportion of relevant work in the system, not logins
For additional context on this topic, see PC Gamer.