iSixSigma

The Myths of Six Sigma

Six Sigma – iSixSigma Forums Old Forums General The Myths of Six Sigma

Viewing 48 posts - 1 through 48 (of 48 total)
  • Author
    Posts
  • #28427

    Carol Trimmy
    Participant

    Hi everyone,
    I’m trying to do some thinking around the myths associated with Six Sigma. I’d like to brainstorm as many myths as possible, so that I may prepare a response when these myths are voiced in my Black Belt’s teams. I would greatly appreciate your help on this forum in presenting additional myths. Here’s what I have so far:

    Six Sigma is the same as TQM
    Six Sigma is too statistical for Transactional processes, it should only be used in manufacturing
    Six Sigma projects take too long to complete
    Six Sigma is too complicated for our business
    Thanks!Carol

    0
    #70790

    muhannad al nabulsi
    Participant

    here are some more:
    *it is  a business strategy
    **It helps to think & act like engineers.
    ***It is customer driven
    ****Whateveryour spec.limits are,this will be set at six-sigma above & below the process mean.
    *****It is the 3.4 defects per million
    ******It is to achieve world-class q.improvement
    *******It is to reduce costs at a revolutionary rate.
    I hope this would help,good luck,regards.     MN
     act like engineers

    0
    #70793

    mcintosh
    Participant

    Muhannad,
    I’m not following your previous post…did you post myths (un-truths) or true things about Six Sigma? For example, Six Sigma is customer driven and it can lead to a world class quality improvement system or business.
    Tom

    0
    #70794

    muhannad al nabulsi
    Participant

    Hi Tom
    I agree with you,based on  my practical experience it is always better to mix myths with “true things”,in a “quiz type”presentation,as attendents will be obliged to “think”twice before jumping to conclusion.
      I hope you  and Carole would agree on this,thank for remark.Muhannad

    0
    #70796

    Jaran S.
    Participant

    What I have heard some of these myths of Six Sigma myself :
    1. Six Sigma is for production only, not for engineering.
    2. Six Sigma is for production improvement, not for process/product development.
    3. Six Sigma is not for R&D. It damages creativity.
    4. Zero defect program is greater/better than Six Sigma becuase Zero defect program generate no defect while Six Sigma generate defect 3.4 ppm.
    5. TQM is greater/better than Six Sigma because TQM invloves total effort while Six Sigma involves partial effort.
    Hope this helps.
    Jaran S.
     

    0
    #70797

    Mike Carnell
    Participant

    Carol,
    Consider a couple things. People are going to raise objections (some) not because they are really concerned as much as they are resisting change without really appearing to resist change. If you look at the people who dwell on the 1.5 sigma shift it is the same thing. Rather than uderstand the thing they identify an insignificant piece and create the cacophony of esoteric BS so they don’t have to do anything.
    Start with “The Deming Management Method” by Mary Walton. In particular the 7 Deadly Diseases and the Obstacles. You will be amazed that the same stuff Deming heard 20-30 years ago is alive and well today. “We are different” being one of them and the never ending request for case studies by people whoare just to lazy to understand the basic concepts and develop their own understanding. There is also a warning about the dependancy on statistics. You need to remember that Six Sigma is about results not Statistics. You will typically find that those people who constantly  drive this to discussions about tools and statistical theory do so because it has very defined parameters. The application is wide open. They typically do not have the understanding of the application or they are so wrapped around the axle with constraints they can always find a reason that they can’t do something or what somebody else did was wrong. The stats are tools, results is the centerpiece of the program.
    As far as it does not apply to transaction stuff is pure garbage. Three issues:
    1. Transaction processes are typically not designed so they have evolved and generally upon examination look pretty bad. They are typically staffed by white collar workers who believe that manufacturing is where the problems are and so that is where the improvement should focus. The reason they don’t require sophisticated tools is that they are much further down the evolutionary ladder than most manufaturing operations and therefore gets results very typically from a process map. It isn’t that the tools do not apply. They are just so screwed up that the basic tools do it. Remember that very typically the Transaction types are more sensitive. If you come from a manufacturing environment you have to coddle them more than a manufacturing group.
    2. A t test, tests means. A F test, tests variances, etc. The tools are not specific to manufacturing. If I put in a column of data Minitab does not request a process identification before it analizes the data. Tools are tools. (As far as DOE it does have limited applicability but that applies to a lot of other processes as well. DOE’s are a pain in the butt to run and are intrusive. If you really understand Hypothesis testing you can eliminate or reduce the use of DOE in a lot of processes. This comment will enflame a lot of the esoteric types because they love to create the smoke and mirrors around the DOE stuff so they look like guru’s.)
    3. If you look at the history, which begins at Motorola. the requirements were on the transaction stuff right from the beginning. Motorola’s Seguin, Texas operation did a great job of manufacturing engine controllers for Ford. They did a great job on their shipping process (because they frequently shipped to the wrong location) – pre 1990 project.
    As far as being the same as TQM it is not. Compare the tool sets. Remember ther is a difference in SS programs of study. The brand which we took into Allied Signal Automotive (I was one of the consultants there) and GE (I was hired at corporate there – Gary Reiner, CIO, sorry about the name dropping) was the product of Motorola Government Electronics.
    As far as the lenth of time a project takes this is a product of the people trying to move the methodology t o something else. First a project should be a chronic type problem. If it is it is not going to be a fast solution otherwise it would have been corrected a long time ago. Second we have spent years screwing up out processes. We have many people with a 30 minute sitcome mentality (Definition to solution,everyone’s happy and the star is the hero). If that is the issue get them out of the program because they will screw it up, get the company to stop doing SS, or quit and go somewhere where they are serious about improvement.
    The one I haven’t heard is “Program of the Day.” Usually this starts with some jaded mid level manager who wants to be percieved as a battle hardened veteran. In truth they look like scared jerk offs. The minute they use that language they are quietly killing the program. When they do this in particular in Champion training ask them in fromt of the entire group “Who is the most empowered group to turn this into a program of the day?” they will stammer around for a while. Tell them “You are” and explain why stupid comments like that kill programs and that they might want to consider that the long list initiative failures is their list of failures. Ask them what they are scared of which is what it really is.
    This is the same reason they struggle with project selection. Project selection is nothing more than assigning work. If they do not know what their most chronic and impactful issue are they they should be fired for incompetance. The reason they push back on project selection is that their selection is very public. Watch them crawl under the table when a CEO asks “Who picked that project?” (Coach the CEO not to do that.)
    I hope some of this stuff helped. You are dealing primarily with fear of change. I am told that my reference on change is antiquated but I like the book “Managing at the Speed of Change.” You can also get some help from “Adhocracy” by Waterman and “Future Shock” by Toffler. If your company has a OD person use them as your personal consultant. Drag them into your team meeting with you. They need to be involved in the change strategy.

    0
    #70798

    Jim Johnson
    Participant

    Carol, I agree with Tom.   Most of the “myths” that you will hear are simply masking RTC (Resistance to Change).  The very best book that I have found that deals with this is by George Eckes and is entitled, “Making Six Sigma Last:  Managing the Balance Between Cultural and Technical Change”.  The ISBN is 0-471-41548-0.
    The key point that I want to make to you is that the real issue revolving around all of these “myths” is that they are simply symptoms of the true issue – Change Resistance.  Use the tools that Mr. Eckes discusses in his book and you will find that you have empowered your BBs to be effective and efficient Change Agents that promote change and motivate others to become Agents of Change.
    I hope that my comments help.  If you would like to discuss this further, you can reach me at [email protected] .  NOTE:  I am not a consultant, just a practitioner so I am not trying to sell my services to you.
     
    Jim Johnson
     

    0
    #70799

    Mike Carnell
    Participant

    The resistance to change was from Mike not Tom. Thank you.
     I am practionioner which is what qualifies me to be a consultant.
    I have not asked her to buy anything.
    She is also welcome to contact me at [email protected]. I do not charge for that either.

    0
    #70825

    Mike Carnell
    Participant

    Carol,
    There was a piece I meant to address very specifically (still at no charge and no offer to sell you anything). When we began a lot of the programs which were the front runners to the SS stuff you see right now, the “Zero Defect” stuff was very popular. It sprung from the “Quality is Free” dogma.
    If you get Waltons book on Deming, Chapter 14, page 76, mentions these programs by name and how completely worthless they are. There is a slide in the old Six Sigma International material which states that Six Sigma is not a spectators sport. Greg Brue and I put this in to specifically address this issue of managers who like to sit on the sidelines, shake their pom poms and holler “Zero Defects” and “do it right the first time.” We had a bunch of these that we had to deal with. The Zero Defects” stuff was perfect for them. They bought posters and floor mats and when defects occured they looked at their boss and said “I did my part I bought the right stuff. It was those hourly people who did it. They aren’t motivated.” It was easy for them. SS doesn’t let them sit around and cheerlead. They are champions, stakeholders, etc.
    In the mid 80’s (the year the shuttle blew up) I worked at a Motorola Government facility making bomb fuses. It is the same program that Mario Perez-Wilson talks about in his book. There was a group of us that worked together; Mario, Adi Bhote(Keki’s son), Jim Blanden, Michelle Johnson, Kathy Campos, and me. A lot of the work that became the foundation for Mario’s original book “Machine Process Capability” was done at that time. We won a quality award from the Navy and 2 CEO Quality Awards. We took a lot of crap from the old guard “quality” guru’s but we did what we believed was right and it worked out. Mikal Harry was running in parallel across the parking lot at a sister division.
    The point to this was that there was a floor mat at the entrance to the factory that said “Do it right the first time.” It used ti piss me off to see that thing there every morning. Think about it. A prson installing detonators in bomb fuses. Why wouldn’t they want to do it right?
    The zero defect stuff never produced a zero defect product for any sustainable amount of time that I am aware of. Point 11 in the Deming stuff is “Eliminate numerical quotas.” Zero defects is really just a numerical quota with no methodology attached to it. Another management placebo.
    Please indulge me on another story. This is about a guy who had trouble separating his life from the work. I mentioned Jim Blanden with the original FMU 139 group. Jim was a true bohemian. He had 300 college credits and no degree. He understood quality tools and philosophy at a level that most of us couldn’t even come close to understanding. As he got involved witht he Quality program (not called SS then) he became so focused on eliminating defects we couldn’t deal with the Motorola stuff any more. To slow or whatever – it was a Government plant – things move slowly. He left and started his own business rebuilding hard drives. Heas written up in a magazine within months for his excellent work. He disappeared. Couldn’t satisfy his own vision. Last I heard he is living in the desert and supported himself carving butterfies from Ironwood trees (the wood is really hard – Jim would never do it the easy way). The point is Jim had a vision that most of us really could not appreciate. You need to take this stuff seriously but moderate it with the constraints that are imposed on you by the system you operate in. That doesn’t mean the constraints can’t be streatched or pushed but not at the cost of your own sanity.
    Good luck. No charge.
    Regards,
    Mike

    0
    #70831

    Carol Trimmy
    Participant

    Thank you all very much for your thoughtful replies to my question. I really appreciate your responses, especially the ones that contain additional thoughts on how to explain the myths. It significantly helps me with my workplan.
    I really appreciate that consultants, corporate employees, and quality professionals (most of which overlap!) can join together on this forum for the benefit of the quality profession. I realize that no one is charging for their answers — thank you to everyone that responded.
    Happy Holidays,Carol

    0
    #70839

    Mike Carnell
    Participant

    Carol,
    The no charge comment was not intended for you. It was intended to remind people like Jim J. That there a lot of consultants that participate in this thing because it can be fun. We do not necessarily do it looking for business since most of the people on the site do not have signature authority for enough money to contract a Wave of training let alone a deployment.
    We have been practicing for years. Because someone has not moved to consulting or because they have they do not occupy a higher or lower place in the evolutionary chain.
    There is a distribution around consultants and practioners alike. As a company I have offered a 200% ROI for years (for every dollar a customer spends with me I will return two), I have also offered shared savings (no charge – have one in progress now) and have made a six figure bet on results (can be verified in a contract) and have never lost. We have pulled the clients we have pulled because we produce results.
    If Mr. Johnson feels he is such a righteous practioner, put your money where your mouth is. Go back to work, find your boss and guarantee him you will save him double your salary or you will refund every dollar he has paid you this year.
    I apologize for using your question to engage this topic.
    Good luck on your deployment.

    0
    #70850

    Jim Johnson
    Participant

    Mike, first let me apologize for not recognizing you by name….my mistake.  I was not trying to insinuate in any way that your practicing of Six Sigma is lessened by the fact that you are a consultant.  What I was trying to say was that I wasn’t trying to sell my services…I was offering them freely.
    I apologize if you took my comment the wrong way.
    Jim Johnson

    0
    #70851

    Jim Johnson
    Participant

    Mike, I am going to apologize to you once more for the comment that I made.  I in no way was trying to imply that you were not here as we all are to help proliferate Six Sigma and to gain knowledge our selves.  You have obviously had a very successful consulting practice for some time and I commend you on that.  Now, to your point of the return that my company garnered from their investment in me:
    I have completed three projects since starting my own quest in Six Sigma.  The first one saved my company 995,000 (USD); the second resulted in savings of 1,300,000 (USD) and the third resulted in savings of 330,000 (USD) on an annualized on-going basis.  While I obviously don’t have the years of experience you have, I believe that my company will make a clear statement that I put my “mouth where the money is” everyday.  Otherwise, I wouldn’t still be employed.
    Having said that, my statement conerning consultants was not intended as a “slam” to anyone.  It is obvious that consultants make their living through contracts and one way (not the only way) of marketing yourself is through this kind of forum.  People like me and Carol benefit daily from the information that more experienced practitioners like youself provide and I thank you for it.  The primary reason that I made the statement that I did was because I was recommending a book to Carol that was written by a consultant and I did not want her thinking that I was trying to “sell” anything to her (namely the book).
    I hope that this response puts an end to this little episode.  I believe that consultants are the life blood for every organization that has ever implemented Six Sigma and I have learned a great deal and continue to learn a great deal from them.  Thanks for the opportunity to clear the air.
    Jim Johnson

    0
    #70868

    Mike Carnell
    Participant

    Jim,
    You are correct I should have let this thing go a long time ago. Please accept my apology as well.
    If you want to see a person who is willing to put their money where there mouth is (not meant as reflection on your comment) go to Greg Brue’s website http://www.SixSigmaCo.com and look at his new “test drive” program.
    The consulting industry has proliferated and now has become refuge point for a lot of big name firms trying to maintain revenues after they saved us all from Y2K. When you get an offer like Greg’s it is a practitioner who belives in their product not a “me too” company.
    Like you said we all have a role to play.
    Good Luck.

    0
    #70944

    Simple
    Member

    Sixsigma is an application or different form OR techniques. It is bit tough to blend to software processes.

    0
    #70945

    Hemanth
    Participant

    Carol,
    While 6- Sigma is an awesome tool, when used properly…remember it is not the only thing.
    Nokia, the worlds biggest cell phone manufacturer did not care about 6-Sigma while Motorola did. Nokia is still a leader bcoz, they have understood that the customer needs different models not 6-Sigma while Motorola stuck to 6-Sigma. As long as your Customers are happy, as Metallica said “Nothing else matters”.
    No offence to anyone here from either of the origanizations.
     

    0
    #70946

    Hemanth
    Participant

    Sorry, Dont agree that Six Sigma is only for OR practices.
     The 80-20 rule is also in Six Sima.
     
     

    0
    #70949

    Simple
    Member

    I mean the Optimising technique of OR is used in the Sixsigma.

    0
    #70957

    Bob Bodemuller
    Participant

    What I hear here is that six-sigma is “SPC”. We fabricate one-of-a-kind scientific experiments and consequently do not have any volume or on-going production for which classical SPC might be of help. The logic goes something like: “Since we can’t do SPC we can’t do six-sigma”.

    0
    #70958

    jeffrey edwards
    Participant

    Carol,
    I worked with both Motorola and Allied Signal on the design and installation of their original quality improvement initiatives – including their integration of what we today call Six Sigma. Call me to discuss some of their original concepts – they are different – in the most fundamental sense – from what is being promulgated today…
    R/
    Jeffrey Edwards
    Alchemists Intl
    904.276.0067

    0
    #70961

    Kim Niles
    Participant

    Perhaps “most myths are due to resistance to change” but if we were to apply the 80/20 rule to this issue, the biggest myth would be:
     – “Six Sigma” = six sigma
    (i.e. everyone I’ve ever met that is turned off about Six Sigma the philosophy is really just confused that it’s six sigma the mathematical expression). 
    KN 

    0
    #70964

    Tom Black
    Member

    Jeffrey,
    I am interested in your answer on the differences now and then.  Is there anyway to give a short answer on the Forum?
    Tom Black, MBB, ASQ CSSBB

    0
    #70965

    Tom Black
    Member

    Jeffrey,
    I am interested in your answer on the differences now and then.  Is there anyway to give a short answer on the Forum?
    Tom Black, MBB, ASQ CSSBB

    0
    #71065

    Dave Harrold
    Participant

    A myth I’m hearing in the process industries is “Six Sigma isn’t suited for batch processes (i.e., pharmaceticals, food and beverage, etc.). Since Six Sigma’s roots are deep in Motorla’s discrete manufacturing and semi-conductor business, it seems strange to me that people would argue such a myth.
    Does anyone have practical examples and positive results related to applying Six Sigma to batch processing?

    0
    #71077

    Hemanth
    Participant

    Hi Carol,
    I am in the process of preparing a small overview on six-sigma for a group of employees who are being nominated for BB certification. If you have a list of myths I would be greatful if you could mail it to me. My email id is [email protected]
     

    0
    #71079

    Cannizzo
    Participant

    Hi Hemanth,
    I haven’t put together my list of myths yet. When I do, however, I’ll be sure to post it to this forum. I think I’ve seen someone else do it – I’ll contact iSixSigma to see if they’ll help me out with this. I’m sure they will.
    Carol

    0
    #115907

    Sanil Mathews
    Member

    ……….Six Sigma means reduction in Variation
    ……………..Less Variation means Consistent Process
    ……………Consistent process means no defects
    ………………..No defects means no loss in money
    …………………..No Loss in money is Purely “Business Profits”
    Six sigma is Power to Profits…

    0
    #115908

    RK
    Member

    Quote……………..Less Variation means Consistent Process
    ……………Consistent process means no defects
    Really?.. I wonder…
     
     
     

    0
    #115912

    Mike Carnell
    Participant

    RK,
    The answer is no. Less variation does not mean no defects. I can reduce variation on a process that is outside the specification limits and be 100% defective. I will just have less variety in my 100% defects.
    Good luck

    0
    #118012

    Anil Kumar dwivedi
    Participant

    Hi Everyone,
    The myths of Six Sigma would be like, some facts which people think are true but actually they are not that way.
    Six Sigma is not for software industries,
    Six Sigma need you to be a good statistician to practice it.
    But these are not true !
    If you have encountered such situations, please revert back.
    Anil Kumar Dwivedi

    0
    #118014

    Mikel
    Member

    Thanks for straightening that out. Consider me reverted back.
    Please give me an example of how you use Six Sigma in Software.

    0
    #118016

    Anil Kumar dwivedi
    Participant

    Hi Stan,
    Six Sigma can be applied to any industry.  FOr a software industry, it’s even simpler.
    Take the example of the project history of an organization.  Compared to the timelines given by the clients, the projecty closure take about 120% of the time allocated.
    Now this becomes  the pain area and we can take up a DMAIC project.
    Where you can measure things, generated data, Six Sigma can be applied.
    I think, I answered your querry.
    Anil Kumar Dwivedi

    0
    #118017

    Anonymous
    Guest

    Anil,
    The only people who believe that six sigma can be applied to software developement are those who either know nothing about six sigma, or those who have never written any software.
    Software development is not the same as manufacturing replication –  each software program is unique, so there is no such thing as a ‘natural process capability.’
    The best quality engineers in the world tried it for eight year – Japanese quality engineers — and without success.!
    Regards,
    Andy

    0
    #118018

    Dayton
    Member

    Andy,
     
    Interesting comments.   Have you been involved in software development?   I have been.  Variance is at play in many aspects of the field.  Have you ever used software release metrics?   As in number of hours of test applied against number of bug found?    Optimization of the collection and use of those metrics could save a great deal of time and money.   How about the development of stress and diagnostics tests?    Methodology optimization for automated code coverage review which could be as simple as comparative runs of versions on a compiler.  When and how do you use systems test, unit test, functional test, white/black box test, etc.  There is a lot more to the software development process than writing code.   I’d have to believe that Six Sigma analytics could certainly apply to the software development process just as it could to other processes.   You seemed to have picked one element, granted an important element, that of writing code and said – see you can’t do it.  
     Vinny

    0
    #118021

    Anonymous
    Guest

    Vinny,
    My comments were only directed to writing code and I agree with most of your comments, except to the notion of a software ‘bug.’
    To answer your question, yes, I have worked on a number of software projects, as a code writer, but not using a ‘professional’ language – only VB. (I did try C, C++, and MFC for a while because I was attracted to the notion of re-usable ‘components.’ As I’m you are aware there are also many advantages to using encapsulation, but these languages- although they allow for greater flexibility -seem to suffer low productivity: at least in my hands anyway!)
    This is why I disagree with the notion that a ‘bug’ is an error. Most bugs can’t be anticipated, so I believe it is important to distinguish between bugs and errors.
    As for the previous post, in my experience there are two main causes of delay. The fist is the phenomenon of ‘specification creep’ and the second is autocratic management. The latter of course refers to the kind of leadership that forgets to ask the development team how long it is going to take, or even after listening still define a shorter target date anyway. Perhaps this is an example of where six sigma can be applied because its a bit like a process engineer telling a designer what the process capability is then promptly ignored!
    While this is the perogative of management; it doesn’t follow that the project will finish on time unless more resources are found.
    While there are  many who teach to the contrary, I believe it is only to make money; but I do not count you in this category because you seem happy to provide specific examples. I am happy to concede that testing is one such example, but I do not agree when it is applied to software design. (Of course that’s only my opinion!)
    Regards,
    Andy

    0
    #118026

    Dayton
    Member

    Andy,
     
    Better understanding now what you were saying, I am in agreement with you, especially about the impacts of specification creep and autocratic (but mostly those that were technically deficient, autocratic technocrats didn’t bother me as much) management.
     
    Regarding the software “bug” you make a good point.  Too often error and unanticipated artifact are commingled in the “bug” descriptor.   Both however point to the necessity of a well-developed test process, which both confirms expectations and applies stress and diagnostic tests to bang away at the code looking for unexpected negative impact – regardless of why it exists.   
     
    You are well aware that it is dangerous to think of even small software changes as completely benign, especially when dealing with legacy code.  It is very possible and a none too infrequent occurrence to see small seemingly benign changes open trap doors in your code that can be both surprising and harmful if found in the field.   Hence the beat it to death before it goes out approach of stress and diagnostics tests run in conjunction with performance tests which test against anticipated functionality.   Error or unanticipated artifact either one can be a problem, but so can testing ad infinitum – that’s where the release metrics come in at looking for an acceptable hours of testing/anomalies found ratio along with severity of anomalies found.   
     
    My own code writing was unimpressive and boring but I enjoyed the software development process as a whole and enjoyed troubleshooting the process as we moved forward on strategic projects.   Some cool stuff. 
     Vinny

    0
    #118027

    Ron Pointer
    Member

    Well that is just another bug in six sigma, which is a doctrine cooked up to make people in management participate, in a structured project environment.  Never mind that you will probably solve the problems for the green belt, what matters is that he will get the money and the credit, and the managers will look good because they took care of a problem using six sigma.

    0
    #118028

    Solo
    Member

    Dave,
     
    Six Sigma is process based.  The process being continuous or batch is irrelevant.
     
    Batch processes have inputs and outputs the same as continuous processes.  Control of the input will apply a control on the output, just as in a continuous process.
     
    It could actually be easier to control a batch process over a continuous one.  For instance, in a chemical world formulation based batch process, inputs could be in the form of mass of additions, where as in a continuous process that input would be in a rate of addition.  Adding 2000 lbs of a material all at once is easier to control than adding material at 1 lb/min for 2000 minutes (consider the introduction of pump variability).
     
    Another advantage is that DOE can be run in the lab on a small scale, before being full scale trialed in the plant and tying up valuable equipment.
     
    I had the same concern when I began my training, so I will tell you what my sensei told me…  “A process is a process is a process…”
     
    -Solo

    0
    #118030

    Peppe
    Participant

    Vinny, if you give a look to SEI site about CMMI, of course you’ll find many withe papers on how to apply sixisigma to sw development, but they are mainly from project management point of view, than “writing program” point of view. Of course you can obeseve than a strong sixsigma project can take care of all the errors (or bugs) and with right corrective action you can prevent it and so on, but I believe they are just “quality activities”. Furthermore, could you give me an example on how you apply the basic formula of sixsigma y=f(x) to software development (new software) ?
    Rgs, Peppe
     

    0
    #118031

    Ron Pointer
    Member

    By the way if you ever get into the family plan for xilinx or tmobil or verizon, you will discover that inspection has not been totally elliminated from the motorola production method, because you will get to reject 2 out of six cell phones for either internal charge defects, or defective battery.  So you are doing the inspection for them.
    Before they were six sigma.  Somehow they adopted lean six-sigma, and now it seems they are only lean.

    0
    #118032

    Anonymous
    Guest

    Vinny,
    I couldn’t agree with you more …
    Let’s broaden this is little further as I believe it contains some important principles. I think we both agree that one of the reasons why we need to test software code is because programming doesn’t have a ‘natural process capability.’ This raises the spectre of other processes that also don’t have a ‘natural process capability, such an legal prosecution – even though this seems to fly in the face of the principle of precedence.
    More interesting are manufacturing processes that do not have a ‘natural process capability’  – because the process has to be pushed up against a physical boundary, in order to compete in the world’s markets. Therefore, these processes have to be tested. But why test at the end of the development, why not after each stage? This seems to suggest the Japanese concept of  ‘process self-assurance,’ which if I may suggest is the principle behind Toyota’s one-by-one confirmation, or Lean.
    In conclusion, it would appear that Lean (TPS) and Six Sigma are complementary in the sense that they are at opposite ends of the spectrum, and therefore cannot be combined without considerable efforts towards ‘harmonisation.’
    Best wishes,
    Andy

    0
    #118034

    BTDT
    Participant

    Anil:We are supporting a Senior VP of Software Development. His favourite quote is, “There is nothing more useless than a program that nearly works.” The gage R&R in this field is centered around the operational definition of a bug. Think of all the developers who say, “That’s a feature, not a bug,” before you define the defect level.There are a host of circumstances that contribute to a complex problem.Our SS projects in software development are:- quantititive risk assessment for managing software releases.- design of an efficient and robust product testing process in conjunction with the above.- requirements management and triage for project management with feature and schedule risk.- requirements mapping (VOC and VOB) for a skunkworks project.The business language of SS allows us to communication with the executive and managements by translating the ‘art’ of program development to the language of money.Six Sigma in software development just requires a bit of flexibility in thinking.
    Just some free advice from someone who has…
    …Been There, Done That

    0
    #118038

    Dayton
    Member

    Andy,
     
    Some good thoughts are surfacing, in particular the phenomena of working at the boundaries of process capability/science/technology/etc., and the impact that has on process improvement and overall process management approaches.   The push to those fringes of control and comprehension, whether you call it chaos, complexity or Chaordic principals is where you find the new opportunities and advances – but it’s also where you need the best and the brightest and can’t take your eye off the ball.  
     
    When I read:
     
    In conclusion, it would appear that Lean (TPS) and Six Sigma are complementary in the sense that they are at opposite ends of the spectrum, and therefore cannot be combined without considerable efforts towards ‘harmonisation.’
     
    I thought immediately (although you have that cross-ponder spelling of harmonization) about the different yet complimentary approaches taken in performing a Hazard Analysis and a FMEA/FMECA with one being a top-down approach and the other being a bottom-up approach yet both being important aspects of product or process risk analysis.  They are different yet additively or synergistically beneficial when both are used and harmonized – and as you said oftentimes done only with considerable effort.
     Vinny

    0
    #118040

    Dayton
    Member

    Peppe,
    Better than my making up a Six Sigma in software development scenario, try looking in the isixsigma software web page for the Six Sigma Software Development Case Study by Gary Gack.  He did a good job of describing an appropriate and I believe effective use of the tools – and along the lines of what I was trying to explain.
    http://software.isixsigma.com/library/content/c030528a.asp
     
    Vinny

    0
    #118043

    Anonymous
    Guest

    Vinny,
    I meant complementary in the sense that a combination of both principles would imply a contradiction, and my use of the term harmonization was in the oriental sense.
    I agree that risk assessment and FMEA are complimentary.
    If I have time, I shall read the article you referenced on isixisigma in more detail, but I have some reservations about this approach, and the reason is that project management is not unique to Six Sigma, nor is management by facts, or the application of quality technology, as mentioned by Peppe. It seems to me that always trying to ‘fit’ a foot into a six sigma shoe with ‘half-sizes,’ or even whole sizes these days, is not always the best approach. More specifically, I think there are better software development paradigms. Thanks for the exchange!
    Best regards,
    Andy
     

    0
    #118047

    Dayton
    Member

    Andy,
     
    I use complimentary in terms of mathematics in which two unique entities can combine to form a whole – as in a compliment to an angle is that other angle that will in combination with the first complete a right angle or the 100’s compliment of 80 is 20.   No combinatorial contradiction implied. 
     
    By oriental sense of harmonization do you mean one of those ivory carvings of Yin and Yang?
     
    I agree that fundamental project/program management tools are appropriate for software development as long as you have all of the necessary process steps, subject matter expertise, and developmental tools in place.   I was responding to the statement that Six Sigma did not have a place in the process – I was trying to say that it can have situationally appropriate applications if you have variance in your software development process and desired to identify and remove causal factors.   Thanks for the exchange and well thought out input.
     
    Vinny

    0
    #118050

    Anonymous
    Guest

    Vinny,
    Just as a final clarification, by ‘oriental sense’ I meant the so-called Buddha logic. I thought that as a mathematician and operations research guy you might appreciate the technical term :-)
    Cheers,
    Andy

    0
    #118051

    Dayton
    Member

    Andy,
    Great response(s).  Thanks, you helped make an otherwise bland day positive and engaging.
    Vinny

    0
Viewing 48 posts - 1 through 48 (of 48 total)

The forum ‘General’ is closed to new topics and replies.