We delivered it on time, close enough to budget that nobody complained, and it did everything the specification asked for. The architecture was sound, the tests passed, the performance was better than the system it replaced. By every measure the delivery team was assessed on, it was a success. Eighteen months later, adoption sat somewhere under a third of the intended user base, and the department it was built for had quietly rebuilt most of their old workflow in spreadsheets alongside it.
Nothing had gone wrong in the way projects usually go wrong. What had gone wrong was that we had treated the specification as the goal rather than as somebody's best guess at the goal. The requirements had been gathered from managers, who described the process as it was supposed to work. The people who would use the thing every day worked to a process that had drifted years away from that description, full of small local adaptations that existed for good reasons nobody had written down. We built the documented process faithfully and shipped it into an organisation that did not run that way.
The second failure was that we thought of the rollout as the end. Training was a half-day session six weeks before launch. There was no plan for the period when people are slower with the new tool than they were with the old one, which is the exact period when they decide whether to persist or quietly work around it. Nobody was accountable for adoption after the go-live date, because the project had a delivery manager and delivery managers are measured on delivery. Once the code was in production the team dispersed to the next thing, and the hard part started with nobody assigned to it.
I now ask two questions before agreeing that something is finished. Who is measuring whether this is actually being used in six months, and what happens if the answer is no. If nobody owns that number, the project does not have a real objective, it has a deadline. And I want to have watched the work being done, not just read a description of it, because the gap between the two is where most of these failures actually live.
Working software that nobody uses is not a partial success. It is an expensive way of learning what you failed to ask.
– Serguey Shinder
Top comments (0)