This document provides an introduction to Six Sigma, including its history, definitions, methodology, and applications for technical writers. It describes how Six Sigma originated from earlier quality management techniques and was developed at Motorola in the 1980s. The core of Six Sigma aims to reduce defects through statistical analysis and process improvement. An imaginary case study demonstrates how the DMAIC methodology could be applied to reduce errors in technical documentation. It outlines defining the problem, measuring the current process, analyzing causes of errors, improving the process, and controlling quality going forward. The document also briefly discusses Design for Six Sigma and training levels for Six Sigma practitioners.

1. 1
What Is Six Sigma?
An Introduction for Technical Writers
Philadelphia Metro Chapter
Society for Technical Communication
20 September 2007

2. 2
Overview
 History
 What is it?
 A brief introduction with imaginary case
study
 The belt pecking order
 Where to go for more information
 References

3. 3
History
 1908 – W.S. Gosset develops statistical tests
to analyze quality at Guinness Brewery
 1950s Deming – helped build Japan’s
economy after World War II (Total Quality
Control)
 1980s – Dr. Mikel Harry and Bill Smith invent
Six Sigma at Motorola
 Currently – thousands of companies have
adopted the methodology

4. 4
What Is It?
 Common sense – you probably already
know a lot
 Business philosophy: system for
improving processes in an organization
 Metrics
 Statistical concept

5. 5
Three Flavors
 Six Sigma – reduce defects
 Design for Six Sigma – design new
products
 Lean – reduce waste

6. 6
Six Sigma – The Literal Definition
26 (Lower Limit)
30 mph
35 mph25 mph
34 (Upper Limit)

7. 7
What Level of Quality Is Acceptable for
Your Product?
 4 sigma – 99 percent
 6 sigma – 99.9997 percent
 7 sigma – 99.99999999974 percent

8. 8
The Methodology:
New Tools, New Words
 Quality
 SIPOC
 Failure Mode Effects Analysis
 Process Map
 Control Chart
 ANOVA
 p-Values
 Quality Functional Deployment
 Rolled Throughput Yield
 Metrics
 Stakeholders
 Team
 Critical to Quality
 Voice of the Customer
 DMAIC

9. 9
Imaginary Case Study
Design, Measure, Analyze,
Improve, and Control (DMAIC)

10. 10
Case Study: Imaginary
 Help Desk getting more calls since the release
of NovelPro version 3
 The company is faced with hiring more Help
Desk employees
 The software works as designed: no bugs
reported
 The Help Desk reports many complaints about
the quality of the documentation
 The technical writing staff was reduced by 50
percent in 2006

11. 11
DMAIC: Define

12. 12
Talk to Your Customers
 Identify Stakeholders and Team
 Talk to Your Customer – surveys,
interviews, focus groups – voice of the
customer (VOC)
 Identify Critical to Quality (CTQ) Items
 Create a CTQ Flowdown

13. 13
CTQ Flowdown

14. 14
Next . . .
 Problem Statement
 Goal
 Analyze Current High-Level Process
 SIPOC Map (Suppliers, Inputs, Process,
Outputs, Customers)
 Process Flow
 Define scope of project
 Figure out what you’re going to fix (Y)

15. 15
Problem and Goal Statements
 In the TechComm Department for fourth
quarter 2007, there has been a 50%
increase in the number of errors from 10
to 15. This exceeds the organizational
control limit of no more than 12 errors.
 Goal Statement: Reduce errors from 12
to 10 or less by June 31, 2008.

16. 16
Time Series Plot of Reported Errors
NovelPro 3,
2007
NovelPro 2, 2006
Time
Reportederrors

17. 17
CustomersProcessInputsSuppliers Output
s
S I P O C
Software
developers
Users of
software
Marketing
Department
Technical
Writers
Templates
Style Guide
Procedures
Software
Design
Document
Beta Version
of Software
Review with
Marketing
Design
Document
Review Software
Design
Write/Layout
Manual
Review
Completed
User Manual
Developers
Help Desk
Proofreaders
Marketing
Other TWs
New
Templates
Updated
Style Guide
Updated
Procedures
DirectIndirect
Proofread
Publish

18. 18
Scope
 This project will cover the process of
developing documentation from the time
the design documents are released to
the time when the documentation is in
production.

19. 19
What We’re Going to Fix – “Y”
 Y = f(x)
 Reduce number of errors in NovelPro
documentation

20. 20
Other “Define” Tasks
 Identify project risks
 Develop timeline
 Communication plan

21. 21
DMAIC: Measure

22. 22
DMAIC: Measure
 Develop a detailed process flow
 Collect data on how the process is
working
 Validate your measurement system
 Quantify process performance

23. 23
Process Flow

24. 24
Collect Data
 Plan your data collection
 May use statistical sampling
 Data must be “clean”

25. 25
Measure Steps in the Process
In this case, we might measure errors:
 In design document
 Proofreading errors
 Errors caused by lack of review
 Errors introduced in publication process

26. 26
Validate Measurement System
 Identify existing system
 Analyze
 Is it accurate and precise?
 Improve measurement system

27. 27
Verify that Process Is Stable
 You can predict how a process is
performing
 Doesn’t mean the process doesn’t
fluctuate
 So, you can predict that 10 to 20 errors
are made per topic in documentation in
the current state

28. 28
Simplify
 Sometimes you can find opportunities to
fix things just by process mapping, not
requiring six sigma rigor
 Low-hanging fruit

29. 29
DMAIC: Analyze

30. 30
Why?
 Focus on the x’s that influence the Y you
are working with – output is a function of
input or Y = f(x)
 Work with stakeholders to figure out cause
and effect
 Use data collected in Measure and
statistics (root cause analysis)
 Quantify the opportunity

31. 31
Work with Stakeholders
 Stakeholders should be:
 Balanced representatives
 Equally matched (higher-level employee
doesn’t trump lower)
 Some ways to identify x’s with team:
 Brainstorming
 Cause and effect diagram

32. 32

33. 33
Pareto Chart

34. 34
You May Do Other Analyses
 Histogram
 Design of Experiments
 Scatter Diagram
 Control Charts
 Process Capability

35. 35
DMAIC: Improve

36. 36
Improve
 Create solutions
 Brainstorm
 Gather from others who do similar work
(benchmarking)
 Quality Function Deployment (QFD)

37. 37
Evaluate and Select Solutions
 Evaluate
 Select Solution
 Pilot
 Evaluate
 Revise your flow chart: ideal process

38. 38
Revised Flowchart
This is where we
removed a step

39. 39
Implement Solution
 Present solution to management to get
buy-in
 Identify Risks
 Implementation Plan
 Document process
 Train
 Execute
 Communicate

40. 40
DMAIC: Control

41. 41
Control
 Ensure that your improvement continues
to work over time
 Develop a process control plan
 List the important x’s identified
previously
 Keep under control
 Monitor Y

42. 42
Sample Control Plan

43. 43
More Control
 Mistake proof
 Update the Failure Mode Effects
Analysis
 Standardize (Standard Operating
Procedures)

44. 44
Design for Six Sigma

45. 45
Design for Six Sigma
Consists of DMADV (Define Measure Analyze Design Verify)
 Define customer requirements and goals for the process, product
or service.
 Measure and match performance to customer requirements.
 Analyze and assess the design for the process, product or
service.
 Design and implement the array of new processes required for
the new process, product or service.
 Verify results and maintain performance.

46. 46
What DFSS Is Used For
 Requirements for New Systems
 Could be used to
 design a new user manual
 create a process for single sourcing
 create a translation process

47. 47
The Levels of Six Sigma
Training:
The Belts

48. 48
Master
Black
Belt
Black Belts
Green Belts
Team Members
Champions
The “Belts”

49. 49
Ideas for Projects
 Design for a single-sourcing system
 Revising a user manual
 Prepare for a new documentation project: add
to your “project management” bag of tricks
 Designing or updating translation process
 Any production process
 Collecting functional requirements for a new
computer system

50. 50
Where to Get Your Greenbelt
 Six Sigma Academy
 George Group
 SBTI
 Villanova On-Line
 Drexel In-Person
 American Society of Quality
. . . And many more

51. 51
References
 Six Sigma web site
 Brassard, Michael and Ritter (2001)
Sailing Through Six Sigma, Marietta,
Georgia: Brassard & Ritter, LLC.
 DeCarlo, Neil with the Breakthrough
Management Group (2007)The
Complete Idiot’s Guide to Lean Six
Sigma: New York, NY: Alpha Books