- New JobKraft FoodsLine Leader
Many software organizations are beginning to use Six Sigma, and are finding that they need to rationalize its relationship to the standard software development life cycle process. A number of issues and alternatives arise when this need is addressed.
Six Sigma includes two complementary roadmaps. The first of these, Design for Six Sigma (DFSS), is used to develop new products and processes through the DMADV approach, which includes Define, Measure, Analyze, Design and Verify phases. The second roadmap, DMAIC, uses Define, Measure, Analyze, Improve and Control phases to improve existing products and processes. Specific tools and deliverables are associated with each of the phases in each roadmap with the DFSS methodology fitting naturally inside most software development processes. The roadmaps are not a replacement for good design practices. Instead, they offer a disciplined, role-based approach to improving efficiency and customer satisfaction by removing typical errors, misapplication of existing tools and mismatches in requirements and features.
SDLCs include many different forms such as iterative, waterfall, agile, and RUP (rational unified process), all consisting of phases and tasks, each with associated tools and deliverables. Both SDLCs and DFSS are used to develop products so, on a conceptual level, they are fundamentally similar and can potentially be merged into a single framework or organizational standard.
One way to rationalize the relationship is to map Six Sigma DFSS tools and tollgate reviews to specific phases and tasks within the SDLC. One might, for example, invoke Six Sigma tools such as Kano analysis during the requirements stage or quality function deployment during Design. This approach is fairly clear-cut requiring a relatively small effort (perhaps several person years for a large organization), and is likely to produce some benefits.
In contrast, DMAIC is a process/product improvement process that can enhance some elements of the SDLC, but does not map directly to it. For example, a DMAIC project applied to the development process can improve average project cycle time or optimize work product inspection to reduce required labor and improve defect discovery rate. Any process area within the SDLC can benefit from the application of DMAIC.
Mapping Six Sigma tools to the SDLC can enrich and improve the software development process and lead to better software products, however this step alone is not adequate to realize the full potential of Six Sigma. Six Sigma is a business management system that applies to every facet of the business, not just software development. Hence, it is more appropriate to think of Six Sigma as something that overarches the SDLC, rather than as something that is included within it.
Six Sigma is far more than a set of tools. It is a comprehensive, role-based process for breakthrough (step function) change and improvement in every area of the business. It was engineered to address typical pitfalls in problem solving behaviors. By design, Six Sigma attacks critical root causes of systematic, chronic and recurring problems. The methodology requires permanent resolution of these problems verified by a closed loop measurement system and a control plan. It succeeds when it is deployed top-down, beginning with linkage to the business critical strategic imperatives, leading to specific and focused improvement projects aligned to those imperatives. Six Sigma improvement projects culminate with documentation of financial benefits verified by the CFO.
One of the most powerful aspects of Six Sigma is that it establishes a common language that enables fact-based conversation among all parts of the business enterprise. It is designed to engage all stakeholders in a process that leads to optimal business outcomes, rather than outcomes that are locally optimized to the needs of any particular area of the business (silos). It clearly makes sense for software specialists to learn this language, as it is unrealistic to expect that the business at large will learn the language of the SDLC.
Six Sigma provides a common framework for cross-functional conversations and decision making that engages marketing, sales, systems engineering, finance, manufacturing, support organizations, and software engineering. In contrast, the scope and intent of the SDLC is largely limited to systems and software engineering, which is rarely understood by (or of interest to) other areas of the business.
From a software development perspective, Six Sigma brings benefits that transcend the specifics of any SDLC. In particular, it makes specific and explicit connections between decisions related to software development and business outcomes stated in financial terms, thereby closing the gap that often exists between the business and the software team. Six Sigma leads to a solid and sustainable business case for software process improvement that is justified and understood by corporate management, a situation rarely experienced prior to the entrance of Six Sigma.
Mapping Six Sigma tools to the SDLC is useful and necessary, but alone not sufficient to drive permanent, systematic, breakthrough results. The full benefits of Six Sigma are realized only when software organizations learn the common language and engage with every area of the business to maximize financial benefits, a far larger and more challenging task than simply mapping to the SDLC.