Workshop Exercises: Understand
Is / Is Not
Narrow down possible causes by comparing where a problem occurs with where it could but does not
Why: Find what is distinctive about the cases where a problem occurs, and weaken hypotheses that would also predict failure where none occurs
When: Use after a fishbone or brainstorm has produced several possible causes and the team needs to narrow them down before testing
Is / Is Not is a comparison of where, when, for whom and how much a problem occurs with where it plausibly could occur but does not, used to narrow down possible causes. It comes from the problem-analysis method developed by Charles Kepner and Benjamin Tregoe. Where a fishbone diagram widens the field of possible causes, Is / Is Not narrows it.
The key question is what the âisâ cases have in common that the âis notâ cases lack. A candidate cause should explain both: why the problem appears where it does, and why it does not appear in similar places. The Agency for Healthcare Research and Qualityâs summary of the method puts it this way: the most likely cause explains every aspect of the problem, and it should then be verified with an experiment where possible.
Worked example: incomplete product setup
This scenario and its observations are illustrative, not findings from a real investigation. It continues the example from the root cause analysis guide and the incident timeline: new accounts are failing to finish the company-details step.
| Â | Is | Is not (but plausibly could be) | Distinctive about the âisâ |
|---|---|---|---|
| What / who | New accounts get an error after pressing Continue on company details | Existing accounts editing company details in settings (confirmed in logs) | Only the setup step uses the new form component |
| Where | Mobile browsers when the field is autofilled | Mobile with manual entry (assumed: no ticket mentions it); desktop browsers (confirmed in logs) | Autofill on mobile |
| When | Since Mondayâs release, on the first attempt | Before Monday | The form component changed on Monday |
| How much | Nine tickets in four days; completion down for new mobile accounts | Other setup steps show no change in completion (confirmed in analytics) | Concentrated on one field and one step |
The team then tests its fishbone hypotheses against the table:
| Hypothesis | Would it also predict failure in the âis notâ cases? | Result |
|---|---|---|
| The next step is unclear | Yes: manual entry and desktop users see the same instructions, and the instructions did not change on Monday | Weakened |
| The completion event is missing | Yes: it would affect every path, and it does not explain the error customers report | Weakened |
| The campaign brought in more mobile visitors | It could lower overall completion, but it does not explain why autofill fails and manual entry does not | Does not explain the error; may still affect the metric |
| The new component does not capture autofilled values | No: it predicts failure only on the setup step, only with autofill, and only since Monday | Strongest candidate |
The strongest candidate is not yet a verified cause, and one of the âis notâ entries it relies on, manual entry, is only assumed. The table points the team to a specific test: compare manual entry and autofill on the affected browser and inspect what is submitted. The root cause analysis guide continues with that reproduction. Whether the campaign also contributed to the lower completion rate remains an open question to record.
Is / Is Not vs. fishbone and comparison
A fishbone diagram asks âwhat could cause this?â and is designed to produce many possible answers. Is / Is Not asks âwhat would a cause have to explain?â and is designed to rule answers out. Running them in that order keeps the team from narrowing too early and from carrying every idea forward untested.
Is / Is Not is also a structured form of the comparison step in root cause analysis. It compares affected and unaffected situations on paper. It does not replace reproducing the failure under the relevant conditions.
Limitations
The âis notâ column is only as good as its data. If âdesktop is not affectedâ really means âno desktop customer has complained yetâ, a hypothesis can be weakened for the wrong reason. Mark which entries are confirmed.
A surviving hypothesis is still a hypothesis. Fitting the table makes a cause more plausible and tells you what to test. It does not show the mechanism.
Several causes can interact. The method works best when one condition explains a sharply bounded problem. When causes combine, for example a defect that matters only under a particular traffic mix, the table can make each one look partial. Record that instead of forcing a single answer.
It needs comparable cases. If there is no plausible âis notâ for a row, leave it empty rather than inventing a distant comparison.
Instructions for running this play
- Prepare a problem statement about one specific problem, such as âNew accounts receive an error after pressing Continue on the company-details stepâ. Discuss it first thing and agree on the period and population it covers.
- Draw a table on a large surface with four rows, What / who, Where, When and How much, and three columns, Is, Is not and Distinctive about the âisâ.
- Do Silent Storming in a Timebox of 5-10 minutes on the Is column: exactly what fails, for whom, where, when and how often. Write the source of each entry on the note. Play back and merge duplicates.
- Fill the Is not column. For each row, write the closest comparable case that could plausibly be affected but is not. Mark each entry as confirmed by data or assumed.
- Fill the Distinctive column: what is true of the âisâ entries and not of the âis notâ entries? Next to each distinction, note anything that changed in or around it, and when.
- Bring in the candidate hypotheses, for example from a Fishbone Diagram. For each hypothesis, go through the rows and ask: if this were the cause, would it also produce failure in the âis notâ cases? Would it explain every âisâ entry? Mark each row â (explains it), â (contradicts it) or ? (unknown).
- A hypothesis that would also predict failure in the âis notâ cases is weakened. Record the hypotheses that survive, the rows each one cannot explain, and a test or reproduction that could verify the strongest. If several survive, continue with a Competing Hypotheses Matrix.
Tips to perfect this play
Master and adapt the play to fit your context and needs.
Tip: Choose a plausible "is not"
The useful comparison is the closest case that could have failed but did not: the same step on desktop, the same form with manual entry. "The billing page works fine" rarely tells you anything.
Tip: Confirmed or assumed?
Mark whether each "is not" entry is confirmed by data or assumed because nobody complained. An absence of support tickets is not the same as an absence of the problem.
Tip: One problem at a time
If the "is" column starts to describe two different failures, split them and run the exercise once for each.
Tip: Look for changes
For each distinction, ask what changed in or around it, and when. A distinction that coincides with a recent change is worth testing first.
Every card deck includes workshop patterns, so your team can put the methods to work in your next session.
Running behavioral design workshops? The Persuasive Patterns Workshop Playbook (PDF) shows you how to design and run them.
Browse the card decks- The Rational Manager by Charles H. Kepner and Benjamin B. Tregoe
- Kepner-Tregoe Matrix by Agency for Healthcare Research and Quality