Built to be Used

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 … Read more

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 … Read more

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 … Read more

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 … Read more

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. … Read more

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, … Read more

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 … Read more

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 … Read more

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 … Read more

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 … Read more