Chapter Three

Diagnose your problem

Chapters 1 and 2 showed how to summarise a complex problem in a Hero-Treasure-Dragon-Quest (HTDQ) sequence. As part of the process, the Watson rule advised you to check all assumptions in your HTDQ sequence. Following Watson is usually non-trivial, as it often requires uncovering the root causes of your problem – or diagnosing it. Let’s look at how to do that.

Misdiagnosing engine troubles on BD 092 resulted in the crew framing the problem poorly, leading them to ask the question ‘how do we manage our malfunctioning right engine?’ when the left engine was the malfunctioning one. As it happens, poor framing is also common in the corporate world: In a two-year study we conducted at IMD, over 55% of executives we polled reported observing poor framing during strategic decisions in their organisation.2

So, we shouldn’t feel that problem framing is a foolish expense of time separating us from getting things done, but rather an investment that is helping us build a robust foundation for the rest of our problem-solving efforts. In addition to the framing techniques you have acquired in ­Chapters 1 and 2, conducting a good diagnosis can help you frame effectively.

Now, you might ask why we propose to frame before diagnosing. Well, to start looking for the root causes of a problem, you need to have a sense of where to look. Otherwise, you risk ‘boiling the ocean’, that is, looking at everything imaginable but without having the time to analyse anything in detail. To be sure, diagnosing will probably lead you to adjust or even completely change your initial framing, and that is completely fine, as long as you have planned enough time to do so. However, the initial frame, consisting of a hero, a treasure, a dragon and a quest, will provide you with a first sense of where to direct your diagnostic efforts.

You can diagnose your problem using a two-step approach: First, identify the potential root causes, which you can do by using a why map – a visual breakdown of the problem’s potential root causes. Second, identify which of these potential root causes are actually at play.

DRAW EFFECTIVE WHY MAPS BY FOLLOWING THE FOUR MAP RULES

Let’s first consider how to identify potential root causes. Imagine that you have just been appointed the general director of a company, and you discover that it is not profitable. Why might this be the case? Maybe you are failing to attract enough new clients? Or perhaps your raw material costs are too high? Or maybe another factor is at play. Ultimately, making your company more profitable depends to a large extent on your ability to identify the underlying root cause (or root causes as there might be more than one). Just like the British Midland pilots who turned off the wrong engine, if you focus on reducing your raw material costs when what is really driving down your profits is that you don’t have enough revenues from new ­clients, chances are that your measures won’t be very effective.

The complex problems you face have lots of potential root causes, so considering them all is usually challenging. In addition, some are causes of others, which makes untangling them difficult.

Just as a map can be invaluable when navigating an unfamiliar territory, mapping out the potential root causes of your problem can also be immensely useful. That’s where drawing a why map comes in.

Let’s walk through a why map. Imagine that your company isn’t profitable. Why could that be? Well, low profitability might originate from two reasons. Either your revenues are too low or your costs are too high (or both, yes, but that’s already accounted for in these two so let’s not repeat it). Pushing your analysis, you might hypothesise that your revenues are too low because your revenues from new clients are too low or your revenues from returning clients are too low. Similarly on the cost side, high costs might result from high fixed costs or high variable costs, and the latter might be driven up by high raw materials costs or high effort costs. You get the idea.

Using this mapping technique, you can identify all the potential root causes for your problem by moving in two dimensions: vertically, you explore new kinds of root causes; horizontally, you get into more details. Mapping is an effective way to actively structure the universe of potential root causes of a problem. So it’s worth learning how to develop why maps. Effective why maps follow four rules. Let’s look at them.

Mapping rule 1: Why maps answer a single why question

To kick off the diagnosis, choose which aspect of your frame you’d benefit most from looking into. In principle, you can concentrate on any aspect of the quest with a why question: ‘Why this hero?’, ‘Why this treasure?’ or ‘Why this dragon?’ All of these questions might be interesting and relevant. However, we have found that it is usually most beneficial to focus on either the treasure or the dragon. For instance, you may question why a specific treasure is important to you, or why you failed to get it in previous attempts. Similarly, you may want to better understand your dragon by asking why your dragon is a problem, or why you haven’t already overcome your dragon.

In an ideal world, you would have the resources to ask several of these why questions . . . or perhaps even all! In practice, however, your resources are limited, so you will often only be able to ask one. Therefore, your challenge is to identify which why question would bring you the most. As with choosing your quest, engage your core stakeholders to help you generate several candidates, compare them, and select the best one.

Once you’ve chosen your why question, start drawing your map. Good maps are clear, so clear in fact that they look simple. But as with Hero-Treasure-Dragon-Quest sequences, achieving that simplicity is usually challenging.

Mapping rule 2: Why maps go from the question to potential root causes

Within a map, you move by asking two types of questions. Horizontally, asking why? helps you get into more detailed potential root causes. Vertically, asking what else? helps you uncover new kinds of potential root causes.

Toyota’s Total Quality Management approach advises that you uncover the root causes of the problem by asking why five times.4 That’s a good general rule, but you might benefit from asking why more times for some branches and fewer times for others. More than the number of levels, what matters is that you develop the map sufficiently so that its items, the so-called nodes, are no longer conceptual (e.g. ‘because our raw materials costs are too high’) but concrete (e.g. ‘because we use 10% more carbon fibre in our products than is needed’). That is, you should use however many levels of whys it takes to get to a point where a reasonably knowledgeable person won’t ask: ‘So, what does this mean more specifically?’ Note that you might not need to develop all branches to the same level – some might be sufficiently explicit after just a couple of levels while others might need many more. This disparity is perfectly fine.5

In your why map, follow simple guidelines to make your thinking clear and concise:

• •Use full declarative sentences.6 Phrase each node as a full declarative sentence that answers the question. That is, make each node an idea, not just a title. That will help you and others avoid ambiguities. Consider for instance a map that answers ‘why isn’t our company profitable?’ with a node that simply states a title, say, ‘revenues’. That node is ambiguous: what about the revenues? Are they overly diversified, decreasing, widely differing across units, or too small? If the node just states ‘revenues’, people reading the map will need to interpret it, which will yield differing interpretations. Conversely, by making each node an idea – ’because our revenues are too low’ – you remove the ambiguities. People might still disagree with your logic, and that might trigger a debate, which is great, but at least your thinking is understandable.
• •Phrase nodes in a clear, consistent manner. Aside from using declarative sentences, you can dramatically increase the quality of your why maps by phrasing nodes clearly and consistently. First, start each node with ‘because’. This is only fair, since you’re answering a why question. Also, use a parallel phrase structure within a given group of nodes and highlight the elements that are changing.

  You might be tempted to ignore this recommendation. After all, the fewer the words, the better, so omitting ‘because’ should help. But after coaching hundreds of people on drawing maps, we find that those who structure their nodes following these guidelines consistently show better logic. We think that this is because forcing us to abide by this structure forces us to clean up our thinking.

• •Synthesise your map in formal root causes. Developing a why map often results in dozens of nodes, making it impractical to analyse each independently. Instead, it makes more sense to cluster them into judicious formal root causes. To keep things practical, aim for two to five such root causes.

Mapping rule 3: Why maps are MECE

One key success factor of effective why maps is their MECEness. MECE (pronounced ‘me-see’) stands for mutually exclusive and collectively exhaustive. MECE thinking refers to the process of organising a set of items so that you are accounting for each exactly once.7

For a concrete example of how MECE thinking works, imagine that while driving you get to a t-junction. What can you do? Well, you may continue straight or turn left, but you can’t do both at the same time. These two alternatives are mutually exclusive; that is, doing one precludes you from doing the other. In other words, the alternatives don’t overlap.

At the t-junction, however, going straight and turning left aren’t your only two alternatives. You may also reverse, stop, change direction, or do a few more things.

If you list all potential alternatives, then the list is collectively exhaustive. There are no gaps in the list of alternatives.

A MECE list, then, has no overlaps (ME) and no gaps (CE). Being collectively exhaustive, you don’t forget any alternative, so you’re thoroughly creative. Being mutually exclusive, you force yourself to understand how the alternatives relate to one another, so you’re clearer in your thinking.

MECEness is a simple concept. Making your thinking MECE, however, usually isn’t trivial. If you are lucky, your problem breaks down into clean-enough parts, such as what to do at a t-junction. However, if your problem involves more nebulous concepts – developing a business model, getting people motivated, reshaping an organisation’s culture – making your thinking MECE can be challenging.

To summarise, good maps have a MECE structure. Their branches are mutually exclusive, which means they don’t overlap. In the profitability example above (see p. 81), if your map’s top branch investigates how low revenues might be the reason why your company isn’t profitable, then your bottom branch should not also cover revenues. Addressing revenues in the top branch of your map precludes you from also addressing it in the bottom branch. Avoiding such duplications, you keep things clear.

The branches should also be collectively exhaustive, leaving no gaps. Since profitability equals revenues minus costs, addressing revenues and costs is sufficient, and your map shouldn’t address other themes.

So far, we have talked about what MECE thinking is, but we haven’t given you concrete ideas on how to make your thinking MECE. We’ll do that in the next chapter, but here’s one idea: To help you be CE, don’t judge your ideas. Include all the potential root causes of your problem in your why map, no matter how improbable they are. This is because you don’t know what you don’t know. Include all the logically valid answers to your why question, no matter how seemingly outlandish they are. Don’t auto-limit yourself; ideate now, you’ll evaluate later.8

Mapping rule 4: Why maps are insightful9

A good why map has a structure that is both logically valid and useful. Let’s go back to our profitability example. On the first level, one avenue is to break down the question into the components of profitability – ­revenues and costs – as we’ve done. But there are other ways to start the map. Pause for a minute and try to identify at least one.

For instance, we could break down the key question by looking at the profitability of each of our product lines. If we choose this approach, all we have to do is assemble a MECE list of these product lines.

Or we may look at whether our lack of profitability is an old problem versus a recent one.

The point is that there is always at least two ways to break down a question or a node in the map. These avenues might not be easy to find, but they exist. Identifying at least a couple is valuable because it helps you look at your question from different perspectives, which might trigger fresh insights.

In the end, you can only start your map with one of the structures you consider. So, which should you use? Well, the most insightful one of course! In the profitability example above, given that all three candidate structures are logically valid, insightfulness comes down to usefulness, and which of these structures is most useful depends on your circumstances. If, for instance, your profitability varies greatly across product lines, it might be most insightful to use the second candidate structure, as it will help you tackle the lines that are problematic and leave alone the ones that work well. Similarly, if your lack of profitability is a recent issue, using that third candidate structure might help you ask that all-important ‘what changed?’ question. With this in mind, you may want to start drawing your own why map.

CONDUCT YOUR ANALYSIS

All we’ve done by drawing a why map is lay out the potential root causes of our problem. Sticking with our scientific approach and the probabilistic mindset it entails, each of these is nothing more than a hypothesis that needs to be tested.

Next, we need to investigate whether evidence supports or opposes these hypotheses, which you can do with the four-step LEAD approach:10

1. 1Locate the evidence. Identify and gather the types of evidence relevant to the hypothesis.
2. 2Evaluate the evidence. Assess the quality of the piece of evidence.
3. 3Synthesise the evidence. Assess the body of evidence as a whole, understanding its ‘so what?’.
4. 4Decide. Identify whether you can accept or reject the hypothesis or whether more information is needed.

One important consideration: favour opposing evidence. For instance, let’s assume that we want to test the root cause: ‘our company isn’t profitable because our revenues from new clients are too low.’ Relevant evidence will affect the likelihood of the hypothesis, increasing it (for supporting evidence) or decreasing it (for opposing evidence). But beware, as focusing on supporting evidence can promote overconfidence.11

Note that running a rigorous analysis helps you develop robust insights, which will increase the likelihood of finding a more impactful solution. But that rigor will also probably improve your engagement with your key stakeholders as you will be able to show that you were thorough and impartial in collecting and assessing evidence.

For each hypothesis, you will probably find both supporting and opposing evidence.12 It is a fact of life (although not a pleasing one!) that evidence is usually incomplete, inconclusive, and ambiguous. Furthermore, our biases push us to look for evidence that supports our views, which can lead to all sorts of troubles. Therefore, we are better served looking for opposing evidence. To this end, identify what evidence would change your mind and try to get that evidence. Your job is to seek the highest quality evidence that you can find – focusing your efforts on finding opposing evidence – to, in the end, decide whether you ought to reject that the hypothesis you’re testing is indeed a root cause or accept it.13

At last, keep in mind that establishing that a hypothesis is indeed a root cause does not exonerate other hypotheses. Sometimes, our profitability is low because our revenues are low and our costs are high.14

UPDATE YOUR QUEST – REFRAME THE PROBLEM

Uncovering your problem’s root causes helps you understand your problem better. For instance, your diagnosis might lead you to conclude that your company is not profitable because your revenues are low. Updating your Hero-Treasure-Dragon-Quest sequence to incorporate that insight will make it more specific: Instead of asking a broad ‘How should we increase our profitability?’ question, you can now ask ‘How should we increase our revenues?’ Or your diagnostic might lead you to realise that your issues expand beyond profitability, leading you to reframe your problem as ‘How should we increase our return on investment?’

The point is that return on investment, profitability, and revenues are interrelated concepts, part of the same set of Russian dolls. Which one you address depends on your circumstances, and you won’t know until you consider different parts of that set of dolls. Diagnosing helps you choose the focus that will have the highest return; that is, where investing one unit of effort will generate the largest dividends.

We strongly encourage you to put these ideas into practice by drawing your own why map (here, too, the Dragon Master™ app can help). Once you’ve run your diagnostic analysis, modify your HTDQ sequence to reflect what you’ve just learned.

Summarising, all that we have done in Chapters 1, 2 and 3 was in the name of developing as good a quest as we could. Next, we’ll switch gears and explore alternatives – that is, potential answers to this quest.

CHAPTER TAKEAWAYS

Addressing a symptom instead of the underlying disease can result in an ineffective effort, so you should diagnose your problem. As a general rule, assume that what you think the problem is when you first encounter it isn’t the problem that you should solve.

Drawing a why map can help you identify your problem’s potential root causes. Effective why maps obey four rules:

• •Mapping rule 1: They answer a single why question.
• •Mapping rule 2: They go from the question to potential root causes.
• •Mapping rule 3: They use a MECE structure.
• •Mapping rule 4: They are insightful.

Evaluate the likelihood of each root cause by analysing relevant evidence, striving to obtain as high-quality evidence as possible – particularly ­opposing evidence.

Thinking MECE means that you leave no gaps and no overlaps in your thinking. Be prepared: making your thinking MECE can be extremely ­challenging! Becoming good at it takes practice.

Being CE will require you to think beyond conventional ideas. Some of these creative ideas will feel odd or dumb, but it’s worth considering them, because you don’t know what good ideas they can spark, so don’t auto censor.

In the end, conclude on your problem’s root causes and synthesise your analysis by updating your frame.

CHAPTER 3 NOTES

1.   1Air Accidents Investigations Branch (1990). Report on the accident to Boeing 737-400 G-OBME near Kegworth, Leicestershire on 8 January, 1989 (Aircraft Accident Report 4/90). HMSO. London.
2.   2A majority of executives who come to IMD . . . . During a two-year study at IMD, we asked over 450 senior managers and executives to share the prevalent issues that they observed in their organisations during problem solving and 55% of the respondents reported framing issues. These results were consistent across geographies, industries, and seniority levels.
3.   3See pp. 16–24 of Kelley, T. and D. Kelley (2013). Creative confidence: Unleashing the creative potential within us all, Currency.
4.   4See, for instance, Arnheiter, E. D. and J. Maleyeff (2005). ’The integration of lean management and Six Sigma.’ The TQM Magazine 17(1): 5–18. Chapter 7 of Andersen, B. and T. Fagerhaug (2006). Root cause analysis: Simplified tools and techniques. Milwaukee, WI, ASQ Quality Press. Card, A. J. (2017). ’The problem with ”5 whys”.’ BMJ Quality & Safety 26(8): 671–677. Chiarini, A., C. Baccarani and V. Mascherpa (2018). ’Lean production, Toyota production system and kaizen philosophy.’ The TQM Journal.
5.   5For a discussion of when to stop going into more details, see pp. 65–67 and 123–124 of Chevallier, A. (2016). Strategic thinking in complex problem solving. Oxford, UK, Oxford University Press.
6.   6This approach parallels using an assertion-evidence structure for designing slides, which has been shown to enhance understanding and recollection. See Garner, J. K. and M. P. Alley (2016). ’Slide structure can influence the presenter’s understanding of the presentation’s content.’ International Journal of Engineering Education 32(1): 39–54; and Garner, J. and M. Alley (2013). ‘How the design of presentation slides affects audience comprehension: A case for the assertion–evidence approach.’ International Journal of Engineering Education 29(6): 1564–1579.
7.   7MECE is old. Some consultants like to say MECE thinking is a McKinsey thing, but it’s been around for a long time. It has been present in philosophy for centuries (initially formulated by John Duns Scotus in the thirteenth century) and it’s an essential part of probability theory.
8.   8See, for instance, Basadur, M. (1995). ’Optimal ideation-evaluation ratios.’ Creativity Research Journal 8(1): 63–75.
9.   9Maps are popular. Our question maps – the why map of this chapter and the how maps of the next – are just one of many visual tools to solve complex problems. For a review, see p. 47 of Chevallier (2016).
10. 10Adapted from pp. 89–92 of Sim, L. J., L. Parker and S. K. Kumanyika (2010). Bridging the evidence gap in obesity prevention: A framework to inform decision making. Washington, DC, The National Academies Press. (And, yes, the adaptation means that the LEAD acronym no longer works but we kept it because LESD is slightly less catchy.) Working with evidence can be tricky. Working with evidence can rapidly get technical. So, for a start, follow the four-step process outlined in this chapter. If you’re interested in more, see Tecuci, G., D. A. Schum, D. Marcu and M. Boicu (2014). ‘Computational approach and cognitive assistant for evidence–based reasoning in intelligence analysis.’ International Journal of Intelligent Defence Support Systems 5(2): 146–172; and Tecuci, G., D. Schum, M. Boicu, D. Marcu and K. Russell (2011). ‘Toward a computational theory of evidence-based reasoning.’ 18th International Conference on Control Systems and Computer Science, University Politehnica of Bucharest. For an in-depth treatment of how to work with evidence, see Anderson, T., D. Schum and W. Twining (2005). Analysis of evidence. New York, Cambridge University Press.
11. 11See Walters, D. J., P. M. Fernbach, C. R. Fox and S. A. Sloman (2017). ’Known unknowns: A critical determinant of confidence and calibration.’ Management Science 63(12): 4298–4307.
12. 12For a brief discussion of how to work with evidence, see pp. 97–102 of Chevallier, A. (2016). Strategic thinking in complex problem solving. Oxford, UK, Oxford University Press. For an in-depth treatment, see Anderson, T., D. Schum and W. Twining (2005). Analysis of evidence. New York, Cambridge University Press. Promoting evidence-based reasoning. The University of Melbourne’s SWARM project strikes a sweet spot between structuring analysis and letting teams use their specific strengths to make predictions. See Van Gelder, T., R. De Rozario and R. O. Sinnott (2018). ‘SWARM: Cultivating evidence-based reasoning.’ Computing in Science & Engineering 20(6): 22–34.
13. 13Formally, we cannot accept a hypothesis but only fail to reject it. However, here we’ll just say ‘accept’ for simplicity sake.
14. 14In medicine, this condition is called comorbidity. See First, M. B. (2005). ’Mutually exclusive versus co-occurring diagnostic categories: The challenge of diagnostic comorbidity.’ Psychopathology 38(4): 206–210.