10.8 Closing a Project and Its Agile Workshops

10.8 Closing a Project and Its Agile Workshops

Quick summary: CP provides a fixed point at which acceptance of the project product is confirmed and the objectives are recognised as achieved — or at which the project is recognised as having nothing further to contribute. Its workshops are the project closure workshop, which establishes clear guidelines for ongoing benefits realization, and the project retrospective.

Purpose

The purpose of closing a project is to provide a fixed point at which acceptance of the project product is confirmed, and to recognise that the objectives set out in the original project initiation documentation have been achieved — or that the project has nothing more to contribute.

That second clause matters. Premature closure is a legitimate outcome. A project stopped because its justification has evaporated has applied the ensure continued business justification principle correctly, and it closes through this process in an orderly way rather than simply stopping.

Without a fixed closure point, projects drift into an indefinite state in which nobody is accountable, resources are never released, and the benefits are never measured.

Activities

The project closure workshop

The project closure workshop brings the project board, project manager, product owners, delivery teams and the receiving operational parties together for the final review.

Its most examinable feature: it establishes clear guidelines for ongoing benefits realization.

This matters because most benefits are realized after the project closes. The project delivers outputs; adoption produces outcomes; outcomes yield benefits, often over months. So the workshop settles:

• Which benefits remain to be realized, and by when
• Who is accountable for realizing and measuring each one after closure
• How and when they will be measured, per the benefits management approach
• What the receiving organization must keep doing for the benefits to appear
• What follow-on action recommendations exist for work the project is not doing

Without this, a project can deliver everything it promised and still fail its business case, because nobody owned the benefits once the team dispersed.

The project retrospective

The project retrospective captures project-level lessons for the organization, satisfying learn from experience at the point where the whole arc of the project can be seen.

Distinguish it clearly from the team retrospective workshop:

The project retrospective looks at things a team retrospective cannot see: whether the tailoring decisions were right, whether the governance rhythm worked, whether the estimates held across the project, whether the Agilometer assessment proved accurate, and whether the agile approach chosen was the right one.

Hand-over and transition

Products transfer to the operational environment, and the transition needs:

• Operational readiness — the receiving team trained, staffed and equipped
• Support arrangements agreed — who fixes it, to what response times
• Documentation at the level operations actually needs
• Outstanding items transferred: known defects, remaining backlog, technical debt
• Change management completed — adoption is the point, and section 11.1 covers transition in detail

Agile tailoring: closure should be close to a formality

The most useful practical point about CP on an agile project: if frequent releases have been working, closure should be small.

In a plan-driven project, closure is where everything happens at once — first hand-over, first acceptance, first operational contact, first benefit measurement. It is high-risk because every assumption is tested simultaneously.

Where a project has been releasing regularly:

• Products have been handed over progressively, so operations already knows the product
• Acceptance has been incremental, so there is no large acceptance test to fail
• Benefits have already started appearing, so the forecast is evidence-based
• Lessons have been captured continuously in team retrospectives, so the project retrospective consolidates rather than excavates

What remains is confirmation: final acceptance, the last hand-over, the evaluation, the benefits guidance, and the board's authorization to close. That is what a well-run agile project's closure looks like — the last piece of the jigsaw, not a cliff edge.