Validation Master Plan...
The primary purpose of a Validation Master Plan is to allow the
identification of requirements and procedures needed during the
validation process.
This is typically achieved through:
- Identifying the objectives and steps of the validation
process.
- Providing a full step by step description of resources,
timeframes and training.
- Identification of prerequisites.
- Identification of evaluation techniques (fast/real time
simulators etc).
- Allocation of resources to focus on the most critical areas of
plant validation.
The master plan ensures that a pattern of random validation is not
undertaken and allows a swift response to the validation of new
equipment, whilst giving the client flexibility for future
needs.
Change Control

Before the release of an automated system and during
the validation process, modification of the system configuration
may be necessary in order to fully comply with client specification
and expectations. Any change that occurs during the installation
phase must be fully documented and controlled. All deliverables in
the context of the project or system should be fully identified so
as to allow areas of change control to be properly identified.
These include:
- Hardware components
- Software (applications, operating systems, firmware, drivers,
parameters etc)
- Configuration files
- Manuals (user and system)
- Development documentation
- Training materials
- SOPs
Operational Change Control
Changes to a live automated system are managed through the
facility’s change management procedure. Some changes may require
notification to, or licence amendment from regulatory agencies. All
proposed modifications, enhancements or additions should be
assessed to determine the affect each change would have on the
system. This operation should determine the degree of validation
required.
When programming changes are made to an automated system, not only
is it important to evaluate the correctness of the implemented
changes, but sufficient validation should be conducted to
demonstrate that portions of the software not involved in the
change have not been adversely affected.