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.
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.
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:
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.
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.
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.
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.
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:
Articles and useful discussions in this area will focus on what it means to deal practically with those management issues in software environments.
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:
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.
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:
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.
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.