Kepner-Tregoe (KT) is a structured rational process for solving problems and making decisions. It has four parts: situation appraisal (sort and prioritize the concerns), problem analysis (find the cause of a deviation), decision analysis (choose among options), and potential problem analysis (protect the plan from what could go wrong). Its core discipline is describing a problem precisely before guessing at its cause.
KT earns its keep on the defects that resist the usual tools, the intermittent reject, the failure that appears on one line but not its twin, the problem where three plausible causes have already been fixed and it still comes back. This guide walks the four processes, focuses on the problem-analysis step that makes KT distinctive, and shows where it fits alongside your other problem-solving methods. For the broader map, see root cause analysis; for where structured problem solving sits in the wider toolkit, see lean manufacturing.
What is Kepner-Tregoe analysis?
Kepner-Tregoe analysis is a systematic method for thinking through problems and decisions in a repeatable, evidence-first sequence rather than relying on intuition. It was developed by Charles H. Kepner and Benjamin B. Tregoe, social scientists who studied decision-making at the RAND Corporation in the 1950s, and laid out in their 1965 book The Rational Manager. The premise is that people are good at gathering information but undisciplined about using it, they leap to a cause, get attached to it, and then bend the evidence to fit.
KT counters that by forcing separation. You describe the problem before you explain it. You define the decision criteria before you look at the options. You imagine the failures of a plan before you launch it. Each of the four processes answers a different kind of question, and mixing them, the usual failure mode in a war-room meeting, is exactly what KT is designed to prevent.
What are the four Kepner-Tregoe processes?
The four processes each handle a distinct kind of question, and knowing which one you are in keeps a meeting from spiraling.
Situation appraisal is the triage step. When several concerns land at once, a customer complaint, a yield dip, a late shipment, situation appraisal separates them, clarifies each, sets priority based on seriousness, urgency, and growth, and routes each concern to the right next process. It is the step that keeps a team from working the loudest problem instead of the most important one.
Problem analysis finds the cause of a deviation, a place where actual performance departs from expected performance for reasons unknown. This is KT's signature process and the one covered in detail below. It is disciplined description first, cause second.
Decision analysis chooses among options. You state the objectives, split them into musts (hard requirements that screen options out) and wants (weighted preferences that rank the survivors), score the alternatives, and then deliberately examine the risks of the top choice before committing. It is the rational counterpart to picking the option someone already favored.
Potential problem analysis protects a plan you are about to execute. You ask what could go wrong, judge each threat by probability and severity, and build in preventive actions (to lower the odds) and contingent actions (to limit the damage if it happens anyway). It is a forward-looking cousin of FMEA applied to a project or a launch rather than a design.
How does KT problem analysis work?
KT problem analysis works by describing the deviation along four dimensions, what, where, when, and extent, and, for each, capturing both what the problem IS and what it IS-NOT but reasonably could be. That IS / IS-NOT contrast is the engine. The differences between the IS and the closely-related IS-NOT point you toward the change that caused the deviation, because a true cause must explain why the problem shows up in the IS conditions and not in the IS-NOT ones.
An example makes it concrete. A sealing defect shows up on pouches from Line 2 but not Line 1, on the night shift but not day, on one film lot but not the previous one, starting last Tuesday. The IS-NOT is doing real work here: whatever you propose as the cause has to explain the Line 2 / not Line 1 split, the night / not day split, and the Tuesday start. A cause that cannot explain those boundaries is not the cause, however plausible it sounded. This is the same logic formalized in IS / IS-NOT analysis which KT originated.
| Dimension | IS (where the problem appears) | IS-NOT (where it could, but does not) | What the difference suggests |
|---|---|---|---|
| What | Seal peel on retort pouch | No leak on the tray line | Something specific to pouch sealing |
| Where | Line 2 only | Not Line 1 (same product) | A Line 2 asset or setting |
| When | Night shift, since last Tuesday | Not day shift, not before Tuesday | A change introduced Tuesday night |
| Extent | ~3% of night pouches | Not every pouch | Intermittent, not a hard failure |
Once the specification is complete, you look for changes between the IS and IS-NOT conditions, a new film lot on Line 2, a sealer temperature setpoint edited Tuesday, a relief operator on nights. Each candidate cause is then tested against the full specification: does it explain every line of the IS and IS-NOT, or only some? The cause that explains all of it, without special pleading, is the one to verify on the floor.
What are the steps to run a KT problem analysis?
The problem-analysis process follows a fixed order, and the order is the safeguard against jumping to a favorite theory.
- State the deviation. Write the problem as an object and a defect, "retort pouch, seal peels", not as a suspected cause. If your problem statement contains a cause, you have already skipped the analysis.
- Specify along what, where, when, and extent. For each dimension, record what the problem IS. Be specific: which asset, which shift, which lot, which date, how much.
- Capture the IS-NOT for each dimension. For every IS, ask what closely-related thing could show the problem but does not. This column is the one that discriminates between causes.
- Identify distinctions and changes. Find what is different or changed between the IS and the IS-NOT conditions. Focus on changes near the time the problem started.
- Generate possible causes. Draw candidate causes from the distinctions and changes, not from the room's opinions.
- Test each cause against the full specification. Ask of each: does this explain both the IS and the IS-NOT, in every dimension? Eliminate any cause that requires an excuse.
- Verify the most probable cause on the floor. Confirm it with an observation or a controlled change before you commit to a fix. A cause that survives the paper test still has to survive reality.
Kepner-Tregoe analysis: by the numbers
KT is a documented, decades-old method with a primary literature and an active practice:
- The method was formalized in Kepner and Tregoe's 1965 book The Rational Manager (later revised as The New Rational Manager), which grew out of their decision-making research at the RAND Corporation in the 1950s.
- The American Society for Quality catalogs KT among structured decision and problem-solving methods in its quality tools library, alongside the cause-analysis and decision tools it complements.
- KT's four processes are order-independent as entry points but discipline-dependent in execution: the value comes from keeping description separate from diagnosis, and diagnosis separate from decision.
When should you use KT instead of the 5 whys?
Use KT when the cause is genuinely unknown and the problem resists simpler tools; use the 5 whys when the causal chain is mostly visible and you just need to follow it down. The 5 whys is fast and works well when one clear cause leads to the next. It breaks down on problems with multiple interacting factors or an intermittent signature, because asking "why" five times down a single chain can walk you confidently past the branch that actually mattered.
KT's problem analysis is slower and more rigorous, and that is the point. The IS / IS-NOT specification forces you to account for the boundaries of the problem, why here and not there, why now and not before, which is exactly the information a single why-chain throws away. On a truly hard defect, KT is often the tool that turns "we've tried everything" into a specification precise enough to point at the one change nobody had connected. It also lives comfortably inside a larger framework: an 8D or A3 can use KT problem analysis for its root-cause step and KT decision analysis for its corrective-action choice. And once the cause is fixed, a line on your quality audit checklist is what confirms the fix is holding on later shifts.
The bottleneck on hard problems is rarely the method; it is the data the specification needs. Filling in the where, when, and extent columns demands accurate records of which line, which shift, which lot, and which date, and when that history lives on paper, the IS-NOT column gets filled with guesses. When capture is digital and traceable, the specification writes itself from real records, and KT delivers what it promises: a description precise enough that the cause has nowhere left to hide. That kind of live, queryable production history is the loop Harmony builds for plants, and the shift CLS made off paper logs. If you are also sorting which problems are worth this depth of analysis, the companion piece on the Kano model covers how to tell a customer-losing basic from a nice-to-have.