Six Sigma is an approach to prod-
uct and process improvement that
has gained wide acceptance and
has delivered large busi...
Integrating Improvement Initiatives
THE SIX SIGMA “BREAK-
THROUGH MANAGEMENT
STRATEGY”
Six Sigma originated at Motorola in...
Integrating Improvement Initiatives
At first glance, those in the technical community might
look slightly askance as this ...
Integrating Improvement Initiatives
measurements and processes are well under-
stood and changes are quick to evaluate.
Cy...
Integrating Improvement Initiatives
• PSP is a defined process that specifies the
deliverables to be produced, quality ass...
Integrating Improvement Initiatives
vide explicit guidance on how to build a
defined and measured process that fits the
pr...
Integrating Improvement Initiatives
customer service after delivery of the soft-
ware, or improved customer satisfaction a...
Properly executed, DFSS leads to many fewer require-
ments changes during development, higher customer
satisfaction, impro...
CONCLUSION
While every situation is different, the authors have
found that it is always helpful to recognize that one
cann...
Upcoming SlideShare
Loading in …5
×

Asq sp 2003 integrating improvement initiatives six s sw, cmmi, psp y tsp, and sqpv5i4gack

537 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
537
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Asq sp 2003 integrating improvement initiatives six s sw, cmmi, psp y tsp, and sqpv5i4gack

  1. 1. 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 . INTRODUCTION Software has long been one of the most difficult challenges faced by many businesses. The rate of failure has been high, rework and “cost of poor quality” (CoPQ) consume a large share of software resources, and yet software is critical to suc- cess in every segment of our economy. The cost of hardware technology has decreased sharply, and quality has increased by orders of magnitude. The cost and quality of software technol- ogy, however, has not seen comparable improvements. Many different responses to these problems have evolved in recent years, including those discussed here and many others, such as ISO 9001 and ISO 12204, which will not be examined here. In response to these diverse approaches, many organiza- tions find themselves somewhat conflicted and confused as to what is best and what should come first. The authors’ goal is to offer some clarity as to how these different approaches relate to one 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 Integrating Improvement Initiatives: Connecting Six Sigma for Software, CMMI® , Personal Software Process (PSP)SM , and Team Software Process (TSP)SM GARY A. GACK Six Sigma Advantage, Inc. KYLE ROBISON LSI Logic Storage Systems www.asq.org 5
  2. 2. Integrating Improvement Initiatives THE SIX SIGMA “BREAK- THROUGH MANAGEMENT STRATEGY” Six Sigma originated at Motorola in the mid-1980s, and was originally targeted at manufacturing operations. The basic methodology was known as DMAIC (define, meas- ure, analyze, improve, and control) and its intended use was 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 the 1930s (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, but also a support infrastructure and an emphasis on results measurement and an explicit financial tie to bottom-line results. Six Sigma also introduced an increased emphasis on control (sustaining the gains), and an extensive use of data, statistics, and metrics. In addition, Six Sigma intro- duced the term “Black Belt” to refer to dedicated full-time process improvement specialists who drive projects. As Six Sigma evolved through the 1990s it was increasingly recognized that in many instances quality and cost problems were rooted in the design of prod- ucts and processes, and sometimes could not be “improved out.” This realization led to the definition of a new branch of the Six Sigma methodology that came 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 products and or processes. SIX SIGMA FOR SOFTWARE The phenomenal success of Six Sigma in manufactur- ing and transactional environments, as demonstrated by General Electric, Motorola, American Express, and many others (Harry and Schroeder 2000), has led to a dramatic increase in the number of organizations con- sidering application of Six Sigma to the elusive and intangible world of software. Six Sigma projects begin and end with business considerations. Project selection and tracking focus on maximizing the benefit delivered to the business bottom line. While there may be plenty of fundamen- tal metrics and statistics en route, Six Sigma project success is measured in financial terms. “Process maturity” is not of interest in itself—the focus is on quantitatively measured business benefits. Success of Six Sigma in software requires more than just an understanding of the Six Sigma philoso- phy and tools (which can be gained from traditional Six Sigma training); it also requires learning how the tools and philosophy apply to the specific business area being addressed. This fact is behind the emer- gence of Six Sigma training tailored to transactional/service environments vs. traditional training rooted in manufacturing. To maximize the application and benefit of Six Sigma concepts, case studies, tools, practice problems, and assignments used in the training need to be appropriate to the domain 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, because learning is maximized when the problems and examples are directly relevant to the student’s immediate needs and because software is “different.” But first, consider the business justification, since without that, one never gets the critical management support one needs. The Six Sigma Value Proposition Perhaps the most important distinction between Six Sigma and other approaches to process improvement in software lies in its almost obsessive preoccupation with financially measured business results. Six Sigma caters primarily to the concerns of the CEO and CFO—process maturity is not viewed as a business benefit in and of itself. Six Sigma is a “show me the money” proposition. 6 SQP VOL. 5, NO. 4/© 2003, ASQ Six Sigma Overview Six Sigma (6s) is a multifaceted approach to business improvement. It includes a philosophy, set of metrics, set of improvement frameworks, and a toolkit. Philosophy The 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 positive impact on the bottom line, does not align with the Six Sigma philosophy.
  3. 3. Integrating Improvement Initiatives At first glance, those in the technical community might look slightly askance as this blatantly commercial per- spective—but give it the benefit of the doubt for a moment. Perhaps there is something here that caters to the needs and desires of software practitioners as well. Experience with Six Sigma has demonstrated, in many business and industry segments, that the payoff can be quite substantial, but that it is also critically dependent 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 discussion of culture change implications is beyond the scope of this article, it is clearly a very important issue, espe- cially as resistance to change is often high in software organizations, as many practitioners have seen a long series of “silver bullets” but few dead wolves. An effective Six Sigma deployment begins at the top with executive training that is designed to ensure a clear linkage between corporate strategic impera- tives and the Six Sigma program. Assuming for a moment that one can establish clear linkages between Six Sigma and software process improvements—imag- ine what a refreshing circumstance this could create! Software practitioners understood and supported by executive management! Costs and schedule improve- ments evaluated based on economic payback! Initiatives sustained after the latest reorganization! Executive juices flow at the prospect of improved financial results, and Six Sigma can deliver. Experience demonstrates that, on average, each Six Sigma Black Belt can complete four to six projects per year at an average financial benefit of $150,000 per project, and Green Belts can complete two to three projects per year at an average financial benefit of perhaps $75,000 each—a small deployment (15 Green Belts, 15 Black Belts) produces a total benefit of around $8,000,000 in the 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 to project, but the results indicated here are well within the typical range.) How many software process improvement efforts produce comparable results? What’s Different About Software? Although there are many ways in which software development differs from manufacturing or transac- tional/service applications of Six Sigma, the authors believe the following are the most significant in the context of this article: • Software projects are very risky. A survey of 8000 large U.S. software projects (Standish Group Chaos Report 2001) indicates an aver- age cost overrun of 90 percent, schedule over- run of 120 percent, and large-project cancellation of 25 percent due to some combi- nation of delays, budget overruns, or poor quality. Six Sigma tools and methods can reduce these risks dramatically. • Requirements failures (reflecting needs not originally recognized or correctly understood, leading to substantial and costly rework late in the software development cycle) are associ- ated with 80 percent of failed (late or can- celled) software projects (Jones 1994). The DFSS methodology, with its associated toolset, can greatly improve timely discovery of latent or “hidden” requirements, clarify the cus- tomer importance associated with each requirement, 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 overly optimistic estimates, leading to long delays and large cost overruns) are a factor in 65 per- cent of failed software projects (Jones 1994). Six Sigma statistical tools, such as regression analysis, can be applied to the development and refinement of software cost, schedule, and delivered quality forecasting. • “Execution” failures (leading to poor software quality, heavily back-loaded costs, and very high levels of rework—commonly 40 percent of total cost) are a factor in 60 percent of failed software projects (Jones 1994). Defect cost analysis scorecards and Rayleigh effort and defect modeling tools provide mecha- nisms to analyze the cost and quality dynam- ics of software projects that enable accurate forecasting of the cost benefit of proposed process improvements. • Software is mysterious. Improvements are not evident unless good intermediate metrics are in place. It’s not like manufacturing where www.asq.org 7
  4. 4. 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, and repeatability is not a common concept as it is in manufacturing and transactional areas. CMMI The Capability Maturity Model Integrated (CMMI), a product of the Carnegie-Mellon Software Engineering Institute, is an evolution and combination of the origi- nal Software Capability Maturity Model and the Systems Engineering Maturity Model. This model describes a series of maturity levels (originally derived from and analogous to Crosby’s “Quality Maturity Grid” [Crosby 1979]) related to key process areas (KPAs) defined by the model. The principal changes introduced by the CMMI relative to its predecessors (Software and Systems Engineering CMM) are: 1) certain aspects of the sys- tems engineering and software models are integrated into a single model; 2) both a continuous view (in which maturity of specific KPAs is rated individu- ally, as in the original system engineering model and in 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 2 rather than at level 4 as in the original Software CMM. From the perspective of Six Sigma, this early introduction of measurement is by far the most important refinement. When considered from a Six Sigma perspective, CMMI can be viewed as a definition of industry best practices—a set of candidate improvements. In this view, Six Sigma provides the “why” (the business case that leads to selection of specific improvements to be implemented in the context of a Six Sigma project), and also the “how” in the sense that the Six Sigma “measure” and “analyze” activities provide the framework and tools needed to develop the busi- ness case that will be acceptable to and supported by the 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 a front-end extension to the best practices defined by the CMMI—it deals with finding and articulating latent or hidden requirements that might otherwise be missed through the application of tools such as needs/context analysis, KJ analysis, Kano analysis, Conjoint analysis, and other Six Sigma tools not within the scope of the CMMI. DFSS activities typically begin before and overlap requirements management and other KPAs. THE PERSONAL SOFTWARE PROCESS “Developing software products involves more than just stringing programming instructions together and get- ting them to run on a computer. It requires meeting customer requirements at an agreed upon cost and schedule. To be successful, software engineers need to consistently produce high-quality programs on sched- ule and at their planned cost. This book shows you how to do this. It introduces the Personal Software Process (PSP), which is a guide to using disciplined personal 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 think there are several key features that are particularly pertinent to the focus of this article. • Using the PSP requires software engineers to track their time according to a standard. Time tracking is fundamental to any realistic approach to improvement in software develop- ment, as personnel time is by far the largest element of cost. If one does not know how long things took before and after process changes, he or she clearly cannot know if cost improvement has really occurred. • PSP also requires that software engineers esti- mate the size of software products to be pro- duced, and record actual size upon completion of the work products. Size is also a fundamental metric that is essential to any improvement process. • In addition, PSP requires that the software engineer record calendar time for each devel- opment process activity. This metric is essen- tial to understanding the cycle time impact of process changes. • PSP emphasizes the importance of planning, and uses actual vs. estimated outcomes to engender a learning cycle based on feedback. This learning cycle leads to improved ability to estimate, and hence to reduction of “expectations” failures. 8 SQP VOL. 5, NO. 4/© 2003, ASQ
  5. 5. Integrating Improvement Initiatives • PSP is a defined process that specifies the deliverables to be produced, quality assurance activities to be performed, and other aspects of the software development process—hence, a repeatable process. This foundation is a desirable prerequisite to application of Six Sigma for Software—a consistent process is necessary for learning and improvement. PSP is one way to create this foundation. • PSP requires the recording and tracking of defects, 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 product reviews using checklists (sometimes referred to as peer reviews or Fagan style inspections). This process enables the recording of defects at each phase, and makes it possible to understand and manage subprocess yields. While there are many other specifics of the PSP, the above gives an overview of the main features. Taken together, all of these attributes of the PSP may be understood as Six Sigma for Software enablers. Followed as prescribed, the PSP will provide some of the data that can be analyzed using the Six Sigma tool set, and will lead directly to improved performance. There are, however, many Six Sigma for Software tools and techniques that are not within the scope of the PSP. THE TEAM SOFTWARE PROCESS “The TSP is a fully defined and measured process that teams can use to plan their work, execute their plans, and continuously improve their software development process. The Team Software Process (TSP) is defined in a series of process scripts that describe all aspects of project planning and product development. The process 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. The current version is intended for relatively small teams (3-15 members), and a version for teams of up to about 150 members is being used on a limited basis. All of the metrics and quality assurance activities associated with PSP are also incorporated into the TSP. The TSP addresses the intent of most of the SEI/CMMI KPAs, although it does not fully achieve all key practices of each KPA. Like the PSP, the TSP establishes a defined process foundation and produces useful data that can be ana- lyzed and leveraged with the Six Sigma for Software toolkit. Limited results available suggest that use of the TSP improves software development effectiveness. Key features of the TSP that are pertinent to Six Sigma include: • An explicit process improvement activity called the process improvement proposal, or PIP. The PIP process shows engineers how to record improvement ideas while doing devel- opment work. These proposals can be used as a starting point for Six Sigma DMAIC proj- ects—potential benefit of alternate proposals may be evaluated using Six Sigma methods and thereby prioritized for action. • TSP teams make quantitative quality plans for defects injected and removed by process step. They also determine quality goals for a family of quality measures that are used in tracking quality performance. During the work, the engineers gather quality data and track their performance against the quality plan. This approach is consistent with and supportive of the control plans that result from the “C” phase of a DMAIC project. • The TSP has been designed to be independent of the languages, tools, or methods used. As a consequence, Six Sigma tools are not specifi- cally called for by the TSP. Where organiza- tions use Six Sigma tools and methods, these would be explicitly called for when the team developed its customized TSP project process. This process would then provide the explicit coupling needed between the development and quality processes to ensure that the developers used the quality methods when required. Similarly, the DMAIC improve and control phase outcomes of a Six Sigma project would explicitly define the links to TSP processes and metrics, thereby ensuring effective integration and avoidance of duplication of effort. • Six Sigma implementation implies organiza- tions must have a defined and measured oper- ational process and that engineers must follow that process and routinely gather the required data as they work. PSP and TSP methods pro- www.asq.org 9
  6. 6. Integrating Improvement Initiatives vide explicit guidance on how to build a defined and measured process that fits the project and that the developers will use. It is worth noting that the SEI has taken 13 years to develop these processes and organizations that introduce Six Sigma for Software without capitalizing on this work may have to reinvent much of what the SEI 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 effectively leverage the potential of Six Sigma. Similarly, Six Sigma can provide the linkage to the business and facilitate the sustained executive manage- ment support essential to success. Many organizations today have within the executive ranks persons who have experienced the tremendous leverage that Six Sigma can bring. These individuals speak the Six Sigma language, understand and respect its potential, and are much more likely to support improvement initiatives that are framed and justified as Six Sigma projects. On the other hand, few general management exec- utives outside the software function are familiar with CMMI, PSP, or TSP, which are designed to “speak” to software engineers and managers. When seeking sup- port of those who control the funding it is very helpful to speak a language they understand. CONNECTIONS AND DISTINCTIONS: COMBINING CMMI, PSP, TSP, AND SIX SIGMA FOR SOFTWARE PSP and TSP are software development process defini- tions (some might call them methodologies) that are compatible with a wide range of software development concepts such as spiral development, object-oriented development, and various other sets of techniques, each with certain advantag0pes in modeling and describing requirements and designs for software systems. One way of viewing this relationship is to consider PSP/TSP as the process framework within which specific techniques may be invoked to describe or model the work products being produced. Six Sigma for Software, on the other hand, is not a software development process definition—rather it is a far more generalized process for improving processes and products. Although a few elements of the Six Sigma for Software toolkit are invoked within the PSP/TSP framework (for example, regression analysis for development of estimating models), there are many other tools available in the Six Sigma for Software toolkit that are not suggested or incorpo- rated in PSP/TSP. While PSP/TSP refers to and may employ some statistical techniques, specific training in statistical thinking and methods generally is not a part of PSP/TSP, whereas that is a central feature of Six Sigma for Software. Whereas Six Sigma for Software incorporates the DFSS approach to improving the feature/function/cost trade-off in definition and design of the software product, this aspect is not addressed by CMMI/PSP/TSP. Tools such as KJ analysis, quality function deployment, con- joint analysis, design of experiments, and many others have high-leverage applications in the software world, but are not specifically addressed by CMMI/PSP/TSP. In summary, the authors believe that CMMI/PSP/TSP are among the potential choices of software develop- ment process definition that can lead to improved soft- ware project performance. They also believe that the full potential 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 to CMMI/PSP/TSP can be best understood as a difference in level of abstraction. • Six Sigma for Software might be used to objec- tively evaluate the overall effect of CMMI/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” (Schwaber and Beddle 2002). The relation of Six Sigma for Software to CMMI/PSP/TSP might also be characterized as a dif- ference in goals, in which the goals of CMMI/PSP/TSP may be a subset of those associated with Six Sigma for Software. • The primary goals of CMMI/PSP/TSP are contin- uous improvement in the performance of soft- ware development teams in terms of software product cost, cycle time, and delivered quality. • The goals of Six Sigma for Software may include the goals of CMMI/PSP/TSP, but do not specify any particular process definition to achieve those goals. In addition, Six Sigma for Software may be applied to achieve many other business objectives, such as improved 10 SQP VOL. 5, NO. 4/© 2003, ASQ
  7. 7. Integrating Improvement Initiatives customer service after delivery of the soft- ware, or improved customer satisfaction and value realization from the software product feature set delivered. Six Sigma for Software applies to the software process, the software product, and to balancing the voice of the cus- tomer and the voice of the business to maxi- mize overall business value resulting from processes and products. • An additional distinction is that Six Sigma is typically applied to selected projects, while CMMI/PSP/TSP are intended for all projects. Six Sigma may, for example, be used to plan and evaluate pilot implementation of CMMI/PSP/TSP, or alternatives thereto, while CMMI/PSP/TSP can provide an orderly and defined vehicle to institutionalize the lessons learned from Six Sigma projects. The most fundamental tenet of Six Sigma is that one must “manage by fact.” This view is consistent with that of TSP/PSP, but it has not yet been established that PSP/TSP is the best alternative in every context, only that it is better than some alternatives. Six Sigma for Software can help organizations find the solution(s) that are truly optimal for each unique circumstance. INITIATIVE INTEGRATION AT LSI LOGIC STORAGE SYSTEMS LSI Logic Storage Systems, Inc. (LSI-SSI) designs and manufactures high reliability, large capacity RAID controllers. These products are embedded software intensive, and much of the value-add and product dif- ferentiation is produced by the software element of the product. Typically, software determines time to market, which is a very important competitive consid- eration, as is product reliability. As a technology leader, LSI-SSI has long placed great importance on quality and continuous improvement. They are ISO certified, have extensive experience with the application of total quality management (TQM), and began to apply Six Sigma to manufacturing and logistics aspects of the business about two years ago. More recently, as a consequence of significant successes in the initial deployment of Six Sigma, LSI decided to deploy Six Sigma to software engineering activities as well. Early in the process of planning the deployment of Six Sigma to software engineering, the LSI team recognized that they faced two important challenges: 1) how to adapt Six Sigma training that was designed for manufacturing environments to suit software engineering, and 2) how to explain to everyone involved how Six Sigma would relate to and coexist with other improvement initiatives already started or being considered. The authors’ focus here is on the second issue, but they think it important to empha- size that the first issue is also critical—most Six Sigma software deployments fail when that issue is not effectively addressed. Six different, but related, initiatives needed to be considered and integrated: 1) a strategic marketing initiative known as “market leadership” (Ryans et al. 2000); 2) a project/program management process known as “critical chain” (Goldratt 1999); 3) Six Sigma product/process improvement (DMAIC); 4) DFSS; 5) CMMI; and 6) PSP/TSP. Market leadership, to simplify a bit, is an approach to strategic marketing planning that begins at the high- est level. This initiative focuses on identifying target markets and segments, understanding the requirements of those markets and segments at a high level, assessing the competitive landscape in terms of threats and opportunities, and evaluating the company’s capabili- ties and channels with respect to capability to service identified markets and segments. This initiative further considers potential differentiation, and attempts to understand and quantify risks in each segment. Critical chain is much more than can be ade- quately explained in the space here, so perhaps we can simply say that it is a new and potentially very powerful way to think about project and program management. It brings some new and important thinking about how to balance risk against the need for the shortest possible cycle times. It is one way to actualize the intent of the project planning and proj- ect tracking CMMI KPAs. DFSS is that aspect of Six Sigma concerned with designing new products and processes, as opposed to improving something that already exists. DFSS employs voice of the customer tools such as needs and context analysis, use cases and measures, KJ analysis, Kano analysis, and various tools for feature importance ranking and prioritization. Further, DFSS attempts to balance the voice of the customer with voice of the business considerations such as time to market, delivered quality, risk, warranty cost, and so forth. DFSS emphasizes forecasting product and process capability before product detailed design and con- struction in order to be proactive rather than reactive. www.asq.org 11
  8. 8. Properly executed, DFSS leads to many fewer require- ments changes during development, higher customer satisfaction, 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 development process itself or a particular legacy system. This view of 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 might define as its primary objective (success metric) a reduction in software development cost, and as a secondary metric improvement in delivered quality as measured by post-release defects. To accomplish those objectives the project might introduce an improvement consistent with the Peer Reviews KPA. This improvement as a Six Sigma project will differ from a CMM initiative in that it will place greater emphasis on the business case and on controlling and sustaining the change after it is introduced. The authors have previously discussed PSP/TSP, so this article now turns to explaining how these several initiatives connect and support one another in this particular situation, recognizing that other ways of looking at this might make sense in a different context. MAKING THE CONNECTIONS First consider how PSP/TSP relates to CMMI. The authors’ view is that PSP/TSP is simply one way to substantially satisfy the attributes of all or most of the CMMI KPAs—not the only way, but certainly a very viable “how to do it” option. Similarly, as mentioned earlier, critical chain can be understood as one way to substantially satisfy the attributes of the project planning and project tracking KPAs—again, not the only way, but a good way. So far one can see connections that relate to different levels of abstraction—CMMI “contains” PSP/TSP, certain KPAs “contain” critical chain. When thinking about the connection between Six Sigma DFSS and DMAIC one can visualize a temporal relationship and a tendency for these views to live in dif- ferent quadrants of the Six Sigma space as illustrated by Figure 1. The relationship is temporal in the sense that one clearly cannot apply DMAIC to a product or process that does not exist, so in that sense DFSS comes first— although clearly many products and processes exist that were not created using the DFSS approach. Hence, the boundary between DFSS and DMAIC is “fuzzy” in practice. When products or processes were created using DFSS we will have created a lot of valu- able information and context that can be revisited to advantage when we later start a DMAIC project. When that is not the case we may need to reach back into the DFSS space from within a DMAIC project to create what is missing. The boundary is also fuzzy in the sense that DFSS tends to focus externally and strategically, while DMAIC has a tendency to focus internally and tacti- cally. Broadly speaking, DFSS projects are often more closely connected to the voice of the customer, while DMAIC projects are often more closely tied to the voice of the business—as with every generaliza- tion, there are exceptions and border conditions. As illustrated in Figure 2, one can consider market leadership as a “front end” to DFSS—with market lead- ership we select the universe we will live in, with DFSS we 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 as analogous to our choice of engine technology, while critical chain might be comparable to the thrust control system that governs our engine. Integrating Improvement Initiatives 12 SQP VOL. 5, NO. 4/© 2003, ASQ Six Sigma Frameworks There are currently two main Six Sigma frameworks: DMAIC (define-measure-analyze-improve-control), is used to improve and optimize existing processes and products. DFSS (Design for Six Sigma) is used to design new prod- ucts and processes. It is also used to redesign existing processes and products that have been optimized but still do not meet performance goals (that is, the desired sigma level). The latter case is believed to frequently occur when moving from a 5-sigma level of performance to a 6-sigma level. While DMAIC enjoys a relatively high degree of consistency across industry, DFSS is much more varied in its implementation. An example of the key DFSS steps is define-measure-analyze-design-verify. LeanSigma, another approach to Six Sigma, may emerge as a third framework. However, lean techniques vary sig- nificantly across industry, and many organizations are implementing them within their existing DMAIC or DFSS frameworks.
  9. 9. CONCLUSION While every situation is different, the authors have found that it is always helpful to recognize that one cannot simply pile one thing on top of another and expect to get results. It is always important to realisti- cally survey all of the things that impact the attention span of the people involved and to provide a clear explanation to avoid the “oh no not another initiative” syndrome we have all experienced. Thinking through how things connect, who will work on what, and realistic appraisal of the effort and expected returns will reduce resistance, clarify responsibilities, and improve outcomes. The ultimate goal of all process and product improve- ment approaches is to help people be more effective and efficient in whatever they do. Six Sigma, CMMI, PSP, TSP, and any other methodologies people may incorporate in their 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 an over-arching “umbrella” under which are found a large set of tools and ideas that professionals can draw upon to do their work. It can be helpful to early understanding to clarify relationships and connections among different methods and tools, but in the end all are most effective when blended into “how we do our jobs.” CMMI®, Personal Software ProcessSM , and Team Software ProcessSM are service marks 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. Winning market 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 training and coaching in the application of Six Sigma to software development and infor- mation technology (IT). He is coauthor of Six Sigma Foundation, Green Belt, and Black Belt training programs tailored to software and IT audiences. Gack has more than 40 years of experience in the software and IT industry with extensive large-scale project and program management, including teams with more than 200 developers. He has owned and managed several soft- ware/consulting businesses, and has extensive experience with software process assessments using the SEI/CMM, ISO 15504, and various proprietary methods. Gack is the author of numerous articles dealing with IT project man- agement, IT process improvement, cost accounting and metrics, and software quality assurance. He has consulted with leading companies in the United States, Canada, and Europe. He can be reached by e-mail at ggack@6siga.com or on the Web at www.6siga.com . Kyle Robison is currently a Six Sigma Black Belt for LSI Logic Storage Systems, Inc. in Wichita, Kansas. He has been involved in Six Sigma for the past three years in various roles in Six Sigma deployment in manufacturing, software engineering, and marketing. Robison graduated with a bachelor of science degree in electrical engineering from Oklahoma State University and is currently pursuing a master’s degree in business administration from Friends University. 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 Six Sigma. 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 Design Creating something new Component System DMAIC Define, measure, analyze, improve, control DFSS Design for Six Sigma Objective Scope External focus Internal focus Critical chain (how) PSP/TSP (how) CMM (what)Voice of the business (capability) Voice of the customer (requirements, CTQs) Tactics Strategy Focus Scope { {Market leadership DFSS 6σ 6σ for software (why, how much, business case) FIGURE 1 The connection between Six Sigma DFSS and DMAIC FIGURE 2 Initiative Integration Map for LSI-SSI ©2003,ASQ©2003,ASQ

×