Pressure to close before service acceptance
A local government data-migration project reports all deliverables complete on time and under budget. The project was to migrate 1.2 million records to a new case-management system and decommission two legacy servers. The project manager is under pressure to close before the fiscal year end in 15 days so remaining budget is not surrendered. Operations has not signed the service acceptance agreement, the runbook is a draft, two data-quality exceptions remain unresolved, and no benefits review has been scheduled. The business owner says benefits will be 'obvious' after six months. The lessons-learned workshop was cancelled twice. The vendor has demobilised its migration team. The steering committee asks you to approve closure. What do you do?
1. Which closure criteria are unmet, and what does ISO 21502 guidance imply about closing now?
Read the worked answer
Unmet closure criteria. Service acceptance is unsigned, the runbook is draft, two data-quality exceptions are unresolved, benefits review is unscheduled, and lessons learned have not been captured. Allocating budget is not a closure criterion. Closure guidance expects confirmed acceptance, transition to operations, release of resources, archival of records, lessons learned and arrangements for benefits realization.
What I would do. Refuse unconditional closure on the current evidence. Propose a conditional or phased closure with a short list of entry conditions, named owners and dates: signed service acceptance, approved runbook, disposition of the two exceptions, benefits review scheduled, lessons workshop held. Residual issues should be transferred formally with an owner and review date. If the sponsor insists on closing for fiscal reasons, I would record the decision and the orphaned risks. Closing to avoid losing budget creates a larger hidden liability.
2. How would you structure the handover and benefits arrangements in 15 days?
Read the worked answer
Handover. Agree a service acceptance checklist with operations: support model, escalation path, runbook, known errors, access, backup and recovery, and the two data exceptions with owners. Get signatures before demobilisation is complete. Transfer residual defects into the operations defect log with severity and target dates.
Benefits. Schedule a benefits review at three, six and twelve months, with a named benefits owner, baseline values and measures such as record accuracy, case-processing time and legacy-server retirement. Do not accept 'obvious' as a measure. Lessons. Run a short facilitated workshop with the vendor, operations and the project team; capture what to repeat and what to change; store in the organizational repository.
Final report. Summarize outcome against baseline, variances, unresolved items and recommendations. This makes closure a controlled transition, not an administrative disappearance.
3. The sponsor argues that closure is an administrative step. How do you respond?
Read the worked answer
Response. Closure is a management practice, not paperwork. It confirms that the product has been accepted, that operations can support it, that residual risks have an owner, and that benefits will be measured. Closing before those conditions exist creates orphaned issues and makes the project appear successful while transferring risk to operations.
Practical route. I would offer the sponsor a date-bound closure plan: conditions, owners, evidence required and a decision date within 15 days. If some conditions cannot be met, propose conditional closure with a formal transfer register and a follow-up review. I would ask the steering committee to either approve that conditional route or explicitly accept the residual risk. The project manager's accountability is to make the trade-off visible, not to trade governance for an underspend.