Acceptance Criteria: The Small Detail That Prevents Big Arguments
The argument arrives at the end, and it always sounds the same. The supplier says the work is delivered. The customer says it is not what was asked for. Both have the same requirement document open in front of them, both are reading it honestly, and both are right, because the requirement said what the thing had to do and said nothing at all about how anybody would know it had done it.
Acceptance criteria are the answer to that second question. They are the conditions a deliverable has to satisfy before the person receiving it agrees it is finished, written in advance and agreed by both sides. They are usually a few lines long, they take an hour to get right, and they are the cheapest insurance available against the most expensive kind of project conversation.
The test a criterion has to pass
There is one test, and it is worth applying literally: could two competent people, working separately and without speaking to each other, inspect this deliverable and reach the same verdict? If not, what is written down is an aspiration. Three properties make the difference.
Observable. The criterion describes something that can be seen, measured, counted or demonstrated. "Intuitive to use" fails. "A new user completes the booking without assistance" is observable, and it is also a smaller claim, which is usually a sign that it is a real one.
Decidable by a named party. Somebody specific has to be able to say yes or no, and everybody has to know in advance who that is. Deliverables argued over at handover frequently turn out to have had two candidate judges and no agreement about which of them was acting.
Known before the work starts. A criterion produced at the point of acceptance is not a criterion; it is a new requirement with a deadline attached. The Scope Performance Domain of the PMBOK® Guide Eighth Edition, at Section 2.2, treats defining and validating scope as one continuous concern precisely because the two ends of it have to agree, and criteria written late are how they come apart.
A fastening station and two weeks of argument
An automotive supplier was installing a torque-controlled fastening station on a trim line ahead of pre-production. The commercial agreement carried a single acceptance line: the station would achieve cycle time in line with line requirements.
The station was delivered and it was quick. Measured from the tool's start signal to its completion signal, it ran comfortably inside the target. Measured from the moment an operator picked the panel off the rack to the green light at the end, it did not, by about nine seconds, because presenting the panel took longer than anyone had allowed for and the fixture needed two hands.
Two weeks went on that nine seconds. The supplier had built and tested against machine cycle, which is what the industry usually means by the phrase. The plant had budgeted against station cycle, which is what its line balance depended on. Neither party had done anything wrong and there was no version of the document that settled it.
The rewrite, agreed for the second station, ran to three lines. Sixty-two seconds or less, measured from operator hand-off to green signal. Over two hundred consecutive units. With the panel presented from the standard rack, by a trained operator, witnessed by the named plant quality engineer. It took forty minutes to write and about ten minutes to argue about, all of it before anybody had cut metal. The second station was accepted on the day it was offered.
The nine seconds were real either way. What the criterion changed was when they were discovered, and by whom, and at whose cost.
Who writes them, and when
The project manager usually should not be the author. The people who should are the person who will accept the deliverable and the person who will produce it, sitting together, with the project manager making sure it happens and that what they agree is recorded somewhere both sides can find it. Criteria written by a project manager alone tend to be reasonable, general and unusable at the point of inspection.
The timing is the other half. Criteria belong at the point where the work is committed, not where it is planned and not where it is delivered. On predictive work that means before the item enters the baseline, and the criteria travel with it through change control, so a change to the deliverable changes its criteria in the same motion. On adaptive work it means during refinement, before the item enters a cycle, which is the moment a team can still say the item is not ready. The mechanics differ and the principle holds in both: whoever is going to judge the work agrees the test before the work begins.
For a PMP® candidate, the useful reading is that a dispute at handover is normally a defect in the definition, so the question worth asking of any such situation is what was agreed and when. A response that negotiates the outcome of one argument leaves the mechanism producing the next one untouched. A structured PMP exam preparation course practises acceptance and validation as a single chain, from definition to sign-off.
This is worth testing against real work. Take the next significant deliverable due and write down who will say yes to it and what they will look at when they do. If either half of that is unclear to you today, it will be contested on the day, and an hour spent now with the two people concerned will be the best-returning hour in the week.
Interested in going further?
Acceptance disputes are rarely about the deliverable in front of the room. They are about a sentence agreed months earlier that turned out to carry two readings. Omega's PMP® Exam Preparation works through definition and acceptance as one continuous piece of work.
Defining scope and validating what has been produced sit together in the PMBOK® Guide Eighth Edition, which is the reference behind this article.
Ad · Amazon affiliate link.
References
A189: Definition of Done vs Acceptance Criteria
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
A107: Scope Creep vs Legitimate Change
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
