Six Sigma-fying Your IT Department? 96
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?"
Ask Slashdot: What the hell is Six Sigma? (Score:5, Funny)
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."
Re:Ask Slashdot: What the hell is Six Sigma? (Score:5, Informative)
Buzzword alert (Score:4, Informative)
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.
Re:Buzzword alert (Score:2)
The description does sound like a business fad, but in practice is is a very effective way to improve manufacturing processes. I'm not sure if it translates well to IT.
Re:Ask Slashdot: What the hell is Six Sigma? (Score:2, Insightful)
It doesn't matter in the long run because major corporations revamp their processes and trends every few years when some yahoo in the company wants to impress everyone and go on a power trip by changing the dynamics of the company (or so they think). And as soon as it has been changed, trained and implemented, someone else comes along and chances it again.
Project idea (Score:4, Funny)
Re:Project idea (Score:1, Funny)
Re:Project idea (Score:3, Funny)
p.s. At first glance I thought the title of the article was "Is Six-Sigma frying Your IT Department?" Mental Freudian slip?
Is Six-Sigma frying Your IT Department (Score:3, Funny)
That's what I thought I saw too, which is why I bothered loading the story, figured it was a new worm or virus or something.
Now that I see what it really is I'm betting a lot of IT departments would have preferred the malware.
Re:Project idea (Score:2)
Great Idea (Score:2)
For the unintiated (Score:3, Insightful)
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 [motorola.com] with the founders of the "process"
Re:For the unintiated (Score:2)
Being part of middle management doesn't necessary imply incompetence and if the organisation is fairly large, clever middle management is necessity.
Oh yes, thanks for the link - it will be useful to determine if Six Sigma looks like just another meaningless exercise to spend funds on.
More than a buzzword.. (Score:2)
You want LCD screens without dead pixles? You want something like this in place. Cheaper chips? This is for you.
The problem Boeing had rolling out a program like this came in the way of resistance of lower level managers.
Re:For the unintiated (Score:2)
People before process, yes. It doesn't matter what is in some document if the people aren't any good -- or are flat out dishonest.
That applies to any sized project, and the smaller the project the more people matter and the less process does.
I worked on one project where nobody on the customer's side would talk to me for 2 weeks strictly because of office politics and a manager that felt threatened by the contracting company I worked for. We had a great process...and it was entirely ineffective for months at a time.
That said, programmers and tech-only specialists don't make large projects work. Good managers do. Think about it: ineffective management will kill any work that good programmers could do. Worse yet, bad management tends to bring in bad workers. Good managers will get rid of bad workers and bring in good ones...improving sucess.
For large projects, process methodologies are just as critical as the people since management has to be able to say "we will do this". No specs, no design documents, nobody to check the code, ...
Process doesn't gaurantee a thing. Without standards and paper work, how do you know that you've done anything? How do you know the difference between an unreasonable user and one that has a real legitimate gripe?
Document the hell out of everything? YES! Don't allow any flexibility? NO! Just make it obvious what is being done and what is expected. If you deal with reasonable people, it'll work out. Work with bad people (managers or not) and it'll be a struggle. If you don't document anything, you have completed nothing.
Yet another buzzword.... (Score:4, Interesting)
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.
Re:Yet another buzzword.... (Score:2)
Programmers are NOT the best people to test their own code. Other programmers, maybe, but that is even debateable.
Re:Yet another buzzword.... (Score:2)
It basically comes down to having a procedure for everything.
You can be a QA accredited company, and churn out as much crap code as you like, as long as you have a procedure that states that's what you're supposed to do.
Of course, whether or not you have any customers is another matter....
Re:Yet another buzzword.... (Score:2)
Re:Yet another buzzword.... (Score:2)
Test/QA/VV&T starts in the general documents needed during sales -- "this system will do these major tasks" -- and is followed by the initial rough specifications. Specifications -- even poor ones -- do come first, right?
Design (how the specs will be implemented) and coding (the implementation) come after QA/VV&T have been working on the project and have written up initial, if sketchy, test plans.
By the time that coding starts, serious scaling issues should already be addressed. QA/VV&T/Test are there to make sure that things work as specified. If the ability to smootly scale up a project wasn't included in the specs or design documents, it's unlikely to end up in the implementation.
Re:Yet another buzzword.... (Score:2)
Re:Yet another buzzword.... (Score:2, Interesting)
Re:Yet another buzzword.... (Score:3, Interesting)
Now the mission has changed. It is now, "We want the ISO certificate to show our customers to impress them." And now the process is all about documenting what we do on a 10,000 foot level (which really provides no value at all).
And now the internal pre-testing has been pushed back again. (The entire timeline keeps getting pushed back and back and back.) I figure if we wait long enough, a reorg will probably take care of this whole thing, and we won't have to worry about it.
PS: I think ISO9001 in IT is just part of a big ploy to document everything that you do so they they can turn it over to trained monkeys in third world countries to attempt to operate half as well, for a quarter of the price.
I understand what a six sigma deviation is (at least, I think I do), but I don't know the actual process you're going through. I'll assume it is an ISO9001 with a heavy emphasis on refining and best practices? Please don't tip off my management to this. Please?
Re:Yet another buzzword.... (Score:1, Interesting)
Just another "five nines" (Score:4, Interesting)
It's just another metric. Don't get too excited.
Are you trying to tighten a nut with a hammer? (Score:5, Insightful)
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
Re:Are you trying to tighten a nut with a hammer? (Score:3, Interesting)
This is a generalization about the IT field that holds true sometimes (most times?), but not always. In the health-care provider world, for example, they expect data feeds on ...get this... tape reels.
IT is just a tool, it's not the application of that tool. ATM machines, NASDAQ, the FAA, and hospital systems all use ancient IT platforms. But I for one am really glad that they took the time to get it right, and that they almost never fail.
Would you want your bank's ATM system to be rolling out .net web services today?
Repeatability (Score:5, Insightful)
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.
Re:Are you trying to tighten a nut with a hammer? (Score:2)
IT basically moves back in forth between distributed computing and centralized computing. Six Sigma might cause somebody to question all of the bonehead decisions made in pursuit of the latest "right" way to do things.
In 1981, VAX and Mainframe ruled IT. Users poked at terminals. IT Gurus talked about JCL and Serial ports.
In 1991, PCs were in. All the bigshots demanded PCs so they could type memos with TrueType fonts and draw graphs with Excel or 1-2-3. Companies spends hundreds of thousands of dollars hiring IT people to allow these people to share a printer. IT gurus talked about QBasic and Thinnet cables.
2001... Centralized server apps rule IT. Users poke at web browsers. It gurus talk about XML and security.
Re:Are you trying to tighten a nut with a hammer? (Score:5, Insightful)
Right on.
I work in an environment where "zero impact" is the big buzzword. The end goal is to have our change control list at the end of the year list "Impacting changes: 0". Our "emergency" changes aren't allowed to be above 15% of our totals.
So you know what that does? That makes everyone do the tasks that _should_ be change controlled cowboy-style. Nobody wants to submit the forms to replace a failed disk drive, because you're going to get beaten up for it. So everyone just DOES IT and hope for the best. Application teams roll out new code and bugfixes all the time without change controls -- they don't want to sit on the phone with the VP's yelling at them for being over their emergency change numbers
That sort of management style "zero defect" does nothing but drive the business processes underground.
It's sickening.
Missed opportunity (Score:2)
VP: Why are 20% of your changes for emergencies?
Sysadmin: Because you won't buy us [X].
This is your chance to send any message to senior management that you want, and have them listen to it. Dilbert cartoons notwithstanding, senior management are generally pretty smart guys. They may not know the difference between bash and sh, but thats != stupid. They put those metrics in place for a reason. If the limits are being exceeded then they want to know why. Not because they enjoy hitting people on the head but because they want to fix it. And if the way to fix it is to spend some money then you have a ready-made business case.
Paul.
Re:Missed opportunity (Score:2)
If we all reported to the same VP, I'd agree.
But the network, sysadmin, and application teams each report to a different VP.
So no matter what happens, there's always 2 VP's yelling.
If it's a network problem, the sysadmin and app VP's gang up on the network team. If it's a system problem, the network & app team gangs up on the sysadmins.
And it's _never_ an application problem
~NBVB (one of the aforementioned sysadmins)
That's not six-sigma (Score:2)
Lets take diskdrives. Are you sure that disk drives on crucial systems shouldn't be "hot swappable" and thus disk drives should be treated as an operations consumable rather than an infastructure repair. That is a failed disk drive swap would always have 0 impact?
As for VPs beating people up; try raising the issue this way. "You are absolutely correct we are having way too many emergency disk drive swaps. Can I meet with some of the six sigma greenbelts overseeing hardware failures for the networking team to see which aspects of their methods we could apply in system's administration?" The networking VP then has to either put his people on the problem (and the easiest way to defuse criticism is to assign people tasks) or he won't raise the issue again.
And if zero impact is the buzz word work with it. That looks to me like the best cow you could ever want. Zero impact forces:
a) Redundant staff
b) Redundant equipment
c) A full testing environment
I'd bring up non-zero impacts every chance I got.
Re:Are you trying to tighten a nut with a hammer? (Score:1)
A little off topic, but that reminds me of this allegedly true story about unintended consequences:
This was from Scott Adam's Dilbert Newsletter #44 [unitedmedia.com], so you might want to take it with a grain of salt.
Re:Are you trying to tighten a nut with a hammer? (Score:1)
The systems I work with are mostly AIX. One of the great things about AIX is the "chfs" command, change a filesystem. It allows dynamic increases of filesystems. What this means is if a filesystem needs to be increased, the command is "chfs -a size=XXXXXX
1) Provide detailed justification and procedures for implementing the change.
2) Provide detailed back-out procedures on how to recover from the change.
3) Schedule the change so as not to conflict with other changes. Note: change window for ALL systems is Sunday 03:00 to 07:00 and our group is responsible for 300 systems. Note 2: You cannot have two changes on one system nor on multiple systems providing the same function for the same line of business.
4) Get the change record approved. Guess what, it's not as easy as it sounds. For web servers the list includes seven groups, application servers eight, database 11, other infrastructure systems up to 16. Oh and don't forget the person approving the record cannot read so you must repeat the justification, procedures and back out plan for each group. Repeat this step up to 16 times.
5) The change MUST be presented to a least one and usually two "Change Review Groups".
6) If the record is not fully approved by the end of day Tuesday, the week BEFORE the change, special excemption must be obtained (2 VP's must approve). This is a wonderfull rule since most client requests are received on the Thursday before they want the change implemented.
So guess what, changes are implemented on the fly. The process could EASILY be streamlined to have TWO groups approve the change, the requestor and the implementor. All that is needed for documentation is a copy of the e-mail pasted into the change record. 5 minutes of work instead of at least 6 hours and you dont have employees whing about internal bullshit on
If GE can't even make it work... (Score:4, Funny)
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.
Re:If GE can't even make it work... (Score:1)
Still no quality (Score:1)
I thought about that, when I read the original post, but the quality has to come from the whole right? So if they don't know how to get a quality out-sourcing (web development in this case), then they don't have quality. Simple is that. I think that "We bring good things to life" (GE's slogan) is a myth. I'm not saying that GE is a crappy company; they know how to deliver the number. I'm simply saying that GE is just good enough so that they don't fall apart.
Re:If GE can't even make it work... (Score:2)
Of course nowadays the presence of the GE (or RCA) logo on a product in no way guarantees that it was actually designed and/or manufactured by them.
Re:If GE can't even make it work... (Score:1)
Why stop at six (Score:1)
Perfect for response times (Score:3, Interesting)
Yet another trendy yet meaningless name... (Score:3)
You also have to be seriously wary of a "concept" when its website has, as its first link, a place to buy logo tee-shirts. This sounds like a Dilbert cartoon.
I hope the program doesn't include large banners that say "Quality".
Re:Yet another trendy yet meaningless name... (Score:2)
Or more commonly referred to as one iota of success.
Dilbert knows all... (Score:2, Informative)
Re:Dilbert knows all... (Score:2)
Six Sigma: It's what you say it is. (Score:4, Interesting)
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
Re:Six Sigma: It's what you say it is. (Score:2)
I also agree that Six-Sigma often translates as "give money to consultants".
Six Sigma (Score:4, Informative)
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?
Re:Six Sigma (Score:2)
Our team (and many others) has been moved from being a "service" or a "support" to being a "capability". That's right. Instead of providing service, or supporting a customer, we're now a Systems Administration Capability. As in, "We're capable of meeting your needs, but we'd rather take a nap."
Nice to see where that process capability lingo snuck in there.
1/6th Sigma (Score:1)
1/6th Sigma, Leanest of the Lean.
SuperGlue
Re:1/6th Sigma (Score:1)
Reminds me of when I was in a college speed reading class, I dropped it after 2 days since I was done.....
SuperGlue
How to implement Six Sigma in IT - 3 easy steps (Score:2)
Step 2 - Wait for an IT group to complete a project... For example, wait until the network staff has completed migration to a new network infrastructure.
Step 3 - Claim real and imaginary (don't be afraid to invent the figures) cost savings as a Six Sigma savings.
Six Sigma in a Software Company (Score:3, Insightful)
-Derek
Re:Six Sigma in a Software Company (Score:2)
There are several replies to the article mentioning that Six Sigma is for manufacturing processes, and other replies mentioning Six Sigma in the context of software development. If the software project managers are really hungry for a formalized process, why not implement the CMM-SW or CMMI [cmu.edu]? They are designed from the ground up for software and not for manufacturing.
Re:Six Sigma in a Software Company (Score:2)
This usually fails for existing projects since it's difficult to engineer something that has grown up organically.
The sucessful managers don't waste time on these existing, organic, projects. Instead, they start with a new project and allow for change. They drag in the users of the systems first and learn what they do. They document failures of the deployed system. They try and make using it more natural so that the delivered system matches the process and silently enforces consistancy.
Unfortunately, six sigma or CMM are check boxes for many managers since they are told by thier bosses to get it. Real improvements are usualy secondary. I try and drag along useful processes under the guise that if we don't do them, we aren't going to get that check box. To me, that can make quite a bit of difference. Manage your managers.
Six Sigma (Score:5, Informative)
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.
flavor of the week (actually decade) (Score:2)
IMHO, great managers are born and not made, there are just some people who have the right mix of charisma, leadership, and care of their employees to cajole the best mix of production with morale, and no amount of schooling will take a bad manager and turn them into a good one.
Don't get me wrong, six sigma is a good idea, just like all of its predicesors it certainly has a place in many operations, but it is not a panecea that will solve all of our current managment problems. Anyway, I have rambled enough for the night.
six sigma and IT (Score:2)
The DMAIC model outlines a software construction process.
From a high level project management standpoint bugs & non-included featues in a program are "defects" and the defect reduction models would apply.
The unity between six-sigma management structures and corporate management structures would apply.
The focus on the customer would apply
So yes six-sigma works perfectly for IT work. But instead of measuring number of defective widgets per million you are measuring number of defective lines of code per million or number of requirements that were failed be met per million...
As far as stupid management philosophies this one is relatively harmless. TQM is actually excellent but a great deal of the really good stuff in TQM has been taken out of six-sigma.
So in answer to your question I'd apply it to an important software project you are working on and track bugs in the program. You'll get to find out what your customers really want rather than what you think they want, or what you promised to deliver. You'll get to find out how over the years the software has been meeting their needs better (or not)...
Anyway cheer up this isn't so bad. You are actually going to learn manager speak to get time to do projects right.
Re:six sigma and IT (Score:2)
But instead of measuring number of defective widgets per million you are measuring number of defective lines of code per million or number of requirements that were failed be met per million...
As I said above, using metrics like these will result in wasted because they are A) unknowable and non-objective B) don't actually translate to "quality" C) drive behaviour aimed at manipulating meaningless numbers instead of improving the product.
A metric based on lines of code is not likely to have any relation to actual end user perception of quality. Writing cleae, maintainable code often involves writing MORE lines of code. This reduces waste over the full product lifecycle, yet the metric punishes it. The metric is also not very well defined: if the program doesn't do X how many lines of code are defective? All of them? None of them? The number that I change to add it? If I refactor my code to add the new feature and change 500 lines of code is that always worse than hacking in a 20 line fix that is much more fragile and nobody but me understands?
Anything based on "number of requirements" is even worse. I have never once worked on a software project where requirements were sufficiently well defined and static to base an objective measurement on. This "problem" is inherent in software development because an application does different things for different people whose understanding of what the application is and could do is constantly evolving. Two people will count the number of requirements not met differently even for the same "bug". If you change the metric to "documented requirements" not met, then the most common answer for bugs is (and should be) "zero". If you count undocumented requirements, then people will always answer "one" to minimize the defect metric, and your requirement documented will evolve into a bug tracking sheet.
measure stage (Score:2)
As for number of requirements here I somewhat disagree. What I was considering is a scenerio like this:
1) All end users make up a wish list
2) All wish lists are combined into a complete set of requirements
3) As time progresses end users and only end users can by unanimous consent drop requirements
4) As time progresses any end user can add requirements
Its this set that we track bugs against. Clearly
a) Some requirements contradict other requirements
b) New requirements get added
c) Some requirements get dropped
d) Many requirements are cut in very early stages as "out of scope"
I think with a program over a period of years it gets pretty close to the "it does what I want it to do" stage. There should be a drop off over time. I can't imagine a software system getting to 6-sigma (which would probably mean something like all but 1 requirement) but I can see an upgrade effort aimed at going from 2 to 3 sigma.
______________
I also completely concur with you that this system is likely to not prioritize well. "What's get rewarded is what gets done". I'd be much happier with a TQM type approach. I agree with Demming completely that management by objective, quotas... tend to be descructive. Software defects are most often caused by
1) Poor leadership in management and executive positions in terms of trade offs (particularly time related)
2) Unwillingness to train staff
3) Poor choice of tools
IMHO Six Sigma in practice is likely to do a great job on #3; and make #1 slightly worse. Real six sigma would attack all 3; but a low level IT guy isn't going to be in those meetings.
Break it down. (Score:4, Interesting)
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
Re:Break it down. (Score:2)
I've used the same tactic...it's effective to a point. The worse the manager, the more likely they will foot drag on these types of requests or lead you into 1000 what-if type questions that lead nowhere.
The better the manager the less likely it's necessary to do this because they already know. If they can't do it (budget), they'll say so but only after they have gone on a money hunt.
PS: Feel free to show this to your boss. Make sure he knows my email address is peter at fpcc net ;-) I'm available for consulting, or save a bundle and hire me outright!
Same here...Washington DC area (local), national, or international; active.consulting at metamark com .
Nasa uses something like it (Score:2)
The bottom line is that this sort of method does work, and can lead to impressive software reliability. But, it also raises the cost per line of code by an order of magnitude or more.
We've done six sigma (Score:2, Interesting)
Anyways, come the end of March last year, six sigma deadline, stop coding and software test and release date. We all stopped production to complete our six sigma projects. And for the most part we swindled it something awful. We picked changes and additions to the software that we performed ages ago. Our premise being that before the change our software was 0% compliant (worse than six sigma) and now with this functionality we were 100% compliant (better than six sigma). So we all did that, past a test on basic statistics, and we all got our little certificates and we all got a pat on the back.
And with the "millions" saved through our six sigma projects we still couldn`t afford any training last year.
It was the rollout and attitude from management and the "six sigma blackbelts" that was the worst part. Six sigma was clearly aimed at production and manufacturing and there was no leeway for software engineering where it is a very loose fit at best.
I hear rumours that "design for six sigma" is better suited to the software industry, but that would require more training...
So as you can see, not too impressed with six sigma.
Re:We've done six sigma (Score:1)
Six Sigma Summary for Dummies (Score:4, Informative)
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.
Misapplication (Score:2, Insightful)
What about an IT process is meaningfully quantifiable?
What about an IT process occurs in statistically significant numbers of comparably quantifiable instances?
What do you have a million of to see where you stand relative to 3.04 defects? Transaction processing response times. What else? Not much that I can think of.
Re:Misapplication (Score:1)
We got around this be implying that new functionality is quantifiable.
If we didn`t have the functionality then we had 1 million defects out of 1 million, everytime you tried to use the non existant functionality it wasn`t there.
So when we implimented the function we were 0 defects out of 1 million, now everytime you use the functionality it is there, doesn`t matter if it works...
And yet the "Quality" never improved, which I believe is what six sigma is all about
Any jobs going at your company? (Score:2)
Answer would presumably depend on the size of your IT department. If you are vast, recieiving thousands of calls each day, then sure; statistical analysis could perhaps identify weaknesses in the processes. If you aren't vast, then I can't see it being much use.
Sounds like you have the hammer problem; if all you have is a hammer, ten everything looks like a nail. If you are a statistician, then you approach everything as a statistical problem.
Defect counting (Score:2)
If you count runtime execution, and write the following code: := 1 to 1000000
For i
WriteLn('Hello, World!');
How could this fail 3 times, in it's lifetime?
Would it be ok for an Open Dialog to fail that often?
Would it be ok for a Save option to fail that often?
Would it be ok for any common option to fail that often?
If you count source code, instead of execution. If the program is Perfect, with zero defects, but is hard to use, is it good enough?
The only acceptable metric would be how often the final user doesn't get what they need or expect... and that is one hard to measure quantity, but I believe it's the only one worth measuring.
--Mike--
Easy way to get a low defect rate (Score:1)
To lower the defect rate, just add more code bloat so the denominator gets larger. Problem solved in a way that makes the PHB's think you're really making progress.
Now that I think about it, this explains so much . . .
Re:Six-Six-Six Sigma-fying Your IT Department? (Score:1)
You want data. (Score:2)
- is expensive, or
- annoys your customer and
- is highly variable, and
- is easy to instrument?
Projects I've worked on in the last year include LDAP server response times, OS image size, OS image development time, application server capacity planning, database server consolidation...Depends on your target (Score:4, Insightful)
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.
Statistics can be useful (Score:2)
In a particular national network, all DNS requests went to one of two data centers, one on the East Coast and one on the West. During an exercise which measured the response time for a particular end-user service which included a DNS lookup, we discovered that the distributions of response times for DNS lookup for the two data centers were different. Further investigation (had to write some custom data collection software) showed that the problem was that about 1% of the DNS requests sent to the West Coast data center produced no response. The East Coast center produced no response in about 0.1% of the attempts, which was consistent with the known packet-loss rate in the backbone network.
I believe the problem turned out to be a faulty load balancing box sitting in front of the multiple DNS servers. As a result of the episode, however, the service-level agreement for the DNS service was expanded to include response rate and response time, as well as server availability.
Don't forget that you don't have to reach 6 (Score:2)
6 sigma works great for some things, but it is expensive to reach it. Do not lose sight of the fact that you don't always needs such agressive goals. There is nothing wrong with deciding that 3 sigma is good enough for you, and a lot cheaper to reach.
Remember the goal is to reduce costs. If you spend 6 billion to reach 5 sigma, and save 15 million per year, you will never pay off your investment. (Unless your company can honestly say that their products will still be in demand 2000 years from now, something history doesn't support) When talking to management do not forget that costs are what they should be thinking about. Those who understand 6 sigma will readially agree with you when you suggest that you don't have to reach as high.
That said, do not try to kill legitamit projects. Real money can be saved by following 6 sigma mythods. Perhaps not everything will apply to you, but take the good and make something work. There is no need for not invented here syndrom.
Not really possible (Score:2)
Uptime (Score:2)
On the other hand, there are some concrete numbers that you can use a six-sigma standard on.
Uptime: over a year, your total downtime should be under 107 seconds. That's right, less than two minutes of downtime per year, for all causes! Since no system can reboot that fast, that means redundancy with fast cutovers.
Connectivity. Again, over a year your total network downtime should be under 107 seconds. That means multiple upstream providers, multiple gateways, etc.
Virus protection. Out of every million viral-laden messages (say a typical afternoon when the lastest MSTD is in full swing
I'm sure you can come up with your own metrics. These are also far more useful measures than the "process driven" ones since it's what the IT "customers" really care about. Think about the analogy to a commercial product - when you get an empty can of soda you don't care how well the can was manufactured or how great the unseen soda would have tasted, you only care about the final product.
Six Sigma-fying Your IT Department? (Score:1)
Careful - this only applies to normal distribution (Score:2)
Due to the resolution of the stepping motor that controlled the cutter, the resulting component lengths, when plotted, were a uniform distribution - for length N-(delta/2) to N+(delta/2), where N was the desired length, and delta the minimum step distance. Within that range, all lengths were equally probable.
The customer got angry, because he needed a less than 1ppm out of tolerance rate (tolerance was about 5*delta), and by his calculations we failed.
His calculations? Measure 100 parts, compute sigma, is 6*sigma < tolerance?
The problem is, the equation P(n:n6*sigma) ~ 10^-6 only holds true for a Gausian (a.k.a. normal) distribution (in other words, probability of x, given x is more than 6 sigma from mean, is less than 1 part per million only for a Gausian curve).
Asserting that if you meet 6 sigma, you will be less than 1ppm only holds true for a Gausian curve.
So to apply this to something without first demonstrating that the something follows a Gausian curve is WRONG.
In my case, the failure rate was so very much less than 1ppm it was pathetic, but since this person did not understand the statistical relationships he was trying to apply, he caused us no end of grief.