7.7 Control Quality

7.7 Control Quality
Inputs Tools & Techniques Outputs

The process of checking deliverables and work results against agreed quality standards and metrics, documenting findings, correcting defects, and sharing verified outputs for formal acceptance.

Purpose & When to Use

Control Quality confirms that project outputs meet specified requirements. It uses inspection, measurement, and testing to find defects, verify fixes, and provide objective evidence of conformance. Use it throughout delivery, especially when work packages complete, before handing items to customer acceptance.

Mini Flow (How It’s Done)

  • Prepare: gather quality metrics, acceptance criteria, sampling plan, and test procedures.
  • Inspect and test: perform checks, measurements, or trials on work results and deliverables.
  • Record findings: log defects, variances, and measurement data using checklists or check sheets.
  • Analyze: use basic statistics and charts to spot trends, outliers, and root causes.
  • Correct and re-test: request rework, verify fixes, and confirm compliance with metrics.
  • Output and communicate: produce verified deliverables, measurement results, change requests, and updates to plans and lessons learned.

Quality & Acceptance Checklist

  • Applicable quality metrics and tolerances are identified and current.
  • Test or inspection methods are defined, repeatable, and tools are calibrated.
  • Sampling approach and acceptance criteria are documented and followed.
  • All checks are executed; results and evidence are recorded and traceable.
  • Defects are logged with severity, location, and responsible owner.
  • Rework is completed and verified; failed items are not released.
  • Recurring or systemic issues undergo root cause analysis and actions are captured.
  • Configuration item identity matches the version tested and approved.
  • Verified deliverables and measurement summaries are prepared for customer acceptance.
  • Change requests, updates to the quality plan, and lessons learned are submitted as needed.

Common Mistakes & Exam Traps

  • Mixing up Control Quality and Validate Scope: Control Quality is internal conformance checks; Validate Scope is customer or sponsor acceptance.
  • Confusing Manage Quality with Control Quality: Manage Quality improves the process and plans; Control Quality measures outputs and finds defects.
  • Relying on 100% inspection when statistical sampling would be sufficient and cost-effective.
  • Ignoring trends or special-cause variation on charts; passing items that show unstable process behavior.
  • Failing to submit change requests for preventive or corrective actions discovered during testing.
  • Not keeping objective evidence (records, logs, measurements), which weakens acceptance and audits.
  • Skipping re-verification after rework or not updating configuration status.

PMP Example Question

You completed inspections on a deliverable, logged defects, and after rework it meets all specified metrics. What should you hand off next for formal acceptance?

  1. Approved change requests.
  2. Verified deliverable and measurement results.
  3. Updated risk register.
  4. Lessons learned updates.

Correct Answer: B β€” Verified deliverable and measurement results.

Explanation: Control Quality produces verified deliverables and objective evidence of conformance, which are then presented in Validate Scope for formal acceptance.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Build the Sprint Reporting System, Not Another Prompt

AI Systems with Claude is our own course for Scrum Masters and Agile Project Managers, taught against one running project across seven sections. You build five working systems and keep them: the sprint report machine, the retro intelligence system, the stakeholder comms engine, the backlog health monitor, and the risk and dependency tracker. Direct from HK School of Management, not on Udemy.

See What Is Included