You are on page 1of 422

SIX SIGMA FAST TRACK COURSE MAY 2008

Six Sigma Explained


Six Sigma is the popular name of a management system that uses data and systematic approaches to continually improve the quality of business processes and consistently achieve performance excellence. Simply stated, Six Sigma is a way for you to do things better, faster, and for less cost. The term "Six Sigma" was originally coined by General Electric and literally refers to a statistical condition is which a process achieves a failure rate of less than 6 standard deviations (the symbol for standard deviation is the Greek litter sigma), or 3.4 parts per million. In this regard, achieving Six Sigma performance ideally means reducing undesirable issues to a rate of less than 3.4 per million transactions. In reality however, few business processes require true six sigma error levels and the term "Six Sigma" has adopted a more general definition of "continually working toward making business processes as efficient as possible." Although Six Sigma is a relatively modern term, it borrows heavily from earlier management philosophies such as Business Process Management, Total Quality Management, and others. If you have any experience with these techniques, you will probably find much of Six Sigma familiar.

The Five Major Areas Of Six Sigma


When Six Sigma is taught, it is generally broken down into five groups of related topics. Since we are moving quickly, rather than covering each of the five areas in depth we will instead provide a brief overview of each area and spend one page highlighting their purpose and components. Let's begin by introducing each topic area:

Analytical Tools
Analytical tools are a collection of charts and graphs that help people understand and communicate data. Some of these charts will be familiar to you while others, such as a control chart, will probably be new. These tools are used when data must be organized, displayed, or communicated to others in the Six Sigma process.

Decision-Making Tools
Decision-making tools are a collection of tools and techniques that help people make logical, fact-based decisions based on data. These tools are used to prioritize options and make the mathematically "best" decision based on the data available to the team. By making the best decisions, a team has the highest possible probability of success.

Process Management
Process management is a step-by-step procedure that helps organizations understand what they do, find better ways to do it, and ensure that improvements remain effective. This technique is frequently used organization-wide to get a handle on what needs to be improved and to ensure that improvement efforts are, and remain, effective.

DMAIC Problem Solving Process


DMAIC is a formal problem solving methodology for correcting an undesirable process outcome performance and ensuring that corrective measures maintain acceptable performance. When an organization encounters a problem, or when a business process is not meeting its performance targets, the DMAIC process can be utilized to systematically reduce or eliminate the problem.

Leadership / Strategic Planning


General leadership and strategic planning topics are often discussed as part of traditional Six Sigma training. These include areas such as team dynamics, managing improvement teams, and establishing clear linkages between Six Sigma efforts and organizational objectives.

How We Will Discuss Six Sigma In This Course


Now that you have a general idea of the topics provided in a Six Sigma course, we'll spend the remainder of this course two ways. First, we must quickly cover some simple concepts and terminology that are used in Six Sigma. You need to learn some of the basics or it will be difficult to understand DMAIC. Once that is finished we will dive right into practical Six Sigma by walking, step-by-step, through the DMAIC problem solving process. DMAIC is a good tool for teaching Six Sigma. As you learn each step in the DMAIC process, you will see how many of the analytical and decision tools are applied, and you will view an example DMAIC "story" to see exactly what the outcome of the structured problem solving process looks like. Once you have a basic familiarity of the tools, techniques, and a "structured process," you will have the minimum skills you need to begin applying DMAIC, Process Management, or any other Six Sigma concept. Working through this process will also demystify Six Sigma and show you why it works so well. Now, before we jump into DMAIC, let's take a look at each of five Six Sigma topic areas along with an index of links to each of their specific tools, techniques, and concepts.

Key Point
ets FasTrack Summary 1 of 1:- -

What is the name of the management system that uses data and systematic approaches to continually improve the quality of business processes and consistently achieve performance excellence?Answer: Six Sigma

What Are The Analytical Tools?


Below you will find a very brief overview of the major concepts introduced in the full Electronic Training Solution (ets) Analytical Tools course. We will encounter many of these tools and techniques as they are applied throughout his course. You are encouraged to skim the list below and see if any of these concepts are unfamiliar to you. If so, please take a moment to click on the item and read a short description of it. Analytical Tools Are A Common Language For Data (Excerpted from the ets Analytical Tools course) Analytical Tools are a common language of charts and graphs that are used to communicate information throughout your organization. Each chart and graph conveys different information, but the purpose of each is to help you and others better understand data. During the course, you were introduced to some general concepts. Click on any of these topics to return to the appropriate page in the course:

The Need For Source Blocks Populations and Samples Attribute Data vs. Variables Data

You also learned the purpose, application, and construction methods for the following analytical tools. Click on any of these topics to return to the appropriate page in the course:

Checksheets or Electronic Spreadsheets A Checksheet is a tool used to collect data.

Bar Charts A Bar Chart is a "summary" graph used to compare the amount of an item with other items.

Line Graphs A Line Graph is a "trend" graph that displays process outputs or outcomes sequenced by time or by occurrence.

Pie Charts A Pie Chart is a "summary" graph that shows highlights data items' relationships to their whole data set.

Pareto Charts A Pareto Chart is a "summary" analysis tool that is used to rank data groups.

Cause and Effect Diagrams A Cause and Effect Diagram is an analytical tool used to determine qualitative relationships between a problem and the reasons or factors that are possibly causing it.

Scatter Diagrams The Scatter Diagram is an analytical tool that determines whether or not a relationship exists between two linked or paired data sets.

Histograms A Histogram is an analytical tool that displays how a group of data is distributed from lowest to highest.

Control Charts A Control Chart is a data analysis tool that helps you to monitor the stability of a process output.

What are Source Blocks?


Maintaining Accountability
Just as you sign your name to a report, you should let others know that you are the source of any analytical tool you create. Source blocks are small packages of information that are attached to analytical tools so that readers know when the data was generated, where the source data was taken from, and who they can contact if they have questions about the tool. Many times analytical tools, such as charts and graphs, are reused or included in presentations, marketing packages etc. Providing a source block ensures that even if your tool is taken out of context, a reader can clearly determine the timeliness of your data and contact the author if questions arise. By requiring clear documentation of authors and dates, source blocks help maintain accountability for analysis tools and encourage you to produce accurate work. They also prevent others from misinterpreting your data or using outdated information.

The Typical Source Block


Source block formatting is the same for all data analysis tools. You should know what information goes into a source block and the standard way they are constructed. Each source block looks like a small table and should contain, at a minimum, the following information: When: This is the date when the data was collected, not when the tool was created or revised. This value may be an exact date, a quarter, or even an event. If you are unsure about what to put here, ask yourself what information that a reader would require to find the exact information you used in creating your chart. Where: This is the physical source of the data. The "Where" entry should provide enough guidance so that any employee could locate the exact data used for this particular tool. Make sure to specify exact locations, such as file paths or document numbers, if they are available. Who: The "Who" entry lists all employees that created the tool. It is provided as a reference so that coworkers may identify the authors of the tool in case they have questions, corrections, or additions. Figures 1 and 2 show example source blocks. Note the level of detail provided in each section of the source block and the variation of the two styles. Locating data in a small company is dramatically different compared to a multinational conglomerate. Make sure you provide enough information for your organization.

Data Source Information When: First Quarter, 2003 YTD Where: Doc #11354-1 Human Resource Funding, P 19-27 Who: K. Abrahams x3386, C. Fenwick x1914
Figure 1: A Typical Source Block from a Large Organization

Data Source Information When: October 3, 2003 Where: Accountant Report (From J. Peterson) Who: Karen in Human Resources
Figure 2: A Typical Source Block from a Small Organization Source blocks should be attached to every data management tool you produce. In fact, it is a good practice to attach the source block prior to completing the tool to ensure your chart will be accurately represented if someone pulls your chart off the printer or your desk while you are at lunch. Source blocks may be placed in any convenient location on your tool, but generally they are kept in the lower right hand corner for consistency.

Sample vs. Population


What is the difference between a Sample and a Population?
You can collect information from ALL of the relevant things (every employee) or you can sample a smaller sub-group of relevant things and use their results to represent the entire group (20% of the employees). When you collect data from everything in your relevant data set, this is called a "population" of data. Populations are denoted by a capital "N." For example, if you have 450 employees and you asked each one of them which flavor of ice cream they prefer, you have conducted a population analysis where N = 450. Gathering population data is also called performing a "census" of your data. When you collect data from a representative portion of your entire relevant data set, this is called a "sample" of data. Samples are denoted by a lowercase "n." If you instead only asked 100 of your 450 employees which ice cream flavor they prefer, you would have conducted a sample analysis where n = 100. Gathering population data is also called performing a "sample" of your data.

What makes data "relevant?"


If you are performing a study of employee satisfaction in your organization, your population would include every single employee. This makes sense, since every employee has a relevant stake in the company's overall satisfaction. Consider, however, an employee satisfaction study of only your Human Resources department. In this case, only HR employees' data would be relevant. You may have 450 total employees, but if only 30 of them work in HR, then your population size for the relevant data set is only 30. When determining whether or not you are performing population or sample analysis, you must first decide who your relevant population is. In the first case, the entire organization is relevant. In the second case, only the HR employees are relevant.

Why should I discriminate between "n" and "N?"


Because in the case of a population analysis, "N," you have 100% of the relevant data. This means that, assuming no one made any mistakes in your data collection, you have almost complete certainty that your data accurately reflects your relevant population. When you perform a sample analysis, "n," the accuracy of your results is dependent on how representative the sample ("n") relevant characteristics are to the population ("N"). In other words, how well the sample resembles the population. Logically, if you only ask 5 people out of 5,000 you will have much less accurate data than if you ask 500 out of 5,000.

Types of Data
Attribute Data vs. Variables Data
Before we look at control charts in depth, it is important to establish an understanding of the difference between the two types of data that control charts display. This is important because the two major categories of control charts only work with their appropriate type of data. Make sure you completely understand this section before proceeding. Attribute Data Attribute data is any form of data that can be counted as individual events or items. Attribute data points will always be a whole number or count of some type of data that can only exist in two states. A good way to remember this is to think of a light switch. A switch is either on or off, it is never partially on or partially off. If you checked a light switch at noon every day for a month, you could count how many times the switch was on. This would be a set of attribute data. Some examples of attribute data sets are shown below.

Number of repeat offenders (Did they repeat? If so, then count them.) Quantity of defective units (Were the units acceptable? If not, then count them.) Project days on time (Is the project on time today? If not, then count it.) Sick children (Is the child sick? If so, count him/her.) Employee performance issues (Is there an issue? If so, record an issue event.)

Variables Data Variables data is any form of data that is measured in more than two states. In other words, anytime your data value can be represented in more than a "count it or don't count it" fashion, you are dealing with variables data. Consider the following examples of variables data. The examples provided are similar to the attribute data examples above, but these have been modified to clearly illustrate the difference in the two types of data.

Severity of repeat offense: 1 to 10. (How bad was it?) Total cost of defective unit replacement. (What is the dollar amount?) How far behind is the project? (How many days is it behind?) How high is the child's temperature? (What is the thermometer measurement?) How urgent is the issue: 1 to 5. (How urgent is it?)

Other more typical variable data sets include:


Time (days, months, weeks, hours, etc.) Cost (dollars, cents, etc.)

Height, weight, length, etc. Pressure ... or any measurement value!

Key Point
ets FasTrack Summary 1 of 8: A collection of charts and graphs that help people understand and communicate data are called? Answer: Analytical Tools

Checksheets
What is a Checksheet?
A checksheet is a form used to collect data. A good checksheet is easy to understand and helps by structuring collected data into groups. Although data can be counted in many ways, checksheets specifically show all of the categories that you are counting in addition to how many "checks" each category received. For example, consider a team that is asked to increase daily application processing speed. They decide to begin their task by analyzing how many applications are processed each day. Some people would suggest Monday is the most productive day, since the staff is rested and ready to come back to work. This seems logical, but on the other hand, some workers may have spent the weekend traveling and arrived at work tired and unproductive. The actual answer cannot be determined by speculation alone. In this instance, a checksheet could be used to record applications processed on each day. By tallying the results, the team would get a fact-based view of daily productivity. See Figure 1 below.

Figure 1: An Example Checksheet Each vertical line in the checksheet represents one application. A diagonal line is used to signify a count of five. This notation is used since most checksheets are completed by hand, and groups of five are easy to count. In today's work, checksheets are often created using electronic spreadsheets (i.e. Microsoft Excel).

Key Point
ets FasTrack Summary 2 of 8: The tool used to collect data is called Answer: Check Sheet

Bar Charts
What is a Bar Chart?
A bar chart is a "summary" graph used to compare the amount of an item with other items from the same group. You have undoubtedly encountered these charts throughout your life. They are used to show comparisons between values. By visually representing data with bars it is easier to recognize small differences in quantities. Data items from the same sample group are listed along the X axis and their respective values are represented by a bar's height on the Y-axis. The numbers on the Y-axis are called the scale. The scale should contain the complete range of values that are represented. See Figure 1 for an example.

Figure 1: A Bar Chart Figure 1 shows a bar chart depicting customer complaints for a given week. Each axis is clearly marked, the chart is titled, and a good indicator shows which direction indicates improvement in the data set-- lower complaints is, of course, better. Notice that each data point value is printed over the X-axis bars. This is desirable information when reviewing a chart, but due to size limitations you may not always be able to include numerical values. Bar chart data can be grouped by color or pattern. When presenting multiple sets of data on a single chart, use different colored bars for each data set. There are many good graphing packages available for creating charts. All of the examples and templates provided in this course use the Microsoft Office XP suite of products.

Line Graphs
What is a Line Graph?
A line graph is a "trend" graph that displays outputs or outcomes sequenced by time (or by occurrence). Line graphs visually represent data so that change in the data set may be determined over a given range. The structure of this chart is similar to the bar chart, but here we use points plotted on the X-axis rather than bars. The X-axis indicates a division of time and usually places the oldest data on the left hand side. As in the bar chart, the Y-axis represents the value of each data point on the X-axis. Once the points are plotted, they are connected by straight lines. Figure 1 shows an example of a typical line graph.

Figure 1: A Line Graph A line graph is an excellent tool for highlighting trends and can be used to track more than one set of data at a time. If you have multiple sets of data to display, use different color lines and symbols for each set. Note: A line graph is also referred to as a "run chart".

Pie Charts
What is a Pie Chart?
A pie chart is a "summary' graph that shows or highlights data items' relationships to their whole data group. They key word to remember when thinking about pie charts is "composition." Pie charts take a value or data set and show you the sub-values that compose the overall value. For example, consider your monthly expenses. You have a typical monthly cost that represents the total of every bill you must pay. This total monthly cost is composed of smaller total costs: the power bill, the mortgage, the credit card payment. A pie chart could be used in this case to not only display your total monthly cost, but also give readers an understanding of the expenses that compose your total cost, and their relative size to the overall total. Figure 1 shows an example of a typical pie chart.

Figure 1: A Pie Chart Notice that the chart above shows a total value, $2 Million, and all of the smaller values that compose the large total. Each colored section represents an amount of the total value. The larger colored sections are of larger value, while the smaller colored sections compose less of the total. Typically, the largest "slice" of the chart will begin at 12:00 and the remaining slices will work their way around the graph clockwise. As you might have figured out, pie charts receive their name from their resemblance to slices of pie.

Pareto Charts
What Is A Pareto Chart?
A Pareto Chart is a "summary" Analysis Tool that is used to rank data groups. These charts are a combination of a bar chart and a line graph, in which the bar chart shows the quantity of your data and the line graph shows the cumulative percentage. This may sound complicated at first, but it actually makes a lot of sense when you see it applied. Consider the example shown in Figure 1 below.

Figure 1: A Pareto Chart Each bar on the Pareto Chart represents a quantity. For example, here we see that 65 "Wrong Size" defects are shown by the blue bar. The left Y-axis labeled "Number Of Defects" is used to measure the bars. The line on the pareto chart represents the cumulative total percentage of each bar. For example, the first point on the line graph occurs in the upper right hand corner of the blue bar. This point corresponds to the right Y-axis labeled "Cumulative Percentage" and is about 57%. This means that the 65 "Wrong Size" defects comprise 57% of the total number of defects. Look at Figure 2 and confirm that the first two problems, "Wrong Size" and "Wrong Color," comprise over 75% of all defects.

Figure 2: Determining Cumulative Percentage Of Bars Notice that each bar has a corresponding point on the line graph located directly above it. To be technically correct, this line graph point should be above the right-most edge of the bar, however, many graphing programs place this point directly above the bar. In practice, Pareto Charts should be ordered from largest bar to smallest, but they are not required to be drawn this way. In some cases, the last bar is labeled "other" and is used as a "catch-all" for data that occurs significantly less than in the other bars.

Cause And Effect Diagrams


What Is A Cause And Effect Diagram?
A Cause and Effect Diagram is an analytical tool used to determine qualitive relationships between a problem and the reasons that are possibly causing it. These diagrams help to find the most likely causes of problems or situations. We will refer to all of these contributing issues as causes and the problem itself as the effect. Look at the example cause and effect diagram in Figure 1 below.

Figure 1: A Cause And Effect Diagram The large blue box on the right-hand side of the diagram is the "effect box." The effect box lists the overall problem that is to be broken down into potential causes. In this case, the problem is "Customer orders are arriving late." The four smaller blue boxes located on the top and the bottom of the chart are "group boxes." Group boxes represent logical groups of potential causes: people issues, method or process issues, equipment \ materials issues and environmental issues. Whenever a potential cause is added to the chart, the cause is attached to its appropriate group. The lines with arrows and text that attach below the group boxes are "potential causes." Each potential cause is repeatedly broken down into its another cause until they cannot be broken down further. For example, look at the methods group box. Below it is a series of potential causes. See Figure 2 below (which is a sub-set of figure one).

Figure 2: A Group Box And Potential Causes Figure 2 is interpreted like this:

Having the "Wrong Address" is a potential METHODS cause of the effect "Customer orders are arriving late." The "Address Not Being Verified" is a potential cause of having the "Wrong Address." "The Customer Is Not Asked For Their Address" is a potential cause of the "Address Not Being Verified." The "Customer Is Not Asked For Their Address" is a potential "root cause" of the effect "Customer orders are arriving late."

As you can see, the Cause and Effect Diagram links potential causes to an effect and then attempts to determine the lowest level cause- the "root cause" of the effect. Cause and Effect Diagrams will always have only one effect, but their number of group boxes, potential causes, and even potential root causes may vary as needed. The key concept to remember about Cause and Effect Diagrams is that they explain a logical thought process in which a reader attempts to determine the lowest level root causes of an effect. These charts serve as a history to this process and a structured aid to those performing the cause and effect analysis.

Scatter Diagrams
What Is A Scatter Diagram?
The Scatter Diagram is an Analytical Tool that determines whether or not a relationship exists between two (2) linked (or paired) data sets. If a relationship is found, scatter diagrams also provide information about the type of relationship that these sets share. Figure 1 shows a typical Scatter Diagram.

Figure 1: A Scatter Diagram Scatter Diagrams contain two sets of data. The two sets shown in the example above are "Speed Of Impact" and "Automobile Repair Cost." Notice that one set of data is listed along the X-axis and the other is listed on the Y-axis. The information that is plotted along the X-axis is called the independent variable. This variable represents the "input" condition into the situation that we are testing for a relationship. The information that is plotted on the Y-axis is called the dependent variable. This variable is the "output" that results from the dependent variable. Each red dot represents an ordered pair of an X-value and a Y-value. These ordered pairs come from an insurance report in which the speed of a vehicle and the repair cost were recorded. For example, if you look directly over the 22 mph "Speed Of Impact" tick mark, you will notice a red dot near the "3" mark on the Y-axis. This means that for 22 mph speeds, at least one Automobile Repair Cost was $3,000. Figure 2 shows how the dots establish a relationship between the two sets of data.

Figure 2: Reading The Scatter Diagram Remember that Scatter Diagrams are tests to determine and communicate relationships, if they exist. In Figure 1 above, the creator of the diagram is testing a theory that a relationship exists between the speed of a car's impact and the subsequent cost to repair that vehicle. Does this seem logical to you?

Histograms
What Is A Histogram?
A Histogram is an Analytical Tool that displays how a group of data (e.g. 30 student test scores) is distributed from lowest to highest. The term frequency distribution is a technical term that means "how the values of this data set are dispersed between a minimum and maximum value." In other words, histograms provide readers with a unique view of a data set's values and how frequently each value appears in the set. Histograms provide lots of information about data, much more than any analytical tool discussed so far. Histograms are also more complex than the previous tools, but once you understand the need for histograms, their structure becomes logical and fairly easy to follow. Take a moment to look at the Histogram shown in Figure 1. Try to familiarize yourself with the format of the chart, but don't worry about actually understanding it yet-- the best way to understand a histogram is to see an example of why they are important. You will see such an example in the next section.

Figure 1: A Histogram

Histograms are actually a special type of bar chart. The X-axis breaks your data set into categories called "bins." The Y-axis, much like other charts, shows the value of each bar's height. Unlike other charts you have seen, the X-axis labels here are boundaries. The first bin on the left begins at .7 and ends at a value of 2.7. The height of each bar tells the reader how many values in a data set are within a certain range. For example, according to Figure 1, there are 19 values in the data set between a value of 4.7 and a value of 6.7. Finally, note that the bars in the Histogram form a sort of "pyramid" or "bell" curve shape. Much like the scatter diagram, the shape of your plotted data also provides information for these charts. Now that you have a basic familiarity of what a histogram looks like, the next section will explain why histograms are so valuable and how to read them.

Control Charts
What Is A Control Chart?
A Control Chart is a data Analysis Tool that helps you to monitor the stability of a process output. Whenever you are tracking information that produces continuing data and you seek stability for your process, a Control Chart provides you with an effective method of determining where to investigate process outputs for special causes that can affect process stability. Much like a Histogram, a Control Chart provides a different view of data that can reveal hidden aspects of the data set. In this case, a Control Chart is a specialized form of a line graph that provides extensive information about how consistent the data is around an average output. The Control Chart is used only to monitor the "stability" of a process and should never be used to determine whether or not process outputs are "good" or "bad". Control Charts are used often in manufacturing where many sub-processes are needed to produce a product such as a car, television set, lamp, etc. Control Charts are used by frontline supervisors and staff to monitor the consistency of their outputs. Since their outputs are critical inputs for the next sub-process, they need to know on-going (and real-time) whether or not their process remains stable and in control. Consistent outputs (around an average value) are critical to ensure the success of an individual process. Control Charts simply tell you whether or not your process is "in control and, more importantly, they tell you when to take action on a process output a process output that signals a new special cause has entered your process. By utilizing Control Charts you could better monitor outputs of your process and be able to differentiate between outputs that are a result of normal (built in) random variation in your process and the outputs that are a result of an abnormal factor (or special cause) that you need to investigate. Consider this example:

Figure 1: A Control Chart For Home Temperature Figure 1 shows a control chart that measures the output of a Service Planning process. The 13th and 22nd outputs were outside the Upper Control Limit (UCL) and each point should cause the supervisor to investigate circumstances that caused that output. Those circumstances most probably involved abnormal factors that need to be addressed. Those abnormal factors (or special causes) were not designed into the process and need to be identified and remembered, if appropriate.

Key Point
ets FasTrack Summary 3 of 8: If you wanted to show summary data and compare one item with other items from the same group, what graph would you use? Answer:Bar Chart

Key Point
ets FasTrack Summary 4 of 8: If you wanted to show trend data and display process outputs or outcomes sequenced by time or by occurrence, what graph would you use? Answer: Line Graph

Key Point
ets FasTrack Summary 5 of 8:If you wanted to show summary data that shows data items' relationship to the whole data set,

what graph would you use? Answer: Pie Chart

Key Point
ets FasTrack Summary 6 of 8:If you wanted to summarize and rank data groups, what graph would you use? Answer: Pareto Chart

Key Point
ets FasTrack Summary 7 of 8:If you had to determine qualitative relationships between a problem and all the reasons that are possibly causing it, what analytical tool would be the best to use? Answer: Cause and Effect (Fish Bone) Diagram

Key Point
ets FasTrack Summary 8 of 8:If you wanted to display how a group of data is distributed from lowest to highest, what tool would you use? Answer: Histogram

Decision Making Tools Overview


What Are The Decision-Making Tools?
Below you will find a very brief overview of the major concepts introduced in the full ets Decision-Making Tools course. We will encounter many of these tools and techniques as they are applied throughout this course. You are encouraged to skim the list below and see if any of these concepts are unfamiliar to you. If so, please take a moment to click on the item and read a short description of it. Decision-Making Tools Produce Decisions Based On Consensus, Fact (Excerpted from the ets Decision Making Tools course) Decision-making tools are a series of techniques used to organize thoughts and determine outcomes. The consensus and data-based approach to the decision making tools shown in this course help teams stay focused on logical solutions and back outcomes that are most likely to succeed. Remember that these tools are all required skills in formal problem solving, DMAIC, six sigma and process management methods. In those courses, you will learn how to apply these tools in a logical sequence to achieve dramatic results. The following list provides a quick reference listing of each topic that you covered in the course, along with a reminder of their general application and role. Take a moment to ensure that you remember the general purpose of each tool, paying special attention to the bold-faced text.

The Problem Statement


What Is A Problem Statement?
A problem statement is the first step in many decision-making processes. A brief discussion on the problem statement is included so that you will have an understanding of the specialized connotation of "problem" often used in formalized decision making processes. A problem statement is a concise, specific statement of a problem that is to be solved particularly in the context of formal decision-making, process management, or improvement programs (six sigma). A good problem statement specifies precisely the problem to be addressed. It has been said, "a problem well stated, is a problem half solved." Clear definition of the problem help focus the team and move them in the right direction from the beginning. Taking time to correctly state the problem can also give a "second look" before moving on to the more time consuming processes of data collection and analysis. It is easy, especially when working on a project over many days, to drift from the original specific problem. Having a single clear statement greatly reduces this effect.

Action Plans
What Is An Action Plan?
An action plan is a technique that contains the "Who, What, When and How" of a course of action (countermeasure). In the context of management, action plans are often used for improvement or project tracking. When well constructed, an action plan serves as the overall blueprint of how your process resources are allocated, and how each member of your team will be involved in the process. Let's briefly look at how the Action Plan shows Who, What, When, and How, using Figure 1 for an example.

Figure 1: An Action Plan Figure 1 shows a typical Action Plan format. Since this course is designed to support improvement, the action plan presented here is for a process improvement countermeasure. For the sake of clarity, a "countermeasure" is an action taken to correct a problem in a process or behavior.

The root cause, practical method, and countermeasure lines all refer to information from a process improvement team. There is a logical relationship between these three fields. The root cause is the problem that the countermeasure is attempting to resolve. The practical method is the way in which the countermeasure will be implemented. Each practical method is usually composed of a series of tasks that must be completed, or continued, to ensure that the method succeeds. These tasks are the items highlighted on an action plan. The "Owners" line lists the people who are responsible for this particular Countermeasure and Method. These will typically be the people held accountable for this plan and its timely execution. In some cases, an "Owners" column may appear on the chart, listing a specific owner's name for each task. Below all of the previous information is where the actual tasks are listed. Each task is represented by a row with boxes used to denote the planned time (empty) and actual time (filled) for each task. Like the x-Axis of a chart, the bars pass through vertical columns that denote some segmentations of time: days, weeks, months, etc. Time progresses from left to right, such that boxes on the left denote a time prior to boxes farther to the right. For example look at the bar to the right of Task Two in Figure 1. The solid box represents completed work toward the task; the empty box represents scheduled work. By using the right and left edges of these boxes you can tell that Task Two, "Generate new questions," began in early February, is about 1/4 completed, and is scheduled to finish in late March. When an action plan is completed, it clearly shows all the information about an improvement process: its owners, its purpose, and its status. These plans serve as a record of team efforts and a standardized way to report progress and timeliness. These types of charts, which use boxes or lines to denote tasks, are also referred to as Gantt Charts.

Barriers and Aids Analysis


What is a Barriers and Aids Analysis?
Barriers and Aids Analysis is a technique that is used to identify elements that hinder (barriers) or help (aids) a proposed course of action (countermeasure). Barriers and Aids Analysis helps a team to decide whether or not a countermeasure would be an effective solution to a problem or opportunity, and to identify any potential problems before going too far with a project. In fact, this process is frequently done before starting an action plan to verify the feasibility of proposed countermeasures. In simple terms, Barriers and Aids Analysis is a structured method of determining the "Pros" and "Cons" of doing something. Figure 1 shows how Barriers and Aids Analysis breaks down the barriers and aids to your countermeasure and rates them on a standardized scale of importance. Remember that standardization and effective communication are important when providing information to decision makers!

Figure 1: A Barrier and Aids Analysis The general course of action is listed on the "countermeasure" line.

The specific course of action, or "Practical Method," line gives a description of how this countermeasure is specifically proposed to be implemented. Note that for every countermeasure, many practical methods may exist! The "Forces Pushing Against - Barriers" column lists all of the barriers that could hinder the implementation of the countermeasure. To the left of this column is the "Impact" column, where each barrier is rated as a High, Medium, or Low barrier to success. The "Forces Pushing For - Aids" column lists all of the aids that can be used to overcome, or balance, the barriers listed. It is not necessary, however, to have an aid for every barrier. The "Impact" column to the left of the "Aids" column rates the impact of each aid on the barrier it affects. When this analysis is completed, a team will have identified the most important barriers that could prevent them from succeeding in implementation of a countermeasure. If a barrier rated as High or Medium impact is not countered or balanced by an appropriate aid, a specific action plan may be needed, or the planned countermeasure may need to be reconsidered.

Brainstorming
What is Brainstorming?
Brainstorming is a structured session in which a group rapidly generates ideas. This is a technique that produces a large amount of ideas in a short amount of time. It is essentially a process in which a group of people follow a systematic procedure of generating creative ideas / solutions to a given problem. Although many people have used an unstructured form of this technique, there are guidelines that should be followed to increase its effectiveness.

The Need For Simple Systematic Processes- "A Tale Of Two Buildings"
While reading about many of the techniques presented in decision making literature, you may find yourself considering how seemingly "simple" some of these processes are. While many of these may seem intuitive, it is important to remember that they are the building blocks of more advanced procedures. Following a structured, standardized process in the "little things" can have a profound effect on larger outcomes. Consider the following example: Two groups of workers are asked to construct a small building using bricks. The first group, realizing that stacking one brick on top of another is a simple task, begin to build their wall. Each worker places the mortar between the brink and stacks another one on top. The second group recognizes the need for consistency, even in a simple task. They measure their mortar, establish a standard method of placing the bricks, and then begin to build. When both groups had finished, they both had completely different results! Group one's bricks were arranged differently on each wall, and one wall was three inches higher due to excess mortar. Group two's walls were of uniform shape and height. Remember this as you progress through your training: Complex processes are almost always composed of many simple processes. Small errors in simple processes add up and produce big problems. For this reason, make sure you master the language and procedure of even the simplest processes.

Consensus
What is Consensus?
Consensus, in the context of this course, is a group decision-making process that takes each member's ideas and opinions into account and results in a decision that everyone in the group can support. It is an effective method for decision making because it involves each member's participation and results in an outcome that every participant had a stake in determining. Consensus improves decision quality, equalizes power, causes examination of alternatives, increases commitment to implement the decision and promotes unity among the team members. The goals of consensus are to:

Eliminate a "we-they" feeling. Focus on the problem, not on personalities, position, or points of view. Reach a "win-win" decision. Develop team ownership of the decision.

Achieving consensus should be the goal of your team in any decision-making process. When consensus has been achieved, the concerns of each individual in the team have been addressed and every team member feels that he or she has participated in the decisionmaking and that the decision that has been made is one that everyone can support, if not 100% agree with.

Cost-Benefit Analysis
What is a Cost-Benefit Analysis?
Cost-benefit analysis is a numerical method of evaluating potential practical methods for implementation. Consider the following situation: An organization's cafeteria has a problem. Their donut sales have dropped for the third consecutive month, and donuts are a high profit item used to cover the operating costs of the small cafeteria. After performing a cause and effect analysis and a countermeasures matrix, the cafeteria staff determined that customers are dissatisfied with the freshness of the donuts (they are made days in advance). The staff unanimously agreed that their first countermeasure should be to create fresher donuts! After some brainstorming, the following practical methods were suggested:

Hire a full time baker to make donuts all day long. Modify the storage system to increase shelf life of the product. Modify the recipe to help prolong freshness.

Each of these suggestions would probably increase donut freshness, but which one should they choose? When identifying practical methods for implementation, organizations can use cost-benefit analysis to find the one that provides the most benefit with the least cost. By selecting the practical method with the highest cost / benefit ratio, a team is ensures the highest probability of success. Take a look at Figure 1 for an example of a cost-benefit analysis based on the previous example:

Figure 1: A Cost-Benefit Analysis? As you can see, the worksheet lists the practical method at the top and then provides columns underneath. The left hand column contains "Costs," with their approximate values. Likewise, the right hand column contains "Benefits" with values. These values are estimates and do not require exact numbers in most cases. The total cost and benefit is computed by adding up each individual value. A ratio of benefits to cost is then calculated, with larger ratio value being more cost effective choices than smaller ratio values.

Countermeasures Matrix
What is a Countermeasures Matrix?
A countermeasures matrix is a technique applied to select the most actionable solutions to a problem, and provide a clear communication of the solution determination process. In more simple terms, this technique is used to "weed out" less feasible solutions and help establish a short list of best possible solutions. The countermeasures matrix also establishes the relevance of a solution to the root cause of a problem and its practical solution methods. The countermeasures matrix consists of a table that lists each countermeasure and provides sections for ranking them according to a series of criteria. Figure 1 provides an example of a typical countermeasures matrix format.

Figure 1: A Countermeasures Matrix

The purpose of each column in Figure 1 is described below:


The "Problem Statement" column lists the problem you are attempting to solve. The "Root Causes" column lists the sources of the problem, which can be generated and verified using a cause and effect diagram. The "Countermeasures" column should lists potential solutions for each root cause. Each root cause should have at least one countermeasure listed. The "Practical Method" column specifies the exact method with which a countermeasure could be implemented. Each practical method is usually composed of a series of tasks that must be completed, or continued regularly to ensure that the method succeeds. The "Effectiveness" column represents the effect of each countermeasure on the root cause it is meant to solve. Each countermeasure must be rated from 1 to 5, with a rating of 1 showing no effect on the root cause and a rating of 5 showing an extreme effect on the root cause. This rating is determined by a group or team based on consensus opinion.

The "Feasibility" column measures how feasible it would be to implement a particular countermeasure. Ratings are again on a scale of 1 to 5, with 1 being an idea that is unfeasible and 5 an idea that is extremely feasible. This rating is determined by a group or team based on consensus opinion. The "Overall" column is the product of the "Effectiveness" and "Feasibility" scores for each countermeasure, and will result in a number between 1 and 25. The higher the score, the more likely the countermeasure is to succeed. The final column, "Take Action," is used to denote which countermeasures and practical methods that a team feels are worth pursuing further.

Multivoting?
What Is Multivoting?
Multivoting is a structured process of group voting that helps reduce a list containing a large number of items down to a manageable few using consensus. This technique can help large groups arrive at near consensus decisions quickly. It is also useful to reduce a "brainstormed" list of ideas or help a team arrange their list of potential improvement themes according to priorities. The actual process of multivoting occurs in three steps, during which the group performs a structured vote on an established list of options. By the end of the third phase, the list of options has been narrowed down to the options that the group feels are the best. In many ways, multivoting is a numerical method for obtaining consensus. Whereas in consensus each person provides an opinion on a topic, multivoting allows each person to support a choice (or choices) by casting a vote. The group outcome choices in multivoting are determined by the number of total votes. Figure 1 shows an example of the outcome from a multivoting process.

Figure 1: Multivoting Worksheet

Pairwise Ranking
What is Pairwise Ranking?
Pairwise Ranking is a structured decision making technique that ranks a small list of items (usually up to five) in a prioritized order. This technique also assists in achieving a consensus on the highest-ranking item. Figure 1 shows how pairwise ranking works. In the following example, a corporation must select a site for a future research and development facility. The company has locations across

the United States, and there are many factors to consider. To help make a decision, the team in charge of site selection has created the following matrix:

Figure 1: Pairwise Ranking Matrix In this matrix, each of the sites are compared to each of the other sites, one at a time. The value written in the matrix is the option, out of the two intersecting choices, that the team prefers. Note that this method forces a team to compare each pair of choices in a matrix, two at a time. In the first column of the matrix (below the blue box with a "1"), Site 1 "Headquarters" is compared with Sites 2, 3, 4, 5, and 6. Whichever site the team believed to be the best was then entered in the box. For instance, when comparing Site 2 with Site 5, the team decided that Site 5 was the best of the pair. Figure 2, shows how you could determine this:

Figure 2: Site 2 vs. Site 5: Site 5 Is Selected The yellow boxes show the intersection of Site 2 with Site 5. The green box, at the actual intersection point, contains the value of the preferred option "5." Logically, the intersection point of a pairwise ranking matrix will always contain either the value at the top of the column (2 in this case) or the site at the head of the row (5 in this case). When the matrix is completed, the team counts how many times each site appears in the matrix and lists them in order. The site that appears the most is the "best choice."

Poka Yoke Mistake Proofing


What is Poka Yoke Mistake Proofing?
Poka Yoke is a specialized type of decision-making process associated with mistake proofing. Although it is not a process to choose between a list of items, the poka yoke process is a systematic method for determining methods of improvement. This method is used in some formal problem solving processes and has been included in this course for completeness. Poke yoke refers to a process of identifying and implementing simple, inexpensive solutions to problems. Developed by a Japanese manufacturing engineer named Shigeo Shingo, this concept revolutionized manufacturing, first in Japan and later throughout the world. Also known as "fail safing," poka yoke (pronounced "poh-kah yoh-kay") is translated into English as to avoid (yokeru) inadvertent errors (poka).

The Need For "Mistake Proofing"


One of the most horrific cases of wrong-site surgery in the U.S. occurred in 1995 in Tampa, Florida, when diabetic patient Willie King had the wrong foot amputated by surgeons at University Community Hospital. Since that time, over 130 other cases have been reported to the Joint Commission on Accreditation of Health Care Organizations, the nation's top accrediting agency for hospitals. In 1998, and again in 2001, the Commission issued special alerts advising patients and doctors to insist that surgical sites be marked with a permanent marker and initialed by the attending physician. Despite these alerts, incidents continue to occur such as the November 2002 removal of a bone from the wrong foot of high school basketball player Keith Smith. Smith, 17, was in the University of Oklahoma Medical Center in order to have a bone growth removed from his left heel, when the bone was mistakenly removed from his right. In 2001 a surgeon at the Adirondack Medical Center in Saranac City, New York, operated on a patient's healthy knee. Unfortunately for the doctor, it had only been five years since he had operated on the wrong hip of a patient. The New York surgery department had started requiring that "YES" be printed on the limb or area to be operated on, but it is now also requiring that a red sock be pulled over the healthy limb of a patient to prevent any further errors. It's hard for most of us to imagine how such a terrible mistake could be made, but two major causes have been identified for wrong site surgery:

Poor communications between the patient and the doctor, and poor communications between the medical team itself. Lack of systems or processes that would include "check points" to prevent the possibility of human error, such as: marking surgical sites; using checklists for verification and assessment; and

involving multiple members of the surgical team to verify the correct patient, procedure and surgical site.

It's this last point that pertains to poka yoke directly, for that is exactly what poka yoke is: systems or processes that act as "checkpoints" to prevent the possibility of human error.

Process Flow Chart


What Is A Process Flow Chart?
A Process Flow Chart is a pictorial representation showing all the steps of a process and their sequence. It can be a useful technique for examining how various steps in a process are related to each other. By studying a flowchart you can often discover redundancies or loopholes that are potential sources of unnecessary work, costs or customer dissatisfaction. Flow charts are provide insight into business processes and often provide the foundation for organizational decisions. Figure 1 shows a properly constructed process flow chart.

Figure 1: Process Flow Chart These flow charts may be a little different than ones you may have encountered in the past. The boxes along the top of the flow chart indicate "who" is involved in a process. The boxes along the left hand side of the flow chart tell "what" each step of the process does. Finally, the symbols inside the chart itself and the arrows connecting them depict the flow of decisions and events within a process. Look at Figure 1 for a moment. All the symbols below the "Internal Customer" box indicate steps in this process that the internal customer is involved in. Likewise, you can look below the "John" box and see that he is responsible for "Fills Out Report, Sends To Supervisor." The table below summarizes the process information depicted in the chart:

1. 1. An Internal Customer Needs a Report (initial activity indicated by an ellipse and should be on top row) 2. John Fills Out Report and Sends To Supervisor (activities or steps indicated by a box) 3. Supervisor Reviews Report (activities or steps indicated by a box) 4. Supervisor Approves or Disapproves (Yes or No decision indicated by a diamond) 5. If Supervisor Approves, Supervisor Sends Report To Customer (activities or steps indicated by a box) 6. If Supervisor Disapproves, Report is Returned to John to be Filled Out again (arrow from decision diamond leading back to previous step) 7. Customer Receives Report (final activity or step indicated by an ellipse and is located on the last row) When reading a flow chart, begin with the top "oval" and follow the arrows through the process. Diamonds represent decisions that will direct you to one path or another, with the most desirable path always being down, and the less desirable path being to the side. As you will learn in the following sections, these specialized flow charts provide a tremendous amount of information on accountability, indicators, rework and hand-offs.

Project Planning Worksheet


What is a Project Planning Worksheet?
The Project Planning Worksheet is a summary document that tracks problem solving or decision-making efforts. This document provides teams and management an overview of the entire decision-making process, based on the principles of Deming's Plan-Do-Check-Act Cycle. The project planning sheet acts as a "road map" as you work to address the theme statement your organization has selected. Let's take a look at Figure 1 to see how a Project Planning Worksheet can assist you in long and short range planning:

Figure 1: A Project Planning Worksheet The project planning worksheet contains the following elements:

The name of your team and members' names. Meeting attendance record. Project schedule organized by the Plan-Do-Check-Act Cycle (a Gant chart similar to an action plan). Recognition of individuals who provide support to the team, but are not team members, such as subject matter experts or the team sponsor. Reference to the Theme and Problem Statements your project is addressing.

Radar (Spider) Chart


What is a Radar (Spider) Chart?
Radar charts are a specialized Analytical Tool often used to gauge improvement or show "difference" between two sets of data typically before and after. Radar charts provide a large amount of information in an easy to read format. Consider the radar chart shown in Figure 1 below.

Figure 1: A Sample Radar Chart Categories or sets are represented as radii on the circle, or "strands" of the "spider web." Each one of these lines, going from the center of the circle to the edge, are like an axis. The radii are divided with tick marks, with the tick marks beginning with their lowest value in the center of the circle, and increasing in value as they move outward. For example, "A" in Figure 1 has the highest value. Notice that each radius actually has two points plotted on it: the inner point, and the outer. The area between the inner and outer points is the blue shaded area shown above. As mentioned earlier, radar charts show comparison between two sets of data. The innermost point on a radius is the "before" value, and the outermost is the "after." The width of the gap between these two points denotes how much change occurred between the two values. By quickly glancing at a radar chart, the width of the shaded region quickly helps a reader identify areas of large change. Additionally, the shape of the shaded region denotes areas of high and low values.

Survey/Interview
What is a Survey/Interview?
A survey, or interview, is a well-designed method for collecting data that is not readily available in a numeric format. Putting an exact value on "customer satisfaction" isn't always easy. You don't have a meter to read or a print-out to analyze. Instead, organizations use surveys. These tools can take the form of face-to-face interviews, written questionnaires, e-mail, online web sites? or a combination of all of them. In the context of this course and many process improvement or problem solving processes, surveys are typically use to gather information from customers. Nonetheless, surveys can be used to gather many types of data required for decision making, including:

A sample of voters is polled by interviewers before an election to determine which candidates or issues they perceive as most relevant. A sample of customers is asked to rate their experience when purchasing a product through a company's website by answering an online questionnaire at the conclusion of their purchase. A company conducts a telephone survey of potential customers in a geographic area to determine a need for its services. Employees are asked to confidentially rate their satisfaction with their employer by filling out a questionnaire and mailing it to an outside firm for tabulation. The U.S. Bureau of the Census conducts a survey each month to obtain information on employment and unemployment in the nation.

Most organizations have already developed one or more customer satisfaction surveys. Often these surveys ask a variety of "important" questions, but fail to ask the "right" questions? the ones needed to actually improve customer satisfaction. Consequently, most survey instruments are inadequate because very little can be done with the results.

Best Practices In Survey Design Typical Surveys 1. Identify / validate customer needs 2. Measure customer satisfaction overall. Good Surveys 1. Identify / validate customer needs by customer segment 2. Measure customer satisfaction overall: by customer segment by valid requirement 3. Assist in stratifying the customer satisfaction data. by customer segment by pertinent what, where, when, who categories 4. Provide comments that tie directly to each question. 5. Assist in identifying root causes of problems. 6. Are brief and to the point.
Figure 1: Differences Between Typical Surveys And Good Surveys Figure 2 shows an example of a well-designed customer satisfaction survey instrument (form). We will discuss the methods for ensuring that your surveys are well designed later in this section. Take a moment to review the figure below, noting its structure and the type of information it asks for.

3. Assist in stratifying the customer satisfaction data.

4. Provide some general customer comments.

Figure 2: A Good Survey Instrument

Theme Selection Matrix


What Is A Theme Selection Matrix?
A Theme Selection Matrix is a decision making process that helps a group to determine the importance of one particular process, or "Theme," in an organization to demonstrate why it should be selected for attention. The word theme, in the context of process management and DMAIC/six-sigma, refers to the overall goal of a team. Example themes include topics such as "increase sales to priority customers, reduce operating overhead in publishing, minimize delays in form processing, etc." Theme selection matrices help teams determine the most important themes to pursue. As with many of the other decision-making tools highlighted in this course, theme selection matrices are integral tools for use in process management and the DMAIC process. Figure 1 shows a simplified theme selection matrix:

Figure 1: A Theme Selection Matrix As you can see, each theme is evaluated based on how greatly it will affect an organization's customers and on how high the perceived need to improve the theme is. Potential themes are given a score for "Impact on Customer" and "Need To Improve," using a scale from one to five. The two scores are then multiplied to determine an overall or score for each potential theme statement. The theme with the highest total score is the theme that is likely to have the greatest effect on customers the highest need to improve.

Key Points
Summary 1 of 4: A collection of tools and techniques that help people make logical, fact-based decisions based on data are called? Answer: Decision Making Tools Summary 2 of 4: When a group rapidly generates ideas in a structured session it is called? Answer: Brainstorming Summary 3 of 4: The process resulting from a group reaching a decision that they can all support, and it is based on taking into account each members ideas and opinions is called? Answer: Consensus

Summary 4 of 4: What kind of chart should be used to illustrate how things work, potential rework and accountability? Answer: Process Flow Chart

Process Management Overview


What Is Process Management?
Below you will find a very brief overview of Process Management, one of the two major, structured processes used in Six Sigma. Process management is a series of steps that are followed in which the Analytical / Decision making tools are used to understand and improve business processes throughout the organization. DMAIC is often used to support process management efforts, and process management itself has many similar features to the DMAIC process, although process management is more robust. You are encouraged to skim the list below and see if any of these concepts are unfamiliar to you. If so, please take a moment to click on the item and read a short description of it. A basic familiarity with process management may help you better understand the purpose of DMAIC projects, indicators, and linkages to organization objectives.

A Method For Understanding And Meeting Customer Needs


Process management is a step-by-step process that helps organizations understand what they do, find better ways to do it, and ensures that improvements remain effective. It is a management technique to systematically ensure that an organization monitors and improves performance in all areas critical to organizational objectives and customer valid requirements. Process management, in a nutshell, states the following everything that is done in an organization is a process: calling a client, creating software, processing an application, shipping an order, etc. These processes are all inter-related, and each to some degree should help bring an organization closer to achieving its mission and objectives. When these processes are understood, their links to customers and suppliers can be determined and then managed, and acceptable targets can be established. When targets are met, organizational goals will be met also. Process management includes the following concepts:

The Integrated Services Delivery System and Strategic Planning The ISDS can be thought of as the all-encompassing methodology that drives organizations to achieve performance excellence. Process management is an integral part of the ISDS.

The 7 Steps Of Process Management Process management is performed in using 7 major steps, and 25 checkpoints.

Step 1: Select Process Determine which process should be managed, based on priority, stakeholder impact, and improvement need.

Step 2: Construct Process Flowchart Map your process, review its efficiency, and assign accountability for on going process management.

Step 3: Identify Indicators Establish measures of success for your process that reflect customer requirements. Ensure that measures are documented and data is available. Assign indicator accountability and develop contingency plans.

Step 4: Implement Process Control Systems Launch the process control system in the organization and assess early effectiveness.

Step 5: Monitor Process Control Systems Review indicators for performance issues focusing on the stability of processes and the capability of processes.

Step 6: Improve Process Fix processes when they are not meeting targets.

Step 7: Standardize Process Document your process management project and maximize its value through replication and P-D-C-A.

The table below shows the seven steps of process management and corresponding checkpoints and provides a quick link to each process management step and checkpoint.

Step Select Process

Checkpoint 1. Key work processes were identified and prioritized according to stakeholder impact and need for improvement. 2. Top priority process was selected.

Construct Process Flowchart

3. Customers and participants were identified. 4. Current process flow was shown. 5. Process flow was reviewed for efficiency. 6. Process steps / time frames were identified. 7. Process champion was identified.

Identify Indicators

8. Process objective was stated. 9. Customer needs and requirements were identified and prioritized.

10. Method of obtaining data was established (survey, focus group, other customer information). 11. Quality and process indicators were assigned, and considered (Quality, Cost, Delivery, Timeliness, Safety, Security and Environment). 12. Process indicators were linked to quality indicators. 13. Standards, targets or limits were established. 14. Quality and process indicators were noted on flowchart. 15. Indicator owners were identified. 16. Contingency plans to ensure control were noted (if necessary). 17. Control system was reviewed with supervisor / manager. Implement Process Control System 18. Finalize the Process Control System.

Develop a procedure for managing the process control system. Develop checksheets to facilitate data collection and analysis. Train employees to: a) monitor; b) evaluate; c) improve; d) document learning; e) apply contingency. Commence data collection and monitor indicators. Review initial results and adjust data collection or process as needed.

Monitor Process Control System Improve Process Standardize Process

19. Process was evaluated for stability (e.g., six interpretation approaches). 20. Process was evaluated for capability (e.g., histograms).

21. Systematic improvement techniques were used (six-sigma DMAIC method). 22. An action plan was established to get back into control or improve the process. 23. Method was established to ensure process standards continuously reflect customer requirements. 24. Specific areas for replication were considered. 25. Applied P-D-C-A to lessons learned.

Step 1: Select Process

Overview
Step 1 of process management is where organizations identify key processes for management and select the highest priority process. The process selected in this step will be the one used for the remainder of this process management cycle.

Step Checkpoints Step Select Process Checkpoint 1. Key work processes were identified and prioritized according to stakeholder impact and need for improvement. 2. Top priority process was selected.

Step 1: Select Process - Checkpoint 1


How Do You Select A Process?
Process Management is a way of improving and controlling work so that it consistently meets customer and business needs. It can ultimately be used for all work processes, but should be applied initially to a key work process that is not performing at the desired level of consistency. In addition, limited organization resources usually require a process selection based on the greatest potential for customer impact and improvement. In order to complete "Step 1: Select Process," processes must first be identified and prioritized. After that, a priority process must be selected for use in the remaining six steps.

Identifying Processes
The first step in process management is to identify your processes so that a key process can be selected that will provide a high return on improvement efforts. If you don't already have a list of processes, you should make one. Remember, processes are ongoing, repetitive, linked activities converting inputs into outputs. Ask yourself or your team the following questions to help obtain a list of your work processes:

What activities services? What activities What activities What activities What activities What activities What activities

are involved in providing customer (internal and external) products and are described in your Job Descriptions? are described in Procedures Manuals? are involved in achieving organization Standards? are described on department checklists? are involved in processing organization forms? do you typically do daily, weekly, or monthly?

Naming Processes
Each process name, or description, should include an action verb and the output or product of the process. The following example is provided to help clarify the structure of process names: Example: A Shipping Coordinator is asked to define her work processes. From her job description, the shipping coordinator identified her key processes as follows. The verb and output have been colored green and red respectively to emphasize proper process name structure: 1.

a. b. c. d. e. f. g. h.

Complete Accounting Reports Generate Plant Production Schedule Manage Plant Inventory Fill Orders Ship Product in Rail Cars Ship Product in Trucks Schedule Rail Car Movements Supervise Clerical Staff

Step 1: Select Process - Checkpoint 2

2. Top priority process was selected.


How Do You Select A Priority Process?
Once a prioritization matrix has been completed, it is important to review the highest scoring processes from a more complete perspective. Prioritization matrices are designed to help you use available, known information and data in a systematic method to help surface the top priority processes requiring attention. To complete the selection process, however, consider a few remaining questions (or viewpoints) before seeking consensus from the team. Important questions to consider before final selection include: 1. What adverse consequences could result if we select this process? 2. Does the emerging priority process make sense to select from a customer, employee and investor point of view? 3. How much control does the team have in affecting changes in this process?

Step 2: Construct Process Flowchart

Overview
After selecting a process in Step 1, it is necessary to describe the process work activities by constructing a Process Flowchart. Step 2 of process management is where organizations illustrate the participants and activities of a process using a process flowchart. Once in proper flowchart form, the process can be optimized, time frames can be analyzed, and a champion established.

Step Checkpoints Step Construct Process Flowchart Checkpoint 3. Customers and participants were identified. 4. Current process flow was shown. 5. Process flow was reviewed for efficiency. 6. Process steps / time frames were identified. 7. Process champion was identified.

Step 2: Construct Process Flowchart - Checkpoint 3

3. Customers and participants were identified.


Who Are Your Customers?
A customer is anyone who is affected by our process, or uses the products or services resulting from our process. There are two (2) types of customers:

External customers are people external to the organization that pay for, use and/or are affected by the products or services associated with the core processes. Internal customers are individuals or departments within the organization that need products or services in order to support the core processes or other support processes.

In identifying internal customers often the expression "the next process is our customer" can be helpful. This expression reminds your team that your process outcome provides an input into another process. All processes and people that depend on your process are customers.

Figure 1: Customer Types Keep a list of the customers of your process. You will need this list in the following steps, while constructing a process flowchart.

Step 2: Construct Process Flowchart - Checkpoint 4

4. Current process flow was shown.


Process flow is shown by using a specialized type of flowchart. These flowcharts, and their general construction procedures, are covered in the ets course Decision-Making Tools. A short review is provided, but this course focuses on application rather than construction. If you are uncomfortable with these flowcharts, you are encouraged to review the ets Decision-Making Tools course.

What Is A Process Flowchart? (Review from Decision Making Tools)


A process flowchart is a pictorial representation showing all the steps of a process and their sequence. It can be a useful technique for examining how various steps in a process are related to each other. By studying a flowchart you can often discover redundancies or loopholes that are potential sources of unnecessary work, costs or customer dissatisfaction. Flowcharts provide insight into business processes and often provide the foundation for organizational decisions. Figure 1 shows a properly constructed process flowchart.

Figure 1: Process Flowchart These flowcharts may be a little different than ones you may have encountered in the past. The boxes along the top of the flowchart indicate "who" is involved in a process. The boxes

along the left hand side of the flowchart tell "what" each step of the process does. Finally, the symbols inside the chart itself and the arrows connecting them depict the flow of decisions and events within a process. Look at Figure 1 for a moment. All the symbols below the "Internal Customer" box indicate steps in this process that the internal customer is involved in. Likewise, you can look below the "John" box and see that he is responsible for "Fills Out Report, Sends To Supervisor." The table below summarizes the process information depicted in the chart: 1. 1. An Internal Customer Needs a Report (initial activity indicated by an ellipse) 2. John Fills Out Report and Sends To Supervisor (activities or steps indicated by a box) 3. Supervisor Reviews Report (activities or steps indicated by a box) 4. Supervisor Approves or Disapproves (Yes or No decision indicated by a diamond) 5. If Supervisor Approves, Supervisor Sends Report To Customer (activities or steps indicated by a box) 6. If Supervisor Disapproves, Report is Returned to John to be Filled Out again (arrow from decision diamond leading back to previous step) 7. Customer Receives Report (final activity or step indicated by an ellipse) When reading a flowchart, begin with the top "oval" and follow the arrows through the process. Diamonds represent decisions that will direct you to one path or another, with the most desirable path always being down, and the less desirable path being to the side. As you will learn in the following sections, these specialized flowcharts provide a tremendous amount of information on accountability, indicators, rework and hand-offs.

Step 2: Construct Process Flowchart - Checkpoint 5

5. Process flow was reviewed for efficiency.


Qualitative Analysis
One important up-front analysis activity involves utilizing the process flowchart after creation to identify potential process weaknesses and evaluate efficiency. Based on the special design of process flowcharts, inefficient patterns can be spotted easily.

Figure 1: Qualitative Analysis Is Reviewing Flowcharts For Potential Process Weaknesses There are several generic potential weaknesses one can look for when performing qualitative analysis using a properly constructed flow chart. One should visually inspect the flow chart for the following: Potential Process Weaknesses 1. 1. 2. 3. 4. Multiple reviews. Rework loops. (See Figure 1 for a good example of rework loops.) Idle time (wait time, dead time, etc.) Too many hand-offs between process players.

5. Too many players (or steps) involved. 6. Low value added steps (these might not be needed). 7. Duplicate steps. You should consider other potential weaknesses based on your team's knowledge of where in the process problems or delays can occur. Since properly constructed flowcharts promote a "downward" flow, one should also look for variations from the vertical flow of the process flowchart to identify additional weaknesses. Once the process weaknesses have been identified, countermeasures can be sought to mitigate or eliminate the process weaknesses.

Determining Low Value Added Steps


Reviewing each process step and determining the "value added" can help determine the kind of improvement countermeasures that may be most effective in redesigning the process. Methods for determining the "value added" vary. One approach is to interview process players for value using a subjective high, medium, and low criteria. Another approach is to quantify each process step's relative cost and benefits and add a corresponding point value (3, 2, 1) for cost and a point value (1, 2, 3) for each benefit. Each step can then be plotted on a matrix and a "value added score" can be calculated by multiplying the cost value by the benefit value.

Figure 2: A Value Added Matrix Once "value added" determinations have been made for each step, the above matrix can be used to help prioritize steps for redesign or suggest an improvement activity to increase low value steps. Quantitative, as opposed to Qualitative, Analysis using flow charts can also be a powerful stratification technique for solving process cycle time problems. Surprisingly, the use of flow charts for stratifications is widely unknown among most process experts. The technique is

powerful in that it stratifies a problem two (2) ways (i.e., by process step and process player) and at the same time. Quantitative analysis will be discussed later in this course.

Step 2: Construct Process Flowchart - Checkpoint 6

6. Process steps / time frames were identified.


Each step in a process has a certain amount of time associated with it. Certain steps, such as simple operations, are performed in a minimal amount of process time. Other steps, such as movements and inspections, typically consume a larger amount of process flow time. Documenting process step time frames is a useful technique for identifying the steps in your process that consume the most resources, and therefore, should be focused on for improvement.

Documenting Process Steps And Time Frames


By this point in process management, you should have already created a working flowchart for the process your mapping. This provides you with a complete list of process steps that can be transferred to the form shown in Figure 1 below. This form is used to identify process steps that consume large amounts of time, and identify processes with lots of hand-offs between operations, transfers, etc.

Figure 1: Process Step Time Frame Worksheet To complete the form, begin by filling out the pertinent information at the top. If this is the current method, check the "current method" box. If this is a revised process, check the "Proposed Method" box. Next, transfer each step your process flowchart into the Process Description / Steps boxes on the worksheet. Start with the first ellipse on your flowchart and enter its text into the top Process Description / Step box on this sheet. Work downward on both the flowchart and the worksheet. Process steps that occur on the same horizontal flowchart level may be entered as a single process, with a time value sum for both steps. Enter the time, in minutes, for this step of the process and place a "dot" on the appropriate symbol for what type of step it is. An explanation of each symbol and step type is provided in Figure 2 below.

Figure 2: Process Step Types And Symbols Beginning with the top "dot" draw a line that connects each dot to its adjacent "dots." When your team has completed their worksheet, it should appear similar to the one shown in Figure 3 below.

Figure 3: Completed Worksheet The line drawn on the "Chart Symbols" section of the worksheet depicts change in process steps. Ideally, you want this line to be as straight and to the left as possible. Left-most symbols represent the most efficient uses of process time. Also, excessive "jaggedness" in the line means that your process has a lot of hand-offs between process steps. Hand-offs introduce the opportunity for error into processes and also consume a significant amount of process time and delays. Your team should consider ways to straighten out the process flow so that less hand-offs occur and more process time is spent in left-most steps. Another helpful method of analysis is creating a histogram or Pareto chart that shows which steps consume most of the process time. When your team understands which steps are the most costly, efforts can be but in place to reduce process step times in these areas. Documenting this type of data also provides a solid benchmark for comparing improvement. To complete a histogram for process flow time, simply count the total number of minutes for each process step. Enter the total value for each bar in the histogram / Pareto. Figure 4 shows a histogram created in this manner.

Figure 4: Process Flow Time Histogram (From Figure 3) Notice that the vast majority of time here is spent on delays. Clearly the team should consider reducing process delays as a high priority for improvement in this instance.

Process Step Time Frame Worksheet Template


The worksheet used in this example is available as a template that may be printed out and used when your team is collecting data on your processes.

Step 2: Construct Process Flowchart - Checkpoint 7

7. Process champion was identified.


Process Champion/Owner Responsibility
Because processes are used by several people, it is important that one person be responsible for the process, and maintaining the Process Control System. Process Control Systems are the documents used to track and record all facets of a process and its status. These documents will be discussed in detail later. Process champions are responsible for ensuring:
o o o o

Charts are plotted for process related activities. Documentation is completed for process activities. Improvement action is taken and accountability is maintained. Training is completed, as needed.

Your team must establish a process owner, or "champion" as they are traditionally called. In many cases, the process owner is a supervisor. However, as you move further towards the goal of empowering your organization, ownership can be assigned or accepted by one of the process users. The process owner is empowered to make continuous process improvements to enhance the consistency and efficiency of their process. In order to ensure that each Process Control System is maintained, a process owner needs to be identified for each process.

Core Process Owner (Or Champion) Responsibilities


Since a core process in a large organization is performed similarly by many locations, often an executive manager is designated as process owner (or champion) for each of the organization's core processes. Each core process owner is responsible for coordinating improvement efforts with the organization's current Business Plan. The core process owner must play an active role in setting improvement targets while allocating sufficient resources needed to help reach those "stretch" goals. In order for processes to be effective drivers of an organization's overall Business Plan and objectives, a process owner (or champion) must be identified in top management levels for each core process. Process management must be deployed and practiced through all levels of an organization for full results to be achieved. ?

Step 3: Identify Indicators

Overview
Step 3 of process management is where process objectives are defined and effective measures are put into place that allow accountable persons to monitor process performance using effective indicators. Step 3 helps organizations determine how to properly judge the performance of a process, and put systems in place that enable performance to be monitored.

Step Checkpoints

Step Identify Indicators 8. Process objective was stated.

Checkpoint

9. Customer needs and requirements were identified and prioritized. 10. Method of obtaining data was established (survey, focus group, other customer information). 11. Quality and process indicators were assigned, and considered (Quality, Cost, Delivery, Timeliness, Safety, Security and Environment). 12. Process indicators were linked to quality indicators. 13. Standards, targets or limits were established. 14. Quality and process indicators were noted on flowchart.

15. Indicator owners were identified. 16. Contingency plans to ensure control were noted (if necessary). 17. Control system was reviewed with supervisor / manager.

Step 3: Identify Indicators - Checkpoint 8

8. Process objective was stated.


In "Step 3: Identify Indicators," process management focus shifts from mapping process structure to evaluating process outcomes. By this point in process management, a team has a clear view of the steps involved in a process. Although it is often easy to find qualitative ways to improve processes flow, it is not quite so easy to determine how much improvement is needed. Realistically, organizations work with finite resources. Most improvement projects are under funded, or added to an already heavy workload. Also, customers may place higher significance on certain processes (payroll, delivery time) and respond negatively to even the smallest performance shortcomings. For these reasons, and many more, understanding how much improvement is needed becomes a high priority.

Your mission, should you choose to accept it...


Checkpoint 8 helps process management teams "shift gears" from process mapping back into performance evaluation. Consider the process that was just mapped in Step 2. This process had a name that described an input and an objective: "Deliver Goods To Customers, Screen Employee Applications, Process Form 19s." Using the process name as a starting point, determine what the overall mission, or "objective" of your process is. In many cases, the objective of a process is a restatement of the process name with adjectives and adverbs added. For example, the object of the "Deliver Goods To Customers" process might be stated as "Deliver The Correct Goods To All Customers On-Time, Every Time." Another example: "Screen Employee Applications" may have an objective of "Screen Employee Applications In 3 Days Or Less, As Sorted By Priority." Try to establish a definitive objective of your process that tells what it does and how it should do it. Write the process objective down and keep it visible through the remainder of this step.

Step 3: Identify Indicators - Checkpoint 9

9. Customer needs and requirements were identified and prioritized.


The first step is determining how well a process works is to determine the needs and requirements that it fulfills for customers. As you have already learned, processes are work activities that meet customer needs. The purpose of this checkpoint is to help process management teams define the specific customer needs and requirements for a process. Once these needs are defined, teams can analyze the needs to determine how well they are, or aren't, meeting them. Up till now we have spoken of customer needs in general terms. The remainder of this step will help you understand specifically what your customer needs are.

Customer Valid Requirements (CVR)


The customer needs that a process must fulfill have a special name: customer valid requirements. These customer valid requirements are defined by process outcomes (e.g., products and services) described in terms of five fundamental quality elements: accuracy, timeliness, cost, safety, and the environment. For example, a process objective such as "Process Applications On Time" clearly indicates that a customer needs applications processed. The customer valid requirements for this process are created by defining the "Process Applications On Time" need in terms of accuracy, timeliness, cost, safety and the environment. Consider the following possible customer valid requirements (CVR's):

CVR1: Process applications within 5 working days. CVR2: Ensure 100% of all required fields are filled out on the application form. CVR3: Keep shipping costs for application less than $1.25 for each completed form.
To summarize, customer valid requirements are customer needs that are specified in terms of the five quality elements. Using your process objective, consider the outcome or product of a process. For each outcome, the following five quality elements have some degree that must be met for the outcome to be considered acceptable by a customer.

Quality Elements
1.

1. Accuracy (Quality or Fit) How accurate (or defect-free) should the process outcomes be? 2. Timeliness (or delivery) How quickly should the process outcomes be produced? What time and place should the process outcomes be delivered? 3. Cost What is the allowable cost for process outcomes in terms of dollars and/or resources? 4. Safety How safe should the process outcome be to meet standards or ensure safe usage? How safely should the outcome be produced and delivered? 5. Environment (corporate responsibility or ethics) How environmentally sound or ethical should be the process outcome? How environmentally sound or ethical should the outcome be produced and delivered? Even though all customer requirements can be derived from these five quality elements, accuracy and timeliness often specify the most urgent customer requirements not consistently being met by existing processes. Now that you understand what customer valid requirements are, you will learn how to convert general needs into these values. Securing customer input in the five quality element areas will produce customer valid requirements expected of the process.

Discuss Customer Needs With The Customer


A key step in the search for customer valid (or agreed upon) requirements is to meet with your customer. This meeting can take place with a focus group of external customers or a direct meeting with your internal (or external) customer(s). Through your meeting discussions, you should identify needs, evaluate these needs in terms of the five quality elements, and agree to consistently meet the important needs of your customers. The following guide can assist you in your meeting to establish these valid requirements. Take a moment to review Figure 1 and then read the explanation below the graphic.

Figure 1: Customer Needs Evaluation Worksheet Using the worksheet, meet with the customers of the process. Under each of the five quality elements, list any specific requirements that the customer has. For each item that is listed, complete the columns to the right of the item by interviewing the customer. Refer to the bottom of each column for instructions. Note that you may be required to gather data or a general estimate for the "Actual" column. Once you have completed the chart, select the appropriate CVR's to be measured based on their overall score. The number of CVR's that you selected should be limited on available time and resources.

Template
The guide in Figure 1 is available as a downloadable template that you may print and use as needed.

Step 3: Identify Indicators - Checkpoint 10

10. Method of obtaining data was established (survey, focus group, other customer information).
In checkpoint nine you established a set of customer valid requirements that should be measured for your process. For anything to be measured, a method of gathering data must be established. This checkpoint deals with the formal methods for gathering meaningful data.

Data Collection
Data collection is the process of collecting the right data for measurements in a useful and meaningful format. Like many aspects of improvement, a formal data collection method helps ensure consistency and communication among all of those involved. It also exposed team members to process interfaces and may provide clues as to how process problems can be resolved. The formal data collection procedure is performed in five steps: 1. 1. 2. 3. 4. 5. Define your data collection goals. Develop rules and procedures for the data collection. Validate your measurements. Collect data. Continually improve measurement accuracy.

Each step is discussed briefly below. Like many of the formalized process presented in ets courses, your organization may or may not require such a high level of structure. For example, you team may already have some of your CVR data readily available in a consistent format. In cases such as these, don't spend a lot of time on formal data collection. Remember that the goal of process management is to better serve process customers, not necessarily fill out every form in the course. Avoid "paralysis by analysis!" If a step seems trivial or an answer already exists, keep moving. Don't get bogged down.

Step 1: Define your data collection goals.


Simply stated, make sure that the data you propose to collect will satisfy your measurement requirements. If there are special measurement requirements, patterns, or grouping that is required for usable data, make certain that these issues are clear before progressing.

Step 2: Develop rules and procedures for the data collection.


How will the data be collected? What instruments will be used, and what units will these measurements be reported in? Will your data be a sample or a census?

All of these questions must be answered before progressing. You must ensure that the data you collect will be done so in a regular fashion, and a consistent format.

Step 3: Validate your measurements.


Make sure that your measurements remain consistent, don't assume it. Although there are many complex and mathematical methods for determining variation in measurements, most measurement validation can be done by a simple "common sense" check. For example, have two separate people measure your data and see if they get the same values. Check previous values against current ones using a line graph. If you notice any highly unusual trends or variation, you may need to perform further analytical analysis. They key point to remember about this step is: "make sure your measurements are good."

Step 4: Collect data.


Begin the logistical process of collecting data. Ensure that people are accountable for data collection and that they understand the frequency, format, and destination for any data they collect.

Step 5: Continually improve measurement accuracy.


Try to make data collection as accurate and painless as possible. CVR measurements are ongoing. This means that you will continue to collect your data indefinitely! For this reason, it is important that you keep the data collection process simple and efficient. Try and find ways to continually improve the accuracy and reduce the effort required to collect measurement data. Technology often provides innovative and cost effective solutions for producing low-cost, high quality data.

Data Collection Plan Worksheet


A worksheet has been provided to help your team construct a well thought-out data collection plan. Two versions of this worksheet are included in the template: a general format and a "Voice of the Customer" (VOC) format. The general format will work for all data collection plans, while the VOC format is designed to help you gather data on customer opinion or satisfaction with your process.

Figure 1: Data Collection Plan Worksheet Remember! The important outcome of this checkpoint is to establish a well-defined method for collecting data. Whether this is done using the included worksheets, an internal action plan, or another method is not important.

Step 3: Identify Indicators - Checkpoint 11

11. Quality and process indicators were assigned, and considered (Quality, Cost, Delivery, Timeliness, Safety, Security and Environment).
Now that customer requirements have been identified and data collected, you can begin to develop indicators

"Indicators" are metrics (or standards of measurements) that measure the outcomes of a process or process sub-step. Much like a speedometer tells you how fast your are going and if you are breaking the speed limit, an indicator is a gauge of process performance that tells you how well a process is performing and if its performance passes an acceptable limit. Line graphs, such as the one shown in Figure 1, are often used to display indicators.

Figure 1: A Quality Indicator As you can see from the figure above, Indicator line graphs have a good arrow indicating the desired direction of line graph movement and a target indicating the desired direction or customer valid requirement. The good arrow shows the direction that the indicator "should move" for good results. For example, if you are looking at an indicator that shows "number of errors," clearly fewer errors are better and therefore the good arrow would point downward. Indicators with upward pointing good arrows might include "customer satisfaction rating," "% complete applications," etc. The target line, or bar in some cases, shows the acceptable limit of the indicator or the goal that your indicator is trying to achieve. Targets can be constant or they can change over time. How these targets are established will be discussed later in Checkpoint 13. The important point to remember about targets is that they denote the "goal" of the indicator. The line graph should move toward the target in the direction of the good arrow, or remain past the target in the direction that the good arrow points.

The Types Of Indicators

Quality Indicators
Quality Indicators measure direct conformance to the customers' valid requirements or satisfaction levels. Quality indicators can measure conformance anywhere in the process or even after the process has been completed. Most often, however, quality indicators are measured at the end of the process.

Quality indicators directly link to customer valid requirements or another aspect of customer satisfaction. For example, if you are a contractor with a process of "build a house" then one quality indicator would be "house built on time." Building houses on time is a customer valid requirement of the land developer you work for. Notice that quality indicators offer a direct "rating" of how well a process is meeting a customer (internal or external) need. Traditionally, quality indicators are denoted by a "Q" or a Q in a circle.

Figure 2: A Quality Indicator

Process Indicators
Process Indicators are selected to measure outcomes within the process that drive quality or outcome measures. These indicators show how certain portions of the process are performing and, if correctly set, will provide early warning that a quality indicator may be affected. In order to provide this early warning, most process indicators are set upstream, or early in the process, and usually measure a critical step in the process. For example, if your process is "build a house," then clearly it is critical for the building materials to arrive on time. If the on-time arrival indicator of the building materials does not meet its target, then the overall quality outcome indicator of "houses built on-time" will surely suffer. Traditionally, process indicators are denoted by a "P" or a P in a circle.

Figure 3: A Process Indicator Notice that Figure 2 is a process indicator for Figure 1. Logically, the % of employees trained in application processing will directly affect the process quality indicator of application processing errors. Remember, process indicators are predictors ("P") of quality indicator outcome. There can be many process indicators that drive a single quality indicator's performance.

Mission Critical Indicators


Mission Critical indicators are high-level indicators that directly link to organizational goals or objectives. Just as process indicators driver quality indicators, when quality indicators meet their targets then mission critical indicators perform well. Of course, this all relies on welldefined indicators, well selected measures, and correctly mapped processes. Mission critical indicators can be viewed as a link between process management and strategic planning. Overall organization strategy is designed to meet organizational objectives through strategic planning. Strategic planning success is defined by performance of mission critical indicators, which are in turn driven by "Q's" and "P's." Traditionally, mission critical indicators are denoted by a "M" or a M in a circle. Although "M" indicators are not discussed in depth during this course, it is important to understand their purpose and relationship to process management.

Figure 4: The P-Q-M Relationship Figure 4 shows how "P" and "Q" indicators in the "Process Applications" process drive the overall mission critical outcome indicator "% Customer Satisfaction With Application Processing." Since this indicator is a "M," there must be a key strategic organizational requirement or objective to satisfy customers with application processing. Now that you understand the three types of indicators (P,Q,M) you need to learn how to identify and create good indicators for your process.

Step 3: Identify Indicators - Checkpoint 12

12. Process indicators were linked to quality indicators.


The best way to identify or confirm process indicators is by asking some specific questions concerning the selected Quality Indicators.

Questions To Identify Effective Process Indicators


Look at the process flowchart and your list of quality indicators (and potential process indicators). Using these documents as reference, ask yourself or your team the following questions:

1. When the Quality Indicator:_____________________________ is performing poorly what most likely within our process has broken down or been delayed? 2. What are critical steps in our process? When what critical steps are performed poorly will our Quality Indicator: ________________________________ will be severely affected? 3. What are the "weakest links" in our process, or areas of demonstrated problems or difficulty, and how do they impact our Quality Indicators? 4. What is the worst thing that can go wrong within our process that adversely affects our Quality Indicators? The answers to these questions will usually be strong candidates for process indicators. Process indicators should meet much of the criteria for good quality indicators, such as being accurate and cost effective, but they must also be accurate predictors of "Q" measures. In most cases, the relevance of a process indicator will be common sense, but not always. If the ability of a "P" indicator to effectively predict the performance of a "Q" measure is not certain, an analytical tool such as a scatter diagram may be used to establish a relationship. For example, the "P" results would be graphed as the independent variable and the "Q" results would be used as the dependent (to test the theory that the "P" data has a correlation to the "Q" data). Remember that process indicators are graphs that demonstrate process performance! When answering these questions, consider the type of graph that would be used to display this process indicator. The following worksheet may be used to record process indicators and confirm their linkage back to quality indicators. You can refresh your memory of the indicator "criteria" by clicking here, if needed.

Figure 1: Process Indicator Worksheet

Step 3: Identify Indicators - Checkpoint 13

13. Standards, targets or limits were established.


Targets are goals that are set indicators. When a person reviews an indicator graph, they should be able to compare performance against the target and quickly tell how the indicator is performing. Although a tremendous amount of focus and complexity has been placed on

target setting through the recent "Six-Sigma" movement, effective targets do not require complex math or statistics to establish. Targets should be created using the most appropriate "common sense" logic or methodology. In many cases, indicators will have logical targets that arise out of customer requirements, law, or business mandates. In other cases, analysis and consensus may be required to determine a valid target. However a target is set, you must establish a target so that each indicator has a clear point of reference for indicator performance. Without a point of reference, it can be difficult to tell if an indicator is improving (especially on cumulative indicator charts).

Target Setting Methodologies


Targets are not always static values. In fact, targets are often revised over time as better methodologies or more accurate data becomes available. Targets may also be adjusted when industry standards, laws, or competitor standards increase. Because targets may be revised at a later date, teams should not waste a lot of time establishing initial targets. Set targets using one of the methods below and keep progressing? the data collection process will be the same regardless of target levels. Adjusting a target later is a simple process. The following techniques can be used to develop targets for your indicators. Use whichever technique makes the most sense in your situation.

Customer Valid Requirements


Targets may be set based on CVR's when a logical target exists. For example, if one of your customers requires that you return calls in 2 hours or less, then clearly you have a target somewhere below two hours. Make sure you have a clear understanding of CVR values if you use this method. Refer back to customer needs information from earlier in this step, if needed.

Benchmarking
Benchmarking is the process of setting targets based on competitor, or best in class/division/organization performance. Often times similar organizations track similar indicators, for example, overall customer satisfaction. If you can determine a competitors level of performance in an indicator, then you can use this level as a target to shoot for. In addition to competitor performance, benchmarks can also be based on high performance or successful organizations in unrelated fields. Finally, benchmarks can be developed using internal organization performance between offices, divisions, etc. This is useful when your indicators are unique, or competitor data is not available. Do you recall reading that organizations with similar departments should strive to use similar indicators? Here is another reason why! An organization can analyze indicator performance across departments and use the best performing department as a benchmark target for the others.

Historical Trends
When competitor data or benchmarks are not available, historical trends can be used to set targets. Indicators can be reviewed to determine the best performance levels they have achieved. This historical performance trend is then used as a target . For example, if a department performs data entry and their best ever entry rate was 5,137 documents per day, setting a target to this value is an excellent start.

"What The Data Will Allow"


In some organizations, such as manufacturing or healthcare, targets are set by resource limitations or the environment. For example, consider a manufacturing process that requires 90 units of material and has 100 units of material available. If "Average Resource Units Wasted In Production" was an indicator, then a good target would be less than 10. Do you see why? 100 Total Resources - 90 To Build A Unit = 10 Units Extra If this organization wasted more than 10 units on average (due to bad cuts, human error, etc.) than they would clearly impact the production process? they would run out of resources! Setting targets by what the data will allow is using features of the process to determine what levels an indicator must perform at.

Management Wisdom
Although often controversial, management mandates may be used to set targets for indicators. In many cases these targets will be aggressive to inspire performance or to encourage employees to "rise to the challenge." As idealistic as this approach may seem, management wisdom can be an effective target setting technique when properly applied. For example, management could make the case that they need certain targets to be met to avoid resorting to layoffs, or to achieve enough reserves to offer employee bonuses. If targets are based on management wisdom, it is usually helpful to explain the logic of these targets via communication to the process owners to establish "buy-in."

Law
These are targets mandated by state, federal, or any other law, plain and simple. If a law states that workers compensation claims must be processed in four weeks, then a target should be set LESS than four weeks with enough time built in for unforeseen problems and difficulty. Don't be afraid to set targets above minimum standards!

50% Improvement
One of the fundamental truths of industrial engineering is that organizations have an inherently high amount of "waste" in processes. This does not mean that an organization is poorly run, or even unprofitable. It DOES mean that every organization has the opportunity to significantly improve process performance. If no clear targets can be determined, look at the most recent indicator values and set a target for 50% above that value (multiply the current indicator value by 1.5). For example, if your latest "Hours Of Training" indicator value was 137, then a 50% improvement target would be 137 X 1.5 = 205.5.

Document The Targets


Once a target is established, don't forget to document the value of the target and the formula / rationale for the targets value! A good place to keep this information is on the Process Control System (PCS, will be discussed shortly) or the indicator graph, or an indicator documentation form (shown later).

Step 3: Identify Indicators - Checkpoint 14

14. Quality and process indicators were noted on flowchart.


The remainder of Step 3 involves finalizing the indicators that have been established in the previous checkpoints. Traditionally, indicators are denoted on the process flowchart they belong to, near the step that they are relevant to. Consider the example in Figure 1 below.

Figure 1: Indicators Displayed On A Process Flowchart This flowchart has three indicators: two "P" indicators and a single "Q" indicator. Notice that these indicators are denoted by a letter contained in a circle, and a numeric subscript. The letter tells a reader what type of indicator this is (P,Q,M) and the subscript is like a legend on a map. The subscript refers to another list that contains detailed information about the indicator. The indicator notation used above is especially useful for keeping track of indicators in large organizations. Remember that each one of these indicator symbols refers to an existing indicator (a graph and target that is being monitored by the process team/owner). These symbols are included in the ets Visio Flowchart Template from the ets Decision-Making Tools course.

Figure 2: The Indicator Symbol In The ets Flowchart Template The position of the indicator circle on the flowchart is also significant. Notice that P1 is located directly next to the decision diamond that generates the "incomplete document rejection" that is tracked by the indicator. Likewise, P2 appears in the process flow at the point that the number of days to approve a document would be counted. Logically, Q1 appears near the end of the process. Do you remember why? Recall that "Q" (Quality) indicators show how well a process is meeting customer valid requirements or mandates. As such, these will usually be near the end of the process the point when a real measurement of success can be taken. On the other hand, "P" (Process) indicators are predictors of how a "Q" will turn out, so common sense dictates that these should appear somewhere in the middle of process flow.

Documenting Indicators
Listing your indicators on a process flowchart is important, but it certainly does not contain all of the requisite indicator data such as the line graph, targets, owner, etc. This information would clutter up a process flowchart if included, so it is not displayed. There must, however, be a document that lists indicators and provides complete indicator information using the P,Q,M / subscript notation shown above. There are a few accepted solutions for tying all of this information together. First, you can use the Process Control System (PCS). A PCS is a one page document that summarizes the majority of information about a single process: process flowchart, indicators, owners, performance data, and more. The remainder of this step will show you how these documents can be used as effective tools for documenting indicator information. Alternatively, you can also use an indicator checklist, an indicator documentation form, or any combination of the above. Whatever method you choose, ensure that readers reviewing your flowcharts can find indicator data relevant to that process. Templates for Process Control Systems, Indicator Checklists, and Indicator Documentation Forms are included at the end of this step.

Step 3: Identify Indicators - Checkpoint 15

15. Indicator owners were identified.


The remainder of Step 3 involves finalizing the indicators that have been established in the previous checkpoints. Now that your have placed the indicators on your process flowchart, you must identify owners for each indicator. In the same fashion that a process owner is responsible for all aspects of a process, an indicator owner is the person responsible for keeping indicator data up-to-date. An indicator owner personally maintains accountability for gathering indicator data and updating indicator charts and graphs. Indicator owners are also responsible for monitoring their indicators and notifying the process owner and/or initiating a contingency plan if the process indicator fails to meet its target / goal. When selecting an indicator owner, try to choose someone either on the process management team or someone that has easy access to the data you will be collecting. Remember to be considerate! One of the pitfalls of formal improvement processes is that they can quickly become burdensome to organizations. Try to keep the amount of indicators you use to a necessary minimum, and collect only as much data as you need.

Document The Indicator Owner


Just as indicators must be documented, the owner of an indicator should be recorded. Owner names may be listed on a PCS chart, an indicator documentation form, or any other method your organization adopts. Figure 1 shows a Process Control System chart with three indicators and three indicator owners listed.

Figure 1: PCS With Indicator Owners Listed Figure 1 shows an example PCS. Take a moment to review the format of the PCS document. The top of the PCS has information about the process itself: process name, process objective, owner and revision history. The left-hand side of the PCS shows the process control flowchart. The right-had side of the document contains information about the indicators listed in the process flowchart. Notice how each indicator has a horizontal row of information such as target, responsibility (owner), and contingency plan information. Each of these rows should be positioned at a height similar to the indicator's symbol on the process flowchart. The red circles highlight where indicator owners are listed on the PCS. Each of these indicator owners should be able to produce their indicator graph, upon request from the process owner.

Step 3: Identify Indicators - Checkpoint 16

16. Contingency plans to ensure control were noted (if necessary).


This is a simple, yet often overlooked step in process management. Contingency plans are "what to do when the indicator doesn't meet target values." Simply stated, a contingency plan specifies the course of action that an indicator owner should take when they feel that their indicator is not meeting acceptable performance levels. Each indicator owner should understand their own indicator to the point that they can determine if a contingency plan needs to be initiated. Does a process indicator that does not meet target necessarily require contingency activities? Not always. If an indicator owner knows that their indicator is being affected by a normal business cycle (such as the holidays), then they may feel that contingency steps are not necessary. Another scenario might be an indicator that is improving, but not yet reaching its target. Although it is not at a target level, the indicator owner can tell if progress is being made and make a call as to whether or not contingency measures should be taken.

How Are Contingency Plans Developed?


Ideally, contingency plans are cost-effective, proven solutions to driving indicators to move in the "good" direction. Unfortunately, such simple options are not always available. If process improvement information is available, or DMAIC problem solving has been performed on this indicator or process, refer to that documentation for practical methods of improving indicator performance. If no such information is readily available, consider performing a DMAIC improvement process on this indicator! Refer to the ets DMAIC Problem Solving Method course for more information. If all else fails, brainstorm some potential or confirmed solutions or simply inform customers / stakeholders so that they are aware of process shortcomings. Ultimately, each indicator should have some practical method for improving its performance when it fails to meet targets. Developing these methods over time and constantly improving them is part of the on-going process improvement procedure, and the PD-C-A cycle.

Document The Contingency Plan


Contingency plans should be documented for each indicator, using either the PCS form or whatever method your organization adopts. Figure 1 shows a Process Control System chart with three indicators and three contingency plans listed.

Figure 1: PCS With Indicator Contingency Plans Listed The PCS is a summary document, intended to provide a quick overview of any process in an organization. In this regard, you need not list every step of a complex contingency plan. Simply provide a general description of the plan on the PCS document. The indicator owner and the process owner should both have access to detailed contingency plan documents if they are needed.

Step 3: Identify Indicators - Checkpoint 17

17. Control system was reviewed with supervisor / manager.


As a final step in developing the PCS, or process flowchart and indicators, your team should provide the package for review. This step helps to synchronize process management activities in an organization, and also allows management to be kept abreast of process management efforts.

Another benefit of reviewing PCS documents is the promotion of sharing ideas and best practices as they develop. Managers are able to capitalize on process team's work by sharing lessons learned with other departments. The review process also provides managers with a tool for understanding your process and finding the "right person" to talk to about process questions or issues. Since accountability and employee development and recognition are vital to the performance excellence philosophy, this is another proactive step toward that goal.

Document The Review


Figure 1 shows a Process Control System chart with the Supervisor / Manager review documented, and the date of the review recorded.

Figure 1: PCS With Supervisor Review Listed

Step 4: Implement Process Control System

Overview
Step 4 of process management is where organizations develop and deploy the Process Control System (PCS) for a process. A PCS tells the story of a process at any given time and is a valuable reference for documenting and communicating process management work.

Step Checkpoints Step Implement Process Control System Checkpoint 18. Finalize the Process Control System.

Develop a procedure for managing the process control system. Develop checksheets to facilitate data collection and analysis. Train employees to: a) monitor; b) evaluate; c) improve; d) document learning; e) apply contingency. Commence data collection and monitor indicators. Review initial results and adjust data collection or process as needed.

Step 4: Implement Process Control System - Checkpoint 18

18. Finalize the Process Control System.


Step 4 of Process Management is where the PCS you have developed in steps one, two and three is actually deployed into the organization. In this step, you actually shift from "planning" to "doing" what your process management team has recommended. All of the steps up until this point have consisted of analysis and preparation to begin actively managing a process developing the process management "plan." Whether or not your organization is using the ets PCS format, by this point you should have a well defined process flowchart with indicators, owners, contingency plans, etc. All of this information clearly lays out a method for managing a process, so now your team must set these plans into motion and ensure that things get done as you intended. Step 18 is a series of sub-checkpoints that help your team effectively launch a process management plan and ensure that it remains effective.

Applying What You Have Learned


Step 18 uses a selection of techniques from the ets Decision Making Tools and Analytical Tools courses including:

Barriers and Aids Analysis (Decision Making Tools) Action Plans (Decision Making Tools) Checksheets (Analytical Tools)

Although this section will review the basic application of these tools, you may refer back to these topics in each respective course for a list of steps, examples, and templates.

Step 4: Implement Process Control System - Checkpoint 18

18. Finalize the Process Control System.


The first step in finalizing the PCS is to establish a procedure for ensuring the PCS is properly managed from here forward. Managing a process control system means making sure the PCS is deployed, verifying that necessary activities are done by the accountable parties, and keeping the process management project on schedule. Your team needs to agree upon a

management procedure and develop an action plan that ensures key PCS management activities occur on time. To manage is to exercise executive, administrative, and supervisory direction of a process. Think of your process management team as a small organization that must provide the same leadership and support to those involved in your project as you would receive from your management staff. Leadership and support includes, but is certainly not limited to, scheduling, technical support, guidance and assistance. Consider what roles and resources are needed, then document these and set them into motion. Document your management procedure to a level where a third party could step in and replace your team, if needed. This helps keep your work process independent, rather than people dependent. Once a good procedure has been documented, you can use this management procedure as a template for future process management projects.

Assessing The Challenge: "Be Prepared!"


Successful PCS deployment begins with proper preparation. One of the best ways to prepare for any situation is to consider the barriers you may face and develop procedures for minimizing the effects of those barriers. It is also helpful to take inventory of the positive forces and resources that will help integrate the PCS more easily. By establishing plans for problems and capitalizing on existing aids, your team will have a better chance of a smooth PCS launch. Before creating an action plan for finalizing the PCS, your team should perform a barriers and aids analysis for implementing your PCS system. In technical terms, your barriers and aids countermeasure will be "improve the process" and the practical method will be "implement the PCS system." While performing the analysis, consider the impact that data collection, process changes, and additional workload may have on staff. Also discuss the benefit of increased efficiency, management support, and additional resources. Be sure to address any "high" rated barriers and capitalize on any "high" rated aids. If you find that the barriers greatly outnumber the aids, you may need to go back to Step 2 and rethink qualitative analysis changes and/or indicator selection. The output of your barriers and aids analysis should be factored in to development of your action plan (the next sub-checkpoint).

Review: Barriers And Aids Analysis


(Excerpted from the ets course: Decision Making Tools) Barriers and aids analysis is a technique that is used to identify elements that hinder (barriers) or help (aids) a proposed course of action (countermeasure). Barriers and aids analysis helps a team to decide whether or not a countermeasure would be an effective solution to a problem or opportunity, and to identify any potential problems before going too far with a project. In fact, this process is frequently done before completion of an action plan to verify the feasibility of proposed countermeasures. In simple terms, barriers and aids analysis is a structured method of determining the "Pros" and "Cons" of doing something.

Figure 1 shows how barriers and aids analysis breaks down the barriers and aids to your countermeasure and rates them on a standardized scale of importance. Remember that standardization and effective communication are important when providing information to decision makers!

Figure 1: A Barrier and Aids Analysis The general course of action is listed on the "countermeasure" line. The specific course of action, or "Practical Method," line gives a description of how this countermeasure is specifically proposed to be implemented. Note that for every countermeasure, many practical methods may exist! The "Forces Pushing Against - Barriers" column lists all of the barriers that could hinder the implementation of the countermeasure. To the left of this column is the "Impact" column, where each barrier is rated as a High, Medium, or Low barrier to success. The "Forces Pushing For - Aids" column lists all of the aids that can be used to overcome, or balance, the barriers listed. It is not necessary, however, to have an aid for every barrier. The "Impact" column to the left of the "Aids" column rates the impact of each aid on the barrier it affects. When this analysis is completed, a team will have identified the most important barriers that could prevent them from succeeding in implementation of a countermeasure. If a barrier rated as High or Medium impact is not countered or balanced by an appropriate aid, a specific action plan may be needed, or the planned countermeasure may need to be reconsidered.

Step 4: Implement Process Control System - Checkpoint 18

18. Finalize the Process Control System


Develop checksheets to facilitate data collection and analysis. In Checkpoint 10 your team determined a method of obtaining data for your process and indicators. The next step in finalizing the PCS is to ensure that there are documents for recording all the data that must be collected (and that these documents are distributed / available to the appropriate people). For most simple data collection needs, checksheets provide a standardized method of gathering and recording information. More complex data sources may require spreadsheets or tables. The important point of this sub-checkpoint is to make certain that a standardized method for documenting all process and indicator related data exists before launching the process management project. Some valid options for recording process management data include:

Checksheets (attributes data, counts, number of defects, etc.) Custom designed charts or forms. Special files or folders. Spreadsheets Shared databases or online applications.

However you choose to record data, ensure that the following information is recorded:

The actual data values, using consistent measurement units. Who recorded the data. When the data was recorded.

Review: Checksheets
(Excerpted from the ets course: Analytical Tools) A checksheet is a form used to collect data. A good checksheet is easy to understand and helps by structuring collected data into groups. Although data can be counted in many ways, checksheets specifically show all of the categories that you are counting in addition to how many "checks" each category received. For example, consider a team that is asked to increase daily application processing speed. They decide to begin their task by analyzing how many applications are processed each day. Some people would suggest Monday is the most productive day, since the staff is rested and ready to come back to work. This seems logical, but on the other hand, some workers may

have spent the weekend traveling and arrived at work tired and unproductive. The actual answer cannot be determined by speculation alone. In this instance, a checksheet could be used to record applications processed on each day. By tallying the results, the team would get a fact-based view of daily productivity. See Figure 1 below.

Figure 1: An Example Checksheet Each vertical line in the checksheet represents one application. A diagonal line is used to signify a count of five. This notation is used since most checksheets are completed by hand, and groups of five are easy to count.

Step 4: Implement Process Control System - Checkpoint 18

18. Finalize the Process Control System


Train employees to: a) monitor; b) evaluate; c) improve; d) document learning; e) apply contingency. Once you have management procedures and data collection tools in place, your team needs to identify all employees involved with your process management project so they understand their role. Although the process owner and indicator owners will handle most of the on-going PCS work, everyone involved with the process management project (directly or indirectly)

should be trained in how to monitor, evaluate, improve, document learning, and apply contingency plans during the project. Each of these required skills is briefly described below. Train Employees To Monitor Employees should have a functional understanding of the correct process flow and the data that is required to populate indicators. Additionally, any employee involved in the process itself should know enough about indicators to realize when one is missing target, or about to miss target. Monitoring can be encouraged by educating process players and keeping them abreast of indicator values and developments, such as a monthly indicator "checkup" posted on a shared bulletin board. Try to instill in the process staff the understanding that indicator performance reflects their overall performance as a "process." Monitoring process health encourages understanding and overall process well-being. Monitoring the PCS is an on-going task that is discussed at length in Step 5. Train Employees To Evaluate When employees understand and monitor, then can begin to evaluate. Evaluation is the process that begins when a process player looks at some feature of a process and asks "Why?" Why is the indicator going the wrong way? Why are we not following process flow? Why is our customer still dissatisfied? Evaluation skills are honed through application of analytical tools (fishbone analysis, theme selection matrices, etc.) along with a considerable amount of wisdom and common sense. Employees should be encouraged to take an active role in encouraging process performance, and they should receive recognition for noteworthy evaluations or observation efforts. When process players begin to evaluate their process, they begin to take personal ownership of the process management philosophy. This ownership reinforces the PCS installation and can become a powerful driver of change! Train Employees To Improve Evaluation and awareness of a problem is the first step to improvement. Once an employee determines that a problem exists, they should have the skills they need to fix the problem, or support an improvement effort. These "skills" consist of analytical tools, decision-making tools, and a formal problem solving process. A formal problem solving process, such as the Six Sigma DMAIC method, is a vital skill for all employees involved with process improvement. The DMAIC method provides a common language and structure for problem solving, and is designed using the same fundamental elements of process management. More importantly, the DMAIC method has been used and refined over many years, and is a proven "best practice" for driving change or improvement. All of the skills required to generate process improvement can be learned using the ets Analytical Tools, Decision Making Tools, and Six Sigma DMAIC Method courses.

Improving the process is an on-going task that is discussed at length in Step 6. Train Employees To Document Learning One of the most beneficial effects of process management is learning to do things better, faster, and for less cost! In this regard, it is critical that all success stories in your organization are documented, replicated in similar areas, and shared with the organization as a whole. Another advantage of using the DMAIC problem solving method is manner in which it documents "lessons learned." Some of the most beneficial gains an organization receives are from sharing lessons learned and documenting best practices. Don't underestimate the importance of this step! Documenting learning is widely recognized as valuable for process improvement. In fact, large corporations, states, and even countries hold regular competitions for improvement teams to share their wisdom and lessons learned with other similar groups. If your process team has a great success story, spread the word! Share your DMAIC story with executive management, post an overview in the corporate newsletter, or submit your wisdom to the corporate intranet. As a process owner or manager, don't forget to honor the employees that find better ways to do things! Train Employees To Apply Contingency Just as employees should be empowered to improve, they must be able to take action when something goes wrong. Checkpoint 16 of the process management procedure requires the development and documentation of contingency plans, "what must be done when process problems occur." Ensure that process players are familiar with the contingency procedure, and understand when contingency plans should be put in to effect. Contingency plans, although vital, should not be used on a regular basis. Excessive reliance on contingency plans is an indication that the process is unstable, and therefore should be analyzed for further improvement. Remember Your P-A-L! This page covers a lot of information, and most of this information needs to be communicated to employees. If you decide to hold meetings for your staff, remember the P-A-L approach: purpose, agenda, limit.

Step 4: Implement Process Control System - Checkpoint 18

18. Finalize the Process Control System.


Commence data collection and monitor indicators. Now that an implementation plan is in place and employees are trained, its time to begin collecting data and actively monitoring indicators. Using the action plan that your team developed for PCS finalization, notify all participants in the project when the start date arrives. This is a critical point in process management, one in which all process players begin their ongoing responsibilities. The process management team should follow up with the indicator owners to ensure that data collection is being done properly, and per the established data collection procedures. Similarly, your team should check all relevant indicators to verify that they are being constructed properly and updated with the correct data. In summary, process management leaders need to make certain that positive momentum is generated and that all process related operations get off to a great start. You will also need to schedule a follow-up meeting shortly after this process occurs to review progress so far and assess initial results.

Step 4: Implement Process Control System - Checkpoint 18


18. Finalize the Process Control System.
Review initial results and adjust data collection or process as needed. The final sub-checkpoint of Step 18 is to assess how well your process management project is doing, and make adjustments if needed. Schedule a meeting for the process management team to sit down and review data that has been collected, indicators, and updates to the PCS system. Ensure that formulas are being followed, targets are accurate, and everything is operating as designed. Also, speak with some of the process players to gather feedback about the deployment. Are there things that could have been better? Are there any suggestions for improving the data collection processes? Gather as much feedback as possible and don't forget to document good ideas and lessons learned. You will assuredly need to make minor adjustments in the early stages of any process management projects. Continue meeting and reviewing performance until your team is confident that everyone has a firm grasp of the procedures. Once this occurs, the team can shift into the on-going improvement and maintenance phase of process management: Steps 5 through 7.

Step 5: Monitor Process Control System

Overview
Step 5 of process management is where organizations evaluate a process to determine how stable it is (predictable and consistent) and how capable it is (level of meeting its customer requirements).

Step Checkpoints Step Monitor Process Control System Checkpoint 19. Process was evaluated for stability (e.g., six interpretation approaches). 20. Process was evaluated for capability (e.g., histograms).

Step 5: Monitor Process Control System - Checkpoint 19

19. Process was evaluated for stability (e.g., six interpretation approaches).
Indicators must be continually monitored to determine if they become unstable. Unstable indicators are a sign that a process is not under control, and therefore, not predictable. Predictability and stability are important for process management because internal and external customers rely on your process to produce proper outcomes on time, every time. If a process is unstable, it can introduce delays and rework into many other processes costing time and money to an organization. Monitoring data for stability is an on-going aspect of process management. Although a process may be stable today, there is no guarantee it will be stable tomorrow. Perhaps some piece of machinery will wear out? Maybe a major change in technology or workforce procedures will affect the stability? However it occurs, you should expect data to always fluctuate to some degree. Process management teams, and indicator owners, must continually monitor indicators to ensure that they do not fluctuate beyond what is considered "normal" variability. But what is normal fluctuation, and how is it determined? To answer this question, you need to learn some simple statistics concepts.

The Statistics Of Measurability And Variability


Within any set of data, some degree of variation is expected. If variation in data is not observed, then it is probably because the data is not being measured with a device sensitive enough to detect the variation. For example, consider a gallon of milk that is purchased from a grocery store. On the shelf are many gallons of milk, all of which weigh the same or do they? Although each jug holds a gallon of milk, there is no guarantee that each gallon jug of milk weighs the same. Consider some of the reasons why this could occur:

The jugs are slightly different sizes. The machine that fills the milk jug isn't very accurate. Small amounts of milk spill from some jugs when the caps are placed on. Some of the jugs may have leaked a small amount of milk.

In reality, almost every set of data will show some variability if it is measured closely enough. Even coins will have slightly different sizes if examined using a micrometer (a device used for measuring very small distances), due to production defects or simple wear and tear. Variability of data, including indicator data, is typical and something that should be expected. If your indicator does not appear to have variability, you are probably not measuring it closely enough. Since variability is a normal part of data sets, the question of determining stability becomes "how much variability is considered abnormal or unstable?" The answer is, "it depends on your data." The range of data that is considered normal or "stable" is actually calculated using

all the values of the data itself. These types of calculations were introduced in the ets Analytical Tools course as "Control Limits" for Control Charts. Control charts, coincidentally, also happen to be the preferred method for monitoring indicator stability.

Step 5: Monitor Process Control System - Checkpoint 20

20. Process was evaluated for capability (e.g., histograms).


Capability is the extent to which a process is capable of meeting customer specifications. When a process is said to be capable, it means that it is performing within a range specified by customer valid requirements. For example, assume your process is "provide employee training." Customer valid requirements probably include data such as "% information retention, hours required for training, or employee satisfaction with training." As you learned in Step 3, many of these customer valid requirements are translated into P and Q indicators. Now assume that management, an internal "customer," mandates that training must occur in 15 to 20 hours and that employee satisfaction must be 85% or higher. When the process outcome indicator data is within the customer specified range, such as between 15 and 20 hours and more than 85% satisfaction, then the process is said to be "capable." A capable process is a process whose indicators lie within the range of values that are acceptable as defined by your customer(s).

Stability vs. Capability


Stability is determined by the statistical behavior of your data. Capability is determined by how well your data stays within the values required (and validated) by your customer. These two concepts are related, but distinct. It is perfectly reasonable to assume a process could be unstable but capable, or incapable but stable. In most cases, however, instability does in fact lead to a lack of capability. Now that these two concepts have been distinguished, let's focus on how capability is defined and tracked.

Determining Capability
Much like stability, capability is determined by the behavior of your data as a whole not an individual point. Capability is determined by how well your process stays within customer specifications. If you were studying for a test, how would you test your "capability" of doing well on the exam? What if you arbitrarily picked a review question and tried to answer it. Would your success on that single question accurately predict how well you will do on your test?

Making a prediction of success on a single, or an insignificant number, of data points is not very effective. A better predictor of your success on an exam would be to attempt many questions, and see how well you did overall. This same logic is applied to determining process capability. When capability for a process is determined, data is gathered over time and a histogram is used to provide a clear statistical picture of the "average" value AND the distribution of your data values. Remember that the average value doesn't always provide a clear picture of your data. If the process indicator for the example above "hours required for training" had an average value of 17.5, what does that mean? Does this value mean that the process is very capable (every person finishes in exactly 17.5 hours) or does it mean that the process is on the brink of being horribly incapable (everyone finishes in 15 or 20 hours)? Figure 1 shows how these two distinctly different situations can both have the save average value.

Figure 1: The Misleading Average Figure 1 reinforces the need for a better view of data, much like the "orange size" example did in the ets Analytical Tools course. Histograms, or other frequency distribution charts, are the accepted tools for analyzing capability.

What Are Frequency Distributions?


Frequency distributions are analytical tools that display the distribution (or variation) of a group of data points. Unlike the average, a frequency distribution tells a reader how the values in the data set are "distributed" and how "frequent" they appear in a certain range of values. Continuing the example from Figure 1, notice that the top data set has values "distributed" at 17.5. The lower data set, however, has values "distributed" at opposite extremes: 15 or 20. A frequency distribution chart tells you where your data lies, in a range of values, and how "frequently" data points occur is certain ranges called "bins." Figure 2 shows Excel generated histograms for the data in Figure 1. Can you tell which distribution belongs to which data set?

Figure 2: Frequency Distributions- Histograms The histogram on the left shows 10 occurrences of a value between 16.5 and 18.5. The one on the right clearly shows 5 values on either end of the chart range. See how histograms provide more insight into a data set? If you are a little rusty on histograms, don't worry! The next section takes a moment to quickly review frequency diagrams and histograms before we show how they are actually used to analyze process capability. You can also review histograms in the ets course Analytical Tools, if you would like.

Step 6: Improve Process

Overview
Step 6 of process management is where a process is improved and accountability is established to ensure that improvements occur on-schedule, and are effective.

Step Checkpoints Step Improve Process Checkpoint 21. Systematic improvement techniques were used (six-sigma DMAIC method). 22. An action plan was established to get back into control or improve the process.

Step 6: Improve Process - Checkpoint 21

21. Systematic improvement techniques were used (six-sigma DMAIC method).


The purpose of this step is to familiarize you with the systematic approaches available for improving a process or solving a process capability / stability problem. Process improvement requires accurate analysis, to determine the proper causes of the problem, and structured techniques, to ensure that the problem is corrected and the process improved. When we talk about improving a process, we mean moving indicators in the "good" direction, increasing stability / capability, raising efficiency and improving overall quality in some way that can be proven with data. You must be able to demonstrate improvement with data, otherwise you cannot be sure that it really occurred. Just as process management has well-established procedures, process improvement is also performed using a series of steps and checkpoints. Some of these improvement methods have been introduced already, but Step 6 will provide you with a clearer picture of how process management and improvement analysis continually interact with each other. To this end, Step 6 will cover:

The Process Analysis Model and the relationship between the activities of process analysis and process improvement. Qualitative Analysis techniques used for driving initial process improvements. Quantitative Analysis techniques used for driving on-going process improvements. Other procedures, activities and concepts that are related to process improvement.

The Need For Process Improvement


Process improvement can occur at any time, and is an on-going part of process management. Nonetheless, most process improvement efforts are typically performed during the initial

process mapping procedures or to correct unstable or incapable processes. Process improvement can also be required due to executive mandates, changes in laws, or adjusted customer requirements. In other words, process improvement is a formal method by which you "fix" processes that are not working correctly, or make good processes even better. As stated above, processes are most often improved when they are not meeting important criteria but they are also improved to simply make them better. Remember that process management follows a P-D-C-A approach. In P-D-C-A, everything is continually evaluated for ways to make it better, faster, and more cost efficient. Even if your process is meeting all current targets and requirements, new technology or techniques may become available to help you improve even more. There is always room for improvement in processes, but this doesn't mean that your team should perform process improvement for every indicator! In practice, process improvement is usually prioritized to focus on areas that generate the most improvement for the least effort, or are causing your organization the most "pain." To help identify and prioritize areas for process improvement, process analysis is used. Process analysis is the act of investigating a process, and can be performed using different approaches, depending on where the problem in your process occurs and how obvious it is.

The Need For Process Analysis


Process analysis is the act of investigating a process, usually to understand what's going wrong or what could be better. When a process isn't working properly, process analysis provides the guidance needed to perform effective process improvement. In fact, a major part of mapping a process and creating a PCS involves features of process analysis. For example, sometimes simply creating a process flowchart can highlight rework loops or inefficiencies that lead to intuitive process improvements. As you can see, process analysis and improvement are closely related. You have already encountered some forms of process analysis during process identification and data collection activities. Another key area of process analysis, however, comes from using more creative analysis processes.

Figure 1: Process Analysis Model

Creative methods of analysis enhance traditional monitoring activities by encouraging teams to go beyond obvious analysis methods and assess processes from new perspectives. Creative analysis processes also direct qualitative and quantitative analysis activities that can eventually lead to re-design of a process so that it becomes more capable or stable. Unlike "re-engineering," which encourages individuals to start with a "blank page" and completely re-invent a process, creative process analysis and improvement techniques fix existing processes they identify waste and weaknesses so that effective re-designs can be put in place, rather than starting over from scratch.

Qualitative vs Quantitative Analysis


Qualitative and quantitative analysis are two different methods of inspecting a process. Both methods involve a degree of creative thinking: Qualitative analysis involves the investigation of the conceptual process aspects or "qualities" of the process: the shape of the flowchart, who is involved, how success is defined, etc. Most qualitative problems can be easily identified with common sense or simply analytical tools. Quantitative analysis involves the investigation of non-conceptual or "countable data" such as poor process capability, stability, indicator performance, etc. Quantitative problems are more difficult to explain and may involve many factors contributing to a problem that must be assessed, ranked, and prioritized for improvement. In practice, quantitative analysis is performed regularly as part of indicator monitoring.

Qualitative analysis is a good starting point for investigating process issues. Quantitative analysis can then be applied if qualitative analysis cannot determine a cause, or is inconclusive.

Step 6: Improve Process - Checkpoint 22

22. An action plan was established to get back into control or improve the process.
Finding a method to improve your process is a good first step, but you must also ensure that critical actions that cause the improvement take place on-time, and are successful. Anytime you must monitor the progress of project, or, more specifically, "an improvement project," an action plan should be used. These tools are discussed at length in the ets Decision Making Tools course, but an overview is also provided below for review.

What Is An Action Plan?


(Excerpted from the ets course: Decision Making Tools) An action plan is a type of chart that contains the "Who, What, When and How" of an organized process. In the context of management, action plans are often used for improvement or project tracking. When well constructed, an action plan serves as the overall blueprint of how your process resources are allocated, and how each member of your team will be involved in the process.

Figure 1: An Action Plan

Step 7: Standardize Process

Overview
Step 7 of process management is where organizations ensure that improvements remain in place and apply improvements from the current process to other areas that might benefit from similar changes. Teams should also use Step 7 as an opportunity to review the process management team experience, and document lessons learned and things that can be done to improve the next process team's procedures.

Step Checkpoints Step Standardize Process Checkpoint 23. Method was established to ensure process standards continuously reflect customer requirements. 24. Specific areas for replication were considered. 25. Applied P-D-C-A to lessons learned.

Step 7: Standardize Process - Checkpoint 23

23.Method was established to ensure process standards continuously reflect customer requirements.
These final checkpoints in process management should occur after your process control system has stabilized and the process management project shifts into a maintenance phase. Monitoring and improvement, Steps 5 and 6 respectively, should continue throughout the life of a process control system but will play a much more present role in the early stages of process management. Once a process is stable and capable, your team should shift their attention to maintaining improvements that have been made and ensuring the continued relevance of indicators to customer needs.

Ensuring Relevance Through Documentation And Review


Overall, the documentation process is a method to ensure that a process management project remains effective and is regularly monitored for customer requirements relevance, not only indicator performance. Once the process control system has been stabilized and is capable of meeting customer requirements, the process should be more formally "standardized." In reality, process management and updating a process control system can be time consuming. All too often, the "victim" of limited time is proper documentation and standardization. PCS teams can get tunnel vision on indicators and improvement projects, and as a result, may fail to provide an adequate level of project documentation. Proper project documentation is important for many reasons. Among these, it ensures that accountability is in place to maintain the PCS, update indicators with changing customer requirements, and bring new team members up to speed. As mentioned in earlier sections of this course, customer requirements may change over time: expectations grow, competition drives new standards, technology improves, etc. The PCS document must be regularly reviewed to ensure that existing measures and targets remain accurate, and to determine if new measures are needed. For example, information technology-related processes underwent dramatic changes in the past twenty years. Imagine how different a "Manage Network Systems" process would be now, as opposed to one used in 1984. Not only would different data be tracked, old targets would probably be laughable. Computer processing "targets" once measured in hours or days are now measured in milliseconds. The documentation process also involves reviewing the existing process documentation and performing continued monitoring efforts to clarify (and even simplify) the work required to sustain process performance. The following pages describe three "best practices" procedures for documenting and ensuring the relevance of your process control system:

Clarify and Simplify The Process Communicate The Process Establish A Follow-Up and Review Plan

Step 7: Standardize Process - Checkpoint 24

24. Specific areas for replication were considered.


During the review and standardization steps, process management teams are responsible for identifying potential best practices, standards, or techniques that may be replicated in other areas of the organization. This single checkpoint can drive some of the most significant gains in an organization. Replication, in simple terms, has two important steps: First, teams must ensure that their good discoveries are communicated with everyone in an organization. Second, organizations must encourage everyone to incorporate other process management team discoveries into their own processes.

Sharing The Success


Organizational processes, although different in application and purpose, often share similar steps or procedures. For example, the process of retrieving customer records may be performed by many different departments and for many different reasons. Although each department may use a customer's record differently, they are all involved in obtaining record data and updating customer information. During the course of process management, teams often identify "better" methods of doing things. When such methods are found, a process management team needs to share these methods throughout their organization so that others with similar processes can capitalize on the better technique. Whether a team simply improves a current method, or establishes a "breakthrough" technique that radically improves a process, there must be a concerted effort on the part of process management teams and organizational management to encourage both improvement sharing and replication of best practices from other areas. Replication will not occur if management does not actively promote it; it won't happen automatically.

The Benefits Of Replication


The value and critical importance of replication has been discussed several times in this course. Now that you have a solid understanding of process management, take a moment to contemplate just how significant replication can be. Replication Maximizes Organizational Improvement

When a process management team finds a way to increase efficiency 2% in a single process, this improvement is magnified many times when it is replicated in other areas. This simple concept is where process management adds some of its greatest value to an organization! A seemingly minimal improvement by one team can still add up to dramatic improvement organization wide. For example, if your process team reduced the "minutes to access customer record" indicator by 2 minutes and shared this technique with 100 other departments that also access customer records, you have just turned a 2 minute improvement into more than a 3 hour improvement. Such gains are further magnified because organization wide improvement can drive better performance indicators of processes that are customers or suppliers of the improved process! Avoids "Re-inventing The Wheel" Re-inventing the wheel is a humorous way of describing rework. When a process management team discovers a great new technique but fails to share it, there is a good chance that another process management team will invest time and effort to "re-invent" the same technique. By sharing good methods and best practices, teams not only encourage re-use of good ideas but also prevent other process management teams from wasting resources to reach similar conclusions. Re-inventing the wheel is very costly: it delays replication, causes lowvalue rework, and ties up a process management team that could be inventing a new technique. Good communication and replication will prevent teams from doing the same things, over and over. Refines Good Practices Into Better Or Best Practices Many times in business or organizations, it takes one stroke of brilliance to make a discovery and the perspective of another person to make that discovery a masterpiece. When good practices are communicated and shared, they become a baseline for future improvement of other process management teams. This concept means that organizations who replicate improvements are continually improving the improvements. Refinement is generated by teams building on each other's work and continually replicating improvements. This cycle of on-going P-D-C-A and replication eventually created industry leading "best practices." A best practice, simply stated, is a process that is believed to be the "best" way of doing something in terms of cost, quality, and value.

Methods To Ensure Replication


Replication will not automatically happen. Management must take an active role in encouraging teams to share improvements, and organization members to embrace improvements from other teams.

One key requirement for replication is a functional understanding of process management, organization wide. It is difficult to explain a process improvement to someone that doesn't understand processes or indicators. Basic understanding of process management helps employees identify the value of shared improvements and assists in their application. Another important factor for ensuring replication is proper documentation. When a good improvement occurs, others must know exactly what changes were performed to drive that improvement. Organization members should also have some means to contact someone in the original process management team, in case there are questions or problems. There are many techniques for encouraging replication:

Newsletters, e-mail, or website updates. Annual improvement overview meetings. Internal quality awards or improvement team competitions. Internal quality departments.

New techniques can also be replicated by making them into standards. A standard would be an official organization procedure or level of performance, such as how to file an overtime request, that is documented as the "right" way to do something. Standards are often listed in employee training manuals or other HR or procedural documentation.

Step 7: Standardize Process - Checkpoint 25

25. Applied P-D-C-A to lessons learned.


After a process management project has obtained stability and capability, and all of the documentation has been completed, your team should schedule a meeting to review the project. This review should be a casual meeting in which each person involved with the project has a chance to reflect on what went well with the project and what could be done better next time. Just as improving organizational processes require continual improvement, the process management process itself should be continually refined and made better. When noteworthy improvements or problems are identified, they should be documented and communicated with other teams. Plan - Do - Check - Act P-D-C-A is a cycle based upon the premise that to always meet customer needs, you must continuously improve. You must plan what needs to be done, do (or implement) it, check the results of your actions (to ensure that you actually accomplished what you intended to do) and act upon the findings, applying lessons learned to future activities.

Process management, as a whole, embraces the philosophy of using systematic approaches to generate improvement and share gains throughout an organization.

Key Points
ets FasTrack Summary 1 of 2: The step by step procedure that helps organizations: understand what they do find better ways to do it, and ensure that improvements remain effective

is called? Answer: Process Management


Summary 2 of 2: How many steps and checkpoint are performed in Process Management? Answer: Seven (7) Steps Twenty-Five (25) Checkpoints

DMAIC Overview
What Is The DMAIC Problem Solving Process?
Below you will find a very brief overview of DMAIC, one of the two major, structured processes used in Six Sigma. DMAIC is a series of steps that are followed in which the Analytical / Decision making tools are used to correct specific problems or reduce undesirable results. Though we will be covering DMAIC in-depth during this course, for consistency we have included a brief overview of the process below.

A Formal Problem Solving Method


The ets Six Sigma DMAIC method is a way to solve problems. It was designed to effectively guide you through problem resolution, set the stage for continuous improvement, and enable you to communicate your approach to othersall while facilitating quick understanding and decision making. You can think of the DMAIC method as a step-by-step procedure that helps a team troubleshoot a problem and find the best solution. As you have read in this course, DMAIC (and other formal problem solving methodologies) are dynamic processes that are continually being improved and revised. Although the Steps and Checkpoints may differ over time, the general logic will remain the same: use data to sift through a problem and find the most significant cause, correct it, and continue until performance is acceptable. To help you learn to apply the DMAIC process, this course was presented in a series of 5 Steps and 33 Checkpoints. These sections are cataloged below for your convenience:

The DMAIC Method Overview The DMAIC method is composed of 5 steps and 33 checkpoints, each of which represents an activity in the problem solving process. These steps and checkpoints are used to help segment the problem solving process into a logical series of actions. By using a series of steps, teams can complete the problem solving process by following step-by-step instructions. In the context of this course, "steps" refer to the major operations in the DMAIC process: Define, Measure, Analyze, Improve and Control. The term "checkpoints" refers to the smaller actions that make up the larger steps. For example, "Step 1: Define" has 5 checkpoints.

Step 1: Define The first step in DMAIC, "Define" contains checkpoints that help a team demonstrate the significance of a particular improvement need, with data, and develop a schedule for completing the DMAIC method.

Step 2: Measure

Whereas the objective of Step 1 was to quantify the significance of a particular improvement need or theme, the objective of Step 2 is to focus more closely on the theme that you selected and find a specific problem within it to improve. During Step 2 you investigate critical features of the theme and select a specific problem to improve. The theme must be examined, stratified, and analyzed from various viewpoints before your team can discover the significant problem.

Step 3: Analyze Step 3 is composed of activities that help illustrate the reasons why a problem statement exists, and walk improvement teams through the process of finding the most significant, or "root causes," of the problem. Just as selecting the root or most significant causes of the problem is critical to efficiently improving the theme, selecting the most significant cause will also generate the most efficient gap reduction. Remember that much of the DMAIC process involves sorting through the "trivial many" to find the "significant few."

Step 4: Improve In Step 4, "countermeasures" are selected, tested, and evaluated for use in correcting the root causes from Step 3. A countermeasure is a refined idea that you, or your team, feels will reduce or eliminate the root cause.

Step 5: Control Step 5 of the DMAIC process is the step in which a team confirms that their improvements were successful, their efforts remain effective, and the theme of the project is completely addressed.

The table below shows each step and corresponding checkpoint and provides a quick link to each DMAIC step and checkpoint.

Step 1. Define 1. 2. 3. 4. 5. 2. Measure 6. 7. 8. 9. 10.

Checkpoint The stakeholder and need were identified. An indicator measuring our performance in meeting the need was developed. A theme statement consistent with the indicator was selected. A schedule for completing the five DMAIC steps was developed. The sponsor signed off on the projects purpose, scope, and significance. The theme was stratified from various viewpoints and a significant problem was chosen. A target for improvement was established based on the stakeholder's need. The impact of the target on the theme indicator was determined. A problem statement that addressed the gap between the actual and target values was developed. Measurement and data collection systems were developed.

11. 3. Analyze 12. 13. 14. 15. 16. 4. Improve 17. 18. 19. 20. 21. 22. 23. 5. Control 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.

The sponsor signed off on the projects focus and target. Cause and effect analysis was taken to the root level. Potential causes most likely to have the greatest impact on the problem were selected. A relationship between the root causes and the problem was verified with data. The impact of each root cause on the gap was determined. The sponsor signed off on the verified root causes and impact on the gap. Countermeasures were selected to address verified root causes. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility. Barriers and Aids were determined for countermeasures worth implementing. The action plan reflected accountability and schedule. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement. Incorporated lessons learned from the pilot into the full-scale action plan and implemented it. The sponsor signed off on the action plan and expected results. The effect of countermeasures on the root causes was demonstrated. The effect of countermeasures on the problem was demonstrated. The improvement target was achieved and causes of significant variation were addressed. The effect of countermeasures on the theme indicator representing the stakeholders need was demonstrated. A method was established to document, permanently change, and communicate the revised process or standard. Responsibility was assigned and periodic checks scheduled to ensure compliance with the revised process or standard. Specific areas for replication were identified. Any remaining problems of the theme were addressed. Lessons learned, P-D-C-A of the ets Six Sigma DMAIC Method, and team growth were assessed and documented. The sponsor signed off on the results and next steps.

The DMAIC Process

DMAIC Method Overview: START - 30 Minutes

What Is DMAIC?
The ets Six Sigma DMAIC Method is a formal, step-by-step procedure for solving problems. Using logical steps and simple checkpoints, an individual or team can use DMAIC to solve almost any problem, regardless of the issue's complexity or scope. A "problem" in the context of organizational problem solving is any issue or situation that is undesirable. For example, "low customer satisfaction, high employee turnover, too many incorrect applications, or low staff morale" represent the types of "problems" that can be resolved using this process. When implementing Six Sigma in an organization the need for improvement arises frequently. Business processes may fail to meet targets. Actions may not follow strategy. Projections may not be realized. DMAIC is the systematic way of determining the causes of these undesirable conditions and correcting them in the best manner possible. If you have a problem that needs to be fixed, DMAIC is the procedure for fixing it.

Learning Six Sigma Through DMAIC


This course will introduce you to the DMAIC method, teach you how to use it, and provide practical insight into DMAIC applications. Since DMAIC uses many of the analytical and decision-making tools, this course will give you an opportunity to see many of these tools applied in context. Also, DMAIC is similar in many ways to process management so you will also get experience using a logical, Six Sigma process. Although there is more to Six Sigma than DMAIC, the concepts and techniques you will learn in this course will give you the ability to follow most Six Sigma efforts and certainly learn more tools and techniques, if so needed. The DMAIC method consists of five steps and 33 checkpoints. Like process management, the DMAIC method uses the cyclical design philosophy of P-D-C-A (Plan, Do, Check, Act). Any procedure based on P-D-C-A stresses accurate planning based on data, relevant action based on the plan, verification of results due to actions, and reinforcement of results through replication of improvements and the procedure itself. Figure 1 below introduces the 5 major steps of the DMAIC method and how they are designed upon the P-D-C-A cycle. We will discuss these steps in detail as you work through this course.

Step 1 Step 2 Step 3

Define Measure Analyze Identify potential root causes Verify root causes with data Plan

Step 4

Improve Develop and pilot

Implement Control Step 5 Quantify improvements Standardize Plan for the future

Do Check

Act

Figure 1: The ets Six Sigma DMAIC Method A Formal Problem Solving Process

Step Overview

Objective:
Define the project's purpose, scope and sponsor, and quantify its significance. The first step in DMAIC, "Define" contains checkpoints that help a team demonstrate the significance of a particular improvement need, with data, and develop a schedule for completing the DMAIC method. DMAIC teams are formed to resolve problems or drive improvement. Logically then, the first step of solving a problem is to begin specifying exactly what the problem is: Who is affected by the problem? How do we know that this situation actually is a problem? At what point will it not be a problem anymore? Once these issues are clarified, the team must establish quantifiable indicators to show where the "gap", or need for improvement, exists. As you may have learned in other ets courses, you cannot effectively improve what you cannot measure. Consider customer satisfaction, since this is usually difficult to accurately measure. Unless you have a scientifically sound manner of gauging your customer improvement, it will be very difficult to tell if you actually improve it. Just because an organization saves money or becomes more profitable does not mean that its customers are satisfied. Gaps must be identified, and improvement needs to be measurable. The Define step helps a team show that a real problem exists and that it is ready to begin building strategy to address this issue. The remainder of the Define step involves laying out this strategy and achieving sponsor approval.

Step Checkpoints
Step Define Checkpoint 1. The stakeholder and need were identified.

2. An indicator measuring our performance in meeting the need was developed. 3. A theme statement consistent with the indicator was selected. 4. A schedule for completing the five DMAIC steps was developed. 5. The sponsor signed off on the projects purpose, scope, and significance.

Step 2: Measure

Objective:
Narrow the project's focus and develop the measurement system, problem statement, and target. Whereas the objective of Step 1 was to quantify the significance of a particular improvement need or theme, the objective of Step 2 is to focus more closely on the theme that you selected and find a specific problem within it to improve. During Step 2 you investigate critical features of the theme and select a specific problem to improve. The theme must be examined, stratified, and analyzed from various viewpoints before your team can discover the significant problem. After a specific, significant problem has been identified, a target for improvement based on the stakeholder's need must be established. You must also qualify the impact of improving your specific problem on the theme indicator in Step 1. A properly defined problem statement is written to further focus the team, and is used to establish measurement systems and to obtain sponsor sign-off. Basically stated, Step 2 forces your team to find a significant, contributing problem to the theme. Once a problem is found, the team focuses on solving that single problem, and thereby improving the theme.

Step Checkpoints Step Measure Checkpoint 6. The theme was stratified from various viewpoints and a significant problem was chosen. 7. A target for improvement was established based on the stakeholders need. 8. The impact of the target on the theme indicator was determined. 9. A problem statement that addressed the gap between the actual and target values was developed.

10. Measurement and data collection systems were developed. 11. The sponsor signed off on the projects focus and target.

Step 3: Analyze

Objective:
Identify and verify the root causes. Step 3 is composed of activities that help illustrate the reasons why a problem statement exists, and walk improvement teams through the process of finding the most significant, or "root causes," of the problem. Just as selecting the most significant problem is critical to efficiently improving the theme, selecting the most significant cause will also generate the most efficient gap reduction. Remember that much of the DMAIC process involves sorting through the "trivial many" to find the "significant few." In addition to finding root causes, the Analyze step also includes some verification Checkpoints to ensure that the suspected root causes have a determinable impact on the problem gap. Analysis of the root causes and their impact on the gap should be performed to a level sufficient to satisfy a reasonable person, no more. Avoid "paralysis by analysis," the state of over-analyzing data when sufficient information has already been given.

Step Checkpoints
Step Analyze Checkpoint 12. Cause and effect analysis was taken to the root level 13. Potential causes most likely to have the greatest impact on the problem were selected. 14. A relationship between the root causes and the problem was verified with data 15. The impact of each root cause on the gap was determined. 16. The sponsor signed off on the verified root causes and impact on the gap.

Step 4: Improve

Objective:
Develop and implement countermeasures to eliminate the verified root causes. In Step 4, "countermeasures" are selected, tested, and evaluated for use in correcting the root causes from Step 3. A countermeasure is a refined idea that you, or your team, feels will reduce or eliminate the cause. Step 4, however, involves much more than just arbitrarily finding a way to "fix" root causes. Countermeasures must generate both short term and long-term improvement on a cause. Countermeasures must not only effectively close the problems gap, but they must also be feasible, efficient, and not cause other problems to occur. Countermeasures must be carefully planned and tested to ensure they have a high likelihood of success. Careful planning involves assessing barriers and aids, scheduling, and a "pilot" implementation that can gather to confirm or refute the countermeasures effectiveness. Finally, an action plan to implement the countermeasures should also consider contingencies and include sufficient detail to answer the questionswho, what, when and how? Although finding a countermeasure for a root cause is the general objective of this Step, ensuring that these solutions actually take place and that they are effective is what you truly must accomplish in Step 4. Verifying success and weighing all of the risks is part of managing with facts and well-informed decision making.

Step Checkpoints Step Improve Checkpoint 17. Countermeasures were selected to address verified root causes. 18. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility. 19. Barriers and aids were determined for countermeasures worth implementing. 20. The action plan reflected accountability and schedule. 21. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement. 22. Incorporated lessons learned from the pilot into the full-scale action plan and implemented it. 23. The sponsor signed off on the action plan and expected results.

Step 5: Control - Results Phase

Objective:
Evaluate the results by confirming that the countermeasures taken impacted the root cause, the problem, and the theme; and that the target has been met. Standardize new methods, communicate lessons learned, and recommend future plans. Step 5 of the DMAIC process is the step in which a team confirms that their improvements were successful, their efforts remain effective, and the theme of the project is completely addressed. This Step can be logically broken down into three major phases: checking results, standardizing results, and developing future plans. By breaking this Step into three phases, ets feels that it provides a better emphasis on the critical activities that a team must accomplish. Let's briefly look at what each of the three major phases of Step 5 entail. We will then begin covering the checkpoints and wrapping up the DMAIC course.

Step 5 Control - Results Phase:


The goal of this phase is to demonstrate, with data, the effects that selected countermeasures had on the stakeholder's need. In other words, your team is expected to show how your countermeasures have affected the root cause, problem gap, and ultimately the theme. Although this Checkpoint immediately follows the Improve Step, a significant amount of time is spent implementing the countermeasures (action plans) before a team progresses to this checkpoint. Clearly a team must first implement their plan and begin to gather data before confirming or refuting the effectiveness of their actions. Once data results have been gathered, an effective way to demonstrate success is by using a series of before and after indicators. First, a team shows comparisons to the root cause analysis and root cause indicators determined in Step 3. Next, a comparison is made to the indicator and target from Step 2, showing initial values and results after countermeasures implementation. If the results were not as expected, these variations should be investigated, understood and addressed. Finally, a comparison to the theme indicator in Step 1 demonstrates the effect of the overall improvement on the stakeholder's need, which in turn demonstrates the success of the DMAIC project. Although this sounds like a good place to stop, is isn't the end. Remember that much of the gains in DMAIC and formal problem solving methodologies come when improvement is maintained and replicated in other areas. The remaining phases and Checkpoints help ensure that gains remain in place and that your organization makes the most of its DMAIC investment.

Step Checkpoints Step Control Results Checkpoint 24. The effect of countermeasures on the root causes was demonstrated. 25. The effect of countermeasures on the problem was demonstrated. 26. The improvement target was achieved and causes of significant variation were addressed. 27. The effect of countermeasures on the theme indicator representing the stakeholder's need was demonstrated.

Step 1: Define - Checkpoint 1


1. The stakeholder and need were identified.
The DMAIC method officially begins by identifying the stakeholder and need. Of course, before DMAIC gets underway you should already have an improvement team established and a team leader identified. The improvement team are the people directly involved in performing DMAIC, while the team leader acts as a coordinator, meeting scheduler, and contact person for the team. To complete this checkpoint, your team must identify the stakeholder for your problem, and establish a quantifiable explanation for what the problem is.

Know Your Stakeholder


Stakeholders are literally people or groups that hold a stake in something. Stakeholders can also be thought of as customers, but the term stakeholder here is more robust. Organizations may (or may not) realize that they serve a variety of internal and external customers. Clearly the family that enters your office to apply for service is your customer, but so is your leadership team, the filing department, and any part of your organization that depends on YOU for goods or services. Just as you are expected to provide quality service to a family, you are also expected to provide quality service to entities within your organization. Both the family that enters your office (external customer) and other work departments (internal customers) are stakeholders they all have a tangible interest in your success. Stakeholders also include people who have an even less apparent stake in your effectiveness. Consider the following examples of less obvious stakeholders: A person who owns stock in a private company is a stakeholder. An American citizen is a stakeholder for any governmental agency. The community at large, and especially needy families, are stakeholders for social service organizations. Although this may seem intuitive, it isn't always easy to define your stakeholder. Because you have formed a DMAIC team to solve a problem, two things are suspected to exist: a stakeholder need, and a measure that is not meeting that need. If your DMAIC project was assigned as an outcome of process management, or strategic process management, your stakeholder and need will most likely be provided to you. If the stakeholder(s) for your improvement need are not already defined, obtain consensus with your team regarding who your stakeholder is that has a problem or improvement need. This agreement ensures that your team keeps the proper perspective for fixing the problem: the perspective of the stakeholder and how this problem affects them.

Click On A Topic Below To Learn

More About: Consensus - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps
Once you have determined the stakeholder(s), write them down.

Know Your Need


An improvement need is the measurable effect that is undesirable to your stakeholder. Your improvement need should explain some negative, measurable effect on your stakeholder, and explain why this effect is considered negative (if it isn't obvious). The following table lists some example "needs."

Documents must be delivered in 4 working days or less, otherwise they become invalid. Minor workplace accidents are higher than the required target of 3 per year. Customer wait times are too long. Information provided on customer forms is incorrect or incomplete.

Improvement needs can come from many places. Some are obvious, such as extreme dissatisfaction, disasters, accidents, or poorly performing indicators. Other improvement needs aren't so clear, or may be misunderstood. For example, "valve release pressures are in excess of 250 psi" is a valid need but it probably wouldn't make much sense to someone who did not work with valves. A better need would be "valve release pressures are in excess of 250 psi, which can result in damaged equipment." An improvement need, much like a stakeholder, may already be provided for your team. In this case, the Define step will move quickly. On the other hand, some DMAIC teams are established simply to "improve" their overall organization. In this latter case, your team may need to brainstorm an area for improvement and gather some tangible data to prove that a need exists. Providing data for your improvement need is important for two reasons. First, gathering data requires you to create an improvement need that is measurable. Second, data provides credibility to your claim. It is a weak argument to arbitrarily claim that something is bad. A much stronger argument explains why something is bad, and provides data to prove that it is bad, and show how bad it is. Data to demonstrate improvement needs can come from many sources, including:

External or internal client surveys, reports or discussions. Department or organizational-level CFO or "M" indicators. (See Process Management for an explanation of M indicators.) Management requests. Information and ideas from individuals.

This checkpoint is completed when you have clearly documented who the stakeholder is, what the measurable need for improvement is, and why improvement is important to this particular stakeholder. Examples:

The processing time for teacher applications is taking more then 14 days. Teachers are adversely affected by this problem because these certifications are required for them to work in our state. Pizzas are not being delivered to our customers in 30 minutes or less. Our customers demand delivery in 30 minutes, or they become dissatisfied with our product.

The following analytical and decision making tools may prove helpful in this Step:

Control Charts Process Flow Charts Survey/Interview Brainstorming Consensus

We'll briefly show how process flowcharts and surveys can be used to determine improvement needs on the next few pages.

Step 1: Define - Checkpoint 2

2. An indicator measuring our performance in meeting the need was developed.


"Indicators" are metrics (or standards of measurements) that measure the outcomes of a process. Much like a speedometer tells you how fast you are going and if you are breaking the speed limit, an indicator is a gauge of process performance that tells you how well a process is performing and if its performance passes an acceptable limit. In the case of DMAIC, indicators are used to provide measurement of your improvement need. Remember that improvement needs must be quantifiable, or "measurable." An indicator provides a graphic way of showing how great an improvement need is, and how much better (or worse) an improvement need becomes over time.

If it helps, you can think of your Checkpoint 2 indicator as the overall "gauge" for determining how well your DMAIC project is working.

Reading Indicators
Indicators and their many forms are discussed in depth throughout Process Management. Rather than repeat an entire discussion on indicators, let's simply refresh our memory on how to read indicators. Line graphs, such as the one shown in Figure 1, are often used to display indicators.

Figure 1: A Quality Indicator As you can see from the figure above, indicator line graphs have a good arrow indicating the desired direction of line graph movement and a target indicating the desired direction or customer valid requirement. The good arrow shows the direction that the indicator "should move" for good results. For example, if you are looking at an indicator that shows "number of errors," clearly fewer errors are better and therefore the good arrow would point downward. Indicators with upward pointing good arrows might include "customer satisfaction rating," "% complete applications," etc. When the indicator moves in the direction of the "good" arrow, your DMAIC story is succeeding. The target line, or bar in some cases, shows the acceptable limit of the indicator or the goal that your indicator is trying to achieve. Targets can be constant or they can change over time. We'll see how targets are set for improvement need indicators later in this course. For now, the important point to remember about targets is that they denote the "goal" of the indicator. The line graph should move toward the target in the direction of the good arrow, or remain past the target in the direction that the good arrow points.

Selecting DMAIC "Improvement Need" Indicators


An (improvement need) indicator should graphically demonstrate the stakeholder's measured need and our need to improve. When selecting an indicator, choose one that accurately depicts your improvement need using data. Accurate measurement of indicator data is critical.

Inaccuracy at this stage in your DMAIC project can result in a large amount of error, potentially enough to cause your project to make invalid decisions.

This checkpoint is completed when you have defined an indicator that measures your need to improve, and you have shown data on the indicator that demonstrates the need to improve exists. Notice how both examples in Figure 2 below show a need to improve (the title of the graph) and measured evidence that the need is not being met (the data is not meeting the target). Examples:

Figure 2: Example "Improvement Need" Indicators Ideally, as you progress through your DMAIC project, you will see this indicator move in the "good" direction. The following analytical and decision-making tools may prove helpful in this Step:

Line Graphs Bar Charts Pie Charts Object / Defect Technique

Let's take a moment to explore a few ways in which indicators can be established using the analytical and decision-making tools listed above.

Step 1: Checkpoint 3

3. A theme statement consistent with the indicator was selected.


A theme statement tells specifically what your DMAIC project is attempting to do. In practice, theme statements serve as the "title" of a DMAIC project, and should be clear and concise. A theme statement tells the team exactly what they are trying to accomplish in terms of their indicator. The stakeholder and need to improve help you identify the indicator. Once this indicator is found, you now have a quantifiable problem. The theme statement tells what your team will be improving in terms of your indicator.

Click On A Topic Below To Learn More About: Theme Selection Matrix - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Templates (actual templates can be downloaded in Appendix 2 - Theme Selection Matrix)
Theme statements tell what your team is going to do by referring to the exact problem shown on your indicator. This may be confusing, so let's clarify this subtle difference using an example: If your need to improve is: Supply deliveries are arriving late. And your indicator is: % deliveries arriving late Then a good theme statement would be: "Reduce the % of deliveries arriving late."

Notice that the theme statement above says what the team is going to do. As you can see, the need to improve, indicator, and theme statement are all closely related. There should always be a clear linkage between the theme statement and the indicator established in Checkpoint 2. This checkpoint is completed when you have clearly documented your project's theme statement. The theme statement tells what your team is going to do in terms of your improvement need indicator.

Examples:

Reduce the number of employees who choose to not take part in the 401k program. Increase the percentage of children passing their Math FCAT.

The following analytical and decision making tools may prove helpful in this Step:

Theme Selection Matrix Brainstorming Consensus

Note that some of the tools and techniques listed above are used to select between multiple themes. It is not uncommon for problem solving teams to be faced with many problems, and in such cases prioritization must take place. Remember that it is important to make decisions based on fact, not intuition. Rely on the expertise of your team and the data presented to guide your team's selection when decisions must be made.

Step 1: Define - Checkpoint 4


4. A schedule for completing the five DMAIC steps was developed.
A schedule represents a commitment by the team, management, and the project's sponsor to achieve their theme within a specified period of time. To successfully meet this objective, team members must meet regularly and management must support the team. As you have learned in these courses, and probably in your daily life, things tend to remain unfinished when people are not held accountable for their completion. This is simply human nature. The Project Planning Worksheet is a standard tool for managing a DMAIC improvement project. Although most fields of the worksheet shown in Figure 1 are self-explanatory, you can find a step-by-step guide to creating project-planning worksheets in the ets course Decision Making Tools. The top section of the form provides basic information about the team and its purpose.

The middle section of the form is where meetings can be scheduled up-front, and then documented after the fact. The bottom section is a Gantt chart where long term schedules for completing each step of the DMAIC process are projected, and documented.

Figure 1: A Project Planning Worksheet

Click On A Topic Below To Learn More About: Project Planning Worksheet - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Template

This checkpoint is completed when you have created a project planning worksheet for your DMAIC project that includes team information, project information, a (tentative) meeting schedule, and a proposed schedule for performing each DMAIC step. Example:

The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet

Step 1: Define - Checkpoint 5

5. The sponsor signed off on the project's purpose, scope, and significance.
The sponsor of a DMAIC project is usually the person directly or indirectly responsible for forming the team. Often times a team's sponsor is someone in management who has a vested interested in fixing the problem that a DMAIC team is formed to address. As a result, a sponsor has a logical accountability for the team's success. The sponsor's review, input, and feedback are critical to ensure steady progress since the sponsor typically has a deep understanding of the purpose and impact of the DMAIC project, and they are attuned to timetables and deadlines throughout the process. Sponsors have key roles in assuring the success of DMAIC teams. One of their responsibilities is to sign off on a DMAIC project's purpose, scope and significance. Although this step is usually a formality, it ensures that a DMAIC team has a solid understanding of their own project, and that they have not veered off onto a potentially unsuccessful path. As we have mentioned previously, one of the most common mistakes that DMAIC team's make is to embrace too broad of a focus. Project planning worksheets are the established tools that are used for obtaining sponsor "sign off" on a DMAIC project. A project planning worksheet is an excellent summary of the team's purpose, scope, and estimated effort. Using this single page, a sponsor can review a detailed summary of the team's plans that include their theme, team composition, and schedule for completion. Sponsor reviews pay special attention to schedules. A schedule represents a commitment by both the team, management, and the sponsor to improve performance within a specified period of time. To meet this objective, the team members must meet regularly, and management must support the team. A DMAIC team sponsor should carefully scrutinize a team's schedule to ensure it achieves their goals in a timely manner, but it is also realistic and feasible for all the team members involved. Project planning worksheets can also be used to develop schedules.

This checkpoint is completed when you have obtained approval from the project's sponsor. Sponsor approval can be noted on the project planning worksheet. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet Tollgate Review

The next section will introduce the tollgate review and how it can be applied for this checkpoint.

Step 2: Measure - Checkpoint 6

6. The theme was stratified from various viewpoints and a significant problem was chosen.
Once the theme has been selected, a significant problem that contributes to the existence of the theme must be found. To find problems that contribute to the theme, a team must analyze the theme from four different perspectives: what, where, when, and who.

What
"What" deals with categories of the problem data such as type, complexity, amount, reason, category, severity, etc. The team should stratify the problem data by several "what" categories.

Where
"Where" deals with the location of the theme (or problem). The problem data should be stratified from different "where" perspectives such as "geographic location" like city, county, and state, as well as by "place" (e.g. in office, stairs, etc.).

When
"When" deals with calendar time, duration time, or "when in the process". Data for a team's processes can be stratified by calendar time (day of the week, time of day, month, etc.), or by duration (number of days, number of minutes, etc.), or by process step.

Who
"Who" is the final perspective to consider when stratifying problem data. "Who" deals with specific information concerning the customer, process player or supplier. Typical "who" stratifications are age, gender, position, etc. Your goal is to determine a single problem that will have a positive impact on your theme. As you learned in Pareto analysis, most of the theme is usually caused by only one or two problems. Your goal is to find these "high value" problems, since they typically provide the most improvement for the least amount of effort. If some of your potential problems require expertise in an area not currently represented in your group, consider adding or trading a team member for someone with the proper experience. It is recommended that the team's composition be reviewed regularly to ensure the appropriate skill and organizational mix. Also, don't forget to rely on analytical or decision-making tools to help your team reduce the list of potential problems to an actionable size.

This checkpoint is complete when a single problem, which is believed to have a significant impact on the theme, is determined. Your team should look at the theme from four (or more) viewpoints to search for potential problems. When problems are found, your team should use decision-making tools (or experience, in some cases) to select the most actionable problem. Examples:

Theme: Too many employee absences are causing customer shipments to be missed. Problem: Last quarter, 47% of all employee absences were related to lost time injuries.

Theme: Accounting has an increasing error rate in overtime calculations, causing billing department rework. Problem: Antiquated computer system crashes during work and causes files to be saved with corrupt data.

The following analytical and decision-making tools may prove helpful in this Step:

Bar Chart Line Graph Pie Chart Checksheet Pareto Chart Histogram Control Chart

Let's look at how analytical tools and the four perspectives shown above can be used to explore a theme and stratify problems.

Step 2: Measure - Checkpoint 7

7. A target for improvement was established based on the stakeholder's need.


The stakeholder referred to here is the same as in Step 1, Checkpoint #1. Targets should be determined by questioning the stakeholder, if possible, or management, rather than by assumption. As in any translation of stakeholder needs and wants to measurable terms, "WinWin" oriented negotiation may be necessary. Data must be present to show what the customer wants. Targets may also be established through benchmarking or competitive knowledge.

The following Target Setting Methodologies should be utilized:


Customer Valid Requirements Benchmarking (internal or external) Historical Trends (best previous performance or expected future performance) What the data will allow (estimated number of defects or waste seen in the data under review - also, what resources are available to apply) Management Wisdom (management often sets more aggressive targets to challenge staff) 50% improvement - can be used when no other methodology can be readily or easily applied)

The following tools and techniques may prove helpful in this process:

Target Setting Workshop Form Critical to Quality (CTQ) Tree

The Target Setting Workshop Form and Critical to Quality Tree are discussed further on the following pages. Targets are goals that are set indicators. When a person reviews an indicator graph, they should be able to compare performance against the target and quickly tell how the indicator is performing. Although a tremendous amount of focus and complexity has been placed on target setting through the recent "Six-Sigma" movement, effective targets do not require complex math or statistics to establish. Targets should be created using the most appropriate "common sense" logic or methodology. In many cases, indicators will have logical targets that arise out of customer requirements, law, or business mandates. In other cases, analysis and consensus may be required to determine a valid target. However a target is set, you must establish a target so that each indicator has a clear point of reference for indicator performance. Without a point of reference, it can be difficult to tell if an indicator is improving (especially on cumulative indicator charts).

Target Setting Methodologies


Targets are not always static values. In fact, targets are often revised over time as better methodologies or more accurate data becomes available. Targets may also be adjusted when industry standards, laws, or competitor standards increase. Because targets may be revised at a later date, teams should not waste a lot of time establishing initial targets. Set targets using one of the methods below and keep progressing? The data collection process will be the same regardless of target levels. Adjusting a target later is a simple process. The following techniques can be used to develop targets for your indicators. Use whichever technique makes the most sense in your situation.

Customer Valid Requirements (CVRs)

Targets may be set based on CVRs when a logical target exists. For example, if one of your customers requires that you return calls in 2 hours or less, then clearly you have a target somewhere at or below two hours. Make sure you have a clear understanding of CVR values if you use this method. Refer to the customer needs information in Process Management for a review of this concepts, if needed.

Benchmarking
Benchmarking is the process of setting targets based on competitor, or best in class/division/organization performance. Often times similar organizations track similar indicators, for example, overall customer satisfaction. If you can determine a competitor's level of performance in an indicator, then you can use this level as a target. In addition to competitor performance, benchmarks can also be based on high performance or successful organizations in unrelated fields. Finally, benchmarks can be developed using internal organization performance between offices, divisions, etc. This is useful when your indicators are unique, or competitor data is not available. Do you recall reading that organizations with similar departments should strive to use similar indicators? Here is another reason why an organization can analyze indicator performance across departments and use the best performing department as a benchmark target for the others.

Historical Trends
When competitor data or benchmarks are not available, historical trends can be used to set targets. Indicators can be reviewed to determine the best performance levels they have achieved. This historical performance trend is then used as a target. For example, if a department performs data entry and their best ever entry rate was 5,137 documents per day, setting a target to this value is an excellent start.

"What The Data Will Allow"


In some organizations, such as manufacturing or healthcare, targets are set by resource limitations or the environment. For example, consider a manufacturing process that requires 90 units of material and has 100 units of material available. If "Average Resource Units Wasted In Production" was an indicator, then a good target would be less than 10. Do you see why? 100 Total Resources - 90 To Build A Unit = 10 Units Extra If this organization wasted more than 10 units on average (due to bad cuts, human error, etc.) than they would clearly impact the production process they would run out of resources! Also, "what the data will allow" refers to the data remaining from a problem stratification such as a Pareto Chart. If 100% of the defects were stratified resulting in 60 defects associated with type A defects, then the target would have to be adjusted downward 60% to equal "what the data would allow".

Management Wisdom
Although often controversial, management mandates may be used to set targets for indicators. In many cases these targets will be aggressive to inspire performance or to encourage employees to "rise to the challenge." As idealistic as this approach may seem, management wisdom can be an effective target setting technique when properly applied. For example, management could make the case that they need certain targets to be met to avoid resorting to layoffs, or to achieve enough reserves to offer employee bonuses. If targets are based on management wisdom, it is usually helpful to explain the logic of these targets via communication to the process owners to establish "buy-in."

Law (also considered a Customer Valid Requirement)


These are targets mandated by state, federal, or any other law, plain and simple. If a law states that workers compensation claims must be processed in four weeks, then a target should be set LESS than four weeks with enough time built in for unforeseen problems and difficulty. Don't be afraid to set targets above minimum standards!

50% Improvement
One of the fundamental truths of industrial engineering is that organizations have an inherently high amount of "waste" in processes. This does not mean that an organization is poorly run, or even unprofitable. It DOES means that every organization has the opportunity to significant improve process performance. If no clear targets can be determined, look at the most recent indicator values and set a target for 50% above that value (multiply the current indicator value by 1.5). For example, if your latest "Hours Of Training" indicator value was 137, then a 50% improvement target would be 137 X 1.5 = 205.5.

Document The Targets


Once a target is established, don't forget to document the value of the target and the formula / rationale for the targets value! A good place to keep this information is on the Process Control System (PCS, will be discussed shortly) or the indicator graph, or an indicator documentation form (shown

Step 2: Measure - Checkpoint 8

8. The impact of the target on the theme indicator was determined.


This simple checkpoint ensures the logical flow of information, or linkage, exists between Steps 1 and 2 of the DMAIC process. Although the process of selecting targets is directly linked to the overall improvement theme, it is possible for team's to lose focus on the theme or expand the scope of their project beyond its original intent. Verifying that the target does indeed effect the theme is a "sanity check" that helps prevent missteps by the team during the DMAIC project. To demonstrate a link between the target and the improvement theme, ask yourself if the target's outcomes can be explained scientifically (benchmarks, customer contact, tools such as histograms, scatter diagrams, checksheets, graphs, or charts). For example, how can you prove that reducing the "caller on hold rate" to our target of 15 seconds will increase overall customer satisfaction? A statement must be made to indicate the impact that meeting the target will have on the theme indicator, and any supporting data or validation information should also be included. Basically, your team must ensure that any logical person could review your selection of targets and clearly understand why these particular targets have a quantifiable effect on the theme.

This checkpoint is complete when some sort of documentation is provided that shows a clear, logical reason why achieving your proposed targets will have a positive effect on the improvement theme. Documentation should be easy for someone to follow or verify, if needed. Examples:

Theme: Too many employee absences are causing customer shipments to be missed. Target: Employees should be absent less than 10 days per year. Impact: Studies have shown that shipments fall behind due primarily to excessive employee absences when their number of missed days is greater than 10 per year.

Theme: Accounting has an increasing error rate in overtime calculations, causing billing department rework. Target: 1% or less error rate in overtime request / approval forms. Impact: Data has shown that incorrectly completed overtime request / approval forms account for over 92% of the error in overtime calculations. By meeting our target, 92% of the overtime calculations will be reduced, thereby improving our theme significantly.

Although it is not done in the example above, you should consider providing references to supporting data when they are available. For example, what "data" has shown that incorrectly completed forms account for over 92% of the errors? The following analytical and decision-making tools may prove helpful in this Step:

Bar Chart Line Graph Pie Chart Checksheet Pareto Chart Histogram Control Chart Survey / Interview Scatter Diagram

Step 2: Measure - Checkpoint 9

9. A problem statement that addressed the gap between the actual and target values was developed.
In Checkpoint 6, you selected a significant problem that related to the theme. This problem was selected because it had a verifiable impact on the overall theme, and was not meeting an acceptable target level of performance. The problem statement summarizes all of these points in a single, concise statement. Whereas your problem simply states something that is wrong, the problem statement tells you what is wrong AND how severe its shortcomings are. For example, one of our example problems from Checkpoint 6 in this Step was "Last quarter, 47% of all employee absences were related to lost time injuries." A problem statement for this would include information that explains the measured shortfall, or "gap," that this indicator suffers from. The statement: "Employee absences are too high due to lost time injuries averaging 27 days per quarter, or 25 days higher than our target of 2" clearly states not only the significant problem, but also tells a reader that a 25 injury gap exists between current performance and their target of 2 lost time injuries per quarter. The problem statement should answer the questions; who, when, where, what is the gap, and why does this need to be improved? The need for improvement can be effectively demonstrated with reference to the theme, or with supplemental CTQ indicators that measure attributes such as quality, cost, or timeliness. The answer to the question "why does this gap exist"? will be addressed in Step 3 of the ets Six-sigma DMAIC Method.

This checkpoint is complete when a problem statement has been documented. The problem statement must identify the gap, and should answer the questions of who is affected by the gap, when does the gap occur, where is the gap occurring, and why we need to fix this gap. Examples:

Problem: Last year, 27% of serviceable families did not receive help because their addresses were entered into the database incorrectly. Problem Statement: Last year, 27% of serviceable families did not receive help they need to support their families because their address was entered incorrectly. Address entry errors averaged 18% last year, which is much higher than our target of 3%-- a 15% gap.

Problem: School form submission is too low because many schools do not know they needed to re-submit their forms. Problem Statement: School form submission is too low because our target of 100% "need to re-submit" awareness was not met. Current data shows that only 56% of schools are aware of the resubmit need, leaving a 44% improvement gap, and causing a delay in funding approval.

The following analytical and decision-making tools may prove helpful in this Step:

CTQ Tree Problem Statement Object/Defect Analysis

Step 2: Measure - Checkpoint 10

10. Measurement and data collection systems were developed.


In checkpoint 7, you established a set of customer requirements that are measured to assess your ability to meet the customers' needs. You also have indicators that must be tracked, and gaps that you will be working to reduce. For anything to be measured, a method of gathering data must be established. This checkpoint deals with the formal methods for gathering meaningful data.

Data Collection
Data collection is the process of collecting the right data for measurements in a useful and meaningful format. Like many aspects of improvement, a formal data collection method helps ensure consistency and communication among all of those involved. It also exposes team members to process interfaces and may provide clues as to how process problems can be resolved. The formal data collection procedure is performed in five steps: 1. 1. 2. 3. 4. 5. Define your data collection goals. Develop rules and procedures for the data collection. Validate your measurements. Collect data. Continually improve measurement accuracy.

Each step is discussed briefly below. Like many of the formalized process presented in ets courses, your organization may or may not require such a high level of structure. For example, you team may already have some of your CVR data readily available in a consistent format. In cases such as these, don't spend a lot of time on formal data collection. Remember that the goal of process management is to better serve process customers, not necessarily fill out every form in the course. Avoid "paralysis by analysis!" If a step seems trivial or an answer already exists, keep moving. Don't get bogged down.

Step 1: Define your data collection goals.


Simply stated, make sure that the data you propose to collect will satisfy your measurement requirements. If there are special measurement requirements, patterns, or grouping that is required for usable data, make certain that these issues are clear before progressing.

Step 2: Develop rules and procedures for the data collection.


How will the data be collected? What instruments will be used, and what units will these measurements be reported in? Will your data be a sample or a census? All of these questions must be answered before progressing. You must ensure that the data you collect will be done so in a regular fashion, and a consistent format.

Step 3: Validate your measurements.


Make sure that your measurements remain consistent, don't assume it. Although there are many complex and mathematical methods for determining variation in measurements, most measurement validation can be done my a simple "common sense" check. For example, have two separate people measure your data and see if they get the same values. Check previous values against current ones using a line graph. If you notice any highly unusual trends or variation, you may need to perform further analytical analysis. They key point to remember about this step is: "make sure your measurements are good."

Step 4: Collect data.


Begin the logistical process of collecting data. Ensure that people are accountable for data collection and that they understand the frequency, format, and destination for any data they collect.

Step 5: Continually improve measurement accuracy.


Try to make data collection as accurate and painless as possible. CVR measurements are on going. This means that you will continue to collect your data indefinitely! For this reason, it is important that you keep the data collection process simple and efficient. Try and find ways to continually improve the accuracy and reduce the effort required to collect measurement data. Technology often provides innovative and cost effective solutions for producing low-cost, high quality data.

Data Collection Plan Worksheet


A worksheet has been provided to help your team construct a well thought-out data collection plan. Two versions of this worksheet are included in the template: a general format and a "Voice of the Customer" (VOC) format. The general format will work for all data collection plans, while the VOC format is designed to help you gather data on customer opinion or satisfaction with your process.

Figure 1: Data Collection Plan Worksheet

Data Collection Plan Worksheet

Remember! The important outcome of this checkpoint is to establish a well-defined method for collecting data. Whether this is done using the included worksheets, an internal action plan, or another method is not important.

This checkpoint is complete when you have a documented plan for collecting all data that is relevant to your project, and one that effectively assigns accountability for each collection task. Exactly how you ensure that data is gathered will vary drastically, since some organizations already have a large amount of data readily available. The key point here is to not assume that "data will collect itself"-- it never does, and when it tries it usually does a lousy job.

Step 2: Measure - Checkpoint 11

11. The sponsor signed off on the project's focus and target.
Continual sponsor involvement, and regular updates to leadership, are important for DMAIC team success. Just as you did in Checkpoint 5, your team should once again provide a summary document (story / story board / etc) to your team sponsor and schedule a brief meeting so that they can be brought up to speed on your Step 2 progress. The focus of the sponsor's review here, in addition to general effectiveness, will be to ensure that the project's focus remains tightly aligned to the theme and that the targets selected are both reasonable and appropriate. There is a tendency is some cases for teams to set targets needlessly high (and earn the contempt of their co-workers). There are also teams that have been known to set very low targets, as to ensure that their workload does not become much heavier. The correct setting for a target is the one that drives improvement in the theme to an acceptable level. It is often helpful to have a third part, such as your sponsor, review the target setting methodology and ensure that all target values were wisely selected.

This checkpoint is completed when you have obtained approval from the project's sponsor on the project's focus and target. Sponsor approval can be noted on the project planning worksheet. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet

Tollgate Review

Step 3: Analyze - Checkpoint 12

12. Cause and effect analysis was taken to the root level.
The purpose of this Checkpoint is to use cause and effect analysis to find the most likely root causes of the problem. Once your team has determined which causes are most likely to be the predominant causes of the gap, your team will spend the remainder of this step validating your root causes and ensuring that they are indeed legitimate. Cause and effect analysis requires that sufficient knowledge concerning the problem is collected. Although some problems can be rapidly taken to a root cause level, other problems may be beyond the team's realm of expertise. In these cases, you may require subject matter experts or people from other departments to provide input during the cause and effect process. At the very least, it is a good idea to pick up the phone or send off an e-mail to a colleague that can corroborate your deductions. No matter which cause and effect analysis technique is used (i.e. Fishbone Diagram), thorough brainstorming, topic expertise, and asking "why" numerous times are critical factors in helping your team get to the root level of a problem. Don't underestimate the importance of any step in the DMAIC process.

This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap.

Click On A Topic Below To Learn More About: Cause And Effect Diagrams - What Is It? - Why Is It Important?

- How Is It Used? - Process Overview - Detailed Process Steps - Example - Templates (actual templates can be downloaded in Appendix 1 - Cause and Effect Diagrams)
Example:

Figure 1: A Typical Root Cause Analysis Using the Fishbone diagram in Figure 1, a team consulted with experts in "front-end fraud" and developed the cause and effect analysis that is shown. Based on their findings, the team

felt that certain factors were likely root causes and they drew yellow clouds around these issues. Notice that although there are five clouds, three of these probable root causes are actually one cause: "Representative not fully trained." The list of potential root causes that 1. 1. Goal setting methodology was invalid. 2. Reporting policy is inconsistent. 3. Representative not fully trained on referrals. This list will serve as the input for Checkpoint 13. The following analytical and decision-making tools may prove helpful in this Step:

Cause and Effect Diagram Scatter Diagram Design of Experiments Hypothesis Testing Failure Mode and Effects Analysis (FMEA) Single Case Bore Analysis Pareto Chart Delphi Technique

Tip: By asking why five times, most issues are taken to the root level. Keep asking why until you reach an obvious, or existing cause. In the prerequisite ets Analytical Tools course, you were introduced to the Fishbone diagram used above. The next page introduces another commonly used cause and effect analysis technique called "Single Case Bore Analysis."

Step 3: Analyze - Checkpoint 13

13. Potential causes most likely to have the greatest impact on the problem were selected.
This straightforward Checkpoint is used to reduce the list of probable root causes from the previous step into a more manageable, and smaller, list of "most likely" root causes. Your goal is to reduce a large list of possible root causes into those few that your team feels are the most significant, and are worthy of verifying. List reduction ("filtering") techniques, such as the multivoting and consensus, can help your team select the "most likely" root causes. You may also want to consult with subject

matter experts to ensure your list of root causes make sense to someone with experience in your problem area. This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap.

This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap. Example: The list of potential root causes from the previous Checkpoint example were determined to be: 1. 1. Goal setting methodology was invalid. 2. Reporting policy is inconsistent. 3. Representative not fully trained on referrals. These selections were then narrowed down by the team using multivoting. They decided that "Representative not fully trained on referrals" made the most sense to continue investigating, since it was easy to verify and appeared multiple times in the cause and effect analysis.

Multivoting Consensus

Step 3: Checkpoint 14

14. A relationship between the root causes and the problem was verified with data.
Once a root cause has been selected, a team must confirm that their selection does in fact have a verifiable impact on the problem. Remember that the root cause that was selected in Checkpoint 13 was done so using the opinion and expertise of the group. To ensure that the

group made a sound decision, your team must use data to show that the root cause you have selected has had, or will have, an effect on the problem statement gap. In some cases, the link between the root cause and the gap is intuitive. For example, if the problem statement is that "27 reports are processed incorrectly due to spelling errors," then a potential root cause such as "Representative not trained on how to user spell-check" may be easy to identify. In these simple cases, a brief explanation or a potential of the cause and effect analysis will suffice as documentation. Unproven, suspected, or complex linkages may require in-depth explanations, examples, or even investigation. Don't assume that a root cause is valid unless you have data to substantiate your claim. Some data gathering and analysis may be required to confirm or disprove your selected root cause. If the root cause is shown to be invalid, or if the root cause has questionable impact, your team should return to Checkpoint 13 and select a different root cause to pursue. There are a series of analytical tools that help in determine if relationships exist between two data sets. These tools include scatter diagrams, Pareto charts, and the Chi-Squared test. However your data is displayed or analyzed, your checkpoint outcome should be convincing enough to satisfy a reasonable person that improving this root cause will reduce the problem gap. You should perform enough research to confirm that your probable root cause appears valid, but don't go overboard research and data gathering can consume a significant amount of time.

This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap. Example: Figure 1 below shows a scatter diagram which was created to determine if a suspected root cause "students have too few hours spent studying" has a verifiable impact on the problem statement gap "132 students did not receive an 80% score or higher on their test." The x-axis on the chart represents the potential root cause (too few hours spent studying) and the y-axis shows the gap (test scores are too low). As you may recall, scatter diagrams will show a linear correlation when a relationship exists between the dependent and independent data set. In this case, the points do appear to cluster around a line, which indicates that there is most likely a positive correlation between hours studying and test scores.

Figure 1: Using A Scatter Diagram To Confirm A Root Cause - Gap Relationship Based of the data shown in Figure 1, the root cause of hours studying has an effect on the gap. This level of proof is enough to convince a team that further pursuing this root cause will most likely help reduce the gap. The following analytical and decision-making tools may prove helpful in this Step:

Cause and Effect Diagram Scatter Diagram Chi-Squared Test Pareto Chart

Creating a Pareto chart by causes, or a Scatter Diagram, can be particularly useful in verifying a root cause. After the cause and effect analysis, data is often readily available to be collected and listed, by causes, on a Pareto chart. A series of Pareto charts that show a correlation between the size of your probable root cause bar and the problem gap is an easy way of showing that a linkage exists between cause and gap. The scatter diagram is more precise and can enable us to determine with varying degrees of confidence (linear correlation coefficient), that a cause and effect relationship exists between variables and how correlated this relationship is. A contingency table (or a chi-squared test) is a more cumbersome, but equally effective solution for verifying cause and effect relationships using discrete data. There are still other more complex statistical tools to assist in verifying root causes. Those higher-level tools are not presented in this section.

Step 3: Analyze - Checkpoint 15

15. The impact of each root cause on the gap was determined.
When multiple root causes are verified, it becomes important to know which root causes will have the most dramatic effect on the gap. In the previous Checkpoint you determined that a relationship existed between a root cause and the problem gap. Your task in this step is to determine how much impact each root cause has on the gap, and what kind of results can be expected for an amount of improvement. For example, if your gap is "253 customer satisfaction scores below target of 95%," and one of your root causes is "time spent waiting for service," your team should try to estimate how much change will occur in the gap if the time spend waiting for service was reduced by 10%, 25%, 50%, 100%, etc. By estimating these values, your team can begin to approximate how much correction of the root cause will be required to eliminate the gap. Depending on what data is available to you, you may need to conduct some brief experiments to gather the data needed for making these types of estimates.

This checkpoint is complete when you have determined an estimated impact amount that each root cause has on the problem gap. For each root cause that was validated in Checkpoint 14, your team should be able to generally determine how much effect on the gap a certain level of root cause reduction will have. Example: Scatter diagrams, especially those that are created in Microsoft Excel or a similar graphing program, provide a quick and easy solution to determining root cause impact on the gap. Notice the linear trend line, denoted in red, on the scatter diagram below. As you may recall from learning about these charts, the trend line represents the mathematical "best approximation" of the relationship between the x and y values. By using this line, your team can easily establish a series of impact values. Simply select a value on the x-axis and follow it upwards to where it intercepts the red trend line. The y-axis value at which this intercept occurs is the average result you can expect, based on the data you have seen thus far. For example, for 5 hours in remedial study, we see that the trend line intersects the y-value of 20. For every 20 hours of remedial studying, student test scores average about 35. For every 25 hours of studying, test scores approach 80. Using this information, a team can determine how much change in student study time is required to eliminate the gap between current test scores and desired test scores. For the more mathematically inclined, the actual cost of improvement can be determined by calculating the slope of the trend line. Going back to high school algebra, the slope of the line

is equal to the change in rise divided by the change in run. An easy way to calculate this is to select two clear data points: (5,20) and (25,80). Find the difference in the y values (80 - 20) and divide that by the difference in the x values (25 - 5). (80 - 20) / (25 -5) = 60 / 20 = 3 Therefore the slope of the line is three. This means that for every 1-point increase in x, we can expect about a 3-point increase in y. In more applicable language, "for ever hour spent studying, we can expect a 3% increase in students' average test scores."

Click On A Topic Below To Learn More About: Scatter Diagrams - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Example - Templates (actual templates can be downloaded in Appendix 1 - Scatter Diagrams)

Figure 1: Using A Scatter Diagram To Confirm A Root Cause - Gap Relationship If absolute accuracy is important, you may use Excel to perform a linear or polynomial regression analysis. This will provide you with a numerical equation for your line that can be used to calculate the exact slope, or outcome result for any x value. This type of calculation can be performed with a determinable degree of accuracy, but a complete discussion on this topic is beyond the scope of this course. It is mentioned here simply for awareness. The following analytical and decision-making tools may prove helpful in this Step:

Cause and Effect Diagram Scatter Diagram Single Case Bore Analysis Pareto Chart

Step 3: Analyze - Checkpoint 16

16. The sponsor signed off on the verified root causes and impact on the gap.
A tollgate review or project status update meeting with the sponsor is key to maintaining management support, enthusiasm, and commitment to the project. These meetings provide

your team with a more objective perspective regarding the outcomes of your most recent DMAIC step. In this Checkpoint, the team sponsor should verify that the logic and procedures for selecting the team's root causes are sound. The sponsor should ensure that the cause and effect analysis is thorough, based on data, and that a clear and demonstrated linkage exists between the causes and the gap.

This checkpoint is completed when you have obtained approval from the project's sponsor on the project's verified root causes. Additionally, teams must demonstrate to their sponsor that they understand the linkage between root causes and the gap, and that impact on the gap can be estimated. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet Tollgate Review

Step 4: Analyze - Checkpoint 17

17. Countermeasures were selected to address verified root causes.


In the context of organizational improvement, a "countermeasure" is an idea that a team believes will reduce or eliminate root causes. A countermeasure does not explicitly tell "how" an idea will be implemented. Rather, a countermeasure is a possible root cause solution that must be evaluated and refined before a team can determine if it is a good course of action or not. Countermeasures can come from informal discussion, brainstorming, reviewing best practices from other organizations, relying on staff expertise, or any other helpful resource.

Click On A Topic Below To Learn More About: Brainstorming - What Is It? - Why Is It Important?

- How Is It Used? - Process Overview - Detailed Process Steps

You can think of countermeasures as ideas that an organization uses to eliminate the root cause of a problem. For example, if the root cause of a problem is that "the office is too cold," then a logical countermeasure would be to make the office warmer. Notice that this countermeasure says nothing about "how" this goal will be achieved. "Making the office warmer" is simply an idea that seems to logically eliminate the root cause. Another countermeasure might be to "buy another office." Which of these two choices sounds more feasible? Why? Clearly, all countermeasures are not created equal. Factors such as time, cost, and available resources can affect how feasible any countermeasure might be. The goal of Checkpoint 17 is to not simply find any countermeasures that might work, but to find the best countermeasures that consider all of the factors critical to success. This is achieved by evaluating and refining the countermeasures into a list of those that the group believes to be the best choices. An effective method for performing this evaluation process is to use a countermeasures matrix. The countermeasures matrix was introduced in the ets Decision Making Tools course. We will begin creating a countermeasures matrix in this step, and finish the matrix in the next Checkpoint by adding "practical methods" and evaluating the countermeasures. Figure 1 below shows a countermeasures matrix created using the ets Microsoft Excel template. Notice how each countermeasure is listed alongside a respective root cause. You can also see how space is provided next to each countermeasure for practical methods, and ratings of effectiveness and feasibility.

Click On A Topic Below To Learn More About: Countermeasures Matrix - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Example - Templates

Figure 1: A Countermeasures Matrix Completing the countermeasures matrix is possible only after the practical methods have been added. We will discuss practical methods in the next checkpoint.

Devising Good Countermeasures


When discussing countermeasures, a distinction must be made between actions taken to quickly "fix" the root cause (an immediate remedy), and those actions that eliminate the root causes and prevent them from recurring. Too often organizations focus on the short term solution rather than taking steps to remedy the root cause. For example, if a lack of employees with technical skills is a root cause, then a poor solution would be to layoff your current staff and rehire new employees with the proper skill base. Although this action may fix the root cause today, it is only a matter of time before the same root cause will recur and you will be faced with the same issue. A better solution is to develop a countermeasure that prevents the root cause from recurring, such as initiating an employee training program or training center. Countermeasures that actually prevent root cause recurrence usually pay dividends in other areas of the organization as well. However your team creates countermeasures, be mindful of whether each suggestion is a quick fix or a long-term solution to the root cause. If you can't decide which are which, go ahead and list your countermeasure on the countermeasure matrix. Most "quick fix" countermeasures will become apparent when practical methods, feasibility, and effectiveness are considered.

This checkpoint is complete when your team has developed a list of countermeasures that focus on effective and sustained elimination of your root causes. In most cases, you should begin constructing a countermeasures matrix in this Checkpoint. You will finalize your matrix in Checkpoint 18.

Example:

Figure 2: An Example Countermeasures Matrix The following analytical and decision-making tools may prove helpful in this Step: The following tools and techniques may prove helpful in this process:

Brainstorming Countermeasures Matrix

Step 4: Analyze - Checkpoint 18

18. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility.
A practical method is literally the "practical" way in which a countermeasure could be used. In many cases, countermeasures can be implemented using a variety of techniques and resources. Of these, many methods are more practical than the rest. The goal of this Checkpoint is to determine which methods of implementing your team's countermeasures have the most likelihood of success.

Countermeasures tell what your team would like to do, and practical methods describe exactly how you might do it. Consider the example root cause from Checkpoint 17 in which the "office was too cold." One countermeasure for this root cause was to make the office warmer. In this case, you can probably think of many practical methods for achieving this: raise the thermostat, require employees to bring sweaters, or perhaps even moving the office to a warmer climate. Each of these methods would seem to ways of achieving the countermeasure, but clearly some of them are not as practical as the others. It is probably too expensive to move the office, and employees might not appreciate being required to wear winter clothing year round. For each countermeasure, your team must determine at least one practical method that can be used to implement the countermeasure. Each practical method should sound reasonable to the team, and once listed, should be evaluated for both effectiveness and feasibility. We will explain what both of these terms mean below. Effectiveness, in the context of a countermeasures matrix, refers to how well your countermeasure (and practical method) will work to close the gap. This rating is typically determined using expert opinions and group consensus. When more than one practical method is listed for a countermeasure, be sure to evaluate the effectiveness of each practical method individually. Feasibility, in the context of a countermeasures matrix, is the degree to which a team feels that this practical method could actually be used. A practical method may be very effective, but if it is forbidden due to law, or prohibitively high cost, then it is not very feasible. An important factor of feasibility is cost-effectiveness: how much benefit comes from this practical method, and at how much cost? Cost effectiveness can be investigated using costbenefit analysis of appropriate detail. The cost-benefit analysis technique is fully explained in the ets course Decision Making Tools.

Click On A Topic Below To Learn More About: Cost Benefit Analysis - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Example - Templates (actual templates can be downloaded in Appendix 1 - Cost Benefit Analysis )

Once each countermeasure and practical method have been evaluated, the team must select which countermeasures they intend to implement. Teams may choose to implement more than one countermeasure when they have adequate funding, time, or manpower. Be careful not to overextend your team's capabilities. Figure 1 below shows a completed countermeasures matrix with countermeasures, each respective practical method, and ratings for effectiveness and feasibility. Notice how the team selected the three highest rating practical methods for future action. These are the countermeasures and practical methods that will be further evaluated in Checkpoint 19.

Figure 1: A Completed Countermeasures Matrix A team is not required to use a countermeasures matrix to select their practical methods. In they do not, however, the team should provide adequate documentation and explanations that support their decisions.

This checkpoint is complete when your team has determined, using a systematic approach, which countermeasures (and practical methods) should be implemented to correct the root causes. Supporting information, either in the form of a countermeasures matrix or some other format, must be provided to justify the team's selections. Example:

Figure 2: An Example Countermeasures Matrix In the example shown above, a team has evaluated their countermeasures and decided to take action on three of them. In this case, specific countermeasures that also describe the practical method were used, instead of separate countermeasures and practical methods. This is an acceptable format, and is included as an example so you are familiar with this "shortcut" notation. The following analytical and decision-making tools may prove helpful in this Step:

Countermeasures Matrix Cost-Benefit Analysis

Step 4: Analyze - Checkpoint 19

19. Barriers and aids were determined for countermeasures worth implementing.

In Checkpoint 18 you selected a series of countermeasures that your team felt were the most effective and feasible choices. You are now encouraged to look more closely at each countermeasure, and consider not only the effectiveness and feasibility, but all other forces that may help or hinder your countermeasure's implementation. This step is a type of "sanity check" that helps ensure that you and your team have considered all the implications of a countermeasure. By the time this step is complete, your team's results may cause you to reconsider which countermeasures are implemented, and which are not. This step is important because effectiveness and feasibility are not always the only concern when selecting countermeasures. On the contrary, in many cases countermeasure selection comes down to political or logistical requirements. Consider Figure 1 below. Notice that one of the barriers states that the building closes early on some days. This may not be a negotiable arrangement, and if it isn't, will probably rule out the "split shift" practical method. On the other hand, management is in favor of innovative approaches. Perhaps if management is involved with the process, a compromise may be reached with maintenance that allows the countermeasure to proceed. Barriers and Aids Analysis are useful for highlighting areas of potential conflict, but also for providing teams with substantial data to support their claims and new ideas when barriers are considerable.

Click On A Topic Below To Learn More About: Barriers And Aids Analysis - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Example - Templates (actual templates can be downloaded in Appendix 2 - Barriers and Aids Analysis )

Figure 1: A Barriers And Aids Analysis The outcome of this analysis can also be used for contingency planning and scheduling on the action plan (which is created in the next Checkpoint).

This checkpoint is complete when your team has performed Barriers and Aids Analysis for each countermeasure and practical method. Please refer to the ets Decision Making Tools course if you cannot remember the details of Barriers and Aids Analysis. Example:

Figure 2: A Barrier and Aids Analysis The following analytical and decision-making tools may prove helpful in this Step:

Barriers and Aids Analysis

Step 4: Analyze - Checkpoint 20

20. The action plan reflected accountability and schedule.


With a set of countermeasures selected, and practical methods defined, you team is now ready to begin implementing your plan. To ensure that countermeasures impact the root causes, a timeline and accountability for each practical method must be established. To do this, your team should construct an action plan.

An action plan is a technique that contains the "Who, What, When and How" of a course of action or countermeasure. In the context of DMAIC, action plans are often used for ensuring that countermeasures and practical methods get implemented, and get implemented on time. When well constructed, an action plan serves as the overall blueprint of how your process resources are allocated, and how each member of your team will be involved in the process. Action plans are discussed at length in the ets Decision Making Tools course.

Click On A Topic Below To Learn More About: Action Plans - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Example - Templates (actual templates can be downloaded in Appendix 2 - Action Plans )

Figure 1: An Action Plan Each practical method is usually composed of a series of tasks that must be completed, or continued, to ensure that the practical method succeeds. These tasks are the items highlighted on an action plan. For example, in Figure 1 above you can see the 5 steps involved in the practical method "construct a new survey." The "Owners" column, when present, lists the people who are responsible for this particular Countermeasure and Method. These will typically be the people held accountable for this plan and its timely execution. In some cases, such as Figure 1, a small group is responsible for all of the steps. Each task (for implementing the countermeasure / practical method) is represented by a row with boxes used to denote the planned time (empty) and actual time (filled) for each task. Like the x-Axis of a chart, the bars pass through vertical columns which denote some segmentations of time: days, weeks, months, etc. Time progresses from left to right, such that boxes on the left denote a time prior to boxes farther to the right. When the proposed time for a task changes, the empty boxes should adjust accordingly. When portions of a task are completed, the box should be shaded a percentage equal to the amount of time completed toward the task. The action plan needs to be as specific, realistic, and as thorough as possible. Use individual names, instead of departments or groups, whenever possible. This will enhance accountability

and the probability of success. Also, make sure that the schedule coincides with any dates established in Step 2, Measure, or the project planning worksheet.

This checkpoint is complete when your team has developed an action plan for each countermeasure and practical method. Action plans should include sufficient detail, and include specific names of people who are accountable for tasks whenever possible. The following analytical and decision-making tools may prove helpful in this Step:

Action Plan

Note: This Checkpoint marks the beginning of the "Do" portion of the P-C-D-A Cycle.

Step 4: Analyze - Checkpoint 21

21. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement.
A test, or pilot implementation of the action plan, should be performed to assess how much impact the countermeasures will have on the root causes and problem. Decision-making tools are helpful and they certainly increase likelihood of success, but they are not guarantees that countermeasures will always work. Before committing to long-term countermeasures, take a week or a month to test your countermeasures on a smaller scale. During this test period, your team should use appropriate data collection and analytical tools to determine if the countermeasure does indeed affect the root cause as expected. During this pilot, the team may discover the need for adjustments, or they may encounter unanticipated barriers and aids that must be dealt with before the final rollout. It is also conceivable the team may decided to rethink which countermeasures would be most effective if their pilot findings are not what they anticipated.

This checkpoint is complete when your team has performed some sort of pilot implementation of the countermeasures and gathered data to assess their effectiveness on the root cause and problem statement gap.

Example: A team decides to test their countermeasure: "install GPS Navigation Systems in case worker vehicles." Rather than purchase 100 of these units for every caseworker, the team acquired two of them from a local distributor to "demo" for three weeks. During this time period, satisfaction scores and performance data were gathered for the two caseworkers that used the navigation systems. This data was then used to determine if the root cause and problem gap was reduced for these two workers. If it was, this is a strong indication that a large-scale implementation would also be successful. Using some additional math, a savvy team could even estimate the overall affect that the countermeasures would have on the root cause and gap organization wide. If two workers realized a 35% reduction, then it is logical to assume that the organization should see a similar reduction of course, this value may be higher or lower in reality. Even conservative estimates can be encouraging to leaders and helpful in acquiring needed funding or support to make countermeasures a reality. The following analytical and decision-making tools may prove helpful in this Step:

Barriers and Aids Analysis

Step 4: Analyze - Checkpoint 22

22. Incorporated lessons learned from the pilot into the full-scale action plan and implemented it.
In the previous Checkpoint, teams tested their countermeasures to see if they performed as anticipated. This pilot implementation usually provides teams with additional insight regarding the rollout of their countermeasures and the effect that their changes will have on not just the root cause, but the organization overall. For example, the pilot implementation may reveal additional barriers to implementation that must be dealt with before applying the countermeasure organization wide. Perhaps the countermeasure must be adjusted for different facilities. Perhaps the staff responded differently to the countermeasure than your team anticipated. When the pilot is completed and the team has confirmed that the countermeasure is effective, this Checkpoint requires that team members discuss the findings of the pilot and how this information should be used to ensure success of the full scale countermeasure roll-out. These lessons learned can be used to proactively address issues that were discovered during the pilot. Additionally, a team may have discovered helpful resources during the pilot that should be utilized in the organization wide deployment. Whatever lessons were learned, and whatever changes are made as a result of this Checkpoint, should be documented so that teams who might work to replicate your success will be aware of these issues if they occur.

This checkpoint is complete when your team has reviewed the outcomes of the pilot implementation and documented lessons learned, changes, and adjustments to your countermeasure rollout plan. Example: Do you remember the GPS Navigation countermeasure that we discussed in the previous Checkpoint? Let's continue that example by assuming that the teams learned the following lessons from their pilot. First, the team realized that the GPS systems were very effective at closing their gap, but their effectiveness was only realized when the caseworkers become comfortable using the system. Another lesson learned is that both caseworkers indicated that they only used one or two features of the GPS system, while most of the "bells and whistles" remain unused. Based on these two findings, what kind of changes in the final rollout would you envision? Here are some suggestions. First of all, it sounds like the team should schedule "case worker GPS training" in their Action Plan. Caseworkers told the team that they needed training, and data clearly reinforced their stance that familiarity with the system generated more efficient use. Another item to consider is the feature set and model of the GPS navigation unit. If a large number of features on the system are going unused, perhaps the team should consider rolling out a lower-end GPS model? This may save money and actually make training easier! The following analytical and decision-making tools may prove helpful in this Step:

Action Plan

Step 4: Analyze - Checkpoint 23

23. The sponsor signed off on the action plan and expected results.
Continual sponsor involvement, and regular updates to leadership, is important for DMAIC team success. Just as you did in Checkpoint 16, your team should once again provide a summary document (story / story board / etc) to your team sponsor and schedule a brief meeting so that they can be brought up to speed on your Step 4 progress. The focus of the sponsor's review here, in addition to general effectiveness, will be to ensure that the project's countermeasures were logically established, a pilot implementation has taken place, and an action plan that considers all the findings from the pilot is developed and ready to proceed.

Teams should be prepared to convince their sponsor, using data, that their countermeasure is the best choice. If a sponsor cannot be convinced, this is a strong indication that your team may have assumed too much and tested too little.

This checkpoint is completed when you have obtained approval from the project's sponsor on the project's countermeasures and countermeasure rollout action plan. Sponsor approval can be noted on the project planning worksheet. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet Tollgate Review

Step 5: Control - Checkpoint 24

24. The effect of countermeasures on the root causes was demonstrated.


The purpose of Checkpoint 24 is to determine, with data, how effective the countermeasures have been on the root cause. Root causes have some sort of measurable effect: the number of times they occur, how late a delivery is, the severity of the root cause (i.e. temperatures are 34 degrees too high). In some cases, the existence of the root cause itself may be a quantifiable event. Your team probably gathered some measurement of your root causes during Checkpoint 15. No matter how a root cause was identified, your team should demonstrate that countermeasures had an impact on the root cause by either significantly reducing it or completely eliminating it. Appropriate use of analytical and statistical tools is an effective way to show the impact of countermeasures on the root causes identified in Step 3. Using data to show improvement or change leaves little doubt as to the effectiveness of the countermeasures and resources expended, especially when a link between countermeasures, root causes, problem gap, and the theme is already established. Of course, if you can simply show that the root cause no longer exists, that is also ample proof of improvement. If root causes have been reduced for reasons other than the countermeasures, or if the countermeasures did not have the intended effect, this should also be explained.

Figure 1: Example Of Before And After Improvement Using A Histogram Figure 1 above shows an illustrative example of how the shift of a histogram mean can show improvement. In this case, a high number of route minutes were determined to be a root cause. By tracking this data before countermeasures were implemented and then comparing to data collected after roll out, the team can show a 20% reduction in the root cause. Although a histogram was used here, other Analytical Tools or graphs that show comparative data could also have been used.

This checkpoint is complete when you have demonstrated, with data, that the countermeasures have had effects on the root causes. You should also quantify these effects, if possible.

Example:

Figure 2: Example Before And After Bar Chart

The bar charts in Figure 2 clearly show that the root cause data shown was reduced from 39 overdue reports to 3 on Fridays. Friday overdue reports are now at the average of the other days of the week. This is supporting evidence that the team's countermeasures worked against Friday reports. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Pareto Chart Pie Graph Control Chart Bar Graph

Step 5: Control - Checkpoint 25

25. The effect of countermeasures on the problem was demonstrated.


Just as Checkpoint 24 showed the effect of countermeasures on root causes, Checkpoint 25 uses data to show the impact of countermeasures on the problem or problem gap. In many cases, the same Analytical Tools that were used in the Measure Step of DMAIC can also be used here. If a Pareto chart was used in Step 2 to demonstrate the problem gap, simply re-use the same chart

and update the data to create a before and after chart. Figure 1 below shows an example of a Pareto chart that shows improvement in problem "A."

Figure 1: Example of Improvement Using Simple Pareto Charts (Sorted Histograms) If the effects demonstrated on your charts are not due to countermeasures, or if your results were unexpected or affected by normal fluctuations in business, seasonal changes, etc., then your team should explain these occurrences.

This checkpoint is complete when you have demonstrated, with data, that the countermeasures have had effects on the root causes. You should also quantify these effects, if possible. Example:

Figure 2: Example Before And After Line Graph This line graph shows problem data both before and after the countermeasure. Notice that prior to the countermeasures implementation in mid September, the average number of errors in a two-week period was 27: a "four error" gap over the target of 23. After the countermeasures were implemented, the average number of errors in a two week period dropped to 20, which is "three errors" below the target of 23. Not only did the countermeasures affect the problem gap, they eliminated it altogether and actually pushed process performance beyond the current target. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Pareto Chart Pie Graph Control Chart Bar Graph

Remember: By reducing the problem, the overall improvement need (Step 1) is also addressed.

Step 5: Control - Checkpoint 26

26. The improvement target was achieved and causes of significant variation were addressed.
Once your team has compiled a set of before and after data in the previous Checkpoint, you should be able to determine how much of a change has occurred in the problem gap. Realistically speaking, improvement projects do not occur in a vacuum. Normal day-to-day work must continue, the economy fluctuates, projects get delayed, and a myriad of other factors can cause your results to be worse, or better, than expected. When your problem gap shows an unexpected change, it is important for your team to understand why things did not turn out as planned. By understanding the factors that contributed to the outcome, your team will have a better understanding of whether their project was flawed, or you were simply victims of poor timing. For example, consider Figure 1 below. Although it looks like the team's countermeasures had a significant impact on the gap, what would you say about these results if there was a dramatic drop in the number of reports submitted. Maybe a new expense report form was created that had better instructions? The purpose of this Checkpoint is to force a team to step back and take a hard, objective look at their results. Don't mislead yourself or others by relying simply on graphs and charts, but rather, try to understand the underlying situation that drove the changes in your data. If analysis is required to determine whether unrelated events had an impact on the gap outcomes, don't be afraid to do some additional investigation, such as scatter diagrams or interviews.

Equally important to explaining shortcomings of success is documenting breakthrough improvement! If your team's results were far better than expected, try to understand why. Determining the mechanisms that drove stellar results can lead to best practices and replication opportunities through the organization.

This checkpoint is complete when your team has analyzed their outcome data and determines what factors were actually, not intuitively, involved in driving the change. In some cases this will be obvious, and in others some investigation may be required. Regardless of the outcome, your team should be able to explain the chain of events that resulted in the change. Example: Assume that a team working on an improvement project finished Checkpoint 25, but rather than closing their gap in the problem "200 technical support questions are going unresolved each day," the team noted that the average number of technical support calls had risen to 310. Was the improvement project a failure? The team contacted the technical support office and asked if any significant changes in call volume or products had occurred recently that might have affected their results. After a few different interviews, a tech support employee noted that a recent virus outbreak had caused many customers to erroneously assume that the improvement team's software product was malfunctioning. In fact, the team discovered that 80% of the technical support calls during the "post countermeasure" period were related to the new virus.

Suspecting that the data might have been skewed unfairly, the team decided to collect another week's worth of data once the virus problems were under control. After this data was collected, the team noted that unresolved questions were averaging only 35 per day. What appeared at first to be a failure was actually a big success! Be highly critical of any data that your team gathers? Accurate and unbiased data collection is one of the keys to project success. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Interviews Pareto Chart Pie Graph Control Chart Bar Graph

Step 5: Control - Checkpoint 27

27. The effect of countermeasures on the theme indicator representing the stakeholder's need was demonstrated.
Remember that the root cause affects the problem, and the problem affects the theme. Since we have already confirmed that both lower level measures of success have been effective, your team must finally assess how much improvement in the theme indicator occurred as a result of correcting your problem gap. Since you selected the most significant problem (the one that would have the most impact on the theme) during Step 2, your team should see some noticeable change in the theme indicator. This change should be demonstrated using data, just as you have done in Checkpoint 24 and 25. You should also note any unusual behavior, or suspected outside influences, if your results were not as expected. Showing an effect on the theme statement is the acid test of your team's success. By improving the theme indicator, your team shows that you have improved an aspect of a process that is important to your customer. A theme, by definition, is directly related to customer need. When the theme improves, customer needs are better met.

Figure 1: Before And After Theme Indicator Data Figure 1 shows an overall theme indicator that showed significant reduction in the total number of customer complaints after countermeasures were applied. Since the improvement team from Figure 1 corrected their root cause and reduced the most significant problem (which was proven to link to the theme in Checkpoint 8), the theme indicator "Customer Complaints" improved.

This checkpoint is complete when your team has demonstrated, using data, the effect of countermeasures on the overall theme indicator. If your team's results were not as expected, investigation and explanation is required. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Pareto Chart Pie Graph Control Chart Bar Graph

Step 5: Control - Checkpoint 28

28. A method was established to document, permanently change, and communicate the revised process or standard.
Once a DMAIC project and its countermeasures have been implemented, changes often occur in the way that an organization does things. Processes may be modified. New tools or techniques may be introduced. Standards may be raised or lowered. Whatever the changes are, your DMAIC team must ensure that all relevant staff members understand these changes, and that staff have an appreciation for why they are being asked to change their work processes. It is important for a successful DMAIC project team to document their efforts and communicate their success to the organization. Although other employees may understand how to perform countermeasures, if they do not understand "why" these countermeasures are important, they probably won't stick with them. In many cases, your team will be asking staff members to change the way they work. This often generates some degree of resentment or resistance. Although these feelings cannot be eliminated, the impact of process changes can be greatly minimized when staff members understand why changes are occurring. If possible, try to involve staff in the process so they feel as if they had a hand in finding the solution. When countermeasures change the way things are done, it is also important that the DMAIC team ensures training materials, equipment, process flowcharts, PCSs, and procedures are appropriately modified to so that countermeasures remain in place. Don't assume that the same staff will be around three weeks from now! Make sure your changes are process dependent, and then they will remain in place regardless of staff turnover or attrition.

Click On A Topic Below To Learn More About: Poka Yoke - What Is It? - Why Is It Important? - How Is It Used? - Process Overview

This checkpoint is complete when your team has communicated their project to relevant staff, adequately explained why the changes are important, and put measures in place to ensure that the countermeasures are tightly integrated into training, processes, and resources. The following analytical and decision-making tools may prove helpful in this Step:

Poka Yoke Devices

Step 5: Control - Checkpoint 29

29. Responsibility was assigned and periodic checks scheduled to ensure compliance with the revised process or standard.
The power of "accountability" has been promoted repeatedly through this course. In this Checkpoint, your team must once again assign accountability to individual team members to ensure that standardization efforts remain in place. Standardization means making countermeasures part of your organizational standard, the way you "do" things on a daily basis. In the previous Checkpoint we discussed ways in which countermeasures and process changes are documented and integrated into an organization. These initial documentation steps are critical to short term success, but long-term success relies on standardization efforts remaining in place throughout the coming months and years. Changes will remain in place only if they are checked periodically by accountable team members. Since today's organizations handle a tremendous volume of information, and laws or procedures may change by the week, it is vital that DMAIC team members take responsibility for checking up on any changes made during Checkpoint 28. Team members should each select one or more standardization changes and establish a regular schedule for checking-up on changes to ensure that they remain in place. These follow-ups should be reasonable, and their frequency can be become more spread out as countermeasures become routine and the workforce adapts to the changes.

This checkpoint is complete when your team has assigned accountability for checking-up on any standardization efforts that were defined in Checkpoint 28. Each significant change should

have a specific person assigned to it and a clearly defined schedule for performing the standardization review. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Sheet Action Plan

Step 5: Control - Checkpoint 30

30. Specific areas for replication were identified.


During these final DMAIC Steps, teams are responsible for identifying potential best practices, standards, or techniques that may be replicated in other areas of the organization. This single checkpoint can drive some of the most significant gains in an organization. Replication, in simple terms, has two important steps: First, teams must ensure that their good discoveries are communicated with everyone in an organization. Second, organizations must encourage everyone to incorporate other DMAIC team discoveries into their own processes.

Sharing The Success


Organizational processes, although different in application and purpose, often share similar steps or procedures. For example, the process of retrieving customer records may be performed by many different departments and for many different reasons. Although each department may use a customer's record differently, they all use similar procedures to obtain record data and update customer information. During the course of process management, teams often identify "better" methods of doing things or countermeasures that create dramatic improvement. When such methods are found, a team needs to share these methods throughout their organization so that others with similar processes can capitalize on the better technique. Whether a team simply improves a current method, or establishes a "breakthrough" technique that radically improves a process, there must be a concerted effort on the part of DMAIC teams and organizational management to encourage both improvement sharing and replication of best practices from other areas. Replication will not occur if management does not actively promote it; it won't happen automatically.

The Benefits Of Replication


Replicating a DMAIC project's success has tremendous value to an organization. The following paragraphs relate some of the fruits of DMAIC success replication.

Replication Maximizes Organizational Improvement

When a DMAIC team finds a way to increase efficiency 2% in a single process, this improvement is magnified many times when it is replicated in other areas. This simple concept is where DMAIC and improvement methods add some of their greatest value to an organization! A seemingly minimal improvement by one team can still add up to dramatic improvement organization wide. For example, if your process team reduced the "minutes to access customer record" indicator by 2 minutes and shared this technique with 100 other departments that also access customer records, you have just turned a 2-minute improvement into more than a 3 hour improvement. Such gains are further magnified because organization wide improvement can drive better performance indicators of processes that are customers or suppliers of the improved process!

Avoids "Re-inventing The Wheel"


Re-inventing the wheel is a humorous way of describing rework. When a DMAIC team discovers a great new technique but fails to share it, there is a good chance that another team will invest time and effort to "re-invent" the same technique. By sharing good methods and best practices, teams not only encourage re-use of good ideas but also prevent other teams from wasting resources to reach similar conclusions. Reinventing the wheel is very costly: it delays replication, causes low-value rework, and ties up a DMAIC team that could be inventing a new technique. Good communication and replication will prevent teams from doing the same things, over and over.

Refines Good Practices Into Better Or Best Practices


Many times in business or organizations, it takes one stroke of brilliance to make a discovery and the perspective of another person to make that discovery a masterpiece. When good practices are communicated and shared, they become a baseline for future improvement of other management teams. This concept means that organizations who replicate improvements are continually improving the improvements. Refinement is generated by teams building on each other's work and continually replicating improvements. In fact, many of the improvement techniques used in DMAIC are the result of teams, teams just like yours, finding better ways to make formal problem solving work. This cycle of on-going P-D-C-A and replication eventually created industry leading "best practices." A best practice, simply stated, is a process that is believed to be the "best" way of doing something in terms of cost, quality, and value.

Methods To Ensure Replication


Replication will not automatically happen. Management must take an active role in encouraging teams to share improvements, and organization members to embrace improvements from other teams. One key requirement for replication is a functional understanding of DMAIC or process management, organization wide. It is difficult to explain a process improvement to someone

that doesn't understand processes or indicators more often than not, they will simply perceive the changes as unwarranted or possibly even irritating. Basic understanding of processes, indicators, and data help employees communicate the value of shared improvements and it also assists in their application. Another important factor for ensuring replication is proper documentation. When a good improvement occurs, others must know exactly what changes were performed to drive that improvement. Organization members should also have some means to contact someone in the original DMAIC management team, in case there are questions or problems. There are many techniques for encouraging replication:

Newsletters, e-mail, or web site updates. Annual improvement overview meetings. Internal quality awards or improvement team competitions. Internal quality departments.

New techniques can also be replicated by making them into standards. A standard would be an official organization procedure or level of performance, such as how and when to file an overtime request that is documented as the "right" way to do something. Standards are often listed in employee training manuals or other HR or procedural documentation.

This checkpoint is complete when your team has taken steps to promote replication. Remember that replication is the true "payoff" of your work! In fact, it is not uncommon for successful DMAIC teams to spend more time replicating and sharing their success with others than they spend on the initial DMAIC project. After all, sharing good news can be fun!

Step 5: Control - Checkpoint 31

31. Any remaining problems of the theme were addressed.


In Checkpoint 31, DMAIC teams must make a judgment call as to whether or not their theme has been sufficiently improved. If you have a clearly defined theme indicator, as in the case of Process Management improvement teams, this may be an easy question to answer. If you do not have a clearly defined improvement target, your team may be required to have a meeting with leaders to determine if additional theme improvement would be beneficial. Perfection or "zero defects" are certainly ideal, but they are not always cost effective. Many improvements begin to have diminishing returns whereas your team spends months to make only trivial gains in the theme indicator.

Remember that DMAIC is designed to tackle the most significant problems first. As a result, after your team resolves the first few problems, you have usually corrected almost all of the theme's shortfall. In the event that additional thematic improvement is required, your team should return to Checkpoint 6, the first Checkpoint in Step 2 of DMAIC, and select the next largest problem for correction. If a large amount of time has passed since your team performed the "Measure" Checkpoint, you may need to update your data. It is possible that countermeasures and other unexpected factors may have increased (or decreased) the severity of other problems. You may be wondering why this Checkpoint occurs after the replication Checkpoint. Even if your DMAIC team didn't drive theme improvement all the way to a desired level, you assuredly have some good ideas and countermeasures to share. Begin replicating success as soon as possible! The overall gains from effective replication will offset any minor costs associated with continuing improvement of the theme.

This checkpoint is complete when your team has determined if the project theme was improved to a point that is acceptable. Exactly what level of improvement that is acceptable will be determined by leadership, process management teams or Process Control Systems, standards, or even your own team's professional opinions. The following analytical and decision-making tools may prove helpful in this Step:

Pareto Chart Cost-Benefit Analysis

Step 5: Control - Checkpoint 32

32. Lessons learned, P-D-C-A of the ets six-sigma DMAIC Method, and team growth were assessed and documented.
After a DMAIC project has obtained stability and capability, and all of the documentation has been completed, your team should schedule a meeting to review the project. This review should be a casual meeting in which each person involved with the project has a chance to reflect on what went well with the project and what could be done better next time. Just as improving organizational processes require continual improvement, the DMAIC process itself should be continually refined and made better. Your team can also reflect on their own growth during the project, and share any insights or revelations that they gained. Radar charts can be used to quantify team member growth in a number of areas, and can be effectively

created by using a simple team member survey. Even an informal survey here can generate some encouraging results.

Click On A Topic Below To Learn More About: Radar Charts - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Templates (actual templates can be downloaded in Appendix 1 - Radar Charts )
For example, ask staff members what their level of comfort with DMAIC was before the project? Next, ask them what their level of comfort is now? When noteworthy improvements or problems are identified, they should be documented and communicated with other teams. You should also make a point to celebrate successes and reward or acknowledge the extraordinary efforts of team members.

Plan - Do - Check - Act


P-D-C-A is a cycle based upon the premise that to always meet customer needs, you must continuously improve. You must plan what needs to be done, do (or implement) it, check the results of your actions (to ensure that you actually accomplished what you intended to do) and act upon the findings, applying lessons learned to future activities. The DMAIC problem solving method embraces the philosophy of using systematic approaches to generate improvement and share gains throughout an organization. Everything associated with performance excellence is built upon a foundation of continual refinement and growth.

This checkpoint is complete when your team has applied P-D-C-A to your DMAIC project and reflected on lessons learned via a discussion, project wrap-up, or a "We Did It!" celebration. This Checkpoint may seem trivial, but like replication, it has on-going benefit and can generate a surprising amount of growth and value. The following analytical and decision-making tools may prove helpful in this Step:

Radar (Spider) Chart

Step 5: Control - Checkpoint 33

33. The sponsor signed off on the results and next steps.
The final Checkpoint in DMAIC is to present the completed DMAIC story to your sponsor and receive their official sign off on the outcome of the project and your team's standardization and future plans. This final Checkpoint is critical because it forces teams to finalize their DMAIC story and document their work in a standardized manner. If this Checkpoint is skipped, there is a reasonable likelihood that a team will never finalize their DMAIC story and important outcomes, lessons learned, or on-going work will be forgotten. The final sponsor sign-off also gives leadership an opportunity to recognize the DMAIC team's hard work and success. Team sponsors should make a point to publicly congratulate their team and spread the good news that improvements have been made. Every organization can benefit from a bit of good P.R.? Don't miss these golden opportunities!

This checkpoint is complete when your team sponsor has reviewed a finalized DMAIC story, ensured that standardization has taken place, and that team effort has been rewarded and recognized. The following analytical and decision-making tools may prove helpful in this Step:

Party, recognition and award ceremony. Project Planning Worksheet Tollgate Review

Key Point
ets FasTrack Summary 1 of 2: The formal problem solving methodology used for correcting an undesirable process

outcome performance and ensuring that corrective measures maintain acceptable performance is called? Answer: DMAIC

Key Point
ets FasTrack Summary 2 of 2: How many steps and checkpoint are performed when using the ets DMAIC Method? Answer: 5 Steps 33 Checkpoints

Strategic Planning / Management Overview


What Is Strategic Planning / Management And How Does It Relate To Six Sigma?
Although the bulk of Six Sigma consists of analytical / decision tools, process management, and DMAIC, traditional Six Sigma courses also provide strategic planning and strategic leadership training to enable students to better manage the details of Six Sigma teams, meetings, and the deployment of strategy. In the interest of brevity, we will not cover team-building exercises or outline the proper methods for establishing organizational Mission, Vision, or Values. In most cases, these activities are performed by a small portion of an organization and are not required skills for all FasTrack students. Teaching these concepts to everyone is akin to training every member of a team to be the team captain: it may be helpful, but is not necessarily a good use of limited time. There are some concepts introduced in strategic planning, however, that may help you understand the link between strategy, processes and DMAIC. For that reason, we will quickly cover some of the high-value topics and jargon.

The Need For Strategic Planning


Strategic planning is the process of establishing the Mission and Vision for an organization, and ensuring that they are achieved. Strategic management is the process of ensuring that strategic planning occurs as intended. The Vision and Mission of an organization are statements that summarize the critical objectives that the organization must meet to be successful. Success in meeting these objectives is driven by DMAIC and process management teams, and measured using indicators. Much of Six Sigma is based on monitoring the success of indicators or improving them when they perform poorly. Strategic planning lays the framework and defines the goals for improvement, while Six Sigma provides the organization with the tools and processes they need to meet the strategic plan. It is not vital for FasTrack students to understand the complex process of strategic planning, but it is probably helpful for you to realize that it is the source of many indicators and targets you encounter.

The Need For Strategic Management


Strategic management is a set of processes and techniques that help ensure strategic plans are followed through. Critical concepts here would be team management skills, holding effective meetings, ensuring people are accountable and the ability to solve logistical issues as they occur. Many of these skills are used on a smaller scale in analytical or decision-making tools. Just as with strategic planning, expertise in leadership and strategic management is not critical for Six Sigma success, but it does provide some perspective on high-level decisions and the prioritization of Six Sigma resources. Section Complete

You have now completed the "What is Six Sigma?" section. The next two sections will quickly provide you with a big picture grasp of the Six Sigma process and some general skills and information you need before beginning the DMAIC section.

Key Point
ets FasTrack Summary 1 of 1: The process of establishing the Mission and Vision for an organization, and ensuring that they are achieved is called?

Answer: Strategic Planning

How Six Sigma Works


Previous Section Review
If you took a break since you read the last section, please take a moment to review the following paragraph and refresh your memory. Six Sigma is the popular name of a management system that uses data and systematic approaches to improve the quality of business processes. Simply stated, Six Sigma is a way for you to do things better, faster, and for less cost. To perform Six Sigma, organizations use a series of tools, techniques, and processes that work together and help leaders make better decisions based on facts.

This Section Overview


By now, you have a decent understanding of what Six Sigma is, but you probably aren't so sure about how it works. Just as Six Sigma uses a collection of refined tools and processes to solve problems, the actual deployment of Six Sigma through organizations and the orchestration of Six Sigma teams also relies on a proven, refined methodology. With so many loosely related concepts and processes, getting a handle on how or why Six Sigma works can be challenging. For this reason, the section you are about to read provides a high-level, "big picture" view of Six Sigma and the mechanics of how it works. You will learn how the Six Sigma philosophy is deployed, and how all of the Six Sigma concepts relate to a single model: the Integrated Service Delivery System (ISDS). By the time you finish this section, you will have an understanding of the roles that leadership and staff play in Six Sigma deployment, and the basis for decisions that direct Six Sigma efforts.

The Integrated Service Delivery Systems (ISDS)


The ISDS Concept
The goal of Six Sigma is to create "performance excellence," the state of successfully achieving the mission and vision of an organization, and meeting "customer" and "stakeholder" needs at all levels. To achieve this goal, Six Sigma relies on a concept called the Integrated Service Delivery System. The Integrated Service Delivery System (ISDS) is defined as an "organized relational description of all organization activities required to provide continuous customer satisfaction and performance excellence." That's probably a bit too technical for most people, so instead, think of the ISDS as a model, which represents an organization as processes, measurements, and interactions between processes.

Models are used to help us represent complicated or abstract concepts. In fact, you have probably encountered many models in your current organization such as "org charts," job profiles, facility maps, etc. Just as each of these models is designed to communicate a certain aspect of the organization, the ISDS is used to display an organization as processes, customers and indicators- the aspects most important to Six Sigma. When an organization begins to model itself using the ISDS, it becomes a series of charts and graphs as shown in Figure 1 below.

Figure 1: What Comprises The ISDS Process flowcharts are used to explain, "what an organization does," the flow of work, and the interaction between internal / external customers. Indicators and measures tell "how the organization measures success," predicts outcomes, and quantifies improvements. Management review processes, then, ensure that "how the organization improves" is tracked, documented and monitored. Understanding the ISDS model explains some of the seemingly disjointed charts and graphs developed during Six Sigma or process management. Although it is not readily apparent, all of these charts and graphs link together to form a comprehensive model of the organization and a system to ensure that the model is current and correct. As a result, using the ISDS model for an organization is a key driver of performance excellence.

Figure 2: Performance Excellence And ISDS Now that you know what the ISDS is, let's look at some of the components, concepts and techniques used in the ISDS model.

The Customer Concept


Organizations are composed of people making contributions as individuals and groups, or departments. Although many employees in an organization never interact directly with external customers, their activities support the needs of "the next in line" or internal customers. In this sense, the word "customer" refers to anyone that receives products or services from an organization, whether they are external customers that consume products and services from your organization, or internal customers that rely on products and services from other internal units. For example, a person that enters a bank to apply for a loan is an external customer to the bank. The branch that receives the loan application is an internal customer of the loanprocessing department; the branch relies on an internal business unit to provide services just as a person relies on a bank to provide services. Any person or organizational department that needs products or services is a customer. Consider how your organization is actually a group of customers and suppliers. For example, an external customer may interact primarily with a caseworker from your organization. The caseworker then relies on the program development team to provide her with the resources she needs to help the external customer. In a sense, the caseworker is a customer of program development. In the same manner, program development relies on management to issue funding and guidance. An organization is essentially a chain of internal customers and suppliers meeting each other's needs to ultimately ensure the needs of external customers and stakeholders are met. Figure 3 shows this customer supplier relationship.

Figure 3: A Simplified Customer-Supplier View Of An Organization When an organization is viewed as a series of customers, the term "customer need" takes on a much deeper meeting. Meeting customer needs does not only apply to external customers, but also to internal customers. When we refer to "customer satisfaction" in this course, we are talking about all of the customers in an organization, internal and external. Another important concept is the "stakeholder." Any person or organization that has an interest, be it personal or financial, in the success of an organization is called a stakeholder. In a public

organization, stakeholders are often investors or owners. In government agencies, the community is the stakeholder. These two concepts, customers and stakeholders, are fundamental to process management. For performance excellence to exist, organizations must be directed by the needs of external customers and other stakeholders. Only by understanding the needs of the external customer and stakeholder, and ensuring that those needs are addressed consistently, can performance excellence be practiced. In other words, your organization must know what your customers want, and make sure that you do a good job of giving them what they want. A way to realize the importance of this concept is to visualize an organization as a customer-supplier model. A solid understanding of the customer-supplier concept is critical to your success in Six Sigma.

Key Point
ets FasTrack Summary 1 of 4: What word describes a person or organization, internal or external, who needs products or services provided by the organization? Answer: A customer

Key Point
ets FasTrack Summary 2 of 4: What word is used to describe a person or organization who has an interest in the success of the organization? Answer: A Stakeholder

Key Point
ets FasTrack Summary 3 of 4: Name one of the three components of an Integrated Service Delivery System? Answer: Strategy, Performance Improvement, Process Management

Key Point
ets FasTrack Summary 4 of 4: The model that Six Sigma uses to show an organization as the processes, measurements and interactions between the processes is called? Answer: Integrated Service Delivery System (ISDS)

The Integrated Service Delivery System (ISDS)


Major Concepts And Components Of The ISDS
Let's take a look at the specific parts and philosophies behind the ISDS. The Integrated Service Delivery System can be broken down into three major components. Each component plays a role in building or maintaining the dynamic model of an organization. In addition, each component of ISDS is designed to reinforce four fundamental principles that have been repeatedly demonstrated as critical characteristics of effective organizations: "managing with facts, P-D-C-A, respecting people, and focusing on customers." Figure 1 below provides a visual representation of how all of these components relate to each other.

Figure 1: The ISDS Components And Its Four Fundamental Principles Since the ISDS is typically the overarching "blueprint" developed through strategic planning, it is the catalyst of many Six Sigma projects. By learning more about the ISDS components, we hope that you gain a more profound understanding of why Six Sigma works, and why every Six Sigma project is vitally important to performance excellence. We will now briefly introduce the ISDS components and principles.

Policy And Strategy


Policy and strategy is the identification, and verification of priority organization issues and the deployment of activities to achieve breakthrough performance improvement in a few selected areas. Activities related to policy and strategy include:

Determine organization vision and direction. Identify external customers and other stakeholders' needs. Determine critical organizational issues. Target areas for breakthrough performance improvement. Communicate organization direction, goals, and objectives. Translate goals into specific activities.

Attain organization-wide participation in the achievement of organizational goals and objectives. Continuously review progress toward the goals and objectives. Provide feedback. Standardize systems.

As you can see from the list above, establishing policy and strategy is critical to the ISDS model. Using a ship as an analogy, strategy acts as the map, a speedometer, and a navigation plan. Individual Capability And Accountability Individual capability and accountability is the purposeful attainment of the skills and resources an organization needs to meet customer requirements. Emphasis in the ISDS is placed on continuous performance improvement, such as Six Sigma DMAIC methods, through structures that enable and promote team and individual contributions (i.e., "Do things right the first time"). Whereas strategy lays out what must be done, individual capability and accountability ensures that it can be done. After all, even the best plans will fail if people lack skills, accountability, or resources to be successful. Activities related to individual capability and accountability include:

Continuously improve to meet the changing needs of customers. Develop and effectively utilize the skills and abilities of all employees at all levels. Promote the use of a common language to facilitate analysis and communication. Encourage employee involvement through teamwork and individual contributions. Strive for balance between assigned and voluntary team efforts. Review progress and provide feedback. Maintain the gains and share with others. Apply lessons learned to future activities.

Capability and accountability is critical to the ISDS model since it ensures the staff is capable of performing the tasks required for performance excellence. Continuing our ship analogy, capability and accountability ensures that the vessel is adequately staffed and that each crew person performs their duties. Process Management

Maintain the gains achieved through team or individual improvement projects. Achieve consistency in operations. Improve and manage daily work processes. Provide the foundation for continuous improvement and the efficient allocation of resources.

In the ship analogy, process management is the engine that powers the ship - the process that propels the crew toward their destination. If you are taking this course, you will probably play a key role in one or more process management activities, such as process mapping, DMAIC stories, or performance evaluation.

Key Point
ets FasTrack Summary 1 of 2: How many principles are used in an ISDS?

Answer: 4 Manage the Facts P/D/C/A Respect People Focus on Customers

Key Point
ets FasTrack Summary 2 of 2: What does PDCA stand for?

Answer: Plan Do Check Act

The Integrated Service Delivery System (ISDS)


The Four Fundamental Principles Of The ISDS

Figure 1: The ISDS Components And Its Four Fundamental Principles Now that we have discussed the three major components of the ISDS concept, let's look at the four principles that were used to develop the ISDS model. These four principles are features that, over and over, are noted in highly successful organizations. Just as excellent study habits are a common characteristic of good students, organizations with high customer satisfaction, high employee satisfaction and high stakeholder satisfaction always reflect the four ISDS principles.

Principle 1: Manage With Facts


Decisions are based on data, rather than instinct or "gut feel". Also, managers must ensure that a disciplined system is in place to manage with facts.

Principle 2: P-D-C-A (Plan-Do-Check-Act)


Everything that is done is being continually improved, not remaining stagnant or "good enough." This continual improvement is represented by a revolving wheel, and at any time, every process in an organization is in one of the four continual improvement stages:

PLAN: Plan what to do, and how to do it. DO: Do it. CHECK: Check what you did. ACT: Act to provide feedback, standardize, or apply lessons learned.

Principle 3: Respect People


Everyone must listen to all ideas and promote the creativity, self-motivation, and limitless potential of others. Treat others as you would like to be treated. Think and act as a team player. If the team wins - the individual wins.

Principle 4: Focus On Customers


Not only must we satisfy the needs and expectations of customers, we should strive to anticipate those needs. The prevailing attitude must be that the customer and other stakeholders come first. Based on the descriptions alone, you will probably recognize many of these concepts. Organizations routinely do some of these things on an ad-hoc or partial basis. The ISDS model, however, uses systematic approaches to force organizations into adhering to these principles. Everything done using ISDS has these four principles built-in. The following four pages will provide more insight into the four principles, and explain why these principles are vital to a successful organization.

Key Point
ets FasTrack Summary 1 of 4: What term is used to describe basing decisions on objective data, not instinct or "gut feel"?

Answer: Manage the Facts

Key Point
ets FasTrack Summary 2 of 4: What acronym is used for the continuous improvement cycle? Answer: PDCA

Key Point
ets FasTrack Summary 3 of 4: Which principle of ISDS focuses on treating others as you wish to be treated and working as a team player? Answer: Respect Others

Key Point
ets FasTrack Summary 4 of 4: Which of the fundamental principles strives to anticipate the needs of customers and satisfy them? Answer: Focus on the Customer

Manage With Facts


The Meaning Of Managing With Facts
To "Manage With Facts" means making the best possible decisions regarding the delivery of quality services to our customers through the use of objective data. There are a few important concepts in the definition above. First, notice that management with facts is focused on making the best possible decision. Sometimes finding the "right" decision isn't always possible. Use of decision making tools and data help organizations to choose options that have the best possible likelihood of success, based on group consensus and statistical significance. Second, notice that management by fact decisions relate to "the delivery of quality services to our customers." This statement reiterates the importance of viewing an organization in the customer-supplier model and focusing attention on meeting customer needs. Finally, note the point made about "objective data." Objective means without personal bias or opinion. It also implies that the data used to make decisions was collected in a way that won't skew or devalue the results. The best decision making process in the world will be worthless if the data used in the process was not collected in an objective manner.

Drawing Decisions From Data


An organization that manages with facts uses properly organized and analyzed data as a basis for decision-making and action, not intuition or "gut-feel." Webster defines data as "facts or figures from which conclusions can be drawn; a basis for reasoning, discussion or calculation." For our purposes, data enables organizations to:

quantify the present situation (baseline). track a process. establish the gap between what is and what should be. verify the root causes of a problem, or the results of countermeasures.

Key Point
ets FasTrack Summary 1 of 1: What goal do you strive for when you manage with facts? Answer: Make the best possible decision based on the objective data / facts

P-D-C-A
Plan - D0 - Check - Act
P-D-C-A is a cycle based upon the premise that to always meet customer needs, you must continuously improve. You must plan what needs to be done, do (or implement) it, check the results of your actions (to ensure that you actually accomplished what you intended to do) and act upon the findings, applying lessons learned to future activities.

Figure 1: The P-D-C-A Wheel P-D-C-A is a concept that can be applied to any process, from getting to work each day to managing technical operations. It is also the underlying concept of the Six Sigma DMAIC improvement process and most systematic improvement systems. PDCA was originally developed by Walter Shewhart, the pioneering statistician who developed statistical process control at Bell Laboratories in the US during the 1930's. It is often referred to as "the Shewhart Cycle," in his honor.

Figure 2: Walter Shewart

P-D-C-A was taken up and promoted very effectively later in the 1950's by the famous Quality Management authority, W. Edwards Deming, and is subsequently also known as "the Deming Wheel."

Figure 3: Dr. W. Edwards Deming

Key Point
ets FasTrack Summary 1 of 1: What does the acronym P-D-C-A stand for? Answer: Plan Do Check Act

Respect People
The Rules Of Conduct
The "respect people" philosophy means respecting other people's ideas, their desire for personal development and recognition, and their capacity for self-motivation. As a key component of successful organization, respecting people is built into the analytical and decision tools throughout Six Sigma, such as consensus, brainstorming, and multi-voting. This principle is also fundamental to the concept of empowerment, allowing people in your organization to make informed decisions. One practical way to reinforce the principle of "respect people" is to establish and follow "Rules of Conduct" during meetings. Your team can either adopt the rules shown below or modify them to best suit your team's needs.

Rules of Conduct

Respect others. Keep an open mind. Listen without interrupting. Share the load. Constructively criticize ideas, not people. Question and participate. Attend all meetings. Follow the P.A.L.

With the ground rules established, the team can begin the continuous improvement cycle and P-D-C-A, but meetings must be effectively managed to ensure progress and success.

Meet Your P.A.L.


P.A.L. is a simple acronym to help you remember the three features of a successful meeting: Purpose, Agenda, and Limit. P - Have a PURPOSE for the meeting. A - Develop an AGENDA for the meeting. L - Set LIMITS for the meeting especially time limits. A P.A.L. can be posted before the meeting, written on the whiteboard, or included in a memo before the meeting. Regardless of how the information is presented, each attendee should know the P.A.L. before a meeting gets underway!

Purpose
Be clear about why a meeting is being held and what is to be accomplished. Never have a meeting for which you have not prepared or which does not have a clearly defined purpose. Never have a meeting "just to have a meeting."

For example, performance improvement team meetings will always have an objective and an output. To help complete the necessary output of each meeting, the team leader should tie these objectives directly to an agenda. Taking time to plan meetings in advance will help keep the team on track.

Agenda
Always have an agenda developed in as much detail as is necessary to keep you and your team on track and accomplish all of the objectives laid out in your meeting's purpose.

Limit
Set a meeting length time limit (for example, one hour). Start the meeting exactly on time and BEGIN STOPPING the meeting at least five minutes before the time limit is up. Starting on time and ending on time is a golden rule of meeting management. If you remember and apply these three simple rules, you will be practicing a simple, but also very powerful leadership behavior- and you will be respecting people.

Key Point
ets FasTrack Summary 1 of 1: PAL is an acronym used to help remember you remember the three (3) features of a

successful meeting. What does it mean? Answer: Purpose Agenda Limits

Focus On Customers
How To REALLY Be Customer Focused
"We're customer focused!" You probably hear this advertising battle cry from many businesses these days, but how many of them really know what it means? Focusing on the customer doesn't mean 10% rebates or free coffee in a waiting room. Being truly customer focused means that you determine the success of your business based on your effectiveness at meeting customer needs. Everyone in an organization ultimately serves the external customer, but all of us also have internal customers. Remember, anyone who uses your products or services is your customer. The customer-supplier model that was introduced earlier in this section hinted at the many customer-supplier relationships that exist in an organization. Now take a moment to review a more complete model. Figure 1 lists each phase of the customer-supplier model and sets the stage for what being TRULY customer focused is all about. In fact, process management is an expansion upon this very concept.

Figure 1: The Customer-Supplier Model 1. 1. Identify your work processes, including inputs, operations and outputs. 2. Identify the customers for your processes. (Who receives your output?) 3. Determine with your customers their needs and expectations for your product or service. 4. Develop indicators to measure your performance against your customers' requirements. 5. Analyze the gap between actual performance and target. 6. Take action to improve. 7. Identify the suppliers for your processes. 8. Inform your supplier of your customer driven requirements. 9. Help your supplier assess performance.

10.Provide feedback to your supplier. Before progressing, take a moment to consider each feature of the customer-supplier model above. Is this how your organization currently works? Can you see how this would change the way your organization measures success or applies effort? What if every person or department that you relied upon in your organization treated you as their most valued customer?

Philosophy Of Customer Satisfaction


The philosophy of customer satisfaction is what "should" be running through everyone in an organization's mind when they say they are customer focused. Take a moment to read this statement. A printable copy of this document is available using the template icon at the bottom of this page. You may find it helpful to post this philosophy in a visible area until you become familiar with its points.

Figure 2: Philosophy Of Customer Satisfaction

Key Point
ets FasTrack Summary 1 of 1: What term refers to the relationship between an organization and its internal and external

customers? Answer: The Customer Supplier Model

Focus On Customers
Identifying Customers
A customer is typically thought of as the consumer or end user when, in fact, the customer is actually any person or group that receives the output (product or service) of your process. External customers are those end-users whose needs should be met by our product or service. To satisfy external customers, we must also meet the needs of our internal customers - those within our organization who add value to the product or service we provide. Our product may pass through the hands of both primary (next in line) and secondary (following) internal customers before ultimately being received by the external customer. Figure 1 below shows an example of how the customer supplier chain begins with an external customer need and ends when that need external need is fulfilled. Notice, however, that many internal customers needs must be effectively met in order to provide quality service to the external customer.

Figure 1: The Customer Chain The figure shows an external customer need entering the customer chain on the left side of the diagram. The person who serves the external customer, such as a caseworker, is now dependent on program development to provide adequate programs. Program development is also a customer of the service provision team. Service provision is a customer of the outcome

assessment group. This entire chain of customer service drives external customer satisfaction, and can be measured.

Customer Needs
To ensure continuous customer satisfaction, we must meet the needs of the customer. This can only be done if we have a clear understanding of those needs. Once customer needs are understood, they must be defined and measured from the customer's perspective, not yours. Measuring need from the customer's viewpoint can be a painful experience for many organizations. Information systems are often not in place to know how you're doing in meeting customer needs from their perspective. For example, customers may have a need for "on-time delivery" of a service. Your customer considers a service delivered on time if it is received on the date delivery was originally requested. Your organization, however, may measure "on-time delivery" based on when service delivery was scheduled. It should be evident that customer opinions of good service may not always match organizational opinions or standards. The four principles of ISDS are critical to the success of any organization. By focusing on the needs of our customers, and engaging and empowering people to make recommendations and decisions based on facts, you can continuously improve all operations for the benefit of customers, employees and other stakeholders. Section Complete You have now completed the "How Six Sigma Works?" section. The section will cover some important concepts that you need to know before beginning to learn the DMAIC process.

Key Point
ets FasTrack Summary 1 of 3: What term is used to describe the end user whose needs should be met by your product or service? Answer: External Customer

Key Point
ets FasTrack Summary 1 of 3: What term is used to describe the end user whose needs should be met by your product or service? Answer: Internal Customers

Key Point
ets FasTrack Summary 3 of 3: What is the most important thing to remember when measuring customer satisfaction? Answer: Measure from the view point of the customer.

Required Knowledge For Six Sigma


Previous Section Review
If you took a break since you read the last section, please take a moment to review the following paragraph and refresh your memory. Six Sigma tools and processes are often used to achieve performance excellence. Since performing Six Sigma organization wide is a daunting task, organizations often use the ISDS concept to model the organization into processes and measures, and ensure accountability. This model is based on a set of principles and philosophies that have been proven successful in organizations worldwide.

This Section Overview


Since this course is a FasTrack version, every attempt is made to speed your progress and provide you with the bare essentials needed to begin applying Six Sigma. As a result, we have glossed over the Analytical Tools, Decision Tools, and Process Management. Although you have at least a conceptual understanding of what these tools and processes are for, there are some specific concepts introduced in these courses that are critical to a good understanding of Six Sigma. The section you are about to read fills in the gaps of what you know, by covering those nuggets of critical information buried within the three full-length courses. When you finish learning about the four, distinct concepts in this section, you will be ready to begin learning DMAIC.

Sample vs. Population


What is the difference between a Sample and a Population?
You can collect information from ALL of the relevant things (every employee) or you can sample a smaller sub-group of relevant things and use their results to represent the entire group (20% of the employees). When you collect data from everything in your relevant data set, this is called a "population" of data. Populations are denoted by a capital "N." For example, if you have 450 employees and you asked each one of them which flavor of ice cream they prefer, you have conducted a population analysis where N = 450. Gathering population data is also called performing a "census" of your data. When you collect data from a representative portion of your entire relevant data set, this is called a "sample" of data. Samples are denoted by a lowercase "n." If you instead only asked 100 of your 450 employees which ice cream flavor they prefer, you would have conducted a sample analysis where n = 100. Gathering population data is also called performing a "sample" of your data.

What makes data "relevant?"


If you are performing a study of employee satisfaction in your organization, your population would include every single employee. This makes sense, since every employee has a relevant stake in the company's overall satisfaction. Consider, however, an employee satisfaction study of only your Human Resources department. In this case, only HR employees' data would be relevant. You may have 450 total employees, but if only 30 of them work in HR, then your population size for the relevant data set is only 30. When determining whether or not you are performing population or sample analysis, you must first decide who your relevant population is. In the first case, the entire organization is relevant. In the second case, only the HR employees are relevant.

Why should I discriminate between "n" and "N?"


Because in the case of a population analysis, "N," you have 100% of the relevant data. This means that, assuming no one made any mistakes in your data collection, you have almost complete certainty that your data accurately reflects your relevant population. When you perform a sample analysis, "n," the accuracy of your results is dependent on how representative the sample ("n") relevant characteristics are to the population ("N"). In other words, how well the sample resembles the population. Logically, if you only ask 5 people out of 5,000 you will have much less accurate data than if you ask 500 out of 5,000.

Key Point
ets FasTrack Summary 1 of 2:When you collect information from everything, so that the entire group is represented in your

data, you show it with an "N". What is this group called? Answer: Population

Key Point
ets FasTrack Summary 2 of 2:If you only show data from a representative portion of a group from whom data is collected,

you show it with an "n". What is this group called? Answer: Sample

What are Source Blocks?


Maintaining Accountability
Just as you sign your name to a report, you should let others know that you are the source of any analytical tool you create. Source blocks are small packages of information that are attached to analytical tools so that readers know when the data was generated, where the source data was taken from, and who they can contact if they have questions about the tool. Many times analytical tools, such as charts and graphs, are reused or included in presentations, marketing packages etc. Providing a source block ensures that even if your tool is taken out of context, a reader can clearly determine the timeliness of your data and contact the author if questions arise. By requiring clear documentation of authors and dates, source blocks help maintain accountability for analysis tools and encourage you to produce accurate work. They also prevent others from misinterpreting your data or using outdated information.

The Typical Source Block


Source block formatting is the same for all data analysis tools. You should know what information goes into a source block and the standard way they are constructed. Each source block looks like a small table and should contain, at a minimum, the following information: When: This is the date when the data was collected, not when the tool was created or revised. This value may be an exact date, a quarter, or even an event. If you are unsure about what to put here, ask yourself what information that a reader would require to find the exact information you used in creating your chart. Where: This is the physical source of the data. The "Where" entry should provide enough guidance so that any employee could locate the exact data used for this particular tool. Make sure to specify exact locations, such as file paths or document numbers, if they are available. Who: The "Who" entry lists all employees that created the tool. It is provided as a reference so that coworkers may identify the authors of the tool in case they have questions, corrections, or additions. Figures 1 and 2 show example source blocks. Note the level of detail provided in each section of the source block and the variation of the two styles. Locating data in a small company is dramatically different compared to a multinational conglomerate. Make sure you provide enough information for your organization.

Data Source Information When: First Quarter, 2003 YTD Where: Doc #11354-1 Human Resource Funding, P 19-27

Who: K. Abrahams x3386, C. Fenwick x1914


Figure 1: A Typical Source Block from a Large Organization

Data Source Information When: October 3, 2003 Where: Accountant Report (From J. Peterson) Who: Karen in Human Resources
Figure 2: A Typical Source Block from a Small Organization Source blocks should be attached to every data management tool you produce. In fact, it is a good practice to attach the source block prior to completing the tool to ensure your chart will be accurately represented if someone pulls your chart off the printer or your desk while you are at lunch. Source blocks may be placed in any convenient location on your tool, but generally they are kept in the lower right hand corner for consistency.

Key Point
ets FasTrack Summary 1 of 4: When displaying data it is good to show the readers what the data is and where it came from. What is used to show this? Answer: A Source Block

Key Point
ets FasTrack Summary 2 of 4: What should be placed in the "When" portion of a source block?

Answer: The date when the data was collected.

Key Point
ets FasTrack Summary 3 of 4: What should be placed in the "Where" portion of a source block?

Answer: Location of the data source.

Key Point
ets FasTrack Summary 4 of 4: What should be placed in the "Who" portion of a source block?

Answer: Who created the too and collected the data.

Types of Data
Attribute Data vs. Variables Data
Before we look at control charts in depth, it is important to establish an understanding of the difference between the two types of data that control charts display. This is important because the two major categories of control charts only work with their appropriate type of data. Make sure you completely understand this section before proceeding. Attribute Data Attribute data is any form of data that can be counted as individual events or items. Attribute data points will always be a whole number or count of some type of data that can only exist in two states. A good way to remember this is to think of a light switch. A switch is either on or off, it is never partially on or partially off. If you checked a light switch at noon every day for a month, you could count how many times the switch was on. This would be a set of attribute data. Some examples of attribute data sets are shown below.

Number of repeat offenders (Did they repeat? If so, then count them.) Quantity of defective units (Were the units acceptable? If not, then count them.) Project days on time (Is the project on time today? If not, then count it.) Sick children (Is the child sick? If so, count him/her.) Employee performance issues (Is there an issue? If so, record an issue event.)

Variables Data Variables data is any form of data that is measured in more than two states. In other words, anytime your data value can be represented in more than a "count it or don't count it" fashion, you are dealing with variables data. Consider the following examples of variables data. The examples provided are similar to the attribute data examples above, but these have been modified to clearly illustrate the difference in the two types of data.

Severity of repeat offense: 1 to 10. (How bad was it?) Total cost of defective unit replacement. (What is the dollar amount?) How far behind is the project? (How many days is it behind?) How high is the child's temperature? (What is the thermometer measurement?) How urgent is the issue: 1 to 5. (How urgent is it?)

Other more typical variable data sets include:


Time (days, months, weeks, hours, etc.) Cost (dollars, cents, etc.) Height, weight, length, etc.

Pressure ... or any measurement value!

Key Point
ets FasTrack Summary 1 of 4:What kind of data can be counted as individual items or events? Hint: It is always a whole

number. Answer: Attribute or countable data.

Key Point
ets FasTrack Summary 2 of 4: What kind of data is an exact measurement of a value taken at intervals? Hint: It is always an

i.e.: measurement, weight, speed, time. Answer: Variables data or measured data.

Key Point
ets FasTrack Summary 3 of 4: If you were charting the number of times the copy machine has been left on overnight, what kind of data would that be, attribute or variable? Answer: Attribute

Key Point
ets FasTrack Summary 4 of 4:If you had to tell your doctor what your temperature has been what kind of data would you use? Answer: Variable

Performance Indicators
What Is An Indicator?
"Indicators" are metrics (or standards of measurements) that measure the outcomes of a process or process sub-step. Much like a speedometer tells you how fast your are going and if you are breaking the speed limit, an indicator is a gauge of process performance that tells you how well a process is performing and if its performance passes an acceptable limit. For example, if you track how many customer complaints are filed for a certain department, you are tracking an indicator. Many organizations track indicators to some degree, but few organizations link them to processes or properly select them. Line graphs, such as the one shown in Figure 1, are often used to display indicators. Indicators may also be created using pie charts or bar graphs.

Figure 1: A Quality Indicator As you can see from the figure above, Indicator line graphs have a good arrow indicating the desired direction of line graph movement and a target indicating the desired direction or customer valid requirement. The good arrow shows the direction that the indicator "should move" for good results. For example, if you are looking at an indicator that shows "number of errors," clearly fewer errors are better and therefore the good arrow would point downward. Indicators with upward pointing good arrows might include "customer satisfaction rating," "% complete applications," etc. The target line, or bar in some cases, shows the acceptable limit of the indicator or the goal that your outcomes are trying to achieve. Targets can be constant or they can change over time. How these targets are established will be discussed later in Checkpoint 13, but the important point to remember about targets is that they denote the "goal" of the indicator.

When an indicator is not meeting its target, the distance between the line and the target value has a special name: the "gap." The gap is the difference between what the current performance is, and the target value for this indicator. Whenever you hear someone refer to the gap in a process, they are literally referring to an under performing indicator value. The line graph should move toward the target in the direction of the good arrow, or remain past the target in the direction that the good arrow points.

Key Point
ets FasTrack Summary 1 of 2: What is used to track performance of a process?

Answer: Indicator

Key Point
ets FasTrack Summary 2 of 2: What tools are used to show in a line graph where the best outcomes should be?

Answer: Good arrows and target lines.

Performance Indicators
The Types Of Indicators
Indicators come in three types depending on what is tracked and how this data is used: quality indicators, process indicators, and mission critical indicators. The difference between the indicator types can be subtle, but this "layered" approach is one of the most vital characteristics of a successful Six Sigma deployment.

Quality Indicators
Quality Indicators measure direct conformance to the customers' valid requirements or satisfaction levels. Quality indicators can measure conformance anywhere in the process or even after the process has been completed. Most often, however, quality indicators are measured at the end of the process. Quality indicators directly link to customer valid requirements or another aspect of customer satisfaction. For example, if you are a contractor with a process of "build a house" then one quality indicator would be "houses built on time." Building houses on time is a customer valid requirement of the land developer you work for. Notice that quality indicators offer a direct "rating" of how well a process is meeting a customer (internal or external) need. Traditionally, quality indicators are denoted by a "Q" or a Q in a circle.

Figure 1: A Quality Indicator

Process Indicators
Process Indicators are selected to measure outcomes within the process that drive quality or other outcome measures. These indicators show how certain portions of the

process are performing and, if correctly set, will provide early warning that a quality indicator may be affected. In order to provide this early warning, most process indicators are set upstream, or early in the process, and usually measure a critical step in the process. For example, if your process is "build a house," then clearly it is critical for the building materials to arrive on time. If the on-time arrival indicator of the building materials does not meet its target, then the overall quality outcome indicator of "houses built on-time" will surely suffer. Traditionally, process indicators are denoted by a "P" or a P in a circle.

Figure 2: A Process Indicator

Notice that Figure 2 is a process indicator for Figure 1. Logically, the % of employees trained in application processing will directly affect the process quality indicator of application processing errors. Remember, process indicators are also predictors ("P") of quality indicator outcomes. There can be many process indicators that drive a single quality indicator's performance.

Mission Critical Indicators


Mission Critical indicators are high-level indicators that directly link to organizational goals or objectives. Just as process indicators drive quality indicator performance, when quality indicators link to and drive mission critical indicators perform well. Of course, this all relies on well-defined indicators, well-selected measures, and correctly mapped processes. Mission critical indicators can be viewed as a link between process management and strategic planning. Overall organization strategy is designed to meet organizational objectives through strategic planning. Strategic planning success is defined by performance of mission critical indicators, which are in turn driven by "Q's" and "P's." Traditionally, mission critical indicators are denoted by a "M" or a M in a circle. Although "M" indicators are not discussed in depth during this course, it is important to understand their purpose and relationship to process management.

Figure 3: The P-Q-M Relationship Figure 3 shows how "P" and "Q" indicators in the "Process Applications" process drive the overall mission critical outcome indicator "% customer Satisfaction With Application Processing." Notice that the lower layer indicators, P and Q, directly affect the success of the higher layer indicator M. Assuming the indicators have been properly selected, if the lower level indicators improve, then the higher level ones will as well. This simple concept is one of the foundations upon which process management and Six Sigma are built. Now that you understand the three types of indicators (P,Q,M) you need to learn how to identify and create good indicators for your process.

Selecting Indicators
When establishing indicators, better results are achieved when the indicator focuses on nonconformance, or the pain to the customer, rather than an arbitrary output level. For example, rather than measuring how many units ship per day, measure how many units arrive to the customer correctly. Some other examples of indicators that follow these guidelines are listed below:

Number of invoices sent containing errors. Percent of services provided later than customer requested delivery date. Number of lost phone calls. Percent of hours of system-down time per month. Number of lost time injuries per 100 employees. Food stamp error rate

Key Point
ets FasTrack Summary 1 of 3: What term, normally written as a "Q" or Q in a circle, is used to describe measures of how

well we are meeting or have met our customers' valid requirements? Answer Quality Indicator

Key Point
ets FasTrack Summary 2 of 3: What term, normally denoted by a "P" or a P in a circle, is used to describe how well a

portion of the process is performing? Answer: Process Indicator

Key Point
ets FasTrack Summary 3 of 3: What term, normally denoted by an "M" or a M in a circle, is used to describe the link to

organizational goals and objectives. Answer: Mission Critical Indicator

Indicators
The Vital Role Of Indicators In Six Sigma
Now that you have an understanding of Six Sigma, the ISDS and its components, consider this graphic analogy that has helped many understand how all of these concepts work together. Once an organization is modeled using the ISDS system, measures can be used to monitor overall organization performance.

Figure 1: Making Indicators Go In The Direction You Want Them To Go As Figure 1 shows, in simple graphic terms Six Sigma uses "systematic common sense" tools and techniques to make indicators go in the direction you want them to go. If an indicator is not meeting its target, something is wrong which will in turn affect downstream business processes. The DMAIC improvement method, and process management, are used to continually smooth out indicators and ensure that they remain below their targets. These are two significant characteristics of a stable business process: it has consistent (smooth) performance, and it is capable (meets target).

Figure 2: Making Indicators Go In The Direction You Want Them To Go, And Smoothing Them Out. In simple graphic terms process management and DMAIC makes indicators go in the direction you want and "smoothes" them out. The "smoothing" relates to achieving consistency in operations. Customer needs are met predictably and consistently, with the processes to meet these needs always improving and becoming more efficient. DMAIC is often responsible for the dramatic changes in direction of indicators, while process management generates consistency and stability.

Bringing It All Together


In summary, the ISDS is format upon which an organization can be structured for Six Sigma application. Six Sigma is applied through the use of strategic planning to define goals, DMAIC projects to achieve breakthrough improvement, and process management to continually refine performance and improve overall quality. When all of these things are done correctly, an organization can achieve great things. In the future, you may find it helpful to take the in-depth ets courses on Analytical Tools, Decision Making Tools or Process Management. These courses provide step-by-step instructions for performing each process and a wealth of real-world examples. Section Complete You have now completed the "Required Knowledge For Six Sigma" section. The next section will begin our discussion and demonstration of the Six Sigma DMAIC process.

Key Point
ets FasTrack Summary 1 of 2: When we say that a process is "capable" what do we mean?

Answer: That the process and its indicators are meeting their targets

Key Point
ets FasTrack Summary 2 of 2: When a process consistently performs, we say that the process is what? Answer: Stable or smooth.

The DMAIC Process


What Is DMAIC?
The ets Six Sigma DMAIC Method is a formal, step-by-step procedure for solving problems. Using logical steps and simple checkpoints, an individual or team can use DMAIC to solve almost any problem, regardless of the issue's complexity or scope. A "problem" in the context of organizational problem solving is any issue or situation that is undesirable. For example, "low customer satisfaction, high employee turnover, too many incorrect applications, or low staff morale" represent the types of "problems" that can be resolved using this process. When implementing Six Sigma in an organization the need for improvement arises frequently. Business processes may fail to meet targets. Actions may not follow strategy. Projections may not be realized. DMAIC is the systematic way of determining the causes of these undesirable conditions and correcting them in the best manner possible. If you have a problem that needs to be fixed, DMAIC is the procedure for fixing it.

Learning Six Sigma Through DMAIC


This course will introduce you to the DMAIC method, teach you how to use it, and provide practical insight into DMAIC applications. Since DMAIC uses many of the analytical and decision-making tools, this course will give you an opportunity to see many of these tools applied in context. Also, DMAIC is similar in many ways to process management so you will also get experience using a logical, Six Sigma process. Although there is more to Six Sigma than DMAIC, the concepts and techniques you will learn in this course will give you the ability to follow most Six Sigma efforts and certainly learn more tools and techniques, if so needed. The DMAIC method consists of five steps and 33 checkpoints. Like process management, the DMAIC method uses the cyclical design philosophy of P-D-C-A (Plan, Do, Check, Act). Any procedure based on P-D-C-A stresses accurate planning based on data, relevant action based on the plan, verification of results due to actions, and reinforcement of results through replication of improvements and the procedure itself. Figure 1 below introduces the 5 major steps of the DMAIC method and how they are designed upon the P-D-C-A cycle. We will discuss these steps in detail as you work through this course.

Step 1 Step 2 Step 3

Define Measure Analyze Identify potential root causes Verify root causes with data Improve Plan

Step 4

Develop and pilot Implement Do Check

Step 5

Control

Quantify improvements Standardize Plan for the future


Figure 1: The ets Six Sigma DMAIC Method A Formal Problem Solving Process

Act

Key Point
ets FasTrack Summary 1 of 2: The DMAIC process is a formal step-by-step process that is used for what? Answer: Solving Problems.

Key Point
ets FasTrack Summary 2 of 2: What simple word can we use to describe within an organization if we say that a situation is undesirable, such as high turnover rate, low customer satisfaction, etc. Answer: We have a problem.

Why The DMAIC Method Is Important


In the past, students have asked why it is important to learn the DMAIC process. To help you better understand the need for DMAIC; let's take a moment to look at the appealing characteristics of this process.

DMAIC Solves "Problems"


The DMAIC method is important because it is a successful, fact-based, and "easy-tocommunicate" process for solving problems. Problem solving is important because, simply put, all organizations have "problems." When something goes wrong and customers get upset, it is a problem. When a department isn't meeting indicator targets or goals, it is a problem. When a process costs too much time or money, it is a problem. Even successful organizations are faced with adapting to changes in technology, competition, or determining ways to improve their products or services. Finding ways to meet these challenges are also problems. In the traditional sense, the word problem has a negative connotation and is often interpreted as "obstacle." Problem also means "a question raised for inquiry, consideration, or solution." When this course refers to problems, both interpretations of the word apply. For example, problem solving can be used to remove obstacles such as "Reduce employee turnover to less than 3% per year." By the dual definition provided earlier, problem solving can also be used to find answers to questions such as "How can we increase customer satisfaction?" Remember that problem solving does not apply only to fixing negative situations, but also to finding better ways to do things.

Why DMAIC Is Effective


Now that you understand what problems are, let's talk about why the DMAIC method is an effective tool for solving problems. Fixing a problem, and fixing a problem effectively are two very different situations. For example, consider the problem of having a flat tire. One solution to this problem is to buy a new car. Is that the most effective solution? What about buying a new tire, or maybe even simply patching the one you have? Problems have many solutions, but in most cases the majority of these problems are not very effective. Effective solutions provide the most gains for the least cost, and prevent the problem from happening again (if possible). The DMAIC method is really a complex decision making tool that walks you through a logical thought process in which data is gathered and analyzed to generate solutions based on fact, not speculation. In the case of fixing your flat tire, the most effective solution becomes much clearer when "facts" are considered, such as cost. In the case of many organizational problems, however, it is often difficult to arbitrarily determine which solutions have the least cost or the highest

likelihood of success. In some cases, even defining the problem and effectively communicating it can be difficult! Following the DMAIC problem solving process ensures that your problem is fixed using the most effective manner possible based on the data available to you. Statistically speaking, DMAIC ensures that problem solutions are likely to succeed by providing a series of steps that eliminate common errors in problem solving, and a structure that enforces effective communication and decisions based on fact. The DMAIC method also verifies the effectiveness of a solution, promotes the sharing of best practices, and helps prevent your problem from returning. As a procedure for solving problems, the ets Six Sigma DMAIC Method:

Provides analytical consistency be ensuring that all problem solving teams use a standardized approach to data analysis and decision-making. Helps team members collect, organize, and analyze information and monitor how they are doing. Ensures communication between team members is accurate and consistent. Communicates team progress to management. Communicates information to non-team members, and can solicit non-team member feedback. Documents the organization's record of continuous improvement.

The Engine Of Change


The DMAIC, along with any other formalized problem solving procedure, is the engine that drives change in an organization. Problem solving begins with an issue, and ends with an effective solution. During this process is where things change, breakthroughs occur, and organizations realize their potential. As a result, formal problem solving is a critical component of every systematic management systemit is where the change occurs. DMAIC teams fight the battles that win your organizations war for improvement. Here's a helpful analogy to show how DMAIC fits into the grand scheme of performance excellence: Think of your organization's success (achieving performance excellence) as writing a book. Analytical and decision-making tools are the words used to communicate ideas. DMAIC uses these words to create "chapters" about your organization's improvement. All of these chapters follow an underlying "plot" that is defined in process management, and all of the plots are part of the on-going story of your organization's performance excellence.

Key Point
ets FasTrack Summary 1 of 2: Besides solving problems, what else does DMAIC do for you? Answer: It finds the best way to do things.

Key Point
ets FasTrack Summary 2 of 2: Problem solving start with an issue and ends with what? Answer: An effective solution.

What is the DMAIC Method?


DMAIC: A Way To The Best Solution
The ets Six Sigma DMAIC method is a way to solve problems. It was designed to effectively guide you through problem resolution, set the stage for continuous improvement, and enable you to communicate your approach to othersall while facilitating quick understanding and decision making. You can think of the DMAIC method as a step-by-step procedure that helps a team troubleshoot a problem and find the best solution.

Figure 1: The DMAIC Method The ets DMAIC method is composed of 5 steps and 33 checkpoints, each of which represents a favorable outcome in the problem solving process. These steps and checkpoints are used to help segment the problem solving process into a logical series of actions. By using a series of steps, teams can complete the problem solving process by following step-by-step instructions. In the context of this course, "steps" refer to the major operations in the DMAIC process: Define, Measure, Analyze, Improve and Control. The term "checkpoints" refers to the smaller actions that make up the larger steps. For example, "Step 1: Define" has 5 checkpoints in it. During this course, we will introduce each checkpoint of the DMAIC process and explain it in the order in which it is used. In addition to the steps and checkpoints, the ets approach also incorporates a DMAIC Improvement Story into the problem solving process. Just as a movie storyboard provides the visual outline of what happens in each scene, an improvement story provides a visual overview of what happens (or will happen) in each step of the problem solving process. In both movie making and problem solving, it is critical for all members of the workforce to understand what is going on and to have a clear picture of what happens next. Improvement stories are great tools for communicating and synchronizing teams. The following sections will introduce both the DMAIC Method and the three common forms of DMAIC Improvement Stories. You will also learn about two fundamental philosophies upon which the ets DMAIC problem solving method was designed: P-D-C-A and the "funnel" model. All of these topics are relevant to the DMAIC problem solving method as a whole, and are referenced throughout the course. After these fundamental concepts are introduced, we will begin working through the DMAIC process, step-by-step.

Key Point
ets FasTrack Summary 1 of 3:How many steps and checkpoints does the ets DMAIC method use? Answer 5 Steps and 33 Checkpoints.

Key Point
ets FasTrack Summary 2 of 3: Each letter of DMAIC represents a step. What do the letters stand for?

Answer: Define Measure Analyze Improve Control

Key Point
ets FasTrack Summary 3 of 3: The DMAIC uses a communication tool, because it is easy for everyone in the organization

to "speak the same language" and a picture is worth a thousand words. What is the name of this tool? Answer:

Overview
The DMAIC Method: Steps And Checkpoints
The ets DMAIC method is composed of 5 steps and 33 checkpoints, each of which represents an activity in the problem solving process. Whenever your or your team must solve a problem, begin at Step 1 of the DMAIC method and follow the checkpoints until you reach the end of the process and have arrived at the best solution. The steps and checkpoints will guide your team through a logical, systematic, fact-based approach to finding a solution. The major steps of the DMAIC process are listed below, along with a brief overview of the checkpoints in each respective step. Please note that DMAIC steps name are often used interchangeably with the step's position in the DMAIC sequence to identify a step of the process. For example, the first step of the DMAIC process could be called "Step 1," or referred to by its step name "Define." To help you become comfortable with this practice, we will use both step names and numbers throughout the course.

Introducing: The 5 Major DMAIC Steps


Step 1: Define
Step 1checkpoints are centered on clearly defining and communicating the project's purpose, scope and significance. The Define step also documents the goal of the problem solving process and quantifies its significance. In this step, the team begins with a general issue and begins to understand and define exactly what the problem is.

Step 2: Measure
The Measure checkpoints narrow the project's focus from a broad problem to a more specific issue. During this step, a measurement system is developed to determine how bad a problem is and gauge improvement success. Step 2 also includes the development of a problem statement and target.

Step 3: Analyze
Step 3 checkpoints identify and verify the root causes, helping a team find the most likely causes of the overall problem. During this step, the improvement team's focus narrows precise issues that are confirmed to be the most significant contributors to the overall problem identified in Step 1.

Step 4: Improve
Step 4 checkpoints involve the development and implementation of countermeasures to correct or eliminate the verified root causes. Activities in the improve step widen the focus of an improvement team as they work to correct Step 3 root causes and review their effectiveness on correcting the problem as a whole. The Improve step is also the point in which a team shifts from problem identification to problem resolution.

Step 5: Control

Control checkpoints evaluate how well countermeasures affected the root causes, the problem, and the improvement theme. Step 5 also ensures and that the improvement target has been met, and proper steps will be taken to standardize new methods, communicate lessons learned, and recommend future efforts related to this project. All of these steps work together to produce a successful approach to problem solving. It is not critical that you memorize each checkpoint in the process, but you should have a basic understanding of them and their general purpose. You will learn in this course that the DMAIC process begins with a general problem, narrows to a specific issue, and then widens to assess the improvement of the overall problem. This "wide-to-specific-to-wide" approach is one of the most misunderstood, most incorrectly applied, and yet the most critical aspects of DMAIC! We will explain why this is so important shortly.

The ets DMAIC Steps And Checkpoints


The complete list of steps and checkpoints used in the ets DMAIC method is provided in Figure 1 below. You are encouraged to print this list using the included template, and keep it nearby as you progress through this course. Don't be intimidated by the long list of checkpoints? Many of these are very simple and are included simply to ensure proper application of the method. Take a few minutes to read through the list of checkpoints below and see if you can figure out how each checkpoint applies to the general purpose of its step.

Step 1. Define 1. 2. 3. 4. 5. 2. Measure 6. 7. 8. 9. 10. 11. 3. Analyze 12. 13. 14.

Checkpoint The stakeholder and need were identified. An indicator measuring our performance in meeting the need was developed. A theme statement consistent with the indicator was selected. A schedule for completing the five DMAIC steps was developed. The sponsor signed off on the projects purpose, scope, and significance. The theme was stratified from various viewpoints and a significant problem was chosen. A target for improvement was established based on the stakeholder's need. The impact of the target on the theme indicator was determined. A problem statement that addressed the gap between the actual and target values was developed. Measurement and data collection systems were developed. The sponsor signed off on the projects focus and target. Cause and effect analysis was taken to the root level. Potential causes most likely to have the greatest impact on the problem were selected. A relationship between the root causes and the problem was verified with data.

15. 16. 4. Improve 17. 18. 19. 20. 21. 22. 23. 5. Control 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.

The impact of each root cause on the gap was determined. The sponsor signed off on the verified root causes and impact on the gap. Countermeasures were selected to address verified root causes. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility. Barriers and aids were determined for countermeasures worth implementing. The action plan reflected accountability and schedule. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement. Incorporated lessons learned from the pilot into the full-scale action plan and implemented it. The sponsor signed off on the action plan and expected results. The effect of countermeasures on the root causes was demonstrated. The effect of countermeasures on the problem was demonstrated. The improvement target was achieved and causes of significant variation were addressed. The effect of countermeasures on the theme indicator representing the stakeholders need was demonstrated. A method was established to document, permanently change, and communicate the revised process or standard. Responsibility was assigned and periodic checks scheduled to ensure compliance with the revised process or standard. Specific areas for replication were identified. Any remaining problems of the theme were addressed. Lessons learned, P-D-C-A of the ets Six Sigma DMAIC Method, and team growth were assessed and documented. The sponsor signed off on the results and next steps.
Figure 1: ets DMAIC Steps And Checkpoints

Each checkpoint will be discussed in depth throughout the remainder of this course.

Key Point
ets FasTrack Summary 1 of 5: What is the general purpose of Step 1: Define?

Answer:
Defining the project's purpose and scope Helping the team understand their project Establishing a timeline for completing it

Project Charter is developed to document the above.

Key Point
ets FasTrack Summary 2 of 5: What is the general purpose of Step 2: Measure?

Answer:
Stratify the theme I Identify a problem to improve

Key Point
ets FasTrack Summary 3 of 5: What is the general purpose of Step 3: Analyze?

Answer: Determine Root Cause.

Key Point
ets FasTrack Summary 4 of 5:What is the general purpose of Step 4: Improve?

Answer: Develop Counter Measures

Key Point
ets FasTrack Summary 5 of 5: What is the general purpose of Step 5: Control?

Answer:
Ensure that results are evaluated Countermeasures remain in place Changes are standardized Additional work and "lessons learned" are recognized

DMAIC Improvement Stories


The DMAIC Improvement Story
A DMAIC Improvement Story is a visual tool used by teams to help track and communicate their progress in applying the ets Six Sigma DMAIC Method. When a team is performing DMAIC problem solving, graphical tools (flowcharts, histograms, matrices) and explanatory text are used to document progress and communicate why decisions were made, or what the outcomes of actions were. When this documentation is compiled into a single package and placed in sequential order, the package is called an "improvement story." The name "story" makes sense, since the documentation and analytical / decision making tools used in the package "tell the story" of a team's improvement efforts. A DMAIC story is the documentation outcome of the DMAIC method, just as Process Control Systems are used to document process management. It is not unusual for a single organization to generate hundreds of DMAIC stories each year, especially during major improvement initiatives. Using improvement stories standardizes communication and helps others in an organization quickly understand everything about your improvement project. Improvement stories can be presented numerous ways, but they are typically packaged in three different formats: Storyboard: Storyboards are large improvement stories, usually attached to a poster-sized document that is laminated or photocopied and posted in a highly visible area (usually relevant to the improvement project). Figure 1 shows the layout of one such storyboard.

Figure 1: A DMAIC Story board The storyboard presented here outlines the DMAIC process and shows commonly used tools or techniques for each step. Typically, teams attach letter sized (8.5 x 11 in) pages of their DMAIC story directly onto the storyboard using tape. For example, once a "Project Planning Worksheet" is completed, the team could attach this document directly to storyboard over the "Project Schedule" picture. Storyboards are like "blueprints for building improvement." Each step, such as "2. Measure" consists of one or more pages that use charts and text to communicate a team's reasoning for selecting a particular problem to improve, why they used specific countermeasures and practical methods, and what the final results of the process were, etc. Although the size and content of each improvement story will be different, the general structure will always be the same. Experience has shown that displaying the DMAIC Storyboard in a team's work area helps the team more smoothly progress through the problem or improvement activities. Posting the story board also enables other staff members to contribute ideas, or take a role in the team. At the end of the project, the DMAIC Storyboard provides a lasting record of the team's accomplishment that can be used to encourage replication in of lessons learned in other organizational areas.

Improvement Story:
Imagine taking all of the letter-sized pages attached to a completed project storyboard and binding them as a booklet. This approach is referred to simply as an improvement story, or "DMAIC" story.

DMAIC stories contain the same information that is attached to a storyboard, but are much easier to handle and distribute. In many cases, a team will use both a storyboard and improvement stories to document and discuss their project. Figure 2 shows an example of a DMAIC improvement story, and the type of pages that would be attached to a DMAIC storyboard.

Figure 2: A DMAIC Improvement Story Improvement stories traditionally have a cover page that lists the improvement theme and team members.

One-page Story:
A one-page improvement story is created when an entire DMAIC project is summarized and displayed on a single page. Unlike a full size improvement story or storyboard, a one-page story doesn't show every single chart and graph. Instead, a one-page story provides a summary of a DMAIC project and provides only the most pertinent information related to team decisions and outcomes. Figure 3 shows an example one-page improvement story. Notice how only summary information is provided for each of the DMAIC steps.

Figure 3: A One-Page Improvement Story DMAIC teams regularly use all three methods shown above to document problem solving or improvement. It is important that you are familiar with these three formats, and understand that they are all legitimate methods of recording DMAIC improvement projects.

Key Point
ets FasTrack Summary 1 of 2: The visual tool used by teams to help track and communicate their progress in applying the ets Six Sigma DMAIC Method is called. Answer: DMAIC Improvement Story

Key Point
ets FasTrack Summary 2 of 2: What three formats are typically used to document DMAIC projects?

Answer:
DMAIC story boards DMAIC stories, One-page DMAIC stories.

The DMAIC Problem Solving Funnel


General-Specific-General: The DMAIC Problem Solving "Funnel"
Like PDCA, the Problem Solving "Funnel" is another effective design principle that was used to develop the DMAIC process. When using the DMAIC method, a team is led through a series of steps that begin with a broad problem and then define, prioritize, and determine the most significant problem, the most likely cause of the problem, and the solution most likely to succeed. The process of DMAIC is one of continual defining, filtering, ranking, and refining to always select the significant few items, while avoiding the trivial many. By using this approach, teams begin with a general issue and whittle it down into a single, actionable countermeasure. This specific countermeasure is believed to have the highest impact on the overall problem, therefore it is then resolved and the team assesses the overall effect that the improvement had on the general issue.

The Importance Of The Funnel Approach


The funnel approach built into DMAIC is important to problem solving success because it forces teams to avoid some of the most common traps that non-structured problem solving teams fall into. One of the common mistakes of non-funnel based problem solving methods is being too general with the problem statement. For example, a team may try to solve the problem "Customer Satisfaction Is Low" by immediately coming up with countermeasures, or plans for action. Will they work? Maybe. How would the team know? When such a broad problem is attacked, there are far too many factors involved to determine if the team's changes really had any effect on the problem, or if something else created the change. Another common pitfall of non-funnel based approaches is trying to "fix everything." One or two well-implemented and monitored countermeasures have a much higher likelihood for improving a problem than trying to implement 14 countermeasures. Inexperienced improvement teams will sometimes assume that applying every solution to a problem is a sure-fire way to fix the problem. In reality, this approach usually spreads resources too thin and results in an ineffective, unpopular, and cumbersome solution. The funnel approach forces teams to make logical, fact-based decisions. Remember all of those analytical and decision-making tools you learned about earlier? Many of them are used in the prioritization and filtering process of DMAIC! The DMAIC funnel emphasizes a "crucial point" in problem solving, a point in which teams are forced to make analytical decisions and only pertinent data is allowed to proceed. These decisions are not always easy, but they help teams avoid common problems and rapidly arrive at effective solutions, rather than becoming mired in a bloated or overzealous attempt. As Pareto taught us, in most situations 80% of the problems are caused by only 20% of the issues. The ets DMAIC method helps teams find and exploit these high-value 20% issues to get the most improvement for the least amount of effort. Once huge improvement gains are made, or the "bleeding" has been stopped, there is plenty of time to go back and consider implementing other, less valuable countermeasures. Remember, PDCA means on-going and continuous improvement!

A Visual Example Of The Funnel


Figure 1, below, shows a conceptual diagram of how data is "funneled" by your team as you follow the DMAIC Method, resulting in pertinent solutions to a specifically defined problem.

Figure 1: The Problem Solving "Funnel" 1. 1. 1. The funnel shows how a general problem theme, such as "Customer Satisfaction Is Low" enters the funnel. 2. Brainstorming is used to generate a list of potential problems that contribute to low customer satisfaction. 3. Multi-voting is used to filter out low-value or insignificant problems. 4. A selection matrix helps teams choose the best problem to proceed with, based on data. 5. Stratification steps are used to break a problem down into its data component parts and clearly define what the exact problem is. 6. A problem statement is used to focus the team's improvement efforts on a quantifiable improvement target.

7. Potential causes are suggested and another series of filters are used to reduce causes into the most likely root cause. 8. Once a root cause is suspected, root cause verification is used to ensure the team has selected a cause that will drive improvement in the problem statement. 9. Now that a cause is known, the team finally begins to list potential countermeasures (solutions) to the problem. 10.Countermeasures are filtered out based on data, the most effective and solutions emerge. At every phase in the funnel, the team is directed toward "the highest value for the lowest cost." Since every decision in a DMAIC process uses structured analytical and decision making techniques, your team's outcome has a statistically high probability of success. Does this mean it is guaranteed to work? No, but your countermeasures have the best chance of succeeding. You also know, in order, what are the next likely solutions to try if your first choice doesn't work out.

If DMAIC Is So Great, Then Why Do Some Countermeasures Fail?


In case you are curious, countermeasures that do not work out are usually not due to poor design or selection, but rather fail in implementation. In most cases, a team was unaware of a law, mandate, or policy that prevented their countermeasure from being implemented. In these cases, having good improvement story data can be a strong argument for considering changes in company policy especially when these changes can be directly linked to huge savings or improvement. In other cases, teams may be provided with bad data or incorrect information. Remember that nothing is guaranteed. Even an approach that has a 99% success rate will fail 1 out of 100 times. Your goal is to make the best decisions you can. Although they may not be perfect, they will most assuredly be better than ad hoc or arbitrary approaches.

Key Point
ets FasTrack Summary 1 of 1: The approach that DMAIC takes toward solving problems resembles what type of figure?

Answer: Funnel

Overview
Summary: The Case For DMAIC
The ets DMAIC problem solving method is a proven, effective method of systematically solving problems and obtaining improvement in an organization. There is nothing magic about the success of this method. DMAIC is simply based on a series of sound principles that combine to produce an efficient method of creating change. The ets DMAIC method is effective because:

It Uses A Step-By-Step Approach


The ets DMAIC method uses a procedural approach broken into steps and checkpoints. This technique makes DMAIC easy, consistent, and helps teams avoid common errors in non-structured problem solving.

It Forces Accountability And Scheduling


A good plan is nothing unless it is executed! The ets DMAIC method includes devices and checkpoints for scheduling action and assigning accountability for project components.

It Communicates Well
The improvement story concept is a key aspect of successful problem solving. Good communication through improvement stories helps synchronize team activities and keep the team on track all while encouraging outside input and replication.

It Aligns To PDCA
The PDCA model is a procedural framework that ensures continuous improvement actually occurs. The ets DMAIC method adheres to the PDCA structure.

It Uses The Funnel Approach


The problem solving funnel principle is another procedural framework that helps teams focus their effort in the right places to drive improvement. Without the disciplined funnel approach, well-intentioned teams can easily drift off course (or onto the rocks).

It Is The Best Blend Of Improvement / Cost


The ets DMAIC method generates rapid improvement by focusing on quick gains first, then exploiting continual improvement opportunities. Quick results and a logical, fact based approach make ets DMAIC the best value in improvement.

It Is An Evolution Of Effective Methods


Recognized as a best practice by international organizations and experts alike, ets DMAIC is a proven method that is continually refined so it remains the most effective organizational problem solving methodology. While other techniques are bloated with

"trends" or "buzzwords," ets DMAIC remains true to its mission of providing solutions without wasting time.

DMAIC Applied
Now that you understand what DMAIC is, and also have a general idea of why it works so well, let's begin discussing the actual step-by-step process. The remainder of this course will walk you through the DMAIC improvement process. We will first cover the checkpoints for each step, and then take a moment to see how these checkpoints are used to produce an actual improvement story. Since the DMAIC method relies heavily analytical and decision making tools, we will review old techniques and even introduce some new ones as the course progresses. By the time you complete this course, you should have a solid understanding of the DMAIC process and be capable of creating an improvement story with a little help from your instructor or resident expert. After that, you'll be an ets DMAIC problem-solving expert!

Key Point
ets FasTrack Summary 1 of 1: What are some of the reasons that DMAIC is an effective problem solving method? Step-by-step approach ensured accountability good communication the funnel approach best blend of improvement / cost and it is an evolved and refined method

and it involves PDCA. What does this stand for: Answer: Plan, Do, Check and Act

Step Overview

Objective:
Define the project's purpose, scope and sponsor, and quantify its significance. The first step in DMAIC, "Define" contains checkpoints that help a team demonstrate the significance of a particular improvement need, with data, and develop a schedule for completing the DMAIC method. DMAIC teams are formed to resolve problems or drive improvement. Logically then, the first step of solving a problem is to begin specifying exactly what the problem is: Who is affected by the problem? How do we know that this situation actually is a problem? At what point will it not be a problem anymore? Once these issues are clarified, the team must establish quantifiable indicators to show where the "gap", or need for improvement, exists. As you may have learned in other ets courses, you cannot effectively improve what you cannot measure. Consider customer satisfaction, since this is usually difficult to accurately measure. Unless you have a scientifically sound manner of gauging your customer improvement, it will be very difficult to tell if you actually improve it. Just because an organization saves money or becomes more profitable does not mean that its customers are satisfied. Gaps must be identified, and improvement needs to be measurable. The Define step helps a team show that a real problem exists and that it is ready to begin building strategy to address this issue. The remainder of the Define step involves laying out this strategy and achieving sponsor approval.

Step Checkpoints
Step Define Checkpoint 1. The stakeholder and need were identified. 2. An indicator measuring our performance in meeting the need was developed. 3. A theme statement consistent with the indicator was selected. 4. A schedule for completing the five DMAIC steps was developed. 5. The sponsor signed off on the projects purpose, scope, and significance.

Key Point
ets FasTrack Summary 1 of 1: What provides evidence of DMAIC improvement need?

Answer: Data

Step 1: Define - Checkpoint 1


1. The stakeholder and need were identified.
The DMAIC method officially begins by identifying the stakeholder and need. Of course, before DMAIC gets underway you should already have an improvement team established and a team leader identified. The improvement team are the people directly involved in performing DMAIC, while the team leader acts as a coordinator, meeting scheduler, and contact person for the team. To complete this checkpoint, your team must identify the stakeholder for your problem, and establish a quantifiable explanation for what the problem is.

Know Your Stakeholder


Stakeholders are literally people or groups that hold a stake in something. Stakeholders can also be thought of as customers, but the term stakeholder here is more robust. Organizations may (or may not) realize that they serve a variety of internal and external customers. Clearly the family that enters your office to apply for service is your customer, but so is your leadership team, the filing department, and any part of your organization that depends on YOU for goods or services. Just as you are expected to provide quality service to a family, you are also expected to provide quality service to entities within your organization. Both the family that enters your office (external customer) and other work departments (internal customers) are stakeholders they all have a tangible interest in your success. Stakeholders also include people who have an even less apparent stake in your effectiveness. Consider the following examples of less obvious stakeholders: A person who owns stock in a private company is a stakeholder. An American citizen is a stakeholder for any governmental agency. The community at large, and especially needy families, are stakeholders for social service organizations. Although this may seem intuitive, it isn't always easy to define your stakeholder. Because you have formed a DMAIC team to solve a problem, two things are suspected to exist: a stakeholder need, and a measure that is not meeting that need. If your DMAIC project was assigned as an outcome of process management, or strategic process management, your stakeholder and need will most likely be provided to you. If the stakeholder(s) for your improvement need are not already defined, obtain consensus with your team regarding who your stakeholder is that has a problem or improvement need. This agreement ensures that your team keeps the proper perspective for fixing the problem: the perspective of the stakeholder and how this problem affects them. Once you have determined the stakeholder(s), write them down.

Know Your Need


An improvement need is the measurable effect that is undesirable to your stakeholder. Your improvement need should explain some negative, measurable effect on your stakeholder, and

explain why this effect is considered negative (if it isn't obvious). The following table lists some example "needs."

Documents must be delivered in 4 working days or less, otherwise they become invalid. Minor workplace accidents are higher than the required target of 3 per year. Customer wait times are too long. Information provided on customer forms is incorrect or incomplete.

Improvement needs can come from many places. Some are obvious, such as extreme dissatisfaction, disasters, accidents, or poorly performing indicators. Other improvement needs aren't so clear, or may be misunderstood. For example, "valve release pressures are in excess of 250 psi" is a valid need but it probably wouldn't make much sense to someone who did not work with valves. A better need would be "valve release pressures are in excess of 250 psi, which can result in damaged equipment." An improvement need, much like a stakeholder, may already be provided for your team. In this case, the Define step will move quickly. On the other hand, some DMAIC teams are established simply to "improve" their overall organization. In this latter case, your team may need to brainstorm an area for improvement and gather some tangible data to prove that a need exists. Providing data for your improvement need is important for two reasons. First, gathering data requires you to create an improvement need that is measurable. Second, data provides credibility to your claim. It is a weak argument to arbitrarily claim that something is bad. A much stronger argument explains why something is bad, and provides data to prove that it is bad, and show how bad it is. Data to demonstrate improvement needs can come from many sources, including:

External or internal client surveys, reports or discussions. Department or organizational-level CFO or "M" indicators. (See Process Management for an explanation of M indicators.) Management requests. Information and ideas from individuals.

This checkpoint is completed when you have clearly documented who the stakeholder is, what the measurable need for improvement is, and why improvement is important to this particular stakeholder. Examples:

The processing time for teacher applications is taking more then 14 days. Teachers are adversely affected by this problem because these certifications are required for them to work in our state. Pizzas are not being delivered to our customers in 30 minutes or less. Our customers demand delivery in 30 minutes, or they become dissatisfied with our product.

The following analytical and decision making tools may prove helpful in this Step:

Control Charts Process Flow Charts Survey/Interview Brainstorming Consensus

We'll briefly show how process flowcharts and surveys can be used to determine improvement needs on the next few pages.

Key Point
ets FasTrack Summary 1 of 3: What are the outcomes of DMAIC Checkpoint 1: The stakeholder and need were identified? Answer: You must identify who the stakeholder is, what their measurable need for improvement is, and why this improvement is important to the stakeholder.

Key Point
ets FasTrack Summary 2 of 3: Who, or what, is a stakeholder? Answer: Stakeholders are people or groups that hold a stake in something your organization does, typically internal/external customers, shareholders, or even the community at large.

Key Point
ets FasTrack Summary 3 of 3:Does data need to be gathered for a DMAIC improvement need? Answer: Yes. Data provides evidence of the need, and a benchmark to measure improvement against.

Step 1: Define - Checkpoint 1


Finding Improvement Needs With Qualitative Analysis
Excerpted from the ets course Process Management. Qualitative analysis, in the context of process management, is a technique of analysis that focuses on "common sense" and simple observation to determine problems. This type of analysis is useful in cases where the root cause of a process issue is obvious and complex analysis techniques are unnecessary or counterproductive. Qualitative analysis techniques include brainstorming, flowchart reviews, multi voting, and simple discussion. For example, imagine that a critical piece of machinery breaks down and drives all of your indicators beyond their limit. Qualitative analysis suggests that the sudden equipment failure was most likely the problem. To confirm this, you simply speak with the process players and verify that everything was within specifications prior to the equipment failure. You can now fix the machine and monitor indicators after the repair to verify that process measures are indeed back to normal. Although qualitative analysis is a legitimate and useful tool, it is not always the right tool. Be careful to avoid over reliance on qualitative analysis and its quick or simple answers. It should only be used in cases where the solution is easy to see, quick gains can be made, or experimentation to find a more precise root cause is required. Over reliance solely on qualitative analysis will yield poor results for your process team. Many process problems are too complex for qualitative analysis, and require the more advanced methods of quantitative analysis discussed later in this section.

Qualitative Analysis With Process Flowcharts


Qualitative analysis is a good tool for reviewing process flowcharts to determine potential areas for improvement or problem causes. You may recall that this concept was introduced during "Step 2: Construct Process Flowchart" and the initial mapping of a process. Let's take a moment to further explore this notion. Because process flowcharts are constructed in a special manner, a great deal of qualitative information can be learned by reviewing their structure. Study Figure 1 for a moment and then read about common qualitative information that can be identified using a process flowchart.

Figure 1: Qualitative Analysis By Reviewing A Process

Common Qualitative Process Flowchart Problems


The following list of common process flowchart problems is provided to help you understand the types of things found during qualitative process analysis. Qualitative analysis is certainly not limited to these items alone. 1. Multiple reviews Multiple reviews exist anytime a process checks or "reviews" something over and over. Although some processes require these checks, most repeated reviews exist out of convenience or have been added to an inefficient process over time. In most cases, reviews can be reduced or consolidated to reduce process complexity and flow time. 2. Rework loops. Since process flowcharts are structured to show the quickest flow as a vertical shape, anytime a flowchart has an arrow that goes back to the top, part of the process is being repeated or "looped." Any process that loops a few times has a significant potential for waste and delays.

Rework loops can be minimized by detecting a rework condition earlier in the process and addressing the causes of the rework need. 3. Idle time (wait time, dead time, etc.) Idle time exists anywhere a process must wait for something to occur before proceeding. Check for process steps that include the word "wait" or involve rework when something isn't ready. Idle time can often be reduced or eliminated by further analysis of the condition that is causing the wait. 4. Too many hand-offs between process players. Anytime process flow moves from one process player to another (such as Adam to Shelia in Figure 1) there is an inherent cost of time, resources, and a risk of problems. Process hand-off points, both internal to a process and between processes themselves, can cause delays or errors. Hand-off points should be scrutinized as much as process steps themselves when looking for problems. Hand-offs can sometimes be reduced or eliminated, but they can always be made better or more efficient. 5. Too many players (or steps) involved. If a process flowchart has a large number of players involved, the chances for problems increase dramatically. Keeping a large group of process players synchronized, trained, and vigilant is a difficult task. Try to find ways to remove non-essential players from the process. This will not only reduce your process complexity, but also free up resources for other processes! 6. Low value added steps (these might not be needed). It is not unusual for process structure to be dictated by tradition or some other arbitrary design. As a result, there is a chance that some steps in a process may add less value then they provide to the process. Low value steps can be identified using the process described below. Once identified, process teams can work to reduce or eliminate these steps from the process altogether. 7. Duplicate steps. Duplicate steps are, logically, any process step that is repeated in multiple places. Although these are not necessarily a problem, they are always an opportunity for improvement or reduction. Duplicate steps can sometimes be consolidated into other steps, or removed completely. You should consider other potential weaknesses based on your team's knowledge of where in the process problems or delays can occur. Since properly constructed flowcharts promote a "downward" flow, one should also look for variations from the vertical flow of the process flowchart to identify additional weaknesses.

Once the process weaknesses have been identified, countermeasures can be sought to mitigate or eliminate the process weaknesses

Determining Low Value Added Steps


Reviewing each process step and determining the "value added" can help select and prioritize areas for improvement. Methods for determining the "value added" vary. One approach is to interview process players for value using a subjective high, medium, and low criteria. Another approach is to quantify each process step's relative cost and benefits and adding a corresponding point value (3, 2, 1) for cost and a point value (1, 2, 3) for each benefit. Each step can then be plotted on a matrix and a "value added score" can be calculated by multiplying the cost value by the benefit value.

Figure 2: A Value Added Matrix Once "value added" determinations have been made for each step, the above matrix can be used to help prioritize steps for redesign or suggest an improvement activity to increase low value steps.

Flowcharts: A Good Resource For Problem Identification


When searching for something to improve, process flowcharts can provide teams with good ideas. In most cases, suspected problems on a process flowchart will be confirmed (or dismissed) during the Measure step of DMAIC.

Key Point
ets FasTrack Summary 1 of 1: The technique used for using common sense and observation to locate problems, as opposed

to complex analytical tools is known as: Answer: Qualitative Analysis

Step 1: Define - Checkpoint 1


Finding Improvement Needs With A Survey / Interview?
Excerpted from the ets course Decision Making Tools. A survey, or interview, is a well-designed method for collecting data that is not readily available in a numeric format. In the context of DMAIC, it is also a useful tool for finding potential problems. Putting an exact value on "customer satisfaction" isn't always easy. You don't have a meter to read or a printout to analyze. Instead, organizations use surveys. These tools can take the form of face-to-face interviews, written questionnaires, e-mail, online web sites or a combination of all of them. In the context of this course and many process improvement or problem solving processes, surveys are typically used to gather information from customers. Nonetheless, surveys can be used to gather many types of data required for decision making, including:

A sample of voters is polled by interviewers before an election to determine which candidates or issues they perceive as most relevant. A sample of customers is asked to rate their experience when purchasing a product through a company's web site by answering an online questionnaire at the conclusion of their purchase. A company conducts a telephone survey of potential customers in a geographic area to determine a need for its services. Employees are asked to confidentially rate their satisfaction with their employer by filling out a questionnaire and mailing it to an outside firm for tabulation. The U.S. Bureau of the Census conducts a survey each month to obtain information on employment and unemployment in the nation.

Most organizations have already developed one or more customer satisfaction surveys. Often these surveys ask a variety of "important" questions, but fail to ask the "right" questions the ones needed to actually improve customer satisfaction. Consequently, most survey instruments are inadequate because very little can be done with the results.

Best Practices In Survey Design Typical Surveys 1. 2. Identify / validate customer needs Measure customer satisfaction overall. Good Surveys 1. Identify / validate customer needs by customer segment 2. Measure customer satisfaction overall: by customer segment by valid requirement 3. Assist in stratifying the customer satisfaction data. by customer segment by pertinent what, where, when, who categories

3.

Assist in stratifying the customer satisfaction data.

4.

Provide some general customer comments.

4. Provide comments that tie directly to each question. 5. Assist in identifying root causes of problems. 6. Are brief and to the point.

Figure 1: Differences Between Typical Surveys And Good Surveys Figure 2 shows an example of a well-designed customer satisfaction survey instrument (form). We will discuss the methods for ensuring that your surveys are well designed later in this section. Take a moment to review the figure below, noting its structure and the type of information it asks for.

Figure 2: A Good Survey Instrument

Surveys: A Good Resource For Problem Identification


Low survey values provide a general area in which an improvement team can investigate for problems. For example, if a team analyzes the average responses for each question in Figure 2 above, they can go back and read the comments for any question that scored unusually low. Notice that the survey specifically requests comments for values of "3" or less. These comments are to help show DMAIC teams where to look when they begin defining a problem.

Key Point
ets FasTrack Summary 1 of 1:What tool can not only be used to identify areas of concern, but can also be used to gather

comments that can direct a DMAIC team's improvement efforts: Answer: Surveys

Step 1: Define - Checkpoint 2

2. An indicator measuring our performance in meeting the need was developed.


"Indicators" are metrics (or standards of measurements) that measure the outcomes of a process. Much like a speedometer tells you how fast you are going and if you are breaking the speed limit, an indicator is a gauge of process performance that tells you how well a process is performing and if its performance passes an acceptable limit. In the case of DMAIC, indicators are used to provide measurement of your improvement need. Remember that improvement needs must be quantifiable, or "measurable." An indicator provides a graphic way of showing how great an improvement need is, and how much better (or worse) an improvement need becomes over time. If it helps, you can think of your Checkpoint 2 indicator as the overall "gauge" for determining how well your DMAIC project is working.

Reading Indicators
Indicators and their many forms are discussed in depth throughout Process Management. Rather than repeat an entire discussion on indicators, let's simply refresh our memory on how to read indicators. Line graphs, such as the one shown in Figure 1, are often used to display indicators.

Figure 1: A Quality Indicator

As you can see from the figure above, indicator line graphs have a good arrow indicating the desired direction of line graph movement and a target indicating the desired direction or customer valid requirement. The good arrow shows the direction that the indicator "should move" for good results. For example, if you are looking at an indicator that shows "number of errors," clearly fewer errors are better and therefore the good arrow would point downward. Indicators with upward pointing good arrows might include "customer satisfaction rating," "% complete applications," etc. When the indicator moves in the direction of the "good" arrow, your DMAIC story is succeeding. The target line, or bar in some cases, shows the acceptable limit of the indicator or the goal that your indicator is trying to achieve. Targets can be constant or they can change over time. We'll see how targets are set for improvement need indicators later in this course. For now, the important point to remember about targets is that they denote the "goal" of the indicator. The line graph should move toward the target in the direction of the good arrow, or remain past the target in the direction that the good arrow points.

Selecting DMAIC "Improvement Need" Indicators


An (improvement need) indicator should graphically demonstrate the stakeholder's measured need and our need to improve. When selecting an indicator, choose one that accurately depicts your improvement need using data. Accurate measurement of indicator data is critical. Inaccuracy at this stage in your DMAIC project can result in a large amount of error, potentially enough to cause your project to make invalid decisions.

This checkpoint is completed when you have defined an indicator that measures your need to improve, and you have shown data on the indicator that demonstrates the need to improve exists. Notice how both examples in Figure 2 below show a need to improve (the title of the graph) and measured evidence that the need is not being met (the data is not meeting the target). Examples:

Figure 2: Example "Improvement Need" Indicators Ideally, as you progress through your DMAIC project, you will see this indicator move in the "good" direction. The following analytical and decision-making tools may prove helpful in this Step:

Line Graphs Bar Charts Pie Charts Object / Defect Technique

Let's take a moment to explore a few ways in which indicators can be established using the analytical and decision-making tools listed above.

Key Point
ets FasTrack Summary 1 of 4: In the context of DMAIC, a measurement that represents the outcomes or performance of a process is called what? Answer: An Indicator

Key Point
ets FasTrack Summary 2 of 4: Indicators often have "Good Arrows." What do these arrows indicate?

Answer: The direction the data should go to indicate improvement

Key Point
ets FasTrack Summary 3 of 4: Indicators often have "targets." What do targets indicate?

Answer: The value that the chart data is trying to achieve

Key Point
ets FasTrack Summary 4 of 4: The following analytical tools bar charts, line graphs and pie charts are good choices to display what? Answer: Indicators

Step 1: Define - Checkpoint 2


Selecting Line Graphs For Indicators
There are three types of line graphs that can be used as indicators. While data could be correctly displayed using any type, selecting the most appropriate type of line graph will help you better monitor the actual progress being made against a plan or target. Figure 1 below shows the three different types of line graphs used for indicators. Afterwards, a more detailed description of each type is provided.

Figure 1: Selecting The Right Type Of Line Graph

Simple Line Graphs


These indicators are suitable for situations where data is plentiful and easy to gather. Since a lot of data is presented, it is easy to track minor variations in the indicator. (Note: Over 80% of organization indicators are simple line graph types.)

Cumulative Line Graphs


These indicators are suitable for situations where data is on going, but being presented from one point in the past up to the current time. Cumulative graphs usually have targets that are plotted from a point in the past to a point in the future. Targets such as this may be used to show if an indicator is "on-track" to meet a goal or falling behind. Since these graphs are cumulative, they can be created at any time to show "up-to-theminute" indicator performance.

Period Ending Line Graphs


These indicators show a summary of data over a complete period, such as years or months, and are composed of samples taken at some interval during the data-recording period. For example, the average minutes that service was unavailable each month would be one data point. By using averages for data points, these indicators provide a better picture of overall improvement since they are unaffected by daily fluctuations. Since these graphs are period ending and rely on averages, they can be created only at the end of a given period (i.e. monthly, weekly, etc.)

Characteristics Of Good DMAIC Line Graph Indicators


The following criteria should be used when selecting good line graph indicators:

Close "FIT" To The Problem Or Need The indicator selected should closely (if not exactly) describe the problem or improvement need.

Accurate Data The data displayed in the line graph indicator should ideally be easy to verify and trusted by everyone as accurate. Try not to choose indicators that rely on difficult or costly data collection, or ones that are controversial.

Low Cost To Collect Data The indicator data collection should at best be simple, easy and require relatively few resources to perform. Selecting an appropriate interval between measurements, or using various sampling techniques, can also help reduce costs.

Easily Understandable By Others

The indicator should be easy for employees and customers associated with the problem to understand.

Roll-up (and breakdown) Capabilities Organizations utilizing "Integrated Service Delivery Systems (ISDS)" need Indicators that can be monitored for an individual location as rolled-up for a district, division or area level. When selecting Indicators for ISDS' it is important to consider this fifth criteria so that your indicators are already prepared for future problem solving diagnostics. This concept is discussed at length in Process Management.

Key Point
ets FasTrack Summary 1 of 3: What type of data is best used on simple line graph indicators? Answer: Data that is plentiful and easy to gather

Key Point
ets FasTrack Summary 2 of 3: What type of data is best used on cumulative line graphs? Answer: Data that is on-going from some time in the past, up until the current time

Key Point
ets FasTrack Summary 3 of 3:What type of data is best used on period ending line graphs? Answer: Data that shows a summary of samples taken over some period

Step 1: Define - Checkpoint 2


What is the Object / Defect Technique?
The Object / Defect technique is a simple procedure for converting a written problem or improvement need into a line graph indicator. If your team is having a hard time developing a good indicator, you may find this technique helpful. Each step of this process, along with a brief example, is shown in the section below. The Object / Defect Technique 1. Begin with a general problem or improvement need from a brainstormed list, a group of priorities, or another source. For example: Category 1. Service plan development time. Category 2. Recidivism (a measurement of how many criminals commit more crimes after release) Category 3. "Why do we have employee injuries?" 2. Reword each problem to specify an "Object" with a "Defect" using any appropriate adjectives. Rephrase your problem as a statement that includes a particular subject or object, and a clear defect. For clarity, the subjects below are shown in blue and the defects are shown in red. Service plan development time takes too long. Recidivism is too high. Incidence of employee injuries is too high. 3. Break-up the outcome of step 2 (Object and Defect format) using the matrix shown below. Break-up your statement from step 2 and separate it into a table, such as the one shown in Figure 1 below. This table provides you with the building blocks of your line graph indicator.

Figure 1: Object / Defect Matrix How Many Tells how many of these objects suffer from the defect, if listed. For example, perhaps only "workers compensation claim" injuries are too high, not all injuries. This box helps you create an accurate title for your indicator. What, Where, or Who Provides the adjective that tells what type of object has a defect. For example, development time may apply to many different processes. "Service Plan" development time is a specific type of development time. This box tells you what type of data to gather. Object Taken from step 2. The object tells you what data values must be gathered. This is the "line" on your line graph. Defect Taken also from step 2. The defect tells you the situation that must be shown, in term of the object's data, to prove that a problem exists. What or Where Defect Seen Tells whether or not this issue occurs everywhere, or only in specific areas or under certain conditions. This box also affects where data is gathered, since you are currently only concerned with the problems that are known. 4. Ask two questions to help find alternative line graphs, if needed: If the outcomes of your Object / Defect session are not satisfactory, here are two questions that can help you look in other areas for valid indicators. A. "How do we know that the defect is present?" Asking this question may help your team find underlying issues that contribute to your main improvement need. These underlying issues may directly affect your improvement need, and as a result, can also provide acceptable indicators. B. "In what ways do we currently measure the object?"

Asking this question will cause your team to consider other measurements that may be available. For example, your organization may track minor injuries in addition to employee injuries that result in worker's compensation claims. Tracking minor injuries may be an equally successful source of indicator data.

Key Point
ets FasTrack Summary 1 of 1: The procedure for converting a written problem into a line graph indicator is called what? Answer: The object / defect technique

Step 1: Define - Checkpoint 2


An Example Of Identifying Indicators
As you have learned in the previous two pages, there is not one "right" indicator for any improvement need. Indicators are developed by your team, and any number of them can be successful as long as they are created properly. Figure 1 below illustrates the transition from an Object / Defect format into a line graph indicator. At point "A" in the illustration, a team begins with the improvement need and breaks it down into the adjective, object and defect. They next look for ways to confirm, with data, that service designs are indeed poor. Point "B" shows four possible indicators that the team could successfully use.

Step 1: Checkpoint 3

3. A theme statement consistent with the indicator was selected.


A theme statement tells specifically what your DMAIC project is attempting to do. In practice, theme statements serve as the "title" of a DMAIC project, and should be clear and concise. A theme statement tells the team exactly what they are trying to accomplish in terms of their indicator. The stakeholder and need to improve help you identify the indicator. Once this indicator is found, you now have a quantifiable problem. The theme statement tells what your team will be improving in terms of your indicator.

Click On A Topic Below To Learn More About: Theme Selection Matrix - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Templates (actual templates can be downloaded in Appendix 2 - Theme Selection Matrix)
Theme statements tell what your team is going to do by referring to the exact problem shown on your indicator. This may be confusing, so let's clarify this subtle difference using an example: If your need to improve is: Supply deliveries are arriving late. And your indicator is: % deliveries arriving late Then a good theme statement would be: "Reduce the % of deliveries arriving late."

Notice that the theme statement above says what the team is going to do. As you can see, the need to improve, indicator, and theme statement are all closely related. There should always be a clear linkage between the theme statement and the indicator established in Checkpoint 2. This checkpoint is completed when you have clearly documented your project's theme statement. The theme statement tells what your team is going to do in terms of your improvement need indicator.

Examples:

Reduce the number of employees who choose to not take part in the 401k program. Increase the percentage of children passing their Math FCAT.

The following analytical and decision making tools may prove helpful in this Step:

Theme Selection Matrix Brainstorming Consensus

Note that some of the tools and techniques listed above are used to select between multiple themes. It is not uncommon for problem solving teams to be faced with many problems, and in such cases prioritization must take place. Remember that it is important to make decisions based on fact, not intuition. Rely on the expertise of your team and the data presented to guide your team's selection when decisions must be made.

Theme Selection Matrix


What Is A Theme Selection Matrix?
A Theme Selection Matrix is a decision making process that helps a group to determine the importance of one particular process, or "Theme," in an organization to demonstrate why it should be selected for attention. The word theme, in the context of process management and DMAIC/six-sigma, refers to the overall goal of a team. Example themes include topics such as "increase sales to priority customers, reduce operating overhead in publishing, minimize delays in form processing, etc." Theme selection matrices help teams determine the most important themes to pursue.

As with many of the other decision-making tools highlighted in this course, theme selection matrices are integral tools for use in process management and the DMAIC process. Figure 1 shows a simplified theme selection matrix:

Figure 1: A Theme Selection Matrix As you can see, each theme is evaluated based on how greatly it will affect an organization's customers and on how high the perceived need to improve the theme is. Potential themes are given a score for "Impact on Customer" and "Need To Improve," using a scale from one to five. The two scores are then multiplied to determine an overall or score for each potential theme statement. The theme with the highest total score is the theme that is likely to have the greatest effect on customers the highest need to improve.

Brainstorming
What is Brainstorming?

Brainstorming is a structured session in which a group rapidly generates ideas. This is a technique that produces a large amount of ideas in a short amount of time. It is essentially a process in which a group of people follow a systematic procedure of generating creative ideas / solutions to a given problem. Although many people have used an unstructured form of this technique, there are guidelines that should be followed to increase its effectiveness.

The Need For Simple Systematic Processes- "A Tale Of Two Buildings"
While reading about many of the techniques presented in decision making literature, you may find yourself considering how seemingly "simple" some of these processes are. While many of these may seem intuitive, it is important to remember that they are the building blocks of more advanced procedures. Following a structured, standardized process in the "little things" can have a profound effect on larger outcomes. Consider the following example: Two groups of workers are asked to construct a small building using bricks. The first group, realizing that stacking one brick on top of another is a simple task, begin to build their wall. Each worker places the mortar between the brink and stacks another one on top. The second group recognizes the need for consistency, even in a simple task. They measure their mortar, establish a standard method of placing the bricks, and then begin to build. When both groups had finished, they both had completely different results! Group one's bricks were arranged differently on each wall, and one wall was three inches higher due to excess mortar. Group two's walls were of uniform shape and height. Remember this as you progress through your training: Complex processes are almost always composed of many simple processes. Small errors in simple processes add up and produce big problems. For this reason, make sure you master the language and procedure of even the simplest processes.

Consensus
What is Consensus?
Consensus, in the context of this course, is a group decision-making process that takes each member's ideas and opinions into account and results in a decision that everyone in the group can support. It is an effective method for decision making because it involves each member's participation and results in an outcome that every participant had a stake in determining. Consensus improves decision quality, equalizes power, causes examination of alternatives, increases commitment to implement the decision and promotes unity among the team members. The goals of consensus are to:

Eliminate a "we-they" feeling. Focus on the problem, not on personalities, position, or points of view. Reach a "win-win" decision. Develop team ownership of the decision.

Achieving consensus should be the goal of your team in any decision-making process. When consensus has been achieved, the concerns of each individual in the team have been addressed and every team member feels that he or she has participated in the decisionmaking and that the decision that has been made is one that everyone can support, if not 100% agree with.

Key Point
ets FasTrack Summary 1 of 1:A theme statement in ets Six Sigma DMAIC methodology states specifically what the DMAIC project is attempting to do in terms of what? Answer: The indicator established in Checkpoint 2

Step 1: Define - Checkpoint 4


4. A schedule for completing the five DMAIC steps was developed.
A schedule represents a commitment by the team, management, and the project's sponsor to achieve their theme within a specified period of time. To successfully meet this objective, team members must meet regularly and management must support the team. As you have learned in these courses, and probably in your daily life, things tend to remain unfinished when people are not held accountable for their completion. This is simply human nature. The Project Planning Worksheet is a standard tool for managing a DMAIC improvement project. Although most fields of the worksheet shown in Figure 1 are self-explanatory, you can find a step-by-step guide to creating project-planning worksheets in the ets course Decision Making Tools. The top section of the form provides basic information about the team and its purpose. The middle section of the form is where meetings can be scheduled up-front, and then documented after the fact. The bottom section is a Gantt chart where long term schedules for completing each step of the DMAIC process are projected, and documented.

Figure 1: A Project Planning Worksheet

Click On A Topic Below To Learn More About: Project Planning Worksheet - What Is It? - Why Is It Important? - How Is It Used? - Process Overview - Detailed Process Steps - Template

This checkpoint is completed when you have created a project planning worksheet for your DMAIC project that includes team information, project information, a (tentative) meeting schedule, and a proposed schedule for performing each DMAIC step.

Example:

The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet

Project Planning Worksheet


What is a Project Planning Worksheet?
The Project Planning Worksheet is a summary document that tracks problem solving or decision-making efforts. This document provides teams and management an overview of the entire decision-making process, based on the principles of Deming's Plan-Do-Check-Act Cycle. The project planning sheet acts as a "road map" as you work to address the theme statement your organization has selected. The project planning worksheet contains the following elements:

The name of your team and members' names. Meeting attendance record. Project schedule organized by the Plan-Do-Check-Act Cycle (a Gant chart similar to an action plan). Recognition of individuals who provide support to the team, but are not team members, such as subject matter experts or the team sponsor. Reference to the Theme and Problem Statements your project is addressing.

Why Is This Important?


The Project Planning Worksheet provides a place for team information, team membership, attendance tracking and a project schedule. Project planning worksheets give you the flexibility to plan the implementation and outline the progress of your efforts to improve a process or solve a problem in both the short and long term, and summarize the state of the project at chosen intervals. As an overall guide and indicator of the status of the project, the project planning worksheet is a valuable device for organizing the decision-making process. Project Planning Worksheets should be updated frequently as the project progresses, in order to reflect the actual time spent on each phase of the project and to document any changes to the plan. The worksheet should never be considered "complete" until the project has finished the "control" step of the DMAIC process, and the team is ready to create new improvement plans. It is a fluid document, and should give team members and others involved with your project a "snapshot" of the current state of the project within any given timeframe. It is up to your project/team leader to determine how frequently the Worksheet should be revised, but we suggest that updates occur on at least a monthly basis.

How Is It Used?
The Project Planning Worksheet provides structure for both the planning process and the implementation of your team's plan for improvement or problem resolution. It is your game plan, your road map, and should give a good idea of your team's overall plan for and progress on your project at any given time. Remember that it should be updated frequently as progress is made, obstacles encountered, or any other change occurs.

In many organizations, project-planning worksheets are required for team improvement projects. These serve as "at-a-glance" summaries for management to review and monitor improvement progress. When using these worksheets to keep others abreast of progress, it is suggested that you distribute the Project Planning Worksheet as follows:

Original copy stays with the team leader. One copy is posted on the team's bulletin board or placed in the team's documentation binder. One copy is routed monthly to the team leader's supervisor, facilitator or manager.

Process Overview
The following steps are used to create a Project Planning Worksheet - see Figure 1 below for a sample Worksheet: 1. 1. Theme: Write in the theme statement from which the team will develop their specific problem and target for improvement. The theme can be chosen by using the Theme Selection Matrix. 2. Team Work Location: List the location of the Team. 3. Team Name: Enter the team's complete name. 4. Team Members: List the names of team members, indicating the team leader with an asterisk (*). 5. Team Information: Include any pertinent information selected by the team. 6. Meetings - Enter the following information after a meeting takes place: Date - Month and day that the meeting took place (for example, 3/2 is March 2). Place an asterisk (*) by the day if the meeting was facilitated by a facilitator or supervisor; otherwise, just put the day. Length of time - Number of hours the team met. Percent attendance - Number of team members attended divided by total number of team members. All this information should coincide with each meeting's respective minutes. 7. Outline of Activities: Before your team begins the steps of the Plan-Check-Do-Act Cycle, estimate the length of time that will be needed to complete each step. Indicate this by placing an open-faced bar across the months for that step. A shaded bar below the open-faced bar will indicate the actual time spent on each of the steps. Place an asterisk (*) in the proper box for your projected presentation date(s). 8. Duration - Calculate the duration of the project as follows: List the Month/Year that the team formed or when an experienced team collected potential themes. At the conclusion of the project, list the Month/Year of completion. Calculate the Total Months between these two dates to figure the duration of the project. 9. Comments: Give a brief synopsis of what analytical, quality control, or other tools were used to complete each step.

Process Steps
The following process assumes that you are using the included Microsoft Word template to create the project planning worksheet. The steps for creating this tool by hand have been included (in italics) so that you may understand both methods. In practice, almost all charting is done using software today but you may need to create a chart in a meeting so this information is still valuable. 1. 1. Theme: Write in the theme statement from which the team will develop their specific problem and target for improvement. The theme can be chosen by using the Theme Selection Matrix. 2. Team Work Location: List the location of the Team. Provide information here that will identify your team, not just your location. 3. Team Name: Enter the team's complete name. Traditionally, problem-solving teams have names- "Cost Cutters", "Time Savers", etc. 4. Team Members: List the names of team members, indicating the team leader with an asterisk (*). 5. Team Information: Include any pertinent information selected by the team. 6. Meetings - Enter the following information after a meeting takes place: Date - Month and day that the meeting took place (for example, 3/2 is March 2). Place an asterisk (*) by the day if the meeting was facilitated by a facilitator or supervisor; otherwise, just put the day. Length of time - Number of hours the team met. Percent attendance - Number of team members attended divided by total number of team members. All this information should coincide with each meeting's respective minutes. 7. Outline of Activities: Before your team begins the steps of the Plan-Check-Do-Act Cycle, estimate the length of time that will be needed to complete each step. Indicate this by placing an open-faced bar across the months for that step. A shaded bar below the open-faced bar will indicate the actual time spent on each of the steps. Place an asterisk (*) in the proper box for your projected presentation date(s). This section is a Gantt chart, much like the action plans presented earlier in this course. 8. Duration - Calculate the duration of the project as follows: List the Month/Year that the team formed or when an experienced team collected potential themes. At the conclusion of the project, list the Month/Year of completion. Calculate the Total Months between these two dates to figure the duration of the project.

9. Comments: Give a brief synopsis of what analytical, quality control, or other tools were used to complete each step.

Key Point
ets FasTrack Summary 1 of 1:In Checkpoint 4 of the DMAIC process, the team must develop a schedule for completing the DMAIC process. What is typically used to develop and document this schedule? Answer: A project planning worksheet

Step 1: Define - Checkpoint 5

5. The sponsor signed off on the project's purpose, scope, and significance.
The sponsor of a DMAIC project is usually the person directly or indirectly responsible for forming the team. Often times a team's sponsor is someone in management who has a vested interested in fixing the problem that a DMAIC team is formed to address. As a result, a sponsor has a logical accountability for the team's success. The sponsor's review, input, and feedback are critical to ensure steady progress since the sponsor typically has a deep understanding of the purpose and impact of the DMAIC project, and they are attuned to timetables and deadlines throughout the process. Sponsors have key roles in assuring the success of DMAIC teams. One of their responsibilities is to sign off on a DMAIC project's purpose, scope and significance. Although this step is usually a formality, it ensures that a DMAIC team has a solid understanding of their own project, and that they have not veered off onto a potentially unsuccessful path. As we have mentioned previously, one of the most common mistakes that DMAIC team's make is to embrace too broad of a focus. Project planning worksheets are the established tools that are used for obtaining sponsor "sign off" on a DMAIC project. A project planning worksheet is an excellent summary of the team's purpose, scope, and estimated effort. Using this single page, a sponsor can review a detailed summary of the team's plans that include their theme, team composition, and schedule for completion. Sponsor reviews pay special attention to schedules. A schedule represents a commitment by both the team, management, and the sponsor to improve performance within a specified period of time. To meet this objective, the team members must meet regularly, and management must support the team. A DMAIC team sponsor should carefully scrutinize a team's schedule to ensure it achieves their goals in a timely manner, but it is also realistic and feasible for all the team members involved. Project planning worksheets can also be used to develop schedules.

This checkpoint is completed when you have obtained approval from the project's sponsor. Sponsor approval can be noted on the project planning worksheet. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet Tollgate Review

The next section will introduce the tollgate review and how it can be applied for this checkpoint.

Key Point
ets FasTrack Summary 1 of 1:What is the role of the "sponsor" in a DMAIC improvement project?

Answer: To review the team's work at the end of each Step

Step 1: Define - Checkpoint 5


Why Use a Tollgate Review?
A Tollgate Review, in the general sense, is a process used to ensure that certain activities have occurred before a process progresses. This procedure is named for its similarity to an actual tollgate, a place where motorists must stop and pay a fee (or be inspected) before the may progress. DMAIC project tollgate reviews are used to review progress and check for key deliverables at the completion of each step of the ets DMAIC method. Simply stated, using tollgate reviews mean that each a DMAIC sponsor formally checks the team's progress at the end of every major step (1 through 5) and then allows them to progress, or in the case of problems, requires them to correct any oversights. In practice, tollgate reviews for DMAIC projects are performed by providing a copy of the improvement story (or story board) to the team sponsor at the completion of each step. The project sponsor then reviews the story to make sure sufficient rigor has been used and provides a formal sign-off to show the step has been satisfactorily completed. Like many procedures in formal problem solving or improvement, a tollgate review is a relatively simple concept with a fancy name. Nonetheless, it is an effective tool for ensuring that teams remain effective. Tollgate reviews are not required for experienced DMAIC teams, but they do offer some significant benefits. These benefits include:

They provide on-going guidance and direction for the project team. They establish a common understanding of the efforts to date and enable sponsors / management to monitor progress. They ensure continuous alignment and reinforce priorities. They provide on-going coaching and instruction about the project. They recognize the project team's efforts and foster intrinsic motivation for improvements.

How To Organize A Tollgate Review


1. 1. A few days before the projected completion of a DMAIC step, the project team prepares an improvement story that shows the work completed for the current DMAIC step. This story is then provided to the project sponsor so that they may study it prior to the actual tollgate review. The sponsor and the team must also agree on a time to meet and perform the actual tollgate review. 2. When the group meets for the tollgate review, the team members first do the following: Present a brief background review to reiterate the project's purpose and importance.

State the purpose of this tollgate review and highlight the required outcomes of the DMAIC step (i.e., verify that each checkpoint was indeed completed). Report on the project's progress since the last review. This includes doing the following: Using the improvement story as the presentation framework. Emphasizing the logic of the work done during each step and conclusions drawn from analysis of the data. Highlighting changes in the purpose, expected results, or risks. Presenting issues, options, decisions, or recommendations for discussion. Presenting plans for next steps. 3. After the presentation, the sponsor does the following: Reinforces the strength of the team's work. States the purpose of this tollgate review and highlights the required outcomes. Offers reactions and suggestions, focusing on one or two specific suggestions for improving the logic or data. Makes decisions or helps achieve consensus, as needed. Conveys appreciation for the team's progress. 4. Before the review is over, the sponsor and the project team work together to: Review decisions, action items, and achieve consensus about next steps. Evaluate the tollgate review, identifying what was useful and any ways the review could be improved.

Key Point
ets FasTrack Summary 1 of 1:What is the name used for the review used to check on the progress of a team and ensure they have met key deliverables before progressing. Answer: A tollgate review

Step 1 - Summary

Objective:
Define the project's purpose, scope and sponsor, and quantify its significance. During this step, your DMAIC team "Defines" its purpose in specific terms and begins to make the necessary preparations for improvement or problem solving. By the time this step is completed, your team should have completed each checkpoint listed below.

Step Checkpoints
The following table shows the 5 checkpoints.

Step Define

Checkpoint 1. The stakeholder and need were identified. 2. An indicator measuring our performance in meeting the need was developed. 3. A theme statement consistent with the indicator was selected. 4. A schedule for completing the five DMAIC steps was developed. 5. The sponsor signed off on the projects purpose, scope, and significance.

Example DMAIC Improvement Story


To help you understand how all of these checkpoints come together and produce an improvement story, we will take a moment at the end of each section to see how each checkpoint of the DMAIC process is used to produce a portion of the DMAIC improvement story. Bob's Pizza is a fictional restaurant that has problems. The following pages will walk you through the thought processes of their team and show you the outcome of each step in their DMAIC process. By the end of this course, you will have watched the Bob's Pizza improvement team create an entire DMAIC story and you will understand the justification for each step.

Step 1: Define - Bob's Pizza


Bob's Pizza: "We Specialize In Quality Pizza!"
Bob's Pizza is a franchised pizza delivery restaurant, dedicated to performance excellence and improving their organization. As a result, the owners of Bob's Pizza formed a DMAIC story team to ensure that they are meeting their stakeholder needs.

Checkpoint 1
The staff of Bob's Pizza know that their stakeholders are the customers and owners of the business. Since making the customers happy sells more pizza, and that makes the owners happy, the team decided to focus on the customer and stakeholder needs. Clearly, making the customer happy will satisfy both stakeholders in this case. Based on extensive research from the American Pizza Delivery Institute, the following statement summarizes the needs of a pizza delivery customer:

External customers require hot pizzas that are prepared to their preference, are tasty, and delivered within 30 minutes of placing the order.

Using this research as a guide, the DMAIC team needed a way to quantify how well they are doing at meeting these needs. Remember, improvement need must be something that can be proven, or quantified with data.

Checkpoint 2
A good method for gathering data on topics that are hard to quantify is a survey. Fortunately for Bob's Pizza, customer satisfaction surveys have been a part of their regular procedures for many years. In fact, measuring the drivers of customer satisfaction are so important, they are tracked as "M" indicators in the Bob's Pizza Integrated Services Delivery System (ISDS). "M" indicators are a process management term. "M" indicators measure data that is considered to be "Mission" critical, or of top priority for organizational success. These indicators are directly affected by the performance of lower level indicators, such as end-ofprocess "Q" measures and the predictive, in-process "P" measures. The linkage between these indicators is a basic process management concept. Knowing that customer satisfaction data was already collected in a six-question survey, the DMAIC team acquired the latest information and reviewed their findings. The data they found is listed in the table below. Results of Survey:

1. % Satisfied with Pizzas are hot 2. % Satisfied with Prepared your way 3. % Satisfied with Pizzas are tasty 4. % Satisfied with Quick delivery 5. % Satisfied with Price is right 6. % Overall satisfaction with pizza

= = = = = =

88% 92% 93% 78% 89% 86%

M6 M5 M4 M3 M2 M1

Based on the survey data, indicator "M3: % Satisfied with Quick Delivery" is the lowest rated response. As a result, one of the greatest opportunities for increasing customer satisfaction is to address dissatisfaction with quick delivery.

Figure 1: Indicator Linkage Figure 1 shows how all of the in-process indicators (Ps) have a direct correlation to the value of the process outcome indicator (Q). Clearly, those things such as cooking time, preparation time, and order taking time have a significant impact on whether or not pizzas are delivered within 30 minutes. The Q indicator, in turn, has an effect on the outcome of the mission critical, or M, indicators. Knowing that M3 indicator performance was linked to other Q indicators, the Bob's Pizza team checked on the Q indicator data and found that that one of the upstream "Q" measures, "Q2: % Pizzas Delivered Within 30 Minutes," was not meeting its performance goal. Indeed, the indicator data for Q2 showed a significant performance gap. Figure 2 shows the Q2 indicator data that the Bob's Pizza team found. Notice that values for 2002 have been considerably below the target value of 100%.

Figure 2: The Q2 Indicator

Checkpoint 3
Based on these findings, the team was ready to develop a theme statement that defined their improvement need: "Increase % of pizzas delivered within 30 minutes of order receipt."

Checkpoint 4
With checkpoints 1 through 3 completed, the team developed their project planning worksheet.

Figure 3: The Project Planning Worksheet

Checkpoint 5
The final checkpoint in Step 1 is to meet with the team sponsor and acquire their "OK" on the improvement plan.

Step 2: Measure

Objective:
Narrow the project's focus and develop the measurement system, problem statement, and target. Whereas the objective of Step 1 was to quantify the significance of a particular improvement need or theme, the objective of Step 2 is to focus more closely on the theme that you selected and find a specific problem within it to improve. During Step 2 you investigate critical features of the theme and select a specific problem to improve. The theme must be examined, stratified, and analyzed from various viewpoints before your team can discover the significant problem. After a specific, significant problem has been identified, a target for improvement based on the stakeholder's need must be established. You must also qualify the impact of improving your specific problem on the theme indicator in Step 1. A properly defined problem statement is written to further focus the team, and is used to establish measurement systems and to obtain sponsor sign-off. Basically stated, Step 2 forces your team to find a significant, contributing problem to the theme. Once a problem is found, the team focuses on solving that single problem, and thereby improving the theme.

Step Checkpoints Step Measure Checkpoint 6. The theme was stratified from various viewpoints and a significant problem was chosen. 7. A target for improvement was established based on the stakeholders need. 8. The impact of the target on the theme indicator was determined. 9. A problem statement that addressed the gap between the actual and target values was developed. 10. Measurement and data collection systems were developed. 11. The sponsor signed off on the projects focus and target.

Step 2: Measure - Checkpoint 6

6. The theme was stratified from various viewpoints and a significant problem was chosen.
Once the theme has been selected, a significant problem that contributes to the existence of the theme must be found. To find problems that contribute to the theme, a team must analyze the theme from four different perspectives: what, where, when, and who.

What
"What" deals with categories of the problem data such as type, complexity, amount, reason, category, severity, etc. The team should stratify the problem data by several "what" categories.

Where
"Where" deals with the location of the theme (or problem). The problem data should be stratified from different "where" perspectives such as "geographic location" like city, county, and state, as well as by "place" (e.g. in office, stairs, etc.).

When
"When" deals with calendar time, duration time, or "when in the process". Data for a team's processes can be stratified by calendar time (day of the week, time of day, month, etc.), or by duration (number of days, number of minutes, etc.), or by process step.

Who
"Who" is the final perspective to consider when stratifying problem data. "Who" deals with specific information concerning the customer, process player or supplier. Typical "who" stratifications are age, gender, position, etc. Your goal is to determine a single problem that will have a positive impact on your theme. As you learned in Pareto analysis, most of the theme is usually caused by only one or two problems. Your goal is to find these "high value" problems, since they typically provide the most improvement for the least amount of effort. If some of your potential problems require expertise in an area not currently represented in your group, consider adding or trading a team member for someone with the proper experience. It is recommended that the team's composition be reviewed regularly to ensure the appropriate skill and organizational mix. Also, don't forget to rely on analytical or decision-making tools to help your team reduce the list of potential problems to an actionable size.

This checkpoint is complete when a single problem, which is believed to have a significant impact on the theme, is determined. Your team should look at the theme from four (or more) viewpoints to search for potential problems. When problems are found, your team should use decision-making tools (or experience, in some cases) to select the most actionable problem. Examples:

Theme: Too many employee absences are causing customer shipments to be missed. Problem: Last quarter, 47% of all employee absences were related to lost time injuries.

Theme: Accounting has an increasing error rate in overtime calculations, causing billing department rework. Problem: Antiquated computer system crashes during work and causes files to be saved with corrupt data.

The following analytical and decision-making tools may prove helpful in this Step:

Bar Chart Line Graph Pie Chart Checksheet Pareto Chart Histogram Control Chart

Let's look at how analytical tools and the four perspectives shown above can be used to explore a theme and stratify problems.

Key Point
ets FasTrack Summary 1 of 1:When a team stratifies the theme to find a significant problem what four perspectives must it

consider?

Answer: Place, Symptom, Time, and Type

Step 2: Measure - Checkpoint 6


Exploring The Theme
Figure 1 shows how a team works from an established theme statement to the identification of a problem. This figure is provided to help reinforce the concept of using analytical tools to explore the perspectives of place, symptom, time and type. Take a moment to review the figure, and then read the explanation for each step in the paragraph below. Theme: Reduce employee injuries that cause delays in customer assistance.

Figure 1: The Theme Analysis Process

Follow these tips when stratifying data: 1. 1. Checksheets (or reports from databases) should provide data records with "What," "When," "Where," and "Who" categories relating to defects. This type of information is used to gain the different perspectives of type, place, time and symptom. 2. Select a time period (or group) of data and stratify this data group by the above categories, searching for a "significant few" (pertinent data). This process helps a team determine if thematic issues only occur during certain times, or are constantly occurring. 3. Separate the "significant few" (pertinent data group) and re-stratify it by the same categories. Repeat this step as needed. Remember that in most cases, one or two problems compose the majority of the thematic issue. Keep sorting and stratifying your problems until you find the most significant ones. 4. Gather detailed information concerning the remaining pertinent data and examine it closely for causes. This is a segue into the analysis step. Once a problem has been selected, the team begins Step 3 and searches for the root cause of the problem. Notice how the process shown uses stratification techniques to separate pertinent from non-pertinent data. Don't be afraid to weed out useless or low value information while your team narrows in on the "significant few."

Key Point
ets FasTrack Summary 1 of 1:In the DMAIC, we strive to separate the few significant problems from the many less

significant ones. What tools do we use with data to help us do this? Answer: Continually stratify and filter the data

Step 2: Measure - Checkpoint 6


Sifting Through The Data: The Starting Point
Problems are rarely so polite as to present themselves in indicator format. In most cases, your team is faced with collecting and sifting through mountains of data to find the significant issues related to the theme. Figure 1 is a spreadsheet example of raw data that relates to our " Reduce employee injuries that cause delays in customer assistance" theme. In most cases, your team will need data such as this to use as a guide while exploring the theme and looking for problem patterns.

Figure 1: Employee Injuries Sorted by Column A (Number) and Column B (Date) Figure 1 is actual data taken from a state department improvement project. In this case, the data was readily available in a spreadsheet. Your data may need to be collected and counted before you can use it. You also may need to request a report from your Information System or database management staff.

Step 2: Measure - Checkpoint 6


Sifting Through Data: Stratification Using a Pie Chart

Pie graphs are used most often to stratify continuous or discrete data with only a few categories (5 or less). Although a pie chart can display a limitless number of categories, they become very difficult to read when too many categories are present. A pie chart shows the composition of a whole data set, based on a specific feature. For example, a team looking to reduce domestic violence has stratified the domestic abuse cases by one feature: gender. They could stratify this data set many ways, but they are looking for ways to stratify their data into smaller or more manageable groups. Based on the team's general knowledge that females are historically more likely than males to be victims of domestic abuse, they decided to stratify their data by gender to see if their assumption was correct.

Figure 1: Example of a Pie Chart Used for Stratification Clearly, female victims far outnumber the males in reported abuse cases. Since this stratification suggested that the majority of the theme was in female cases, the team decided they needed to look more closely at these 114 records. Note two important outcomes of this process. First, the team made an assumption, but verified it with data. Teams are encouraged to use their experience and knowledge to solve problems, but they must be careful to not fabricate data or work solely on intuition. Assumptions can direct a team, but data is required to validate their actions. The second important outcome of this process is that the team made a stratification of their problem. Notice that, by using this simple tool, the team has already removed an entire gender from their search for a specific problem. As you will see in the following pages, continued stratification will usually zero in on one glaring problem that causes most of the problem.

Step 2: Measure - Checkpoint 6


Sifting Through Data: Stratification Using a Bar Graph
Bar graphs are used to stratify continuous or discrete data. In this example, the team has further stratified the month's data on female abuse victims by hour of the day reported. Notice that the team is exploring the "when" perspective in this stratification:

Figure 1: Example of a Bar Chart Used for Stratification In figure 1, the team stratified their data using a bar chart to determine if there was a thematic significance to the time of day. Based on their findings, does time seem to be a factor in this data set's domestic violence rate? Time is clearly a factor, since nearly half of all reported cases occur in the period between 8 and 10 PM. A team looking to stratify this problem into a more manageable group would limit their further research to those cases in the 8 to 10PM range.

Displaying Data In Helpful Ways


When a team is analyzing data to look for stratification opportunities, it is helpful to display this data in a manner that clearly ranks problem significance. Some bar graphs, for example, can provide completely accurate data that is misleading at first glance. Consider the left-hand bar chart shown in Figure 2 below. Which process step (bar) has the highest opportunity for improvement?

Figure 2: Example of Conversion from a Reduction Problem to a Zero Defect Problem Although bar "A" is the tallest bar and represents the overall most time to complete any process step, bar "B" has the highest amount of waste in the process and is thus, the best opportunity for improvement. This concept is clearly expressed when the reduction bar chart is converted to a zero problem bar chart on the right hand side. Notice that the zero problem bar chart shows only the unnecessary costs, from greatest to least. A reduction problem bar chart shows stacked data, where the "bad" values are often placed on top of the good ones. The ideal case of a reduction bar chart is when the "unnecessary cost" bars are reduce to a height of 0. A zero problem bar chart shows only the defect (unnecessary costs), and is much more intuitive for a reader to understand. The ideal case of a zero problem bar chart is to reduce all of the bars to 0. Be careful when solving cost (or time) problems to not go after the largest overall cost (or time), but rather, convert the reduction problem into a zero problem and seek the largest unnecessary costs (or time).

Key Point
ets FasTrack Summary 1 of 1:Reduction problems combine the good and bad data on a single chart, and can sometimes be confusing to read. What kind of graphs help us by ONLY displaying the problem data? Answer: Zero problem graphs

Step 2: Measure - Checkpoint 6


Sifting Through Data: Stratification Using a Histogram
Histograms can be used to stratify data. In the case of a histogram with limits, any data that appears outside the limits is clearly cause for further investigation. Figure 1 below shows an example of how a histogram can be used to stratify data.

Figure 1: Example Of A Histogram Used To Stratify Data Using histograms (or frequency charts, if the countable data is below 20) to stratify data can be a very powerful tool in separating pertinent from non-pertinent data. On the topic of histograms, these charts like pareto charts can also be used to compare "before" and "after" data at the end of the improvement process:

Figure 2: Example Of A Histogram Used To Review Results

Figure 2 shows how the entire set of data shifted to the left, showing that the mean and overall distribution of the data set improved. This before and after technique is commonly used in DMAIC or other improvement stories during the Control step.

Key Point
ets FasTrack Summary 1 of 1:Can histograms be used to compare the before and after results of a data set? Answer: Yes

Step 2: Measure - Checkpoint 6


Sifting Through Data: Stratification Using a Pareto Diagram
A Pareto diagram, by design, is used to stratify discrete data with the purpose of finding the most significant portion of a data set. As you may recall from the ets Analytical Tools course, the purpose of a Pareto diagram is to identify the 20% of a group that comprises 80% of the (typically problem) data. Figure 1 below shows how a Pareto chart can stratify data and highlight a single, significant group within the set.

Figure 1: Number Of Employee Strain Injuries At Florida State Hospital - 1996 Figure 1 is an actual Pareto chart taken from a state improvement story. Notice how nearly all of the injuries depicted in the Pareto chart are of a single type: back. A team searching for a significant problem with this data would be wise to start with "back" problems.

"Drilling Down" With Pareto Charts


Paretos can be used to continuously drill down into a data set and display data in increasingly discrete levels. This type of repeated stratification is often helpful while searching for the "significant few."

Figure 2 below begins with a set of data containing doctor cases, and then repeatedly stratifies this data by more discrete types. First, all of the injuries were summarized in a Pareto Chart by what "type" of injury they are: strain, wound, bruise, sprain, etc. Wound is one of the two large bars of this Pareto, so it becomes the base data set for the next stratification. Next, the selected sub-set of data from the previous step, "wound," is broken down (or stratified) using a second Pareto Chart by "wound types": bite wounds, step wounds, climb wound, close wounds, etc. Since the "bite" wound type is the largest bar here, we will break "bite" wounds down into types for the third Pareto stratification. The third Pareto chart shows the three types of "bite wounds" that exist in the data set, each one a separate bar on the Pareto chart. Once again, a single type of "bite wound" greatly outweighs the others. This type of bite wound, "dog bite," becomes the base data set for our final Pareto stratification. Beginning with the "dog bite wound" data set, this Pareto breaks down each of the 47 dog bite cases into job classification types. With 36 instances, "meter readers" are the most significant dog bite group. Notice how we systematically found the most significant group of the entire data set: "Doctor Cases By Injury Type." Meter readers are the most significant problem, not just in the final Pareto stratification, but also in the entire data set. The logical progression of stratification used in this diagram shows how a team can begin with a large set of data and systematically find the most valuable target for improvement. By addressing the problem of meter reader dog bite wound injuries, which is the largest single problem group that our team found, the improvement team will be fixing the issue that will have the most dramatic impact on the overall issue.

Figure 2: Example of Successive Stratification Levels You may be wondering how a team knows when to stop stratifying Pareto data. The best answer for this question is to stop when no more logical groups exist, or any logical grouping fails to show a single, significant problem. For example, the data from Figure 1 was stratified again by the team in an effort to find out which meter readers (by what, where, when, who) suffered from the most dog bites. The team found no significant sub-group in any of these stratifications. In other words, no matter how they looked at the meter reader dog bite cases, they couldn't find a significant feature that made some meter readers more susceptible to being bitten.

Showing Improvement With Pareto Charts


Since we are discussing Pareto charts, it should be noted that Paretos can also be used to display "before" and "after" views of data. Figure 3 below shows 3 charts. The line graph counts the total number of employee injuries, both before and after a DMAIC improvement

project. The Pareto chart on the left stratifies all of the data BEFORE the DMAIC improvement project. The Pareto chart on the right stratifies all of the data AFTER the DMAIC improvement project. Based on what you learned earlier on this page, and assuming that the DMAIC project worked, you should see at least one Pareto bar shrink as a result of improvement efforts. Is this the case below?

Figure 3: Number of Employee Injuries (1996-1998)

Yes, improvement is clearly evident. Back injuries decreased from 53 to 6, showing a 90% reduction in the significant problem area. Additionally, by addressing this single significant problem the DMAIC team managed to reduce the entire data set "Number of Employee Injuries" by 64%. This actual data shows how focusing on a single, significant problem can drive dramatic improvement in the overall data set.

Key Point
ets FasTrack Summary 1 of 2: If your DMAIC team wanted to "drill down" through a data set to find the most significant

factors that contribute to the data at each level, what types of diagrams are very useful? Answer: Pareto Diagrams

Key Point
ets FasTrack Summary 2 of 2:Can Pareto charts be used to show before and after results of a data set?

Answer: Yes

Step 2: Measure - Checkpoint 6

Sifting Through Data: Defects Per Million Opportunities (DPMO / Sigma Level)
What is DPMO?
Defects Per Million Opportunities (DPMO) is a way of expressing the proportion of defects over the total number of opportunities in a set of data. DPMO is a single, numeric value that tells you exactly how good or poor a process is performing. By comparing these values, teams can stratify indicators and/or processes to find the worst performer and thus, the most significant problem. This technique is closely related to calculating the "sigma" level of a process, the procedure from which Six Sigma gains its name. We will explain this process briefly below.

Calculating DPO
Calculating DPMO is a relatively simple procedure that is performed in two steps. First, you must calculate the DPO, or "Defects Per Opportunity." Once this value is found, converting DPO to DPMO, and then Sigma, is trivial. The formula for calculating DPO is as follows: Divide the number of process defects by the number of units multiplied by the number of opportunities for defects per unit.

For example, assume your office receives applications for certification. Each application has 15 areas that must be answered. This means that each application has 15 opportunities for an error to occur, or 15 opportunities for defect per unit. Opportunities For Defect Per Unit = 15 During the past month, you noted 137 total defects on 372 submitted applications. Number Of Defects = 137 Number Of Units = 372 Therefore, the calculation of DPO is simply: 137 / (372) x (15) =

137 / 5580 = DPO = .0246 This means that based on the data collected, you averaged .0246 defects per opportunity.

Calculating DPMO From DPO


Since you already know the defects per one unit, to find the defects per one million units you simply multiple DPO by one million. DPMO = DPO x 1,000,000 DPMO = .0246 * 1,000,000 DPMO = 24,600

Calculating Sigma Level from DPO


The Greek symbol "Sigma" represents the standard deviation of any given process outputs. Standard deviation is a unit of measure for process variation. Processes that have Six Sigma (or 6 standard deviations) contained within their process specification limit are considered near flawless processes. The "Sigma Level" calculates the number of Sigmas (or standard deviations) contained within a process specification limit. The Sigma level is measured in standard deviations from the process average (or mean) to a target, or specification limit. One way to estimate your "Sigma level" is to find the DPMO and then use a conversion chart, like the one provided below:

DPMO 933200 915450 894400 869700 841300 809200 773400 734050 691500 645650 598700 549750 500000

Sigma Level (# of standard deviations) 0 .125 .25 .375 .5 .625 .75 .875 1 1.125 1.25 1.375 1.5

DPMO 450250 401300 354350 308500 265950 226600 190800 158700 130300 105600 84550 66800 52100 40100 30400 22700 16800 12200 8800 6200 4350 3000 2050 1300 900 600 400 230 180 130 80 30 23.35 Sigma Level (# of standard deviations) 1.625 1.75 1.875 2 2.125 2.25 2.375 2.5 2.625 2.75 2.875 3 3.125 3.25 3.375 3.5 3.625 3.75 3.875 4 4.125 4.25 4.375 4.5 4.625 4.75 4.875 5 5.125 5.25 5.375 5.5 5.625

DPMO 16.7 10.05 3.4

Sigma Level (# of standard deviations) 5.75 5.875 6

Figure 1: DPMO To Sigma Rate Conversion Chart Based on our calculated DPMO above of 24,600, we can estimate our sigma level using the chart above to be about 3.4 sigma.

Key Point
ets FasTrack Summary 1 of 1:What are DPO, DPMO, and Sigma level?

Answer: 1. DPO is defects per opportunity, 2. DPMO is defects per million opportunities and 3. Sigma level
is a measure of defect frequency.

Step 2: Measure - Checkpoint 7

7. A target for improvement was established based on the stakeholder's need.


The stakeholder referred to here is the same as in Step 1, Checkpoint #1. Targets should be determined by questioning the stakeholder, if possible, or management, rather than by assumption. As in any translation of stakeholder needs and wants to measurable terms, "WinWin" oriented negotiation may be necessary. Data must be present to show what the customer wants. Targets may also be established through benchmarking or competitive knowledge. The following Target Setting Methodologies should be utilized:

Customer Valid Requirements Benchmarking (internal or external) Historical Trends (best previous performance or expected future performance) What the data will allow (estimated number of defects or waste seen in the data under review - also, what resources are available to apply) Management Wisdom (management often sets more aggressive targets to challenge staff) 50% improvement - can be used when no other methodology can be readily or easily applied)

The following tools and techniques may prove helpful in this process:

Target Setting Workshop Form Critical to Quality (CTQ) Tree

The Target Setting Workshop Form and Critical to Quality Tree are discussed further on the following pages. Targets are goals that are set indicators. When a person reviews an indicator graph, they should be able to compare performance against the target and quickly tell how the indicator is performing. Although a tremendous amount of focus and complexity has been placed on target setting through the recent "Six-Sigma" movement, effective targets do not require complex math or statistics to establish. Targets should be created using the most appropriate "common sense" logic or methodology. In many cases, indicators will have logical targets that arise out of customer requirements, law, or business mandates. In other cases, analysis and consensus may be required to determine a valid target. However a target is set, you must establish a target so that each indicator has a clear point of reference for indicator performance. Without a point of reference, it can be difficult to tell if an indicator is improving (especially on cumulative indicator charts).

Target Setting Methodologies


Targets are not always static values. In fact, targets are often revised over time as better methodologies or more accurate data becomes available. Targets may also be adjusted when industry standards, laws, or competitor standards increase. Because targets may be revised at a later date, teams should not waste a lot of time establishing initial targets. Set targets using one of the methods below and keep progressing? The data collection process will be the same regardless of target levels. Adjusting a target later is a simple process. The following techniques can be used to develop targets for your indicators. Use whichever technique makes the most sense in your situation.

Customer Valid Requirements (CVRs)


Targets may be set based on CVRs when a logical target exists. For example, if one of your customers requires that you return calls in 2 hours or less, then clearly you have a target somewhere at or below two hours. Make sure you have a clear understanding of CVR values if you use this method. Refer to the customer needs information in Process Management for a review of this concepts, if needed.

Benchmarking
Benchmarking is the process of setting targets based on competitor, or best in class/division/organization performance. Often times similar organizations track similar indicators, for example, overall customer satisfaction. If you can determine a competitor's level of performance in an indicator, then you can use this level as a target. In addition to competitor performance, benchmarks can also be based on high performance or successful organizations in unrelated fields. Finally, benchmarks can be developed using internal organization performance between offices, divisions, etc. This is useful when your indicators are unique, or competitor data is not available. Do you recall reading that organizations with similar departments should strive to use similar indicators? Here is another reason why an organization can analyze indicator performance across departments and use the best performing department as a benchmark target for the others.

Historical Trends
When competitor data or benchmarks are not available, historical trends can be used to set targets. Indicators can be reviewed to determine the best performance levels they have achieved. This historical performance trend is then used as a target. For example, if a department performs data entry and their best ever entry rate was 5,137 documents per day, setting a target to this value is an excellent start.

"What The Data Will Allow"

In some organizations, such as manufacturing or healthcare, targets are set by resource limitations or the environment. For example, consider a manufacturing process that requires 90 units of material and has 100 units of material available. If "Average Resource Units Wasted In Production" was an indicator, then a good target would be less than 10. Do you see why? 100 Total Resources - 90 To Build A Unit = 10 Units Extra If this organization wasted more than 10 units on average (due to bad cuts, human error, etc.) than they would clearly impact the production process they would run out of resources! Also, "what the data will allow" refers to the data remaining from a problem stratification such as a Pareto Chart. If 100% of the defects were stratified resulting in 60 defects associated with type A defects, then the target would have to be adjusted downward 60% to equal "what the data would allow".

Management Wisdom
Although often controversial, management mandates may be used to set targets for indicators. In many cases these targets will be aggressive to inspire performance or to encourage employees to "rise to the challenge." As idealistic as this approach may seem, management wisdom can be an effective target setting technique when properly applied. For example, management could make the case that they need certain targets to be met to avoid resorting to layoffs, or to achieve enough reserves to offer employee bonuses. If targets are based on management wisdom, it is usually helpful to explain the logic of these targets via communication to the process owners to establish "buy-in."

Law (also considered a Customer Valid Requirement)


These are targets mandated by state, federal, or any other law, plain and simple. If a law states that workers compensation claims must be processed in four weeks, then a target should be set LESS than four weeks with enough time built in for unforeseen problems and difficulty. Don't be afraid to set targets above minimum standards!

50% Improvement
One of the fundamental truths of industrial engineering is that organizations have an inherently high amount of "waste" in processes. This does not mean that an organization is poorly run, or even unprofitable. It DOES means that every organization has the opportunity to significant improve process performance. If no clear targets can be determined, look at the most recent indicator values and set a target for 50% above that value (multiply the current indicator value by 1.5). For example, if your latest "Hours Of Training" indicator value was 137, then a 50% improvement target would be 137 X 1.5 = 205.5.

Document The Targets


Once a target is established, don't forget to document the value of the target and the formula / rationale for the targets value! A good place to keep this information is on the Process Control System (PCS, will be discussed shortly) or the indicator graph, or an indicator documentation form (shown

Key Point
ets FasTrack Summary 1 of 1:Targets for improvement should be based on what?

Answer: Stakeholder Needs

Step 2: Measure - Checkpoint 7


The Target Setting Worksheet
The chart shown in Figure 1 below is a useful tool for walking you though the target setting process. This chart is available as a Word template that you may download, print, and use as needed. Please note that this worksheet is designed to be printed and completed by hand.

Figure 1: Target Setting Chart

Step 2: Measure - Checkpoint 7


What is a CTQ Tree?
A CTQ Tree is an Analytical Tool that is used to identify Critical To Quality (CTQ) characteristics, or "features by which customers evaluate your product or service." These features are what we also refer to as customer valid requirements, and in the case of CTQ analysis, each one must have an easily identifiable target. In many areas of organizational improvement, different methodologies and names have evolved to describe similar outcomes. In this case, CTQs (critical to quality characteristics) and CVRs (customer valid requirements) are similar concepts that were simply grown in different organizational improvement "camps." Conceptually, the ideas are virtually identical and we will refer to them interchangeably. CTQ, then, is simply another procedural method for determining customer valid requirements. CTQ is a process that can be helpful in determining quantifiable characteristics of your stakeholder's needs. If you team is having trouble identifying customer valid requirements, CTQ can be a helpful exercise.

Keys To Successful CTQ Analysis


When creating a cost to quality tree, your team should concentrate on identifying critical to quality characteristics (CTQ) that have the following features:

They are clearly critical to the customer's perception of quality. They can be measured (are quantifiable). For each characteristic, a specification can be set to tell whether the CTQ has been achieved (in other words, make sure a target exists, or can be easily established).

Advantages Of The CTQ Tree


In addition to providing teams with CTQ/CVR information, the CTQ approach also provides the following useful information:

It links customer needs gathered from your voice-of-the-customer (VOC) datacollection efforts with drivers and with specific, measurable characteristics. Links are shown visibly, rather than being implied or buried in written references. It enables the project team to transform general data into specific data. CTQ trees show the logical thought process of converting a customer need into a list of quantifiable requirements. It makes the measuring process easier for the team. When a need is broken down into a set of quantifiable CTQs, the need is much easier to measure since an entire list of CTQs can be tracked and compared.

Figure 1 below shows a conceptual diagram of how a CTQ tree is constructed. You begin with a verified customer need, then continually break that need down into "drivers" of the need, or CTQs.

Figure 1: Example CTQ Tree A need driver is something that you consider vital for meeting the customer need. For example, if your customer need is for "accurate form completion," then a driver of this need would be "use easy-to-understand forms." Using forms that are easy to understand will, in turn, "drive" accurate form completion. Although drivers themselves are not quantifiable, they can be broken down into quantifiable CTQs. Continuing the "easy-to-understand form" example from above, a team could establish a series of measures that help determine whether or not a form really is "easy to understand." Some of these CTQ measures might be:

% forms completed in less than 5 minutes. Average score on customer satisfaction survey for question 8: "Was the intake form easy to use?" # of errors per form.

The following page walks you through the process of creating a typical CTQ tree.

Key Point
ets FasTrack Summary 1 of 1:The analytical tool that is used to identify features that a customer uses to evaluate your

organization's products is called what? (Hint: CTQ) Answer: Critical To Quality Tree

Step 2: Measure - Checkpoint 7


Process Steps
The following process is used to build a cost to quality tree: 1. Gather sorted customer needs from your data collection process. Customer needs can be gathered using a variety of methods, many of which were discussed earlier in this course or in the ets Process Management course. 2. List the major customer needs from your data on the left side of the CTQ Tree. Begin by taking the customer need data and placing on the left-hand side of the page. You should leave a considerable amount of room to the right, above, and below, each customer need. This space is required because your CTQ tree expands outward to the right, both vertically and horizontally. 3. Try to view each need from the customer's point of view. As you consider each need, ask, "What would that mean" from the customer's standpoint. Each answer becomes a driver for the CTQs. Keep asking, "What would that mean" until you reach a level where it would be absurd to continue. Your answers at this level are the CTQs This is a repetitive process of drilling down, from a need through drivers, until you arrive at one or more CTQ characteristics. For example:

"Good customer service" might logically mean that an organization has knowledgeable customer service representatives, or "knowledgeable reps." Looking again from the customer's perspective, a team feels that "knowledgeable reps" means that the answers they give are correct. In most cases, it would be absurd to ask what "correct answers" means, so you should stop at this point. "Correct answers" is an appropriate CTQ. Notice that this is also something that can be measured, or "quantified." A person, machine, or list could be used to determine when correct answers are provided to customers. This data can then be used as a CVR for the overall need, "good customer service." More importantly, CTQs usually have easy to determine targets. For example, in most cases you would assume that customer service representatives are expected to provide correct answers 100% of the time.

Repeat this process with each need until you have identified all the CTQ's. Figure 1 below shows an example of how a CTQ tree for the need "Good Customer Service" might be developed.

Figure 1: Example Completed CTQ Tree 4. Select CTQs for the project based on which have the greatest positive impact, and which are within your project's scope or area of focus. Once a list of CTQs has been generated, your team may select from a list of measures, with targets, that are effective measures of customer needs. During the selection process, your team should consider:

Which will have the greatest positive impact on the customer? Which are within your scope or process area of focus?

Tip: In some cases you can go directly from the customer needs to the CTQs, while in others you might need to drive down through several levels of the CTQ Tree to discover the underlying CTQs.

Step 2: Measure - Checkpoint 8

8. The impact of the target on the theme indicator was determined.


This simple checkpoint ensures the logical flow of information, or linkage, exists between Steps 1 and 2 of the DMAIC process. Although the process of selecting targets is directly linked to the overall improvement theme, it is possible for team's to lose focus on the theme or expand the scope of their project beyond its original intent. Verifying that the target does indeed effect the theme is a "sanity check" that helps prevent missteps by the team during the DMAIC project. To demonstrate a link between the target and the improvement theme, ask yourself if the target's outcomes can be explained scientifically (benchmarks, customer contact, tools such as histograms, scatter diagrams, checksheets, graphs, or charts). For example, how can you prove that reducing the "caller on hold rate" to our target of 15 seconds will increase overall customer satisfaction? A statement must be made to indicate the impact that meeting the target will have on the theme indicator, and any supporting data or validation information should also be included. Basically, your team must ensure that any logical person could review your selection of targets and clearly understand why these particular targets have a quantifiable effect on the theme.

This checkpoint is complete when some sort of documentation is provided that shows a clear, logical reason why achieving your proposed targets will have a positive effect on the improvement theme. Documentation should be easy for someone to follow or verify, if needed. Examples:

Theme: Too many employee absences are causing customer shipments to be missed. Target: Employees should be absent less than 10 days per year. Impact: Studies have shown that shipments fall behind due primarily to excessive employee absences when their number of missed days is greater than 10 per year.

Theme: Accounting has an increasing error rate in overtime calculations, causing billing department rework.

Target: 1% or less error rate in overtime request / approval forms. Impact: Data has shown that incorrectly completed overtime request / approval forms account for over 92% of the error in overtime calculations. By meeting our target, 92% of the overtime calculations will be reduced, thereby improving our theme significantly. Although it is not done in the example above, you should consider providing references to supporting data when they are available. For example, what "data" has shown that incorrectly completed forms account for over 92% of the errors? The following analytical and decision-making tools may prove helpful in this Step:

Bar Chart Line Graph Pie Chart Checksheet Pareto Chart Histogram Control Chart Survey / Interview Scatter Diagram

Key Point
ets FasTrack Summary 1 of 1: Why must a team ensure that their target has a clear and logical effect on the theme?

Answer: So the team does not solve a problem that won't have any effect on the theme

Step 2: Measure - Checkpoint 9

9. A problem statement that addressed the gap between the actual and target values was developed.
In Checkpoint 6, you selected a significant problem that related to the theme. This problem was selected because it had a verifiable impact on the overall theme, and was not meeting an acceptable target level of performance. The problem statement summarizes all of these points in a single, concise statement. Whereas your problem simply states something that is wrong, the problem statement tells you what is wrong AND how severe its shortcomings are. For example, one of our example problems from Checkpoint 6 in this Step was "Last quarter, 47% of all employee absences were related to lost time injuries." A problem statement for this would include information that explains the measured shortfall, or "gap," that this indicator suffers from. The statement: "Employee absences are too high due to lost time injuries averaging 27 days per quarter, or 25 days higher than our target of 2" clearly states not only the significant problem, but also tells a reader that a 25 injury gap exists between current performance and their target of 2 lost time injuries per quarter. The problem statement should answer the questions; who, when, where, what is the gap, and why does this need to be improved? The need for improvement can be effectively demonstrated with reference to the theme, or with supplemental CTQ indicators that measure attributes such as quality, cost, or timeliness. The answer to the question "why does this gap exist"? will be addressed in Step 3 of the ets Six-sigma DMAIC Method.

This checkpoint is complete when a problem statement has been documented. The problem statement must identify the gap, and should answer the questions of who is affected by the gap, when does the gap occur, where is the gap occurring, and why we need to fix this gap. Examples:

Problem: Last year, 27% of serviceable families did not receive help because their addresses were entered into the database incorrectly. Problem Statement: Last year, 27% of serviceable families did not receive help they need to support their families because their address was entered incorrectly. Address entry errors averaged 18% last year, which is much higher than our target of 3%-- a 15% gap.

Problem: School form submission is too low because many schools do not know they needed to re-submit their forms. Problem Statement: School form submission is too low because our target of 100% "need to re-submit" awareness was not met. Current data shows that only 56% of schools are aware of the resubmit need, leaving a 44% improvement gap, and causing a delay in funding approval.

The following analytical and decision-making tools may prove helpful in this Step:

CTQ Tree Problem Statement Object/Defect Analysis

Key Point
ets FasTrack Summary 1 of 1:The distance between actual values and the target values of the indicator is called the _________. Answer: Gap

Step 2: Measure - Checkpoint 9


What Is A Problem Statement- The Object / Defect Perspective
Problem statements are essentially objects with defects and adjectives that zero in on the data with the most root causes. Figure 1 below shows a simple step-by-step process for expanding the object / defect analysis process to also create a problem statement.

Click On A Topic Below To Learn More About: Problem Statements - What Is It? - Why Is It Important? - How Is It Used? - Process Overview

Figure 1: Overview Of The Problem Statement Process

Figure 1 shows how the process proceeds through Steps 6, 7, 8 and 9. First a problem is selected and verified with data. The data is next stratified to find the significant few issues that are causing most of the problem. Based on the first Histogram above, it appears that 30 service plans were developed late and after 35 days. A second level Pareto stratification of the 30 late forms reveals that the majority of these(20) are coming from one source, Leon County. The team now has a significant problem that directly relates to the theme. This relation can easily be verified by looking at the problem stratifications above. Additionally, the team also has an administrative target, which states that service plans are developed late when they take longer than 35 days. As a result, the 20 service plans that Leon County developed constitute the gap, since it is desirable to have zero late plans. When all of this is combined, a resulting problem statement could be "20 Leon County service plans were developed later than 35 days despite the administrative requirement that no service plans are later than 35 days."

Step 2: Measure - Checkpoint 10

10. Measurement and data collection systems were developed.


In checkpoint 7, you established a set of customer requirements that are measured to assess your ability to meet the customers' needs. You also have indicators that must be tracked, and gaps that you will be working to reduce. For anything to be measured, a method of gathering data must be established. This checkpoint deals with the formal methods for gathering meaningful data.

Data Collection
Data collection is the process of collecting the right data for measurements in a useful and meaningful format. Like many aspects of improvement, a formal data collection method helps ensure consistency and communication among all of those involved. It also exposes team members to process interfaces and may provide clues as to how process problems can be resolved. The formal data collection procedure is performed in five steps: 1. 1. 2. 3. 4. 5. Define your data collection goals. Develop rules and procedures for the data collection. Validate your measurements. Collect data. Continually improve measurement accuracy.

Each step is discussed briefly below. Like many of the formalized process presented in ets courses, your organization may or may not require such a high level of structure. For example, you team may already have some of your CVR data readily available in a consistent format. In cases such as these, don't spend a lot of time on formal data collection. Remember that the goal of process management is to better serve process customers, not necessarily fill out every form in the course. Avoid "paralysis by analysis!" If a step seems trivial or an answer already exists, keep moving. Don't get bogged down.

Step 1: Define your data collection goals.


Simply stated, make sure that the data you propose to collect will satisfy your measurement requirements. If there are special measurement requirements, patterns, or grouping that is required for usable data, make certain that these issues are clear before progressing.

Step 2: Develop rules and procedures for the data collection.


How will the data be collected? What instruments will be used, and what units will these measurements be reported in? Will your data be a sample or a census? All of these questions must be answered before progressing. You must ensure that the data you collect will be done so in a regular fashion, and a consistent format.

Step 3: Validate your measurements.


Make sure that your measurements remain consistent, don't assume it. Although there are many complex and mathematical methods for determining variation in measurements, most measurement validation can be done my a simple "common sense" check. For example, have two separate people measure your data and see if they get the same values. Check previous values against current ones using a line graph. If you notice any highly unusual trends or variation, you may need to perform further analytical analysis. They key point to remember about this step is: "make sure your measurements are good."

Step 4: Collect data.


Begin the logistical process of collecting data. Ensure that people are accountable for data collection and that they understand the frequency, format, and destination for any data they collect.

Step 5: Continually improve measurement accuracy.


Try to make data collection as accurate and painless as possible. CVR measurements are on going. This means that you will continue to collect your data indefinitely! For this reason, it is important that you keep the data collection process simple and efficient. Try and find ways to continually improve the accuracy and reduce the effort required to collect measurement data. Technology often provides innovative and cost effective solutions for producing low-cost, high quality data.

Data Collection Plan Worksheet

A worksheet has been provided to help your team construct a well thought-out data collection plan. Two versions of this worksheet are included in the template: a general format and a "Voice of the Customer" (VOC) format. The general format will work for all data collection plans, while the VOC format is designed to help you gather data on customer opinion or satisfaction with your process.

Figure 1: Data Collection Plan Worksheet

Remember! The important outcome of this checkpoint is to establish a well-defined method for collecting data. Whether this is done using the included worksheets, an internal action plan, or another method is not important.

This checkpoint is complete when you have a documented plan for collecting all data that is relevant to your project, and one that effectively assigns accountability for each collection task. Exactly how you ensure that data is gathered will vary drastically, since some organizations already have a large amount of data readily available. The key point here is to not assume that "data will collect itself"-- it never does, and when it tries it usually does a lousy job.

Key Point
ets FasTrack Summary 1 of 1: Having a formal data collection plan ensures that data is gathered how? Answer: Consistently

Step 2: Measure - Checkpoint 11

11. The sponsor signed off on the project's focus and target.
Continual sponsor involvement, and regular updates to leadership, are important for DMAIC team success. Just as you did in Checkpoint 5, your team should once again provide a summary document (story / story board / etc) to your team sponsor and schedule a brief meeting so that they can be brought up to speed on your Step 2 progress. The focus of the sponsor's review here, in addition to general effectiveness, will be to ensure that the project's focus remains tightly aligned to the theme and that the targets selected are both reasonable and appropriate. There is a tendency is some cases for teams to set targets needlessly high (and earn the contempt of their co-workers). There are also teams that have been known to set very low targets, as to ensure that their workload does not become much heavier. The correct setting for a target is the one that drives improvement in the theme to an acceptable level. It is often helpful to have a third part, such as your sponsor, review the target setting methodology and ensure that all target values were wisely selected.

This checkpoint is completed when you have obtained approval from the project's sponsor on the project's focus and target. Sponsor approval can be noted on the project planning worksheet. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet Tollgate Review

Key Point
ets FasTrack Summary 1 of 1:Why is it a good idea for a Sponsor to sign off on a target? Answer: So that targets are not set too high or too low.

Step 2 - Summary

Objective:
During this step, your DMAIC team "Measures" your theme to establish targets for improvement, and defines the most significant problem that will be remedied in the remainder of the DMAIC Steps.

Step Checkpoints Step Measure Checkpoint 6. The theme was stratified from various viewpoints and a significant problem was chosen. 7. A target for improvement was established based on the stakeholders need. 8. The impact of the target on the theme indicator was determined. 9. A problem statement that addressed the gap between the actual and target values was developed. 10. Measurement and data collection systems were developed. 11. The sponsor signed off on the projects focus and target.

Step 2: Measure - Bob's Pizza


Bob's Pizza: "We Specialize In Quality Pizza!"
Bob's Pizza is a franchise pizza delivery restaurant, dedicated to performance excellence and improving their organization. As a result, the owners of Bob's Pizza formed a DMAIC story team to ensure that they are meeting their stakeholder needs. At the end of Step 1, Define, we watched how the Bob's Pizza DMAIC team began work on their DMAIC project. We will now rejoin the team and see how they progress through the Measure step.

Checkpoint 6
The team has already established their theme statement, "Increase % of pizzas delivered within 30 minutes of order receipt." Based on this information, the team began to stratify their theme from the perspective of their customers. After considering what, where, when, and who type of situations that could contribute to long delivery, the DMAIC team determined that a series of delays were among the significant problems. Of these delays, on road issues contributed the most significant amount of overall delays. As a result, the team selected "reduce on road delays that cause late delivery" as their problem.

Figure 1: Delays Resulting In Deliveries That Take Longer Than 30 Minutes

Checkpoint 7
Establishing a target for on road delays was the team's next task. Although they would like to reduce on road delays to zero, they all agree that this is not a realistic target. Traffic accidents, detours, and bad weather can always introduce delays into the delivery time. Rather than shoot for zero on road issues, the team decided to try reducing the delays to 10 or less, a 90% reduction target. The team felt that 10 on road delays are a reasonable target when issues beyond their control are factored in.

Checkpoint 8
Although the team stratified their data, they are still required to clarify the impact that their target will have on the theme indicator. Since delays cause most late deliveries, and since on road delays compose 50% of all delays, reducing on road delays by 90% will reduce the total number of late delivery delays be almost half. The team documented this logic so that their sponsor would understand their reasoning.

Checkpoint 9
Since the target was established and the gap in meeting that target is known, the team can add this information to their problem and create the following problem statement: Problem Statement: During 2002, "On Road Delays" contributed to 50% of the late deliveries. Reduce "On Road Delays" by 90%.

Checkpoint 10
It has already been mentioned, but Bob's Pizza already collects a tremendous amount of data on employee performance, customer satisfaction, safety, etc. Since the data doesn't need to be collected, this checkpoint can be fulfilled by appointing one or more team members to regularly gather the latest data on delays, customer satisfaction, and any other information critical to the theme, indicator, or problem statement.

Checkpoint 11
The final checkpoint in Step 2 is to meet with the team sponsor and acquire their "OK" on the improvement plan and the team's progress, which was presented in a DMAIC story. The sponsor ensured that the project remained focused on the original theme, and that the target was logical and well conceived.

Step 3: Analyze

Step 3 - Analyze: START - 60 Minutes

Objective:
Identify and verify the root causes. Step 3 is composed of activities that help illustrate the reasons why a problem statement exists, and walk improvement teams through the process of finding the most significant, or "root causes," of the problem. Just as selecting the most significant problem is critical to efficiently improving the theme, selecting the most significant cause will also generate the most efficient gap reduction. Remember that much of the DMAIC process involves sorting through the "trivial many" to find the "significant few." In addition to finding root causes, the Analyze step also includes some verification Checkpoints to ensure that the suspected root causes have a determinable impact on the problem gap. Analysis of the root causes and their impact on the gap should be performed to a level sufficient to satisfy a reasonable person, no more. Avoid "paralysis by analysis," the state of over-analyzing data when sufficient information has already been given.

Step Checkpoints
Step Analyze Checkpoint 12. Cause and effect analysis was taken to the root level 13. Potential causes most likely to have the greatest impact on the problem were selected. 14. A relationship between the root causes and the problem was verified with data 15. The impact of each root cause on the gap was determined. 16. The sponsor signed off on the verified root causes and impact on the gap.

Key Point
ets FasTrack Summary 1 of 1: What are the Checkpoints of DMAIC Step 3: Analyze?

Answer:

12. Cause and effect analysis was taken to the root level. 13. Potential causes most likely to have the greatest impact on the problem were selected. 14. A relationship between the root causes and the problem was verified with data. 15. The impact of each root cause on the gap was determined. 16. The sponsor signed off on the verified root causes and impact on the gap.

Step 3: Analyze - Checkpoint 12

12. Cause and effect analysis was taken to the root level.
The purpose of this Checkpoint is to use cause and effect analysis to find the most likely root causes of the problem. Once your team has determined which causes are most likely to be the predominant causes of the gap, your team will spend the remainder of this step validating your root causes and ensuring that they are indeed legitimate. Cause and effect analysis requires that sufficient knowledge concerning the problem is collected. Although some problems can be rapidly taken to a root cause level, other problems may be beyond the team's realm of expertise. In these cases, you may require subject matter experts or people from other departments to provide input during the cause and effect process. At the very least, it is a good idea to pick up the phone or send off an e-mail to a colleague that can corroborate your deductions. No matter which cause and effect analysis technique is used (i.e. Fishbone Diagram), thorough brainstorming, topic expertise, and asking "why" numerous times are critical factors in helping your team get to the root level of a problem. Don't underestimate the importance of any step in the DMAIC process.

This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap.

Example:

Figure 1: A Typical Root Cause Analysis Using the Fishbone diagram in Figure 1, a team consulted with experts in "front-end fraud" and developed the cause and effect analysis that is shown. Based on their findings, the team felt that certain factors were likely root causes and they drew yellow clouds around these issues. Notice that although there are five clouds, three of these probable root causes are actually one cause: "Representative not fully trained." The list of potential root causes that 1. 1. Goal setting methodology was invalid. 2. Reporting policy is inconsistent. 3. Representative not fully trained on referrals. This list will serve as the input for Checkpoint 13.

The following analytical and decision-making tools may prove helpful in this Step:

Cause and Effect Diagram Scatter Diagram Design of Experiments Hypothesis Testing Failure Mode and Effects Analysis (FMEA) Single Case Bore Analysis Pareto Chart Delphi Technique

Tip: By asking why five times, most issues are taken to the root level. Keep asking why until you reach an obvious, or existing cause. In the prerequisite ets Analytical Tools course, you were introduced to the Fishbone diagram used above. The next page introduces another commonly used cause and effect analysis technique called "Single Case Bore Analysis."

Key Point
ets FasTrack Summary 1 of 1:What is the purpose of cause and effect analysis? Answer: To find possible root causes.

Step 3: Analyze - Checkpoint 12


What Is Single Case Bore Analysis?
Single Case Bore Analysis is a simple, visual method of identifying root causes for a problem statement. The single case bore analysis can be utilized by itself, or as pre-work to produce a more complete fishbone diagram.

Process for Using Single Case Bore Analysis


1. Select a sample of items from the problem statement. (Between 8-15 data items work best.) Since a problem statement must be composed of quantifiable data, each data point recorded for the problem statement gap represents some discrete, or countable event. For example, if your problem statement is "8 investigations in Leon County were commenced late," then your independent data points that constitute the gap would be those 8 investigations. 2. Identify cause(s) or factor(s) for each item. This is done by talking with people directly responsible for the item. Identify cause(s) or factor(s) that appear to directly impact the item's performance (as described in the problem statement). For each data point collected from step 1, interview the group that recorded the data, or the person most familiar with the relevant processes, and try to determine what caused the unacceptable value. This should be performed for each of the data points. 3. Display the cause(s) or factor(s) in a matrix format (below the problem statement), as shown in Figure 1 below. Keep alike causes at the same horizontal level, grouping them below any data point in which they are believe to be a factor. 4. After listing causes or factors for an item, test the causes and factors by asking the following question for each data point: "If these factors and causes were not present, would this data point have been likely to be below the target?" If the answer is yes, then you are still missing additional factors or causes for that item. Continue investigating data points until you reach the logical root causes.

Figure 1: Single Case Bore Summary

Key Point
ets FasTrack Summary 1 of 1:The analytical tool used to identify probable root causes of a problem statement is called.. Answer: Single case bore analysis

Step 3: Analyze - Checkpoint 13

13. Potential causes most likely to have the greatest impact on the problem were selected.
This straightforward Checkpoint is used to reduce the list of probable root causes from the previous step into a more manageable, and smaller, list of "most likely" root causes. Your goal is to reduce a large list of possible root causes into those few that your team feels are the most significant, and are worthy of verifying. List reduction ("filtering") techniques, such as the multivoting and consensus, can help your team select the "most likely" root causes. You may also want to consult with subject matter experts to ensure your list of root causes make sense to someone with experience in your problem area. This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap.

This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap. Example: The list of potential root causes from the previous Checkpoint example were determined to be: 1. 1. Goal setting methodology was invalid. 2. Reporting policy is inconsistent. 3. Representative not fully trained on referrals. These selections were then narrowed down by the team using multivoting. They decided that "Representative not fully trained on referrals" made the most sense to continue investigating, since it was easy to verify and appeared multiple times in the cause and effect analysis.

Multivoting Consensus

Key Point
ets FasTrack Summary 1 of 1: When selecting root causes, a DMAIC team should try and find the probable root causes that have the most impact on what? Answer: The problem gap

Step 3: Checkpoint 14

14. A relationship between the root causes and the problem was verified with data.
Once a root cause has been selected, a team must confirm that their selection does in fact have a verifiable impact on the problem. Remember that the root cause that was selected in Checkpoint 13 was done so using the opinion and expertise of the group. To ensure that the group made a sound decision, your team must use data to show that the root cause you have selected has had, or will have, an effect on the problem statement gap. In some cases, the link between the root cause and the gap is intuitive. For example, if the problem statement is that "27 reports are processed incorrectly due to spelling errors," then a potential root cause such as "Representative not trained on how to user spell-check" may be easy to identify. In these simple cases, a brief explanation or a potential of the cause and effect analysis will suffice as documentation. Unproven, suspected, or complex linkages may require in-depth explanations, examples, or even investigation. Don't assume that a root cause is valid unless you have data to substantiate your claim. Some data gathering and analysis may be required to confirm or disprove your selected root cause. If the root cause is shown to be invalid, or if the root cause has questionable impact, your team should return to Checkpoint 13 and select a different root cause to pursue. There are a series of analytical tools that help in determine if relationships exist between two data sets. These tools include scatter diagrams, Pareto charts, and the Chi-Squared test. However your data is displayed or analyzed, your checkpoint outcome should be convincing enough to satisfy a reasonable person that improving this root cause will reduce the problem gap. You should perform enough research to confirm that your probable root cause appears valid, but don't go overboard research and data gathering can consume a significant amount of time.

This checkpoint is complete when you have established a list of one or more potential root causes. These root causes are the lowest level factors that your team believes to be generating the gap in the problem statement. Assuming that these root causes are valid, taking action to resolve them should in turn reduce the gap. Example:

Figure 1 below shows a scatter diagram which was created to determine if a suspected root cause "students have too few hours spent studying" has a verifiable impact on the problem statement gap "132 students did not receive an 80% score or higher on their test." The x-axis on the chart represents the potential root cause (too few hours spent studying) and the y-axis shows the gap (test scores are too low). As you may recall, scatter diagrams will show a linear correlation when a relationship exists between the dependent and independent data set. In this case, the points do appear to cluster around a line, which indicates that there is most likely a positive correlation between hours studying and test scores.

Figure 1: Using A Scatter Diagram To Confirm A Root Cause - Gap Relationship Based of the data shown in Figure 1, the root cause of hours studying has an effect on the gap. This level of proof is enough to convince a team that further pursuing this root cause will most likely help reduce the gap. The following analytical and decision-making tools may prove helpful in this Step:

Cause and Effect Diagram Scatter Diagram Chi-Squared Test Pareto Chart

Creating a Pareto chart by causes, or a Scatter Diagram, can be particularly useful in verifying a root cause. After the cause and effect analysis, data is often readily available to be collected and listed, by causes, on a Pareto chart. A series of Pareto charts that show a correlation between the size of your probable root cause bar and the problem gap is an easy way of showing that a linkage exists between cause and gap.

The scatter diagram is more precise and can enable us to determine with varying degrees of confidence (linear correlation coefficient), that a cause and effect relationship exists between variables and how correlated this relationship is. A contingency table (or a chi-squared test) is a more cumbersome, but equally effective solution for verifying cause and effect relationships using discrete data. There are still other more complex statistical tools to assist in verifying root causes. Those higher-level tools are not presented in this section.

Key Point
ets FasTrack Summary 1 of 1:What should the team do if they find out that the root cause shown is invalid, or has questionable impact? Answer: Return to checkpoint 13 and select a different root cause

Step 3: Analyze - Checkpoint 15

15. The impact of each root cause on the gap was determined.
When multiple root causes are verified, it becomes important to know which root causes will have the most dramatic effect on the gap. In the previous Checkpoint you determined that a relationship existed between a root cause and the problem gap. Your task in this step is to determine how much impact each root cause has on the gap, and what kind of results can be expected for an amount of improvement. For example, if your gap is "253 customer satisfaction scores below target of 95%," and one of your root causes is "time spent waiting for service," your team should try to estimate how much change will occur in the gap if the time spend waiting for service was reduced by 10%, 25%, 50%, 100%, etc. By estimating these values, your team can begin to approximate how much correction of the root cause will be required to eliminate the gap. Depending on what data is available to you, you may need to conduct some brief experiments to gather the data needed for making these types of estimates.

This checkpoint is complete when you have determined an estimated impact amount that each root cause has on the problem gap. For each root cause that was validated in Checkpoint 14, your team should be able to generally determine how much effect on the gap a certain level of root cause reduction will have. Example: Scatter diagrams, especially those that are created in Microsoft Excel or a similar graphing program, provide a quick and easy solution to determining root cause impact on the gap. Notice the linear trend line, denoted in red, on the scatter diagram below. As you may recall from learning about these charts, the trend line represents the mathematical "best approximation" of the relationship between the x and y values. By using this line, your team can easily establish a series of impact values. Simply select a value on the x-axis and follow it upwards to where it intercepts the red trend line. The y-axis value at which this intercept occurs is the average result you can expect, based on the data you have seen thus far. For example, for 5 hours in remedial study, we see that the trend line intersects the y-value of 20. For every 20 hours of remedial studying, student test scores average about 35. For every 25 hours of studying, test scores approach 80. Using this information, a team can determine how much change in student study time is required to eliminate the gap between current test scores and desired test scores.

For the more mathematically inclined, the actual cost of improvement can be determined by calculating the slope of the trend line. Going back to high school algebra, the slope of the line is equal to the change in rise divided by the change in run. An easy way to calculate this is to select two clear data points: (5,20) and (25,80). Find the difference in the y values (80 - 20) and divide that by the difference in the x values (25 - 5). (80 - 20) / (25 -5) = 60 / 20 = 3 Therefore the slope of the line is three. This means that for every 1-point increase in x, we can expect about a 3-point increase in y. In more applicable language, "for ever hour spent studying, we can expect a 3% increase in students' average test scores."

Figure 1: Using A Scatter Diagram To Confirm A Root Cause - Gap Relationship If absolute accuracy is important, you may use Excel to perform a linear or polynomial regression analysis. This will provide you with a numerical equation for your line that can be used to calculate the exact slope, or outcome result for any x value. This type of calculation can be performed with a determinable degree of accuracy, but a complete discussion on this topic is beyond the scope of this course. It is mentioned here simply for awareness. The following analytical and decision-making tools may prove helpful in this Step:

Cause and Effect Diagram Scatter Diagram Single Case Bore Analysis Pareto Chart

Key Point
ets FasTrack Summary 1 of 1: Sometimes there are multiple root causes for a problem. Why is it important to estimate how much each contributes to the problem?

Answer: So that the team can approximate how much correction is needed to close the gap.

Step 3: Analyze - Checkpoint 16

16. The sponsor signed off on the verified root causes and impact on the gap.
A tollgate review or project status update meeting with the sponsor is key to maintaining management support, enthusiasm, and commitment to the project. These meetings provide your team with a more objective perspective regarding the outcomes of your most recent DMAIC step. In this Checkpoint, the team sponsor should verify that the logic and procedures for selecting the team's root causes are sound. The sponsor should ensure that the cause and effect analysis is thorough, based on data, and that a clear and demonstrated linkage exists between the causes and the gap.

This checkpoint is completed when you have obtained approval from the project's sponsor on the project's verified root causes. Additionally, teams must demonstrate to their sponsor that they understand the linkage between root causes and the gap, and that impact on the gap can be estimated. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet Tollgate Review

Step 3 - Summary

Objective:
Identify and verify the root causes. During this step, your DMAIC team "Analyzes" the problem statement to try and determine the most significant root causes of the problem and the "gap."

Step Checkpoints Step Analyze Checkpoint 12. Cause and effect analysis was taken to the root level 13. Potential causes most likely to have the greatest impact on the problem were selected. 14. A relationship between the root causes and the problem was verified with data 15. The impact of each root cause on the gap was determined. 16. The sponsor signed off on the verified root causes and impact on the gap.

Step 3: Analyze - Bob's Pizza


Bob's Pizza: "We Specialize In Quality Pizza!"
Bob's Pizza is a franchise pizza delivery restaurant, dedicated to performance excellence and improving their organization. As a result, the owners of Bob's Pizza formed a DMAIC story team to ensure that they are meeting their stakeholder needs. The team has already established their theme statement, "Increase % of pizzas delivered within 30 minutes of order receipt." Based on this information, the team began to stratify their theme from the perspective of their customers. After considering what, where, when, and type of situations that could contribute to long delivery, the DMAIC team determined that a series of delays were among the significant problems. Of these delays, on road issues contributed the most significant amount of overall delays. As a result, the team selected the following problem statement: "On Road Delays" contributed to 50% of the late deliveries. Reduce "On Road Delays" by 90%.

Checkpoint 12
The DMAIC team began by brainstorming the "on road delay" issue by listing the potential causes of these delays. Once a substantial list had been developed, the team began classifying these causes into major categories: people, equipment, process and location. The causes were then transferred to a cause and effect diagram. The team continued asking "why" each cause existed until they reached the lowest, most likely root cause. These results are summarized in the simple diagram shown in Figure 1 below. (This chart has been simplified for clarity.)

Figure 1: The Team Brainstormed The Problem

Checkpoint 13
In the cause and effect diagram from the previous Checkpoint, Bob's Pizza team consulted with drivers and order takers to help determine which of these causes are the most likely contributors to most of the on road delays. The outcome of this meeting was three probable

root causes that were to be further investigated: driver knowledge, routing, and can't find the addresses.

Checkpoint 14
To determine whether or not these three causes have any effect on the actual problem gap, the DMAIC team reviewed records of on road delays to determine how frequently these three causes played a role. Additionally, the team interviewed the drivers to get their expert opinion as to whether or not their three suspected root causes are a factor in delays. The data collected from the driver survey and the historical records provided the following insights: Of the on road delays sample taken, half of the delays had driver knowledge as a contributing factor. The other two causes also had significant verification that there were cases in which they resulted in delays. The table below shows the frequency that the data attributed each cause to an on road delay. The team also noted that in 20% of the cases other small factors played a role, many as a result of one or more of the first three root causes. A. A. B. C. D. Driver Knowledge (50%) Routing (20%) Can't Find Address (10%) All Others (20%)

With this data, the DMAIC team has demonstrated that at least some relationship exists: at least one cause was the primary issue with over 80% of the on-road delays, and 100% of the on-road delays were due to some combination of the root causes shown.

Checkpoint 15
Using the percentages from the previous Checkpoint, the team could quickly estimate the impact that each root cause would have on the gap: driver knowledge was responsible for 50% of the gap, routing for 20%, can't find the address was 10%, and the remaining 20% were a combination of other factors. By correcting the driver knowledge, 50% of the gap would be eliminated. By addressing the routing cause, 20% of the gap would be corrected. Although this type of impact is not as precise as other methods, the team feels that it is adequate for their needs.

Checkpoint 16
The final checkpoint in Step 3 is to meet with the team sponsor and acquire their "OK" on the improvement plan and the team's progress, which was presented in a DMAIC story. The sponsor ensured that the root causes were logically deduced, and that adequate input from staff experts (drivers and order takers) was present. The sponsor then checked the logic of the cause - gap linkage, and verified that some level of impact analysis for each cause had taken place. With this information, the team is now ready to begin fixing their root causes in Step 4: Improve.

The Bob's Pizza Improvement Story


The entire Bob's Pizza improvement story is available for download, printing, and review. You may find it useful to see how an actual improvement story is created using the information shown on this page.

Step 4: Improve

Step 4 - Improve: START - 60 Minutes

Objective:
Develop and implement countermeasures to eliminate the verified root causes. In Step 4, "countermeasures" are selected, tested, and evaluated for use in correcting the root causes from Step 3. A countermeasure is a refined idea that you, or your team, feels will reduce or eliminate the cause. Step 4, however, involves much more than just arbitrarily finding a way to "fix" root causes. Countermeasures must generate both short term and long-term improvement on a cause. Countermeasures must not only effectively close the problems gap, but they must also be feasible, efficient, and not cause other problems to occur. Countermeasures must be carefully planned and tested to ensure they have a high likelihood of success. Careful planning involves assessing barriers and aids, scheduling, and a "pilot" implementation that can gather to confirm or refute the countermeasures effectiveness. Finally, an action plan to implement the countermeasures should also consider contingencies and include sufficient detail to answer the questionswho, what, when and how? Although finding a countermeasure for a root cause is the general objective of this Step, ensuring that these solutions actually take place and that they are effective is what you truly must accomplish in Step 4. Verifying success and weighing all of the risks is part of managing with facts and well-informed decision making.

Step Checkpoints Step Improve Checkpoint 17. Countermeasures were selected to address verified root causes. 18. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility. 19. Barriers and aids were determined for countermeasures worth implementing. 20. The action plan reflected accountability and schedule. 21. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement. 22. Incorporated lessons learned from the pilot into the full-scale action plan and

implemented it. 23. The sponsor signed off on the action plan and expected results.

Key Point
ets FasTrack Summary 1 of 1: What are the Checkpoints of DMAIC Step 4: Improve?

Answers:
17. Countermeasures were selected to address verified root causes. 18. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility. 19. Barriers and aids were determined for countermeasures worth implementing. 20. The action plan reflected accountability and schedule. 21. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement. 22. Incorporated lessons learned from the pilot into the full-scale action plan and implemented it. 23. The sponsor signed off on the action plan and expected results.

Step 4: Improve - Re-Engineering Vs. DMAIC


Re-Engineering Vs. The DMAIC Improve Step
Since re-engineering is a term that often gets woven into improvement discussions, let's take a quick look at what re-engineering is (and isn't) and how it relates to the DMAIC Improve Step. Re-engineering is a general term that broadly encompasses dramatic "improvement" activities. Technically, re-engineering is "Any radical change in the way in which an organization performs its business activities." Note the difference here. Although countermeasures can certainly be dramatic, they can also be subtle and equally effective. One of the dangers of re-engineering is that it can sometimes "throw the baby out with the bath water," meaning it sometimes does away with many good practices while dealing with bad ones. As you have learned so far, efficient improvement comes from systematically identifying low performing areas and addressing root causes. Re-engineering, although arguably effective, is not usually the most efficient method of improvement. Nonetheless, re-engineering a process is sometimes the only option. Don't be afraid to change a process when you have data that support your change, and always make sure to get all the facts and consider all the consequences before making such changes.

Helpful Concepts Of Re-engineering


Many re-engineering concepts and techniques are helpful to DMAIC teams when defining and refining countermeasures. When looking for solutions, the concepts presented in the table below can be useful as starting points or catalysts for innovation. 1. "Moments of Truth" Where must we interface with the customer? What mode of contact is preferred by the customer? By us? 2. Empowerment Where can we move decisions closer to qualified workers? How can we qualify more workers to make key decisions? 3. Information Technology How can we treat resources as though they were centralized? How can we allow those using data outputs to also do the data inputs and updating? How can "real time" handling of variances be accomplished? 4. Small What are the minimum requirements to satisfy our customers? Needs? What are the least number of steps, players or data processing activities to accommodate the customer? (How about one step? or zero steps?) What would a "no frills" product or service look like? 5. Value What low value steps can we eliminate? How can we reduce the cost of high benefit activities? How can we increase the benefits of low cost activities? 6. Parallel Activities What activities could be moved up in the process? What mode of contact is preferred by the customer? By us? What activities can be performed concurrently?

Key Point
ets FasTrack Summary 1 of 1: Countermeasures are ideas to correct problems (and root causes) in a process. Re-engineering

is a redesign of what? Answer: An entire process


Note: (Both processes correct problems, but countermeasures tend to be more efficient.)

Step 4: Analyze - Checkpoint 17

17. Countermeasures were selected to address verified root causes.


In the context of organizational improvement, a "countermeasure" is an idea that a team believes will reduce or eliminate root causes. A countermeasure does not explicitly tell "how" an idea will be implemented. Rather, a countermeasure is a possible root cause solution that must be evaluated and refined before a team can determine if it is a good course of action or not. Countermeasures can come from informal discussion, brainstorming, reviewing best practices from other organizations, relying on staff expertise, or any other helpful resource.

You can think of countermeasures as ideas that an organization uses to eliminate the root cause of a problem. For example, if the root cause of a problem is that "the office is too cold," then a logical countermeasure would be to make the office warmer. Notice that this countermeasure says nothing about "how" this goal will be achieved. "Making the office warmer" is simply an idea that seems to logically eliminate the root cause. Another countermeasure might be to "buy another office." Which of these two choices sounds more feasible? Why? Clearly, all countermeasures are not created equal. Factors such as time, cost, and available resources can affect how feasible any countermeasure might be. The goal of Checkpoint 17 is to not simply find any countermeasures that might work, but to find the best countermeasures that consider all of the factors critical to success. This is achieved by evaluating and refining the countermeasures into a list of those that the group believes to be the best choices. An effective method for performing this evaluation process is to use a countermeasures matrix. The countermeasures matrix was introduced in the ets Decision Making Tools course. We will begin creating a countermeasures matrix in this step, and finish the matrix in the next Checkpoint by adding "practical methods" and evaluating the countermeasures. Figure 1 below shows a countermeasures matrix created using the ets Microsoft Excel template. Notice how each countermeasure is listed alongside a respective root cause. You can also see how space is provided next to each countermeasure for practical methods, and ratings of effectiveness and feasibility.

Figure 1: A Countermeasures Matrix Completing the countermeasures matrix is possible only after the practical methods have been added. We will discuss practical methods in the next checkpoint.

Devising Good Countermeasures


When discussing countermeasures, a distinction must be made between actions taken to quickly "fix" the root cause (an immediate remedy), and those actions that eliminate the root causes and prevent them from recurring. Too often organizations focus on the short term solution rather than taking steps to remedy the root cause. For example, if a lack of employees with technical skills is a root cause, then a poor solution would be to layoff your current staff and rehire new employees with the proper skill base. Although this action may fix the root cause today, it is only a matter of time before the same root cause will recur and you will be faced with the same issue. A better solution is to develop a countermeasure that prevents the root cause from recurring, such as initiating an employee training program or training center. Countermeasures that actually prevent root cause recurrence usually pay dividends in other areas of the organization as well. However your team creates countermeasures, be mindful of whether each suggestion is a quick fix or a long-term solution to the root cause. If you can't decide which are which, go ahead and list your countermeasure on the countermeasure matrix. Most "quick fix" countermeasures will become apparent when practical methods, feasibility, and effectiveness are considered.

This checkpoint is complete when your team has developed a list of countermeasures that focus on effective and sustained elimination of your root causes. In most cases, you should begin constructing a countermeasures matrix in this Checkpoint. You will finalize your matrix in Checkpoint 18. Example:

Figure 2: An Example Countermeasures Matrix The following analytical and decision-making tools may prove helpful in this Step: The following tools and techniques may prove helpful in this process:

Brainstorming Countermeasures Matrix

Key Point
ets FasTrack Summary 1 of 1:An idea that a team feels, based on data and research, will eliminate or greatly reduce a root cause is called a: Answer: Countermeasure

Step 4: Analyze - Checkpoint 18

18. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility.
A practical method is literally the "practical" way in which a countermeasure could be used. In many cases, countermeasures can be implemented using a variety of techniques and resources. Of these, many methods are more practical than the rest. The goal of this Checkpoint is to determine which methods of implementing your team's countermeasures have the most likelihood of success. Countermeasures tell what your team would like to do, and practical methods describe exactly how you might do it. Consider the example root cause from Checkpoint 17 in which the "office was too cold." One countermeasure for this root cause was to make the office warmer. In this case, you can probably think of many practical methods for achieving this: raise the thermostat, require employees to bring sweaters, or perhaps even moving the office to a warmer climate. Each of these methods would seem to ways of achieving the countermeasure, but clearly some of them are not as practical as the others. It is probably too expensive to move the office, and employees might not appreciate being required to wear winter clothing year round. For each countermeasure, your team must determine at least one practical method that can be used to implement the countermeasure. Each practical method should sound reasonable to the team, and once listed, should be evaluated for both effectiveness and feasibility. We will explain what both of these terms mean below. Effectiveness, in the context of a countermeasures matrix, refers to how well your countermeasure (and practical method) will work to close the gap. This rating is typically determined using expert opinions and group consensus. When more than one practical method is listed for a countermeasure, be sure to evaluate the effectiveness of each practical method individually. Feasibility, in the context of a countermeasures matrix, is the degree to which a team feels that this practical method could actually be used. A practical method may be very effective, but if it is forbidden due to law, or prohibitively high cost, then it is not very feasible. An important factor of feasibility is cost-effectiveness: how much benefit comes from this practical method, and at how much cost? Cost effectiveness can be investigated using costbenefit analysis of appropriate detail. The cost-benefit analysis technique is fully explained in the ets course Decision Making Tools. Once each countermeasure and practical method have been evaluated, the team must select which countermeasures they intend to implement. Teams may choose to implement more than one countermeasure when they have adequate funding, time, or manpower. Be careful not to overextend your team's capabilities. Figure 1 below shows a completed countermeasures matrix with countermeasures, each respective practical method, and ratings for effectiveness and feasibility. Notice how the team

selected the three highest rating practical methods for future action. These are the countermeasures and practical methods that will be further evaluated in Checkpoint 19.

Figure 1: A Completed Countermeasures Matrix A team is not required to use a countermeasures matrix to select their practical methods. In they do not, however, the team should provide adequate documentation and explanations that support their decisions.

This checkpoint is complete when your team has determined, using a systematic approach, which countermeasures (and practical methods) should be implemented to correct the root causes. Supporting information, either in the form of a countermeasures matrix or some other format, must be provided to justify the team's selections. Example:

Figure 2: An Example Countermeasures Matrix In the example shown above, a team has evaluated their countermeasures and decided to take action on three of them. In this case, specific countermeasures that also describe the practical method were used, instead of separate countermeasures and practical methods. This is an acceptable format, and is included as an example so you are familiar with this "shortcut" notation. The following analytical and decision-making tools may prove helpful in this Step:

Countermeasures Matrix Cost-Benefit Analysis

Key Point
ets FasTrack Summary 1 of 2:If countermeasures are ideas, what is the term that refers to the ways in which these ideas are implemented? Answer: Practical methods

Key Point
ets FasTrack Summary 2 of 2:A countermeasures matrix ranks countermeasures and practical methods based on two

criteria. What are these two criteria? Hint: One is how well it will work, second is how practical is it to implement Answer: Effectiveness and feasibility

Step 4: Analyze - Checkpoint 19

19. Barriers and aids were determined for countermeasures worth implementing.
In Checkpoint 18 you selected a series of countermeasures that your team felt were the most effective and feasible choices. You are now encouraged to look more closely at each countermeasure, and consider not only the effectiveness and feasibility, but all other forces that may help or hinder your countermeasure's implementation. This step is a type of "sanity check" that helps ensure that you and your team have considered all the implications of a countermeasure. By the time this step is complete, your team's results may cause you to reconsider which countermeasures are implemented, and which are not. This step is important because effectiveness and feasibility are not always the only concern when selecting countermeasures. On the contrary, in many cases countermeasure selection comes down to political or logistical requirements. Consider Figure 1 below. Notice that one of the barriers states that the building closes early on some days. This may not be a negotiable arrangement, and if it isn't, will probably rule out the "split shift" practical method. On the other hand, management is in favor of innovative approaches. Perhaps if management is involved with the process, a compromise may be reached with maintenance that allows the countermeasure to proceed. Barriers and Aids Analysis are useful for highlighting areas of potential conflict, but also for providing teams with substantial data to support their claims and new ideas when barriers are considerable.

Figure 1: A Barriers And Aids Analysis The outcome of this analysis can also be used for contingency planning and scheduling on the action plan (which is created in the next Checkpoint).

This checkpoint is complete when your team has performed Barriers and Aids Analysis for each countermeasure and practical method. Please refer to the ets Decision Making Tools course if you cannot remember the details of Barriers and Aids Analysis. Example:

Figure 2: A Barrier and Aids Analysis The following analytical and decision-making tools may prove helpful in this Step:

Barriers and Aids Analysis

Key Point
ets FasTrack Summary 1 of 1: When implementing countermeasures, effectiveness and feasibility, are not always the only issues involved. Teams need to use other means to help capitalize on assets and avert pitfalls to successfully reduce root causes. There is a very useful tool to help a team do this, and it is called: Answer: Barriers and aids analysis

Step 4: Analyze - Checkpoint 20

20. The action plan reflected accountability and schedule.


With a set of countermeasures selected, and practical methods defined, you team is now ready to begin implementing your plan. To ensure that countermeasures impact the root causes, a timeline and accountability for each practical method must be established. To do this, your team should construct an action plan. An action plan is a technique that contains the "Who, What, When and How" of a course of action or countermeasure. In the context of DMAIC, action plans are often used for ensuring that countermeasures and practical methods get implemented, and get implemented on time. When well constructed, an action plan serves as the overall blueprint of how your process resources are allocated, and how each member of your team will be involved in the process. Action plans are discussed at length in the ets Decision Making Tools course.

Figure 1: An Action Plan Each practical method is usually composed of a series of tasks that must be completed, or continued, to ensure that the practical method succeeds. These tasks are the items highlighted on an action plan. For example, in Figure 1 above you can see the 5 steps involved in the practical method "construct a new survey." The "Owners" column, when present, lists the people who are responsible for this particular Countermeasure and Method. These will typically be the people held accountable for this plan and its timely execution. In some cases, such as Figure 1, a small group is responsible for all of the steps. Each task (for implementing the countermeasure / practical method) is represented by a row with boxes used to denote the planned time (empty) and actual time (filled) for each task. Like the x-Axis of a chart, the bars pass through vertical columns which denote some segmentations of time: days, weeks, months, etc. Time progresses from left to right, such that boxes on the left denote a time prior to boxes farther to the right. When the proposed time for a task changes, the empty boxes should adjust accordingly. When portions of a task are completed, the box should be shaded a percentage equal to the amount of time completed toward the task. The action plan needs to be as specific, realistic, and as thorough as possible. Use individual names, instead of departments or groups, whenever possible. This will enhance accountability and the probability of success. Also, make sure that the schedule coincides with any dates established in Step 2, Measure, or the project planning worksheet.

This checkpoint is complete when your team has developed an action plan for each countermeasure and practical method. Action plans should include sufficient detail, and include specific names of people who are accountable for tasks whenever possible. The following analytical and decision-making tools may prove helpful in this Step:

Action Plan

Note: This Checkpoint marks the beginning of the "Do" portion of the P-C-D-A Cycle.

Key Point
ets FasTrack Summary 1 of 1: What are two things an action plan, or plans, help identify: Answer: A timeline for deployment; accountability

Step 4: Analyze - Checkpoint 21

21. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement.
A test, or pilot implementation of the action plan, should be performed to assess how much impact the countermeasures will have on the root causes and problem. Decision-making tools are helpful and they certainly increase likelihood of success, but they are not guarantees that countermeasures will always work. Before committing to long-term countermeasures, take a week or a month to test your countermeasures on a smaller scale. During this test period, your team should use appropriate data collection and analytical tools to determine if the countermeasure does indeed affect the root cause as expected. During this pilot, the team may discover the need for adjustments, or they may encounter unanticipated barriers and aids that must be dealt with before the final rollout. It is also conceivable the team may decided to rethink which countermeasures would be most effective if their pilot findings are not what they anticipated.

This checkpoint is complete when your team has performed some sort of pilot implementation of the countermeasures and gathered data to assess their effectiveness on the root cause and problem statement gap. Example: A team decides to test their countermeasure: "install GPS Navigation Systems in case worker vehicles." Rather than purchase 100 of these units for every caseworker, the team acquired two of them from a local distributor to "demo" for three weeks. During this time period, satisfaction scores and performance data were gathered for the two caseworkers that used the navigation systems. This data was then used to determine if the root cause and problem gap was reduced for these two workers. If it was, this is a strong indication that a large-scale implementation would also be successful. Using some additional math, a savvy team could even estimate the overall affect that the countermeasures would have on the root cause and gap organization wide. If two workers realized a 35% reduction, then it is logical to assume that the organization should see a similar reduction of course, this value may be higher or lower in reality. Even conservative estimates can be encouraging to leaders and helpful in acquiring needed funding or support to make countermeasures a reality. The following analytical and decision-making tools may prove helpful in this Step:

Barriers and Aids Analysis

Key Point
ets FasTrack Summary 1 of 1: Pilot implementations of countermeasures provide a great deal of insight into the potential

success (or failure) of a countermeasure and practical methods. Why is it a good idea to do a pilot implementation? Answer: Because countermeasures can be costly to implement

Step 4: Analyze - Checkpoint 22

22. Incorporated lessons learned from the pilot into the full-scale action plan and implemented it.
In the previous Checkpoint, teams tested their countermeasures to see if they performed as anticipated. This pilot implementation usually provides teams with additional insight regarding the rollout of their countermeasures and the effect that their changes will have on not just the root cause, but the organization overall. For example, the pilot implementation may reveal additional barriers to implementation that must be dealt with before applying the countermeasure organization wide. Perhaps the countermeasure must be adjusted for different facilities. Perhaps the staff responded differently to the countermeasure than your team anticipated. When the pilot is completed and the team has confirmed that the countermeasure is effective, this Checkpoint requires that team members discuss the findings of the pilot and how this information should be used to ensure success of the full scale countermeasure roll-out. These lessons learned can be used to proactively address issues that were discovered during the pilot. Additionally, a team may have discovered helpful resources during the pilot that should be utilized in the organization wide deployment. Whatever lessons were learned, and whatever changes are made as a result of this Checkpoint, should be documented so that teams who might work to replicate your success will be aware of these issues if they occur.

This checkpoint is complete when your team has reviewed the outcomes of the pilot implementation and documented lessons learned, changes, and adjustments to your countermeasure rollout plan. Example: Do you remember the GPS Navigation countermeasure that we discussed in the previous Checkpoint? Let's continue that example by assuming that the teams learned the following lessons from their pilot. First, the team realized that the GPS systems were very effective at closing their gap, but their effectiveness was only realized when the caseworkers become comfortable using the system. Another lesson learned is that both caseworkers indicated that they only used one or two features of the GPS system, while most of the "bells and whistles" remain unused. Based on these two findings, what kind of changes in the final rollout would you envision? Here are some suggestions. First of all, it sounds like the team should schedule "case worker GPS training" in their Action Plan. Caseworkers told the team that they needed training, and data clearly reinforced their stance that familiarity with the system generated more efficient

use. Another item to consider is the feature set and model of the GPS navigation unit. If a large number of features on the system are going unused, perhaps the team should consider rolling out a lower-end GPS model? This may save money and actually make training easier! The following analytical and decision-making tools may prove helpful in this Step:

Action Plan

Key Point
ets FasTrack Summary 1 of 1: After DMAIC teams complete the countermeasures pilot, what do they do with the

information they gather and "lessons learned?"

Answer: Adjust the plan, or rethink the selection of practical methods.

Step 4: Analyze - Checkpoint 23

23. The sponsor signed off on the action plan and expected results.
Continual sponsor involvement, and regular updates to leadership, is important for DMAIC team success. Just as you did in Checkpoint 16, your team should once again provide a summary document (story / story board / etc) to your team sponsor and schedule a brief meeting so that they can be brought up to speed on your Step 4 progress. The focus of the sponsor's review here, in addition to general effectiveness, will be to ensure that the project's countermeasures were logically established, a pilot implementation has taken place, and an action plan that considers all the findings from the pilot is developed and ready to proceed. Teams should be prepared to convince their sponsor, using data, that their countermeasure is the best choice. If a sponsor cannot be convinced, this is a strong indication that your team may have assumed too much and tested too little.

This checkpoint is completed when you have obtained approval from the project's sponsor on the project's countermeasures and countermeasure rollout action plan. Sponsor approval can be noted on the project planning worksheet. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Worksheet Tollgate Review

Key Point
ets FasTrack Summary 1 of 1: Who reviews all the activities of the team's countermeasures: the logic behind them, their

relevance to the root cause, the action plan, and the results of the countermeasures pilot? Answer: The sponsor

Step 4 - Summary

Objective:
Develop and implement countermeasures to eliminate the verified root causes. During this step, your DMAIC team "Improves" by devising countermeasures and practical methods to correct root causes, and implementing plans that will help ensure the success of the countermeasures.

Step Checkpoints Step Improve Checkpoint 17. Countermeasures were selected to address verified root causes. 18. The method for selecting the appropriate practical methods was clear and considered effectiveness and feasibility. 19. Barriers and aids were determined for countermeasures worth implementing. 20. The action plan reflected accountability and schedule. 21. Implemented and evaluated a test pilot plan to determine the capability to achieve the target established in the Problem Statement. 22. Incorporated lessons learned from the pilot into the full-scale action plan and implemented it. 23. The sponsor signed off on the action plan and expected results.

Step 4: Improve - Bob's Pizza


Bob's Pizza: "We Specialize In Quality Pizza!"
Bob's Pizza is a franchise pizza delivery restaurant, dedicated to performance excellence and improving their organization. As a result, the owners of Bob's Pizza formed a DMAIC story team to ensure that they are meeting their stakeholder needs. The team has already established their theme statement, "Increase % of pizzas delivered within 30 minutes of order receipt." They have also determined their three most likely root causes: driver knowledge, routing, and the driver's inability to find the delivery address. We resume our example with Checkpoint 17, in which the team begins to construct a countermeasures matrix.

Checkpoint 17
The team began their search for countermeasures by listing the probable root causes in a countermeasures matrix. From there, the team began to openly discuss each cause with other members of the team and drivers. They continued brainstorming ideas and refining the list until they arrived at the countermeasures listed below in Figure 1.

Figure 1: Countermeasures Matrix

Checkpoint 18
The next Checkpoint required the team to discuss practical methods of implementing each countermeasure. The Bob's Pizza team makes a fairly specific list of countermeasures. For this reason, the practical methods were obvious and the team felt that they really didn't need to separate the practical methods from the countermeasures. Remember that teams are encouraged to use common sense! Don't ever go through the motions simply for the sake of following procedure. If you determine that you already have the information for a Checkpoint available, don't waste time recreating it! To complete the checkpoint, the team added effectiveness and feasibility columns to their matrix. First, the team ranked the effectiveness of their countermeasures based on how well

the team (and drivers) felt that these countermeasures would help eliminate the root causes and the problem gap. Training was an effective option, and received a score of "4." The team felt that GPS equipment would be very helpful and they rated this solution a "5" in two places. The final two countermeasures were also deemed effective and received ratings of "4." The effectiveness ratings alone didn't provide the team with much guidance. Let's see if the feasibility scores help iron out their decision! Figure 2 below shows the completed countermeasures matrix.

Figure 2: Countermeasures Matrix As you may have guessed, the team had strong opinions on the feasibility issues. After performing a quick cost-benefit analysis on a few of the countermeasures, the team determined that GPS equipment was far too costly to be a feasible choice. They decided to rank this option a "2" in hopes that prices on GPS systems might drop in the near future. Another impractical idea was to hire only experienced drivers. These type of drivers are not only hard to find, but command a higher wage than new drivers, making this a lower feasibility option. Training existing drivers and simply getting directions from customers seemed like good ideas because the training could be done in house, and asking for directions is a low cost and easy solution. The most feasible choice, however, was to develop a map system that drivers could use to quickly locate delivery destinations. This map system could be developed in house and shared by all employees. Based on the enthusiasm from the drivers and management, the team rated the map system as a high feasibility option. The end results of the countermeasures matrix show scored of 20, 16, 16, 10, 10, and 8. Based on the discussions leading up to the matrix and the analysis results, the team decided to pursue three countermeasures in the next Checkpoint: "train existing drivers, make a map system, and get directions from the customer." Their countermeasures were the three highest scoring choices on the countermeasures matrix.

Checkpoint 19
The team performed Barriers and Aids Analysis for each of their countermeasures that they selected to implement in Checkpoint 18. Based on their results, the team felt that their three countermeasures had no significant barriers to their implementation. They also agreed that there were significant aids, including in-house experts, to help the team implement the training and map systems.

Checkpoint 20
In Checkpoint 20, Bob's Pizza team developed action plans for implementing all three of their countermeasures. They also broke each countermeasure into a set of smaller tasks and assigned accountability for each task. Figure 3 below shows the action plans that the team developed.

Figure 3: Action Plans

Checkpoint 21
To test the effectiveness of countermeasures, the team performed a small scale pilot implementation. For one week, a single driver (who would later develop the training materials) used an improvised version of the map system and started getting directions from her customers. The results of this week long test supported the viability of the countermeasures, and the team decided to press onward with a full implementation.

Checkpoint 22
Once the pilot was completed, the team reconvened to review their data and discuss lessons learned. They took time to interview the test driver and gather her feedback as well. Based on the information that she provided, the team decides to narrow their training focus and make some minor revisions to the map system. These changes did not affect the overall action plan schedule, but were important modifications to the roll-out.

Checkpoint 23
Once the team had documented their countermeasures, incorporated lessons learned, and finalized their action plan, they met with their sponsor and presented their plan. The team supported their decisions by showing the countermeasures matrix and pilot implementation impact on the root cause. Once the sponsor agreed that the countermeasures were good, the team discussed the action plan and worked with their sponsor to ensure that the countermeasure roll-out would proceed as smoothly as possible.

The Bob's Pizza Improvement Story


The entire Bob's Pizza improvement story is available for download, printing, and review. You may find it useful to see how an actual improvement story is created using the information shown on this page.

Step 5: Control - Results Phase

Step 5 - Control: START - 60 Minutes

Objective:
Evaluate the results by confirming that the countermeasures taken impacted the root cause, the problem, and the theme; and that the target has been met. Standardize new methods, communicate lessons learned, and recommend future plans. Step 5 of the DMAIC process is the step in which a team confirms that their improvements were successful, their efforts remain effective, and the theme of the project is completely addressed. This Step can be logically broken down into three major phases: checking results, standardizing results, and developing future plans. By breaking this Step into three phases, ets feels that it provides a better emphasis on the critical activities that a team must accomplish. Let's briefly look at what each of the three major phases of Step 5 entail. We will then begin covering the checkpoints and wrapping up the DMAIC course.

Step 5 Control - Results Phase:


The goal of this phase is to demonstrate, with data, the effects that selected countermeasures had on the stakeholder's need. In other words, your team is expected to show how your countermeasures have affected the root cause, problem gap, and ultimately the theme. Although this Checkpoint immediately follows the Improve Step, a significant amount of time is spent implementing the countermeasures (action plans) before a team progresses to this checkpoint. Clearly a team must first implement their plan and begin to gather data before confirming or refuting the effectiveness of their actions. Once data results have been gathered, an effective way to demonstrate success is by using a series of before and after indicators. First, a team shows comparisons to the root cause analysis and root cause indicators determined in Step 3. Next, a comparison is made to the indicator and target from Step 2, showing initial values and results after countermeasures implementation. If the results were not as expected, these variations should be investigated, understood and addressed. Finally, a comparison to the theme indicator in Step 1 demonstrates the effect of the overall improvement on the stakeholder's need, which in turn demonstrates the success of the DMAIC project. Although this sounds like a good place to stop, is isn't the end. Remember that much of the gains in DMAIC and formal problem solving methodologies come when improvement is maintained and replicated in other areas. The remaining phases and Checkpoints help ensure that gains remain in place and that your organization makes the most of its DMAIC investment.

Step Checkpoints Step Control Results Checkpoint 24. The effect of countermeasures on the root causes was demonstrated. 25. The effect of countermeasures on the problem was demonstrated. 26. The improvement target was achieved and causes of significant variation were addressed. 27. The effect of countermeasures on the theme indicator representing the stakeholder's need was demonstrated.

Step 5: Control - Standardization Phase


Objective:
Evaluate the results by confirming that the countermeasures taken impacted the root cause, the problem, and the theme; and that the target has been met. Standardize new methods, communicate lessons learned, and recommend future plans. Step 5 comprises three phases, the Results Phase, the Standardization Phase, and the Future Plans Phase. Each phase has it's own overview page.

Standardization Phase:
Successful countermeasures should be documented and integrated into the appropriate process, procedure or standard. When a team has determined that their countermeasures eliminate the root causes, these countermeasures need to be built into the relevant processes so that changes remain in place. Changes must be communicated and the necessary education and training must occur. Without proper training and integration into existing materials, courses, etc, there is a high likelihood that staff will revert to doing things the "old" way. In many cases, the old way evolved out of convenience or comfort so it is easy to revert back into it if constant vigilance is not maintained! A system of responsibility should also be established to ensure that the revised process or procedure is continually monitored for unacceptable performance, or deviation from the original intent. For example, divisions may try to implement a scaled down version of a countermeasure, or simply make a token effort to implement required changes. This is not only detrimental to the organization as a whole, but it can also undermine the hard work of the team by unfairly devaluing their improvement efforts, or even worse, re-enforcing negative outlooks of skeptical staff. If the above steps are not taken, countermeasures and other process improvement will gradually revert to the old methods and the problem will return. Without a revised process or new standards, the problem will likely return when new people become involved in the work. Without ongoing vigilance and reviews, staff will take their gains for granted and casually begin cutting corners for convenience, or removing countermeasures that they perceive as pointless or extra work. Finally, once the countermeasures are in firmly in place, the team considers specific areas for replicating their success so that the organization can leverage scarce resources and minimize duplication of effort.

Step Checkpoints Step Checkpoint

Control 28. A method was established to document, permanently change, and communicate the Standardization revised process or standard. 29. Responsibility was assigned and periodic checks scheduled to ensure compliance with the revised process or standard.

30. Specific areas for replication were identified.

Step 5: Control - Future Plans Phase


Objective:
Evaluate the results by confirming that the countermeasures taken impacted the root cause, the problem, and the theme; and that the target has been met. Standardize new methods, communicate lessons learned, and recommend future plans. Step 5 comprises three phases, the Results Phase, the Standardization Phase, and the Future Plans Phase. Each phase has it's own overview page.

Future Plans Phase:


By the time a team reaches the final three Checkpoints, their Six-Sigma DMAIC story is completed. The team has made improvement, but the question remains whether the team made enough improvement in their theme. The team and their sponsor must make an assessment as to how thoroughly the theme indicator has been improved and whether it would be effective to continue working on the theme through another ets six-sigma DMAIC project. Remember that the team only addressed the most significant problem so far. There are other problems that can be improved, and other "big bars" on the Pareto charts that can be shrunk. In many cases, one improvement story generates enough improvement to satisfy a theme, but this is not always the case. Additional work on improving the theme may be required. If so, a team can return to their work in Step 2 and select the next most significant problem to correct. In addition to assessing the need for additional work on the theme, some time should be spent discussing and documenting the lessons the team members learned and the team members' collective personal growth. The DMAIC process is a series of Steps and Checkpoints that help guide teams to a logical solution. Teams will undoubtedly find ways to enhance the process and adapt DMAIC to their own organizational needs. When breakthroughs are discovered, be sure to document these and share them with other staff members and the SixSigma DMAIC community at large only through continuous improvement, refinement, and innovation does the performance excellence field grow. Continuous performance improvement comes with each "turn of the wheel", and each turn begins at a higher performance level than the previous turn. Finally, the team sponsor should sign off on the team's decisions and assist them in next steps, such as project replication, additional thematic improvement, or transitioning to another project.

Step Checkpoints Step Checkpoint

Control - 31. Any remaining problems of the theme were addressed. Future 32. Lessons learned, PDCA of the DMAIC process, and team growth were assessed and documented. Plans 33. The sponsor signed off on the results and next steps.

Step 5: Control - Checkpoint 24

24. The effect of countermeasures on the root causes was demonstrated.


The purpose of Checkpoint 24 is to determine, with data, how effective the countermeasures have been on the root cause. Root causes have some sort of measurable effect: the number of times they occur, how late a delivery is, the severity of the root cause (i.e. temperatures are 34 degrees too high). In some cases, the existence of the root cause itself may be a quantifiable event. Your team probably gathered some measurement of your root causes during Checkpoint 15. No matter how a root cause was identified, your team should demonstrate that countermeasures had an impact on the root cause by either significantly reducing it or completely eliminating it. Appropriate use of analytical and statistical tools is an effective way to show the impact of countermeasures on the root causes identified in Step 3. Using data to show improvement or change leaves little doubt as to the effectiveness of the countermeasures and resources expended, especially when a link between countermeasures, root causes, problem gap, and the theme is already established. Of course, if you can simply show that the root cause no longer exists, that is also ample proof of improvement. If root causes have been reduced for reasons other than the countermeasures, or if the countermeasures did not have the intended effect, this should also be explained.

Figure 1: Example Of Before And After Improvement Using A Histogram Figure 1 above shows an illustrative example of how the shift of a histogram mean can show improvement. In this case, a high number of route minutes were determined to be a root cause. By tracking this data before countermeasures were implemented and then comparing to data collected after roll out, the team can show a 20% reduction in the root cause. Although a histogram was used here, other Analytical Tools or graphs that show comparative data could also have been used.

This checkpoint is complete when you have demonstrated, with data, that the countermeasures have had effects on the root causes. You should also quantify these effects, if possible. Example:

Figure 2: Example Before And After Bar Chart

The bar charts in Figure 2 clearly show that the root cause data shown was reduced from 39 overdue reports to 3 on Fridays. Friday overdue reports are now at the average of the other days of the week. This is supporting evidence that the team's countermeasures worked against Friday reports. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Pareto Chart Pie Graph Control Chart Bar Graph

Key Point
ets FasTrack Summary 1 of 1:The effect of countermeasures is demonstrated by measuring the effect on what? Answer: Root causes

Step 5: Control - Checkpoint 25

25. The effect of countermeasures on the problem was demonstrated.


Just as Checkpoint 24 showed the effect of countermeasures on root causes, Checkpoint 25 uses data to show the impact of countermeasures on the problem or problem gap. In many cases, the same Analytical Tools that were used in the Measure Step of DMAIC can also be used here. If a Pareto chart was used in Step 2 to demonstrate the problem gap, simply re-use the same chart and update the data to create a before and after chart. Figure 1 below shows an example of a Pareto chart that shows improvement in problem "A."

Figure 1: Example of Improvement Using Simple Pareto Charts (Sorted Histograms) If the effects demonstrated on your charts are not due to countermeasures, or if your results were unexpected or affected by normal fluctuations in business, seasonal changes, etc., then your team should explain these occurrences.

This checkpoint is complete when you have demonstrated, with data, that the countermeasures have had effects on the root causes. You should also quantify these effects, if possible. Example:

Figure 2: Example Before And After Line Graph This line graph shows problem data both before and after the countermeasure. Notice that prior to the countermeasures implementation in mid September, the average number of errors in a two-week period was 27: a "four error" gap over the target of 23. After the countermeasures were implemented, the average number of errors in a two week period dropped to 20, which is "three errors" below the target of 23. Not only did the countermeasures affect the problem gap, they eliminated it altogether and actually pushed process performance beyond the current target. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Pareto Chart Pie Graph Control Chart Bar Graph

Remember: By reducing the problem, the overall improvement need (Step 1) is also addressed.

Key Point
ets FasTrack Summary 1 of 1: Although a DMAIC team may have shown that countermeasures affected root causes, what do they need to ensure that the countermeasures impact? Answer: The problem gap

Step 5: Control - Checkpoint 26

26. The improvement target was achieved and causes of significant variation were addressed.
Once your team has compiled a set of before and after data in the previous Checkpoint, you should be able to determine how much of a change has occurred in the problem gap. Realistically speaking, improvement projects do not occur in a vacuum. Normal day-to-day work must continue, the economy fluctuates, projects get delayed, and a myriad of other factors can cause your results to be worse, or better, than expected. When your problem gap shows an unexpected change, it is important for your team to understand why things did not turn out as planned. By understanding the factors that contributed to the outcome, your team will have a better understanding of whether their project was flawed, or you were simply victims of poor timing. For example, consider Figure 1 below. Although it looks like the team's countermeasures had a significant impact on the gap, what would you say about these results if there was a dramatic drop in the number of reports submitted. Maybe a new expense report form was created that had better instructions? The purpose of this Checkpoint is to force a team to step back and take a hard, objective look at their results. Don't mislead yourself or others by relying simply on graphs and charts, but rather, try to understand the underlying situation that drove the changes in your data. If analysis is required to determine whether unrelated events had an impact on the gap outcomes, don't be afraid to do some additional investigation, such as scatter diagrams or interviews.

Equally important to explaining shortcomings of success is documenting breakthrough improvement! If your team's results were far better than expected, try to understand why. Determining the mechanisms that drove stellar results can lead to best practices and replication opportunities through the organization.

This checkpoint is complete when your team has analyzed their outcome data and determines what factors were actually, not intuitively, involved in driving the change. In some cases this will be obvious, and in others some investigation may be required. Regardless of the outcome, your team should be able to explain the chain of events that resulted in the change. Example: Assume that a team working on an improvement project finished Checkpoint 25, but rather than closing their gap in the problem "200 technical support questions are going unresolved each day," the team noted that the average number of technical support calls had risen to 310. Was the improvement project a failure? The team contacted the technical support office and asked if any significant changes in call volume or products had occurred recently that might have affected their results. After a few different interviews, a tech support employee noted that a recent virus outbreak had caused many customers to erroneously assume that the improvement team's software product was malfunctioning. In fact, the team discovered that 80% of the technical support calls during the "post countermeasure" period were related to the new virus. Suspecting that the data might have been skewed unfairly, the team decided to collect another week's worth of data once the virus problems were under control. After this data was collected, the team noted that unresolved questions were averaging only 35 per day. What appeared at first to be a failure was actually a big success! Be highly critical of any data that your team gathers? Accurate and unbiased data collection is one of the keys to project success. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Interviews Pareto Chart Pie Graph Control Chart Bar Graph

Key Point
ets FasTrack Summary 1 of 1: In DMAIC Checkpoint 26, a team must determine if an improvement target was achieved

and what the causes of significant variation were. What does this accomplish? Answer: Find out the "WHY" the results were achieved (so they can be replicated.)

Step 5: Control - Checkpoint 27

27. The effect of countermeasures on the theme indicator representing the stakeholder's need was demonstrated.
Remember that the root cause affects the problem, and the problem affects the theme. Since we have already confirmed that both lower level measures of success have been effective, your team must finally assess how much improvement in the theme indicator occurred as a result of correcting your problem gap. Since you selected the most significant problem (the one that would have the most impact on the theme) during Step 2, your team should see some noticeable change in the theme indicator. This change should be demonstrated using data, just as you have done in Checkpoint 24 and 25. You should also note any unusual behavior, or suspected outside influences, if your results were not as expected. Showing an effect on the theme statement is the acid test of your team's success. By improving the theme indicator, your team shows that you have improved an aspect of a process that is important to your customer. A theme, by definition, is directly related to customer need. When the theme improves, customer needs are better met.

Figure 1: Before And After Theme Indicator Data

Figure 1 shows an overall theme indicator that showed significant reduction in the total number of customer complaints after countermeasures were applied. Since the improvement team from Figure 1 corrected their root cause and reduced the most significant problem (which was proven to link to the theme in Checkpoint 8), the theme indicator "Customer Complaints" improved.

This checkpoint is complete when your team has demonstrated, using data, the effect of countermeasures on the overall theme indicator. If your team's results were not as expected, investigation and explanation is required. The following analytical and decision-making tools may prove helpful in this Step:

Line Graph Histogram Pareto Chart Pie Graph Control Chart Bar Graph

Key Point
ets FasTrack Summary 1 of 1:The DMAIC team must verify that the countermeasure, root cause, and gap changes did in

fact improve the overall theme and theme indicator. Why? Answer: It's the acid test of the team's success

Step 5: Control - Checkpoint 28

28. A method was established to document, permanently change, and communicate the revised process or standard.
Once a DMAIC project and its countermeasures have been implemented, changes often occur in the way that an organization does things. Processes may be modified. New tools or techniques may be introduced. Standards may be raised or lowered. Whatever the changes are, your DMAIC team must ensure that all relevant staff members understand these changes, and that staff have an appreciation for why they are being asked to change their work processes. It is important for a successful DMAIC project team to document their efforts and communicate their success to the organization. Although other employees may understand how to perform countermeasures, if they do not understand "why" these countermeasures are important, they probably won't stick with them. In many cases, your team will be asking staff members to change the way they work. This often generates some degree of resentment or resistance. Although these feelings cannot be eliminated, the impact of process changes can be greatly minimized when staff members understand why changes are occurring. If possible, try to involve staff in the process so they feel as if they had a hand in finding the solution. When countermeasures change the way things are done, it is also important that the DMAIC team ensures training materials, equipment, process flowcharts, PCSs, and procedures are appropriately modified to so that countermeasures remain in place. Don't assume that the same staff will be around three weeks from now! Make sure your changes are process dependent, and then they will remain in place regardless of staff turnover or attrition.

This checkpoint is complete when your team has communicated their project to relevant staff, adequately explained why the changes are important, and put measures in place to ensure that the countermeasures are tightly integrated into training, processes, and resources. The following analytical and decision-making tools may prove helpful in this Step:

Poka Yoke Devices

Key Point
ets FasTrack Summary 1 of 1:Documenting countermeasures is part of the DMAIC Control Step. Why, after the theme has

already been improved, should a team be concerned with documenting or standardizing their revised processes and countermeasures? Answer: To force a change in the PROCESS

Step 5: Control - Checkpoint 29

29. Responsibility was assigned and periodic checks scheduled to ensure compliance with the revised process or standard.
The power of "accountability" has been promoted repeatedly through this course. In this Checkpoint, your team must once again assign accountability to individual team members to ensure that standardization efforts remain in place. Standardization means making countermeasures part of your organizational standard, the way you "do" things on a daily basis. In the previous Checkpoint we discussed ways in which countermeasures and process changes are documented and integrated into an organization. These initial documentation steps are critical to short term success, but long-term success relies on standardization efforts remaining in place throughout the coming months and years. Changes will remain in place only if they are checked periodically by accountable team members. Since today's organizations handle a tremendous volume of information, and laws or procedures may change by the week, it is vital that DMAIC team members take responsibility for checking up on any changes made during Checkpoint 28. Team members should each select one or more standardization changes and establish a regular schedule for checking-up on changes to ensure that they remain in place. These follow-ups should be reasonable, and their frequency can be become more spread out as countermeasures become routine and the workforce adapts to the changes.

This checkpoint is complete when your team has assigned accountability for checking-up on any standardization efforts that were defined in Checkpoint 28. Each significant change should have a specific person assigned to it and a clearly defined schedule for performing the standardization review. The following analytical and decision-making tools may prove helpful in this Step:

Project Planning Sheet Action Plan

Key Point
ets FasTrack Summary 1 of 1:In the Control Step of DMAIC, what measures are taken to ensure the standardization changes

remain in place, even after the DMAIC team is disbanded? Answer: Assigning accountability & Monitoring to verify compliance

Step 5: Control - Checkpoint 30

30. Specific areas for replication were identified.


During these final DMAIC Steps, teams are responsible for identifying potential best practices, standards, or techniques that may be replicated in other areas of the organization. This single checkpoint can drive some of the most significant gains in an organization. Replication, in simple terms, has two important steps: First, teams must ensure that their good discoveries are communicated with everyone in an organization. Second, organizations must encourage everyone to incorporate other DMAIC team discoveries into their own processes.

Sharing The Success


Organizational processes, although different in application and purpose, often share similar steps or procedures. For example, the process of retrieving customer records may be performed by many different departments and for many different reasons. Although each department may use a customer's record differently, they all use similar procedures to obtain record data and update customer information. During the course of process management, teams often identify "better" methods of doing things or countermeasures that create dramatic improvement. When such methods are found, a team needs to share these methods throughout their organization so that others with similar processes can capitalize on the better technique. Whether a team simply improves a current method, or establishes a "breakthrough" technique that radically improves a process, there must be a concerted effort on the part of DMAIC teams and organizational management to encourage both improvement sharing and replication of best practices from other areas. Replication will not occur if management does not actively promote it; it won't happen automatically.

The Benefits Of Replication


Replicating a DMAIC project's success has tremendous value to an organization. The following paragraphs relate some of the fruits of DMAIC success replication.

Replication Maximizes Organizational Improvement


When a DMAIC team finds a way to increase efficiency 2% in a single process, this improvement is magnified many times when it is replicated in other areas. This simple concept is where DMAIC and improvement methods add some of their greatest value to an organization! A seemingly minimal improvement by one team can still add up to dramatic improvement organization wide.

For example, if your process team reduced the "minutes to access customer record" indicator by 2 minutes and shared this technique with 100 other departments that also access customer records, you have just turned a 2-minute improvement into more than a 3 hour improvement. Such gains are further magnified because organization wide improvement can drive better performance indicators of processes that are customers or suppliers of the improved process!

Avoids "Re-inventing The Wheel"


Re-inventing the wheel is a humorous way of describing rework. When a DMAIC team discovers a great new technique but fails to share it, there is a good chance that another team will invest time and effort to "re-invent" the same technique. By sharing good methods and best practices, teams not only encourage re-use of good ideas but also prevent other teams from wasting resources to reach similar conclusions. Reinventing the wheel is very costly: it delays replication, causes low-value rework, and ties up a DMAIC team that could be inventing a new technique. Good communication and replication will prevent teams from doing the same things, over and over.

Refines Good Practices Into Better Or Best Practices


Many times in business or organizations, it takes one stroke of brilliance to make a discovery and the perspective of another person to make that discovery a masterpiece. When good practices are communicated and shared, they become a baseline for future improvement of other management teams. This concept means that organizations who replicate improvements are continually improving the improvements. Refinement is generated by teams building on each other's work and continually replicating improvements. In fact, many of the improvement techniques used in DMAIC are the result of teams, teams just like yours, finding better ways to make formal problem solving work. This cycle of on-going P-D-C-A and replication eventually created industry leading "best practices." A best practice, simply stated, is a process that is believed to be the "best" way of doing something in terms of cost, quality, and value.

Methods To Ensure Replication


Replication will not automatically happen. Management must take an active role in encouraging teams to share improvements, and organization members to embrace improvements from other teams. One key requirement for replication is a functional understanding of DMAIC or process management, organization wide. It is difficult to explain a process improvement to someone that doesn't understand processes or indicators more often than not, they will simply perceive the changes as unwarranted or possibly even irritating. Basic understanding of processes, indicators, and data help employees communicate the value of shared improvements and it also assists in their application.

Another important factor for ensuring replication is proper documentation. When a good improvement occurs, others must know exactly what changes were performed to drive that improvement. Organization members should also have some means to contact someone in the original DMAIC management team, in case there are questions or problems. There are many techniques for encouraging replication:

Newsletters, e-mail, or web site updates. Annual improvement overview meetings. Internal quality awards or improvement team competitions. Internal quality departments.

New techniques can also be replicated by making them into standards. A standard would be an official organization procedure or level of performance, such as how and when to file an overtime request that is documented as the "right" way to do something. Standards are often listed in employee training manuals or other HR or procedural documentation.

This checkpoint is complete when your team has taken steps to promote replication. Remember that replication is the true "payoff" of your work! In fact, it is not uncommon for successful DMAIC teams to spend more time replicating and sharing their success with others than they spend on the initial DMAIC project. After all, sharing good news can be fun!

Key Point
ets FasTrack Summary 1 of 1:- -

What are three clear benefits of "replication" in DMAIC? Answer: Replication maximizes improvement, avoids "re-inventing the wheel," and helps refine good practices into better or "best" practices

Step 5: Control - Checkpoint 31

31. Any remaining problems of the theme were addressed.


In Checkpoint 31, DMAIC teams must make a judgment call as to whether or not their theme has been sufficiently improved. If you have a clearly defined theme indicator, as in the case of Process Management improvement teams, this may be an easy question to answer. If you do not have a clearly defined improvement target, your team may be required to have a meeting with leaders to determine if additional theme improvement would be beneficial. Perfection or "zero defects" are certainly ideal, but they are not always cost effective. Many improvements begin to have diminishing returns whereas your team spends months to make only trivial gains in the theme indicator. Remember that DMAIC is designed to tackle the most significant problems first. As a result, after your team resolves the first few problems, you have usually corrected almost all of the theme's shortfall. In the event that additional thematic improvement is required, your team should return to Checkpoint 6, the first Checkpoint in Step 2 of DMAIC, and select the next largest problem for correction. If a large amount of time has passed since your team performed the "Measure" Checkpoint, you may need to update your data. It is possible that countermeasures and other unexpected factors may have increased (or decreased) the severity of other problems. You may be wondering why this Checkpoint occurs after the replication Checkpoint. Even if your DMAIC team didn't drive theme improvement all the way to a desired level, you assuredly have some good ideas and countermeasures to share. Begin replicating success as soon as possible! The overall gains from effective replication will offset any minor costs associated with continuing improvement of the theme.

This checkpoint is complete when your team has determined if the project theme was improved to a point that is acceptable. Exactly what level of improvement that is acceptable will be determined by leadership, process management teams or Process Control Systems, standards, or even your own team's professional opinions. The following analytical and decision-making tools may prove helpful in this Step:

Pareto Chart Cost-Benefit Analysis

Key Point
ets FasTrack Summary 1 of 1:Why might a DMAIC project team need to address remaining problems?

Answer: If their overall thematic improvement was not sufficient and If they simply want to continually improve.

Step 5: Control - Checkpoint 32

32. Lessons learned, P-D-C-A of the ets six-sigma DMAIC Method, and team growth were assessed and documented.
After a DMAIC project has obtained stability and capability, and all of the documentation has been completed, your team should schedule a meeting to review the project. This review should be a casual meeting in which each person involved with the project has a chance to reflect on what went well with the project and what could be done better next time. Just as improving organizational processes require continual improvement, the DMAIC process itself should be continually refined and made better. Your team can also reflect on their own growth during the project, and share any insights or revelations that they gained. Radar charts can be used to quantify team member growth in a number of areas, and can be effectively created by using a simple team member survey. Even an informal survey here can generate some encouraging results. For example, ask staff members what their level of comfort with DMAIC was before the project? Next, ask them what their level of comfort is now? When noteworthy improvements or problems are identified, they should be documented and communicated with other teams. You should also make a point to celebrate successes and reward or acknowledge the extraordinary efforts of team members.

Plan - Do - Check - Act


P-D-C-A is a cycle based upon the premise that to always meet customer needs, you must continuously improve. You must plan what needs to be done, do (or implement) it, check the results of your actions (to ensure that you actually accomplished what you intended to do) and act upon the findings, applying lessons learned to future activities. The DMAIC problem solving method embraces the philosophy of using systematic approaches to generate improvement and share gains throughout an organization. Everything associated with performance excellence is built upon a foundation of continual refinement and growth.

This checkpoint is complete when your team has applied P-D-C-A to your DMAIC project and reflected on lessons learned via a discussion, project wrap-up, or a "We Did It!" celebration. This Checkpoint may seem trivial, but like replication, it has on-going benefit and can generate a surprising amount of growth and value. The following analytical and decision-making tools may prove helpful in this Step:

Radar (Spider) Chart

Key Point
ets FasTrack Summary 1 of 1:Why should the team review lessons learned after they finished a project?

Answer: To document improvements and share with other teams and to Celebrate success.

Step 5: Control - Checkpoint 33

33. The sponsor signed off on the results and next steps.
The final Checkpoint in DMAIC is to present the completed DMAIC story to your sponsor and receive their official sign off on the outcome of the project and your team's standardization and future plans. This final Checkpoint is critical because it forces teams to finalize their DMAIC story and document their work in a standardized manner. If this Checkpoint is skipped, there is a reasonable likelihood that a team will never finalize their DMAIC story and important outcomes, lessons learned, or on-going work will be forgotten. The final sponsor sign-off also gives leadership an opportunity to recognize the DMAIC team's hard work and success. Team sponsors should make a point to publicly congratulate their team and spread the good news that improvements have been made. Every organization can benefit from a bit of good P.R.? Don't miss these golden opportunities!

This checkpoint is complete when your team sponsor has reviewed a finalized DMAIC story, ensured that standardization has taken place, and that team effort has been rewarded and recognized. The following analytical and decision-making tools may prove helpful in this Step:

Party, recognition and award ceremony. Project Planning Worksheet Tollgate Review

Key Point
ets FasTrack Summary 1 of 1: Why should you recognize the outstanding performance of DMAIC team members?

Answer: Teams should be recognized for a job well done and it is also a good way to generate some positive publicity for a DMAIC project.

Step 5 - Summary

Objective:
Evaluate the results by confirming that the countermeasures taken impacted the root cause, the problem, and the theme; and that the target has been met. Standardize new methods, communicate lessons learned, and recommend future plans. During this step, your DMAIC team "Controls" their outcomes by verifying and understanding results, putting measures in place to standardize countermeasures and maintain gains, and devising "next steps" to support the P-D-C-A cycle.

Step Checkpoints Step Control - Results Checkpoint 24. The effect of countermeasures on the root causes was demonstrated. 25. The effect of countermeasures on the problem was demonstrated. 26. The improvement target was achieved and causes of significant variation were addressed. 27. The effect of countermeasures on the theme indicator representing the stakeholder's need was demonstrated. Step Control Standardization Checkpoint 28. A method was established to document, permanently change, and communicate the revised process or standard. 29. Responsibility was assigned and periodic checks scheduled to ensure compliance with the revised process or standard. 30. Specific areas for replication were identified. Step Control - Future Plans Checkpoint 31. Any remaining problems of the theme were addressed. 32. Lessons learned, P-D-C-A of the DMAIC process, and team growth were assessed and documented. 33. The sponsor signed off on the results and next steps.

Step 5: Control (Results Phase) - Bob's Pizza


Bob's Pizza: "We Specialize In Quality Pizza!"
Bob's Pizza is a franchised pizza delivery restaurant, dedicated to performance excellence and improving their organization. As a result, the owners of Bob's Pizza formed a DMAIC story team to ensure that they are meeting their stakeholder needs. The team has already established their theme statement, "Increase % of pizzas delivered within 30 minutes of order receipt," and their problem statement, "reduce on-road delays by 90%." They have also determined their three most likely root causes of on-road delays: driver knowledge, routing, and the driver's inability to find the delivery address. In the previous Step, we saw the team establish a set of three countermeasures along with implementation action plans. These countermeasures were: "train existing drivers, make a map system, and get directions from customer." We will now see if the DMAIC team was successful, and what their next steps will be.

Checkpoint 24
Once the countermeasures were set in action, the team followed through with all three action plans for the entire first quarter of 2003. We rejoin our discussion on the DMAIC team's progress with them reviewing their first quarter data after countermeasure implementation. The DMAIC team first re-interviewed their drivers to see if the new countermeasures had any effect on their root causes: driver knowledge, routing, and the driver's inability to find the address. Based on interview results, the drivers reported that driver knowledge was no longer an issue at all. Also, finding the address no longer caused any problems. The only root-cause related issues that remained were 2 occasions in which the driver was in the vicinity of a serious accident and the roads were closed for a while. Routing causes, which were once only 20% of all probable root causes, are now 100% of the on road delays. Since all of the root causes except routing were eliminated, and the only issues due to routing appeared to be beyond the control of the DMAIC team, it appears as if the countermeasures had an extremely positive impact on the root causes. Checkpoint 25 The DMAIC team gathered a fresh set of delivery data to see if their countermeasures had any effect on their problem of "on road delays." Figure 1 shows a before and after Pareto chart, stratifying the various problems that lead to late deliveries.

Figure 1: Before and After Measures By examining the data in Figure 1, the number of "on road" problems have certainly been reduced: from 100 to only 8. That's a 92% improvement. Overall, late deliveries dropped from 200 per year to only 116. By addressing this one problem, the team has reduced the total number of late deliveries nearly in half! Based on the information shown in Figure 1, would you say that the team was successful? Perhaps. There are a few factors that still must be considered. First, the team needs to verify that the changes that took place were, in fact, a result of their countermeasures. It is entirely possible that "on road" problems were reduced for other reasons. For example, perhaps a large shopping center opened up next door to Bob's Pizza, and now the majority of their customers' pizzas are now delivered next door. A change like this would certainly reduce the "on road" delays, but this improvement would not be as a result of DMAIC countermeasures. Another issue that must be mentioned in the annualization of data. Since Bob's Pizza used a year-long total from 2002, they simply could not evaluate year-end totals against data from only 3 months. To compensate, the Bob's Pizza DMAIC team "annualized" their data. The term annualized means, in this case, that they simply multiplied their results by four. This is a valid estimate, but it assumes that delivery performance and business conditions will be similar for the remaining three quarters of the year. In conclusion, it looks like the team may be successful but it is too early to tell. The team needs to ensure that second quarter (2Q) performance is on par with their results to date. If so, it will appear as if the team has reduced the largest problem into the smallest, and that is quite a success.

Checkpoint 26
Since the improvement target was achieved, and there was no variation, the team merely noted their concerns about annualization accuracy and the importance of on-going countermeasures implementation to continued success.

Checkpoint 27
The theme of the DMAIC project was to increase the percentage of pizzas delivered within 30 minutes of receipt. Based on the data shown in Figure 2, the team already met their goal of

90% on-time delivery by 1Q 2003, and in their improvements continue at a similar rate, they will be on track to achieve their goal by year end.

Figure 2: Improvement in On Road Delays

Checkpoint 28
To ensure that countermeasures were documented and would remain in place throughout the organization, the Bob's Pizza DMAIC team integrated their new countermeasures into the existing training materials. Additionally, all employees were provided with a special update newsletter that informed them of the change and why this change was good for Bob's Pizza as a whole. They also agreed on quarterly refresher training for managers, and on-going monitoring and improvement of the mapping system. The team also updated the process control systems for the delivery and order taking processes, taking special care to integrate the new countermeasures into the existing processes. For example, the "order takers" now know to ask for directions to a home if it is not already listed in the map system. This step was built into the process flowchart, and added to all the checklists and scripts used by the staff. The acceptable indicators for root causes and problems were also added into the process flows so that new issues can be addressed before they have a negative effect on customer satisfaction.

Checkpoint 29
The DMAIC team decided to assign accountability for each countermeasure to a particular position in each store. Assistant managers would be responsible for maintaining the training program. During the regular, quarterly manager meetings, assistant mangers are required to provide a status report on training progress to ensure that their staff continue to follow the new procedures. Drivers are all responsible for updating the maps and they receive a free pizza anytime they find an error or omission on the store map these free pizzas cost the company next to nothing and are a real motivator for staff assistance! The order takers also have an incentive

to help. Order takers are accountable for adding directions into the map system when an unfamiliar address is provided. Every time an order takes adds 10 new address directions to the map system, they also earn a free pizza. Even with the reward system in place, assistant managers are still expected to review their employees to ensure that they remain vigilant in application of the countermeasures.

Checkpoint 30
Replication for Bob's Pizza is easy. This store may be small, but it is part of a national chain; what works in one store can usually be replicated into other franchises as well. Another potential area for replication is to help suppliers. By applying many of the same analysis and countermeasures, the DMAIC team may be able to improve delivery times for pizza dough, sauce, and toppings to their stores.

Checkpoint 31
The team knows they were successful, but they still have work to do. Although more than 90% of deliveries are now on-time, management would like to see 100% of deliveries made on time. Since further theme improvement is required, the team returns to their data and begins working on the next largest problem. Based on current data shown in Figure 1 above, it looks like the DMAIC team needs to figure out how to eliminate cooking delays.

Checkpoint 32
The DMAIC team decided to get together for coffee and reflect on what they did right during the project, and what they could have done better. One suggestion was to use non-annualized data next time, this way the team could be more certain about their improvements. The team noted this suggestion and documented it so they could make adjustments to their DMAIC procedure. The team also felt that their leader, R. Chen really put in an extraordinary amount of effort. As a result, they purchased him a special shirt with their DMAIC team logo printed on the side.

Checkpoint 33
As a final step, the team met with their sponsor and brought their finalized DMAIC story. The sponsor reviewed their work, asked what their next steps were and why they felt the next steps were necessary. Once the supervisor was satisfied, the entire team received plaques for their work and were highlighted in the next month's company newsletter.

The Bob's Pizza Improvement Story


The entire Bob's Pizza improvement story is available for download, printing, and review. You may find it useful to see how an actual improvement story is created using the information shown on this page.

What You Have Learned A Formal Problem Solving Method


The ets Six Sigma DMAIC method is a way to solve problems. It was designed to effectively guide you through problem resolution, set the stage for continuous improvement, and enable you to communicate your approach to others all while facilitating quick understanding and decision making. You can think of the DMAIC method as a step-by-step procedure that helps a team troubleshoot a problem and find the best solution. DMAIC also uses many principles that are fundamental to Six Sigma, including analytical tools, decision-making tools, and a structured process for selecting best outcomes. If you understand the value of this approach, you are well on your way to becoming a Six Sigma expert! As you have read in this course, DMAIC (and other formal problem solving methodologies) are dynamic processes that are continually being improved and revised. Although the Steps and Checkpoints may differ over time, the general logic will remain the same: use data to sift through a problem and find the most significant cause, correct it, and continue until performance is acceptable. To help you learn to apply the DMAIC process, this course was presented in a series of 5 Steps and 33 Checkpoints. These sections are cataloged below for your convenience.

The DMAIC Method Overview The ets DMAIC method is composed of 5 steps and 33 checkpoints, each of which represents a favorable outcome in the problem solving process. These steps and checkpoints are used to help segment the problem solving process into a logical series of actions. By using a series of steps, teams can complete the problem solving process by following step-by-step instructions. In the context of this course, "steps" refer to the major operations in the DMAIC process: Define, Measure, Analyze, Improve and Control. The term "checkpoints" refers to the smaller actions that make up the larger steps. For example, "Step 1: Define" has 5 checkpoints in it.

Step 1: Define The first step in DMAIC, "Define" contains checkpoints that help a team demonstrate the significance of a particular improvement need, with data, and develop a schedule for completing the DMAIC method.

Step 2: Measure Whereas the objective of Step 1 was to quantify the significance of a particular improvement need or theme, the objective of Step 2 is to focus more closely on the theme that you selected and find a specific problem within it to improve. During Step 2 you investigate critical features of the theme and select a specific problem to improve. The theme must be examined, stratified, and analyzed from various viewpoints before your team can discover the significant problem.

Step 3: Analyze Step 3 is composed of activities that help illustrate the reasons why a problem statement exists, and walk improvement teams through the process of finding the most significant, or "root causes," of the problem. Just as selecting the most significant problem is critical to efficiently improving the theme, selecting the most significant cause will also generate the most efficient gap reduction. Remember that much of the DMAIC process involves sorting through the "trivial many" to find the "significant few."

Step 4: Improve In Step 4, "countermeasures" are selected, tested, and evaluated for use in correcting the root causes from Step 3. A countermeasure is a refined idea that you, or your team, feels will reduce or eliminate the a cause.

Step 5: Control Step 5 of the DMAIC process is the step in which a team confirms that their improvements were successful, their efforts remain effective, and the theme of the project is completely addressed.

How Is This Knowledge Applied?


Solving Many Types Of Problems With Data
Although the DMAIC process has been exclusively applied to organizational improvement throughout this course, you might be surprised to learn how effective this approach is at solving other problems. In most problems, there is usually one cause that constitutes the majority of the problem. When these significant causes are addressed and corrected, often times many of the related issues will improve as well. In some cases, problems that appear tremendous are actually one big problem and lots of symptoms: one ROOT cause and lots of related causes. In debt management courses you are often taught to continually find the most costly bill and pay it off first. This is not always the highest interest rate credit card! By continually finding the "biggest bar on the Pareto," you will be taking the quickest path to being debt free. In car repair, often times one major malfunction can spawn a cascade of other parts to fail. Since automobiles are so tightly related and reliant on other systems, failing to find the "root cause" of a problem can have costly and inconvenient side effects. You can even try DMAIC in your daily life to make more free time or save some money. Simply sit down and analyze your days just as you would an organization. More likely than not, you will find one or two issues that eat up most of your time. By continually finding the biggest time waster and making minor improvements in it, you can really make a difference. Consider what would happen if you woke up 5 minutes earlier every day for a year. That simple change would provide more than 30 additional hours a year to do what you want, or what needs to be done.

DMAIC Is A Process And A Philosophy


There is nothing magic about DMAIC. You can't use it to solve unsolvable problems, nor can DMAIC create improvement that wasn't inherently capable in an organization to begin with. DMAIC is simply a procedure that will help you become a better problem solver. Just as a golf-pro can teach you techniques to improve your swing, DMAIC shows you some proven methods for achieving your goals. However, in both the case of the golf and DMAIC, mastery will only come with practice. A lot of "hype" is attached to performance excellence to sell books, conferences and lectures. This hype has the unavoidable effect of overselling what DMAIC, or any formal problem solving method, can accomplish. Nonetheless, DMAIC can accomplish dramatic gains and save your organization millions, or billions, of real dollars even in the first year. The success of your DMAIC projects will rely solely on how well they are selected, executed, and supported by management. Phillip Crosby, a performance management guru, is credited with saying "quality is free." What he meant by that statement is that the amount of effort invested in any well-executed performance improvement initiative will always generate much greater returns. When DMAIC is properly applied, along with process management, organizations will easily achieve a 10 to 1 return on their investment, some 20 to 1 or more. In other words, if the total cost of employee time, countermeasures, and advisement for improvement efforts was $100,000, your organization should expect at least a $1 million return in real savings, possibly even 2$

million or more- and these are savings that continue to provide return on investment, year after year.

ets FasTrack COMPLETED


You have now completed the REQUIRED portion of this course for the ets FasTrack certificate of completion, but don't close your browser yet. Please take a moment to read the paragraphs below, which outline some of the other valuable information and tools provided in optional sections of this course. First, don't forget to take the final exam for the course! By completing the exam and obtaining a score of 80% or higher, you will receive the certificate of completion for this course. The exam may be taken at any time in the next year, by clicking on the exam button in the upper left hand corner of your screen. You are welcome to wait and take the exam after you have had time to read through some of the appendices, or practice using the DMAIC and Six Sigma concepts. You can also take the exam as many times as you need. The remainder of this course contains links to much of the content provided in the complete ets courses Analytical Tools, Decision Making Tools, and Process Management. You may access this material using the appendices, or the quick reference tables provided in the "Brief Overview Of Six Sigma" section at the beginning of this course. You are strongly encouraged to "look around" in the appendices by clicking on the navigation links located on the left hand side of this screen. To do so, click the "+" icons to expand chapter and view the individual pages. For example, you can learn all about building process flowcharts by opening the "Appendix 2: Decision Making Tools" section and then clicking the "+" next to process flowcharts. A complete list of pages on that topic will be displayed. Since this was a FasTrack course, we covered a lot of material in a short amount of time. It is up to you to continue learning and refer to this online resource when you need it. Don't forget to login and take advantage of this resource when you need guides, templates, or some quick answers to Six Sigma questions.