Inspection

Scope technique · See it on the map

Runnable here

Checking a finished deliverable against its requirements before it is formally accepted.

When to use it

Use it on every deliverable before asking for formal acceptance. There is essentially no scope deliverable this doesn't apply to -- 'when to avoid it' is close to never, because skipping inspection means accepting a deliverable on the producer's word alone.

When to avoid it

There isn't a real case for skipping it outright. The honest caution is about depth and rigor, not whether to do it at all: match the inspection's thoroughness to the deliverable's risk and cost of being wrong, and don't let time pressure turn it into a rubber stamp -- an inspection that only confirms the deliverable exists, rather than checking it against its actual acceptance criteria, isn't validating scope, it's skipping validation with extra steps.

Steps

1. Pull the acceptance criteria for the deliverable from the scope statement or requirements documentation -- inspecting against vague or missing criteria is why rubber-stamping happens.
2. Decide the inspection method that fits the deliverable: a walkthrough for a document, a demo for a feature, a physical measurement for a built artifact, a test run for software.
3. Have someone other than the person who produced the deliverable perform or lead the inspection -- self-inspection catches less and carries less weight with the customer.
4. Check each criterion individually and record a pass, fail, or conditional result for it -- not one overall thumbs up.
5. Route anything that fails back to the team producing the work as a defect or change, and only carry the deliverable to formal acceptance once every criterion is met.

What it produces

• A verified deliverable, checked criterion by criterion against its acceptance criteria.
• An inspection record documenting what was checked and the result -- the evidence formal acceptance rests on.
• A list of defects or gaps routed back for rework, if any.

Common pitfalls

• Turning inspection into a rubber stamp -- confirming the deliverable exists or looks plausible rather than checking it against its actual, specific acceptance criteria.
• Letting the producer inspect their own work with no independent check, then presenting that as validation.
• Inspecting against criteria that were never written down, so the result is really just someone's opinion dressed up as a verification step.

Worked example

A city parks department has a deliverable: a redesigned playground, built to a signed-off design spec with named safety criteria (fall-zone surfacing depth, equipment spacing, accessibility clearances). Before the department accepts the playground from the contractor, the PM leads a walk-through inspection with the safety inspector and the original design lead -- not the contractor's own foreman -- checking each named criterion against the built result and recording pass/fail per item. Two clearances fail; the contractor reworks them and the inspection is repeated on just those items before the parks department signs formal acceptance.

Source

• PMBOK-6 §5.5.2.1

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