Write acceptance criteria before delivery starts

Why does everyone define 'done' differently?

A vendor may say a system is configured while the customer cannot complete an actual business task. Both may be using different definitions of delivery. Disputes begin when nobody agreed observable acceptance tests at the start.

Technical completion is not the same as operational readiness, especially when testing, handover and ownership are missing.

The root cause is output-based scope without tests

A scope might say 'configure email and permissions' but never state how many accounts, which access scenarios, or who verifies recovery. Each party then invents its own acceptance threshold later.

Good criteria link every deliverable to a demonstrable outcome and a named decision owner.

Specify acceptance that can be tested

For every output define what must work, under which conditions, with which sample data, who witnesses the result, and how failure is handled. Separate critical requirements from improvements that can be deferred.

Photo source: Pexels.

• A precise statement of the expected result.
• Evidence from a repeatable test.
• An acceptance owner and a defect resolution deadline.

Related perspective: Illustrative Case: A Business Expanded Before Fixing Approvals

Start with five critical scenarios

Translate scope into end-to-end user scenarios. For example: a new user gets role-based access; a departing employee loses access; a contact form reaches its correct mailbox; a file can be recovered; and a report reconciles to source data.

Record results before sign-off, including permitted exceptions and their owners.

Hypothetical example: email accounts without reliable delivery

Imagine a company receives new mailboxes but has not tested inbound external mail or multi-factor authentication. Missing messages and unprotected accounts emerge after launch.

Practical acceptance would verify send and receive, access controls, authentication, support instructions and a handover record. This is a hypothetical illustration.

Measure what acceptance actually protects

Monitor passed tests, open critical defects, existence of operating instructions, and a named post-launch owner. Do not close a critical failure without an accepted resolution plan.

• No unresolved critical defect without a decision.
• Clear acceptance evidence and sign-off.
• A defined monitoring period for residual issues.

A testable acceptance template

Turn each scope promise into a scenario: who performs the action, what outcome must appear, who witnesses it, and what happens on failure?

Sending login details is not evidence of successful delivery. Retain the test result, sign-off decision, and any explicitly accepted exceptions.

Handover should create operational capability

Delivery should leave a team able to use and maintain what it owns, not merely possess accounts or documents. Acceptance therefore belongs in foundation design before tools are implemented.

Digital Business Foundation connects operating outcomes to digital setup, documentation and controlled handover.

• Item — Business-email example
• Requirement — Receive mail from an external sender
• Test — Send from another domain
• Evidence — Correct mailbox receives the message without error
• Sign-off — Authorized client representative