Chronicle of a Six Sigma Project
	Six Sigma originated with manufacturing, but works with transactional functions as well. Transactional functions involve exchange of goods, services, or information rather than making a product. Technical Communication is an excellent example of a transactional function that can benefit from Six Sigma methodologies. Other examples are Purchasing, Information Technology, Sales, Customer Support and Service, and Human Resources. Savvy companies are now deploying Six Sigma tools in these areas and seeing the benefits. This article describes an actual Six Sigma project that was successfully completed by a team of technical communicators. How did the process work, and what tools did this team apply? Chartering the Project Phases of a Six Sigma Project Define Phase Measure Phase Analyze Phase Improve Phase Control Phase Six Sigma as a Way of Life
Chartering the Project	Six Sigma certification (as a Black Belt or Green Belt) typically requires completion of a project that demonstrates ability to follow the Six Sigma process and competency with the tools. Selecting a project can be the first major challenge of the certification effort, and defining the project the first usage of Six Sigma tools. (Criteria for good Six Sigma projects are presented in “Choosing a Six Sigma Project,” published in the STC Rochester Chapter Proof Sheet online in October 2002, www.stcrochester.org/newsletter.htm.) The Project Charter is the first tool used in the process. It documents the goal of the project, identifies the players, and sets forth the expected outcome of the project. The project described here focused on development of documentation for a new product. The technical communications team was charged with making the leap from paper-delivered manuals to electronic delivery, with the documentation becoming part of the product. The team’s past experience with electronic documentation was limited to online help text for screens. The team knew that the methods used to create help text needed improvement. Writers had created the help text using FrameMaker templates and delivered output text files to software development. Once the help text was incorporated into the product and the software was submitted for testing, many errors were found. The errors necessitated multiple cycles of rework and retesting. This “hidden factory” was unacceptable. The team chartered the project with a goal of minimizing or eliminating defects in the electronic documentation before delivery to the software-testing phase. The project met the criteria requiring that a Six Sigma project must: Save money. By reducing rework and retesting, the company would save more than $63,000. Improve a clear process. Know the customer. The immediate customer was the software testing team, while the ultimate customer was the end user. Identify defects. The team knew it was necessary to eliminate defects, such as broken HTML links or missing files. Identify measures. The team could measure the number of files written and analyze the potential number of errors that could occur with each file. Ensure importance to the business. The issue was critical to the business, since problems with the documentation could have an impact on product delivery. Ensure organizational support. The team had full support due to the project’s importance to product delivery and the cost avoidance it represented. Back to top
Phases of a Six Sigma Project	Once chartered, Six Sigma process improvement projects follow a five-phase process typically characterized as Define, Measure, Analyze, Improve, and Control (DMAIC). If a new process is being developed, the phases are called Define, Measure, Analyze, Design, Verify, and Validate (DMADVV). Specific tools are used in each phase. Since this team was improving an existing process, the team followed the DMAIC process. Back to top
Define Phase
Voice of the Customer	Before starting to improve a process, it is essential for the team members to understand who the customers are and what they want. By listening to the Voice of the Customer, a team can clearly understand the elements that are critical to quality for the customer. Everything done in the project revolves around those Critical to Quality (CTQ) elements. The team returns to the Voice of the Customer study many times to make sure the project remains on the right path and will deliver what the customer needs and wants. There are several ways to listen to the Voice of the Customer. Interviews, surveys, and questionnaires are possibilities. This team collected the Voice of the Customer through a series of meetings with actual customers of the product. By sitting down with the customers and asking, “What would you want in an electronic documentation system?” the team discovered that customers wanted usable documentation that was delivered at the point of need. The customers wanted the documentation to be available, accurate, and clear. It was Critical to Quality that the links between the HTML files worked, that the documentation was easy to use and navigate, and that screens were formatted correctly and contained correct content. By analyzing these elements, the team realized that the electronic documentation would require extensive functional review to make sure these CTQ elements were met.
SIPOC	Moving further into the Define phase of the project, the team created a SIPOC diagram for the existing help text development process. SIPOC is an acronym for Suppliers, Input, Process, Output, and Customer. The SIPOC diagram forms the basis for much of the analysis done through the rest of the project. The SIPOC diagram includes a high-level map of the process, showing its basic steps. Through the process, the suppliers provide input. The process adds value, resulting in output that meets or exceeds the customer expectations. By analyzing the SIPOC diagram, the team recognized that the current process included good review and approval steps for the help text, a step towards meeting all the CTQ elements.
Process Map	The Process Map is an extension of the SIPOC diagram. The process map is a visual representation of the workflow in a process, showing the way the inputs and outputs flow through the process. Using a process map, a person totally unfamiliar with the work should be able to understand the way product moves through the process from beginning to end. In technical communication projects, the process map may depict information flow. The process map for the electronic documentation project matched the process steps identified in the SIPOC analysis. The team examined the inputs to determine which were standard procedures guiding the process, as well as which inputs were controllable and which were not controllable. The team also identified the variability associated with the process output, in characteristics including timeliness, accuracy, and completeness. Variability was what they aimed to reduce or eliminate. In studying the process map, the team discovered that the review and approval steps focused on content rather than function. Those steps were not adequate to ensure meeting the identified CTQs. Information was needed to determine what types of errors were not being identified during these steps.
Data Collection	Data collection is at the heart of the Six Sigma process. Six Sigma teams study data in order to understand the current state of the processes they want to improve and to analyze how their projects will affect the process. They generate data to verify that the improvements are actually making the process better. Two types of data are studied. Discrete data includes counts, percentages, and attributes (such as pass/fail or good/bad). Continuous data is obtained by use of a measuring system. Length, width, time, and distance are examples of continuous data. Most often, projects in transactional areas such as technical communication gather discrete data. We can count elements such as number of pages, number of people, number of steps, or number of errors. We might also be able to measure continuous data such as the amount of time in a review cycle. How can a team collect data? Team members may be able to look directly at whatever process is being studied and record data by “walking the process.” On other occasions, a team must rely on historical records. Back to top
Measure Phase	Moving into the Measure phase of the project, the team obtained records showing errors found in the help text during testing for recent releases of the product. By analyzing the errors, the team was able to assign the errors to one of five categories: formatting, translation, content, missing help, and links to the wrong help screens.
Pareto Chart	The team used a Pareto Chart to analyze the items and discovered that the majority of the problems with the current help text fell into the formatting and translation categories. Content was not a major issue, so the team knew that the existing review and approval steps were working when it came to content. Data collection and analysis provided the team a clear focus. Translations were outside the project scope (but would become a Six Sigma project later). The team could concentrate on improving the process to eliminate the formatting errors.
Failure Modes and Effects Analysis (FMEA)	A Failure Modes and Effects Analysis (FMEA) helps identify possible failures within a product or process. By asking, “What can go wrong?” and “What will happen if this goes wrong?” the team can understand what steps in the process are the highest risk and deserve the most attention. For each step in the SIPOC diagram and process map, the team asked these questions and checked to see if controls were in place to catch the failure before it became a problem. One control that was clearly missing was verification of the help text before it was handed off to software testing. The help text authors had no way of seeing the documentation in its final form, so all errors had to be caught in the software testing phase. The analysis showed that the highest risk lay in the release step. If release occurred without verification of the electronic documentation, all CTQs would be compromised! The team completed the Measure phase with a focused problem statement: Currently, help text authors could not see electronic documentation files, as they would be shown in final form. That meant that errors in formatting and other problems could not be found before delivery to software testing, creating the need for extensive rework and retesting. Back to top
Analyze Phase	The team entered the Analyze phase of the project with a sharpened focus. Its members needed to learn why the errors in the help text were occurring and devise a way to catch the errors before the new electronic documentation left the authors’ hands.
Cause and Effect Diagram	The team found the creation of a Cause and Effect Diagram to be a breakthrough for the project. On the far right, the diagram has a simple statement of the basic problem: In this case, the help text contained errors. To create the diagram, the team started with the problem statement and asked “Why?” a total of five times. The help text contained errors. Why? Because there were problems with the formatting. Why? Because some screens were not formatted according to standard. Why? Because authors had not applied the help text template consistently. Why? Because authors had not been trained in the template. Why? Because there was no time to train them. As the team worked through the cause and effect analysis, focusing on each type of error found during the Measure phase, a theme showed up frequently and consistently—“no time.” The team realized that this did not mean asking for more time on the project. Rather, verification of the electronic documentation needed to be an integral part of the project plan, not supplemental to it. Time for verification had to be planned into the project schedule.
Design of Experiments	The team continued the Analysis phase of the project by exploring methods for making verification happen as part of the documentation development process. The team wanted to ensure that verification would meet the goal of the Six Sigma project: to minimize or eliminate the errors in the electronic documentation before hand-off to software testing. The team realized the goal could be met if the authors could view the electronic documentation exactly as it would appear in the new product. The team explored available technology and found a method of software emulation that made this possible. The authors could test the documentation within their own environment and correct errors before release. The challenge became development of a testing scenario that would meet the rigorous requirements of software testing. Under the guidance of the software-testing group, the team created test cases and decided to conduct an experiment designed to prove that the test cases would be adequate for finding errors in the help files. The experiment had a two-level, full-factorial design. The team created two prototype electronic documentation files. One was a “clean” file that had been reviewed and was error-free. The other contained documented errors deliberately introduced by the team. The team developed a detailed test case for the prototype software module, and had two independent evaluators test the modules. The evaluators did not know they were participating in a designed experiment, or that they were working with “manipulated” files. The experiment called for each evaluator to test each of the “clean” and “dirty” files multiple times, using both the test case and a random method whereby they were asked to look for errors in the files. The hypothesis was that the test case would not make a difference in the number of errors found; the alternate hypothesis was that the test case made a significant difference. Once the experiment was completed and analyzed statistically, the team determined that the test case made a significant difference. Each evaluator found more errors when using the test case than when using no test case. Thus backed by data, the team believed that verification of the files using a test case was the solution to reducing or eliminating errors prior to software testing.
Gage R&R	But how good were the test cases? The team decided to use an analysis tool called Gage R&R to measure the test cases. Long used in manufacturing projects, Gage R&R determines the repeatability and reproducibility of a process. Gage R&R helps the team understand variation between parts, between operators, and between operators and parts. This is simpler to determine in a manufacturing environment where “parts” are clearly understood. What is a “part” in technical communication? In this case, the “part” was an electronic documentation file. To set up the Gage R&R, the team created three sets of files. One was “clean.” One contained an intermediate number of deliberately introduced errors, and one was the “dirty” file used during Design of Experiments. The team chose three evaluators (who had no familiarity with their process or their files) to test the files using test cases. Each of the evaluators tested each of the three files twice. The resulting Gage R&R showed: The test cases were able to determine part-to-part (file-to-file) variation. The evaluators were consistently measuring the same way. The parts (files) were more variable than the measurement system. Variation by file showed evidence of the three levels of files. Variation between operators was small. The operator/file interaction showed some significant differences. The team questioned this significance and found that, during the last rounds of testing, many errors occurred with the software used in the testing. Following up with the software developers, the team discovered that the prototype software was not robust and had begun to fail after intensive use. The team knew that the solution was good and the measurement system—the test cases—would work. Also, by analyzing the results of the Gage R&R, the team knew that robust software would be required during verification efforts. Back to top
Improve Phase	Entering the Improve phase, the team had a single solution in hand. They developed an implementation plan for verifying the electronic documentation using approved test cases prior to handing off the files to software testing. The resulting Verification Plan was approved by management and became an official company document. The plan included: Adding a verification and correction cycle to the current development process Documenting the new process with a SIPOC diagram Ensuring that the test cases used in verification were robust and accurate Ensuring that the authors of the electronic documentation files were not permitted to test their own work Ensuring that the evaluators were trained and aware of their role in the process Ensuring that management was aware of the importance of the process Ensuring that adequate time for the reviews and correction cycle was built into the development process Back to top
Control Phase	Finally, the team was ready to decide how to control the new process once it was in place. How could they be sure that the plan continued to be successful? The team decided to monitor the reports of errors documented during software testing. If testing identified any errors in the electronic documentation, the software-testing group would notify the team leader. The team leader set up a series of control charts to track reported errors. The expectation was that in the beginning of the new process, some errors might be discovered. However, if the new process worked, the team expected to see the number of errors decrease significantly; ultimately to zero. The team leader would continue to monitor any errors and pay attention to any trends or shifts that became evident. If the number of errors began to increase, the team would investigate the cause. For example, the team would ensure that the verification plan was being followed and the test cases being used appropriately. Back to top
Six Sigma as a Way of Life	The project was completed. But the work did not end there! During the Measure phase, the team discovered that translations were another area of concern related to the help text. This became the target of a new Six Sigma project. The team leader was certified as a Black Belt, and chartered projects with the company’s translation supplier to improve the translation and the translation review process. By doing so, the company could make sure that its suppliers were also using Six Sigma to improve their processes, resulting in savings of time and money for everyone. The team members continue to use their knowledge. One of them is now a Black Belt candidate and the team leader a Master Black Belt candidate. The other team members continue to apply the Six Sigma tools in their daily work. For this successful Technical Communications group, Six Sigma is now a way of life. Back to top For more information about Six Sigma tools and methods, visit www.isixsigma.com.
	About the Author: Jill Finan is a past president of the STC Rochester Chapter. She is a certified Black Belt and Master Black Belt candidate at Ortho-Clinical Diagnostics, Inc., a Johnson & Johnson Company. Back to top