Validation Management and Planning

Validation Planning

Now, how to describe Validation simple? Ok, there is no simple way, and some start with definitions and standards, and after two hours you have understood, that it is a lot of work - or not very interessting.

In simple words: Validation is nothing special, or adding tons of (unneccesary) tasks to a "normal" project - if any project is being executed with good practices - it is more or less validated. But in normal live, not every project is following good practices....

Please do not forget, that about 60 Percent of IT Projects in general are not in time and budget. So validation is enabling as a quality management discipline a good IT project in general - and in addition regulatory compliance and inspection readiness.

Quality Project Plan

Introduction Like everything in the validation world, a Quality Project Plan (QPP) can be known by several other names (e.g. Quality Plan, Quality Execution Plan, etc.), but essentially its aim is to define a plan for quality assurance activities and outline the regulations and activities to be used by an overall project team (this can / should include the IT and engineering). Rather than replicating the Validation Plan it should supplement and support it. It can also be used to assign people to roles and responsibilities that should have been defined in the Validation Plan.

Who should write a QPP?

The Validation Team - Whilst the Validation Plan should determine the WHAT, WHO and HOW, the QPP should help define these too (the validation team can have a set of roles and responsibilities defined for the project which sit below the overall project Roles and Responsibilities), aswell as adding the WHEN and the WHERE.

Engineering / IT - Sometimes, depending on the company structure and project type, the engineering / IT departments may write their own QPP. This usually focuses on the design, build and install phases, with the emphasis on development and verification of design, test and operability as opposed to the validation teams focus, which should be orientated towards the procedural and regulatory.

The Principal Contractors - The system developers should provice a QPP that shows how they shall meet the requirements of the project based against their Quality Management System? and project plan, detailing their deliverables and timelines.

Section Summary

The aim of a quality plan should be to ensure the following occurs during the system Life Cycle Phases?; the project deliverables are in line with company Standard Operating Procedures and / or the Quality Management System? system is developed against clear requirements (e.g. User Requirements Specifications?) system is developed in line with any regulatory requirements (e.g. 21 CFR Part 11) system is developed using specified guidelines (e.g. GAMP5) before delivery the equipment and software meets specifications (generally through Factory Acceptance Testing) all equipment and software is properly installed (insallation verification and qualification) system is safe to operate (operatonal verification and qualification) documentation for operation and maintenance has been established and all system users and maintainers have been adequately trained system is fully operational in accordance with the functional requirements (based on the original user requirements and generally satisfied by performance qualification)

Suggested QPP Contents

• Overview Quality Project Plan
• Quality Approach - QPP
• Roles and Responsibilities
• Life Cycle Phases
• Validation Approach
• Verification Approach

This should give a brief description of the system and its use. It is usually preferable to cut & paste the overview fom the URS to maintain a consistent description. The overview can also include or be the scope. Some of the following are suggested to be covered;

Example 1. Process Control System Describe what process equipment the system will control (e.g. filter dryer, reactor, centrifuge), the area it is located in and the likely process (or processes if it is multi-functional) that will be ran in the plant.

Example 2. Master Data Management System Describe the data type (GMP, Business, HR), whether historical or archived data needs to be imported, the scale of the system (local or global) and the types of users and access requirements likely (e.g. HR, IT, Engineering).

Example 3. Building Environmental Management System Describe the size and type of building (e.g. manufacturing, storage, laboratory), number of rooms and their dimensions, the classification of spaces and whether the system is to monitor, control or monitor and control the spaces (some end users like to have separate control and monitoring systems but this is not efficient in terms of engineering or valdation effort if the GMP critical areas can be clearly defined using Functional Risk Assessment? of the User Requirements Specifications? and / or Criticality Assessments? of the devices).

Quality Approach

The quality approach should describe the general process for executing the Quality Project Plan. The following should be considered;

The Quality Project Plan can have a section to record the completion of each validation deliverable document. This can be in the form of an Appendix attached to the Quality Project Plan.

Document Description Document Reference Completion Date Validation Signature Validation Plan ABC-09-001-VP User Requirements Specification ABC-09-002-URS

The Quality Project Plan should have a section to record the execution of each phase of the project, reference the Life Cycle Phases?. This can be in the form of an Appendix attached to the Quality Project Plan.

PHASE Completion Date Validation Signature REQUIREMENTS DESIGN SYSTEM BUILD INSTALLATION OPERATION

Define the project review and approval policy. This can differ from project to project (depending on type and size) but generally a 10 day review period is enough. Do not make it too short or people will simply not get time to properly review the documents.

Define system implementation, methodologies and plans against the project roles / responsibilities and the requirements. This can include a document matrix with authors, reviewers and approvers being assigned. Ensure ONLY those absolutely necessary review / approve documents, e.g. Subject Matter Experts review / approve technical design documents - there is no need for QA or validation to spell check or format a document just to add their signature.

Specify what documentation should be assembled in a project documentation repository for the system, along with all the validation documentation outlined in the Validation Plan;

1. System Life Cycle deliverables 2. Audit Plans and Results 3. Design specifications, schedules and drawings 4. Test Plans and Results 5. System Qualification Documentation 6. Training Documentation

Define the project boundaries in terms of document deliverables and change management. Consider if the Performance Qualification? is in or out of the project scope in terms of the system deliverables - especially in relation to the system developer who may possibly be the system suppport and maintainer once the system has gone live (especially if it was an in-house development). Also critical is defining when project change control ends and site change management starts.