Audits

Quality technique · See it on the map

Runnable here

A structured, independent check of whether the project's actual quality process was followed — as distinct from whether the product it produced meets its requirements.

When to use it

On a routine cadence, before a major deliverable handoff, after a serious quality escape to check whether the process failed or was simply skipped, or where a certification or compliance obligation requires it.

When to avoid it

When the process being audited is one the team doesn't believe is workable — fix the process first, or the audit measures compliance with a rule nobody follows and becomes theatre. Also avoid auditing when the real question is whether one specific product is good; that's testing/inspection, not an audit.

Steps

1. Define the standard being audited against — the actual documented process, not an assumed best practice.
2. Assign an auditor who did not do the work being checked.
3. Choose a sample of activities or records: recent work, plus at least one item flagged as risky.
4. Compare what happened — interviews, records, artifacts — against what the process says should have happened.
5. Record each gap as a finding: what the process required, what actually happened, and the evidence for it.
6. Separate findings that are process failures (the process itself doesn't fit how the work actually happens) from findings that are compliance failures (the process was workable and wasn't followed).
7. Agree corrective actions and a follow-up date with the process owner, not only with the team that was audited.

What it produces

• An audit report listing findings against the stated process.
• Agreed corrective actions with owners and a follow-up date.
• Good practices identified that are worth reusing elsewhere on the project.

Common pitfalls

• Auditing compliance with a process nobody believes in — teams learn to perform for the audit rather than change how they work; fix or retire the process instead.
• An auditor who is also accountable for the result being audited, so findings get softened.
• Treating a clean audit as proof the product is good. An audit checks whether the process was followed, not whether the output meets spec — pair it with testing or inspection for that question.
• Findings that nobody is assigned to actually fix.

Worked example

At Larch & Rowe, a quarterly audit of the change-order approval process finds that 6 of 20 sampled change orders were verbally approved on site, with paperwork filed after the fact. The audit doesn't fault the PM's workmanship — it flags that the approval process, which requires a signature before work starts, doesn't fit how change orders actually arise on a job site. The corrective action revises the process to allow a documented verbal approval with a 24-hour paper follow-up, rather than keep failing everyone against a rule nobody follows.

Source

• PMBOK-6 §8.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.