Operationalizing Transformation Pilots in Life Sciences

As an industry, we have spent the last few years exploring the emerging technologies that will enable lights out manufacturing (i.e., how can a plant run without people present). The term autonomous operations is now ever-present in what we see and read.  This concept is intended to capture the promise of AI and robotics to not only enable plants to run without people present but to continuously optimize the plant to achieve better outcomes. It feels like that vision is a long way off.  Not because the technology is not there, but because there are many people and cultural changes that need to occur before we are comfortable allowing technology to run our facilities.

We have collectively built and run pilot programs based on technology feasibility, but now we must shift the focus from the technology to pragmatism and value. Most IT/OT programs fail to scale or fail to deliver the promised value. Why have we failed? Because we’ve been trying to manage new challenges with old ways of working. Scaling technologies is not a new proposition, but scaling in the age of complexity and the age of AI is.

Beyond Traditional Approaches (Waterfall and Agile)

For projects that are following well-worn paths, standard waterfall project management is sufficient. The waterfall approach succeeds when requirements are well-defined and when industry benchmarks exist. Scoping costs and timing is fairly straightforward and can be managed.

For projects with greater complexity and less certainty, we have typically turned to Agile project management. Agile, and its iterative sprint approach, can effectively create and maintain alignment between user requirements and the technology being built to meet them. As a methodology, Agile still succeeds for projects we might call “first in kind for you,” initiatives that are new to an organization but have established industry precedent. The technology options are well-defined, although the user requirements and business outcomes may not be well-understood.

What happens when we seek outcomes that are more transformative, that require a new operating model and new ways of working? Many organizations are looking for an approach that leads to “true innovation,” in which not only the requirements but the technologies and how we work are not well-defined. A waterfall approach is too slow and cumbersome to navigate a technology landscape where the options are constantly evolving. Even an Agile framework, with its inherent focus on managing risk, fails to deliver the ambitious outcomes that transformation projects aim to achieve because they do not focus on the people and culture.

True innovation is about getting to a different scale. And if we want new results, we need to start with a new approach: an operating model that is flexible enough to account for uncertainty, too many options, new ways of working, and a workforce that needs to be led into the unknown.

We are no longer building to a set of well-defined requirements; we are building to achieve business objectives and validating to the outcomes we want to achieve. In this new operating model, we track to an overarching goal, measure progress along the way, prioritize effectively, and adapt, shift, and course-correct as often as necessary.

4 Factors that Drive Transformation

1. Lead with the Desired Outcomes, Not Requirements (Lighthouse)

A scenario recurs across life sciences manufacturing: a company encounters a challenge and then matches a set of requirements to a software system that may address it. The system is launched and the initiative is completed. Weeks or months later, it becomes clear that the original problem remains unsolved. The mistake was starting technology requirements rather than building towards outcomes and addressing the way people work.

It is better to start with a Lighthouse: a clear set of outcomes at which every downstream decision is directed. The Lighthouse is broader than the system or platform. It is the aspirational, cross-functional outcome an organization aims to achieve long term. The Lighthouse may be so ambitious that the company never fully reaches it, but as a beacon, it keeps the team working towards it.

Autonomous operations is an excellent example of a Lighthouse initiative (one shared by many organizations). The path there is uncharted, but the mandate is clear: take the journey, be ready to pivot along the way, build a continuous learning culture, and always stay focused on the outcome. The Lighthouse only survives if senior leadership owns and protects it over time, relentlessly advancing the vision and passing the torch to the future leaders of the business.

2. Define What Is Important and When You Are Done (Success Criteria)

If the Lighthouse tells the organization where it is going, success criteria tell the organization the speed at which it is making progress toward the Lighthouse. The two work in tandem: the Lighthouse is directional; success criteria are concrete and measurable. Determining the success criteria depends entirely on what the organization values. Take autonomous operations as the Lighthouse. Three companies could share that vision and measure progress in completely different ways:

1. Labor efficiency: share of work that runs without human intervention
2. Workforce continuity: productivity gains while maintaining current staffing
3. Waste reduction: fewer inputs achieve baseline output

Same Lighthouse; three different sets of success criteria. All three are legitimate. None are derivable from a template. Success criteria are a leadership decision, because determining them is a values exercise rather than a technical one. Once we know what criteria we are measuring, we need dimensions to measure across. At Stellix, we evaluate the return on digital investments across four dimensions:

1. Fast (Speed): The time between when an action is needed and when it happens is minimized. Work moves without delays.
2. Efficient: The least amount of resources—time, money, and effort—required to get the job done. This is where companies often focus because efficiency ties directly to cost reduction.
3. Enjoyable: The work itself becomes more meaningful and engaging, rather than repetitive or rote.
4. Transparent: Performance is visible and measurable, often for the first time. Organizations can see how operations are actually running and where to improve.

Success criteria measure business outcomes, not whether the project plan is complete. This method for measuring progress avoids a common pattern that leaders may recognize: an extensive project that is completed on schedule and on budget. Every box is checked, but ultimately, the business runs no better than it did before.

3. Understand the Differences in the Problem Set (Segmentation Requirements)

Certain requirements are non-negotiable in life sciences—security, IP protection, compliance, managing regulatory risk—but not all requirements carry that same weight. Treating every requirement with equal importance, and conflating critical and non-critical segments, creates downstream challenges. For example, we cannot treat cybersecurity and user experience the same. One is absolutely mandatory; the other may be a high priority requirement that aligns with the Lighthouse, but it is still negotiable.

Neglecting to segment requirements up front can lead to under-resourcing critical requirements and creating significant risks. And overplanning in areas that will naturally evolve isn’t an effective use of resources, either. When we default to treating all requirements equally, time and cost of the project increase, but the value derived does not. On the other hand, when we get segmentation right, with a clear prioritization of requirements, the work that follows is more focused. Rigorously plan for key requirements; maintain flexibility on everything else.

4. Know When It’s Working and When to Pivot (Operate Using Phase Gates)

A detailed roadmap was once considered a prerequisite for a project’s success: the more detail added, the more successful the project was likely to be. Today, that kind of approach is more likely to slow a project down or take it off course than to accelerate results. Rigor in planning is still paramount, but building a step by step roadmap to reach a specific endpoint isn’t feasible for a Lighthouse like autonomous operations. Technology is too dynamic, and organizations are too complex, to fully map the journey from A to Z before you’ve started at A.

Where a road map is not possible, trying to plan every step only slows progress and creates “analysis paralysis.” A better solution is to use a phase gate approach, where each gate is an opportunity to pivot and iterate as new information emerges. With the foundation of the Lighthouse, success criteria, and segmentation in place, we can ask a diagnostic question at every phase-gate: Does the current focus still align with where the organization is trying to go?

This approach requires more bottom-up thinking. Every process, every assumption, must be questioned. We will not benefit from bringing current ways of working into the transformation unless they are critical to achieving the outcome. It was commonly accepted that phones needed keypads—until we got the iPhone. Today, AI allows us to conceive something like user experience differently: does a better user experience mean an improved graphical user interface (GUI), or would the experience be better with a voice interface only? We need to ask questions like these at every step of the journey. 

Successful Deployments Require a More Flexible Approach

The technology to deliver autonomous operations may already exist. But to realize value from technology, we also need the new operating model built and deployed. A Lighthouse tells us where we are going. Success criteria tell us how fast we are moving. Segmentation tells us what’s important. And phase-gates give us points to reassess our journey along the path without losing the direction.

I’ve seen newly installed systems that were technically implemented perfectly but were ripped out and replaced because they failed to meet user requirements. And I’ve encountered numerous instances when data visualization software has been used to catalog and configure hundreds of millions of data points, but the teams that need to use the information find that the data mapping renders it effectively unusable. Millions of dollars and months, if not years, are wasted when a project is well-executed but fails to deliver the intended outcomes.

How much of the traditional ways of working, with their deterministic pathways, should we continue to apply in the age of AI? Should we treat AI more like humans that we govern and less like technology? With its immeasurable options and ubiquity in every aspect of the way we work, AI adds a great deal of complexity to our environment. It also adds opportunity. We have the potential to design and build truly innovative solutions for life sciences manufacturing, but only if we embrace an operating model that acknowledges and accounts for the appropriate level of uncertainty.

The companies that fail to do so are the ones whose AI investments will sit unused years from now, whose autonomous operations programs will stall out in pilot mode, and whose cost-reduction mandates will lead to activity that does not produce the innovation they seek. Other companies will stay focused and flexible, and they are the ones most likely to succeed. I look forward to digging deeper into this conversation at Stellix’s next Aspire event on June 4th. Reach out if you’re interested in joining us for From Pilots to Production: Building the Digital Foundation for Autonomous Operations.