7.2 The User's Quality Expectations & Acceptance Criteria

User's Quality Expectations & Acceptance Criteria

Practitioner Core Mandate: The success or failure of a project is ultimately judged by whether the delivered product is formally accepted by the customer and operationalized by business users. Vague, unmeasurable requirements represent the single greatest cause of project disputes, cost overruns, and delayed handovers. PRINCE2 7 resolves this vulnerability through a disciplined, two-stage refinement process: capturing high-level User's Quality Expectations during pre-project startup, and translating them into rigorous, prioritized, measurable Acceptance Criteria during project initiation.

---

1. User's Quality Expectations: The Initial Voice of the Customer

The user's quality expectations are the initial, overarching statement of what the user community expects the project deliverables to achieve in terms of quality, usability, performance, reliability, and maintenance. PRINCE2 7 renamed these from the 6th Edition's customer's quality expectations, and section 8.2.1.1 of the manual is titled 'User's quality expectations'. They are documented in the project product description, which is an element of the project brief and is created in starting up a project.

               EVOLUTION FROM EXPECTATION TO FORMAL ACCEPTANCE

   PRE-PROJECT: Starting Up a Project (SU)
   ┌────────────────────────────────────────────────────────┐
   │ USER'S QUALITY EXPECTATIONS                            │
   │ • Broad, high-level, aspirational                      │
   │ • Captured in outline Project Product Description      │
   │ • Contained inside the PROJECT BRIEF                   │
   └───────────────────────────┬────────────────────────────┘
                               │
                               ▼ Transformed & Quantified during
   INITIATION STAGE: Initiating a Project (IP)
   ┌────────────────────────────────────────────────────────┐
   │ MEASURABLE ACCEPTANCE CRITERIA                         │
   │ • Specific, quantified, realistic, and testable        │
   │ • Prioritized using MoSCoW (Must, Should, Could, Won't)│
   │ • Baselined in formal PROJECT PRODUCT DESCRIPTION      │
   │ • Contained inside the PID                             │
   └────────────────────────────────────────────────────────┘

Nature & Process Context

• When Captured: During the Starting Up a Project (SU) process.
• Where Documented: Captured in the outline Project Product Description, which forms an integral section of the Project Brief.
• Who Articulates Them: Articulated primarily by the senior user (representing user and end-user interests) in consultation with the project executive (safeguarding business viability).
• Characteristics: Broad, high-level, and frequently qualitative. Customers rarely specify technical decibel levels or millisecond latencies upfront; they express desires such as "a modern, intuitive customer portal", "highly reliable cloud hosting", or "an environmentally sustainable office headquarters".

Core Dimensions of User Quality Expectations

When eliciting quality expectations, the Project Manager must prompt stakeholders across several operational dimensions:

1. Functional Performance: Core operational throughput, processing speed, capacity, and feature integration.
2. Usability & Accessibility: User interface ergonomics, learning curves, and compliance with accessibility standards (e.g., WCAG 2.1 AA).
3. Reliability & Availability: Mean time between failures (MTBF), fault tolerance, disaster recovery failover speed, and annual uptime percentages.
4. Maintainability & Supportability: Modularity, frequency of patching, availability of vendor support, and spare parts logistics.
5. Environmental Sustainability: Operational energy consumption, carbon lifecycle emissions, sustainable sourcing, and end-of-life recyclability.
6. Total Cost of Ownership (TCO): Ongoing operational expenditure, licensing structures, and facility maintenance overhead.

---

2. Translating Expectations into Measurable Acceptance Criteria

Broad customer expectations provide valuable direction, but they cannot serve as contractual handover baselines. An expectation like "the software must be fast and easy to use" is completely untestable; a developer might consider a 5-second response time fast, while an operational trader considers anything over 200 milliseconds catastrophic.

During the Initiating a Project (IP) process, the Project Manager must lead the refinement of these expectations into formal, measurable Acceptance Criteria, documented in the final Project Product Description (PPD) within the Project Initiation Documentation (PID).

The Anatomy of an Effective Acceptance Criterion

To eliminate subjectivity and prevent handover deadlocks, every acceptance criterion must satisfy four non-negotiable rules:

• Specific: Defines precisely what attribute or performance parameter is being evaluated.
• Measurable: Expressed in quantitative, objective metrics (time, percentages, physical dimensions, financial limits, or pass/fail criteria).
• Realistic & Achievable: Technically and commercially feasible within the project's time, cost, and supplier constraints.
• Testable & Verifiable: Accompanied by a defined verification method (e.g., automated test run, load test, third-party laboratory inspection, user acceptance testing).

Translation Table: From Expectation to Acceptance Criterion

---

3. Prioritizing Acceptance Criteria: The MoSCoW Framework

Not all acceptance criteria carry equal operational or business weight. If a project encounters unforeseen supply chain delays, budget constraints, or technical hurdles, the Project Board requires a predefined mechanism to negotiate trade-offs. PRINCE2 mandates that acceptance criteria be prioritized during project initiation.

PRINCE2 7 section 7.3.3.1 lists several ways to reach agreement on priorities, and the first is categorizing criteria as must-have, should-have, could-have, or won't have — the categorization widely known as MoSCoW. The manual also names three alternatives you should recognize in a scenario: a product backlog approach that sets the sequence in which features become available to users; pairwise comparison to draw out preferences between criteria; and the Kano model, which classifies features as delighters, performance features, or essential in order to gauge customer satisfaction. Note that the manual describes the categories without using the acronym 'MoSCoW' itself.

                      MoSCoW PRIORITIZATION HIERARCHY

   ┌──────────────┬─────────────────────────────────────────────────────────┐
   │  MUST HAVE   │ Non-negotiable core. Without these, the product cannot  │
   │  (Vital)     │ be accepted, legal compliance fails, and business case  │
   │              │ collapses. Project CANNOT close if a MUST is missing.   │
   ├──────────────┼─────────────────────────────────────────────────────────┤
   │ SHOULD HAVE  │ High-priority operational requirements. Essential value,│
   │ (Important)  │ but temporary workarounds exist if tolerances threatened.│
   ├──────────────┼─────────────────────────────────────────────────────────┤
   │  COULD HAVE  │ Desirable enhancements. Low impact on business case.    │
   │  (Desirable) │ First to be descoped if cost or time tolerances breach. │
   ├──────────────┼─────────────────────────────────────────────────────────┤
   │  WON'T HAVE  │ Explicitly excluded from current delivery scope. May be │
   │  (Deferred)  │ scheduled for subsequent projects or future phases.     │
   └──────────────┴─────────────────────────────────────────────────────────┘

Governance Rules for MoSCoW Criteria

1. The 'Must Have' Rule: If even a single 'Must have' acceptance criterion is unsatisfied at project closure, the customer cannot accept the product, and formal handover cannot take place. Delivering all 'Should haves' and 'Could haves' does not compensate for an unfulfilled 'Must have'.
2. The Descoping Sequence: When the Project Manager forecasts a breach of stage time or cost tolerances during stage execution, potential trade-offs follow a disciplined order: examine 'Could haves' first for descoping or deferral, followed by 'Should haves' (subject to Project Board approval via change control).
3. Preventing Scope Creep: The 'Won't have for now' category is vital for managing stakeholder expectations. It establishes explicit boundaries around what the project will not deliver, preventing insidious scope creep.

---

4. Tolerances: Project-Level vs. Product-Level Quality Tolerances

Just as projects operate with tolerances for time and cost, PRINCE2 establishes quality tolerances to provide controlled flexibility without requiring constant governance escalation.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     QUALITY TOLERANCE HIERARCHY                             │
├─────────────────────────────────────────────────────────────────────────────┤
│ PROJECT-LEVEL QUALITY TOLERANCES                                            │
│ • Defined in the PROJECT PRODUCT DESCRIPTION                                │
│ • Allowable variance on overall final project acceptance criteria           │
│ • Governed by the business layer and Project Board              │
│ • Escalation: Exception Report raised if project-level tolerance breached   │
│                                                                             │
│ PRODUCT-LEVEL QUALITY TOLERANCES                                            │
│ • Defined in individual specialist PRODUCT DESCRIPTIONS                     │
│ • Allowable variance on individual component deliverables                   │
│ • Governed by Project Manager and Team Manager within Work Packages         │
│ • Escalation: Managed by PM; escalated only if stage tolerance is threatened│
└─────────────────────────────────────────────────────────────────────────────┘

Project-Level Quality Tolerances

• Definition: The permissible range of variance applied directly to the overarching acceptance criteria documented in the Project Product Description.
• Example: In a data center relocation project, an acceptance criterion states that network latency between primary and backup sites must be 10.0 milliseconds, with an agreed project quality tolerance of ±1.5 milliseconds. If latency tests show 11.2 milliseconds, the deliverable is acceptable. If latency reaches 12.0 milliseconds, an overall project tolerance breach has occurred.
• Governance Action: A forecast breach of project-level quality tolerance threatens the Project Plan and Business Case. The Project Board cannot absorb this variance unilaterally if corporate-level parameters are exceeded; an Exception Report must be submitted to the business layer.

Product-Level Quality Tolerances

• Definition: The permissible range of variance defined within an individual specialist Product Description for a specific component deliverable.
• Example: In an aerospace manufacturing Work Package, the Product Description for a titanium bracket specifies a thickness of 12.0 mm with a product quality tolerance of ±0.2 mm. Brackets measuring between 11.8 mm and 12.2 mm are accepted by the Team Manager and Project Manager.
• Governance Action: If a component fails its product quality tolerance (e.g., measuring 12.5 mm), it is logged as an Issue (Off-specification) in the Issue Register. If the defect can be corrected within the existing Work Package and stage tolerances, the Project Manager manages the rework autonomously. If correcting the defect will cause the stage time or cost tolerances to be exceeded, the Project Manager must raise an Exception Report to the Project Board.

Comparative Matrix: Project-Level vs. Product-Level Quality Tolerances

---

5. Stakeholder Roles and Accountabilities in Quality Definition

PRINCE2 establishes unambiguous division of accountability across the project management team regarding who defines, validates, approves, and documents quality parameters.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     QUALITY GOVERNANCE ACCOUNTABILITIES                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ SENIOR USER                                                                 │
│ • Articulates user's quality expectations                                   │
│ • Formulates and prioritizes acceptance criteria                            │
│ • Confirms products enable business benefits realization                    │
│                                                                             │
│ EXECUTIVE                                                                   │
│ • Holds ultimate accountability for project success & Business Case         │
│ • Formally approves Project Product Description & acceptance criteria       │
│ • Ensures quality standards align with corporate investment boundaries      │
│                                                                             │
│ SENIOR SUPPLIER                                                             │
│ • Evaluates technical and commercial feasibility of expectations            │
│ • Confirms acceptance criteria are realistic and achievable                 │
│ • Commits supplier technical resources and production quality standards     │
│                                                                             │
│ PROJECT MANAGER                                                             │
│ • Facilitates workshops and translates expectations into measurable criteria│
│ • Authors Project Product Description and individual Product Descriptions   │
│ • Maintains Quality Register and monitors tolerance consumption             │
└─────────────────────────────────────────────────────────────────────────────┘

Role Breakdown & Common Pitfalls

• The Senior User's Primacy: A frequent examination trap suggests that the Senior Supplier defines acceptance criteria because they possess technical expertise. This is false. The Senior User is strictly accountable for specifying acceptance criteria. The supplier advises on feasibility, but the user specifies what is required to operate the business.
• The Project Executive's Fiduciary Oversight: While the Senior User specifies criteria, the Project Executive must approve them. If the Senior User demands gold-plated quality standards that double project costs and render the Business Case unviable, the Project Executive holds the authority to reject those standards and mandate realistic baselines.
• Project Assurance Roles:
  • User Assurance: Verifies that user expectations are comprehensively captured and that acceptance criteria are realistic, complete, and testable.
  • Supplier Assurance: Verifies that proposed quality specifications are achievable within supplier capabilities and that appropriate quality control techniques are scheduled.

---

6. Updating Acceptance Criteria Across the Project Lifecycle

Once the Project Initiation Documentation (PID) is approved by the Project Board in the Directing a Project (DP: Authorizing a Project) process, the Project Product Description and its acceptance criteria are formally baselined.

Can Acceptance Criteria Change?

Yes. Projects operate in dynamic environments. Changes in legislation, corporate strategy, technological breakthroughs, or competitor actions may necessitate modifying acceptance criteria during project delivery. However, acceptance criteria cannot be altered informally or unilaterally.

The Change Protocol for Acceptance Criteria

1. Issue Identification: Any stakeholder proposing a modification to acceptance criteria must submit a formal Issue (Request for Change - RFC), recorded by the Project Manager in the Issue Register.
2. Impact Assessment: The Project Manager assesses the full operational and commercial impact of the change:
   • Does altering the criterion affect the Business Case and forecast benefits?
   • Will it require revisions to Stage Plans, delivery dates, or financial budgets?
   • Does it impact other dependent specialist products or technical architectures?
3. Project Board Determination: Because acceptance criteria reside in the baselined Project Product Description, only the Project Board holds the delegated authority to approve changes to them (involving both the Project Executive and Senior User). If the change breaches project-level tolerances agreed with the business layer, the Project Board must escalate the decision to the business layer.
4. Re-baselining & Configuration Control: Upon formal Project Board approval, the Project Product Description is re-baselined under formal configuration management, and associated Product Descriptions and Stage Plans are updated.

---

7. Practical Scenario Evaluations

Scenario A: The Disputed Handover on Aspirational Criteria

On the CloudLogistics Freight Management project, the outline Project Product Description stated that the warehouse tracking software must have 'an intuitive and highly responsive user interface'. During final operational handover, the Senior User refuses to sign off on acceptance, arguing that data entry screens require too many mouse clicks and feel sluggish. The Senior Supplier counters that the software is fully functional and demands final contract payment.

Practitioner Evaluation:

• Governance Flaw: The project management team failed to translate an aspirational user quality expectation into quantitative, measurable acceptance criteria during project initiation.
• Impact: Without specific metrics (e.g., 'maximum 3 clicks per booking, screen load time ≤ 800ms'), acceptance becomes a subjective debate between user perception and supplier defense, paralyzing project closure and inviting contractual litigation.
• Correct PRINCE2 Action: During the Initiating a Project process, the Project Manager should have facilitated workshops between the Senior User and Senior Supplier to define measurable metrics, allowable tolerances, and explicit verification methods for interface responsiveness, securing Project Board sign-off in the baselined PPD.

Scenario B: Senior Supplier Unilaterally Relaxing Quality Tolerances

During Stage 3 of the HighSpeed Rail Signalling project, specialized trackside transponders fail temperature stress tests at -35°C, against a baselined Product Description requirement of -40°C ± 2°C. Facing factory delivery penalties, the Senior Supplier instructs the manufacturing team to re-label the transponders as compliant at -35°C, arguing that local winter temperatures rarely drop below -30°C and that the variance is inconsequential.

Practitioner Evaluation:

• Governance Flaw: The Senior Supplier has committed an unauthorized modification of a baselined quality tolerance, violating the Defined Roles and Responsibilities and Manage by Exception principles.
• Impact: Unilateral relaxation of safety-critical quality tolerances bypasses governance, invalidates the safety case, and exposes the rail network to catastrophic winter failure.
• Correct PRINCE2 Action: The failure to meet quality tolerance represents an Off-specification. The Senior Supplier must immediately report the non-conformance to the Project Manager. The Project Manager logs the issue in the Issue Register and conducts an impact assessment. Because safety-critical tolerances and the Project Product Description are threatened, the Project Manager must raise an Exception Report to the Project Board for directional guidance or formal concession approval.

Scenario C: Descoping 'Must Have' Criteria Without Exception Governance

On an enterprise ERP upgrade, the project encounters an 18% cost overrun during the final delivery stage. To prevent breaching stage cost tolerance, the Project Manager and Senior Supplier agree to remove data encryption at rest—a criterion baselined as a 'Must have' in the Project Product Description. The Project Manager notes in the Daily Log that encryption will be deferred to an operational maintenance patch six months after launch.

Practitioner Evaluation:

• Governance Flaw: The Project Manager has descoped a mandatory 'Must have' acceptance criterion without Project Board authorization, violating the Focus on Products and Manage by Stages principles.
• Impact: A 'Must have' criterion represents an absolute condition of operational viability and legal compliance. Omitting encryption at rest breaches data protection laws (e.g., GDPR) and destroys the Business Case justification. The Project Manager possesses no authority to descope 'Must have' criteria to protect personal stage tolerances.
• Correct PRINCE2 Action: As soon as cost pressures threatened stage tolerances, the Project Manager was obligated to submit an Exception Report to the Project Board. Only the Project Board, in consultation with corporate compliance and security stakeholders, has the authority to decide whether to approve an Exception Plan, inject additional contingency funds, or pause the project.