Signed Off, But Not Fit
A payroll migration for 22,000 employees is twelve months in and entering its go-live stage. The product description for the 'payroll calculation module' states the purpose as 'accurate, user-friendly payroll calculation', the quality method as 'supplier unit test', and the quality criteria as 'system testing complete'. The supplier's own test team signed the module off last month. During user acceptance testing, 3% of employees turn out to receive incorrect overtime deductions and the exception-handling screens are reported as unusable. The supplier's position is that the acceptance criteria were met and any further work is a change.
1. Evaluate the quality planning for this product. Identify each defect and state what PRINCE2 requires instead.
Read the worked answer
Defect 1 - quality criteria are not measurable. 'System testing complete' describes an activity, not a characteristic a product can be judged against. Quality criteria must be defined so that a reviewer can objectively decide pass or fail (e.g. 'zero variance in overtime deductions across five parallel runs covering 500 sampled employees').
Defect 2 - criteria were not derived from the customer. The senior user defines customer's quality expectations and acceptance criteria. 'User-friendly' is the customer's expectation; it needed translating into testable acceptance criteria and a defined quality method (e.g. task-based usability review with nominated users), not left as an adjective.
Defect 3 - no independent quality control. The supplier testing its own work gives no assurance against the customer's needs. Quality control should include the users' acceptance activity; the quality register should show planned and actual results for each check.
Defect 4 - the quality method is inadequate for the purpose. Unit testing cannot demonstrate fitness for purpose of a calculation module feeding 22,000 payslips.
Quality assurance point: project assurance should have challenged the quality management approach at initiation; the defects are systemic, not a one-off oversight.
2. The project is three weeks from go-live. How would you classify and handle the two problems through PRINCE2's issue and progress routes?
Read the worked answer
Classify first - the two problems are different.
- Incorrect overtime deductions is a failure to deliver the product to its required standard: an off-specification (the product is not fit for purpose as described). It is not a change; the work is already within scope.
- Unusable exception screens may be an off-specification if agreed criteria exist, or a change request if the usability requirement was never turned into a criterion. Given the weak product description, treat it as a change request and accept that the product description was inadequate - record that in the lessons log.
Assess impact before acting. Both need an impact analysis on time, cost, quality, scope, benefits and risk, plus which products are affected.
Progress route. If the analysis shows the go-live stage will breach its cost, time or quality tolerance, the project manager issues an exception report now, not at the stage boundary, with options: delay go-live by a defined period, parallel-run with manual correction, or go live with payroll exceptions handled offline. The board may request an exception plan covering the remainder of the stage; the project manager may not simply absorb the work and report a green stage.
3. What two changes to the project's quality approach would reduce the chance of this repeating for the remaining products, and how would you get them agreed quickly?
Read the worked answer
Change 1 - re-plan the products, not just the defect. Every remaining product description gets: purpose stated in terms of the user need, quality criteria written as measurable tests with the value and units specified, a quality method named for each criterion, and the quality responsibilities identified (producer, reviewer, approver). Enter them in the quality register with planned dates so they can be tracked at checkpoints.
Change 2 - put the user inside quality control. Agree with the senior user a named group of acceptance representatives and a defined acceptance method (scripted parallel runs and task-based usability review) that happens before the supplier declares completion. Keep supplier testing, but stop treating it as verification of fitness for purpose.
Getting it agreed quickly:
- Treat the reworked quality approach as a change with a stated impact, not a discussion paper.
- Take it to the change authority within its delegated limits, or to the board via an exception report if it affects stage tolerance.
- Frame the case in business terms: the cost of re-testing versus the cost of an incorrect payroll run for 22,000 staff, and the benefit to the supplier of not carrying rework into support.
- Record the decision and the reasoning in the quality register and lessons log so the next stage boundary can evidence that learning has been applied.