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.
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:|
|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.|
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:|
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.