Governance & delivery · JNAGA perspective
Who should own a digital change after the project team leaves?
A delivery team can hand over a system. It cannot hand over accountability to nobody.
Published 25 September 2026
Imagine a new scheduling tool works technically, but appointments are still confirmed by email when a request does not fit its standard slots.
The operational owner needs to define the exception rule, the technical owner needs to make it reliable in the tool, and the business owner needs to decide whether the service outcome has improved. None can substitute for the other two.
Separate the kinds of ownership
Technical ownership covers availability, security, integration and maintenance. Operational ownership covers the process, exceptions, training and service quality. Business ownership covers whether the change is still worth doing and what outcome it is meant to improve. These responsibilities may sit with different people, but they need to meet regularly.
If every issue is sent to the technology team, process problems may be treated as defects. If nobody owns the technical side, useful changes can become fragile.
Design the handover before launch
Agree who can change rules and content, how users raise problems and which issues require a decision rather than a fix. Keep documentation proportionate and usable. Test the handover with a normal case and an awkward exception while the delivery team is still present.
Provide time for the new owners to learn. A name in a responsibility chart is not the same as capacity to act.
Keep the outcome visible
After launch, review whether the work actually became easier or more reliable. If it did not, the owner needs authority to adjust the process or the system. Sustained benefit is an operating responsibility, not a final project milestone.