Root cause identification in 6 sigma project

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.

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

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.”
 

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.

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.

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.
 

Well said Ashky, thanks for your feedback.