Validation as a Best Practice – Part 2

Written by Scott Collins - Sr. Validation Manager

Several months ago I wrote about why validation is a best practice with a link to Part 1 of a presentation on how to complete a validation.  This time I will summarize the activities associated with completing a validation and provide a link to Part 2 of the same presentation.

In Part 1 of the presentation, Validation as a Best Business Practice – Part 1, I stated the first steps for a validation project: Validation Project Plan and the User Requirements Specification (URS).  While the Validation Plan may or may not be required depending upon the project, the URS is critical for all validation efforts.  This document provides the team as well as the equipment or system developer with enough information to provide an end product that meets its intended use.  Each requirement must be clear, concise, specific, non-conflicting with other requirements, and most of all testable.

For best results the next two steps should be completed with help or input from the developer or vendor.  The next document to be developed is the Functional Requirement Specification (FRS).  The FRS addresses at a high level how each requirement will be met by the equipment or system.  This is best answered by the developer or vendor.  The FRS is also a great tool for deciding which developer or vendor to use, so very often a customer will supply the URS to many developers or vendors and make their supplier decision based on the FRS.  Once a developer or vendor has been identified, each functional specification is detailed in the Design Specification (DS).  The FRS can be expanded into the DS to reduce the number of documents and to make sure that each functional specification has been addressed.

After the DS has been created, the developer or vendor can build or supply the equipment or system.  If the equipment or system is being built, then the customer should insist on a Factory Acceptance Test if possible.  Keep in mind that it may not be practical to perform and FAT on a major utility system or an off-the-shelf system.  Major utility systems are too big and need t be installed in their final location before performing testing and an off-the-shelf system has been tested at many client sites so there is little chance that it will not work once installed at the final location.  The FAT allows for the developer or vendor to work out the bugs in the system before installing at the client site.  It also allows the client to test the system for their intended use at the developers or vendors site so any bugs or changes can be addressed quickly and easily, and usually without additional cost to the client.

Once the FAT is completed and all issues addressed, the equipment or system is delivered and installed at the client site.  After everything is set up, but before the developer or vendor leaves, the Site Acceptance Testing (SAT) should be completed.  The SAT usually reruns the FAT tests.  This proves that nothing was changed or affected by breaking the equipment or system down and shipping to the client site.

Another activity that should be completed before the developer or vendor leaves or is given the final payment is Commissioning.  Commissioning usually involves the developer or vendor performing their checks and tests on the equipment or system.  Be sure to get the executed documents for your records.  If you intend to use the Commissioning document to support less testing later on, then you need to have the documentation meet your internal standards.

Now that the equipment or system has been installed, the validation testing can begin.  The validation testing involves Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ).  These documents can be combined into one if preferred.  Some companies insist on these being separate documents to force the team to complete one phase before moving to the next phase.  The critical point to make here is that the tests that are developed are clear, concise, and test, at a minimum, all of the critical user requirements.

The best way to make sure all requirements have been tested is by developing Traceability Matrix.  The Traceability Matrix can be a table that lists each requirement with its unique number down the left column, the next column includes the Functional Specification number(s) that address each requirement, the next column lists the Design Specification number(s) that address each Functional Specification, and the last column lists the protocol and test number(s) that verify each Design Specification.  For more detailed information please review the Validation as a Best Business Practice – Part 2 presentation.  

Following this process, even at a high level will help insure that you have a piece of equipment or system that meets your intended use.  This is one critical part to ensuring that your product meets the critical quality attributes determined during the development phase of the product lifecycle.  This is why Validation is a best business practice.