How To Use A Fishbone Diagram To Avoid The One That Got Away



Do you remember the last time your friend told you about the biggest fish that he or she ever caught? (It was immense!) Of course, there is no real evidence of the fish. It’s not like there was a photograph or something that you could see…but, as your friend will tell you, it was one of the biggest fish they’ve ever seen. Here, we discuss an important quality improvement technique that can help you avoid being caught up believing in that biggest fish story ever told.


A Fishbone Diagram Helps


Have you ever heard of an Ishikawa diagram? Guess what. It’s also called a “fishbone diagram”. The Ishikawa diagram helps you identify those factors that you think correlate with a certain outcome. Sometimes it’s called Y=f(x). This gives the idea that the outcome you’re looking at, Y, is a function of different variables in some system. Recently, a quality improvement team I helped used this fishbone diagram to avoid being caught up in a fish story like the one your friend may have told you. Here is how they did it.


Avoiding The Bait With The Fishbone Diagram


This particular team was interested in how long it took them to bring on new physician hires, because delays were really impacting the system.  There are lots of factors involved and the team used an Ishikawa diagram to label all those factors that they think played an important role. There were a whole slew of factors that the team thought could influence how long it took to bring on new hires.  The team could have taken the bait (sorry for the pun) and simply tried to adjust the most obvious factor they intuitively thought correlated with time until a new physician hire got to work.  Instead of falling for that fish story (yes, I’ll say it:  hook, line, and sinker…) the team decided to use data to help them see what correlated with time until a new physician got to work in the system.


They then went on to label the factors as ones they could control (with designation “C”) and ones that they felt were noise (N, or something they couldn’t control). They then collected data prospectively on the next providers who they brought on board. After the team had all the data, they used a multiple regression model to turn their fishbone diagram into powerful conclusions.  (Read more about using a multiple regression with and Ishikawa diagram here.)


Reeling In Some Conclusions


In this case, the team learned that the only factor which reached significance in the model of the factors contributing to total time until the provider started was the variable “amount of time from when the state medical board received the providers completed application until it went before the board for acceptance” which they called board receipt to presentation.


This is an important learning point for the team. It turns out many of the other things they thought correlated didn’t seem to reach significance and, so, working to improve those other factors probably wouldn’t influence time until the physician got to work. This important fact allowed the team to refocus on how to decrease that important time from submission of an application to the board until final board approval.


How did the team do it?  They broke down the factors that often made the board have to go back and forth with them as a healthcare system. They looked into what prevented an application from being turned in cleanly and immediately going to the board. Then they looked to decrease cycle time from when the board asked for more information until the board representative received the information it needed. They looked at how to decrease the number of incomplete applications and how to answer questions better (and faster) so that applications could be put before the board more quickly.  The team knew where to fish because it knew where to spend its time concentrating.


Now Go Try It Yourself


Now you see an important way that a fishbone diagram can be used to avoid a fishing story filled with red herrings. One way to avoid misdirecting effort and time in a quality project is to use the fishbone diagram along with a multiple regression.  We hope you find these two tools more useful together and best of luck on your next fishing trip.

Do You Use These Favorite Six Sigma Tools?


By:  DM Kashmer MD MBA FACS (@DavidKashmer)



Lots of courses in statistical process control focus on the tools and how to use them. A few have gone on to say that, once you are comfortable with the tools, you can pick and choose specific elements to achieve the team’s goals. A recent survey even described which of the Six Sigma tools practicing black belts used routinely. In this entry I will share with you my favourite elements that I usually string together as part of a project. Are these the same tools you routinely use?


Project Charter


In the brief survey I looked at, the project charter was the most commonly used tool. Why? I like to think it’s because the project charter makes a very clear case for why the team should bother doing what it’s doing. It puts forward a cost of poor quality assessment and that strong financial case, in addition to the clarity it brings, really lets the team know how waste impacts the organization. So, like many practicing black belts and master black belts, I have used the project charter for each and every one of the more than 30 projects I have completed with teams.


SIPOC Diagram


I also routinely use a SIPOC diagram. The SIPOC diagram helps me prevent some of the typical reasons why a project fails. One important reason why a projects are unsuccessful is something called Scope Creep. I have described Scope Creep previously. Here, let’s just say that Scope Creep is having an unclear scope that tends to grow with the project. It can also occur when a project bites off more than it can chew. Having it define a clear scope is very useful and the SIPOC diagram helps to do this. What does SIPOC stand for? It stands for suppliers, inputs, process, outputs, and customers.


The process portion is the usually the part I help the team complete first. We usually go for five to six high level steps to demonstrate how we get done what we do. These are framed by the project scope and these process steps do not go beyond the project scope. SIPOC diagrams are very useful for clarifying who eventually are the customers for the processes output, and whether they are internal or external customers. It also focuses on how materials, patients, or other inputs come into the process. I’ve found the SIPOC diagram helps get everyone on the same page for my next favorite tool:  the data collection plan.


Data Collection Plan


Data collection plans are great because they compel the team to come up with an operational definition for each data end point. It’s amazing how much variation there can be even within one organization for the different data end points that it is measuring. Also the data collection plan helps us build a sampling plan so that we know what size sample we need and how to best get at it. Finally, the data collection plan helps the team understand which portions of the system it will be reviewing and ensures that the team gets process, input, and output measures.


Data Analysis Tools


There is no really one tool for this portion of the DMAIC process. I do like to share, however, that processes in the real world sometimes do not follow the normal distribution. Therefore, software packages are very useful for using some of my favourite data tools, including the Box Cox transformation and other tools that work with non-normal data sets such as the KW Test, Levene Test and Mood’s Median Test.




These are some of my favourite Six Sigma tools and I think back to that article where black belts described their most commonly used tools. It was surprising to me that the article was all over the map in terms of which specific tools black belts employed when completing projects. Which tools do you use in your practice to achieve the different tollgates and get the highest quality outcomes?


Get in touch and let me know as I am always interested to hear from black belts around the country and the world.

Have You Ever Used Stealth Sigma?

By:  DM Kashmer MD MBA MBB FACS (@DavidKashmer)


You took a job at a place where they don’t use Six Sigma…now what?


Ut-oh…you’ve entered an organization and it’s one that doesn’t use Six Sigma…but that’s one of your favorite toolsets!  Maybe you use Lean techniques and Six Sigma ones, routinely, together.  After all, you know very well that the Six Sigma process is really just a collection of effective tools put together in the best manner to achieve great outcomes. You know that it’s not so much that Six Sigma is the only way to get things done; however, you know it’s a highly effective process and that it complements Lean so well. Again, the problem is, your organization doesn’t use Six Sigma and maybe even says “We don’t do that here”.  It could be that the new place uses Lean by itself or some other process, which, of course, is infinitely better than having no process at all!

Have you ever been in that situation or heard about it? If you have, then read on for some advice about how to operate with the tools of Six Sigma effectively in an organization that “doesn’t use Six Sigma”.

BIG DISCLAIMER:  By the way…Lean, TQM, and other toolsets are, in fact, great!  Each has an important role in reducing waste, improving quality, and focusing on patient safety.  The question here is:  how do you use the Six Sigma toolset that compliments Lean and other tools so very well in an organization that hasn’t seen those Six Sigma tools before?  After all, Lean and Six Sigma are like peanut butter and jelly…


Don’t call what you’re doing Six Sigma.


I have learned this from entering several organizations that outright say “we don’t use the Six Sigma process”. Like I said above, practitioners who utilize the Six Sigma tools know that they are merely a set of statistical tools strung together in perhaps the best possible manner. More important even than the math behind Six Sigma is its ability to influence culture and produce positive change. Whichever way you look at it, I have found, over time, that entering an organization that practices something like Lean (to the exclusion of all else) often means that I can’t call what I’m using “Six Sigma”.  Sometimes this technique of “doing Six Sigma” without advertising it in any way is called “Stealth Sigma”.


Why bother with Stealth Sigma? People seem to react to the term “Six Sigma”. They have preconceived notions about it. Often, it’s not a body of knowledge they have attained and it’s sort of math intensive. They are interested in the sometimes more soft vocabulary of Lean. The Six Sigma body of knowledge, is, again, often fairly math heavy. Talking about things like data distributions doesn’t go down well in the organization that is focused on less quantitative tools.


Instead, don’t ever package or use a term for exactly which tools you’re doing. Use terms like “quality improvement project” and other terms like “statistical process control”. Again, let me recommend, whatever you do, call the process you are using something other than “Six Sigma”.


Enlist others.


Although you may be using the statistical tools and knowledge behind them, try to focus on bringing people together over important issues. Give them the background on devices you are using like project charters etc. There is no need to ever give them the overview of the fact that you are using the DMAIC process or other tools. Just walk them through it and show them the data. Often, they won’t ever realize that you are helping them perform their first ever Six Sigma project.


Celebrate successes.


When there is a success in a project, highlight it greatly. Again, I recommend doing this to make staff feel good about the quality project they’ve just done. Once they are on the other side of it they will start to feel that Six Sigma (or whatever you’ve called it) isn’t so bad.


Highlight tampering versus under controlling.


One of the powerful elements of Six Sigma is its ability to generate statistically useful conclusions. You can guard against tampering (and under-controlling) with hospital systems. Other quality systems don’t do that so well.  I recommend highlighting the risk of type 1 and type 2 error.  Highlighting decision-related issues like that helps differentiate the tools you know and use from others that the organization is currently using.  It shows what the tools can do for you and the the organization you’ve joined.


One thing I have seen in hospital settings is that we, as staff, are sometimes so eager to do better for the patients that we tamper with systems that are already effective or ones which we haven’t adequately characterized.  (More on type 1 and type 2 errors here.)


At the very least, the samples on which we base our decisions can be very poor. This leads to organizations that lurch from one problem to the next rather than truly repairing problems. It’s a problem, but by no means the worst one you can have.  I add this commentary because, in the set of problems your organization can have, I think this is a fairly good one.


It shows that people are trying, they are interested in making improvements, and they just need some guidance to understand when to intervene and when not to. So, when you use Six Sigma in an organization that does not have, believe in, or utilize the Six Sigma body of knowledge, highlight the benefits of using the statistical tools themselves rather than attributing them to the Six Sigma body of knowledge.  The tools can help protect you from tampering with systems and also under-controlling for problems.


In conclusion, let me share with you that I’ve been in organizations that use only the Lean toolset or only a similar quality improvement toolset. Those organizations can achieve remarkable outcomes and do very well. However, it’s worth noting that when utilizing some of the quantitative Six Sigma tools in organizations like that, it is important to perform what is often called “Stealth Sigma”. This means it’s important to call what we are doing statistical process control or use some other term. Remember to highlight early successes and try to get the team rallied around a certain important fact only to quickly celebrate their achievement when they get to the other side of their first Six Sigma project…whether they know they’ve done a Six Sigma project or not!