Expert Judgment

General technique · See it on the map

Guide only — Expert judgment is, by definition, not encodable.

Asking someone experienced for a judgment call instead of working the answer out from scratch yourself.

When to use it

The question needs judgment a specialist has built up (an estimator's feel for a task, a lawyer's read on a clause, a senior engineer's sense of where a design will break) and getting a data-backed answer instead would cost more time or money than the decision is worth.

When to avoid it

When the evidence already exists and asking someone is just faster than looking it up — you'll get an opinion where a fact was available, and it will read as more authoritative than it is. Also avoid it when only one expert is reachable on a decision with real consequences: a single unchallenged opinion presented as 'expert judgment' is how a guess becomes policy. If the same person is asked the same kind of question every time with no record of what they were told, you've built an oracle nobody can audit.

Steps

1. Write down the specific question before contacting anyone — a vague ask produces a vague, unreviewable answer.
2. Identify who actually has standing on this question (role, past experience, certification) rather than who is easiest to reach.
3. Give them the same background material and constraints you'd give a second opinion, so their answer is comparable to one.
4. For a consequential call, get more than one opinion and note where they agree and where they diverge.
5. Record the question, who answered, what they were told, and their answer — not just the conclusion.
6. Fold the judgment into the deliverable it informs (an estimate, a risk rating, a design decision) and keep the record attached to it.

What it produces

• A documented judgment: the question asked, who answered it and on what basis, and how it fed the deliverable it informed.

Common pitfalls

• Asking only one person and treating the answer as settled fact.
• Not recording who was asked or what they were told, so a later reader can't tell whether the input was informed or offhand.
• Reaching for an expert because gathering real data felt like more work, when the data was gatherable.
• Letting seniority stand in for relevance — the most senior person in the room is not automatically the right expert for this question.
• Anchoring: showing the expert your own guess before asking theirs.

Worked example

A PM planning a warehouse retrofit needs a rough duration for re-routing overhead conduit around a new mezzanine. No historical data exists for this exact configuration. She writes the specific question, sends the drawings and constraints to two electricians who've done similar retrofits, and asks each independently. One says three days, the other four, both citing the same conduit run as the risk. She logs both answers with their reasoning, uses four days with a note on why, and attaches the log to the estimate.

Where it comes from: this technique is named by the PMBOK Guide, 6th edition. No clause number is recorded for it here — a guessed citation would be worse than none. Cross-cutting: PMBOK-6 lists it as a tool of nearly every process rather than defining it at one clause.