Five Whys digs down. Kepner-Tregoe draws a fence around the problem first. Often the fence alone tells you the cause.
What it is
Charles Kepner and Benjamin Tregoe developed their methods at the RAND Corporation and published them in The Rational Manager in 1965. Their problem analysis is built on one simple table.
You describe the problem in four dimensions. For each, you write what it is, and what it could be but is not:
| Dimension | Is | Is not |
|---|---|---|
| What | What object, what defect | Similar objects, similar defects that don't have it |
| Where | Where it's seen, where on the object | Where it could be but isn't |
| When | When it started, when in the cycle | When it could have happened but didn't |
| Extent | How many, how big, trend | How many could have it but don't |
Then you ask: what's different or changed about the "is" side compared to the "is not" side? Possible causes must explain both columns. A cause that explains the "is" but not the "is not" is wrong.
Why it's powerful
People jump to causes. "It's the new operator." Kepner-Tregoe asks: then why does the problem only happen on Line 2, when the new operator also works Line 1? The "is not" column kills bad theories fast.
Why people skipped it
Filling in the "is not" column takes data. Someone has to pull production records, shift logs, lot numbers and complaint dates. It's quicker to guess.
How a bot does it
A bot can sort through records and fill both columns from facts.
- Give it the records. Complaints, defect logs, production data, change logs, shift schedules.
- Have it fill the is / is not table with evidence for each cell.
- Have it list distinctions: what's true of the "is" side and not of the "is not" side.
- Have it list changes around the start date.
- Have it test each possible cause against both columns.
- A person verifies the top cause, ideally by test.
The bot brief
Run Kepner-Tregoe problem analysis.
Problem statement: [one line]. Records: [files].
Fill an IS / IS NOT table for What, Where, When, Extent. Every cell must cite a
record. If the data isn't available, write NO DATA and say what to pull.
List distinctions (true of IS, not of IS NOT) and changes near the start date.
Propose possible causes from the distinctions and changes.
Test each cause: does it explain every IS? Does it explain every IS NOT?
Rank causes by how fully they explain both columns. Recommend one verification test.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
Problem: the weekly report bot sometimes shows the wrong week's sales.
| Is | Is not | |
|---|---|---|
| What | Sales figure wrong | Order count, owners: correct |
| Where | Reports sent Monday | Reports sent Thursday |
| When | Since Sept 2 | Before Sept 2 |
| Extent | 4 of 7 Monday reports | 0 of 7 Thursday reports |
Distinction: Monday reports run before the sales file is refreshed at 9 AM. Thursday reports run in the afternoon. Change on Sept 2: the Monday report routine was moved from 10 AM to 8 AM.
Cause that explains both columns: the routine now runs before the sales file updates. Verification: run Monday's report at 10 AM once and compare.
Notice that "the model is unreliable" doesn't survive the table. It doesn't explain why Thursdays are fine.
Where bots differ
The table is only as good as the records. A bot can't fill "is not" from data you don't keep. When the bot writes NO DATA, that's useful too: it tells you what to start logging.
A bot can also force-fit a cause. Make it show, cell by cell, how each cause explains both columns.
What this means for you
- Before blaming anything, fill in the is / is not table.
- Have a bot pull it from your records.
- Throw out causes that don't explain the "is not" side.
- Verify the winner with a test.