Acceptance Criteria That Prevent Disputes: Common Mistakes and How to Avoid Them

Acceptance criteria are the conditions that a deliverable must satisfy before it is accepted as complete. In project management, acceptance criteria serve a dual purpose: they define quality expectations for the contractor or development team, and they provide an objective basis for deciding whether a deliverable has been satisfactorily completed. When acceptance criteria are clear, acceptance decisions are straightforward. When they are ambiguous, acceptance decisions become negotiations -- and negotiations about whether a deliverable has been delivered become disputes.

Mistake 1: Criteria That Cannot Be Tested

The most common acceptance criteria mistake is writing criteria that describe desired characteristics rather than testable conditions. 'The system shall be user-friendly' is not an acceptance criterion -- it is a design aspiration. 'A user with no prior training shall be able to complete the order entry workflow in under five minutes on the first attempt, with no assistance, in a usability test with five representative users' is a testable acceptance criterion. If you cannot describe the test you would run to verify the criterion, the criterion is not testable -- and untestable criteria will be interpreted differently by the delivery team and the client.

Mistake 2: Criteria That Mix Requirements and Quality Standards

Acceptance criteria should specify what the deliverable must do and how well it must do it -- not how it must be built. Specifying implementation approach in acceptance criteria constrains the delivery team unnecessarily and creates disputes when the team delivers a solution that meets the requirement through a different approach. 'The database must use PostgreSQL 14' is an implementation constraint. 'The database must be capable of supporting 10,000 concurrent users with a query response time of under 200 milliseconds at peak load' is an acceptance criterion.

Mistake 3: Criteria Written Only by the Client

Acceptance criteria that are written solely by the client, without input from the delivery team, often contain requirements that are technically ambiguous or that specify a test approach the delivery team cannot execute within the project budget. Acceptance criteria should be developed collaboratively -- the client articulates what they need, the delivery team confirms what is testable and achievable, and both parties agree on the criteria before work starts.

Mistake 4: Criteria Added After Work Starts

Adding acceptance criteria after work has started -- particularly when the addition is motivated by disappointment with a delivered product rather than a genuine evolution of requirements -- is a common source of disputes. Acceptance criteria should be agreed before the work they govern begins. Changes to acceptance criteria after work starts should be treated as scope changes, with associated cost and schedule implications reviewed and agreed.

Mistake 5: No Process for Evaluating Achievement

Even well-written acceptance criteria will generate disputes if there is no agreed process for evaluating whether they have been met. Who runs the acceptance tests? Who is present? What is the process if a criterion is partially met? What is the resolution mechanism if the client and contractor disagree on whether a criterion has been met? These questions should be answered in the contract, not improvised at acceptance time.

XNM provides project management and contract management advisory to public-sector and capital-project clients, including scope definition and acceptance criteria development. Reach out to XNM's program & project delivery advisory team to discuss acceptance criteria and scope management for your project.