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?"
Posted by Cliff on 07:58 PM January 20th, 2003 from the we-can't-link dept.
Woodblock asks: "These days all the major corporations are looking at Six Sigma methodology to improve their processes. Should I Ask Slashdot whether for a project using Six Sigma methodology without explaining or providing any descriptive links? Sincerly, Six Sigma Lover in Colorado."
I think you might be able to utilize the Six Sigma backbone to leverage the synergy of your expected net gain while remaining focused on your core competencies. But it might be smarter to start printing out resumes.
One thing that all of the various "quality assurance" regimes miss entirely is the value of being able to make mistakes. Risk-averse managers love this "zero defects" kind of environment, because they like the predictability. However, for the organization in a rapidly changing environment, such predictability is often deadly. Achieving the goals takes too long, and by the time you have perfected a process it's obsolete. Customers have moved beyond what you are doing and demand something else. Your perfect buggy whip is no longer useful in an age of automobiles.
Six Sigma and the like were developed in a manufacturing environment, where the same processes are used for years, and there is time to get it perfect. In the IT industry, two or three years yields a radically different environment. People need the room to take risks in order to deal with such a dynamic environment. The corollary is that in taking risks, sometimes you roll snake eyes and crap out. People make mistakes and if you focus only on the down side, you miss out on the greatly increased upside that comes from taking those risks.
Six Sigma in the IT department sounds like a loser. In IT, you want a management style that is looser and and more free-flowing, able to shift quickly, and not stuck on not making mistakes. (Perhaps the biggest mistake to learn from would be to try to apply Six Sigma to your department!)
--Paul
"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.
I agree with your response, but I'd like to state it somewhat differently.
It's all a question of repeatability.
The idea of six sigma is a statistical thing, where you have a huge number of instances of the same thing, and they are almost all identical: almost completely repeatable. The fewer the exceptions, the more sigmas.
I feel this is quite inappropriate in something like IT app development, because of the one-off nature of most IT apps. It may be a good idea for other aspects of IT that need to be repeated a huge number of times without any glitches, such as phone connections, server backups, etc., and maybe that's all that 6-sigma is trying to address here. But IT app dev is custom craftsmanship. You have a few things that are approximately repeated, such as putting up yet another web form, but most apps are not clones of anything. If they were, it would be "installation", not app dev. Most apps don't even share much in the way of success metrics, and there are far too few of them to talk about 6-sigma.
I believe in statistical process control for repeatable processes, but for custom crafted items like apps, I think other software methodologies make a lot more sense.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."