DMAIC

Define, Measure, Analyze, Improve, Control. Incremental process improvement using Six Sigma methodology. See DMAIC Methodology

Pronounced (Duh-May-Ick).

DMAIC refers to a data-driven quality strategy for improving processes, and is an integral part of the company's Six Sigma Quality Initiative. DMAIC is an acronym for

five interconnected phases: Define, Measure, Analyze, Improve, and Control.

Each step in the cyclical DMAIC Process is required to ensure the best possible results. The process steps:

Define the Customer, their Critical to Quality (CTQ) issues, and the Core Business Process involved. Define who customers are, what their requirements are for products and services, and what their expectations are Define project boundaries the stop and start of the process Define the process to be improved by mapping the process flow

Measure the performance of the Core Business Process involved. Develop a data collection plan for the process Collect data from many sources to determine types of defects and metrics Compare to customer survey results to determine shortfall

Analyze the data collected and process map to determine root causes of defects and opportunities for improvement. Identify gaps between current performance and goal performance Prioritize opportunities to improve Identify sources of variation

Improve the target process by designing creative solutions to fix and prevent problems. Create innovate solutions using technology and discipline Develop and deploy implementation plan

Control the improvements to keep the process on the new course. Prevent reverting back to the "old way" Require the development, documentation and implementation of an ongoing monitoring plan Institutionalize the improvements through the modification of systems and structures (staffing, training, incentives)

DMAIC Phase Steps

Define Customers and Requirements (CTQs) Develop Problem Statement, Goals and Benefits Identify Champion, Process Owner and Team Define Resources Evaluate Key Organizational Support Develop Project Plan and Milestones Develop High Level Process Map

Tools Used

Project Charter Process Flowchart SIPOC Diagram Stakeholder Analysis DMAIC Work Breakdown Structure CTQ Definitions Voice of the Customer Gathering

Project Charter

A project charter is the first step in the Six Sigma methodology. It takes place in the Define step of DMAIC, and the charter can make or break a successful project. It can make it by specifying necessary resources and boundaries that will in turn ensure success; it can break it by reducing team focus, effectiveness and motivation.

Necessary Project Charter AreasProject Title:It may not be evident at project inception, but you are going to complete the project and over time this project will hopefully serve as a best practice for other people within your business. It's important to name the project with a properly descriptive title that will allow others to quickly view and select your project based on the keywords and phrases. If you are increasing call center effectiveness, a possible title may be Call Center Cycle Time or Call Center Variation Reduction.

Black Belt/Green Belt:This is the person leading the process improvement project. It's important to identify the project leader so management knows who's leading the efforts, and others can locate the leader for gathering further knowledge at a later date.

Mentor/Master Black Belt:It's important to identify a resource for the project leader to 'lean on' if any project questions or issues arise (and they always do). Everyone needs a helping hand -- a successful project ensures that when it's needed, the helping hand has already been identified.

Project Start Date:No project can maintain momentum indefinitely. This field is mainly for documentation purposes. It's the date the project or project leader formally started working on the project.

Anticipated Project End Date:The anticipated project end date will probably be set by the mentor, master black belt or quality leader. The duration of the project will provide the leader and team adequate time to complete the project, given business conditions, work-load, holiday schedules, and such. Many businesses set general guidelines around how long projects should take.

Cost of Poor Quality:It's sometimes easy, other times difficult, to quantify the cost of poor quality that is

being produced by your process. If scrap is being produced -- quantify it. If excess hours are being spent by employees performing manual and redundant activities -- quantify it. If violations and fines are being levied (oh my, I hope not!) -- quantify it. It just needs to give business leaders an order of magnitude guesstimate of your project savings. If you're going to save the business $6,000 over the next year, that may not be a project on which to focus an entire team.

Process Importance:Here's where we get to the meat of the matter. Every business operates by processes. So what's the process that you're improving and why is it important enough to spend time improving. For instance, if you want to improve the account opening process, you could identify how your process compares to competition, how it's the lifeline of your company, how the customer experience is suffering...you get the picture. Next we get to the exact problems.

Process Problem:Once we have a high level view of why the process is important to the business, we talk about how it's broken. For instance, there's no online data checking, customers can't instantly open accounts which leads to frustration, redundant processes lead to human error, no validation of customer typed information leads to mis-shipments of collateral, etc.

Process Start/Stop Points:We can't solve world hunger or boil the ocean (if anyone knows of any other sayings, please send them to me for inclusion), so how do we make sure we're biting off something we can chew 100 times before swallowing? Bound the project with a start and stop point: From the time a customer calls until the time the complaint is handled and customer is informed of the decision. Then, when the inevitable issue arises confusing the group's mission, you can ask -- 'Does that action/issue occur between our process stop and start points?' If the answer is no, table it and get the team focused on the task at hand.

Project Goals:What results do you anticipate from this project? Will cycle time be reduced 50%? Will defects be eliminated or at least reduced 90%? Will variable costs be identified and capped to a certain dollar figure per transaction? Set challenging but realistic goals.

Process Measurements:What are the measures that you'll use to determine effectiveness of the project. Will it be $/item or cycle time in days, or call queue time in seconds? Specify all you think may be necessary, but make sure that they are within the scope (process start/stop points) of your project.

Team Members:List the following roles and who will be filling the roles:SponsorProject LeaderSubject Matter Experts -- it's sometimes a useful reference to list the subject matter in parentheses next to each name, especially if the team is cross functional and employees don't know each other.

Project Time-Frame:We have already identified the project start and (estimated) stop points. What are

the major milestones (e.g. presentations, phases of the Six Sigma methodology, etc.) between those dates? Mentors and MBBs are very helpful in creating this part of the charter because they've done projects and have an idea for how long each step requires.

D - Define Phase

Define Customers and Requirements (CTQs) Develop Problem Statement, Goals and Benefits Identify Champion, Process Owner and Team Define Resources Evaluate Key Organizational Support Develop Project Plan and Milestones

Develop High Level Process Map

Tools Used

Project Charter Process Flowchart SIPOC Diagram Stakeholder Analysis DMAIC Work Breakdown Structure CTQ Definitions Voice of the Customer Gathering

Project Charter

A project charter is the first step in the Six Sigma methodology. It takes place in the Define step of DMAIC, and the charter can make or break a successful project. It can make it by specifying necessary resources and boundaries that will in turn ensure success; it can break it by reducing team focus, effectiveness and motivation.

So what pieces are necessary and what are some tips people have learned over the years? Alright, let's get down to business. Here are the major project charter areas that are necessary. We'll start with an explanation of each, then at the end of the article you'll find a template that you can download, print and use today.

Necessary Project Charter AreasProject Title:It may not be evident at project inception, but you are going to complete the project and over time this project will hopefully serve as a best practice for other people within your business. It's important to name the project with a properly descriptive title that will allow others to quickly view and select your project based on the keywords and phrases. If you are increasing call center effectiveness, a possible title may be Call Center Cycle Time or Call Center Variation Reduction.

Black Belt/Green Belt:This is the person leading the process improvement project. It's important to identify

the project leader so management knows who's leading the efforts, and others can locate the leader for gathering further knowledge at a later date.

Mentor/Master Black Belt:It's important to identify a resource for the project leader to 'lean on' if any project questions or issues arise (and they always do). Everyone needs a helping hand -- a successful project ensures that when it's needed, the helping hand has already been identified.

Project Start Date:No project can maintain momentum indefinitely. This field is mainly for documentation purposes. It's the date the project or project leader formally started working on the project.

Anticipated Project End Date:The anticipated project end date will probably be set by the mentor, master black belt or quality leader. The duration of the project will provide the leader and team adequate time to complete the project, given business conditions, work-load, holiday schedules, and such. Many businesses set general guidelines around how long projects should take.

Cost of Poor Quality:It's sometimes easy, other times difficult, to quantify the cost of poor quality that is being produced by your process. If scrap is being produced -- quantify it. If excess hours are being spent by employees performing manual and redundant activities -- quantify it. If violations and fines are being levied (oh my, I hope not!) -- quantify it. It just needs to give business leaders an order of magnitude guesstimate of your project savings. If you're going to save the business $6,000 over the next year, that may not be a project on which to focus an entire team.

Process Mapping and Flow Charting

Process mapping is a well-known technique for creating a common vision and shared language for improving business results. It helped one management training and development firm realize that people within their sales department had been working at cross purposes, and crucial executive-level discussions with customers were not taking place. Based on sales process mapping, the leaders reorganized their sales operations so that job descriptions and performance measures focused more on the customer. In six months, they reversed a five-year slump and earned big bonuses for team members. In another case, sales process mapping helped a large manufacturer's national account teams discover a powerful new way to coordinate with field salespeople, yielding far more new business opportunities than expected.

However, leaders in both large and small sales organizations often make mistakes that undermine the potential of process mapping. A common result, for example, is that salespeople ignore the process and operate "outside the system." Based on work with several dozen clients, I've observed four common mistakes that tend to hinder their success

Flowchart

A flowchart is a graphical representation of a process, depicting inputs, outputs and units of activity. It represents the entire process at a high or detailed (depending on your use) level of observation, allowing analysis and optimization of workflow.

A flowchart is a graphical representation of a process. It represents the entire process from start to finish, showing inputs, pathways and circuits, action or decision points, and ultimately, completion. It can serve as an instruction manual or a tool for facilitating detailed analysis and optimization of workflow and service delivery.

SIPOC Diagram

A SIPOC diagram is a tool used by a team to identify all relevant elements of a process improvement project before work begins. It helps define a complex project that may not be well scoped, and is typically employed at the Measure phase of the Six Sigma DMAIC methodology. It is similar and related to Process Mapping and 'In/Out Of Scope' tools, but provides additional detail.

The tool name prompts the team to consider the Suppliers (the 'S' in SIPOC) of your process, the Inputs (the 'I') to the process, the Process (the 'P') your team is improving, the Outputs (the 'O') of the process, and the Customers (the 'C') that receive the process outputs. In some cases, Requirements of the Customers can be appended to the end of the SIPOC for further detail.

The SIPOC tool is particularly useful when it is not clear:

Who supplies Inputs to the process? What specifications are placed on the Inputs? who are the true Customers of the process? what are the Requirements of the customers?

Steps To Complete the SIPOC Diagram

SIPOC diagrams are very easy to complete. Here are the steps you should follow:

1. Create an area that will allow the team to post additions to the SIPOC diagram. This could be a transparency (to be projected by an overhead) made of the provided template, flip charts with headings (S-I-P-O-C) written on each, or headings written on post-it notes posted to a wall.

2. Begin with the Process. Map it in four to five high level steps. 3. Identify the Outputs of this Process. 4. Identify the Customers that will receive the Outputs of this Process. 5. Identify the Inputs required for the Process to function properly. 6. Identify the Suppliers of the Inputs that are required by the Process. 7. Optional: Identify the preliminary requirements of the Customers. This will be

verified during a later step of the Six Sigma measurement phase. 8. Discuss with Project Sponsor, Champion, and other involved stakeholders for

verification.

Stakeholder Analysis

Stakeholder Analysis is a tool used to identify and enlist support from stakeholders. It provides a visual means of identifying stakeholder support so that you can develop an action plan for your project.

Customer CTQs - Defining Defect, Unit and Opportunity

In order for any process capability to accurately be calculated, one must properly define and quantify the process defect, unit and opportunity. Every process should have definitions for defect, unit and opportunity. This article will define the defects, units and opportunities, as well as provide examples.

Jump To The Following Sections:

Start With The Customer Define Your Product/Service Defects Define Your Product/Service Units Define Your Product/Service Opportunities CTQ Examples Including Defect, Unit and Opportunity

Start With The CustomerBefore you can define your process defects, units and opportunities, you need to understand the needs of your customers. Voice of the Customer (Customer Needs, eSurveys, Focus Groups, Surveys) is the process of gathering customer comments/quotes and translating them into issues and specifications. From these comments, issues and specifications come the customer CTQ (Critical To Quality) - a product or service characteristic that must be met to satisfy a customer specification or requirement.

Define Your Product/Service DefectsA defect is defined as any part of a product or service that:

does not meet customer specifications or requirements, or causes customer dissatisfaction, or does not fulfill the functional or physical requirements.It should be noted that the term customer refers to both internal and external customers. Define Your Product/Service UnitsA unit is something that can be quantified by a customer. It is a measurable and observable output of your business process. It may manifest itself as a physical unit or, if a service, it may have specific start and stop points.

Define Your Product/Service OpportunitiesSimply stated, opportunities are the total number of chances per unit to have a defect. Each opportunity must be independent of other opportunities and, like a unit, must be measurable and observable. The final requirement of an opportunity is that it directly relates to the customer CTQ (see Start With The Customer above). The total count of opportunities indicates the complexity of a product or service.

Voice of the Customer

Customer Needs eSurveys Focus Groups Surveys

M - Measure Phase

Define Defect, Opportunity, Unit and Metrics Detailed Process Map of Appropriate Areas Develop Data Collection Plan Validate the Measurement System Collect the Data Begin Developing Y=f(x) Relationship Determine Process Capability and Sigma Baseline

Tools Used

Process Flowchart Data Collection Plan/Example Benchmarking Measurement System Analysis/Gage R&R Voice of the Customer Gathering Process Sigma Calculation

Building a Data Collection Plan

Black Belts and Six Sigma practitioners who are leading DMAIC projects should develop a sound data collection plan in order to gather data in the measurement phase. There are several crucial steps that need to be addressed to ensure that the data collection process and measurement systems are stable and reliable. Incorporating these steps into a data collection plan will improve the likelihood that the data and measurements can be used to support the ensuing analysis. What follows is a description of these steps. A checklist, populated with dummy responses, is also provided to illustrate the importance of building a well-defined data collection plan prior to execution.

Three phases -- five steps total -- are involved in building a sound data collection plan:

Pre-Data Collection Steps1. Clearly define the goals and objectives of the data collection2. Reach understanding and agreement on operational definitions and methodology for the data collection plan3. Ensure data collection (and measurement) repeatability, reproducibility, accuracy, and stability

During Collection Steps4. Follow through with the data collection process

Post-Data Collection Steps5. Follow through with the results

Step 1: Define Goals And Objectives

A good data collection plan should include:

a brief description of the project,

the specific data that is needed, the rationale for collecting the data, what insight the data might provide (to a process being studied) and how it

will help the improvement team, and what will be done with the data once it has been collected.

Being clear on these elements will facilitate the accurate and efficient collection of data.

Step 2: Define Operational Definitions and MethodologyThe improvement team should clearly define what data is to be collected and how. It should decide what is to be evaluated and determine how a numerical value will be assigned, so as to facilitate measurement. The team should consider consulting with the customer to see if they are already collecting the same (or similar) data. If so, comparisons can be made and best practices shared. The team should also formulate the scope of the data collection:

how many observations are needed,

what time interval should be part of the study, whether past, present, and future data will be collected, and the methodologies that will be employed to record all the data.

It is best to obtain complete understanding of and agreement on all the applicable definitions, procedures and guidelines that will be used in the collection of data. Overlooking this step can yield misleading results if members of the improvement team are interpreting loosely defined terms differently when collecting data. Serious problems can arise for the organization when business decisions are made based on this potentially unreliable data.

If the team wishes to examine historical data to include as part of the study, careful attention should be paid to how reliable the data and its source has been, and whether it is advisable to continue using such data. Data that proves to be suspect should be discarded.

Step 3: Ensuring Repeatability, Reproducibility, Accuracy and StabilityThe data being collected (and measured) will be repeatable if the same operator is able to reach essentially the same outcome multiple times on one particular item with the same equipment. The data will be reproducible if all the operators who are measuring the same items with the same equipment are reaching essentially the same outcomes. In addition, the degree to which the measurement system is

accurate will generally be the difference between an observed average measurement and the associated known standard value. The degree to which the measurement system is stable is generally expressed by the variation resulting from the same operator measuring the same item, with the same equipment, over an extended period.

Improvement teams need to be cognizant of all the possible factors that would cause reductions in repeatability, reproducibility, accuracy and stability - over any length of time - that in turn may render unreliable data. It is good practice to test, perhaps on a small scale, how the data collection and measurements will proceed. It should become apparent upon simulation what the possible factors are, and what could be done to mitigate the effects of the factors or to eliminate the factors altogether.

Step 4: The Data Collection ProcessOnce the data collection process has been planned and defined, it is best to follow through with the process from start to finish, ensuring that the plan is being executed consistently and accurately. Assuming the Black Belt or project lead has communicated to all the data collectors and participants what is to be collected and the rationale behind it, he or she might need to do additional preparation by reviewing with the team all the applicable definitions, procedures, and guidelines, etc., and checking for universal agreement. This could be followed up with some form of training or demonstration that will further enhance a common understanding of the data collection process as defined in the plan.

It is a good idea that the Black Belt or project lead be present at the commencement of data collection to provide some oversight. This way the participants will know right away whether or not the plan is being followed properly. Failure to oversee the process at its incipient stages might mean that a later-course correction will need to be made, and much of the data collection and/or measurement efforts will be wasted. Depending on the length of time it takes to collect data - and whether the data collection is ongoing - providing periodic oversight will help to ensure that there are no shortcuts taken and that any new participants are properly oriented with the process to preserve consistency.

Step 5: After The Data Collection ProcessReferring back to the question of whether or not the data collection and measurement systems are reproducible, repeatable, accurate, and stable, the Black Belt or project lead should check to see that the results (data and measurements) are reasonable and that they meet the criteria. If the results are not meeting the criteria, then the Black Belt or project lead should determine where any breakdowns exist and what to do with any data and/or measurements that are suspect. Reviewing the operational definitions and methodology with the participants should help to clear up any misunderstandings or misinterpretations that may have caused the breakdowns.

Analyze Phase

Define Performance Objectives Identify Value/Non-Value Added Process Steps Identify Sources of Variation Determine Root Cause(s) Determine Vital Few x's, Y=f(x) Relationship

Tools Used

Histogram Pareto Chart Time Series/Run Chart Scatter Plot Regression Analysis Cause and Effect/Fishbone Diagram 5 Whys Process Map Review and Analysis Statistical Analysis Hypothesis Testing (Continuous and Discrete) Non-Normal Data Analysis

Histogram

Purpose Of A HistogramA histogram is used to graphically summarize and display the distribution of a process data set.

How to Construct A HistogramA histogram can be constructed by segmenting the range of the data into equal sized bins (also called segments, groups or classes). For example, if your data ranges from 1.1 to 1.8, you could have equal bins of 0.1 consisting of 1 to 1.1, 1.2 to 1.3, 1.3 to 1.4, and so on.

The vertical axis of the histogram is labeled Frequency (the number of counts for each bin), and the horizontal axis of the histogram is labeled with the range of your response variable.

You then determine the number of data points that reside within each bin and construct the histogram. The bins size can be defined by the user, by some common rule, or by software methods (such as Minitab).

What Questions the Histogram Answers

What is the most common system response? What distribution (center, variation and shape) does the data have? Does the data look symmetric or is it skewed to the left or right? Does the data contain outliers?

Pareto Chart

Purpose Of A Pareto ChartA pareto chart is used to graphically summarize and display the relative importance of the differences between groups of data.

How To Construct A Pareto ChartA pareto chart can be constructed by segmenting the range of the data into groups (also called segments, bins or categories). For example, if your business was investigating the delay associated with processing credit card applications, you could group the data into the following categories:

No signature Residential address not valid Non-legible handwriting Already a customer Other The left-side vertical axis of the pareto chart is labeled Frequency (the number of counts for each category), the right-side vertical axis of the pareto chart is the cumulative percentage, and the horizontal axis of the pareto chart is labeled with the group names of your response variables.

You then determine the number of data points that reside within each group and construct the pareto chart, but unlike the bar chart, the pareto chart is ordered in descending frequency magnitude. The groups are defined by the user.

What Questions The Pareto Chart Answers

What are the largest issues facing our team or business? What 20% of sources are causing 80% of the problems (80/20 Rule)? Where should we focus our efforts to achieve the greatest improvements?

Constructing Run Charts

A run chart is a line graph that shows data points plotted in the order in which they occur. They are used to show trends and shifts in a process over time, variation over time, or to identify decline or improvement in a process over time. They can be used to examine both variables and attribute data.

Steps in Constructing a Run Chart

1. Draw and label the vertical (y) axis using the measurement units you are tracking (e.g., numbers of defectives, mean diameter, number of graduates, percent defective, etc.)

2. Draw and label the horizontal (x) axis to reflect the sequence in which the data points are collected (e.g., week 1, week 2, ... or 8AM, 9AM, 10AM, etc.)

3. Plot the data points on the chart in the order in which they became available and connect the points with lines between them.

4. Calculate the average from the data, and draw a horizontal line across the chart at the level of the average.

5. Interpret the chart and decide what action to take. Are trends present? Would the chart look different if everything were perfect? The key is to look for trends, and not focus on individual points.

Example:

Average Math Entrance Exam Scores by Year Average Year Math Score 1975 1391976 1301977 61 1978 164 1979 1291980 1001981 108 1982 110 1983 68 1984 78 1985 57 1986 77 1987 38 1988 53 1989 50 1990 81 1991 105 1992 65 1993 97 1994 62 1995 961996 93

It should be obvious from this chart, that average math scores in the eighties dropped from those in the seventies, and now, in the nineties have rebounded somewhat but are still lower than they were in the seventies.

Scatter Diagram

A Scatter Diagram is used to interpret data by graphically displaying the relationship between two variables.

A Scatter Diagram Is Used For:

1. Validating "hunches" about a cause-and-effect relationship between types of variables (examples: I wonder if students who spend more time watching TV have higher or lower average GPA's?; is there a relationship between the production speed of an operator and the number of defective parts made?; is there a relationship between typing speed in WPM and errors made?)

2. Displaying the direction of the relationship (positive, negative, etc.) (examples: Will test scores increase or decrease if the students spend more time in study hall?; will increasing assembly line speed increase or decrease the number of defective parts made?; do faster typists make more or fewer typing errors?)

3. Displaying the strength of the relationship (examples: How strong is the relationship between measured IQ and grades earned in Chemistry?; how strong is the relationship between assembly line speed and the number of defective parts produced?; how strong is the relationship between typing faster and the number of typing errors made?)

Steps In Constructing A Scatter Diagram:

1. Collect two pieces of data (a pair of numbers) on a student, process, or product. Create a summary table of the data.

2. Draw a diagram labeling the horizontal and vertical axes. It is common that the "cause" variable be labeled the horizontal (X) axis and the "effect" variable be labeled the vertical (Y) axis. The values should increase up the vertical scale and toward the right on the horizontal scale. The scale on both the X and Y axes should be sufficient to include both the largest and the smallest X and Y values in the table.

3. Plot the data pairs on the diagram by placing a dot at the intersections of the X and Y coordinates for each data pair.

1. Interpret the scatter diagram for direction and strength. Interpreting the direction:

Data patterns may be positive, negative, or display no relationship. A positive relationship is indicated by an ellipse of points that slopes upward demonstrating that an increase in the cause variable also increases the effect variable. A negative relationship is indicated by an ellipse of points that slopes downward demonstrating that an increase in the cause variable results in a decrease in the effect variable. A diagram with a cluster of points such that it is difficult or impossible to determine whether the trend is upward sloping or downward sloping indicates that there is no relationship between the two variables.

Interpreting the strength:

4.Data patterns, whether in a positive or negative direction, should also be interpreted for strength by examining the "tightness" of the clustered points.

The more the points are clustered to look like a straight line the stronger the relationship.

Regression and Multiple Regression

Determine the Root Cause: 5 Whys

Asking "Why?" may be a favorite technique of your three year old child in driving you crazy, but it could teach you a valuable Six Sigma quality lesson. The 5 Whys is a technique used in the Analyze phase of the Six Sigma DMAIC methodology. It's a great Six Sigma tool that doesn't involve data segmentation, hypothesis testing, regression or other advanced statistical tools, and in many cases can be completed without a data collection plan.

By repeatedly asking the question "Why" (five is a good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of a problem. Very often the ostensible reason for a problem will lead you to another question. Although this technique is called "5 Whys," you may find that you will need to ask the question fewer or more times than five before you find the issue related to a problem.

Benefits Of The 5 Whys

Help identify the root cause of a problem. Determine the relationship between different root causes of a problem. One of the simplest tools; easy to complete without statistical analysis. When Is 5 Whys Most Useful?

When problems involve human factors or interactions. In day-to-day business life; can be used within or without a Six Sigma project. How To Complete The 5 Whys1. Write down the specific problem. Writing the issue helps you formalize the problem and describe it completely. It also helps a team focus on the same problem.2. Ask Why the problem happens and write the answer down below the problem.3. If the answer you just provided doesn't identify the root cause of the problem that you wrote down in step 1, ask Why again and write that answer down.4. Loop back to step 3 until the team is in agreement that the problem's root cause is identified. Again, this may take fewer or more times than five Whys.

5 Whys ExamplesProblem Statement: Customers are unhappy because they are being shipped products that don't meet their specifications.1. Why are customers being shipped bad products?  - Because manufacturing built the products to a specification that is different from what the customer and the sales person agreed to.2. Why did manufacturing build the products to a different specification than that of sales?  - Because the sales person expedites work on the shop floor by calling the head of manufacturing directly to begin work. An error happened when the specifications were being communicated or written down.

3. Why does the sales person call the head of manufacturing directly to start work instead of following the procedure established in the company?  - Because the "start work" form requires the sales director's approval before work can begin and slows the manufacturing process (or stops it when the director is out of the office).4. Why does the form contain an approval for the sales director?  - Because the sales director needs to be continually updated on sales for discussions with the CEO.

In this case only four Whys were required to find out that a non-value added signature authority is helping to cause a process breakdown.

Let's take a look at a slightly more humorous example modified from Marc R.'s posting of 5 Whys in the I Six Sigma Dictionary.

Problem Statement: You are on your way home from work and your car stops in the middle of the road.1. Why did your car stop?  - Because it ran out of gas.2. Why did it run out of gas?  - Because I didn't buy any gas on my way to work.3. Why didn't you buy any gas this morning?  - Because I didn't have any money.4. Why didn't you have any money?  - Because I lost it all last night in a poker game.5. Why did you lose your money in last night's poker game?  - Because I'm not very good at "bluffing" when I don't have a good hand.

As you can see, in both examples the final Why leads the team to a statement (root cause) that the team can take action upon. It is much quicker to come up with a system that keeps the sales director updated on recent sales or teach a person to "bluff" a hand than it is to try to directly solve the stated problems above without further investigation.

5 Whys And The Fishbone DiagramThe 5 Whys can be used individually or as a part of the fishbone (also known as the cause and effect or Ishikawa) diagram. The fishbone diagram helps you explore all potential or real causes that result in a single defect or failure. Once all inputs are established on the fishbone, you can use the 5 Whys technique to drill down to the root causes.

Improve Phase

Perform Design of Experiments Develop Potential Solutions Define Operating Tolerances of Potential System Assess Failure Modes of Potential Solutions Validate Potential Improvement by Pilot Studies Correct/Re-Evaluate Potential Solution

Tools Used

Brainstorming Mistake Proofing Design of Experiments Pugh Matrix House of Quality Failure Modes and Effects Analysis (FMEA) Simulation Software

Effective Brainstorming

Brainstorming session is a tool for generating as many ideas or solutions as possible to a problem or issue. It is not a tool for determining the best solution to a problem or issue. The process of analyzing your brainstormed ideas will not be discussed here; please visit the Affinity Diagram category of Quality links for more information on that subject.

Before beginning any effective brainstorming session, ground rules must be set. This doesn't mean that boundaries are set so tightly that you can't have fun or be creative. It does mean that a code of conduct for person to person interactions has been set. It's when this code of conduct is breached that people stop being creative.

The best way to have meaningful groundrules is to have the team create their own. Try performing a mini-brainstorming session around creating brainstorming groundrules. It should provide a nice opportunity to practice the skills necessary for an effective brainstorming session. This also allows the team to take ownership of acceptable and unacceptable behaviors. Only if the team hasn't addressed the key groundrules should you (as the facilitator) add to the list. Once the groundrules list is generated, be sure to gain consensus that the session will be conducted according to them, and post them in a highly visible location in the room.

With that, here are four key groundrules that are useful when conducting a brainstorming session:

There are no dumb ideas. Period. It's a brainstorming session, not a serious matter that requires only serious solutions. Remember, this is one of the more fun tools of quality, so keep the entire team involved !

Don't criticize other people's ideas. This isn't a debate, discussion or forum for one person to display superiority over another.

Build on other people's ideas. Often an idea suggested by one person can trigger a bigger and/or better idea by another person. Or a variation of an idea on the board could be the next 'velcro' idea. It is this building of ideas that leads to out of the box thinking and fantastic ideas.

Reverse the thought of 'quality over quantity.' Here we want quantity; the more creative ideas the better. As a facilitator, you can even make it a challenge to come up with as many ideas as possible and compare this team's performance to the last brainstorming session you conducted.

Other brainstorming preparation questions:

Who will lead or facilitate the brainstorming session? Who will participate in the brainstorming session? Who can write very quickly to record the brainstormed ideas without slowing

down the group? Where will the brainstorming session be held? What materials are needed for brainstorming (easel, paper, white board, pens,

etc.)? What is my brainstorming session desired outcome?

Poka Yoke Mistake Proofing

It was a Japanese manufacturing engineer named Shigeo Shingo who developed the concept that revolutionized the quality profession in Japan. Originally called "fool proofing" and later changed to "mistake proofing" and "fail safing" so employees weren't offended, poka yoke (pronounced "poh-kah yoh-kay") translates into English as to avoid (yokeru) inadvertent errors (poka). The result is a business that wastes less energy, time and resources doing things wrong in the future.

What Is Poka Yoke?Poka yoke is one of the main components of Shingo's Zero Quality Control (ZQC) system -- the idea being to produce zero defective products. One way this was achieved is through the use of poka yoke; a bunch of small devices that are used to either detect or prevent defects from occurring in the first place. These poka yoke methods are simple ways to help achieve zero defects.

Who Develops Poka Yokes?Here's the beauty of the methods...anyone, from manager to line supervisor to line employee can develop a poka yoke. (Alright for you transaction people out there...anyone, from regional sales manager to sales associate to document specialist). All it takes is the empowerment of employees, as well as a little instruction around what makes a good poka yoke.

What Does A Poka Yoke Look Like?Poka Yoke looks different in each situation. I'll try to present a few different scenarios for poka yoke use. Let's take a transactional situation and analyze a few parts of it. Say, for instance, we're at the signing of a bank loan by a lucky couple closing the mortgage on their first home.

Example 1:The lucky couple picks up the pen to sign, but when they depress the top of the pen to extend the writing part it malfunctions because the spring is missing. A poka yoke could have prevented this situation. If all pieces of the pen were presented to the assembler in a dish, a simple poka yoke would be for the assembler to visually inspect the dish for any remaining parts once the pen was assembled. (Ok, I lied about this being only a transactional process!)

Example 2:The lucky couple bypasses the signature part of the process because their bank is really high-technology focused. In fact, they signed a writing pad and their signature

was recorded electronically. The bank also needed to collect 4 additional pieces of information before the entire package of information is sent to the processing department. A simple poka yoke to add to this process is to require all fields to be filled in (including the loanee signature) before allowing the form to be sent to processing. This prevents the processing department from reviewing an incomplete document, sending back to the loan department, delaying the processing of paperwork...you get the idea.

Example 3:Once the complete paperwork is submitted to the processing department and it is printed, it then needs to be filed with the city and state. In order for this to occur, papers need to be filled out (the city and state are not high-technology enabled) and attached to the form. A poka yoke used by the city is a simple check-sheet at the top of the form. This allows the person submitting the form to ensure that all additional information and payments are attached. As in example 2 above, this prevents the city/state from reviewing an incomplete document, sending back the document to the sender, delaying the processing of paperwork...again, you get the idea.

ConclusionIs there any rocket science to poka yoke? I don't think so either. So what's the big deal? Well, the big deal involves execution within your business. Bright ideas are a dime a dozen, it's the execution that's the hard part. First, you need to educate your workforce on the concept of poka yoke (call it mistake proofing for ease). Second, you need to empower your employees to make a bunch of small improvements to their processes -- continuously. What you will end up with a business that wastes less energy, time and resources doing things wrong in the future.

User Test - Real World ScenarioI was recently reading a newspaper article entitled "Surgeon operates on wrong side of man's head". An except is below:

Providence, Rhode Island, USA - A surgeon at Rhode Island Hospital operated on the wrong side of a man's brain after a CAT scan was placed the wrong way round on an X-ray viewing box, the hospital told the state Health Department.

The patient had bleeding on the right side of his brain but the reversed scan made it look as if the bleeding was on the left. In addition, the patient's incision site had not been marked with a pen, as recommended by error-prevention experts.You're probably thinking the same thing as me...WOW, how could this happen with all the procedures, mistake proofing, quality systems, etc.? It just amazes me. The good news is that the patient lived after the doctor repeated the procedure on the right side and the blood was drained. It turns out that wrong-side surgery tops a list of 27 serious, preventable events says the National Quality Forum, which promotes a strategy for measuring health-care quality.

Most Practical DOE Explained

Generic Steps For Using The Attached SpreadsheetThere are many different articles in the literature that outline steps that should be

taken to complete a DOE. The following steps are recommended for using the accompanying spreadsheet:

1. Determine the acceptance criteria you need (i.e. acceptable alpha error or confidence level for determining what you will accept as passing criteria). This is typically alpha=.05 or 95% confidence for solid decisions; see additional advice below.

2. Pick 2-3 factors to be tested and assign them to columns A, B, and C as applicable (advise using the key provided).

3. Pick 2 different test levels for each of the factors you picked (i.e. low/high, on/off, etc.).

4. Determine the number of samples per run (room for 1-8 only; affects normality and effect accuracy, not confidence).

5. Randomize the order to the extent possible.6. Run the experiment and collect data. Keep track of everything you think could

be important (i.e. people, material lot numbers, etc.). Keep all other possible control factors as constant as possible as these may affect the validity of the conclusions.

7. Analyze the data by entering the data into the yellow boxes of the spreadsheet and reading the results. A review of the ANOVA table will show you those effects that meet the acceptance criteria established in step number one. If the alpha value in the table is greater than the acceptance criteria, accept the result; if it is less, reject the result. Similarly, the higher the confidence, the higher the probability that that factor is statistically different from the others. Signal to noise measurements are helpful to use when selecting factors for re-testing in subsequent experiments.

8. Confirm your results by performing a separate test, another DOE, or in some other way before fully accepting any results. You may want to more closely define results that are close to your acceptance criteria by retesting the factor using larger differences between the levels.

Additional AdviceHow DOEs WorkNote that using the eight run array, we have four runs being tested with each factor at high levels and four without being at a high level. We have the equivalent of eight data points comparing the effects of each high level (4 high + 4 not high = 8 relative to high) and vice versa for each factor and the interactions between the three factors. Therefore, using this balanced multifactor DOE array, our eight run test becomes the statistical equivalent of a 96 run, one-factor-at-a-time (OFAT) test [(8 Ahigh)+(8 Alow)+(8 Bhigh)+(8 Blow)+(8 Chigh)+(8 Clow)+(8 ABhigh)+(8 ABlow)+(8 AChigh)+(8 AClow)+(8 BChigh)+(8 BClow)]. Other advantages to using DOE include the ability to use statistical software to make predictions about any combination of the factors in between and slightly beyond the different levels, and generating various types of informative two- and three-dimensional plots. Therefore, DOEs produce orders of magnitude more information than OFAT tests at the same or lower test costs.

DOEs don't directly compare results against a control or standard. They evaluate all effects and interactions and determine if there are statistically significant differences among them. They also calculate statistical confidence levels for each measurement. A large effect might result but if the statistical confidence for that measurement is low then that effect is not believed. On the other hand, a small measured effect with high confidence tells us that the effect really isn't important.

Why This Array?Selecting a test array requires balancing your test objectives, test conditions, test strategy, and resources available. Therefore, it is usually more advantageous to run several DOEs testing only a few factors at once than one large DOE. Comparing the statistical power of this array (inherent ability to resolve differences between test factors; 1-b) with the cost of performing the experiment (number of runs needed) also shows how this array is advantageous since it requires only eight runs and yields successful results in most situations.

Picking Acceptance CriteriaAcceptable confidence depends upon your needs. If health could be affected, then you may want more than 99% confidence before making a decision. This author's rule of thumb is that 51-80% is considered low but in some cases is worth considering (see precautions below). A confidence level of 80-90% is considered moderate with the results likely to be at least partially correct and a confidence level greater than 90% is considered high with the results usually considered very likely to be correct.

Calculating Samples Per RunSince statistical confidence doesn't increase with additional samples per run (replications are needed to have that effect), it is important to remember that additional samples per run are only needed when concerns of non-normal data exist (in accordance with the central limit theorem) and or to improve measured effect accuracy (significance of changes between test levels). Since test costs and/or knowing the statistical confidence in our effects is usually more important than statistical significance and normality effects, running two to three samples per run is usually ideal.

PrecautionsSince this array has less power than others available, we need to remember that when optimizing a process that isn't critical to human safety, using test results with a low confidence level can often be much better than not knowing which way to go with machine settings, etc. Assuming all the error in one's experiment is evenly distributed (random distribution of error), a confidence level of 60% (measured to be true via DOE), for example, might seem horrible but really means the equivalent of 80%, since the 40% that we are unsure of could go either way [60% + (40% / 2) = 80%].

The accompanying spreadsheet cannot easily be changed. It should be used while training others (shows the math), or when you want to perform a quick experiment and are away from statistical software. It can't be replicated or you can't add center points in its current form (center points increase statistical confidence by improving measurements of error in the experiment).

Pugh Matrix

Pugh method or decision-matrix method

This is a method for concept selection using a scoring matrix called the Pugh Matrix.  It is implemented by establishing an evaluation team, and setting up a matrix of evaluation criteria versus alternative embodiments.  This is the scoring matrix usually associated with the QFD method and is a form of prioritization matrix. Usually, the options are scored relative to criteria using a symbolic approach (one symbol for better than, another for neutral, and another for worse than baseline). These get converted into scores and combined in the matrix to yield scores for each option.

Effective for comparing alternative concepts Scores concepts relative to one another Iterative evaluation method Most effective if each member of a design tean performs it independently and

results are compared.

Comparison of the scores generated gives insight into the best alternatives.

Steps to Use/Construct Pugh matrix:

1.     Choose or develop the criteria for comparison.  Examine customer requirements to do this. Generate a set of engineering requirements and targets.

2.      Select the Alternatives to be compared.

        The alternatives are the different ideas developed during concept generation.  All concepts should be compared at the same level of generalization and in similar language.

3.      Generate Scores.

    Usually designers will have a favorite design, by the time it comes to pick one.  This concept can be used as datum, with all the other being compared to it as measured by each of the customer requirements.  If the problem is to redesign an existing product, then the existing product can be used as the datum.

    For each comparison the product should be evaluated as being better (+), the same (S), or worse (-).  Alternatively, if the matrix is developed with a spreadsheet like Excel, use +1, 0, and –1 for the ratings. 

If it is impossible to make a comparison, more information should be developed.

4.      Compute the total score

Four scores will be generated, the number of plus scores, minus scores, the overall toal and the weighted total. 

The overall total is the number of plus scores- the number of minus scores. The weighted total is the scores times their respective weighting factors,

added up. The totals should not be treated as absolute in the decision making process

but as guidance only.

If the two top scores are very close or very similiar, then they should be examined more closely to make a more informed decision.

5.      Variations on scoring

    A number of variations on scoring Pugh’s method exist.  For example a seven level scale could be used for a finer scoring system where:

+3  meets criterion extremely better than datum +2  meets criterion much better than datum

+1  meets criterion better than datum   0  meets criterion as well as datum -1  meets criterion not as well as datum -2  meets criterion much worse then the datum -3  meets criterion far worse than the datum

Quality Function Deployment (QFD) / House of Quality

Quality Function Deployment (QFD) is a set of powerful product development tools that were developed in Japan to transfer the concepts of quality control from the manufacturing process into the new product development process.The main features of QFD are a focus on meeting market needs by using actual customer statements (referred to as the "Voice of the Customer"), its effective application of mutli disciplinary teamwork and the use of a comprehensive matrix (called the "House of Quality") for documenting information, perceptions and decisions. Some of the benefits of adopting QFD have been documented as :

Reduced time to market Reduction in design changes Decreased design and manufacturing costs Improved quality Increased customer satisfaction

QFD uses a series of matrices to document information collected and developed and represent the team's plan for a product. The QFD methodology is based on a systems engineering approach consisting of the following general steps:

1. Derive top-level product requirements or technical characteristics from customer needs (Product Planning Matrix).

2. Develop product concepts to satisfy these requirements.3. Evaluate product concepts to select most optimum (Concept Selection Matrix).4. Partition system concept or architecture into subsystems or assemblies and

flow-down higher- level requirements or technical characteristics to these subsystems or assemblies.

5. Derive lower-level product requirements (assembly or part characteristics) and specifications from subsystem/assembly requirements (Assembly/Part Deployment Matrix).

6. For critical assemblies or parts, flow-down lower-level product requirements (assembly or part characteristics) to process planning.

7. Determine manufacturing process steps to meet these assembly or part characteristics.

8. Based in these process steps, determine set-up requirements, process controls and quality controls to assure achievement of these critical assembly or part characteristics.

The QFD process described below is supported by DRM Associates' QFD training snd software package. The matrices and the specific steps in the QFD process are as follows.

Gather Customer Needs

1. Plan collection of customer needs. What sources of information will be used? Consider customer requirement documents, requests for proposals, requests for quotations, contracts, customer specification documents, customer meetings/interviews, focus groups/clinics, user groups, surveys, observation, suggestions, and feedback from the field. Consider both current customers as well as potential customers. Pay particular attention to lead customers as they are a better indicator of future needs. Plan who will perform the data collection activities and when these activities can take place. Schedule activities such as meetings, focus groups, surveys, etc.

2. Prepare for collection of customer needs. Identify required information. Prepare agendas, list of questions, survey forms, focus group/user meeting presentations.

3. Determine customer needs or requirements using the mechanisms described in step 1. Document these needs. Consider recording any meetings. During customer meetings or focus groups, ask "why" to understand needs and determine root needs. Consider spoken needs and unspoken needs. Extract statements of needs from documents. Summarize surveys and other data. Use techniques such as ranking, rating, paired comparisons, or conjoint analysis to determine importance of customer needs. Gather customer needs from other sources such as customer requirement documents, requests for proposals, requests for quotations, contracts, customer specification documents, customer meetings/interviews, focus groups, product clinics, surveys, observation, suggestions, and feedback from the field.

4. Use affinity diagrams to organize customer needs. Consolidate similar needs and restate. Organize needs into categories. Breakdown general customer needs into more specific needs by probing what is needed. Maintain dictionary of original meanings to avoid misinterpretation. Use function analysis to identify key unspoken, but expected needs.

5. Once needs are summarized, consider whether to get further customer feedback on priorities. Undertake meetings, surveys, focus groups, etc. to get customer priorities. State customer priorities using a 1 to 5 rating. Use ranking techniques and paired comparisons to develop priorities.

Product Planning

1. Organize customer needs in the Product Planning Matrix. Group under logical categories as determined with affinity diagramming.

2. Establish critical internal customer needs or management control requirements; industry, national or international standards; and regulatory requirements. If standards or regulatory requirements are commonly understood, they should not be included in order to minimize the information that needs to be addressed.

3. State customer priorities. Use a 1 to 5 rating. Critical internal customer needs or management control requirements; industry, national or international standards; and regulatory requirements, if important enough to include, are normally given a rating of "3".

4. Develop competitive evaluation of current company products and competitive products. Use surveys, customer meetings or focus groups/clinics to obtain feedback. Rate the company's and the competitor's products on a 1 to 5 scale with "5" indicating that the product fully satisfies the customer's needs. Include competitor's customer input to get a balanced perspective.

5. Review the competitive evaluation strengths and weaknesses relative to the customer priorities. Determine the improvement goals and the general strategy for responding to each customer need. The Improvement Factor is

"1" if there are no planned improvements to the competitive evaluation level. Add a factor of .1 for every planned step of improvement in the competitive rating, (e.g., a planned improvement of going from a rating of "2" to "4" would result in an improvement factor of "1.2". Identify warranty, service, or reliability problems & customer complaints to help identify areas of improvement.

6. Identify the sales points that Marketing will emphasize in its message about the product. There should be no more than three major or primary sales points or two major sales points and two minor or secondary sales points in order to keep the Marketing message focused. Major sales points are assigned a weighting factor of 1.3 and minor sales points are assigned a weighting factor of 1.1.

7. The process of setting improvement goals and sales points implicitly develops a product strategy. Formally describe that strategy in a narrative form. What is to be emphasized with the new product? What are its competitive strengths? What will distinguish it in the marketplace? How will it be positioned relative to other products? In other words, describe the value proposition behind this product. The key is to focus development resources on those areas that will provide the greatest value to the customer. This strategy brief is typically one page and is used to gain initial focus within the team as well as communicate and gain concurrence from management.

8. Establish product requirements or technical characteristics to respond to customer needs and organize into logical categories. Categories may be related to functional aspects of the products or may be grouped by the likely subsystems to primarily address that characteristic. Characteristics should be meaningful (actionable by Engineering), measurable, practical (can be determined without extensive data collection or testing) and global. By being global, characteristics should be stated in a way to avoid implying a particular technical solution so as not to constrain designers. This will allow a wide range of alternatives to be considered in an effort to better meet customer needs. Identify the direction of the objective for each characteristic (target value or range, maximize or minimize).

9. Develop relationships between customer needs and product requirements or technical characteristics. These relationships define the degree to which as product requirement or technical characteristic satisfies the customer need. It does NOT show a potential negative impact on meeting a customer need - this will be addressed later in the interaction matrix. Consider the goal associated with the characteristic in determining whether the characteristic satisfies the customer need. Use weights (we recommend using 5-3-1 weighting factors) to indicate the strength of the relationship - strong, medium and weak. Be sparing with the strong relationships to discriminate the really strong relationships.

10. Perform a technical evaluation of current products and competitive products. Sources of information include: competitor websites, industry publications, customer interviews, published specifications, catalogs and brochures, trade shows, purchasing and benchmarking competitor’s products, patent information, articles and technical papers, published benchmarks, third-party service & support organizations, and former employees. Perform this evaluation based on the defined product requirements or technical characteristics. Obtain other relevant data such as warranty or service repair occurrences and costs.

11. Develop preliminary target values for product requirements or technical characteristics. Consider data gathered during the technical evaluation in setting target values. Do not get too aggressive with target values in areas

that are not determined to be the primary area of focus with this development effort.

12. Determine potential positive and negative interactions between product requirements or technical characteristics using symbols for strong or medium, positive or negative relationships. Too many positive interactions suggest potential redundancy in product requirements or technical characteristics. Focus on negative interactions - consider product concepts or technology to overcome this potential trade-offs or consider the trade-off in establishing target values.

13. Calculate importance ratings. Multiply the customer priority rating by the improvement factor, the sales point factor and the weighting factor associated with the relationship in each box of the matrix and add the resulting products in each column.

14. Identify a difficulty rating (1 to 5 point scale, five being very difficult and risky) for each product requirement or technical characteristic. Consider technology maturity, personnel technical qualifications, resource availability, technical risk, manufacturing capability, supply chain capability, and schedule. Develop a composite rating or breakdown into individual assessments by category.

15. Analyze the matrix and finalize the product plan. Determine required actions and areas of focus.

16. Finalize target values. Consider the product strategy objectives, importance of the various technical characteristics, the trade-offs that need to be made based on the interaction matrix, the technical difficulty ratings, and technology solutions and maturity.

17. Maintain the matrix as customer needs or conditions change.

Concept Development

1. Develop concept alternatives for the product. Consider not only the current approach and technology, but other alternative concept approaches and technology. Use brainstorming. Conduct literature, technology, and patent searches. Use product benchmarking to identify different product concepts. Develop derivative ideas. Perform sufficient definition and development of each concept to evaluate against the decision criteria determined in the next step.

2. Evaluate the concept alternatives using the Concept Selection Matrix. List product requirements or technical characteristics from the Product Planning Matrix down the left side of the Concept Selection Matrix. Also add other requirements or decision criteria such as key unstated but expected customer needs or requirements, manufacturability requirements, environmental requirements, standards and regulatory requirements, maintainability / serviceability requirements, support requirements, testability requirements, test schedule and resources, technical risk, business risk, supply chain capability, development resources, development budget, and development schedule.

3. Carry forward the target values for the product requirements or technical characteristics from the Product Planning Matrix. Add target values as appropriate for the other evaluation criteria added in the previous step. Also bring forward the importance ratings and difficulty ratings associated with each product requirement or technical characteristic from the Product Planning Matrix. Normalize the importance rating by dividing the largest value by a factor that will yield "5" and post this value to the "Priority" column. Review these priorities and consider any changes appropriate since these are the weighting factors for the decision criteria. Determine the priorities for the additional evaluation criteria added in the prior step. List concepts across the top of the matrix.

4. Perform engineering analysis and trade studies. Rate each concept alternative against the criteria using a "1" to "5" scale with "5" being the highest rating for satisfying the criteria.

5. For each rating, multiply the rating by the "Priority" value in that row. Summarize these values in each column in the bottom row. The preferred concept alternative(s) will be the one(s) with the highest total.

6. For the preferred concept alternative(s), work to improve the concept by synthesizing a new concept that overcomes its weaknesses. Focus attention on the criteria with the lowest ratings for that concept ("1's" and "2's"). What changes can be made to the design or formulation of the preferred concept(s) to improve these low ratings with the product concept? Compare the preferred concept(s) to the other concepts that have higher ratings for that particular requirement. Are there ways to modify the preferred concept to incorporate the advantage of another concept?

Subsystem/Subassembly/Part Deployment Matrix

1. Using the selected concept as a basis, develop a design layout, block diagram and/or a preliminary parts list. Determine critical subsystems, subassemblies or parts. Consider impact of subsystems, subassemblies or parts on product performance or with respect to development goals. What parts, assemblies or subsystems present major challenges or are critical to the success and operation of the product? What critical characteristics have a major effect on performance? Consider performing failure mode and effects analysis (FMEA); failure mode, effects and criticality analysis (FMECA); or fault tree analysis (FTA) to help pinpoint critical items and their critical characteristics from a reliability/quality perspective.

2. If there will be multiple Subsystem/Subassembly/Part Deployment Matrices prepared, deploy the technical characteristics and their target values to the appropriate matrices. Carry forward the important or critical product requirements or technical characteristics from Product Planning Matrix (based on importance ratings and team decision) to the Subsystem/Subassembly/Part Deployment Matrix. These "product needs" become the "what's" for this next level matrix. Where appropriate, allocate target values (e.g., target manufacturing cost, mean-time between failures, etc.) to the Subsystem / Subassembly / Part Deployment Matrices. Organize these product requirements or technical characteristics by assembly(ies) or part(s) to be addressed on a particular deployment matrix. Include any additional customer needs or requirements to address more detailed customer needs or general requirements. Normalize the Importance Ratings from the Product Planning Matrix and bring them forward as the Priority ratings. Review these priority ratings and make appropriate changes for the subsystems, subassemblies or parts being addressed. Determine the the Priority for any needs that were added.

3. Considering product requirements or technical characteristics, identify the critical part, subassembly or subsystem characteristics. State the characteristics in a measurable way. For higher-level subsystems or subassemblies, state the characteristics in a global manner to avoid constraining concept selection at this next level.

4. Develop relationships between product needs (product-level technical characteristics) and the subsystem / subassembly / part technical characteristics. Use 5-3-1 relationship weights for strong, medium and weak relationships. Be sparing with the strong relationships.

5. Develop preliminary target values for subsystem / subassembly / part characteristics.

6. Determine potential positive and negative interactions between the technical part characteristics using symbols for strong or medium, positive or negative relationships. Too many positive interactions suggest potential redundancy in critical part characteristics. Focus on negative interactions - consider different subsystem / subassembly / part concepts, different technologies, tooling concepts, material technology, and process technology to overcome the potential trade-off or consider the trade-off in establishing target values.

7. Calculate importance ratings. Assign a weighting factor to the relationships (5-3-1). Multiply the customer importance rating by the improvement factor (if any), the sales point factor (if any) and the relationship factor in each cell of the relationship matrix and add the resulting products in each column.

8. Identify a difficulty rating (1 to 5 point scale, five being very difficult and risky) for each subsystem / subassembly / part requirement or technical characteristic. Consider technology maturity, personnel technical qualifications, business risk, manufacturing capability, supplier capability, and schedule. Develop a composite rating or breakdown into individual assessments by category. Determine if overall risk is acceptable and if individual risks based on target or specification values are acceptable. Adjust target or specification values accordingly.

9. Analyze the matrix and finalize the subsystem/subassembly/part deployment matrix. Determine required actions and areas of focus.

10. Finalize target values. Consider interactions, importance ratings and difficulty ratings.

Failure Modes and Effects Analysis (FMEA)

Control Phase

Define and Validate Monitoring and Control System Develop Standards and Procedures Implement Statistical Process Control Determine Process Capability Develop Transfer Plan, Handoff to Process Owner Verify Benefits, Cost Savings/Avoidance, Profit Growth Close Project, Finalize Documentation Communicate to Business, Celebrate

Tools Used

Process Sigma Calculation Control Charts (Variable and Attribute) Cost Savings Calculations

DFSS

DFSS is the acronym for Design For Six Sigma. Unlike the DMAIC methodology, the phases or steps of DFSS are not universally recognized or defined -- almost every company or training organization will define DFSS differently. Many times a company will implement DFSS to suit their business, industry and culture; other times they will implement the version of DFSS used by the consulting company assisting in the deployment. Because of this, DFSS is more of an approach than a defined methodology.

DFSS is used to design or re-design a product or service from the ground up. The expected process Sigma level for a DFSS product or service is at least 4.5 (no more than approximately 1 defect per thousand opportunities), but can be 6 Sigma or higher depending the product. Producing such a low defect level from product or service launch means that customer expectations and needs (CTQs) must be completely understood before a design can be completed and implemented.

One popular Design for Six Sigma methodology is called DMADV, and retains the same number of letters, number of phases, and general feel as the DMAIC acronym. It rolls off the tongue (duh-mad-vee) in the same fashion as DMAIC (duh-may-ick). The five phases of DMADV are defined as: Define, Measure, Analyze, Design and Verify.Define the project goals and customer (internal and external) requirements.Measure and determine customer needs and specifications; benchmark competitors and industry.Analyze the process options to meet the customer needs.Design (detailed) the process to meet the customer needs.Verify the design performance and ability to meet customer needs.

A slight modification on the DMADV methodology is DMADOV (see Discussion Forum sidebar): Define, Measure, Analyze, Design, Optimize and Verify.

There are a few other "flavors" of DFSS that you might be interested to know about: DCCDI, IDOV and DMEDI.

DCCDI is being popularized by Geoff Tennant and is defined as Define, Customer Concept, Design and Implement. You can see that there are many similarities between these phases and the DMADV phases.Define the project goals.Customer analysis is completed.Concept ideas are developed, reviewed and selected.Design is performed to meet the customer and business specifications.Implementation is completed to develop and commercialize the product/service.

IDOV is a well known design methodology, especially in the manufacturing world. The IDOV acronym is defined as Identify, Design, Optimize and Validate.Identify the customer and specifications (CTQs).Design translates the customer CTQs into functional requirements and into solution alternatives. A selection process whittles down the list of solutions to the "best" solution.Optimize uses advanced statistical tools and modeling to predict and optimize the design and performance.Validate makes sure that the design you've developed will meet the customer CTQs.

DMEDI is being taught by PricewaterhouseCoopers and stands for Define, Measure, Explore, Develop and Implement. I'm sure you won't have much trouble identifying the main objectives in each of these phases based on the title of each phase.

As you can see, the DFSS approach can utilize any of the many possible methodologies. The fact is that all of these DFSS methodologies use the same advanced design tools (Quality Function Deployment, Failure Modes and Effects Analysis, benchmarking, Design of Experiments, simulation, statistical optimization, error proofing, Robust Design, etc.). Each methodology primarily differs in the name of each phase and the number of phases (and, of course, the acronym).

How do you decide which DFSS methodology to use? If you're hiring a consulting company to help with your deployment, use their methodology as their training materials will be tailored around it. If you are implementing DFSS on your own, any of the DFSS books available should get you moving in the right direction. In any case, following a detailed DFSS methodology will help you achieve high quality levels for new products and services. If you are interested in improving your existing products or services, DMAIC is a more appropriate methodology to use.

Design for Six Sigma Roadmap

This article guides product developers on a standardized Design for Six Sigma (DFSS) roadmap for the development of products from the stage of specified customer requirements or technical specifications derived from a QFD. This roadmap displays the sequential use of tools for the development of robust products.

Two Types of QualityType 1: Customer Quality - The features that customers want.Type 2: Engineered Quality - The problems customers do not want.

Customer quality leads to the size of the market segment. It includes items such as function, features, colors and designs. The better the customer quality, the bigger the market size becomes. In order to obtain the market size, the price must be reasonable. Customer quality is addressed primarily though customer surveys and series of QFDs.

On the other hand, engineered quality includes defects, failures, noise, vibration, unwanted phenomena, lowering the cost of manufacture, and minimizing manufacturing problems.

Robust ProductsEvery engineer's dream is to design a product or process that exhibits the state of 'robustness.' However, few can actually make the claim that they know exactly what robustness means. The most appropriate definition of robustness, as described by quality guru Dr. Taguchi, is the state where the technology, product, or process performance is minimally sensitive to factors causing variability (either in the manufacturing or user environment), and aging at the lowest manufacturing cost.

Project TeamThe entire product development process should be undertaken by a project team that includes marketing, manufacturing, design, quality assurance and vendor development.

Flow Charts ProvidedThe flow charts on the following pages explain the method of developing robust products in the shortest time. The flow charts refer to various other check sheets as annexes, which can be used during the development. Additional check sheets can be developed depending on the type of products you are developing. It should be noted that the provided check sheets are not exhaustive in nature.

Design Of ExperimentsThe DOE techniques mentioned in the flow charts can be of Full Factorial, Fractional Factorial, Placket and Burman, Response Surface Methodology, Mixture, Static Taguchi Design or Dynamic Taguchi Design depending on situation.