Who owns the Monday after go-live?

A technology programme has a cutover plan, an implementation team and a date in the diary.

Now imagine the first ordinary working day after launch.

A team member cannot complete an important task. A manager spots that a report no longer matches the process. The service desk is unsure whether a request is an incident, a training question or an agreed limitation.

Who handles each issue, and who has the authority to resolve it?

That hypothetical Monday is a useful place to start when planning the people needed around a technology change.

Follow one real task through the new process

Choose a routine activity: approving a purchase, onboarding a colleague or handling a customer request.

Walk through how it will work after launch. Include the handovers between teams and the exceptions, not just the successful path shown in a demonstration.

Ask who can explain the new process, who supports someone when it fails and who decides whether the process or the system should change.

If those responsibilities are unclear, an additional announcement may not solve the problem.

Make operational ownership visible

A project team and an operational team have different responsibilities, even when the same people contribute to both.

Before handover, identify the owners of access requests, support guidance, process decisions, technical incidents and ongoing improvements. Agree how unresolved issues move between them.

Ownership should survive the departure of an individual contractor or the closure of a project channel. Keep the information somewhere the relevant teams can find and maintain.

Identify capability before choosing job titles

The gap may involve business analysis, change support, technical engineering, service transition or subject-matter expertise.

Start with the work. Does someone need to map the process? Test an exception? Prepare guidance? Resolve a technical defect? Coordinate a business decision?

One person may cover several activities. That does not make every combination practical, particularly when the work peaks at the same time.

A Change Manager, for example, can help coordinate readiness without automatically becoming the owner of every training document, technical fix and operational decision.

Decide what evidence will be useful

Training attendance can tell you who attended. It cannot, on its own, tell you whether a person can complete a task in the new process.

Choose proportionate checks for the work involved. You might ask a representative group to complete a task, review recurring support questions or check whether an operational owner can resolve an exception using the agreed guidance.

Make the purpose clear. These checks should help identify where support or correction is needed, rather than become a surprise assessment of individuals.

Protect time for the transition

A named owner still needs time to do the work.

Ask what existing responsibilities will change, what support is available and which issues need escalation. Be specific about how long implementation support will continue and what happens when it ends.

Avoid treating an enthusiastic volunteer as the answer to an ongoing workload without discussing capacity.

Put the handover into the hiring brief

If you are recruiting for the programme, explain the stage it has reached and what the person will inherit. Identify the relationships they need to build and the deliverables they are expected to leave behind.

For candidates, those are useful interview questions too. Ask who owns the service after launch, how handover works and what the role can influence.

A launch date is a milestone. The people using and supporting the service need a workable arrangement beyond it.