Problem Solving

Quality technique · See it on the map

Guide only — Diagnosing and resolving a problem is a judgment call.

A disciplined path from noticing something is wrong to a tested fix.

When to use it

A problem whose cause or best fix isn't already known, especially one with several plausible solutions worth comparing before committing.

When to avoid it

A known problem with a known standard fix — running a full problem-solving process on it only slows down doing the fix. Also don't use it in place of root cause analysis when the cause itself is the unknown: problem solving assumes the problem can already be stated, root cause analysis is how you find why it's happening.

Steps

1. State the problem in terms everyone in the room would describe the same way, and confirm it's actually the problem — not a symptom, and not someone's preferred fix in disguise.
2. Gather the facts and constraints that actually apply: what's fixed (budget, schedule, code) and what's flexible.
3. Generate more than one candidate solution before evaluating any of them — pressure-testing the first idea too early kills the second, possibly better, one.
4. Evaluate the candidates against the constraints and the problem statement, not against how politically comfortable each one is.
5. Select a solution, and decide up front what would tell you it isn't working.
6. Implement, then check against that signal — the process isn't done at 'we picked one,' it's done at 'we confirmed it worked.'

What it produces

• A documented decision: the problem, the options considered, the choice made, and the reasoning.
• An implemented fix with a defined signal for whether it worked.

Common pitfalls

• Collapsing straight from 'problem' to 'solution' without stating the problem precisely, so the team solves what a stakeholder said rather than what's actually wrong.
• Generating only one candidate solution and calling that a decision.
• No defined signal for success, so a fix that didn't work isn't noticed until the problem recurs.

Worked example

Larch & Rowe crews keep running out of a specific fastener mid-job. The easy jump is 'order more.' Stated properly, the problem is 'the reorder point is set below what a typical job actually consumes.' Candidates considered: raise the reorder point, switch to a supplier with faster restock, or pre-kit fasteners per job. The team picks pre-kitting, since it also cuts loss on site, sets a check (zero mid-job runouts across the next five jobs), and confirms it a month later.

Source

• PMBOK-6 §8.2

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