Capstone 3 - Quality and Evaluation
Google Project Management Certificate · Course 6: Applying Project Management in the Real World
Weeks 1 and 2 produced the two documents that define the Sauce and Spoon tablet pilot: a charter with SMART goals, and a project plan with tasks, milestones and time estimates. Week 3 puts them into action. The tablets are wired into the point-of-sale system at the Downtown and North locations, the staff have been trained, and 50 friends-and-family guests have eaten a meal ordering and paying on a tablet. The question for this week is no longer what will we build, but did what we built actually work.
Course 4 already taught quality management and retrospectives as concepts. This week is deliberately thin on new theory and heavy on application: it reviews the vocabulary in a couple of minutes, then spends the rest of the module walking a single real test launch through the whole evaluation chain. Quality standards become evaluation questions, evaluation questions become indicators, indicators become survey questions, survey answers become findings, and findings become recommendations that a stakeholder can act on. The chain matters more than any one link, because a survey question written without an evaluation question behind it produces data nobody can use.
The module ends with a retrospective, and that is where the capstone adds the most. Course 4 said retrospectives should be blameless and participatory. This week shows what to actually do when the room goes quiet, when the team blames the vendor, or when one person turns the meeting sour.
Moving into execution
Section titled “Moving into execution”Execution is where the plan gets put into action, and the phase reading, compiled from dozens of Google project managers, gives four pieces of guidance for it.
Ask people how they want to be communicated with
Section titled “Ask people how they want to be communicated with”Progress has to be communicated consistently and coherently so everyone knows the current state, what to focus on and what happens next. Rather than guessing, ask each stakeholder and team member their preference:
Where quality standards come from
Section titled “Where quality standards come from”The reading names three sources, the same three the videos use:
- Project documents such as the business case and project charter, which already state goals, scope, budget and the details that make the project acceptable to stakeholders.
- Conversations with experts and stakeholders, especially the people funding the project, to understand their own view of quality.
- Online research into industry standards.
Quality assurance in the phase
Section titled “Quality assurance in the phase”Schedule regular quality assurance audits to confirm work is going to plan and the right procedures are being followed. Regular check-ins and reporting to stakeholders build their confidence, and yours.
Phased launches
Section titled “Phased launches”A phased launch puts part of the project in front of real users before the end goal is reached, to collect data and feedback that improve the final result. The reading contrasts two ways of launching before you launch:
| Minimum viable product | Beta | |
|---|---|---|
| What it is | The bare minimum version that still solves a customer problem | A real product, not an experiment, with fewer features than the full launch |
| Purpose | Validate the idea by gathering the most customer data for the least effort | Work out which features to add |
| Question it answers | Do people want this? | How can we build it better? |
The Sauce and Spoon test launch is a phased launch of this kind: the bar sections of two locations, 50 invited guests, one service.
Choosing Waterfall or Agile
Section titled “Choosing Waterfall or Agile”The reading closes by restating the approach choice, since execution style follows from it.
- Phases are clearly defined and run sequentially, one at a time
- Some tasks must finish before others can begin
- Changes are very expensive once the project has started
- Customer feedback arrives faster than in a traditional approach
- Work processes are streamlined without cutting quality or value
- Waste is reduced proactively and resources conserved
- The team can respond quickly to changing business or technology factors
- Trust, support and motivation grow, and decision-making is pushed into the team
A short Scrum glossary follows for reference: Product Backlog, Sprint, Daily Scrum, Development Team, Product Owner and Scrum Master, all as defined in Course 5.
Why quality matters
Section titled “Why quality matters”Quality is defined twice in the week, once in the videos and once in the reading, and the two definitions agree. Quality means delivering what you said you would, doing it as efficiently as you can, and meeting or exceeding the customer’s needs and expectations. Finishing on time and under budget is not the same thing: a project can land on schedule and still fail its stakeholders.
Because of that, quality is tracked across the whole life cycle rather than checked at the end. A project cannot simply be launched on the assumption that everything will be fine.
The three benefits
Section titled “The three benefits”The vocabulary, in one pass
Section titled “The vocabulary, in one pass”| Term | What it means |
|---|---|
| Quality planning | The process the project manager or team establishes and follows to identify exactly which quality standards are relevant to the project as a whole, and how to satisfy them |
| Quality standards | The requirements, specifications or guidelines used to ensure materials, products, processes and services are fit for achieving the desired outcome |
| Quality assurance (QA) | A review process that evaluates whether the project is moving towards delivering a high-quality service or product |
| Quality control (QC) | The techniques used to keep quality standards maintained once a problem has been identified |
| Quality management plan | The overarching document holding everything needed to manage quality across the life cycle: the policies, processes and criteria for project quality, plus the roles and responsibilities for carrying them out |
Two placements are worth remembering, because the week uses them as hinges. Surveys are a form of quality assurance, alongside beta testing and internal checklists. Retrospectives are a form of quality control, because they adjust and improve processes once something has been found to be wrong.
For Sauce and Spoon the quality management plan is built from three things: quality standards, evaluation questions and feedback surveys.
Defining measurable quality standards
Section titled “Defining measurable quality standards”Quality is measured by setting standards for the individual parts of a project: major tasks, milestones and deliverables. If a part is failing its agreed standard, that is the signal to adjust the project plan.
The video works the idea through the staff training deliverable. How would you know the training had been fulfilled successfully? The questions that produce the answer are the start of the standards list:
- What does the staff need to be able to do or demonstrate at the end of the training?
- Does each staff group need training on the same things?
- Will management have different requirements from front of house and back of house?
- Does the training need to fit a specific time frame, budget or geographic location to count as successful?
Established categories exist in most industries and are a useful prompt: functionality, design and safety (the examples given for software and construction), plus ease of use, productivity, effectiveness and customer satisfaction.
Objective and measurable, or it is not a standard
Section titled “Objective and measurable, or it is not a standard”This is the point the week hammers. Stakeholders tend to name a category rather than a number. When someone says the tablets should be easy to use, the project manager’s job is to ask what a sign of that would be. The answers turn into standards: it should not take longer than 20 seconds to place an order, or returning customers report that the tablet is faster than ordering with a server.
The prompting questions the video suggests:
| If the standard is about | Ask |
|---|---|
| Productivity and effectiveness | Should the tablets change how front of house staff work? Does it make them faster, or let them serve more tables at once? |
| Customer satisfaction | How should the tablets ideally change the customer’s experience? What would you want a customer to do or say as a result of using one? |
Even with documents, experts and research to draw on, critical thinking is still needed to pick the right standards and adjust them to the project.
The weekly check-in: turning a wish into criteria
Section titled “The weekly check-in: turning a wish into criteria”The worked example is a check-in between Peta, the project manager, and Deanna, the Director of Operations, who wants to tell Omar how the project will meet the company’s commitment to customer satisfaction. Deanna opens with an assumption rather than a standard: since service delays have produced negative reviews, customers would be satisfied by a faster, more efficient experience and by orders made correctly. Peta accepts the direction and immediately asks how each half would be measured. The conversation is essentially five rounds of that same question.
-
How do we measure a faster experience? Deanna proposes average ticket time, the gap between an order being placed and it reaching the table. From her experience, a good average is 8 minutes for appetizers and 12 to 15 minutes for entrees. It ties to the existing goal of cutting average table turn time by 30 minutes.
-
What else counts as faster? Peta notes guests can now run their cards at the table, so checkout is a candidate. Deanna wants it to mirror the online delivery checkout customers already like. The criterion becomes a checkout time of one minute or less, with the process seamless and easy to navigate.
-
What would undo all of it? Tablets that do not work. Peta pulls a standard straight out of the charter: under 5 percent of tablet users reporting technical issues each week.
-
What about incorrect orders? Peta proposes 98 percent order accuracy, reasoning that guests placing their own orders can confirm the ticket before it goes to the kitchen, so accuracy should rise once the hardware behaves.
-
Anything else before Omar sees it? Deanna adds an average lobby wait of ten minutes or less before guests are seated, which Peta accepts because wait times should fall as table turn time falls, making the specific impact worth measuring.
The customer satisfaction standards
Section titled “The customer satisfaction standards”| Standard | Measure |
|---|---|
| Faster service | Average ticket time of 8 minutes for appetizers, 12 to 15 minutes for entrees |
| Quick checkout | One minute or less, and easy to navigate |
| Reliable tablets | Under 5 percent of tablet users report a technical issue each week |
| Order accuracy | 98 percent of orders delivered correctly |
| Shorter lobby wait | Average of ten minutes or less from door to seated |
Deanna closes by asking for the rest of the project’s standards in time for the next check-in, which is the signal that customer satisfaction is one deliverable’s worth of a much longer list.
Activity: quality standards
Section titled “Activity: quality standards”The first activity asked me to read the project documentation and this check-in transcript, and to consolidate the customer satisfaction standards into the quality management plan. The structure is simply a named aspect of the project with its list of objective, measurable criteria underneath, which is the five-row table above. The graded checkpoint is whether each criterion carries a number or a threshold rather than an adjective.
Evaluation questions
Section titled “Evaluation questions”With the tablets installed, integrated with the point-of-sale system and the staff trained, the project reaches its testing milestone and the standards have to be measured. That measurement is evaluation.
Evaluation is a form of research designed to promote learning and inform decisions. It also provides accountability, and it shows how far the project has met its objectives. The three things it lets you do:
It also catches unintended problems the project itself creates for the organisation, the team or anyone else. The example given: if tablets are installed while the restaurant is open, the installation itself ruins the dining experience, so the timing of installation is an evaluation matter too.
Start with the why
Section titled “Start with the why”Before writing questions, articulate why you are evaluating, because the why shapes the questions. Narrow it down by reviewing the project goals and the organisational goals, and asking how the aspect being evaluated connects to them. Peta’s why at this milestone is judging the quality and performance of the tablets, and identifying ways to improve the training process, because her evaluation will inform the later phases, including the rollout to two more locations.
Two categories of question
Section titled “Two categories of question”| Questions that help you improve | Questions that measure and compare |
|---|---|
| How can we improve? | What were the results? |
| What is working and what is not working? | Were there unintended outcomes? |
| Which goals are being met? | What were the costs and benefits? |
| Who is benefiting? | Are there any lessons to be learned? |
| What are the most common participant reactions? | Should we continue? |
The second category is what you use to judge whether to proceed with the process or with the project itself. The example question carried through the rest of the module is: to what extent do tablets improve the staff’s work performance?
What makes an evaluation question effective
Section titled “What makes an evaluation question effective”- It addresses stakeholder or user values, interests and concerns.
- It relates to the purpose of the project and the purpose of the evaluation.
- It is worth answering, and important for the project and beyond.
- It is practical and feasible to answer with the resources available.
Activity: evaluation questions
Section titled “Activity: evaluation questions”The second activity added evaluation questions to the quality management plan, one or more per quality standard. The plan’s structure gains a column: the aspect being evaluated, the standard, and the evaluation question that tests it. The completed version pairs each of the five customer satisfaction criteria with a question of the improve or the measure-and-compare type, and keeps the four effectiveness criteria above as the self-check.
Evaluation indicators
Section titled “Evaluation indicators”An evaluation question on its own does not tell you what to collect. The indicator does.
The relationship mirrors the one between standards and deliverables. A quality standard adds specificity to a deliverable; an indicator adds specificity to an evaluation question by fixing the type of response you are aiming for. The word indicate means to point out or show, and that is the job: indicators point the way to the answer.
Indicators can also be visible signs rather than figures: test scores, attendance rates, observed behaviour. The video’s examples for the tablet pilot are pointed. Fewer staff congregating by the beverage station or arriving late indicates increased productivity. Over 90 percent staff compliance with the tablet ordering process indicates order placement accuracy.
Activity: evaluation indicators
Section titled “Activity: evaluation indicators”The third activity added an indicator to each evaluation question already in the quality management plan. The template’s column simply asks what data would show the answer, so the completed rows read as question, then the countable or observable thing that answers it. The test is whether the indicator names something a survey or an operational report could actually produce.
Surveys
Section titled “Surveys”Surveys are one of several data-collection methods and a popular one in project management. Each respondent answers a set of clearly defined questions, and the collected data is analysed to give concrete examples of the indicators. Peta chose customer surveys as the way to answer this project’s evaluation questions.
Survey question or evaluation question
Section titled “Survey question or evaluation question”The distinction is easy to blur and the week is firm on it.
| Evaluation question | Survey question | |
|---|---|---|
| Asks about | The outcomes, impact or effectiveness of the project | One specific data point |
| Audience | The project manager and stakeholders, internally | The respondent |
| Relationship | The thing you want to know | A more direct interpretation of it, designed to get data |
Worked through: the evaluation question asks to what extent tablets increase work performance. One indicator is how much side work staff complete during a shift. The corresponding survey questions become: are the tablets easy to use; was there enough time during training to practise and ask questions; on average how many side work tasks can you complete during a shift; since using the tablets, how often have you sent back an incorrect order.
Question types
Section titled “Question types”A scaled question differs from multiple choice because the options form a scale rather than a list of alternatives.
Writing questions that work
Section titled “Writing questions that work”- Ask what you mean to ask. Each question should be specific and address only one measurable aspect.
- Do not assume things about respondents. Not everyone knows or enjoys the same things or has had similar life experiences, so the answer options must let people answer accurately about their own experience.
- Do not over-explain. Too much detail in the question steers the respondent towards a particular answer and quietly creates bias.
The development process in order: develop the evaluation questions, define the indicators, then decide what type of survey to design and which questions to ask.
Activity: survey questions
Section titled “Activity: survey questions”The fourth activity took one Sauce and Spoon evaluation question and wrote the survey questions that would answer it, adding them to the quality management plan. The template gives the evaluation question and its indicator and leaves the survey questions blank; the completed version has a mix of question types, with at least one scaled question so the result can be tracked as a percentage, and one open-ended follow-up so the reason behind a poor score is captured.
Reading the results
Section titled “Reading the results”The surveys were administered and the data came back. 50 test-launch guests dined as they normally would, ordering and paying on the tablet, and each received a digital survey at the end of the visit. The results are given as counts and percentages, with verbatim comments attached to several questions.
The headline numbers
Section titled “The headline numbers”| Question | Result |
|---|---|
| Overall rating of the tablet (scale of 1 to 5) | 72 percent rated it 4 Good or 5 Great: 40 percent Good, 32 percent Great. 4 percent Lacking, 10 percent Mediocre, 14 percent Neutral |
| Waiter instruction on how to use the tablet | 76 percent said Very well, 14 percent OK, 10 percent Not well |
| Ease of tablet navigation | Only 48 percent rated it Fairly or Very easy. 30 percent Neutral, 18 percent Slightly difficult, 4 percent Difficult |
| Ease of ordering from the menu | Only 46 percent rated it Fairly or Very easy |
| Checkout was quick, easy and secure | 82 percent True, 18 percent False |
| Confidence submitting payment on a tablet | 66 percent rated 4 or 5 |
| Newsletter sign-up on the tablet | 78 percent Yes |
| Birthday Club sign-up | 16 percent Yes |
| Tablet versus a traditional waiter experience | 40 percent preferred the tablet exclusively, 30 percent wanted a mix, 20 percent had no preference, 10 percent disliked the tablets |
| Multiple orders placed during the meal | 36 percent Yes |
Every guest ordered dinner, 82 percent ordered appetizers, 70 percent dessert and 56 percent drinks, which mainly confirms the sample ate a full meal rather than a snack.
Where the pilot missed its targets
Section titled “Where the pilot missed its targets”This is the part the findings have to be built on, because three of the five customer satisfaction standards were not met.
| Standard | What the survey showed | Verdict |
|---|---|---|
| 98 percent order accuracy | Only 72 percent said the kitchen prepared the order correctly. 28 percent said no | Missed, badly |
| Under 5 percent reporting technical issues | 12 percent reported an issue: frozen screens, glitches, one fixed by a waiter reboot | Missed |
| Lobby wait of ten minutes or less | 54 percent waited more than 15 minutes. Only 26 percent were seated within 10 minutes | Missed |
| Checkout of one minute or less | 82 percent found checkout quick, easy and secure | Met on the guest’s own judgement |
| Ticket time of 8 minutes for appetizers, 12 to 15 for entrees | The survey bucket is food order time overall: 56 percent within 20 minutes, 30 percent 21 to 30 minutes, 12 percent 31 to 40 minutes, one guest 41 to 50 | Not directly measurable from this instrument |
The verbatim comments are what make the numbers actionable, and they are strikingly specific. The order accuracy failures cluster on modifiers and substitutions: parsley or cheese not left off, a requested substitution not made, mashed potatoes instead of fries, an overcooked entree, a wrong entree entirely. The checkout failures cluster on cash: guests who only had cash did not realise they could not use it and needed the waiter anyway, plus one frozen tablet and one wish to pay by phone. The free-text comments at the end are mostly warm (the tablets were fun, dinner felt faster, the Sauce and Spoon video on the tablet was good) with two useful asks: keep the option of choosing a waiter, and give guests time to get used to the devices.
Synthesising and presenting the findings
Section titled “Synthesising and presenting the findings”Analysing data and reporting it are two different jobs, and the week is blunt about the gap.
Start with the audience
Section titled “Start with the audience”Think about what is most meaningful to them and how much time they have. Where the audience is a mix of roles, the same data may need presenting in more than one way, because different audiences want the information for different reasons.
- Benefits from a detailed report
- They need it to address the parts of the project they own
- Typically do not need, want or have time for a detailed analysis
- They want a summary of the most important information and its impact on their investment
The recommended sequence is to write the detailed evaluation report first, addressing the evaluation questions, then summarise it into whatever format suits the audience. Beyond the full report, two common styles:
| Style | What it is |
|---|---|
| Summary sheet | A one- or two-page write-up with only the most relevant information, like a flyer or snapshot of the findings |
| Slide-based presentation | Digital slides presenting the information visually |
Reporting data is not presenting an evaluation
Section titled “Reporting data is not presenting an evaluation”The example the video uses: suppose 36 percent of respondents reported a negative dining experience with the tablets. That number alone says nothing, because it could mean any of four different things.
Filtering and analysing the data is the most important part, because that is where you make sense of it for yourself and become familiar with the results, the respondents and what they mean for project quality. Two working tips: look for trends, patterns and anomalies, and share the process with teammates, taking turns saying what each of you thinks the data means, which both checks your own reading and surfaces things a single perspective misses. When you can explain the meaning in plain language, you have the basis of the presentation.
Tell the story
Section titled “Tell the story”Before building slides, think about what you want to achieve, the points you want to make, and the questions and concerns you need to answer. The structure the video recommends for this presentation:
-
Remind them of the goal. Open with the overall goal and purpose of the project, since the point is to show whether quality standards are being met.
-
Name the milestone being evaluated and how it was expected to contribute to the project goals.
-
Explain what the data revealed, without walking through every data point or survey question.
-
Call out the major issues the data revealed and summarise the rest. Where things went well, pick a few highlights and move on.
-
For the major failings, propose solutions or craft the specific questions you need answered.
Activity: the test launch findings presentation
Section titled “Activity: the test launch findings presentation”The fifth activity was to analyse the survey results and build the stakeholder slides. The template is a five-section skeleton with no content: Title, Summary, Overview, Findings, Next Steps. The exemplar shows the intended shape in five slides: a title naming the milestone and how it was reached; an evaluation slide stating the two questions (did we achieve our goals, were customers satisfied) and the method; a results slide carrying a single large number, the 72 percent who rated the experience 4 or 5; and then one slide per recommendation, each pairing a survey finding with a recommendation. The exemplar’s two are table turn time not decreasing, answered by working with the general managers on speeding up guest visits, and tablet malfunctions, answered by a process for checking tablets before service and swapping them out between guests.
My submitted deck follows that shape across six slides:
| Slide | What it carries |
|---|---|
| Title | The pilot name, that these are test-launch findings and next steps, and the author |
| Milestone reached | What was done, in five bullets, plus a one-line chain of how we got here: vendor selected, tablets installed and integrated, staff trained, test launch executed with 50 guests |
| What we set out to measure | The five customer satisfaction standards as targets, with the data source named as the exit survey |
| What guests liked | The four positives: 72 percent rated it Good or Great, 88 percent had no technical issue, 82 percent found checkout quick, 70 percent want tablets going forward either exclusively or mixed |
| Recommendation 1 | Close the order-accuracy gap. Data on one side (72 percent against the 98 percent target, verbatims about modifiers and substitutions), next steps on the other: a mandatory pre-submit confirmation screen listing every modifier, modifiers printed bold on the kitchen ticket, a kitchen huddle on the new ticket format, and a weekly accuracy metric with a go or no-go on the target before scaling |
| Recommendation 2 | Improve navigation and add a cash-pay path. Data: 48 percent found navigation easy, 46 percent for menu ordering, 18 percent could not check out on the tablet, 54 percent waited over 15 minutes. Next steps: simplify the navigation flow with the vendor, add a pay-with-waiter option plus signage, refresh front of house training on coaching first-time users, and add lobby wait monitoring with a look at peak-hour staffing |
The pattern to take away from both versions: one recommendation per slide, the finding and the response side by side, and the positives compressed into a single slide so the meeting time goes on the problems.
A separate exemplar shows the same evaluation written as an executive summary, a single paragraph pair covering what was installed and when it went live, how feedback was gathered, what was changed as a result, and then the outcome figures after the official launch: average daily guest count up 10 percent, wait time down 30 minutes, checkout cut to one minute, food waste down 50 percent, sales up more than 20 percent, and customer satisfaction up from 72 percent after the pilot to 86 percent. It closes by noting there is still room to improve. That is the same story at a tenth of the length, which is the point of writing the detailed version first.
The retrospective
Section titled “The retrospective”Retrospectives often happen at the end of a project, but they are a process improvement tool for the whole life cycle and are especially useful after a milestone. Right after implementing the tablets and testing them with the pilot guests is exactly such a moment: celebrate what has gone well and find the improvements before the next milestone.
Three purposes
Section titled “Three purposes”Because it is a specific type of meeting it needs an agenda to guide the discussion, organise the meeting and document what is learned. The project manager’s job is to manage the tone, make sure every team member feels included, and capture the details that go into the retrospective document.
A Google view: psychological safety
Section titled “A Google view: psychological safety”Dana, a site reliability manager at Google, adds the practitioner’s angle. Her team runs retrospectives at the end of every project to look at what went well, what went poorly and where they got lucky, so the lessons carry into the next project. If a decision is needed mid-project, they collect the same data and run one early.
Her named failure mode is people not speaking up, which she sees often at Sprint retrospectives where everyone sits quietly and says everything is fine. She gives two causes and is far more worried about the second:
- They genuinely do not care much about improving. It is fine, they tolerate it, that is how it is.
- Lack of psychological safety: they do not feel they can say what they think and have it received well by the people in the room.
Her framing of why the venue matters: a team with a safe space to raise these topics knows it has a stake in what happens next, because a great deal really can change in how projects are managed, how communication happens, and which projects get picked during planning. Retrospectives must be positive and blameless, and the goal is continuous improvement of ourselves, the team and the processes.
Three hard retrospectives
Section titled “Three hard retrospectives”The capstone’s real contribution is the next three videos, each on a way a retrospective goes wrong and what to do about it. The habit underneath all three is the same: ask yourself the diagnostic question before the meeting, not during it.
Lack of participation
Section titled “Lack of participation”The question to ask first: does your team seem likely to contribute to the discussion? If the answer might be no, low participation will block the team from making meaningful process improvements, because a retrospective draws attention to challenges as well as successes and a team that is uncomfortable voicing challenges will simply not speak.
| Technique | How it works in practice |
|---|---|
| Create a safe environment | Open with a policy of what is said here stays here, what is learned here leaves. Remind the team the meeting is free of stakeholders and customers, so problems can be named directly |
| Model the participation you want | Prepare a few tasks or processes you know you handled badly and say them out loud. The example given is a paperwork error that delayed tablet delivery by two business days: admit it, then say how you will avoid it. Admitting your own mistakes makes it acceptable for everyone else |
| Pose a group question, ask for individual responses | Ask everyone to think of one success and one challenge, then go round the room and ask each person to share |
| Rephrase a question that is not landing | If what went well and what went wrong produce nothing, try what should we start, stop and continue |
| Review the project timeline | If people only raise very recent items, walk the timeline to refresh memories and pull discussion back across the whole project |
Encouraging accountability without blame
Section titled “Encouraging accountability without blame”Accountability means encouraging the team to think holistically about mistakes and challenges and to identify future solutions, not assigning fault to individuals. It also encourages ownership, and a team member who feels ownership over part of the project tends to be more motivated to keep that part meeting its quality standards.
| Technique | How it works in practice |
|---|---|
| Come prepared with specific challenges | Especially useful if the team only wants to discuss successes. The example: the kitchen managers fed back that they felt left out of decisions made by the general managers. Share that with the group and ask them to help work out what caused it |
| Turn complaints into SMART action items | Action items can be specific, measurable, attainable, relevant and time-bound just as goals are. Same example: invite the kitchen manager to the weekly staff check-in, add a five-minute agenda slot for them to raise issues and get feedback, and plan a check in two months on whether they feel more included |
| Push the team to identify its own role | Teams gravitate to challenges they had no control over, such as a late supplier delivery. Walk the series of events and find the moment the team missed an opportunity to spot and address the problem. Had someone owned the tablet vendor relationship early and set up weekly check-in calls, the restaurants would have had the foresight to plan around the missed delivery |
| Keep criticism constructive | Constructive criticism is respectful feedback intended to help the recipient improve the work. When it slides into harsh or unhelpful, redirect: detach the challenge from any specific person in the room and steer towards process improvements the whole team can learn from |
Disagreement, negativity and tension
Section titled “Disagreement, negativity and tension”The question to ask first: is this conversation likely to feel stressful for the team? Sometimes the answer is yes. Retrospectives build trust, honesty and direct communication, but if the environment does not feel psychologically safe it is very easy for one to turn negative, and negativity makes it harder to hold a discussion that actually identifies solutions.
- Open by highlighting project successes
- Mention positive stakeholder feedback, or thank the team for reaching a major milestone
- Meeting props help: hand out an equal number of green and red index cards
- Successes on green, challenges on red. Handing out green cards nudges people to think of successes too
- Meet beforehand with anyone likely to bring a negative attitude
- Ask why: do they feel insecure about the value they add, or are they getting negative feedback on their work?
- Understanding the root suggests the fix, such as reassuring someone of their value
- A single negative voice can derail an otherwise productive discussion
- Ask members individually rather than the group: it gives everyone room, models solution-oriented thinking, and stops one person answering every question
- Call a break. A timeout de-escalates
No single technique fits every scenario, and how you address negativity depends on the situation.
The Sauce and Spoon retrospective
Section titled “The Sauce and Spoon retrospective”The worked example brings seven people into the room: Peta as project manager, Carter the executive chef, Gilly and Zane as general manager and kitchen manager at North, Alex and Larissa in the same two roles Downtown, and Seydou the restaurant consultant. Peta uses several of the techniques above without announcing them.
-
Frame the safe space first. Peta opens by thanking everyone, noting the official launch is one step closer, and saying explicitly that she wants everyone to feel they are in a safe space and to share whatever helps improve the process.
-
Open with a question that allows either answer. Does anyone want to start with something that went well, or something we could improve? Alex answers with a success, tablets installed and working Downtown.
-
Go round by name. Gilly is asked directly about North, and after confirming the same success she volunteers the first real problem: table turn time did not fall as much as wanted. Alex confirms the same pattern.
-
Route the problem to the people who can explain it. Rather than solving it in the room, Peta asks the kitchen for its perspective. Zane reports ticket flow was smooth and easy to track, but orders were still being sent back. Larissa confirms it, adds that there were fewer than before, and volunteers that the kitchen has already made operational changes off the back of the new ticket flow that they are happy with.
-
Acknowledge, then park. Peta names the sent-back orders as a priority for further analysis and offers a separate session on the kitchen improvements, which keeps the retrospective from turning into a working meeting.
-
Receive bad news well. Seydou prefaces the technical issues found during point-of-sale integration with an apology for the news. Peta treats it as good news because they were fixed quickly, and turns it into an action: update the process manual so the fix is easy to find next time. She then follows the thread, asking Seydou to check whether a technical issue is behind the ticket accuracy problem.
-
Model accountability on herself. Peta reports her own contributions, that weekly vendor calls kept dependencies clear and that the survey captured meaningful data, then names an internal failure: operational issues at the locations that nobody had planned for, which disrupted the team’s work. Her improvement is to understand each location’s history before planning starts on the next rollout.
-
Others follow. Seydou admits implementation ran longer than hoped because of unaccounted vacation time, and separately that the Birthday Club got few participants, with his own corrective work already under way. Zane asks for back of house capacity to be scaled before the main launch. Larissa raises the mutual lack of understanding between front and back of house, noting that sharing experiences would reduce the tendency to blame each other. Alex proposes redesigning waitstaff training, possibly splitting it in two so it covers daily service operations as well as the tablets.
The shape is worth noticing. The first two contributions are pure successes; the critical items only arrive once Peta has gone round by name and modelled admitting a miss herself. The heaviest items, cross-team understanding and training redesign, come last, from the people who spoke least early on.
Activity: the retrospective review
Section titled “Activity: the retrospective review”The final activity built the retrospective document from the survey results and this meeting. The template is a single sheet with five columns and nothing else:
| Column | What goes in it |
|---|---|
| Feedback From | The source of the item, such as customers or the project team |
| Type | Went well, or needs improvement |
| Description | The finding in one sentence |
| Evidence | The specific survey question and counts, or the named person in the retrospective who raised it |
| Actions | What will be done about it |
My completed version has twelve rows, split between customer feedback drawn from the survey and project team feedback drawn from the meeting.
| Source and type | Items recorded |
|---|---|
| Customers, went well | 72 percent rated the experience Good or Great; 82 percent found checkout quick, easy and secure; 78 percent opted in to the newsletter on the tablet |
| Customers, needs improvement | Order accuracy at 72 percent against the 98 percent target; only 48 percent found navigation easy; 54 percent waited more than 15 minutes for a table |
| Project team, went well | All tablets installed and working at both locations; tickets arriving at a good pace and easy to track; weekly vendor calls keeping dependencies clear |
| Project team, needs improvement | Table turn time barely moved; orders still being sent back; and a combined row for implementation running long on unaccounted vacation time, back of house not yet scaled, the front and back of house understanding gap, and waitstaff training needing a redesign |
The discipline the sheet enforces is the Evidence column. Every row has to cite either a survey question with its counts or a named person in the meeting, which stops the document drifting into impressions. The Actions column then has to be concrete enough to hand to someone: document the install steps in the vendor playbook, adopt weekly vendor calls as the standing cadence in the rollout runbook, add lobby wait time to the operational dashboard, run cross-team shadowing sessions, measure turn time against baseline over four weeks after launch.
Revision summary
Section titled “Revision summary”Next: Closing the project → - communicating problems, the closeout report and the impact report.