Antonio Trombetta
Continuous Improvement Consultant and Enterprise Agile Coach
Understanding cause-and-effect relationships is a critical skill when it comes to problem-solving. It is through careful identification of problem causes that countermeasures or solutions for problems can be designed, developed and put in place, minimizing the risk of implementing Band-Aids that simply address the symptoms of a problem.
Use of “Fish-bone” or Ishikawa diagrams has been part of the standard seven tools of quality since the early 1950’s. That said, simply brainstorming causes for a problem, grouping them as the team is building the diagram and “asking why” five times is probably not going to give the team the keys to the kingdom.
There is some discipline involved.
Let’s talk about reasoning!
When presented with a problem, people can react in different ways. They may not necessarily be aware. Team members may…
- Become defensive – It’s easy to raise self defense mechanisms to avoid paradigm shifts. When team members look for what is missing, what failed, or how things “Should be”. The team may be looking for something or someone to blame.
- Jump to “solution mode” – When participants make “educated” or informed guesses, based on the minimal data available. Participants start thinking about solutions. The team may want to take action right away.
- Look for the cause – When the team looks for the causes, the conditions or situations that are an actual prerequisite for the problem to present itself.
As you, and your team, brainstorm potential “causes” for the problem keep this in mind!
Team members “Playing Defense”
It’s expected that team members will feel a certain degree of dissonance when reality clashes with their ideals and paradigms. Their world view is challenged. Team members automatically think about how things “should be”.
Whenever you’re reviewing the outcome of a brainstorming session where you are looking for the causes of a problem, inspecting a fish-bone diagram or the outcome of “asking why” several times, and you see the words “No….”, “Lack of…”, “Missing…” listed as the possible causes for a problem, this is usually a sign of team members “Playing Defense“. “Lack of training and procedures” are typical examples.
The danger of these defensive statements creeping into your team’s fish-bone diagram is that, although they may be legitimate, they may not be what is truly causing the problem in the first place.
Team members “Jumping to Solution”
Here, your team, may face the compulsion to spring into action. Team members may rationalize this propensity by telling themselves that they don’t want to be bogged down by “Analysis Paralysis” or that their rationale is objective, when it’s clearly subjective and devoid of data and empirical evidence. Here you may find the team has brainstormed a list of potential causes peppered with possible solutions to a problem, trying desperately to counteract it’s symptoms.
If you see solutions coming out of the brainstorm session or grouped somewhere in your fish-bone, as answers to your “why” questions, you will know some team members have “Jumped to Solution“.
There is a time for you, and your team, to brainstorm solutions. The focus for the creation of the fish-bone diagram is to look for causes. It may be better to “park” those possible solutions in your meeting’s “Parking Lot”.
Looking for Problem Causes
Here are a few guidelines to keep in mind as you, and your team, brainstorm possible causes for a problem:
- Correlation does not equal causation. Just because two events or situations happen to have some relationship between them, it does not necessarily mean that one causes the other.
- Causation in its most simple expression is established with the following algorithm: If “A” happens, then “X” will occur. Essentially you can say “X” happened because “A”. For example: If I add four table spoons of sugar to my coffee, it will taste too sweet… for my palate, at least.
- An event, situation or problem may have multiple causes. So, if “A” can cause “X”; “B” can cause “X”; and “C” can cause “X”, this not disqualify either “A”, “B” or “C” as potential causes for “X”. For example: a printer may have a paper jam, or be out of paper. Either of these is a possible cause for a document not to be printed.
- Causation can occur only when multiple factors are put in play. For example: A fireman will tell you that in order for you to have a fire you need: fuel, oxygen and a source for the ignition.
- Causation may be hidden over time. For example: A psychologist could tell you that a childhood trauma is the cause for a phobia, a fear you have today.
You can use the aforementioned guidelines as a test of sorts to determine validity, when reviewing the outcome of brainstorm sessions, where you are looking for problem causation, before or while you are grouping possible causes into a fish-bone diagram.
Causal Trees
Your team can also build “Causal trees”. A variation of a fish-bone diagram. Here team members may graphically represent multiple chains or sequences of causation. “A” and “B” cause “C”, “C” causes the outcome, or problem “X”. For example: My daily caloric intake and daily exercise routine determine whether or not my daily calorie allowance is met, or exceeded. My daily caloric allowance is one of the causes for me to gain/lose weight. Unfortunately, this is just a branch of the causal tree mentioned to make the point, as you are also probably aware that there are other branches of that particular causal tree that will have an impact on weight gain/loss. As I am painfully aware, as well!
Parting thoughts
Whenever you are working with your team to resolve problems, it is best you identify root causes. This will allow your team to design countermeasures that can be implemented to resolve your problems in a sustainable way. Playing defense, or jumping to solution is a sure way to find yourself trying to solve the same problem, again…
For additional information, please don’t hesitate to contact me via LinkedIn or through my e-mail at antoniotrombettad@gmail.com