UPI Study › Courses › Project Management › Free lessons › Lesson 8.6 Free with a free account
Quality Management Processes and Performance Metrics
Project Management · Chapter 8: Driving Project ExecutionSection 8.6 · lesson 49 of 7314 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Project Management.
Lesson complete
Earn the 3 college credits for Project Management
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Change Management Planning and Component Integration →← Handling Incomplete Tasks: Consequences and RecoveryNext lesson: Change Management Planning and Component Integration →
In this lesson
Assuring processes, controlling products and measuring quality with simple tools.
- Distinguish quality assurance, which examines the process, from quality control, which examines the product
- Use fishbone diagrams and five whys to search for root causes
- Build a Pareto chart to find the vital few causes of defects
- Calculate defect density, rework rate and first-pass yield
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,946 words). Read along, or search it.
Opening Case
A Hundred Defects, Time for Eighty
A hundred open defects, and time to fix about eighty before the release freeze. Which eighty? Mateo is the quality lead at a made-up studio building a travel-booking app. Defect reports have climbed for three weeks, and the release date is fixed by a partner launch. Fixing them newest first spends the hours on whatever just arrived, and never touches the cause. This lesson builds the tools that give Mateo a better answer.
Roles in Execution
Who Performs Which Quality Activity
The quality plan says what quality means for the project. In execution, the question is practical: who performs which quality activity, and when? A defect is a flaw that makes a deliverable fail a stated requirement. Nearly every quality activity exists to prevent defects, or to find them. One group of activities looks at the process: the way the work is done. They happen at planned points, whether or not a deliverable is ready. The other looks at the product: the thing produced. Those happen as soon as a deliverable, or a usable part of one, exists. Makers check their own work as they go, because they see errors first and fix them cheapest. Independent reviewers and testers do the scheduled checks on finished work. The project manager doesn't usually do the checks. The manager makes sure each one has time and people in the schedule, that results are recorded, and that findings lead to action.
Quality Assurance
Audits and Process Analysis Prevent Defects
Quality assurance, or QA, is process-focused: checking that the way work is done can produce deliverables that meet requirements, so defects are prevented rather than found later. Two activities carry most of it. An audit is a planned, independent examination of whether work follows the agreed procedures, and whether the records show it. Process analysis studies how a procedure actually runs, to find the steps that cause errors, delays or waste. At a made-up construction firm, an auditor finds three concrete pour records left blank. Process analysis shows two versions of one drawing in circulation at the same time. Neither is a defect in a particular floor. Each is a process weakness that will keep producing defects, so the output of assurance is a corrective action, like a single controlled drawing list. And mind the boundary: a passed audit shows a procedure was followed, not that the procedure is good. Assurance and product checks are used together.
Root Cause Search
Fishbone Diagrams Widen the Search
When defects keep coming, assurance looks for root causes. A root cause is the condition that, removed, stops the defect from recurring. The symptom is only what the defect looks like. A fishbone diagram, or cause-and-effect diagram, puts the problem at the head of a spine, with angled branches for categories of cause. Typical branches are people, methods, tools, materials or inputs, measurement, and environment. They're prompts, not rules, and teams rename them to fit the work. A fishbone lists possible causes, so a team searches widely instead of settling on its first idea. It doesn't show which causes are real, so evidence has to follow.
Root Cause Search
Five Whys Behind Peeling Paint
Five whys follows one cause down. A wall's paint peeled. Why? It went on over damp plaster. Why was it damp? It hadn't finished drying. Why paint before it dried? The crew was booked that week, and the schedule allowed no delay. Why did nobody stop it? Nobody measured the dampness. Why not? The inspection checklist had no step for it. The root cause is a gap in the checklist, a process matter assurance can fix, not a careless painter. Its limits: five is a habit, not a rule. It follows one chain, though problems often have several causes. And it depends on who asks, so it can stop early, or drift into blame. So check each answer against evidence before asking the next why. A fishbone is better for a wide set of candidates. Five whys follows one to its end.
Quality Control
Inspection, Testing and Sampling
Quality control, or QC, is product-focused: examining deliverables against their requirements, to find defects before they reach the customer. Inspection examines a deliverable directly, by measuring it, reviewing it, or checking it against a drawing or checklist. Testing operates it under defined conditions, and compares what it does with what was expected. Sampling checks only some items, and judges the whole group from them. It's used when there are too many items, or when the check destroys the item. Sampling estimates. It never proves. Check twenty of two hundred items, find one faulty, and the estimate is about five percent. The other hundred and eighty could hold more faults, or fewer. And a sample must be representative. If faults appear only late in the day, or on one device model, a sample drawn from early items or another model passes the whole batch. Inspecting every item is preferred when items are few, a single failure is serious, or the check is cheap. Even then, a person checking thousands can miss some.
Telling Them Apart
The Thing Made or the Way Made
To place any activity, ask one question: does it examine the thing made, or the way it was made? Running test cases on a build examines the thing made, so it's control. Auditing whether the test records are complete examines the way testing is done, so it's assurance. A peer review of work before it's merged inspects the product, so it's control, even though it also teaches the author. Who should do control is contested. One side says checkers should be independent of makers: fresh eyes, no stake in the work looking good, and a record others trust. The other says makers should own quality, because a separate checker invites the thought that someone else will catch it. The evidence is mixed. This course takes no position.
Quick Check
Watching Intake Staff Enter Patients
Quick check. At a clinic, a reviewer sits with the intake staff and watches how they enter new patients, to find where errors creep in. Is that quality assurance, quality control, or formal acceptance? Pause, and decide. Quality assurance. It's process analysis: the reviewer examines the way records are made, not any one record, and the result will be a change to the procedure. It would be control if the reviewer checked a batch of finished records against the requirements. Formal acceptance is a separate decision about a finished deliverable.
Pareto Chart
Three Causes Behind Eighty Defects
Back to Mateo's hundred defects. A Pareto chart sorts the causes of defects from most to least frequent, with a running total, to find the few that cause most. Build it in steps: count defects per cause, sort from largest to smallest, divide each by the total, and add the shares in order. The testers tag each defect with a cause. Ambiguous requirements, thirty-eight. Untested device variants, twenty-seven. Changes made without a retest, fifteen. Then unchecked user input, nine. Inconsistent build settings, seven. And text and label errors, four. The running total goes thirty-eight, sixty-five, eighty, eighty-nine, ninety-six, a hundred. It reaches eighty percent at the third bar. Those three are the vital few: eighty defects. The other three, the trivial many, account for twenty. Some cautions. The eighty-twenty pattern is a common tendency, not a law. A flat chart is a finding too: no single fix will do. And the chart ranks by frequency. A rare cause that loses customers' data may matter more, so check the vital few against severity before committing effort.
Control Chart
Signals Versus Ordinary Variation
A control chart watches a process over time. It plots one measure at regular intervals, like the weekly rework rate, with a center line for the usual level, and upper and lower control limits. The limits come from the process's own past results, not from what the customer wants. So a process can sit happily inside its limits and still fail a requirement. Ordinary ups and downs inside the limits are expected. Reacting to every wiggle makes a process worse, not better. The signals are a point outside a limit, several points in a row on one side of the center line, or a steady climb or fall. Teams agree in advance what counts. The chart says when something in the process shifted, not what or why. It tells the team when to start root-cause work, earlier than waiting for one bad deliverable.
Quality Metrics
Density, Rework Rate and First-Pass Yield
Three metrics put numbers on quality. Defect density is defects found, divided by the size of what was measured, like thousands of lines of code, screens, or pages. Rework rate is rework effort divided by total effort: the share spent redoing work that didn't meet its requirement the first time. First-pass yield is the items that pass inspection the first time, divided by the items inspected. An item repaired and passed on its second try doesn't count. Some made-up numbers: a booking module of twelve and a half thousand lines. Testing found thirty defects. Thirty over twelve point five is two point four defects per thousand lines. It took four hundred hours, sixty of them rework: sixty over four hundred is fifteen percent. And forty-one of fifty items passed first time: eighty-two percent. Each has a blind spot. Density says nothing about severity, or whether testing was weak. Rework rate doesn't say why. Yield doesn't say how serious the failures were. They warn at different times. First-pass yield registers the moment an item is inspected, so with strict, timely inspection it usually warns first. Rework rate lags most.
Continuous Improvement
Fixing the Rotation Crash for Good
Continuous improvement fixes a process in small, tested steps, using the plan-do-check-act loop. Say the app crashes when a user rotates the phone with a form open. The same defect has been fixed every time it's reported: six, five, and six reports in three weeks. Plan: five whys shows the layout is rebuilt on rotation, losing the form data, and the checklist has no rotation case. The team plans two fixes, and a measure: weekly rotation reports. Do: try both fixes on one module. Check: over the next three weeks, reports fall to two, one, and zero, and first-pass yield rises. Act: add the rotation case to every module's checklist, and redraw the Pareto chart, since removing one vital cause changes what's left. Had the counts not fallen, the team would revise and try again.
Quick Check
Thirty-Four of Forty Pass First Time
Quick check. A library's search feature has forty work items inspected. Thirty-four pass the first time, and the other six pass after repair. What's the first-pass yield? Pause, and decide. Point eight five: thirty-four over forty, or eighty-five percent. The six repaired items don't count, because they weren't right the first time. Point one five is the share that failed. And point three four confuses the count with a share.
Case Resolved
Mateo Fixes the Vital Few First
Back to Mateo. He drew a fishbone with the team for the problem, too many defects reaching testing, and got a long list of possible causes. Then the testers tagged each open defect, and the Pareto chart showed three causes behind eighty of the hundred. Five whys on the biggest traced it to tickets written before the design was settled, and never reviewed before development began. So he fixed the eighty in the vital few first, and had the team review the acceptance wording of every remaining ticket, so the cause stopped feeding the log. Before committing, he checked the twenty in the tail for anything severe. None stopped a booking from completing. The trade-off: twenty minor defects ship open, listed in the release notes, and the review takes developer time. One defect needed a screen redesign, which changes the plan, so it went to change control.
Key Takeaways
Process, Product and the Right Tools
To recap: quality assurance examines the process, to prevent defects. Quality control examines the product, to find them. Fishbones widen the search for causes, and five whys follows one cause to its root. A Pareto chart finds the vital few, and a control chart signals when a process shifts. And density, rework rate and first-pass yield each tell part of the story, never all of it.
About Project Management at UPI Study
Project Management (Business 230) is a self-paced online course of 73 video lessons in 12 chapters, from starting and defining a project to planning, budgets, scheduling tools, proposals, contracts, execution, monitoring, closure, teams and certification. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Business courses Every course with PRO →
Why take it here
Why students take Project Management with UPI Study
Where the credit goes
Universities that work with NCCRS
Project Management carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Quality Management Processes and Performance Metrics
What is the difference between quality assurance and quality control?
How do you build a Pareto chart for project defects?
How is first-pass yield calculated?
What does a control chart show in project quality management?
About the Project Management course
How many college credits is Project Management?
How much does Project Management cost and what is included?
Which universities accept UPI Study credits?
How long does Project Management take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Project Management.
73 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →