I don't like the phrase "tame problem" because it suggests that the solutions are easy when they often are not.
The term tame problem is intended to mean that the problem can be tackled in a structured step-by-step approach. That it can be contained within definable boundaries.
The vast majority of business and organisational problems are tame problems and are dealt with using structured decision making.
My other course – "Problem Solving and Decision Making: Creatively," covers the steps you would use, with a problem-solving team – to develop solutions to these sorts of problems.
I am not going to repeat that course here – so please take that course if you want more detail on the methodology – but I will cover some of the main points. And I will introduce some new tools that you can use with Tame Problems.
First, let's explore the concept of the Tame Problem a little more.
What Is a Tame Problem?
Tame Problems are problems where the ingredients are familiar. We know the components of the problem and have likely encountered a similar type of problem before.
In short, we are familiar with the territory of this type of problem. We know there is likely to be a solution, and we work through a standard problem-solving methodology to get there.
Structured problem-solving works well for this type of problem. Heart surgery is an example of this type of problem. It may be complex and risky, but we can develop a route to a successful outcome that minimises the risk.
In business, developing a new product, launching into a new market, or improve production processes would all follow this route.
Not all problems are Tame Problems. Some have many interconnected causes where there is unlikely to be one "best" solution. Those are Wicked Problems, and we will come to them later in the course.
Trying to solve a Wicked Problem like a Tame Problem – with a logical method – doesn't work, and we need new methods for those problems. However, the good news is that, in business, there are a few Wicked Problems.
The Problem-Solving Method
Most problem-solving methods follow a six-step structure:
-
Form a problem-solving team with a mix of thinking styles.
-
Define the problem.
-
Analyse the problem.
-
Generate ideas.
-
Test the solutions.
-
Decide: select and implement a solution.
Problem-solving tools are used to help us define the problem, analyse it, and generate solutions to resolve it, and we'll come onto some of those now.
Tools for Solving Tame Problems
My three favourite tools for structured problem-solving are as follows:
-
The Problem Statement and Goal Statement.
-
Process Mapping.
-
The Ishikawa Diagram (also known as the Fishbone Diagram).
I covered these three tools in some detail in my course "Making a Start with Business Improvement." I'll only cover them in summary here, and you may wish to refer to that course for more information.
The Problem Statement and Goal Statement
The problem statement is a great tool for summarising the issue or problem the improvement team is seeking to address in three or four sentences.
One of the first things that an improvement team should do when they meet is to define the problem they are facing, and we use the Problem Statement for this.
The Problem Statement is a short definition of the problem described in a way that anyone can understand. To create a problem statement, the improvement team should consider the following questions:
-
What is the business problem we're trying to address?
-
Who is affected by this problem, and how? This helps identify the stakeholders in the problem.
-
What are the consequences of the problem for each stakeholder?
-
What are the impacts of the problem on the process, the organisation, and the customer? And we should quantify those impacts if possible.
The Problem Statement
Here's an example problem statement:
"Currently our delivery service is unreliable with 20% of items not arriving in the delivery window specified to the customer.
An average of 40 customer complaints a day relate to poor delivery performance. This results in dissatisfaction and frustration for customers, significant compensation costs, and loss of future sales."
If you can't define the problem in two or three sentences, then you don't understand the process or its problems well enough!
The Goal Statement is the opposite of the Problem Statement. It is a short vision statement of what we would like to achieve by addressing the problem.
Based on the problem statement you have created:
-
What would we like the process to achieve when the problem is solved?
-
What will the benefit be to customers and the organisation?
-
How will key metrics be impacted by the improvement (targets are appropriate here)?
Example Goal Statement
For the delivery problem was saw in the Problem Statement, our Goal Statement might be:
Our aim is to consistently reduce the number of deliveries outside of the specified window to less than 5%, reducing customer complaints, and reducing compensation claims due to poor delivery performance to 10% of the current level."
The Problem Statement and Goals Statement are really useful tools to help us define the problem we are working on and to set the vision for the future state – how the business process will operate when the problem is resolved.
Process Mapping
When we have a problem we want to resolve, it is often useful to understand the business process in which the problem occurs. Process mapping gives us the context for the problem and, very often, identifies the precursors to the problem.
Creating a process map helps us see the big picture of the business process we are having issues with.
It helps how workflows through the business process – every step and activity – from when the customer places an order, or the user places a request, to the moment he or she receives the product or service.
Seeing every twist and turn in the process enables us to identify issues, constraints, and problems in the process. The process map shows us the elements that lead up to the problem arising. Often the solution to the problem lies in addressing those earlier elements – the presenting problem may just be a symptom of other hidden problems in the process. Only by resolving those hidden problems will we actually eliminate the presenting problem.
Process mapping really is the best way to understand how a process works and how and where a problem occurs. You might want to search online for some examples of process maps.
The Ishikawa Diagram
The Ishikawa Diagram provides a structured way for an improvement team to examine the root causes of a problem. The team analyse the problem from six points of view, to give a broader understanding of the issues involved.
The six points of view examined by the team in the Ishikawa Diagram are:
-
Materials – the materials and tools used at the point the problem occurs.
-
Methods – the procedures and working instructions in place.
-
Measurement – the sufficiency and accuracy of the data and measures collected.
-
People – the skills and capabilities of the people working in the process where the problem occurs. Note we do not seek to blame the people, but rather identify any weaknesses in terms of skills, knowledge, training, communication, competence, etc.
-
Machines – the equipment used in the process, including IT systems.
-
Mother-Nature – any uncontrollable issues that may have contributed to the problem (such as freak weather conditions, or accidents).
More branches can be added to the diagram if needed. For example, I often add "Management" as a branch to cover any deficiencies with the way the process is managed, or weaknesses in company policies. "Environment" may be included to cover the working environment and health and safety factors. "Systems" may be added in processes heavily reliant on IT systems and where a separate category from "Machines" is desired to distinguish IT problems.
In the example on the screen, we see that the problem is items getting damaged when sent to customers, and the possible causes include.
Thank you for listening to this lesson. In the next lesson, I will introduce some new tools for problem-solving.
