The Monday Morning Test: Designing Process Ownership That Outlasts the Programme

A programme reaches go-live, the ribbon is cut, the training deck is circulated and the project team begins to demobilise. Then Monday arrives. The new workflow is live, but the questions are not: who can approve an exception, who adjusts the measure when volumes change, who decides whether a local workaround becomes the standard? In many UK organisations, the honest answer is that nobody is quite sure. The process has been delivered, but it has not been owned.

That gap is rarely caused by a lack of goodwill. It is usually designed in. Projects are structured around delivery milestones, not steady-state accountability. Decision rights are deferred because they slow the build. Named individuals hold project roles rather than operational ones. Handover becomes a communication event rather than a transfer of authority. The result is a process that is technically live but organisationally orphaned.

Why go-live creates an ownership vacuum

During a change programme, ownership is often implied rather than assigned. The project manager owns the plan. The business analyst owns the requirements. The sponsor owns the case for change. When the programme closes, those roles disappear, but the process remains. If no one has been given explicit authority for its performance, the vacuum is filled by habit, local preference or the loudest operational voice.

This is particularly common where the change crosses functions. A new case-handling process may touch operations, finance, compliance and customer service. Everyone has an interest; no one has a mandate. In the absence of a named owner, the process drifts back towards what each team finds easiest. The training deck remains on the intranet, but the working process quietly diverges from it.

The Monday morning test is simple: can you name the person who will answer for this process next week, and can you describe what they are entitled to decide? If the answer depends on the issue, the time of month or who is in the room, ownership has not been transferred.

Ownership is a set of decisions, not a job title

Calling someone the business owner is not the same as making them the process owner. Ownership becomes real only when it is expressed through decision rights. A process owner should be able to approve or reject changes to the process within agreed limits, resolve exceptions that cross team boundaries, confirm the measures that matter and escalate when performance is at risk. They should also have the standing to say no to local variations that undermine the standard.

This matters because many handovers fail at the first difficult decision. The project team has gone, the owner has the title but not the authority, and the issue is escalated to a steering group that no longer meets. The process then either stalls or is changed by default. Ownership is a design choice: it must be built into the operating model before the programme closes, not added afterwards as a governance label.

A handback checklist for the final fortnight

The final two weeks of a programme are usually consumed by cutover activity. They should also contain a deliberate handback conversation. The following checklist is a practical minimum for any material process change.

1. Name one accountable owner. Not a committee, not a function and not a role that is currently vacant. A single named individual who has the capacity, seniority and operational proximity to act. If the owner is too senior to engage with weekly performance, name an operational delegate with clear authority.

2. Define decision rights in writing. Specify what the owner can decide alone, what requires consultation and what must be escalated. Cover exceptions, process changes, local variations and changes to measures. Keep the language operational rather than legalistic.

3. Agree the measures that will be reviewed. A process owner needs a small set of indicators that show whether the process is working: cycle time, quality, rework, backlog, compliance or customer outcome. Avoid measures that only report activity. Confirm who produces the data and how often it will be reviewed.

4. Establish the escalation route. Name the route for issues the owner cannot resolve, including the threshold for escalation and the expected response time. An escalation route that leads to a disbanded forum is not a route.

5. Confirm change control. State how the process will be changed after go-live, who approves changes and where the current version is held. This prevents the familiar situation in which three versions of the process coexist and no one can say which is authoritative.

6. Record acceptance. The owner should formally accept the process, the measures and the known risks. This is not a bureaucratic signature; it is the moment accountability changes hands.

The first sixty days: make ownership visible

Handback does not end with a document. The first 60 days should make ownership visible to the organisation. The owner should chair the first performance reviews, not the departing project manager. They should decide the first exceptions and communicate the rationale. They should confirm whether the measures are meaningful in practice and adjust them if they are not. The project team can remain available as advisers, but it should not continue to make operational decisions in the background.

A short 30-day check is useful: confirm that the owner has used their decision rights, that the measures are being produced and that at least one escalation has followed the agreed route. At 60 days, review whether local variations are emerging and whether the owner has the authority to address them. These checks expose shadow ownership, where a project team member is still quietly resolving issues because the formal owner has not been empowered.

Common failure modes in UK organisations

Several patterns recur. The first is the matrix ambiguity problem: the process owner has accountability but no control over the teams that deliver the work. The second is the absentee owner: a senior manager accepts the title but delegates every decision back to the project team. The third is the measure mismatch: performance is reported through a finance or service desk dashboard that the process owner does not control. The fourth is escalation to a programme board that has already moved on to the next initiative.

Each of these can be designed out before demobilisation. The test is not whether the handback pack is complete, but whether the owner can act on the Monday after go-live. If they cannot approve an exception, adjust a measure or challenge a workaround, the handover is incomplete.

Conclusion

Go-live is a milestone, not an operating model. The process that emerges after the project team leaves will be shaped by whoever has the authority to make decisions about it. Naming an owner is necessary but not sufficient. The work is to define what that ownership means, give it visible expression in the first 60 days and ensure the route for escalation and change is real. At Jenesys Associates, we see this as a design discipline rather than an administrative close-out task. The Monday morning test is a useful final check: if the answer to who owns it is anything other than a name and a set of decisions, the change is not yet handed over.