Most IT implementations that fail do not fail loudly.
The software is delivered. The tests pass. The system goes live more or less on schedule, and the steering committee records a successful implementation and closes the project.
Eighteen months later, the spreadsheet is back. The reports cannot be relied on. Somebody is proposing a project to repair what the first one was supposed to have solved.
Nobody refused. Nobody protested. People logged in every morning, transactions were processed, reports were produced. Underneath all of it, the work carried on very much as it did before.
When adoption disappoints, the explanation offered is almost 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 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.
The book sets out what determines whether people will use a system, and what to do about it while it is still cheap: how to study real work before requirements are frozen, how to find the behavioural assumptions hidden in a business case, how to measure what people actually do rather than how often they log in, and what to do when an implementation has already gone wrong.
Twenty-seven chapters. Nine working instruments. Every chapter ends with what to do on Monday.
#ITimplementation #DigitalTransformation #ChangeManagement #ERP #ProjectManagement
This article accompanies the book Built to Be Used.