How do you pick the right problem-solving approach when there are so many to choose from?

Do you ever have a problem actually getting going with your problem-solving activity? 

I remember, many years ago, being in a situation where, looking back, I’d already been taught most of the problem-solving tools I needed, yet couldn’t really see how to apply them and was almost paralysed like the proverbial rabbit in the headlights.

These days, there are more structures, templates and guides available, which should help. However, do I use 3C, 4C, 8D, PPS, A3, TBP, PDCA, DMAIC or what? Whether you understand what some or all of these are, have simply heard of them or are just baffled by a series of meaningless abbreviations, it can be hard to know what approach to apply when. 

Often I see individuals and teams introduced to a method and are left struggling to “fill in the form” without really understanding the principles behind it.

Which is a real shame because, stepping back and looking at all of the various methods (or at least those which really work) there is a simple set of steps that lead to a robust and sustainable resolution. The differences occur due to the nature and/or complexity of the problem, where in an organisation it’s applied, the level of experience of the individuals or teams, or simply the particular preference of the organisation/group working on the problem.

So let’s consider each of those aspects, see if we can “lift the fog” and help you to make better progress.

The Fundamental Steps of Problem Solving

Let’s start by reminding ourselves what we mean by a problem; in simple terms “a gap between where you are and where you want to be.” So, our task in problem solving is to “close the gap”.

The first important principle is to avoid simply tackling the symptoms of the problem and get to the root cause or underlying problem. This is like applying a sticking plaster over a wound without removing the piece of dirt trapped underneath – the problem will only fester and get worse rather than better. Of course, we may need to take some immediate action to “stop the bleeding”, but the need to address the cause is still there.

The “jump to conclusions” approach is a form of this. Someone says, “I know what the problem is!” and jumps straight into action. In their mind, they’re already assuming the cause of the problem and what action is needed. Now, don’t get me wrong, there will be some occasions when it’s so obvious that this is the right approach, and perhaps all that is needed is a “How can you be sure?” question.

However, in most cases, a more structured approach is needed and there are five steps that are common to most, if not all, structured approaches.

1.   Define the Problem

2.   Study the Problem

3.   Find the Root Cause

4.   Identify corrective actions (countermeasures)

5.   Apply corrective actions using a PDCA (Plan-Do-Check-Adjust) approach

Different methods will add other steps for specific purposes, break some of the steps down differently and so on, yet all follow this basic pattern.

1.   Define the Problem

“If you define the problem correctly, you almost have the solution.”

Steve Jobs

Often, in a group, I’ll ask each group member to write their definition of the problem on a large sheet of paper. Next, I’ll get them to share their definition with the others. Guess what? They’re all different! How can we work on a resolution when we don’t all agree what the problem is?!

So, the first step in an effective problem-solving approach is to create an agreed definition of the problem.

A great question for this is “what is wrong with what, and by how much?” 

This not only describes the problem clearly, but also gives it some scale. We might also ask, “when/where does the problem occur?” and “when/where does it NOT occur?” (You can use a method called “Is/Is Not” for this).

A key point is to keep the definition to facts rather than opinion or speculation. “What evidence do we have?” and “Can we demonstrate that with data?” are great questions to ask.

Equally, a problem definition should not include anything about possible cause or likely solution. All we are trying to do at this stage is to describe the problem.

Another key part of definition is to ask “what are things like when the problem is not there?”

Where we have a situation where something has been working well and something has changed so it’s no longer working, this “desired state” will be known.

Where our “gap” is actually an improvement - to reach a level of performance that we haven’t had before, for example – then we may need to do a little more work to define this.

At the end of this stage we will have clear definitions of:

·     the problem, backed by evidence (and data where possible) that everyone agrees on

·     the “desired state”; what the situation will be like when the problem has been resolved

2.   Study the Problem

“It isn’t that they can’t see the solution,

it is that they can’t see the problem”

GK Chesterton, Writer

For anything other than the simplest problems, it is rare that the Problem Definition stage will include enough information about the current situation to move forward. To be ready to think about cause, more detailed information will be required. This could be:

• Detailed observation of a task being carried out. This avoids assumptions based on what we think is happening and also prompts more questions.
• If there is a standard procedure, is it being followed?  If not, why not?  If there is, what additional insight do we gain?
• Collect and analyse data
• Discuss the problem with those involved
• Where we have identified opinions and assumptions, can we find evidence to support or contradict them?

The objective here is to get both an objective, broad and deep understanding of the problem to provide the insight needed for the next step.

3.   Find the Root Cause

Getting to the root cause of a problem is essential to prevent it recurring. It is important to be thorough to avoid simply addressing a deeper symptom.

At its most basic, we are seeking the answer to the question, “Why is this problem occurring?” A simple method for this is “5 Whys” – asking “Why?” several times (not always five) until a root cause becomes clear. Occasionally there may be ore than one possible answer and a process of elimination can be used to identify the root cause.

In very many cases, this simple method will be enough. For more complex problems, it may be necessary to consider a variety of possible causes and then apply 5 Whys or another method to dig deeper into each cause.

To start, identify as many possible causes as you can. Useful techniques here, particularly for complex problems) are Brainstorming, Affinity Diagrams, Fishbone diagrams (also known as Ishikawa or Cause & Effect) and Fault Tree Analysis. At this stage it’s important to consider as many different causes and types of cause to ensure nothing significant is missed, and these methods help to do that.  Crazy ideas are to be encouraged, as they can often yield valuable insight and lines of enquiry.

People are Stupid!

Sometimes the strangest idea for a possible root cause can yield the best results. The comment above was made by a member of a procurement team when we asked, “Why don’t people put the correct information on the purchase requisition?”

However silly the response seemed, it led to a consideration of the perspective of the form filler and why they might find it hard to complete all the boxes on the form. This in turn led to a series of corrective actions to make the form easier to complete and the necessary information easier to find.

In many cases, relationships between causes become apparent, some may be seen as “sub-causes” of others and so on. Evidence and data can be used to confirm or disprove the validity of some of the causes, therefore eliminating some.

Further experiments may be required to identify one or more possible root causes.

For most root causes, it should be possible to “switch on” and “switch off” the cause and see the effect on the problem come and go, thus confirming the root cause.

1.   Identify corrective actions (countermeasures)

Firstly, note that we don’t use the term “solutions” here yet. We won’t know we have a solution until we have verified that it works. So we use “corrective actions (or “countermeasures”) to describe actions we could take to eliminate the root cause.

It is likely that there will be multiple possibilities, so some method for identifying the “best” one (easiest to implement, most likely to succeed etc) will be needed.

2.   Apply corrective actions using a PDCA (Plan-Do-Check-Adjust) approach

Once corrective actions have been selected, they should be applied carefully (Plan). Once applied (Do), it’s important to make sure that the measure has the effect intended (Check). If it does, then the action can become part of “business as usual”. If not, it may be necessary to go “round the loop” again (Adjust) as we have new information about the problem.

Pick your method

“If the only tool you have is a hammer,

then you see every problem as a nail.”

Abraham Maslow, U.S. Author and psychologist

There are a number of factors to consider when selecting the particular method to be used. If the method is selected simply on preference or familiarity, you may end up heading towards undesirable extremes.

For example, if an over complex method is selected, it may be too demanding in terms of time and skill/experience required for relatively simple problems. For example, I’ve seen organisations insist on a “full 8D” for every problem when a much simpler method may have sufficed. Conversely, too simple an approach may miss aspects of the problem and merely address some symptoms rather than get to true root cause.

By considering the following dimensions of a problem, the right approach and tools can be selected to match the particular problem.

The Nature of the Problem

Is the problem fundamentally about:

• Equipment/Material/Software - something has broken or is performing poorly?
• Process (working procedure) - not being adhered to or not yielding the desired result?
• People - not demonstrating the desired behaviours or not delivering the expected level of performance?

The Characteristic of the Problem

Is the problem likely to have:

• An exceptional (special) cause – typically something has broken down or something unusual has occurred. Typically generates a REACTIVE response.
• A routine (common) cause – typically because results are more variable than expected or do not deliver the required level of performance. For the latter, maybe it never has or maybe the requirement has changed. Typically requires a PROACTIVE response and might be characterised as an improvement rather than a problem.

The Complexity of the Problem

Is the problem:

• A simple problem - typically a common daily issue, likely to be fixable by the team identifying the problem, with a linear relationship between cause and effect. This could be something like an equipment breakdown, a quality issue with supplied parts or operating procedure not being followed properly.
• A complex problem - likely to:

- involve multiple people/teams

- have a number of contributing factors rather than a single root cause

- have a “point of cause” in a different area from where the problem is experienced (e.g. a manufacturing problem caused by a design error, with the root cause being found in the design procedures)

- have an identifiable and provable root cause that can be “switched on and off” by making clearly defined changes

• A “wicked” problem - likely to be due to a complex interaction of equipment, process and people/teams, where true root cause is difficult or impossible to prove. Such problems cannot be “fixed” in the conventional sense and might be considered insoluble, in that they are resistant to resolution and where efforts to solve one aspect of the problem may reveal or create other problems.

Problems in this category are less likely to be “technical”, in the sense of relating to product, equipment or standard procedures, and more likely to relate to policy, strategy or organisational culture. On a global scale, we see seemingly intractable problems like poverty, education inequality and sustainability as wicked problems. In organisations, it’s issues like employee engagement, improving business-wide processes and managing complex change. They generally have a cultural dimension as the people element has so many variables.

Attempts to tackle "wicked" problems can often seem like a game of “whackamole.” An improvement in one area that you think is tackling a root cause yields an unintended consequence somewhere else. 

That doesn’t mean they are not worth solving. Indeed, making improvement in these areas can often be essential to success. They do, however, require wide-ranging study involving many stakeholders to develop an understanding of the complexities and acceptance that attempts to find a true “root cause” may be fruitless and too much analysis can be fruitless. Better to identify contributory factors and then experiment (using the PDCA approach) to see what helps and what doesn’t. Steady progress in a clear direction, even if you hit a few bumps on the way!

The ability and preferences of the individual/team

While some of the fundamental principles and the suitability of different methods and tools for particular types of problem will be constant, not everyone relates so well to each method or tool or has equal experience in applying them so, to some extent, this can also be a factor.

Equally, those new to problem solving are probably better to stick to a few key tools and really get to understand their use rather than trying to get to grips with the complexities of too many of them. In this context, understanding the principles and also the strengths and limitations of each method and tool will help teams and individuals to know whether the approach they are taking is suitable or if they may need to ask for help from someone more experienced.

For example, despite knowing that they are a key tool for investigating cause, I’ve never got along with Fishbone diagrams (a scary admission for a consultant!). Don’t know whether it’s me or the way I was taught, but there we are. I much prefer a more free form approach using sticky notes and grouping (Affinity Diagram or Web Chart) to identify common themes and causal relationships. In my view, the end result is the same and it works better for me.

So I think there is a case for allowing, even encouraging, some personal preference as long as the method and tools are appropriate for the problem being studied.

Each of these dimensions of a problem will require something different of the method and the tools to be used within the method.

Fortunately, the majority of problems (generally considered to be 80% or more) are simple problems with a clear (exceptional) cause for which a root cause can be found relatively easily and clear corrective action (countermeasures) identified.

For these, a simple method like 4C may be used with a tool like “5 Whys” to determine root cause. The four ‘Cs’ are:

• Concern (Define the problem)
• Cause (Find root cause)
• Countermeasure (Corrective Action)
• Confirm (verify that the concern is permanently resolved)

Introducing teams to the basic principles defined above and this simple method will enable them to tackle most problems independently.

For more complex problems, more sophisticated methods and tools will be required at each stage. The nature of the tools and methods will be appropriate to the characteristics of the problem. For example:

• For a suddenly occurring production problem where the cause is unknown and a quick evaluation using 4C has not yielded a root cause, the 8D (8 disciplines) approach is suitable (Practical Problem Solving (PPS), or Toyota Business Practices (TBP)/A3 are similar alternatives). This approach includes emergency and interim containment actions to prevent the consequences of the problem (e.g. poor quality product) reaching the customer. These responses are very much of the “sticking plaster” variety to allow time for the root cause to be identified and permanent corrective actions and prevent recurrence actions to be taken.
• For problems where there is a high level of variation that needs to be reduced, the DMAIC (Define-Measure-Analyse-Improve-Control) method is perhaps the most useful. Originating from Six Sigma, this method typically uses a high level of statistical analysis to identify the nature of variation and its sources. These lead, in turn, to improvement actions.

A full exposition of these methods and tools is beyond the scope of this article. However, a quick search on the internet will reveal plenty of sources on both. Read through the lenses of the principles in this article, it should be possible to select the right ones for the problem at hand.

In any case, it should quickly become apparent where an inappropriate method or tool has been used. For example, a production team applying a 4C may struggle identify a root cause or come up with multiple causes and be unsure where to go next. Escalation to a more experienced problem-solving practitioner may reveal that a more comprehensive method or a broader team is required. The work done so far will not be wasted, though, and there will be valuable data and knowledge as a foundation to move forward.

Avoiding Common Pitfalls

Through many years of personal experience and sharing stories with other practitioners, there are a number of common pitfalls encountered by inexperienced problem solvers.

I’ve mentioned some already – jumping to conclusions, wanting to rush into action without taking time to define the problem properly and religiously sticking with one method, like 8D, where it isn’t appropriate. Here are a few more I’ve seen frequently.

Missing the blindingly obvious

On occasion, I’ve experienced cases where a team has jumped into full-blown problem solving where properly defining the problem would have revealed the solution immediately. I frequently tell the story of my two friends and their attempts to fix a non-functioning brake light (see below). They soon get the point.

My brake light doesn’t work!

My friend Richard, a musician with little “technical” skill asked another friend, Grahame, an electrician, for help because a brake light on his car didn’t work.

Grahame set to with all his diagnostic skills and equipment and couldn’t find anything wrong in the wiring. He was just about to start to dismantle the dashboard to get behind the switches when Richard – understandably concerned at this stage – asked innocently “you did check the bulb, didn’t you?”

Grahame hadn’t. He’d simply assumed that Richard would already have checked something so simple and that there would be a deeper cause.

Relying on “what they think they know”

Problem solving activities are often carried out in a meeting room away from the location where the problem occurred.Statements are made about the problem and cause based on what the people in the room know – or at least what they think they know!I’ll encourage every problem-solving team to “go and see” for themselves to make sure that their assumptions are correct. This will often avoid going down blind alleys and often lead more quickly to understanding cause, as illustrated by the story of my colleague Martin from his days as a production manager.

Go – Look – See- Understand

My colleague Martin tells a story of his days as a production manager at the Rover factory in Birmingham. He got a call about problems with door locks and set off across the factory.

As he went, the team kept updating him. It’s only on cars produced on this shift. Then, it’s only the locks fitted by Fred.

Martin got to the location and started to watch Fred at work. He knew Fred was a committed colleague and, sure enough, he followed all the steps of the procedure and tightened up the bolts using a torque wrench. Then he did something unusual, he put the torque wrench in his top pocket.

Martin asked him about this. Fred’s reply was, “I know how important it is to torque these bolts correctly and the torque wrench is always missing, so I brought mine in from home.” Of course, Fred’s wrench was not calibrated and, despite his good intentions, this was causing the problem.

A simple observation and question avoided what could have been a lengthy problem-solving activity.

Getting too hung up on the method or tool

Even experienced problem solvers can become obsessed with following the steps of their chosen method precisely or always using particular tools for a particular step and occasionally get lost in the detail or focus on using the tool correctly rather than whether or not it is yielding the result required. 

It’s important to remember that the frameworks are there to guide you through the logic of solving the problem. Sometimes, for a given problem, the way that step is usually carried out doesn’t fit, or a different tool is more helpful. 

So, if it’s not quite working, step back, consider the principles and ask yourself “is this helping?” If not, try something else that may be more appropriate.

Not looking broadly enough for possible causes

It can be easy to get “stuck” in one line of thinking about cause or to miss one area of possibility altogether. Getting inputs from a wide range of people with different backgrounds and experiences will help here, as will have a checklist of possible “categories of cause” (e.g. people, equipment, method, materials, measurement, environment, leadership) can help ensure that the broadest range of possibilities is considered.

Wanting “the answer”

For tricky problems, teams can get stuck with a shortlist of possibilities and wonder how to get to the right corrective action. In some cases, the only way forward is simply to acknowledge that there may not be “one answer” to the problem and that a series of experiments is required to determine which possible cause has the biggest impact on the problem or which corrective action will have the biggest impact.

Conclusion

In summary, there are lots of great problem-solving methods and tools out there. In general, they have evolved to suit a specific organisation, situation or problem type, and it’s important to consider these aspects when selecting which to use.

More significantly most, if not all, effective problem-solving methods have a similar underlying structure based on some fundamental principles. Getting to grips these will help you to recognise a good model when you see one and also avoid getting lost in the detail.

Beyond that, gaining understanding of the specific context and purpose of a particular model or tool rather than simply the mechanics of it will help you and your teams make the right choice. Mastering the model or tool will amply reward the time invested in doing so.

Of course, as I experienced earlier in my career, it can be easy to lose clarity on how to set about tackling your particular problem when you’re stuck facing the consequences. That’s when using someone else, not so involved in the problem, can help. This can be someone with an external perspective, more experience, or simply a fresh pair of eyes. 

At an organisational level, an experienced external consultant can support you to select the right methods and structures for your organisation at every level and equip your organisation’s problem solvers to take effective action. If we can help you, please get in touch by phone, email or completing the contact form on the website.