Six Sigma is an approach to prod-

uct and process improvement that

has gained wide acceptance and

has delivered large business bene-

fits across many industries. As

application of this framework

spreads to software development

one must consider how Six Sigma

relates to, and can be integrated

with, other improvement initia-

tives and models already in use or

under consideration.

This article describes Six Sigma and

several widely used software

improvement initiatives in terms of

their relationships to one another –

how they are similar, and how they

are different. This foundation pro-

vides a backdrop for an illustration

of how one organization, LSI Logic

Storage Systems, has defined the

connections between several initia-

tives currently under way or under

consideration.

Developing and communicating a

clear statement of the connections

between various initiatives has

been found to be a critical factor

for successful deployment of any

set of improvements. Articulating

the connections and distinctions

between initiatives prevents con-

fusion and helps to avoid conflict-

ing priorities and expectations

among those involved.

Key words: goal setting and

deployment; organizational lead-

ership; Personal Software Process

(PSP)SM; program performance and

process effectiveness; risk man-

agement; SEI Capability Maturity

Model Integrated (CMMI)®; Six

Sigma; standards, specifications,

and models; Team Software

Process (TSP) SM.

INTRODUCTIONSoftware has long been one of the most difficult challengesfaced by many businesses. The rate of failure has been high,rework and “cost of poor quality” (CoPQ) consume a largeshare of software resources, and yet software is critical to suc-cess in every segment of our economy. The cost of hardwaretechnology has decreased sharply, and quality has increased byorders of magnitude. The cost and quality of software technol-ogy, however, has not seen comparable improvements.

Many different responses to these problems have evolved inrecent years, including those discussed here and many others,such as ISO 9001 and ISO 12204, which will not be examinedhere. In response to these diverse approaches, many organiza-tions find themselves somewhat conflicted and confused as towhat is best and what should come first. The authors’ goal is tooffer some clarity as to how these different approaches relate toone another, and to provide an example of how a set of poten-tially overlapping initiatives were rationalized and connected.

P R O C E S S I M P R O V E M E N T

IntegratingImprovementInitiatives:

Connecting SixSigma for Software,

CMMI®, PersonalSoftware Process(PSP)SM, and TeamSoftware Process

(TSP)SM

GARY A. GACKSix Sigma Advantage, Inc.

KYLE ROBISONLSI Logic Storage Systems

www.asq.org 5

Integrating Improvement Initiatives

THE SIX SIGMA “BREAK-THROUGH MANAGEMENTSTRATEGY” Six Sigma originated at Motorola in the mid-1980s, andwas originally targeted at manufacturing operations. Thebasic methodology was known as DMAIC (define, meas-ure, analyze, improve, and control) and its intended usewas improvement of existing products and processes.

At first glance, it sounds much like the plan-do-check-act cycle that originated with Walter A. Shewhart in the1930s (Shewhart 1931). So what was new and different?Six Sigma did not really introduce new tools, but a differ-ent focus—not just manufacturing, not just quality, butalso a support infrastructure and an emphasis on resultsmeasurement and an explicit financial tie to bottom-lineresults. Six Sigma also introduced an increased emphasison control (sustaining the gains), and an extensive use ofdata, statistics, and metrics. In addition, Six Sigma intro-duced the term “Black Belt” to refer to dedicated full-timeprocess improvement specialists who drive projects.

As Six Sigma evolved through the 1990s it wasincreasingly recognized that in many instances qualityand cost problems were rooted in the design of prod-ucts and processes, and sometimes could not be“improved out.” This realization led to the definitionof a new branch of the Six Sigma methodology thatcame to be known as “Design for Six Sigma” (DFSS).

The DFSS approach, often referred to as “DMADV”(define, measure, analyze, design, and verify), has

come to be used when one is designing new productsand or processes.

SIX SIGMA FOR SOFTWAREThe phenomenal success of Six Sigma in manufactur-ing and transactional environments, as demonstratedby General Electric, Motorola, American Express, andmany others (Harry and Schroeder 2000), has led to adramatic increase in the number of organizations con-sidering application of Six Sigma to the elusive andintangible world of software.

Six Sigma projects begin and end with businessconsiderations. Project selection and tracking focuson maximizing the benefit delivered to the businessbottom line. While there may be plenty of fundamen-tal metrics and statistics en route, Six Sigma projectsuccess is measured in financial terms. “Processmaturity” is not of interest in itself—the focus is onquantitatively measured business benefits.

Success of Six Sigma in software requires morethan just an understanding of the Six Sigma philoso-phy and tools (which can be gained from traditionalSix Sigma training); it also requires learning how thetools and philosophy apply to the specific businessarea being addressed. This fact is behind the emer-gence of Six Sigma training tailored totransactional/service environments vs. traditionaltraining rooted in manufacturing. To maximize theapplication and benefit of Six Sigma concepts, casestudies, tools, practice problems, and assignmentsused in the training need to be appropriate to thedomain in which Six Sigma is to be applied.

This need for training tailored to the intended envi-ronment of use is even more critical in software, becauselearning is maximized when the problems and examplesare directly relevant to the student’s immediate needsand because software is “different.” But first, considerthe business justification, since without that, one nevergets the critical management support one needs.

The Six Sigma Value PropositionPerhaps the most important distinction between SixSigma and other approaches to process improvement insoftware lies in its almost obsessive preoccupation withfinancially measured business results. Six Sigma catersprimarily to the concerns of the CEO and CFO—processmaturity is not viewed as a business benefit in and ofitself. Six Sigma is a “show me the money” proposition.

6 SQP VOL. 5, NO. 4/© 2003, ASQ

Six Sigma OverviewSix Sigma (6s) is a multifaceted approach to business

improvement. It includes a philosophy, set of metrics,

set of improvement frameworks, and a toolkit.

PhilosophyThe Six Sigma philosophy is to improve customer satis-faction through defect elimination and prevention and,as a result, to increase business profitability. “Defects ”are defined in terms of the customer’s (not engineer’s)viewpoint. The business profitability motive is crucial;improvement for improvement’s sake, without positiveimpact on the bottom line, does not align with the SixSigma philosophy.

Integrating Improvement Initiatives

At first glance, those in the technical community mightlook slightly askance as this blatantly commercial per-spective—but give it the benefit of the doubt for amoment. Perhaps there is something here that caters tothe needs and desires of software practitioners as well.

Experience with Six Sigma has demonstrated, inmany business and industry segments, that the payoffcan be quite substantial, but that it is also criticallydependent on how it is deployed (see, for example,Eckes 2001). The importance of an effective deploy-ment strategy is no less in software than in manufactur-ing or transactional environments. While a discussionof culture change implications is beyond the scope ofthis article, it is clearly a very important issue, espe-cially as resistance to change is often high in softwareorganizations, as many practitioners have seen a longseries of “silver bullets” but few dead wolves.

An effective Six Sigma deployment begins at thetop with executive training that is designed to ensurea clear linkage between corporate strategic impera-tives and the Six Sigma program. Assuming for amoment that one can establish clear linkages betweenSix Sigma and software process improvements—imag-ine what a refreshing circumstance this could create!Software practitioners understood and supported byexecutive management! Costs and schedule improve-ments evaluated based on economic payback!Initiatives sustained after the latest reorganization!

Executive juices flow at the prospect of improvedfinancial results, and Six Sigma can deliver. Experiencedemonstrates that, on average, each Six Sigma BlackBelt can complete four to six projects per year at anaverage financial benefit of $150,000 per project, andGreen Belts can complete two to three projects peryear at an average financial benefit of perhaps $75,000each—a small deployment (15 Green Belts, 15 BlackBelts) produces a total benefit of around $8,000,000 inthe first year, at a typical cost of less than $2,000,000—a four-to-one return in the first year and greater there-after. (Results will vary significantly from project toproject, but the results indicated here are well withinthe typical range.) How many software processimprovement efforts produce comparable results?

What’s Different AboutSoftware?Although there are many ways in which softwaredevelopment differs from manufacturing or transac-

tional/service applications of Six Sigma, the authorsbelieve the following are the most significant in thecontext of this article:

• Software projects are very risky. A survey of8000 large U.S. software projects (StandishGroup Chaos Report 2001) indicates an aver-age cost overrun of 90 percent, schedule over-run of 120 percent, and large-projectcancellation of 25 percent due to some combi-nation of delays, budget overruns, or poorquality. Six Sigma tools and methods canreduce these risks dramatically.

• Requirements failures (reflecting needs notoriginally recognized or correctly understood,leading to substantial and costly rework late inthe software development cycle) are associ-ated with 80 percent of failed (late or can-celled) software projects (Jones 1994). TheDFSS methodology, with its associated toolset,can greatly improve timely discovery of latentor “hidden” requirements, clarify the cus-tomer importance associated with eachrequirement, determine measures of function-ality and associated cost/benefit trade-offs,and balance identified alternatives with the“voice of the business.”

• “Expectations” failures (incorrect and overlyoptimistic estimates, leading to long delaysand large cost overruns) are a factor in 65 per-cent of failed software projects (Jones 1994).Six Sigma statistical tools, such as regressionanalysis, can be applied to the developmentand refinement of software cost, schedule, anddelivered quality forecasting.

• “Execution” failures (leading to poor softwarequality, heavily back-loaded costs, and veryhigh levels of rework—commonly 40 percentof total cost) are a factor in 60 percent offailed software projects (Jones 1994). Defectcost analysis scorecards and Rayleigh effortand defect modeling tools provide mecha-nisms to analyze the cost and quality dynam-ics of software projects that enable accurateforecasting of the cost benefit of proposedprocess improvements.

• Software is mysterious. Improvements arenot evident unless good intermediate metricsare in place. It’s not like manufacturing where

www.asq.org 7

Integrating Improvement Initiatives

measurements and processes are well under-stood and changes are quick to evaluate.Cycle times for software development are typ-ically several months or even years long, andrepeatability is not a common concept as it isin manufacturing and transactional areas.

CMMIThe Capability Maturity Model Integrated (CMMI), aproduct of the Carnegie-Mellon Software EngineeringInstitute, is an evolution and combination of the origi-nal Software Capability Maturity Model and theSystems Engineering Maturity Model. This modeldescribes a series of maturity levels (originally derivedfrom and analogous to Crosby’s “Quality MaturityGrid” [Crosby 1979]) related to key process areas(KPAs) defined by the model.

The principal changes introduced by the CMMIrelative to its predecessors (Software and SystemsEngineering CMM) are: 1) certain aspects of the sys-tems engineering and software models are integratedinto a single model; 2) both a continuous view (inwhich maturity of specific KPAs is rated individu-ally, as in the original system engineering model andin the ISO 15504 [SPICE] model) and a step view(as in the original Software CMM) are accommo-dated; and 3) measurement is introduced at level 2rather than at level 4 as in the original SoftwareCMM. From the perspective of Six Sigma, this earlyintroduction of measurement is by far the mostimportant refinement.

When considered from a Six Sigma perspective,CMMI can be viewed as a definition of industry bestpractices—a set of candidate improvements. In thisview, Six Sigma provides the “why” (the businesscase that leads to selection of specific improvementsto be implemented in the context of a Six Sigmaproject), and also the “how” in the sense that the SixSigma “measure” and “analyze” activities providethe framework and tools needed to develop the busi-ness case that will be acceptable to and supported bythe CFO. In the authors’ view, the “why” and the“how” are not within the scope of the CMMI. Hence,Six Sigma overarches and draws upon the CMMI.

The DFSS aspect of Six Sigma can be understood as afront-end extension to the best practices defined by theCMMI—it deals with finding and articulating latent orhidden requirements that might otherwise be missed

through the application of tools such as needs/contextanalysis, KJ analysis, Kano analysis, Conjoint analysis,and other Six Sigma tools not within the scope of theCMMI. DFSS activities typically begin before and overlaprequirements management and other KPAs.

THE PERSONAL SOFTWAREPROCESS“Developing software products involves more than juststringing programming instructions together and get-ting them to run on a computer. It requires meetingcustomer requirements at an agreed upon cost andschedule. To be successful, software engineers need toconsistently produce high-quality programs on sched-ule and at their planned cost. This book shows youhow to do this. It introduces the Personal SoftwareProcess (PSP), which is a guide to using disciplinedpersonal practices to do superior software engineering”(Humphrey 1997).

While space does not permit a complete descrip-tion of every aspect of the PSP, the authors thinkthere are several key features that are particularlypertinent to the focus of this article.

• Using the PSP requires software engineers totrack their time according to a standard. Timetracking is fundamental to any realisticapproach to improvement in software develop-ment, as personnel time is by far the largestelement of cost. If one does not know howlong things took before and after processchanges, he or she clearly cannot know if costimprovement has really occurred.

• PSP also requires that software engineers esti-mate the size of software products to be pro-duced, and record actual size uponcompletion of the work products. Size is also afundamental metric that is essential to anyimprovement process.

• In addition, PSP requires that the softwareengineer record calendar time for each devel-opment process activity. This metric is essen-tial to understanding the cycle time impact ofprocess changes.

• PSP emphasizes the importance of planning, anduses actual vs. estimated outcomes to engendera learning cycle based on feedback. This learningcycle leads to improved ability to estimate, andhence to reduction of “expectations” failures.

8 SQP VOL. 5, NO. 4/© 2003, ASQ

Integrating Improvement Initiatives

• PSP is a defined process that specifies thedeliverables to be produced, quality assuranceactivities to be performed, and other aspectsof the software development process—hence,a repeatable process. This foundation is adesirable prerequisite to application of SixSigma for Software—a consistent process isnecessary for learning and improvement. PSPis one way to create this foundation.

• PSP requires the recording and tracking ofdefects, and hence enables prediction and eval-uation of yield at each step in the process(often called “phase containment effectiveness”in software)—not just final yield (often called“total containment effectiveness” in software).

• The PSP emphasizes use of formal work productreviews using checklists (sometimes referred toas peer reviews or Fagan style inspections). Thisprocess enables the recording of defects at eachphase, and makes it possible to understand andmanage subprocess yields.

While there are many other specifics of the PSP, theabove gives an overview of the main features. Takentogether, all of these attributes of the PSP may beunderstood as Six Sigma for Software enablers.Followed as prescribed, the PSP will provide some ofthe data that can be analyzed using the Six Sigma toolset, and will lead directly to improved performance.There are, however, many Six Sigma for Software toolsand techniques that are not within the scope of the PSP.

THE TEAM SOFTWAREPROCESS“The TSP is a fully defined and measured process thatteams can use to plan their work, execute their plans,and continuously improve their software developmentprocess. The Team Software Process (TSP) is definedin a series of process scripts that describe all aspectsof project planning and product development. Theprocess includes team role definitions, defined meas-ures, and the postmortem process.” (Humphrey 2002)

The TSP is an extension of, and incorporates,the PSP—essentially, PSP scaled up for teams. Thecurrent version is intended for relatively smallteams (3-15 members), and a version for teams ofup to about 150 members is being used on a limitedbasis. All of the metrics and quality assuranceactivities associated with PSP are also incorporated

into the TSP. The TSP addresses the intent of mostof the SEI/CMMI KPAs, although it does not fullyachieve all key practices of each KPA.

Like the PSP, the TSP establishes a defined processfoundation and produces useful data that can be ana-lyzed and leveraged with the Six Sigma for Softwaretoolkit. Limited results available suggest that use ofthe TSP improves software development effectiveness.

Key features of the TSP that are pertinent to SixSigma include:

• An explicit process improvement activitycalled the process improvement proposal, orPIP. The PIP process shows engineers how torecord improvement ideas while doing devel-opment work. These proposals can be used asa starting point for Six Sigma DMAIC proj-ects—potential benefit of alternate proposalsmay be evaluated using Six Sigma methodsand thereby prioritized for action.

• TSP teams make quantitative quality plans fordefects injected and removed by process step.They also determine quality goals for a familyof quality measures that are used in trackingquality performance. During the work, theengineers gather quality data and track theirperformance against the quality plan. Thisapproach is consistent with and supportive ofthe control plans that result from the “C”phase of a DMAIC project.

• The TSP has been designed to be independentof the languages, tools, or methods used. As aconsequence, Six Sigma tools are not specifi-cally called for by the TSP. Where organiza-tions use Six Sigma tools and methods, thesewould be explicitly called for when the teamdeveloped its customized TSP project process.This process would then provide the explicitcoupling needed between the development andquality processes to ensure that the developersused the quality methods when required.Similarly, the DMAIC improve and controlphase outcomes of a Six Sigma project wouldexplicitly define the links to TSP processes andmetrics, thereby ensuring effective integrationand avoidance of duplication of effort.

• Six Sigma implementation implies organiza-tions must have a defined and measured oper-ational process and that engineers must followthat process and routinely gather the requireddata as they work. PSP and TSP methods pro-

www.asq.org 9

Integrating Improvement Initiatives

vide explicit guidance on how to build adefined and measured process that fits theproject and that the developers will use.

It is worth noting that the SEI has taken 13 yearsto develop these processes and organizations thatintroduce Six Sigma for Software without capitalizingon this work may have to reinvent much of what theSEI has done. At a minimum, the PSP and TSP pro-vide an excellent starting place with respect to defini-tion of a mature software process that can effectivelyleverage the potential of Six Sigma.

Similarly, Six Sigma can provide the linkage to thebusiness and facilitate the sustained executive manage-ment support essential to success. Many organizationstoday have within the executive ranks persons whohave experienced the tremendous leverage that SixSigma can bring. These individuals speak the Six Sigmalanguage, understand and respect its potential, and aremuch more likely to support improvement initiativesthat are framed and justified as Six Sigma projects.

On the other hand, few general management exec-utives outside the software function are familiar withCMMI, PSP, or TSP, which are designed to “speak” tosoftware engineers and managers. When seeking sup-port of those who control the funding it is very helpfulto speak a language they understand.

CONNECTIONS AND DISTINCTIONS: COMBININGCMMI, PSP, TSP, AND SIXSIGMA FOR SOFTWAREPSP and TSP are software development process defini-tions (some might call them methodologies) that arecompatible with a wide range of software developmentconcepts such as spiral development, object-orienteddevelopment, and various other sets of techniques, eachwith certain advantag0pes in modeling and describingrequirements and designs for software systems. One wayof viewing this relationship is to consider PSP/TSP as theprocess framework within which specific techniquesmay be invoked to describe or model the work productsbeing produced.

Six Sigma for Software, on the other hand, is not asoftware development process definition—rather it isa far more generalized process for improvingprocesses and products. Although a few elements ofthe Six Sigma for Software toolkit are invoked withinthe PSP/TSP framework (for example, regression

analysis for development of estimating models), thereare many other tools available in the Six Sigma forSoftware toolkit that are not suggested or incorpo-rated in PSP/TSP. While PSP/TSP refers to and mayemploy some statistical techniques, specific trainingin statistical thinking and methods generally is not apart of PSP/TSP, whereas that is a central feature ofSix Sigma for Software.

Whereas Six Sigma for Software incorporates theDFSS approach to improving the feature/function/costtrade-off in definition and design of the software product,this aspect is not addressed by CMMI/PSP/TSP. Toolssuch as KJ analysis, quality function deployment, con-joint analysis, design of experiments, and many othershave high-leverage applications in the software world,but are not specifically addressed by CMMI/PSP/TSP.

In summary, the authors believe that CMMI/PSP/TSPare among the potential choices of software develop-ment process definition that can lead to improved soft-ware project performance. They also believe that the fullpotential of the data produced by these processes can-not be fully leveraged without applying the more com-prehensive Six Sigma for Software toolkit.

The relation of Six Sigma for Software toCMMI/PSP/TSP can be best understood as a differencein level of abstraction.

• Six Sigma for Software might be used to objec-tively evaluate the overall effect ofCMMI/PSP/TSP on software product quality,cost, and cycle time as compared to an alter-native approach, perhaps one of the “agile”process definitions such as extreme program-ming or Ken Schwaber’s “Scrum” (Schwaberand Beddle 2002).

The relation of Six Sigma for Software toCMMI/PSP/TSP might also be characterized as a dif-ference in goals, in which the goals of CMMI/PSP/TSPmay be a subset of those associated with Six Sigmafor Software.

• The primary goals of CMMI/PSP/TSP are contin-uous improvement in the performance of soft-ware development teams in terms of softwareproduct cost, cycle time, and delivered quality.

• The goals of Six Sigma for Software mayinclude the goals of CMMI/PSP/TSP, but do notspecify any particular process definition toachieve those goals. In addition, Six Sigma forSoftware may be applied to achieve manyother business objectives, such as improved

10 SQP VOL. 5, NO. 4/© 2003, ASQ

Integrating Improvement Initiatives

customer service after delivery of the soft-ware, or improved customer satisfaction andvalue realization from the software productfeature set delivered. Six Sigma for Softwareapplies to the software process, the softwareproduct, and to balancing the voice of the cus-tomer and the voice of the business to maxi-mize overall business value resulting fromprocesses and products.

• An additional distinction is that Six Sigma istypically applied to selected projects, whileCMMI/PSP/TSP are intended for all projects.Six Sigma may, for example, be used to planand evaluate pilot implementation ofCMMI/PSP/TSP, or alternatives thereto, whileCMMI/PSP/TSP can provide an orderly anddefined vehicle to institutionalize the lessonslearned from Six Sigma projects.

The most fundamental tenet of Six Sigma is that onemust “manage by fact.” This view is consistent withthat of TSP/PSP, but it has not yet been established thatPSP/TSP is the best alternative in every context, onlythat it is better than some alternatives. Six Sigma forSoftware can help organizations find the solution(s)that are truly optimal for each unique circumstance.

INITIATIVE INTEGRATION ATLSI LOGIC STORAGE SYSTEMSLSI Logic Storage Systems, Inc. (LSI-SSI) designs andmanufactures high reliability, large capacity RAIDcontrollers. These products are embedded softwareintensive, and much of the value-add and product dif-ferentiation is produced by the software element ofthe product. Typically, software determines time tomarket, which is a very important competitive consid-eration, as is product reliability.

As a technology leader, LSI-SSI has long placed greatimportance on quality and continuous improvement.They are ISO certified, have extensive experience withthe application of total quality management (TQM), andbegan to apply Six Sigma to manufacturing and logisticsaspects of the business about two years ago. Morerecently, as a consequence of significant successes in theinitial deployment of Six Sigma, LSI decided to deploySix Sigma to software engineering activities as well.

Early in the process of planning the deploymentof Six Sigma to software engineering, the LSI teamrecognized that they faced two important challenges:

1) how to adapt Six Sigma training that was designedfor manufacturing environments to suit softwareengineering, and 2) how to explain to everyoneinvolved how Six Sigma would relate to and coexistwith other improvement initiatives already started orbeing considered. The authors’ focus here is on thesecond issue, but they think it important to empha-size that the first issue is also critical — most SixSigma software deployments fail when that issue isnot effectively addressed.

Six different, but related, initiatives needed to beconsidered and integrated: 1) a strategic marketinginitiative known as “market leadership” (Ryans et al.2000); 2) a project/program management processknown as “critical chain” (Goldratt 1999); 3) SixSigma product/process improvement (DMAIC); 4)DFSS; 5) CMMI; and 6) PSP/TSP.

Market leadership, to simplify a bit, is an approachto strategic marketing planning that begins at the high-est level. This initiative focuses on identifying targetmarkets and segments, understanding the requirementsof those markets and segments at a high level, assessingthe competitive landscape in terms of threats andopportunities, and evaluating the company’s capabili-ties and channels with respect to capability to serviceidentified markets and segments. This initiative furtherconsiders potential differentiation, and attempts tounderstand and quantify risks in each segment.

Critical chain is much more than can be ade-quately explained in the space here, so perhaps wecan simply say that it is a new and potentially verypowerful way to think about project and programmanagement. It brings some new and importantthinking about how to balance risk against the needfor the shortest possible cycle times. It is one way toactualize the intent of the project planning and proj-ect tracking CMMI KPAs.

DFSS is that aspect of Six Sigma concerned withdesigning new products and processes, as opposed toimproving something that already exists.

DFSS employs voice of the customer tools such asneeds and context analysis, use cases and measures, KJanalysis, Kano analysis, and various tools for featureimportance ranking and prioritization. Further, DFSSattempts to balance the voice of the customer with voiceof the business considerations such as time to market,delivered quality, risk, warranty cost, and so forth.

DFSS emphasizes forecasting product and processcapability before product detailed design and con-struction in order to be proactive rather than reactive.

www.asq.org 11

Properly executed, DFSS leads to many fewer require-ments changes during development, higher customersatisfaction, improved competitiveness, and, conse-quently, higher market share and profitability.

Six Sigma DMAIC is that aspect of Six Sigma con-cerned with improving existing processes or prod-ucts — for example, the software developmentprocess itself or a particular legacy system. This viewof Six Sigma will often leverage the recommenda-tions and metrics of specific CMM KPAs in the meas-ure-analyze-improve phases of a Six Sigma project.For example, a Six Sigma DMAIC project mightdefine as its primary objective (success metric) areduction in software development cost, and as asecondary metric improvement in delivered qualityas measured by post-release defects. To accomplishthose objectives the project might introduce animprovement consistent with the Peer Reviews KPA.This improvement as a Six Sigma project will differfrom a CMM initiative in that it will place greateremphasis on the business case and on controllingand sustaining the change after it is introduced.

The authors have previously discussed PSP/TSP, sothis article now turns to explaining how these severalinitiatives connect and support one another in thisparticular situation, recognizing that other ways oflooking at this might make sense in a different context.

MAKING THE CONNECTIONSFirst consider how PSP/TSP relates to CMMI. Theauthors’ view is that PSP/TSP is simply one way tosubstantially satisfy the attributes of all or most of theCMMI KPAs—not the only way, but certainly a veryviable “how to do it” option.

Similarly, as mentioned earlier, critical chain canbe understood as one way to substantially satisfy theattributes of the project planning and project trackingKPAs—again, not the only way, but a good way. So farone can see connections that relate to different levelsof abstraction—CMMI “contains” PSP/TSP, certainKPAs “contain” critical chain.

When thinking about the connection between SixSigma DFSS and DMAIC one can visualize a temporalrelationship and a tendency for these views to live in dif-ferent quadrants of the Six Sigma space as illustrated byFigure 1. The relationship is temporal in the sense thatone clearly cannot apply DMAIC to a product or processthat does not exist, so in that sense DFSS comes first—although clearly many products and processes exist thatwere not created using the DFSS approach.

Hence, the boundary between DFSS and DMAIC is“fuzzy” in practice. When products or processes werecreated using DFSS we will have created a lot of valu-able information and context that can be revisited toadvantage when we later start a DMAIC project. Whenthat is not the case we may need to reach back into theDFSS space from within a DMAIC project to createwhat is missing.

The boundary is also fuzzy in the sense that DFSStends to focus externally and strategically, whileDMAIC has a tendency to focus internally and tacti-cally. Broadly speaking, DFSS projects are oftenmore closely connected to the voice of the customer,while DMAIC projects are often more closely tied tothe voice of the business—as with every generaliza-tion, there are exceptions and border conditions.

As illustrated in Figure 2, one can consider marketleadership as a “front end” to DFSS—with market lead-ership we select the universe we will live in, with DFSSwe design the space ship we will use to explore our uni-verse. With DMAIC we might improve the fuel con-sumption of our rocket. PSP/TSP might be viewed asanalogous to our choice of engine technology, whilecritical chain might be comparable to the thrust controlsystem that governs our engine.

Integrating Improvement Initiatives

12 SQP VOL. 5, NO. 4/© 2003, ASQ

Six Sigma FrameworksThere are currently two main Six Sigma frameworks:

DMAIC (define-measure-analyze-improve-control), isused to improve and optimize existing processes andproducts.

DFSS (Design for Six Sigma) is used to design new prod-ucts and processes. It is also used to redesign existingprocesses and products that have been optimized butstill do not meet performance goals (that is, the desiredsigma level). The latter case is believed to frequentlyoccur when moving from a 5-sigma level of performanceto a 6-sigma level. While DMAIC enjoys a relatively highdegree of consistency across industry, DFSS is much morevaried in its implementation. An example of the keyDFSS steps is define-measure-analyze-design-verify.

LeanSigma, another approach to Six Sigma, may emergeas a third framework. However, lean techniques vary sig-nificantly across industry, and many organizations areimplementing them within their existing DMAIC or DFSSframeworks.

CONCLUSIONWhile every situation is different, the authors havefound that it is always helpful to recognize that onecannot simply pile one thing on top of another andexpect to get results. It is always important to realisti-cally survey all of the things that impact the attentionspan of the people involved and to provide a clearexplanation to avoid the “oh no not another initiative”syndrome we have all experienced.

Thinking through how things connect, who willwork on what, and realistic appraisal of the effort andexpected returns will reduce resistance, clarifyresponsibilities, and improve outcomes.

The ultimate goal of all process and product improve-ment approaches is to help people be more effective andefficient in whatever they do. Six Sigma, CMMI, PSP, TSP,and any other methodologies people may incorporate intheir work are not ends in themselves but means.Progressive organizations, such as Raytheon, think of“Six Sigma” (although it may go by another name) as anover-arching “umbrella” under which are found a largeset of tools and ideas that professionals can draw upon todo their work. It can be helpful to early understanding toclarify relationships and connections among differentmethods and tools, but in the end all are most effectivewhen blended into “how we do our jobs.”

CMMI®, Personal Software ProcessSM, and Team Software ProcessSM are servicemarks of the Carnegie Mellon University, Software Engineering Institute.

REFERENCES

Crosby, Philip. 1979. Quality Is Free: The art of making quality certain. New York:New American Library.

Eckes, George. 2001. Making Six Sigma last: Managing the balance between cul-tural and technical changes. New York: John Wiley and Sons.

Goldratt, Eliyahu. 1999. Critical chain. Great Barrington, Mass.: North River Press.

Harry, Mikel, and Richard Schroeder. 2000. Six Sigma: The breakthrough manage-ment strategy revolutionizing the world’s top corporations. New York: Doubleday.

Humphrey, Watts. 1997. Introduction to the Personal Software Process. Reading,

Mass.: Addison-Wesley.

Humphrey, Watts. 2002. Winning with software. Reading, Mass.: Addison-Wesley.

Jones, Capers. 1994. Assessment and control of software risks. Englewood Cliffs,

N.J.: Prentice Hall.

Ryans, Adrian, Roger More, Donald Barclay, and Terry Deutscher. 2000. Winningmarket leadership: Strategic market planning for technology-driven businesses.Toronto: John Wiley and Sons Canada.

Schwaber, Ken, and Mike Beddle. 2002. Agile software development with scrum.Englewood Cliffs, N.J.: Prentice Hall.

Shewhart, Walter. A. 1931. Economic control of quality of manufactured product.New York: Van Nostrand.

Standish Group Chaos Report. 2001. See URL www.standishgroup.com/ chaos/toc.php .

Integrating Improvement Initiatives

BIOGRAPHIES

Gary Gack is a cofounder of Six Sigma Advantage, a firm dedicated to trainingand coaching in the application of Six Sigma to software development and infor-mation technology (IT). He is coauthor of Six Sigma Foundation, Green Belt, andBlack Belt training programs tailored to software and IT audiences.

Gack has more than 40 years of experience in the software and IT industrywith extensive large-scale project and program management, including teamswith more than 200 developers. He has owned and managed several soft-ware/consulting businesses, and has extensive experience with softwareprocess assessments using the SEI/CMM, ISO 15504, and various proprietarymethods. Gack is the author of numerous articles dealing with IT project man-agement, IT process improvement, cost accounting and metrics, and softwarequality assurance. He has consulted with leading companies in the UnitedStates, Canada, and Europe. He can be reached by e-mail at ggack@6siga.comor on the Web at www.6siga.com .

Kyle Robison is currently a Six Sigma Black Belt for LSI Logic StorageSystems, Inc. in Wichita, Kansas. He has been involved in Six Sigma for thepast three years in various roles in Six Sigma deployment in manufacturing,software engineering, and marketing. Robison graduated with a bachelor ofscience degree in electrical engineering from Oklahoma State University and iscurrently pursuing a master’s degree in business administration from FriendsUniversity. He has held many positions within LSI over the last 20 years,including firmware development engineer, program manager, product market-ing engineer, and operations program manager before his involvement in SixSigma. He can be reached by e-mail at kyle.robison@lsil.com .

www.asq.org 13

Improve/maintain

Dramatically improving

an existing product or

process

DesignCreating

something new

Component

System

DMAICDefine, measure,

analyze, improve, control

DFSSDesign for Six Sigma

Objective

Scop

e

External focus

Internal focus

Critical chain (how)

PSP/TSP (how)

CMM (what)Voice of the business(capability)

Voice of the customer(requirements, CTQs)

Tactics

StrategyFocus

Scop

e

{{Market

leadership

DFSS

6σ6σ for software(why, how much,

business case)

FIGURE 1 The connection between SixSigma DFSS and DMAIC

FIGURE 2 Initiative Integration Map forLSI-SSI

© 20

03, A

SQ©

2003

, ASQ