Slashdot Mirror
Six Sigma-fying Your IT Department?
Saqib Ali asks: "These days all the major corporations are looking at Six Sigma methodology to improve their processes. I am planning to take a Six Sigma Green/Brown belt class in March. I work for the IT department, I have a statistics background, and I've studied statistics in university as well. I can understand Six Sigma being used in Production/Manufacturing facilities, but it is hard for me to figure how to apply Six Sigma in IT. Are any other readers using Six Sigma methodology for IT? If so what are some of the things that it can be applied to? As part of the training class, I have to come up with an idea for a Six Sigma analysis project. Though the project doesn't have to be IT related, but I would like it to be, so that I can see its application in real life. Any ideas for the project?"
link
"Six Sigma" is a buzzword name given to the methods of W. Edwards Deming, who advocated a methodology that depends on having objective, numerical measures of results. In a nutshell, the methodology tells us to understand the causes of variability in product and process design, and to work systematically to identify, understand, and eliminate causes of variation that propogate into the metric for goodness that we choose. Beware trying to apply these techniques when the metric for goodness isn't even clear.
These techniques are used heavily in machining and electronics because they provide an objective, rationally based methodology for improvement. If you are building car cylindars, you use these techniques because if your competitor has more perfectly round cylindars than you do, cars built with them get better mileage and are more reliable and durable.
The Six Sigma methods are difficult to apply in settings where an objective numerical measure of "goodness" isn't available. This is often the case in software design, when features and "ease of use" are the objective. One area where it can be applied quite well in software is in performance monitoring and tuning. Run duration is quantifiable, repeatable, and "faster is better" translates run times into a raw quality measure.
Trying to use statistical methods on metrics that aren't objective or aren't easily quantified. Beware of using bug or defect coutns unless the failure mode is extremely well defined. Crap like "lines of code" or "number of methods" may be objective but there is no way to translate them into an overall measure of quality.
Statistical techniques are a very powerful tool, but they are just that -- a tool. Just like a hammer isn't useful if you need to sand wood, don't expect "Six Sigma" to be the solution to every quality problem.