Execution 2 - Quality Management and Continuous Improvement

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

---

Execution is where the deliverable actually gets built, so it is also where the question is this any good? has to be answered out loud rather than assumed. This module covers quality management - the four linked concepts that turn a vague hope of a good product into something measurable - and improvement, both while the project runs and after it ends.

The through-line is that quality is not the team’s opinion. The triple constraint of time, scope and budget shapes it, since squeezing any one of the three makes quality suffer, but the verdict belongs to the customer. So half the module is about asking them: feedback surveys, user acceptance testing, and the soft skills that make those conversations honest.

The other half is about learning from what happened. Continuous improvement and process improvement keep the work getting better while it runs, and retrospectives capture the lessons at milestones and at the end, blamelessly, so they carry into the next project instead of evaporating.

Note

Where this sits: quality management runs through execution rather than at one point in it. Standards are agreed at the start and planning happens once, but assurance and control run continuously, and retrospectives loop the findings back into the process.

---

What quality actually means

There is a real difference between done and quality. Finishing every task on the plan is not the achievement; the deliverable has to meet the customer’s standard, not merely exist.

Note

Quality - fulfilling the outlined requirements for the deliverable and meeting or exceeding the customer’s needs and expectations.

Two things follow. Quality is judged from outside the team, so you need a way to learn what the customer expects and a way to check you are hitting it. And communication is the lever: the better a PM communicates with the team, the more likely the team is to produce high-quality deliverables. Delivering on that takes the core quality concepts plus a quality plan you actually oversee.

---

The four concepts of quality management

Quality standardsagree what good means

→

Quality planningdecide how to hit it

→

Quality assuranceaudit as you go

→

Quality controlinspect results, correct

The chain runs left to right, but QA and QC are not one-off phases: they span the life cycle and keep feeding back into the plan.

Quality standards

Note

Quality standards - the requirements, specifications or guidelines used to make sure a product, process or service is fit to achieve the desired outcome. Meeting them is what makes the result a success in the eyes of both the organisation and the customer.

Set them with your team and your customer at the very beginning, define them clearly enough that everyone knows exactly what they are, then check in periodically to confirm the requirements are still being met. Well-defined standards pay off directly in less rework and fewer schedule delays. They apply across all products and processes. Running example, Project Plant Pals at Office Green, a new service supplying desk-friendly plants to top clients:

Standard type	Plant Pals example
Reliability	Each planter arrives by the agreed time and in good condition, ready to sit on a desk; suppliers hold enough stock to meet demand on time
Usability	Planters cause no allergic reactions or illness and suit all people, and animals where relevant
Product	The supplier matches the brand look and feel, uses the specified materials, and delivers the item intact
Usability, applied to a process	The ordering website must be easy to navigate on a phone, a computer or a tablet

Quality planning

Note

Quality planning - establishing and running a process to identify which quality standards are actually relevant to the project as a whole, and how to satisfy them.

Four questions steer the discussion: what outcome do my customers want at the end of this project, what does quality look like to them, how can I meet their expectations, and how will I know whether the quality measures led to project success? This is where procedures get designed. If reliability is a standard, the planning measure is arranging with the plant provider to durability-test the planters before you commit to using them.

Quality assurance (QA)

Note

Quality assurance - a review process evaluating whether the project is heading towards delivering a high-quality product or service. Unlike standards and planning, QA spans the whole life cycle rather than sitting in one phase.

The quality plan should build in regular audits confirming the plan is being followed, plus regular check-ins and reporting that raise stakeholder confidence and your own. QA is how you make sure you and the client get the exact product that was contracted for. On Plant Pals it means inspecting planter options and sitting in on the durability testing; if the provider runs that testing themselves, you track their progress and check in regularly rather than assuming.

Quality control (QC)

Note

Quality control - monitoring project results and delivery to decide whether they meet the desired results, and applying corrective techniques when a problem is found or the quality plan is not being executed as intended.

On Plant Pals, QC is the final walk-through of the customer offices after delivery, checking for broken planters or plants damaged in transit and swapping them out. You would not do it for every customer forever, but doing it early catches issues you can improve on back at the office, which also gives the next project a better landing.

QA and QC side by side

	Quality assurance	Quality control
Question it answers	Are we on track to deliver quality?	Did the result actually meet the standard?
Timing	Continuous, across the whole life cycle	On results and deliverables, when a problem is identified
Posture	Preventive - stop defects before they occur	Detective and corrective - find defects after they happen, then fix them
Typical activity	Audits, check-ins, stakeholder reporting, overseeing testing	Inspection, walk-throughs, swapping out damaged items
Relationship	The broader review process	A subset of QA activities

Stick to the plan, check throughout with QA, correct as needed with QC, and the odds of a high-quality deliverable that satisfies organisational goals and exceeds customer expectations are high.

---

Talking to customers about quality

Communication starts before the project does and never stops. The Project Management Institute finds that most projects suffer a communication breakdown of some kind, even though project managers spend roughly 90 percent of their time on communication alone. Done well, strategic communication with a customer builds confidence that you are a trustworthy partner. Three soft skills carry it - negotiation, empathetic listening and trust building - and all three rest on one practice: asking open-ended questions and actively listening.

Those questions reveal the customer’s current state versus their desired state, and what would move them from one to the other. That is how you find where to make them feel secure, where to negotiate so both sides’ needs are met, and how to build the trust a partnership needs.

Set communication expectations rather than waiting to be asked. Promising weekly progress updates beats hoping the client comes to you with questions. Judgement decides what to escalate: if a designer quits and you replace them without the project skipping a beat, there is no need to hand the customer an extra worry. But when you genuinely cannot move forward without their input, raise it calmly and with empathy.

Negotiation in practice

Suppose the quality standards allowed for supplier error at two broken planters in every 50, and a customer receives a shipment with five broken. That triggers a negotiation: is five in 50 acceptable after all, or would the customer invest in a higher tier of sturdier planters? The sturdier option hits their budget, so are they comfortable with that, and does it force another trade-off? Throughout, the goal is customer satisfaction, so stay considerate of their feelings and limits - understand the frustration, address it, and find a solution good for both sides. Your own experience of good and bad customer service is a useful guide, since you already know what care feels like on the receiving end.

Feedback itself may arrive during the work or after completion, depending on what the project is for. An e-commerce launch wants feedback early so the shopping experience can be tuned; an on-demand cookie delivery service naturally delivers first, then asks how the cookies and the delivery felt. Either way, user feedback closes the gap between what the customer expected and what the project delivered.

---

Measuring customer satisfaction

The best way to learn what customers want is to ask them, but not by phoning each one individually. Two streamlined methods do the job.

Feedback surveys collect which features users like or dislike, which parts feel intuitive and which are harder to navigate. They can run as you design, before launch, to check people like and understand the product, or after launch, to make the experience more satisfying. The outcome is a decision: you are clear to launch, or you go back and iterate on a product already on the market.

User acceptance testing (UAT)

Note

User acceptance test (UAT) - a test confirming a product, service or process works for its users, meets the agreed requirements and delivers the expected results. It assesses the end-to-end experience and runs near the end of development, which is why it is sometimes called a beta test.

Its three objectives: show the thing behaves as expected in real-world scenarios, show it works as intended, and surface issues to address before project completion. Because UAT simulates real conditions, a feature that works in testing is far likelier to work at launch. It also answers questions nothing else will: do users recognise its purpose and uses, how do they interact with it, how long does that take, do they notice every feature, is it accessible to everyone? And it records how the experience feels - the emotions it evokes, the identity it conveys, the appeal it holds.

1. Welcome the users, thank them for taking part, then present the product, covering the testing guidelines and demonstrating how it works.

2. Run the test cases, walking the audience through critical user journeys - the sequence of steps a user follows to accomplish a task in your product.

3. Show something real. Give users a visual representation, mock-up or demo. For a construction project replacing every appliance in a home, that means 3D models, digital blueprints or material samples.

4. Focus on a call to action. Give a real-life scenario, then a scale question. For a dishwasher chosen to open quietly with little force: load the dishes, start the cycle, then rate from one to ten how much force opening and closing took.

5. Collect feedback on the overall experience throughout, and look for edge cases - rare outliers the original requirements never accounted for, at the extreme maximums and minimums of a parameter. An app allowing unlimited photo uploads assumed nobody would exceed a thousand in a session; what happens when someone uploads millions at once?

6. Recap the findings, identify bugs and issues, prioritise which get addressed first, then close the test once next steps are agreed.

UAT best practices, and the feedback that comes back

Practice	What it means
Write down acceptance criteria	Pre-established standards each item must meet - for a new employee handbook, that it is a digital PDF readable on mobile and desktop
Create test cases	A sequence of steps plus expected results, such as downloading that PDF on a phone and confirming it opens cleanly
Select users carefully	They must be the genuine end users of the product, service or process
Write scripts from user stories	A user story explains a feature informally from the end user’s view: as a new employee, I want to find the vacation policy and email it to my team
Tell users what to expect	Preparing them in advance means fewer questions, issues and delays on the day
Prepare the environment	Check credentials and access work before the session, not during it
Give a step-by-step plan	Clear instructions in a shared doc or sheet focus attention on the right places
Compile notes in one place	One document tracking every issue, including how severe users thought it was, which drives prioritisation
Triage bugs and issues	Track them and prioritise: critical problems (the handbook cannot be opened, downloaded or searched) outrank cosmetic ones (opinions on the cover art)
Manage change requests	Usually minor suggestions, still prioritised. Depending on type and volume, share the data with primary stakeholders and expect to adjust the timeline

Tip

The scheduling lesson: leave room in the plan for proper testing and issue resolution. UAT that finds problems you have no time left to fix has told you something useless.

---

Accessible feedback and testing

Collecting feedback is only fair if everyone can take part, so build accessibility into how you measure quality.

• Live interviews: offer accommodations in the invitation itself. You may be asked for live captioning or an interpreter; someone with anxiety or on the autism spectrum may want the questions in advance. What suits one person may not suit another, even with the same disability.
• On location: check the venue with an accessibility lens - an accessible path into the building and the room, and hallways clear of clutter that would block a wheelchair, a walker, or someone with a visual impairment.
• Surveys and tools: confirm the system is accessible. If unsure, ask its owner whether it complies with the latest Web Content Accessibility Guidelines (WCAG), and be ready to send questions and take answers another way.
• The product and the team: raise accessibility from the beginning, because leaving it to the final stages causes launch delays or a product part of the population cannot use. Make sure developers know the requirements from the start, connect them with experts if not, and include testers with various disabilities in usability testing - at minimum, test against the guidelines.

---

Customers and sponsors are different audiences

A customer is one kind of stakeholder, and it helps to sort stakeholders into buckets. Customers are usually the end users or the purchasers of a product. Sponsors fund the team that builds it, and they care about return on investment, so keep quantifying the return you are generating. Understanding what a customer needs is genuinely hard, and it is a skill built over time - it rests on empathy, putting yourself in their shoes and seeing the product through their eyes.

Caution

Sponsors carry a quiet fear of not getting what they paid for, so the frequency and the level of detail of your updates matter. Too much detail and they cannot see the forest for the trees; too little and they stop trusting what you tell them. Striking that balance is a core PM skill.

---

Continuous improvement and process improvement

Note

Continuous improvement - an ongoing effort to improve products or services, so the product keeps moving towards the best possible outcome.
Process improvement - identifying, analysing and improving existing processes to lift team performance, develop best practices, or optimise the customer experience.

Continuous improvement begins with recognising when processes and tasks need to be created, eliminated or improved; the PM then plans and implements the change to keep the project on track. In practice the two ideas differ in kind: process improvement is the concrete act of looking at data to make something more effective or more cost efficient, even something as small as how meeting notes get taken and circulated, while continuous improvement is a mentality of pushing to get better even when the product already looks fine. Once something is out in the world, people use it in ways nobody anticipated, so you set the ego down and keep solving what real usage reveals.

Testing a change with a control

Note

Control - an experiment or observation designed to minimise the effects of variables. A control group is a representative sample that stays unchanged, so any difference in the experimental group can be attributed to your change rather than something else. Controls eliminate alternative explanations for a result.

Observe a problem in the process

Form a hypothesis - an educated guess at the cause and the fix

Change one variable, hold the control group the same

Observe results again, confirm or try something else

Change exactly one thing at a time, or you will not know which change produced the result.

Worked example. Plant Pals demand is booming, and suppliers have streamlined packing into one box size for everything. Small plants get extra padding and arrive intact; large plants are squeezed in and, according to customer surveys, sometimes arrive damaged. The hypothesis: would more large plants arrive intact in bigger boxes, using the padding used for the small ones? So half the large plants keep shipping in the original boxes, the control group, and half ship in bigger boxes, with shape, thickness, box supplier and delivery addresses all identical. A new survey after delivery either confirms the hypothesis or sends you looking for a different cause.

Data-driven improvement frameworks

Controlled experiments are not the only route. The module names two data-driven improvement frameworks, DMAIC and PDCA, and the one it works through is PDCA.

Plan

→

Do

→

Check

→

Act

PDCA at Office Green: sales of one plant variety drop, so you feature that species at the top of the website with a small discount, check the effect, and act on what you find.

The change worked well enough to become a best practice: from then on, low-performing and overstocked varieties are featured at the top of the site. A one-off fix has become a repeatable process, and running it over and over is what drives continuous improvement.

---

Projects, programs and portfolios

Improvements do not stay inside one project, because a PM sits in a bigger ecosystem.

Projectone single-focused endeavour, short-term and temporary

Programa collection of projects

Portfolioprojects and programs across the whole organisation

Projects can sit inside programs, which can sit inside portfolios - but projects can also stand alone as separate, unrelated initiatives.

Role	Oversees	Horizon
Project manager	Individual projects	Short-term, concrete deliverables
Program manager	Groups of projects, and often other project managers	Long-term business objectives
Portfolio manager	A grouping of projects and programs, managed centrally	Organisation-wide

Each role is tasked with continuously improving whatever it owns, and improvements travel upwards. A PM starts monthly cross-departmental trainings so a small team always has cover when someone is out; after a couple of months it turns out they improved communication and worked as accidental team-building. Taken to the program manager, that can be rolled out across every project in the program.

Office Green shows the same escalation. Launching Plant Pals is a project and it ends at launch; keeping the service running indefinitely turns it into a program, one of the company’s long-term objectives; Plant Pals plus the other projects and programs make up the portfolio. So an improvement proven on one project can go company-wide across other sites and products, cutting waste and lifting revenue, and if it spreads across programs, the portfolio gains stronger profitability indicators.

---

Retrospectives

Note

Retrospective (retro) - a workshop or meeting that gives the project team time to reflect on a project, discussing the successes and setbacks within the project or a phase of it. Think of it as process improvement applied to your own project.

Retros should happen throughout the life cycle, though they are most often held after major milestones and, most commonly, after the project completes. Even with every risk planned for, something will sneak up on you, and that is exactly the moment to reflect with the team and record lessons other people can use on their own projects.

Missed deadlines or expectationsMiscommunications between stakeholdersEnd of a sprint (a series of ordered tasks ending in a goal)After product launches and landingsWhenever something slipped through the cracks

The three purposes

• Team building - members come to understand each other’s perspectives, which is what makes better collaboration possible.
• Improved collaboration on future projects - better mutual understanding raises productivity next time.
• Positive change to future procedures and processes - the emphasis is on improvement instead of recycling old, potentially bad habits.

There is no exact formula or template; how you structure a retro depends on your team and workplace. A formal, in-person session suits teams who like to debrief together, with sticky notes, documents or other physical props. If in-person meetings tend to drift off track, a virtual or online retro works better, with surveys to organise thoughts first.

Keeping it blameless

The single most important practice is that retros are blameless. People must feel able to give feedback as candidly as possible, or the exercise produces nothing, and anonymous or private channels help with awkward or sensitive subjects. Two tactics keep the tone right:

Tactic	What it looks like
Change perspective	Before blaming the delivery company for late plants, view it from their side. Was their route optimised and tested against traffic? If not, that should probably have been a task in your project
Swap you language for we language	Not you never made it clear we had no contingency budget, which makes the sponsor feel judged and wonder why the PM did not ask better questions early. Instead: the lack of a contingency budget was not made clear from the start, and that is something we can improve next time

Often the honest answer is that both sides could have done a little more, and that is fine.

Caution

Two failure modes. Only discussing the negative - retros are for what went well too: what was fun, what carries forward, which teams bonded that rarely work together, which contractor you liked enough to hire full time. Celebrate those, even with dinner or dessert as a thank you. And not enacting the changes discussed - people stop participating when their feedback visibly goes nowhere.

---

Running a retrospective

Settle two things before you start. Maintain a positive tone throughout, because even the tough conversations exist to prepare you for future projects. And consider teams outside your own: partner teams should be involved, since cross-team communication and deliverable handoffs are among the most frequent retro topics. If they decline to attend, share the findings with them anyway.

A standard retrospective template gives the PM a document to fill in and use to guide the conversation. Work through it in this order, walking the chain of events exactly as it happened in real time.

Chain of events

• What happened, in real-time order
• Planning stage, then execution
• What could have gone better, and where did we get lucky?

Lessons learned

• What to do differently next time
• Which risks materialised
• Gap between plan and execution, and how the team felt

Action items

• What should we do as a result?
• Type: tool, process, team, other. Owner: who holds it
• Links: where the item is tracked

Future considerations

• Risks that could become issues next quarter
• Ownership to hand off, plus type
• Contact who can act as a resource, and relevant links

Expect difficult feedback in the lessons-learned section, and sit with it. If the website launch missed its deadline, the sales team missed its numbers that month, marketing had to re-date content and ads, and the sponsor had to answer to investors waiting to see the site. The team’s view is that time went to less important tasks first. The lesson is concrete: next time, prioritise the task carrying that many dependencies.

Tip

The template is a starting point, not a rule. If your team wants something more interactive, gather the same information with colour coding, sticky notes or columns with emojis - whatever keeps them engaged. What is not optional is carrying the lessons learned into the next project.

Retros as continuous course correction

Retros are usually framed as an end-of-project ritual, but they work better as a continuous exercise of checking in on how the project is going. One example: halfway through launching something on Google Search, a team realised there was a better approach with far bigger user benefits, so they pulled the whole project team together, worked through what had been done, the current state, the options forward and the shortcomings nobody had spotted, then collectively replanned the rest of the project around an adjusted definition of success.

Caution

If you know the project is heading in a bad direction, continuing in it is the worst possible choice for the project and the company. Start analysing your options as fast as you can and commit to the new direction quickly, while still taking enough time for the decision to be data-driven and for stakeholders and sponsors to be on board. What makes that possible is ordinary discipline: manage scope, resources and timeline tightly, keep comparing actual progress against the plan you originally laid out, and course-correct on what you see.

---

Revision summary

Tip

One-minute recap

• Quality = meeting the outlined requirements and meeting or exceeding the customer’s expectations. Done is not the same as quality, and the customer is the judge.
• Four concepts in order: quality standards (agree what good means, with team and customer, at the start), quality planning (which standards apply and how to satisfy them), quality assurance (audit continuously), quality control (monitor results and correct). Well-defined standards mean less rework and fewer delays.
• QA prevents defects before they happen; QC catches them after and fixes them. QC is a subset of QA activities.
• Soft skills carry the customer relationship: negotiation, empathetic listening and trust building, all powered by open-ended questions about current versus desired state. Set update expectations rather than waiting to be asked.
• Measuring satisfaction: feedback surveys (before launch, or after, to iterate) and UAT (end-to-end, near the end of development, sometimes called a beta test).
• UAT flow: welcome, present, run test cases through critical user journeys, demo, call to action, gather feedback, hunt edge cases, recap and prioritise fixes. Best practices: written acceptance criteria, test cases, genuine end users, scripts from user stories, prepared users and environment, a step-by-step plan, one notes document. Triage bugs by severity, manage change requests with stakeholders, and leave schedule room to fix what you find.
• Accessibility belongs in the feedback methods (accommodations, venues, WCAG-compliant tools) and in the product from the start, never the final stages.
• Customers versus sponsors: customers use or buy it; sponsors fund it and want quantified ROI at the right level of detail.
• Continuous improvement is the ongoing mentality; process improvement is the concrete analysis of a process. Test a change with a control group and exactly one changed variable.
• DMAIC and PDCA are the named data-driven frameworks; PDCA = plan, do, check, act, and a proven fix becomes a best practice.
• Project, program, portfolio nest, and so do improvements: what works on one project can scale program-wide, then organisation-wide.
• Retrospectives reflect on successes and setbacks. Hold them throughout, especially after milestones, missed deadlines, miscommunications, sprints, launches and completion. Three purposes: team building, better future collaboration, positive process change.
• Blameless is the rule: change perspective, use we language not you language, allow anonymous feedback, and celebrate what went well.
• Turn findings into action: chain of events, lessons learned, action items with type, owner and links, future considerations with a contact. Feedback that is never implemented kills participation.
• Course-correct while the project runs - replan collectively and fast when the direction is wrong, but keep the decision data-driven and the stakeholders aligned.

---

Next: Data-Informed Decisions → - using data to steer the project and tell its story.