Problem Solving Step 2/7: Structuring the Problem

Problem Solving Step 2/7: Structuring the Problem

So, now that we have defined exactly what it is that we are trying to solve, we have greater insight into:

  • Our SMART problem statement
  • Context
  • Scope
  • Stakeholders
  • Criteria for success / champagne popping
  • Barriers to implementation

We are now in a solid position to start analysing the different elements of the problem.

Remember, we are structuring the PROBLEM and not structuring the solution! We are in the divergent phase of problem solving – generating options and choices, not making choices.

So, what is the point of breaking down the problem? Remember the Underlying philosophy: Conceptually and analytically mapping out the different aspects of the problem (breaking the problem down) in a structured way helps us explore all areas of the problem and possible solutions in a logical way.

Conceptually meaning to understand the nuances, inter-relations and obscure factors at play in influencing the problem and any potential solutions.

Analytically meaning to logically break the problem down into component parts, understand how the system logically works together and determine which components are important versus less important.

This is, in my experience, the single most important part of the problem solving process and the most difficult. Finding effective solutions; finding creative solutions; finding innovative solutions all require a sound understanding of the underlying issues and how they work together or impact one another. The two most common ways I have seen people break down problems is either in a bottom up fashion or in a top down fashion, let me explain:

The d.school bottom up methodology

As one moves through the “Empathize” and “Define” parts of the Design School problem solving process, we capture a bunch of bottom up observations, perspectives and elements of a particular problem or opportunity. One then scatters these elements out and then proceeds to identify and group elements by themes (i.e. try and find the larger, more macro elements of the problem).  Then, considering the themes, one may find further ideas are triggered that can be added to the “buckets”.

The McKinsey Issue Analysis approach uses Issue Trees to try and push a more top down structure

My preferred methodology in Problem Structuring is to use Issue Trees. Before I go into how I find them valuable, let’s have a quick look at what an issue tree is.

An issue tree is a very simple framework of laying out the elements of a problem in a structured way.

I see Issue Tree’s as being “mind maps on steroids” as they take the scattered divergent ideas and apply some disciplined logic and structure to turn ideas into thinking. An issue tree is simply a graphical representation of the different elements of a problem and how they inter-relate. Lets have a look at a simple financial issue tree. As it is mathematical, it is easy to grasp:

You can see from the graphic that the logical grouping of ideas makes sense. You can very quickly see how I am thinking about the problem and how the different elements relate to one another.

Here is a second example of a non-mathematical issue tree:

Simple examples.

Normal methods rely on generating a comprehensive list of the right hand side elements of the tree. This is very difficult to do as we mentally move down rabbit holes really quickly. For example:

If I say, how can we save on expenses? You immediately jump into expense mode and go down the rabbit hole listing things like: paper, pencils, staff, cleaning fluid, toilet paper, water, food, etc, etc. This mental shift isn’t always helpful. At this point in understanding the problem it is equally important to understand both the depth AND THE BREADTH OF THE PROBLEM. There may be big buckets of opportunity and drivers of the problem that we are missing because we are mentally shifting to a “cost cut stationary” mind set.

One of the principles that McKinsey is famous for is being MECE. This stands for mutually exclusive and collectively exhaustive. In simple terms, your problem solving structure has no gap and no overlaps. Why is this principle useful? As discussed, it is very difficult to know when you have “listed” all elements of the problem. How do you know when to stop? Taking the issue tree framework and applying a MECE lens to it will help you determine whether there are some macro or micro elements that you are missing in your structure.

For example, if we look at the first tree: Profit is only mathematically made up of revenue minus cost. That means that the first level of my issue tree is MECE.

When looking at revenue, it can only be made up of volume sold multiplied by price. These two don’t necessarily overlap as I can sell the same quantity at a higher price or I can keep the price the same and sell more. MECE. If we had to take this section of the tree down to further drivers, you will see it becoming more complicated:

It does become harder and harder to be MECE. However, MECE is a principle and a guideline to push disciplined disaggregation of the problem. It isn’t a law. It is virtually impossible to make everything MECE.

The other critical factor to using Issue Trees effectively is to make sure your levels are as consistent as possible. If I had put “Cost of pencils” at the same level as “Increase Revenue”; I wouldn’t be able to use my issue tree to test for MECE’ness. Consistency is important in how the tree is structured. Here is a great example of an issue tree that I was given and the power of testing for MECE’ness:

The Problem Statement was to improve quality and compliance in customer service operations

Firstly, you can immediately see how the manager was thinking about the problem. To get this manager to explain this to me would have taken ages. Within one minute I can get a snapshot of what was in her head. Super effective in efficient collaboration! The first thing I did was start to label themes on the buckets that jumped out at me:

I immediately noticed that the major buckets all referred to a “bigger bucket” called Quality Assurance (i.e. monitor and check if people are adhering to quality standards). That resulted in a mental step back to say, “hang on, there is stuff we need to do before and after quality assurance…  This allowed us to identify two other major buckets to consider:

As you can see in the revised Issue Tree (the initial tree is in grey) there were two other large buckets that needed to be considered. My manager had gone down a Quality Assurance rabbit hole.

This clearly illustrates the power of the issue tree as a disciplined problem structuring tool and a very effective collaboration tool to share thinking and get input.

What about hypotheses?

What I generally do with my issue trees is to ask questions for the first couple of levels. Once you get to “How do we decrease stationary cost?” it is generally more effective to start generate hypotheses at this point (i.e. “Reduce paper usage” and “Reduce price paid for paper”)

If you jump to hypotheses too soon, you will start converging too soon. Remember, we are generating choices here. Dump everything. Even crazy ideas. Suspend judgement. Let the madness flow.

I was once problem solving with someone on secondary sources of income. We laughed and joked and started talking about drug dealing. Although we would never have considered this a possibility, it sparked a perfectly legal idea: sell supplements. Supplements like Herbalife or Weider. We added it to the tree and realised there was a whole bucket of “Sell stuff part time” that we hadn’t thought about.

Suspend judgement. Go crazy. Be wacky. Be creative. Look at the problem and solution space from all possible angles. Be MECE.

How do I know when my tree is right? You never will. You will know if your tree is helpful.

If you show it to a team mate or colleague and their reaction is “wow, that’s insightful! I never thought about that part of the puzzle!” then you are on the right track. Try multiple trees. Build it top down. Take post-it noted, brainstorm and build it bottom up. Create collages. Search for frameworks on the internet.

But bring them back to a tree so you can logically and easily test for MECE’ness!

Use your team.

Build your own issue tress and then come together and mould them into a bigger tree.

Take a break and play some table tennis and then go back and have another look.

Show your boss. Show your husband. Show your dog!

Show experts. Explain it to muppets.

Do anything to show people how you are thinking and how you are disaggregating the problem to see if there is anything logical, crazy or creative that you may be missing.

 

 

 

 

 

Problem Solving Step 3/7: Prioritisation

Problem Solving Step 3/7: Prioritisation

Embedding Strategy: McKinsey's 7S Model

Embedding Strategy: McKinsey's 7S Model