Purpose and Origin

Six Sigma (6) is a business-driven, multi-faceted approach to process improvement, reduced costs, and increased profits. With a fundamental principle to improve customer satisfaction by reducing defects, its ultimate performance target is virtually defect-free processes and products (3.4 or fewer defective parts per million (ppm)). The Six Sigma methodology, consisting of the steps "Define - Measure - Analyze - Improve - Control," is the roadmap to achieving this goal. Within this improvement framework, it is the responsibility of the improvement team to identify the process, the definition of defect, and the corresponding measurements. This degree of flexibility enables the Six Sigma method, along with its toolkit, to easily integrate with existing models of software process implementation.

Six Sigma originated at Motorola in the early 1980s in response to a CEO-driven challenge to achieve tenfold reduction in product-failure levels in five years. Meeting this challenge required swift and accurate root-cause analysis and correction. In the mid-1990s, Motorola divulged the details of their quality improvement framework, which has since been adopted by several large manufacturing companies. [Harry 00, Arnold 99, Harrold 99 ]

Technical Detail

The primary goal of Six Sigma is to improve customer satisfaction, and thereby profitability, by reducing and eliminating defects. Defects may be related to any aspect of customer satisfaction: high product quality, schedule adherence, cost minimization. Underlying this goal is the Taguchi Loss Function [Pyzdek 01], which shows that increasing defects leads to increased customer dissatisfaction and financial loss. Common Six Sigma metrics include defect rate (parts per million or ppm), sigma level, process capability indices, defects per unit, and yield. Many Six Sigma metrics can be mathematically related to the others.

The Six Sigma drive for defect reduction, process improvement and customer satisfaction is based on the "statistical thinking" paradigm [ASQ 00], [ASA 01]:

Everything is a process

All processes have inherent variability

Data is used to understand the variability and drive process improvement decisions

As the roadmap for actualizing the statistical thinking paradigm, the key steps in the Six Sigma improvement framework are Define - Measure - Analyze - Improve - Control (see Figure 1). Six Sigma distinguishes itself from other quality improvement programs immediately in the "Define" step. When a specific Six Sigma project is launched, the customer satisfaction goals have likely been established and decomposed into subgoals such as cycle time reduction, cost reduction, or defect reduction. (This may have been done using the Six Sigma methodology at a business/organizational level.) The Define stage for the specific project calls for baselining and benchmarking the process to be improved, decomposing the process into manageable sub-processes, further specifying goals/sub-goals and establishing infrastructure to accomplish the goals. It also includes an assessment of the cultural/organizational change that might be needed for success.

Once an effort or project is defined, the team methodically proceeds through Measurement, Analysis, Improvement, and Control steps. A Six Sigma improvement team is responsible for identifying relevant metrics based on engineering principles and models. With data/information in hand, the team then proceeds to evaluate the data/information for trends, patterns, causal relationships and "root cause," etc. If needed, special experiments and modeling may be done to confirm hypothesized relationships or to understand the extent of leverage of factors; but many improvement projects may be accomplished with the most basic statistical and non-statistical tools. It is often necessary to iterate through the Measure-Analyze-Improve steps. When the target level of performance is achieved, control measures are then established to sustain performance. A partial list of specific tools to support each of these steps is shown in Figure 1.

Note:Many tools can be effectively used in multiple steps of the framework. Tools that are not particularly relevant to software applications have not been included in this list.

Figure 1: Six Sigma Improvement Framework and Toolkit

An important consideration throughout all the Six Sigma steps is to distinguish which process substeps significantly contribute to the end result. The defect rate of the process, service or final product is likely more sensitive to some factors than others. The analysis phase of Six Sigma can help identify the extent of improvement needed in each substep in order to achieve the target in the final product. It is important to remain mindful that six sigma performance (in terms of the ppm metric) is not required for every aspect of every process, product and service. It is the goal only where it quantitatively drives (i.e, is a significant "control knob" for) the end result of customer satisfaction and profitability.

The current average industry runs at four sigma, which corresponds to 6210 defects per million opportunities. Depending on the exact definition of "defect" in payroll processing, for example, this sigma level could be interpreted as 6 out of every 1000 paychecks having an error. As "four sigma" is the average current performance, there are industry sectors running above and below this value. Internal Revenue Service (IRS) phone-in tax advice, for instance, runs at roughly two sigma, which corresponds to 308,537 errors per million opportunities. Again, depending on the exact definition of defect, this could be interpreted as 30 out of 100 phone calls resulting in erroneous tax advice. ("Two Sigma" performance is where many noncompetitive companies run.) On the other extreme, domestic (U.S.) airline flight fatality rates run at better than six sigma, which could be interpreted as fewer than 3.4 fatalities per million passengers - that is, fewer than 0.00034 fatalities per 100 passengers [Harry 00], [Bylinsky 98], [Harrold 99].

As just noted, flight fatality rates are "better than six sigma," where "six sigma" denotes the actual performance level rather than a reference to the overall combination of philosophy, metric, and improvement framework. Because customer demands will likely drive different performance expectations, it is useful to understand the mathematical origin of the measure and the term "six-sigma process." Conceptually, the sigma level of a process or product is where its customer-driven specifications intersect with its distribution. A centered six-sigma process has a normal distribution with mean=target and specifications placed 6 standard deviations to either side of the mean. At this point, the portions of the distribution that are beyond the specifications contain 0.002 ppm of the data (0.001 on each side). Practice has shown that most manufacturing processes experience a shift (due to drift over time) of 1.5 standard deviations so that the mean no longer equals target. When this happens in a six-sigma process, a larger portion of the distribution now extends beyond the specification limits: 3.4 ppm.

Figure 2 depicts a 1.5-shifted distribution with "6" annotations. In manufacturing, this shift results from things such as mechanical wear over time and causes the six-sigma defect rate to become 3.4 ppm. The magnitude of the shift may vary, but empirical evidence indicates that 1.5 is about average. Does this shift exist in the software process? While it will take time to build sufficient data repositories to verify this assumption within the software and systems sector, it is reasonable to presume that there are factors that would contribute to such a shift. Possible examples are declining procedural adherence over time, learning curve, and constantly changing tools and technologies (hardware and software).

Assumptions:

Normal Distribution

Process Mean Shift of 1.5 from Nominal is Likely

Process Mean and Standard Deviation are known

Defects are randomly distributed throughout units

Parts and Process Steps are Independent

For this discussion, original nominal value = target

Key

= standard deviation = center of the distribution(shifted 1.5from its original , on-target location)+/-3 & +/-6 show the specifications relative to the original target

Figure 2: Six Sigma Process with Mean Shifted from Nominal by 1. 5

Usage Considerations

In the software and systems field, Six Sigma may be leveraged differently based on the state of the business. In an organization needing process consistency, Six Sigma can help promote the establishment of a process. For an organization striving to streamline their existing processes, Six Sigma can be used as a refinement mechanism.

In organizations at CMM level 1-3, "defect free" may seem an overwhelming stretch. Accordingly, an effective approach would be to use the improvement framework ('Define-Measure-Analyze-Improve-Control') as a roadmap toward intermediate defect reduction goals. Level 1 and 2 organizations may find that adopting the Six Sigma philosophy and framework reinforces their efforts to launch measurement practices; whereas Level 3 organizations may be able to begin immediate use of the framework. As organizations mature to Level 4 and 5, which implies an ability to leverage established measurement practices, accomplishment of true "six sigma" performance (as defined by ppm defect rates) becomes a relevant goal.

Many techniques in the Six Sigma toolkit are directly applicable to software and are already in use in the software industry. For instance, "Voice of the Client" and "Quality Function Deployment" are useful for developing customer requirements (and are relevant measures). There are numerous charting/calculation techniques that can be used to scrutinize cost, schedule, and quality (project-level and personal-level) data as a project proceeds. And, for technical development, there are quantitative methods for risk analysis and concept/design selection. The strength of "Six Sigma" comes from consciously and methodically deploying these tools in a way that achieves (directly or indirectly) customer satisfaction.

As with manufacturing, it is likely that Six Sigma applications in software will reach beyond "improvement of current processes/products" and extend to "design of new processes/products." Named "Design for Six Sigma" (DFSS), this extension heavily utilizes tools for customer requirements, risk analysis, design decision-making and inventive problem solving. In the software world, it would also heavily leverage re-use libraries that consist of robustly designed software.

Maturity

Six Sigma is rooted in fundamental statistical and business theory; consequently, the concepts and philosophy are very mature. Applications of Six Sigma methods in manufacturing, following on the heels of many quality improvement programs, are likewise mature. Applications of Six Sigma methods in software development and other 'upstream' (from manufacturing) processes are emerging.

Costs and Limitations

Institutionalizing Six Sigma into the fabric of a corporate culture can require significant investment in training and infrastructure. There are typically three different levels of expertise cited by companies: Green Belt, Black Belt Practitioner, Master Black Belt. Each level has increasingly greater mastery of the skill set. Roles and responsibilities also grow from each level to the next, with Black Belt Practitioners often in team/project leadership roles and Master Black Belts often in mentoring/teaching roles. The infrastructure needed to support the Six Sigma environment varies. Some companies organize their trained Green/Black Belts into a central support organization. Others deploy Green/Black Belts into organizations based on project needs and rely on communities of practice to maintain cohesion.

Alternatives

In past years, there have been many instances and evolutions of quality improvement programs. Scrutiny of the programs will show much similarity and also clear distinctions between such programs and Six Sigma. Similarities include common tools and methods, concepts of continuous improvement, and even analogous steps in the improvement framework. Differences have been articulated as follows:

Six Sigma speaks the language of business. It specifically addresses the concept of making the business as profitable as possible.

In Six Sigma, quality is not pursued independently from business goals. Time and resources are not spent improving something that is not a lever for improving customer satisfaction.

Six Sigma focuses on achieving tangible results.

Six Sigma does not include specific integration of ISO900 or Malcolm Baldridge National Quality Award criteria.

Six Sigma uses an infrastructure of highly trained employees from many sectors of the company (not just the Quality Department). These employees are typically viewed as internal change agents.

Six Sigma raises the expectation from 3-sigma performance to 6-sigma. Yet, it does not promote "Zero Defects" which many people dismiss as "impossible."

Sources: [Pyzdek 2-01, Marash 99, Harry 00]

Complementary Technologies

It is difficult to concisely describe the ways in which Six Sigma may be interwoven with other initiatives (or vice versa). The following paragraphs broadly capture some of the possible interrelationships between initiatives.

Six Sigma and improvement approaches such as CMM, CMMISM, PSPSM/TSPSM are complementary and mutually supportive. Depending on current organizational, project or individual circumstances, Six Sigma could be an enabler to launch CMM, CMMISM, PSPSM, or TSPSM. Or, it could be a refinement toolkit/methodology within these initiatives. For instance, it might be used to select highest priority Process Areas within CMMISM or to select highest leverage metrics within PSPSM.

Examination of the Goal-Question-Metric (GQM), Initiating-Diagnosing-Establishing-Acting-Leveraging (IDEALSM), and Practical Software Measurement (PSM) paradigms, likewise, shows compatibility and consistency with Six Sigma. GQ(I)M meshes well with the Define-Measure steps of Six Sigma. IDEAL and Six Sigma share many common features, with IDEALSM being slightly more focused on change management and organizational issues and Six Sigma being more focused on tactical, data-driven analysis and decision making. PSM provides a software-tailored approach to measurement that may well serve the Six Sigma improvement framework.

Index Categories

This technology is classified under the following categories. Select a category for a list of related topics.

Name of technology

Six Sigma

Application category

Detailed Design (AP.1.3.5)Code (AP.1.4.2)Unit Testing (AP.1.4.3.4)Component Testing (AP.1.4.3.5)

Quality measures category

Reliability (QM.2.1.2)Availability (QM.2.1.1)Maintenance Control (QM.5.1.2.3)Productivity (QM.5.2)

Computing reviews category

Management (D.2.9)

References and Information Sources

[Arnold 99]

Arnold, Paul V. Pursuing the Holy Grail [online]. Available WWW (1999).

[ASQ 00]

ASQ Statistics Division. Improving Performance Through Statistical Thinking. Milwaukee, WI: ASQ Quality Press, 2000.

[ASA 01]

American Statistical Association, Quality & Productivity Section. Enabling Broad Application of Statistical Thinking [online]. Available WWW (2001).

[Bylinsky 98]

Bylinsky, Gene. How to Bring Out Better Products Faster [online]. Available WWW (1998).

[Harrold 99]

Harrold, Dave. Designing for Six Sigma Capability [Online]. Available WWW (1999).

[Harry 00]

Harry, Mikel. "Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations." New York, N.Y. Random House Publishers, 2000.

[Lahiri 99]

Lahiri, Jaideep. The Enigma of Six Sigma [online]. Available WWW (1999).

[Marash 99]

Marash, Stanley A. Six Sigma: Passing Fad or a Sign of Things to Come? [online]. Available WWW (1999).

[Pyzdek 01]

Pyzdek, Thomas. The Six Sigma Handbook. New York, N.Y.: McGraw-Hill Professional Publishing, 2001.

[Pyzdek 2-01]

Pyzdek, Thomas. Six Sigma and Beyond: Why Six Sigma Is Not TQM [online]. Available WWW (2001).

Current Author/Maintainer

Jeannine Siviy, SEI

External Reviewers

Anita Carleton, SEIWolfhart Goethert, SEIDavid Zubrow, SEI

Modifications

1 May 2001 (original)