This article first appeared in Life Science Leader
Pharma companies sometimes see business process management software (BPMS) as a silver bullet that can resolve many process-related issues. This is because a BPMS can automate workflows, enforce process and data consistency and quality, and lay the foundation for further AI and automation efforts.
Once a pharma organization has decided to deploy a BPMS, the priority becomes implementing the platform in a way that both best gains user acceptance and fulfills value drivers as quickly as possible. The traditional options are an agile or a waterfall approach. Though a waterfall approach is popular and generally reliable, it can be slow and cumbersome. On the other hand, a full agile approach is not ideal for BPMS implementation. The best option for maximizing the efficiency and effectiveness of the implementation can be a hybrid methodology.
A waterfall approach, in which planning, design, development, testing, and go-live have a strict sequential cadence, has clear benefits: robust documentation, defined and agreed upon set of requirements, clear scope for testing, and well defined and understood stage gates; Pharma companies naturally gravitate toward waterfall because the extensive documentation and clear structure are easily demonstrable to auditors and regulatory authorities. On the other hand, the flexibility and frequent and iterative user feedback of Agile can make it another compelling default option for some organizations. However, using a pure Agile approach for deploying a BPMS will be a challenge.
A pure Agile approach releases a certain amount of product components, or features, per each sprint to the end user. Successive sprints add more and more features until the solution is completed; this means that the end-to-end structure does not need to be finished and released until the end of the final sprint. However, since BPMS solutions are workflow-based, with each step relying upon the previous one, the entire end-to-end process structure must be completed up front. If this is not done, the implementation will not be able to proceed effectively. To use a hypothetical example, if a company is implementing a BPMS to guide label change requests, you could not deploy features for quality review until the workflow is in place to bring you to that point; individual features simply cannot be deployed isolated from the workflow, as they depend on the workflow to exist.
Furthermore, Agile’s incremental release structure can prove problematic for in-flight processes, since in-flight BPMS processes cannot have new features added to them. Using an example cited earlier, imagine that you are working on requesting a label change. After completing the required sections, you submit your request form. A week later, you discover that your request is incomplete and cannot be processed! It turns out that there was a recent software update and now need to provide additional information; the update did not apply to your request because it was in-flight. Imagine if the same situation occurred for the submission of critical, time-sensitive regulatory documents to the FDA; the impact could be disastrous.
Though a pure Agile approach may not be feasible for BPMS implementation, bringing certain Agile tactics into a waterfall approach will be more effective than a traditional waterfall approach on its own. These tactics will drive collaboration, align project teams with users and stakeholders, reduce timelines, and focus implementation efforts.
The following Agile components are particularly key to a hybrid methodology:
We have direct experience with a hybrid approach. During a recent engagement, we led the business design of a BPMS for a major pharma company. The system was intended to guide the requesting and authoring of Risk Management Plans (RMPs), as well as the tracking of post-regulatory commitments. We recommended a hybrid waterfall/agile approach to system design, partially because there was a tight schedule for implementation.
Thanks to the frequent demos and daily standups, development issues were fixed rapidly in hours instead of days. Furthermore, the iterative testing approach mitigated time and budget constraints during validation. Program Increment planning sessions, a key to development within agile sprints, gained particularly positive feedback from the client, as it was easy to visualize and comprehend the effort needed to deliver the system within a certain time frame. Finally, thanks to the constant feedback of users, a system in line with user expectations was delivered with minimal change management interventions.
Since a full agile approach is not recommended for BPMS implementations, a different innovative methodology is needed. A hybrid approach can bring greater value to a BPMS implementation than a strictly waterfall effort by ensuring stronger alignment between the business and design and development teams, maximizing the efficiency of development and testing activities, and driving collaboration. In turn, this can reduce timelines and costs and prevent delays to delivery.
Did you know the top 10% of financial performers are 30% more agile than the rest?