SkarpChapter 10 of 11
Finishing Well: Handover, Closure, Reviews and Lessons Learned
See how a project is wrapped up professionally, from handing over outputs to capturing lessons so that future projects start smarter.
1. Why Finishing Well Matters
Why Finishing Well Matters
How a project finishes is as important as how it starts. Professional closure protects the benefits promised in the business case and avoids loose ends or disputes about whether the project is really finished.
PFQ View of Closure
In PFQ-aligned practice, closure is a structured phase: confirm outputs, hand over to operations, review performance vs business case, and capture lessons learned for future projects.
Risks of Poor Closure
If closure is rushed: operations may not be ready, stakeholders may dispute completion, and the organisation may repeat the same mistakes on later projects.
Link to Earlier Topics
Closure checks whether quality, resources and procurement decisions delivered the promised outputs, and whether communication and leadership supported a positive, well-managed finish.
2. Overview of the Closure Process (PFQ-Aligned)
PFQ Closure at a Glance
PFQ treats closure as a planned phase. A simple structure: 1) prepare for closure, 2) hand over and transition, 3) confirm acceptance and close contracts, 4) review performance and benefits, 5) capture lessons, 6) release resources and archive.
Overlap in Practice
These steps can overlap. Small projects might cover them in one workshop; larger projects may treat each step as a mini-workstream with its own checklist and owner.
Alignment with Modern Standards
Organisations often use templates aligned with current standards like APM BoK 7th edition or PRINCE2 7. Whatever the method, the essentials are controlled handover, a clear closure decision, and deliberate learning.
3. Preparing for Closure
Start Closure Early
Closure begins before the last task is finished. Plan the end-state early and refine it: know what “done” means, who will own outputs, and how acceptance and reviews will happen.
Check Scope Completion
Compare delivered outputs to the baseline scope. Identify remaining work, change requests, or agreed descopes so you can explain clearly what has and has not been delivered.
Update Key Documents
Bring the business case, plans, risk and issue logs, and change records up to date. These become the factual basis for handover, audits, and post-project reviews.
Engage Stakeholders
Confirm with sponsor and users what "done" means, communicate a closure timeline, and plan the handover: future owners, training, support, and documentation.
Simple Example
For a student website redesign, preparing for closure includes: checking all pages are live, updating the style guide, scheduling staff training, and arranging final sign-off.
4. Handover and Transition to Operations
What is Handover?
Handover is the bridge from project mode to business-as-usual. The aim is that operations can safely own, use, and support the new outputs without relying on the project team.
Technical and Operational Handover
Provide final deliverables, configuration details, access rights, and support procedures to the operational owners and support teams who will run the solution.
Training and Knowledge Transfer
Run user and support training. Provide manuals, quick-start guides, FAQs, or recorded demos so knowledge is not trapped in the project team.
Support, Warranty, Acceptance
Agree incident handling and support levels, confirm supplier warranties or SLAs, and obtain formal acceptance from the sponsor or customer.
Timetable App Example
A new timetable app is handed to IT operations with training and a 3‑month hyper-care period. The Students' Union signs acceptance once key tests and early fixes are complete.
5. Thought Exercise: Design a Handover Checklist
Imagine you are closing a project that has introduced new lab booking software at your university. Students and staff can now book lab time online instead of using paper forms.
Your task: sketch a handover checklist for this project.
Write down at least 5 items under these headings:
- To give to operations
- What artefacts, documents, or accesses must be transferred so IT services can support the system?
- To give to users
- What training, guides, or communications do students and staff need?
- To confirm with the sponsor
- What decisions or approvals are needed to formally close the project?
Prompt questions:
- How will people know where to get help if the system fails?
- What needs to be documented so a new technician, hired next year, can understand the system?
- What would you want to know if you were a lab user encountering this for the first time?
Pause for 3–4 minutes and draft your checklist. If you are studying with others, compare lists and agree the 3 most critical items.
6. Post-Project Review and Benefits Review
Two Types of Review
PFQ distinguishes post-project reviews, which focus on how the project was run, from benefits reviews, which focus on whether the expected value has actually been realised after the project ends.
Post-Project Review
Held near closure. Examines time, cost, quality, risk, change, suppliers, and team performance. Compares actual performance to the original or updated business case.
Benefits Review
Held months or years later. Checks if the benefits in the business case, such as savings or satisfaction improvements, are being achieved and identifies unintended impacts.
Role of the Business Case
The business case justified the investment. Reviews test whether the promised value is emerging and whether assumptions and forecasts were realistic.
Timetable App Example
Post-project review: did we go live on time and manage suppliers well? Benefits review a year later: have complaints dropped and staff admin time reduced as predicted?
7. Quick Check: Post-Project vs Benefits Review
Test your understanding of post-project and benefits reviews.
Which statement best describes the difference between a post-project review and a benefits review in PFQ-aligned practice?
- A post-project review focuses on whether benefits have been realised; a benefits review focuses on time and cost performance.
- A post-project review looks at how the project was managed; a benefits review looks at whether the value in the business case is being achieved over time.
- There is no real difference; both are just names for the final sign-off meeting at project closure.
- A post-project review is optional, but a benefits review is only done for failed projects.
Show Answer
Answer: B) A post-project review looks at how the project was managed; a benefits review looks at whether the value in the business case is being achieved over time.
A post-project review examines how the project was managed and delivered (time, cost, quality, processes). A benefits review, held later, checks whether the benefits and value described in the business case are actually being realised.
8. Lessons Learned and Knowledge Capture
What Are Lessons Learned?
Lessons are actionable insights from experience that can improve future projects. They should be specific, evidence-based, and suggest what to do differently next time.
Collect and Discuss
Capture lessons throughout the project and hold a closure workshop with team, sponsor, and key stakeholders. Ask: what went well, what did not, and what should we change?
Refine and Prioritise
Turn vague comments into precise statements. Move from “communication was bad” to concrete practices that helped or hindered, and prioritise the lessons with biggest impact.
Store and Reuse
Store lessons in a central log or knowledge base, tagged by topic. Feed them into templates, checklists, risk lists, and kick-off meetings for new projects.
Example Lesson
Example: involving IT support in early design workshops reduced rework. Future software projects should invite operations to at least two early design meetings.
9. Turn Experiences into Lessons
Think of a group assignment or project you have worked on (at university, work, or volunteering) that is now complete.
- List 3 experiences
- One thing that went well.
- One thing that went badly.
- One surprise (good or bad).
- Turn each into a lesson using this structure:
- Situation: When/where did this happen?
- Observation: What exactly happened?
- Impact: Why did it matter?
- Recommendation: What should be done differently next time?
Example transformation:
- Raw comment: "We started writing the report too late."
- Lesson: "In our marketing group project, we delayed report drafting until the final week, causing rushed work and errors. Future groups should produce a rough draft by week 3 to allow time for review."
Write your 3 lessons in this structured way. If you are in a class, share one lesson with a partner and see if they could apply it to their next project.
10. Key Terms Review
Flip these cards to review core concepts from this module.
- Project closure
- A planned phase at the end of a project where outputs are handed over, acceptance is confirmed, reviews are held, lessons are captured, resources are released, and the project is formally closed.
- Handover
- The process of transferring project outputs, knowledge, and responsibilities from the project team to business-as-usual (operations) so the organisation can use and support them.
- Post-project review
- A review held near or shortly after closure that examines how the project was managed and delivered, including performance against time, cost, quality, and the business case.
- Benefits review
- A review held after the project has ended to assess whether the expected benefits and value in the business case are being realised in practice.
- Lessons learned
- Actionable insights, based on project experience and evidence, that describe what should be repeated or changed in future projects to improve performance.
- Business-as-usual (BAU)
- The ongoing operational environment that takes ownership of project outputs and is responsible for realising benefits after the project closes.
Key Terms
- Handover
- The transition of deliverables, knowledge, and responsibilities from the project team to operational owners so they can run and support the outputs.
- Hyper-care
- A short, intensive support period immediately after go-live when the project team provides extra help to operations and users to stabilise the new solution.
- Business case
- A document that justifies a project or programme by describing the problem or opportunity, options, costs, benefits, risks, and recommendations.
- Benefits review
- A review that checks whether the benefits expected in the business case are actually being realised after the project has closed.
- Lessons learned
- Documented, evidence-based insights from a project that can guide better decisions and practices in future projects.
- Project closure
- A structured phase at the end of a project where outputs are handed over, acceptance is confirmed, reviews and lessons are completed, resources are released, and the project is formally ended.
- Post-project review
- A review focused on how the project was managed and delivered, typically held at or soon after closure, comparing performance against objectives and the business case.
- Business-as-usual (BAU)
- The normal operational environment of an organisation, which takes over from projects and is responsible for using outputs to realise benefits.