Cause Analysis for Verification/Validation Failures - Seeking Opinions

Chennaiite

Never-say-die
Trusted Information Resource
Deeper cause analysis during verification/validation phase can many times get into research mode. While the learning out of such analysis will help in future projects, the flip side is that it delays the Start of Production of the project under development. Therefore we are facing the need to give up analysis at some point and take corrective actions accordingly. I am interested to know how this situation is managed generally?

For Example, lets say a Brake liner is not meeting the target life during vehicle level validation. Typically the DFMEA of the liner addresses some potential causes for this failure mode - liner not meeting target life. Preliminary analysis will zero in on one of the causes, example lets say grade of the liner material. Now one option is to stop the analysis here and take actions to upgrade the liner and revalidate. The other option is to further drill down and understand as to what characteristics of the particular grade of liner is not acceptable, etc. The analysis sometimes become even more complicated when the same grade meets required life in a different application. Drilling down further sure helps in enhancing the Design capability of the Organization, but then usually project timelines do not allow the team to do that and hence more often they are merely documented as Things gone wrong at the end of the project. What are your views on this?
 

TWA - not the airline

Trusted Information Resource
Re: Cause analysis for Verification/Validation failures - seeking views

For me this is simple (though I'm well aware of the fact, that life in this world is anything but simple...): A failed validation results an a CAPA and for that there is a system/procedure you follow to determine your root cause and define your corrective and preventive actions.
The issues you described are the same for any quality problem that needs a CAPA to resolve: the more time/ressources you invest, the more you'll know in the end about that issue and the better your CA will be and the more good PAs you'll implement that prevent problems in the future but the flip side is that your hands are tied while this process is ongoing...

Options you have are the same as for any quality problem: Differentiate between safety/function related issues which need to be corrected immediately and anything else, for which it is a bussiness decision to decide how much you want to invest to get rid of it and how this is prioritized.
 

Chennaiite

Never-say-die
Trusted Information Resource
Verification/Validation problems in my opinion are little tricky. The difference is, in case of production, problems are failures of a proven and established idea. Stray cases notwithstanding, the analysis in such cases will generally revolve around what went wrong against the established standard. Whereas, the fact that verification/validation are performed to prove an idea, when faced with problems, it takes to generate new ideas sometimes. I am not saying this happens everytime when problem happens, but good number of times to ignore.
 

TWA - not the airline

Trusted Information Resource
I understand your reasoning. In my system the cause of such failures is already determined in the NCR phase, like typically "production did not follow SOPs", faulty components that were used because they were not found during incoming QC etc. Only the tricky ones become CAPAs...
 
Top Bottom