We face problems on a daily basis. Our success or failure often hinges on how effectively we deal with these problems. Problem Solving is an essential skill. Hence this article.
But what could be simpler? We have a problem. We provide a solution. Problem is fixed. Everything in the garden is rosy. Oh, if only it was that easy.
What we often see are the symptoms of the problem, not necessarily the root causes of the problem. Yet it is the root causes that we need to address to effectively eliminate the problem. When we provide a solution does it really fix the problem? How do we know? Also, will the solution introduce new problems in other areas?
So problem solving is not necessarily simple or straightforward. Fortunately there are many problem solving methodologies that can be used. I'm going to discuss two specific methodologies:
• Cause & Effect
• Solution & Effect
These are based on the use of diagrams which are often referred to as Ishikawa or Fishbone diagrams.
I've also divided this subject into two Ask Gordon articles. In this article, Part A, I will cover Cause & Effect and in Part B (next month) I will discuss Solution & Effect.
Identifying Roots Causes using the Cause & Effect methodology
There are a number of ‘standard’ Cause & Effect diagrams which provide different frameworks. The 6M approach is often used in manufacturing sectors whilst the 6P and the 4S may be more appropriate to the service sectors. The choice is yours. I will use the 6M approach in this article.
These frameworks can be applied in a practical manner with MindGenius. I do not use the classic fishbone diagram. I use the MindGenius input tree diagram. Purists may hold up their hands in horror, but it has proven to work for me. Hopefully you will see why as the article progress.
Let's look at a specific problem scenario. It's one that I have seen in many organisations.
Company A has a staff appraisal system in place. Basically it is a system of appraisal whereby a staff member and their immediate manager/supervisor meet to discuss how the staff member is performing and developing to the mutual benefit of themselves and the company. The intent is that potential issues and opportunities are identified and acted upon where agreed. However, a recent staff satisfaction survey has indicated staff dissatisfaction with the staff appraisal system.
So let’s start problem solving.
You'd be surprised how many people just go off half cocked. They instantly believe that they know what the problem is. Put in a solution. Walk away - that's it fixed. I often refer to this as the ‘Hero’ culture.
The first, and important, step is to understand the situation. I enter gather mode. I need to collect information to aid my understanding. I use the Cause & Effect diagram to facilitate this. The Effect is ‘Low staff satisfaction in staff appraisal system.’Causes? That’s the key question.
The 6M diagram provides me with a framework to start understanding the current situation. I start to talk to people using the 6M framework to ensure that the different potential perspectives of the problem are covered and that my approach is consistent.
I often attach an activity management map to the core of my map so that I ensure that I gather information from a representative cross section of sources.
This also provides a useful reference if there are any future queries on information sources.
The map soon builds up.
But. And as always there is a big but. You've only collected information and opinion which most likely reflect the symptoms of the problem. Not the root causes - the things that you need to identify and address.
Identifying the root causes is where the hard work begins. They don't often tell you that in the literature. To do this you need to interpret and analyse the information you have gathered. You need to rearrange the information you have gathered and group them against potential root causes. At this point I’m moving away from the 6M diagram. It has served its purpose in facilitating my information gathering. Now I have to move on. This is where I need to re-use the information I’ve gathered and use it to best effect. Hence why I mentioned before that I wasn’t concerned about using the input tree diagram rather than the fishbone diagram.
What the input tree diagram does is to pull the information together so that your brain can feed off of it and start to identify underlying issues (potential root causes). I walk through the map to familiarise myself with all of the content. If there are any significant gaps in the recorded information then I perform some more gathering activities.
As thoughts spring to mind during the map walkthrough, I develop another map of potential root causes. It would be great if there was a single root cause, but in practice you invariably find that the problem is brought about by a combination of a number of root causes. Which is why addressing a single root cause often does not solve a problem.
Then I assign categories to these potential root causes and attach the map to the core of my cause & effect map so that I can access it when required.
I then go back through my map and assign these categories where there is a potential linkage. There can be multiple root cause linkages from a single branch in the map.
Having assigned these root cause categories, I can quickly create a new category centric map based on the information already gathered.
The category concentric map can initiate a major re-think of the potential root causes if there appears to be lack of evidence supporting them.
Here’s what the resulting category map looks like for the methods parent branch from my Input Tree (Gathering) map.
Can you imagine how difficult and messy this would be to do on a fishbone diagram and even worse how would you do it on paper?
Indications from category concentric maps are that I’ve identified a number of root causes, hopefully all of them. So I am now in the position to consider what may be an appropriate solution(s) to implement. But that’s for next month’s article.
Some other things you could possibly do as part of the process.
• Identify the sources of the information using Resources.
• Categorise the information to show whether or not it is:
So that’s my approach to the first, and vitally important, part of problem solving – identifying the root causes of the problem.
As ever, if you have any queries, ask Gordon