Go-Live Is Fixed, So the Quality Review Was Cancelled
A retail bank is migrating card processing to a new platform. The project product description says the platform must be 'fast and stable'. Product descriptions exist for the migration plan and the test plan but not for the data-migration runbook that operations staff will follow on go-live night. The supplier's own test team performs all testing and signs off its own results. A quality review of the runbook, booked for last week, was cancelled to protect the go-live date. Two of the four project board members have never seen the quality register. The project manager says quality is 'covered by the supplier's contract'.
1. Identify the quality-related failures in this project and state what the project manager should put in place.
Read the worked answer
There are five distinct failures, and only the last is about paperwork.
- No measurable quality criteria. 'Fast and stable' is not a quality criterion; it cannot be tested, so acceptance becomes an argument. The customer's quality expectations in the project product description must be turned into measurable acceptance criteria (throughput, error rate, availability, recovery time).
- A missing product. The runbook that operations will follow on the highest-risk night of the project has no product description, so nobody has specified what a correct runbook contains, who reviews it or what 'done' means.
- No independence in quality control. The supplier cannot be the producer and the approver of its own test results. Quality control requires the customer side - senior user, project assurance, or an independent test function - to approve.
- No usable quality register. Reviews planned, held and outcomes must be recorded and visible; two board members not knowing it exists signals quality is invisible to the people accountable for it.
- Outsourcing responsibility. A contract transfers work, not accountability; the project manager is responsible for the quality approach.
Actions: rewrite acceptance criteria, add product descriptions for the runbook and other operational products, reassign approval to the customer side, and maintain the quality register.
2. The go-live date cannot move. What is the defensible response to the cancelled quality review, and who should make the decision?
Read the worked answer
The defensible response starts from a hard position: an unreviewed runbook is an unfinished product, and an unfinished product cannot be accepted for use. Cancelling the review did not remove the risk, it moved it to go-live night.
Options, in order of preference:
- Re-plan the review in a tailored form. Quality methods can be adapted - a structured walkthrough of the critical rollback and recovery sections with the operations lead may achieve the necessary assurance in a fraction of the time of a full review. Tailoring the method is legitimate; abandoning the control is not.
- Escalate. If the review genuinely cannot happen before go-live, this is an issue for the project board, because it is the board that accepts risk on behalf of the business. Prepare an issue report setting out what is not assured, the consequences on go-live night, and the options with dates.
- If the board accepts the deviation, record it in the quality register and on the product, with the acceptance owner named - so that if go-live fails, the decision is visible rather than accidental.
The project manager must not decide this alone by allowing a date to override a control, and must not pretend the contract absorbs it.
3. On the final acceptance meeting, the operations manager refuses to sign off the migrated data, saying it 'feels incomplete'. Who is entitled to accept the products, and how should the project manager handle the refusal?
Read the worked answer
Acceptance is a user-side act. The senior user is accountable for confirming that the products meet the user community's needs and that the intended benefits can be realised; the project manager cannot accept products on the users' behalf, and the supplier certainly cannot.
Handling the refusal:
- Test it against the acceptance criteria. If the criteria were made measurable (as they should have been), the conversation becomes 'which criterion is not met, and what evidence shows it?' rather than a debate about feelings. This is precisely why vague criteria are dangerous - they leave a refusal unanswerable.
- If a criterion is genuinely unmet, treat it as an off-specification issue: log it, assess impact on cost, time and benefits, and agree remedial work and re-acceptance.
- If the operations manager is not the senior user, establish who holds that accountability and ensure operations is represented in the acceptance process - ideally as the named senior user or an agreed delegate - before the meeting, not after it.
- Escalate to the board if acceptance and go-live cannot be reconciled within tolerance.
Judgement point: the project manager's job is to make acceptance evidence-based and properly owned, not to talk the user into signing.