The quality practice I: expectations, acceptance criteria and the approach

This course is an independent study of four of the seven PRINCE2 practices: quality, risk, issues and progress. PRINCE2® is a registered trademark of PeopleCert. Every explanation, example and question here is original; none of it reproduces the official manual or real exam questions. When you sit a PRINCE2 exam, the official PRINCE2 7 manual is the authority, and in the Practitioner exam it is the only book you may consult.

PRIN-130 studied the three practices that set a project up: business case, organizing and plans. This course studies the four practices that keep it under control once it is running. Quality asks what fit for purpose means and how the project will know it has been achieved. Risk asks what might happen and what the project will do about it. Issues asks what has happened and how change is controlled. Progress asks where the project is now, where it will end up, and who needs to decide what as a result. Together they turn the plans and the business case from documents into a working control system.

How this course is organized

Most lessons follow Ridgeline Water, the invented municipal water utility from PRIN-130, as its smart-metering project moves from the pilot stage into rollout. The pilot stage plan from PRIN-130 gives us a 29-week schedule, a budget of 1,450 thousand with a +5 % cost tolerance, a scope of one district of about 3,000 connections and a quality target of a 98 % daily read rate. Those numbers now become the baselines that quality, risk, issues and progress control. The capstone switches to Harbour City Libraries, the second case from PRIN-130, for its pilot branch stage. All figures are illustrative.

The purpose of the quality practice

In plain terms, the quality practice exists to make sure the project defines, in advance and in measurable terms, what its products must be like, and then checks that they are like that before they are accepted. It has two halves. Quality planning defines the expectations, criteria and methods. Quality control carries out the checks, records the results and gains approval and acceptance. A project that does only the first half has good intentions and no evidence. A project that does only the second half tests products against criteria that nobody agreed.

The quality practice supports the principle of focus on products. Products are defined by product descriptions that include quality criteria, so a project cannot focus on products without saying what a good product looks like. It also supports continued business justification: benefits depend on outcomes, outcomes depend on people using the outputs, and people will not use outputs that do not work. A meter that reports readings 90 % of the time instead of 98 % undermines the billing benefit just as surely as a cost overrun undermines the investment appraisal.

Customer quality expectations

Quality planning starts with the customer's quality expectations: statements about the key quality characteristics of the project's final product. They are usually captured during starting up a project, when the project product description is first drafted, and they are often vague at first. A senior user might say that the new meters must be reliable, that customers must trust their bills and that the system must be easy for billing staff to use. These are genuine expectations, but nobody could test a meter against the word reliable. The work of quality planning is to turn them into something that can be measured.

Expectations should also be prioritized. Not every expectation is equally important, and when time or money runs short the project needs to know which ones may be relaxed. PRINCE2 guidance commonly suggests a prioritization method such as MoSCoW, which sorts requirements into must have, should have, could have and won't have this time. Prioritization at this point is valuable later: it tells the board which quality tolerances can be flexed in an exception and which cannot.

Acceptance criteria

Acceptance criteria are a prioritized list of measurable definitions of the attributes required for the project's final product to be acceptable to key stakeholders. They answer the question the senior user will be asked at the end of the project: does this meet what you need? A good acceptance criterion is specific, measurable, agreed with the people who will accept the product and realistic for the supplier to achieve. Acceptance criteria may cover functionality, performance, reliability, appearance, ease of use, security, sustainability, operating cost and the date by which the product must be available.

Each criterion has a measure, a target, a priority and someone who will confirm it. The priorities matter. If, late in rollout, the supplier proposes to save three weeks by relaxing the installation complaints target, the board can see that it is a could-have criterion and may accept a concession. If the proposal were to relax the daily read rate, the board can see immediately that it is a must-have criterion and that relaxing it would threaten the billing benefit. Acceptance criteria therefore feed directly into the issues and progress practices.

Public-sector projects often inherit acceptance criteria from outside the project. A Canadian municipal utility, for example, must meet provincial measurement and drinking-water rules, and Measurement Canada approves the design of meters used in trade for some utilities such as electricity and natural gas; check which rules apply to the specific product before writing the criterion. Accessibility requirements for the customer portal may come from provincial accessibility law, such as Ontario's AODA, or from the organization's own policy. Writing these inherited requirements into the acceptance criteria makes them visible to the supplier and testable at acceptance, instead of discovering them during an audit.

The project product description

The project product description is a special product description for the project's final product. It is created in starting up a project and refined during initiation. In plain terms, it describes the overall purpose of the final product, its composition (the major products it is made of), the customer's quality expectations, the acceptance criteria, any project-level quality tolerances, the acceptance method, and who is responsible for acceptance. It is used in closing the project to confirm that the project has delivered what was expected.

Ordinary product descriptions do the same job for each individual product that the project will create. PRIN-130 showed how they are written during product-based planning. For the quality practice, the important parts are the quality criteria, the quality tolerance on each criterion, the quality method that will be used to check the product, the skills required to carry out the check, and the people responsible for producing, reviewing and approving the product. If any of those are missing, quality control will have nothing firm to work against.

The quality management approach

During initiation, the project manager prepares a quality management approach, which becomes part of the project initiation documentation. It describes how quality will be managed on this project: which standards, procedures and techniques apply, how quality planning and quality control will be done, which records will be kept, how and when quality assurance outside the project will take place, and who is responsible for what. It also explains how the project's approach fits with any corporate or customer quality management system, such as an ISO 9001 certified system at the supplier.

Who is responsible for what

Quality responsibilities follow the customer–supplier split that PRIN-120 described. The customer, represented by the senior user, defines what is acceptable and confirms acceptance. The supplier, represented by the senior supplier, confirms that the product can be built to that standard and provides the specialist resources for quality checks. The project manager plans and coordinates quality activities. Project assurance checks, on behalf of the board, that quality planning and control are actually happening. Project support usually maintains the quality register.

Two distinctions are worth keeping clear. First, project assurance is not the same as quality assurance. Project assurance is carried out on behalf of the project board and checks every aspect of the project, not only quality. Quality assurance, in the PRINCE2 sense, is an independent check, usually by the business layer or the customer's quality function, that the project's quality management is adequate and follows corporate standards. Second, quality planning is a customer-led activity even when the supplier writes most of the documents: a supplier who defines its own acceptance criteria is marking its own homework.

Checking that criteria are measurable

A common assurance check is to read acceptance and quality criteria and ask whether each one could actually be tested. The code below applies two simple tests to a list of draft criteria: does the criterion contain a number or threshold, and does it avoid words that cannot be measured on their own? It is a teaching device, not a substitute for reading the criteria with the people who will accept the product.

import re
vague = ["reliable", "user-friendly", "easy", "robust", "fast", "high quality", "adequate", "modern"]
drafts = {
    "Daily read rate": "At least 98 % of meters report a valid daily reading over 30 days",
    "Portal": "The customer portal must be user-friendly and modern",
    "Billing accuracy": "Fewer than 1 in 1,000 bills need manual correction",
    "Meters": "Meters must be robust and reliable",
    "Alerts": "At least 80 % of test customers describe the correct action",
    "Clerk time": "Exceptions are resolved fast by trained clerks",
}
for name, text in drafts.items():
    has_number = bool(re.search(r"\d", text))
    found = [w for w in vague if w in text.lower()]
    ok = has_number and not found
    note = "measurable" if ok else "rewrite: " + ("no threshold" if not has_number else "") + (
        (" vague: " + ", ".join(found)) if found else "")
    print(f"{name:17} {note}")

Daily read rate   measurable
Portal            rewrite: no threshold vague: user-friendly, modern
Billing accuracy  measurable
Meters            rewrite: no threshold vague: reliable, robust
Alerts            measurable
Clerk time        rewrite: no threshold vague: fast

Three of the six drafts pass. The portal, meters and clerk time criteria fail: they have no threshold and use words such as user-friendly, robust and fast. Each would need to be rewritten, for example as an accessibility conformance level and a usability test result for the portal, a read rate and annual failure rate for the meters, and an average resolution time for the clerks. Small checks like this are cheap during initiation and very expensive to fix after a supplier has built to the vague version.