Execution 6 - Closing a Project

Google Project Management Certificate · Course 4: Project Execution - Running the Project

---

Projects rarely end with a bang. They tail off: the last deliverable ships, people drift onto the next thing, and the project is finished without ever being closed. This module is about the difference, and about the surprisingly expensive gap between the two.

The framing image is a restaurant. Ordering your meal and eating it does not mean the evening is over - you still have to pay the bill before you walk out. Projects work the same way. A project that has produced everything it promised can still leave unsigned contracts, unbilled vendors, stakeholders who think they can still request changes, and contractors quietly logging hours against a budget nobody is watching.

So closing is a phase in its own right, with its own criteria, its own process, its own presentation to stakeholders, its own ritual for the team, and its own document. This module walks all five, then ends with the artefact a project manager writes for the next project manager: the project closeout report.

Note

Where this sits: closing is the final phase of the project life cycle, after initiating, planning, and executing and monitoring. It is also the phase most often skipped - which is exactly why it needs planning like any other phase.

---

What closing a project actually means

Note

Project closing - the processes performed to formally complete the project, the current phase, and all contractual obligations.

Completing a project and closing a project are two different events. Three criteria have to be satisfied before a project is genuinely closed.

1. Assure all work is donedouble- and triple-check nothing was overlooked

2. Ensure the agreed project management processes were executedthe administrative and procedural work, not just the tasks

3. Get formal recognition from key stakeholderswritten agreement that the project is done

All three, in order. Missing any one of them leaves the project half-open.

Assure all work is done

Work gets reprioritised mid-project, and a reprioritised task is a task that can quietly fall off the list. On Project Plant Pals, user acceptance testing finished and everything looked wrapped up. Months later a customer went looking for allergy information about the plants on the Office Green site and found nothing - creating that allergy documentation had been overlooked. A review before wrapping up would have caught it, instead of forcing the team to reopen a closed project.

Ensure the agreed processes were executed

When a task itself is finished, the paperwork that follows it is easy to forget. The classic example is contracts: months after launch you revisit the agreement with the plant provider and realise neither party ever actually signed it. That leaves both sides legally exposed, long after the service has gone live.

Get formal stakeholder recognition

Without formal sign-off that the project is over, some stakeholders will keep treating it as active and keep requesting adjustments - and that lands on your team. If Office Green’s contracted web developers believe the project is still running, they may still be dedicating time and billing hours to it. That is money the company is spending on a project that does not exist any more.

---

Why closing matters, and the two projects to avoid

Closing exists for the same reason initiation, planning, execution and monitoring exist: it serves a purpose no other phase serves. Here that purpose is making sure nothing has fallen through the cracks. A project left unclosed damages the team’s effort, time and credibility, and it can leave you on the hook for incomplete contracts, incomplete scope, or non-compliant practices.

Two failure patterns are worth naming because they are what an unclosed project turns into.

Pattern	What it is	Typical causes	The counter
The never-ending project	Deliverables and tasks simply cannot be completed, so the project never reaches an end	Tasks given to people without the skills to do them; deadlines not properly communicated; UAT throwing up too many bugs that do not block launch; a client who stays unsatisfied even though their requirements were met	Protect the scope fiercely. If the customer clearly wants more than this project was ever slated to deliver, commit to a follow-up project and close the current one
The abandoned project	The handoff of deliverables is inadequate, so the final deliverable never reaches the customer	No transition plan for the deliverables at the end	Plan the handoff or transition explicitly, so customers actually receive what was built. Building a product you then cannot market or sell makes no sense

Case study: Tilly’s Toys

A small toy manufacturer developed an interactive piggy bank that speaks and plays songs to teach children number recognition, counting and addition. The project ran smoothly and was never properly closed out. Three oversights, one per closing criterion.

Oversight	What happened	Impact on the organisation
Not all work was completed	The final toy box arrived from the packager without the safety disclaimer about small parts and children under the age of three. The disclaimer design was in the original statement of work but was never done	No box could be used. New boxes had to be produced at significant cost, the original launch date was missed, and the toys did not reach stores before the holiday season - lost revenue plus extended timeline and resources
An agreed process was not executed	The customer required every contractor to sign a non-disclosure agreement. One contracted educational expert never received it, and posted about the toy on social media months before launch	A breach of contract between Tilly’s Toys and their customer, and significant legal risk
No formal recognition that the project was done	The project manager assumed the team was finished and released them to other projects. The customer then sent a list of further design changes	Too late to implement them. The customer was unhappy and said they might use a different manufacturer next time

Missed launch datesLegal riskSignificant financial lossUndermined team and personal credibilityDamaged customer relationship

Caution

No matter how good the project looks in its final stages, the project manager’s job is not done until every step of the closure phase is done. Plan for closing exactly as you would plan for any other phase of the life cycle.

---

Closing for clients and stakeholders

Stakeholders usually set the goals and scope alongside the project manager, so a good PM wants them satisfied not just with the end product but with how it was handed over. Loose ends damage the relationship with customers, users and vendors, and a damaged relationship damages the team’s credibility.

One closing phase, or one per milestone?

The first decision is how many closings this project needs.

Small closeout at each milestone

→

Formal comprehensive phase at the end

→

Or both

The test for a milestone closeout: is this milestone final, meaning it will not need to be readdressed later in the project?

The Plant Pals website launch is the example. Launching the site is an official milestone and a one-time event - there will be ongoing updates and maintenance, but it will never be launched again - so a short formal closeout makes sense. That means handing over deliverables, assembling the proper documentation, and telling all stakeholders that this portion of the project is now closed.

Closing after a phase or milestone

1. Confirm the phase satisfied the strategic goals it was meant to meet. Go back to the prior documentation - statement of work, request for proposal, risk register, RACI chart - and ask whether all the required work in the elapsed phase was done, whether every identified issue was addressed, and whether every team member completed their assigned tasks.

2. Put together the closing documentation, including closeout reports, and build and review it with team members so every aspect of the project has been discussed. Review the notes from any retrospectives too, so people can say what they liked and disliked and leave with a sense of closure.

3. Conduct administrative closure of procurement. Close the necessary contracts, deliver payments to vendors, and retrieve all final deliverables from contracted workers - so external stakeholders and contractors understand the phase is genuinely over.

4. Formally recognise the completion of the phase, if needed. Every stakeholder should know a phase or project is ending. Sometimes that is an email announcing the milestone; sometimes it warrants a larger meeting.

5. Complete the follow-up work - gathering final feedback, running closing surveys, and proactively offering support for future issues.

Closing at the very end of the project

If you close once, comprehensively, the shape is a little different.

1. Provide the training tools, documentation and capabilities to use the product - manuals, how-to guides, anything that lets customers and users work the product or service after the project is closed.

2. Confirm the project satisfied its goals and desired outcomes. Review it to check every task and deliverable was completed and nothing is missing. Did you accomplish what you set out to do, and is the full scope of work complete?

3. Document acceptance from all stakeholders, clients and sponsors included. You want written proof that they are happy with the deliverables and outcomes - captured in retrospectives, a project completion document, or another formal sign-off.

4. Review all contracts and documentation with the project team - the SOW, RFP, RACI chart, risk register and procurement documents. Including the whole team in the review is what stops things being missed.

5. Document lessons learned in a formal retrospective, with your team, any other teams involved, your stakeholders and outside vendors in the room.

6. Disband and thank the project team.

---

Impact reporting

Note

Impact reporting - a presentation or formal report given to key stakeholders at the end of a project, typically the same stakeholders who were at the initial kick-off meeting. Its purpose is to show how the project went and what impact the product or service had.

It matters to the project manager personally: it is the chance to demonstrate the project’s success on your own terms and present the value your work added to the business. The core question it answers is what problem were we trying to solve, and how did we solve it?

Key performance areas

Goals, objectives, budget, schedule and key performance indicators all have to be set at the beginning of the project - the impact report simply shows how you did against those early targets.

Goals and objectiveswhat you set out to achieve by the end

Performance against KPIsa KPI is a measurable value showing how effectively a company achieves its objectives

Schedule and budget performancecost savings and efficiencies, deadlines met, delivered within budget

Restate how you defined success at the start, then show the outcomes that prove it.

The video version of the same list is shorter: how the project landed on time, scope and budget, when the new product or service launched, any available user feedback, and how the desired outcomes were achieved.

Metrics that show impact

Facts and statistics are among the best ways to present impact, so collect the data and track progress throughout the project in every area you intend to measure.

Improvement in schedule performanceRevenue growthPositive return on investmentIncreased external user countsIncreased percentage of internal usersCost versus marginsHigh customer satisfaction percentageReduction in overheadReduction in technical issuesTime saved

Pair the metrics with the right visuals and tie them back to the project’s larger goals, and the value of the project reads instantly.

Presenting it well

• Be concise. Share the metrics that show you hit the goals, drop the extraneous detail, and organise with bullet points rather than paragraphs.
• Understand your audience. Strip out technical language and jargon your stakeholders will not follow.
• Use visuals. A slide tool such as Google Slides, PowerPoint or Canva, with charts and graphs for results, images for interest, and icons to draw the eye to the point.
• Describe your learnings. Cover the lessons from the project and the areas you identified for improvement.
• Keep stakeholders engaged by varying how the data arrives: show with videos of demos, testimonials or case studies; storytell with an anecdote tied to the data; engage with questions, surveys or quizzes.

---

Closing with the team

The team side of closing has two parts: reflecting, and celebrating. Neither is optional.

Retrospectives at closure

Retrospectives were covered in depth in Quality Management →, so the short version here is what closing adds. A retrospective discusses successes, failures and possible improvements, and can be held after a major milestone or at the end of the project. Its three benefits for the team stay the same: it encourages team building by surfacing differing perspectives, it improves collaboration on future projects, and it promotes positive change in future procedures and processes.

What is new is that a retrospective is a component of the closing process itself. Whether you close after each phase or once comprehensively at the end, you run a retrospective as part of it. Teams often resist stopping to reflect before charging into the next phase, but you cannot grow without reflecting, and reflection is how you learn which practices to keep and which to improve.

That means soliciting feedback deliberately - on planning, scheduling, execution, communication or team dynamics - and accepting that some of it will be about processes you led. Working through that feedback is part of growing as a project manager, which is why the safe space for giving it matters so much.

Tip

Formal retrospectives are the practice, but most people run informal ones constantly - talking over the day with friends or family, replaying an interaction and thinking about how to handle it better. The formal version is just that instinct, written down and shared.

Celebrating and recognising the team

Recognising a job well done is part of encouraging continuous growth, not a nice extra at the end. How you celebrate depends on where you are in the project and what suits the team, but rewarding yourselves with a token of appreciation turns the celebration into a team-building exercise in its own right. Appreciation keeps the work feeling uplifting and rewarding rather than monotonous and tiring, and it fuels positive change. So play a game, eat some cake, spend some quality time together. A project is not fully closed until the team has been celebrated.

---

From the field: blameless post-mortems

A Google program manager working on computer science education programs described a live failure: during one of the year’s biggest tech education moments, the third-party platform their program depended on broke completely, while thousands of students and teachers were getting ready to code online. Emails, bugs and requests flooded in.

• Do not panic, and communicate openly and quickly while the issue is live.
• Once the problem is fixed, run a retrospective and a clear post-mortem so this team and future teams can prevent and mitigate the same thing.
• A culture of blamelessness means that when something breaks, nobody points at the engineering team for being unprepared or at the comms team for an error - the whole team takes responsibility, and the whole team gets to treat it as a chance to improve.
• Capture both scales of lesson - the big strategic ones, such as building more flexibility into a timeline, and the very small tactical tweaks that make the project run more efficiently next time.

---

The project closeout report

Note

Project closeout report - a document created by project managers, for project managers. Think of it as a transfer of knowledge from you to whoever runs the next project like this one.

Three purposes

A blueprintwhat the team did, how they did it, what they delivered

An evaluation of qualityhow good was the work

An evaluation of performanceagainst budget and schedule

Like a retrospective, the closeout report is a source of best practices for future projects.

Why it pays off: when a similar project or a continuation of yours comes up, a different project manager may well be assigned to it while you have moved on. An in-depth closeout report tells them what happened last time, including what worked well and what did not, and it cuts the time you spend fielding their questions. Assume your future readers know nothing about the project, and be as detailed as necessary for them to understand its purpose, execution and outcome from the report alone.

What goes in it

Section	What to write
Executive summary	A description of the process and the purpose of the project, a few sentences to a paragraph at most. Test it: if an executive read only this, would they understand the project’s highlights?
Key accomplishments	The team’s achievements and the overall impact of the project
Lessons learned	What went well and why, what went wrong and why, and the major effects of key problem areas such as scope creep and schedule slip
Open items	What you did not quite get to, plus ideas for changes you would have made with more time
Next steps	Expected follow-up projects, and any ongoing maintenance required
Schedule and deadlines	What the milestones were and how you chose them, how long the project took, whether it stayed on track, and any major setbacks
Resources and team members	Who was involved and what their roles were - also the place to acknowledge everyone who contributed
Resources and project archive	Links to the original project plan, documented stakeholder communication and feedback such as meeting notes, the documents used to track, monitor and report, and technical material for the deliverables such as user guides and manuals

Closeout reports promote visibility among team members and make future projects more efficient. They benefit the organisation and the project manager alike.

---

Revision summary

Tip

One-minute recap

• Closing = the processes that formally complete the project, the current phase, and contractual obligations. Completing a project is not the same as closing it - you still have to pay the bill before leaving the restaurant.
• Three closing criteria: all work is done, all agreed project management processes were executed, and key stakeholders have formally recognised and agreed that the project is complete.
• Skipping any of them costs money. Overlooked tasks force you to reopen the project, unsigned contracts leave both parties exposed, and stakeholders who think the project is live keep requesting changes and billing hours.
• Two projects to avoid: the never-ending project, where deliverables can never be completed, countered by protecting scope and committing to a follow-up project instead; and the abandoned project, where an inadequate handoff means the deliverable never reaches the customer.
• Tilly’s Toys shows one failure per criterion: a missing safety disclaimer that scrapped every box and the launch date, an unsigned NDA that became a breach of contract, and an early team release that left a customer’s change requests too late to honour.
• Consequences of poor closure: missed launch dates, legal risk, financial loss, undermined credibility, damaged customer relationships.
• Decide the closing shape: a small closeout at each final milestone, a comprehensive phase at the end, or both. A milestone qualifies if it will never be readdressed.
• Phase closeout: confirm strategic goals were met against SOW, RFP, risk register and RACI chart; build closing documentation with the team; administratively close procurement, pay vendors, retrieve deliverables; formally announce completion; do the follow-up feedback and surveys.
• Final closeout: hand over training, manuals and how-to guides; confirm goals and full scope were met; document written stakeholder acceptance; review all contracts and documents with the team; hold a formal retrospective; disband and thank the team.
• Impact reporting is the end-of-project presentation for the kick-off stakeholders: goals and objectives, performance against KPIs, schedule and budget performance, time, scope, budget, launch date, user feedback. Answer what problem did we solve, and how?
• Metrics carry it - schedule performance, revenue, ROI, user counts, cost versus margins, satisfaction, overhead, technical issues, time saved. Be concise, know the audience, use visuals, describe learnings, and keep people engaged by showing, storytelling and engaging.
• Retrospectives are part of closing itself, not an optional epilogue: team building, better future collaboration, positive process change - held blamelessly, capturing both strategic and small tactical lessons.
• Celebrate the team. A project is not fully closed until a job well done has been recognised.
• The project closeout report is written by a PM for future PMs: a blueprint of what was done, an evaluation of quality, and an evaluation of budget and schedule performance. Sections: executive summary, key accomplishments, lessons learned, open items, next steps, schedule and deadlines, resources and team members, resources and project archive.

Note

Closing out Course 4. Execution started with tracking the plan and reporting status honestly, then asked whether the work was any good through quality management, then made the case with data and a story stakeholders could act on. From there it turned to the people side - leading a team, handling conflict, and communicating with everyone the project touches. This module supplies the ending: proving the impact, capturing the lessons, thanking the team, and writing it all down so the next project starts further along than this one did.

---

Back to the course overview →.