Who operates it when the project is over?

The missing conversation

A project can agree on a delivery date without agreeing on the work that starts the following morning. Updates, access requests, failed jobs, configuration changes and data corrections do not disappear when the project closes. The useful question is not simply who owns the system, but who does which kind of work, with what authority and with what time.

Separate the layers

Start with a concrete service and walk through its layers: infrastructure, operating system, application, configuration, data and everyday casework. For each layer, distinguish decisions from execution. A team may run a database without having the authority to decide which records should be stored in it.

Follow the whole lifecycle

Then examine preparation, provisioning, installation, change, backup and recovery, and eventual retirement. Ask who can authorise a change, who carries it out, who checks the result and who is available when it fails. A box containing the name of a department is not enough if nobody has accepted the work.

Make a small, testable agreement

Choose one operation that is likely to occur: restore a record, onboard a new colleague or upgrade a component. Write down the people, permissions and dependencies involved. Walk through it together. Where the walkthrough stops, the handover is not yet complete.

A question to take away

Could the people expected to operate the service describe their responsibilities in the same way as the project team? Start with the differences rather than adding another technical requirement.