Someone has just gotten the 6 Sigma religion and decides to apply it to the development of the new software. They define the development process, establish quality gates, count defects, produce statistics. But they're counting defects in the software. The software isn't the product, it's the tool.
Can you elaborate a bit more, without telling too much of course?
I assume the software supports the business ("the 'product' is actually a new process"), and the software isn't shrinkwrap that is shipped to customers.
In my other comments in this thread, cites have indicated that 6σ can be applied to software or any process that can be measured and improved. I get the impression that you feel that in the present case, applying 6σ to this software development isn't going to improve the software because the customers have no impact on the process.
In other words, is the problem that there's a disconnect between what the customers want and what the 6σ process is trying to optimize? Or is it your belief that the "new process" is not amenable to 6σ optimization techniques? Or is it something else?
My impression is:
1) 6σ can be applied to the development of new software that supports the customers.
2) The ideas behind 6σ and TQM and so forth can be applied to the development of a new business process, but measuring bug rates in the support software is only a tiny part of the problem.
3) Without a clear understanding of the overall business goal and the benefits and limitations of 6σ by those attempting to manage the process, they won't acheive their goals.
It's like that old [link|http://www.edn.com/article/CA601846.html|software development mantra]:
British computing pioneer Sir Tony Hoare once wrote: "Premature optimization is the root of all evil." Unfortunately, engineers often take this phrase out of context and use it to justify avoiding any thought of optimization or even plans to optimize in their code.
Charles Cook succinctly explains the problem with this approach: "The full version of the quote is 'We should forget about small efficiencies\ufffdsay, about 97% of the time: Premature optimization is the root of all evil,' and I agree. It's usually not worth spending a lot of time micro-optimizing code before it's obvious where the performance bottlenecks are. But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems. An inexperienced developer will not bother, misguidedly believing that a bit of fine-tuning at a later stage will fix any problems."
The key point here is that inexperienced developers often write code without any consideration of the performance of their code. Unfortunately, system design without any concerns about performance rarely produces systems that perform well without major rewriting. The only thing worse than premature optimization is designing a system without any consideration of system performance. The assumption that 20% of a program's code accounts for 80% of its execution time has been the downfall of many designs.
Here, I suppose we could change it to, "Premature 6σ is the root of all evil." ;-)
Thanks.
Cheers,
Scott.