Why A Hybrid Approach Is Best For BPMS Implementations

By John Heid

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.

WHERE AGILE BEATS WATERFALL AND VICE VERSA

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.

KEY AGILE ELEMENTS TO INCORPORATE INTO YOUR APPROACH

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:

• Development in Agile Sprints: The sprint structure of Agile can be modified to fit BPMS implementations rather easily; an end-to-end workflow just must be deployed first. Features can still be assigned to specific sprints to prioritize and focus developments activities. This can potentially reduce timelines and costs while ensuring that critical business processes continue.
• Iterative Testing: In each sprint, requirements can be tested as they are deployed, mitigating a chaotic rush of formal testing at the end of the project. This also de-risks the testing and validation processes, as issues can be resolved in real time.
• Daily Standup Meetings: Daily standup meetings can help quickly and effectively resolve development queries, especially when working with an offshore team. This helps prevent delays and ensure clearer alignment between business architects and developers.
• Frequent Demos: The frequent demos inherent to Agile prove to both users and stakeholders that requirements have been captured, implemented, or modified correctly. While frequent user demos are key to any agile or hybrid agile project, they are especially critical to BPMS deployments, since BPMSs tend to have higher amounts of user interaction.
• Product Owner Role: This role can be compared to a business partner with strong product knowledge. The product owner oversees the design and development of the system, ensuring that the vision is clear to the entire team. They also can make decisions on behalf of the business to change, add, or remove requirements, as opposed to making change orders. This streamlines development efforts and focuses additional energy on aligning implementation efforts and product capabilities with business expectations.

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.

John Heid is a life sciences and implementation expert at PA Consulting. He focuses on the design and implementation of innovative software solutions, primarily in the drug safety, compliance, and regulatory spaces, for major pharmaceutical clients across the US. You can contact him on LinkedIn at https://www.linkedin.com/in/johnheid1/