The team says a deliverable is finished. The person receiving it says it is not what they expected. Project acceptance criteria describe the conditions used to decide whether a deliverable is acceptable. Agree them before completion so the review does not become a fresh negotiation about what was intended.
Photo by ThisisEngineering on Unsplash.
A useful criterion connects a requirement with observable evidence and an authorised decision. “High quality” gives the reviewer too little to work with.
Use a condition, check and owner
For each important deliverable, write:
What must be true for the intended use.
How that condition will be checked.
What evidence will be retained.
Who reviews the evidence and accepts the result.
How failed checks and exceptions will be handled.
Choose checks suited to the work. A sample document review, an observed workflow and a technical test answer different questions. Involve people who understand the operational use rather than asking the project team to invent every condition alone.
Replace vague adjectives with examples
“Easy to use” could become “A nominated coordinator completes the agreed example workflow using the supplied instructions, with any required assistance recorded.” This is an editorial example, not a universal testing standard. Agree what level of assistance is acceptable for your situation.
Avoid claiming that one successful example proves every future case will work. Record the tested scope, important exceptions and any further assurance required.
An illustrative acceptance review
A small business is receiving a new reporting pack. Its criteria cover the agreed reporting period, named data sources, reconciliation checks and the format needed for its management meeting. The recipient checks a sample pack and finds that one data source is missing.
The team records the failed condition and owner. It does not rename the omission a “minor improvement” simply to close the project. The authorised recipient can require correction or formally accept a stated limitation, depending on the consequences and their authority.
Protect the agreed basis
If a new requirement appears during acceptance, compare it with the agreed criteria and decide whether it is a defect, clarification or change request. Keep the discussion specific and record the decision. An accepted limitation should have an owner if further work remains.
Related guidance: small-team project planning guide.
