Scope software outsourcing around the decisions the partner must make, the evidence the business will accept and the responsibilities that remain after handover. Give delivery, approval and operational support named owners. Use the worksheet below to connect a bounded piece of work to its acceptance checks, deployment authority and the next person’s ability to maintain it.
What should the partner actually deliver?
Start with a user task and an observable outcome. Identify the existing process, the intended change and the information the partner needs to understand both. Keep a clear list of decisions the business must supply, such as which people may approve a record or what should happen with an unusual request.
Describe the deliverable in terms a reviewer can examine. A working feature may need source code, configuration, data mapping, test evidence and operating instructions. Decide which artefacts belong in the handover and where the organisation will retain them. Ask how another authorised maintainer would locate and use them.
GOV.UK beta guidance includes integration with or replacement of existing services. Documentation. Include the current systems and transition boundaries in the brief. A partner cannot sensibly plan the handover from a description of the new interface alone. Identify the records, integrations and colleagues affected by the change and give unresolved dependencies an owner.
How should feedback and acceptance be organised?
The beta guidance starts with an invited limited group for feedback. Documentation. Define a proposed controlled evaluation with the people who will use or operate the delivered work. Agree the task, environment and expected outcome before the demonstration. Keep the invitation and support arrangements appropriate to the actual service rather than borrowing a government rollout process wholesale.
The beta guidance calls for capacity to sustain learning and iteration. Documentation. The beta guidance includes support capacity for users who struggle. Documentation. Allocate time and responsibility for responding to feedback. A review meeting should leave each consequential observation with a decision: correct it, investigate it, accept a specific treatment or change the requirement. Record the reason and the next owner.
Keep acceptance separate from a list of completed development tasks. Ask the reviewer to follow the intended user journey and locate the evidence supporting the outcome. If a prerequisite prevents a check from running, show it as unexecuted and identify what must happen before the decision can be made.
An original outsourcing handover worksheet
Use this practical checklist for a defined delivery increment. Complete it with the actual people, artefacts and approval route. It is an original project aid for making the handover reviewable, not a substitute for the organisation’s commercial agreement.
| Responsibility boundary | Information to agree | Acceptance question |
|---|---|---|
| Business rule | Decision and accountable business owner | Has the partner received an unambiguous requirement? |
| Implementation | Source, configuration and technical owner | Can the delivered behaviour be related to its implementation? |
| Evidence | Test conditions, observations and unresolved issues | What supports acceptance of the intended task? |
| Deployment | Authorised operator and approved release reference | Who may activate the change? |
| Recovery | Previous state, recovery route and decision owner | What happens if the release behaves unexpectedly? |
| Support | Contact route and operational responsibilities | Who responds after the initial handover? |
| Maintenance | Documentation location and future change process | Can another authorised maintainer continue the work? |
Add a dependency column for information or access the partner does not control. Identify who can resolve each item and which acceptance checks depend on it. This makes a delay or partial result understandable without quietly expanding the partner’s authority or hiding missing business decisions.
Retain the reviewed version of the deliverable and its evidence together. A later correction should have a new reference and a clear explanation of what was repeated. Avoid leaving the business with a demonstration recording that cannot be related to the source and configuration actually handed over.
Who can decide that a release is ready?
Microsoft recommends small, incremental and quality-gated release methods. Documentation. Agree the release increment and its acceptance evidence before activation. Name the business approver, the technical reviewer and the authorised operator according to the organisation’s actual process. Keep approval of the work distinct from authority to change production.
Microsoft recommends staging environments that mirror production. Documentation. Ask the partner to document relevant differences between the evaluation and live arrangements. Include the source of test data and any dependencies intentionally substituted during the rehearsal. The reviewer can then judge what the evidence establishes and which production questions still need checking.
Microsoft recommends health checks before phases of progressive exposure. Documentation. Microsoft recommends halting deployment and initiating recovery when issues are detected. Documentation. Define the observations that allow a release to continue and the conditions that should stop it. Keep the recovery decision and responsible person visible in the handover so the operator does not have to invent a response during an incident.
Hypothetical example: a demonstration passes but the support owner is absent
Imagine a partner delivers a working customer-request feature and demonstrates the intended task. The organisation has not yet assigned anyone to investigate requests that fail after deployment. This hypothetical case exposes an operational gap even when the visible feature is ready for review.
Put the failure handover on the worksheet. Identify the information the support owner needs, the relevant logs or record references and the decision they may make. Ask another authorised colleague to work through the instructions in the evaluation environment and note what remains unclear.
Then rehearse a dependency outage using controlled conditions. Determine how the request’s state is recorded, what the user sees and who is notified. Keep the observed result attached to the delivered version and resolve the support responsibility before relying on the feature in ordinary operation.
What should happen during an emergency change?
Microsoft recommends defining who can approve accelerated emergency deployment procedures. Documentation. Agree the emergency route before it is needed. Record the circumstances under which the ordinary process may be accelerated, who can authorise that decision and how the relevant evidence will be retained. Include the partner’s actual support responsibility in that arrangement.
The beta guidance keeps the legacy service running until its replacement is live. Documentation. For a replacement project, document the organisation’s transition and recovery decisions alongside the implementation. Identify which customer tasks and records must remain accessible and who verifies them at the handover boundary.
A good outsourcing brief leaves no ambiguity about the outcome, the approval evidence and the people who own the service afterwards. See web development and website maintenance for related scope discussions. Get started with the proposed delivery increment, current dependencies and acceptance questions you want to resolve.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.