This entry is part of a multi-post case study. You’ve identified your problem. You’ve uncovered its root causes by building a why tree and by testing hypotheses. So you’ve covered the first two steps of the problem-solving process. Next, you need to identify solutions.

This requires you to reformulate your problem: you need to find a new key question and then build a logic tree; but this time it will be a how tree.

[IMAGE MISSING: 3.51-Results-of-why-analysis-1024x740.png]
Issue trees are also a great way to capture your analysis.

Let’s get back to the cables negotiation. Assume that, by the end of your hypothesis-testing step, you’ve identified that most of the problem was due to three elements:

• Because we start negotiating on time but lose too much time in the negotiation (and you estimate that this explains for 40% of the delays),

• Because key people aren’t involved in the negotiation (another 35%), and

• Because the suppliers prevent a timely close (some 15%).

The other hypotheses account, collectively, for the remaining 10% of our negotiations problems. So, you’ll probably want to invest your efforts in the first three and leave the others for later, if you decide to consider them at all.

In fact, within these three, you’ll probably want to go back to the third branch of your tree, the one corresponding to suppliers, and break it down into further detail. Indeed, our first two hypotheses are fairly detailed and explain a big part of our problem but that third one is very vague. By the time you break it into parts, maybe these 15% will be very diffuse and not worth your time. Anyway, that’s optional, so if it sounds too complicated don’t worry about it.

Write a new problem identity card

You’re now ready to actively look for solutions for your problem. The first step is to reformulate it, this time with a ‘how’ key question.

[IMAGE MISSING: 3.52-Cables-negotiation-second-PIC-e1280764768356.jpg]
A problem identification card summarizes all the relevant information necessary to understand the problem.

As before, we write a problem identification card. This one doesn’t have to be very different from our first. In fact, in the context, the situation and complication can remain the same. Only the key question changes. In the scope, since we’ve identified that a significant part of the problem is ours (vs. our suppliers’), it will be useful to involve our own key players in developing the issue tree with us. Why? First because, as a team, we’ll be smarter. Second, because they’ll probably be more convinced by the solution we propose if they’re the ones that proposed it in the first place; and therefore they’ll be more likely to implement it.

Develop a how issue tree / issue map to generate solutions

Next, we need to develop a second logic tree, the how tree. The basic rules are the same: be MECE and perspicacious.However, there are a few differences compared to our why tree. First, we are now replying to a how question, so all the items in the tree must be actions. It’s a good idea to start each item with an action verb: that helps us stay on target.

[IMAGE MISSING: 3.53-Cables-how-tree4-1024x842.png]
A how issue tree, showing the different ways in which we can answer the key question.

Second, you’ve already done quite a bit of work to identify the principal causes of your problem in the first place, so—although a completely MECE ‘how’ tree would need to include all reasons—it is fair to include in your ‘how’ tree only those  reasons that have the highest impact and to decide that your tree is MECE-enough. In our cables negotiation case, we’ve estimated that four factors explain some 90% our problem so it makes sense to discard all other factors.

Third, you can’t really use processes (more on that here), so you’ll have to modify your thinking process: don’t try to identify all the necessary and sufficient conditions to do each action, rather think about all the different ways in which you can do each action. Remember that your only limits are the items that you’ve placed in the out-of-scope section of your problem identification card. All other potential solutions are fair game… and therefore must appear in your tree.

Your ‘how’ tree has a key question on the left and proceeds to the right with potential solutions, essentially saying: “by doing this, I can solve my problem”. The further it goes to the right, the more detailed the action. That goes until you get to a point where you are explicit enough. We’ll talk more about what is ‘explicit enough’ but a good rule of thumb when you start with logic trees is: just a bit more than you think is necessary. Let me explain why.

Much value of logic trees comes from -1- organizing your thinking (MECE, perspicacious) and -2- identifying concrete, precise solutions. So far, we’ve done a lot of organizing, both in the ‘why’ and in the ‘how’ tree. But the right side of your ‘how’ tree is where you get to work on the second value generator: identifying concrete, precise solutions. Don’t get lazy here and stop your thinking at the level of generic categories. Instead, force yourself to go deeper in details than you think is necessary because even if you won’t apply most of the ideas you come up with, these can be triggers for other ideas that you’ll apply.

So go deep in detail. When you’re done, group items into hypotheses. One rule applies here: all the items in your issue tree must be associated with one hypothesis. To be clear, an hypothesis can apply to various items at the same time, but all items must be included in hypotheses.

So, as in the ‘why’ tree example, group items as you see fit. My way of doing this is to form very small groups of items when I think a branch can add a lot of value, and groups with many items when I don’t think they can bring much value. That way, I’ll try to funnel my energy where it matters most.

The result for the cable case study is in the figure above. In the next post, we’ll talk about testing these potential solutions.