Validation: What's most important?

What is the most important part of a validation program or strategy? This seems like a question similar to "what's the best film of all time?". It doesn't look like there can be a definitive answer; for some people it is "The Godfather", for others it would be the oft cited "Citizen Kane" and still others could not give a single answer* as there are too many to choose from. It's a very personal thing.

However when it comes to the components of the system life cycle there are a limited number of candidates to consider. Suggestions might include:

• Validation Planning; obviously the first and most important part of the lifecycle?
• Change Management Process; how can you maintain any control without this?
• User/System Requirements; the bedrock of developing and testing a system is a solid set of requirements, surely?
  

Well these and others are strong candidates for being validation MVP (most valued part), but here's my choice and I'll explain why...

Traceability Management.

Saywhatnow? Let's discuss what we mean by this term.

Traceability can be imagined to be a web-like structure that connects the elements of a system or life cycle and thus enables an understanding of how items are related and dependent.

GAMP5 (Main Body section 4.2.5.4) states that traceability is a process for ensuring that:

• Requirements are addressed and traceable to appropriate functional and design elements;

• Requirements can be traced to the appropriate verification.
  

[Note this implies a relation between design elements and verification.]


But when you think about what traceability is really about and why it is important, you can see that this is way short of what we should consider.

Traceability underpins the system life cycle, doth during development and (if you get it right) during operation. But without effective traceability management most other process would not be practicable; indeed the overall objectives of validation would be pretty hard to realise.

Here's some examples of how effective traceability management enables other areas to perform effectively:

Change Management; very important, but change to a single configuration item will often have impacts and dependencies on others . So to ensure and maintain the veracity of the system architecture (both technical and documentation) we need to know what the relations are between configuration items. So when we, say, change the code that generates a report traceability can highlight that there are also technical specifications and user procedures that need to be updated.

Design/Development; OK, so we have a set of requirements and these are worked over by the development team into a set of design specifications, describing how our requirements can or will be met by the system. How can we verify that all of our requirements are actually described by this design? We can just walk through the requirements one by one and see how the design fits. But in reality, design plans are liable to change or requirements may be expanded or reduced; there may not be a solution ready for some requirements until a later date. Maintaining traceability between requirements and design can ensure that all requirements are addressed and none get forgotten. And if we get this right, this traceability will be invaluable during operational support, since it becomes like a map around the system; the people doing the support will normally not be the same people who built the system, and they will need a map.

Test Planning and Management: Test Planning requires a known list of things to test. Effective traceability provides a list of items that may require testing, and the dependencies for such testing, such as security authorisations related to a functional area.
During and following Test Execution, traceability can be used to demonstrate the execution status of all tests so we can easily track where we are in the testing cycle. And perhaps most importantly, at the end of testing we can use traceability to show that everything we needed to test has actually been successfully tested.

Incident and Problem Management/CAPA: As with Change Management, the analysis of incidents and problems is aided by understanding the relationships of the configuration items involved. For example, a software error presented from one area of system functionality may be the result of a bug in another area. Traceability serves to highlight possible areas of resolution.

Risk Management: Risk assessment and control should be performed at various levels throughout the development, e.g. high level project risk, detailed functional risk. Risk assessment may identify risk scenarios related to requirements/design, and risk controls may be implemented as elements of system design, which should then be verified as effective. Managing the traceability between system elements and their risks and between risks and their mitigation, and between mitigation and their verification are a necessary part of a good risk-based approach to validation.

So from the simplified GAMP5 model above we can develop a real-world model of relationships:


This illustrates the full range of relationships that could/should be defined for a large complex system (e.g. a global ERP system). But remember that any validation process must be scaled appropriately. Scaling of traceability should be primarily based on system complexity and size; e.g. for a simple system with no configuration, used "out of box", it may be acceptable to only relate requirements to testing. Another consideration is what tools are available to manage the traceability.

*By the way...my favourite film, if I had to pick just one...Casablanca.