Quality Management in PM²: building quality, not chasing defects

Twentieth article in the “Learning PM² Through a Project” series

Quality does not mean “the highest possible level” or “zero defects at any cost”. In a project, it means that deliverables, processes and results satisfy agreed requirements, standards and acceptance criteria, appropriately for their purpose.

In PM², Quality Management plans, assures and controls quality during the project. Waiting until the end to discover whether a deliverable is acceptable makes corrections more expensive and puts schedule and trust at risk.

Quality, scope and acceptance: related but distinct

A deliverable can be in scope but of insufficient quality: for example, the booking feature exists but does not meet agreed performance, accessibility, security or operational criteria.

The quality cycle

flowchart LR
  A[Define standards and criteria] --> B[Prepare methods and responsibilities]
  B --> C[Prevent defects in the work]
  C --> D[Verify with evidence]
  D --> E[Correct and improve]
  E --> C

In practice, PM² distinguishes:

Quality must be verifiable

Terms such as “high quality”, “modern interface” or “reliable app” are aspirations, not criteria. A useful criterion is observable and testable.

Not every project needs sophisticated metrics. Each needs criteria clear enough to prevent acceptance from meaning only “it looks good to me”.

Quality Management Plan: what it should clarify

The quality plan is tailored to the project. For a small project it may be a Project Handbook section; for a complex one it may be a dedicated plan. In both cases it clarifies at least:

The plan need not repeat established organisational procedures. It should make clear how those procedures apply to this project and its deliverables.

Quality assurance: prevent before testing

Quality Assurance looks primarily at the process, not only the product. Examples:

• code review takes place before merge;
• requirements have acceptance criteria before development;
• critical tests are automated or planned;
• the definition of “done” is shared;
• test data and environments are fit for purpose;
• recurring non-conformities are analysed for causes, not only fixed one by one.

The typical question is: are we working in a way that makes the required quality likely?

Quality control: verify the deliverable

Quality Control looks at the result: functional tests, integration tests, performance checks, inspections, completeness checks, document reviews or demonstrations with users.

A quality-control outcome can be:

• compliant;
• compliant with minor observations;
• non-compliant, with a defect or issue to correct;
• subject to a waiver decision, with risk and impact made explicit.

A waiver does not erase a defect. It is a conscious decision to temporarily accept a non-conformity, documenting rationale, owner and follow-up actions.

The Annotatio case: quality of the waiting-list function

For Smart Bookings, the requirement is: when a place becomes available, the first user on the list is notified and has 30 minutes to confirm.

A proportionate quality plan may include:

Testing only the happy path is not enough. Quality requires attention to exceptions, concurrency, roles, integrations and real use.

Cost of quality: prevention costs less than late correction

There is a real trade-off: reviews, tests and checks take time. But a correction discovered after go-live can require urgent analysis, support, communication, loss of trust and new regressions.

Quality is not adding unlimited controls. It is selecting the controls that most reduce risk to the most important deliverables and benefits.

Do not confuse these

Three questions to anchor it

1. Which objective criterion demonstrates that this deliverable has the required quality?
2. Which control prevents a defect before it reaches final testing?
3. If a non-conformity is not corrected, who can accept the risk and under which conditions?

Flashcards

Q: What is the difference between Quality Assurance and Quality Control?
A: Assurance checks and improves the process used to prevent defects; control verifies compliance of deliverables and results.

Q: What makes a quality criterion useful?
A: It must be clear, observable and verifiable with evidence or tests.

Q: What is a quality waiver?
A: A documented decision to accept a non-conformity, with rationale, impact and any follow-up actions.

Exam-style question

The team completes development of the booking function. The PM proposes accepting it because all user stories are closed, deferring concurrency testing and role verification until after go-live.

What is the correct assessment?

Answer: closing user stories alone does not demonstrate compliance with quality and acceptance criteria. Relevant controls — here, concurrency and authorisations — must produce evidence before acceptance, unless a waiver is explicitly decided by competent governance.

Source

Quality Management, the Quality Management Plan and deliverable-quality management are covered in the European Commission’s PM² Methodology Guide 3.1.

Next: Communication Management, for getting the right information to each person at the useful time, with clear responsibility.