Validation and a consistent approach to projects seem to be something that is alien to a lot of companies.

We all know about the traditional approach including URS,FS,DS,FDS,TM,IQ, etc etc and with the advent of the QbD (Quality by Design) approach there seems to be even more acronyms to get your head around when performing validation projects.

Some companies are good at taking the validation lifecycle seriously while others are not so good. This could be down to the fact that people in organisations still don’t really understand what a validation lifecycle is, and how it is extremely important to the overall success of a project.

Do some of the following comments sound familiar?

• We don’t have a URS but we know what to test;
• Let’s combine the URS and the FDS, there are the same thing;
• Why do we need to perform validation when the system has been running for 6 years!;
• Let’s do the Trace Matrix at the end when we have time;
• Let’s forget about the Trace Matrix, it takes too long and we don’t have the time;
• We don’t have time for a dry run, everything will be fine;
• Let’s go straight into IQ/OQ;
• Let’s create 50 documents for this, so that the auditors will think that we have done a great job!;
• That’s not a deviation, because John said so, refer to the ambiguous procedure that says so;

Perhaps following a full validation lifecycle is not the best approach for some projects, but I would imagine that at a minimum, having clear requirements and testing these requirements would be a good starting point.

We would like to hear your opinions on how you perform your validation projects.

Do you have a standard document set you follow for each project?

If you don’t have you got your own in-house methodology?

Please leave your opinions in the comments box below.