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:

Typically is documented in
What this is
1 Plan Validation plan The 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)
2 Supplier Supplier qualification Adding software and infrastructure suppliers to your approved suppliers list (ASL).
3 Process mapping This can be incorporated into your procedure or work instruction for the process A 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.

4 Requirements User 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.

5 Risk analysis Risk 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.
6 Functional Specifications Functional specifications document

Functional and configuration document

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

Infrastructure overview document

Identifies where the system will be developed, validated, produced and installed.
8 Testing your system Test 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.
9 Installation checklist Installation 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.
10 Traceability matrixes Standalone traceability report or within the validation plan Tables 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.

11 Instructions on how to use the system Operating procedures or work instructions Once 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.

12 Configuration management Operating procedures or work instructions Explains how future changes to the system will be made, eg how platform upgrades or changes to process specifications will be carried out.
13 Training Training plan A list of who needs to be trained to use the new system and when and how this will be done.
14 Migration of legacy data Migration 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.

15 validation report Validation report The 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