The project that cannot define done
Northgate Payroll Services chartered Project Phoenix 14 months ago to replace a 19-year-old payroll engine before a regulatory reporting deadline in nine months. The charter objective reads 'modernise payroll to improve resilience'. Sixty-two percent of the approved budget is spent, but no agreed definition of done exists. The team reports progress by counting features released; operations has already absorbed about 30 percent of the new capability into business-as-usual, including a new validation service. A remaining data-cleansing effort of roughly 12 weeks is claimed by both the project and the payroll operations manager, who says it is 'just fixing bad records'. The sponsor wants the project closed by the end of Q4 to release contingency, while the compliance lead says the regulatory outcome is not yet demonstrable. Two releases slipped because the project treated user acceptance testing as a final gate rather than an incremental feedback point. The PM is asked to decide what is project work, what is BAU, and whether 'closed' can be declared.
1. How should the PM distinguish project work from business-as-usual and continuous improvement in this situation? Explain the criteria you would apply and how they affect the decision about the data-cleansing effort.
Read the worked answer
The PM should not settle this by labels or by who is arguing loudest. Start with the ITIL 4 view of a project as a temporary endeavour undertaken to create a unique product, service or result, and test the work against four criteria: does it have a defined start and end, a unique outcome rather than a recurring operational task, cross-team coordination or funding that needs temporary governance, and an owner who can accept the outcome?
Apply that to the data cleansing. If the 12 weeks are a one-off remediation of legacy records needed for cutover and regulatory reporting, it has a temporary boundary, a unique outcome and cross-team dependencies; manage it as project scope or a project iteration with explicit exit criteria. If bad records recur weekly and operations will keep fixing them after go-live, that part is BAU and should be owned by the payroll operations manager with a problem-management and continual-improvement route.
The practical answer is usually a split: keep the one-off remediation in a controlled work package with a named acceptance owner, and establish a BAU capability for recurring data quality, including measures and a service owner. This prevents the project from absorbing permanent operational debt while also preventing operations from declaring difficult remediation work 'not ours'. The decision should be recorded in the business case and scope baseline, not left as an informal argument.
2. Evaluate the charter objective 'modernise payroll to improve resilience' against ITIL 4 project concepts. What should the PM do now to make the objective testable?
Read the worked answer
The objective mixes an output ('modernise payroll') with a hoped-for outcome ('improve resilience') and gives no measure, baseline or acceptance authority. ITIL 4 distinguishes outputs from outcomes: the new engine, validation service and reports are outputs; resilience is an outcome that must be observable in service behaviour. As written, the objective cannot tell the team when to stop, cannot support a benefits case and cannot help the sponsor decide whether contingency should be released.
The PM should rework the objective with the sponsor, compliance lead and payroll operations. First, identify the outcome the organisation actually needs: for example, payroll runs complete accurately by the regulatory deadline, material failures are detected before payment, and recovery within an agreed time is demonstrated. Second, attach baselines and measures, such as current failure rate, reconciliation effort, recovery test results and reporting accuracy. Third, define dis-benefits and constraints: cost, disruption during peak payroll cycles, audit evidence. Fourth, state who accepts each outcome.
This is not bureaucracy. It changes prioritisation: if resilience is the outcome, then validation, monitoring, recovery testing and operational readiness may outrank another feature. It also changes closure: releasing contingency because features are counted is not the same as demonstrating the regulatory outcome. The revised objective should be agreed as a change to the charter and reflected in the business case.
3. What does 'done' mean for Project Phoenix, and how should the PM respond to the sponsor's request to close by Q4?
Read the worked answer
'Done' should mean the agreed outcomes have been accepted and can be sustained without the project. That normally requires four tests: the regulatory outcome is demonstrable against agreed measures; the new capability has an operational owner, support model and service levels; knowledge and residual risks have been transferred; and any remaining work has a funded, governed home. Feature count alone is an output measure and is not evidence of transition.
The PM should resist a binary choice between 'close' and 'continue everything'. Convene a closure readiness review with the sponsor, compliance, operations and finance. Present the evidence against each test, including the failed UAT feedback pattern and the unresolved data-cleansing ownership. If the regulatory outcome is not demonstrable, the project should not be declared closed. However, the PM can propose closing a phase: transfer recurring data quality to BAU, retain a small outcome-focused remediation backlog with clear exit criteria, and release only contingency that is genuinely surplus.
The sponsor's Q4 date can become a decision point rather than an arbitrary end date. Document the residual risk if closure is forced: compliance exposure, hidden operational cost and unclear ownership. A controlled phase closure with named BAU ownership is honest; premature closure simply moves the risk somewhere it cannot be seen.