PSP and TSP are software development process definitions (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 advantages 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 (e.g., 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 incorporated 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 (QFD), conjoint analysis, design of experiments (DOE) and many others have high leverage applications in the world of software, but are not specifically addressed by CMMI/PSP/TSP.

CMMI/PSP/TSP are among the several potential choices of software development process definition that can lead to improved software project performance. The full potential of the data produced by these processes cannot be fully leveraged without applying the more comprehensive Six Sigma for software toolkit.

The Relation of Six Sigma to CMMI/PSP/TSP

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 objectively evaluate the overall effect of CMMI/PSP/TSP on software product quality, cost, and cycle time as compared to an alternative approach, perhaps one of the agile process definitions such as extreme programming or Ken Schwaber’s “scrum.”

The relation of Six Sigma for software to CMMI/PSP/TSP might also be characterized as a difference 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 continuous improvement in the performance of software 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 customer service after delivery of the software, 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 customer and the voice of the business to maximize 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 we 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 – An Illustration
I recently worked with an organization that designs and manufactures high reliability, large capacity storage systems. These products are embedded software intensive, and much of the value-add and product differentiation is produced by the software element of the product. Typically, software determines time to market, which is a very important competitive consideration, as is product reliability.

As a technology leader, this firm 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, they 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 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 co-exist with other improvement initiatives already started or being considered. Our focus here is on the second issue, but we think it important to emphasize 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, (2) a project/program management process known as Critical Chain, (3) Six Sigma product/process improvement (Define, Measure, Analyze, Improve, Control, or DMAIC), (4) Design for Six Sigma (DFSS), (5) CMMI^® and (6) PSPSM/TSPSM.

Market Leadership, to simplify a bit, is an approach to strategic marketing planning that begins at the highest 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 capabilities and channels with respect to ability 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 adequately explained in the space we have here, so perhaps we can simply say that it is 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 project 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 construction in order to be proactive, rather than reactive. Properly executed, DFSS leads to many fewer requirements changes during development, higher customer satisfaction, improved competitiveness, and consequently higher market share and profitability.

Six Sigma DMAIC is that aspect of Six Sigma concerned with improving existing processes or products (e.g., the software development process itself or a particular legacy system). This view of Six Sigma will often leverage the recommendations and metrics of specific CMM KPAs in the Measure-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 is 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 much greater emphasis on the business case and on controlling and sustaining the change after it is introduced.

We have previously discussed PSP/TSP, so let us turn now 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 let’s consider how PSP/TSP relates to CMMI. Our 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 we see connections that relate to different levels of abstraction – CMMI contains PSP/TSP, certain KPAs contain critical chain.

When we think about the connection between Six Sigma DFSS and DMAIC we can visualize a temporal relationship and a tendency for these views to live in different quadrants of the Six Sigma space as illustrated by Figure 1. The relationship is temporal in the sense that we 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 valuable 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 tactically. 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 generalization, there are exceptions and border conditions.

As illustrated in Figure 2, we can consider market leadership as a front end to DFSS – with market leadership we select the universe we will live in, with DFSS we design the space ship we will use to explore our universe. With DMAIC we might improve the fuel consumption 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.

Conclusion

While every situation is different in particulars, we have found that it is always helpful to recognize that we cannot simply pile one thing on top of another and expect to get results. It is always important to realistically survey all of the things that are impacting 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.