Validation -An Integral Part ofProject ManagementProject ManagementBy:Dipen Shroff Date: 07.05.201381081 93423 firstname.lastname@example.org
IntroductionThe concept of validation was first proposed by twoFood and Drug Administration (FDA) officials, TedByers and Bud Loftus, in the mid 1970’s in order toimprove the quality of pharmaceuticals.improve the quality of pharmaceuticals.The first validation activities were focused on theprocesses involved in making these products, butquickly spread to associated processes includingenvironmental control, facility, equipmentsanitization and purified water production.
QualityThe degree to which a set of inherentcharacteristics fulfill requirements.– PMBOK 4th Edition.Or,Or,To meet with pre-defined specification.
ValidationAction of proving, in accordance with the principlesof GMP, that any procedure, process, equipment,facility, material, activity or system actually leads tothe expected results.the expected results.It is a process using documented evidence thatprovides a high degree of assurance that a specificprocess will consistently produce the predeterminedoutcome.
QualificationAction of proving that any premises, systems anditems of equipment / facility work correctly andactually lead to the expected results.A process of establishing confidence that theA process of establishing confidence that theequipment / facility is capable of consistentlyoperating within established limits and tolerances.Studies therefore done prior to use.
QualificationQualification should be done in accordance withpredetermined and approved qualification protocols.The results of the qualification should be recordedand reflected in qualification reports.and reflected in qualification reports.The extent of the qualification should be based onthe criticality of a system or equipment.
Qualification - ValidationQualification :- Confirm compliance with specified requirements orcriteria.(Do you have the right tool for the job?)- Conduct tests to establish if the component of aprocess has the attributes to produce a specifiedprocess has the attributes to produce a specifiedoutcome.- Performed on one element or component of theprocess to be validated.Validation :- Proof. Document that the process willconsistently produce a predetermined outcome.
User Requirement SpecificationUser Requirements Specifications describes what usersrequire from the System.User requirement specifications are written early in thevalidation process, typically before the system is created.It is written by the System Owner and End Users, withinput from Quality Assurance.User Requirements Specifications are not intended to be atechnical document; readers with only a generalknowledge of the system should be able to understand therequirements outlined in the URS.
User Requirement SpecificationUser Requirement Specification should be signed bythe System Owner, Key End Users and Quality.Depending on the size and complexity of the project,the user requirement specification can be combinedthe user requirement specification can be combinedwith the functional requirements document.
Functional Requirement SpecificationThe Functional Requirement document, defines thecapabilities and functions that a System must be ableto perform successfully.The functional specification is designed to be read byThe functional specification is designed to be read bya general audience. Readers should understand thesystem, but no particular technical knowledge shouldbe required to understand the document.
Functional Requirement SpecificationThe functional specification describes what thesystem must do; how the system does it is describedin the Design Specification.If a User Requirement Specification was written, allIf a User Requirement Specification was written, allrequirements outlined in the user requirementspecification should be addressed in the functionalrequirements.
Functional Requirement SpecificationThe Functional Specification should be signed by theSystem Owner and Quality Assurance. If key endusers, developers or engineers were involved withdeveloping the requirements, it may be appropriatedeveloping the requirements, it may be appropriateto have them sign and approve the document as well.Depending on the size and complexity of theprogram, the functional requirements document canbe combined with either the user requirementsspecification or the design specification.
Functional Requirement SpecificationUser Requirements describe the End User’srequirements for a system.Functional Requirements describe what the systemmust do.must do.
Design SpecificationDesign Specifications describes how a System performsthe requirements outlined in the FunctionalRequirements.Depending on the system, this can include instructions onperforming specific requirements, configuration settingsor review of functions or code.All requirements outlined in the functional specificationshould be addressed; linking requirements between thefunctional requirements and design specification isperformed on the Traceability Matrix.
Design SpecificationA suitable supplier should be selected for theappropriate system or equipment (approved vendor).The design specification is reviewed and approved bythe System Owner, System Developer and Qualitythe System Owner, System Developer and QualityAssurance.Quality signs to ensure that the document complieswith appropriate regulations and that allrequirements were successfully addressed, but do notnecessarily need to review technical information.
Test ProtocolsTests Plans or Test Protocols are used to test Systemrequirements previously established in specificationdocuments.Test Plans refer to a more general testing strategy; TestProtocols are the actual testing documents.Test Protocols are organized into collections of Test Caseswhich check a specific element of the system. Each testcase is made up of a series of test steps.Each step should include an instruction, an expectedresult and the actual result.
Test ProtocolsAny discrepancy between the expected result and theactual result should be tracked as a deviation.Deviations should be resolved before validation iscomplete.complete.
Test ProtocolsInstallation Qualifications (IQ) verify that systemsare on machines suited to run the software, that thesystem has been properly installed and that theconfiguration is correct. These requirements wereconfiguration is correct. These requirements wereoutlined in the Design Specification.Operational Qualifications (OQ) verify thatsystems perform as expected. The OQ testsrequirements outlined in the FunctionalRequirements.
Test ProtocolsPerformance Qualifications (PQ) verify thatsystems perform tasks in real-world conditions. ThePQ tests requirements outlined in the UserRequirement Specification.Requirement Specification.
Test ProtocolsFactory Acceptance Test (FAT) – Factory acceptance testsare an attempt to verify that the equipment meetsrequirements outlined in the User RequirementSpecification or Functional Requirements.FAT are performed at the point of assembly.User Acceptance Test (UAT) or Site Acceptance Test(SAT) – User and site acceptance tests verify that the itemperforms as required by the User RequirementSpecification or Functional Requirements.Both are part of Installation Qualification.
Installation QualificationInstallation Qualifications are a collection of testcases used to verify the proper installation andconfiguration of a System.The requirement to properly install the system wasThe requirement to properly install the system wasdefined in the Design Specification.Installation Qualifications must be performed beforecompleting Operational Qualification orPerformance Qualification.
Installation QualificationEach step of the qualification should include aninstruction, an expected result and the actual result.Any discrepancy between the expected result and theactual result should be tracked as a deviation.actual result should be tracked as a deviation.Installation Qualifications should be approved beforeprotocol execution.
Operational QualificationOperational Qualifications are a collection of testcases used to verify the proper functioning of aSystem.The operational qualification tests requirementsThe operational qualification tests requirementsdefined in the Functional Requirements. OperationalQualifications are usually performed before thesystem is released for use.
Operational QualificationEach step of the qualification should include aninstruction, an expected result and the actual result.Any discrepancy between the expected result and theactual result should be tracked as a deviation.actual result should be tracked as a deviation.Operational Qualifications should be approvedbefore protocol execution.
Performance QualificationPerformance Qualifications are a collection of test casesused to verify that a System performs as expected undersimulated real-world conditions.The performance qualification tests requirements thatThe performance qualification tests requirements thatwere defined in the User Requirement Specification (orpossibly the Functional Requirements).Due to the nature of performance qualifications, thesetests are sometime conducted with power users as thesystem is being released.
Performance QualificationEach step of the qualification should include aninstruction, an expected result and the actual result.Any discrepancy between the expected result and theactual result should be tracked as a deviation.actual result should be tracked as a deviation.Performance Qualifications should be approvedbefore protocol execution.
Requirement Traceability MatrixThe Requirement Traceability Matrix (RTM) is adocument which links requirements throughout thevalidation process. The purpose of the requirementtraceability matrix is to ensure that all requirementstraceability matrix is to ensure that all requirementsdefined for the system are tested in the Testing Protocols.The requirement traceability matrix is usually developedin concurrence with the initial list of requirements (eitherthe User Requirement Specification or FunctionalSpecification).
Requirement Traceability MatrixAs the Design Specifications and TestingProtocols are developed, the traceability matrix isupdated.Ideally, requirements should be traced to the specificIdeally, requirements should be traced to the specifictest step in the testing protocol where they are tested.
DeviationsWhen the actual results of a test step in a TestProtocol do not match the expected results, this iscalled a Deviation.Deviation reports should include:Deviation reports should include:Description – How the actual results differ from theexpected resultsRoot Cause – What caused the deviationCorrective Action – What changes were made to thetesting protocol or the system to correct the deviation
DeviationsAn organization’s control over their deviation processoften is reflective of their Quality organization as awhole; thus regulatory auditors will often focus onthe deviation process.the deviation process.
Validation Summary ReportValidation Summary Reports provide an overviewof the entire validation project.Once the summary report is signed, the validationproject is considered to be complete.project is considered to be complete.When regulatory auditors review validation projects,they typically begin by reviewing the summaryreport.
Validation Summary ReportThe validation summary report should include:• A description of the validation project• All test cases performed, including if those testcases passed without issue• All deviations reported, including how those• All deviations reported, including how thosedeviations were resolvedThe collection of documents produced during avalidation project is called a Validation Package.
Change ControlChange Control is a general term describing theprocess of managing how changes are introduced intoa controlled System.Change control demonstrates to regulatoryChange control demonstrates to regulatoryauthorities that validated systems remain undercontrol during and after system changes.Change Control systems are a favorite target ofregulatory auditors because they vividly demonstratean organization’s capacity to control its systems.
Change ControlTypical Steps in a Change Control process are:• Request the Change• Assess the Impact of the Change• Decision on Changes• Decision on Changes• Implementation of Change, & Monitoring• Impact Analysis and Closing
Any “?”Contact @email@example.com@gmail.com