8.1 Plan Quality Management
Decide what quality means for this project and how you will prove it.
Planning / Quality · ← PMBOK reference · See it on the map
Why it matters
Without agreed standards, 'good enough' means something different to every stakeholder, and disagreements about whether work is done right multiply.
What done looks like
Quality standards and the metrics used to check them are written down and agreed.
First time tip
Pick metrics that are cheap to measure regularly. A standard nobody can practically check gets skipped the first time the schedule is tight.
What you need (Inputs)
- Project Charter
- Requirements Management Plan
- Risk Management Plan
- Stakeholder Engagement Plan
- Scope Baseline
How Scrum/Kanban projects satisfy this — counted from: committed backlog items and definition-of-done items (models/agile.py) — a committed backlog (status ready/in_progress/done) plus a written definition of done is what an agile team baselines scope against - Requirements Documentation
How Scrum/Kanban projects satisfy this — counted from: backlog items (driftless/models/agile.py:BacklogItem) — a backlog item's description IS its requirement statement; present once any item has one, healthy once every item does - Stakeholder Register
How you do it (Tools & Techniques)
- Expert Judgment
- Data Gathering
- Data Analysis
- Cost of Quality
- Decision Making
- Data Representation
- Test and Inspection Planning
What you get (Outputs)
Worked example
"Good enough" for the reading room is written down as paint with no roller marks visible under the room's own lighting and shelving that holds 40 kg a shelf — both things one person can check in ten minutes.
Common pitfalls
- Setting a standard nobody can check in the time the work actually allows.
- Borrowing a standard from a different kind of work without adapting it.
- Writing a metric with no number in it, so two people score it differently.
How driftless helps
- Cost of Quality can be run here.
- Quality Management Plan can be created in the wizard.