Don’t look for the single right issue tree… because there isn’t a single right one. There are several. And this is good news.

Think of issue trees as maps

Here is an anecdote that has another ten good years, tops (after that GPSs will have killed it). When I was a boy scout, we used maps to go hiking. If you hike in the mountains, you want to know about altitude differences. How do you represent altitude differences on a map? Well, there are several ways.

One way is to link all the points that are at a same altitude with a continuous line called a contour line. The map links all the points in, say, 10 meters increments so the closer two lines are together, the more pronounced the slope.

Another way is to use colors with, say, using colors as the altitude increases.

A third way would be to represent the object in relief, so have a 3D map.

Maybe yet another way, instead of contour lines, would be to have little flags with the altitude of each point.

Some ways to map are less effective than others. I haven’t seen any maps with little flags, as described above, and my feeling is that it’s probably quite impractical. So there are worse ways. But there isn’t necessarily a best way.

There may be one perfect issue tree, there is probably more than one good-enough trees

Well, it’s the same with issue trees. Your problem (the mountain that you want to map) can be broken down in various equivalently perspicacious issue trees. What matters isn’t to choose the best break down possible, because that would require you to think of them all. Rather, what matters it is to choose one that isn’t one of the worse ones.

When solving problems you have two extremes: not analyzing enough and analyzing too much. These are equally destructive because in the first you can’t find the right answer and in the second you might find it but too late.

So, again, balance satisficing and optimizing. Your first goal is to avoid satisficing: make your best effort to analyze sufficiently, i.e. don’t settle for the first break down that occurs to you without having at least a couple others to compare it to and decide which one is the most perspicacious. Your second goal is to avoid optimizing: recognize when good enough is good enough and avoid becoming pinned forever in the quest for the ultimate issue tree.

Use competing designs to improve your best issue tree and move on

When facing a new problem, take some time to develop the first level of all the issue trees you can think about.

Then step back, understand the “so what” of each issue tree and identify the two or three that look the most perspicacious ones. Develop those to another levels or two of detail.

Step back again, understand the “so what” and pick the most perspicacious one. But don’t discard the other ones! Rather refer to them frequently to ensure that the framework that you are using is indeed collectively exhaustive. Remember that you are mapping the same mountain/problem; so whatever element that appears in one of your issue tree must appear in the other one, maybe in a different shape, but it must be there.

In fact, if your problem is sufficiently important or if you can spare the extra work load, consider developing two issue trees in parallel to answer the same key question as a way to “check your math”. In an ideal situation have two different teams develop two different trees, just for a couple of hours. The result should be much richer than whatever you could have come up on your own following just one direction.