I’m sure we are all happy to see the new iSixSigma channel dedicated to software. The growing knowledge base at this portal will take shape in the body of articles, discussion forum threads, links, and resources that are contributed. The most important factor in all this is, of course, you, the site participants. While the overall discussion and article topics will evolve over time, it may be helpful at the outset to scope out “what’s different about software” and to think about how software issues intersect with some key aspects of the Six Sigma product and process improvement. The hope is that this discussion will frame the potential knowledge base and prime the pump for a balanced “wide and deep” coverage of all the topics most useful to this community.

What’s Different About Software?

While Six Sigma’s long history in the manufacturing world provides many insights that are useful to applications in software, people can become confused or miss the connection entirely if they try to map the hardware model directly to software. Some consideration of “what’s different about software?” can help identify a more useful way to make the connection.

As Figure 1 illustrates, hardware development starts with a first article build which, in many cases, is the ‘easy’ part. Put a few of the right engineers and some select materials and components in the right lab for a short time and it’s not too surprising that they can emerge with a one-off next-generation prototype. The real challenge, which becomes a focus of Six Sigma for hardware, is the scaling to volume delivery; manufacturing many copies of that prototype, using components and materials from different lots, on different equipment, with different operators at different locations, etc. The lot-to-lot, within-lot, and environmental variation that the enemy can be characterized and managed by measuring tangible inputs and outputs like dimensions, temperatures, rates and forces.

In software, on the other hand, the “first article,” a compiled, integrated system, is not at all trivial, but instead the focus of our design, build and test efforts. There are important product and process measures, which are often intangible or much less tangible than their hardware analogs (e.g. effort, schedule pressure, ease of use). Figure 2 illustrates some of those less tangible factors connected with our efforts to improve the predictability of a software development process. To answer the key management questions “How long with it take?”, “How much will it cost, how good will it be?”, and “What will it be worth?” we have to deal with some input variables like the size of the work-product, the team’s capability, and the schedule compression that will characterize the project management.

On the issue of variation in volume delivery, some will observe that, in software, “Creating 1..n copies is trivial, – all our distribution CDs will be identical, with no part- to-part’ variation.” Even though volume duplication is straightforward, variation in the target hardware and in the 1..n user-environments can still be an important enemy. Six Sigma for Software can help us identify and manage that variation.

Having established a few important things that make software different, we should underline at least one area where it isn’t very different at all. The original motivation for Six Sigma at Motorola centered on reducing escaped defects that contributed to expensive field failures. The software world has long understood the lesson that Motorola learned about moving the focus from “yield” (which tracks defective units) to the greater detail available in the study of defects within units. In the science of defect measurement, analysis, and prevention, the software side of the house stands to learn a lot from traditional Six Sigma.

Scoping the “Software” World

Another part of scoping the Six Sigma fit to software involves recognizing that what people call “software work” itself spans quite a range. The nature of the work across that range can make a real difference in the way Six Sigma measurement systems, models, and tools are applied. Let’s consider these four domains as one way to describe the continuum:

• Embedded software / firmware
  

  This software is closest to the hardware, often controlling it or depending on it for IO, power, etc. Software engineers in this area deal with real time bits-and-bytes issues, algorithms, and often the engineering science (mechanics, optics, chemistry) related to the nearby hardware. While understanding software-specific distinctions is still important – the use of measurement systems, capability metrics, and defect analysis can parallel hardware Six Sigma more closely than the other kinds of software.

• Applications
  

  Engineers in this area deal with the broader system issues that sit on top of hardware and firmware. Databases, client-server/web issues, and information processing are often the focus. The implementation issues, kinds of data available, and the work environment for applications is usually less concerned with physical systems and more focused on things like response time, throughput, and usability. That changes the color of the measurement systems, transfer functions, and analysis one would expect to see in Six Sigma projects.

• Package Deployment/Integration (Commercial, Off The Shelf)
  

  Here the focus is on software packages and systems, often at the broadest enterprise-wide level. ‘Software work’ means selecting packages that provide base functionality, integrating them with company business and information systems using small amounts of code, scripts and work-processes (people-ware). The front-end issues like VOC, Requirements and Measures Development, and Solution Design will directly tap into Six Sigma methods, but the volume and nature of ‘coding’ and test are unique. Some good case studies documenting best practices in this area would be very worthwhile.

• Support (Help Desk)
  

  IT often owns functions that support software installation, upgrades, and data processing. While their Six Sigma work may reasonably be part of the software discussion, this work can map quite directly to the ‘transactional’ Six Sigma that has already built some strong history in the area of services in general.

Mapping to the iSixSigma Software Channel “Dimensions”

The original iSixSigma portal evolved a set of icons to describe different important aspects of the Six Sigma work. Covering those same bases will be important as the software discussion grows. We will briefly spotlight each of those areas, with an eye to the software fit.

Quality Issues and Topics
Deals with the processes and infrastructure that make Six Sigma work at all levels. Architects, Developers, Test Engineers, and managers all play a role in building and sustaining those processes. At the top level, this area connects the broader “quality system” elements, like Six Sigma project selection, Roadmaps, Tollgate Review Checklists, and “Belt” resources, with day-to-day practicalities like how and where tools are used. Issues as broad as the design and evolution of these systems to ones as narrow as specific how-to tips would be welcome as this portal’s software-specific experience grows around these topics.

Management Issues and Topics
Deals with the responsibilities and the payback that management should expect as they plan and implement a Six Sigma deployment. These responsibilities will track with the traditional Six Sigma experience, while requiring some examples to show how they play out in Software settings. They include:

• Preparing for Six Sigma.
• Identifying the people and the readiness timetable for Champions, Master Black Belts, Black Belts, Green Belts, and (Optionally) Yellow Belts.
• Building a project selection process that will identify and prioritize high payback Six Sigma projects.
• Understanding the Six Sigma Common Language and tools (in terms of “how and where are they used?” and “how are the tool outputs interpreted and put to practical use?”).
• Communication – identifying all the stakeholders with various reasons to be involved and informed. Managing the process of creating ongoing messages tailored to each kind of stakeholder (tailored in terms of who delivers the messages, how, when, etc.).
• Walking the Talk – As people are quick to recognize what’s important to their leaders by watching how they actually operate (not so much “what they say”), a key responsibility of a leader is to work in a way that calls for and reinforces the Six Sigma methods being put in place. For example, they need to expect facts and data to be used to support tollgate reviews, expenditure justifications, and other important decisions about key opportunities and risks.

Articles and useful discussions in this area will focus on what it means to deal practically with those management issues in software environments.

Tools
This lowest level of detail, focuses on tools themselves. For each tool that may be spotlighted, it could be useful to consider issues like these:

• How and where (and by whom) is the tool most effectively used?
• What are the ‘input conditions’ for the tool? (i.e. what kinds of information and preconditions are needed to make the tool ‘ready to use’ appropriately and efficiently?)
• What are the steps involved in using the tool?
• Any particular good ideas for gaining special value or addressing special cases?
• What are the pitfalls that some teams have learned to avoid?
• How are the outputs of the tool interpreted and most effectively used?

Particularly in software, we’ll be interested that the broadest scope of the Six Sigma toolkit. While the quantitative and statistically-focused can get the most press in hardware applications, Six Sigma has evolved the application of some powerful tools for qualitative data and language data processing. At the fuzzy front end of design, where language and observational data predominate, it will be interesting to see how people are applying those tools to requirements development and concept selection. Even the more routine DMAIC problem-solving process has a fuzzy front end related to problem formulation. The qualitative data and language processing tools can be particularly useful in software environments to bring the clarity that later enables the use of the more routine numeric and statistical tools.

Integrating Six Sigma and Software Processes

Six Sigma provides ‘process’ to guide the work of team throughout a project. Most notably, there is a Design for Six Sigma (DFSS) roadmap, outlining the steps and tollgates for the creation of new product or process and a problem-solving/breakthrough improvement process (like DMAIC). Software professionals can usually see the benefits in those processes, but they often wonder about how to manage the integration with other software processes that may be in place or in the plans. As Six Sigma is most successful when well integrated with appropriate other processes and initiatives, this forum will be interested in the experience of all participants along this line. Some of the most visible processes that are being integrated with Six Sigma include:

• The Software Engineering Institute (SEI) Capability Maturity Model (CMMSM) and Capability Maturity Model Integrated (CMMI). With longstanding history and credibility in the software world, these models provide guidance about key process areas that describe a progression of better and more effective software processes. This system is a natural companion for integration with Six Sigma, for (to oversimplify) CMM and CMMI do an excellent job describing ‘what’ is important to do, while Six Sigma can describe ‘How’ to deal with practicalities like the planning, data collection, and analysis underlying the ‘what.’
• Personal Software Process(PSP) / Team Software Process (TSP). These methods, introduced by Watts Humphrey, have gained popularity and results based on some sound principles in the area of in-process data collection and analysis. Six Sigma aligns with the motivation and the ‘how-to’ of PSP and TSP. The iSixSigma forum should welcome participant experience in making that integration happen.
• Unified Modeling Language (UML) and Rational Rose Unified Process (RUP). Object-oriented thinking continues to be an important software force. To oversimplify, some of its key goals include:
  • Understanding and modeling the target environment
  • Building robust ‘components’ of known capability
  • Anticipating and dealing gracefully with the whole range of ‘real world’ use conditions

  These goals are absolutely in line with Six Sigma goals. The requirements development work around use-cases and usability can share a lot with Design for Six Sigma methods. Other software standards and best practices from ISO, IEEE, and other organizations provide insight and frameworks that will be important to link with Six Sigma work as appropriate to particular target environments.

Putting it All Together

In summary, we might visualize the software channel task at hand as the opportunity and challenge to do a good job covering and filling the grid in Figure 3. As this portal has reach into such a breadth of software and Six Sigma experience it should be possible, through articles and case studies, inquiries, and forum discussions to eventually populate the site with a knowledge-base that appropriately covers that entire space.