Built to Be Used: Why People Work Around the Systems You Build
The software works. The project closed on schedule. So why is everyone still using the spreadsheet?
Eighteen months after go-live, the reports cannot be trusted, the old process is quietly running alongside the new one, and somebody is proposing a project to fix what the first one was supposed to have solved.
Nobody refused. Nobody protested. People logged in every morning. And underneath all of it, the work carried on very much as it did before.
This is the most common way large IT investments fail, and the least visible.
When adoption disappoints, the explanation offered is always the same: people resist change. It is a convenient answer, and it ends the investigation before it starts.
Built to Be Used takes the opposite position. A workaround is not disobedience. It is a precise description of the distance between a system and the work it was bought to support, written by somebody who understands that work better than the project does. A record entered on Monday morning for the week that has already happened is a statement about what the system can actually be used for. Rejection is evidence. Most organisations respond to it by trying to make it stop.
What you will find inside:
• Why technically successful implementations produce no benefit, and how to see it coming
• Eight failure patterns that recur across every sector, each with an early warning sign
• How to study real work before requirements are frozen, in ten days and by one person
• The behavioural assumptions hidden in every business case, and the three questions that test them
• How to measure what people actually do, rather than how often they log in
• What to do when an implementation has already gone wrong
Twenty-seven chapters. Nine working instruments. Ninety sources.
Written for the person accountable for whether the investment produces something (the business sponsor, the programme manager, the director whose operation is about to change) and for the project managers, product owners and analysts who have to make it happen.
Every chapter ends with what to do on Monday.
The system has to work. The work has to work too, and the second is the harder of the two.
- Language: English
- Format: paperback, 398 pages
- ISBN: 979-81-9021-881-7
- Published: 14 August 2026
Articles
The question that waited eleven weeks
15/09/2026
A user asks a question that needs a decision. Eleven weeks later the answer arrives, and it no longer matters. When somebody raises something that needs deciding — a field that cannot be answered, an exception with no route, a rule that contradicts a policy — the elapsed time until an answer is a direct
Your team still sends the old report
15/09/2026
Six months after go-live, your team is still producing the old report. That is not a training issue. Three levers determine whether a team adopts a new system, and only one of them is ever discussed. What the manager asks for. A manager who requests a figure produced by the new system has made that
The saving that never reached the budget
15/09/2026
The business case promised a saving. Two years on, the budget has never seen it. Here is where it usually goes. The most common defect in IT business cases is the conversion of released time into money. Eleven minutes saved per case, times forty cases a day, times two hundred staff, produces an impressive annual
Who has to do something differently?
15/09/2026
Your business case promises a benefit. Who exactly has to do something differently for it to arrive — and has anybody asked them? Benefit cases rarely fail loudly. A target is restated, then extended, then folded into a later programme’s case, and at no point does anybody record that the original investment did not produce
What did your last implementation actually retire? If nothing comes to mind, that is the answer.
15/09/2026
The most common way a large IT investment fails is that the new system is added to the organisation rather than substituted into it. Nothing stops. The workload goes up, and the business case quietly stops being true. One question tests for it. Which report is no longer produced. Which reconciliation is no longer performed.
Everyone is using the system. Almost nobody is using it while the work is happening.
15/09/2026
Adoption reporting typically measures completeness: what proportion of the work was recorded in the system. The more revealing measure is timing. When did the entry happen, relative to the event it describes? A system used correctly but always retrospectively is not carrying the work. It is functioning as a reporting layer over an unchanged process,
Where does your adoption figure come from?
15/09/2026
Somebody reports an adoption figure to your steering committee. Does anyone in the room know what its denominator is? Every adoption percentage carries one, and it is usually chosen by accident. Does the population include everyone with an account, everyone holding the role, or only those who received eligible work in the period? Are people
The implementation failures that cost the most are the ones you will not find for two years.
15/09/2026
They are not dramatic. They are quiet, competent adaptations that leave every formal indicator intact. Which is why acceptance risk needs a third dimension beyond likelihood and impact. If this happens, how would the organisation find out, and when? A risk that announces itself is manageable almost regardless of its likelihood. A system nobody can
“Users may resist the new system.” If that sentence is in your risk register, you do not have a risk. You have an anxiety.
15/09/2026
It contains no cause, no specific behaviour, no consequence and no group. It cannot be assessed for likelihood, cannot be assigned to anybody meaningfully, and cannot be closed except by assertion. A usable acceptance risk states three things. The cause: something identifiable about the design, the process, the environment or the distribution of burden. The
The project was recorded as a success. The benefit never arrived. Both statements are true.
15/09/2026
An implementation produces outcomes at four levels, and only one of them is normally contracted. The technical outcome: the system exists and functions within agreed parameters. The operational outcome: people can use it to perform their work, including the interruptions, exceptions and time pressure the process documentation left out. The behavioural outcome: they do. The