8.3 Control Quality
Check the finished product against the agreed standards before it ships.
Monitoring and Controlling / Quality · ← PMBOK reference · See it on the map
Why it matters
Shipping a defect the customer finds costs far more in rework, trust, and sometimes contract penalties than catching it here would have cost.
What done looks like
Deliverables have been measured against the standards and any defect has been resolved.
First time tip
Sample early deliverables even if the process seems fine. A problem in the first batch is cheaper to fix than the same problem repeated across the rest.
What you need (Inputs)
- Quality Management Plan
- Quality Metrics
- Deliverables
- Work Performance Data
- Approved Change Requests
- Test and Evaluation Documents
How you do it (Tools & Techniques)
What you get (Outputs)
- Quality Control Measurements
- Verified Deliverables
- Work Performance Information
How Scrum/Kanban projects satisfy this — counted from: sprints under way (driftless/models/delivery.py:Sprint) for an agile project, or service levels and incidents (driftless/models/operations.py) for an operations-cadence one — a sprint under way is the work performance data an agile team reads instead of a baseline-and-actuals pair; an operations-cadence project reads the same question off its service levels and the incidents raised against them - Change Requests
Worked example
Before the room reopens, a shelf is loaded to 40 kg and the paint is checked under the room's own lights against the standard agreed in Plan Quality Management. Both pass, and the reworked brackets are re-checked alongside them.
Common pitfalls
- Checking a deliverable against memory rather than the written standard.
- Sampling only the last batch, after the earlier ones have already shipped.
- Accepting a deliverable with an open defect on a promise to fix it later.
How driftless helps
- Inspection can be run here.
- Meetings can be run here.