Agree acceptance evidence before arranging the demonstration

The demonstration works. A requester books a meeting room, a confirmation appears, and the project team moves to the next screen. At the end, the sponsor asks whether the service can be accepted.

That decision is difficult when nobody agreed what the demonstration had to establish. A working screen may leave facilities visibility, conflicting bookings and the assisted route unexamined. Project acceptance planning should make those questions explicit before the demonstration is arranged.

Define the service being accepted

For a fictional campus booking service, start with the people who must use and operate it. A requester needs a reliable reservation. Facilities needs to identify the current booking for the room. A colleague who cannot complete the online task needs an agreed route to assistance.

Name the release, locations, user groups and operating hours in scope. If the team is demonstrating a test environment with prepared data, record that limitation. The sponsor should not have to infer whether the evidence covers the production service or only one interface.

UK government project guidance distinguishes verification against design from validation against need and places formal acceptance within planned transition. That distinction is useful here; it does not determine this fictional organisation's contract. GovS 002, sections 8.6 and 8.8.

Agree an acceptance matrix with the receiving team

The following is an original planning example, not a prescribed standard or a completed test record.

The named roles are examples. The organisation must identify who actually has acceptance authority and who only supplies evidence.

Agree the acceptable outcome before running each scenario. For the conflicting request, “no crash” is too weak: the team needs to establish that it did not confirm incompatible reservations. For assistance, a contact link alone cannot demonstrate that the receiving team can complete the task.

Keep observation, correction and acceptance separate

During the demonstration, record what happened, including inconvenient results. A defect should have a clear connection to the need it affects. A polished repeat of the happy path does not resolve a failed conflict check.

After a fix, retain the original finding and the new evidence. State which release was retested. If the team accepts a limitation, name its impact, permitted scope, owner and review condition. Calling it “minor” without that information does not help the receiving operation.

An acceptance decision can then reference the evidence and exclusions. It should not be backdated to the day somebody first watched the demonstration.

Check the handover that follows the decision

Acceptance is only useful if the receiving team understands what it has taken on. Give facilities and support the current service instructions, known limitations, escalation route and the evidence relevant to their responsibilities. The supplier service handover guide examines that operational boundary in more detail.

Keep unresolved items visible after the meeting. A defect may be permitted within a restricted launch but unacceptable for wider rollout. Expansion needs evidence for the expanded scope, rather than a copy of the earlier approval.

Before scheduling the demonstration, ask the acceptance owner to read the matrix. They should be able to explain what a pass would permit and which result would leave the decision open. That short conversation can prevent a successful presentation from being mistaken for a supported service decision.