I’d like to open a debate on what are the current trends that effect the way current validation is going.
What slows up a validation project?
Some of my key concerns are the following
Risk Analysis insufficient
Software Validation performed by people that don’t understand software
Lack of Regulatory understanding
Poor Project Management and ownership skill
Lets validation the entire the system because I don’t understand it enough to apply a risk based approach
Basically what makes a successful validation project?
As a contractor, we continue to get clients that establish really poor requirements. Such requirements make validation very difficult, if not impossible in some cases.
Immature software also greatly slows validation efforts. Things changing out from under the validation base potentially require a restart. Not knowing what the configuration is (features implemented, features changed, etc.) can cause the validation effort to go down wrong paths.
Validations performed by people that don’t understand validation.
Starting the validation project too late in the software development/implementation process.
Valiation thought as something completely extraneous to development/implementation
Lack of process owner involvement and/or interest
A good validation project (as far as I’m concerened) is one which form the offset ignores compliance, quality and validation. It instead concentrates on real needs of the users from both a business and functionality standpoint.
A good validation guy can then :
Build in the quality
Make it complaint
Deliver it pragmatically and efficiently
I’ve seen the most compliant systems the world has to offer - except that they don’t meet the needs of the user or just simply don’t work - those are my bad.
In over 25 years of validation I’ve seen only a few people get the balance right.
A good validation or bad validation depends upon how efficient is your validation exercise in facing the regulatory audits. Base your validation activity in two dimesions. One to assure your system suitable for use, secondly to convince the regulatory auditor with sufficient documentation which acts as the proof or work. Because regualtion is procedure and documentation driven. Many companies have failed in documentation despite a vigorous validation testing. Validation should always be viewed from the regulatory standpoint instead of viewing from testing standpoint. Testing is part of validation. It goes beyond testing. In many cases validation is handled by the testing team which makes the whole process inefficient.
Do’s and Don’ts of Validations:
1.Understand your system thorougly
2. Apply risk assessment techniques with an intention to reduce the validation effort and cost focusing on critical requirement
3. Conduct mock audits for the system from Regulatory perspective
4. Make a checklist of documentation requiremet as per regulation
Don’ts:
Do not rely completely on the vendor scripts for validations
Do not test the system simply for the sake of auditors
Do not forget to capture screen shots for proving steps in test cases
Do not fail to furnish suffiecient documentaton for your system during audits