A Fish (bone) Tale

by Michael S. Perry

You have been asked to perform a root cause analysis to determine where a process is breaking down. Not sure where to begin?

Use a fishbone diagram, a problem solving quality tool developed by Kaoru Ishikawa, to help you and your team identify and discuss all potential causes of an effect.

The tool demands brainstorming by category, which will focus the thoughts of your team. Include all personnel who can contribute positively.1 At the same time, strive to eliminate all potential causes systematically until you are left with only the root cause.

Here’s how to use this tool:2

  1. Clearly define the problem.
  2. Identify potential cause categories.
  3. Draw a diagram similar to that in Figure 1. State the problem, effect or complaint. Extend a horizontal line from the head to the left. Extend major categories from the backbone. Attach ideas to the potential causes.
  4. Brainstorm potential causes by each category.
  5. Discuss potential causes with the goal of eliminating all but the root cause. In other words, determine the cause that, once addressed, will solve the problem (effect) for good.

I work for a fiscal intermediary company that processes and pays Medicare claims. Basically, we ensure providers (hospitals, nursing homes and physicians) get paid for services rendered to people with Medicare. Among other activities, our company tries to enlighten providers on the finer points of claims submission. Let’s walk through an example of how my organization used the fishbone diagram tool.

When the results of our annual provider survey came back earlier this year, providers pointed out that outreach partners (OPs) were “never available to take phone calls” to answer Medicare specific inquiries.

The OP’s primary function is to conduct educational workshops for providers and community members. OPs also facilitate in-service training sessions. OPs travel extensively and spend the balance of time preparing and evaluating workshops.

We acknowledged a problem in not meeting this customer expectation. With that clearly identified, it was time to organize a group and go fishing for answers. I arrived at the meeting with a template of the cause and effect diagram partially filled in with the major potential cause categories and some ideas.

As we came up with different ideas I added them to the diagram.Then I began color coding them: red ink for ideas deemed irrelevant (“Our service policy requires OPs to take phone inquiries”), black ink for relevant but not root cause ideas (“Funding and lack of resources prevent us from meeting provider expectations”) and green ink for ideas that seemed to be getting at the heart of the matter (“There are gaps in our customer service representative [CSR] training efforts”).

Group collaboration proved paramount. Warning: Avoid steering the group toward your idea of the root cause.

What’s the Verdict?

After the brainstorming and building our diagram, we uncovered the underlying cause of the problem. Providers were attempting to reach OPs to answer Medicare specific questions. By job description, it was the CSRs, not the OPs, who were responsible for taking such inquiries.

Some providers had become disillusioned with the contact center and said they had been given inconsistent information in the past. Providers said they had more confidence in OPs and said they had built relationships with them. The OPs had perpetuated this situation by taking provider inquiry calls in the name of good customer service.

The root cause was discovered to be in the contact center. It seemed the CSRs needed more focused training on the types of inquiries commonly received by OPs.

Had we simply looked for ways to make the OPs more available to take phone calls they should not be receiving in the first place, this particular training issue for the CSRs might never have been addressed.

The cause and effect diagram proved to be a powerful quality tool for our organization. Perhaps this technique will net answers in cause and analysis activities for you and your organization.


  1. Charles A. Cianfrani and John E. “Jack” West, Cracking the Case of ISO 9001:2001 for Service, ASQ Quality Press, 2003.
  2. Cianfrani, see reference 1.

MICHAEL S. PERRY is a business and quality analyst with TriSpan Health Services Inc.’s Medicare claims and customer service division in Flowood, MS. He earned a bachelor’s degree in business administration at Houghton College in New York. Perry is a member of ASQ and a certified quality auditor.

Average Rating


Out of 0 Ratings
Rate this article

Add Comments

View comments
Comments FAQ

Featured advertisers