Chapter 3: Other Process Improvement and
Quality Methods
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.
Other Formal Quality or Process Improvement Programs
Lean Process Management
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.” 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
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
Page | 26
© 2018 The Council for Six Sigma Certification. All rights reserved.
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
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
Page | 27
© 2018 The Council for Six Sigma Certification. All rights reserved.
Business Process Reengineering
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 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
• 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
Page | 28
© 2018 The Council for Six Sigma Certification. All rights reserved.
Rummler-Brache
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.
Management Design Goals
Performer Concerned with Concerned with the Concerned with
feedback, tools and training performance metrics
consequences, and needed to do the job as and requirements at an
rewards well as job individual level
documentation
Process Concerned with who Concerned with the Concerned with the
owns the process and design of the process, requirements of the
how they might work space, or system business and the
improve it customer
Organization Concerned with overall Concerned with overall Concerned with
leadership culture and org charts and process operating plans and
the requirements of architecture top-level 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.
Page | 29
© 2018 The Council for Six Sigma Certification. All rights reserved.
• 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.
• 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
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.
The Customer Experience Management Method (CEM)
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.
Page | 30
© 2018 The Council for Six Sigma Certification. All rights reserved.
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
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.
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.
Page | 31
© 2018 The Council for Six Sigma Certification. All rights reserved.
When to Use Six Sigma
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.
When facing the unknown
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.
When problems are widespread and not defined
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.
When solving complex problems
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.
When costs are closely tied to processes
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.
Page | 32
© 2018 The Council for Six Sigma Certification. All rights reserved.
