In the context of the PRINCE2 7 Practitioner Quality practice, Acceptance Criteria define the prioritized list of measurable definitions of the attributes required for the set of products to be acceptable to the key stakeholders. They essentially act as the ultimate definition of what 'done' looks …In the context of the PRINCE2 7 Practitioner Quality practice, Acceptance Criteria define the prioritized list of measurable definitions of the attributes required for the set of products to be acceptable to the key stakeholders. They essentially act as the ultimate definition of what 'done' looks like for the final project product.
These criteria are initially derived from the project mandate during the 'Starting Up a Project' process and outlined in the Project Brief. During the 'Initiating a Project' process, they are refined, agreed upon, and baselined within the Project Product Description (part of the Project Initiation Documentation). This establishes a shared understanding between the customer (who specifies the need) and the supplier (who delivers the solution), serving as a vital control mechanism to prevent scope creep and quality disputes.
Crucially, Acceptance Criteria must be specific and testable. Vague objectives such as 'easy to use' are replaced with quantifiable metrics, such as 'new staff can process an order within 5 minutes of training.' In PRINCE2, these criteria are often prioritized using the MoSCoW technique (Must have, Should have, Could have, Won't have for now). This prioritization is essential for managing tolerances; if the project faces constraints, the Project Board can distinguish between critical requirements that must be met and desirable features that can be omitted.
While 'Quality Criteria' define the technical specifications for individual component products, Acceptance Criteria apply to the project product as a whole. They are the primary tool used during the 'Closing a Project' process. The project product is verified against these criteria, and only upon confirmation that the criteria are met will the operational and maintenance authority accept the handover, thereby concluding the project.
Acceptance Criteria in PRINCE2 Practitioner v7
What are Acceptance Criteria? Acceptance Criteria consist of a prioritized list of criteria that the project product must meet before the customer will accept it. They are essentially the definition of what a successful project looks like from the perspective of the key stakeholders (specifically the Senior User). While 'Quality Expectations' are often broad aspirations, Acceptance Criteria are the measurable definitions used to verify the final output.
Why are they Important? They are vital for determining the feasibility of the project. Without clear Acceptance Criteria, the supplier cannot estimate the time and cost accurately, and the customer cannot guarantee the project will deliver value. They serve as the primary agreement to prevent scope creep and disputes at the end of the project regarding whether the product is 'finished'.
How it Works 1. Derivation: During the Starting Up a Project process, the Project Mandate is analyzed to understand the Customer's Quality Expectations. These are refined into specific Acceptance Criteria. 2. Documentation: They are recorded in the Project Product Description (a component of the Project Brief). 3. Prioritization: Acceptance criteria must be prioritized because it may not be possible to meet every desire within the constraints. The MoSCoW technique (Must have, Should have, Could have, Won't have for now) is typically used. 4. Approval: The Project Board approves them as part of the Project Brief and later the Project Initiation Documentation (PID). 5. Verification: During the Closing a Project process, the final product is assessed against these criteria to secure acceptance.
Exam Tips: Answering Questions on Acceptance Criteria When facing Practitioner scenarios, keep these differentiators in mind: 1. Acceptance vs. Quality Criteria: This is the most common trap. Acceptance Criteria apply to the final Project Product and focus on the user's needs/utility. Quality Criteria apply to individual components (products) and focus on technical specifications required to meet the acceptance criteria. If the question refers to the 'Project Product Description', think Acceptance Criteria. If it refers to a standard 'Product Description', think Quality Criteria. 2. Measurability is Key: A common question style asks you to identify 'good' or 'bad' acceptance criteria. Valid criteria must be measurable. 'Fast system' is bad; 'System loads in under 2 seconds' is good. 3. Change Control: Remember that once the PID is approved, Acceptance Criteria are baselined. If a stakeholder wants to change them during the delivery stages, this constitutes a Request for Change, not just a simple update by the Project Manager.