iSixSigma

Root cause identification in 6 sigma project

Six Sigma – iSixSigma Forums Old Forums General Root cause identification in 6 sigma project

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #51891

    Prabhu shankar
    Participant

    Hi
     In a 6 sigma project, how to conclude whether an identified root cause is a real root cause or some other cause is still available or to be further anlayzed?

    0
    #181560

    Scott
    Member

    Customer issue:  When is a root cause a real root cause and do I stop finding root causes
     
    Conclusion: Keeping identifying root causes and removing the causes until the project objective has been meet.  If you decide to make further improvements beyond the project goal, create a new six sigma project.
                                                                Example
    Set Six Sigma Project Objective: Suppose a test of a specific CTQ output on an electronic devices has a Cpk = 0.5.  Your six sigma project goal is Cpk =>1.0.
    Root Cause Identified: Your team identify a root cause.  The upper test limit, (UTL) was entered incorrectly into the automated test system.  You make the correction, and you measure Cpk.  With the new UTL the Cpk = 0.7.  
    Meeting the Project Objective:  The project objective has not been met.  Clearly, there is another root cause causing such a low Cpk value.  Since the project goals have not been met you need to find another root cause, and make the needed correction.
    Stop: When the project goals have been met the project is completed.

    0
    #181561

    Ashky
    Participant

    you may like to see the combined effect of factors. the best i would suggest you to
    step 1: identify possible factors (use fish bone diagram / failue modes in system / process)
    step 2: analyse vital factors and find root cause (use annova, 2 sample t, chi-sqr test depending upon data type and then 5 Why analysis)
    step 3: collect data on all vital factors & response and coduct Regression. if r-sqr and r-sqr (adj) more than 64% or 80% depending on your sector benchmark, it means the combined effect of selected factors / root cause are sufficient and explain the variation in the system.
    Note : ur vital factors may even be one and if r-sqr value less than 64% you may have missed some vital factor or root cause.
    step 4: implement improvement plan and post that check your process has improved to the level of your pjt tgt / expectations or not.
    If not, then start again from step 1. you may have missed some factor or data collected during regression was not true representation of actual process variation.
    Hope this helps :-D
    Ashky
     

    0
    #181564

    Vallee
    Participant

    Rick,In your example you just fixed the error someone made in entering the UTL. What caused the UTL To get entered incorrectly and why was it not caught until it was too late? This will happen again here or if a system problem somewhere else. HF Chris Vallee

    0
    #181566

    Vallee
    Participant

    Prabhu,First off are you working on a project or a paper? I like to know the agenda behind the question. To be upfront, RCA is the area I work in now. With the agendas out of the way. You can’t stop at the symptom level and apply corrective actions there. While Rick’s post was accurate about meeting the objective of your project, putting a band-aide on the error/symptom level just delays the forthcoming failure that will show up again.Also just because a group agrees on the problem and gets a feel good feeling using some of the tools mentioned in the other post for RCA, does not make it accurate.. you have to have the right people ask the right questions and avoid bias as much as possible. You have to truly understand What happened and that is done by observing… then you can look for the root causes.

    0
    #181646

    Scott
    Member

    HF Chris VAllee,
    Customer Issue:  A permanent corrective action was not provided.
    Comments: You make an excellent point.  I provided the containment action but not a permanent corrective action — for example either a sign-off procedure by another individual to validate the entry or some other procedure is needed to prevent the error from happening again.
    On the other hand, my purpose was to illustrate when you stop looking for more root causes.  Notice that I stopped looking with a Cpk =1.0.  I am sure that you agree when I say, “a process with a Cpk = 1.0 is not a very good process.”
     

    0
    #181649

    Vallee
    Participant

    Rick,I understand that you were setting up the mechanics for when to stop root cause analysis; however, many people do stop at the error level of root cause which is why it is temporarily controlled or contained. In my world containment is a band-aide. Stopping the root cause search at the containment is not smart and allows people to speedily go for the quick fix. Interim corrective actions are fine until the root causes are found.This leads into another issue of projects that are initially signed off because of the containment fix and the gains never materialize. In all honesty the CPK numbers were not an issue to me because I felt that your example stopped at the error level anyway. Setting you objective is a whole other issue.HF Chris Vallee

    0
    #181664

    Severino
    Participant

    Some questions that may help identify the root cause:

    Have I identified the fundamental breakdown of a process or system that created the issue?
    If I turn my “root cause” on does my problem appear?
    If I turn my “root cause” off does my problem go away?
    Do the observed phenomena contradict my root cause?
    The list above is by no means exhaustive, but they have proven very useful to me when solving problems.

    0
    #181669

    Tuguchi
    Member

    I have excellent slides but I will never exchange with anybody because of lack of appreciation,respect and feedback!
    Good Luck

    0
    #181684

    SiggySig
    Member

    Causality is hard to prove unless you try out improvements on the root causes you identified, and see if your process performance improves. If it doesn’t keep looking for root causes. If it does, close the project, but monitor the results and conduct periodic audits to make sure the problem doesn’t come back. If it does, you have to keep looking for root causes.

    0
    #181698

    Tuguchi
    Member

    Just apply 5WHYs!

    0
    #181700

    Scott
    Member

    HF Chris Vallee,
    I agree with you 100%.  Stopping at a containment action (unless the containment and permanent corrective actions are the same) does not prevent the root cause from re-occurring.  Yet, both containment and permanent corrective actions are needed.  The band-aide stops the boat from sinking; giving time to implement a permanent corrective action.  The containment action is particularly important to stop defects from leaking out to the customer – either external or internal customers. 
    Just to keep a bit of continuity between discussions: I made the assumption that the root cause for the wrong upper test limit would be found and fixed.  Given that assumption, the question that I then answered was the following:  Having resolved the root cause of the wrong upper test limit, a necessary step, is the resolution of that root cause sufficient to stop looking for new root causes. 
    One More Point: The results for a root cause search are presented in an 8D reports.  Within that report, I see two other steps that are often dropped:  First is the confirmation of the solution once it is fully implemented into production.  I have seen software, permanent corrective actions, that appeared to work fine but after full implementation a bug was found.  Also, the preventive action step is often dropped.  What a waste for some one else to solve the same problem on a similar product 6 months later. 
    My thanks for making me think deeper.
     

    0
    #181702

    Vallee
    Participant

    Thanks Rick

    0
    #181813

    EK.Prabhu Shankar
    Participant

    Well said Ashky, thanks for your feedback.
     

    0
    #181822

    Obiwan
    Participant

    Rick
    I read your entire exchange with HF and noticed that I still believe that there is one thing missing.  You made no mention of ongoing control of the situation.  A project is not complete just because you were able to establish the goals of the project.  Those goals must continue to be met on an ongoing basis, thus control into the future is equally (I could argue that is is MORE) important than just meeting the goals.
    Otherwise, I substantially agree with you and HF’s string of posts.
    Obiwan

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

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