There are many reasons why validation projects take so long from bad leadership to lack of understanding of validation to inadequate risk assessments (if any). One of the major elephants in the room is the significant amount of time consumed around the management of paper and the lack of intelligence between static word documents.
This article will focus on a typical test document such as an IQ/OQ or PQ and the amount of time involved to generate, review, approve, execute and post approve such a document.
Locate the Correct Template
First of all the correct template needs to be used in order to complete the validation script so time is wasted initially either looking on the Document Management System or the Shared Drive to locate the correct template and the correct version of the template for use.
In current systems there is no centralised management of templates which almost always leads to confusion.
Locating the Correct Associated Documents
To write the test protocol the correct design documents, drawings etc. are required to ensure the correct test information is being captured, often trying to locate these documents is a problem as some might be located on a shared drive others on the Document Management System, or some might even be lost and never to been seen again!
Already we are wasting valuable time and we haven’t even started to write the document yet.
Writing the Test Protocol
Ok, so now we have the correct template and the correct associated documents at hand to assist in development of the test protocol. Below is a list of some of the most common issues when writing these documents using a word editor such as MS Word:
- Styling & Formatting issues
- Corrupt Template
- Alignment Issues
- Table of Content Issues
- Page Break and Numbering Issues
- Table Header Issues
- Forgetting to Save…..Lost Content
- Forgetting Where You Put the Document
These issues may not seem that important but these are common issues people face on a day to day basis when using MS Word to develop their validation documents. Imagine the time that would be saved if these issues were not present and people did not have to worry about the complexities of using MS Word!
Dry Run the Protocol
Before you send the document out for approval you first want to make sure that it works as intended and you are testing adequately. Depending on the size of the protocol and system/process/software being tested this can take some time and often requires a certain amount of rework to the test protocol. The time required to perform the test run should be factored into any timelines upfront so management can see where all the time is being spent before official execution commences. Some people like to print off the test protocol to perform the dry-run while others just like to skim over it using the MS Word version.
Sending Out For First Round Review
So now you have just completed the first draft of your awesome test protocol and it’s ready to face the audience for review. At this stage you’ve become emotionally attached to the document so like any actor in a first time production you are not going to take critique easily.
Sending out the document for review can be a real pain in itself if you are using a Document Management System first of all you need to check-in the document assign it a unique number etc and send to the appropriate people on your list for review. Alternatively if you are using a shared drive you need to send an email to everyone on your review list a link to the file on the drive and hope to God that they don’t mess it up……make sure you have a backup stored somewhere.
Reviewers Send Comments Back
After days of waiting people have finally gotten around to reviewing your document and you start to get a slew of emails to your inbox with the document peppered with comments from Mary, John, Jack etc.
Some follow the correct procedure and add comments to the master document while others save a brand new version of the document and add their comments that way….now you have a number of Master Versions to deal with.
All of a sudden you begin to panic and become frustrated having to manage not only the different documents but the amount of comments, with some people just commenting on the various styling issues and not what actually matters….. the content!
Incorporating First Round Review Comments
You once thought track changes was a useful tool, now you are seeing it in a different light as your document now resembles a rainbow with the multitude of colours from the various reviewers on the document.
With so many comments on the document how do you incorporate all of the various comments especially when so many comments are conflicting?
After talking to the various stakeholders on the document you decide to call a meeting to discuss the comments and try and get some kind of agreement.
Sending Out the Document for Second Review
You are now happy that you have updated the document correctly so you send out the document for second review to the stakeholders hoping for the green light so you can send for approval.
Reviewers Send Comments Back
Unfortunately it was too good to be true the document has been returned with more comments that need to be addressed and again John’s comments conflict with Mary’s. Instead of going back and forward through emails and phone calls, you meet with John and Mary to update the document with both of their comments incorporated.
Ready for Approval
Finally the document is ready for approval and all of the comments and concerns from the stakeholders have been incorporated. Time to print the document and walk around the plant to get the wet signatures so you can commence with the protocol execution.
Ensure each page has been stamped; no pages are missing…………let’s get those final signatures.
Approval Walk-Around
The physical side to validation, walking around the plant looking for the signatures to allow execution to commence. This can also be a very time consuming aspect of the approval process trying to locate the correct people and hope that they find the time to sign the document. Often at this point pages get lost in transit, the page numbers are incorrect or someone finds something else very small that they insist requires a reprint.
Back to your workstation to update the document, reprint and walk around for approval again.
Executing the Protocol
Executing the protocol or test script is the most important aspect of the entire process and needs total concentration. If there are pre-requisites to be executed first, make sure they have been completed correctly or else the execution could lead to a nightmare of deviation after deviation.
This is probably the most arduous and time consuming aspect and needs total focus, sometimes it’s even best to commence first thing in the morning when your brain is fresh.
Depending on the size of the protocol and the number of deviations/discrepancies that need to be raised an execution can take anything from a day up to a week or two.
Closing All Deviations
Unless you have a protocol that has caused no issues you will need to close all deviations associated with the protocol before you send the completed protocol for review and approval. This can often be a time consuming task trying to explain to the relevant people what each deviation means and whether a deviation merits a retest or not.
Package the Completed Protocol
Now that the protocol is now complete with all associated deviations it is time assemble the final package so post execution review can commence. Ensure that all the pages are present in the correct order for the main protocol and all of the deviations, attachments and other documentation are present sign and dated with page numbers where necessary.
Sanity check the entire package to double check that any references made within the main protocol to associated documentation is accurate.
Incorporate All Post Execution Review Comments
Usually the Quality Department are responsible for the main post execution review process, this usually takes a considerable length of time before all questions have been addressed successfully and all deviations have been explained to a degree that is acceptable to the Quality Heads. All comments need to be incorporated into the test protocol before Post-Approval walk-around can commence.
Post Approval Walk Around
At this point the protocol and all associated documentation has been completed and the post approval walk around is the next step to get final sign off on the protocol….remember you need this sign-off before you commence with the Protocol Report!.
Before you begin walking the plant looking for the people with the “Golden Signatures” it’s a good idea to ensure that the package has no missing pages and all pages have been numbered correctly. You will be amazed what people will find to complain about just when you thought it’s all coming to an end!
Close Out & File Away
Finally, the protocol has been approved and you can file this document in storage until you need it for audit purposes or to write the final validation report.
Conclusion & Your Comments
We have only focussed on one validation protocol but as you can see from creation to completion it is a very time consuming process. Even when you have experienced validation personnel doing this work it takes time but imagine when there are junior people involved and multiple validation documents with multiple projects, then the drain on resources and time really becomes apparent.
If this article has stuck a chord with you, we would be very interested to hear your feedback and what you think validation projects take so long to complete.
Please enter your valuable comments below.
