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 recovery plan was good
15/09/2026
The recovery plan was good. Six months later, one of the three fixes has been delivered. The plan was never the problem. By the time an organisation admits an implementation is in trouble, it has usually been in trouble for a year. Each individual difficulty was explained — this site has a leadership problem, that
Your override rate is falling
15/09/2026
Your override rate has fallen from fourteen per cent to three. Before you call that growing confidence, check what it costs somebody to disagree. A model produces a score. A human assessor makes the decision. Human review is the control on which the whole arrangement rests, and it is described that way to the regulator.
Compliance is high and the data is unusable
15/09/2026
Compliance with the new system is high. The data coming out of it cannot be used. Both are consequences of the same decision. Making use compulsory changes the motivation and nothing else. It does not make a task possible, a design usable, a process workable, or data trustworthy. Where any of those is the obstacle,
The pilot succeeded, the rollout did not
15/09/2026
The pilot succeeded. The first rollout site did not come close. Nobody wrote down the difference. A pilot does not run under normal conditions, and the result cannot be extrapolated until somebody has. Project staff on site. Direct access to developers. Defects fixed in forty-eight hours. Reduced caseload targets. Key users released. A general willingness
Six findings, all classified as minor
15/09/2026
Six findings on the same daily task, all correctly classified as low severity. Together they can cost you several full-time equivalents. Severity is assessed per item and experienced in aggregate. No triage process that scores findings separately can see the difference. An extra confirmation step. A field that defaults incorrectly. A list that resets its
Ninety minutes, five days
15/09/2026
The incident report says ninety minutes, inside the service level, closed. Ask the people who were working that morning. When something goes wrong after go-live, two different things need restoring, and only one of them is usually measured. Technical restoration is the service becoming available again. It is measured in minutes and reported to the
That is a known issue
15/09/2026
A user reports a problem in week one and is told it is a known issue. That is the most expensive sentence available at go-live. Most implementations go live with a list of known defects. Most organisations decide not to publish it, on the reasoning that a list of problems would undermine confidence at the
Five approvals, none ever declined
15/09/2026
Your process has five approvals. Pull two years of records and count how many were ever declined. Approvals accumulate in processes and are never removed. Digitising them makes them permanent. That last part is worth pausing on. A step that was a habit becomes a rule the moment it is configured. Removing it afterwards costs
It tested well and it is slower
15/09/2026
It tested well. Users scored it highly. In production it takes longer than the system it replaced. That combination is common enough to have its own signature, and it has nothing to do with the interface. Usability asks whether a person can operate this system to perform a task. Workability asks whether the work can
Your user group has gone quiet
15/09/2026
Your user group has stopped raising anything substantial. They worked out something you did not tell them. Every implementation has three kinds of decision at any moment. Closed ones, taken and not revisitable without a cost the organisation will not accept. Constrained ones, open within limits set by an architecture, a regulation or a product.