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.
I've alway been of the opinion project and processes methodologies are the last resort worthless middle management use to justify their existence. Leadership, aptitude and competence being fearsome skills they prefer to outsource.
Should your institution decide on that course - its a good idea to start with the founders of the "process"
Hmmm, lets see, I have been through:
Mil-Spec (which sort of actually has a point but is a bit over done, well a bit is an understantment and you are at the whime of the government auditors, better keep them happy.
QA (Quality Assurance, uhh WTF? can we say paperwork)
ISO 9001 and ISO 9002 (really is there a difference) yes I know the textbook answer, but it seems simply to amount to more paperwork, less productivity, surprise inspections, it is like Mil-Spec without the fat government contracts, sort of like eating healthy and still having a heart attack).
Now the latest, Six Sigma, some tool writes a book on applying standard deviation to business practice and know everyone is on the boat. Give me a break, yet another engineers paperwork hell. Anyone who says it works probably has an MBA.
It's just another metric. Don't get too excited.
Free Java games for your phone: Tontie, Sokoban
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
Last Fall I was searching for a new refrigerator. I had settled on a GE model, and was combing their website looking for specs and ran into dozens of html/web app errors.
;)
Having just read an article about how GE pioneered six-sigma, and thinking about the statistical distribution of the 6th sigma, I recall figuring that there must have been millions of web pages on that site, and I must have just hit all the ones with errors by chance.
Well, it was either that or GE hadn't managed to apply Six-Sigma to their web development, and I knew that couldn't be true because I had just read it was used throughout the organization.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Soon, I will be implementing an automated monitoring system for our web servers, etc. I plan on using a 6 Sigma approach to monitor reponse times. After all, they do vary with load, and 6 Sigma is more adaptive than establishing a hard limit. Plus, it is trivial to implement (our web servers log to a Postgres server, so 90% of the work can be done with a well-written select ...
6 Sigma is given a bad name by MBA types; it really is an extremely useful technique ... don't let these naysayers discourage you! (but be sure you don't succumb to the 'every problem is a nail' dementia)
The owner of my company read the book 'The Six Sigma Way' and got very excited about it. He asked me to read it, and he asked the manufacturing guy to read it. Whenever we would have a problem, he would say stuff like "That's not Six Sigma" in email.
I read about half of the book. It seemed to be a bunch of billions of generalities, complete with meaningless charts and graphs, and I am not actually sure what implementing it would do in a concrete sense.
The basic idea of doing a ground-up analysis of your business to determine what needs to be done to make things more reliable is, in my opinion, something every business should do periodically. However, I don't think giving it a trendy name and insisting on hiring expensive consultants is going to help quality as much as just, well, periodically scrutinizing your own processes and looking for ways to improve quality.
One of the key things the book said is that if you don't have buy-in from management and employees, Six Sigma is useless. So if nobody in your company wants to drink the Kool-Aid, it's pretty wortheless. But if people are enthusiastic about improving the way their company works, I'm not sure if the Six Sigma framework says that much that common sense doesn't.
Hope this helps; I welcome dissent from the better informed.
D
It's called process capability analysis in the textbooks.
Six sigma arose out of a rigorous statistical method of analysis of manufacturing data. Basically you plot some measurement of some characteristic of a device being manufactured over a large number of samples. This provides a characterization of the manufacturing process. Hopefully the data you chose to gather is normally (in the formal sense) distributed and you can assign a mean and standard deviation (sigma) to the data. You also examine where the actual specification for the measured characteristic lies. A simple way to characterize the location of the specification is in terms of the number of standard deviations (sigmas) that the specification is away from the mean measurement. Six sigma is simply a statement that the specification is six standard deviations away from the mean. Measurements outside the six sigma range denote defects.
All of this is very cut and dry stuff that has been used in manufacturing for decades. Six sigma was 'popularized' when Motorola adopted it as a quality goal for their products company-wide.
How does this apply to software development? I don't have a clue. How the hell do you establish a process capability measurement for a software development process in a rigorous fashion? Good Luck.
IMHO this is just the latest quality fad that is rippling through the management/consultant community. What next? Re-engineering rises from the ashes again?
"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."
Okay, your department does stuff, right? Break that stuff up into categories. Look at where things can (and do) go wrong. Try to figure out why. Figure out a way to measure success vs. failure. Then apply those measurements.
;-) I'm available for consulting, or save a bundle and hire me outright!
Some concrete examples.
What percentage of updates to "internet facing" services are applied within a set time frame? Maybe you decide they need to be applied within four business hours, or maybe 12 hours. When a patch is released it is a "moment of truth."
What percentage of help desk calls are resolved (i.e. the employee is back to work) within x minutes (30? 60?). Why aren't they all?
Six Sigma is full of buzzwords, but IMO it has some great potential. If I was a a guy "in the trenches" (sadly, I'm out of the technical field right now) I'd be taking advantage of a Six Sigma push to help my boss (and his boss) feel my "chronic pain." I.e. "The reason we can't resolve 99.992% of help desk calls in 60 min is that we don't have the parts we are supposed to have." or whatever.
PS: Feel free to show this to your boss. Make sure he knows my email address is peter at fpcc net
-Peter
From the site:
Six Sigma is a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a company's operational performance by identifying and eliminating "defects" in manufacturing and service-related processes. Commonly defined as 3.4 defects per million opportunities, Six Sigma can be defined and understood at three distinct levels: metric, methodology and philosophy...
With such a description, I wouldn't touch it with a ten foor pole.
the pun is mightier than the sword
1. You have a problem
2. Collect stats about it
3. Analyse those stats to identify the problem
4. Some sort of magic goes here to get from problem to solution
5. Apply solution
6. Collect stats again
7. Calculate saving and claim is a 6Sigma saving
8. Claim that the solution can be applied elsewhere for some vague future saving
The problem is that the saving comes from applying the solution (Step4) not from the process of Six Sigma.
Step 4 is done by the skilled engineers who know what solution fixes what problem, not the Six Sigma MBA who has no special expertise in the process.
If the fix can't be applied because the guy is collecting statistics in Step 2) then he is causing the company damage by delaying the fix.
His own salary is also a cost and the load he puts on the skilled engineers while trying to 'learn' their skill also costs money.
In order to obtain statistics, you have to know what the possible causes are, so in the real world, they go to the engineer who already knows the problem and contrive a set of stats to collect that prove that solution.
Then there's step 8, claim it will be re-used.
If you look at the examples Six Sigma people give, its stuff like a leaking airconditioner pipe.
If you have a leaking air-condition pipe, you hire a plumber or buy a book on plumbing, you don't look through Six Sigma projects looking for one that might turn up useful information.
Quite simply the chances of someone re-using this information is negliable and its the fix in step 4 is the thing that would be reused and that isn't a Six Sigma step.
So no, it just fluff to keep middle managers employed. That is why every company that uses it continue to increase costs. GE increased profit came from increase *sales* and economies of scale, not Six Sigma.
As many of the people have already commented, your responses are going to break down into one of two types:
The question is, what exactly are you hoping to make use of 6S for? Six Sigma is a methodology for analyzing business processes - customer interactions, process flow, things like that. It's not a process for developing programs or websites or business tasks.
The majority of the audience here on /. probably does not (judging from comments already posted) does not know the difference between "business processes" and "business tasks". Tasks should be done in the manner which is most effective. However, the framework around those tasks is something that can be analyzed and improved...
If you are an end-of-the-line technician/programmer/coder/etc/etc/etc, then Six Sigma will not necessarily be of help for you. Six Sigma will not help your company with the people that do the business. However, if your position gives you access to be a project manager, or department leader, or something sith some kind of management level overview, where you can influence the way various groups work with each other, then you will find the methodologies helpful.
This space for rent. Call 1-800-STEAK4U