[ER] Fishbone or Ishikawa diagram

Technical Technical Discussion
1

Within the Einstein Report, it mentions the use of a Fishbone Diagram:

“As part of the investigation, Ted McKain, formerly the Technical and Quality Director for Rolls Royce North America, currently retired, and a consultant to Rolls Royce, came to FRC headquarters to work with the FIRST staff. With his support, a complete list of possible causes for command response failures was compiled into a fishbone diagram.”

I created this thread because many in FIRST probably do not have exposure to using such a tool. Many problems are easy to diagnose, and you can just do some poking and prodding. For the tough ones, or the ones that you are going to have to answer to an audience that won’t accept your “first guess”, a Fishbone diagram is a good way to start. A Fishibone diagram is alos known as an Ishikawa diagram. While the diagrams by themselves do not solve problems, they are a great tool for organizing thoughts and possible causes in order to prioritize testing and analysis to find the actual root cause. These documentation tools are really helpful to ensure that all possible causes are thought of and evaluated, and to make sure you are not just treating the symptom, but looking for the root cause as well. They still require the knowledge and expertise to list all the possible causes, as well as the expert judgement to prioritize possible causes and get rid of the most likely non-contributors. I have found that these are especially useful when you have a group of experts of particular fields all working on the same problem which is likely why the quality expert of a jet engine company was called in to organize the thoughts of a group of 18 experts with the variety of expertise this group had.

Note this style of problem solving is good for both manufacturing, product development, as well as the service industry.

I have often thought that while watching “House”, that it would be worth-while for someone to teach him how to make an Ishikawa diagram to focus there efforts, and possibly make a less mistakes. Of course, that would mean the programs would be 30 minutes of Ishikawa development, 20 minutes of testing, and a lot fewer near death moments which is probably not good for television.

2

I am kind of surprised that this thread went without comment. Perhaps it was because of the stunned surprise some of us experienced from reading the report findings.

To back up Ike’s point of the usefulness of the fishbone method, I wanted to share some of my experience using it for FRC. Starting in 2010, Finney Robotics started using this process as outlined in Chris Fultz’s Continuous Improvement white paper. In following years we have run workshops at the MEZ for other teams to spread this powerful technique. Since then we have addressed cronic issues such as chain retention due to frame bending, student attendance and transportation, managing changes to the robot, robot structural failures, pit management, drivetrain decisions, and more.

It is always very interesting to see what the team sees as issues during the brainstorming. Some years it has been very robot centric and questions need to be asked about non-robot items and other years it is the complete opposite.

The key thing to realize about this process is that completing the action plan (next steps) that results from the fishbone activity is the key to success. Just creating a fishbone & action plan isn’t enough. Several of the above issues were not successfully address because of lack of follow through from the individuals tasked in the action plan.

Chris Fultz, thanks for pulling this paper together for teams so many years ago. It has been incredibly helpful.