Benchmarking

Scope technique · See it on the map

Runnable here

Comparing your project against similar organizations or projects to find a useful target, a gap, or a practice worth copying.

When to use it

Use it early in requirements work when you need an external anchor: a competitor's feature set, an industry cycle-time norm, a peer team's staffing ratio. It is especially useful when stakeholders disagree about what 'good' looks like and an outside reference can settle the argument better than another round of opinions.

When to avoid it

Skip it when no genuinely comparable organization or project exists -- a forced comparison to a dissimilar peer produces a number that looks authoritative and is not. Also skip it as a substitute for talking to your own stakeholders: benchmarking tells you what others do, not what this project's sponsor actually needs. Treat it as one input to Collect Requirements, never the whole exercise.

Steps

1. Name the specific attribute you're benchmarking (cost per unit, cycle time, feature set, defect rate) -- not 'how are we doing', a single measurable thing.
2. Pick two or three genuinely comparable organizations or projects; document why each is comparable so the comparison survives scrutiny later.
3. Gather the comparison data from public sources, industry reports, or direct contacts -- note the collection date, since these numbers age.
4. Line your own planned or current value up against each benchmark and note the gap in both directions (you may already beat some of them).
5. Turn each meaningful gap into a candidate requirement or a target metric, and hand it to Collect Requirements or Define Scope for the stakeholders to accept, adjust, or reject.

What it produces

• A short comparison table (attribute, your value, each peer's value, gap).
• One or more candidate requirements or targets derived from the gaps.

Common pitfalls

• Comparing against a peer that only looks similar (same industry label, wildly different scale or context) and treating the gap as meaningful.
• Using stale data without checking it -- a two-year-old industry figure quoted as current.
• Stopping at the comparison table and never converting a gap into an actual requirement someone owns.

Worked example

A mid-size clinic network is scoping a new patient portal. The PM benchmarks average appointment-booking time against two similarly sized clinic networks that publish their support metrics: 90 seconds and 110 seconds median, against the current 4 minutes on the clinic's existing phone-based process. That gap becomes a candidate requirement -- 'online booking completes in under 2 minutes for a returning patient' -- which goes into requirements collection for the sponsor to confirm.

Source

• PMBOK-6 §5.2.2.2

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