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.
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.