The purpose of this document is to describe the approach that will be taken to ensure that the <Project Name> is developed according to quality software engineering principles, that it provides the functional capability required by the users and the system will continue to provide the required functionality over time.

<In this section, describe the scope of the validation effort.  Information may include:

·      What is being validated – the whole system, a piece of the system, etc.?

·      What is the release number?

·      Is this project an extension, an upgrade, or a new system?

·      Are there interfaces to other systems?

·      At what locations will the system be used?

Also discuss any impact on the validation effort or the focus of the validation effort based on the results of the Validation Analysis and Risk Assessment.

A description out-of-scope items can be added if deemed appropriate.>

See the SDLC Glossary, GDL-G-ALL-APM-176, for general definitions.

<List any definitions/acronyms/abbreviations, specific to this project, used in this document that may not be familiar to reviewers and approvers of this document.>

<List the approved and controlled documents that are being referred in this document with their unique document identifier.>

<Provide a brief overview of the system by describing its functionality, location and intended use or purpose. Provide a brief description of the system and process being developed / evaluated.

For new systems, include statements, which indicate that the system is a new installation, and identify the system boundaries.

For legacy systems, provide high-level information on the background of the system, when it was developed, previous validation, and validation measures existing documentation, etc., as applicable.

Describe the system environments that need to be established and in place (e.g., Development, QA/Test, Production, Disaster Recovery, etc.).>

As per the Validation Analysis, the following regulations are applicable for this project and validation deliverables are required:

<Delete regulations that are not applicable.>

·     Financial Regulation: (SOx, etc.)-Any system/project - financial reporting or control, purchasing and tracking assets (inventory, payroll, budgeting, etc).

·     Legal or Risk Management: Trademark, copyright, audit, change management, records management

·     Privacy: Personally identifiable information, HIPAA, etc.

·     Product Regulation: (FDA, etc.)-Any system/project relating to product - purchase, manufacture, distribution, recall or control.

·     Security: IAPP Information Asset Protection) - system or project containing business critical information

·     WICO

·     Others … <please define>

<If none of the above applies, use the following statement and delete the text above.>

As per the Validation Analysis, the project is not subject to regulation and validation deliverables are not required.

<Describe the validation strategy to be followed for the project. Identify the type of Implementation (Custom or SAP) and the work type(s) that apply for the project. Include an overview of the environment(s) that will be used (e.g. a validation environment will be used for testing prior to Production deployment). Specify if the use of this system does/does not fall under the scope of validation.>

<An initial risk assessment is performed to evaluate risk factors involved in computerizing a manual process, or in the purchase or enhancement of a computerized system. This assessment covers risks to the business, to regulatory validation patient safety, and other areas of validation . The GxP criticality of the system, and whether it is GxP regulated or not, should be documented.

In this section, define the strategy for addressing business and validation risks and describe the plans and processes for tracking risks. Each plan should:

·     Identify and prioritize risk areas.

·     Identify factors contributing to the potential occurrence of each risk.

·     Describe the means to reduce each risk or rationale for accepting the risk.

·     Identify contingency procedures for each risk area.

The assessment may be used to tailor the validation process, ensuring the appropriate life cycle work types are being executed, documentation, and level of testing. This risk assessment should be documented. This assessment will be revisited and enhanced later in the life cycle as necessary.

The risk assessment described above focuses on residual risks, such as validation and business risks associated with the system in operation. Project risks, such as risks to the completion of the project, availability of resource, and technical feasibility, will be covered in the Project Risk Register. Additionally, those areas of non-validation to the IAPP, if they exist, should be documented as validation risks.  Other technical risks may be associated with potential safety/reliability hazards identified during the hazard analysis and reliability activities of the proposed system. These safety and effectiveness risks need to be documented in the risk assessment documentation.>

<Internal suppliers (service provider) should comply with relevant local and corporate computerized system validation requirements.

Each external supplier should be formally assessed to determine their suitability and their ability to support the user’s computerized system validation and validation requirements. This assessment should be conducted and documented, and in many cases this will involve an audit of the supplier. This assessment should be performed prior to signing any contract with the supplier. In addition, a Business Partner Risk Assessment (BPRA) must be conducted if need is identified in the Validation Analysis. If another J&J Company has already audited the supplier at the same location for the same reason, then subject to that company agreeing to share such information, another audit may not be required. The justification for not auditing a specific supplier should be formally documented.>

<Identify the roles and responsibilities of the parties involved in the validation process.>

<Guidance on approval roles is available in the Roles Matrix, GDL-G-ALL-APM-157. Identify the validation documents required for the system and assign the roles as the responsible Owner to the deliverable. Provide a rationale in the Comments column for items that will NOT be included. Additional rows may need to be added to the applicable tables below to ensure system environments are covered (e.g., hardware and software for both test and production environments).

Documents may need to be revised and re-approved, as necessary, as the team progresses through the Process.  These will be reviewed and revised as necessary, prior to closing the work type. Any deviations from this plan must be described in the comments section (i.e. Functional Specification has been combined in the User Requirements Specification).  Modify the default values in the Approver Roles and Comments fields as appropriate.>

This section identifies the validation deliverables for the project.  NOTE: The lists of deliverables in the following tables include the deliverables for both the Custom and the SAP

Implementations in the SDLC. The deliverables marked with (*) do not have an SDLC template. Please use templates, system, or documentation format per local or corporate standards or guidelines, as appropriate.

The following key is used in the deliverables tables:

·     A: If Applicable. Mandatory if the deliverable is applicable.

·     M: Mandatory. Create the deliverable OR write a rationale in the Validation Plan as to why it is not necessary for the specific project.

·     N/A: Not applicable.

·     R: Recommended. It is a project decision, but the recommendation is to create the deliverable for the specific project, following project development best practices.

·     O: Optional. It is a project decision, but there are no impacts at all if not applied.

GxP and SOx project recommendations take priority over ‘All others except Simplified Path’ recommendation. For projects which are classified as Simplified Path please use ‘Simplified Validation Plan and Specification’ template in SDLC.

The execution of this Validation Plan will be considered successful and the system may be used in its production environment when:

·     Development, review, and approval of all validation deliverables is complete

·     Execution and documentation of all validation tasks is complete

·     All Test Defects must be addressed and CAPAs must be opened for any unresolved Test Defects that are classified as High or Medium.  Justification for releasing the system to Production with open Test Defects classified as High or Medium must be included in the Validation Report.

Any deviations from this Validation Plan will be documented and rationalized in the Validation Report.

<Describe the process for reporting and resolving defects from executing formal testing.  Refer to Attachment A & B of this Validation Plan to document the test defects report and log to be used throughout the testing process.  The data will be summarized in the Validation Report.  Default criteria for classifying test defects as High, Medium, or Low are provided and can be modified as needed.>

Test Defects will be classified as High, Medium or Low based on root cause as follows and the classification should be recorded on the Test Defect Report Form:

<Describe the process for controlling and maintaining the configuration of the application or system throughout the project. Refer to relevant procedures, as applicable.>

<This section describes the activities required to identify change, to control change, to ensure proper implementation of changes, and to report changes while the system deliverables are under control of the system developer(s), prior to user acceptance or completion and approval of the User Acceptance Test cases.>

<List the procedures to be developed and/or modified for operating the software system (e.g., security procedures, operating procedures, etc.).>

<Describe the strategy if an event or issue were to occur that would result in a decision to revert back to the original state or old environment during the implementation process, resulting in a postponement of the conversion or implementation to the new system.  Identify the approvals required to stop the implementation. Describe the communication that would need to occur (e.g., method of communication, to whom, when, etc.).>

<Use the table below to track changes made to the document.  Be sure to include the date the document was created/updated. Be sure to sufficiently define changes to facilitate version review and document update approvals.>

<Instructions for Use

Guidance for creating documents or templates from this template:

·      Always start with a fresh template. Do not use a locally stored template or existing Document as a starting point.

·      It will be useful to display fields as shaded. Tools| Options, View Tab, select Always in the field “Field Shading.”  You will only need to do this once. This is useful to include in you templates Instructions for Use.

·      Using File | Properties provide values for the fields defined. Provide values for all the fields defined in the lower portion of the display. Then select the entire document and press F9. This will populate the fields throughout the document with the customized values. To convert field values to regular text, select and type Ctrl-Shift F9.

·      Use fields in boilerplate text for items such as Project Name, Project ID, System Name, etc.

·      Provide general instructions for use within your template; be sure to include instructions to remove all the Template Instruction text. Also see above on shading fields.

·      Formatting requirements for Templates

Ø Minimize section breaks; they confuse people. Also some older printers have problems when switching between landscape and portrait layouts.

Ø All tables have their heading rows(s) set to repeat at the top of each page

Ø Use Paragraph spacing (format | Paragraph) to put blank spacing between paragraphs. Do not use empty paragraphs to provide the blank space as it makes orphan and widow control impossible.

Ø Do not hardcode page breaks unless the page break will occur in that spot on every instance of the document (such as before Section 1). Use Format |Paragraph| Lines and Page Breaks | Page Break Before when page-breaking before a heading, for example.

Ø Use Styles to change fonts, spacing, etc. when possible. It makes it easier to change consistently later.>