This is a question that is asked a lot in a regulated environment. It has different meanings in different situations. For a Product Manager of commercial software it is a question of "how much feature function can I get into my product in the next release cycle?". For the in-house, bespoke system Product Manager the question becomes, "What is the right release cadence to service my business?" Both situations face the same challanges; getting them wrong can be disastrous to both.

The challenge

We are regulated to ensure that we construct systems in a responsible way and can demonstrate that with clearly defined processes and documented evidence. However, these processes and documented evidence come at a hefty price. For the commercial software Product Manager this means that there is less feature function for the next release as resources are burned following, and documenting the necessary processes and outcomes. For the bespoke business software Product Manager the question is how often they can release. The need is to get the business benefit as quickly as possible, without spending a disproportionate amount of time on process and documentation. As a former Product Manager for a large central lab in the Clinical Trials business I can still remember the times when new features were critical to the success of business. However, delivering them in the necessary time frame was problematic with the burden of process and especially documented evidence of those processes.

After all this, there is still the question of control. I am sure we have all sat through internal and external audits where our colleagues in QA question our ability to continue to release software in a controlled fashion. The fear is that with so much feature function injected to a product or the speed and frequency of delivering sorely needed functionality to the business, the process will be compromised along with quality.

So what do we do?

One approach has been to employ electronic systems to help with the collection of the documented evidence. This has helped but comes with its own set of challenges. It is hard to find the different systems for the components of a system validation (user requirements, functional requirements, design, defect tracking, test cases, and so on) that will ‘play nice’ together. Then, integrating these tools becomes exponentially more complex the more one employs, and usually involves a degree of manual intervention; e.g., data export/import. All of which leads to a higher risk of error, requiring the implementation of QC process to ensure correctness ... and so we are back to where we started with a heavy process restricting our ability to deliver more and faster. But now we also have a number of tools to maintain. Streamlining authorization with electronic workflow and signatures has been a help. But again, using the workflow engine with disjointed validation tools is not as effective as one would hope.

One tool to rule them all

There is clearly a need for a single, fully integrated system validation tool that can collect user and functional requirements, and tie those requirements to the code that implements them and the test cases with execution evidence that verifies them. This tool needs to be specific to needs of our regulators - namely the FDA. Too many times organizations have employed general tools that fall short of the 21CFR Part 11 needs as far as traceability and audit-friendly features. With a fully integrated tool, specifically designed for 21CFR Part 11 system validations, the authorization workflow can now be automated effectively, even in a global environment with the challenges of multiple time zones.

 AGILEPART11 is such a tool. It is specifically aimed at FDA system validations and designed to decrease the effort to collect the artifacts needed for satisfying the burden of proof. It's also, organized to easily provide access to these artifacts during audits, demonstrating the control that regulators demand.

Now, going about convincing the auditors that this is true… a subject for another post.