Planning for validation

Written by Rina Nir

planing for validation, requirements

Planning your project and planning your validation are very closely intertwined and, when your project process is mature, these will converge to become one thing.

Our focus here though is on the importance of allowing time in your project plan to make sure all the validation boxes are ticked. Whether you run your project using Waterfall or Agile methodology, the validation outline will be largely the same.

Validation process planning

This is the list of validation elements you should have ready by the time the project moves to production:

Element
Typically is documented in
What this is
1PlanValidation planThe plan should:

  1. Identify the system that will be delivered
  2. Specify the product or quality areas it will impact
  3. Outline the team and other resources that will be involved and the timeline
  4. List the validation elements that will be delivered (basically this list)
2SupplierSupplier qualificationAdding software and infrastructure suppliers to your approved suppliers list (ASL).
3Process mappingThis can be incorporated into your procedure or work instruction for the processA process map is a detailed flow diagram of the process that should occur once the project has been implemented.

Although this is not strictly required by regulations, process mapping helps to drive a good implementation.

4RequirementsUser requirement specifications

In small projects requirement specifications may also be part of the validation plan

A list of system requirements. Each requirement is identified along with its connections to other traceability elements.

Often the bulk of requirements will be framed as work instructions that describe your process. Each step in the work instruction can then be identified as a requirement.

5Risk analysisRisk analysis document

In small projects this may also be part of the validation plan

Identifies the steps that should be put in place to make the system safe.
6Functional SpecificationsFunctional specifications document

Functional and configuration document

Requirements translated into concrete software features and configuration elements. Each element is uniquely identified for traceability.
7InfrastructureValidation plan

Infrastructure overview document

Identifies where the system will be developed, validated, produced and installed.
8Testing your systemTest report

Operational qualification (OQ), performance qualification (PQ) or OQ/PQ

Running test scripts, either manual or automatic. Each test will be uniquely identified for traceability.
9Installation checklistInstallation report

Installation qualification (IQ)

A checklist describing the installation steps. After execution the checklist should contain the actual results (success or failure), and document any unplanned steps taken.
10Traceability matrixesStandalone traceability report or within the validation planTables that map:

  1. Each requirement to elements of the functional specification, proving that each requirement has been met
  2. Each risk mitigation to a user requirement

Each functional specification element will be tested to prove that the system works as outlined in the functional specification.

11Instructions on how to use the systemOperating procedures or work instructionsOnce the new system is in place, your team will work differently. This needs to be reflected in your operating procedures or work instructions.

Written well, these can be a great tool for onboarding people to the system.

12Configuration managementOperating procedures or work instructionsExplains how future changes to the system will be made, eg how platform upgrades or changes to process specifications will be carried out.
13TrainingTraining planA list of who needs to be trained to use the new system and when and how this will be done.
14Migration of legacy dataMigration plan or within the validation plan

The migration requirements may also be reflected in the requirement specifications and other traceability elements

Importing relevant existing documents or data to the new system.

If you identify that this step will be necessary, include it in your validation activities.

15validation reportValidation reportThe final step before the system goes into production.

This brings all the previous validation elements together along with an official conclusion that the system is ready for production.

 

Blog posts in this series:

  1. Validating Jira
  2. Heading toward hands-free validation

Have an idea for your Quality Management System?

We’d love to learn more about your project.

Let’s have a chat