Project-End Report and Lessons Learned in PM²: closing with evidence and reusable knowledge
Thirtieth article in the “Learning PM² Through a Project” series
A project is not truly closed when the last feature is in production or when the team stops working on it. Closure requires an explicit account of what was delivered, what remains open, which decisions were taken and what the organisation can learn.
In PM², the Project-End Report documents the project outcome; Lessons Learned turn experience, mistakes and effective practices into useful learning for future projects. They are distinct artefacts, but both help close with accountability and preserve value.
Closing: the context for both artefacts
At the end of Executing, the RfC — Ready for Closing gate authorises entry into Closing. This phase includes final review, transition, administrative closure and learning capture. Only after these activities can the project be declared concluded.
flowchart LR
A[Deliverables completed and accepted] --> B[RfC]
B --> C[Final review and Lessons Learned]
C --> D[Project-End Report]
D --> E[Handover, residual actions and administrative closure]
E --> F[Project Ended]
The Project-End Report is not a decorative step toward Project Ended: it is a verifiable summary that allows governance to understand what happened, which commitments continue and whether closure is correct.
What the Project-End Report is for
The Project-End Report answers questions that become difficult or impossible to reconstruct after the team disperses:
| Question | Why it matters |
|---|---|
| Which deliverables were delivered and accepted? | Confirms outcome against scope. |
| Which objectives were achieved and with which deviations? | Makes project performance transparent. |
| Which cost, schedule, risks and issues had impact? | Explains differences between baseline, forecast and outcome. |
| What remains open, and who owns it? | Prevents post-project actions from having no responsibility. |
| How are handover and support handled? | Connects the project to operations. |
| Which lessons should be reused? | Preserves knowledge for the future. |
It is not an exercise to demonstrate that everything went well. A credible report also documents delays, deferred scope, higher cost and problems, linking them to facts, decisions and impacts.
Practical report structure
Detail depends on project size, risk and obligations. A solid structure includes:
| Section | Content |
|---|---|
| Executive summary | Objective, overall outcome, main results and points for governance. |
| Deliverables and acceptance | What was delivered, accepted, deferred or excluded; any waivers. |
| Performance | Comparison of baseline, key forecasts and outcome for scope, schedule, cost/effort and quality. |
| Benefits and business implementation | Adoption status, available measures, benefit owner and post-project actions. |
| Risks, issues, changes and decisions | Items that had impact and how they were managed. |
| Transition and handover | Support, documentation, operational ownership, contracts and residual conditions. |
| Residual actions | Owner, due date, completion criterion and monitoring channel. |
| Lessons Learned | Reference to captured lessons and improvement actions. |
The mistake is turning it into a copy of every log. The report summarises the significance of events and refers to detailed evidence where needed.
Lessons Learned: not only “what went wrong”
A useful lesson is not a generic phrase such as “communicate better” or “test earlier”. It links context, evidence, effect and future practice.
| Element | Example |
|---|---|
| Context | Integration with a notification provider in a mobile release. |
| Observation / evidence | End-to-end testing happened only close to go-live. |
| Effect | An Android defect reduced buffer and created an urgent fallback. |
| Lesson | For critical external dependencies, execute end-to-end tests on representative devices by a defined milestone. |
| Reusable action | Add the check to the Work Plan template and assign an owner. |
The lesson should not seek blame. It improves the system of work: available information, process, roles, tools, decisions, skills and organisational conditions.
Collect lessons during the project
Waiting for the final meeting loses detail and encourages selective memories. PM² treats Lessons Learned as an activity that can collect evidence throughout the lifecycle, then consolidate it in Closing.
| Moment | Useful question |
|---|---|
| After a gate or milestone | What enabled or hindered the transition? |
| After a material issue | Which signal or control could have anticipated it? |
| After a release or test | What worked and what should be standardised? |
| During Closing | Which patterns, not isolated events, deserve future action? |
A lightweight Lessons Log, updated during the project, makes final review more concrete and less dependent on memory.
Final review: facts before opinions
The Project-End Review Meeting should involve people with useful perspectives: business, solution, key users, PM and, where appropriate, support or suppliers.
Discussion works better when it starts with evidence:
- deliverables and acceptance criteria;
- milestones and deviations;
- trends in risks, issues and changes;
- quality and adoption measures;
- user and stakeholder feedback;
- comparison with objectives and expected benefits.
Then move to causes and actions. “We had communication problems” is too generic; “PO decisions had no deadline and blocked three critical-path activities” is a diagnosis that can be acted upon.
The Annotatio case: closing Smart Bookings
At closure of Smart Bookings, the Project-End Report could state:
| Area | Outcome |
|---|---|
| Deliverables | Booking, cancellation and waiting list accepted; dashboard deferred to next release with approved change. |
| Schedule | Go-live on 7 July instead of 30 June, due to Android issue and late acceptance availability. |
| Cost / effort | +10% effort, within approved tolerance; no additional external cost. |
| Quality | Main flow and concurrency tested; email fallback temporarily active. |
| Transition | Operational support assigned, guide available, two-week hypercare complete. |
| Benefits | After two weeks, 85% of bookings managed in Annotatio; no-show measurement continues with BM as owner. |
| Residual actions | Fix Android push before next release; deliver CSV/occupancy dashboard as planned change. |
Two possible lessons:
| Observation | Lesson and action |
|---|---|
| Push testing was too late. | Insert end-to-end tests on real devices before the readiness milestone; technical owner. |
| Manager availability for acceptance was confirmed late. | Make the acceptance window a binding dependency in the Work Plan during Planning; PM/BM owner. |
This report does not say that the project was a “success” or “failure” in the abstract. It shows results, deviations, decisions and residual responsibilities so governance can close consciously.
Post-project actions: closing does not mean abandoning
Some actions can continue after closure: benefit measurement, excluded evolutions, accepted waiver corrections, audits, contract renewals or adoption follow-up.
For every post-project action, the report should state:
| Element | Question |
|---|---|
| Owner | Who is accountable after the project team is disbanded? |
| Due date | By when should it be completed or reviewed? |
| Resources / budget | Which operations or initiative will support it? |
| Monitoring | In which forum or tool will it be followed? |
| Completion criterion | How is completion demonstrated? |
Without these elements, “we will do it later” merely transfers an unmanaged risk outside the project.
Do not confuse these
| Statement | Correction |
|---|---|
| “The Project-End Report is an administrative formality.” | It documents outcome, deviations, handover, residual actions and closure responsibilities. |
| “Lessons are for listing errors.” | They turn observations into reusable practices or actions. |
| “Lessons are collected only at the end.” | Collect them during the project and consolidate them in Closing. |
| “A post-project action can remain in the report without owner.” | Without owner, due date and monitoring, it is not managed. |
Three questions to anchor it
- Which comparison between baseline and final outcome must be transparent in the Project-End Report?
- Which evidence turns an episode into a reusable lesson?
- Who owns actions and benefits once the project is officially closed?
Flashcards
Q: What is the Project-End Report for?
A: To summarise outcome, deliverables, performance, handover, residual actions, benefits and learning needed to close the project correctly.
Q: What makes a lesson learned useful?
A: Context, evidence, effect, a concrete future practice and, where needed, an action/owner to reuse it.
Q: Why collect lessons during the project?
A: To avoid losing detail and to improve practices in the current project, not only future ones.
Exam-style question
During closure, the PM archives the logs and writes: “The project ended with some delay; we need to communicate better in future.” No deferred deliverables, support owner or residual actions are stated.
What is the main correction?
Answer: the Project-End Report should document outcome against scope, schedule, cost, quality and handover, assigning residual actions. Lessons Learned should be specific and actionable, for example linking delays to observable causes and a future practice with an owner.
Source
The Project-End Review Meeting, Lessons Learned, Project-End Report and Administrative Closure are covered in the European Commission’s PM² Methodology Guide 3.1.
This article completes the essential PM² artefacts path. The most useful next step is a final collection of mind maps, quizzes and integrated cases to consolidate certification preparation.