What’s in a Name?
Our client was in negotiations with a very-well-known integrator for a year regarding automating its core processes. The automation involved developing a customized, “one off” EDC application by customizing a core product supposedly built for this purpose. Prior to finalizing the Statement of Work (SOW) with the integrator, our client asked us to assess whether the integrator meets regulatory industry standards and our client’s operational/business requirements.
After spending a day-and-a half at the integrator, we identified too many project-related unknowns for our client to be comfortable with the quality and timeliness of the deliverable. Listed below are selected examples:
- The integrator never worked with the core product that our client was about to license.
- Neither our client nor the integrator ever performed a detailed assessment of the core product or the developer of the core product.
- Even though the SOW indicated that some time was allocated for QA/QC on the part of the integrator, the integrator could not identify specifically which activities/documents within the system development and validation processes would be QA/QC’d.
- Our client was relying on the integrator to provide them with the requisite SOPs. However, the integrator indicated that it always uses client-specific development or validation SOPs and does not have of its own SOPs that our client could follow.
- End-user training was not in the scope of the SOW.
- The integrator could not define what the concepts of “Basic” or “Full” functionality meant, or explain the differences between the two, so it was not clear what our client was buying into.
- The bases for “GO/NO GO” decisions that would have an impact on the project’s timelines and budget were not clearly defined.
- The integrator indicated that it would take no ownership regarding whether the customized EDC application will work because our client – and not the integrator – chose the core product.
- The integrator offered a very limited number of hours of transition support to our client after the system went live.
- The SOW did not include wording regarding the integrator’s commitment to ensuring that their deliverable will support 21 CFR part 11 compliance, nor did any of the documents identified in the SOW mention compliance to this regulation. Furthermore, the SOW stated that the integrators’ interpretation of regulations may be different from that of the regulators and that the integrator’s interpretation would take precedence.
So what”s in a name? The very-well-known integrator would have introduced significant business risk to our client; the system may not have been implemented on time and on budget, and on-going transitional support would have been minimal. Regulatory risks could have been introduced as well, given the minimal attention noted above regarding regulatory compliance and lack of QA oversight.
Based on the results of our due diligence, the business and regulatory risks were addressed through appropriate language that was included in the SOW and, where applicable, additional controls (e.g., requesting limited transition support from the developer of the core product) built into the project, to protect our client’s position from the legal, operational and regulatory compliance angles.
The moral of the story is that a “name,” even a very-well-known name, should not preclude a due diligence. Our practical advice allowed our client to complete the project on time and budget, and within the regulatory compliance requirements. This would not have been possible without our thorough assessment of the integrator.