This entry is part of a multi-post case study. So, we're back to our cables negotiation. We've defined the problem and identified the basic framework for breaking down the key question. Next we need to build our diagnostic tree, why issue tree.Building the why issue tree / issue map essentially means breaking our diagnostic key question into parts (or issues) and breaking these parts into smaller parts (sub-issues), all the while remaining MECE in our thinking (and letting the answers be independent and collectively exhaustive, ICE*).

(*Even though the technical term is ICE, we'll use ICE and MECE interchangeably on this site.)

So building our tree requires us to do the same as we did in our previous post: combine innovation, in-depth thinking and good judgement to find frameworks that are both ICE and insightful.

How can we break down the reasons why we/our suppliers prevent the close of the negotiations? Maybe we can do it by following the negotiation process.

[IMAGE MISSING: 3.44-Breakdown-the-key-question-11.png]
The early stage of an issue tree, showing how to break the key question into two parts and how these branch off.

One way to breakdown the process is to think about it as first reaching an initial agreement and then closing that agreement. If we can't negotiate effectively, it is because either we can't do the first step or we can't do the second (or we can't do both, but that's a subset of the first two cases, so it's already considered and we can omit it).

Reaching a preliminary agreement and closing the preliminary agreement are ICE steps: one isn't included in the other (I) and the sum of the two is all we have to do to negotiate (CE), so we satisfy the first condition. But is it insightful?

Reaching a preliminary agreement requires us to interact with an external entity (our suppliers). Closing on the deal requires us to gain the necessary internal permission (from management, legal, engineering, etc.). These two actions have  different key success factors and they involve different stakeholders, so their implications are fairly different. To me, this is a good sign that it is a insightful-enough breakdown.

[IMAGE MISSING: 3.45-Breakdown-the-key-question-21-e1279909304709.png]
The logic tree continues, breaking each branch into smaller components.

Next we need to move to the following level of sub-issues. Why can't we reach a preliminary agreement? Again we need to find a good breakdown to analyze this. Again, maybe it's useful to look at the process. When you're diagnosing problems with which you're not completely familiar, it can be useful to reformulate them in terms with which you are familiar, that is, use analogies. Here we're essentially diagnosing a case of "why are we late to get to where we want?" Well, maybe it's because we left too late in the first place (that is, because we started negotiating too late) or because we spent too much time on the road (so we started negotiating on time but we lost too much time in the negotiation). Again, we can breakdown these further. In the end, we might have a first branch that looks like this:

[IMAGE MISSING: 3.46-Breakdown-the-key-question-31-e1279909628344.png]
The logic tree continues, breaking each branch into smaller components (cont'd).

When you breakdown issues into sub-issues, there are a couple of things that you should keep in mind. First, an issue cannot have only one sub-issue. If it does, it means that either -1- the issue and sub-issue can be combined into a single entry or -2- you are missing other sub-issues. This is a really simple rule of thumb but it's very useful to review your trees and make them stronger. Conversely, it is a good idea to use frameworks so that issues never have more than three to five sub-issues because it gets complicated to verify that your breakdown is indeed MECE when there are more elements than that.

Second, you need to decide when to stop the breakdown. I don't have a clear rule for that, just an indication: you stop the breakdown either when you can't divide an issue into two (or more sub-issues) or when it is self-explanatory by itself.

Next, we need to do that for the second branch.

[IMAGE MISSING: 3.47-Breakdown-the-key-question-4-e1279917119988.png]
The logic tree continues, breaking each branch into smaller components (cont'd).

Once we're done thinking about the reasons why we may prevent the timely close of negotiations, we can start thinking about why our suppliers may prevent them. Here you have to think if it makes more sense to use the same framework as the one we've just developed or if we're better off developing another framework.

Here again there are no clear-cut rules. You have to assess each situation and decide case by case. In this case I think it makes sense to use the same framework because, indeed, all the reasons we have identified for us might also apply to our suppliers. There are some more considerations for these types of scenarios but let's leave those aside for now and let's reuse the same framework as before. So we put everything that we've found so far in a box, call that box "1", and point to "1" in the next branch. In the end, we have our issue tree, at least the first part. Now we can move to developing and testing hypotheses.

[IMAGE MISSING: 3.48-Breakdown-the-key-question-5-e1279917684853.png]
In the end, the "why" issue tree shows all the potential root causes for our problem.