The Deck That Wasn't Done: What One Dispute Taught Us About Acceptance Criteria
The handover meeting was supposed to take twenty minutes. Two hours later, the contractor and the client were still circling the same point: was the work "done" or not? The project — call it a community facility upgrade delivered by a small contractor working remotely with a hybrid client team — had gone smoothly until the final sign-off. The names and details here are anonymized, but the pattern will be familiar to anyone who has managed delivery.
The dispute was not about quality. The work was competent. It was about a sentence in the agreement that read, simply, "install accessible viewing platform." The contractor had built a solid, code-compliant platform. The client had pictured railings on three sides, a non-slip surface, and a ramp at a gentler grade than code required. Both believed they were right, because the criterion never said enough to make either of them wrong.
Why vague criteria cause disputes
Acceptance criteria are the conditions a deliverable must meet to be accepted. They are the bridge between what someone wanted and what was actually built. When they are vague, that bridge has gaps, and people fall through them in good faith. Each party fills the silence with their own assumptions, and those assumptions only collide at the worst possible moment — at the end, when changing course is expensive.
Three things made this dispute predictable in hindsight:
The criterion described an outcome ("accessible") without saying how acceptance would be tested or measured.
It used a word — "accessible" — that meant a legal minimum to one party and a lived experience to the other.
Nobody confirmed a shared picture before work started, because the remote setup made the casual hallway conversations that usually catch this disappear.
What good acceptance criteria look like
Strong acceptance criteria are specific, testable, and agreed before work begins. You should be able to hand them to a neutral third party who could check each one and say plainly whether it was met. They describe the condition of "done," not the activity of doing.
Make them testable. Each criterion should be something you can verify by measuring, inspecting, or demonstrating. "Ramp slope no steeper than 1:12" can be checked; "easy to use" cannot.
Define the words that carry weight. If "accessible" or "complete" or "compatible" means something specific, write that meaning down, with the standard or reference it points to.
Cover the unhappy paths. Say what should happen when inputs are wrong, loads are heavy, or conditions are bad — not just the ideal case.
Agree them up front, together. Acceptance criteria written after the work, or by one side alone, settle nothing. Confirm them while there is still time to adjust the work.
Had the original criterion read something like "viewing platform meeting accessibility standard X, with guardrails on all open sides, slip-resistant surface rated to Y, and a ramp at a maximum 1:12 grade," the handover meeting would have lasted its twenty minutes. The contractor would have priced and built the right thing; the client would have known what to expect. The cost of writing that sentence well is a few minutes of thought up front. The cost of writing it badly was a strained relationship and a change order nobody wanted to pay for.
A habit worth building
Before any deliverable is agreed, ask a simple question: how will we know this is done, and would a stranger reach the same verdict reading only our criteria? If the honest answer is no, the criteria are not finished yet. In remote and hybrid work, where the informal check-ins that used to catch ambiguity happen less often, writing it down clearly is not bureaucracy — it is the cheapest insurance you can buy.
Getting acceptance criteria right at the outset is one of the quiet skills that keeps projects out of dispute — XNM's program & project delivery advisory helps teams set up clear, defensible criteria before the first dollar is spent.