Today it is time to go deeper into our problem-solving by continuing to ask why to leave the product level’s root cause(s) and enter the organisational level. This is a very important step to be able to judge if the root cause to the original problem was in fact organisational or not. We continue with our engineer at the engineering department.
After six months, the fuse blew again, which gives us the following scenario so far:
Notice also that the feedback loops get longer and longer, the closer we come to the root cause we are looking for. That is typical when we have a problem within static products with repetitive faults, but which is definitely not the case within an organisation with flexible people, as you will see later.
Now the engineer cannot understand what is wrong, because everything has been done according to current knowledge at the engineering department. But, to come to the root of this problem, the engineer examines the documentation of the scrap metal prevention system carefully, and surprised sees that the maintenance interval for the scrap metal prevention system has been changed from 24 months to only 6 months. The machine stop depends on that the sourcing part of the organisation has not informed the engineering department that this newer system has a shorter maintenance interval. And the reason for the change is that the sourcing department need to cut the cost and therefore bought a cheaper scrap metal prevention system. The engineer gets somewhat annoyed, since this means that the engineering department will increase their cost due to more frequent maintenance work. Who has even thought about their gain and our pain? Which makes most money for our Company, the engineer continues the way of thoughts? The scenario so far looks like follows:
As you can see, this root cause is due to an organisational problem of cutting cost at the sourcing department. But, for the engineering department the root cause is the last one on the product level, since there is the end of their responsibility. So, depending on the investigator, there will be different views on what is a root cause*. The engineer has made a great job and continued to ask why even though the answer is outside the engineering department, since it is easy to stop at the investigator’s area of responsibility or competence. An updated picture with this information about the different levels looks like this:
To stop at the root cause at the investigator’s area of responsibility or competence area is a common behaviour at root cause analyses but unfortunately a big mistake. The stated reason for this behaviour is that we need to respect people and not blame someone that has made something wrong. But, to blame a person is not the reason with continuing to ask why, instead the reason to continue is to find the organisational root causes, which depends on that our system is bad, meaning that people will make mistakes due to a bad system, and in worst case the people cannot make their voice heard to change the system. There is of course nothing wrong with our people, they are always fighting to do their best, but if the system is bad, the people will fight in vain and the company will fail. So we need to find and solve the root causes so we get a better system.This quote of Deming is apt:
Everyone is already doing their best; the problems are with the system … only management can change the system.
Dr. William Edwards Deming
Note! A common misconception of Deming’s quote is that management has all the answers to make the system better. Management is normal responsible for the system (the way of working and organisational structure), but it is the people that work with the system on a daily basis, that can raise the problems they see and come with proposals on how to solve the them.
Also, the supplier continued to ask why to judge if there was in fact organisational root causes, and then it looked like this below for their different products and their respective root cause analysis.
Regarding the root cause analysis for the fuse, the supplier has continued to ask why and found that calibration task has fallen between the chairs and the scenario looks like this:
Regarding the oil, the supplier found that the calibration task missed depended on that some parts of the organisation has a “no complain” culture, so no one dared to point out the visible mistake and the scenario looks like this:
Regarding the pump, the supplier found that there were some late found small quality issues, but depending on the closeness to customer delivery could not be fixed in time, and the scenario looks like this:
Regarding the scrap metal prevention system, the supplier found that the requirement specification was not understood due to time pressure of too many activities at the same time for the responsible team and the scenario looks like this:
Putting it all together for the supplier we get the following big picture:
In the next blog post we will continue with some other kind of problems.
C u soon.
*which often is the “root cause” to not asking why enough times, so the root cause(s) to the original problem never are found