Showing posts with label Six Sigma. Show all posts
Showing posts with label Six Sigma. Show all posts

Thursday, October 28, 2010

What takes more time? and costs more?

I am having a debate. For those who know me, that won't come as a surprise. I love to debate about things that I'm passionate about. The current debate that I'm having is about product design. The specific topic is about how to approach determining part tolerances for a new design.

The debate is prompted by problems we are having getting a supplier to achieve the tolerances we specified for the parts they make for us. We have been through three rounds of back and forth with this supplier trying to get good parts only to finally decide to do an experiment and learn that we could have given more tolerance to the supplier to begin with.

Of course, my suggestion to rectify this problem is well designed and planned Design of Experiments (DOE) for the purpose of determining the edges of the performance window. The counterpoint is that DOE takes too long and we don't have time or the samples to do it. This post is not a how to on DOE, I can cover that another time. This post is about what is the best business decision to make.

So, lets analyse the sides of this debate. On one side the arguement is that DOE takes too long, we don't have the samples and we can't test everything. I would agree with one of those viewpoints, we can not test everything. We should only test the important things. How to determine the important things, for that you need a QFD (Quality Function Deployment) tool. We'll save that for another time also.
The other side of this debate is that NOT doing DOE takes too long, costs more money and reduces the chances of success of the design.

What are the facts? DOE can take a while to complete IF too much is thrown into the mix to test. DOE matrices can grow to hundreds of replicates and samples if not contained. There are strategies to whittle down the many factors to the critical few, among the best I have used are Taguchi Designs. Taguchi design matrices allow for testing many factors at two or three levels for the purpose of screening factors for importance.  I have completed simple two factor two level designs in less than a week from start to finish, as recently as this summer. Can DOE take a long time, yes, if we dont plan it well. So what is the cost in time and money associated with NOT doing Designed Experiments? Those costs are real and painful. In the real life debate I am having, we have been working with a supplier since April of 2010 to try to get good parts, now, in October, we still don't have good parts. This has delayed the intended release of the design several times and forced us to decide between another delay and accepting a 40% scrap rate for these parts. This is only half of the story though. By not doing experiments to determine the real needed specification, we have asked the supplier to make a part that costs more to produce because of the extra care required to obtain the tight tolerances we ask for. Additionally, the tight tolerances require that we measure the parts on a sofisticated, highly precise measurement machine that takes quite a few minutes to make the measurement for one part, and finally because we can not get good parts, we must measure every part, further adding to cost and slowing the process. The final cost associated with this decision is in the manufacture of the design. Due to all of the issues, Assemblers will probably have to rework these products in order to make sure they function properly before leaving the factory, taking more time that could be spent doing other things.

To me, the decision is easy. Determine the proper specification upfront by building samples to test the boundaries of performance on critical dimensions, incorporate those learnings into the tolerance for the design, give the suppliers as much room as possible to make good parts, and measure it as simply as possible with acceptable precision. Seems worth the investment of a few weeks effort to me.

Monday, May 17, 2010

Whats the difference between flavors of six sigma?

Six Sigma for Manufacturing; Six Sigma for Healthcare; Six Sigma for Public Sector; Six Sigma for Education.

There's a lot of marketing materials out there hyping the specialty classes and programs for Six Sigma or Lean for a particular industry sector or application. So, what is really different between these different approaches? In short-Nothing.

Lets start with what Six Sigma is and what it is not. Six Sigma is a universally applicable logic based improvement process, it is not specific to manufacturing environments only. Six Sigma is flexible in the use of specific tools for a given problem, it is not so flexible that the logical problem solving process can be avoided. Six Sigma is a scientific method of discovery, it is not a substitute for knowledge.

One thing that may not be universally recognized is that the specific tools that are endorsed and needed to make the six sigma method work effectively are not unique to six sigma. The early practioners of Six Sigma did not invent Gage R&R, Capability Analysis, Process Flow Diagrams, Brainstorming, Regression or Designed Experiments. What they did do was recognize how those tools could add value and strengthen the six sigma method. Why is that important to understand? because understanding that the "inventors" of six sigma borrowed good tools from other areas where they were already in use informs us that we also can adapt tools and apply them in the six sigma method without violating the 'spirit" of the method. For instance; the generally accepted statistic used to express capability in a six sigma project is the Z score, however if you have a transactional of office process that you are working on and continuous data is not available to derive a Z score, thats OK. Just count occurences of your defect regardless of what it is (time, errors, missed deliverables, rework) and report a percentage of failure against the requirement. That's the same thing in "spirit" as a  Z score. Some dogmatic practitioners might insist that the only acceptable metric is a Z score. I assure you this is not correct, what is required is that we measure our baseline capability against the requirement of the process (specification) and express that in some appropriate way.

The other area of flexibility in the six sigma method is in the area of specific process steps that apply. I have led and mentored many project teams and in some of those cases we have had to abandon efforts to complete certain steps because the process we were working on did not lend itself to effectively completing that particular step. In other cases there have been steps that were not needed. One of the typical steps that some teams struggle to complete is the Gage R&R requirement. In some cases it is not practical or necessary to conduct a proper Gage R&R but it is always necessary to ensure that the data is reliable. See this post for a further discussion fo Gage R&R. The step that most often gets skipped is the Designed Experiment step in Analyze. many times this step is skipped intentionally and quite properly because earlier analysis of historical data via regression has produced a conclusive list of reliable root causes and no experimentation is needed to confirm or screen these root causes. If you know from historical data what needs to be fixed, why waste time and money on a confirmation experiement. Conversely, recognizing that your suspected root causes are weakly correlated to the problem should drive the design of an experiment to determine conclusively what the causes are. Of course in an office or transactional project, a designed experiment may not be possible.

Six Sigma is a flexible, universally applicable process improvement method that follows the logical thought pattern of; Define the problem, Baseline performance, Discover root causes, Implement improvements, and Standardize the new process. These concepts apply to any process, anywhere in any professional setting. What is required to use the method successfully in any setting is an understanding of the improvement process, the reasons why each step is important, how all of the steps fit together, and a concerted effort to apply each step. Finally, if you are doing a six sigma project and have used a particular tool effectively in the past, there is no limitation to the use of new tools within the six sigma process. if it works for you and is effective at helping the team move forward, use it.

Monday, May 10, 2010

Improve your Lean with some Six Sigma (and vice versa)

With the advent in recent times of a combined lean and six sigma approach to continuous improvement efforts, one might think that the dilemma of which methods to chose has been resolved. However, confusion still exists over how to move forward with a combined approach to Lean and Six Sigma.

First, why a combined approach to Lean and Six Sigma? Isn't lean or six sigma good enough on its own? Not in all cases by my experience. Every problem is like a snowflake, unique, with some similarities to other problems but still, unique. For some types of problems six sigma is good enough all on its own, those types of problems are typically variation related issues. For other types of problems, lean is fine, those are typically waste related issues. Combining them together leaves nothing on the table in terms of improvement opportunities. Lean and Six Sigma each complement weaknesses in the other method. For instance, Lean is weak in the area of data based analysis and decision making, this is a strength of Six Sigma. Six Sigma is a top down driven improvement approach, which risks not involving the right people in solving the problem, lean compliments this by being driven bottoms up, ensuring the process users are involved in the improvement.

Add some lean to your six sigma or six sigma to your lean. In studying both Lean and Six sigma, we find that they operate on multiple levels. Lean and Six Sigma are at once, a tool set, a methodology, and a culture. Much handwringing has occurred over the question of creating another initiative when a six sigma or lean culture already exists. Concerns usually center on creating confusion in the ranks. Avoid this confusion by folding the supporting tools and method into your existing improvement culture. If six sigma is your way of working, incorporate lean tools into the method to capture waste in addition to the variation reduction. If you have a Lean culture, add the six sigma data gathering and analysis tools and steps to your lean to strengthen your decision making.

I  led a couple of projects that are good examples demonstrating the idea of combining approaches to achieve the best results. Without going into much detail on them I can share that in the first project we improved process accuracy by over 40% while reducing cycle time from 45 to 19 days.This project can be reviewed here for those interested in more detail. In the other project we reduced cycle time by 40 hours through using regression statistics to identify what equipment was producing the longest cycle times, then apply lean concepts to improve them.

The point here is that combining lean and six sigma approaches together improves results by reducing variation and reducing waste at the same time. This is the best use of our precious improvement resources, gaining the maximum benefit for the time and effort spent focused on a particular problem.

Monday, April 12, 2010

Six Sigma Tool of the Month-Attribute Agreement

How many times has this happened to you? You’re leading a six sigma project on a transactional process of some kind, something not directly tied to manufacturing or measurement of product quality. You get to the Gage R&R step in Measure and struggle to figure out how to satisfy the requirement for a Gage R&R statistic to interpret. If that’s ever happened to you, I have a solution to this problem for you..


First, let’s discuss briefly the “spirit” of the Gage R&R requirement. The reason we want to do a Gage Study boils down to confidence and good decision making. In Measure, we do a Gage Study of the data used to generate the Project Y or Critical To Quality (CTQ) measurement. Why? So we can be confident that, as we carry that data forward to capability analysis and Root Cause Analysis in the Analyze phase, we can trust the conclusions that we will draw and the results we will see. That’s it, confidence and good decision making.

How do we gain confidence whent he data is based on a person judging the quality of a characteristic rather than an objective instrument? One way that works very well is called Attribute Agreement. Attribute agreement assesses the results of decision making by people and produces some key statistics that tell us whether the results are due to random chance or if our judgment appears to be better (or worse) than random chance. Attribute agreement produces a result that can be interpreted in a similar fashion to a traditional Gage R&R and the detailed statstical analysis can give insight into areas in need of improvement, just as a traditional Gage R&R can.

Attribute agreement analysis is an effective method for delivering a statistical interpretation of a subjective judgement decision made by people, allowing fact based improvements to be identified, implemented and measured. Attribute agreement analysis allows those leading projects without continuous data to measure the quality of that data and boost confidence in the capability of the system, and decisions that are made to improve it. For a more in-depth discussion of Atrribute Agreement including a case study where it was used effectively, including details on how to interpret the results go to this article that I wrote.

Monday, March 22, 2010

Six Sigma Tool of the Month-Defect vs Defective

What is a defect? What is a defective? Whats the diference? Why do I care? Last month I discussed capability analysis as the Six Sigma Tool of the Month. Get a refresher on that here. One of the ways that we can measure capability is a statistic called DPMO or Defects Per Million Opportunities. DPMO is a measure of how many times (out of a million) your process would produce good "product" vs bad "product". But that measurement begs the question, What is a defect? So that brings us to today's post.

A defect is a characteristic of the "product" that does not meet the customer's requirements (Specifications). in a DPMO calculation, each one would count as one. Does a defect make a unit of product defective? lets say we are producing a complex product, with multiple quality characteristics, say a new automobile or a monthly sales forecast for 20 products. Does one defect make the car or the sales forecast defective? In other words does a defect affect our decision about the purchase or retention of the product as a whole. If there is a blemish in the paint on the car, should the car go to the junkyard? If one product in our sales forecast is misrepresented by 10% does that mean the whole sales forecast is no good and should be scrapped? Probably not. That's the difference between a defect and a defective. A defective is a unit of product that can not be considered good due to a preponderance of failing quality characteristics (Defects) - OR - a failing quality characteristic that is so vital to the functional purpose of the product that its failing inhibits the primary function of the product. In our new car and sales forecast examples if the car had a paint blemish, a burnt out headlight, a wobbly wheel, a staticy radio, and cracked windshield and tear in the seat. We'd return that car and demand a new one, or not buy it in the first place. In our sales forecast, if one product was off by 10%, and another off by 12% and another off by 23% and so on, eventually we would not believe the forecast at all. Its defective. Again, using our two case examples, if the car was missing the engine or the forecast for a major product was off by 50% or more, that alone would make the forecast defective.

So why care about the difference between a defect and a defective. Its all about the pain the customer is feeling. remember, we measure process capability in terms of the deliverable(s) the customer cares about (specifications). Our reaction to measuring a missing engine in our automobile product as a defect might be different than if we take the customers' perspective that the product is unuseable without the engine (defective).

Thursday, February 11, 2010

Six Sigma Tool of the Month-Capability Analysis

Capability analysis comes up twice in the six sigma process. Capability can be measured a number of different ways. I'll cover that in a minute.

First, what is capability analysis and why do we measure it? Capability analysis is measuring the variation and bias of our process against the requirements of the customer (otherwise known as specifications). The number reported, in whatever form, is a statistic that indicates to us how well the process meets the needs of the customer. The diagram below shows a process that has wide variation and is not centered between the specifications. Both of these issues result in defects, costing the organization money and reducing customer satisfaction.



So, how can capability be measured? At least four ways come to mind immediately: Cpk, Z Score, DPMO, and Yield. The key thing to remember about all of these measurements is that they are just different ways of expressing the same idea; how good is my process at meeting the customer needs. So, whats the difference? The short answer is not much. Cpk and Z scores are directly convertable from one to the other just by multiplying or dividing by 3, depending on which statistic you prefer. DPMO is Defects Per Million Opportunities and expresses the idea that if you were to perform the work process 1 million times, how many results would be defects. Yield is another way of expressing this as a percentage. Yield is just the percentage of the output of the work process that is "good". I could share with you the formulas for how to calculate these different capability measurements but I dont want you to leave, and those formulas are readily available from any number of sources, including myself.

What I'd rather discuss is why we do this in the context of six sigma or really any continuous improvement project. There are two reasons; 1. baseline process performance and, 2. measure the improvement. In step 6 of DMAIC we measure baseline capability. Capability is a measure of how well the process performs its intended function for the customer. Before we go and start tinkering with things in an effort ot improve performance, we need to understand how the process performs today: thats a baseline. We come back later in DMAIC at step 14, after we have implemented the improvement plan and allowed the process to run for some time and we measure performance again. This time, we compare the new process performance to the baseline to determine how much improvement we have made through our efforts.

Thursday, January 14, 2010

Six Sigma Tool of the Month-Gage R&R

In this series of posts, I review the purpose, use, interpretation, and limitations of various six sigma tools.

This post is about Gage R&R, a critical tool in the Measure phase and the Control phase of DMAIC. There are many aspects of Gage Repeatability and Reproduceability, I'll attempt to cover the major points here, starting with the purpose(s). When a decision is made to charter a six sigma project, one of the major concerns early into the project is the reliability of the data that is used to determine root causes. It is very important that the data that is analyzed about the project problem be accurate, and consistent to enable accurate analysis, and that good conclusions can be drawn from the data. This is important to ensure that improvement plans are effective at addressing the root causes and can deliver real improvement. Gage R&R also comes up again in the Control Phase of DMAIC to help ensure that the significant parts of the improvement plan can be accurately measured. There is another purpose for Gage R&R. Actually Gage R&R is primarily a tool for determining if measurement systems used to evaluate the quality aspects of a product will produce reliable results. In either situation, the intent of Gage R&R is to give an indication of the proportion of the variation that is present in our system that comes from the measurement system. At its very basic level, a measurement system must be able to distinguish good product from bad product. Understanding the ability of the measurement system to do that is the purpose of a Gage R&R study.


There are several aspects to a Gage R&R study. Among the most important things to consider are:
-Reproduceability
-Repeatability
-Accuracy
-Precision
-Bias
-Linearity
-Sample Selection

Lets start with Reproduceability. Reproduceability is the measurement of the portion of the variation in the measurement system that is coming from differences between people. Most measurement systems consist of two primary components of variation; People induced variation, and Instrument induced variation. Reproduceability tells us about differences between the ways that people do the steps of a measurement method and how much those differences matter.

Repeatability is the portion of the measurement system variation that comes from the instrument itself. Repeatability is a measure of the ability of the measurement device to deliver a consistent result over several measurements.

Accuracy and Precision can be taken together. Accuracy is a measurement of the measured result compared to the true result. Remember that our measurement system is intented to give us a high confidence in the data that we use to decide on product quality or determine the root causes and improvement plans for six sigma. Precision is a measurement of the variation in results seen. Think of these two like a bullseye target. See below for a visual example showing the relationship between Accuracy and Precision.


Bias is the difference between the measured result of a sample and the actual result of that same sample. Bias is the error that exists in the measurement system. In the example below we are looking at our car speedometer. If we compare the measured result of the speedometer at three speeds (30, 50, and 70 mph) and we can know the actual speed that the car is going, we can determine the bias or error across the range of interest of the measurement system. The red arrow indicates the measured speed on the speedometer, and the yellow arrow is the actual speed as measured by some other device (a gps for example). We see that at 30 mph, we are actual traveling at 25 mph, there is a negative bias of 5 mph. At 50 mph, we are actually traveling at 50 mph so there is no bias at this speed. At 70 mph however, we are actually traveling at 85mph! This is a positive bias of 15 mph. Our local police officer would be very interested in this result. In an ideal world, bias would not exist, but since we don't live in an ideal world, we know it does, and we would like the bias to be predictable. That leads us to the next measurement characteristic; Linearity.

Linearity is the measure of the bias over the range of interest in the measured samples. In our example below, we see that at 30 mph there is a negative bias of 5 mph and that as we proceed up the scale of measurement, the bias increases to plus 15 mph at 70 mph. This is NOT a linear response. If you look at the chart below the speedometers below, you will see that the actual speed is not a linear line, its more quadratic (curved) than straight. This is useful information for us. First, it tells us that we can not apply a simple correction factor for bias across the range of measurement. If we were to apply a correction factor to the speed based on either end of the measurement range, results at the opposite end of the range will not be accurate. Secondly, the linearity tells us that the error grows as speed increases and that measurements at the high speed end of the range are more suspect and risky than measurements at the low speed end of the range.




Finally, lets talk a bit about sample selection. Hopefully through this discussion, you have seen that one of the most important aspects of setting up a Gage R&R Study is the choice of samples to measure. Remember the purpose of our study from earlier; determine if our measurement system can produce reliable results that can be used in decision making, either for our six sigma project or in the actual measurement of quality. In order to know about things like Bias and Linearity of response, we must measure samples that span the range of interest of our measurement. What does this mean? Lets say for instance that using our speedometer example from above, that we have an upper specification of 65 mph and a lower specification of 30 mph. If we were to chose the measure at 50 mph because that result is in the middle of the range of interest, we get a very different picture of our capability to measure speed than if we measure at either end and outside the range of specification. If we only measured 50 mph, we would incorrectly conclude that our speedometer is accurate and precise, with no bias. We would not be able to comment on linearity and this would result in our surprise at getting a speeding ticket for going about 12 mph over the limit at 65 mph. If we measure across the range of interest we then can add linearity to our understanding and know that we should not be confident in results near the upper specification of 65 mph. This tells us that we should set our upper specification for the speedometer somewhere in the area of 58 mph (measured) to always be under 65 mph (actual).

Gage R&R is a very useful tool in your six sigma tool box. It is also vital to ensuring that customer receive good product that meets their needs. Gage R&R studies are constructed to tell us how much confidence we can have in the measurement system. Gage studies can tell us where we need to improve the measurement system. Through analysis of the statistics that come along with the study, we can determine if person variation is causing issues or if the device itself is the source of variation. In any case, the gage study is a versatile tool to help identify improvement needs and improve quality.

Monday, December 14, 2009

Six Sigma-Innovation Killer NOT!

I'm reading a new book that everyone should go out and buy. Its called The Brain Advantage, Become a More Effective Business Leader using the Latest Brain Research. A friend of mine is a co-author so I got a copy from him to read through. I'm only through Chapter 3 but already I've made several connections to my past experiences in leadership.



I'm going to share one of them with you here, then you go right out and buy the book.

Several weeks ago, I wrote a brief post about myths regarding Six Sigma. See the original post here. One myth that I addressed in that post was that Six Sigma is an Innovation Killer. This is the widely held conventional wisdom in publications such as Business Week that resulted from the withdrawl of Six Sigma from places like 3M in the recent past.

In The Brain Advantage I found an answer to why this myth persists and why Six Sigma may be perceived as an innovation killer. The answer is a simple as Right Brain vs Left Brain. In Chapter 1 and 3 of The Brain Advantage the authors discuss the commonly held misconception that Six Sigma is an innovation killer and research that indicates that innovation (literally the Eureka moments) are exclusively Right Brain activities, while process oriented scripts and routine tasks are the domain of the Left Brain. Further, the authors discuss how there is no bleed over in brain function between the right and left brain when it comes to innovation. Its as if the left side of our brains go to sleep while we think creatively exclusively in the right Anterior Superior Temporal Gyrus (ASTG).

We can apply this new learning to help overcome the bias against Six Sigma in innovation circles by intentionally setting the stage for innovation to occur within the steps of the Six Sigma method. So, follow the six sigma process to achieve a product or process design that meets or exceeds the customer need (Left Brain), but at the critical process steps where a innovative solution is needed, we must recognize that an intentional shift in focus is needed and that the environment for innovation has to be intentionally set that allows for the rules to be ignored, creativity to flow, and insights to occur (Right Brain). "Ok, great, how do we do that?" you might be saying. My advice to you is to contact the authors and ask them for some help, seems like their area of expertise to me.

Go buy the book, right now! You can find it here.

Monday, December 7, 2009

Six Sigma or not to Six Sigma? That is the question.

I was having a conversation recently with a friend who runs an academic program at a major US university. She was telling me about solving a problem in her department and how the solution was obvious so she just did it. She then related how one of her collegues protested that she should have used some six sigma tools to really understand the process before making the change. The short story is that she rejected this suggestion and just did what she knew needed to be done. A strange coincidence occured last week when Leadership Change Agent and fellow blogger Brad Kolar posted on the very same topic here. It must be something about Thansgiving that makes people contemplate their "gut feel" for things.

Of course, I think she was exactly right. This discussion reveals one of the major issues facing continuous improvement initiatives today. Doesn't matter if its Lean, Six Sigma, 8D, TRIZ or whatever the latest fad in the workplace is. If you know what to do to solve a problem, why mess around with "discovering" it. Just get your backbone up and do what you know is right.

If that's the case, then why do so many "experts" advise going through the "process" to "discover" what to do? Two reasons. First, I have found that some practitioners of six sigma have a devotion to it that borders on religious fanaticism, insisting that everything be done with six sigma. The truth is that everything should not be done with six sigma, or lean or whatever your method du jour is. There's an old saying that I like. Not sure where it came from but here it is. "When all you have is a hammer, every problem looks like a nail". What this means to me, is that we have to use different tools in our toolboxes intelligently to solve different problems appropriately. Instead of a nail, every problem is more like a snowflake, unique and different in some way from every other problem. Sure there are some common traits of certain problems, but a cookie cutter approach will only carry us so far. The second reason is really abuse of the CI method. A common misconception I hear frequently is that using the process, say six sigma, builds a solid case for management to use in decision making with all the data and statistics and stuff. The only problem is that you've spent 3-6 months to build a case to prove that you should do what you knew you should do in the beginning. The net effect is that the problem continued for 3-6 months while you deferred the decision that you knew you should make in the beginning. This is an abuse of six sigma, lean or any other CI method. It leads to criticisms of the method as slow, not innovative, or original. Abuse leads fence-sitters and non-believers to conclude that you really don't need six sigma or lean or whatever to make things better, since all six sigma does is confirm what we already knew.

So if we should not use a cookie cutter approach to problem solving, when is it appropriate to use or chose not to use a particular CI method? First, if the problem that needs to be solved has an obvious root cause and/or obvious solution, don't bother with any CI method, just summon the courage and go do it. You may need some tools to help figure out exactly what to do, but if you know, don't waste time, just go do it and start reaping the benefits sooner. If these conditions dont exist, then you really do need to consider some method to discover what is causing the problem and what should be done about it. In general, if its a variation type of problem, use six sigma, if its a waste type of problem, use lean, if its a design problem use Design for Six Sigma or TRIZ or something like that. If its a bottleneck constraint in the workflow, use Theory of Constraints(TOC). Finally, once you start to dive into the problem, don't adopt a rigid approach. Be open to use some lean to remove waste while reducing the main variation problem. If considering a waste problem, look for bottlenecks in the process and apply TOC to speed the flow throught the "factory". The bottom line is that problem solving calls for thoughtfulness, flexibility, and creativity. Above all, problem solving requires a good understanding of the different methods in the toolbox so that good decisions can be made about what to use in different situations.

Monday, November 16, 2009

Kano Model for Customer WOW!

The Kano model is a useful tool to help the design team or even an improvement team develop ideas that will WOW the customer by addressing needs that the customer does not even know they have. It is a simple model for customer satisfaction that posits three satisfaction regions; Dissatisfaction, Satisfaction, and Delight. The model was developed by Japanese TQM consultant Noriaki Kano*. The Kano model is useful for process improvement teams as well as design teams to help the team think outside the box for innovative solutions that are focused on meeting and hopefully exceeding customer needs. Heres a visual of the model: (Click to enlarge)






The model works this way. A product or service that does not meet the customers' unspoken or basic needs will result in dissatisfaction of the customer. A product or service that does not meet the expressed needs will also result in dissatisfaction. Think of it like this. You purchase a car that claims to get 100 miles to a gallon of gas. If that car does not actually get 100 miles or more to a gallon of gas, you will be dissatisfied. If that car also has no steering wheel, you will be really dissatisfied even though you didn't expressly ask for a steering wheel to be included. That's the difference between a spoken and an unspoken need. Unspoken (Basic) needs are assumed to be present, until they are not. The interesting thing about basic needs is that by meeting them, satisfaction does not improve, but the absence of them will cause satisfaction to decrease. Having a steering wheel in your car does not make you a satified customer, you assume it will be there. The other interesting thing about basic needs is that customer expectations advance over time and things that were satisfiers in the past, become expected today and in the future. In our visual example above, the customer is dissatisfied because the machine that they purchased from us does not complete a manufacturing cycle without causing a process reset activity. A basic need in this example might be that the machine controls actually function properly.

In order to move from the basic needs into a leadership position, the customers' expressed needs must be met. In our example, to move from dissatisfaction to satisfaction, the team must solve reliability issues with the machine such that the customer can complete a cycle without having to reset the process. If the team is able to redesign the system to perform reliably, customer satisfaction will improve. This will be particularly true if performance of the new system exceeds competitors performance.

Moving from dissatisfaction to customer delight is where the real power of this tool lies. This is where innovation and out-of-box thinking comes into play. The Kano model challenges us to think about what would delight the customer in regards to the problem we are working on. Delight results from the delivery of a product or service to the market that the market didn't ask for but once its is experienced, the customer can not do without it. Using our car example from earlier, if our car achieved 100 miles per gallon of gas AND had an autopilot function for long trips, that might delight some customers who would prefer to nap or read than drive on a long trip. The iPhone is another example of a delighter. Flash memory sticks were a delighter to those of us that remember floppy disks. Those were not things that customer's demanded but they were recognized as extremely valuable once the idea was introduced. In our visual example, the customers that did not experience the problem but experienced the upgrade to prevent the problem from occuring were delighted by the service provided.

I recently talked about a couple of myths about six sigma. One of those myths was that six sigma stiffles innovation. Use of the Kano Model as a tool in the six sigma process is one way to make sure that innovation is not stiffled, but encouraged in the problem solving process as well as in the development process.

*From Quality Function Deployment: How to Make QFD Work for You by Lou Cohen. Copyright 1995 by Addison Wesley Longman, Inc.

Thursday, November 12, 2009

Measurement-Context is Important

Fellow blogger and Leadership Change Agent Brad Kolar posted last week on something that has got me thinking. Brad shared an experience he had with a team in which the team had some data about an improvement that showed a tremendous productivity gain. However, Brad got the team to look at the data a different way, which showed that the improvement was not nearly as dramatic and that more work needed to be done on adoption of the improvement. Read Brads full post here.


I have had all kinds of similar experiences to Brad's story. The most recent one occurred this week. I was doing some coaching with one of my friends who is also a Six Sigma Green Belt. He was asking me to review his data and help him present a graphic and set of statistics that would show the improvement in performance of a process that he has been working on for several months. He had done some of his work ahead of time so there was very little for me to add but one thing struck me during our discussion. He was comparing process performance in September with process performance in October since they represented his before and after improvement conditions. On the surface, this seemed a valid comparison until you consider that the process interacts with outside weather conditions. So I asked the question, was September and October different or the same in terms of outside weather? Turns out, September was warmer and drier than October, making the comparison suspect. So what to do? We looked for a comparable period of outside weather conditions in the before period and ran the analysis on that month. Turns out March was very similar to October so that was our before comparison month.

Completing the analysis showed us that indeed the process had improved in terms of variation and centeredness. My friend was on solid ground to make his claim of improved performance. Just goes to show, you have to think about your data and ask yourself hard questions about the validity of assumptions that are made to be able to stand up to scrutiny and convince others that your improvement is real.

Monday, November 2, 2009

Six Sigma-Its no substitute for knowledge

I recently was having a conversation with a senior manager who was lamenting that "six sigma analysis" did not find the root cause of a longstanding problem but our scientific knowledge did. I think this may have been meant as a dig at me since I'm a Master Black Belt but I think he makes a great point, slightly misguided but still a great point. Six Sigma, or any other problem solving process is only as good as the information analyzed. We've all heard the adage "Garbage In-Garbage Out". I've thought alot recently about the perspective of this senior manager and it reminds me of something that I think is worth reminding ourselves from time to time. Six Sigma is no substitute for knowledge. In the problem I was discussing with this senior manager, no routine data was collected on the process step that produced the problem.

Some people seem to think that Six Sigma is an excellent method for discovery of new knowledge. I understand why this misconception occurs. One of the strongest tools in the Black Belt's toolbox is Multivariate Regression. This toolset is used to uncover hidden relationships in data and thereby help uncover the root causes of problems that can't be solved in other ways. This, I believe, leads people to assume that Six Sigma properly applied can find new knowledge, and it can, but only when the data is present. The strength of six sigma is in the disciplined, logical problem solving approach that is inherent within the DMAIC method. But, Six Sigma will not find the root cause of a problem if there is no data on that problem or that particular root cause. The DMAIC method teaches us to follow the data, and trust the statistics. We still have to use our brains though and when the data and statistics do not present an answer to the problem, we have to expand our circle of thought to include other information that didn't get included in the first go around.

In all of the six sigma classes that I have taught and all of the mentoring I have done with project leaders I have emphasized that six sigma is not a substitute for your brain. Use the DMAIC method, but follow the data and trust the statistics and if they tell you that you have not found root cause, go look somewhere else for the answer. One of the best places to go is to the guru. Sometimes, scientific experimentation has already produced the answer to our problem but we may not have ready access to that knowledge because it resides in someones head, rather than in a library somewhere.

Monday, October 19, 2009

Six sigma vs Lean. Whats the difference?

As you consider your options for kicking off a Continuous Improvement initiative, one of the questions you'll face is which program to chose. I talked a little about this here. Today, I want to go a little more in depth on the differences between two of the most popular CI programs; Lean and Six Sigma.

First a little definition, starting with Six Sigma. Six Sigma is many things. It is a statistic (3.4 defects per million), it is a set of tools (GR&R, Descriptive Stats, Regression, DOE, etc.), it is a problem solving process (DMAIC, PIDOV, DMADV), but it is also a management philosophy.

Lean is all of the things listed above (except a statistic) for Six Sigma. Lean is a toolset (Kanban, Poke Yoke, Andon, VSM, Standard Work, Visual Factory, etc..).Lean is also a process, usually starting with 5S and proceeding from there to more difficult problems and solving them using a Kaizen approach. Lean is also a management philosophy.

Both approaches can be successfully applied at any of the levels mentioned, but the full realization of each is as a management philosophy. Gains can be made when the tools are applied to a given problem so each can be successful without full commitment, further each compliments weaknesses in the other approach, which leads to the recent trend in combining the tools and methods together (Lean Six Sigma). There are obvious differences between the tools used in each method, the processes used are similar to each other. Kaizen can be mapped over the steps of DMAIC or vice versa.

So what is the difference between Lean and Six Sigma? The biggest differences can be found when Lean or Six Sigma is applied pervasively as a way of managing the business. Both include training as a core component but there is a subtle difference between the approaches used. While both Lean and Six Sigma need trained practitioners to be successful, Lean has an additional value placed on training that does not exist in Six Sigma. A core concept of a Lean culture is a cross-trained workforce. Cross-trained in the work process, not specifically in Lean tools. This is an important part of a Lean Transformation because a cross-trained workforce supports job rotation to keep workers from getting bored and complacent. Another significant difference is evident in the use of measurements. Both Lean and Six Sigma emphasize measuring performance, the approach is very different however. Six Sigma seeks to measure process performance relative to the problem being worked on at the project level or of the most important measures of business success through Dashboards. These dashboards cascade down from the top and rarely show up on the shop floor, so the workers dont really know how they are doing. Lean, on the other hand, focuses measurements on the shop floor FIRST and places a high value on managers going to the Gemba, or shop floor to see for themselves how things are going. This suggests a bottoms up approach to measurement, starting with the work cell and proceeding UP to the plant and the company from there. This is supported by Visual Factory concepts. I remember a quote from one of my Lean Sensei's that the standard for Visual Factory effectiveness was that a one eyed person could gallop a horse through the plant and at the end be able to tell you what is going on in that plant. It should be that obvious. This difference highlights the main philisophical difference between Lean and Six Sigma. Six Sigma is a tops-down management philosophy that only occasionally reaches the shop floor whose main practitioners are mid-level managers and engineers. Six Sigma projects are chosen by reviewing performance at a high level and imposing the change down with some involvement from the "doers". Lean, on the other hand is characterized by the idea of "servant leadership" in which the leadership views one of its main functions to be enabling the success of the workers. Management goes to the floor to see what is happening, values effective communication, training, promotion, and learning and the initiative start and complete improvment work starts at the lowest level, the individual worker and the work cell member's desire to improve their own work.

Finally, there is one other significant differnce between Lean and Six Sigma at top level. Since Lean is so focused on enabling the worker to perform better, a sacred trust is built between the workers and management. This implied contract is that making Lean improvements will not result in people losing their jobs. This is incredibly powerful in creating trust. Dont get me wrong, Lean does result in fewer workers being needed in the work cell, but the sacred trust means that those workers are placed elsewhere, not on the street. Six Sigma on the other hand...well, one only needs to talk to someone who has worked for GE during the Welch era to know what happened there.

Thursday, October 15, 2009

Creating an Organization-Wide Continuous Improvement Culture (Part 2)

In Part 1 we discussed the realization that a CI program of some sort is needed and that the two most important things to consider are the level of commitment that you have and the expected outcomes for the business. In this section we will discuss detailed planning to achieve the vision, training & execution, marketing your success and promoting the right behaviors and skills (otherwise known as feeding the beast).

Detailed Planning: There are a thousand little things to consider here. Many depend on what approach you settle on. Who will do your training? Will you certify your internal people? To what standard will they be certified? How will you communicate internally about progress and the program? How will you handle the negative backlash to change? What fears are most likely to rise up? All of these question will need to be addressed in a detailed way, pretty much up front. Some might wait until later, but if you imagine yourself as wildly successful, you will soon be faced with these issues, better to start thinking about them now.

Training: Depending on the program you've chosen, there are a wealth of resources out there to help accomplish this task. When engaging with someone to help you with training and even with program development, remember, you are in the drivers seat. Do your homework so you can engage the consultant and they can help you craft a program that meets your organizations needs, not theirs.

Execute, execute, execute: Once the detailed planning is drafted and the training is underway, its now time to execute. This is, by far, the most important part of any culture change activity. This is where credibility is built. This is the part where skeptics can become supporters and even passionate believers in what you do. The old saying "the proof is in the putting" is appropriate here. Early success is key to building credibility, so chose what problems to tackle wisely. Remember that you are dealing with high performing people but they have little to no experience with this new set of tools. Mistakes will be made, projects will fail, it happens so don't set someone up with a too complex problem as their first opportunity. At the same time, you want the problem to be real and easily recognizable by all as a problem worth fixing

Market your success: Once you start to have some solid success, start marketing. This part is underrated by many (including me early on) but marketing the successes will help create momentum for the initiative. You'll be able to recognize when you have momentum when you no longer have to recruit people into the initiative, but they seek you out to lobby you to allow them to participate. How to market depends on the company culture. I've used "Six Sigma Fairs", project presentations, billboard and email announcements, and testimonials to varying degrees of success. Try lots of things and stick to what you find works.

Promote the right behaviors: One of the most important things to consider upfront is how you will feed the beast in the future. Most CI Initiatives require some intentional turnover to be viewed as beneficial and viable. The challenge here is what to do with the people that have the new skills required to be effective CI leaders. The best thing to do is promote them into positions of leadership. If the program is truely valuable to the company, those skills will be valued in leadership roles as well. There is an added benefit of showing the organization how important the initiative is to the company's success, and that participation is a possible path to promotion.

Monday, October 12, 2009

Creating an Organization-Wide Continuous Improvement Culture (Part 1)

Want to improve your business situation? Regardless of the reasons why, a recognized need to improve the performance of your business is all that is needed to get the ball rolling. Once the decision is made, however, several questions immediately come to mind. Which approach? How do we start? How many people will this take? What do I expect to get from this? In my experience, it really does not matter which approach you chose. You can chose Six Sigma, Lean, Baldrige, ISO, PDCA, or any of the other latest fads in continuous improvement methods. With the right attitude and commitment, any of these approaches can be successful.

There are proponents of each of the previously mentioned methods, true believers in Six Sigma abound. Fervent advocates of lean are also out there in force. Many companies in the US have used the Baldrige criteria to improve and achieve excellence. ISO requirements for improvement have been ingrained since the standards were developed. Go to a conference and you will find all of these adherents out in force, preaching the gospel of their particular flavor of Continuous Improvement and telling anyone who will listen that THEIR flavor, can save the world and what the shortcomings of all of the other approaches are. So, which to choose? Answering this question starts with another question. What is your organizations culture and what are its big problems? If your organization is already highly disciplined and the perceived problems are with efficiency, lean may be the way to go. If you’re organization is very entrepreneurial, with no appreciation for process discipline, maybe start with ISO or Baldrige requirements. If you’re organization has a basic process discipline appreciation, but product quality issues are killing you, six sigma is for you. By the way, you don’t have to choose just one method. The trend in recent years towards combined approaches (Lean Six Sigma) makes sense from the standpoint of wanting to get the most benefit possible.

Since which method is not the most important thing to consider, what is? There are two things that are of paramount importance to the success of a CI initiative; How committed are you, and what is the expected outcome? I can not overstate the importance of top management commitment to the program. Commitment comes in many forms, starting with agreement all the way up to active participation. Real, meaningful management commitment is towards the top end of that spectrum, but don’t worry, you don’t have to do a Black Belt project to demonstrate commitment. What you do have to do though is this; Commit high potential resources, I mean really commit them. Take people out of their current roles and dedicate them to making this culture change happen. Do not take a half step here, don’t create “Part-time” resources because part–time means no time. An important point here is the caliber of people that you commit to the effort. Don’t choose the people that you can “afford” to do without in their current roles. If, while having the resource discussion, a persons’ name comes up whom someone says they can’t live without, that’s the right person to put on the effort. This decision is a reflection back to managements’ commitment. If the people chosen to lead the effort are viewed as expendable, the organization will recognize very quickly that management is not really interested in this initiative and support will wither. The second thing to consider is what do you expect from the program? What’s the big hairy goal that focuses the organizations efforts on this program? Is it winning awards from your customers, is it reducing cost by 50%, is it growing the business significantly? What motivates top management to be interested in this program and the results it achieves? Once you know this you’re ready for the next phase.

Create a crisis. This statement is one way to say that you need to create a vision and a sense of urgency that everyone can easily recognize and understand, to make it easier for people to support and participate. So what is your crisis? Is it competition taking market share, customers firing you, significant product quality costs, significant overhead costs making you less competitive? Clearly define the crisis and communicate it broadly to the entire organization, repeatedly.

Once you have defined the vision, selected an approach or set of approaches to use, determined resources, and communicated the crisis, it time to get to work. Those resource decisions that you made earlier, its time to execute them. Actually take people from their old roles, reassign their old responsibilities to others, move them physically if possible. Now it’s time to think about training.

Next week, we’ll talk about planning for training and helping people to build a detailed vision and plan for culture change and linking that to the crisis. We'll also discuss creating momentum for the inititaive.

Friday, October 9, 2009

Debunking Six Sigma Myths

I'm a Master Black Belt in Six Sigma, I say that upfront in the interest of full disclosure that I am biased about Six Sigma. Being a Master Black Belt and Deployment Leader for Six Sigma also means I have some expertise and not a few opinions on the subject. So with that I'd like to tackle two common myths about Six Sigma.

Myth One: Six Sigma is too slow.

I hear this one all of the time. "Six Sigma slows me down. Analyzing all of that data takes too long". Two things about this myth; One - there is no time constraint on six sigma. Typically a project takes 3-6 months to complete, but I have seen them complete in less time. I've also seen them take longer. My observation about this is that if you have a problem with speed in six sigma, look for underlying organizational dynamics that might be causing it. Do other types of projects go much quicker and still achieve good results? If so, maybe there are training issues with six sigma practitioners, or there may be issues with accessability and useability of data critical to analysis, if not maybe there's an underlying issue with accountability and urgency in the organization. Another common problem that leads to the "too slow" criticism is using six sigma to implement a solution that is already known. The purest reason to begin a six sigma project is to solve a problem that we dont know how to solve. If we use six sigma to solve problems we already know the answer to, then of course, the method will be slower than just deciding to implement the solution and doing it. Six Sigma used to create management commitment to a known solution is a misuse of six sigma. Finally, using the "six sigma is too slow" excuse is typically an excuse to do nothing, which has shown time and again to take much longer to improve performance than doing six sigma.

Myth Two: Six Sigma Stiffles Innovation

Nothing could be further from the truth. I am most familiar with the Design For Six Sigma (DFSS) method known as PIDOV. (Plan, Identify, Design, Optimize, Validate) I also have some exposure to DMADV but am less familiar. A brief review of the steps that underly each of the phases will quickly show that there is no step in the process where creative thinking is discouraged. In fact creative thinking is required to build the possible solution. The only requirement placed on innovative thinking is that the results of innovation must meet the needs of the customer as expressed by their Critical To Quality characteristics (CTQ's). That's it. Develop an innovative solution, but make sure that you have something that the customer will need. If the innovative solution meets no one's needs, who will buy it? No one. A buggy whip with GPS installed is still a buggy whip.

See my other published article

In light of my good news earlier today, I thought I should remind you to check out another article I had published a couple of years ago. This article is about a Lean Six Sigma project that I completed on a transactional process-Business Forecasting. You can check it out at the link on the right hand side of this page.