Kepner-Tregoe Method: Rational Problem Solving and Decision Analysis

By Linh Ngo · Updated Oct 10, 2026

The Kepner-Tregoe (KT) method is a structured way to think through business problems and decisions. It splits the work into four rational processes: situation appraisal, problem analysis, decision analysis, and potential problem analysis. Each one uses a simple worksheet, so teams argue about evidence instead of opinions.

What is the Kepner-Tregoe method?

KT is a named problem-solving and decision-making method built around one idea: most bad outcomes come from jumping to an answer before the question is clear. It gives you a fixed sequence of questions, and each sequence ends in something you can write down and defend.

Its history is well documented by the company that carries the founders' names. According to the Kepner-Tregoe company timeline, Ben Tregoe and Chuck Kepner started the KT partnership in 1958 in Tregoe's garage in Pacific Palisades, California, and their book The Rational Manager was published by McGraw Hill in 1965.

The method is also quietly everywhere. Kepner-Tregoe says the German automotive association VDA's 8D publication emphasizes how the KT IS / IS NOT method can help earn an "excellent" rating in an audit. So if you've run an 8D report, you've probably already used a piece of KT without knowing it.

Key Facts

• Four processes: situation appraisal, problem analysis, decision analysis, and potential problem (or opportunity) analysis, as described by Purple Griffon.
• Origin: the KT partnership started in 1958, and The Rational Manager followed in 1965.
• Signature tool: the IS / IS NOT comparison, which tests each possible cause against what the problem is and what it is not.
• Decision rule: MUSTs are pass/fail screens. WANTs are weighted and scored.
• Best fit: high-stakes, ambiguous, or recurring problems where the cause isn't obvious and several people must agree on the fix.
• Weak fit: quick, low-stakes issues where a five whys chat does the job.

The four rational processes

KT treats the four processes as a toolkit. You don't always run all of them, and you don't always run them in order. But they answer four different questions, and mixing those questions up is where most teams lose time.

1. Situation appraisal

You start with a mess: ten complaints, three late projects, one angry customer. Per Purple Griffon's overview, this step lists all current concerns without solving them yet, gathers enough information to clarify each, and sets priorities based on urgency, impact, and available resources.

The discipline is the "without solving them yet" part. Your team's instinct is to start fixing the loudest issue. Situation appraisal slows that down for an hour so the right issue gets fixed first. For each concern you also decide which process comes next: does it need a cause found, a choice made, or a plan protected?

2. Problem analysis (IS / IS NOT)

Problem analysis is for a deviation: something that should work a certain way and doesn't, with a cause you don't yet know. The method defines the problem (what, where, when, and how big), collects data, lists possible causes, and tests each one against the data to find the most probable cause.

The IS / IS NOT table is the heart of it. For each dimension you record what the problem IS and, just as carefully, what it IS NOT but easily could have been. Then you look for distinctions, the differences between the two columns. Kepner-Tregoe notes that distinctions must apply only to the IS side, so "it's different" is too vague to help.

Here's a concrete case. An invoicing team notices that some invoices go out with the wrong tax rate.

Each possible cause then faces the same test: does it explain both the IS and the IS NOT data? A cause that explains why the new list fails but not why the old one works needs a stretch of assumptions. The cause with the fewest and most reasonable assumptions wins, and you verify it before acting.

3. Decision analysis (MUSTs and WANTs)

Decision analysis picks between options. Per Purple Griffon, you identify objectives as must-haves and nice-to-haves, generate alternatives, evaluate them, and choose.

The standard KT practice for that evaluation:

1. State the decision in one sentence, such as "Select a new carrier for regional freight."
2. Write MUSTs. These are mandatory, measurable, pass/fail. "Covers all five regional hubs" is a MUST. Any option that fails one is out, no matter how cheap.
3. Write WANTs. These are preferences, such as "lowest cost" or "real-time tracking." Give each a weight reflecting how much it matters.
4. Score each surviving option against each WANT, multiply by the weights, and total.
5. Check the top two or three for risk before you commit. This hands off to the fourth process.

If this sounds like a decision matrix, it is, with one useful twist: the MUST screen happens first, so a high score can't rescue an option that breaks a hard requirement.

4. Potential problem analysis

Potential problem analysis (PPA) looks forward. Once you've picked a fix or a plan, you ask what could go wrong, how likely it is, how bad it would be, and what you'd do. You then write preventive actions to reduce the likelihood and contingent actions to limit the damage if it happens anyway. Purple Griffon describes the same pattern: identify what could go wrong, plan preventive measures, and prepare contingency plans.

It's cousin to FMEA, though lighter. FMEA scores a whole process or product design in detail. PPA is a 30-minute pass on a single plan before you launch it.

Kepner-Tregoe vs other problem-solving methods

Teams often ask which method to use. The honest answer is that they sit at different levels.

A practical pairing: use a fishbone to widen your list of possible causes, then use IS / IS NOT to narrow it. And use the PDCA cycle to verify that the fix held.

How to run a Kepner-Tregoe session

Block 90 minutes for a real problem, and bring the people who touch the process, not just the managers.

1. List concerns. Put every issue on a wall. No fixing yet.
2. Triage. Rank by urgency, impact, and resources. Assign the next process and an owner to each.
3. Specify the problem. Write a one-line problem statement naming one object and one defect, such as "Wrong tax rate on invoices," not "invoicing is broken."
4. Fill the IS / IS NOT table. Push for real IS NOT entries. Thin IS NOT data is the most common failure.
5. Find distinctions and changes. Ask what's different about the IS side, and what changed near the time it began.
6. List and test possible causes. Test each against every row. Eliminate those that need strained assumptions.
7. Verify the most probable cause with a quick check or small experiment before you spend money.
8. Decide the fix with MUSTs and WANTs if there are several options.
9. Run potential problem analysis on the chosen fix.
10. Assign actions and a review date.

Ready-to-copy templates

Situation appraisal

Decision analysis

Potential problem analysis

Examples by business function

Do's and don'ts

Do

• Write the problem as one object and one deviation.
• Fill the IS NOT column with real, plausible alternatives.
• Make MUSTs measurable. "Good support" isn't a MUST; "24-hour response, written into the contract" is.
• Verify the leading cause before acting on it.
• Run potential problem analysis on any plan that's expensive or hard to undo.

Don't

• Don't brainstorm solutions during situation appraisal.
• Don't treat every WANT as a MUST. You'll end up with no options.
• Don't use the full method for a trivial, one-off issue. Over-process is a real cost.
• Don't skip the review date. A fix nobody checks is a guess.
• Don't let the worksheet replace judgment. Subjective weights can still introduce bias, as Purple Griffon's list of drawbacks points out, along with the training time the method needs.

When to choose KT

Choose it when the cause is unknown, several explanations are competing, and the team needs a record the next shift can follow. Pick something lighter, like a five whys conversation, when the chain of cause is short and the cost of being wrong is small. Plan on a few hours of practice; the first IS / IS NOT table feels slow and the third feels natural.

For related quality ideas, see total quality management, which sets the culture KT-style analysis fits into. If you want a cousin focused on defects and variation, Six Sigma uses DMAIC for the same purpose with statistical tools.