Six Sigma A Complete Step by Step Guide

SIX SIGMA:
A COMPLETE STEP-BY-STEP GUIDE
i
© 2018 The Council for Six Sigma Certification. All rights reserved.
Harmony Living, LLC, 412 N. Main St, Suite 100, Buffalo, WY 82834
July 2018 Edition
Disclaimer: The information provided within this book is for general informational purposes
only. While we try to keep the information up-to-date and correct, there are no
representations or warranties, express or implied, about the completeness, accuracy,
reliability, suitability or availability with respect to the information, products, services, or
related graphics contained in this eBook for any purpose. Any use of this information is at
your own risk.
The author does not assume and hereby disclaims any liability to any party for any loss,
damage, or disruption caused by errors or omissions, whether such errors or omissions
result from accident, negligence, or any other cause.
ii
SIX SIGMA: A COMPLETE STEP-BY-STEP GUIDE
Using the most recent edition in your workplace?
Because we continually attempt to keep our Handbook up to date with the latest industry
developments, be sure to check our website often for the most recent edition at
www.sixsigmacouncil.org.
iii
iv
v
vi
vii
Six Sigma, or 6, is both a methodology for process improvement and a statistical concept
that seeks to define the variation inherent in any process. The overarching premise of Six
Sigma is that variation in a process leads to opportunities for error; opportunities for error
then lead to risks for product defects. Product defects—whether in a tangible process or a
service—lead to poor customer satisfaction. By working to reduce variation and
opportunities for error, the Six Sigma method ultimately reduces process costs and
increases customer satisfaction.
In applying Six Sigma, organizations, teams, and project managers seek to implement
strategies that are based on measurement and metrics. Historically, many business leaders
made decisions based on intuition or experience. Despite some common beliefs in various
industries, Six Sigma doesn’t remove the need for experienced leadership, and it doesn’t
negate the importance of intuition in any process. Instead, Six Sigma works alongside other
skills, experience, and knowledge to provide a mathematical and statistical foundation for
decision making. Experience might say a process isn’t working; statistics prove that to be
true. Intuition might guide a project manager to believe a certain change could improve
output; Six Sigma tools help organizations validate those assumptions.
8
Without proper measurement and

analysis, decision making processes in What is beta testing?
an organization might proceed as
Beta testing is the act of implementing
follows:
a new idea, system, or product with a
 Someone with clout in the select group of people or processes in
organization has a good idea as controlled an environment as
or takes interest in someone possible. After beta testers identify
else’s idea. potential problems and those
 Based on past experience or problems are corrected, the idea,
knowledge, decision makers
system, or product can be rolled out to
within an organization
the entire population of customers,
believe the idea will be
successful.
employees, or processes. The purpose
 The idea is implemented; of beta testing is to reduce the risks
sometimes it is implemented and costs inherent in launching an
in beta mode so expenses unproven product or system to a
and risks are minimized. widespread audience.
 The success of the idea is
weighed after implementation; problems are addressed after they impact products
or processes in some way in the present or the future.
Beta testing is sometimes used in a Six Sigma approach, but the idea or change in question
goes through rigorous analysis and data testing first. The disadvantage of launching ideas
into beta—or to an entire population--without going through a Six Sigma methodology is
that organizations can experience unintended consequences from changes, spend money
on ideas that don’t end up working out as planned, and impact customer perceptions
through trial-and-error periods rife with opportunities for error. In many cases,
organizations that don’t rely on data make improvements without first understanding the
true gain or loss associated with the change. Some improvements may appear to work on
the surface without actually impacting customer satisfaction or profit in a positive way.
The Six Sigma method lets organizations identify problems, validate assumptions,
brainstorm solutions, and plan for implementation to avoid unintended consequences. By
applying tools such as statistical analysis and process mapping to problems and solutions,
9
WHAT IS SIX SIGMA?
teams can visualize and predict outcomes with a high-level of accuracy, letting leadership
make decisions with less financial risk.
Six Sigma methods don’t offer a crystal ball for organizations, though. Even with expert use
of the tools described in this book, problems can arise for teams as they implement and
maintain solutions. That’s why Six Sigma also provides for control methods: once teams
implement changes, they can control processes for a fraction of the cost of traditional
quality methods by continuing the use of Six Sigma tools and statistics.

Six Sigma as a methodology for process improvement involves a vast library of tools and
knowledge, which will be covered throughout this book. In this section, we’ll begin to define
the statistical concept represented by 6
At the most basic definition, 6is a statistical representation for what many experts call a
“perfect” process. Technically, in a Six Sigma process, there are only 3.4 defects per million
opportunities. In percentages, that means 99.99966 percent of the products from a Six
Sigma process are without defect. At just one sigma level below—5, or 99.97 percent
accuracy--processes experience 233 errors per million opportunities. In simpler terms, there
are going to be many more unsatisfied customers.
According to the National Oceanic and Atmospheric Administration, air traffic controllers in
the United States handle 28,537 commercial flights daily.1 In a year, that is approximately
10.416 million flights. Based on a Five Sigma air traffic control process, errors of some type
occur in the process for handling approximately 2,426 flights every year. With a Six Sigma
process, that risk drops to 35.41 errors.
The CDC reports that approximately 51.4 million surgeries are performed in the United
States in a given year.2 Based on a 99.97 accuracy rate, doctors would make errors in 11,976
surgeries each year, or 230 surgeries a week. At Six Sigma, that drops to approximately 174
errors a year for the entire country, or just over 3 errors each week. At Five Sigma, patients
are 68 times more likely to experience an error at the hands of medical providers.
1
“Air Traffic,” Science on a Sphere, National Oceanic and Atmospheric Administration.
http://sos.noaa.gov/Datasets/dataset.php?id=44
2
“Inpatient Surgery,” FastStats, Centers for Disease Control and Prevention.
http://www.cdc.gov/nchs/fastats/inpatient-surgery.htm
10
While most people accept a 99.9 percent accuracy rate in even the most critical services on
a daily basis, the above examples highlight how wide the gap between Six Sigma and Five
Sigma really is. For organizations, it’s not just about the error rate—it’s also about the costs
associated with each error.
Consider an example based on Amazon shipments. On Cyber Monday in 2013, Amazon

processed a whopping 36.8 million orders.3 Let’s assume that each order error costs the
company an average of $35 (a very conservative number, considering that costs might
include return shipping, labor to answer customer phone calls or emails, and labor and
shipping to right a wrong order).
Cost of Amazon Order Errors, 5

Total Orders Errors Average Cost per Total Cost of
Error Errors
36.8 million 8574.4 $35 $300,104.00
Cost of Amazon Order Errors, 6

Total Orders Errors Average Cost per Total Cost of
Error Errors
36.8 million 125.12 $35 $4,379.20
For this example, the cost difference in sigma levels is still over $295,000 for the Cyber
Monday business.
For most organizations, Six Sigma processes are a constant target. Achieving and
maintaining Six Sigma “perfection” is difficult and requires continuous process
improvement. But even advancing from lower levels of sigma to a Four or Five Sigma
process has a drastic impact on costs and customer satisfaction. Let’s look at the Amazon
Cyber Monday example at other levels of sigma.
3
Siegel, Jacob, “Amazon sold 426 items per second during its ‘best ever’ holiday season,”
Boy Genius Reports, Dec. 26, 2013. http://bgr.com/2013/12/26/amazon-holiday-season-
sales-2013/
11
WHAT IS SIX SIGMA?
Sigma Level Defects per Million Estimated Cyber Total Cost (at $35
Opportunities Monday Defects estimate per
error)
One Sigma 690,000 25,392,000 $888,720,000
Two Sigma 308,000 11,334,400 $396,704,000
Three Sigma 66,800 2,458,240 $86,038,400
Four Sigma 6,200 228,160 $7,985,600
Five Sigma 233 8,574.4 $300,104
Six Sigma 3.4 125.12 $4,379
At very low levels of sigma, any process is unlikely to be profitable. The higher the sigma
level, the better the bottom line is likely to be.
Organizations and teams can calculate the sigma level of a product or process using the
equation below:
Consider a process in a marketing department that distributes letters to customers or

prospects. For the purposes of the example, imagine that the process inserts 30,000 letters
in preaddressed envelopes each day. In a given business week, the process outputs 150,000
letters.
The marketing department begins receiving complaints that people are receiving letters in
envelopes that are addressed to them, but the letters inside are addressed to or relevant to
someone else. The marketing department randomly selects 1,000 letters from the next
week’s batch and finds that 5 of them have errors. Applying that to the total amount, they
12
estimate that as many as 750 letters could have errors. (Sampling and extrapolation are
covered in depth in the advanced chapters on statistics.)
The letter process has 150,000 opportunities for error each week and an estimated 750
defects.
((150,000 – 750) / 150,000) * 100 = a yield of 99.5
Look up a yield of 99.5 in the abridged Sigma table below and you’ll see the process
described above is currently between 4 and 4.1 sigma.
Yield % DPMO Sigma Level
99.7450 2,550 4.3
99.6540 3,460 4.2
99.5340 4,550 4.1
99.3790 6,210 4.0
99.1810 8,190 3.9
Sigma levels provide organization with a high-level look at how a process is performing, but
comparing sigma levels between multiple processes doesn’t always point to the particular
process an organization should improve first. Leadership should also consider costs,
resources, and the estimated impact of improvements.
13
WHAT IS SIX SIGMA?
For example, consider these processes that might be found in a food processing plant:
Process Performance Metric(s) Current Sigma Level
Attaching a decorative Decorative touch is 2.2

element to food item centered on food
product and stable so it
won’t fall off in transit
Packing product Product is sealed for 3.1

freshness
Shipping of product Product reaches the right 4.3

customer in a timely
manner
A glance at sigma levels indicates that the process that attaches the decorative element is in
most need of improvement. While that process has the highest rate of defects, leadership
within the plant would have to ask themselves: How much does that matter to the
customer, and what is the hit to the bottom line?
It’s likely that most customers will notice most that the product is sealed for freshness and
reaches the right location. Since bad product has to be thrown away, the most expensive
errors might be associated with improper sealing during packing. The plant is likely to use
resources to improve the packing process before addressing the decorative element issue.
After the packing process is improved, the plant might then consider whether to improve
the decorating process or the shipping process. As part of that consideration, the company
might conduct customer surveys to reveal that some customers have stopped buying the
product because of the decorative element issue. An analyst estimates that the loss of sales
related to that issue are costing the company $1,000 a week. Shipping issues are costing the
company $500 a week.
Should the company address the costlier issue first? What if you were told that the shipping
process could be improved with staff training sessions, while the decorative element issue
required an expensive machinery update? Sometimes, organizations have to consider the
expense of an improvement. Applying a Six Sigma project to all situations isn’t financially
14
lucrative since those improvements take time and money. A Six Sigma culture is about
continuous improvement, which means teams consider all options before embarking on the
most lucrative improvement measures.
Organizations can impact their sigma level by integrating core principles from the Six Sigma
methodology into leadership styles, process management, and improvement endeavors.
The principles of Six Sigma, and the tools used to achieve them, are covered in detail in
various sections of this book, but some common ideas are introduced below.
In the illustration about the food plant, we saw that the Six Sigma process doesn’t just make
improvements for the sake of driving up sigma levels. A primary principle of the
methodology is a focus on the customer. In Chapter 5, we’ll look at the Voice of the
Customer (VoC) and ways for establishing what the customer really wants from a product or
process. By combining that knowledge with measurements, statistics, and process
improvement methods, organizations increase customer satisfaction, ultimately bolstering
profits, customer retention, and loyalty.
A detailed understanding of the customer and customer desires not only lets businesses
customize product offerings and services, but it also lets organizations:
 Offer additional features customers want and are willing to pay for
 Prioritize product development to meet current needs
 Develop new ideas based on customer feedback
 Understand changing trends in the market
 Identify areas of concern
 Prioritize work on challenges based on how customers perceive various problems or
issues
 Test solutions and ideas before investing time and money in them
Value Streams The value stream is the sequence of all items, events, and people required to
produce an end result. For example, the value stream for serving a hotdog with ketchup to
someone would include:
 A hotdog supplier
 A bun supplier
15
WHAT IS SIX SIGMA?
 A ketchup supplier
 Hotdogs
 Buns
 Ketchup
 A cooking procedure for the hotdog
 A pot
 Tongs
 Someone to do the cooking
 A plate
 Someone to put the hotdog into the bun
 Someone to put the ketchup on the hotdog
 Someone to put the completed hotdog onto a plate
 Someone to serve the hotdog to another
If you combine all of the above processes into a pictorial representation of exactly how
these elements become the served hotdog, then you have a value stream map.
The purpose for determining a value stream for a process is that you can identify areas of
concern, waste, and improvement. In the above process, are there four different people
putting the hotdog together and serving it, or is one person doing all four of those tasks? Is
the supplier a single grocery store, or are you shopping for items at various stores and why?
Do you get savings benefits to offset the added time spent working with multiple suppliers?
These are some examples of the questions you can reveal and answer during value stream
mapping.
Inherent in the Six Sigma method is continuous process improvement. An organization that
completely adopts a Six Sigma methodology never stops improving. It identifies and
prioritizes areas of opportunity on a continuous basis. Once one area is improved upon, the
organization moves on to improving another area. If a process is improved from 4 Sigma to
4.4 Sigma, the organization considers ways to move the sigma level up further. The goal is
to move ever closer to the “perfect” level of 99.99966 accuracy for all processes within an
organization while maintaining other goals and requirements, such as financial stability, as
quickly as possible.
16
One of the ways to continuously improve a process is to reduce the variation in the process.
Every process contains inherent variation: in a call center with 20 employees, variation will
exist in each phone call even if the calls are scripted. Inflection, accents, environmental
concerns, and caller moods are just some things that lead to variation in this circumstance.
By providing employees with a script or suggested comments for common scenarios, the
call center reduces variation to some degree.
Consider another example: A pizzeria. The employees are instructed to use certain amounts
of ingredients for each size of pizza. A small gets one cup of cheese; a large gets two cups.
The pizzeria owner notes a great deal of variation in how much cheese is on each pizza, and
he fears it will lead to inconsistent customer experiences. To reduce variation, he provides
employees with two measuring cups: a 1-cup container for small pizzas and a 2-cup
container for large pizzas.
The variation is reduced, but it is still present. Some employees pour cheese into the cups
and some scoop it. Some fill the cups just to the rim; others let the cheese create a mound
above the rim. The owner acts to reduce variation again: he trains all employees to fill the
cup over the rim and use a flat spatula to scrape excess cheese off. While variation will still
exist due to factors such as air pockets or how cheese settles in the cup, it is greatly
reduced, and customers experience more consistent pizzas.
Remember the hotdog example for value streams? We asked the question: do four different
people act to place the hotdog in the bun, put the ketchup on the hotdog, plate the hotdog,
and serve it? If so, does the process take more time because the product has to be
transferred between four people? Would it be faster to have one person perform all those
actions? If so, then we’ve identified some waste in the process—in this case, waste of
conveyance.
Removing waste—items, actions, or people that are unnecessary to the outcome of a

process—reduces processing time, opportunities for errors, and overall costs. While waste
is a major concern in the Six Sigma methodology, the concept of waste comes from a
methodology known as Lean Process Management..
17
WHAT IS SIX SIGMA?
Implementing improved processes is a temporary measure unless organizations equip their

employees working with processes to monitor and maintain improvements. In most
organizations, process improvement includes a two-pronged approach. First, a process
improvement team comprised of project management, methodology experts, and subject-
matter experts define, plan, and implement an improvement. That team then equips the
employees who work directly with the process daily to control and manage the process in
its improved state.
Often, Six Sigma improvements address processes that are out of control. Out of control
processes meet specific statistical requirements. The goal of improvement is to bring a
process back within a state of statistical control. Then, after improvements are
implemented, measurements, statistics, and other Six Sigma tools are used to ensure the
process remains in control. Part of any continuous improvement process is ensuring such
controls are put in place and that the employees who are hands-on with the process on a
regular basis know how to use the controls.
Six Sigma is not without its own challenges. As an expansive method that requires
commitment to continuous improvement, Six Sigma is often viewed as an expensive or
unnecessary process, especially for small or mid-sized organizations. Leadership at Ideal
Aerosmith, a manufacturing and engineering company in Minnesota, was skeptical of Six
Sigma ideas and the costs associated with implementing them. Despite reservations, the
company waded into Six Sigma implementations, eventually seeing worthwhile results after
only 18 months. Those results included a production improvement of 25 percent, a 5
percent improvement in profits within the first year, and a 30 percent improvement in
timely deliverables.4
Some obstacles and challenges that often stand in the way of positive results from Six Sigma
include lack of support, resources, or knowledge, poor execution of projects, inconsistent
access to valid statistical data, and concerns about using the methodology in new industries.
4
Gupta, Praveen and Schultz, Barb, “Six Sigma Success in Small Business,” Quality Digest.
http://www.qualitydigest.com/april05/articles/02_article.shtml
18
Six Sigma requires support and buy-in at all levels of an organization. Leaders and
executives must be willing to back initiatives with resources—financial and labor related.
Subject-matter experts must be open to sharing information about their processes with
project teams, and employees at all levels must embrace the idea of change and
improvement and participate in training. Common barriers to support include:
 Leaders that are unfamiliar with or don’t understand the Six Sigma process
 Leaders willing to pursue improvements initially but who lose interest in overseeing
and championing projects before they are completed
 Staff that is fearful of change, especially in an environment when change has
historically caused negative consequences for employees
 Employees who are resistant to change because they believe improvements might
make them obsolete, drastically change their jobs, or make their jobs harder
 Department heads or employees who constantly champion their own processes and
needs and are unwilling to enter into big-picture thinking
Lack of resources can be a challenge to Six Sigma initiatives, but they don’t have to be a
barrier. Lack of knowledge about how to use and implement Six Sigma is one of the first
issues small- and mid-sized companies face. Smaller businesses can’t always afford to hire
dedicated resources to handle continuous process improvement, but the availability of
resources and Six Sigma training makes it increasingly possible for organizations to use
some of the tools without an expert or to send in-house staff to be certified in Six Sigma.
Companies implementing Six Sigma for the first time, especially in a project environment,
often turn away from the entire methodology if the first project or improvement falls flat.
Proponents of Six Sigma within any organization really have to hit it out of the ballpark with
the first project if leadership and others are on the fence about the methodology. Teams
can help avoid poor project performance by taking extreme care to execute every phase of
the project correctly. By choosing low-risk, high-reward improvements, teams can also stack
the deck in their favor with first-time projects. The only disadvantage with such a tactic is
that it can be hard to duplicate the wow factor with subsequent improvements, making it
important to remember that long-term implementation and commitment is vital in Six
Sigma.
19
WHAT IS SIX SIGMA?
Data and analytics issues are a common challenge for organizations of all sizes. Gaining
access to consistent and accurate data streams—and applying statistical analysis to that
data in an appropriate manner—is difficult. Some data-related challenges include:
 Discovering that an important process metric is not being captured

 The use of manual data processes in many processes
 Automated data processes that capture enormous amounts and create scope
challenges
 Data that is skewed due to assumptions, human interaction in the process, or
incorrect capture
 Lengthy times between raw data capture and access
 Industry or company compliance rules that make it difficult to gain access to
necessary data
Six Sigma originated in the manufacturing industry and many of the concepts and tools of
the methodology are still taught in the context of a factory or industrial environment.
Because of this, organizations often discount the methods or believe they will be too
difficult to implement in other industries. In reality, Six Sigma can be customized to any
industry.
20
While the roots of Six Sigma are commonly attributed to companies such as Toyota and
Motorola, the methodology is actually grounded in concepts that date as far back as the
19th century. Before delving into the history of Six Sigma, it’s important to understand the
difference between traditional quality programs, such as Total Quality Management, and
continuous process improvement methods, such as Six Sigma.
Most modern quality and improvement programs can be traced back to the same roots.
Both quality programs and continuous process improvement methods look to achieve goals
such as reducing errors and defects, making processes more efficient, improving customer
satisfaction, and boosting profits. But quality programs are concerned with achieving a
specific goal. The program either runs forever, constantly working toward the same goal, or
it achieves the end goal and must be reset for a new goal.
Six Sigma seeks to instill a culture of continuous improvement and quality that optimizes
performance of an organization from the inside out. It’s the cultural element inherent in Six
Sigma that lets organizations enact both small and sweeping improvements that drastically
impact efficiencies and costs. Six Sigma does work toward individual goals with regard to
each project, but the projects are part of the overall culture of improvement that, in
practice, is never done. Six Sigma creates safeguards and tactics so that, even after a project
is considered complete, controls are in place to ensure progress continues and it is
impossible to revert to old ways.
Six Sigma applies statistics to define, measure, analyze, verify, and control processes. In fact,
Six Sigma teams usually use methodologies known as DMAIC or DMADV to accomplish
improvements and develop controls for processes. DMAIC stands for Define, Measure,
Analyze, Improve, and Control. These are the five phases of a Six Sigma project to improve a
process that already exists. When developing a new process, teams use DMADV, which
21
SIX SIGMA HISTORY AND APPLICATION
stands for Define, Measure, Analyze, Design, and Verify. Both methods are discussed in
Chapter 11, and Unit 3 provides in-depth information about each phase of DMAIC.
The roots of statistical process control, which provide a backbone for Six Sigma methods,
began with the development of the normal curve by Carl Friedrich Gauss in the 19th
century. We know today that the normal curve is just one of several possible probability
distribution models. It is perhaps the most widely used model, and the other models
developed from the normal curve. Probability distribution models are discussed in later
chapters on statistics
In the early part of the 20th century, statistical process control received another big boost
thanks to contributions from an engineer and scholar named Walter Shewhart. Shewhart's
contributions to quality are many, but two specific ideas stand out. First, Shewhart was the
first person to closely relate sigma level and quality. He defined a process in need of
correction as one that is performing at three sigma. If you look back to Chapter 1 and the
theoretical Amazon example, the cost difference between four sigma and three sigma is
over $78 million; in comparison, the difference between five and four sigma is only
approximately $7.6 million. Because errors and costs exponentially increase as sigma level
decreases, Shewhart’s definition has very practical applications in business. While Six Sigma
as a method seeks to move ever toward less than 3.4 defects per million opportunities
22
(dpmo), it is also true that if the quality of a process decreases, as it approaches three
sigma, the costs associated with errors increase substantially.
Second, Shewhart is considered the father of control charts. Control charts, which are
covered in depth in the chapters on advanced statistics, are a critical component of
statistical process control that lets organizations maintain improved performance after a Six
Sigma initiative. At a time when scholars were writing about the theoretical application of
statistics in a growing number of fields, Shewhart developed ways to apply these concepts
to manufacturing and industrial processes specifically.
During the same time period, W. Edwards Deming was working for the U.S. Department of
Agriculture. A physicist and mathematician, Deming was in charge of teaching courses at
the agency’s graduate school and he arranged for Shewhart to come and speak there. Later,
Deming brought Shewhart's statistical concepts to the United States Census Bureau,
applying his theories outside of an industrial or manufacturing environment for possibly the
first time.
One of Deming’s ideas is called the PDCA cycle, or plan-do-check-act cycle. The idea is that
improvement comes when you recognize there is a need for change and make a plan to
create improvement. Next, you do something by testing your ideas. Using the results of the
test, you check or verify that your improvements are working. Then you act, bringing your
improvements to a production environment or scaling improvements outside of the test
environment. The fact that PDCA is a cycle means it never ends; there are always
improvements to be made. This is a core tenet of Six Sigma.
23
Following World War II, Deming worked in Japan on behalf of the United States government
in several capacities. While in post-war Japan, Deming befriended statisticians and
convinced at least one notable engineer that statistical process control was relevant to
Japan's need to drastically drive economic and production performance to overcome
damage from the war. In the end, Deming became a valued teacher and consultant to
manufacturing companies in Japan, planting the ideas and concepts that would soon
become the Toyota Production System, or Lean Six Sigma.
What is Jidoka?
Jidoka is a principle that creates
control of defects inside a
Deming's teachings and the need for Japanese industry business process. Instead of
to make a successful comeback following a identifying defects at the end of
catastrophic war combined to bear fruit for Toyota. the production line and
Toyota’s leadership had visited the concepts of quality attempting to trace errors back
prior to WWII, but improved performance and to a source, jidoka demands that
efficiency became a more critical goal given the nature a process stop as soon as errors
of Japan's economy and resources in the 1940s and are detected so improvements
50s. Taking manufacturing ideas attributed to Henry or troubleshooting can happen
Ford, Toyota leaders applied statistics and new quality immediately.
concepts to create a system they felt would increase
For jidoka to work properly,
production and allow for variable products while
machines are often equipped to
reducing costs and ensuring quality.
recognize bad outputs from
Several individuals were instrumental in the ultimate good outputs; the machines are
development of the Toyota Production System. They also equipped with a notification
infused the process with automated machinery, quality of some type to spark human
controls to keep defects from occurring, and efficiency interaction in the process when
tools that had not yet been applied with such detail things go awry.
and consistency. One man, Kiichiro Toyoda, had
previous factory experience. In his previous jobs, he
24
added efficiencies to processes in textile mills through conveyor and other automated
systems. Toyoda introduced the same concepts on certain lines in the Toyota
manufacturing process. Later, Eiji Toyoda and Taiichi Ohno introduced concepts known as
Just-in-Time and jidoka, which are the pillars of the Toyota Production System.
The principles driving Toyota's system, and later, the foundation of Lean Process
Management or Lean Six Sigma, include:
 Defining customer values

 Identifying the value stream for customer needs and desires
 Identifying waste in the process
 Creation of a continuous process flow
 Continually working to reduce the number of steps and time it takes to reach
customer satisfaction
Lean management is highly concerned with removing waste from any process. Waste
increases costs and time spent on a process, making it undesirable in any form.
Though the basis for Six Sigma was laid in the late 19th and early 20th centuries, it wasn't
until the mid-1980s that these concepts saw large-scale success in the United States.
Decades after Toyota developed its system, engineers at Motorola began to question how
effective their quality management programs were. Those questions first arose after a
Japanese company took over a Motorola television manufacturing plant. By applying Lean
concepts, the new company began creating televisions that demonstrated 1/20th the
amount of defects as Motorola’s own television sets.
At the time, departments across Motorola measured defects as a ratio of a thousand

opportunities. Bob Galvin, the CEO of Motorola, issued a challenge to his team. He wanted
to see an improvement in quality and production—not just any improvement; he wanted a
ten-fold improvement in half a decade. Engineer Bill Smith and a new addition to the
Motorola team – Dr. Mikel Harry – began to work on the problem.
The team realized that measuring errors against a thousand opportunities didn't provide the
level of detail needed for true statistical process control. Instead, the engineers wanted to
measure defects against a million opportunities. We know that sigma levels were already
defined and the idea of using sigma levels as a measure of quality began with Shewhart. It
25
wasn't a long jump for the Motorola engineers to make from their desire for more accurate
data to the basic concepts of Six Sigma as both a goal and a methodology.
Throughout the next two decades, Motorola worked to perfect its Six Sigma methodology,
seeing positive results along the way. In addition to statistical tools, the team created a
step-by-step process by which any team--in almost any industry--could make gains and
improvements. For the first time, this type of statistical process control was taken out of the
manufacturing environment on a large scale company-wide. Motorola applied the method
to customer service, engineering, and technical support. It used the process to create a
collaborative environment between stakeholders inside and outside of the organization. It
was highly successful; according to Motorola, the company saved more than $16 billion as a
result of continuous process improvement initiatives within 12 years.5
Motorola did more than improve its own systems and products, though. Galvin directed his
team to share Six Sigma with the world. Motorola and its team published articles and books
on the Six Sigma method and implemented efforts to train others. In this way, they created
a methodology based on statistics that could be taught and implemented within any
organization or industry.
After leaving Motorola, Dr. Harry joined Asea Brown Boveri. At ABB, Harry worked with
Richard Schroeder, who would also become a champion for Six Sigma. In fact, the two men
later cofounded the Six Sigma Academy. At ABB, Harry came to realize a key idea in the
evolution of Six Sigma: business, or profits, in some ways came before quality. Quality, in
fact, was a driving factor of business. Customers didn’t make purchases if quality was poor.
Because the individuals with the ability to decide in favor of Six Sigma initiatives were highly
motivated by dollars, Harry incorporated financial tactics into the Six Sigma methodology.
For the first time, the method was focused on the bottom-line as a primary goal with other
concerns and goals stemming from financially-led goals.
In 1993, both Schroeder and Harry changed jobs, joining the team at Allied Signal. Allied
Signal’s CEO at the time was Larry Bossidy. He was interested in Six Sigma but realized that
executives and other high-level leaders experienced knowledge barriers while attempting to
interact and collaborate with analysts, process engineers, and Six Sigma experts. Bossidy
5
“The History of Six Sigma,” iSixSigma. http://www.isixsigma.com/new-to-six-
sigma/history/history-six-sigma/
26
suggested that leadership at a company had to be well-versed in Six Sigma to pick the right
projects for success and support those projects on a company-wide basis to ensure success.
Harry, who is sometimes referred to as the father of Six Sigma, created a system for
educating executive leaders. In conjunction with others at Allied Signal, he developed
systems that allowed Six Sigma to be effectively deployed by leadership throughout an
organization in its entirety.
Around the same time, GE CEO Jack Welch entered into the Six Sigma arena. Prior to
learning about Six Sigma, Welch had stated he was not a proponent of quality measures.
He’d previously criticized quality programs as heavy-handed approaches that did little to
deliver results. Welch invited Larry Bossidy to speak at a GE corporate meeting in 1995. He
also requested an analysis regarding the benefits of implementing Six Sigma at GE. At that
time, GE was performing at between three and four sigma. The potential savings should the
company rise to six sigma were enormous; estimates were $7 to $10 billion.6
Welch is known as a champion of Six Sigma not because he contributed in major ways to the
development of statistical process controls or the Six Sigma toolsets, but because he
demonstrated exactly how leaders should approach Six Sigma. He also made GE a
historically successful Six Sigma organization by tying Six Sigma goals to employee reward
structures. Employees were no longer only compensated based on financial performance
factors; they were also evaluated based on Six Sigma performance. Suddenly, employees at
every level had a personal reason to become involved in continuous process improvement,
and employees and managers were supplied with the Six Sigma training to succeed.
Following the success of corporations such as GE and Motorola, companies across the
country rushed to implement Six Sigma. Unfortunately, in the rush to implement the
process, many organizations executed improvements poorly or failed to gain an adequate
understanding of statistical process control before moving forward with improvements.
Although Six Sigma methods have been used by organizations to gain millions—even
billions—in savings and efficiencies, some companies walked away with a bad taste for the
process. That bad taste has resulted in the following misconceptions and myths that are still
prevalent today in many industries:
6
“The Evolution of Six Sigma,” PQA.net.
http://www.pqa.net/ProdServices/sixsigma/W06002009.html
27
 Six Sigma is solely concerned with metrics and ignores common sense. The opposite
is actually true: Six Sigma often starts with traditional common sense ideas, often
arrived at through brainstorming, and validates those assumptions with data. The
reason for this myth is twofold. First, managers and others who are used to making
calls without being questioned are suddenly questioned in a Six Sigma environment.
Not only are they questioned, but hard data sometimes proves them wrong.
Second, in some cases data is improperly used to support conclusions that are
against common sense or tradition. When those conclusions turn out to be faulty,
it’s easy to blame the process of Six Sigma there is a lack of adequate understanding
of the statistical theories involved.
 Six Sigma is too expensive. While enterprise-wide adoption of Six Sigma can be
costly at first, due in part to training needs, slowly integrating the concepts into a
company often costs very little in the long run. Organizations have to balance how
they adopt Six Sigma with budgetary concerns—but when implemented correctly,
Six Sigma generally leads to savings that more than cover its initial investment.
 Six Sigma can fix anything. Opposite the nay-sayers are Six Sigma cheerleaders who
believe they can apply the method like a salve to any problem. While Six Sigma can
be applied to any problem of process, it’s not always relevant to problems of
culture or people. If morale or other human resource problems are at the root of an
issue, statistics can’t help. However, if morale is low because a process is difficult to
work with or is performing poorly, Six Sigma can be used to improve the process,
thereby improving morale.
Six Sigma is applied via a controlled project selection and management process. Once areas
of concern are identified, leaders usually turn to analysts, Six Sigma experts, and subject-
matter-experts for cost-benefit analyses. Six Sigma teams attempt to quantify how broken a
process is (by calculating sigma level, costs of defects, downtime, and other metrics) and
how much it might cost to address the problem. Problems are then prioritized according to
severity as well as an organization’s ability to address the issue. Teams begin working
through the priority list, returning to the analysis from time to time to ensure the list has
not changed. The majority of this book covers the methods by which teams identify and
address problems using Six Sigma.
28
Possessing a Six Sigma certification proves that an individual has demonstrated practical
applications and knowledge of Six Sigma. Some organizations offer in-house certification
processes. Most people seek certification by enrolling in online or onsite Six Sigma training
course. Most organizations that offer Six Sigma education also offer a path to certification.
You can take courses for certification at various levels; Six Sigma levels are differentiated by
belt level.
A certified Six Sigma White belt is familiar with the basic tenets of the Six Sigma
methodology, though they aren’t often regular members of process improvement teams.
White belt training is a good introduction to Six Sigma for auxiliary staff members within an
organization and can provide the information necessary for understanding why project
teams do what they do. The training lets employees review project processes, understand
information presented in milestone meetings, and better participate in project selection
processes. White belt training can also be used across all levels of employees when
organizations are attempting to implement a Six Sigma culture. It is worth noting that White
Belt training usually only provides a very basic introduction and overview of Six Sigma, so
much so that not all Six Sigma professionals recognize it as a true Six Sigma certification.
A yellow belt certification is a step above white belt: it is still considered a basic introduction
to the concepts of Six Sigma, but a yellow belt learns basic information about the DMAIC
method often used to improve processes. The following concepts are often included in Six
Sigma yellow belt training:
 Six Sigma roles

 Team development and management
 Basic quality tools such as Pareto charts, run charts, scatter diagrams and
histograms
 Common Six Sigma metrics
 Data collection
 Measurement system analysis
 Root cause analysis
 An introduction to hypothesis testing
29
At the yellow belt level, training is often geared toward understanding of the overall
methodology and basic data collection. Yellow belts don’t need to know how to conduct
hypothesis testing, but they must understand the language of hypothesis testing and the
conclusions that are drawn from such tests. Yellow belts are often employees who need to
know about the overall process and why it is being implemented.
Certified green belts work within Six Sigma teams, usually under the supervision of a black
belt or master black belt. In some cases, green belts might lead or handle smaller projects
on their own. Green belts are generally equipped with intermediate statistical analysis
capabilities; they might address data and analysis concerns, help Black Belts apply Six Sigma
tools to a project, or teach others within an organization about the overall Six Sigma
methodology.
Green Belts can be middle managers, business analysts, project managers, and others who
have a reason to be involved regularly with process improvement initiatives but who might
not be a full-time Six Sigma expert within an organization. Sometimes, Green Belts are
considered the worker bees of the Six Sigma methodology because they undertake most of
the statistical data collection and analysis under the supervision of certified Black Belts.
The following concepts are often included in Green Belt training:
 All of the information listed for yellow belt certification

 Failure mode and effects analysis
 Project and team management
 Probability and the Central Limit Theorem
 Statistical distributions
 Descriptive statistics
 How to perform basic hypothesis testing
 Waste elimination and Kaizen
 Basic control charts
A certified Six Sigma Black Belt usually works as the project leader on process improvement
projects. They might also work within management, analyst, or planning roles throughout a
30
company. Common minimum requirements for black belt certification include everything
listed for yellow and green belts in addition to:
 Advanced project and team management skills

 Knowledge of the expansive list of Six Sigma brainstorming and project tools
 Intermediate to advanced statistics
 An understanding of other process improvement and quality programs, including
Lean and Total Quality Management
 An ability to design processes
 Advanced capabilities for diagraming processes, including flow charts and value
stream maps
 Use of software to conduct analysis, such as Excel or Minitab
A Master Black Belt is the highest certification level achievable for Six Sigma. Within a
business organization, Master Black Belts usually manage Black Belts and Green Belts,
consult on especially difficult project concerns, offer advice and education about
challenging statistical concepts, and train others in Six Sigma methodology.
Most certification programs require individuals to pass an exam for certification; some
require that green and black belt candidates also demonstrate their knowledge in the form
of Six Sigma project experience.
If an exam is required for white or yellow belt certification, it is usually fairly short and
covers basic concepts about the methodology. Green belt exams are longer and might
include questions about statistics and some basic calculations. Black belt exams often take
up to four hours to complete; they test for understanding and application. Exams might
include difficult statistical problems or questions about how a project leader might handle
various situations. While exams differ by organization, this book is designed based on The
Council for Six Sigma Certification’s (CSSC) published body-of-knowledge requirements.
Note: For those that are utilizing this textbook in preparation for one of the certification
exams administered directly by the Council for Six Sigma Certification
(www.sixsigmacouncil.org), the following material should be reviewed as follows in
preparation for the open-book examination(s):
White Belt Certification or Lean White Belt Certification: Chapter 1 thru Chapter 3
31
Yellow Belt Certification or Lean Yellow Belt Certification: Chapter 1 thru Chapter 11
Green Belt Certification or Lean Green Belt Certification: Chapter 1 thru Chapter 24
Black Belt Certification or Lean Black Belt Certification: Chapter 1 thru Chapter 33
Master Black Belt Certification or Lean Master Black Belt Certification: Chapter 1 thru
Chapter 33
32
By studying the history of Six Sigma, you’ve already realized that the methodology is closely
related to a number of other quality-driven initiatives developed over the past century. This
is true in part because all successful businesses ultimately seek to do the same thing: serve
a customer a product or service they need while making as much profit as possible.
While Six Sigma encompasses all the tools you need to approach virtually any problem of
process, familiarity with other types of process improvement and quality methods is
important. Some of these methods, such as Lean and JumpStart, add value within a Six
Sigma approach. Others might be used by outside resources alongside a Six Sigma project.
Even if you don’t use or work with some of these programs, you will need to communicate
with leadership and business partners who are more familiar with other methods. The
ability to frame Six Sigma concepts in a more global quality management approach can help
you win support for your own projects.
Lean principles often go hand-in-hand with Six Sigma principles. While Lean originally
developed as a concept for reducing waste in a manufacturing environment, the ideas of
Lean Process Management can be applied to any process that involves the movement or
creation of goods or services. This is true even if those services are virtual or digital, such as
in a computerized workflow process.
One of the ways that Lean is similar to Six Sigma is that it is concerned with continuous
improvements; like Six Sigma, Lean provides waste-removal tools so daily control and
improvements can be made to processes. In fact, one of Lean’s continuous improvement
tools is called Kaizen, a Japanese word that translates loosely to “change for the better.”
33
OTHER PROCESS IMPROVEMENT AND QUALITY METHODS
The purpose of every change in a Kaizen environment is to eliminate waste and/or create
more value for the customer on a continuous basis.
Lean Process Management can be deployed within a project environment or in daily

production. Like Six Sigma, Lean is more about an overall culture of quality than a single
quality event. Many organizations use Lean principles to make improvements in processes.
By simply instituting some of the Lean principles, managers can drastically increase
production and reduce costs for their departments.
Because Lean principles are so effective and fit so well with Six Sigma principles, for the
purpose of this book, we will often treat Lean as a part of the Six Sigma methodology.
Total Quality Management, or TQM, is a phrase well-known by anyone who worked in

business in the last quarter of the 20th century. The TQM approach to quality is one of the
first formal methods enacted in business environments in the United States. Originally
developed in the 1950s, Total Quality Management didn’t become popular with companies
across the country until the 80s. At one point, TQM was so popular with executives and
other leaders that it actually became something of a joke among certain workforces who
believed that much effort and expense was expended on quality without an equal resulting
benefit. In fact, if you remember from the last chapter, Jack Welch at GE felt this way.
While Total Quality Management programs were often somewhat lackluster when it came
to results, the method was an essential stepping point to current improvement and quality
methods such as Six Sigma. TQM was not without its results: as with any method, results
depended highly on the way the program was implemented and the culture of the
organization. For this reason, TQM and its variations are still in play in many industries
today. Some requirements for a successful TQM program include:
 A strict quality commitment at all levels of the organization, especially among

leaders
 Empowered employees who can make quality decisions while working within the
process without constantly seeking leadership approval for those decisions
 A reward and recognition structure to promote quality work so that employees
have a reason to make quality-making decisions
 Strategic planning that takes quality and quality improvement goals into account
when making long-term decisions
 Systems that let organizations make improvements and monitor quality
34
Successful TQM initiatives require eight key elements: ethics, integrity, trust, training,
teamwork, leadership, recognition, and communication. You can view these elements as if
they were part of the components needed to build a high-quality, lasting building. Ethics,
integrity, and trust become the foundation for quality. Training, teamwork, and leadership
are the bricks by which quality organizations are built. Honest, open, and concise
communication is the mortar that binds everything else together, and recognition is the
roof that covers everything, providing employees with a reason to seek and maintain
quality.
One of the biggest advantages of the TQM mentality is that it began to force organizations
to see themselves as one entity rather than a number of loosely related entities or
departments. Prior to the quality methods developed in the last half of the 20th century,
many organizations were run via heavily siloed departments. One department often did not
understand what another was doing, which caused a great deal of rework and waste. Each
department might seek higher quality levels or process improvements, but in the end, the
organization was only as strong as the weakest element.
TQM began to change departmental thinking on a massive scale: organizations began to

take enterprise approaches to decision making, quality, and customer service. Business
leaders started to look at companies as a series of linked processes operating toward a
single end goal. Within the bounds of TQM, the ideas for business process reengineering
began to develop.
Organizations using TQM often experienced benefits such as:
 Improved employee engagement and morale

 A reduction in production or product costs
 Decreased cycle times
 More satisfied customers
Six Sigma, Lean and TQM are all concerned with making continuous changes on both a large
and small scale that bring an organization ever closer to a model of perfection. In the case
of Lean, that model is a process that has zero waste; in Six Sigma, the model is statistically 6
sigma. In TQM, organizations often define their own version of perfection before working
toward it. Business Process Reengineering, or BPR, is less concerned with incremental
35
quality wins and more concerned with a radical change across an entire organization or
process architecture.
Business process reengineering, which is also called business process redesign, is most often
concerned with the technical processes that occur throughout an organization. Those
processes might include systems, software, data storage, cloud and web processes, and
computer-based workflows operated and maintained by human users. Because of the
intense integration of automation and computer elements into processes with BPR,
organizations that enter BPR endeavors have to rely heavily on both inside and outside
technical resources. Inside resources provide programming, integration, and
troubleshooting services as processes are developed or redesigned. Outside resources can
be BPR consultants, contracted programmers and developers, or vendors bringing new
software products to the table.
As you can probably imagine, BPR initiatives can be costly, which is why they are often
deployed only when an organization expects exponential gain or has determined that
current processes are obsolete or badly broken.
BPR projects tend to follow a common map, though there isn’t a defined set of principles as
there is with Six Sigma. Most projects go through planning, design, and implementation
phases. During planning, teams use process mapping and process architecture principles to
define enterprise-wide processes in their current state. Teams look for opportunities for
improvement and brainstorm new architectures for processes throughout the organization.
During the design phase, BPR teams use validation techniques 3 to ensure solutions they
are planning will work within the enterprise structure. They also begin to build tools and
programs to integrate the changes; technical teams might use the Scrum methods
described later in this chapter at this point in the process.
Finally, organizations implement the changes they have made. Since changes are often
programmatic in nature, implementation usually includes a rigorous change management
and testing procedure. Testing in technical environments includes steps such as:
 Sandbox testing of basic functionality

 Quality assurance testing by trained technical resources
 Beta testing during which experienced subject matter experts vet all aspects of a
program in a limited live environment
36
 A rollout of the program to the enterprise, often conducted in a phased approach

during which technical resources are on call to immediately resolve
troubleshooting issues
 A conversion to regular function where technical resources are available in a
normal capacity to deal with occasional issues
As process improvement methods became increasingly popular in the 1980s and later,
individuals often took portions of one method or another and integrated it into new
improvement or quality programs. In this manner, companies outside of the manufacturing
industry began implementing bits and pieces of methods that incorporated Lean and Six
Sigma elements. One such program is known as Rummler-Brache.
Rummler-Brache was pioneered in the 80s by Geary Rummler and Alan Brache. They
developed what remains a proprietary program used by their own consulting firm, but
details of the method have been published and used by others. The method seeks to affect
positive change in processes and organizations by using a set of practical tools to address
business issues and process problems.
One of the foundational components of Rummler-Brache is known as the Nine Boxes

Model. The model is created by a matrix of three performance levels and three
performance dimensions. Performance levels are the performer, the process, and the
organization. Dimensions are management, design, and goal. When placed on a grid, the
levels and dimensions form nine boxes, as seen below.
37
Management Design Goals
Performer Concerned with Concerned with Concerned with

feedback, the tools and performance
consequences, training needed metrics and
and rewards to do the job as requirements at
well as job an individual
documentation level
Process Concerned with Concerned with Concerned with

who owns the the design of the the
process and how process, work requirements of
they might space, or system the business and
improve it the customer
Organization Concerned with Concerned with Concerned with

overall leadership overall org charts operating plans
culture and the and process and top-level
requirements of architecture metrics
performance
evaluation
Rummler-Brache approaches improvement in six phases:
 Improvement planning. During the first phase, leadership and subject-matter-

experts commit to making improvements and begin to identify opportunities for
change.
 Definition. During the second phase, project goals and scopes are defined and
teams are formed to create improvements.
 Analysis and Design. Teams use analysis to understand the current problem and to
define and validate workable solutions.
 Implementation. Teams implement process changes. Depending on the type of
change, this might include programming changes, retraining staff, changes in
machinery or equipment, or policy changes.
 Management of process. Teams monitor the process during and immediately
following the change to ensure improvements function as planned.
38
 Processes are turned over to daily teams. Management of the process is turned
over to daily teams, often with some type of control in place to ensure continued
success.
Scrum is a project development method specific to Agile programming endeavors in

technical departments. Scrum is used when teams want to create new technical products or
integrate new developments on existing products within a short time frame. Commonly,
Scrum projects last between two and four weeks, which is traditionally a very tight timeline
for programming projects. Scrum was developed as programming and development teams
needed a way to meet continuous technical design and improvement needs from other
departments without substantially increasing programming, testing employee hours, or
hiring more technical staff. Scrum can also be used to drive faster times to production or
market for software and application products.
Scrum is a related concept to other process improvement initiatives discussed in the book
because many projects today call for some type of technical resource or change. While
project teams are working to validate and measure, technical departments often
simultaneously deploy Scrum concepts to meet development needs for the improvement
project by deadline.
Scrum projects feature three main phases:
 The pregame. Development teams analyze available data and business

requirements. They use this information to come up with the concept for the new
product or upgrade. Often, this involves translating business and process concepts
into computer and technical concepts.
 The game. Teams begin to develop the product via programming sprints. Sprints are
smaller phases of development that are completed in sequence, usually with a
review and validation of the work before moving on to the next sprint. By validating
work during development, teams are able to create working products faster.
 The postgame. Even though validation occurs during development, teams still have
to follow quality assurance, testing, and change management procedures. Quality
preparation for product release is handled in the final phase.
39
Like Rummler-Brache, the Customer Experience Management Method, or CEM Method,

was created by process improvement consultants to address needs in organizations outside
of manufacturing. CEM combines some process improvement tools with customer relations
management. It was developed in the 1990s by the Virgin Group and became popular
throughout the 90s and early part of the 21st century.
The CEM Method takes an outside-in approach to process improvement, focusing on what
the customer wants or needs and how each process in an organization serves that need.
The primary purpose of CEM is to align processes throughout an organization with customer
satisfaction goals. As such, even processes without a direct relation to customers are
defined in terms of customers.
For example, shipping processes are obviously directly related to end customers, so it’s easy
to define how those processes can best serve customers. Shipments should arrive on time,
be accurate to orders, and shipping costs should be affordable.
In-house human resource processes are harder to link to customer-facing goals. However,
the morale and functionality of employees is directly related to how those employees can
serve customers. You can make a customer-facing statement about almost any process in
an organization in this manner. If organizations cannot link a process to the customer, then
they must ask whether the process is necessary or broken.
Like Six Sigma, CEM relies heavily on data. Organizations can’t make determinations about
customer goals and the success of processes without collecting and analyzing customer
feedback. The advantage of CEM is that organizations are able to deploy customer-facing
tactics across the enterprise, which often results in enormous gains in customer
satisfaction, loyalty, and spending. A disadvantage of this method is that traditionally
inward-facing departments, such as human resources, legal, and accounting, often have a
difficult time implementing customer-focused cultural change.
JumpStart differs from the other programs and methods described in this chapter in that it
is a fast-paced method for identifying problems and solutions in a single session. JumpStart
can be used within almost all of the other methods described in this book as a way to spark
discussion regarding processes or to identify possible solutions. It can also be used as a
management tool for helping teams come to tenable solutions outside of project
environments or in the absence of project resources.
40
Because JumpStart doesn’t take the time for rigorous verification or statistical analysis on its
own, teams should not use this method to enact sweeping changes or attempt to improve
processes that could seriously impact customer experience or the bottom line. One
disadvantage of using JumpStart alone is that changes are sometimes made on a wait-and-
see mentality, which is safe for many inner-team changes but often dangerous for
department or enterprise-wide processes, or for making changes to processes that are
closely tied to regulatory or compliance rules.
JumpStart usually begins when leaders at some level identify an area of concern or
opportunity. The manager, supervisor, or other delegate identifies a team of employees
who they believe would offer appropriate insight on the issue at hand. In most cases,
JumpStart doesn’t work to define the problem: the group is close enough to the issue that
they already know what is wrong. Instead, the group spends several hours brainstorming
root causes for the problem and coming up with possible solutions.
Six Sigma and other process improvement tools can be deployed during JumpStart sessions.
Fishbone diagrams and solutions selections matrixes, both covered in later chapters, can be
used to validate assumptions using only the knowledge of the people in the room and some
quick research.
The benefit of JumpStart is that it lets teams create and implement small-scale solutions
quickly, often providing problem resolution the same day. It also lets teams identify issues
that need to be addressed in a more comprehensive project environment.
Some organizations make use of various project improvement methods. As a Six Sigma
expert, you might have to champion your own method on occasion. Here are some reasons
to choose Six Sigma over other methods described in this chapter.
Six Sigma is designed so you can begin a project even when you don’t know the cause of the
problem. In some cases, teams aren’t even sure what the exact problem is – they only know
some metric is not performing as desired. For example, an organization might experience a
drop in profits that doesn’t correct itself in several consecutive quarters. Six Sigma methods
can begin to seek the causes of the problem, prioritize them, and work toward solutions.
41
Even when a problem is understood, if it is wide in scope and not well defined,
improvement projects that are not tightly managed can escalate in scope to a point that
they become unmanageable. In this situation, teams attempt to solve increasingly bigger
issues. As a result, no problem is ever completely solved. Six Sigma includes controls for
avoiding such scope creep so teams can make incremental improvements that steadily
improve a process over time. We’ll talk about scope creep more in later chapters.
If processes are complex and feature many variables, it is difficult to determine how to
approach a solution, much less define and measure success. Knowledge of statistical
analysis and process control lets teams approach problems that involve enormous amounts
of data and many variables. Through analysis and graphical representation, complex ideas
can be distilled to specific hypotheses, premises, and conclusions.
Because Six Sigma’s statistical process control component lets teams make more accurate
assumptions than almost any other method, it is very appropriate for situations that are
closely tied to revenue or cost. When a single tiny change can result in millions of dollars in
gains or losses, teams must validate assumptions with an extremely small margin of error.
Guesswork, basic research, and even years of experience cannot do that as accurately as
properly implemented Six Sigma methods.
42
We’ve discussed Lean concepts in the previous three chapters because most Six Sigma
approaches today incorporate Lean concepts into problem solving and the control of a
process. In fact, organizations often use the term Lean Six Sigma when describing a process
improvement approach that incorporates tenants from both Six Sigma and Lean
methodologies. This is a popular approach because the greatest results usually come when
you improve a process so that both defects and waste are eliminated. That statement rings
true whether you’re measuring from a business-driven bottom-line or a customer-
satisfaction approach.
A Six Sigma defect is a failure to meet a requirement in a process. We’ll talk more about
requirements in Chapter 8 when we define quality. For now, know that defects cost money
because businesses have to replace parts, equipment, or products that are not perfect.
Organizations also experience financial loss associated with defects when quality reputation
is so low that customers choose not to return or purchase from the company. From a
customer satisfaction standpoint, defects can increase the time it takes for a customer to
get what they want or can cause the customer to be unhappy with the end product or
service.
Waste costs money because it is unnecessary time, labor, or material in the process.
Generally, waste is something that is used in the process that isn’t required for a
satisfactory outcome. In some cases, waste creates a customer satisfaction issue because it
holds up the process or introduces undesirable elements or defects in the end product.
In this chapter, we’ll look at some specific types of waste and how to avoid them as well as
touch on some Lean concepts for creating the most efficient processes.
Muda is a Japanese word that translates to waste. It describes a concept of being useless,
unnecessary, or idle. The concept that muda must be eliminated in a process is a driving
concept of the Toyota Production System and Lean manufacturing. Muda is a non-value-
added task (NVA) within a process. Some types of muda are easier to identify than others,
which is why Lean Six Sigma deploys tools such as value stream mapping. By understanding
43
LEAN CONCEPTS
a process at all levels, teams are more likely to identify various forms of muda. According to
Taiicho Ohno, chief engineer for Toyota, there are seven muda, or resources that are
commonly misused and mismanaged: overproduction, correction, inventory, motion,
conveyance, over processing, and waiting.
Overproduction is one of the easiest forms of muda to spot, as it tends to result in what we
commonly think of as waste. Overproduction means a product, part, or service was
produced too fast, at the wrong time, or in too much quantity for the process. To
understand the idea of overproduction, consider a basic fast food restaurant that offers
hamburgers and French fries for lunch. The restaurant does not serve breakfast, and it
opens its doors at 11:00 a.m. for the lunch crowd.
If the cooks light up the grill at 11:00 a.m., then they might start the day behind, as it is
possible that several orders will be placed immediately. However, if the cooks start making
hamburger patties at 10:30 a.m., they might have patties that sit for some time before
being consumed, which leads to customer dissatisfaction or waste if the patties are thrown
out. Making 10 patties every 10 minutes starting at 10:30 a.m. is overproduction—the
patties are being made too soon.
What if the restaurant owners have done some research and they know the average
number of orders between 11:00 and 11:15 a.m. on a Tuesday is 10 hamburgers? They
might instruct the cooks to begin making patties at 10:50 a.m. and to make 5 patties every
10 minutes. The goal is to align patty-making with customer orders so that wait times are
reduced but customers are still able to enjoy fresh patties.
By noon, the owners know orders tend to come in quickly, so they ask the cooks to make 15
patties every 10 minutes. By 2:00 p.m., however, the order traffic usually drops to 10
hamburgers an hour. If the cooks are still making 15 every 10 minutes, then the process
suffers from overproduction.
At some point, the traffic in the restaurant may call for made-to-order grilling—a process
where the cook only makes hamburger patties as they are ordered to avoid wasting any
materials. By understanding the traffic trends in their restaurant, the owners are able to
estimate needs and create processes that reduce the amount of waste made in the kitchen
while still meeting the quality demands of customers.
Overproduction is most often associated with tangible outcomes from a process, though
these outcomes don’t have to be final, or “end products” of said processes. Consider a
44
business that prints business cards, stationary, invitations, and other documents. Perhaps
this business offers a printing and mailing service; to complete this service, the company
uses a machine-driven process that prints, folds, and stuffs mailings. The printer is capable
of delivering 1,000 pages an hour, but the folding machine is only able to fold 800 pages an
hour.
Even if a customer wants 1,000 pages printed and mailed, the printer is overproducing if the
first machine is set to operate at maximum speed. The process will take longer than one
hour because it is contingent upon the slowest machine. Since the overproduction doesn’t
result in tangible waste – the printed pages will eventually be folded and mailed – the
company’s process owners have to consider other factors in order to decide if the
temporary overproduction is detrimental to the process. Does the stacking of extra paper
before the folding process create an extra risk for error? Does operating the printing
machine at maximum capacity without necessity put unnecessary strain or wear and tear on
it? If the answer is yes to either question, then there exists waste that should be eliminated
from the process.
Overproduction can also exist with regard to reporting, digital assets, and preparation for
processes. Almost anyone working in a business environment is familiar with reporting
requirements—just as almost anyone who has created reports knows the unfortunate truth
that the information often goes unread. Creating reports no one reads—or creating highly
detailed reports when an overview would suffice—is overproduction.
Preparing equipment that isn’t used in a process is also overproduction. Surgery centers
often prepare machines, equipment trays, and operating rooms before shifts begin. The
goal is to create efficient processes for any patient operation; staff must also be able to
access equipment quickly if issues arise during procedures. Preparing 20 trays of equipment
on a day when only 10 surgeries are scheduled might be considered overproduction if there
is no use for the extra trays.
In some situations, such as the medical example above, processes might call for slight
overproduction. If 10 surgeries are scheduled, staff might prepare 13 or 14 equipment
trays. This way, if an emergency surgery arrives, or if an issue comes up with an existing
tray, stand-by equipment is available. By understanding nuances within processes and
requirements, Six Sigma teams can better identify muda of overproduction versus
overproduction that might be required by regulation or problem-solving policies.
The key to eliminating overproduction is planning. In the examples above, you’ll note that
each solution came when the process operator understood the needs inherent within the
45
LEAN CONCEPTS
process. When the owners knew how many orders were likely, they were able to plan to
reduce waste. When the printer knows the capability of each machine in the process, he or
she can plan for the most efficient printing run.
Also known as muda of rework, this form of waste often plagues organizations that are keen
on traditional quality programs. In a desire to eliminate defects from the end product,
organizations institute in-process quality checks that route work with defects back for
correction. While rework might be necessary in some cases, especially if materials are
particularly valuable and work is worth saving rather than scrapping, it is still waste in the
process that should be identified and analyzed.
When rework occurs, it increases overall process time and uses additional labor and
materials to create a smaller amount of products or outputs. Let’s look at an example that
might be found in the call center for a large automobile insurance company. Some of the
calls coming into the center are from individuals who have sustained damage to vehicles in
an accident. Consider the following process for handling such calls:
 The caller reports damage to the car.

 The representative records information in a computer form.
 The representative makes a decision based on the information provided by the
caller:
o The claim is routed for immediate handling if it is deemed an emergency
o The claim is routed to team A if it is a single-car or act-of-God incident
o The claim is routed to team B if it is a multi-car accident
Now, imagine a claim that arrives in the work queue for an employee working on team B.
The information entered into the computer is incomplete, so the employee cannot
determine for sure if the claim is related to a multi-car accident. The employee might send
the claim back to the original queue, which means a call-center employee would have to call
the insured back to gather additional information. The claim would then be routed again,
according to the new information, and would wait in a work queue again.
One of the biggest problems with muda of correction is that a case can often be made that
the processing is necessary. Perhaps team B is not equipped to deal with single-car
incidents, so the work has to be rerouted if the claim is to be completed. But why not equip
down-line team members to handle any claim, or create a process for rerouting claims to
the correct team without sending the work back to the original queue?
46
Correction, or rework, can occur in any type of process. Manufacturing processes cull out
defective parts and products; sometimes materials are reworked for a better outcome and
sometimes they are scrapped—also a form of waste. Call centers and digital work queues
are famous for rework, as it’s easy to send work back and forth in a digital format. In some
cases, rework occurs not because of correction, but simply because departmental or worker
responsibilities overlap.
To eliminate rework or correction, organizations must use a twofold approach. First, the
root cause of the rework—that which is causing the errors—must be addressed. Is further
employee training required? Could a process be changed to make it more mistake proof? In
some cases, the principles discussed in later units on process control, including a strategy
called a poka yoke, can be deployed to make it more difficult to create defects than to not
create defects during a process. When defects are avoided, rework is also avoided.
In addition to addressing the root cause of errors, organizations should create quality steps
that reduce rework waste. In the example about the insurance company call center, we
noted that it would be more efficient for the down-line worker to reroute the claim to the
correct team than to return it to the original team. This method sometimes causes a
problem of culture, though; there is a feeling among leaders and staff that the first team or
first team member should be held accountable for the error. One way of seeking
accountability is to have that person correct his or her mistake. While reworking errors can
be a good training method when time and resources allow, it isn’t always feasible and
doesn’t make for an efficient daily process. Instead, employees might be more efficiently
held accountable through goal-setting and metrics for the greater good of the organization
as a whole.
Muda of inventory is similar to muda of overproduction; in fact, overproduction can cause a

waste of inventory. Muda of inventory occurs when materials or inputs stack up before a
step in the process; this phenomenon is also called a bottleneck. Remember the printing
example for overproduction? If the first machine is set to the highest production level, it will
generate 1,000 pages an hour. The folding machine can only handle 800 pages an hour, so
you would have an inventory of 200 pages created every hour. If both machines ran at
highest production for four hours, the process would have developed an inventory of 800
pages. Until and unless the folding process becomes faster, then those extra pages are
wasted inventory and will continue to pile up.
47
LEAN CONCEPTS
Inventory waste can occur when items are purchased or created before they are needed in
a manufacturing or service process. Inventory can also occur in work queues, digital data
queues, or even email inboxes. If you receive 300 emails a day and you are only handling 30
of them on a regular basis, you have a process problem with your communications.
While inventory waste can occur in any process, it is especially common in processes that
operate in batches. Traditional lean wisdom says to avoid batch process – processes that
involve creating a certain number of products or outputs before pushing them down the
line. Reducing batch size lowers lead times—the time it takes to deliver the end product. It
also reduces the amount of inventory that occurs before each step of the process.
While Lean mindsets usually push a batching-is-bad mentality, you can’t always avoid it—
and reduced lead times on individual outputs aren’t always a primary goal of a process.
Consider a baker who is preparing an order of one dozen cupcakes. He could prepare the
order as a batch, or he could prepare each cupcake separately. Obviously, mixing the
ingredients and baking the cupcakes as a batch makes more sense. Decorating them as a
batch also works well—the baker might frost all of the cupcakes, add piping to all the
cupcakes, and then top all the cupcakes with a candy. Batching works for the baker because
the first cupcake is not going to leave the bakery before the 12th is finished—they all move
together because they are considered a unit.
You can also reduce waste of inventory by understanding a process and basing inventory
decisions on historic metrics. A shipping center that processes between 50,000 and 100,000
boxes a week wouldn’t place an order for 300,000 boxes if they only wanted to have a
week’s supply on hand. A baker doesn’t whip cream for seven pies if he or she only intends
to make two.
Muda of motion has to do with how employees themselves move during a process. This
type of waste is often relevant to people-powered processes in manufacturing,
warehousing, shipping, delivery, or industrial fields, but waste of motion can even crop up
in processes that are computerized.
For example, if a data-entry employee has to click back and forth between screens when
entering information, this could be muda of motion. If the system is designed so that a
number is to be entered in one window and a second number entered in a different
window, the click between windows is wasting motion. Moving to another window involves
a mouse or keyboard action that could be eliminated if the data were entered on the same
window. It seems like an inconsequential detail, but imagine what happens when the data
48
employee completes this process hundreds or thousands of times a day. The waste can
absolutely add up:
 If each data-entry employee completes 600 entries an hour on average, and there
are 10 employees on a team, the team is completing 48,000 entries each day.
 If it takes only half a second more to toggle between the two windows, the team is
still spending a collective 400 minutes a day – just over 6.5 hours – toggling.
 If the average hourly wage for a data worker is $10, the team is spending an extra
$325 each week – almost $17,000 each year – to cover the act of toggling between
windows.
Given those numbers, a programing change that includes both data elements on the same
window could save the company $17,000 in a single year. This same concept can be applied
to any form of muda when you can apply a time and dollar figure to the waste.
Other examples of muda of motion include a task that requires an individual to physically
move back and forth between work, extra motion that stems from a poor layout of work, or
movement that occurs when an employee leaves an area and has to return one or more
times because he or she forgot something. Public libraries have long employed a simple tool
to avoid muda of motion in the reshelving process: books are first ordered on a cart. The
cart allows an employee to carry many books without moving back and forth, and placing
the books in order on the cart lets the individual move through the stacks once. If books are
placed at random on the cart, the subsequent movement between shelves wastes motion
and time.
Streamlining company processes eliminates muda of motion, and data must be collected
and analyzed to identify unnecessary movement. A common tool used in manufacturing
and similar environments to track movement is known as a spaghetti diagram. Begin with a
basic, bird’s eye drawing of the workspace. Include furniture, computer stations, machinery,
doors, and walls. Observe an actual process, tracking any and all movements with a line on
the diagram.
When drawn correctly, the diagram looks like a string of spaghetti fell onto your page. Once
the process is complete, you can look at the diagram to see where the movements cross
paths multiple times or go out of the way unnecessarily. This helps you find opportunities
for streamlining the movement in a process—sometimes, it’s as simple as moving furniture
or resources around to reduce unnecessary movement. It’s worth noting that a spaghetti
diagram only reveals a snapshot of movement in time; sometimes, it is worthwhile to
49
LEAN CONCEPTS
complete more than one such diagram at different times of day or with different employees
to reveal an overall picture of a process and possible muda.
Muda of conveyance is similar to muda of movement except conveyance involves the

movement of outputs, products, or resources. It is sometimes also referred to as muda of
transportation. For example, in a doll-making facility, if the glue that binds doll eyes to doll
faces is kept in an inventory room and carried, as needed, to the process, there might be
muda of conveyance.
If an expense report is printed and then carried to a manager for approval who then routes
it in an inner-office envelope to a director, who then carries it to the accounting
department, the muda of conveyance is occurring. This is especially true because
appropriate technology used correctly and efficiently lets organizations handle expensive
reporting via computer with little conveyance at all.
If a plate is prepared by a chef and placed on a counter where a kitchen assistant moves the
plate to a different table where wait staff know to pick it up, conveyance is occurring. The
wait staff then carries the plate to the customer.
Conveyance can relate to physical movement of items or digital movement of data or

workflow. Email strings, which are present in many work environments, often present muda
of digital conveyance. A CEO might email a director with a request for data. The director
emails a manager, who emails a supervisor, who emails a subject-matter-expert. The SME
delivers the information to her supervisor, and the emails work their way back up the chain.
The same request and information was conveyed multiple times when it only may have
needed to be conveyed once. This allows for many opportunities for error.
Some might point to chain-of-command concerns, but for the purpose of this example, if
the data request is a repeated process, then it makes sense for the chain of command to
inform the CEO where this information comes from. To go even further, a truly Lean process
would require all waste be removed from this process. If the data requirement comes on a
weekly basis, then Lean ideals require that the SME automatically generate the data and
send it to the CEO weekly.
Physical conveyance is often easier to locate and address than digital conveyance. A
spaghetti diagram, process map, or value stream map can help you identify areas where
muda of conveyance might exist. Spaghetti diagrams work well in physical conveyance
situations, and process maps help you identify conveyance in digital settings.
50
Once you identify muda of conveyance, you can eliminate it by making changes in the
process, layout, or inventory requirements for the work. If conveyance waste isn’t due to
poor process design or work-area layout, it might be related to another form of muda.
Conveyance is often seen in processes that involve a lot of correction, because work is
transferred back and forth between staff or areas. By addressing the muda of correction,
you often also address the muda of conveyance.
Over-processing occurs when an employee or process inputs more resources into a product
or service than is valued by the customer. This could occur because of ignorance, a desire
for perfection, or even excitement. Sometimes over-processing occurs because an
employee hasn’t had training on the most efficient way to handle a task. Other times, it
occurs because an employee or process is more thorough than is worthwhile. A goal of any
process should be to do just enough useful and necessary work to ensure that customer or
end-user expectations are met.
One example of over-processing often occurs in healthcare administrative offices during the
insurance verification process. Insurance verification occurs when a healthcare provider’s
office attempts to verify that a person is covered by insurance for the services that are
about to be rendered. Depending on the type of insurance coverage and the office’s
policies, a staff member either checks benefits via a computer program or calls the
insurance company.
In most cases, the goal of insurance verification is simply to ensure that the insured is
covered by the plan for the date the services are to be rendered. Sometimes, however, an
office worker delves deeper into the verification, spending up to an hour on the phone with
an insurance company to receive detailed benefits or calling back to check with another
representative to ensure the original information provided was correct. While specific cases
exist that require in-depth insurance verification, basic doctor’s visits don’t require this level
of work. A staff member who is taking up to an hour to verify insurance coverage is
overproducing, and it’s probably causing productivity problems for the office as a whole.
In consumer-centric processes, over-processing occurs when you put more into a product
than the value afforded by the customer. While product excellence is important, at some
point the work you put into a product exceeds that which is deemed necessary or useful by
the customer, and this is often tied to price point. A customer expects more out of a
premium, more expensive model, for example.
51
LEAN CONCEPTS
An example of over-processing might be painting the bottom of an inside cabinet shelf

when no one will ever see it. In a restaurant, ironing table linens to an exacting standard
could be considered over-processing, especially if you remove the linens between meals for
washing. In most restaurants, much of the table linen drapes over the table; owners might
want linens that aren’t full of wrinkles, but they don’t need crisp and perfect seams. In the
technical world, building an app with 100 features when 99 percent of people only want to
use 10 main functions can be considered both over-processing and over-producing.
A value stream map, covered in Chapter 35, is a good tool for identifying any points of over-
processing. Any part of the process that doesn’t provide value could be considered over-
processing; when the process features a series of linked events and none provide value, it’s
even more likely that over-processing is occurring.
In a true Lean process, every step of a process provides value, but it can be tricky to
determine when value is not occurring. Quality is important to both the success of the
process and the end customer, for example, but the customer doesn’t care, or usually even
realize, that your process is imbued with quality checks throughout. They care instead that a
process takes 10 minutes longer because of those quality checks—teams have to dig deep
into processes, metrics, and customer voice to determine if those 10 extra minutes are
providing enough added value to cover the annoyance or loss of customer because of the
added time. This knowledge is all ascertained through data collection and statistical analysis
discussed in detail throughout this book.
Muda of waiting refers to any idle time in a process, whether that idle time is for machinery
or people. In other words, an employee or machine is working below capacity or is not
working at all due to waiting on inputs from another part of the process. Waiting occurs
when steps in the process are not properly coordinated, when processes are unreliable,
when work is batched too large, during rework, and during long changeovers between staff
or machines.
In a retail or fast food environment, when one cashier’s shift is over, another cashier takes
over at the station. To maintain financial integrity, almost all companies switch out cash
register drawers during the change between cashiers; if there is a mistake with the drawer,
the company knows who was running the register at that point in time, making it easier to
find trends or issues. However, when the drawer is being changed out, the register usually
can’t be used. The cashier is simply waiting, sometimes along with the customer.
52
To reduce the muda of waiting in this cash register example, most organizations use a
process that includes a series of register drawers that are prepped at the beginning of the
day or shift. The drawers are designed to be interchangeable in the registers, so the old
drawer can be pulled and the new drawer put in in less than 30 seconds, solving the waste
of waiting.
Waste of waiting is common in construction environments. Construction of roads, bridges,

buildings and other structures requires close attention to order and detail: you can’t build
the roadway of a bridge until the pillars are in place and steady. This concept is seen even
on a small scale in construction, causing paid employees to often stand around waiting for
others to complete a piece of the job before they can finish the assigned task.
Because construction is a field of specialists and certifications, one employee often cannot
do the work another can. In other words, employee tasks are not interchangeable. This
causes additional muda of waiting; one group of construction workers might have to wait
on the forklift operator to come and move some items. Meanwhile, the forklift operator is
finishing up with a task on the other side of the construction lot. This isn’t a problem limited
to construction: some offices have policies requiring an official IT staff member to handle
any computer issue. Whether it’s a software glitch, a troubleshooting error, or simply the
need to switch out an underperforming mouse, regular office staff must send a support
ticket or make a phone call and wait for IT staff to solve the problem.
You can eliminate waste of waiting within many processes by balancing machinery, people,
and production. The process will only perform as fast as the slowest link; beefing up the
production of a single element does nothing for the whole, so teams must work to balance
and improve the entire process.
Sometimes, scheduling is a key component in eliminating waiting. In the construction

example, advanced planning and scheduling tactics could reduce the chance that one team
would be waiting for a forklift operator while he or she is busy elsewhere. Understanding
organizational, team, project, and process needs also helps leadership provide the right
amount of resources to reduce waiting. The construction site might benefit from two forklift
operators, for example. In the IT example, a company can reduce wait times by maximizing
IT staffing at high-volume times or implementing processes within the IT department to
create more efficient responses to help tickets. An auxiliary IT staff member can be hired to
handle less technical issues such as switching out an under-performing mouse.
53
LEAN CONCEPTS
While Toyota originally defined seven common muda, even Taiichi Ohno agreed that other
types of waste exist. In some cases, what seems like other types of waste are just more
defined or specific types of the seven muda discussed above. Some forms of waste don’t
seem to fit neatly into one of the seven muda categories.
Talent can be wasted when a process doesn’t make the most use of the labor or staff
available. If a process calls for data to be entered, and the staff member slowest on 10-key
is assigned to the task, resources are being wasted. Hiring the wrong person, putting staff in
the wrong position, or ignoring a staff member’s growth potential could all be instances of
muda of talent. Wasted talent is more a concern for leadership and human resources than
for process improvement specialists, though Six Sigma experts should be aware that the
way personnel resources are handled can drastically impact the efficiency of a process.
Muda of ideas occurs when the thoughts and ideas of people are discounted, not sought
out, or misappropriated in a way that doesn’t make sense. Leadership and project teams
can often overlook subject matter experts who have detailed insight into a process and, as
such, could offer first-hand knowledge and ideas. The result could be the design of a
process that works great in theory but falls flat on a granular level once it’s instituted.
One reason waste of ideas is such a concern for organizations is that people themselves
rarely come forward with thoughts. Staff members might think they don’t have anything
real to contribute, might feel like their ideas won’t be heard, or could be anxious about
looking silly or ignorant.
Six Sigma Green or Black Belts in charge of projects can facilitate less muda of ideas by
encouraging subject matter experts to contribute and encouraging leaders to seek all ideas
before moving forward with change. Brainstorming tools, which are covered in later
chapters, are valuable for this purpose because they are designed to create a safe haven for
all ideas. By fostering all ideas in a safe environment, teams can foster valuable ideas and
avoid waste of ideas.
54
Saving for a rainy day is smart, but banking cash when there are profits to gain isn’t always
the right decision. Muda of capital or cash occurs when leadership decides not to invest in
upgrades or improvements that would create additional cash flow. This type of waste is very
similar to waiting, except the cash itself is waiting, often for a time when leadership feels
safe enough to spend it.
Six Sigma helps reduce muda of cash because statistical analysis helps point leaders to
decisions that involve the least risk or most gain. No business decision is 100 percent
guaranteed, but Six Sigma helps leaders hedge bets by using statistical data in the decision-
making process so they don’t sit on cash or capital that could be used to drive gains in
efficiency, production, and profit.
All muda is waste that fails to add value to a product or process as defined by the customer
or end-user. All muda can also be divided into two overall types, which can help
organizations prioritize waste for project and improvement purposes. Muda can be referred
to as type I or type II.
Type I muda are non-value-added tasks that might actually be essential or required by
circumstances. Inspection of products during a process might be required if the process is
known to produce defects. Organizations don’t want defects to reach customers, so they
put quality controls in place. The act of the inspection, and the time and expense it adds to
a process -- are all muda. However, an organization can’t remove that waste until it
addresses the cause of the defects within the process.
Sometimes, auxiliary processes within an organization are Type I muda. For example, the
external end customer doesn’t receive direct value from human resource processes within
an organization. At the same time, if employees don’t receive pay checks or support
regarding benefits, they aren’t likely to continue performing work. Those processes are then
essential to the organization. Instead of removing the muda completely, teams might look
for ways to make essential muda as efficient and cost-effective as possible.
55
LEAN CONCEPTS
Type II muda are non-value-added tasks that are not essential and can be immediately
removed from a process. For example, if a product is carried to and from several work
stations while it is being completed, it’s likely type II muda of conveyance exists. By
rearranging the workflow, teams might be able to reduce the muda by a substantial amount
without making any actual changes to how the product is put together.
5S is a Japanese Lean approach to organizing a workspace, so that by making a process

more effective and efficient, it will become easier to identify and expunge muda. 5S relies
on visual cues and a clean work area to enhance efficiencies, reduce accidents, and
standardize workflows to reduce defects. The method is based on five steps:
 Sort (Seiri)
 Straighten (Seiton)
 Shine (Seiso)
 Standardize (Seiketsu)
 Sustain (Shitsuke)
During the sort phase, all items or materials in a workspace are reviewed, removing
unneeded items and keeping necessary resources.
Consider the copy room in an office: over the years, supplies, tools, and machinery have
piled up. When going through the room, teams might decide that the stapler and Scotch
tape stay; people still need to staple pages or access tape. The old paper cutter isn’t
necessary for the team, since no one ever performs paper-cutting duties. However,
someone notes that the team in shipping and warehousing has to manually cut pages down
sometimes, so the paper cutter is relocated to that department. The team decides to toss a
bin of miscellaneous loose paper and an old fax machine because a new copy machine
includes fax capability. By eliminating obstacles and unnecessary items, costs, time, and
employee frustration are also removed.
The sort step lets you take inventory of an area, discover unused or wasted resources, and
make room for reorganization. Sort can also be applied with computerized processes.
56
Once excess is removed from the work area, teams must provide a streamlined and easy-to-
use location for everything necessary to the workspace. During the straighten phase, every
item, tool, or material is given a home. To facilitate ongoing organization, the location of
resources should be labeled clearly. The idea is to create a workspace that anyone could
use: if someone from another area comes to your copy room, it should only take a few
seconds to locate the right size paper. Employees in a factory should be able to move from
station to station, finding equipment and tools with ease. The goal is to provide the visual
controls that allow for common-sense operation. Labeling a shelf for letter-sized paper,
arranging sockets in size order in a drawer labeled sockets, or parking the forklift in a
marked area of factory floor when not in use are all good examples. Labeling the stapler
with a label maker is an example of things going beyond common sense: you don’t need to
label items that most people in the workplace would recognize on site.
The straighten phase also works well in a digital environment, especially when computers or
systems are used by a variety of people. In an office that has a shared workspace policy,
computer desktops might be pushed out by technical resources so that the same programs
are available to everyone. Not only are all programs the same, but the icons are in the same
location on each desktop so users don’t have to search for programs if they move to a new
workstation.
The third phase in the 5S methodology is targeted to keeping the workplace clean and neat.
Seiso can also be translated to “sweep, sanitize, or scrub.” The goal is to shine the work
space by cleaning it, maintaining equipment, and returning items to the proper place after
use. In a computerized environment, the shine phase can be accomplished by naming files
in a manner that makes them easy to locate, keeping folder structures intact, and deleting
or archiving files that are no longer necessary.
Shine can be applied to any environment, physical or digital.
The standardize phase is used to maintain the progress achieved in all previous phases. By
keeping high standards of orderliness in place, the benefits of the 5S methodology can be
long-term. The stress and speed of a daily workday can make it hard to keep up with the 5S
standards. If everyone is committed to working together, the benefits can be ongoing.
57
LEAN CONCEPTS
5S only works if everyone on the team or within the organization commits to the process.
Employees must follow the rules that are set up for standardizing and sustaining the
organization. Otherwise, the team enters a cycle of cleaning up after a period of failing to
keep up with the standards of 5S.
The overall benefits the 5S method includes:
 Reduced risks of accidents and safety issues

 Increased compliance with regulations from organizations such as OSHA
 A foundation that makes additional improvements easier to implement
 Waste is easier to identify and eliminate
 Production and quality are generally improved
All of these benefits translate to increased profits and customer satisfaction, which are the
overall goals of the Six Sigma methodology.
Just-in-Time manufacturing, or JIT, is another Lean concept that originated with Toyota.
Originally, JIT took a literal meaning. The goal of JIT manufacturing was to produce an
output “just in time,” or “as needed” by the customer. The customer was the person or
process that required the output; sometimes, that meant the end customers, and, other
times, the customer was a different employee or process within the organization.
In a JIT processing situation, one machine might produce a part required by another
machine. JIT manufacturing means that the first machine supplies only the amount of parts
that the second machine can process. If the second machine can process one part per
minute, the first machine is set to produce one part per minute. You’ll recognize this idea
from the sections on muda of inventory and overproduction.
It’s obviously not always possible to run a process just-in-time for the end customer, but
most modern companies do try to come as close as possible. Using predictive analytics,
companies attempt to estimate how many of each product will sell before they produce
those products. In some cases, such as with book publishing, companies run a smaller
number of items first. If those items sell well or sell out, the company orders bigger and
bigger runs of the product.
58
Some entrepreneurs have applied JIT manufacturing to DVD sales. These individuals and
companies buy the rights to films that have never been released on DVD or Blu-ray before.
They usually go after low-cost films that are likely to have a small cult or niche following.
Because the demand is small, it isn’t feasible to print and market these DVDs in traditional
fashion. However, the companies make a stable profit by selling the DVDs through online
retailers such as Amazon.com and printing the DVDs to order. Modern technology lets this
process occur with minimal expense and waiting.
Today, JIT mentalities are less about the literal idea of providing the product just in time;
rather, it has become a more general concept of Lean manufacturing that helps
organizations eliminate waste in the process.
We’ve covered many of the high level Lean concepts, and you’ll see some of these concepts
repeat throughout the rest of this book. While Six Sigma is concerned with improving
processes and reducing defects, eliminating waste and increasing efficiencies goes hand-in-
hand with these goals.
59
In the last chapter, we covered some of the major concepts associated with Lean. In this
chapter, we’ll look at some of the major concepts of the Six Sigma methodology. These,
along with the concepts introduced in Chapter 1, are some of the building blocks used in
improvement projects and statistical process control.
The driving goal of Six Sigma is to reduce defects. By reducing defects, teams can increase
productivity, decrease overall costs, increase customer satisfaction, and create maximum
profit. One idea inherent in the Six Sigma methodology is that variance is the root of many
defects.
For example, if an oven heats to exactly 350 degrees in five minutes and stays at that
temperature until it is turned off, it is less likely to burn cookies. If a cook measures each
ingredient exactly, he or she is more likely to turn out cookies that consistently taste good.
Add variation in the process, and consistency is lost. When consistency is lost, defects are
introduced. If the oven doesn’t maintain an exact temperature all the time, the cookies
might burn. If the cook puts in a cup of sugar instead of a cup and a half, the cookies might
not be sweet enough. Variation makes for inconsistent quality.
It’s important to note that removing variation alone doesn’t always improve quality. What if
the cook set the oven to 400 degrees all the time and only used half a cup of sugar for each
batch? The process has no variation, and neither do the results. The cookies will always be
bland and burnt.
Six Sigma process improvement teams usually take a two-step approach to improvements.
First, they have to determine if the process is functional. In the cookie example, does the
recipe work at all? Is there even a recipe? Once the team determines there is a workable
recipe, they make improvements to remove the variation that causes outputs to deviate
from the result intended by the recipe.
60
The statistical measure used by teams to understand variation in a process is known as

standard deviation. Standard deviation is represented in math by the lower case Greek
letter Sigma – the you saw in Chapter 1.
Standard deviation measures the distance between data points and the mean of all data. A
large standard deviation means an overall wide spread of points; a smaller standard deviation
means a closely clustered set of points.
The image above provides a graphical representation of deviation. Imagine the vertical axis is
a measure of time and the horizontal axis is a measure of temperature. The center line in each
image represents the mean temperature. You can see that the temperature over time varies
much more in the figure on the right.
Standard deviation is a statistical concept. The formula for standard deviation when dealing
with data of the entire population is:
61
BASIC SIX SIGMA CONCEPTS
You would use this formula if you have all the data elements of a population and not just a
random sampling of data elements. For example, if you wanted to find out what the
deviation was in the size of pizzas made, you could ask staff to measure each pizza before
serving it. You would have the data for the entire population of pizzas for the day, so you
could use the equation above. However, if you wanted to calculate standard deviation when
you have sample data, you would use the equation from the next section.
Formula Key:
Standard deviation
μ = mean
tells you to add up the results of all the calculations done for the items listed in the
parentheses
N = the number of data elements for which you calculated standard deviation
X = a place holder for each data element
If you’re new to statistics, the equation for standard deviation looks complicated. We’ll
break it down and run through some exercises on calculating standard deviation manually,
but in practice, you will usually use a statistical software tool to make this calculation
automatically.
For our explanation, we’ll use a data set from a teacher. She wants to find the standard
deviation of scores on the latest test. The scores from her class of 15 students are:
62
67, 68, 73, 74, 81, 85, 88, 88, 90, 90, 90, 93, 94, 98, 99
1. Calculate the mean.
To begin the standard deviation calculation, you need to know the mean for the population.
The mean is represented mathematically by the Greek letter mu, or μ. Mean is calculated
by adding all of the numbers and dividing that sum by the number of items in a data set. In
this case, there are 15 items.
67 + 68 + 73 + 74 + 81 + 85 + 88 + 88 + 90 + 90 + 90 + 93 + 94 + 98 + 99 = 1278
1193/15 = 85.2
2. Subtract the mean and square it.
The formula calls for you to take each number in the data set, subtract the mean from it,
and square the result. The first number is 67, so:
67 – 85.2 = -18.2
-18.2 * -18.2 = 331.24
If you apply that concept to all 15 numbers, you end up with a list of results:
331.24
295.84
148.84
125.44
17.64
0.04
7.84
7.84
23.04
23.04
23.04
60.84
77.44
163.84
190.44
3. Find the mean of the results.

63
The rest of the formula under the square root sign simply tells you to add up all the
numbers you just calculated and divide by N, where N is the number of items in your data
set. Or, to put it another way, you need to find the mean of the new numbers you just
calculated.
The sum of the numbers above is 1496.4.
1496.4 / 15 = 99.76
This new number, 99.76, is called the variance.
4. Find the square root of the variance.

The standard deviation is the square root of the variance. In this case, the square root of
99.76, which is 9.987.
The standard deviation for the test scores is 9.987.
While statistics based on total population data are always more accurate than those based
on sample data, you’ll probably work from sample data more often. It just becomes too
expensive or even impossible to get population data for many elements. Sometimes, the
data is measuring events or states over time, which means population data doesn’t exist.
For example, if you wanted to understand temperature fluctuations in a warehouse, you
might record the temperature at a certain location every ten minutes. After several days,
you have sufficient sample data to analyze.
Other examples of sample data include:
 A random sample of reasons for denied medical claims

 Measurements for river height taken three times per day for a month
The formula for standard deviation based on sample data is:
64
Formula Key:
sStandard deviation of a sample
x-bar = the mean of the sample
tells you to add up the results of all the calculations done for the items listed in the
parentheses
N = the number of data elements for which you calculated standard deviation
X = a place holder for each data element
Since mu is the mean of population data, it’s been replaced in this formula with x-bar, which
is the average of the data points in your sample. Sigma has been replaced with s, but the
only mathematical difference is that you divide by N-1 instead of N to get the variance as a
way to make up for some of the accuracy lost in using a sampling.
Using the same data from the population example above, let’s assume that the 15 grades
the teacher had were a random sampling from all of her classes. The only difference in the
math would come in the second to last step, where we divide by 14 instead of 15, so:
1496.4 / 14 = 106.885
The square root of 106.885 is 10.338, which would be the standard deviation for the
sample.
65
See for yourself:
Lab techs are measuring the response of bacteria to an ingredient in a potential

treatment. They want to know how long it takes bacteria to show a response. Sample
data for response times in minutes is:
2, 3.5, 2.3, 2, 2.5, 3.1, 2.2, 3.2, 4
Calculate the standard deviation.
Admittedly, if you’re calculating standard deviation by hand, it’s a lot of arithmetic. Luckily,
once the statistical concepts behind the numbers are understood, statistical analysis
software, such as Excel and Minitab, can be used to accurately crunch numbers. Standard
deviation is automatically calculated in most statistical analysis software programs by
clicking a button after you enter your data sets. The standard deviation is also calculated
automatically by such software programs when you initiate other calculations that require
standard deviation. We’ll look at some of these functions more in-depth in the chapters on
using Excel add-ons and Minitab for statistical analysis.
In the meantime, you can quickly calculate standard deviation in Excel using the standard
deviation function. To do so:
1. Enter your data set in a column
66
2. In a new cell, enter =STDEV()
3. Select the cells with data you want to calculate standard deviation for.
4. Hit enter
Note: The formula in Excel calculates a sample standard deviation using the N-1 math,
which means you can use this formula for samples and not for populations.
Standard deviation gives you an idea of how much variation actually exists in a process
while taking outliers somewhat into account. In the example of the grades from above, the
sample standard deviation indicates that most of the grades are going to fall within 10.33
points on either side of the average.
That tells the teacher that students have a fairly wide performance on her test. If the results
were an average score of 90 with a standard deviation of 3, he or she might assume that
students in class were learning and retaining the knowledge as expected. If the average
score was 64 with a standard deviation of 2, then he or she might assume students in class
were not retaining the knowledge as expected or there was some issue with the test
structure. Both of these situations indicate a small variance in the way students are
performing, which points to the success or problem being tied to the class, the teaching, or
the test.
67
On the other hand, if the average score was 60 with a standard deviation of 30, then some
students were performing very well while others were performing poorly. This might
indicate to the teacher that some students are falling behind. If he or she took samples from
several classes, he or she might investigate and realize that the lowest scores were mostly
from one class, which could indicate that he or she forgot to adequately cover a certain
concept in that class.
Standard deviation alone serves as a pointer for where to investigate within the process for
problems or solutions. Another reason to calculate it is because it is involved in many of the
other statistical processes we cover in later chapters. Standard deviation becomes an
important concept in both analysis and statistical process control and often serves as the
starting point for further Statistical Six Sigma analysis.
The Pareto principle, also called the 80/20 rule, says that 20 percent of the causes lead to
80 percent of the effects. This there is also called the law of the vital few: the vital few
inputs drive the majority of the outputs.
The Pareto principle was first suggested by a management consultant named Joseph Juran.
Juran named the principle for Vilfredo Pareto, an economist in Italy who wrote that 20
percent of the nation’s people owned 80 percent of its land. The principle has become
common in various circles. Business professionals commonly state that 80 percent of sales
come from 20 percent of customers, and volunteer organizations usually operate with 20
percent of the people doing 80 percent of the work.
The principle is critical to Six Sigma not because causes and effects line up nicely via an
80/20 breakdown, but because it almost universally applies that a few inputs create more
impact than all of the other inputs. Individuals seeking to reduce defects can almost always
identify three to four inputs that, if improved, will create dramatic impact on the outcome.
While resources, costs, and difficulty of improvements also play a role in solution selections,
understanding which inputs or root causes are high on a Pareto chart let project teams
determine where improvements will make the biggest impact to the bottom line.
The Pareto principle is best displayed using a Pareto chart, which is a graphical
representation of data elements – usually inputs or causes – in a ranked bar chart. Unlike a
regular bar chart, the bars are arranged in order of height, with the highest on the left and
the lowest on the right. Statistical software used to create such charts adds formatting and
other elements automatically, but you can also create a basic Pareto chart in Excel.
68
To illustrate the Pareto principle, we’ll look at a common situation involving defects in the
medical field—specifically in the process for submitting medical claims. Payers often deny
claims, and they do so for a variety of reasons. When claims are denied, provider offices
have to rework, resubmit, or appeal the denials. Some denial reasons are not appealable,
which means the provider’s office loses the revenue associated with the claim.
We’ll imagine a medical office that is experiencing a cash flow problem because of claim
denials. The office gathers data about the denials and creates a Pareto chart so the team
can see where the bulk of the denials are coming from. The data is listed below, followed by
a basic Pareto chart created in Excel.
Reasons for Denying Medical Claims

Reason Count
Duplicate claim 18012
Timely Filing 13245
No beneficiary found 10215
Claim lacks information 4548
Service not covered 2154
Medical necessity 1423
Date of service issue 526
69
From the Pareto chart, you can see that the top three denial reasons account for 80 percent
of the denied claims. An experienced billing team could tell you three things just from
looking at this data:
 The office has muda of rework. They are sending a large percentage of claims more
than one time.
 The office has an efficiency problem. Almost a fourth of their claims are not making
it to the payer pior to timely filing deadlines.
 The office has an insurance verification problem, because a fifth of their claims are
being sent with information that doesn’t match anything on the payer’s end.
Addressing duplicate claims is important because it reduces rework and could enhance the
office’s relationship with insurance companies. However, the team might choose to work on
the timely filing problem first because timely filing denials are final, which means the office
is losing the revenue associated with all those claims. Filing claims on time is not difficult in
many cases, given the fact that most payers allow months or even a year for claims to be
filed, so this could be an “easy” win for the team. A Pareto chart often uncovers low-
hanging fruit in this manner.
70
If you don’t have statistical software, you can create a basic Pareto chart like the one above
in Excel. Use the claims denial data or data of your own to practice making a Pareto chart.
1. Create a column for the data labels. Pareto charts work well when you have
quantifiable causes for a defect or other effect. In the example, the data labels are
the reason for the denial. No matter what type of data you are using, enter it in
order from largest to smallest for Pareto chart purposes.
2. Create a column for count. Enter the total for each cause in that column.
3. Create a column for cumulative count. This column provides a running total. You
can calculate the numbers manually or using Excel. In the data table below, you
would set C3 = B3. In C4, you would enter the formula =C3+B4. You can drag that
formula down and Excel will change the references for each cell so you get =C4+B5,
=C5+B6…and so forth.
4. Create a column for percent. In the data table below, the formula for D3 is
=B3/$C$9. Cell C9 has the total of all denials, so we want to divide each individual
denial total by C9. The dollar signs in the formula let you copy it into each lower
cell. The first reference will change, moving to the next line, but the dollar signs tell
Excel to keep the C9 reference for each calculation. The final result is a table that
looks like this:
Reason Count Cumulative Percent

Duplicate claim 18012 18012 35.9%
Timely Filing 13245 31257 26.4%
No beneficiary found 10215 41472 20.4%
Claim lacks information 4548 46020 9.1%
Service not covered 2154 48174 4.3%
Medical necessity 1423 49597 2.8%
Date of service issue 526 50123 1.0%
5. To create the Pareto chart, highlight the information in both the Reason and
Percent column and select Insert  Chart  Bar chart.
71
6. The bar chart will be created automatically. Select Add Chart Element  Trendline,
and add either an exponential or linear trendline.
72
7. Select Add Chart Element  Data Labels, and select the format of data label you
prefer for your chart.
73
Pareto charts are helpful analytical tools when you need to analyze frequencies or causes of
problems. They also help narrow an approach for a problem that has many causes or is too
broad to address in a single improvement project. Like the claims denials example above,
you can find a single cause to work on that can yield large results across the entire process.
Pareto charts are also helpful when communicating information about causes to others,
especially those outside of the Six Sigma process. Although Pareto charts are a powerful
analytical tool, they also represent complex data in a visual format that is familiar to most
anyone. Business professionals know how to read a bar chart, and putting the chart in order
only makes it easier for individuals to see the true causes behind issues. For this reason,
many Six Sigma experts regularly include Pareto charts when presenting to business leaders
74
and others, especially if the data might be considered surprising or need visual
reinforcement.
Voice of the Customer, or VOC, is a foundational concept in many quality programs. The
goal of quality is to make a better, more consistent product. One of the ways you know
you’ve reached this goal is that your customers will be more consistently satisfied. The only
way to reach this goal is to seek feedback from the customer, making VOC data critical to
collect before, during, and after improvement projects.
Successful VOC programs are proactive and constant in their desire for feedback, and
technology makes it possible to seek customer feedback in numerous ways. Some methods
for capturing feedback include:
 Surveys via telephone, mail, email, or online

 Focus groups in person or online
 Interviews
 Beta or user testing
 Feedback forms
 Customer complaints
 Social media or site interaction
 Reviews
 Forums
The VOC can be sought as a means to clarify needs and desires, clarify specific problems
with a process, or as a regular part of improvement, customer service, and marketing
agendas.
Asking the right questions, in the right way, helps you create powerful VOC campaigns that
provide useable data for Six Sigma teams. We’ll talk about two specific types of VOC
campaigns in this section: general customer feedback and specific customer feedback.
General customer feedback is often obtained through feedback forms, customer complaint
records, and passive information gathering via websites or social media. Through such
methods, organizations are usually testing general waters to get a temperature reading: are
75
customers happy overall, dissatisfied overall, and is there any direction as to the cause of
customer feelings?
Pick up a feedback form in any fast food restaurant or access the online survey usually
linked to on a receipt and you’ll get a good idea of the type of information sought in general
VOC campaigns.
Kroger, a grocery store chain in the United States, includes a link to a survey on most of its
receipts. The survey first asks for the date, time, and an entry code from the receipt. This
helps the company know where and when a person shopped so they can attribute feedback
to the right location and staff.
Next, the Kroger survey asks in which areas of the store a person shopped. The rest of the
survey asks specific questions about each area of the store a person visited, including:
 What was the overall satisfaction with the store?

 What was the customer’s satisfaction with:
o Employee friendliness
o Prices
o Service
o Cleanliness
o Items being available
o Weekly specials
o Ease of movement
o Quality of brands
o Check out times
 Whether the shopper is likely to recommend the store to another person in the
next 30 days.
These questions are designed to gauge general customer feelings on critical quality
elements for the store. Understanding your critical to quality factors, or CTQs, is important
to designing a strong VOC campaign. We’ll cover CTQs more in depth in Chapter 8.
General VOC feedback is often used as a smoke alarm. A smoke alarm is designed to alert
individuals in a business, home, or other building that the possibility of a fire exists. Smoke
alarms are set at a sensitive level, so they go off when smoke is present and people within
the building can take action. Often, the alarm and early action saves lives and can even
reduce damage associated with a potential fire.
76
VOC data can work the same way. If numbers change suddenly in a certain area, an
organization knows to look deeper into the issue. It’s an indicator that a problem could
exist; early investigation and action can help prevent problems from becoming bigger or
more costly. For example, if a certain Kroger store always scored high in cleanliness, and the
numbers dropped consistently across a month, then store management might need to
revisit maintenance and cleaning training.
Results from general VOC feedback are also used in some organizations as an indicator of
quality for certain employees. Sales and services staff are often rewarded financially and in
other ways for high customer satisfaction scores. This also increases employee drive and
satisfaction.
Sometimes, organizations want feedback that is specific to a problem, product, or idea. The
same tools used in general feedback campaigns can be used in specific campaigns, but you
can also tailor the VOC tool to the need. If you want feedback about a new app, you could
use a beta test. If you want to test a product, idea, or marketing campaign, an in-person or
online focus group might be best.
For specific feedback, you have to ask specific questions. This is especially true if you are
seeking additional information or clarification of general feedback. For example, if Kroger
did see a problem with ratings on cleanliness, it might want more information about how
and where customers note uncleanliness. Without additional feedback, managers might
have staff mopping the floors more when customers really felt the store was dirty because
of a lack of lighting or because shelves were stocked in a sloppy manner.
Getting the right type of feedback—and keeping costs and timelines within budget—
requires selecting the right VOC tool for your project. The table below rates each tool on
relative cost and provides some brief pros and cons.
77
Tool Cost Benefits Disadvantages
Feedback form Low -Gathers a lot of -An individual must

data from many decide to leave
sources feedback, skewing
results to people who
-Can be geared
feel strongly one way
toward numeric
or the other
data for easier
analysis
Survey via High -Can randomly -Requires a lot of labor

phone select, which hours
allows you to draw
-Customers may be
conclusions for the
annoyed by unwanted
entire population
phone calls
Survey via mail Medium -Can randomly -The customer must

select, which send it back for it to
allows you to draw count. Because many
conclusions for the people won’t do so,
entire population. you have to send more
surveys to get a
-Lower cost
statistical sampling.
alternative to
phone or in-
person surveys.
Social media Low -Ongoing ability to -Requires an

seek feedback. established social
media following.
-Ability to ask
questions on the
fly.
-Relies on followers and
-Possibly the least fans, which means you
expensive option are asking for feedback
for VOC. from people who
78
already favor your

brand in some way.
Focus groups in High -Lets moderators -Limits data pool to

person seek more in- local customers or
depth answers or those willing to travel.
feedback
immediately -Can’t use data to make
assumptions about the
general population.
-Customers may be less

inclined to be honest
when face-to-face with
surveyors
Focus groups Low -Lets moderators -Can’t use data to make

online seek more in- assumptions about
depth answers or general population.
feedback
immediately
-Doesn’t require
travel and you can
access customers
across the globe
User or beta High -Provides feedback -Takes time and

testing about a specific requires experienced
produce, service, users or testers.
or process.
When designing your own VOC tool, keep in mind how you intend to use the information
gained. If you want to input data into statistical analysis software to test hypothesis or
79
create visual charts, then you need to ask questions that yield actual data points that can be
analyzed using statistics. A popular way to do this is with a Likert Scale.
Using a Likert Scale, you would frame all questions so they are answered via a 5-point
ranking. The ranking can be any number of things, but most commonly is some variation of:
 Strongly agree
 Agree
 Neutral
 Disagree
 Strongly disagree
The answers are coded with numbers when data is entered into statistical software. For
example, an answer of strongly agree might be coded as 10. Agree would be 7, neutral 5,
disagree 3, and strongly disagree 1. By using numerical data, you can easily create charts
and graphs and run more in-depth statistical analysis, which is covered in future chapters.
We introduced some ideas about Six Sigma metrics in Chapter 1 when we talked about
sigma level and defects per million opportunities, or DPMO. Metrics are extremely utilized
when applying Six Sigma to processes and improvements, requiring that anyone working in
a Six Sigma environment be familiar with them.
Many Six Sigma metrics come with an equation, just like standard deviation. For example,
the equation for DPMO is:
(number of defects in a sample/opportunities for a defect in the sample) * 1,000,000
For example, if a mail-order retailer examines quality of the order process, it might sample
forms entered by customer service representatives. If each form has 10 fields, then there
are 10 opportunities for an error on each form. If the retailer reviews 90 forms, then there
are 10 * 90, or 900, total opportunities for errors.
During the review, the retailer finds 2 errors, or defects. To calculate DPMO, the math
would be as follows:
(2/900) * 1,000,000 = 2,222 defects per million opportunities.
80
DPU is a measure of how many defects there are in relation to the number of units tested.
DPU is concerned with total defects, and one unit could have more than one defect. The
formula for DPU is:
Number of defects found / number of units in the sample
For example, if a publisher printed 1,000 books and pulled out 50 books for quality checks,
it might be looking for the following defects:
 Incorrect printing
 Incorrect alignment
 Missing pages
 A loose spine
 Torn cover
Out of 50 books, the publisher discovers:
 3 books are missing pages

 1 book is missing pages and has a torn cover
 2 books have loose spines
 1 book has incorrect printing and incorrect alignment
There are 9 total errors, as two books had two defects each.
The DPU is calculated by dividing defects by number of units sampled. In this case, 9/50 =
0.18.
DPU provides an average level of quality—it tells you how many defects on average each
unit can be expected to have. In this case, that is 0.18 defects on average.
First time yield is the ratio of units produced to units attempted to produce. For example, if
you put 12 cookies in the oven, but only 10 come out edible, then you haven’t produced 12
cookies.
The formula for FTY is:
81
Number of good units produced / number of units entering the process
In the cookie example, the FTY is 10/12, or .833.
Most products or services are created via multiple processes; you multiply the FTY for each
process to calculate an overall FTY. For example, consider the following process chain:
 100 units enter process A and 95 units exit.

 95 units enter process B and 85 good units are achieved.
 85 units enter process C and 80 good units exit.
The FTY would be calculated as follows:
 95/100 = 0.95 = FTY of process A

 85/95 = 0.89 = FTY of process B
 80/85 = 0.94 = FTY of process C
 0.95 * 0.89 * 0.94 = 0.79
The overall FTY of the process is 0.79.
The rolled throughput yield, or RTY, provides a probability that a unit will be generated by a
process with no defects. One of the main differences between RTY and basic yield or first
time yield is that RTY considers whether rework was needed to generate the number of
final units. This is a valuable concern, because organizations don’t always think about the
rework that is inherent in a process, which means they often measure a process and deem
it successful even if muda is present.
RTY is calculated in a similar manner to FTY, but it takes rework into account. If process A
from the FTY example only achieved a yield of 95 because someone reworked five items to
make them good, then RTY calculations add five instances of rework into the ratio. The
formula is:
(Number of units entering - (scrap + rework))/number of units entering process
In the case of process A: (100 - (5+5))/100 = 90/100 = 0.9
Consider the following process chain:
 100 units enter process A. Five are scrapped, 5 are reworked, and a total of 95 are
produced.
82
 95 units enter process B. Ten are scrapped, 5 are reworked, and a total of 85 are
produced.
 85 units enter process C. Five are scrapped, 15 are reworked, and a total of 80 are
produced.
The RTY is calculated as follows:
 100 – (5 + 5) = 90, 90/100 = 0.9 RTY for A

 95 – (10 + 5) = 80, 80/95 = 0.84 RTY for B
 85 – (5 + 15) = 65, 65/85 = 0.76 RTY for C
 0.9 * 0.84 * 0.76 = 0.574
The overall RTY for the process is 0.574, which is a much lower rate than when you look
at FTY alone. RTY doesn’t provide an indication of final production or sales, but a low
RTY indicates that there is waste in the process in the form of rework.
See for yourself
A government agency handles applications for assistance for local families. The process for
each application includes:
- A representative enters the family’s information into a computer system

- A separate staff member reviews the information and uses an income scale to
determine if the family is eligible for any assistance
- The second staff member sends the family a letter stating their options for assistance
All of the applications and customer feedback for March were reviewed, and the team
found the following information:
- 643 families sought assistance in March

- 3 families were not able to complete the application process because the
representative took too long to see them
- 50 applications could not be passed to the second rep because of incomplete
information
- 45 applications did not have complete information at first but that information was
later received
- The second staff member was able to process all completed applications she received
- Of all letters that went out to families, 10 included incorrect information
Calculate the FTY and the RTY for this process.
83
Understanding how to approach the problem – beginning to identify the problem and
defining it with a statement – is critical to creating a foundation for successful Six Sigma
projects. In later chapters, we’ll cover the importance of defining a variety of project,
process, and problem aspects, but in this chapter, we’re going to discuss the project in
general, digging deeper via a series of why questions, and creating a general problem
statement as a launching point for a project.
Because Six Sigma approaches things with a statistical mindset, it considers all problems as
a function. Using mathematical symbols, this looks like:
The y=f(x) statement can be used in two ways. First, it is a general map for stating a
problem. Y (the problem) occurs because some X (input or cause) is occurring. In reality, Y is
usually occurring because of some group of causes or inputs, which means there are going
to be more than one X inputs.
The idea can also be applied to specific processes and outcomes within the problem. As you
get more and more granular, the y=f(x) concept becomes increasingly mathematical; in
many cases, you can graph the relationship between the output (y) and the input (x).
84
To understand the concept of thinking of problems as a function, let’s look at a problem

that might occur for a large HVAC service provider. The manager of a service team has
discovered that service calls are taking much longer than expected; in fact, his five team
members take 1.75 times longer on average than other service reps in the company to
handle all types of calls.
To find out what might be causing the situation, the manager researches the problem by
talking to the reps, talking to the customers, and going out on random calls with all five
representatives. He makes the following observations:
 One representative is a native to the area the team services, which means he or
she knows many of the customers personally. This results in friendly chatter
that lengthens the time on the job.
 One representative is providing homeowners with very in-depth explanations
and education about HVAC issues, sometimes over and beyond what the
homeowner would ever need to know regarding his or her HVAC unit.
 One representative is new to the job and takes longer to complete each task
because he or she is unsure of the work, has to double-check the work, or calls
another rep to ask questions about the work.
 The remaining two reps perform work in times that are on par with company
averages.
The manager distills this data down to two overall causes for the problem:
 Too much talking (reps one and two)

 Inadequate training
The problem can now be stated as a function:
The extra time is a function of too much talking and inappropriate training.
The manager also now has two root causes to address. The example is simple, but it
illustrates the basic concept in defining a y=f(x) relationship for a problem and its causes.
It’s not always so easy to conduct the research and analysis to find the relationship, but the
relationship is always present.
Some other examples of y=f(x) relationships include:
 Low customer satisfaction with hamburger taste is a function of an uncalibrated

grill.
85
 Low employee morale is a function of a poor time-off approval system.
 Customer wait times are a function of technology distractions for employees.
Data analysis is one of the best ways to validate a y=f(x) assumption, but teams who are
familiar with processes can often arrive at some basic relationships through a process
known as the 5 Whys. This is a brainstorming tool that asks increasingly granular why
questions about a problem or process, seeking to understand the root cause or actual
problem. The 5 Whys can be used to define a problem or to begin seeking causes.
For example, consider the hamburger example above. Teams addressing a problem of
customer satisfaction might begin doing so because feedback forms have shown a lower-
than-normal satisfaction with food quality over the past week.
The team first asks: Why are customers dissatisfied with the food?
Looking at feedback tied to orders, the team notes that the customers who are rating the
food poorly are mostly customers who ordered hamburgers of some type. The answer to
the first question is that the customers are dissatisfied with the food because they are
dissatisfied with the hamburgers.
Why are customers dissatisfied with hamburgers?
The team looks at written feedback on forms or speaks with customers directly and
discovers that many customers feel that their hamburgers were undercooked. The new
answer is that customers are dissatisfied with hamburgers because the meat is
undercooked.
Why is the meat undercooked?
An investigation into the kitchen reveals that the grill is not properly calibrated and is
providing inconsistent results. At this point, you have the y=f(x) relationship, but the team
could keep asking questions.
Why is the grill not properly calibrated?
Further investigation shows that the morning shift, responsible for calibrating the grill, has a
new grill cook. During training, education on performing this function was omitted. The grill
is not properly calibrated because the employee responsible was not properly trained. Now
the team has a specific cause and a solution: train the grill cook.
86
In a Six Sigma environment, the team might move on with one more question: Why was the
grill cook not properly trained? This might lead to the development of a consistent training
policy so the problem doesn’t occur the next time a new grill cook is hired.
In the hamburger example, it only took four why questions to get to the root of the
problem, and a fifth question started pointing to controls or long-term solutions. It isn’t
always this easy; the tool is called the 5 Whys because it often leads to answers within five
questions. However, teams could ask a dozen questions if they begin at a very high level and
work down through a complex process.
One benefit of 5 Whys is that it only costs your team a small amount of time to use—a team
familiar with a process can conduct a complete 5 Whys session in less than an hour if a
moderator keeps things on task. Because of its simplicity, the 5 Whys tool can be used for
almost any problem. Use it to address a problem team members bring up, to address a
problem a supervisor noticed, or to address the vague feeling that there is a problem when
no one has been able to define what is actually wrong. At the very least, a 5 Whys session
facilitates communication and thought.
In a Six Sigma project environment, 5 Whys is usually deployed when processes involve
human interactions or people-powered inputs, though it can be an effective start to
brainstorming on any process.
Since a 5 Whys session is usually based on input from subject-matter-experts, gather people
who are close to the process. On a white board or web conference screen, display a basic
problem statement as you understand it. This problem statement is not going to be detailed
like the statements we’ll discuss in the next session—a 5 Whys session is often one of the
tools you use to get to that detailed statement.
Examples of statements you might see in a 5 Whys station include:
 Customers are not happy with the selection of produce

 Customers are receiving orders late
 The printing process is resulting in too many defects
 Lead times on the bottling process are excessive
 Employees are not happy with vacation schedules
87
These are all fairly general statements that simply say something about defects or
dissatisfaction. Begin by asking the highest-level “Why?” question possible about the
statement. “Why are employees not happy with vacation schedules?” Write this question
down.
The team works together to provide a high level answer to the question. Employees are not
happy with vacation schedules because it’s rare to get the exact time off requested. Write
the answer down under the question, then create the highest-level “Why?” question you
can about the new answer.
“Why are employees not getting their first choice time off for vacation?” Perhaps the
answer is that supervisors take so long to approve vacation requests that other employees
have also asked off for the same time, so it’s hard for supervisors to accommodate
everyone.
The next question is “Why are supervisors taking too long to approve requests?” The
answer might be that the time-off system is too cumbersome, so supervisors put off
approvals until they have a lot of time to manage them.
“Why do supervisors see the system as cumbersome?” Because there are wait times when
moving from screen to screen and each approval requires a vast number of clicks and
entries.
Now, the team has a root cause: the system itself is inefficient, which leads to problems
down the line. If the team can correct the programing issues and encourage supervisors to
approve vacation requests faster, employee morale can be improved.
A Six Sigma improvement project usually starts with a formal project statement. This is
different from the basic statements used to launch a 5 Whys session. A strong problem
statement is similar to a 30-second elevator pitch, which executives and sales people across
the globe use to hook clients or business investors on an idea. The problem statement, like
that pitch, provides enough information that a busy executive can understand what the
issue is and why there is a need for an improvement effort.
Project statements should include:
 Where and when the problem was recorded or was occurring

 A measurement of magnitude for the problem, preferably with some tie to cost
88
 A brief description of the problem that could be understood by professionals

not closely aligned with the process (avoid too many niche words and acronyms
if you will be presenting information to non-niche professionals)
 A brief notation about the metric used to measure or describe the problem
In the first quarter, the California distribution center sent 108,000 packages. Of those
packages, 15,000 were returned, resulting in a 13.8 percent return rate. The rate of return is
above the accepted 7 percent rate and cost the company an additional $372,000 for the
quarter. Over the course of the year, the current process could result in additional costs of
over $1.4 million.
This problem statement covers all the basic information:
 When? During the first quarter of this year.

 Where? The California distribution center
 What? Returns
 How many? 15,000, or 6.8 percent above expectations
 What is the magnitude? The cost could be $1.4 million a year
The problem statement doesn’t talk about solutions or provide too many details. This is a
strong problem statement because it answers all the basic questions and it provides a
significant reason for leadership to invest interest: $1.4 million a year is a big loss.
The Canton, Ohio bakery is producing undercooked bread. Customer dissatisfaction with the
bread is resulting in returns and bad word of mouth. The bread is supposed to be baked at
350 degrees for 40 minutes.
This statement introduces a problem, but it doesn’t provide details about when the
problem occurred, how it was measured, and what the true magnitude is. The problem
statement also begins going into possible root causes when it includes how the bread
should be baked; the problem statement isn’t the place to begin this type of analysis.
This statement might be better framed as:
In November and December 2014, customer satisfaction complaints were traced back to
bread baked in the Canton, Ohio facility. The facility produced 300,000 loaves during that
89
time period and received 50,000 complaints of bread being undercooked. Bread returns and
loss of sales related to quality are estimated to be $125,000 per month.
When you first start writing problem statements, it’s sometimes harder than you might
expect to get all the information into a couple of sentences. To avoid leaving out
information, it helps to use a list and to consider yourself a problem-statement journalist.
When journalists write a report, they are looking to answer some specific questions: What
happened? Who did it happen to? When did it happen? Why does the audience care?
The same is true when you are writing a problem statement. Follow the problem statement
checklist:
o Where did the problem occur?

o When did the problem occur?
o What process did the problem involve?
o How is the problem measured?
o How much is the problem costing (in money, time, customer satisfaction, or
another critical metric)?
Use the checklist to construct the problem statement, and then ask yourself: Could
someone else answer all the questions in the checklist from your problem statement alone?
Before you present your statement to a boss or other decision-maker, test it out with a
coworker or someone who is not as familiar with the issue as you are.
Here are two problem statements. See if you can answer all of the questions in the checklist
just using the information provided.
The call center in Jacksonville, Florida, handled 36,000 calls in February 2015. Of those calls,
8,000 had an average speed of answer (ASA) over the contract-required 15 seconds. Those
8,000 service-level-agreement violations resulted in costs of $200,000.
The call center in Ohio has a service-level-agreement issue that is costing approximately
$9,000 per day.
90
Problem statement 1 answers all of the questions on the checklist:
o Where did the problem occur? Jacksonville, Florida

o When did the problem occur? February 2015
o What process did the problem involve? Answering phone calls
o How is the problem measured? Average speed of answer
another critical metric)? $200,000 per month
Problem statement 2 does not answer all of the questions:
o Where did the problem occur? Ohio

o When did the problem occur? Unknown
o What process did the problem involve? Unknown
o How is the problem measured? Unknown
another critical metric)? $9,000 per month
Problem statement 2 would benefit from adding a place, a specific reference to a process,
and a specific metric.
Another way to tell you have a strong problem statement is that you can create an overall
project objective statement or goal directly from the problem statement. Consider the two
examples above.
The team working with problem statement 1 might create an objective that states:
The goal is to reduce answer speed SLA violations in the Jacksonville call center by 50
percent within three months. The potential savings to the company is $100,000 per month.
The team working with problem statement 2 would not be able to create a goal statement
with this much detail. They would simply be able to say they hope to reduce the service-
level-agreement violations in the facility.
Specific problem and objective statements are critical to Six Sigma project success for
several reasons. First, being as specific as possible sets up appropriate expectations. In the
first example, leadership has a specific expectation of the project: the team is going to work
to reduce average speed of answer, and success is a reduction of 50 percent. No one is
91
going to expect the team to solve another problem, such as customer satisfaction with
phone operators. That is out of scope for this project.
In the second situation, the problem and goal statements are not specific enough. What SLA
violations is the team addressing? What, exactly, does success look like? Is the team
expected to reduce costs completely? Not being specific enough sets you up for failure.
Leadership might expect you to address service level agreements that have to do with how
reps route phone calls, but you are only intending to address service level agreements that
relate to the speed with which calls are answered. Leadership might think success is a 75
percent reduction in costs when you intend to work toward a 25 percent reduction.
Creating strong problem statements lays a stable foundation for the rest of your project,
gives the team a beacon when they get overwhelmed with information, and reduces the
chance of scope creep and misunderstanding.
Scope is the definition of what is included – and what is not included – in a process or
improvement project. You begin defining scope with your problem statement. The
information you include in the statement gives clues to what you will be working on, and
the goal statement provides appropriate limits on the work to be done.
Six Sigma projects are not everlasting initiatives, though the culture of improvement that
comes from Six Sigma is. This means your individual project needs a specific, challenging,
but attainable goal. Once that goal is met, the project is concluded and you begin looking
for a new problem to improve upon.
Scope creep occurs when teams look to make infinite perfections on a process, attempt to
reach unrealistic goals, or begin to reach for processes or problems that are out of the
original scope. For example, consider the problem statement from one of our examples in
this chapter:
In the first quarter, the California distribution center sent 108,000 packages. Of those
packages, 15,000 were returned, resulting in a 13.8 percent return rate. The rate of return is
above the accepted 7 percent rate and cost the company an additional $372,000 for the
quarter. Over the course of the year, the current process could result in additional costs of
over $1.4 million.
A related goal statement might be:
92
The goal is to reduce the return rate to the accepted 7 percent and save the company
$372,000 per quarter.
In scope for this project are processes related to shipping and returns only insomuch that
they impact the return process. At some point, the team might stumble upon a packing
process that is using too much material, thus costing the company an additional $50,000
per month. Unless the packing process is causing the returns—which is not likely in this
situation—this issue is not in scope for the team and they should not seek to fix it. The team
can, however, note the issue or report it so that a future project might be launched to
address the problem.
It takes discipline and organization to address only that which is in scope for a project.
Understanding the relationship between problems and inputs and knowing how to create a
strong problem statement are the first steps to controlling an improvement process.
93
In Unit 1, we introduced Six Sigma as a concept and covered a lot of principles that
are foundational to creating and maintaining improvement in a business. In Unit 2,
we’ll begin looking at what a process is, why quality is important in a process, and
how Six Sigma projects can improve processes. The concepts you learn in Units 1
and 2 become the bricks used to build project work that we discuss throughout the
rest of the book.
A process is a collection of tasks, steps, or activities that are performed, usually in a specific
order, and result in an end product such as a tangible good or the provision of a service. In a
business, multiple processes work together to achieve organizational goals. Technically, the
business or organization itself can be seen as one enormous process. For example, a law
firm that handles criminal defense cases operates via a huge, complex process. Defendants
and their cases enter the process. The output of the process is the result of the case: a
bargain with prosecutors, a win or loss in court, or dismissal of charges prior to court.
Within the huge process that sees the defendant through to his or her outcome, there are
hundreds, possibly thousands, of smaller processes. There are processes within processes. A
lawyer and team of paralegals might move through the process of negotiation; a legal
secretary might go through the process of setting appointments. Holding depositions,
making copies, sending letters, and filing legal documents are all examples of processes. At
the most detailed level, even answering the phone or typing a letter can be considered
processes.
94
In Chapter 6, we briefly introduced the idea of scope and scope creep. To define and
maintain proper scope, we said that a Six Sigma team had to identify the processes that
were related to a process improvement or project. In the legal firm example, a project to
reduce the time it takes to set appointments would likely not include a process for filing a
legal brief. To know that, however, you have to know that the legal brief process doesn’t
share components with the appointment setting process. In this chapter, we’ll cover the
components of processes and a format for mapping those components known as a SIPOC.
As you continue with this chapter, you’ll see that processes can be very complex. Our basic
definition above is just that: Basic. Before we begin defining the components of a process,
let’s peel back the layers of this concept known as “a process.”
Whether physical, digital, or ideological, every process is a series of some number of steps.
You can put those steps on paper in the form of instructions—often called a standard
operating procedure in a formal business training or policy document -- or a visual diagram
known as a process map. A process map uses standard shapes and connections to create a
map of a process that can be understood by most employees and any Six Sigma team
member.
Processes all take a certain amount of time, and processing time can change with a variety
of factors. Process maps and documents can only record information such as the average
time a process takes or measures of variation in the processing time. This information is
often noted in such documents because it provides valuable information to teams, but real-
time observation of a process almost always provides better information about processing
time.
A retail chain might create a process map for restocking a certain area. The process
documentation notes an average time of two hours to fully restock the shelves in the
defined area. In an effort to obtain more data about the process, a Six Sigma team observes
employees actually performing job functions in real time at various times of day for two
weeks. Some notes that come from those observations include:
 Stocking in the evening takes only minutes.

 Stocking during the day is hampered by the movements of customers.
95
What is a Process?
 Stocking work performed during peak shopping hours usually takes the longest.
With just this information, you can probably see an easy way to reduce stocking time in this
example: move stocking duties to non-peak times when possible. Simply understanding the
steps to stock the area is not enough to understand the process; you also have to gather
data about process times.
Almost any process in a business will be dependent upon one or more other processes.
Remember, the business itself is a series of linked processes all working toward the same
goal or goals. Sometimes, interdependencies are noted on processes maps. Other times,
interdependencies are resource-related.
For example, consider a very simple passenger train scenario. The train leaves station A with
passengers, carrying them to station B. Before the train can leave, the engineer must be on
board and prepared to operate the machine. Safety checks, clearance from the rail yard, the
closing of all the doors: these are all processes that must be completed before the train
leaves the station. The process of the train transporting passengers is dependent upon the
completion of other processes.
When working with processes during a Six Sigma improvement project, teams must be
aware of interdependencies. What does any process you are working on rely? What relies
on your process? The first is important because you might need help from processes or
people upstream from your process when making improvements. The second is important
because you have to know how your improvements will impact downstream processes and
people – and improvement in the performance of your process doesn’t do any good for the
company or organization as a whole if it hinders the performance of a downstream process.
Processes require resources. Like a motor vehicle requires fuel or electricity to run, a
process requires resources such as power, people, cash, digital bandwidth, computer
equipment, machinery, supplies, parts, and even skill. Since someone in an organization has
96
to approve and pay for resources, project teams must understand the resources involved,
the cost of those resources, and the owners of the processes and resources in question so
they can make appropriate requests about needing additional resources.
Processes are made up of components that include inputs, outputs, events, tasks
(activities), and decisions. Inputs enter the process when a specific event occurs; tasks and
decisions are performed upon or with the inputs. At the end of the process, an output is
generated. Most of the time, the idea of process components is introduced with a simple
factory-based illustration: raw goods of some type enter the factory, work is performed,
and finished goods leave the factory. For example, if a factory makes hard candy, things
such as sugar, water, plastic, and electrical power enter the factory. Equipment and
employees take the inputs and work with them. The end result is a wrapped piece of candy
ready for the store.
The figure below illustrates the idea of process components using a pizza shop example. An
event – the ordering of a certain pizza – begins the process. You can see all of the
components in the diagram, and we’ll talk about each component in detail in the section
that follows.
97
What is a Process?
Figure 1 Medium Cheese Pizza Process
98
Input refers to anything that enters a process or is required to enter a process to drive the
creation of an output. In the pizza example above, the inputs are all the ingredients needed
to make the pizza. You might also consider factors such as oven temperature, type of oven,
and the cook’s skill level to be inputs in the process.
Understanding all inputs to a process is important in Six Sigma because inputs are often
causal – or related to causal – factors regarding a process. Inputs or the results of those
inputs can cause errors or defects in the process. The cookies burn when the oven is too
hot. The computers made in a factory don’t function when the circuit boards are bad. A
lawyer doesn’t win his case if his or her information is wrong. The oven temperature, the
circuit boards, and the lawyer’s information: these are all inputs into processes that are also
causing problems within the processes.
Other reasons for defining inputs when working with a process include:
 Understanding the resources required for a process to run

 Identifying extraneous inputs that aren’t required
 Understanding costs for the process
 Understanding how the process relates to processes that come before it
Remember, in a business, processes are linked together to accomplish a final goal or goals.
The inputs entering process B might be the outputs leaving process A.
The output of a process is the service or product that is used by the customer of the
process. In the pizza example, the output is the cheese pizza the customer is going to eat. In
the candy factory example, the output is the hard candy that will be sold by the retail store.
The process customer is not always the traditional end customer who purchases a product
or service. Customers can be internal or external. An example of a process serving an
internal customer might be seen in a business office that employees a receptionist to
answer phone calls. If the receptionist takes messages or transfers phone calls, he or she is
serving both the person on the phone and the person who is receiving the call or message.
In some cases, the customer of a process is not even a person. Many processes feed other
processes. In a pharmacy, the process of entering data about a prescription feeds the
process that bills an insurance company for the medication.
99
What is a Process?
From a Six Sigma perspective, an output is almost always of more value to the ultimate
process than the input is. The process itself involves adding value of some kind to the
inputs. A bakery puts raw bread dough through the oven to add value to it: the result is an
edible and tasty product that a consumer is more likely to purchase or to pay more for.
Events are specific, predefined criteria or actions that cause a process to begin working. A
process that performs well responds to an event just like a light bulb responds to the action
of a switch being pulled. Six Sigma teams must determine what events trigger a process
because it helps them understand why a process is being performed and whether the
process is being run when it isn’t needed.
Consider an example about compliance audits in a financial sector company. Perhaps a

company created a specific audit process that initiates when red flags on accounts are
raised; the audit process is comprehensive and usually takes an average of 80 labor hours.
You can imagine that it is an expensive process to run. In investigating, a Six Sigma team
identifies the event associated with the process: anytime a discrepancy in an account is
noted by a clerk, the compliance process is triggered.
The team investigates and realizes that this is true even when the discrepancy was minor –
a few dollars or less – or the clerk was able to reconcile the discrepancy later in the day. The
team might suggest that the relationship between the process and the event is a problem.
The process is running at times when it might not be valuable for it to do so.
Tasks, or activities, are the heart of a process. Just as the heart pumps blood through your
body, the tasks within a process pump the inputs through, turning them into the outputs.
Tasks are the physical, automated, or computerized actions within a process. Examples of
tasks include:
 A machine joining two metal parts with a weld

 A person entering data into a software program
 A computer processing data to create a report
 An email being written
 A piece of computerized work being routed within a workflow system
 A chef chopping ingredients for a recipe
100
Decisions are closely related to tasks and can be tasks themselves. A chef preparing
ingredients for a soup dish has to chop those ingredients, but he also has to decide how
much of each ingredient he needs. His decision will likely be guided by the recipe and the
number of people he has to feed.
Decisions within a process are typically governed by a set of rules. Sometimes those rules
are formally documented; other times, decisions are made via informal rules along with
staff knowledge and experience. Processes that are governed by informal rules can have
problems of consistency; even when all staff are experienced, they could have individual
variations on performing a task. And, as we discussed in Unit 1, variation can lead to more
opportunities for defects and a reduction in quality.
Using the task examples above, here are examples of decisions in a process:
 A person entering data into a software program makes a decision to select a certain
drop down category because of training or rules provided by the software
 A computer processes a report; the result of that report is a number above a set
threshold, so the computer sends the report to a person
 When writing an email, a person chooses to include certain specific information,
such as an order number or customer number, because it is protocol to do so when
sending this type of email
You’re probably noticing that processes can be extremely complex, and the relationships
between all the components are equally complex. Inputs can be outputs from previous
processes; outputs can be inputs in the next process. A decision might result in an event
that starts a new process, but it can also be the factor that decides which task begins. As Six
Sigma teams work with processes – observing them, diagramming them, and measuring
them – the teams begin to understand the relationships of the components, and that helps
them make decisions about possible improvements and changes.
As teams work to improve processes, they need to understand who the process owners are.
Depending on the business organization, process owners can be the people with the power
to approve changes. In some organizations, the lowest-level owner might not have veto or
101
What is a Process?
decision power about all changes, but he or she is held responsible for the performance of
the process.
A process owner can be:
 A person in charge of a very specific process or function

 A team supervisor or department manager
 An executive-level individual who is probably responsible for a number of
processes in his or her division
The responsibilities of a process owner are often defined by the infrastructure of a specific
business, but commonly, a process owner will:
 Monitor how the process performs, usually using one or more metrics or regularly
reported data elements.
 Understand how the process fits into the overall business, why the output of the
process is critical to business goals, and what inputs feed the process.
 Ensures the process is documented via standard operating procedures (SOPs) and
that process documentation is kept current and accurate.
 Ensures operators within the process have the resources and training they need to
complete their jobs.
In a Six Sigma environment, process owners might also ensure a control plan is in place and
regularly review the process for possible improvement opportunities.
Finally, all processes generate some form of data. Even if data isn’t yet being captured,
information is inherent in any process. A computer program that automatically routes work
in a workflow might generate data such as the number of items in work queues, how many
items were worked that day, the time items have been waiting in queues, how many items
were transferred, and where those items were transferred to. A process for filling bottles
with liquid might generate data such as how much liquid is placed in each bottle, how many
bottles per hour are filled, and perhaps variation between bottles.
Data is extremely valuable to Six Sigma teams because it’s often how they define whether a
process is in control and successful.
102
The SIPOC diagram is often an important part of the define stage of a Six Sigma project. But
you can use the SIPOC diagram anytime you want to learn more about a process or
understand how a process in a business environment is linked to other processes.
SIPOC stands for Suppliers, Inputs, Process, Outputs, and Customer. For the purposes of a
SIPOC, inputs and outputs follow the same guidelines described previously in this chapter.
Suppliers are the people, processes, and organizations that supply inputs to your process.
Customers are the people, processes, and organizations that make use of the outputs of
your process. The process itself is the series of steps that take the inputs and make them
outputs.
SME: Subject Matter Expert

The SIPOC diagram is one of the most often used tools
An SME is someone who is
for understanding process components and process
closely associated with or
relevance because it is so effective and simple. Teams
familiar with a process or work
can create SIPOC diagrams in a single brainstorming
function. Six Sigma teams invite
session, though effective diagramming usually
SMEs to participate in
requires the presence of a process owner and one or
discussion, process mapping
more SMEs who are familiar with the process on a
sessions, or problem and
daily level.
solution brainstorming, because
SIPOC diagrams are also infinitely scalable. Teams can SMEs have valuable insight that
diagram processes at a very minute level, but they can might not be provided by high-
also use SIPOC to diagram an entire business. We’ll level process owners or a review
walk through creating a SIPOC diagram and then of the data.
provide some examples of SIPOCs at various levels to
illustrate scalability.
You can create a SIPOC diagram as an individual exercise or within a team environment.
SIPOCs can be created using a computer and software tool such as Word or Excel, but you
can also draw them freehand on a whiteboard or piece of paper. Freehand diagramming is a
valuable brainstorming tool because teams can quickly edit the rough draft of the diagram
as they discuss a process. Keep this in mind :many of the diagrams presented in this book
103
What is a Process?
look clean because they have already been typed and edited. As you diagram your own
processes, they can tend to look messy at first with edits, arrows, scratch outs, and inserts.
“Editing” or putting rules on the brainstorming process can limit the ideas and information
that flow during the process. You can always create a clean copy of the diagram for
presentation purposes when you are finished brainstorming.
A SIPOC diagram is based on swim lanes. Swim lanes let you show how cross-functional
activities and resources relate to your process. A SIPOC diagram gets five lanes: one each for
Suppliers, Inputs, Process, Outputs, and Customers. You’ll end up with something that looks
like the figure below.
Suppliers Inputs Process Outputs Customers
Before beginning a SIPOC session, set a definition for where your process or responsibility
begins and ends. If you don’t understand the scope of your process, then your SIPOC
session can get out of hand or produce a diagram that isn’t useful for your project.
Naming your process helps the team identify more readily with a specific aspect of the
business. For example, a team working to improve processes within a medical office might
look at a process named “Gathering New Patient Information.” By naming the process, the
team has put some scope limitations in place: the team will talk about things related to
gathering information from patients. The scope is further limited to the process by which
staff gathers information from new patients.
As you work through the SIPOC diagramming exercise, you can point back to the name and
the scope you’ve defined to keep the team on task with the discussion.
104
You can complete SIPOC swim lanes in any order, but best practices usually have teams
enter data in the following order:
 Process
 Outputs
 Customer
 Inputs
 Suppliers
Realistically, teams will think of things as they work through the process, so you’ll be
returning to swim lanes repeatedly to move information around and add new information.
A SIPOC isn’t usually a low-level or detailed map of the actual process, so keep teams high-
level when completing the process swim lane. You can simply enter the name of the process
in that section, or you can list some of the high level steps required for the process. Listing
steps is a good exercise if teams aren’t sure about outputs and inputs – beginning to
visualize the process usually helps ideas flow about how the process is connected to other
processes and resources in the company.
To keep the session from turning into a detailed process mapping activity, ask the team to
describe the process in less than five to seven steps. Keep things simple by limiting process
steps to short verb-noun combos such as “Enter information,” “Collect money,” or “Place
labels.”
Once you have a rudimentary process definition, begin with either inputs or outputs. Ask
the team “What does this process make? What comes out of this process?” Those answers
go into the outputs swim lane.
Next, ask the team “Who or what uses the things that come from this process?” Place those
answers in the customer swim lane. Remember that customers can be external or internal,
and another process can be the customer in cases of automation.
Ask the team “What does the process need to perform? What raw goods or materials feed
the process?” Record those answers in the inputs section.
105
What is a Process?
You can divide the idea of inputs into two types, if you like. First, you have the actual inputs
– the goods and services that are transformed by the process to create the outputs. Second,
you have enablers of the process. These aren’t technically inputs because they don’t enter
the process and aren’t changed by the process; instead, they are required for the process to
function. Machinery is an enabler. In a process that cuts metal parts from a steel sheet, the
machine that does the cutting is an enabler. While it’s not required, separating enablers on
your SIPOC helps you define the process and provides additional information for later in the
project.
Once you have a list of inputs, ask the team, “Where do the inputs come from? Who or
what supplies the process with these things?” As with customers, suppliers can be external
or internal. A vendor might provide the raw sugar that goes into the candy in a factory; the
marketing department might provide the leads that the sales department uses to create
orders.
Suppliers can also be other processes, particularly in an automated environment, and you
can have a list of several suppliers for one input in a raw SIPOC diagram. For example,
support tickets come into the Information Technology (IT) department. The supplier of the
ticket could be both the end-user submitting the ticket and the automated process that
routes the ticket to the appropriate work queue. If you are documenting enablers, you
might record the end-user as the supplier and the automated process as the enabler.
Ensure that your understanding of the process at this high level is accurate by validating
your diagram. If you’ve put together a comprehensive team that includes SMEs, the team
can validate most of the information on its own. It’s always a good idea to get a second
opinion on anything the team isn’t sure about, though. Invite other SMEs or the process
owner to review the diagram briefly with the team and provide feedback.
One of the best ways to create an initial SIPOC diagram during a team session is on large
pieces of paper or a whiteboard. Create swim lanes by drawing them on the whiteboard or
hanging a piece of paper for each swim lane on the wall. Provide the team with sticky notes
and markers; write on sticky notes instead of writing directly on the board or paper. This
lets you move components around quickly as you work through the diagram.
106
Here are some sample SIPOC diagrams. The first diagram is at the highest level: the process
is the business itself. The second diagram features an automated process. The third diagram
illustrates a people-powered factory process and includes enablers.
This diagram shows the SIPOC for a mid-sized printing company. It’s a very high-level,
simplified SIPOC that shows how customers and vendors provide information and items; the
printing company then turns those inputs into products such as printed business cards. The
final product goes to individuals, businesses, and marketing professionals who placed the
order.
Paper Orders/customer Receive Business Individuals

vendor specifications order cards
Business
Ink vendor Paper Layout Brochures owners
designs
Copy and Ink Banners Marketing

print Print and signs departments
machine designs
provider Designs
Mailers
Deliver
Customer printed
product Letterhead
107
What is a Process?
Most of the time, a Six Sigma team won’t deal with a business-level SIPOC diagram.
However, if the team includes members from outside the division or company, such as
vendors or consultants assisting with an improvement, then starting with a high-level
diagram can help those outside of the business understand the overall goals of the
company.
The diagram below represents an automated process in a mail-order pharmacy. The process
in question puts labels on bottles that are to be filled with corresponding medications. The
scope of the process is only the labeling of the bottles.
Bottle sorting Unlabeled Choose Labeled Bottle-filling

machine bottles bottle size bottle station
Label machine Data for Print label

labels
Prescription Affix label

software Labels
Ink and label Ink for

vendors printing
Because this is a process within a chain of automated processes, almost all of the
components are machines, processes, and things. Prior to labeling, a machine sorts bottles
by size. That machine feeds the labeling station as needed. After the labeling is done,
another station fills the bottles.
108
The SIPOC diagram below illustrates how enablers might be recorded for your process. The
process in question takes place in a factory that makes furniture; in this process, a person
attaches legs to a barstool on an assembly line. For the purposes of this illustration, leg
attachment is the last step in the completion of the product, which means the product
moves from the leg attachment station to packing and shipping.
Upholstery Stool top Align legs Barstool Packing

station with legs station
(provides final attached
top of stool) Legs Attach legs
with screws
Warehouse Screws
(provides legs, Place
screws, and protective
protective Protective cover
cover) cover
Enablers:
Conveyor machine that

moves products
Drill for application of screws
Without the conveyor machine, the people in involved in this process would have to move
items manually. The conveyor isn’t 100 percent required for legs to be added to the stool,
109
What is a Process?
but it enables the process to move at a more efficient pace. A case could be made that the
drill isn’t required either – screws can be installed manually – but it’s certainly what enables
the process to move at a speed required for mass production.
With just this simple SIPOC diagram of a process, a Six Sigma team would already have
some idea about where variation could be hiding, what drives efficiencies in the process,
and how the process relates to the overall business.
Whether working in a team or on your own, choose a process you know about and practice
creating your own diagram. Pick a process associated with your business or a business
example you have experience with. Use the following templates to get started.
110
Enablers:
111
What is a Process?
112
One of the most concise definitions of quality comes from the International Organization for
Standardization, or ISO. ISO 9000 defines quality as the “degree to which a set of inherent
characteristics fulfills requirements.”7
The same document defines requirements as expectations or needs that are implied,
obligatory, or stated, and the ISO notes that requirements can be generated by different
interest points. A Six Sigma team should be interested in requirements generated by all
interest points, but often focuses most on those generated by the customer. Various types
of requirements might include:
 Customer expectations, which are typically stated or implied values. It’s implied
that a customer wants the product he or she ordered. Expectations of delivery
speed might be stated in the form of feedback in customer surveys.
 Compliance or regulatory rules, which are obligatory. For example, banks must
protect credit card information—they are obligated by rules from government and
the industry’s Payment Card Information Data Security Standards (PCI-DSS).
Similarly, healthcare organizations must protect the confidentiality and security of
patient data; they are obligated to do so under the Health Insurance Portability and
Accountability Act (HIPAA).
 Brand expectations, which come from in-house leadership. Brand expectations are
typically stated; while not obligatory in the sense of being backed by regulation,
companies for which high-quality, a specific voice, or other unique factor is a
component of branding might treat brand expectations as obligatory. Coca-Cola,
for example, has a brand that is recognizable around the globe. While components
of that brand, such as the design of logos or soda cans, aren’t mandated by
regulations and might not be required by customers, Coca-Cola itself holds these
components as important and puts resources and effort into them because it
values its brand.
7
https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:en:term:3.9.11
113
QUALITY
In this chapter, we’ll take a look specifically at quality factors critical to processes and
process improvement as well as costs associated with quality in general.
Critical to quality characteristics, or CTQs, are the factors or parameters that are the major
drivers of quality within an organization or process. Usually, CTQs are key characteristics
that can be measured; where the performance of said metric provides information about
whether or not the customer is going to be satisfied.
CTQs are closely related to CTCs, or critical to customer characteristics, but they are not the
same thing. Something can be critical to quality – even critical to how a customer ultimately
feels about a service or product – without being critical to the customer directly. CTQs are
internal concerns, but they drive CTCs.
Let’s look at some examples of CTQs and CTCs to understand the difference and the
relationship between these two factors.
When a customer purchases a pair of pants, he or she is usually concerned with how the
pants fit and look. Are they comfortable, is the size correct, and does the clothing match the
customer’s personal style?
It’s hard to create a measurement for whether pants are comfortable, but a manufacturer
can take customer feedback on various types of pants and learn that a certain fabric with a
certain cut is most comfortable for the target audience. The manufacturer can also
determine appropriate measurements for each size. During the manufacturing process,
these critical-to-quality factors are applied: only fabric that meets the specifications
identified is used. The fabric is then cut to specific measurements and sewn together in a
specific manner – measurements and sewing methods are critical to quality.
The average customer, however, doesn’t want to hear about the exact measurements of
each fabric piece or the way the seams were sewn. They want to put on a pair of pants and
experience a comfortable fit.
A chocolate company conducts a survey to find out why sales of its newest product haven’t
performed as expected. The feedback suggests that the chocolate is too sweet – the taste
and the sweetness of the chocolate is a critical to customer characteristic.
114
The company might tweak its formula, reducing the amount of sugar that goes into the
chocolate. The recipe – and the amount of sugar -- is a critical to quality factor in this case.
But what if the customer feedback indicated that health-conscious consumers simply didn’t
want to buy a chocolate bar with so much sugar in it? Then the amount of sugar in the
recipe becomes both a CTQ and a CTC. It is critical to the quality of the taste of the bar, but
customers might also look at the nutritional information on the bar and make purchasing
decisions based on the amount of sugar in the chocolate.
If a business wants to launch a mobile app for its customers, then an obvious customer-
centric need is that the app works on the customer’s phone. The customer doesn’t care
about the process the business needs to go through to launch the app on the platform in
question, but the business must meet the criteria for Apple, Android, Windows, or other
mobile operating systems. Those requirements become some of the CTQs for the mobile
app development, even though certain requirements from the platforms might not appear
to be at all related to statements from customers about desires or needs.
In a process improvement environment, CTQs are critical to narrowing work scope and
understanding how to enact change. Consider the 80/20 rule discussed in Chapter 5. Often,
CTQs are the factors, characteristics, or outputs that drive 80 percent of customer
satisfaction. By improving these few critical factors, teams can substantially impact
customer satisfaction and the performance of the overall process. Identifying CTQs lets
teams create the most improvement possible with the time, money, and people resources
available.
Outside of a project environment, understanding CTQs lets organizations stay on top of

quality. By managing a few critical metrics, teams can ensure excellent output in a
continuous fashion and identify potential areas for improvement before they become
customer-facing problems.
In Chapter 5, we introduced the concept of the Voice of the Customer, or VoC. Six Sigma
teams usually start with some type of VoC data when they are defining a problem and
working on goals for a project. Either the team conducts surveys to hear from a statistically
115
QUALITY
relevant group of customers during the first few phases of a project, or the team receives
feedback from internal customers about a process. Sometimes, the VoC information a team
begins with is something as simple as a champion or executive-level individual making a
statement about expectations for an internal process or project. When VoC data is limited
in such a fashion, teams might have to work harder to validate assumptions with data
before moving on to CTQ analysis.
To gain a better understanding of how to measure the quality of a process, teams must
convert VoC statements to CTQs. One of the best ways to do this is through a diagramming
process known as a CTQ tree.
A CTQ tree begins with specific and critical customer needs, breaks that need down into
drivers, and uses the drivers to create requirements. Specific requirements are easier to
convert to measurable quality components. While each CTQ tree is unique, they begin with
a common form. The common structure of a CTQ tree is shown below.
When creating a CTQ tree, you don’t have to follow an equal pattern for drivers and
requirements. Some customer needs will have more drivers than others; some drivers will
have more requirements. You might also have multiple CTQ trees – you’ll want to create
one for every need you identify that is critical to a customer.
116
Begin the CTQ tree process by creating a list of needs that are critical to the customer. A
bank working on processes dealing with online checking access might identify accessibility,
user-friendly interfaces, and security of information as the major critical-to-customer needs,
for example. Define needs in broad terms to help catch all drivers and requirements later in
the diagramming process.
The best way to define needs is to directly ask customers for feedback, but time and
resources don’t always allow for surveys. Six Sigma teams might be able to take advantage
of data collected via recent surveys or feedback forms, which is the next-best thing. In the
absence of customer feedback, brainstorm critical needs with a group of employees who
has knowledge of and experience with the customer. Subject matter experts from sales,
customer service, and complaint departments can often provide viable information when
the customer is the end-user. You can also begin a CTQ tree with the outputs of your SIPOC
diagram; depending on how you structured the outputs on a SIPOC, you might need to
define critical quality factors for the output as a starting point for your CTQ tree diagram.
Once you have a list of critical needs, work with one need at a time to create a tree similar
to the diagram above. Identify quality drivers that must be present or met for the customer
need to be fulfilled. For example, customers of an HVAC service company might require
excellent service. Drivers for that need might include friendly service technicians, helpful
and knowledgeable employees, and a timely response to service calls.
Drivers are the transition point between customer needs and requirements; you don’t
necessarily have to be able to measure drivers, but you want them to be a bit more detailed
than the broad customer needs you already identified and you want to be flowing in the
direction of measureable factors when possible.
Requirements are the most detailed breakdown regarding critical to quality characteristics.
These are the things that you can measure that lead you to understand whether drivers are
performing appropriately so customer needs are met.
For example, let’s look at our HVAC example in a CTQ tree format.
117
QUALITY
You can see in the above CTQ tree that drivers have been converted to requirements – and
each of those requirements can be measured with numbers. In some cases, driver-to-
requirement conversions equate to a hard number. The chocolate bar example at the
beginning of this chapter features such a scenario: if the company deems that the recipe
with a quarter cup of sugar is the correct recipe, then the process metric for quality is
exactly a quarter cup of sugar.
In other examples, companies might provide leeway for exceptions or the understanding
that a process is not going to hit an exact number every single time. For example, an HVAC
team cannot possibly arrive at a customer’s home exactly 24 hours after a phone call is
made – and if the service technicians can arrive earlier than 24 hours, most people would
want them to. That means the company has to create a definition for the requirement: how
many hours is it before a customer considers a technician untimely? In the case of our
example company, it’s 48 hours. The requirement in another situation might be 24 hours.
Because teams will use the requirements from the CTQ trees to develop process
measurements and metrics for success, it is extremely important that each requirement is
vetted before teams incorporate it into the project or process. Requirements should be
compared to VoC data, to existing measurements, and to experience and knowledge from
subject matter experts and leaders. The team should ask themselves and others “If these
118
requirements are met, will the customer be satisfied?” If the answer is ever no, then the
requirements need work. The team might also consider asking “Are these requirements
possible in the real world.” If the answer is no, then either the process or the requirements
needs work.
Six Sigma teams must always be aware that quality comes at a cost. When talking about
quality costs, many organizations consider what is known as the cost of poor quality, or
CoPQ. The cost of poor quality is defined as the costs or expenses associated with defects
created by a process. Quality actually has a broader cost – avoiding poor quality comes at
an expense as well. The cost of quality, or CoQ, covers the expenses associated with
maintaining good quality throughout an organization or process. Sometimes, this is referred
to as the cost of good quality. In this section, we’ll talk about both types of cost
measurements, how they relate to Six Sigma in general, and how they relate to Six Sigma
teams and projects.
In some ways, the cost of poor quality is easier to measure than the cost associated with
overall quality. CoPQ is usually broken into two major categories: costs associated with
external failures and costs associated with internal failures. External and internal failures
are often referred to as the costs of nonconformity – they are the expenses that occur when
outputs do not conform to critical to quality requirements.
External failures usually occur after products or services have been delivered, which means
they are directly associated with customer dissatisfaction. External failures might include
revenue losses associated with a reduction in sales because of the quality of products,
services, systems, or information. Other types of external losses include expenses
associated with repairs, returns, or rework associated with a customer complaint; expenses
associated with warranties; or loss of revenue or sales because of customer ill will or bad
word-of-mouth.
Internal failures occur when products, services, or processes don’t conform to the
requirements set by the company, and the product or service is provided to the customer in
an unsatisfactory fashion. Internal failures are usually handled by scrapping the work,
119
QUALITY
redoing the work, or repairing the work. Obviously, such rework results in added material
and labor costs, but it also results in losses associated with delays, shortages of parts or
inventory, and lack of flexibility or the ability to adapt. For example, if a process has such
poor quality that 50 percent of the items produced by it require rework, then the process
might be producing 40 percent less on a daily basis than it could be. That means the process
can serve fewer customers, generate less output, and contribute less overall to the
company’s profit.
Understanding the cost of poor quality is critical to Six Sigma organizations because it lets
leaders understand how financial needs are related to the need for quality improvements.
The higher the cost of poor quality, the more likely an organization will work toward
improvement.
At a project or process level, the cost of poor quality might help determine budgets for
improvement. If poor quality within the process is costing an organization $5,000 a month,
a project that costs $20,000 but saves $3,000 a month in quality would pay for itself in just
seven months. On the other end, a project that costs $100,000 when the costs of poor
quality are only $1,000 a month is less likely to make sense.
The equation for CoPQ is:
CoPQ = External Failure Costs + Internal Failure Costs

While the equation seems simple, identifying all of the costs associated with poor quality
can be difficult. Most experts use the metaphor of an iceberg to explain the hidden costs of
poor quality. On the surface, you see the very small tip of the iceberg—the obvious costs of
poor quality. These might be things such as scrap, reprocessing, warranty claims, customer
returns, and extra shipping.
Beneath the surface, however, an iceberg is always much bigger. The same is usually true of
the cost of poor quality, and hidden costs might include:
 Loss of customer loyalty

 Loss of morale
 Loss of employees if morale remains low for extended periods
 Conflicts associated with scheduling or rescheduling
 Higher risks of compliance issues, including fines
 Higher administrative costs
120
 Unpredictable revenue, sales, or production
Calculating the cost of poor quality is extremely difficult on an enterprise-wide level and still
moderately difficult on a process level. A method for listing all possible costs and
formulizing them to dollar amounts doesn’t exist. It’s a good idea for organizations to
develop a streamlined method that is used throughout the enterprise when calculating
CoPQ. At the very least, Six Sigma experts in the organization might consider defining a
specific way of listing costs of poor quality company-wide so that various process teams are
using similar measures when they report to leadership.
The cost of quality, or CoQ, includes the cost of poor quality and the cost of good quality. In
addition to internal and external failure costs, CoQ includes prevention and appraisal costs.
Prevention and appraisal costs are often referred to as the costs of conformity – they are
the expenses related to ensuring outputs conform to critical to quality requirements.
The costs of prevention are the expenses that are related to any activity meant to stop an
error or defect from occurring. Error-proofing, which is covered in detail in later chapters on
controlling processes, results in prevention costs. For example, if a company produces
baked goods, at some point in the process people or machines must measure ingredients to
add to dough batches. One way to error-proof such a process is to provide specialized
machinery that will only allow a specific amount of each ingredient to be introduced to a
batch. Such a machine would likely be quite expensive; it would also have to be managed by
a qualified operator and maintained by appropriate repair and cleaning staff. All of that
activity would generate costs which might be considered preventative in nature.
Other types of prevention costs include expenses related to quality planning, reviews, or
education and training focused on quality. Quality review and evaluation processes also
create prevention costs, whether those reviews are related to suppliers, products,
processes, or people. Customer surveys, the creation of technical manuals, work to create
and manage requirements and specifications, and the management of job descriptions can
all lead to prevention costs. Even housekeeping costs might be considered preventative
costs, especially if a clean work environment is required to reduce flaws or errors in product
manufacturing.
121
QUALITY
Appraisal costs are those associated with any activity meant to ensure high levels of quality
across a process or organization. If a manufacturing plant hires a quality control specialist,
and that person’s job is to review parts that come down the manufacturing line and either
return the work for correction or report the level of quality as a metric, then the salary of
that person and any expenses related to his or her employment are appraisal costs. In some
cases, those expenses might also be considered prevention costs, but they would not be
counted twice when calculating CoQ.
Other types of appraisal costs might include expenses related to quality audits on products,
services, or processes, the cost of calibration and measurement equipment or software, and
the costs of field tests. Prototype inspections, consulting expenses, financial reporting and
auditing, security checks, safety checks, supplier certifications, employee surveys, and
customer feedback are all further examples of areas where appraisal costs might exist.
The equation for CoQ is:
CoQ = CoPQ + Prevention Costs + Appraisal Costs

The same challenges inherent in calculating CoPQ also exist when calculating CoQ. The
same iceberg analogy is relevant, and prevention and appraisal activities often have hidden
costs such as unnecessary overtime, paperwork, or system expenses.
Traditional wisdom might say that if the cost of poor quality goes down, the cost of good
quality is likely to go up. You have to spend money on quality to have good quality, in other
words. While historically that might be true for many organizations, it is not the case in a Six
Sigma company. Because Six Sigma works to create quality that is inherent in the process –
meaning things are done right the first time and defects are reduced – the costs of quality
often go down while quality itself goes up.
In Chapter 1, we showed that a process with a higher sigma level (and thus, higher quality)
has fewer defects. Defects decrease in an exponential manner as sigma level rises. Because
there are fewer defects, the costs of poor quality are exponentially reduced as well. But
time and again, Six Sigma has also reduced the cost of overall quality. As the sigma level of
processes is increased via the application of Six Sigma tools and methodology, the cost of
both prevention and appraisal goes down as well.
122
One way of relating the cost of quality – and perhaps the most common way of doing so
among corporations – is as a percent of sales. The cost of quality as a percent of sales
typically aligns so closely with sigma values that you can predict the cost of quality based on
a company’s or process’s sigma value. The average ranges for CoQ in relation to sigma
values are shown in the table below. As you can see, as companies improve their sigma
levels, they experience a substantial savings in the cost of quality.
Sigma level Cost of Quality as a Percent of Sales
2 Above 40%
3 25 to 40 %
4 15 to 25%
5 5 to 15%
6 Less than 1%
Six Sigma is one of the best methodologies for managing the cost of quality because it
works to build quality into every process. When approaching an organization or process that
has a high cost of quality, teams and leadership can apply a triage-based method to reduce
those costs. While no organization can remove quality costs 100 percent, the goal should be
zero costs of failure, either internal or external, and minimal preventative and appraisal
costs.
First, teams should concentrate on costs associated with failures. It’s often easier and less
expensive to detect costs associated with nonconformance, and improvements that seek to
correct causes for a few critical failures can have a big impact on overall quality and total
cost. Instead of adding layers of quality programs over processes to ensure quality – which
only adds prevention or appraisal activities and increases the cost of quality – Six Sigma
improvement projects build preventative measures into processes themselves. In other
words, efficient Six Sigma processes are self-regulating. They have built in checks and
balances that work to constantly reduce defects and rework.
The benefit of building failure stop-points into a process include:
123
QUALITY
 Earlier detection when errors do occur, which keeps hidden costs down. When
the error can’t make it to the next process or to the customer, you avoid many
issues and costs associated with low morale, reduced customer loyalty, or
product returns.
 Employees are able to support and manage higher quality. When quality is
something employees have ownership of, they are more likely to work hard to
create the best possible output. In contrast, appraisal-style quality programs
can spark feelings of paranoia at being closely watched or create a relationship
in employee minds between the idea of quality and the idea of reprisal or
correction. Poor performance on a continuous basis does need to be addressed,
but employees should not default to a negative mindset when they hear the
word quality.
 In-process quality assurance is actually more effective than post-process or
over-process prevention and appraisal methods. Statistical process control and
Six Sigma improvements can push a process to six sigma level. To ensure the
same level of performance – 3.4 defects per million opportunities – quality
assurance employees would need to review millions of parts and ensure only a
very tiny few had defects. It’s simply not an economical option for most, if any,
organization.
After teams use the Six Sigma and Lean process management methods discussed
throughout this book to reduce failure costs, teams can turn to prevention and appraisal
costs. Often, in a process that is functioning at a high sigma level, prevention and appraisal
activities are a form of muda. They can be expunged from the process without impacting
the end product, quality, customer satisfaction, or employee morale. In some cases,
removing prevention or appraisal from processes actually creates a positive impact on
quality, production, and customer and employee satisfaction.
The first step to removing quality-related muda is identifying it. Process maps, spaghetti
diagrams, and value stream maps are valuable tools for uncovering activities that don’t
need to be included in a process. All of these tools are covered in depth in Unit 9.
Whether you’re mapping a process or simply discussing various components with process
owners or a Six Sigma team, asking questions about value and necessity can also help
identify muda of prevention and appraisal. If you think an activity related to a process might
be an unnecessary form of prevention or appraisal, ask:
124
 Does the activity itself add any value to the output?

 Does the activity substantially reduce the time it takes for the process to
produce an output?
 Does the activity substantially increase the cost of the process?
 If the activity is designed to prevent defects within the process, can the activity
be made more efficient?
 If the activity is designed to prevent defects, can the activity be made less
expensive?
 If an activity is designed to capture quality data about the process for reporting
purposes, are those reports necessary?
 If quality reports are necessary– either because of obligatory requirements such
as compliance or because the reports provide value in another process – can
the reports be automated to reduce associated expense?
The answers to these questions help teams identify areas where muda can be removed or
where quality-related processes can be improved.
When Six Sigma teams are expunging quality-related costs and unnecessary activities from
processes, it is critical that they don’t actually remove quality. While it’s true that traditional
quality programs and costs don’t have to be present to ensure a reduction in defects and an
improvement in customer satisfaction, it’s equally true that you have to replace those
programs with some other form of control. By the end of this book, you will have learned
about a number of tools, from statistical process control to poka yokes, which you can use
to create quality within a process.
It’s also worth noting that a single Six Sigma team – or even an entire department devoted
to Six Sigma – can’t reduce the costs of quality in an organization on their own. Corporate
leadership must buy into the belief that quality is better when controls are incorporated
within the process, and they have to be willing to communicate this fact via training and
example. Some companies choose instead to use Six Sigma to improve processes while
maintaining the expense of traditional quality, compliance, and audit departments. For
some industries, such as healthcare or finance, audits and other appraisal and prevention
costs might be mandated by laws and regulations. Outside of that mandate, it’s almost
always best to remove any quality activity that doesn’t provide additional value.
125
Teams can bring abundant knowledge of Six Sigma to the table, but if organizations don’t
choose the right projects, improvements won’t drive effective changes for the benefit of the
bottom line and/or customer satisfaction. Since Six Sigma works best when it is
implemented as a company-wide culture, project selection should work as an enterprise-
wide function. This chapter covers a number of tools and methods for brainstorming and
selecting projects that are most likely to bring significant improvement to processes and
serve overall business goals.
A critical part of Six Sigma success for organizations is knowing when teams reach maximum
project load. Even when organizations hire employees dedicated to process improvement,
they can only sustain a certain number of improvement projects without substantially
reducing the positive outcomes of those projects. While project work, including data
gathering and analysis, might be handled by employees committed 100 percent to
improvement projects, teams usually have to engage with and pull resources from regular
staff members. An organization that juggles too many projects puts daily output at risk. In
seeking to improve processes, a company that selects too many projects at one time could
actually negatively impact quality.
No formula exists for how many Six Sigma projects a company should run at a given time,
but a few well-designed projects are more likely to make greater impact than many poorly
designed, overlapping, or unfunded projects. Organizations should only launch projects they
can:
 Fund. Six Sigma projects take monetary resources, which means organizations
must prioritize based on financial criteria.
 Support with people resources. Six Sigma projects require work from
employees at all levels. Companies shouldn’t launch three projects at one time
that draw heavily on IT resources or attempt multiple, simultaneous projects
that need input from the Director of Compliance on a regular basis. Relying too
heavily on resources for multiple projects can burn out employees, decrease
126
morale, impact quality, and impede work that is necessary to keep the business
running from day to day.
 Manage. Project teams require leadership; Six Sigma teams are usually run by
Black Belts, sometimes along with certified Project Managers. Since Black Belts
are supported by Green Belts who handle much of the data collection and
analysis work, a single Black Belt can usually manage more than one project at
a time if needed. This is especially true for experienced Black Belts who are not
responsible for any type of daily operation. Even so, organizations with limited
Six Sigma experts on staff can’t launch dozens of projects without putting a
strain on those resources.
When companies are working to apply Six Sigma culture to the entire enterprise, executive
leaders and other decision makers should work directly with Six Sigma experts to identify
improvement opportunities and launch projects. Doing so lets leadership align project
selection with organizational goals, ensure projects are organized in a way that matches
resources, and keep a bird’s eye view of improvement endeavors. Organizations can apply a
five-step procedure for identifying viable Six Sigma improvement projects.
1. Data-Based Review of Current State of the Organization
Organizations can begin with a high-level look at internal and external sources of
information about performance. Internal information might include complaints or issues
raised by employees, existing performance metrics or reports, financial reports, and quality
reports. External sources include all of the Voice of the Customer tools we covered in
Chapter 5. In reviewing internal and external information, organizations should ask:
 What types of things are customers or employees complaining about?

 Where is the organization falling short of benchmarks or competitor
performance?
 What needs do customers have that the organization is not meeting?
 What needs might customers have in the near future that the organization is
not yet able to meet?
 What processes are outputting the most defects?
 What processes are known for the most rework?
 What are the slowest or most expensive processes in the organization?
127
SELECTING THE RIGHT PROJECTS
 What are some obstacles keeping the organization from reaching its goals?
2. Brainstorm and Describe Potential Projects
Answers to the questions in step one become a brainstorming list for potential projects.
What types of things are customers complaining about? Perhaps surveys and feedback
forms show customers complaining about long shipment times, poor quality of products, or
rude customer service. With just a single question, an organization has a list of possible
projects:
 A project to reduce the time it takes for customers to receive orders

 A project to increase the quality of products
 A project to create better customer service
Admittedly, the scope is enormous with these examples, so organizations would need to
look for a bit more detail. Why do customers think the quality of products is low? In Chapter
6, we covered the 5 Whys brainstorming method, and that method is relevant here. During
the brainstorming process, organizations and teams should repeatedly ask “Why?”
questions to get a more granular look at project possibilities.
For example, if a feedback form for a carpet installation company indicates that customers
aren’t satisfied with the service they receive, the team might ask “Why are customers
dissatisfied?” Further investigation into customer feedback might indicate that the
customers are unhappy because carpet edges are coming up shortly after the carpet is
installed. Why is this happening? The short answer is that something is wrong in the
installation process. The organization might add “Improve carpet installation process” to a
list of possible projects.
Creating a list of possible projects in this manner isn’t always a matter of a single
brainstorming session. As issues are raised, more information might be required to list
possible projects, but if you gather the right group of people for a few braining storming
sessions, it’s likely someone already has that information or knows some basic answers.
Remember, the point of this exercise is to call out possible areas for improvement, not
validate assumptions or come up with solutions.
Once teams have a large list of possible projects, they should begin creating short
descriptions that will become the basis of step three. The descriptions also let teams quickly
identify things that are not actually problems or would not apply within an improvement
project environment. Descriptions should include answers to three questions:
128
 How is the issue painful to the customer, the employees, or the organization? In
short, how does the issue impede someone from getting what they want or
need?
 What is the goal that would be accomplished with an improvement?
 Why should an organization address this issue now?
If this is starting to sound familiar, it’s because the answers to these questions create
something similar to, though slightly less formal than, the problem statements discussed in
Chapter 6. Using the carpet installation example, for example, the description might be:
Customers are not satisfied with carpet installation because edges are coming up within a
few weeks of installation. The poor edges are creating safety and aesthetic issues and
increasing expense and rework for teams who have to return to sites to address defects.
The goal is to reduce the number of times carpet edges come up by 80 percent. The
organization should address the issue because it is costing $20,000 per month in errors.
Some basic idea of what the team wants to do is provided, and leadership has a very real
measurement of why the improvement is important. Even better, the measurement --
$20,000 in additional costs each month – can be compared to other project opportunities.
3. Apply Some Basic Criteria to Shorten the List
Once a list of possible projects is created, teams can apply some very basic criteria to
remove projects that are inappropriate, would not work with Six Sigma methodology, are
not property scoped, or have little likely return on investment. This step usually begins
during the second part of step two, when teams are creating short descriptions of possible
projects.
First, teams can remove items from the list where there is no real pain point. If a significant
difference between desired state and current state doesn’t exist, then there’s nothing to
improve. For example, if a single employee complaint about the efficiency of a piece of
software made it onto the initial list, a company wouldn’t pursue improvements further if it
turned out no one else was having the issue.
Second, teams can remove issues that have very obvious problems and/or solutions.
Consider the carpet installation problem: if the issue of edges cropped up in the last month
and someone on the team reviewing potential problems recently received an email about
defects in edging materials from a carpet vendor, the solution might be obvious. Perhaps
the vendor sent notification that the materials in a certain batch of carpet were faulty and
provided instructions for a solution. In this case, action is required on the part of the
129
organization, but that action isn’t a Six Sigma project. We’ll talk more in Chapter 11 about
the DMAIC process, but if a problem is already defined and a solution provided, you don’t
need to spend time going through the DMAIC phases.
4. Create Unique Business Criteria
After removing project ideas that don’t fit Six Sigma methodology, teams should create and
apply business criteria to further filter the list. Business criteria usually come in the form of
expenses, monetary gains, impact on customer satisfaction, and urgency. Some questions
teams might ask include:
 How will the improvement impact revenue-facing measurements such as profit,

orders, or income?
 What savings will the improvement create?
 How is the problem trending? Is it becoming a bigger and more urgent issue
quickly, or can the organization operate with minimal impact without making an
immediate or near-future change?
 How much will the improvement cost?
 How many employees/employee hours will be required for the improvement?
 What resources are required for the improvement?
5. Use Business Criteria to Prioritize Project Lists
Using the business criteria, teams should prioritize projects and select projects from the top
of the prioritized list for immediate work. One of the best ways to prioritize projects is to
create a selection matrix with defined criteria and a numerical ranking system.
For example, using the example questions in step four, we might create the following list of
criteria:
 Potential savings
 Potential cost
 Potential increase to revenue
 Ability to access resources needed
A matrix can be created using the criteria and a list of projects. Teams can then rate each
project against each criteria using a numeric scale. In the example below, we applied a scale
from 1 to 10, with 1 being the most negative and 10 being the most positive.
130
It’s important to note that in this example, the numbers aren’t associated with real-world
numbers. For example, when rating savings, a higher number just means a more positive
expectation. In this case, the positive expectation would be a high amount of savings. When
rating costs, however, the higher number (and more positive expectation) would relate to a
project with a lower overall cost.
Revenue Access to
Savings Costs
increase resources Total
Project
1 8 9 10
1 28
Project
5 5 4 6
2 20
Project
10 2 2 2
3 16
In the table above, you can see that Project 1 has low expected savings, but the team also
estimates it will have a low overall cost, drive a high increase in revenue, and has easy
access to resources. Project 3, on the other hand, has a high expected savings, but negative
ratings in all other categories.
To rank projects, add up the scores for all categories and order the projects from highest to
lowest by total score.
Teams can choose to create their own criteria for a project selection matrix, or they can use
a 15-point viability model as defined below. One benefit of the project viability model is
that it provides some weighting, letting teams make some criteria more important than
others. It also removes some of the objective nature of the selection matrix defined in the
previous section.
This model is based on 15 criteria, which are defined in the table below.
Criteria Definition
1. Sponsorship The project is likely to be sponsored at a high

level. (For more information on project
sponsorship, see the team building information
in Chapter 10). Sponsorship increases the chance
that teams will have access to the funds and
resources required for a successful potential
131
project.
2. Corporate alignment The goals of the project are aligned with the
goals of the business. Working on potential
projects that aren’t aligned with business goals
can reduce business effectiveness.
3. Data Data is available or can be accessed so the team

can design project metrics. Without access to
data, a Six Sigma methodology can’t be applied.
If data is excessively time-consuming or
expensive to collect, then the potential project is
usually not the best choice.
4. Definition of defect There is a specific, well-defined defect or

problem. Without a well-defined defect,
potential projects run the risk of scope creep.
5. Stability The potential process is stable and there are no

expectations that the process is going to be
overhauled, redesigned, or changed in the near
future. There is usually no reason to spend time
and money improving a process that will
drastically change soon anyway.
6. Customer The planned goal of the potential project would

create a substantial and positive impact on
customer satisfaction or perception of quality.
7. Benefits The potential project has a strong cost-benefit

ratio.
8. Timeline The timeline for a potential project is relatively

short. Timelines for most Six Sigma improvement
projects are around 6 months, though some do
run longer. Longer timelines decrease the chance
that an improvement fits within the DMAIC
methodology.
132
9. Solution The potential project purpose is to find a solution

that is not already known or defined. As we
previously stated, if a solution is obvious, you
don’t need to run a project to find it.
10. Implementation is A solution identified and verified by the potential

likely project is likely to be implemented. If, for any
reason, change is very unlikely within a process,
then going through Six Sigma improvement work
is a waste of resources.
11. Required investment The potential project requires a large investment

of cash. Generally, the greater the cash or capital
investment required, the less likely a project will
be selected or a solution will be implemented
due to cost-benefit analysis.
12. Available Six Sigma The Black and Green Belts required for the
Resources project are available.
13. Inputs can be For a Six Sigma process improvement project to

controlled be successful, at least some of the inputs must
be within control of the team or organization.
For example, a team can’t work to improve the
quality of a part that is provided wholly by a
vendor.
14. Redesign The process can be improved as is and doesn’t

need a complete redesign.
15. Process quality is The improvement doesn’t negatively impact the

improved/maintained quality of service or products along the value
chain.
133
Based on the above criteria, teams create a matrix.
Most
Most ly
Weig No ly No Possibl Yes Yes
ht (1) (2) y (3) (4) (5)
Is there a sponsor or champion?
Do project goals align with corporate goals?
Is data available or accessible?
Are defects well defined?
Is the process stable?
Are there customer benefits to the project?
Are there company benefits to the project?
Can the project be completed within 6
months?
Is the solution unknown?
Is it likely a discovered solution will be
implemented?
Would a new solution cost little to no cash?
Are Six Sigma team members available for
the project?
Can inputs in the process be controlled?
Can the process be improved without a full
redesign?
Will the improvements maintain or improve
quality across the value chain?
134
Teams then apply a numerical weight to each criterion. Weight each criterion on a scale of 1
to 5, with 1 being least important and 5 being most important. For example, our team with
the carpet installation issue might create weights as follows:
Weight
Is there a sponsor or champion? 3
Do project goals align with corporate goals? 4
Is data available or accessible? 3
Are defects well defined? 3
Is the process stable? 1
Are there customer benefits to the project? 5
Are there company benefits to the project? 5
Can the project be completed within 6 months? 3
Is the solution unknown? 4
Is it likely a discovered solution will be implemented? 3
Would a new solution cost little to no cash? 5
Are Six Sigma team members available for the project? 3
Can inputs in the process be controlled? 5
Can the process be improved without a full redesign? 2
Will the improvements maintain or improve quality across the
value chain? 5
Next, teams should answer each question by marking a 1 in the relevant box on the grid;
the answers correspond with no, mostly no, possibly, mostly yes, and yes. The complete
grid for our carpet installation problem is featured below.
135
Most
Most ly
Weig No ly No Possibl Yes Yes
ht (1) (2) y (3) (4) (5)
Is there a sponsor or champion? 3 1
Do project goals align with corporate goals? 4 1
Is data available or accessible? 3 1
Are defects well defined? 3 1
Is the process stable? 1 1
Are there customer benefits to the project? 5 1
Are there company benefits to the project? 5 1
months? 3 1
Is the solution unknown? 4 1
implemented? 3 1
Would a new solution cost little to no cash? 5 1
the project? 3 1
Can inputs in the process be controlled? 5 1
redesign?
2 1
Will the improvements maintain or improve
quality across the value chain?
5 1
Once a matrix is completed for each project, teams must calculate and compare the score
for potential projects. These calculations are completed via the following steps.
1. Divide each weight by 3; a weight of 3 equals 1, but a weight of 5 equals 5/3, or 1.7
2. Convert each of the 1s listed on your grid to a weighted value by multiplying it by the
converted weight from step one. For example, the weight for the first question on the grid
136
above is 3. We divided 3/3 to get 1. We would multiple 1 * 1 for the first row. The next row
is weighted 4; 4/3 is 1.3. The numbers have all been converted in the grid below.
Mos
Most tly
Weig No ly No Yes Yes
ht (1) (2) Possibly (3) (4) (5)
Do project goals align with corporate
goals? 4 1.3
Is the process stable? 1 0.3
Are there customer benefits to the
project? 5 1.7
Are there company benefits to the
project? 5 1.7
months? 3 1
Is the solution unknown? 4 1.3
implemented? 3 1
Would a new solution cost little to no
cash? 5 1.7
Are Six Sigma team members available
for the project? 3 1.3
Can inputs in the process be controlled? 5 1.7
Can the process be improved without a
full redesign?
2 0.4
Will the improvements maintain or
improve quality across the value chain?
5 1.7
3. Sum the numbers in each of the five columns.
137
Mos
Most tly
Weig No ly No Yes Yes
ht (1) (2) Possibly (3) (4) (5)
goals? 4 1.3
Is the process stable? 1 0.3
Are there customer benefits to the
project? 5 1.7
Are there company benefits to the
project? 5 1.7
months? 3 1
Is the solution unknown? 4 1.3
implemented? 3 1
cash? 5 1.7
Are Six Sigma team members available
for the project? 3 1.3
Can inputs in the process be controlled? 5 1.7
Can the process be improved without a
full redesign? 2 0.4
improve quality across the value chain? 5 1.7
1.3 4.4 4.7 3.3 4.4
4. Multiply each of the summed weighted scores by the number at the top of the column.
For example, the sum of the column for the “No” answers is 1.3. Multiplying that by 1
equals 1.3. The other columns are calculated as:
 2 = 8.8
 4.7 * 3 = 14.1
 3.3 * 4 = 13.2
138
 4.4 * 5 = 22
5. Add up the answers from the previous step. In this case, the total is 59.4.
6. Divide the sum from step five by the sum of the weighted totals from step three. In this
case, 59.4 / 18.1 = 3.28
7. The answer from step 6 is the score for your project.
Once you score each potential project, you can determine if it is a viable project within a
DMAIC methodology with the following key:
Score DMAIC Viability
< 2.0 Not viable for DMAIC
2.0 to 3.0 Possibility viable, but organizations

should validate further
Above 3.0 A viable DMAIC project
It should be noted that the 15-point matrix described above can only be used to determine
if a project is viable within a DMAIC structure. A process might still need to be improved
even though it doesn’t fit DMAIC methodology; in the case of a redesign, the DMADV
structure might let Six Sigma teams approach the improvement. The differences between
DMAIC and DMADV methodologies, and how to determine which method is best for a
project, are covered more in-depth in Chapter 11.
The goal of a Six Sigma team is not to define appropriate projects at an enterprise level. A
department or team responsible for only a few processes might be seeking to make an
improvement. In an organization where Six Sigma is important to business culture,
departmental leaders are likely familiar with some Six Sigma tools and might even be Green
139
Belts or Black Belts themselves. While these leaders have daily responsibilities that are not
Six Sigma related, they can bring Six Sigma thought processes to their department.
Departmental leaders might want to identify potential opportunities to present to

leadership. They might also want to identify areas where they and their teams can work
toward improvement themselves. In some organizations, department leaders can run
smaller versions of projects with the guidance of on-staff Six Sigma experts – especially
when such projects would require little in the way of capital or resources.
Departmental staff can use all of the tools in this chapter to identify possible projects.
Often, though, they are close enough to the situation that they can identify possibilities for
improvement without going through brainstorming stages. If data is already present,
departmental staff might use Pareto charts to identify some areas where improvement
would create results; they can then use the selections matrix to validate those assumptions
and prioritize efforts.
140
Consider a problem or need for improvement in your own company or one you faced in a
past work experience. Practice completing the project viability matrix using the template
below.
Weigh No Most Possibl Most Yes

t (1) ly No y (3) ly (5)
(2) Yes
(4)
Is there a sponsor or champion?
goals?
Is data available or accessible?
Are defects well defined?
Is the process stable?
Are there customer benefits to the project?
Are there company benefits to the project?
months?
Is the solution unknown?
implemented?
cash?
the project?
Can inputs in the process be controlled?
redesign?
improve quality across the value chain?
TOTAL
S:
Score:
141
Six Sigma is typically managed on two levels within an organization. First, the culture of Six
Sigma must be managed at an enterprise-wide level, usually by a group or council of senior
managers, such as executives, with the guidance of a Master Black Belt or Black Belt.
Ultimately, this group sets the tone for Six Sigma within an organization, provides final
approval on projects, and holds others accountable for metrics, performance, and success.
While many of these individuals might also work as sponsors or champions on projects, as a
group they don’t tend to get involved in the day-to-day project details.
Some roles of a high-level Six Sigma leadership group include:
 Creating a rationale for the use of Six Sigma in the organization and supporting
process improvement as a cultural goal.
 Setting clear objectives for Six Sigma initiatives to ensure that project goals
align with business goals.
 Holding Six Sigma teams and the organization accountable for improvements
and performance.
 Demanding and reviewing measurements of results
 Communicating wins and losses to the team in an honest manner.
 Rewarding teams and individuals for Six Sigma successes.
 Advocating for resources and funding for necessary improvement projects.
Six Sigma must also be managed at the team level, which is the primary focus of this
chapter. We’ll cover building a team, detail the various common roles within a Six Sigma
team, and talk about managing a team with timelines and schedules, milestones, budgets,
and a defined measure of success.
You can’t simply have a pre-made team ready to begin work on every project that comes
up. Six Sigma teams must be uniquely tailored to the goals and processes at hand. The same
142
Six Sigma experts – Black Belt leaders, data analysts, or project managers – might work
across multiple projects, but individual subject matter experts and team members only
bring high value to the team if they are familiar with the process or have some related
education, knowledge, or skill to offer. Not all team members will serve consistently
throughout the entire life of a project, either. This is often why companies send existing
employees for Six Sigma training rather than hire Six Sigma experts.
Executive leadership groups working with Six Sigma leaders and experts usually put teams
together. Any process improvement team should have, at minimum:
 A Six Sigma leader

 A process owner
 An expert on the process
 Someone to manage budgeting and accounting
Some of those roles might be handled by the same person; the process owner might also be
the process expert. Depending on expectations of needs, the team might also need to
include technical resources, such as a programmer or IT leader, as well as individuals from
human resources, compliance, legal, or other ancillary departments.
When putting teams together, organizations should remember that three basic team
member types exist with relation to a Six Sigma project. First, there are the regular team
members. These individuals participate in all activities of the team and attend all or almost
all of the team’s meetings. Regular team members include project leaders, process owners
and experts, and identified subject matter experts who the team or executives feel would
be critical components of their group.
Second, ad hoc team members provide expertise on an as-needed basis. Usually, these are
subject matter experts or employees who work directly with the process. You don’t want to
take these employees from their job functions for every single team event, as that would
negatively impact the state of current production. Instead, these employees are included in
team meetings as needed when additional information or assistance is required.
Finally, resource team members are only included when the project team leader feels they
are needed in a meeting or team event to provide expert information, counsel, or help in
accessing resources. Resource team members are usually members of ancillary
departments such as accounting, human resources, or compliance. Resource team
members might also be managers or leaders in departments that are related to the process
143
BASIC SIX SIGMA TEAM MANAGEMENT
being improved. For example, if a team is seeking to improve a customer service

department, they might need help with inputs from the marketing department; someone
from the marketing department could be added as a resource team member.
Most Six Sigma process improvement teams are relatively small: five regular team members
is considered a good number on average. Adding too many regular team members can
create communication problems, make it difficult to manage brainstorming sessions, and
cause burnout. When all of a company’s Six Sigma teams are large, there’s a good chance
that team members are serving on multiple projects. While ad hoc or resource team
members can serve several projects and handle their own work on a daily basis, regular
team members should not be asked to serve on more than one team and handle daily
workloads. In fact, organizational leaders might want to consider reducing work
requirements for team members who are serving as full-time members on a project.
Other tips for selecting team members include:
 Choosing employees who are knowledgeable about the customer, product, or

process related to the project.
 Choosing employees who have shown a willingness and ability to work toward
improvement in a team environment.
 Selecting employees who have access to and an understanding of the data
required to learn about and measure the process or problem.
 Picking employees who can provide at least five hours of work per week to the
team.
 Matching the skills of employees to the projects at hand; if a project is likely to
include all technical improvements, you would be less likely to add a team
member who is skilled in marketing.
 Removing political obstacles through team selection; if a specific person in an
organization is likely to be an obstacle to a team, sometimes putting that
person on the team can increase the chance that they will buy into the process.
The team member roles described in this section are based on Six Sigma process
improvement best practices, but best practices also say that teams and team leaders should
not be overly rigid. Experienced Six Sigma leaders and experts understand how to work
144
within best practices while also creating unique team structures that are tailored to the
project or process at hand.
We’ve briefly touched on sponsors and champions in previous chapters. In most Six Sigma
environments, these are the senior-level leaders who oversee projects at the highest level.
Even the Black Belt must report to the project sponsor or champion. The senior leader is
usually responsible for the final result of a project, which means he or she usually wants
regular reports about progress; sometimes, the sponsor or champion is the liaison between
the team and the leadership council. As the senior leader, the champion or sponsor is also
responsible for assisting the team with obtaining funds and resources to ensure project
success. Some additional duties within this role include:
 Coaching the team, particularly at the project charter stage. The sponsor often
provides input into what is in scope on a project and who might be included on
a team.
 Locating resources for the team, including support from other departments,
money, equipment, time, and labor hours.
 Handling matters of politics within a corporate structure so the team doesn’t
have to.
 Working with other managers within the organization to help the team
succeed in improving a process and transitioning improvements to a daily work
environment.
The business or process owner is usually someone who is directly responsible for the
process in a leadership capacity. Usually, the process owner is the person who is going to
“receive” a solution implemented by a Six Sigma team once that solution is ready to be
rolled out to all team members or used on a daily basis. Because of this, the process owner
is usually included in the team because he or she must understand how and why any
change is made. The process owner must also be familiar with methods of control that are
created by the Six Sigma team as he or she will become responsible for maintaining and
monitoring those controls once the process is transitioned from a team environment to day-
to-day production.
A process owner usually also acts as a process expert on a Six Sigma team. The process
owner has insight into the existing process, understands the needs of the customers and
145
employees related to the process, and might already have access to data regarding the
process. The process owner isn’t always the only process expert on a team, however; in
some cases, the person who owns the process doesn’t have enough day-to-day interaction
with the process to be an expert.
When leading or managing a Six Sigma team, Black Belts and others do have to be wary of
process owners who are resistant to change or who believe they have all the answers.
Someone who is set in his or her ways might not want to involve other team members or
might believe certain changes are “impossible” because they are new. Some leaders who
are also process owners might be afraid that a team member will outshine them or threaten
their position, which could lead them to block team members from participating on a team.
These are some of the political and human resource problems Six Sigma leaders run into,
and Black Belts and project leaders must work tactfully with champions, sponsors, and
process managers to resolve such issues.
Six Sigma projects are usually led by certified Black Belts, although some organizations do
allow Green Belts to act as leaders on small initiatives with occasional feedback and
guidance from Black Belts. In most organizations, the Black Belt holds primary responsibility
for the regular work performed by a team and usually only works with one team or project
at a time.
Best case scenarios let organizations align Black Belts with projects in areas they are already
familiar with. For example, a bank might have several Black Belts on staff. Each Black Belt
might specialize in working with certain processes or departments; one might usually work
with compliance and audit processes, another with accounting, a third with customer-facing
processes, and a fourth with online processes. Since Black Belt resources might be limited,
this isn’t always possible. Most certified Black Belts can bring Six Sigma methods to process
improvements even in areas they aren’t closely familiar with. In some cases, various
managers or other individuals are certified as Black Belts and can lead processes in addition
to their regular responsibilities, although this can put an undue burden on employees and
isn’t always the best solution.
Black Belt project leaders often work to:
 Help create a rationale for a project.

 Provide input for the selection of project team members.
 Lead teams throughout all the phases of DMAIC, which are covered in depth in
Unit 3.
146
 Educate and support team members as they learn about and use Six Sigma
tools.
 Provide oversight through time management, decision making, and planning.
 Maintain schedules and timelines, sometimes in conjunction with a certified
Project Manager.
 Provide expertise in the form of statistical analysis or guidance with analysis.
 Assist with project transition.
 Report to sponsor or champion on a regular basis.
 Provide documentation at the end of the project.
In some organizations, Master Black Belts play an overall role in leading multiple Six Sigma
projects. Master Black Belts act as coaches to multiple teams; Black Belts leading Six Sigma
teams can work with Master Black Belts to solve especially difficult problems or seek help
for complex statistical analysis. Master Black Belts provide continuing education to both
Black and Green Belts, helping team members to constantly improve their grasp of Six
Sigma methodologies.
Some organizations use traditional project management techniques alongside Six Sigma
improvement methodologies. In these organizations, a project manager is usually assigned
to a Six Sigma project. While structures vary by organization, the project manager does not
usually lead the team. Instead, the PM offers leader support to the Black Belt by keeping up
with documentation and timelines, helping keep meetings on track, and ensuring items are
followed up on after meetings. At first, you might think that adding a PM to a team would
cause problems for a Black Belt, but when the two roles work together, the Black Belt
benefits. With a PM worrying about timelines or whether the meeting is getting too far off
track, a Six Sigma exert is free to concentrate on the brainstorming session or statistical
analysis at hand.
Not all Six Sigma teams use timekeepers, but they can help keep meetings on track, reduce
the chance of scope creep, and increase overall productivity. The timekeeper can be any
person on the team who is not regularly engaged in leading meetings, brainstorming
activities or recording team activities and notes. The timekeeper shouldn’t police time in a
such a rigid fashion that the benefits of fluid discussion and brainstorming are lost, but he or
she should gently steer teams toward following agenda schedules or provide the project
leader with an indication that time is up for the topic at hand.
147
To function properly, a timekeeper needs an agenda to follow. It is usually the

responsibility of the Black Belt or project manager to provide a detailed agenda for each
meeting. The agenda should include clear indications regarding how long each item is
expected to take, though teams should always be aware that agendas might be changed
during the meeting at the discretion of the project manager or project leader.
Team leaders should pick a timekeeper who is organized and level-headed. In the heat of
discussions and arguments, it’s easy for any member of the team to lose track of time – and
the timekeeper is a member of the team. In addition to regular duties as a team member,
the timekeeper is expected to:
 Keep an eye on the agenda and the time

 Let team members know when the time for a certain agenda is almost up;
teams might want to set up a five-minute warning rule so they have a few
minutes to wrap up a discussion
 Signal that the time is up for a certain discussion or item
While project leaders can choose to ignore agendas, they should also back up the
timekeeper’s ability to interrupt politely. Timekeepers can’t perform if they are being
heckled by other team members for noting the time.
A lot of discussion occurs in the midst of Six Sigma brainstorming and team sessions, and
someone needs to record that information. Notes are important because they help team
members review what was discussed, create lists of follow-ups and actions from a
discussion, and record charts, graphs, and diagrams that were created during brainstorming
processes. While everyone can take notes, the team leader should appoint one person as
the official scribe for the team. Sometimes, that person is a certified project manager
working in conjunction with a Six Sigma team leader. Other times, it is a member of the
team who is seen as detailed and organized.
The Black Belt or other project leader should never be the scribe; it is too difficult to take
notes while leading a discussion or exercise. The Black Belt might make some notes during
the discussion, but he or she is likely to miss important details while working directly with
other team members.
The scribe should create notes or minutes of the meeting in typed format and disseminate
those notes to all team members as soon as possible following a meeting. Team members
can review the notes and add any missing information if desired; often, organizations create
148
portals or shared file systems so teams can keep notes and all other documents in an easy-
to-access location.
One challenge in recording the discussions of a Six Sigma project meeting is in recording the
diagrams and brainstorming that occurred. This is especially true if teams use whiteboards,
paper, or sticky notes to create diagrams; the scribe is not always equipped with the skills or
the software to recreate a computerized version of such documents. One tip for recording
such information that is used by many modern Six Sigma teams is to take a picture of the
diagrams with a smartphone or digital camera. The images can then be uploaded into the
team’s shared workspace; if necessary, a Black Belt or Green Belt can convert the raw
diagrams to a computerized version for the purpose of presenting information to leadership
or other departments if desired.
In the beginning of this chapter, we covered the three major types of team members:
regular, ad hoc, and resource. Selecting members for each of these roles is up to the project
leader, the sponsor or champion, and the overall organizational leadership team. In addition
to the project leader, process owner, and process expert, Six Sigma teams are usually
comprised of one to three other regular team members. In addition to acting as timekeeper
or scribe as directed by the team leader, team members also:
 Participate in brainstorming sessions, discussions, and other team activities.

 Collect data and perform analysis under the direction of the Black Belt. Often, team
members performing these functions are Green Belts.
 Perform work between meetings as required by the project leader.
 Report the results of and progress on individual assignments to the team.
Review work performed by other team members and the team as a whole, offering
suggestions and feedback.
Scheduling and maintaining that schedule is an integral part of the Six Sigma project
process. Organizational leaders need to understand how long a project will take, when
results can be expected, and when team resources will be freed up for other endeavors.
Without this information, leadership can’t plan for ongoing improvement and employees
can feel trapped in a project that seems to stretch on forever. In this section, we’ll cover
149
two methods for creating a project timeline or schedule and touch on the importance of
milestones.
Six Sigma projects usually follow a specific series of phases; we’ve briefly introduced the
concept of the DMAIC method. DMAIC breaks a project up into five phases: Define,
Measure, Analyze, Improve, and Control. Experienced Six Sigma experts with some data and
information about a project and process can usually provide a very basic and raw estimate
of time by assigning a certain number of weeks to each phase. It’s also worth noting that
most of the phases are likely to overlap.
To create a raw timeline for a project, a Black Belt or other Six Sigma leader usually starts
with an overall time requirement. He or she either estimates the total time required for an
improvement or works with a deadline imposed by the leadership group. For example, the
leadership group might say that an improvement needs to be completed within four
months.
Using a four month timeline and what information is already available about the process,
problem, and resources, the Black Belt might create an estimated timeline for the DMAIC
process that looks something like the figure below.
The estimated timeline is for 16 weeks; the expert believes the Define phase will take 3
weeks and the Measure phase will take 5. The Measure phase overlaps with both the Define
and Analyze phases, which is normal with Six Sigma projects.
The benefit of this approach is that you can generate a timeline quickly. The disadvantages
are that someone without experience of Six Sigma and a fair amount of knowledge of the
process being improved can easily misjudge the time required for each phase and
leadership might consider this a hard timeline, which can create unrealistic expectations.
150
When presenting such a timeline, make sure everyone knows that it is a rough estimate and
the time for each phase can change as you go through the process.
The critical path method is a more detailed way of defining timelines for various elements
of a project, but it does require more information and input from a project team. This
means you probably won’t be able to provide a detailed timeline until the project is
underway; a critical path diagram could be one of the activities the team undertakes as part
of the Define phase.
A critical path diagram can be created for the entire project or for each phase of a project.
As we go through the steps of creating a critical path diagram, we’ll use the Define phase of
a project to reduce bad debt (uncollected invoices) in a medical billing environment as an
example.
1. Identify the critical needs or activities to complete the project or phase of a project.
To complete the define phase of our project to improve bad debt in a medical billing setting,
the team needs to choose a team, charter the project, define the problem, and create a
baseline metric.
2. Put critical activities in order.
The order with which the team should accomplish the tasks defined in step one is:
 Choose a team
 Charter the project and define the problem (these tasks can be done
simultaneously)
 Create a baseline metric
3. Assign a time to each task.
A Six Sigma expert estimates it will take one week to choose a team, one week to create a
charter, one day to create a problem statement, and two weeks to create a baseline metric.
4. Create a diagram of the tasks, stacking simultaneous or parallel process and including
time figures.
151
The diagram is created from left to right. The items on the left must be done before the
items to the right can be completed. When items can be done at the same time, they are
stacked.
5. Draw a critical path through the diagram.
When steps are stacked, the critical path goes through the step with the longest time
estimate. For example, the team might create a problem statement while they are working
on a project charter; the project charter takes from Monday through Friday to complete.
The problem statement is complete on Tuesday. However, the team is not done with all of
the steps in that series until they are done with the project charter.
6. Add up the longest times from each section.
152
In this case, the team adds 1 week, 1 week, and 2 weeks to get to 4 weeks total for the
Define phase.
We’ve used a very simple example, but you can use the critical path method to estimate
timelines for extremely complex projects or processes.
Once a timeline is established, set up milestone meetings and dates to help keep the team
on track and notify the sponsor or champion of progress. In a DMAIC project, milestones are
usually set at the end of each phase (Define, Measure, Analyze, Improve, and Control).
However, teams can set custom milestones, and sponsors might require specific milestones
if they are approving large resourcing or funding requests for a project.
You can also set up milestones within a team environment to manage goals and tasks; these
milestones can be kept within the team. For example, a team working for a chain of
sandwich shops is hoping to improve the process by which sandwiches are put together.
They have set up the following milestones:
Define: January 21
Measure: February 12
Analyze: February 22
Improve: March 15
Control: April 10
The milestone dates are when the team or the Black Belt will meet with the sponsor to
present the findings or results of each phase of the project. Each date gives the team
something to work toward. However, the team has determined that certain tasks must be
accomplished during the Measure phase. First, they have to create some definitions of
terms so everyone is on the same page when discussing measurements. Second, the team
has to gather data about the temperature at which ingredients are stored and cooked.
Finally, the team wants to actively observe sandwich shop employees in order to measure
the time it takes to make various sandwiches.
The team might set up internal milestones for the Measure phase, stating that definitions
will be created by January 25, temperature data collected by February 5, and time data
collected by February 10.
153
By breaking each phase, and each larger task, into smaller parts, it is easier for the team to
stay on track and complete work. Smaller tasks seem more manageable, so they are more
likely to be accomplished.
Teams, and especially team leaders, must always be concerned with project budgets. While
success is rated by end customers in terms of performance, quality, and satisfaction, Six
Sigma teams also answer to corporate leadership. For leaders, success is also measured in
terms of time and budget. A strong timeline and good milestones help you meet time
requirements, and an understanding of financial drivers, strong communication, and
financial oversight help you keep a project within budget.
One of the challenges when dealing with budgets in a Six Sigma project is that all team
members are not always completely aware of financial drivers. In some cases, financial
information might even be restricted; employers don’t generally want specific data about
employee pay made public to various team members, for example. Some information and
analysis might need to be performed solely by a project-leading Black Belt in such cases,
especially if data is critical or sensitive.
Outside of concerns with sensitive data, process improvement projects work best when all
team members are made aware of as many of the drivers and data as possible. When teams
know how much funding a champion is willing to seek on their behalf, they can make
realistic decisions about how to improve a process. Sometimes, the solution that is most
likely to generate the most improvement isn’t viable because of budget. If an improvement
project has a budget of $50,000, the team can’t implement a solution that requires an
$80,000 capital investment in machinery, for example.
Budget concerns vary by organization. In some organizations, leaders are most concerned
with specific expenditures by a team, including expenses on new equipment, hiring new
personnel, or purchasing new products or software. Some organizations take a more
granular approach to project budgets, considering the expense of hours spent by the team
on the project as well as the expenses associated with training and implementing a solution
outside of the team environment.
Six Sigma team leaders must ensure they understand how leaders and organizations
manage project budgets. Working for the first time with an organization or sponsor means
having honest and thorough conversations about how budgets are calculated, how much
154
sponsors are willing to work for increases in a budget, and what the Six Sigma leader’s
expected role in maintaining budgets is.
Finally, Six Sigma teams must create a well-defined measure of success. To best manage a
Six Sigma project and team, leaders have to ensure all team members, leaders, and
sponsors agree on what success means. If success isn’t defined at all, the team risks scope
creep and getting lost in a project that never seems to end. If success isn’t well-defined,
teams risk concluding a project without satisfying the customer, sponsor, or all members of
the team. If a sponsor and the team don’t agree on what success looks like, the team could
think they’ve concluded a successful project while leadership believes the project was a
failure.
In the end, successful Six Sigma team management hinges on many of the same concepts as
successful leadership in other endeavors does. Choosing the right people, being clear about
expectations, approaching work in an organized manner, and being honest and open about
progress helps every member of the team succeed and provide value.
155
One of the things that sets Six Sigma apart from some other quality improvement and
management methodologies is a structured approach to every project. Projects that are
meant to improve an existing process follow a road-map for success known as the DMAIC
process; DMAIC is broken into five phases: Define, Measure, Analyze, Improve, and Control.
The main activities of a DMAIC project include identifying the critical inputs or causes (the
Xs) that are creating the problem (the Y), verifying those causes, brainstorming and
selecting solutions, implementing solutions, and creating a control plan to ensure the
improved state is maintained.
The DMAIC methodology is designed to be fairly inclusive – the vast majority of teams who
are seeking to improve a project will be able to fit their activities in to the DMAIC steps
because those steps are designed to allow some flexibility. Sometimes, though, teams
realize that fixing or improving a process isn’t the right way to achieve sustained
improvement for the organization. Instead, a process might need to be completely replaced
or redesigned to meet goals for customer satisfaction or organizational improvement. In
such cases, teams can employ the DMADV method.
DMADV stands for Define, Measure, Analyze, Design, and Verify. The principles governing
the method are very similar to those governing DMAIC, but the last two phases are geared
toward rolling out and testing a completely new process. Six Sigma teams might approach
improvements through DMADV if:
 The business wants to launch a new service or product.

 Business leaders decide to replace a process because of upgrade needs or to align
business processes, machinery, or employees with future goals.
 A Six Sigma team discovers that improving a process is not likely to provide the
success desired from a project.
Most teams go into the project knowing whether they are employing DMAIC or DMADV
approaches, but some DMAIC projects can become DMADV projects – usually during the
156
Define, Measure, or Analyze stages – when the team realizes the need for a complete
process replacement. Switching to the new methodology during the middle of the project
might require some shuffling of resources and could impact project schedules, which means
keeping champions and sponsors informed of team progress and decisions is imperative.
It’s worth noting that some organizations don’t formally use the DMADV approach for any
project, in part because they find it easier to stick with the nomenclature of a single
methodology. These organizations might still complete process redesign projects by altering
some of the activities handled in the Improve and Control stages of DMAIC. In short, the
teams do use the DMADV approach, but they use the verbiage associated with DMAIC to
streamline Six Sigma education across all levels of
the organization.
What is Change Management?
Change management refers to a

The major differences between DMAIC and DMADV closely-managed process of
are the goals the team sets and the outcome of the making changes in an
completed project. In some ways, a DMADV project organization. Often, companies
might feel like it has a more tangible outcome, but in use change management policies
reality, both methods are seeking to deliver better and rules to govern how changes
quality, better efficiency, more production, more are made to software,
profits, higher customer satisfaction, or some infrastructure, or processes that
combination of these things. We’ll introduce each of have compliance or audit
the phases of both methods in this chapter. But first, elements.
let’s look at some quick definitions of each phase as
During change management,
they relate to DMAIC versus DMADV.
teams must document all activity
in keeping with corporate
policies and report changes and
During a DMAIC project, the Define phase is results to an oversight
concerned with identifying the problem, defining committee. Sometimes, Six
requirements for the project, and setting goals for Sigma projects involve changes
success. Requirements and goal setting might relate that are also governed by these
to a variety of factors and are dependent somewhat policies, which means Six Sigma
on guidance from the leadership team and expected leaders must be prepared to
budgets, and Six Sigma leaders can use various tools report to change management
within the phase to create flexibility that allows for a committees.
variety of project types.
157
INTRODUCTION TO DMAIC AND DMADV
In a DMADV project, the Define stage is slightly more rigid. Teams also have to identify a
problem and begin defining requirements, but requirements must be made within a
change-management environment. Sometimes, organizations have a change management
program in place, which means Six Sigma teams must incorporate all requirements of that
program into the DMADV phases. The team also works to define customer requirements to
create a measuring stick to which the process development can be compared.
The DMAIC Measure phase is when teams use data to validate their assumptions about the
process and the problem. Validation of assumptions also merges into the analyze phase.
The bulk of the measure phase is occupied with actually gathering data and formatting it in
a way that can be analyzed. Measuring can be one of the most difficult tasks in a Six Sigma
project if data isn’t already being captured. Teams might have to build tools to capture data,
create queries for digital data, sift through enormous amounts of data to find relevant
information, or capture data by hand in some manual process.
After validating assumptions from the Define stage with actual data, the team might revisit
problem statements, goals, and other process-related definitions. If the team leaves Define
with a “rough draft” of these things, they should leave Measure with a final draft. Teams
also work during Measure phases to measure key inputs and steps in the process in
preparation for Define.
Teams working through a DMADV approach might do some of the same things during the
Measure phase, but activities are typically more targeted. Teams will likely collect data and
measurements that help them define performance requirements for the new process.
During the Analyze phase of a DMAIC project, teams develop hypotheses about causal
relationships between inputs and outputs and between Xs and Ys, they narrow causation
down to the vital few (using methods such as the Pareto principle), and they use statistical
analysis and data to validate the hypotheses and assumptions they’ve made so far. The
Analyze phase tends to flow into the Improve phase in a DMAIC project; hypothesis testing
to validate assumptions and possible solutions might begin in Analyze and continue into the
Improve phase.
158
A team using DMADV might also identify cause and effect relationships, but they are usually
more concerned with identifying best practices and benchmarks by which to measure and
design the new process. Teams might also begin process design work by identifying value-
and non value-added activities, locating areas where bottlenecks or errors are likely, and
refining requirements to better meet the needs and goals of the project.
Six Sigma teams start developing the ideas that began in the Analyze phase during the
Improve phase of a project. They use statistics and real-world observation to test
hypotheses and solutions. Hypothesis testing actually begins in the analyze phase, but is
continued during the improve phase as teams select solutions and begin to implement
them. Teams also work to standardize solutions in preparation for rolling improved
processes to daily production and non-team employees. Teams also start measuring results
and lay the foundation for controls that will be built in the last phase.
The fourth phase is where DMADV projects begin to diverge substantially from DMAIC
projects. The team actually works to design a new process, which does involve some of the
solutions testing mentioned above, but also involves mapping, workflow principles, and
actively building new infrastructures. That might mean putting new equipment in place,
hiring and training new employees, or developing new software tools. Teams also start to
implement the new systems and processes during the fourth phase.
For DMAIC and DMADV teams, the control or verify phase is where loose ends are tied and
the project is transitioned to a daily work environment. Controls and standards are
established so that improvements can be maintained, but the responsibility for those
improvements is transitioned to the process owner. During the transition, the Six Sigma
team might work with the process owner and his or her department to troubleshoot any
problems with the improvement.
Consider the following improvement projects. Which methodology do you think a Six Sigma
team might use to approach each project?
1. A business wants to create a smartphone app to help customers make and manage
appointments.
159
2. A doctor’s office has had numerous complaints from patients because it is too hard
to get appointments, appointment communications are confusing, or patients show
up for appointments and are told they don’t have an appointment.
3. A company that manufactures pizza boxes isn’t happy with the profit margins in the
small size boxes.
The team handling an improvement for the business in example 1 would choose a DMADV
approach. They are creating a product that doesn’t yet exist; while the team is meeting a
need that already exists and is improving an overall process – the setting of appointments –
the app itself is a new process and a new product. The app will need to be designed,
integrated into existing systems, and the final product tested before full implementation.
Example 2 is for an existing process, so the team would begin with a DMAIC approach. It’s
possible that the team might determine during the process that one solution might be to
develop a new appointment-setting software or replace existing software with something
from a different vendor. In some cases, that might warrant a switch to DMADV, but, as
previously stated, not all organizations would do so. Some organizations would continue
with the DMAIC process and modify the activities in each phase to fit the needs of the
project at hand.
Example 3 is a classic example of what brings many teams to the DMAIC method. The
problem hasn’t yet been defined, but the organization knows that goals and expectations
are not being met. A leadership team might work with subject matter experts and one or
more Six Sigma experts to discover more about the processes involved before settling on
one or more improvement projects.
During the Define phase of a Six Sigma process improvement project, teams create what is
known as a project charter and a basic plan for work. A charter is a synopsis of the project.
It provides some common information and a summary of what the team hopes to
accomplish. The charter usually features a list of team members, names of those
responsible for outcomes, a problem statement, a goal, and some basic definitions of scope
and metrics for success. Some charters also include a rough timeline estimate for the
project.
Also during the Define phase, teams create or list measurable customer requirements and
create high-level documents about the process (including process maps). Often, teams will
start with a SIPOC diagram to help them begin to understand a process. Teams should also
160
identify stakeholders during the Define phase. Stakeholders are individuals, both within and
without an organization, who have some level of influence on the success of an
improvement project. By understanding who stakeholders are, teams can remain in contact
with various persons throughout the project, communicating with those stakeholders as
needed to ensure future viability of any improvement that is created. One way to identify
stakeholders is through a Stakeholder Analysis.
One of the biggest challenges Six Sigma teams face when in the Define phase of a project is
generating positive, targeted momentum that sets the foundation for the rest of the
project. As a Six Sigma team leader, you can increase chances of success by keeping the
team as focused as possible during the Define stage. Begin by explaining the Six Sigma
process and the purpose of the project for any ancillary team members who may not be
familiar with Six Sigma and DMAIC. Next, work as a team to create ground rules for how the
project will run – including how meetings are organized and managed, how information will
be communicated, and what each team member might be responsible for during the
project.
Create a charter and project plan so the team has something to focus on. If possible, have
the Champion of the project spend time with the team. Hearing directly from an executive
leader about expectations and the support of leadership for the project helps motivate a
team. At the same time, ensure the Champion doesn’t step in to take over the project, as
this isn’t his or her role.
Define is also a good time to explain the roles of scribe and time keeper and talk about the
purpose of brainstorming. Some Six Sigma leaders like to let team members take turns
facilitating various exercises for the group, as this integrates each person more tightly
within the process and helps team members at all levels learn more about Six Sigma.
Once a team has a good grasp of what the process does and how it works, what the
problem is, and what the goal for the project is, the team moves from Define to Measure.
Usually, the transition between phases is marked by a tollgate review wherein the team
presents its Define work to a champion or a Six Sigma leadership board. The champion or
board provides feedback and makes the decision about whether the team is ready to move
on to Measure.
161
During the Measure phase, the team is concerned with creating a baseline metric for the
process and refining problem statements and other outputs of the Define stage. Creating a
baseline metric lets teams understand how a process should be measured and how the
process is really performing before improvements begin. It also provides a comparison point
so teams can show how much improvement they’ve brought to a project at the end of the
DMAIC method.
One of the biggest challenges, especially for teams and team members who are new to the
Six Sigma method, can be deciding what to measure. Many times, inexperienced teams end
up spending time collecting data that doesn’t provide answers or can’t be used for the
process. Because the Measure phase starts with some educated guesswork and trial-and-
error, teams and Six Sigma leaders have to keep a close eye on progress and redirect work
when measurements are not creating the answers or production required.
A successful Measure phase requires strong observation skills, an understanding of the

reasons behind measure, knowledge of data types such as discrete and continuous, tools for
measurement assessment, and a strong background in statistical analysis. Some of the tools
often deployed in the Measure phase, such as the CTQ tree and sigma level calculation,
were covered in previous chapters.
The Measure phase is often the most challenging phase for a Six Sigma team leader,
especially when working with teams that are inexperienced in the methodology. When
teams start to really dig deep into a process and begin to measure things, they often get a
true idea about how challenging the problem really is. They might also have a difficult time
understanding how and when to measure things, and collecting data that hasn’t been
collected before can be time consuming and tedious. Because of all these challenges, teams
might enter what is called a storming stage—team members question the viability of the
project, rail against the Champion or the team leader, complain how much time the project
is taking from other duties, or stop showing up to meetings altogether.
Six Sigma leaders can reduce the impact of storming on a team by demonstrating a calm
approach to each aspect of the project and redirecting the strong emotion of storming to
more productive work. If you can identify an easy task or problem, letting the team work on
that and accomplish something immediately can reduce the excitement of storming; Six
Sigma leaders should also ensure work is fairly distributed and that each team member
knows exactly what his or her responsibilities are.
162
Once measurements are collected – or are in the process of being collected – Six Sigma
teams usually move on to the Analyze phase. Again, a tollgate review is often conducted
between phases, but the lines between Measure and Analyze are often blurrier than the
lines between Define and Measure. In some cases, a team has to measure, analyze, and
then measure some more – particularly if metrics aren’t already in place for a process.
Analyze phases are when teams perform detective work on the process. Using the clues
gathered during the Define and Measure phases, along with information provided by the
sponsor, process owner, and subject matter experts, teams attempt to identify root causes
for a problem; they also use statistical analysis and other tools to verify causes before
turning to the work of identifying possible solutions. During the Analyze phase, teams use a
variety of tools – some of which were introduced in earlier chapters. Tools common in the
Analyze phase include Pareto charts, run charts, histograms, cause-and-effect diagrams,
scatter diagrams, process maps, and value analysis.
As teams work through the Analyze phase, they also start preparing for the Improve phase.
During Analyze, teams might begin working on possible solutions and selecting solutions,
developing improvement plans, and preparing some basic documentation about
improvement work. Whether a team begins this work during Analyze often depends on the
individual project and the manner in which the Six Sigma team leader would like to proceed.
The Six Sigma team leader should ensure that teams aren’t taking on too much of the
project at one time and that working on early Improve work doesn’t reduce the efficacy of
the work done for the Analyze phase.
Teams in the Analyze phase might continue to suffer from storming; if teams didn’t storm
during Define or Measure phases, they might begin to do so in Analyze. Six Sigma leaders
can use the same tips for controlling storming in the Measure phase in the Analyze phase.
Another common challenge for Six Sigma team leaders is introducing and explaining
statistical concepts during the Analyze phase. When other team members or even the
champion of the process are not familiar with statistical analysis, presenting advanced
analysis in terms of statistical verbiage only can be a mistake. Team members won’t
understand how you came to the conclusions you are presenting, which makes it less likely
they will get behind the solution or improvement in a positive way.
163
Six Sigma experts should be aware of the knowledge limitations of various team members
and work to both present information in a way that is understood by everyone and continue
to add to team member knowledge by explaining concepts when possible.
During the Improve phase of a project, a Six Sigma team selects a final solution and begins
to put it in place. Sometimes, teams will select more than one solution, especially if a few
smaller solutions are highly related and work together for an overall solution. It can be hard
to determine which solution actually improves a process, however, so it’s usually a best
practice to implement one change at a time and verify that change before moving on to
something else.
Teams might also come up with many possible solutions, all of which would provide some
improvement for the process. They should use a solutions selection matrix or other Six
Sigma tool to evaluate solutions, choosing only the few best solutions. It’s worth noting
again that the best solution is not always the solution that provides the most improvement.
Solutions that are so expensive or disruptive that they cause disadvantages that outweigh
any benefits should never be selected by project teams.
During Improve, Six Sigma teams must continue to keep the project definitions in mind. The
solution must address a root cause verified in the Analyze phase; the root cause must be
directly related to the problem stated during the Define phase. After selecting solutions,
teams must test them using statistical tools and real-world sampling to ensure effectiveness
before deploying solutions to a live work environment.
Possibly the most common problem that plagues Six Sigma teams during the Improve phase
is project fatigue. By the time teams come to Improve, they have been working on a project
for weeks or even months; for many team members, the project work is on top of regular
work. Fatigue or frustration might push team members to select and implement solutions
just to have the project completed. Six Sigma leaders have to work to keep teams motivated
on quality and improvement.
The best way for a Six Sigma team leader to create strength as the team nears project
completion is to build a good foundation for Six Sigma in the earlier phases. Teams that
understand the DMAIC process and have at least basic understanding of Six Sigma and
statistical analysis by the Improve phase are more likely to stick with planning, analysis, and
the DMAIC method.
164
Six Sigma team leaders should also continue to foster a team approach to all aspects of the
project. One challenge for some leaders is the temptation to take measurements and
analysis and begin performing much of the work themselves. Sometimes, it’s faster and
easier to handle decision-making and analysis on your own, especially when you are dealing
with team members who aren’t fluent in DMAIC or Six Sigma methods. Doing so alienates
team members, though, and can result in a Six Sigma leader without direct process
knowledge making the wrong decision. Keeping the team involved – and making exercises
and meetings fun and productive – helps you make it through the Improve phase.
Control is the final phase for Six Sigma teams employing the DMAIC process. During the
Control phase, teams usually handle four tasks: creating the foundation for process
discipline, finalizing documents regarding the improvement, establishing ongoing metrics to
evaluate the process, and building a process management plan that lets the team transition
the improvement to the process owner.
Tools used by a team during the Control phase include documentation checklists, control
charts, response plans, process maps, and process dashboards.
The Control Phase is often easy for a team because the work of the team has already
reached a crescendo. In a well-run DMAIC process, the Control phase is a time of wrapping
up loose ends and arriving at the end of a project. At the same time, teams might find it
challenging to let go of a process they have put so much time into. By the time teams reach
the Control phase, they might have been working with a process for months. If a Six Sigma
leader has done his or her job, the team has taken ownership of the process and feels
personally tied to the quality and output, making it hard to turn the work over to other
teams or employees.
Six Sigma leaders can help team members transition a project by preparing them in advance
for this phase. You might also find ways to incorporate team members into meetings or
presentations where project results are being shared. Six Sigma leaders should always host
a meeting to wrap up the project. The meeting should be somewhat celebratory in nature –
if budget, time, and policy allows, Six Sigma leaders might consider having lunch or snacks
at the meeting. Take time to recognize each team member’s contribution, and ask team
members to identify something they learned that can be applied to their own work. This
helps team members see that Six Sigma is an ongoing culture within an organization, and
165
the end of a particular project doesn’t equate to the end of each person’s involvement in
continuous improvement.
Recognition is extremely important when ending a Six Sigma project. Team members might
have put in extra hours to provide excellent work on a project while maintaining their own
responsibilities. Often, work on a Six Sigma project is not part of a team member’s regular
duties, so they are going above and beyond what might normally be expected of them. Six
Sigma leaders should make it a point to recognize the work of team members in front of a
project sponsor or champion, and, when possible, in front of the department for which the
improvement is being made.
Design is the fourth phase of DMADV; it replaces the Improve phase of DMAIC. DMADV is
one approach for what is called Design for Six Sigma, or DFSS. Another approach is called
DMADOV, which stands for Define, Measure, Analyze, Design, Optimize, and Validate.
Teams using the DMADV approach usually combine the activities from Design and Optimize,
and we’ll briefly introduce those activities in this section.
The Design phase of DMADV is when teams create a new process or develop a new product.
A Six Sigma team would have previously done all the work to lay the foundation for
development during the Define, Measure, and Analyze stages, which means most of the
Design phase is taken up with the actual work involved in creating the process or project.
Using the plans, instructions, or maps created in earlier phases, the team either creates a
product themselves or works with vendors, manufacturers, or other employees to create
the product. For example, if the DMADV project involved the creation of a new app for
customers or employees, the team might work with staff in the programming and technical
departments. They might also work with a vendor who will be supplying the app or software
in question; in such a case, a representative from the vendor should have been part of the
team throughout all phases.
During Design, a team will also test the product, process, or service. Testing can be done in
testing environments, in limited production environments, or via Beta testing. Usually, the
team rolls out the new process or product to a limited number of internal or external
customers; those customers provide feedback and the team uses the feedback to
troubleshoot the new process or product as needed. Seeking feedback and troubleshooting
the new process to create the best possible solution is where the Optimize in DMADOV
comes in.
166
In a process redesign project, all phases are essential, but Design is often seen as the most
critical. Teams that falter in the design phase can waste the work that was put into other
phases, and it’s easy for teams to fall prey to project fatigue just as work requirements pick
up for everyone involved. Six Sigma team leaders can help improve the chances of a
successful Design phase by following the tips for managing Improve phases. Teams should
also be realistic about target dates for design work. Promising a complete solution in a short
time period pleases leadership at first, but if teams are rushed, they tend to deliver low-
quality processes. If you promise a too-good-to-be true timeline, you also run the risk of
running far behind schedule, which can impede the work of other projects and process
improvements.
The Verify phase of a DMADV or DMADOV project is very similar to the Control phase of a
DMAIC project. The new process, product, or service is transitioned out of project mode and
handed off to a process owner or employees who work daily with the process or product in
question. Control plans, including control charts, might be put in place by the team to track
ongoing results, and almost all of the tools used in a DMAIC Control phase are relevant to
Verify.
One of the differences between Verify and Control is that DMADV teams might take time to
complete further CTQ analysis at the end of a project so they can identify new critical-to-
quality factors. This is done because the process or product is different than it was when the
team first started working. While the team should have made educated guesses about CTQs
for the new product – and used those CTQs in planning and designing – they could not
predict 100 percent how the customer might react to the new product or process. A new
process might have a capability the old one did not; having that capability, the customer
might decide it is the most important factor in quality about the process or product.
At the end of the Verify phase, a team delivers a final product or process that meets the
needs first identified in the Define stage. The process or product should be free of known
problems and defects wherever possible, and teams should have provided a way to manage
and control the process through statistical control charts, Lean templates, and policies.
167
One of the major differences between DMAIC and DMADV is the possible timeline. We
previously stated that a problem fits the DMAIC model if it can be solved in less than six
months. While some DMADV projects might only take a few months, many process or
product designs can take years. Because of this, the concluding challenges for a DMADV
team are similar to those in a DMAIC environment, but they might be heightened by the
length of time a team has spent on a project.
Team members who have spent a year or more working to develop a new process or
product might feel like the end of the project threatens their job. This is especially true
when team members have not been handling regular work duties in addition to product
duties. Six Sigma leaders and champions can reduce these worries by communicating next
steps and expectations clearly with staff.
Team members who have been working on regular job duties alongside project work for
years might find it hard to return to regular duties without something else to work on. One
of the benefits of Six Sigma is that team members learn to expect more of themselves, their
coworkers, and an organization’s processes. Six Sigma team leaders can work with
employees returning to daily work and help them apply what they learned in a positive
fashion within their respective departments.
Finally, Six Sigma team leaders should ensure that a DMADV project closes on a positive
note by validating all team members and ensuring process owners have all the tools they
need to accept the new process without disrupting work.
You should now have a basic understanding of how a Six Sigma team approaches a problem
or process improvement. Whether improving an existing process or creating a new process
or product, teams work through phased approaches. The phases of DMAIC and DMADV
provide control and organization for a project, help keep everyone on task, and let teams
break up what can seem like enormous tasks into chunks that are tolerable. As the old
adage says: How do you eat an elephant? One bite at a time. Similarly, the phased approach
of Six Sigma breaks up the elephant so teams can work on it one bite at a time.
168
Six Sigma teams enter the project process with various levels of information. Sometimes, a
problem is fairly well defined before the team begins work, particularly in organizations that
use a Six Sigma leadership council to choose projects and create teams. Other times, teams
begin work with little information except that a problem – of some type – exists because
the outcomes of a process are not as expected. Teams might not know where errors are
occurring or even begin a project with a complete understanding of the inputs and outputs
associated with the process.
Whatever knowledge teams begin with, the define phase is when teams move from very
basic information about a process or problem to the knowledge and organization necessary
to enter measure and subsequent other phases with a successful foundation. In the define
phase, teams set rules, create a charter that will govern efforts moving forward, identify
stakeholders and customers, define a process through process mapping, and prepare for a
define tollgate before entering the measure phase.
A project charter, or team charter, is a short document that includes information about the
team and what they plan to accomplish. The purpose of the charter is to set expectations
that can be agreed upon by the team as well as the sponsor or executive leaders, keep the
team focused on the goal, ensure the project remains aligned with the goals of the business,
and documents the fact that control of a process is being moved from a business executive
or manager to a Six Sigma project team.
Minimally, team charters should include:

169
DEFINE
 A complete and concise problem statement that follows the guidelines set out
in Chapter 6.
 A list of critical to quality metrics, or those measurements that will ultimately
determine project or process success. Critical to quality was introduced in
chapter 8.
 The names and roles of each person on the team. Selecting team members and
appropriate team member roles are covered in Chapter 10.
 A list of both internal and external process customers. Use a SIPOC, discussed in
Chapter 7, to begin defining internal or external customers.
 The name of a sponsor and/or champion.
 A duration for the project.
Teams might also include information such as a list of non-customer stakeholders, an

estimated schedule for each phase of the project, scope definitions for the process or
project, and financial drivers for the project.
The information for the team charter usually can’t be gathered in a single brainstorming
session; the charter is an outcome of the entire define phase, not a quick notation at the
beginning. By taking time to properly consider all elements of a team charter, Six Sigma
teams create a stronger foundation for the rest of their work.
Businesses that are implementing Six Sigma organization-wide might consider creating or
using a specific template for team charters. Templates streamline define phases and make it
easy for leadership teams and other employees to understand critical process components
at a glance. While final team documentation is likely to be extensive, and even in the define
phase, teams themselves might work with lengthy requirements documents, charters
themselves should be as concise as possible. Some organizations distill charters to a single
page while others use multipage documents. A sample one-page charter template is
attached at the end of this chapter.
We’ve covered some of the most important elements of the charter in detail in previous
chapters, but here’s a quick look at some of the items we didn’t cover in as much detail and
are worth mentioning again.
170
The business case might also be referred to as the financial drivers behind a project. Related
closely to the problem statement, the business case is a short statement that provides a
reason the project should be undertaken. The problem statement tells someone where,
when, and how; the business case says why it’s important. If you think back to Chapter 6,
we said dollar amounts or another financial metric were important to include in the
problem statement. If you include a business case in your charter, you would build on that
basic financial statement to explain why, specifically, the loss of money, efficiency, or
quality is important to consumers, employees, or the organization. You might also make an
argument for why the problem must be solved now; in essence, why is this project being
run now in place of another project?
We introduced the concept of scope briefly in Chapter 6. For the purposes of the team
charter, the scope should include a hard beginning and end of the process or problem being
considered. You might also include a short list of items or activities that are in scope and out
of scope for your project. A SIPOC diagram helps teams identify the parameters for a
project, and you can also use the In and Out of the Box method described later in this
chapter to understand the intended scope of a project.
The scope should be clear. Listing the scope for a project or process as “beginning at the
order stage and ending with fulfillment” isn’t clear, because different people might consider
different points the beginning of the order stage or the end of fulfillment. A better scope
statement might be “beginning when a customer places an order and ending when the
order is boxed for shipment.” Going even further, a team might deem return and
replacement processes out of scope for a project so that they are only dealing with original
orders. Successful projects have a well-defined scope that is approved and backed by a
project sponsor or champion.
Listing major stakeholders on the charter helps the team remember who and what they are
likely to impact in addition to end customers. Having the list visible during meetings reduces
the chance that the team will initiate changes that might have a negative or unwanted
effect on other process owners or processes, and it helps direct the team to resources
outside of the team that can provide help, access, or information to areas related to the
project.
171
DEFINE
Team members and roles were covered in Chapter 10, and the team charter simply needs to
list the names of all team members along with their role and expected time commitment.
Adding time commitments to the charter helps sponsors and executive leadership
understand the human resource requirements for the project; often a Six Sigma team
leader has to seek approval for staff members from other areas to devote a specified
amount of time to the project.
Time commitments can be listed in hours per week but are often listed as a percent of the
employee’s overall time. For example, a subject matter expert who is expected to attend all
of the team meetings to provide input, but is not expected to complete data collection,
analysis, or improvement work, might be listed as providing 10 percent of his or her time to
the team. A list of team members in a charter might look something like the list below. You
don’t have to list all the staff members you might possibility consult during the course of
the project.
 Mike Smith, Black Belt, 100%

 Chase Michaels, Green Belt, 100%
 Lisa Javes, Green Belt, 100%
 Rosalie Myers, Process Owner, 25%
 Brent Reed, subject matter expert, 10%
 Brenda Tran, subject matter expert, 10%
In Chapter 10, we covered creating a draft schedule for a Six Sigma project. The diagram
included in Chapter 10 that broke down the timeline for a project is called a Gantt chart.
Adapted by Henry Gantt in the early 20th century, a Gantt chart is a bar chart that displays
the phases of a project according to time. One of the benefits of using a Gantt chart to
display a rough project schedule is that it can easily be included in a one-page project
charter; anyone reviewing the charter can quickly visualize the time element required for
the project.
Teams should ensure a date is provided for the end of each of the DMAIC phases and that
all team members agree that the dates are plausible given what the group wants to do. In
some cases, milestones might be set by the project sponsor or champion, but the team
should agree that milestone dates are possible. If dates seem implausible, teams can
present a counter schedule with logical arguments regarding why the original schedule
wouldn’t work.
172
In addition to milestones at the end of each project phase, Six Sigma teams might also want
to set milestones for work within each phase – specifically for the more laborious measure,
analyze, and improve phases. While the team should document all milestones it agrees on,
detailed milestones don’t necessarily belong in the one-page charter document.
Everyone needs to know how the team is going to measure success. If a sponsor is
measuring success on customer satisfaction scores and the team is measuring success on
internal quality scores, ideas about the outcome of the project are likely to differ. Usually,
measures of success can be pulled from the critical to quality metrics discussed in Chapter
8. If teams can convert a CTQ to a measurement, they can understand what major metrics
determine success of a project. While teams might begin to gather measurements or look at
existing measurements while in the define phase, finalization of metrics can extend into the
measure phase.
Financial information is already likely included on the charter in both the business case and
the problem statement. Teams might include expected financial benefits in the business
case section of a charter, but it must be included somewhere. For some sponsors and
executive leaders, the financial benefit is the most important piece of information included
in a charter. An estimated savings or increase in revenue also provides a measuring stick by
which leaders can consider requests for resources for a project.
A Six Sigma expert should never over extend estimates regarding financial benefits; it’s
almost always better to under-promise and over-perform. If you tell leaders a project will
save $500,000 in the first year because a big number means you’re more likely to get
project approval and all the resources you ask for, you’re the one that answers when the
project saves only $80,000. As with any aspect of a Six Sigma project, be as accurate as
possible, but be conservative with estimates when accuracy is in question.
Before a Six Sigma team presents a charter for approval, it should take time to review the
document as a group to ensure the charter lays a foundation for success. Some questions a
team might ask itself about a charter include:
 Is everything—especially the goals, financial expectations, and timeline—

challenging but realistic?
173
DEFINE
 Can everyone on the team devote the committed amount of time to the
project?
 Is the project backed by a sponsor or champion with enough influence to drive
critical assistance and resources?
 Does the team expect to be supported by auxiliary departments such as
information technology, human resources, compliance, accounting, or legal as
necessary for project success?
 Does the team expect to have the necessary freedom to implement a solution
it designs after the solution is approved by the sponsor, champion, or executive
steering committee?
 Does the team have a leader who is well-versed in Six Sigma tools and project
management?
If the answer to any of the questions above is no, then the team could be setting itself up
for failure. Before moving forward, the team should address these concerns and, if possible,
make changes that convert no answers to yes answers.
Before moving forward with any work – even defining a team charter – it’s a good idea for a
Six Sigma team to establish some basic rules and requirements for the team. We touched
briefly on this in Chapter 10 when discussing management of a team. The ground rules for a
project should be maintained in writing and approved by all team members, but they don’t
have to be part of an official charter document. The reason for documenting the rules and
having all team members approve them is because a single team member cannot later claim
to be ignorant of the rules.
At the same time, rule generation on a Six Sigma team shouldn’t be a completely
democratic process. Some of the more common sense or critical rules can be provided by
the Black Belt or team leader. For example, ground rules should cover topics such as who
should attend each meeting and the fact that team members should hold certain
information confidential. A Black Belt might simply state that team members should
observe confidentiality and attendance rules, be on time to meetings, and respect each
other. The team itself will likely vote on the frequency of meetings and when meetings
should be scheduled. Seeking team member input ensures that all team members can
actually commit to meeting time slots. For consistency, it’s best to hold meetings on the
same days and at the same time each week, but it’s understandably difficult to keep such a
schedule through the entire life of some projects.
174
Black Belts might also provide some tips and suggestions for how team members should
participate during meetings, particularly during group brainstorming sessions. For more
information on running a brainstorming session, see Chapter 35. Black Belts should also
dictate the rules for creating an agenda and running a meeting according to the agenda,
though they might delegate some of these functions such as time keeper and secretary.
We’ve covered a number of define tools in previous chapters, including the SIPOC diagram
and the 5 Whys. Process maps and value stream mapping are two advanced Six Sigma tools
that are often used in the define stage. Some Six Sigma teams begin using run charts to start
defining a baseline in the define phase; run charts are covered in Chapter 13 on the
measure phase.
In this section, we’ll cover three additional tools that are common to the define phase: the
Stakeholder Analysis, the In and Out of the Box Method, and the Is/Is Not Matrix.
A stakeholder analysis is a quick way to identify how various people within an organization
relate to a project and how the team should keep them informed. Begin the analysis with a
grid drawn over an x and y axis. The vertical axis represents the amount of power a person
has in the organization. The horizontal axis represents the amount of interest a person has
in the team’s project. The stakeholder analysis works best when teams conduct it on a
whiteboard or large flipchart. Draw the basic diagram, as seen in the figure below, in large
format.
175
DEFINE
Provide the team with sticky notes. Ask them to write down possible stakeholders for a
project or process. Stakeholders are anyone who has an interest in the project, who might
benefit from the outcome of the project, or who might be impacted by the work done via
the project. Take a few minutes to discuss the names that were brainstormed and discard
any the team feels are not actually stakeholders.
Once the team decides who the stakeholders are, begin placing the names on the chart
according to power and interest. People with both low power and little interest will be
placed in the lower left corner. People with higher power and low interest are placed in the
upper left; people with less power but a lot of interest are placed in the lower right corner,
and people with high levels of power and a lot of interest are placed in the upper right
corner. A name might be placed high and to the right of the lower-left corner if the
stakeholder has a moderate amount of interest and power, but the team doesn’t feel like
the person quite crosses the line. Likewise, a name placed at the lower bounds of any
quadrant might show lower amounts of power than those placed nearer the top of the box;
the stakeholder analysis lets teams prioritize stakeholders in this manner, even within the
four quadrants.
176
Each of the quadrants of the diagram correlate loosely to the type of stakeholder, providing
some guidance on how the team might interact with each person or department listed.
Top Left: Keep Satisfied
Stakeholders that fall into the top left quadrant of the diagram have enough power that
they could interfere with a project, but they aren’t extremely interested in the day-to-day
outcomes. The team should ensure these individuals are satisfied in whatever way they do
interact with the project. Teams might also consult with these individuals at various times
during the project. For example, a team working to solve problems of shipping in a
warehouse might need to consult with procurement managers at some point because the
team identifies a need for a different type of packing tape. Procurement leaders have
power over obtaining the resource, but they might not have a great deal of interest in the
project overall.
Sometimes, teams might identify a stakeholder that falls into this section and realize that it
would be valuable to the team for that particular stakeholder to be more invested in the
project. Six Sigma leaders can work with stakeholders to try to move someone from low
interest to high interest categories – this is a political tactic that some teams use to bolster
support for a project.
Bottom Left: Minimal Effort
Stakeholders that fall into the bottom left quadrant have the least important connection to
a project. Teams will mostly communicate general information about a project via
newsletters or email to these stakeholders. While these stakeholders take minimal effort
from teams, some situations might exist where teams want to move stakeholders from this
box to the lower-right box.
Bottom Right: Keep Informed
Individuals in the lower-right box have a strong tie or interest in the project, but do not have
access to power to support projects from a resource standpoint. These stakeholders might
include employees in departments related to the process being improved or subject matter
experts that will be consulted about individual aspects of a project.
While stakeholders in the lower-right quadrant can’t usually bring resources to bear, they
can act in support of a project, often in the form of a goodwill ambassador.
Top Right: Key Player
177
DEFINE
Individuals in the top-right quadrant are either key players regarding a process or executive
leaders with the ability to assign resources to a project. These are the individuals teams will
report to at various tollgates; often, the executives responsible for the ultimate success of a
process or project appear in the top-right quadrant.
The In and Out of the Box method is a quick and easy method that helps teams define
project or process scope. Begin by drawing a large box on a whiteboard or flip chart. Provide
markers and sticky notes for the team. Ask the team to write down elements of the process
to be worked on, including resources, activities, and people. Each item should be written on
a sticky note. Work together to create as complete a list as possible, placing the sticky notes
on a wall or table as you go. Make sure everyone on the team understands that there are
no wrong answers and the first phase of the exercise doesn’t require discussion. By
brainstorming items with little-to-no discussion, teams can capture more ideas, leading to a
more accurate picture of what is in and out of scope.
Once a comprehensive list is made, begin working as a team to assign each item to a place
inside, on the line, or outside of the box. Items outside of the box are those that will be
considered out of scope for the project. Teams might place items outside of the box
because they don’t have access or control over the items, they don’t have time to work on
the items, or they have specifically been told not to include the item in the project.
Items that are within the box are considered in scope for the project. These should be
elements of the process the team can reasonably be expected to influence. If the team isn’t
sure yet where an item might fall, they should place it on the line. Items that go on the line
might be ones that the team hopes to be able to impact but for which the team leader
needs to seek permission or assistance from someone outside the team.
Once all items are placed on, in, or outside of the box, review the placements as a team and
make any changes. Document the exercise by photographing the diagram or recreating it on
a computer. The team might reflect back on the diagram when attempting to control scope
creep or considering who they should approach for help with a project.
The Is/Is Not Matrix is another quick brainstorming tool teams can use to define scope. It
can also be used to help define some of the information necessary to a problem statement.
The matrix works by considering specific things about the process or project and coming up
with both is and is not answers.
178
For example, if a Six Sigma team is tasked with determining why the furnaces in a certain
factory are not heating to proper temperatures, they might create an Is/Is Not Matrix like
the one below.
Is Is Not
Where South plant North or East plan
What Steam furnaces Wood furnaces
When January 2015 Prior to January 2015
The matrix clearly shows that the scope of the project only includes work at the south plant
on the steam furnaces. The problem was noted in January 2015, which provides the team
with a starting point for gathering data. This is a very simple matrix; teams can ask as many
questions as they like to narrow down scope or better understand processes and projects
through the Is/Is Not structure.
A successful define phase ends with all of the following deliverables:
o A comprehensive project statement

o A team charter
o An understanding of the process and a project diagram or map
o An understanding of the Voice of the Customer
A definition of what success will look like that has been agreed on by the team members
and any sponsors or executive leaders
179
DEFINE
Team Charter Template

Project Name:
Team Members Sponsor:
Name Role Time
Commit
CTQs:
Financial
drivers:
Internal
Customers:
Non-Customer In Scope
Stakeholders
External
Customers:
Out of Scope
180
Problem Statement:
Objective/Goal
Project Schedule:
181
Moving from the define phase to the measure phase of a project, Six Sigma teams continue
to delve into the process, now coming to understand processes more fully through data.
The measure phase is often the most laborious phase for the team, especially when data is
not already available in digital formats. In this chapter, we’ll review some of the metrics
covered in previous chapters and introduce some concepts for data collection. We’ll
continue building on the concepts of measure introduced in later chapters on statistical
analysis.
One of the first steps of the measure phase is determining the capability of a process. This
step can be completed before a team formally leaves the define phase if the data needed to
perform sigma level calculations is available. Calculating sigma levels for a process was
covered in Chapter 1. In addition to sigma levels, teams might also calculate various metrics
for a process, including defects per million opportunities, FTY, or RTY, which were all
covered in Chapter 5.
The Failure Modes and Effect Analysis is a tool that can be applied by a Six Sigma team in
any phase from define to analyze. Often, teams begin working with FMEAs in measure
because it helps them identify risk priorities for various inputs and errors within a process.
Used properly, the FMEA uses systemic data and team input to set the stage for root cause
analysis in the next DMAIC phase. Remember, while tollgates do occur and teams move
through five phases during a DMAIC project, hard borders don’t always exist between the
phases. Teams might begin working on measure phase tasks before leaving the define
phase, and it’s almost certain that teams will begin some analysis while still collecting data.
Ultimately, an FMEA tool should be used when teams need more detailed information
about inputs and possible associated fail-points than the tools discussed in the define
chapter allow. The FMEA offers some of the information that is offered by SIPOC, but it also
provides evaluations of the inputs. Teams typically create FMEAs in a spreadsheet program,
as some calculations are required during the process.
To create an FMEA, create a spreadsheet with the following column headers:

182
1. Process step
2. Potential failure
3. Potential failure effect
4. SEV
5. Potential cause of failure
6. OCC
7. Current monitor/control
8. DET
9. RPN
10. Recommended changes/actions
11. Who and When?
12. Action completed
13. SEV
14. DET
15. RPN
Columns 1 through 9 of the FMEA might be completed during the measure phase while
columns 10 through 15 are more appropriate for the improve phase.
Begin by identifying all possible process steps, activities, or inputs in column one. In column
two, indicate what might go wrong for each process step. Note that you can list process
steps more than once if there are multiple opportunities for error within each step. If the
team has created a detailed enough list of steps, however, this won’t likely be the case for a
majority of the steps.
In column three, enter a short description of the impact of the failure on the customer.
Incorrect measurement can result in increased variance in a product, for example. In the
SEV column, rate the severity of the possible failure you described in the previous columns.
Rate the severity from 1 to 10, with 1 being no effect, 5 being minor disruption to
production, and 10 being severe enough to endanger a process or person.
In column five, enter the potential reasons the specific failure might occur, and in the OCC
column, enter a numeric rating for how often the failure might be expected, with 1 being a
very unlikely failure and 10 being an almost inevitable failure.
In column seven, create a short description of the current controls that are in place to
monitor the process or prevent the failures the team has described. In the DET column, rate
the ability of the process or staff to detect failure if it does occur. Rate detection between 1
183
MEASURE
and 10, with 1 being a process that includes automated detection that rarely fails and 10
being no detection at all.
Finally, calculate the risk priority number by multiplying the severity, occurrence, and
detection ratings, as in the example below.
A Six Sigma team working on a project to improve the speed with which refunds are
processed to customers is creating an FMEA. One row of the FMEA includes the following
information:
 Process step: Refund request is entered in system.

 Potential failure: Incorrect amount is entered.
 Potential failure effect: The customer receives more or less refund than
anticipated.
 SEV: 8
 Potential cause of failure: Data-entry employee transposes numbers or makes a
similar typing mistake.
 OCC: 10
 Current monitor/control: A supervisor randomly reviews a sample of refund
requests to ensure accuracy.
 DET: 7
 RPN: (SEV * OCC * DET) = (8*10*7) = 560
The team completes a second row as follows:
 Process step: Refund check is printed.

 Potential failure: The printed check has defects that make it difficult to cash.
 Potential failure effect: The customer can’t cash the check and has to call for a
new one.
 SEV: 9
 Potential cause of failure: Printer is misaligned or out of ink.
 OCC: 1
 Current monitor/control: The person who signs the checks reviews the checks
as they sign them.
 DET: 2
 RPN: (SEV * OCC * DET) = (9*1*2) = 18
184
The potential failure in the first example has a much higher risk priority number, which
means, as the team moves forward, they are more likely to work on solving that potential
failure. During analyze and improve phases, the team would recommend changes,
implement the recommended actions, and rescore the process to determine if the RPN of
the changed process is lower. If it is higher or the same, then the change was not a good
one and the team might need to try again.
Creating a baseline metric for a process begins in the define phase, but teams cannot leave
the measure phase without a strong understanding of current process performance. That
understanding begins with figures such as sigma level, but teams should also define a
process-specific metric where possible and gather historical data regarding that metric so
they have something to compare future data against to prove that improvements were
made.
Ideally, the team would have access to historical metrics for the process. In some cases, the
team has to collect data from scratch. We’ll introduce data collection later in this chapter
and cover it in depth in the units on sampling.
Before creating and displaying a baseline metric via graphical representation, you have to
understand the type of data you are dealing with. Data is either discrete or continuous, and
teams collect data either as a population sample or a process sample. How teams collect
data and the type of data collected determine how the data can be viewed graphically and
analyzed.
Discrete data is categorical in nature; it is also referred to as qualitative data or attribute

data. Discrete data falls into three categories: ordinal, nominal, and binary, or attribute,
data; some data collected can be expressed in one or more of the discrete categories. For
example, student test scores can be conveyed in an ordinal fashion via the grades A, B, C, D,
and F or in a binary fashion via the Pass/Fail distinction.
Discrete data can be displayed via Pareto charts, pie charts, and bar charts. In some
instances, the data can be converted to run and control charts using variation within the
data or ratios as the item being charted. In the chapter on the control phase, you’ll begin
185
MEASURE
understanding why a team might want to convert discrete data to be used in a control
chart.
Within discrete data, binary or attribute data is usually the easiest data to collect. Attribute
data records one of the other answers. Does the person choose paper or plastic? Is the
room hot or cold? Is the glass empty or full? Is the light on or off? Depending on the
scenario, attribute data can be very accurate. The light is either on or off; the switch
position tells you that. Attribute data in this case can be automated with the right
technology, which means it would be highly accurate. Whether the cup is empty or full is
another story, because there are so many variations between completely empty and
completely full. If the data is being collected by people, personal biases might enter the
equation. Teams can remove some of those biases and better ensure accurate
measurements, which will be covered in the sections on measurement systems.
Continuous data is quantitative data and is measured in units. For example, the time of day
is measured in hours. Temperature is measured in degrees, and almost anything can be
converted to continuous data by making it a percentage.
Continuous data is visualized in graphs such as histograms and box plots. Box plots are
discussed in chapter 14, and histograms are covered in depth in the chapters on statistics.
Continuous data can also be viewed in the form of run and control charts.
Sometimes, a process or activity can be measured in both discrete or continuous data.

Depending on the purpose of the measurements, teams might need to pick between the
two data types. For example, if a Six Sigma team has identified room temperature as an
input into the quality of product, they will want to monitor the temperature of the room.
They can do so by recording the temperature in degrees every ten minutes; that data would
be continuous. Alternatively, the team might create a tick sheet, having someone make a
mark every hour to note whether the temperature was in the 40s, 50s, 60s, 70s, or 80s with
regard to the Fahrenheit scale. That data would be discrete.
In this particular example, most teams would choose to record the continuous data. Exact
temperature measurements every 10 minutes provides a lot more information than
whether the temperature of the room was in the 70s at the turn of the hour. The
continuous data could be converted to provide teams with the discrete data easily; the
discrete data in this case – and in most cases – could not be converted to continuous data.
186
What is true in the example is true for most scenarios. When possible, teams should convert
measurements to continuous data. Continuous data:
 Provides more information than discrete data does.

 Is typically more time-consuming to collect than discrete data unless teams have
access to automated or computerized data collection.
 Is more precise than discrete data.
 Lets teams remove variation and errors inherent in estimation and rounding.
Data can be classified at four basic levels: nominal, ordinal, interval, and ratio. Attribute, or
binary, data is actually a limited form of nominal data.
Nominal is considered to be the lowest data classification level and simply involves applying
number labels to a qualitative description so statistical analysis programs and tests can be
applied to the data. The numbers assigned to each category don’t provide any information
about whether the data is better or worse than other data in the listing – in nominal data,
numbers don’t reflect a scale.
An example of nominal data might be applied in a list of birth states for a classroom. In a
class of 30, the number of students born in various states breaks down as follows:
 Texas: 6
 Louisiana: 4
 Arkansas: 10
 Mississippi: 1
 Oklahoma: 9
In nominal data, each state would be provided a numeric label:
1. Texas
2. Louisiana
3. Arkansas
4. Mississippi
5. Oklahoma
187
MEASURE
That doesn’t mean 5 students are from Oklahoma; it means 9 students fall into category 5
for the question “What state were you born in?”
For nominal data, central tendencies are calculated not with means or medians, but with
mode. For example, a list of the nominal data in our example would be as follows:
1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5
The mode is the number that appears most in the set; in this case, 3.
Statistically, analysis is limited with regard to nominal data, but some tests can be
performed with statistical analysis software.
Ordinal data is considered to be a higher form of data than nominal, though it still uses
numbers and categories to identify data elements. With ordinal data, though, the numbers
themselves actually provide some meaning. The numbers used in the FMEA scales at the
beginning of this chapter were ordinal data. The numbers are qualitative in nature, but they
are also ranked. Central tendencies with ordinal data are measured by either the mode or
the median, and common uses for this type of data include ranking various things against
each other or rating a specific thing, such as a movie or pain level.
Ordinal data can be arranged in an order that makes sense: on a 1 to 10 scale, Suzy rated
the movies as 2, 5, 6, and 9. If one is the worst and 10 is the best, then we can assume Suzy
liked the last movie best.
While ordinal data comes with a logical order, the intervals between the numbers don’t
mean anything. If Suzy rated movie A as a 10 and movie B as a 9, the conclusion is that she
liked movie A better. Exactly how much more she liked the movie is not discernible using
ordinal data.
Interval data is an even higher form of data classification. Interval data provides numeric
values that can be arranged in a logical order with meaning; the big difference between
ordinal and interval data is that the difference between each interval value provides
meaning. If Frank is keeping track of the temperature in his house and he sees that at 8:00
a.m. it was 76 degrees and at 9:00 a.m. it was 80 degrees, he not only knows that 9:00 a.m.
was hotter; he knows that it was 4 degrees hotter at 9:00 a.m. than at 8:00 a.m. Interval
data is continuous, or quantitative, and offers more flexibility when it comes to statistical
analysis.
188
Ratio data is considered to be the highest of the data classifications. Ratio data has an
absolute zero point, can be both discrete or continuous in nature, and provides the highest
capabilities for statistical analysis in many cases. Some examples of information that can be
recorded using ratio data include force, defects per million opportunities, voltage, height,
units per hour, and volume.
Measurement systems analysis applies scientific principles to help teams analyze how much
variation a system of measurement brings to a process. The purpose of the MSA is to
identify errors of accuracy within data collection tools. Teams can then redress
measurement systems to create more accurate data captures or, if that isn’t possible, take
the possibility of errors into account when performing analysis on data.
During measurement systems analysis, teams should review multiple components of

possible measurement error. Six Sigma teams analyze:
 Whether bias occurs in the accuracy of measurements

 Whether the measurement has the proper resolution
 What measurement scale linearity exists
 Whether measurement activities are stable over time
 Whether measurements are repeatable and reproducible
Depending on the measurements the team is dealing with, the MSA can be time consuming
and is often why the measure phase of a DMAIC project is one of the longest.
In this stage of MSA, teams define the difference between the most accurate measurement
possible and the data being collected by the current measurement system. The goal of a
measurement system is accuracy: coming as close as possible to a defined target, if not the
exact measurement. For example, in a computer manufacturing plant, one employee might
solder a chip to the motherboard. For the rest of the chips and wires to be added to the
motherboard, the chip must be placed within a 2 mm area. In this case, a measurement tool
might be implemented with a required accuracy of plus or minus 0.5 mm to ensure the chip
is placed within the area targeted.
Teams can ensure accuracy of data by verifying that the gauge used to collect data is
performing accurately. If a digital scale is being used to weigh ingredients, teams should
189
MEASURE
calibrate the scale using calibrated weights. If templates are used on a factory floor to make
measurements more efficient, teams should ensure those templates are accurate by
comparing them against known measurement tools such as verified rulers and scales. Note
that, for the purpose of the MSA, accuracy reflects the performance of the measurement
tool, not the operator. Whether the employee uses the measurement tool correctly or
records the amount correctly is considered a concern of precision, which is covered later in
this chapter under R&R Gages.
Once a Six Sigma team is confident that a measurement tool is properly calibrated, they can
instruct employees or others who are responsible for recording data. Data should be
accepted as it is collected for most efficient access and because early review can turn up
specific problems with data collection. When possible, teams should not round data but
collect it as it is recorded.
If data is being collected manually, employees should have a data collection template that
prompts them to collect data at appropriate times and record information about the data
collection event, including the person collecting the data, the machine or process involved,
conditions of the environment – especially those that are different from normal conditions
or might have a direct impact on measurements – and the measurement tool being used if
multiple tools are an option. These details help Six Sigma teams rule out outliers, which are
discussed in the next chapter.
Before measurements are passed to the analyze phase, Six Sigma experts should review
data to ensure there are no misplaced or missing decimal points, that duplicate entries
haven’t been recorded, that frequency-based measurements aren’t missing points, or that
any other obvious issues haven’t occurred with the data. Addressing obvious data problems
before beginning analyze phases reduces the chance that teams will come to false
conclusions about root causes or viable solutions for a process.
Measuring at the correct resolution ensures that a measurement system can detect change
in the data or process appropriately. For example, if a Six Sigma team is working to improve
a process that cuts pipe for bathroom fixture installations, it might be concerned with the
length of the pipe. In reviewing the measurement system for the cut pipe, the team finds
that the process includes measuring the pipe to the nearest centimeter. If, however, pipes
that are off by several millimeters cause issues in the installation, then the nearest
centimeter measurement is not a small enough resolution.
190
A good rule of thumb to follow for resolution is called the 10-bucket rule. Break your
measurement resolution into a tenth of what is required. If the pipe must measure within a
range of 5 mm to perform, the measuring tool should measure to the ½ mm. In another
example, a food service department might be tasked with maintaining the correct
temperature in a freezer. To monitor the temperature, an employee records the
temperature once per hour. If temperatures fluctuate quickly in the freezer, a change in
temperature that would impact quality of food or ingredients might come and go between
recordings. In this case, the proper resolution might be gained by recording measurements
every 10 minutes or every six minutes for 10 readings per hour. Even better, in a freezer
with a digital thermostat connected to a network, teams might be able to access readings
recorded every minute.
Resolution is usually one of the easiest things to correct within a measuring system, but it
isn’t always cost-effective or plausible to measure at the most detailed resolutions. Teams
should consider resource requirements when developing a measurement system. If,
however, the most detailed resolution is possible, measurements obtained will provide
more information about the process and a larger sample size from which to work.
Linearity describes how a measurement system performs across a range. A standard metric
ruler in the hands of most people is fairly accurate at measuring centimeters, but is less
accurate at measuring millimeters or kilometers. A scale with a range between 0 and 10
kilograms might measure less accurately at either end of the range.
Taking measurements at various ranges with an existing measurement system and

comparing those measurements to data gathered with tools known to be accurate across all
ranges can help teams find errors of linearity. In some cases, teams can develop
mathematical equations to account for the discrepancies. For example, if the scale is
accurate at 5 kilograms, but is off by an extra quarter of a kilogram for each kilogram
thereafter, a measurement of 8.5 kilograms would actually be:
8.5 – ((8.5-5)*.25) = 7.625
If mathematical adjustments are not possible, then teams should not use measurement
systems to measure ranges where linearity errors regularly occur.
191
MEASURE
Stability describes the consistency of measurements over time. If operators are measuring
in the same way and using the same tools – and those tools don’t have any of the other
problems described above – then measurements should reflect stability on a control chart.
Control charts are introduced in Chapter 16 and covered in depth in later chapters on
statistical process control.
If the variation of measurements, as reflected on a control chart, do not indicate stability,

then teams might want to first rule out a problem with the measurement system before
determining that the process is out of control.
Gage R&R tools are used to ensure repeatability and reproducibility with regard to
measurement systems. In most cases, Gage R&R tools apply to measurement systems that
involve human operators and appraisers. Six Sigma teams apply Gage R&R tests to find
weaknesses within such measurement systems.
In Gage R&R testing, repeatability means that a single employee, using the same
measurement system and appraising the same things, can repeat his or her measurements.
Reproducibility means that multiple employees using the same measurement system and
appraising the same things come up with measurements that match or are very close to
matching.
Most Gage R&R tests fall into two types: attribute and variable. The premise for testing
each type of measurement is the same, though the criteria and statistical analysis following
the test differ slightly.
An attribute Gage R&R is used when Six Sigma teams are analyzing measurement systems
for go/no go data. For example, if operators review an item in the product line and decide
simply to pass or fail it, this would be an attribute measurement. In the example of the
freezer measurements above, an employee might simply be tasked with recording whether
the temperature was in an appropriate range: a yes/no measurement. As previously stated,
attribute measurements provide the least information about a process, so in the case of the
freezer temperature, it’s better to record the actual temperature. Whether that recording
was within appropriate range can be determined systemically from the temperature data.
192
When attribute data is used, an attribute Gage R&R is used to test the measurement system
following the steps below.
1. Select at least two appraisers.

2. Provide a number of samples. Label the samples in a way that you know which
one is which but that wouldn’t identify the sample for the appraiser.
3. Record the actual attribute measurement for each sample according to the best
possible (most accurate) measurement you have.
4. Have each appraiser record the attribute measurement for each sample
provided (go/no go; yes/no; hot/cold; pass/fail; etc.).
5. Repeat the process with the same samples and appraiser, randomizing the
order in which you present the samples. Randomizing sample order the second
time appraisers are presented with them reduces the chance that appraisers
remember what measurement they recorded the first time and record the
same measurement by default.
6. Enter all data into a spreadsheet or Gage R&R file similar to the one below that
shows a test of a pass/fail measurement.
Sample Actual Appraiser 1 Appraiser 2 Agreement

Label Attribute
Trial 1 Trial 2 Trial 1 Trial 2 Yes/No?
1 P P P F P No
2 P P P P P Yes
3 P P P P P Yes
4 F P F F F No
5 P P P P P Yes
6 F F F F P No
7 F P P F F No
8 P P P F F No
9 F F F F F Yes
10 P P P P P Yes
193
MEASURE
From the Gage R&R above, you can see that the measurement system is reproducible only
50 percent of the time, making it a poor measurement system. It is repeatable 90 percent of
the time for Appraiser 1 and 80 percent of the time for Appraiser 2, and the appraisers are
accurate 80 percent and 70 percent of the time respectively. Given these results, a Six
Sigma team might determine that there is some problem of clarity with instructions for how
to determine whether a sample is a pass or a fail. The chart above only provides data for a
set of 10 samples; more accurate attribute Gage R&R testing usually requires at least 20
data points.
Not all data is attribute data, which is why teams can also perform variable Gage R&R tests.
While the raw data from a variable Gage R&R test can provide a Six Sigma team with a
picture of whether a measurement system is obviously failing or not, statistical analysis is
usually required to make a true determination about the performance of a measurement
system. This is because, with variable measurements, some differences between
measurements and operators is likely, particularly when measuring to very small or large
figures or capturing data in a moving measurement.
Set up a variable Gage R&R test in much the same way you set up an attribute test, using
two to three appraisers and at least five to ten outputs to be measured. Have each
appraiser measure each sample two or three times, randomizing the order in which samples
are presented to avoid appraisers remembering the measurements initially entered. Record
all data on a variable Gage R&R template, such as the example below.
194
Sample Actual Appraiser Appraiser Appraiser 3 Variation

Measurement 1 2
The statistical analysis performed in Excel SPC or Minitab by a Black Belt or Green Belt
typically returns four figures:
 % Study Variation
 % Tolerance
 % Contribution
 Number of distinct categories
Teams should look to ensure all four elements of a variable Gage R&R test calculation are in
what are considered “safe” ranges. Commonly, each element comes with a scale for safe, or
green, zones along with caution zones and failure zones. If one of the elements falls into a
caution zone and all others into the green, then a team will likely conclude that the
measurement system is sufficient. In some cases, all or a majority of caution zone scores
might be deemed acceptable, particularly if making the measurement system any more
accurate would be costly or cause application issues for other processes. Measurement
systems that score in the failure zone for any element should probably be repaired or
replaced.
Common criteria used to judge each element of the variable Gage R&R calculations are as
follows:
195
MEASURE
Element Pass Caution Fail
% Study Variation 0 to 10 10 to 30 30 and above
% Tolerance 0 to 10 10 to 30 30 and above
% Contribution 0 to 1 1 to 9 10 and above
# of Distinct 10 or more 6 to 10 1 to 5
Categories
Note: Another tool that is effective in identifying variation in a measurement system is

called the ANOVA, or Analysis of Variance. ANOVA is also useful for analyzing variation of
any type, and will be covered in Unit 5 on intermediate statistics.
Once teams are sure the best possible measurement tools are in place, they can begin
collecting data to be used in the analyze phase of the DMAIC project. The most accurate
conclusions come when a team can analyze data for the entire population, but that is rarely
possible due to time and cost constraints. If you can gain access to automated data or data
warehouses, you might be able to collect population data or extremely large sample sizes
that better approximate population data. Otherwise, Six Sigma teams must randomly
sample the population that is available and use those samples to draw conclusions about
the population as a whole.
To ensure samples can be used to draw statistical conclusions, they must be handled
correctly and be the appropriate size. In this section, we’ll simply cover the types of
sampling strategies that Six Sigma teams might use and why.
Simple random sampling works when there is an equal chance that any item within the
population will be chosen. For example, if you put 20 marbles of the exact size, weight, and
texture in a bag and blindly select one, each marble in the bag has a 1 in 20 chance at being
selected. If the marbles are different sizes or weights, those differing attributes can impact
the chance that each marble will be selected. Heavier marbles might sort to the bottom of
the bag; bigger marbles might be more likely to be picked up.
196
Random sampling for statistical analysis requires that the sample will represent similar
attributes and percentages as the entire population. The population is “N” items large. The
sample size is “n” items large. How big the sample needs to be to statistically represent the
population is decided by a number of factors.
Stratified sampling occurs when the population as a whole is divided or can be divided into
subgroups with differing attributes. For example, if a shipping company wants to test the
accuracy of its estimated shipping times against actual shipping times, it might assume that
the results will vary according to the distance a package has to travel. By randomly selecting
samples from the entire package population, there’s a chance the company might only end
up with samples for packages delivered within a 200-mile radius.
To prevent bias in the data, the shipping company might divide the population into four
subgroups:
 Deliveries within 200-mile radius

 Deliveries within 201 to 400-mile radius
 Deliveries within 401 to 600-mile radius
 Deliveries over 600 miles
By sampling randomly from the stratified subgroups, the team ensures a sample size with
less bias.
Sequential sampling involves selecting every X item for inclusion in the sampling. Sequential
sampling can be used when teams are collecting data at intervals such as time. The team
might collect data every 10 minutes. Sequential sampling can also be used to sample
physical items; every 5th item on a product line might be reviewed. Given the right
parameters and enough time, sequential sampling can provide valid statistical results.
Teams must be cognizant, however, that the sequence of the sampling could, in rare cases,
skew results. It is possible, for example, that something occurs during every 5th iteration of a
process that causes a difference to occur.
Non-random sampling should not be used when dealing with statistical analysis because it is
more likely to introduce user or sampling error. While all sampling comes with some form of
197
MEASURE
error, random sampling errors can be calculated and accounted for in analysis. The same
cannot be said of non-random samples.
Non-random sampling includes convenience or judgment sampling. Convenience sampling

occurs when a team takes the most convenient measurements. “We want to know about
the process right now, so let’s review the next dozen items that come off the line.” That
type of analysis only truly tells the team how the process performed at that exact moment
in time.
Judgment sampling occurs when an expert or knowledgeable person is tasked with

“selecting” appropriate samples. A supervisor might say to his or her team members,
“Select some of your work that represents the normal way you function in a given day.” In
most cases, the team members select what they believe is better quality work, skewing any
results from the sample.
One of the major deliverables coming out of define and measure phases is the baseline
metric. How is the process performing now, and what measurement will the team use to
compare current performance to post-improvement performance?
Baseline metrics are numbers, but most teams find that presenting the metric graphically
resonates best with business resources and executives. Visual representations also provide
teams with a quick way to determine if progress is occurring.
The type of visual representation you use depends on whether your major metric is discrete
or continuous. Discrete data can be displayed on Pareto charts (see Chapter 5) and
continuous data can be displayed via run charts. You can also use variation or other
calculations to convert discrete data to continuous data for display in run charts and control
charts (see Chapter 16 for information about control charts).
A run chart can be used to monitor the performance of any variable or process over time.
With a single, intuitive chart, Six Sigma teams can display trends, shifts, and cycles within a
process; they can also monitor a process for concerns, though run charts are not as
effective at this as the very similar control chart is.
A basic run chart is simply a line plot of the data over time, which means anyone can create
the chart. Most Six Sigma run charts also feature a line representing the median of all data
points for visual reference. Depending on the type of information being charted, you may
198
need to convert data to a ratio for a more accurate run chart. For example, if you are
plotting the temperature of a surface over time, there is no need to convert data. If you are
plotting the number of patients readmitted to a hospital within 30 days of being discharged,
then it helps to convert the data to a percentage of the number of patients discharged
within the same time period. In a 30-day period where 10,000 patients were discharged,
you can expect a higher number of returns than a period during which only 5,000 patients
are discharged.
The figure below illustrates a run chart of temperature over time. You can see how
temperature changes through time and begin to see some possible trends. A Six Sigma team
would be able to zoom out, viewing the run chart over more time to validate trend
assumptions. You can also see that the median temperature for the process is 33.
The run chart below indicates the number of returns per hundred sales for each month of
the year. You can see that returns as a rate of sales increases steadily during the first part of
the year before holding steady from May through November. The orange line indicates the
median returns per hundreds sales, which is just under 7.
199
MEASURE
Statistical analysis software, including Minitab and Excel SPC, creates all elements of a run
chart automatically from entered data, but anyone can use basic Excel functions to create a
run chart if needed.
First, create a data table.
Creating a data table for a single attribute, such as temperature, just requires entering the
time labels in one column and the attribute measurements in another. For the example,
we’ll walk through creating a rate data table, since it involves additional steps.
1. Enter the data labels (month, week, hour, etc.) in the first column of Excel.
2. In the next column, enter the corresponding measurements for the attribute you
are interested in: in this case, the total number of returns per month.
3. In the third column, enter the total number of items you are comparing the
attribute to: in this case, the total number of sales per month.
200
4. In the fourth column, calculate the percentage the first column of data is of the
second. In this case, the percentage of returns per sales for each month. The
calculation is achieved in this case by the formula =B2/C2 for January, =B3/C3 for
February, and so forth.
201
MEASURE
5. Decide whether you want to create a run chart showing percentages, or if you
would like to create the chart illustrating rate per 100, per 1,000, etc.
6. If you want to illustrate a rate per (x), multiply the percentage calculation in the
fourth column by (x). In this case, the figures in column D are multiplied by 100.
7. Use Excel to calculate the median of the number you plan to chart. The median is
calculated with the formula =Median(Number 1, Number 2,…), where the numbers
in the formula correlate with the range of all the charted data points. In this case,
the median is 6.96679
8. Highlight the data labels (in this case, column A) and the figures to be charted
(column E)
202
9. Select Insert > Charts > Line Chart to insert a line chart of the attribute or attribute
calculation.
10. Select Insert > Shape > Draw Line.
203
MEASURE
11. Draw a line on your run chart approximately where the median would be. Use Excel
tools to select a color and thickness for the line that you desire.
The completed run chart can be used to present information to the Six Sigma team or
include a graphical representation of baseline process performance in a measure phase
tollgate presentation. Again, it should be noted that manual creation of a run chart is not
required for most Black Belts and Green Belts, who will have access to statistical analysis
software.
Use the checklist below to determine whether a team is ready to move from the measure
phase to the analyze phase of a DMAIC project.
204
o The team has agreed upon the key measurements and come up with a baseline
measurement of process performance.
o The team has analyzed measurement systems and identified any issues that might
contribute to analysis errors.
o Where possible, the team has corrected measurement systems to remove error
risks.
o The team has calculated process variation and sigma level.
o The team has conducted appropriate sampling to allow for statistically valid
conclusions in the next phase.
o The sponsor or champion has reviewed and signed off on all elements of the
measure phase.
205
If the chapter on the measure phase seemed especially long, it’s because the phase itself is
long and requires a great deal of work. Without a strong measure phase, the team cannot
move on to analyze data and make data-based decisions that drive improve and control
phases. Analyze phases also require a lot of work, but that work is usually performed by
Black Belts and Green Belts, who report findings to the Six Sigma team and ask for feedback
about analysis and verification of analysis.
In this chapter, we’ll discuss a number of tools that might be used by Six Sigma teams during
the analyze phase, but we’ll also reference other chapters and units. Units 4, 5, 7 and 8
provide in-depth information about the statistical tools referenced throughout this chapter.
One of the fundamental activities of the analyze phase performed by the entire team with
help from identified subject matter experts is the root cause analysis. Root cause analysis is
used to identify root causes for problems or defects when a team has reached the analyze
phase without a clear idea of primary causation. Some of the tools described for identifying
root causes in this chapter could be used in either define or measure phases at the
discretion of the Black Belt leading the team; the FEMA described in Chapter 13 on measure
could likewise be used in the analyze phase as part of root cause analysis.
A popular method for brainstorming and analyzing causation in a process is the fishbone
diagram. The fishbone diagram can be completed by a single Six Sigma expert, but it
typically has more value when it is completed by the entire Six Sigma team. The diagram
lets teams concentrate on a brainstorming process that generates ideas about possible
problem causes, organizes those possibilities in a logical way, and lets teams visualize the
information to identify priorities, trends, and relationships between ideas. When used as a
team activity, the fishbone diagram encourages participation and input from all team
members, which increases the chance of laying the foundational work for a viable and
original solution.
206
The cause and effect diagram is called the fishbone diagram because you begin with what
looks like a simple drawing of a fish skeleton. Reference the diagram below and follow the
instructions to create a fishbone diagram as part of a team brainstorming exercise. You can
also use these instructions now to practice a fishbone diagram based on a process or
problem you have experience with.
1. Sketch a basic fishbone shape on a whiteboard or large flipchart. Write a

summarized version of the problem where the fish head should be. Note: You don’t
have to conduct a fishbone diagram only on the problem statement from the define
phase. Teams might also conduct the diagram on a specific defect or issue found
during the define or measure phase. For example, if the problem statement
discusses the amount of waste in a restaurant, the team might have discovered
during the measure phase that bread is being thrown away at a rate higher than all
other food items. One of the activities handled in the analyze phase might be a
fishbone diagram specifically about the reason for so much bread waste.
2. Draw a fish spine and four major connectors. Label each connector as People,
Process, Materials, and Procedure. Some Black Belts also include two other major
connectors: Equipment and Environment.
3. Explain the categories of the fishbone diagram to the team. Note that there are
some places, especially with particular processes, where the various categories will
overlap. Some ideas generated by the team as they complete the fishbone diagram
might fit in more than one category, and that’s okay.
a. People references anyone who carries out or interacts with a process.
b. Process or machine refers to the process by which inputs become outputs.
207
c. Procedure or method refers to the way things are done, whether by written
documents or unwritten rules.
d. Materials are the inputs, such as raw goods, into the process.
e. Equipment includes the technology or machines required to handle the
work.
f. Environment is the immediate area surrounding the process.
4. Begin with each category on the fishbone diagram, asking the team how something
in that category might be responsible for a problem or defect.
5. Use sticky notes to write down ideas and place them on the fishbone diagram so
you can move ideas around later. You can also write directly on the diagram.
6. Couple cause-and-effect brainstorming with the 5 Whys exercise described in
Chapter 6. For each branch of the fishbone diagram, ask “Why?” at least five times
to ensure the most granular detail possible.
7. Once the team has run out of ideas for the first category, repeat steps 4 through 6
for all other categories.
8. Take some time as a team to review the diagram, discussing the placement of
potential causes, and moving them to appropriate categories and subsections to
create an organized visual representation.
9. Remove or cross-out causes that don’t prove to be valid after initial discussion.
10. As a team, decide which root causes seem most likely or highest priority. Circle
those causes as high-priority possibilities for further investigation.
To provide a better idea of how a fishbone diagram works, consider the example image
below and we’ll walk through how the team came up with the information recorded on the
procedure/method line of this diagram.
208
The team above was working to solve a problem of burnt cakes in a food-service bakery.
When discussing the method by which the cakes are being baked, the team first came up
the with the reason that the cakes were being baked at inconsistent times. Perhaps,
suggested one team member, staff weren’t paying attention and were leaving cakes in the
oven too long. The idea was written down.
The instructions for baking cakes are vague, said another team member – this time, a
subject matter expert from the bakery. “Why?” asked the team. The subject matter expert
responded that the instructions in the bakery don’t take various types of cakes into account,
leaving staff guessing about bake times for some cakes. Further “Why?” questions helped
the team determine that new cakes were added to the menu without the overall
instructions for bakery staff being updated.
After digging deeper into the inconsistent baking times, the team again asked themselves
how methods could be responsible for burnt cakes. Someone suggested that the
temperature in the oven was too hot, and the team tied that suggestion to the same root
cause as the inconsistent bake times. Upon final review, someone noted that the suggestion
that staff not paying attention was a cause wasn’t valid, because the bakery was equipped
with alarms that sounded when baking time was done. The team crossed that idea off the
diagram.
In this case, the Six Sigma team might prioritize the fact that instructions are not available
for all types of items being prepared in the bakery. Because this would likely be a simple
and common-sense improvement to make, the Black Belt might even assign someone to
begin working on the improve phase as soon as the cause was verified. Many times, the
root cause is not as obvious and the solution for the cause even less obvious, requiring
additional analysis and validation before moving forward.
Once teams identify possible root causes, they must verify that the causes are valid. Root
cause verification can be completed via a variety of methods, including statistical analysis,
design of experiments, logical questioning, observing a process, gathering additional data,
analyzing data via graphical representation, and mapping processes at a more granular level
than accomplished in the define phase. While this chapter touches briefly on statistical
analysis and graphical representation, those topics, as well as experiments and process
mapping, are covered in later units.
209
Whatever method is used to validate root cause assumptions, the Six Sigma team should
document it. Documentation regarding root cause verification is usually completed on a
matrix that includes the problem, possible root causes, the verification method, why the
verification method was chosen, results of the verification, and, in some cases, whether a
senior Six Sigma leader, such as a Master Black Belt, agrees. A template for such a matrix is
included below, but teams can also create similar documents in Excel or Word.
Problem Possible Method of Reason for Verified? Notes

Root Verification Verification
Causes Method
The root cause verification matrix for the burnt cake example might be completed as
follows:
210
Problem Possible Root Method of Reason for Verified? Notes

Causes Verification Verification
Method
Cakes in Temperature Run chart of Allows team to Yes

the too hot temperature visually
Delaware against determine
bakery are required whether
coming temperature temperatures
out burnt exceed
10 percent requirements at
of the any point during
time. bake process
Bake times Box plot of Provides visual Yes

inconsistent bake times representation of
per type of the variation per
cake cake type; bake
times should not
vary widely by
cake, so the
boxes should be
flat; lets teams
determine if
certain cake
types are more of
a problem.
Instructions Process Easy way to Yes

not provided observation determine if
to staff bakery staff have
the instructions
necessary to
complete work
without defects
211
Six Sigma experts and teams can use a variety of graphical analysis tools to help generate
ideas about root causes or understand how inputs and outputs really impact each other.
Some of those graphical analysis tools require statistical analysis software, and those will be
covered in later chapters. In this section, we’ll look at a few graphical representations you
can create easily with Excel.
The first graphical tool for validating root causes is the Pareto chart, which was covered in
chapter 5. Chapter 5 discussed the Pareto Principle, or 80/20 rule, which says that 20
percent of the causes lead to 80 percent of the results. Because of this, a Pareto chart is a
good starting point for root cause brainstorming – teams can start with the few inputs or
attributes accounting for the bulk of the Pareto chart. Just as you can “drill down” using the
fishbone diagram, asking deeper and deeper “Why?” questions, you can drill down using a
Pareto chart.
Consider the Pareto chart illustrating reasons for medical claims denials from Chapter 5.
In this case, the team might decide to concentrate on the top two claims denial reasons:
duplicate claim and timely filing. The team could use various methods for digging deeper
212
into root causes for these two claims denial reasons. They might perform a fishbone
diagram to discover why duplicate claims are being generated. To understand the timely
filing problem, teams might gather additional data for graphical analysis.
Timely filing means that the claim was not originally filed with an insurance company prior
to the deadline for claims submission. Different insurance companies have various timely
filing requirements, and the countdown usually starts at the time of service to the patient or
the time of discharge from a facility. The team might want to understand which payers are
denying claims for timely filing, so they collect data as follows on how many timely filing
denials are associated with each payer. Because Pareto analysis is concerned with the top
few, you can lump the many others together in a single entry and, for the purposes of the
Pareto analysis, ignore them. A medical provider might bill claims to dozens of providers;
including every provider on the data table and Pareto chart would be a waste of both time
and space for this particular exercise.
Payer Denials
A 3512
B 2779
C 1575
D 1142
E 945
F 847
G 702
H 502
Others 1241
Converted to a basic Pareto chart, the data is illustrated in the graph below.
213
It’s easy to see from the graph that the bulk of the problem is with payers A and B; perhaps
these companies have shorter timely filing guidelines than the other companies or billing
staff is unaware of the proper timely filing requirements for those payers. Six Sigma teams
can begin asking questions specific to these payers as they continue analyzing data and
discovering root causes.
Box plots are another graphical representation that can be handled with Excel. In later
chapters on statistical analysis, we’ll cover how box plots can be related to hypothesis
testing and other analysis. When differences between distributions are marked, however,
or when outliers are fairly obvious within data, the image of a box plot tells its own story
without requiring advanced statistical knowledge.
Box plots are often called Box-and-Whisker graphs. To understand how to read a box plot,
consider the data table and graph below. The data table shows the time in minutes in which
various runners completed a one-mile race. The results are divided into the categories
Children and Adults.
214
Children Adults
9.9 4.1
10.2 4.1
11.6 4.5
12.7 4.6
13.8 4.7
13.4 7.5
13.4 8.3
13.9 8.9
15.2 9.7
15.8 9.8
15.7 10.1
16.2 11.6
16.7 13.5
18.9 13.7
19.4 14.8
20.1 14.9
29 15
215
The above image shows a box plot of the data table, generated in Excel. Even without
further explanation, you can likely tell that the children completed the race on average
slower than the adults. The blue box, which represents the children, is shorter than the
orange box, indicating that the middle 50 percent of children completed the mile-long run
in times that had less variation than that of the middle 50 percent of adults. To understand
how this conclusion was arrived at, we’ll take a look at all the elements of a box plot.
A box plot begins with the upper and lower hinge – the top and bottom of the box. The top
represents the 75th percentile; the bottom represents the 25th percentile of the data. The
line within the box represents the 50th percentile. Within the box are the 50 percent of data
points between the 25th and 75th percentiles.
Each box plot receives upper and lower whiskers indicating the range of most of the other
data within a set. In this case, Excel creates whiskers that extend to the top and bottom of a
range barring any statistical outliers. Some statistical analysis software or methodologies
use other methods to create the whiskers with very similar results.
Finally, since all plot points must be represented on a box plot graph, outliers are indicated
with dots. You’ll see a blue dot above the children’s box, representing the data point of 29
minutes. That particular point is a statistical outlier; Six Sigma teams who note outliers on
box plots should consider the data that is shown as an outlier. If an explanation can be
216
found for the outlier, it can be ignored. For example, if the child who took 29 minutes to
complete the mile was much younger than the other children or was walking with an injury,
the data point is explained and can be excluded from further analysis.
In addition to calling out outliers, box plots let you compare two distributions graphically to
see if, as in the above example, there are obvious differences between the data sets. Box
plots are useful in comparing how various attributes impact a process. Six Sigma teams
might compare process results for different operators, different times of day, different
teams, or using different inputs. It’s important when comparing data in this fashion to only
alter one attribute or input; otherwise, you won’t be able to tell what the cause of any
difference between data sets was if a statistical difference does seem likely on a box plot.
Use some information for a work process you are familiar with, or use the sample data
provided, to create box plots in Excel following the steps provided below.
A department manager believes that the staff on her teams would be more productive if
they were able to work with two computer monitors. Because outfitting an entire
department with dual monitors would be costly, the manager’s boss requires some proof
that her assumption is correct. The manager equips a few stations with dual monitors and
lets different team members work at the stations. She records the amount of work done
within hourly increments at stations that have dual monitors as well as stations that have
single monitors. Her data is featured in the table below.
One Two
Monitor Monitors
9 10
8 4
4 9
7 7
2 8
6 7
1 9
8 9
5 14
4 10
3 12
7 7
217
9 9
5 4
1 9
5 7
6 8
7 14
4 13
2 10
9 12
5 12
4 8
8 6
2 10
Create a box plot of the information in the manager’s data table.
1. Copy the data from the table above into Excel.

2. Highlight all of the data cells, including the header row.
3. Click Insert > Statistic Chart > More Statistical Charts
4. Select Box and Whisker and click OK.
218
5. Using normal Excel chart editing functions, edit the title and data labels of your
chart as desired.
219
While a Six Sigma Black Belt would be able to back up the conclusion with hypothesis testing
or other analytics, the manager might get her request for monitors approved with nothing
more than this box plot. It’s easy to see that the second monitor did increase production
capability for staff. Another thing worth noting is that the distributions for each of the boxes
and whiskers is similar, which is somewhat expected. High producers are still going to
produce the most, and low producers are still going to produce less than high produces,
even if everyone is producing slightly more with the new set-up.
Note that the two examples used in this chapter used data sets that were different enough
to be visually noticeable on a box plot. This isn’t always the case, which is why box plots and
other graphical representations are often only the starting point for analysis.
Because statistical analysis is covered in several future units, this section lists some common
statistical analysis tools with definitions.
220
Hypothesis testing lets Six Sigma experts draw conclusions about the population based on
statistical analysis performed on a sample. Because the conclusions are based on samples
and not the entire population, there is always some risk of error. You might have seen or
heard poll results given with a plus/minus in the result: “60 percent, plus or minus 2
percentage points, would vote for the candidate today.” That plus/minus is the value for the
error risk.
In statistical analysis, the risk that a sample doesn’t offer a good representation of the
population is known as the alpha-risk and the beta-risk. Using information about the sample
and alpha and beta risks, statisticians calculate what is called the p-value. The p-value is a
probability estimate that tells statisticians how likely an assumption or conclusion drawn on
sample data will be incorrect.
Statistical software removes a lot of the manual calculations from the process of setting up
and running hypothesis tests. With Minitab, for example, Six Sigma experts can conduct
hypothesis tests on prepared data with a few mouse clicks. They do have to know which
types of hypothesis tests to use in which situations.
Regression and correlation analysis helps Six Sigma experts understand how variables within
a process might be related. Regression analysis helps teams define the relationship between
one independent variable – possibly an input – and one dependent variable – possibly an
output. Does the temperature in the oven have a relationship to whether the cake is baked
correctly, and how close are the two things related? Does the number of hours a person
works have an impact on his or her productivity – can the team show a correlation between
lower production as employees approach the end of a shift? These are the types of
questions that regression analysis can answer.
To work with regression analysis, both of the variables being studied have to be in
numerical format. To conduct a regression analysis regarding the relationship between oven
temperature and whether a cake is baked correctly, a Six Sigma team baked cakes at varying
temperatures and rated them numerically on “doneness.” A rating of 1 indicated the cake
hardly cooked at all; a rating of 5 indicated a perfectly baked cake. At 10, the cake was
completely burned. The temperatures and corresponding ratings are seen in the data table
below.
221
Oven Temperature Doneness of Cake
200 1
225 1.2
250 2.2
275 2.4
300 4
325 5
350 5.2
375 6.2
400 8
425 8.9
450 9.5
475 10
Using this data, the team creates a scatter diagram with a trend line, as seen below.
Just looking at this graph, you can tell that a relationship does exist. The data plots are
gathered tightly around the trend line, which indicates that as temperature rises so does
the doneness of the cake.
222
Correlation and regression analysis doesn’t always provide the information a team needs to
determine relationships between variables, especially when those relationships are
complex, or multiple variables are present. Because the analyze phase sets the stage for the
improve phase, teams have to be as certain as possible in their analytical conclusions before
they decide on solutions for implementation. A design of experiments can provide the more
granular details and analysis required for that level of certainty.
Design of experiments, or DoE, is performed via statistical analysis software such as

Minitab. Teams can set up experiments for one factor or multiple factors.
o Primary root causes have been identified.

o Team has prioritized root causes.
o Champion or sponsor agrees with team priorities moving into the improve
phase.
o Where possible, root cause assumptions are backed by statistical data.
o Relationships between variables within a process are understood.
o Where possible, variable relationships have been confirmed with statistical
analysis.
223
During the improve phase of a DMAIC project, Six Sigma teams brainstorm possible
solutions for the root causes identified in the analyze phase and rank those solutions
according to costs, how effective the solution would be, and how likely the solution could
be implemented. Analytical rankings are used to prioritize and select solutions for
implementation. Teams pilot solutions through beta tests or small roll outs, collect data on
the solution, and verify that the solution is working as expected via statistical analysis. Once
the team is confident that the solution works to address the problem, it plans and
implements a full rollout of the solution.
A solutions selection matrix is an analytical tool that lets teams propose and rank solutions
for any of the root causes identified in the analyze phase. While teams can work
simultaneously on multiple solutions if multiple prioritized root causes were found, Black
Belt and other team leaders must remain cognizant of timelines, resources, scope, and the
purpose of the project. If a single solution provides enough positive impact to reach project
goals, then other solutions might be saved for future improvement projects. If one solution
would reach results, but another solution would be especially easy to implement and
provide additional positive results, the team is likely to decide to implement both.
A solutions selection matrix can be created in Excel, and teams should work on the
document together in a brainstorming capacity. It’s a good idea to include the entire team
as well as relevant subject matter experts and stakeholders during solutions brainstorming.
This ensures the solutions the team comes up with are more likely to be a realistic fit for the
process and business; once solutions are selected using the matrix, teams will also likely
have to get sponsor, champion, or leadership council support before a partial or full
implementation is possible. This is especially true where solutions require expenditure or
will impact processes and people outside of the project’s scope.
An example solutions selection matrix is pictured below.
224
The matrix is completed by:
1. Entering the problem statement in the first column. This should be the final
problem statement that was arrived at during the measure phase if the team
decided that the statement should be altered after gathering data. Otherwise, this
can be the problem statement from the define phase.
2. Entering a priority validated root cause from the analyze phase. If the team is going
to attempt to solve more than one root cause during the improve phase, it should
create a solutions selection matrix for each root cause.
3. Brainstorming potential solutions in column three. During the brainstorming
process, teams should not question or attempt to analyze solutions, but should
record any solution suggested that seems at all viable. The only solutions that
might be ignored are those that are clearly out of scope or impossible, but the
Black Belt leading the brainstorming exercise will have to use his or her own
discernment about such suggestions.
4. Noting, at a very high level, the practical methods by which a solution could be
implemented. In one example used in the analyze chapter, a commercial bakery
had a problem that was caused by lack of baking instructions. In this case, the Six
Sigma team might propose that staff be provided with proper instructions. The
method by which that solution occurs is written documentation and training.
5. Rating solutions. After a list of possible solutions and practical methods is created,
the team rates each possibility on effectiveness, feasibility, and cost-benefit. Each
category is given a rating between 1 and 10.
a. Effectiveness is the measure of how well a solution will eliminate a root
cause for a problem, with 1 being not effective and 10 being highly
effective.
225
IMPROVE
b. Feasibility is the measure of effort required to implement the

improvement, with 1 being not feasible because of the effort or resources
required and 10 being highly feasible.
c. Cost-benefit is an estimated measure of how the costs of a project
compare to the savings expected. This rating is not a formal cost benefit
analysis, but is a high-level estimation. If savings are expected to outweigh
the costs associated with a project, the team ranks the solution as high.
Otherwise, the team ranks the solution low.
6. The scores for effectiveness, feasibility, and cost-benefit are multiplied to calculate
an overall score. The overall score can be used to prioritize solutions and select the
solution that features the best overall effectiveness, feasibility, and cost-benefit
rating.
Consider a possible solutions selection matrix created regarding the medical claims denial
example used in the analyze chapter.
226
During the analyze chapter, a Pareto analysis indicated that timely filing issues were a root
cause for high claims denials. In the solutions selection matrix above, a team has identified
and prioritized four possible solutions after discovering that claims were not filed on time
because claims billing staff didn’t have all the proper information in time.
The first solution is to require the front desk to collect as much information as possible. The
team gave this solution a mid-range rating for effectiveness because it doesn’t address the
fact that clinical information can still be missing from the claim. But, the process would be
effective at gathering demographic information and would not require large expense or
effort to implement, so the team rated it high for the other categories.
Next, the team considered creating and requiring a patient email or portal system so billing
staff could communicate quickly with patients when information was missing. Because not
all patients have email and many would be unlikely to use such a system, the team ranked
this solution as low for feasibility and effectiveness.
The third solution considered by the team was requiring clinicians to include all information
necessary for billing as they charted during the visit with the patient. The team thought this
solution would be fairly effective, but that clinicians would be unlikely to take the time to be
so thorough when dealing with patient issues. The solution might also slow physician visits,
resulting in a negative impact to revenue.
Finally, the team considered a solution that put certain staff members in charge of claims
with missing information. Because those staff members could concentrate on missing claims
and would work through a new workflow built by the team, they would be more likely to
file claims on time. Overall, the team ranked this solution highest, but they decided to
implement both solutions one and four because solution one required so little effort and
would actually help drive the success of solution four.
When teams include the appropriate individuals in the process, a solutions selection matrix
is very adept at identifying the best possible solutions for implementation. Leadership
councils and executive sponsors often want more information about the costs and benefits
expected for a solution, though, so teams should be prepared to create a cost benefit
analysis. Black Belts often have many of the elements required for such an analysis after the
measure and analyze phases, but teams might also need to work with accounting, finance,
or business planning departments to gain accurate financial details required.
227
IMPROVE
The goal of a cost benefits analysis is to compare the costs of implementing a solution with
the monetary benefits expected from the solution. Costs include expenses such as software
development or purchase, equipment purchase, building development or renovation,
additional labor or hiring, training expenses, additional supplies, and any losses associated
with disruption as the solution is implemented. Benefits might include an increase in
product margin, increase in revenue, cost savings or avoidance, and intangible benefits such
as increase to staff morale or customer retention.
Six Sigma teams usually aren’t in a position to handle detailed cost benefit analysis such as
might be completed by a certified accountant, but they can create an idea of cost benefit
relationships via the payback method of analysis. This is the simplest way to approach such
an analysis and provides leadership with an estimated time before a project “pays off.”
To conduct a payback analysis, Six Sigma teams must have an estimated cost for the project
as well as the estimated financial benefit per year. Remember, financial benefits don’t just
include increases in revenue. Cost savings, new customers, or mitigation of customer loss
can all be considered as contributing to benefits each year. The team also needs to
understand the estimated operating costs of an improvement for each year.
The formula for this analysis is:
(Cost of implementing solution) / (Annual financial benefits – annual costs)
If a project costs $50,000 to implement and $2,000 per year in extra labor, and the team
expects the project to generate $15,000 in financial benefits each year, then the calculation
is:
$50,000 / ($15,000 - $2,000)
$50,000/$13,000
Or, approximately 3.84 years until the project pays for itself.
Obviously, organizational leaders are looking for payback calculations that are as short as
possible, but if the solution will solve a major problem or set a foundation for extraordinary
success in the future, a longer payback time doesn’t necessarily keep a solution off the
table.
228
A more concise way of calculating cost benefits is known as the Net Present Value, or NPV.
NPV adjusts benefits and costs as time passes because cash flow in the future is not as
valuable as current cash flow due to inflation and other economic factors. The discount rate
for various endeavors can be calculated using expected return, interest rates, or inflation
rates. Often, corporate finance departments can provide Six Sigma teams with a discount
rate used for NPV in the company. A very basic NPV model is shown below.
This year First Year Second Year Third Year

Total
Benefits
Increased $10,000 $20,000 $30,000

revenue
Cost Savings $5,000 $10,000 $15,000
Costs
Capital -$20,000 -$20,000
Equipment -$15,000 -$15,000
Training -$5,000 -$5,000
Labor -$2,000 -$2,000 -$2,000
Total Benefits -$50,000 $13,000 $27,000 $3,000

– Cost Annual
NPV $12,350 $25,650 $2,850

(Discounted 5
percent)
229
IMPROVE
In this model, the team spent $50,000 implementing a solution and expects a $2,000 labor
expense associated with the solution each year. The estimated benefits from the solution
are recorded for the first two years, and all of the benefits and costs are added up for a
third-year view. The NPV is discounted by 5 percent, and the final number is seen in the
bottom right cell: $2,850. The goal is a positive NPV, so this project fits that goal.
Once a solution is selected and work done to bring it into production at a minimal level, the
Six Sigma team is ready for a pilot. A pilot is a limited trial of a solution in a live
environment. No matter how much analysis was completed or how well test cases were
run, teams can’t know for certain how a solution will behave in the “wild.” The live
production environment will always have variables that teams can’t account for, particularly
when people are involved in the process.
Benefits of a limited pilot include:
 Use of resources are limited, which reduces waste if the solution turns out to
be incorrect or not effective in resolving the problem
 Confirmation that expected results occur
 Allows troubleshooting of a new solution on a smaller scale to minimize
disruption during full transition
 Lets employees outside of the Six Sigma team provide feedback on the solution
and implementation to make the final rollout more successful
Teams don’t have to pilot every change they make. Simple or small changes can be made
without piloting as long as teams document the changes well and measure results for
verification. When changes are large in scope, could cause expensive or expansive
consequences, or would be difficult to reverse, teams should begin with a pilot. The same is
true for any solution that might be expensive to implement at a full scale.
Pilots can occur on a limited scale or for a limited time. Limited scale pilots incorporate a
specific region, team, group of people, or machinery. Limited time pilots implement a
temporary change; at the end of a scheduled time, the team makes a decision about
whether the change should be made permanent.
Pilots can occur with either processes or products. Process pilots might feature testing
specific locations, testing results with some customers, working with some employees to
test new processes, or conducting dry runs of a process without impact to the end-user.
230
Product pilots are conducted using test markets, product models, or alpha and beta testing
of the product with certain end-users.
To create a pilot, a Six Sigma team must first select the audience for the pilot. Internal
process pilots can be performed by a select team or a select few employees. External
product pilots can be performed using a subset of customers. For the best pilot results,
avoid biasing results by selecting the best possible performers or customers who are most
likely to work hard to ensure a product succeeds. When the solution is implemented on a
full scale, it will be used by everyone, so you want to ensure it works for everyone.
When possible, pilot at a very small level and then expand the pilot to a larger audience.
This is the premise behind alpha and beta testing. A very small set of loyal customers tests
the product first, because you know they will provide feedback. Next, an expanded set of
customers tests the product after teams have made changes associated with feedback from
the first group of users. Finally, if the limited tests are successful, teams choose to roll out
the product to the entire audience.
Six Sigma experts can use all the tools associated with the analyze phase to test whether
solutions have a positive impact during testing or pilot programs. Hypothesis testing can be
used to compare data from before the solution to data after the solution, determining if
there is a statistically significant and positive change. Graphical analysis can be very helpful
in demonstrating for executive leaders how a solution has positively impacted a problem by
reducing defects, improving production or efficiency, or reducing costs.
Once solutions have been verified through tests and analysis, teams can begin the work of
implementing changes on a large scale. Teams should create and work from an action plan
during this vital and active stage of the DMAIC process to ensure that no plans or
requirements fall through the cracks. During the active part of the improve phase, the
project leader will likely delegate numerous activities to members of the team, and the
team will also rely on input and assistance from those outside of the Six Sigma team.
Keeping an action plan document helps everyone on the team see where they are in the
process, what they are responsible for, and what date work must be completed by.
If the Six Sigma team is working with a project manager, he or she is likely responsible for
action plan documentation and follow-up. Teams can also use a basic spreadsheet or Word
231
IMPROVE
document, which should be saved in a common location, to keep track of what work is to be
done and who will do it.
Because every project is unique, improve action plans are also unique. Most action plans
will contain common tasks such as documentation, training, and transition.
First, the Six Sigma team should have documented all of its work so far during the DMAIC
process. If asked, the Black Belt or designated team member should be able to present
analysis in the form of data tables, statistical calculations and explanations, and graphical
analysis. All brainstorming activities and diagrams should be saved in a central file location
where all team members can view them and appropriate team members can edit them as
needed. Access to these documents helps team members work efficiently on additional
documentation required for implementation.
Almost any organization will require new processes or changes to processes to be recorded
in standard operating procedures. Depending on the organizational structure of a business,
Six Sigma teams might be responsible for drafting such documents or they might need to
work with knowledge management resources to create SOPs in keeping with corporate
branding and templates. Teams might also create general communications letting other
staff members know about the upcoming changes and the reasons for those changes as well
as general reference documents such as cheat sheets and Frequently Asked Questions.
Strong documentation is key to the next part of implementing improvements, which is staff
training. Six Sigma teams usually aren’t in charge of complete staff training on any
improvement they make. Instead, teams begin the training process by working with training
subject matter experts or delegates in the department impacted by the upcoming changes.
The Six Sigma team trains these individuals, who then go on to train other individuals who
will be impacted by the process. At some point, the process training should be integrated
into regular organizational training by trainers or knowledge management departments.
During the improve phase of a DMAIC project, teams should begin to consider the need to
transition a process back to the business and traditional process owner. Transition is part of
the control phase, but teams should move from improve to control with a good
understanding of how the process should be measured and monitored. Strong
232
documentation and training during the improve phase helps cement the success of the
control phase.
o Solutions were reviewed and prioritized.

o One or two top solutions were selected for action.
o Solutions were implemented on a limited basis.
o Data from limited trials was analyzed and solutions appear to work as
expected.
o Cost-benefits analysis was performed.
o Sponsor, champion, or executive steering committee signed off on
implementing the solution completely.
o All team members agree the solution should be implemented.
o The solution is fully documented through SOPs and training materials.
o Critical staff received training on the solution and are prepared to pass that
training on to others.
233
The last stage of a DMAIC project is control. During the control phase, teams build monitors
that let them ensure the process continues to work successfully after changes are
implemented across the regular business process. At the same time, Six Sigma teams work
to transition the process back to the process owner.
Up until this point in the DMAIC process, Six Sigma teams have worked with statistical
analysis tools, and a Black Belt or other Six Sigma expert has been present to walk team
members through analysis and interpretation. While many organizations train process
owners and other employees in Six Sigma fundamentals, it isn’t always true that a process
owner and his or her team will be familiar with the statistical controls that Six Sigma experts
have been using. Because of that, appropriate documentation via a control plan and
education regarding tools such as control charts might be necessary to ensure business
teams can maintain a process and identify when it is out of control and needs remediation.
At this time, Six Sigma teams might want to revisit the FMEA tool originally introduced in
chapter 13. Six Sigma teams initially use the Failure Modes and Effect Analysis to identify
potential failures in a process and causes of those failures. In chapter 13, we discussed how
the FMEA listed potential failure points and ranked them according to severity, occurrence,
and detection, calculating a total risk priority number.
At the end of the improve phase or beginning of the control phase, Six Sigma teams should
revisit the FMEA, noting what recommended actions were completed and recalculating risk
priority numbers for the improved process. There are two reasons for revisiting the FMEA.
First, the team is able to see that positive and significant changes have occurred because of
the solutions adapted during the improve phase. For any root cause that matched a solution
implemented, the team would hope to see a smaller risk priority number.
Second, an updated FMEA helps the team identify the next problem or root cause that
might be addressed. Remember, Six Sigma is a continuous improvement initiative. The team
might have implemented a solution and met an improvement goal, but further
234
improvements can always be made. Control is a time to review the process and suggest
possible improvements for future projects.
To facilitate continued success, Six Sigma teams should create a written control plan for the
process owner. The purpose of a control plan is to help the process owner and business
team track and respond to key performance indicators so that the process remains
improved. The control plan should be a concise, easy-to-reference document that tells the
business team when to monitor, how to monitor, what range of data is acceptable to the
monitor, and how to respond with corrective action if the range measured is not
acceptable.
Control plans can be spreadsheets, specialized digital documents, or hard-copy documents

posted at a work station. Common elements of a control plan include:
o Company, division, or department name

o Name of person who created the plan
o Date the plan was created
o Name of the person who last edited the plan
o Date the plan was last edited
o Project and/or process name or identifier
o Process owner
o List of process steps where control action is required
o CTQ or metric associated with each action required
o Limit specifications, or the acceptable range of measurements
o The unit of measurement
o The method of measurement
o The necessary sample size
o The frequency of measurement
o The person responsible for measurement
o Where the information is recorded
o Correction actions
o Associated policy and procedure documents
In discussing quality in chapter 8, we introduced the example of a company that makes

chocolate bars and noted that the amount of sugar in the chocolate bar recipe was critical
to the customer’s experience with the end product. If a Six Sigma team were tasked with
235
CONTROL
improving customer satisfaction with a new chocolate bar product, they might have
implemented a solution that ensures the proper amount of sugar is added to the mixture at
the right temperature to incorporate the ingredient appropriately.
A control plan for the new chocolate bar solution might look something like the document
below.
Company: XYZ Sweets Control Plan Created by: Joe Black

Belt
Process: Sugar addition, raw goods Control Plan Created on: Jan. 4,
mixture 2012
Process Owner: Sue Processor
Process Step Addition of sugar to Heating of batch

batch
CTQ/Metric Total amount added to Mean temperature

batch during mixing
Limit specification LSL: 4.90 cups LSL: 105 F

USL: 5.10 cups USL: 110 F
Unit of measurement Cups Degrees F
Method of 6-cup sugar test bowl Read integrated digital

measurement thermometer on mixing
machine
Sample Size One batch 3 reading, 2 minutes

apart, during mixing
Frequency Every 2 hours Every 2 hours
Employee Mixer operator Mixer Operator
Record data in Mix operation log Mix operation log

spreadsheet spreadsheet
236
Corrective action Manually measure Turn off machine, waste

correct amount for inappropriately heated
current batch to allow batch, and report
for processing, calibrate temperature calibration
sugar disbursement issue to maintenance.
machine following SOP
100.54, test sugar
disbursement for first
batch after calibration
to ensure problem is
resolved. Report issue
to supervisor.
The above example control plan provides instructions for two specific steps in the process
with easy-to-understand measurement and monitor requirements. To reduce the chance of
errors, the Six Sigma team has even specified a special measuring tool for measuring the
sugar in the test batch so that every operator performing the monitor measures using the
same tool.
At the end of the control document, the team provides steps for corrective action. The first
step can be corrected by the operator, who has the ability to calibrate the machine him or
herself. The temperature calibration in this case can’t be performed by the operator, which
means the process has to be stopped so that someone can attend to the issue. Note that it
is always preferable, when possible, to build corrective action at the process level, such as
was done with the sugar measurement. This minimizes downtime, puts employees more in
control of the processes they own, and helps employees stay involved with the quality
process.
The control plan above assumes that manual measurements must be taken or recorded.
Optimally, Six Sigma teams should look for ways to automate measurements, which means
data can be continuously gathered and converted into statistical process controls such as
control charts. Automated data gathering doesn’t mean a control plan isn’t necessary, it just
means that a control plan won’t include instructions for gathering the data. Instead,
employees and process owners can be instructed to review automated data or control
charts and take action if necessary.
237
CONTROL
You’ll also note that the specification requirements given above are provided with LSL and
USL. LSL is the lower specification limit and the USL is the upper specification limit. These
are the upper and lower limits of the acceptable range.
In addition to providing a control plan, Six Sigma teams can implement specific visual
controls in a workplace to help business teams maintain a controlled process. Some of these
tools were covered in chapter 4 on Lean process management, including 5S. Other visual
controls teams might implement include signs, posted matrixes and instructions, auditing
boards that let teams keep track of individual or group performance over time, color coding,
and safety signals.
Standard operating procedures can often be distilled to visual representations on posters. A

coffee shop, for example, might provide employees with a visual representation of what
ingredients are used to create various complex drink flavors. Such a poster ensures that
employees can prepare drinks quickly while reducing errors in ingredient inclusion.
Other SOP visualizations might include safety procedures in a medical environment, such as
visual reminders for hand washing and short pictorial representations for how to operate
equipment such as hospital beds. In an office environment, pictorial instructions are found
on copy machines, where pictures indicate how paper should be loaded and visual gifs are
often displayed on LED screens to help employees remove jammed paper. These are some
examples that Six Sigma teams can follow when creating documents that will help business
staff accept ownership of an improved process and maintain the improvements made.
One of the most common methods Six Sigma teams use to monitor a process is the control
chart. A number of types of control charts exist, and Six Sigma experts must choose the
right control chart for the type of data and analytical purpose.
Now, we’ll cover the visual tests that let a Six Sigma team or process owner know that a
process is out of control.
A basic control chart has the following elements:
 A line chart of data with plot points for specific data points
 An x-bar line representing the average of the data points
238
 Lines above and below the x-bar line representing 1, 2, and 3 standard
deviations from the median in either direction
 An upper control limit (UCL) line at 3 standard deviations above the median
 A lower control limit (LCL) line at 3 standard deviations below the median
Above is an example of a control chart. The middle line, which is black, is the x-bar line. The
x-bar line is bounded by green lines on both sides, indicating 1 and 2 standard deviations
away from the mid-line. Those lines are bounded by orange lines on either side: at the top,
the upper control limit, and on bottom, the lower control limit. Between the various lines
are areas of the control chart, designated as C, B, and A going in either direction. These
distinct areas are important for understanding if a process might be out of control. They are
also called Zones 1, 2, and 3.
A control chart is best displayed using an automated reporting system or dashboard, where
process owners or responsible employees can view it as needed. If automated data
collection and control charting is not possible, then a business analyst can be tasked with
collecting data and presenting it in this format periodically, though periodic graphical
analysis is less likely to catch a problem of control within a process.
Eight tests exist that can quickly tell someone viewing a control chart if a process is out of
control.
 Test one: A single point on the control chart appears outside of the upper or
lower control limits. If this occurs, process owners should take immediate
239
CONTROL
action, because it is evidence of a major problem within a process. While there

is a very remote possibility that shifts outside of three standard deviations can
occur randomly, the likelihood is only 3 in 1,000.
 Test two: Nine points in a row appear on one side of the center line. This
indicates that a change occurred in the process; if the process owner knows
what change caused the shift and it was intentional change, nothing needs to
be done and the control chart will right itself over time with the new data.
Otherwise, the process owner should investigate the process.
 Test three: Six points on the control chart increase or decrease in a row,
indicating the process is becoming less or more efficient or is generating fewer
or more errors. Process owners should investigate unless there is a known
reason for the trend.
 Test four: Fourteen points on the control chart in a row alternate moving up
and down. This could indicate variation in machines, employees, shifts, or over
correction.
 Test five: Two out of three points in a row on the control chart are in the upper
A section or in the lower A section. This might indicate some type of special
cause creating sudden high variation.
 Test six: Four out of five points in a row on the control chart are located in the
upper B section (or beyond) or the lower B section (or beyond). This can
indicate a problem of major causation or a shift problem similar to that of test
four.
 Test seven: Fifteen points in a row are located within the C section above or
below the centerline. This can indicate that control limits are no longer relevant
to the process; if a team has improved variation of a process, they should
recalculate control limits to new parameters. Alternatively, this might occur
temporarily when short-term variation is high or low relative to the rest of the
points on a control chart.
 Test eight: Eight points in a row on the control chart are located on either side
of the center line, but none are located in the C section above or below the line.
This could indicate an issue of mixed resources or processes; a team might think
they are measuring a single process when they are actually measuring two
process, for example. Alternatively, it could indicate a major difference in
processing for two employees or teams.
When it’s possible to create control charts and display current data on a regular basis, these
charts make a good addition to a control plan. Individuals don’t have to be well-versed in
240
statistical process control to learn about the eight tests, and business teams with the
benefit of control charts can spend more time working on production or correcting issues
and less time collecting and documenting measurements.
It’s important to note the distinction between a controlled process and one that is capable
of meeting customer requirements. We touched on this concept in unit 1: controlled
processes don’t have a lot of variation. Capable processes don’t have a lot of variation and
the outputs center around a customer requirement. This is why both control limits and
specification limits are important.
Consider the example used earlier in this chapter about sugar in the chocolate mix. The
specification limits ranged from 4.9 to 5.1 cups of sugar in each batch. It’s possible for a
control chart to show that the process is in control if the measurements range from 3.5 to
3.6 cups of sugar per batch, but the process owner should know that those measurements
aren’t going to contribute to a product that meets critical to customer quality requirements.
To understand how a process is performing against specification limits, Six Sigma teams can
calculate sigma level and process capability.
Sigma level is the number of standard deviations between the current process center, as
measured by the median, and the nearest specification limit (not control limit.) The
equation for sigma level is the smaller of the following calculations:
For example, if a process has an USL of 5 and a LSL of 3, a standard deviation of .25 and a
median of 4.2, then you would calculate from the USL, since the median is closer to the USL.
241
CONTROL
Process capability is calculated by dividing the sigma level by 3. In the case of the example,
the capability is 1.06.
Process capability is denoted as Cpk. A process capability of 1.33 is equal to a sigma level of
4, which is what most experts agree is the minimal level at which most customers will be
satisfied. Under statistical process control, many organizations aim for a process capability
of 2.0 with minimal acceptable process capability at 1.5.
When Six Sigma teams deem improvements and the related process to be capable and in
control, and they’ve passed those processes back to business and process owner control,
they should take time to celebrate and reflect on the outcome of the project. This is usually
done following the final tollgate review with a sponsor or champion, and can be a quick
meeting to close loose ends, recognize the work done by the team, and discuss lessons
learned within the process.
The celebration and reflection meeting is also a great time for team members to bring up
ideas for possible improvement projects. While improvements – and the related problems
and causes – are still fresh on the team’s minds, they can effectively brainstorm ideas for
next steps. As with any brainstorming session, no idea should be automatically held off the
table because it seems silly, would be too hard to implement, is too costly, or seems too big.
Not all of the ideas will become future projects, but the team’s input provides valuable
information that the Black Belt can later share with Six Sigma leadership panels.
 The team has calculated the performance and capability of the new process
 The team has written a control plan and communicated it to the process owner
 The team has created a monitor for the process, either through procedures for
manual data collection or automated generation of control charts
 The team has provided the process owner and business team with all tools and
information required to maintain improvements
 The sponsor, champion, or executive leadership has been informed about the
state of the improvements
 The team met to reflect on the project and generate a list of ideas for future
improvements
242
Graphical analysis is a critical part of the Six Sigma approach. Whenever data or ideas can be
displayed in a visual format, obvious data trends can be quickly identified and
communicated. Visual analysis is extremely helpful when presenting ideas to auxiliary staff
or executives, who might not be trained in intermediate or advanced statistics. The Black
Belt or other Six Sigma experts have the ability to tell the same story that statistics tell, but
in a format that can be understood by anyone. Visual depictions are tools that make it
easier for Six Sigma professionals or sponsors to retell the story to others, which can be
helpful for training, building cultural buy-in for a process change, or even resource requests.
Throughout the first three units of this book, we’ve discussed a number of graphical analysis
tools, including:
 Pareto charts in chapters 5 and 14

 Run charts in chapter 13
 Box plots in chapter 14
 Introduction to control charts in chapter 16
 Introduction to scatter diagrams in chapter 14
In this chapter, we’ll discuss additional graphical analysis tools, including bar charts and pie
charts. We’ll also look again at scatter diagrams and how to create them in Excel. In Chapter
16, you learned about the components of an X-bar control chart and how to tell if a control
chart indicates a process might be out of control. In this chapter, we’ll walk through the
243
INTERMEDIATE GRAPHICAL ANALYSIS
steps for manually creating an X-bar control chart in Excel. Finally, you’ll learn how to install
a data analysis add-in for various versions of Excel. The add-in provides functionality that
will become relevant in the next few chapters.
As with many other areas of the Six Sigma methodology, it can be easy to go overboard
when dealing with graphical analysis – particularly when presenting information to others.
With so many tools at your disposal, it’s tempting to pick the graph that is new, exciting, or
more complex. Often, though, that means spending non-value added time creating one
visual tool when an easier tool would do the job. If you recall from chapter 4, this would be
an instance of over-processing to avoid.
Consider the two charts below to understand when over-processing might be occurring with
regard to graphical analysis.
244
Both charts are a graphical representation of the same information. The first is a simple bar
chart that was created within a few clicks in Excel. The second is a Pareto chart, also created
in Excel but requiring many more clicks of the mouse. In this particular case, a Pareto chart
is not necessary to convey the required information. The data is diverse enough that anyone
can see from looking at the bar chart that sales person E accounts for a lot of the errors. In
this particular case, a Pareto chart is overselling the conclusion and doesn’t need to be
created if extra work is required.
In this example, it’s possible that a visual portrayal of the data isn’t required at all: the
conclusion is obvious. Looking at the raw data below, you can quickly see that employee E
has triple the errors as the next-highest employee. Even when the raw data provides for
easy analysis, however, many Six Sigma experts do take the time to create a graphical
representation for the purpose of presentations. A graph is more visually appealing and
quicker to read than a data table.
245
Sales
Employee Errors
A 10
B 5
C 2
D 9
E 34
F 7
G 3
The simplest graphical analysis isn’t always the best choice, especially when data elements
are not so obvious to note. More complex analysis might be required to discover outliers,
relationships, and trends. Even when conclusions about data seem obvious, they aren’t
always correct. This is especially true when dealing with the relationship or correlation
between factors in a process.
As a Six Sigma expert, it takes time to be able to quickly choose which type of graphical
analysis will best represent the data at hand. It’s also important to note that the best choice
for graphical analysis relies equally on the questions being asked as much as it does on the
data itself. In the example above, the basic bar chart is a good choice for a team that wants
to know where errors might be coming from. If the team was comparing errors to shift
times being worked, the bar chart would not be helpful.
While it’s true that you don’t want to waste time and space presenting data in a way that is
not helpful – or could be considered muda of over-production – the same isn’t always true
when dealing with analysis. At the analysis stage of a DMAIC project, Black Belts and other
Six Sigma experts often work with numerous graphical analysis tools as they attempt to
understand data. The need to view data in various ways is one reason statistical analysis
software is helpful: such software takes some of the manual work out of creating these
charts and graphs. Trial-and-error work with all types of Six Sigma analysis tools also helps
you learn to identify which tools fit each situation best.
In this section, we’ll discuss some tools that haven’t been introduced so far, covering
benefits, limitations, and how to create the tools in Excel without statistical analysis
software when necessary.
246
One of the biggest benefits of bar charts is that they are recognizable and easy to read.
Almost any employee in a company can glean information from a properly formatted bar
chart without instruction or guidance, making them a great choice for general use
presentations and training materials. Bar charts are also easy to create, so they are a
preferred method of illustration in presentations and reports. Other benefits include:
 The ability to summarize large data sets in a simple visual format

 The ability to clarify trends
 The fact that most people can easily estimate important values on a well-formatted
bar chart
 The ability to visually check data and identify areas where data might be skewed
 The ability to easily display data sets that range above and below zero on the same
chart
Bar charts typically require nominal or ordinal data – data that is classified according to
qualitative information. When displaying nominal data, it’s often beneficial to create a
Pareto-style chart so the reader can see instantly how the population relates to the
categories. Ordinal data usually involves its own logical order for presentation. For example,
if individuals are asked to rank satisfaction with a product as very satisfied, somewhat
satisfied, neutral, unsatisfied, and very unsatisfied, then you usually would not want to
change the order of that presentation on a bar chart.
Bar charts are not without limitations. Depending on what is being presented, additional
narrative might be required to explain the chart. Bar charts also often fail to reveal key
information about trends that aren’t part of the specific design of the chart, and they rarely
on their own provide detailed data about causes or patterns in data. Finally, it’s easy to
manipulate colors, order, and layout of a bar chart to influence the message that your
audience takes away. Six Sigma experts should always choose the best format for displaying
fundamental truths, but should never format a chart to create an impression that might not
be in keeping with the statistical data behind the graphical representation.
Create your own bar charts in Excel by starting with data tables of relevant nominal or
ordinal data. Copy the data table below into Excel to practice bar chart creation, or use data
relevant to your own processes or projects. The sample data table provides the total
247
number of phone calls experienced by a regional customer service call-center team for each
hour in a particular day.
Phone
Hour calls
8:00
AM 78
9:00
AM 89
10:00
AM 107
11:00
AM 118
12:00
PM 149
1:00
PM 147
2:00
PM 105
3:00
PM 90
4:00
PM 97
5:00
PM 85
6:00
PM 178
7:00
PM 198
8:00
PM 145
9:00
PM 57
1. Highlight the columns that contain the data you want to chart as well as the labels
for that data. In this case, the data is the number of calls and the labels are the
hours.
248
2. Select Insert > Chart > Bar Chart
3. For this example, the simplest form of bar chart is appropriate.

4. Use Excel formatting tools as desired to customize the chart title, colors, and labels.
249
Most versions of Excel offer several types of bar charts, and you can experiment with these
various formats to see how they display your data. Some notes about common formats are
included below.
Technically, what is commonly referred to as a bar chart – and what we’ve been calling a
bar chart here – is a column chart. The visual columns representing each data category rise
vertically. A literal bar chart displays the same information horizontally. Most versions of
Excel let you choose between the two displays. The information from the example data
table is presented below in a horizontal bar chart.
250
The charts displayed so far in this chapter are all 2-dimensional. Excel can also help you
create 3-dimensional charts to add visual appeal to a presentation. 3-D charts are helpful if
you are presenting a number of similar-looking charts in a row, as it helps to differentiate
between information in your presentation. It might also be helpful to create more visually
appealing charts simply to capture audience attention more fully. Here’s an example of the
same data used above in a 3-D chart.
251
Stacked bar charts let you display the total nominal or ordinal data for each category while
also breaking that information into color coded categories. For example, if the Six Sigma
team analyzing phone calls per hour wanted to display data that included how many calls
were handled by separate teams within a department, the bar chart might look something
like the image below.
252
To create a stacked bar chart, you must have ordinal or nominal data that is broken into
categories. The categories must be the same for each data set so that the total of the sub-
category numbers equals the total of the main category. For example, if you have three
bags of marbles, you might have data that says:
Bag Number of marbles
1 10
2 3
3 15
Upon further analysis, you realize you have marbles in three colors: red, blue, and yellow.
Bag 1 Bag 2 Bag 3
Red 7 1 5
Yellow 3 1 8
Blue 0 1 2
Bag 1 doesn’t include any blue marbles, but you must include blue as a category for Bag 1
because it is a category in the other two bags. You simply put a 0 in that data field. You’ll
note that the totals of the subcategories under each bag add up to the amount of marbles
in each bag. Following these guidelines – including all subcategories for each section and
ensuring the subcategories total correctly – helps you create accurate stacked bar charts.
Examine the data table below, which displays the breakdown of calls by teams in the call
center.
253
Phone
Hour calls Team A Team B
8:00
AM 78 35 43
9:00
AM 89 40 49
10:00
AM 107 57 50
11:00
AM 118 90 28
12:00
PM 149 42 107
1:00
PM 147 77 70
2:00
PM 105 57 48
3:00
PM 90 45 45
4:00
PM 97 72 25
5:00
PM 85 64 21
6:00
PM 178 98 80
7:00
PM 198 89 109
8:00
PM 145 77 68
9:00
PM 57 54 3
1. Highlight the cells containing the data you want to include in your stacked bar
chart as well as the cells containing the data labels.
254
2. Select Insert > Charts > Bar Charts > Stacked Bar Chart
3. Use Excel’s format options to edit titles, colors, and data labels as desired.
The pie chart is another visual tool that almost any employee in a business environment will
be familiar with, making it a good choice for displaying certain types of information. Ordinal
and nominal information can also be displayed in a pie chart with the main purpose of
visually representing how each category relates to the whole. Conventional wisdom says to
use a pie chart when the numbers you are charting add up to 100, but this doesn’t have to
be the case. Excel converts values to percentages to create pie charts. Consider the pie
chart below, which graphs the numbers 8, 5, and 4. Excel considers each of these numbers
255
against the total “pie” of 17. The blue section, which represents 47%, corresponds to the
raw data 8/17.
Benefits of pie charts include:
 The ability to summarize large amounts of specific data types in a visual

format.
 Simplicity; the pie chart is one of the simplest types of graphs
 The ability to identify obvious problems with data or calculations
 Pie charts usually require very little extra explanation when labeled
correctly
 Pie charts display the relevance of subset data within a total data set
The fact that pie charts are used constantly in business environments is both an advantage
and disadvantage for Six Sigma teams and experts. When data can be depicted in a pie
chart, the Six Sigma expert usually has to create less narrative to get a potential point
across. At the same time, pie charts don’t always carry the weight that a more advanced
statistical representation might because business employees are so used to seeing them.
Other disadvantages of pie charts include the fact that they can be manipulated in much the
same way as bar charts, they usually fail to easily display changes over time, and it can be
difficult to visualize exact values when presented with a pie chart.
256
Practice creating a pie chart in Excel using the following data table, which records how
many minutes are spent on average for each step of a process. You can also use data
relevant to your own process or project to create a practice pie chart if desired.
Process
Step Minutes
A 14
B 18
C 41
D 64
E 12
F 4
G 3
H 7
I 23
J 18
1. Highlight the column of data you want to chart as well as the data labels. In the
example, we are charting the number of minutes and the process numbers are the
data labels.
2. Click Insert > Chart > Pie Chart
257
3. Use Excel’s formatting tools to make changes to color, title, and labels as desired.
From the pie chart created for our sample data, we can see that approximately half of the
total process time is related to only two steps in the 10-step process. We can also quickly
see which steps take the longest on average and which are the shortest, although we can’t
draw any conclusions about actual time from only this chart.
As with bar charts, you can take advantage of Excel options for creating three-dimensional
pie charts. A particularly helpful function is the Pie of Pie function in Excel, which lets you
create an overall pie chart and carve out a second pie chart to delve deeper into certain
areas of the larger structure. Consider a Pie of Pie chart below, which represents the same
data from the pie chart above.
258
The original pie chart depicted 10 steps. The illustration above shows a large pie chart with
a secondary chart. The large pie chart appears to show 7 steps – but this pie chart shows
the same information as the one above. However, four steps from the process are called
out in a smaller chart so you can see how they relate to each other better. Those four steps
combined make up the 7th, dark-blue pie piece in the larger pie. This makes it easier to
pinpoint relevance of smaller data categories within the whole or to emphasize a certain
area of the chart.
You do have to be careful, however, that the viewer doesn’t assign relevance or importance
based solely on the size of the pie pieces. The gray pie piece in the secondary chart above is
bigger than some of the other pieces in the larger pie, but that doesn’t mean that step takes
longer. The smaller pie should be considered a large-scale view of a small piece of the
overall graph. In this case, that small piece takes into account four of the steps.
We introduced scatter diagrams very briefly in chapter 14, and we’ll revisit them in depth in
later chapters on correlation and regression modeling. In this section, we’ll cover how to
create a scatter diagram in Excel with any analysis add-on. In chapter 19, we’ll use an add-
on for Excel to conduct some statistical analysis while creating scatter diagrams.
Scatter diagrams are beneficial because they can help teams visually see the relationship
between two factors in a process. Does temperature decrease over time? Does a person’s
259
productivity increase with his or her salary? These are examples of questions that might be
answered by scatter diagrams, but it’s important to realize that correlation as depicted on a
scatter diagram doesn’t necessarily mean causation. Two variables can be closely related
without one causing changes in the other.
Scatter diagrams typically help teams see whether there is no correlation, weak correlation,
or positive or negative correlation. Positive correlation occurs when variable 2 is related to
an increase in variable 1, or vice versa. Negative correlation occurs when variable 2 is
related to a decrease in variable 1, or vice versa. For example, it is commonly noted that the
rate of crime and the average per-capita income of geographic areas in the United States
are related. Areas that demonstrate higher crime rates often also demonstrate lower
income statistics. The statement can be made the other direction: areas that demonstrate
lower income statistics often demonstrate higher crime rates. That is not to say that either
of these things necessarily causes the other.
Drawbacks of scatter diagrams are that they are not as familiar to business employees as
bar, pie, or even line charts. There is also a risk that individuals who don’t have an
understanding of statistical analysis will mistake correlation for causation, which can lead to
incorrect decisions. Black Belts and other Six Sigma experts must be cognizant of these risks
so they can appropriately explain scatter diagrams and provide further explanation when
necessary.
Use the data table below, which includes the average number of errors per hour a process
creates as output is increased per hour to create a scatter diagram in Excel. Copy the
information from the table below into Excel, or use data from your own process or project if
desired.
Parts Per
Hour Defects
100 3
150 4
200 5
250 5
300 7
350 7
400 9
450 8
260
500 10
1. Highlight the data you want to chart. To create a scatter diagram, you will need to
highlight two sets of data that you want to compare.
1. Select Insert > Chart > Scatter
2. Use Excel’s formatting functions to edit colors, titles, and labels as desired.
261
From the scatter diagram created, we can see that the two variables – production volume
and errors – appear to be related in some manner. While it’s a good bet that increased
production actually causes increased errors, you can’t simply assume causation from this
graph. This assumption could be further tested using more advanced statistical techniques.
It should be noted that, even when correlation seems obvious on a scatter diagram, it isn’t
always the case. Six Sigma experts should always test correlation assumptions to ensure
they are correct statistically before presenting a scatter diagram to others as an illustration
of a relationship. We’ll cover statistical regression and correlation tests in chapter 19.
The X-bar control chart plots the mean of a sample over time – or the mean of samples
taken over time, in the case of an active process. X-bar control charts are one of the most
frequently used control charts. Some control charts can also be created in Excel using these
steps; more advanced control charts require statistical analysis software.
1. Create the following template in an empty Excel spreadsheet.
262
2. Enter your data points in column A.

3. In cell G1, enter the formula =STDEV(A2:A15)
a. The cell references A2:A15 should be edited to correspond to your actual data
list.
b. This calculates the standard deviation of your data set.
4. In cell G5, enter the formula =AVERAGE(A2:A15)
a. The cell references A2:A15 should be edited to correspond to your actual data
list.
b. This calculates the mean of your data set.
5. In cell G2, enter the formula: =G5+3*(G1)
a. This calculates an upper control limit that is three standard deviations above
the mean.
6. In cell G3, enter the formula: =G5-3*(G1)
a. This calculates a lower control limit that is three standard deviations below the
mean.
7. In the UCL column (B), direct Excel to create a column of numbers where every number
is equal to the upper control limit by copying =$G$2 into each cell in a row that has an
X-bar data point in column A.
8. In the LCL column (C), direct Excel to create a column of numbers where every number
is equal to the lower control limit by copying =$G$3 into each cell in a row that has an
X-bar data point in column A.
263
9. In the Mean column, direct Excel to create a column of numbers where every number is
equal to the mean by copying =$G$5 into each cell in a row that has an X-bar data point
in column A.
(Practice steps 1 through 9 with the following data.)
X-Bar Data Points

24.1
25.2
24.7
28.3
27.1
26.4
25.4
21.4
24.5
23.5
27.5
29.5
24.5
26.8
The result should be a spreadsheet that looks just like the one below.
10. Create a control chart by highlighting the data in columns A through D.
264
11. Select Insert > Charts > Line Chart > 2-D Line Chart with Markers
12. Right click on the data labels for the Y axis and select “Format Axis.”
265
13. Alter the bounds for the axis to remove excess white space in your control chart. In this
case, we’ll change bounds from 0 to 35 to 15 to 35.
14. Format the chart as desired for color, titles, and data labels. You now have a very basic
control chart.
One thing you’ll note missing from this control chart is the lines that denote one and two
standard deviations above and below the mean. In chapter 16, you learned that those lines
266
help you apply the tests that determine if a process is in control or not. You can easily add
those lines by following the steps below.
Add Standard Deviation Lines
1. Add calculations to your spreadsheet for:

a. The mean plus one standard deviation
b. The mean plus two standard deviations
c. The mean minus one standard deviation
d. The mean minus two standard deviations
2. Add four data columns, one for each of the calculations in step one. Copy the
numbers from each of the calculations down the columns as you did with the upper
and lower control limits and the mean in the original instructions above.
3. The spreadsheet should now appear similar to the image below.
4. Highlight all of the information in columns A through H.

5. Select Insert > Charts > Line Chart > 2-D Line Chart with Markers.
6. Change the Y-Axis to an appropriate range.
7. Edit the background standard deviation lines to be less intrusive by clicking on each
and first selecting the gradient line option.
267
8. Click on the line again and select “Marker.” Select none to remove the markers for
the background lines.
9. Edit the final chart as desired with titles and labels.
268
This process might seem very time consuming, but it only takes a few minutes once you are
well-versed in the elements of a control chart. It’s a good idea to know how to create
control charts in Excel, because Six Sigma experts can’t always rely on access to statistical
analysis software.
You can complete these calculations by hand, but that can be time consuming and require
extremely advanced statistical skill sets. We will start with manual calculations because it
helps to understand the reasoning behind an analysis. But we’ll also rely heavily on tools
that complete most of the calculations. Not only does statistical analysis software minimize
the time it takes to conduct such analysis, but it also reduces the chance of calculation
errors and increases the accuracy of analysis and conclusions offered by Six Sigma experts.
For lessons covered in the next few chapters, you can rely on the free data analysis tool
available from Microsoft for Excel. To add this free tool in Excel 2013 and higher, follow the
steps below.
269
1. Select File
2. Select options
270
3. Select Add-ins
271
4. Locate the Analysis ToolPak under inactive application add-ins. Note: if the Analysis
ToolPak is located under Active Application Add-ins, then it is already active and you
don’t need to take any of the next steps.
5. At the bottom of the dialogue box, ensure that “Excel Add-ins” is listed in the
Manage box, and click “Go”.
6. In the new dialogue box, ensure the option for Analysis ToolPak is checked.
272
7. Click OK
8. Check that the Analysis ToolPak was installed by selecting “Data” from the Excel
menu bar and looking for the Data Analysis option.
If the Analysis ToolPak doesn’t appear as an Add-In option, that means it wasn’t installed
when your version of Excel was installed. If you are using Excel that was installed from a
disk, you’ll need to locate your software CDs and either reinstall the software or complete a
custom install of just the Analysis ToolPak file.
Note that there are two files with the Analysis ToolPak name. The file called Analysis
ToolPak – VBA is not the file that provides analytical capability.
The Analysis ToolPak is also available in earlier versions of Excel. In 2003 and earlier versions
of Excel, you’ll find the Add-in menu item under Tools. In 2007, the Add-in option is found
by selecting the Office button and then Excel options. In 2010, select File, Options, and
Manage Add-ins.
273
Now that you’ve downloaded the Analysis ToolPak in chapter 17, you can begin learning
more detailed statistical analysis. In this chapter, we’ll discuss how and when to use a
normal probability curve to draw inferential statistics. Now is a good time to know the
difference between descriptive statistics and inferential statistics.
Descriptive statistics are numbers used to describe a set of data. Given a set of data about
the employees in a company, for example, someone might say, “Over 50 percent of the
employees work in sales or marketing departments,” or, “86 percent of the employees live
in the same zip code that the office is located in.” These are descriptive statistics because
they simply discuss the nature of the data at hand. Averages, means, and even standard
deviations associated with that data are all descriptive in nature.
Inferential statistics involve calculations and resulting numbers that draw more general
conclusions from data. For example, if you have data about a sample of 150 employees in a
city – not all the employees from a single business, but random employees from different
companies – you might be able to use inferential statistics to draw conclusions about all the
working individuals in that city based on the data in your sample.
Descriptive statistics can relate to population data or sample data. Inferential statistics are
used to draw conclusions about the population from sample data. If you randomly select 20
people from an overall population and record their height, then the mean of the recorded
heights is a descriptive statistic about the sample size. Descriptive statistics about the
sample are used in calculations for inferential statistics about a population.
274
Probability is the likelihood that a certain event or outcome will occur given a specific set of
data or a specific action. If you flip a coin one time, the probability of it coming up heads is 1
in 2, or 50 percent.
When discussing basic probability, we talk about outcomes and events. The outcome is the
result of one trial: you flip the coin once or you randomly select a single item from the
sample. The event is a specific outcome or outcomes. The coin coming up heads is an event.
A person measuring 5 feet tall is an event if you are talking about selecting from a
population or sample.
Basic probability can be calculated by the formula:
In the case of the coin, there are two possible events, or outcomes, that can occur when
you flip it. Only one of those events is coming up heads. Therefore, ½ = .5, or 50 percent.
In the case of rolling a six-sided die, there are six possible events. You can roll a 1, 2, 3, 4, 5,
or 6. The probability of rolling a 5 is 1/6, or .167. The probability of rolling either a 4 or a 5,
however, is 2/6, or .33.
While probability measurements can be expressed as a percentage, they are calculated and
usually communicated in statistics as a decimal point. Since probabilities are presented as
fractions, the lowest probability possible is 0 and the highest is 1. A probability of 0 means
an impossible event; a probability of 1 means a certain event.
Twenty marbles are placed in a bag. They are all the same size, but are different colors as
follows:
275
NORMAL PROBABILITY DISTRIBUTIONS
- 3 red
- 5 black
- 8 blue
- 4 green
What is the probability that a green marble would be pulled from the bag?
4 / 20 = 0.2
What is the probability a blue or a black marble would be pulled from the bag?
13 / 20 = 0.65
What is the probability a yellow marble would be pulled from the bag?
0 / 20 = 0
Note: This is an impossible task, because there are no yellow marbles in the bag.
In a Six Sigma setting, you aren’t dealing with marbles and bags, but the ideas of probability
are somewhat similar. If a process produces 100 products an hour and two of those
products are defective, the probability of receiving a defective product within that hour is
2/100, or 0.02. However, it’s rare that a team or business unit would review all 100
products that were produced that hour to know that 2 out of 100 are defective. That
information is also only useful for stating probabilities with relation to that particular hour
of output, given that the sample wouldn’t be random.
Instead, Six Sigma experts randomly sample the population of all outputs of a process for a
certain amount of time. They create descriptive statistics about that sample and use the
descriptive statistics to further study and understand the nature of the data they are
working with. Once they know the nature of the data, they can work with probability
distributions and curves to determine probability via calculations and statistical analysis. In
this chapter, we’ll discuss how to work with what is called normal probability distributions.
276
Before moving forward with probability distributions, it’s important to understand

histograms. Histograms are another graphical analysis tool. Technically, histograms are bar
charts where each bar, or “bin,” corresponds to a data range. Data points within a sample
or population are divided between the bins and are graphed accordingly.
Histograms are used to analyze continuous or variable data that is finite in nature or comes
from population sampling. Histograms help Six Sigma experts understand how the spread,
or distribution, of the data is shaped and where the center of that data might be. The center
is the average or middle of the data spread, though the mean or median values aren’t
always located at the center of a histogram. A histogram also shows the range of the data –
the variation between the highest value of the data set and the lowest value of the data set.
Finally, the histogram’s shape provides information about where the data is concentrated.
Consider the two histograms below. In the first, the data elements are concentrated toward
the center. The histogram approximates what is called the bell curve, or normal curve. This
shape is likely to indicate that the data used to create the histogram is normal data, which
will be discussed further later in this chapter.
The second histogram depicts data that is concentrated at either end of the range. When
two specific concentrations, or humps, are noted on a histogram, this is called bi-modal
distribution. Often, when you see this shape of data, it means that you are measuring two
processes that you believe are a single process. For example, if two different people are
performing a piece of work, they might have different outcomes that result in two different
humps on the histogram. If bi-modal data does come from a single process, then the data is
not normal.
277
Histograms can also have several other common shapes, especially when presenting non-
normal data or data that has an error or issue. If the histogram appears very random, as in
the first example below, then it’s possible an error lies within the data measurement
process. The measurement might not be adequate to capture the true picture of the
process, or the definition of the operation and how to collect data might be at fault. The
same is true if the histogram depicts an almost even distribution of data elements among
bins.
278
A skewed distribution, seen in the second diagram above, features data that is clustered at
only one end of the graph. Skewed histograms are common with certain types of data,
particularly when data “falls off” at a natural cut-off time. For example, in a call center, you
might measure the time it takes representatives to complete a certain type of phone call. A
natural end-point for that data is 0 – it will always take more than 0 seconds to complete a
phone call. sually, it will take more than a few seconds, so you won’t have many data points
in the lower end of the range. Perhaps this particular phone call follows a script and the
majority of the calls end at the 7 to 8-minute mark. A histogram for length of calls might
look something like the chart below.
279
Consider the basic example below to understand histograms further.
A local distribution company wants to understand more about how well delivery drivers are
meeting estimated arrival times. The team pulls a random sample of deliveries from a
week’s worth of information and considers two data points for each delivery: the estimated
time of delivery and the actual time of delivery. They subtracted the actual time from the
estimated time to determine how far off one way or the other the deliveries were. The
result was the following data table.
Difference in
Estimate Actual minutes
8:00 AM 7:55 AM -5
8:30 AM 8:20 AM -10
8:50 AM 9:07 AM 17
9:15 AM 9:23 AM 8
9:45 AM 9:46 AM 1
10:05 AM 10:03 AM -2
10:30 AM 10:33 AM 3
10:55 AM 11:05 AM 10
11:30 AM 11:27 AM -3
12:45 PM 12:32 PM -13
1:30 PM 1:35 PM 5
1:45 PM 1:57 PM 12
2:20 PM 3:01 PM 41
3:00 PM 3:48 PM 48
3:30 PM 3:05 PM -25
280
8:50 AM 8:45 AM -5
9:15 AM 9:58 AM 43
9:45 AM 10:21 AM 36
10:05 AM 10:09 AM 4
10:30 AM 10:03 AM -27
1:45 PM 1:46 PM 1
2:20 PM 2:54 PM 34
3:00 PM 3:04 PM 4
3:30 PM 3:23 PM -7
11:30 AM 11:16 AM -14
To create a histogram, the team sorted the selection by difference in minutes and
discovered the range as -27 to 48. The team decided to create a histogram from -30 to 50
with a bin size of 10. The resulting data is as follows:
Bin Frequency
-30 0
-20 2
-10 3
0 5
10 8
20 2
30 0
40 2
50 3
281
To create the above table, the team simply counted how many data points fell in each bin.
The data points -27 and -25 fell into the bin -20 (to -29); that is 2 data points. Eight data
points fell into the 10 bin. When charted on a bar chart, this information creates a
histogram.
When dealing with histograms, the number of bins used is important. If you have too few
bins, the graph doesn’t provide any relevant information. If you have too many bins for the
data set in question, you also lose informative functionality and your graph, rather than
appearing as a rough curve, becomes something that looks like a comb. Usually, the more
data you have, the more bins you can include on your histogram.
Consider the following four histograms that all represent the same set of data. The data
features 150 random numbers ranging from 38.62 to 62.89.
282
283
The bin sizes get progressively smaller as the number of bins increase. In the first chart, bin
sizes are 5; in the last chart, bin sizes are 0.5. For the purposes of understanding what type
of data is represented in this histogram, the second or third charts are probably the most
284
relevant. We’ll cover determining data type from a histogram and associated statistics later
in this chapter.
Before moving on with probability distributions, we’ll look at creating histograms in Excel
using the Analysis ToolPak that was discussed in the last chapter.
1. Open Excel and copy the following data table into a blank workbook.
56.1
38.2
47.1
48.1
60.1
45.8
33.4
49.2
53.1
41.8
19.2
49.3
49.0
61.8
42.4
53.2
285
61.6
20.8
55.2
57.5
48.8
28.9
33.8
53.2
58.0
47.3
51.4
61.5
58.9
60.4
30.7
52.5
40.7
44.8
54.6
61.6
31.0
52.7
47.5
286
26.3
71.3
61.8
51.9
43.9
50.0
47.4
61.9
51.8
50.4
61.0
2. Copy the following bin designations into the second column in the same worksheet.
10
15
20
25
30
35
40
45
50
55
287
60
65
70
75
3. Select Data > Data Analysis
4. Select Histogram and click OK.
5. Click in the Input Range box, and then highlight the cells for the input range (the 50
data cells you copied from above).
6. Click in the Bin Range box, and then highlight the cells that include the bin data you
copied from above.
7. Check the New Worksheet Ply: option.
8. Check the Chart Output option.
9. Ensure that your Histogram dialog box appears as below.
288
10. Click OK.
Excel automatically generates a bin and frequency table as well as a histogram graph in a
new worksheet. The histogram design defaults to a standard bar graph, but you can create
the look of the histograms previously shown by changing one setting on the design.
289
1. Click on the histogram.

2. Select Design from the top menu.
3. Under Quick Layout, choose the layout where the bars are stacked next to each
other rather than with space between them.
Your result should look like the graph below.
290
Experiment with your own data, creating histograms with various bin sizes to begin to
develop an understanding of how data converts to this type of chart.
Normal distribution, also called Gaussian distribution, is probably the most important
distribution related to continuous data from a statistical analysis standpoint. A normal, or
Gaussian, distribution is depicted below.
291
Normal data is shaped symmetrically surrounding the mean, represented above by the x-
bar line. A normal curve is beneficial for determining the probability that a given data point
in a population will fall inside a certain range within the distribution.
In a perfect normal distribution, 68.26 percent of all data points fall within plus or minus
one standard deviation from the mean; this area is represented by the red arrow on the
visual above. The blue arrow, which covers plus or minus two standard deviations from the
mean, indicates the area under the curve that includes 95.46 percent of the data points.
The purple area, which covers plus and minus three standard deviations from the mean,
indicates the portion of the curve that covers 99.73 percent of the data. Less than 1 percent
of data will fall under the curve outside of three standard deviations on either side.
Distributions – even normal distributions – vary a bit. To determine the exact probabilities
of various data points, advanced statistics are required; Excel and other programs perform
the calculations for you, making it easier to conduct analysis. Before we discuss probability
calculations using Excel, we’ll look at determining whether your data is normal in the first
place.
Testing whether data is normal is critical to many steps in statistical analysis, because the
results of many tests can be invalid if you don’t account for the data you are working with.
The most basic form of many of these tests are designed to work with normal data.
292
We’ve touched on how visual inspection can help you determine whether data is normal or
not. The histogram below, taken from earlier in the chapter, presents what seems to be
obviously normal data. Data points converge around the center, and the histogram is
roughly symmetrical in nature.
But what about this histogram, which is the one created in the practice exercise in the
section on creating histograms in Excel?
293
The histogram above is an example of a chart that doesn’t fall neatly into any of the
histogram shapes previously discussed. It seems to have elements of the normal curve, but
it could also be skewed data. This is why we perform statistical tests to determine
normality.
You’ll usually begin exploring probability data by following the instructions in the previous
section to create a histogram for the data. For the example of the normality test, we’ll use
the same data from the section above, which is:
19.2
20.8
26.3
28.9
30.7
31
33.4
33.8
38.2
40.7
41.8
42.4
43.9
44.8
45.8
47.1
47.3
294
47.4
47.5
48.1
48.8
49
49.2
49.3
50
50.4
51.4
51.8
51.9
52.5
52.7
53.1
53.2
53.2
54.6
55.2
56.1
57.5
58
295
58.9
60.1
60.4
61
61.5
61.6
61.6
61.8
61.8
61.9
71.3
Creating a histogram using the Analysis ToolPak generates a chart and a data table, as seen
below.
296
Use the Descriptive Statistics option in the Analysis ToolPak to quickly generate descriptive
statistics for your data set.
1. Select Data > Data Analysis > Descriptive Statistics

2. Click OK
3. Click in the Input Range box and select your input range using the mouse.
297
4. In this case, the data is grouped by columns. In most statistical analysis, that will be
the case, but if you have data grouped by rows, you should change the Grouped By
selection.
5. Select to output information in a new worksheet.
6. Ensure at least the Summary statistics box is checked. You can also check the
Confidence level for mean and the Kth largest and smallest boxes, though that
information isn’t required in the Chi-Squared Goodness-of-Fit test, which is the test
we are running to test for normality of the data. If you check these extra boxes,
Excel will simply provide you with additional information that we won’t be using at
this time.
298

Six Sigma A Complete Step by Step Guide

Uploaded by

Copyright:

Available Formats

Six Sigma A Complete Step by Step Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Six Sigma A Complete Step by Step Guide

Uploaded by

Copyright:

Available Formats

SIX SIGMA:

A COMPLETE STEP-BY-STEP GUIDE

July 2018 Edition

Using the most recent edition in your workplace?

Without proper measurement and

Consider an example based on Amazon shipments. On Cyber Monday in 2013, Amazon

Cost of Amazon Order Errors, 5

36.8 million 8574.4 $35 $300,104.00

Cost of Amazon Order Errors, 6

36.8 million 125.12 $35 $4,379.20

One Sigma 690,000 25,392,000 $888,720,000

Two Sigma 308,000 11,334,400 $396,704,000

Three Sigma 66,800 2,458,240 $86,038,400

Four Sigma 6,200 228,160 $7,985,600

Five Sigma 233 8,574.4 $300,104

Six Sigma 3.4 125.12 $4,379

Consider a process in a marketing department that distributes letters to customers or

((150,000 – 750) / 150,000) * 100 = a yield of 99.5

Yield % DPMO Sigma Level

99.7450 2,550 4.3

99.6540 3,460 4.2

99.5340 4,550 4.1

99.3790 6,210 4.0

99.1810 8,190 3.9

Process Performance Metric(s) Current Sigma Level

Attaching a decorative Decorative touch is 2.2

Packing product Product is sealed for 3.1

Shipping of product Product reaches the right 4.3

Removing waste—items, actions, or people that are unnecessary to the outcome of a

Implementing improved processes is a temporary measure unless organizations equip their

 Discovering that an important process metric is not being captured

 Defining customer values

At the time, departments across Motorola measured defects as a ratio of a thousand

 Six Sigma roles

The following concepts are often included in Green Belt training:

 All of the information listed for yellow belt certification

 Advanced project and team management skills

Lean Process Management can be deployed within a project environment or in daily

Total Quality Management, or TQM, is a phrase well-known by anyone who worked in

 A strict quality commitment at all levels of the organization, especially among

TQM began to change departmental thinking on a massive scale: organizations began to

Organizations using TQM often experienced benefits such as:

 Improved employee engagement and morale

 Sandbox testing of basic functionality

 A rollout of the program to the enterprise, often conducted in a phased approach

One of the foundational components of Rummler-Brache is known as the Nine Boxes

Management Design Goals

Performer Concerned with Concerned with Concerned with

Process Concerned with Concerned with Concerned with

Organization Concerned with Concerned with Concerned with

Rummler-Brache approaches improvement in six phases:

 Improvement planning. During the first phase, leadership and subject-matter-

Scrum is a project development method specific to Agile programming endeavors in

Scrum projects feature three main phases:

 The pregame. Development teams analyze available data and business

Like Rummler-Brache, the Customer Experience Management Method, or CEM Method,

 The caller reports damage to the car.

Muda of inventory is similar to muda of overproduction; in fact, overproduction can cause a

Muda of conveyance is similar to muda of movement except conveyance involves the