iSixSigma

To Sigma or Not To Sigma

Six Sigma – iSixSigma Forums Old Forums General To Sigma or Not To Sigma

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #34027

    MLT
    Participant

    Last year I read an article in a Six Sigma journal that detailed projects that did not lend themselves to the sigma method. Does anyone have that list or a list of their own? I’m not talking about sigma mistakes – just situations in which sigma just doesn’t work well.

    0
    #93288

    John J. McDonough
    Participant

    As a long time cult member, my knee-jerk reaction is to say, “any project not worth doing” is a good candidate to not use Six Sigma for.
    But I can think of a couple of cases.  One of the DMAIC steps is to fix the obvious.  Now one needs to be cautious that just because it’s obvious doesn’t mean it’s so.  But if you get a flat, you probably don’t need a Six Sigma project to figure out that you should change the tire.
    The other case is in a 2-n implementation.  Let’s say I ran a DFSS to design a new burger shack.  I ran another DFSS to figure out where to deploy these burger shacks.  After I’ve built a few of them, there is probably little to learn from building the 10th or 100th one.
    –McD
     

    0
    #93466

    Dean Bottorff
    Participant

    I can think of 2 cases where 6s may not be the proper approach. One is if the underlying objective is patently illogical or unethical. Just because something is desired does not make it a worthy undertaking. Second, non-repetitive events, or events which merely demand execution, not improvement (such as the flat tire example), where little or no data is available, and only immediate and obvious action is required.

    0
    #93487

    Mike Carnell
    Participant

    Dean,
    It is difficult to argue with your first point on illogical or unethical. Actually I would think that would be a great indicator that it was time to leave.
    The non-repetative events I don’t completely buy into although the flat tire is a good example of what I would consider a non-six sigma project (when it becomes repetative it does qualify and we have that project in progress right now).
    Where I have an issue is when people excuse themselves from a structured improvement process whether it is SS, Lean, TQM, etc. because they are low volume/prototype products. The issue comes from the focus on the product versus the process. My initial work was around a wave solder process that was a high mix but the part numbers were short runs. The product (by part number) was a low volume but the wave solder machine ran all day. We learned to stratify product by characteristics and the relationship of the machine to those characteristics.
    I’m not dis agreeing with the assertion of non-repetitive just want people to understand you don’t need volume product to run the project. When I see the “new” approach to SS for low volume it is intersting since that was where a lot of this started – low volume.
    Good luck.

    0
    #93488

    Dean Bottorff
    Participant

    Mike,
    I believe there is an important distinction between “non repitive” and “low volume.” Low volume is often repetitive, just in a low volume degree. When an instance is purely a one shot deal, with no evidence of repetiveness whatsoever, 6s tools may not be the best tool kit to address this scenario. Also, acting immediately on an emperitive (say a one shot event) may be the best form of prevention, that is, preventing worse outcomes, such as preventing ruining the rims of your wheels because you did not change the flat tire fast enough. There is a time to act now, and a time to plan and improve. Prevention needs both.
    Thanks for the input.
     

    0
    #93491

    MelissaI
    Participant

    I’m a new Black Belt (finalizing my first project) and I’m going through a process right now of working with a potential Project Champion to identify new projects.  There’s a struggle to not, on the one hand, charter ‘obvious’ fix areas and on the other hand, to no ‘boil the ocean’ from a scoping perspective.  For example, one problem the process area is experiencing is a high level of mismatch of a quote to an invoice.  The result is increased credit and rebill transactions, lowered GP and decreased customer satisfaction.  They ‘know’ that one real problem (as reported by the operators accepting orders) is that accessing the most recent quote in the system is extremely difficult.  The solution is to submit a request for a system change to make the quote more accessible.  I’m struggling with truly relying on their judgement that the root causes are ‘obvious.’ When is a fix obvious?  On the other hand, they are not able to identify any other major inputs to the process that may be causing the problem that they have not already put a fix in place for (rep training and non-standard pricing agreements have been addressed recently).   Is it worth it to go through a project that the process owners have a strong feeling what the solution is (or at least one that would fix a large percentage of the issues, from their perspective)? 
     

    0
    #93492

    Mike Carnell
    Participant

    Dean,
    My concern is that people cofuse the two. I hate to bring up the Motorola Iridium deal because as a business venture it didn’t fair well. Motorola had been in the satellite business for years and everything was “unique.” All of a sudden there was this project that required 60+ (I don’t remember the exact number I think it ended up being less than the Atomic Number for Irridium) satellites. Things change quickly.
    Thanks.
    Good luck.

    0
    #93497

    bwjones
    Participant

    Regarding project selection – I work with customers who employ the Value Stream Map approach to identifying SS projects and/or verify a perceived solution is the most appropriate one.  A good VSM (void of empire protectors) can possibly ID several SS projects.
    Also, one of my lessons learned, is the urge by process owners / management to skip D, M & A and jump straight into I of the DMAIC process. Because of the mentality “we just know” the solution.  Sounds like the approach with the quote process.
    If the strategy is to use SS to solve the obvious / low hanging fruit / pet peeve problems.  Then you are missing the benefits from a sound Lean/Six Sigma implementation. (I am starting to detest the term “project”).
    Drive On …
     

    0
    #93500

    Kim Niles
    Participant

    Dear MLT:
    Improving anything costs money or other resources and therefore should take place in accordance with need.  There is a spectrum of different types of effort that might be required from individual task levels to full time sequestered team based efforts.  Six Sigma projects are somewhere in between. 
     
    Each level of effort has an appropriate use depending upon who is concerned and by how severe the concern or expectation for success is.  Examples include individual efforts, department to do lists or ticket based systems, working group efforts (low priority improvement teams), task forces (high priority teams), Six Sigma projects (some full time some not over a several month project), Kaizen Blitzes, or Events (full time sequestered but only for a couple days).
     
    I hope this helps provide general areas where Six Sigma projects apply and or don’t apply. 
     
    Sincerely,
    KN – http://www.KimNiles.com – https://www.isixsigma.com/library/bio/kniles.asp
     

    0
    #93502

    John J. McDonough
    Participant

    I think Dean is touching on an issue that can sometimes be a problem, not only with Six Sigma, but with any methodology.
    Six Sigma does not require that you leave your common sense at the door.  No matter what you do, you want to apply good judgement.  MBBs are always telling their Black Belts “follow the data”.  But sometimes there isn’t enough data, or the data isn’t very compelling.  Until we can get more data, we need to apply common sense.  Even if we have data, and the data challenges common sense, we ought to scrutinize the data.
    The real challenge is that, as we run more and more projects, we discover that these obvious fixes often aren’t really the problem.  The tough part is sorting out what is really a quick fix and what isn’t.
    I would suggest that you look for folks who may have some vested interest in a particular solution.  You need to weigh their input accordingly.  Sometimes the vested interest may be nothing more than “I’ve been telling you that for years”.  In those cases, the Six Sigma project becomes an opportunity to prove them right.  Keep in mind that few people value anything more highly than their ego.  If they are right, give them credit for it, even if you needed to do some investigation to prove it.  It they are wrong, try to frame the other approach in a way that doesn’t challenge them.
    The other thing to look at is problems you’ve solved before.  Many times the solution has already been tested, but without DMAIC there is no ‘C’, and entropy takes over.  In deciding to make a quick fix, weigh the risk of not having an appropriately considered control plan.
    –McD
     

    0
    #93565

    DaveG
    Participant

    Melissa,
    bwjones’ response is a good one, but consider this:  most people in a “floor-level” environment are extremely in tune with the inputs and outputs of their work and how well it flows.  Therefore if they say recent quotes are a constraint, in their view it is:  they are comparing their actual experience to what they perceive the ideal to be.  If their mental ideal does not add value, or they consistently raise issues that management perceives as low priority, it suggests that management has not given them the correct paradigm.  You need to strike a balance between accepting people’s conclusions and “digging deeper”.  I usually say “I understand your point and we’ll consider that, but I/we need to dig deeper”, then you develop an action plan where they are actioned or kept in the loop for progress.
    I think that giving workers “goodies” in the form of processes that don’t present roadblocks is a significant investment in morale that yields a multiple ROI.  They want to be seen as productive.  As you do more projects, you should budget for these things.  If you can inexpensively fix the quote problem, you’ll gain some instant allies.  Even if it is somewhat expensive or time-consuming, do it anyway.  ****ing on workers is a guarantee for failure.

    0
    #93574

    Hemanth
    Participant

    Hi
    It seems you are currently selecting your first project. I couldnt go through all the posts, so there might be repetations.
    First thing which you need to do is make a matrix with each project recieving ratings for savings, effort and probability of success. Now when rating probability of success look for that does the champion / process owner have a solution in mind and are they confident that it would work. If the answer is yes then cut off that project. Once you have the rating for all the opportunities then you can pick one’s with higher ratings.
    Some of the pitfalls while selecting projects:
    1. “Just Do it” projects
    2. Not directly linked to champions / process owners KRA (feel good projects, that are not strategically important nor improve external customer satisfaction)
    3. Success dependent on too many future developments (project with a supplier who may or may not be continued, labor union issues etc).
    4. Project on a process which is not followed or established (process / product that is still in a develpmental stage)
    5. Does not require characterisation and optimisation route (Just needs few people to sit together and think, in such cases the six sigma worker’s contribution is greatly reduced).
    6. This one’s a desirable criteria “the process must be in team’s control” You may not be able to improve something at customer end if your customer is not part of the project.
    These are based on my personal experience, others may have additional checks. Hope this was helpful.
    Hemanth

    0
    #93576

    Arend
    Participant

    You already got a lot of good replies on your question, but from my own experience I would like to add one more: 6Sigma doesn’t work well if the rest of the ‘world’ doesn’t understand the approach you use. I think that especially management understanding and support for 6Sigma is essential. The last part of a project is usually the hardest to complete in such cases. Once the solution comes in sight, it takes much discipline to continue with structural working and closing off with a completed control phase. In non-6Sigma environments you’ll run a big risk that the support for your work quickly diminishes after finding and improvement, sometimes even before verifying it. There are many other risks, but I think this is a major one.kind regards,
    ArendArend

    0
    #93577

    Alan Passmore
    Participant

    In the words of the famous advertising slogan, Just Do It!
    It looks as though the staff who work with the system every day have told you what the answer is. Why not listen to them?
    Firstly, of course, you’ve got to analyse the costs of changing the system and the benefits that you expect to reap.  Mmm… sounds like a ‘cost/benefit analysis’ – the sort of thing that managers have been doing for hundreds of years!
    If there is still thought to be further scope for improvement, you can review the situation.

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

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