Technology adoption has an operating owner

I look for the decisions, processes and incentives that must change alongside a technology rollout.

The business owner needs to remain involved after delivery. Usage signals and service feedback help identify whether the intended capability is taking hold. That creates a more useful definition of completion than the point at which a project team hands over an application.

Adoption is neglected largely because of how projects are structured. Budgets end at go-live, the project team disbands and its members move to the next priority. Business owners sometimes assume the new system will change behaviour on its own, when in practice people continue with the workarounds they trust. Parallel spreadsheets survive, old reports continue to be requested and the new tool is used only where it cannot be avoided. On paper the programme is complete. In the operation, the intended capability has barely moved, and the investment case quietly goes unrealised.

Before a programme is approved, I ask the operating owner to agree an adoption plan alongside the delivery plan. It names the decisions and processes that will change, the old tools that will be retired and when, the usage and outcome signals that will be monitored, and who will support colleagues through the transition. Part of the budget is reserved for the period after go-live, so the technology team remains available to resolve issues and refine the system as real use reveals what the design missed. Completion is defined by the owner, not by the project.

Consider a new planning system deployed to regional teams. It works as designed, but planners keep maintaining their own spreadsheets because they trust them, and their managers still ask for updates in the old format. Usage data shows the system is barely touched. The answer is not further training, because the planners already know how to use it. The answer is managerial: regional leaders stop requesting the old format and run their planning reviews from the new system's output. Once the review changes, the spreadsheets fade within a few cycles.

Business leaders sometimes argue that adoption is the technology function's responsibility, or that a thorough training programme will resolve it. Training matters, but it addresses skill rather than habit or incentive. Only line leaders can change what they ask for, what they reward and which meetings rely on the new information. I am careful not to let technology teams take on that accountability, however willing they are, because they lack the authority to make it stick. What they can do is make adoption visible, so the operating owner sees early where change is taking hold and where it is not.

This asks the leadership team to define success in operating terms before a programme starts, and to hold those terms steady after delivery when attention naturally moves elsewhere. It asks the chief information officer to keep technology teams engaged beyond go-live, which has implications for how capacity is planned across the portfolio. And it asks the board to enquire about adoption as routinely as it enquires about budget and schedule. Those questions signal that the organisation values the change the system was bought to enable, not merely the completion of the work to install it.

When adoption has an owner, the conversation after go-live is about value rather than defects. The operating leader can say which behaviours have changed, which have not and what support is needed. That is the evidence a board should expect before it calls a technology investment complete.