ERP projects fail in all industries. And they get it wrong more often, and more badly, in the life sciences. The reasons are predictable, and most are preventable—if the organization knows what to look for before the project begins.
This article will explore the most common failure patterns in life sciences ERP projects and the factors that differentiate the organizations that succeed.
Why life sciences projects fail more frequently
The factors that make life sciences ERP implementation more difficult than commercial implementations are the same factors that make the industry operationally complex: regulatory requirements, specialized workflows, validated system standards and compliance obligations that intersect with every system design decision.
These factors make implementation more complex, and errors are more consequential. A misconfiguration that requires a workaround in a non-regulated environment is a compliance remediation project in a regulated environment. An approach to data migration that suffices for a commercial company does not suffice for an organization where historical lot records are regulatory artifacts.
The generalist ways of implementing things are not built for this kind of environment. In the context of life sciences implementations, failure is the expected outcome.
Top 5 failure patterns
With knowledge of the failure patterns, organizations can design against them. The 5 patterns that account for most troubled life sciences ERP projects include partner selection without vertical depth; compliance requirements not scoped at the start of the project; data migration as a technical exercise; a big-bang go-live approach; and poor change management for regulated workflows.
Most life sciences ERPs fail because they choose a partner without vertical expertise. It does not create visible problems at the start of the project. It generates them during design, when choices regarding compliance configuration are made, and during go-live, when the system fails to meet regulatory requirements.
Not scoping compliance requirements at the beginning of the project is the result of a failed partner selection and inadequate internal preparation. If 21 CFR Part 11 audit trail requirements, validation documentation obligations, or FDA traceability requirements are not in the implementation scope, they become mid-project scope changes. When the scope of a project changes during execution, the project takes longer, costs more, and implementation in compliance-critical areas is rushed.
If you consider data migration as a technical exercise, unvalidated migration records are created, data quality issues continue after go-live, and traceability gaps exist between the new system and historic records. In regulated environments, historical data isn’t a nicety to the live system. It’s the evidentiary record that supports audit responses.
A big-bang go-live approach puts all the risk in one point in time. If the organization reaches that point with unresolved compliance configuration gaps, then it goes live with an audit-exposed system. Phased go-live reduces this risk by exposing compliance requirements to be managed at each phase boundary.
Regulated workflows suffer from poor change management that leads to adoption failures for quality, compliance, and operations teams. No matter how well a system is configured, if the people who are most important for regulatory success - QA, regulatory affairs, and production supervisors - do not trust or use the new system properly, the system's compliance value is not realized.
What successful projects do differently
Here are 5 characteristics of organizations that execute life sciences ERP projects on time, on budget, and with systems that will pass regulatory muster.
They choose partners with proven vertical depth. The implementation team has regulatory experience with the client and not general life sciences experience.
They look at compliance requirements before the project starts. Before any configuration work, all applicable regulatory frameworks are identified and mapped to the system design requirements.
They regard data migration as an event of validation. Historical data is cleaned, mapped, migrated, and validated with evidence. Migration is subject to the same requirements as any other part of the validated system.
They phase the go-live to minimize risk at each boundary. At each stage compliance requirements are validated before the next stage can proceed.
They believe in change management for regulated teams. QA, regulatory affairs, and operations staff are involved in the design, trained on real workflows, and supported during the transition period.
Recovery options for projects in trouble
Organizations that find their implementation project in trouble have 3 paths to recovery.
Current partner resets scope and timeline. If the partner is good but the project scope was defined incorrectly, a formal reset of scope, with compliance requirements properly scoped and a revised timeline, can get the project back on track. An open discussion of what went wrong and a joint commitment to do things differently.
Augmentation of partners. Where the existing partner has sufficient general capability, but not the specific compliance expertise, it is appropriate to bring in a specialist firm to address particular compliance gaps while the generalist firm continues with the broader implementation.
Partner substitution. If the current partner’s work has caused fundamental design errors that cannot be corrected within the current engagement, then replacement is the appropriate response. This is disruptive and costly, but less than implementing a non-compliant solution and remediating it post go-live.
The earlier in the project the recovery action is taken, the less expensive the remediation. The organizations that find trouble early and take decisive action are invariably more successful than those that wait until go-live to validate their concerns.