This entry is part of a multi-post case study.

So we've developed our why tree: we've identified all the potential reasons why we're having our problem and we've organized these reasons in such a fashion that they only appear once in the tree. Next we need to test these hypotheses. That requires you to do four things: -1- plan out how you're going to test each hypothesis, -2- identify in which order you'll test them, -3- conduct the actual test, and -4- conclude (identify the root causes of your problem).

Identify how you'll test your hypotheses

The next column of your issue tree is to capture ways to help you test your hypotheses.

In our negotiation example, the first hypothesis is to test whether we prevent the timely close of negotiations because we think that starting the negotiations late helps our bargaining position. How can we test this? Maybe we can ask the lead negotiator(s). If there's a historical trend, we can also ask previous lead negotiators. Further we can review company guidelines/policies to see if anything is there. That's all good info, capture it in your issue tree.

[IMAGE MISSING: 3.50-Information-sources-questions1-e1280461553559.png]
A why issue tree, going from the key question all the way to an interview plan.

So you get points for identifying the right source for your information, but you get extra points if you go further and spell out what question(s) you want to ask each source. That's because you'll end up with the same sources for many hypotheses (usually, your clients, your management/boss and specialized literature). So if you can already think about the questions that you want to ask each, you are already developing your interview questionnaire or your research plan!

Cover all elements in the issue tree with one analysis

Each element in your tree doesn't have to have an individual hypothesis. That's for two reasons: first because you'll have so many hypotheses that it would be really easy to get lost in your tree and second because it doesn't make sense. We've made our tree collectively exhaustive, that means that we've considered all the reasons why we think we have our problem in the first place. Surely some of these reasons are very unlikely and don't deserve the same amount of analysis as some of the "usual suspects". So group your hypotheses in the most perspicacious way; as long as each element of the tree is in a source, you'll be fine.

Order the analysis

By the time you identify the sources and the questions for each you should have a pretty big tree. So next you'll need to identify which one(s) is/are the primary source of the problem.

To do so, you can proceed in one of two ways: -1- take them in the order that they appear in the issue tree and study them one by one or -2- prioritize them in some fashion and analyze the most likely first. Although the first manner is the most thorough, it is also the most time consuming and you might not have the luxury to do it. So, instead, let's look at effective ways to prioritize assumptions. The first way is to evaluate the probability by yourself based on your experience. An alternative is to ask for help.

Ask others to help you rank hypotheses

We've talked in the past about the importance of enlisting others in problem resolution, because if used correctly, groups are smarter than (even the smartest) individuals (James Surowiecki has a thought-provoking book on this subject); well, now is a good time to do so. You've identified a series of potentials explanations for your problem. If you have a team of knowledgeable individuals about the issue, now is a good time to ask them to help you.

Now the first trick is to assemble a group of individuals that have each a reasonably consistent knowledge about the issue. If you're going to ask to a group in which  you have both experts and total beginners, you might want to discriminate their response accordingly, maybe by giving more weight to the responses of experts.

The second trick is to ask the group to be as objective as possible. They need to understand that this exercise is not a blame game or an opportunity to show others how great their own division is doing. No, this is about looking at the problem as objectively as possible and identifying the best explanation for the problem.

[IMAGE MISSING: 3.49-Hypotheses-table-e1280447570441.png]
The third trick is to ensure that everyone's answer is as unbiased as possible. If you put your team into a room and ask them which hypothesis they think is the most likely, whatever answer that will come out first will color every answer thereafter. By making the thinking process collective, you essentially reduce the likelihood it diverges. Instead, I like to ask the team to rank their opinion individually and, if you think it might help, anonymously. Then I collect the answers, process them into a ranking and share the ranking with the team: once we've diverged we can now converge.

Test your hypotheses

Our example has some 8 analyses (see column "sources" in the topmost figure, above). That's pretty standard; in fact, it's pretty low, in part because we haven't developed the second branch of the tree. The point is that you want to reduce these to a tractable number; that's 2-4. Hopefully your ranking will allow you to single out these 2-4 main hypotheses that are most likely to be the real source of your problem.

Once you've tested your primary hypotheses stop and step back: do you feel that these explain enough of the problem? If not go back to your ranking, select the next 3-5 most likely hypotheses and analyze those. If you do feel that your set of original  hypotheses explain enough of the problem—say, 80% of it—congratulations! You've uncovered the root cause of the problem. You can now move to identify solutions.