Capstone 4 - Closing the Project

Google Project Management Certificate · Course 6: Applying Project Management in the Real World

Week 3 ended with the tablets tested, the survey results read and the retrospective run. This final week does two things at once. It finishes the execution phase with the communication skill that execution keeps demanding, escalating a problem to someone senior, and then it walks the project across the line into the closing phase.

The order matters. A problem is only worth a senior stakeholder’s attention if you can say what it is in one or two sentences and say what it costs the organisation, which is where objectives and key results come back in. Once the fixes land and the tablets launch, closing is about documentation rather than delivery: a closeout report written for the next project manager, an impact report written for the people who funded the work, an archive that makes the whole project findable, and a proper thank you to the team.

The week closes the certificate as well as the project. The last activity turns the same closing technique on the learner, as a personal closing report on the programme itself.

Communicating a project problem

Every project has problems, and communicating them is part of the project manager’s job. Most are small enough to settle inside the immediate project team. Occasionally one has to be escalated to a senior stakeholder, together with a proposed solution, so they can give input and guidance on the next step.

The core principle: a stakeholder should never have to open several project documents or chase multiple email threads to work out what the problem is. Pulling the relevant pieces together is the project manager’s responsibility, not theirs.

The test question

When deciding what belongs in a one to two sentence overview, ask: how can I communicate a decision in a way that makes it easy for them to decide?

Sending a link to the project plan and pointing at the overdue rows fails that test, because it gives no understanding of what the problem actually is.

Several sourcesemails, meeting notes, presentations, the project plan

One or two sentencesthe problem stated plainly, with the cause

A line of organisational impactwhich OKR this puts at risk

A named decisionthe recommendation, and what happens if it is not taken

The shape of an escalation. Every layer exists so the stakeholder can decide without reading anything else.

The worked example from the video

Five tasks in the plan are overdue because of supplier delays, and the slippage may reach the final deliverable. Solutions have already been explored. The summary given:

A number of tasks have run past their due date because of supplier issues, so we recommend hiring a second supplier to hit the deliverable date. Otherwise we will need to push the launch date back.

That gives the stakeholder three usable options: agree with the solution, disagree with it, or offer one of their own. Any of the three counts as success, because the project manager’s role was to communicate the problem and propose a solution, not to be right.

Chris on problem solving

Chris is a program manager at Google working on Search, building features for millions of users across many surfaces, languages and information needs. His view is blunt: problem solving is the single most important thing program managers do, because it is the job.

Scope problems - work moving out of scope, or scope growing or shrinkingBudget problems - too little funding, or too muchPeople problems - too few, too many, or the wrong skill setsTimeline problems

His loop is four moves: identify the problem, build a framework for it from your tools, processes and methodologies, propose a solution, and get buy-in for it. The only way to get buy-in is to put something organised and principled in front of people.

Always hunt the root cause. What you are experiencing is usually a red herring, an outcome of something underneath. Debugging the underlying systemic, process, tooling or technical issue is the first step, not the last.
The decision is the outcome. Once you understand the problem well enough, assembling an objective plan from those inputs is how you actually reach a decision.
The artifacts are not the job. Charters, scope documents, meeting notes and trackers feel like the job, but they are mechanisms and tools. The real job is running scope and programmes, convincing people, driving organisational change and solving strategic initiatives.
Build the skill anywhere. If you have not yet had big problems to work on, hobbies, building a piece of software for yourself or a friend, or a passion in another industry all supply real problems to solve. Every industry and business has them.

Activity: the problem summary

The first activity asked for a one to two sentence overview of a problem affecting the Sauce and Spoon tablet pilot, synthesised from the week’s supporting materials rather than lifted from any single one of them. The course flags that this summary is not a throwaway: it gets reused inside the escalation email written two activities later.

Objectives and key results

OKRs were introduced earlier in the programme; this week revisits them specifically as a lever for getting a problem taken seriously.

Sauce and Spoon example
Objective	Prioritise customer needs and wants
Key result	Address feedback from customer reviews within 24 hours

Two jobs OKRs do

Testing whether a project deserves to exist

If a project and its goals contribute to the organisation’s wider OKRs, that is a good sign it is relevant and worth the time and money
At Google, every project, large or small, aims to contribute tangibly to organisation-wide OKRs
Struggling to explain how a project helps reach an OKR is a strong signal to re-evaluate the project altogether

Getting a problem onto a senior agenda

Naming the specific OKRs a problem threatens makes clear why it must be addressed
It also explains why the problem is worth that person’s attention at all
Senior stakeholders have a great deal to focus on beyond your project, so an OKR link is what catches limited attention

OKRs work as a shared language across an organisation, which is exactly why they travel well upwards.

Activity: connect the problem to the OKRs

The second activity fine-tuned the problem summary from the first by adding one sentence explaining how the issue jeopardises Sauce and Spoon’s organisational objectives. The two objectives the video points at are running an efficient, profitable business model, and prioritising customer needs. Being able to identify a problem’s effect on the organisation’s OKRs is what lets you set and communicate the right level of risk and urgency.

Emailing a senior stakeholder

If an issue is big enough to escalate, it is an issue you want resolved quickly, so email is the tool: fast to send, and able to ask for a specific decision. The risk is being ignored.

Start from what matters to them. Senior stakeholders are usually more interested in a problem’s potential impact on the organisation than on a single project. Make that impact clear within the first two sentences.
Write a subject line that states the topic and the action. Words such as urgent, timely, decision needed or please review tell a person receiving many emails a day both what this is and what you want them to do.
Keep the body brief. Outline the problem, explain how it hits organisational goals, and state the decision you need in order to proceed. Concretely: one or two sentences summarising the problem, plus one sentence on the OKR impact.
Attach or link anything they need to decide, rather than making them ask for it.
Proofread. Misspellings, grammatical errors and inaccurate hyperlinks all cost credibility. Use the spellcheck and grammar tools available to you.

Laura on communicating with executives

Laura is an executive productivity advisor at Google, coaching executives one to one on time management, meeting management, effective email, communication and organisation. Her material is the counterpart to the email best practices: how to shape communication around a particular person.

Concise for an executive, detailed for a teammate. When summarising for an executive, isolate the absolutely important information they need to see.
Do the homework before you write. Ask their executive assistant, or someone who has worked with them, what their preferred communication style is, what kinds of presentation they like, and what information they typically need in order to decide. That preparation matters most when your window with them is short.
Expect stakeholders to differ. She worked with two managers on one project: one was talkative, loved brainstorming and wanted frequent meetings to hash out every detail; the other was the complete opposite. The same information and the same decision have to be tailored per person.
Anticipate the five questions. Before presenting, work out the five questions the stakeholder is likely to ask and keep that detail ready in an appendix, so their time is used well.
Arrive with proposed solutions. Not what should I do, but I think we should do A, though B and C are also options, what do you think. It gives them a starting point and shows you have done the background work and understand the problem.
Put a TLDR at the top. Too long, did not read: the one sentence they need from the email. Variants that do the same work are an update on project A, need decision, action requested, or deadline by. It tells them what is coming before they read it.
Make the body scannable. Bullets, bolding and highlighting for what must stand out, the ask reiterated at the end, deadlines stated, links and attachments included, so someone skimming or re-reading later still has everything needed to reply.

Activity: the escalation email

The third activity applied all of the above by composing an email to a stakeholder of the Sauce and Spoon tablet pilot. The problem summary written in the first activity and the OKR sentence added in the second became the body of that email, with a subject line signalling the action required.

Why closing a project properly matters

The phase reading is a set of guiding questions and tips compiled by dozens of project managers at Google. Its argument for thoroughness is risk avoidance: a project closed properly protects you, the team and the organisation from later trouble.

Assurance onethe work

All work has been completednothing is left half finished and quietly assumed to be somebody else’s problem

Assurance twothe process

All agreed project management processes have been executedincluding the ones nobody enjoys, such as procurement

Assurance threethe recognition

Everyone involved formally recognises the project is completeclosure is a shared, stated fact, not an inference from the calendar

The closing checklist

Conduct administrative closure of the procurement process.
Run a formal closing process after the final project phase or milestone.
Complete and present an impact report.
Document acceptance from all stakeholders, confirming they are happy with the deliverables and outcomes.
Formally disband and thank the project team.

Retrospective tips from the reading

The retrospective itself was Week 3’s material, but the closing reading adds four facilitation tips worth carrying into the final one.

Tip	Why it works
Create a safe space for people to share experiences and feedback	Honest input only arrives where it is safe to give
Model the behaviour and responses you want from the team	The facilitator sets the tone before anyone else speaks
Phrase questions non-confrontationally	Instead of what went wrong and what went well, ask what we should start, stop and continue
Remind the team of the milestones they reached	Recalling the whole arc of the project sparks far more discussion than starting from a blank page

The Sauce and Spoon outcome

Peta, the project manager, has taken the tablets through quality standards and launched them. Molly Edwards is the project manager taking on the next round of rollouts, and the week’s email thread is the handover conversation: Molly asks for highlights ahead of a debrief lunch, and Peta answers before writing her closeout and personal closing reports.

What the post-pilot fixes changed

The pilot responses were shaky, and the launch results come from what was changed afterwards.

Problem seen in the pilot	Fix applied	Result at launch
Guests struggled with tablet navigation	Switched to a simpler layout	Guests found the new layout much easier
Table turn time objective not being met	Worked with the general managers, trained waitstaff to be aware of guest pacing	Turn time reduced by 30 minutes, so table waits shortened too
Confusion over payment	Clearer messaging that tablets take cards only, plus a streamlined path for guests paying cash	Checkout time held at one minute or less
Glitchy tablets in service	New pre-service testing checklist	Fewer than 5 percent of customers reporting technical issues each week, hitting the standard

Goals against results

Goal	Target	Achieved
Average check total	Raise from 65 to 75 dollars	Met by the end of Q2
Appetiser sales lift	15 percent	15 percent average across the pilot locations, 10 percent North and 20 percent Downtown
Table turn time	Reduce by 30 minutes	Met, after the pacing training
Daily guest count	Up 10 percent	10 percent overall, and 20 percent at Downtown, double the target
Food waste	Cut by 25 percent	Met
Tablet checkout time	One minute or less	Held
Technical issues	Under 5 percent of guests per week	Met
Order accuracy	98 percent	Still short. Surveys showed guests were still receiving incorrect orders

Alex drove the turn time reduction with the Downtown waitstaff. Gilly is adapting to the new way of working and stays focused on the guest experience. Carter and the kitchen remained the open issue: the survey evidence on incorrect orders led to a direct conversation about examining every possible source of error, kitchen staff included, framed around the shared goal of a great customer experience.

The closeout report

Before a project manager can call a project complete, there is a closeout report to write. It is a compilation exercise as much as a reflection: every link and every document gathered in one place, a practice the course calls good project hygiene.

What it does

Confirms the project is done and summarises deliverables, success metrics, feedback, lessons learned and next steps.
Serves as a reference document for the organisation, so that a follow-up or similar project starts with the artifacts already assembled.
Reflects on the team’s performance and helps the team verify that every task was actually completed.
Finalises the team’s efforts so people can move on to new projects and tasks, with everyone satisfied with the work done.
Increases the impact of the work by communicating it to people who were not closely involved.

Who it is for

A closeout report is a document created by project managers for project managers: future project managers, and anyone interested in the project’s elements and artifacts. The reading describes it as a blueprint of what the team did, how they did it and what they delivered, including an evaluation of the quality of the work and of performance against budget and schedule.

The bar the video sets: someone entirely unfamiliar with the project should be able to read it and come away understanding what the project was, why it was done and how well it went. In this course it is also framed as a portfolio piece that can stand alone in front of a potential employer, demonstrating the ability to synthesise and communicate information clearly.

The sections

Section	What goes in it
Project summary	The objectives, or put another way, the desired result for the project
Methodology	Which approach the team used: Waterfall, Agile, Lean, a combination, or something else
Results: performance baseline	Actual against planned schedule, cost and scope, with a notes column for explaining discrepancies
Key accomplishments and outcomes	What was achieved, as bullets
Lessons learned	What the team now knows that it did not before
Next steps	What happens after this project
Project documentation archive	Links to the proposal, charter, plan, evaluation findings and other artifacts

The template supplies guiding questions under each section to push for enough detail, with the invitation to go further still. The purpose throughout is to compile and archive the most important aspects of the project.

Activity: complete the closeout report

The template arrived with the performance baseline table already filled from the project record, and with the narrative sections empty. The planned against actual comparison is the heart of it:

Baseline	Planned	Actual	Note
Schedule	Launch on 23 April	Launched on 23 April	Hit the intended day, but tasks had to be accelerated because of earlier delays
Cost: training materials and fees	10,000 dollars	7,486 dollars	Well under
Cost: hardware and software across locations	3,500 dollars	3,600 dollars annually	Marginally over
Cost: maintenance and IT fees	5,000 dollars	0 dollars	Included with the hardware order subscription
Cost: website and menu redesign	5,000 dollars	4,250 dollars	Under
Cost: other customisation	550 dollars	578 dollars	Marginally over
Scope	Install tablets at two locations, launch at the start of Q2, create a staff training plan	Tablets installed by an electrician at two locations, menus and coupons and branding loaded, integrated with the POS system, vendor timing renegotiated, training plan created, waitstaff expectations managed, back and front of house trained, maintenance and locking system created, customer satisfaction surveying implemented	The number of moving pieces was badly underestimated

Overall the budget was very nearly matched. The scope row is the instructive one: three planned lines expanded into roughly a dozen delivered lines, which is the discrepancy the notes column exists for.

The sections I completed described the pilot and rollout across the bar sections of the North and Downtown locations, with the aim of speeding up service, increasing product mix and generating operational data in support of the company’s growth and expansion OKRs. The methodology recorded was a hybrid: a traditional Waterfall life cycle for initiation, planning and closeout, with execution layering in an iterative test, feedback and adjust loop built from the friends and family pilot, the customer survey and the team retrospective. Key accomplishments repeated the goals-against-results table above. The documentation archive listed the project proposal, the charter, the project plan, the test launch findings presentation, the stakeholder analysis and the retrospective review.

The impact report and the executive summary

Impact reporting sits next to the closeout report and answers a different question for a different audience: what value did this add?

Closeout report

Audience - future project managers, and anyone interested in the details
Form - a detailed document
Purpose - a blueprint of what was done, how, and what was delivered
Content - summary, methodology, results, lessons learned, next steps, documentation archive
Tone - complete and evaluative, including quality, budget and schedule performance

Impact report

Audience - senior stakeholders and project sponsors who were not in the day-to-day
Form - usually a presentation guided by a deck
Purpose - show the value that the project added
Content - executive summary, results, what worked, next steps
Tone - a highlight reel, told with storytelling, data and visualisations

Why report impact at all

Improve the service

Analysing the results is what lets you adapt and improve what you offer

Motivate people

Celebrating achievements motivates both staff and senior stakeholders

Build credibility

Trust with supporters, sponsors, funders and everyone who benefits from the project

Spread the learning

Lessons shared with similar organisations, not kept inside one team

The closing reading adds the delivery advice: invite key stakeholders and senior leadership to the presentation, and amplify the outcome beyond that room by taking it to a company all-hands, a newsletter, or a meeting with another team that could use the lessons.

The executive summary

The test to apply: if an executive had time to read nothing but this, would they understand the project highlights? It should answer how effectively the project was delivered and what was learned from it, while being neither overloaded with detail nor so general as to be vague.

Two pieces of practical advice. First, review the SMART goals, the business case and the project charter before writing, because they point at the aspects that matter most and are usually tied to the key accomplishments. Second, write the executive summary last: draft the results, what worked and next steps slides first, in detail and with graphs and images, and the highlights become easy to lift out.

Three elements belong in it:

Element	The question it answers
Project vision	What was the purpose, and what need is the project fulfilling?
Key accomplishments	Which activities, tasks and milestones produced the success? What are the main highlights, what value was added, did profitability improve?
Lessons learned	What could be improved, and how will future processes change for the better?

The savings app example

The video builds a summary for an imaginary app that automatically moves money from a user’s checking account into a designated savings account twice a month, with the amount set by an algorithm using the checking balance at the time of withdrawal plus other variables such as deposit frequency.

Vision - help users get ahead financially through an algorithm-based automatic deposit system that pulls money into savings.
Key accomplishments - in the run-up to launch, 1,000 beta users saved over 300,000 dollars in six months, which proved the use case and the need.
Financial highlight - at 3 dollars per user per month, 1,000 users over six months netted 18,000 dollars.
Lessons learned - beta testers mainly wanted more frequent updates about when their money was being transferred, so that goes into the update.

Activity: write the impact report executive summary

The template arrived as a deck with everything except the summary already built, so that the shape of a typical impact report was visible before writing.

Slide	Content supplied
Title	Sauce and Spoon tablet rollout impact report
Executive summary	Blank, the task
Customer satisfaction: pilot	Pie chart of the post-pilot survey, 72 percent rating their tablet experience 4 or 5 out of 5
Customer satisfaction: launch	Pie chart of the post-launch survey, 86 percent rating 4 or 5, described in the deck as a 14 percent increase
Revenue	Revenue chart marked with the 23 April launch, July running up to 20 percent above April
What worked: key accomplishments	Four themes, each with two supporting lines: decreased table turn time, decreased food waste, increased customer satisfaction, increased sales
Next steps: looking forward	A table of initiative, action and date
Appendix	A link to all resources

The next steps table on that slide names three initiatives:

Initiative	Action	Date
Roll tablets out to more locations	Create a new project plan for installation at the new locations	Q2
Keep tracking customer experience and satisfaction	Continue surveying and gathering data by various means	Ongoing
Expand tablet features	Investigate additions such as social media integration, reservations and video	Q4

The summary I wrote follows the three-element structure: the vision of speeding up service, lifting average check value and modernising the guest experience across two pilot locations in support of the growth and expansion OKRs; two accomplishments, the satisfaction rise from 72 to 86 percent after the post-pilot fixes and the steady revenue climb with July around 20 percent above April, alongside the turn time, food waste and guest count results; two lessons, that the original tablet interface was too complex and needed earlier usability testing with more guests, and that cross-functional issues such as order accuracy needed joint fixes rather than tickets assigned owner by owner; and two next steps, the rollout to the remaining locations under Molly Edwards and continued work towards the 98 percent order accuracy target.

Celebrating the team

The last item on the closing checklist is to formally disband and thank the team, and the reading treats celebration as a real project management task rather than a nicety. Celebrations help a team feel recognised and rewarded for the work, and the form should suit the project and the company.

Publicise the successful outcome inside the companyRequest a speaking slot at a team or company all-hands to spotlight the project and the teamOrganise a celebration event for the project teamRecognise individual contributions through awards or superlativesUse the employee recognition programmes your organisation already runs

Documenting and organising the project’s components serves the same end from the other direction: it provides visibility and accountability, and project team members and senior stakeholders reference and contribute to project documents throughout the work, not only at the end.

The personal closing report

The final activity applies the same closing discipline to the learner rather than the project. The course calls it personal closing reporting: reflecting on completing the certificate exactly as you would reflect on a delivered project, using the retrospective and closeout habits built through the programme.

What the video asks for

List your key accomplishments. Look back to the start of the programme: what challenges did you overcome? Concepts you doubted you would ever understand and then did. Difficulties in your personal life you worked around. Fitting the course in alongside a full-time job counts as a major win.
Reflect on lessons learned. A busy week where a lesson got less attention than it deserved. Discovering which parts you enjoyed, such as stakeholder management, and which you enjoyed less, such as budgeting and procurement.
Decide next steps for the career. Contacting recruiting companies, asking a current manager for more responsibility, refreshing a resume, setting a target of applying to a number of project management jobs per week.
Put the goals on a timeline as if they were part of a project you were managing, because project management applies to everyday life as much as to work.
Write your own executive summary last: your experience of the programme as a whole, your successes, and how you plan to advance in project management.

The template

Section	What it holds
Executive summary	The programme experience as a whole, written to feel inspiring rather than dutiful
Key accomplishments	Challenges overcome and wins worth noting, including small ones such as a strong quiz score or applying a concept to something outside work
Lessons learned	What you would do differently, and what you discovered you like and dislike
Next steps	Concrete career moves
Goals	Four timeframes: 1 month, 6 months, 1 year and 5 years

The framing at the end is that the report is a project artifact to keep and look back on, and that finishing the certificate deserves the same treatment you would give a team at the end of a project: celebrate the successes, then keep growing and improving.

Where the certificate ends

The closing video walks the whole capstone back through the project life cycle, which doubles as a map of the four weeks.

Initiationproject charter, project goals and deliverables, stakeholder analysis to prepare for negotiation

Planningdetermining the tasks that achieve the goals, team brainstorms so nothing is missed, techniques for accurate time estimates

Executionexecuting tasks, quality management, setting quality standards and measuring quality with user surveys

Closingconnecting problems to project goals through OKRs, the closeout report, impact reporting and the executive summary

The capstone in one line: one project taken end to end, with the documentation produced at each stage becoming a portfolio.

The stated payoff of finishing is not only the knowledge but the portfolio of work produced along the way, which is showable to potential employers.

Revision summary

One-minute recap

Escalating a problem: most problems stay in the team; occasionally one goes up to a senior stakeholder with a proposed solution. Synthesise from emails, notes, presentations and documents into a coherent summary, because stakeholders should not have to read several documents to understand an issue. Test: how can I communicate a decision in a way that makes it easy for them to decide? Example: tasks are overdue because of supplier issues, so hire a second supplier or push the launch date. The stakeholder can then agree, disagree, or propose their own.
Chris, program manager on Google Search: problem solving is the job. Problems are scope, budget, people or timeline. Identify, build a framework, propose, get buy-in. Always debug the root cause, because the symptom is usually a red herring. Charters and trackers are mechanisms, not the job. Build the skill on hobbies and side projects.
OKRs: organisation-wide goal setting pairing a goal with a metric. Objective is what to achieve, key result is how success is measured. Example: prioritise customer needs, measured by addressing review feedback within 24 hours. They test whether a project deserves to exist, and they are how a problem earns senior attention.
Email best practices: lead with organisational impact in the first two sentences, write a subject line stating topic and required action (urgent, please review, decision needed), keep the body to the problem plus the OKR impact plus the decision needed, attach what they need, proofread.
Laura, executive productivity advisor: keep it concise for executives, research their preferred style in advance, tailor per stakeholder, prepare answers to the five likely questions in an appendix, always bring proposed solutions, open with a TLDR, use bullets and bolding, restate the ask and the deadline at the end.
Why closing matters: a thorough close assures that all work is complete, all agreed processes are executed, and everyone formally recognises the project is done. Checklist: close procurement administratively, run a formal closing process, present an impact report, document stakeholder acceptance, disband and thank the team.
Retrospective tips: safe space, model the behaviour, ask what to start, stop and continue instead of what went wrong, and remind the team of the milestones reached.
Closeout report: written by project managers for project managers, a blueprint of what was done, how and what was delivered, evaluating quality, budget and schedule. Sections: summary, methodology, performance baseline, key accomplishments, lessons learned, next steps, documentation archive. The performance baseline compares planned against actual schedule, cost and scope with a notes column. Compiling every link in one place is good project hygiene. It should stand alone as a work sample.
Impact report: for senior stakeholders and sponsors not in the day-to-day, usually a deck. Structure: executive summary, results, what worked, next steps. Report impact to improve the service, motivate people, build credibility and share lessons, then amplify it beyond the presentation.
Executive summary: a few sentences to a paragraph covering project vision, key accomplishments and lessons learned. Write it last, after the rest of the deck. Check it against SMART goals, the business case and the charter.
Sauce and Spoon outcome: after post-pilot fixes to navigation, waitstaff pacing, payment messaging and a pre-service tablet checklist, the pilot hit its goals: check total up from 65 to 75 dollars, turn time down 30 minutes, guest count up 10 percent overall and 20 percent Downtown, food waste down 25 percent, appetiser sales up 15 percent, checkout at one minute or less, technical issues under 5 percent weekly. Order accuracy stayed short of 98 percent. Launched on 23 April as planned, roughly on budget, with scope far larger than planned. Handover went to Molly Edwards for the next rollouts.
Personal closing report: the same closing technique applied to your own progress. Template sections are executive summary, key accomplishments, lessons learned, next steps, and goals at 1 month, 6 months, 1 year and 5 years. Keep it as a personal project artifact.

Next: AI for project management → - where generative AI actually helps a project manager.