When people quietly work around it

Workarounds are data

Six weeks after launch, somebody keeps a private spreadsheet beside the system. Somebody else re-checks every output by hand. A team has a rule that for one particular client they do it manually. Nobody has complained.

These are not disobedience. They are the most precise feedback you will ever receive, and each one names a specific defect. The spreadsheet holds the field the system does not capture. The re-checking marks the case where it was wrong once. The manual exception is the client whose documents look different.

Go and look at the spreadsheet. It is the requirements document you failed to gather.

The four reasons adoption fails

It lives somewhere else. A tab away, behind another login. Anything requiring a copy and a paste loses to the existing habit, regardless of quality.

It is slower for the person. Faster overall and slower at the moment of use is still slower to the person using it. Waiting eight seconds for a suggestion when typing takes twenty is not obviously a gain.

The correction path costs more than the task. If it is right 90 per cent of the time but fixing the other 10 per cent takes longer than doing it from scratch, the rational choice is to do it from scratch, every time. Reducing the cost of correction usually beats raising accuracy: an editable draft with the source shown beside it can make a 90 per cent system useful, while an unfixable 97 per cent system is not.

It removed a step that was doing something else. This is the subtle one.

The step that was also a check

The person who typed invoice details into the system was, incidentally, reading them. They noticed the wrong purchase-order number, the supplier who had changed their bank details, the quantity that made no sense for that customer. None of that was in their job description and none of it was in the process map.

Automate the typing and the typing goes away. So does the noticing. The errors it used to catch do not stop occurring; they stop being caught, and they surface later, somewhere else, where nobody connects them to the change.

Two consequences. When you map a process, ask explicitly what each person notices while doing each step: a question almost nobody asks. And when you remove a manual step, replace its incidental checking with a deliberate one: a reconciliation, a threshold alert, a sample review. Otherwise you have traded a visible cost for an invisible one, which is exactly the trade this course keeps warning about.

Measure adoption per person

An aggregate of 70 per cent hides two completely different situations: seven people using it fully and three refusing, or everyone using it for the easy 70 per cent of their work. The first is a conversation with three people. The second is a product gap on the hard cases, which is where the value was.

Chart use per person per week, and talk to the people at both ends. The heaviest user has found something you did not design, and the lightest has a reason worth hearing.

Do not mandate

The instinct when adoption is low is to require it. Mandating destroys the signal: people comply visibly and route around it invisibly, and you lose the only instrument you had. You also inherit responsibility for outcomes from a tool people did not choose, which is the worst position to be in when something goes wrong.

Involve them before, because it is cheaper

The people whose work changes should shape the thing before it is built. This is the right thing to do and it is also the cheapest requirements-gathering available: they know the exceptions, they know which client is different, they know which field is never filled in properly. A week of their input at the start prevents the six weeks of workarounds at the end.

And let them change what they can safely change: the prompt for tone, the categories, the thresholds. A team that can adjust a tool treats it as theirs. A team that must file a ticket to change a word treats it as somebody else’s, and works around it accordingly.