By Ritvars Mētra, Founder of ReadinessCompassThe closure report is signed. The programme team is redeployed, the steering committee is stood down, and the system is described as being in business as usual.
Nobody has said who now owns the process. Eighteen months later, when someone asks why the credit check step was configured to run before rather than after approval, there is no one who knows and no document that says.
Handover is a gate condition, not an administrative step
Government assurance treats this as something to confirm before going live rather than after. The Gateway review workbook — for example Gate 4: Readiness for service — requires confirmation that arrangements are in place for handover of the project from the project owner to the operational business owner, and it states that the review also confirms ownership of the project is clearly identified after handover to operational services.
That is a considerably higher bar than a closure report. It asks who holds the thing afterwards, by name, and expects the answer before the system is live.
Five things that quietly become unowned
| What needs an owner | Who usually gets it | If nobody does |
|---|---|---|
| The process design — what the steps are and why | Nobody. IT owns the system, not the process | Local variants appear and diverge without anyone deciding |
| Configuration rationale — why it was set up this way | Left in a design document nobody reads | Future changes undo deliberate decisions |
| Data quality rules | Assumed to be enforced by the system | Master data degrades from month three |
| Training material and onboarding | Nobody, once the training function disbands | New joiners learn the workaround |
| Decision rights over future change | Whoever shouts loudest, per request | The design erodes one reasonable request at a time |
The second row is the one Markus and Tanis single out. Describing the onward-and-upward phase — routine operation until the system is replaced — they identify as a common problem the loss of knowledgeable personnel who understand the rationales for prior configuration choices and how to improve the business processes through use of the system. They also note that post-implementation investment audits and continuous improvement, though typical activities of that phase, are frequently not performed at all.
Process ownership is not system ownership
The most common failure is assuming IT service management inherits everything. It does not, and it should not.
A service owner is accountable for availability, incidents, access and change control on the system. They are not accountable for whether the order-to-cash process still makes commercial sense, whether the approval threshold is right, or whether three regions have quietly diverged. Those are business questions and they need a business owner with authority over the process rather than the software.
A workable definition: the process owner decides what the process should be, the service owner keeps the system able to support it, and a small standing forum resolves the cases where those conflict. Without the first role the second absorbs it by default, and every question becomes a change request evaluated on technical cost rather than on whether it is a good idea.
Decide it before closure, in writing
The window for this is narrow. Before closure, the programme has authority, budget and the people who know why things are as they are. Afterwards it has none of them, and the questions become unanswerable rather than merely unanswered.
- Name a process owner per end-to-end process, at a level with authority to say no to a change request. A job title, and a person in it.
- Write down the design decisions that must not be undone, with the reason. A single page per process, not the design document.
- Establish who arbitrates when two functions want incompatible changes, and how often that group meets.
- Fund the first year of ownership. An unfunded owner is a name on a slide, and this is where the cost that nobody budgets shows up for the second time.
- Schedule the post-implementation review with a date and an owner, because it is otherwise the activity most reliably skipped.
The test
There is a single question that reveals whether handover happened: if a manager wanted to change one step in this process next month, who would they ask?
If the answer comes back as a name, ownership exists. If it produces a pause, or a service desk queue, or a discussion about who might have to be consulted, then the process has no owner and the design will drift — slowly, reasonably, and irreversibly, one accommodated request at a time.
More on what has to survive a programme in the Adoption Risk Hub, or read how to tell whether a transformation is genuinely embedded.