I once thought that having a quality and process ally like the FDA was going to be a great thing, but that soon turned out to be a double-edged sword. Fortunately for the team, I was able hire an ex-FDA auditor to work on the specifics of dealing with regulatory commercial compliance. His knowledge and experience in citing high-risk areas was instrumental to our success and to remaining within budget. Getting to the compliant state increased my team’s efforts and cost close to 40 percent more when compared to a project with no regulations, and ongoing maintenance costs (depending upon the rate of change for the regulated components) increased to around 30 percent.
Avoiding the Land Mines
Let’s examine some aspects of the Agile Manifesto and set in motion some changes in executing agile delivery for regulated data and processes.
Individuals and Interactions over Processes and Tools
The first part—“individuals and interactions”—will not change. Ensure that your compliance team is a stakeholder and an active contributor in delivering a compliant system. There is a clear migration toward pooling resources as regulations cross and overlap between many internal business units, but no business will remain compliant without a solid approach and long-term strategy. Consolidate compliance through a single, internal audit department supported by tools that streamline the process of achieving and maintaining the compliant state.
Tools will not change, as they are efficient mediums to maintain the documents or artifacts needed for an audit. Processes are at the heart of what regulatory compliance talks to. One must have standard, documented processes and methods. Document how processes are defined, governed, implemented, and monitored. In other words, create an SOP on creating SOPs. That is not a joke. An SOP on compliance training needs a special citation and should not be overlooked. Everyone involved in delivering a regulated application must be trained on those regulations and what it means to be compliant. Periodic training sessions must also be part of the training SOP. In our organization, Big Q was responsible for ensuring that the organization was trained.
Working Software over Comprehensive Documentation
Software that has regulated data and processes must be working and, of course, validated. A compliance strategy already must have decided how comprehensive the documentation needs to be in order to be compliant. Get buy-in from Big Q on how it will be stored, secured, accessed, and reported. Once you have deployed the regulated aspects of the software into production, documentation must be submitted and complete. There is no way around the documentation requirement.
Handling compliant systems via agile delivery must be done carefully, especially when deciding when to introduce the regulated components into the production environment. In waterfall delivery, this problem is much easier to deal with. The final certification of compliance can be completed prior to the production release, or it can be held off with regard to the regulated components and deployed closer to production. During release planning in an agile delivery project, the team must make these decisions and decide the best time to introduce the regulated components into production. Once the regulated components are in production, they must be continually certified as each subsequent production deployment is made.
About the author
Paul Fratellone is program director of quality and test consulting in the testing business unit of MindTree. Paul’s career of more than twenty-five years in information technology has been concentrated in testing, compliance, and quality management. He strives to achieve consistent execution to attain a predictable level of quality that is commensurate with the investment and enables leadership to objectively measure the success and continuous benefits from these investments.
