before you start filling in the blanks or writing a protocol…remeber to do your Due Diligence. this part of the work is the most ignored of all the processes. what happes here will determine the outcome of this phase in validation and usually takes-up a big chunk of your time with discrepancy reports, deviations etc…
Hi there,
Can you expand a little on this?
Do you mean preparation time extra…
Regards
Sure…yes! Assuming that your company has not entered into a “coup d’etat” of a company or what I like to call “…a validation Trojan Horse”; everything should flow easily as far as data and documentation are concerned. This can only be achieved if your project manager and his support group have laid the groundwork and full cooperation is in the works. Resistance can also play a role when area supervisors and managers do not welcome you with open arms. It takes alot of diplomacy and handshaking to gather the documents necessary and data called for in the completion of IQ’s and the sort. Sometimes training documents are non-existent which merit the design of such a system in coordination with the local staff (Process Owners). By the same token, many SME’s do not fully understand a system in its entirety which hinders the opportunity to learn a system. When manuals and instructions are not available the internet is one of the best and viable source of information on machines, instruments, and equipment. Gather as much as you can to bring your protocol to fruition. It’s not only about a template and the rules and regulations; it’s about footwork, getting out there and doing your Due Diligence!
Nice post and good points, I know exactly what you mean.
I suppose the reason this doesn’t happen all the time is down to
Resources and Time Limits. Some PM’s I have worked with just want to get the job done and are not too concerned witn the Quality of the output if it means taking that bit of extra time for preparation.
My pet hate is when engineers are under time pressure and do not
have the time to perfrom a dry run on the protocols, sure it will take more time but will save alot of heartache later on…
An interesting point about dry runs raised. First off, I firmly believe in them. Indeed, they have always shown to be fruitful (to me) in saving heartache later. I worked with one person that was adamant about retaining the results as original data. I’ve not seen this any where else. Any thoughts from the group?
For the last 2 years I have been compiling notes and anecdotes to help me start a handbook, to sell or give-out, on this subject. So far not enough material for a real publication, but I’m holding on until I get an invite for input to a joint effort…but for now I’ll stick to my main projects.
Incriminating or not; written notes and historical data are as important as any official document and should be conserved…
Is a dry run used to test the protocol or the system?
I agree it can eliminate a lot of issues, but does that result in a ‘suspiciously clean’ set of test results? It’s one of those oddities that I’ve seen, where system owners/ validation managers almost prefer to see one or two issues raised to ‘prove’ that the test was actually executed.
It is very rare that you will have a totally clean execution even if you have performed a dry run (depending on the complexity of the protocol).
The purpose of the dry run is to remove any glaring mistake in the protocol that may result in the execution being terminated.
In my view a prortocol with few errors due to a dry run is better than one littered with mistakes due to no prep work been performed.
Just my 2 cents!