Don’t get lost in the terminology

Don’t get lost in the terminology

Apr 18, 2011

Issue trees, issue maps, logic trees, how trees, why trees, diagnostic trees, solution trees, decision trees, fact trees, hypothesis trees… How should you call your trees?

Your favorite consultancy has its own terminology and so does the rest of the world. Unfortunately, they don’t coincide, so here is an attempt at making things clearer.

The short answer is that there isn’t a clear, common nomenclature. At Accenture, we called both “why” and “how” trees “issue trees”.

That’s because both types raise and answer questions or issues—we used the two terms interchangeably. McKinsey talk about “logic trees” in the same way.

Then you’ll hear people talk about hypothesis trees and fact trees or data trees. The first ones are useful to uncover the root causes of a problem and the other two help identify potential solutions. But that, in my opinion, is misleading: indeed, both hypotheses and facts are present in all types of trees, so calling a tree by the type of elements it contains doesn’t really help. Instead, I think it makes more sense to call them by what they do.

Call your tree what you want it to do

So here is what I think makes the most sense:

1. There are two types of trees: diagnostic and solution. A diagnostic issue tree identifies the root causes of the problem by answering a key question formulated with a “why”. A solution tree is very much alike a decision tree: it identifies various ways in which one can solve the problem, that is, answer a key question formulated with a “how”. (A solution tree is not entirely a decision tree because, these require branches that are truly mutually exclusive and they usually end up with the expected value of each branch, which isn’t a common feature  of a solution tree.)

2. Both types of trees are logic trees or issue trees. The aim of both types of trees is to bring logic in the problem, helping us be MECE (or ICE, really), so it makes sense to call them logic trees. But both types of trees are also question—or issue—based, so it makes sense to call them issue trees as well.

3. Both trees raise questions and include hypotheses. Furthermore, both types of issue trees spell out the analysis needed to test hypotheses and uncover facts. When asking “how do I get from NYC to London?”—which is a solution tree so, one would think, a fact/data-tree—I need to make hypotheses. By plane, by boat, by submarine, swimming, etc. are all possible logical solutions and must be included in the tree, but until I have validated that they are indeed potentially acceptable answers to my original problem they remain hypotheses.

4. You can’t mix “why” and “how” questions in one same tree. Because a tree’s functionality is either to understand the root causes of the problem (diagnostic trees) or to identify various potential ways to solve it (solution trees) but not both at the same time, you can’t have both types of questions in the same structure. I am not saying that you should answer only why or how questions in your analysis; indeed, in general, a complete analysis requires to first develop a diagnostic tree and then develop a solution tree. I am saying that both these types of questions are important, but they don’t come at the same time in the analysis. So, first, understand the real problem (e.g. do I have a headache because I’m dehydrated, because I have brain cancer, or because of another reason), then solve it (e.g. I’ll take an Advil vs. I’ll start chemotherapy).

[IMAGE MISSING: Screen-shot-2011-04-18-at-10.15.49-AM-e1303139801129.png]
Use the right type of tree for the right action.