Project Management Leadership with AIExecution, control, risk and quality · Lesson 11 of 21
Building quality in
Video lecture
Building quality in
The narrated lecture is in production
Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.
Chapters
Transcript of the narration, chapter by chapter.
0:00 Quality means fitness for purpose
Here's a pattern I've seen in many teams. Testing is squeezed to meet a date. The release goes out. Defects appear in production. The team spends the next two sprints fixing them instead of building new features. The date was met, and the project got slower. Quality isn't the opposite of speed. Poor quality is one of the biggest causes of slow delivery. In this lecture you'll learn what quality really means for a project, the difference between quality planning, assurance and control, why prevention beats inspection, how a strong Definition of Done works, and how to find root causes with the five whys. By the end, you'll be able to write a Definition of Done your team will actually use, and run a root cause analysis on a real defect.
0:57 Why it matters
Why does this matter? Because the later a defect is found, the more it costs to fix. A misunderstanding caught in a requirements conversation costs minutes. The same misunderstanding caught in production costs rework, support calls, lost trust and sometimes regulatory attention. Rework also hides: it shows up as lower velocity, slipping schedules and tired teams, rather than as a line item called 'quality'. And quality protects the benefits in the business case. A system that technically works but frustrates users won't deliver the adoption, efficiency or revenue it promised. Quality is part of value, not a phase at the end.
1:41 The concept: fitness for purpose
Here's the key idea: quality means fitness for purpose, meeting the requirements and being suitable for how it will actually be used. It's managed in three linked activities. Quality planning decides the standards and acceptance criteria up front. Quality assurance checks whether our processes are working: are reviews happening, are tests written early, is the definition of done followed? Quality control checks whether the product meets its criteria, through testing, inspection and reviews. Think of a restaurant. Planning is the recipe and the standards. Assurance is the head chef checking the kitchen follows them. Control is tasting the dish before it goes out. You need all three, but the best restaurants invest most in the first two, so the tasting rarely finds a problem.
2:35 Prevention and the Definition of Done
Prevention over inspection means building quality in rather than testing it in at the end. Clear acceptance criteria before work starts. Peer reviews. Automated tests written alongside the code. Small batches, so problems surface quickly. The Definition of Done is the team's shared quality bar: a checklist every item must meet before it counts as done. For a software team, it might include: code reviewed, automated tests passing, acceptance criteria met, security checks run, documentation updated and deployed to a test environment. For a construction or engineering deliverable, it might include inspections, test certificates and as-built records. The power of the Definition of Done is that it's non-negotiable and applies to every item, so 'done' means the same thing to everyone, and quality isn't traded away quietly under pressure.
3:31 Worked example one: writing a Definition of Done
Let's write a Definition of Done from scratch. Start with evidence: the last ten defects that reached users. For each, ask: what check would have caught it? A missing error message suggests 'error states tested'. A slow page suggests 'performance checked against the agreed threshold'. A layout broken on mobile suggests 'tested on the agreed devices'. Combine those with the basics: acceptance criteria met, peer reviewed, automated tests passing, documentation updated. Keep it to six to eight concrete, checkable items. Too many, and people start skipping them. Agree it as a team, put it on the board, and review it in retrospectives. A Definition of Done built from your own defects is far more convincing to a team than a generic one copied from the internet.
4:26 Worked example two: five whys in Lahore
Now the realistic example from the lesson. A fictional software firm in Lahore saw a spike in production defects. They ran five whys. Why? Defects in the payments module after release. Why? Edge cases weren't tested. Why? Test cases were written late, after coding, under time pressure. Why? Acceptance criteria were vague when stories entered the sprint. Why? Backlog refinement sessions were routinely cancelled. There's the root cause, and it's not about testers at all. It's about refinement. The fixes: protect refinement time in the calendar, require testable acceptance criteria before a story can enter a sprint, and add edge-case examples to the Definition of Done for payment features. Defects in later releases fell substantially. Fix the symptom, and the problem returns. Fix the cause, and it goes away.
5:22 Watch me do it: a simple defect Pareto
Let me show you a quick analysis that focuses improvement effort. I take the defect list from the last few releases and add one column: cause category. Things like unclear requirements, missing test, environment difference, integration, and data. A pivot table counts defects per category and sorts them. Then a Pareto chart: bars for each category in descending order, and a line showing the cumulative percentage. Almost always, two or three categories account for most defects. Here, unclear requirements and missing tests together account for about seventy per cent. That's where the next improvement goes, not spread thinly across everything. And after the change, I run the same chart again to see whether it worked.
6:12 Measuring quality
How do you know whether quality is improving? A few measures work well. The escape rate: the share of defects found by users rather than by the team, which tells you how effective your prevention and testing are. The share of effort spent on rework, which you can estimate from tickets tagged as fixes. The cycle time for fixing defects, which shows how quickly the team responds. And the number of customer-reported issues after each release. Watch trends rather than setting hard targets, because targets on defect counts invite gaming: people stop logging defects, or argue about what counts as one. The most useful chart I know marks process changes, like a new Definition of Done, directly on the trend line, so you can see whether the change actually made a difference.
7:09 Regulated work, balance and common mistakes
In regulated and physical projects, quality management is more formal: inspection and test plans, certificates, hold points, traceable records, and often organisations with quality management systems certified to ISO 9001. The principles are the same; the evidence is stricter. On balancing quality against time and cost, remember that cutting testing to meet a date usually costs more time later. If scope must give, reduce features, not quality. The common mistakes: treating quality as a phase at the end, a vague Definition of Done nobody checks, measuring only defects found rather than defects escaping to users, and blaming individuals for what are usually process causes.
7:54 Recap and try this now
Let's recap. Quality means fitness for purpose. Plan the standards and criteria, assure the process and control the product, and invest most in prevention, so quality is built in rather than inspected in. A clear Definition of Done, built from your own defect history, makes 'done' mean the same thing to everyone. Use five whys to find root causes and a Pareto chart to decide where improvement effort goes. And never trade quality silently for a date; trade scope instead, and make the decision visible. Your try-this-now: write or improve a Definition of Done for your team, based on your recent defects, and run a five whys on one recent defect or failure.
Quality means fitness for purpose
Quality is the degree to which deliverables meet requirements and are fit for their intended use. It is not gold-plating (adding features nobody asked for). The cost of poor quality, including rework, defects found by customers, warranty claims and reputational harm, usually exceeds the cost of preventing it.
Quality planning, assurance and control
| Activity | Question | Examples |
|---|---|---|
| Quality planning | What standards and criteria apply, and how will we meet them? | Acceptance criteria, Definition of Done, test strategy, regulatory standards |
| Quality assurance | Are our processes likely to produce quality? | Process audits, code reviews, design reviews, peer reviews |
| Quality control | Do deliverables meet the criteria? | Testing, inspections, measurements |
Prevention over inspection
A principle from quality management thinking (associated with Deming and others): build quality into processes rather than inspecting defects out at the end. Practical examples:
- Clear acceptance criteria before work starts.
- Peer review of designs and code.
- Automated testing in continuous integration pipelines.
- Checklists for repetitive tasks (e.g., deployment checklists).
- Early prototypes with users.
Definition of Done
In agile teams, the Definition of Done (DoD) is a shared quality standard every increment must meet. Example:
Definition of Done (illustrative)
[ ] Acceptance criteria met and demonstrated to product owner
[ ] Code peer-reviewed and merged to main branch
[ ] Automated unit and integration tests passing
[ ] Security scan passed with no high-severity findings
[ ] Accessibility checks against agreed standard completed
[ ] Documentation and release notes updated
[ ] Deployed to staging; no regressions in smoke testsThe DoD applies to every item; acceptance criteria are specific to each item.
Useful quality tools
- Cause-and-effect (fishbone) diagram: organise possible causes of a problem (people, process, technology, materials, environment, measurement).
- Pareto analysis: often a minority of causes produce most defects; focus on them first.
- Control charts: distinguish normal variation from special causes in repeatable processes.
- Root cause analysis (5 Whys): keep asking why until you reach a cause you can fix.
Worked example: 5 Whys
Illustrative. A fictional software firm in Lahore saw a spike in production defects.
- Why? Defects in the payments module after release.
- Why? Edge cases not tested.
- Why? Test cases written late, after coding, under time pressure.
- Why? Acceptance criteria were vague when stories entered sprints.
- Why? Backlog refinement sessions were routinely cancelled.
Fix: protect refinement time; require testable acceptance criteria before a story can enter a sprint; add edge-case examples to the DoD for payment features. Defects in subsequent releases fell substantially.
Quality in regulated and physical projects
Construction, healthcare, aviation and financial services projects must meet external standards and inspections (e.g., building codes, medical device regulations, financial regulators' requirements). Integrate inspection and test plans (ITPs) into the schedule, with hold points where work cannot proceed until inspected. Organisations may also operate quality management systems certified to ISO 9001.
Balancing quality, time and cost
Cutting testing to meet a date is a common temptation. Make the trade-off explicit: what risk is accepted, who accepts it, and what mitigation exists (e.g., limited release, feature flags, extra monitoring). Record the decision.
Common mistakes
- Vague acceptance criteria.
- Testing compressed at the end of the schedule.
- DoD written but ignored under pressure.
- Treating quality as the QA team's job alone.
- Fixing symptoms without root cause analysis.
Quick self-check
What share of your defects in the last release were found by customers rather than the team? If it is rising, look upstream at requirements and review practices, not just at testing.
Measuring quality
Choose a few quality measures that match the work: escaped defects (found after release), defect density, test pass rates, rework hours, customer complaints, inspection failures or first-time-right rates. Track trends over time and investigate changes. Share them with the team as learning signals rather than blame metrics, so people report problems honestly.
Quality culture
Quality ultimately depends on culture. Teams that are praised for finding problems early, given time to do work properly and trusted to stop a release when standards are not met produce better results than teams pressured to hit dates at any cost.
Hands-on: defect Pareto in Excel
Defects sheet: A ID | B Release | C Severity | D Found in (test / production) | E Cause category
Pivot: Rows = Cause category, Values = Count of ID, sort descending
Cumulative % =SUM($B$2:B2)/SUM($B$2:$B$10)
Chart Insert > Statistic chart > Pareto (current Excel), or a combo of bars + cumulative line
Escape rate =COUNTIFS(D:D,"production")/(COUNTA(A:A)-1) (header excluded)Template: Definition of Done (software example)
[ ] Acceptance criteria met and demonstrated to the product owner
[ ] Code peer-reviewed; no unresolved review comments
[ ] Automated unit and integration tests written and passing
[ ] Error states and agreed edge cases tested
[ ] Performance checked against the agreed threshold; tested on agreed devices/browsers
[ ] Security checks run (per policy); no high findings open
[ ] User-facing text and documentation updated
[ ] Deployed to the test environmentAdapt the items to your domain; in construction, items might include inspection sign-off, test certificates and as-built drawings.
Prompt template: a five-whys facilitation aid (approved AI tool)
We are running a five-whys analysis on this defect: <description>. Evidence so far: <facts>.
Suggest follow-up questions for each "why" that would test alternative explanations. Do not conclude the root cause;
list what evidence would confirm or rule out each candidate cause.The team decides the root cause from evidence, not from the AI's suggestions.
How to measure success
- Escape rate (defects found in production ÷ all defects) falling release on release.
- Top Pareto category shrinking after targeted improvements.
- Definition of Done reviewed in retrospectives and applied to every item.
Key takeaways
- Quality is fitness for purpose; poor quality costs more than prevention.
- Plan quality, assure processes and control deliverables; prefer prevention over inspection.
- A Definition of Done sets a shared quality bar for every increment.
- Use root cause tools (5 Whys, fishbone, Pareto) and make quality trade-offs explicit.
Check your understanding
Quick questions to lock in the lesson. They don’t count towards your certificate.
Put it into practice
Write or improve a Definition of Done for your team and run a 5 Whys on one recent defect or failure.
Enrol for free to save your progress
Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.