The document provides an overview of Six Sigma, explaining that it is a management system that uses data and systematic approaches to continually improve quality and performance. It discusses the five major areas of Six Sigma: analytical tools, decision-making tools, process management, the DMAIC problem solving process, and leadership/strategic planning. The course will provide a quick overview of key Six Sigma concepts and then focus on walking through the DMAIC problem solving process step-by-step using an example.

1. SIX SIGMA
FAST TRACK
COURSE
MAY 2008

2. 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.

3. 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.

4. 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

5. 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.

6. • 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.

7. 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.

8. 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.

9. 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.

10. 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.)

11. • 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

12. 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®).

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

14. 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.

15. 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".

16. 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.

17. 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.

18. 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.

19. 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).

20. 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.

21. 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.

22. 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?

23. 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

24. 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.

25. 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 front-
line 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:

26. 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

27. 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

28. 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.

29. 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.

30. 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.

31. 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.

32. 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.

33. 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.

34. 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.

35. 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 decision-
making and that the decision that has been made is one that everyone can support, if
not 100% agree with.

36. 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:

37. 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.

38. 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.

39. 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.

40. 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

41. 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."

42. 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

43. • 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:

44. 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:

45. 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.

46. 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.

47. 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.

48. Best Practices In Survey Design
Typical Surveys Good Surveys
1. Identify / validate customer needs 1. Identify / validate customer needs by
customer segment
2. Measure customer satisfaction overall. 2. Measure customer satisfaction overall:
… by customer segment
… by valid requirement
3. Assist in stratifying the customer
satisfaction data.
3. Assist in stratifying the customer
satisfaction data.
… by customer segment
… by pertinent what, where, when, who
categories
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.

49. 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:

50. 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

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

52. 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.

53. • 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 Checkpoint
1. Key work processes were identified and prioritized according to stakeholder impact and
need for improvement.
Select
Process
2. Top priority process was selected.
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.
Construct
Process
Flowchart
7. Process champion was identified.
8. Process objective was stated.Identify
Indicators
9. Customer needs and requirements were identified and prioritized.

54. 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.
19. Process was evaluated for stability (e.g., six interpretation approaches).Monitor
Process
Control
System
20. Process was evaluated for capability (e.g., histograms).
21. Systematic improvement techniques were used (six-sigma DMAIC method).Improve
Process
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.
Standardize
Process
25. Applied P-D-C-A to lessons learned.

55. 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 Checkpoint
1. Key work processes were identified and prioritized according to stakeholder impact and
need for improvement.
Select
Process
2. Top priority process was selected.

56. 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 are involved in providing customer (internal and external) products and
services?
• What activities are described in your Job Descriptions?
• What activities are described in Procedures Manuals?
• What activities are involved in achieving organization Standards?
• What activities are described on department checklists?
• What activities are involved in processing organization forms?
• What activities 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.

57. a. Complete Accounting Reports
b. Generate Plant Production Schedule
c. Manage Plant Inventory
d. Fill Orders
e. Ship Product in Rail Cars
f. Ship Product in Trucks
g. Schedule Rail Car Movements
h. Supervise Clerical Staff

58. 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?

59. 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 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.
Construct
Process
Flowchart
7. Process champion was identified.

60. 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.

61. 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

62. 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.

63. 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. Multiple reviews.
2. Rework loops. (See Figure 1 for a good example of rework loops.)
3. Idle time (wait time, dead time, etc.)
4. Too many hand-offs between process players.

64. 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

65. 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.

66. 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.

67. 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.

68. 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.

69. 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.

70. 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 Charts are plotted for process related activities.
o Documentation is completed for process activities.
o Improvement action is taken and accountability is maintained.
o 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. ?

71. 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 Checkpoint
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.
Identify Indicators
14. Quality and process indicators were noted on flowchart.

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

73. 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.

74. 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.

75. 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.

76. 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.

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

78. 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. Define your data collection goals.
2. Develop rules and procedures for the data collection.
3. Validate your measurements.
4. Collect data.
5. 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?

79. 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 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.

80. 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

81. "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.

82. 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.

83. 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 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.

84. 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:

85. 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.

86. 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

87. 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.

88. 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!

89. 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.

90. 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.

91. 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.

92. 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.

93. 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

94. 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 P-
D-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.

95. 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.

96. 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

97. 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 Checkpoint
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.

98. 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

99. 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.

100. 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.

101. 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

102. 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)

103. 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.

104. 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

105. 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 on-
going 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.

106. 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 Checkpoint
19. Process was evaluated for stability (e.g., six interpretation approaches).Monitor
Process
Control
System
20. Process was evaluated for capability (e.g., histograms).

107. 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

108. 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?

109. 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?

110. 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

111. 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 Checkpoint
21. Systematic improvement techniques were used (six-sigma DMAIC method).Improve
Process
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

112. 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.

113. 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.

114. 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.

115. Figure 1: An Action Plan

116. 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 Checkpoint
23. Method was established to ensure process standards continuously reflect customer
requirements.
24. Specific areas for replication were considered.
Standardize
Process
25. Applied P-D-C-A to lessons learned.

117. 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:

118. • 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

119. 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 low-
value 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.

120. 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.

121. 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

122. 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 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.
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

123. 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 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.
1. Define
5. The sponsor signed off on the project’s purpose, scope, and significance.
6. The theme was stratified from various viewpoints and a significant problem was
chosen.
7. A target for improvement was established based on the stakeholder's 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.
2. Measure
10. Measurement and data collection systems were developed.

124. 11. The sponsor signed off on the project’s focus and target.
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.
3. Analyze
16. The sponsor signed off on the verified root causes and impact on the gap.
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.
4. Improve
23. The sponsor signed off on the action plan and expected results.
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.
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.
31. Any remaining problems of the theme were addressed.
32. Lessons learned, P-D-C-A of the ets Six Sigma DMAIC Method, and team growth
were assessed and documented.
5. Control
33. The sponsor signed off on the results and next steps.

125. 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 Define
Step 2 Measure
Analyze
Identify potential root causesStep 3
Verify root causes with data
ImproveStep 4
Develop and pilot
Plan

126. Implement Do
Control
Quantify improvements
Check
Standardize
Step 5
Plan for the future
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 Checkpoint
Define 1. The stakeholder and need were identified.

127. 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 project’s 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 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 stakeholder’s need.
8. The impact of the target on the theme indicator was determined.
Measure
9. A problem statement that addressed the gap between the actual and target values was
developed.

128. 10. Measurement and data collection systems were developed.
11. The sponsor signed off on the project’s 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 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.
Analyze
16. The sponsor signed off on the verified root causes and impact on the gap.
Step 4: Improve

129. 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 problem’s 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 questions—who, 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 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.
Improve
23. The sponsor signed off on the action plan and expected results.
Step 5: Control - Results Phase

130. 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 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.
Control -
Results
27. The effect of countermeasures on the theme indicator representing the stakeholder's
need was demonstrated.

131. 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

132. 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.

133. 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.

134. 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.

135. 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.

136. 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."

137. 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.

138. 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

139. 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:

140. The following analytical and decision-making tools may prove helpful in this Step:
•
• Project Planning Worksheet
Step 1: Define - Checkpoint 5

141. 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.

142. 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.

143. 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, "Win-
Win" 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.

144. 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)

145. 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".

146. 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

147. 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.

148. 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.

149. 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.

150. 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. Define your data collection goals.
2. Develop rules and procedures for the data collection.
3. Validate your measurements.
4. Collect data.
5. 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."

151. 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.

152. 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.

153. 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

154. • 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?

155. - 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

156. 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

157. 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

158. 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.

159. 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.

160. 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

161. 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)

162. 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

163. 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?

164. - 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

165. 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.

166. 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.

167. 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 cost-
benefit 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 )

168. 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:

169. 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.

170. 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 )

171. 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:

172. 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.

173. 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 )

174. 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

175. 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.

176. 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.

177. 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.

178. 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.

179. 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.

180. 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

181. 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:

182. 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.

183. 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.

184. 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.

185. 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.

186. 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

187. 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

188. 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

189. 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

190. 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. Re-
inventing 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

191. 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.

192. 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

193. 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:

194. • 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

195. 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

196. 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

197. 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

198. 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.

199. 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.

200. 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 loan-
processing 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

201. 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)

202. 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.

203. • 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.

204. 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

205. 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.

206. 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

207. 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

208. 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

209. 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

210. 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."

211. 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

212. 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.

213. 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

214. 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

215. 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.

216. 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.

217. 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.

218. 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

219. 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

220. 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.

221. 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.

222. 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.

223. • 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

224. 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.

225. 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.

226. 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

227. 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.

228. 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 non-
conformance, 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

229. 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

230. 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).

231. 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

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

233. 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 Define
Step 2 Measure
Analyze
Identify potential root causesStep 3
Verify root causes with data
Improve
Develop and pilot
Plan
Step 4
Implement Do
Step 5 Control Check

234. Quantify improvements
Standardize
Plan for the future
Act
Figure 1: The ets Six Sigma DMAIC Method— A Formal Problem Solving Process
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.

235. 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-to-
communicate" 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

236. 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 system–it 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.

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

238. 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 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.
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.

239. 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:

240. 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

241. 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 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.
1. Define
5. The sponsor signed off on the project’s purpose, scope, and significance.
6. The theme was stratified from various viewpoints and a significant problem was
chosen.
7. A target for improvement was established based on the stakeholder's 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.
2. Measure
11. The sponsor signed off on the project’s focus and target.
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.
3. Analyze
14. A relationship between the root causes and the problem was verified with data.

242. 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.
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.
4. Improve
23. The sponsor signed off on the action plan and expected results.
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.
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.
31. Any remaining problems of the theme were addressed.
32. Lessons learned, P-D-C-A of the ets Six Sigma DMAIC Method, and team
growth were assessed and documented.
5. Control
33. 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?

243. 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

244. 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.

245. 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.

246. 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.

247. 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.

248. 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!

249. 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.

250. 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

251. 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

252. "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!

253. 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

254. 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 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.
Define
5. The sponsor signed off on the project’s purpose, scope, and significance.

255. Key Point
ets FasTrack
Summary 1 of 1: What provides evidence of DMAIC improvement need?
Answer: Data

256. 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

257. 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.

258. 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.

259. 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.

260. 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.

261. 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.

262. 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.

263. 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

264. 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 Good Surveys
1. Identify / validate customer needs 1. Identify / validate customer
needs by customer segment
2. Measure customer satisfaction overall. 2. Measure customer
satisfaction overall:
… by customer segment
… by valid requirement
3. Assist in stratifying the customer satisfaction data. 3. Assist in stratifying the
customer satisfaction data.
… by customer segment
… by pertinent what,
where, when, who
categories

265. 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

266. 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

267. 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

268. 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:

269. 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

270. 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

271. 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

272. 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-the-
minute" 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

273. 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

274. 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.

275. 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?"

276. 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

277. 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.

278. 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."

279. 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.

280. 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?

281. 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:

282. •
• 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 decision-
making 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

283. 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

284. 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:

285. The following analytical and decision-making tools may prove helpful in this Step:
•
• Project Planning Worksheet

286. 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.

287. 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.

288. 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.

289. 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

290. 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:
•

291. • 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

292. 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.

293. • 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

294. 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 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.
Define
5. The sponsor signed off on the project’s 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.

295. 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-of-
process "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” = 88% M6
2. % Satisfied with “Prepared your way” = 92% M5
3. % Satisfied with “Pizzas are tasty” = 93% M4
4. % Satisfied with “Quick delivery” = 78% M3
5. % Satisfied with “Price is right” = 89% M2
6. % Overall satisfaction with pizza = 86% M1

296. 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

297. 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.

298. 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 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 stakeholder’s 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.
Measure
11. The sponsor signed off on the project’s focus and target.

299. 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.

300. 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

301. 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.

302. Figure 1: The Theme Analysis Process

303. 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

304. 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

305. 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.

306. 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?

307. 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

308. 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

309. 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

310. 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."

311. 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.

312. 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

313. 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)

314. 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

315. 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) =

316. 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
Sigma Level (# of standard
deviations)
933200 0
915450 .125
894400 .25
869700 .375
841300 .5
809200 .625
773400 .75
734050 .875
691500 1
645650 1.125
598700 1.25
549750 1.375
500000 1.5

317. -
DPMO
Sigma Level (# of standard
deviations)
450250 1.625
401300 1.75
354350 1.875
308500 2
265950 2.125
226600 2.25
190800 2.375
158700 2.5
130300 2.625
105600 2.75
84550 2.875
66800 3
52100 3.125
40100 3.25
30400 3.375
22700 3.5
16800 3.625
12200 3.75
8800 3.875
6200 4
4350 4.125
3000 4.25
2050 4.375
1300 4.5
900 4.625
600 4.75
400 4.875
230 5
180 5.125
130 5.25
80 5.375
30 5.5
23.35 5.625
-

318. DPMO
Sigma Level (# of standard
deviations)
16.7 5.75
10.05 5.875
3.4 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.

319. 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, "Win-
Win" 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).

320. 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"

321. 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.

322. 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

323. 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

324. 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) data-
collection 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.

325. 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

326. 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.

327. 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.

328. 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.

329. 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

330. 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.

331. • 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

332. 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

333. 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. Define your data collection goals.
2. Develop rules and procedures for the data collection.
3. Validate your measurements.
4. Collect data.
5. Continually improve measurement accuracy.

334. 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

335. 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.

336. 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

337. 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.

338. 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 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 stakeholder’s 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.
Measure
11. The sponsor signed off on the project’s focus and target.

339. 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.

340. 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.

341. 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 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.
Analyze
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:

342. 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.

343. 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.

344. 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.

345. 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.

346. 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.

347. 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

348. 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

349. 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

350. 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:

351. 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.

352. 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

353. 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.

354. 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

355. 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.

356. 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

357. 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 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.
Analyze
16. The sponsor signed off on the verified root causes and impact on the gap.

358. 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

359. 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. Driver Knowledge (50%)
B. Routing (20%)
C. Can't Find Address (10%)
D. 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.

360. 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 problem’s 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 questions—who, 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 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.
Improve
22. Incorporated lessons learned from the pilot into the full-scale action plan and

361. 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.

362. 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?

363. 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.)

364. 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.

365. 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:

366. 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

367. 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 cost-
benefit 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

368. 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:

369. 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

370. 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

371. 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.

372. 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:

373. 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

374. 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.

375. 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

376. 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

377. 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

378. 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

379. 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.

380. 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

381. 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 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.
Improve
23. The sponsor signed off on the action plan and expected results.

382. 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

383. 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.

384. 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.

385. 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.

386. 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.

387. Step Checkpoints
Step 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.
Control -
Results
27. The effect of countermeasures on the theme indicator representing the stakeholder's
need was demonstrated.

388. 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
28. A method was established to document, permanently change, and communicate the
revised process or standard.
Control -
Standardization
29. Responsibility was assigned and periodic checks scheduled to ensure compliance
with the revised process or standard.

389. 30. Specific areas for replication were identified.

390. 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 Six-
Sigma 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
31. Any remaining problems of the theme were addressed.
32. Lessons learned, PDCA of the DMAIC process, and team growth were assessed and documented.
Control -
Future
Plans
33. The sponsor signed off on the results and next steps.

391. 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.

392. 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:

393. 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

394. 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.

395. 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.

396. 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

397. 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.

398. 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

399. 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.)

400. 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

401. 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

402. 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

403. 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

404. 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

405. 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.

406. 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. Re-
inventing 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.

407. 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

408. 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

409. 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.

410. 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

411. 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.

412. 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.

413. 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 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.
Control - Results
27. The effect of countermeasures on the theme indicator representing the
stakeholder's need was demonstrated.
Step 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.
Control -
Standardization
30. Specific areas for replication were identified.
Step 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.
Control - Future
Plans
33. The sponsor signed off on the results and next steps.

414. 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.

415. 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

416. 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

417. 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.

418. 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.

419. • 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.

420. 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$

421. 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.