Quality criteria nobody can test

What went wrong: quality was planned as wording rather than as measurement.

• The acceptance criteria ("fast", "reliable", "satisfied") are not measurable quality criteria. There is no agreed scan-time threshold, no acceptable read-failure rate, no definition of satisfaction or how it will be assessed. Any product can pass a criterion that cannot be tested.
• The product descriptions specify a quality method (review) with no reviewer, no technique and no quality criteria, so the control step had no defined standard to control against.
• The quality register is incomplete (four entries for six products) and "passed" entries without dates cannot be audited or traced to a person.
• No one checked that the product was fit for its purpose in the wards, which is a user-defined test, not a technical one.

Who is accountable: the project board is accountable for quality within the project. The senior user is accountable for specifying the user's quality criteria and acceptance criteria and for confirming the products meet them - the senior user signed those product descriptions, so the gap is theirs as much as the project manager's. The project manager owns the quality planning and the quality register and should have rejected criteria that could not be tested.

Not rework immediately. The scope of "not what the wards need" is undefined, and unauthorised rework against an unquantified standard repeats the original error.

Recommended sequence:

1. Raise it as an issue (a problem/concern, potentially a change request) with the senior user's specific, measurable statement of what is required - 4.5 seconds and 12% failures mean nothing until a threshold is agreed.
2. Impact analysis against scope, time, cost, quality and risk, and check whether the revised criteria fall within quality tolerances.
3. Establish the standard properly: rewrite the affected product descriptions with measurable quality criteria, named reviewers, defined methods and responsibilities, and correct the quality register (dates, results, person who carried out each check).
4. Re-inspect rather than assume. Use the product status account to determine what has been accepted, on what evidence, and therefore what may need re-testing.
5. Take it to the board if the impact exceeds stage tolerances, since the senior user's late rejection is a baseline change, not a defect fix.
6. Capture the lesson: unmeasurable acceptance criteria approved by a senior user is a predictable, preventable failure.

The tester performed quality control: measuring the product against its quality criteria and recording the result. That work was done, but against no testable criteria, so the control produced a meaningless pass.

Quality assurance is different in kind. It asks whether the quality methods, standards and responsibilities are adequate and being followed - it is a check on the system, not on the product. Here assurance would have asked: is "review" with no named reviewer a valid method? Are the quality criteria measurable? Does the quality register reflect reality?

Why the project manager cannot simply do this: project assurance must be independent of the project manager. A PM who designed the quality approach cannot credibly assure it, and self-review gives the board no independent information. In PRINCE2 terms this is a board-level responsibility, discharged through project assurance roles that monitor the project independently of the PM and report to the board.

Practical implication: the tester's defence is correct as far as it goes, but it also shows why the board needed an independent view of quality planning before the first inspection, not after the senior user rejected the product.