Evolution in CSV Part 3 of 6: Downsides of the Document

Evolution in CSV Part 3 of 6: Downsides of the Document

The document-based approach, whether paper or electronic, was designed and implemented to align with a more traditional Waterfall approach to development and testing.  Defined schedules with phases mapped out and executed in serial fashion could more easily account and plan for the document-based approach to CSV during the planning phases.  This approach also allowed for the validation documentation to be drafted with a certain level of accuracy as each phase would, for the most part, maintain the requirements outlined in the planning phase.   

The nature of an Agile methodology requires flexibility in a fast moving, cross-team process in which requirements can change quickly and often.  Iterative based sprints and releases of functional components of the full application require that teams be nimble enough to adapt to ongoing changes based on feedback from business groups and end users. To maintain ever moving targets and schedules, ongoing reporting across projects and teams at a granular level is required to maintain cohesion across the software development lifecycle.  A static validation document with pre-defined requirements and phases quickly falls down in this methodology. 

Without constant maintenance and revision attention, validation documentation soon becomes far out of sync with the ever-changing project requirements.  This constant changing in requirements and reauthoring of the validation documentation then requires more rounds of review and approval. More rounds of review and approval then require more down time and delays before the rest of the team can start to execute those requirements.  Requirement traceability becomes an onerous, manual task that is in a perpetual state of change.  Project reporting when relying on a static document does not allow for a wholistic view of project status. Validation and QA teams are constantly at odds with Development, Business and IT teams.  All of this adds up to an incredibly inefficient use of resources, time and budget. 

Where document-based CSV was previously an annoying bottleneck in a Waterfall methodology, it quickly becomes a freeway closing, multi-car pileup in an Agile environment.   

Unfortunately, the inefficiency doesn’t end there.  When the FDA comes knocking, teams need to have their ducks in a row and that means well organized, accessible controlled validation information.   Unfortunately, use of documents make it difficult to quickly find specific information that an auditor may be looking for.  However, once the focus shifts from “documents” to the underlying validation “data” filters and queries can be used to quickly find what you are looking for.     

The importance of validation and compliance in a regulated environment cannot be understated and no matter how much of an impedance maintaining a document based approach may be, if it has been leveraged to maintain relatively good standing with the FDA, then it becomes very difficult to persuade Compliance/Validation and QA teams to deviate or adopt any major changes to the status quo.  Afterall, no matter how inefficient the document-based approach to validation may be, we are talking about a regulated environment and introducing major changes in methodologies and solutions comes with considerations and implications that all teams need to weigh out.   

As difficult as proposing changes in a regulated environment may be, remaining tied to outdated methodologies should not be an option.  The document’s place in modern CSV is proving to be nothing short of limiting, if not altogether impeding to today’s development and software quality requirements.  Organizations need to start having dialogue among their teams to formulate and promote an exit strategy from the document. 


Share to: