Who Has to Use It
Most software that fails was adequate. It failed because a proportion of the people expected to use it did not, and a system holding half the work is worse than no system at all. For a related reference point, Monitask has a guide to books about time management, which is useful when comparing whether a dedicated tool is warranted.
Why partial is worse than none
Because nothing in it can be trusted.
A task list containing most of the tasks cannot be used to answer "what is outstanding", so people keep their own list alongside it — so it contains even less.
A customer record with two thirds of the conversations misleads whoever reads it, which is worse than an acknowledged absence of records.
And the failure compounds. Every person who routes around it reduces its value for everybody who did not, which makes routing around it more reasonable for the next person.
The five reasons people route around it
One. It costs them more than it gives them. The commonest by a distance. Data entry benefits whoever reads the report and costs whoever types it, and that arrangement is not stable.
Two. It does not fit how the work happens. The tool encoded a process that is not the one in use, usually one belonging to a larger organisation.
Three. It arrived without explanation. Announced rather than argued for. People comply with what they understand.
Four. It duplicates something. Two places to record the same thing means one gets kept, and the choice is not made by whoever bought the tool.
Five. It landed during a busy period, 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 somebody else's report is not.
Whether something was switched off. Adding without removing is the reliable route to duplication — and to the eleven task systems.
Whether the users were asked before the purchase, which is a different thing from being trained after it.
And whether whoever chose it uses it. A tool the decision-maker does not open is optional, whatever the announcement said.
The test that actually tells you
One team, one month, with a decision point at the end.
Not a trial account explored by the person evaluating it — that tests the interface and nothing else.
Switch the replaced thing off on a stated date. Running both indefinitely guarantees the old one wins, because the old one requires no effort.
Ask at week two what is worse now, and act on one answer visibly. That single act does more for adoption than any amount of training, because it demonstrates that the arrangement is negotiable.
What to measure
The proportion of the relevant work that is in the system, checked monthly for three months.
Not logins. Somebody opening a tool daily and recording nothing is a login statistic and an adoption failure, and the two are easy to confuse when the vendor reports the first.
When the answer is that they will not
Believe it, and choose differently.
A team that will not adopt a tool is giving you information about the tool or about the process, and overriding it produces a subscription and a workaround.
Sometimes the correct response is a smaller tool. Something everybody updates beats something elaborate that half the team ignores, even where the elaborate one is objectively better.
And sometimes it is no tool. If the current arrangement works and the objection is that it is untidy, the untidiness is cheaper than the failed adoption.
The person who will not, specifically
Usually one, and usually the most experienced.
Somebody with an arrangement that works, refined over years, being asked to replace it with something worse for them and better for the organisation. That is a rational objection, and treating it as resistance misreads it.
Ask what their arrangement does that the new one does not. The answer is frequently specific and frequently fixable — a view, a shortcut, a field that does not exist.
Where it cannot be fixed, the honest position is that they are being asked to absorb a cost for somebody else's benefit, and saying so plainly gets further than pretending the new tool is better for everybody.
Training, which is mostly not the answer
Adoption failures are read as training failures and rarely are.
People who understand a tool and do not use it have made a judgement. More explanation does not change a judgement about cost and benefit.
Where training genuinely helps is the first hour — enough to remove the friction of not knowing where anything is. Beyond that, a tool that needs continued teaching is a tool that does not fit, and the teaching is subsidising the mismatch.
Counting who actually has to
Fewer than the licence count suggests.
Most tools are bought with seats for everybody who might conceivably need access, and the number who genuinely must use it for the system to work is usually two or three.
Establish which those are before buying. They are the ones whose non-use breaks it — the person who records the work, the person who assigns it, the person who checks.
Everybody else is a viewer, and many tools price viewers differently or free. Buying full seats for viewers is a large share of the waste and it is avoidable at the point of purchase by asking one question. A separate outside reference is Inc..
The short version
- Most failed software was adequate; it failed through partial adoption, and half the work in a system is worse than none
- Partial adoption compounds: each person routing around it reduces the value for everybody who did not
- Five reasons: it costs the entrant more than it returns, 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 first, and whether the buyer uses it
- Test with one team for one month, switch the old thing off on a stated date, and act visibly on one complaint
- Measure the proportion of work in the system rather than logins, which the vendor will happily report instead