Six Sigma for Software is rapidly emerging as the new wave of change in Six Sigma and no wonder. It actually addresses the tools AND the root causes of the lack of needed change, management accountability and organizational behavior.
We need to fundamentally change what’s going on in Software. FAST!
Defects, long cycle times, poor estimation, missed targets and project cancellations are stripping away profits and our ability to satisfy and retain customers. It’s occurring in Software Development companies, Embedded Product Software (Firmware), and Business Application Software. And, it’s happening in all industry segments.
During the past 12 months there has been an increasing demand among those companies “in the know” about the power of Six Sigma to migrate the Six Sigma methodology into the Software and Information Technology environment. In view of successful deployment in the manufacturing and service sectors, it is only logical to expect similar results in Software using the Six Sigma improvement process. The early adopters of Six Sigma have proven beyond a shadow of a doubt that Six Sigma’s power can be transported, albeit with some customization, to Software and IT issues.
While the Software Quality Assurance (SQA) body of knowledge is not new, its pervasive and focused application to scaleable improvement has not occurred after nearly 20 years of various applications. Pockets of success and slow rates of improvement have been experienced by some, but not the consistent, breakthrough performance that is possible.
This was also true of conventional Quality Assurance practices in the 70’s and 80’s, in the manufacturing, hardware and other industrial sectors. At some point however, global competition (most obviously from Japan but others as well) created a significant, competitive threat by their adoption of Juran and Deming’s quality improvement philosophies. Six Sigma was Motorola’s answer to that threat.
The Six Sigma process fundamentally created the breakthrough in Quality and Cost that allowed Motorola to catch and then surpass the competition. Similarly in Software, offshore “Software Centers of Excellence” have been created in countries like India, Australia and Ireland. Many of these countries have National priorities and funding to improve their software competency to best in class levels. Does this constitute the new competitive threat to the US Software industry? Perhaps.
Additionally there are multiple cost and quality “burning platforms” needing immediate and focused attention in software today. As evidenced by the following data, prepared by the Research Triangle Institute on behalf of the National Institute of Standards and Technology, our software processes are in dire need of a methodology to drive breakthrough improvement and consistent results.
This “Cost of Poor Quality” (COPQ, in Six Sigma speak) data clearly shows that defects, cycle time efficiency and productivity in Software need major improvement. Note the magnitude and detailed nature of the data now available relating to the issues in Software today. There was a time not too long ago (and still echoed by some of today’s lesser informed software professionals) that Software “can’t be” or “is difficult to” measure. This is a myth.
This study clearly demonstrates that Software and Firmware can and do get measured. This study identifies around forty (40) metrics that can potentially be measured, and thus provide the basis for the execution of a defined and statistically based improvement methodology. With this and other available data as a starting point, the question of how to use it to quickly drive improvement must be asked. The common battle cry among Six Sigma practitioners is “You can’t manage what you can’t measure,” indicating the methodology’s requirement for data driven improvement.
While examining the issue of Software improvement it probably makes sense to examine a few other popular improvement methods available today and their current effectiveness.
The SEI Capability Maturity Model (CMM) has provided us with a good standard of best practices designed to guide an organization down a planned long-term path towards Software improvement. Some organizations that have rigorously applied this approach have demonstrated that long-term improvement may be more likely for them than those organizations that do nothing. But it certainly is not a guarantee – no more than ISO9000 certification is a guarantee to improved market share and profitability. It helps, and it lowers risk but the issues today are speed of execution and magnitude of change. CMM is a good framework for technical process topics but does not get at the issue of management accountability and organizational behavior change.
ITIL, a set of standards and benchmarks for “operational” IT processes is also proving to be a valuable framework in the IT world. ITIL might be viewed as analogous to Total Productive Maintenance (TPM) or even (LEAN) as practiced by some of the world’s best manufacturing companies. Again, while creating a specific set of standards and improving an organizations ability to move down a path toward long term improvement, concrete bottom line results are slow to come and limited in their functional scope.
Other organizations including the IEEE and the International Standards Organization (e.g., ISO 9126) have also developed various standards for Software. However, few of these standards and tools address the organizational and behavioral side of what is happening in Software today. If software professionals are pressed for time in everything they do and no additional bandwidth is available to them, how can they take advantage of these great new methodologies and tools for improvement?
If we reflect on the long experience in Six Sigma for manufacturing we can identify parallels to most of these scenarios. We had a model, we had best practices, we knew what to do, we had technology, we had a burning platform – but change simply didn’t come fast enough or impact the bottom line “hard” enough. The question was, “Knowing all we know, why can’t we change?”
The answer to this question lies more in behavioral sciences than it does in Engineering. This is one of the issues that the early adopters of Six Sigma wrestled with in the mid 80’s. Allied Signal / Honeywell, and shortly thereafter General Electric Corporation, cracked the code to driving a rapid and deep behavior change designed to get results using the Six Sigma methodology. Perhaps as many as 400 companies have followed in their footsteps and yielded similar results.
It is no accident that the provocative terms “Black Belt,” “Green Belt” and “Champion” emerged to label the participants and later applied distinct and specific responsibilities AND accountabilities on their shoulders. Executive compensation packages were altered to significantly change Executive priorities and shift more attention and accountability to improvement related to bottom line results using the Six Sigma Methodology.
Considering this context, Six Sigma is far more than a new fangled tool for our Software Professionals “to try out and see what happens.” It is also not a complete replacement for CMM, Technology Tools, or other emerging best practices. It is in fact a methodology to organize the tools of the trade in a way that they can be executed on business issues that really matter, by people who really care.
Those who have had great success with the methodology know that there is really no going part way with it. We must embrace its 3 major critical success factors in order to enable the breakthrough results.
From here the methodology (DMAIC and DFSS roadmaps and tools) can take over with a high probability of success. As you can now see, we do have a significant opportunity to dramatically improve software. Not by the random application of a few tools, but by fostering a commitment to a long-term change through the implementation of a proven methodology.
Six Sigma for Software is rapidly emerging as the new wave of change in Six Sigma and no wonder. It actually addresses the tools AND the root causes of the lack of needed change, Management Accountability and Organizational Behavior.
About The Author
Bruce Hayes is a seasoned Operations Professional and Consultant specializing in Strategy, Initiative Integration and Six Sigma. Mr. Hayes has over 26 years of industry experience including Operations Management roles in Service, Manufacturing, Engineering, Consulting, Training, and Quality Management. He was formerly a Senior Executive at Motorola where he was one of the key contributors to developing and “operationalizing” Six Sigma. He was also co-founder and, for 3 years, President of a leading Six Sigma Consulting firm. He has served as an Executive Coach and Trainer for many fortune 500 companies implementing Six Sigma in a variety of Industry segments. Mr. Hayes can be reached via email at email@example.com.
Table 1, 2: Planning Report 02-3, The Economic Impacts of Inadequate Infrastructure for Software Testing Prepared by: RTI for the National Institute of Standards and Technology, Program Office Strategic Planning and Economic Analysis Group, May 2002 (NIST, US Department of Commerce).