The document discusses validation and project management. It defines validation as proving that a process will consistently produce expected results. Validation involves qualification and testing stages like installation qualification and operational qualification. A requirement traceability matrix links requirements throughout the validation process to ensure all are tested. Deviations from expected test results are tracked, and a validation summary report provides an overview of the completed validation project. Change control manages how changes are introduced to validated systems.

1. Validation -
An Integral Part of
Project ManagementProject Management
By:
Dipen Shroff Date: 07.05.2013
81081 93423 dipen.shroff@gmail.com

3. Introduction
The concept of validation was first proposed by two
Food and Drug Administration (FDA) officials, Ted
Byers and Bud Loftus, in the mid 1970’s in order to
improve the quality of pharmaceuticals.improve the quality of pharmaceuticals.
The first validation activities were focused on the
processes involved in making these products, but
quickly spread to associated processes including
environmental control, facility, equipment
sanitization and purified water production.

4. Quality
The degree to which a set of inherent
characteristics fulfill requirements.
– PMBOK 4th Edition.
Or,Or,
To meet with pre-defined specification.

5. Validation
Action of proving, in accordance with the principles
of GMP, that any procedure, process, equipment,
facility, material, activity or system actually leads to
the expected results.the expected results.
It is a process using documented evidence that
provides a high degree of assurance that a specific
process will consistently produce the predetermined
outcome.

6. Qualification
Action of proving that any premises, systems and
items of equipment / facility work correctly and
actually lead to the expected results.
A process of establishing confidence that theA process of establishing confidence that the
equipment / facility is capable of consistently
operating within established limits and tolerances.
Studies therefore done prior to use.

7. Qualification
Qualification should be done in accordance with
predetermined and approved qualification protocols.
The results of the qualification should be recorded
and reflected in qualification reports.and reflected in qualification reports.
The extent of the qualification should be based on
the criticality of a system or equipment.

8. Qualification - Validation
Qualification :
- Confirm compliance with specified requirements or
criteria.
(Do you have the right tool for the job?)
- Conduct tests to establish if the component of a
process has the attributes to produce a specifiedprocess has the attributes to produce a specified
outcome.
- Performed on one element or component of the
process to be validated.
Validation :
- Proof. Document that the process will
consistently produce a predetermined outcome.

9. Stages of Qualification
Requirement Specification
1. User Requirement Specification (URS)
2. Functional Requirement Specification (FRS)
3. Design Specification / Qualification (DS / DQ)3. Design Specification / Qualification (DS / DQ)
Test Protocols
1. Installation Qualification (IQ)
2. Operational Qualifications (OQ)
3. Performance Qualifications (PQ)

11. User Requirement Specification
User Requirements Specifications describes what users
require from the System.
User requirement specifications are written early in the
validation process, typically before the system is created.
It is written by the System Owner and End Users, with
input from Quality Assurance.
User Requirements Specifications are not intended to be a
technical document; readers with only a general
knowledge of the system should be able to understand the
requirements outlined in the URS.

12. User Requirement Specification
User Requirement Specification should be signed by
the 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 combined
with the functional requirements document.

13. Functional Requirement Specification
The Functional Requirement document, defines the
capabilities and functions that a System must be able
to perform successfully.
The functional specification is designed to be read byThe functional specification is designed to be read by
a general audience. Readers should understand the
system, but no particular technical knowledge should
be required to understand the document.

14. Functional Requirement Specification
The functional specification describes what the
system must do; how the system does it is described
in the Design Specification.
If a User Requirement Specification was written, allIf a User Requirement Specification was written, all
requirements outlined in the user requirement
specification should be addressed in the functional
requirements.

15. Functional Requirement Specification
The Functional Specification should be signed by the
System Owner and Quality Assurance. If key end
users, developers or engineers were involved with
developing the requirements, it may be appropriatedeveloping the requirements, it may be appropriate
to have them sign and approve the document as well.
Depending on the size and complexity of the
program, the functional requirements document can
be combined with either the user requirements
specification or the design specification.

16. Functional Requirement Specification
User Requirements describe the End User’s
requirements for a system.
Functional Requirements describe what the system
must do.must do.

17. Design Specification
Design Specifications describes how a System performs
the requirements outlined in the Functional
Requirements.
Depending on the system, this can include instructions on
performing specific requirements, configuration settings
or review of functions or code.
All requirements outlined in the functional specification
should be addressed; linking requirements between the
functional requirements and design specification is
performed on the Traceability Matrix.

18. Design Specification
A suitable supplier should be selected for the
appropriate system or equipment (approved vendor).
The design specification is reviewed and approved by
the System Owner, System Developer and Qualitythe System Owner, System Developer and Quality
Assurance.
Quality signs to ensure that the document complies
with appropriate regulations and that all
requirements were successfully addressed, but do not
necessarily need to review technical information.

19. Test Protocols
Tests Plans or Test Protocols are used to test System
requirements previously established in specification
documents.
Test Plans refer to a more general testing strategy; Test
Protocols are the actual testing documents.
Test Protocols are organized into collections of Test Cases
which check a specific element of the system. Each test
case is made up of a series of test steps.
Each step should include an instruction, an expected
result and the actual result.

20. Test Protocols
Any discrepancy between the expected result and the
actual result should be tracked as a deviation.
Deviations should be resolved before validation is
complete.complete.

21. Test Protocols
Installation Qualifications (IQ) verify that systems
are on machines suited to run the software, that the
system has been properly installed and that the
configuration is correct. These requirements wereconfiguration is correct. These requirements were
outlined in the Design Specification.
Operational Qualifications (OQ) verify that
systems perform as expected. The OQ tests
requirements outlined in the Functional
Requirements.

22. Test Protocols
Performance Qualifications (PQ) verify that
systems perform tasks in real-world conditions. The
PQ tests requirements outlined in the User
Requirement Specification.Requirement Specification.

23. Test Protocols
Factory Acceptance Test (FAT) – Factory acceptance tests
are an attempt to verify that the equipment meets
requirements outlined in the User Requirement
Specification 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 item
performs as required by the User Requirement
Specification or Functional Requirements.
Both are part of Installation Qualification.

24. Installation Qualification
Installation Qualifications are a collection of test
cases used to verify the proper installation and
configuration of a System.
The requirement to properly install the system wasThe requirement to properly install the system was
defined in the Design Specification.
Installation Qualifications must be performed before
completing Operational Qualification or
Performance Qualification.

25. Installation Qualification
Each step of the qualification should include an
instruction, an expected result and the actual result.
Any discrepancy between the expected result and the
actual result should be tracked as a deviation.actual result should be tracked as a deviation.
Installation Qualifications should be approved before
protocol execution.

26. Operational Qualification
Operational Qualifications are a collection of test
cases used to verify the proper functioning of a
System.
The operational qualification tests requirementsThe operational qualification tests requirements
defined in the Functional Requirements. Operational
Qualifications are usually performed before the
system is released for use.

27. Operational Qualification
Each step of the qualification should include an
instruction, an expected result and the actual result.
Any discrepancy between the expected result and the
actual result should be tracked as a deviation.actual result should be tracked as a deviation.
Operational Qualifications should be approved
before protocol execution.

28. Performance Qualification
Performance Qualifications are a collection of test cases
used to verify that a System performs as expected under
simulated real-world conditions.
The performance qualification tests requirements thatThe performance qualification tests requirements that
were defined in the User Requirement Specification (or
possibly the Functional Requirements).
Due to the nature of performance qualifications, these
tests are sometime conducted with power users as the
system is being released.

29. Performance Qualification
Each step of the qualification should include an
instruction, an expected result and the actual result.
Any discrepancy between the expected result and the
actual result should be tracked as a deviation.actual result should be tracked as a deviation.
Performance Qualifications should be approved
before protocol execution.

30. Requirement Traceability Matrix
The Requirement Traceability Matrix (RTM) is a
document which links requirements throughout the
validation process. The purpose of the requirement
traceability matrix is to ensure that all requirementstraceability matrix is to ensure that all requirements
defined for the system are tested in the Testing Protocols.
The requirement traceability matrix is usually developed
in concurrence with the initial list of requirements (either
the User Requirement Specification or Functional
Specification).

31. Requirement Traceability Matrix
As the Design Specifications and Testing
Protocols are developed, the traceability matrix is
updated.
Ideally, requirements should be traced to the specificIdeally, requirements should be traced to the specific
test step in the testing protocol where they are tested.

32. Deviations
When the actual results of a test step in a Test
Protocol do not match the expected results, this is
called a Deviation.
Deviation reports should include:Deviation reports should include:
Description – How the actual results differ from the
expected results
Root Cause – What caused the deviation
Corrective Action – What changes were made to the
testing protocol or the system to correct the deviation

33. Deviations
An organization’s control over their deviation process
often is reflective of their Quality organization as a
whole; thus regulatory auditors will often focus on
the deviation process.the deviation process.

34. Validation Summary Report
Validation Summary Reports provide an overview
of the entire validation project.
Once the summary report is signed, the validation
project is considered to be complete.project is considered to be complete.
When regulatory auditors review validation projects,
they typically begin by reviewing the summary
report.

35. Validation Summary Report
The validation summary report should include:
• A description of the validation project
• All test cases performed, including if those test
cases passed without issue
• All deviations reported, including how those• All deviations reported, including how those
deviations were resolved
The collection of documents produced during a
validation project is called a Validation Package.

36. Change Control
Change Control is a general term describing the
process of managing how changes are introduced into
a controlled System.
Change control demonstrates to regulatoryChange control demonstrates to regulatory
authorities that validated systems remain under
control during and after system changes.
Change Control systems are a favorite target of
regulatory auditors because they vividly demonstrate
an organization’s capacity to control its systems.

37. Change Control
Typical 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

38. Any “?”
Contact @
dipen.shroff@gmail.comdipen.shroff@gmail.com

39. THANK YOU