July 24, 2017
When new buzzwords are introduced, they inspire a new way of thinking. As they are adopted more and more, their meaning is often clouded and we don’t know what to think anymore. Just think about the word “innovative." It has been used so much – “we are the most innovative!” that you almost lose trust in the word. Related – shouldn’t the customer determine who is innovative?
Suddenly I’ve been seeing a lot of messaging around agility in Randomization and Trial Supply Management (RTSM) or as some refer to it, Interactive Response Technology (IRT). Is “agile” becoming the new “innovative”?
Then I paused. Does everyone understand what it truly means to be agile with regards to software development? What about project delivery? Both are equally important, but I will argue that agile software enables agile project delivery and not the other way around (which has its limitations).
If I didn’t know what agile stemmed from I’d automatically equate the term to simply being flexible. But flexible how, with what? The technology? Services? Timelines? Without context, you are left to your own interpretation. So herein lies the challenge. Our industry is craving flexibility as clinical trials are becoming more complex. How do you cut through the clutter and gain much needed context behind this new wave of agile?
Start with the basics. What is agile, really? Fundamentally, agile is a software development methodology that:
- Accelerates the delivery of high-value projects through iterative development sprints
- Enables continuous feedback and allows for faster changes in system design to meet customer needs
- Produces higher quality, more reliable systems
However, not all RTSMs that reference being agile are based on the software methodology. Can you have agility in project delivery that is not grounded in agile software development? Sure. But I will argue there are limitations to how flexible you can be, and with the overall benefits the customer will receive without it.
How will you know the difference and how that might impact your study? Arm yourself with a series of questions to weed through all the various interpretations of the term.
What are the Top Questions You Should Ask about an Agile RTSM?
1) Was the RTSM developed using agile software methodology and/or are you using “agile” in the context of delivery?
It is critical to understand if the term is being used to describe a software methodology or simply being flexible in delivery. Systems developed using agile methodologies can dramatically accelerate study start-up and mid-stream adjustments because flexibility is literally built into the system. Systems that are not developed based on an agile methodology (and on a modern technology stack/cloud-based platform) face limitations in terms of flexibility and speed to adapt to a customer’s evolving needs.
2) Is the RTSM 100% configurable? If not, what % is customized vs. configured?
100% configurable RTSM systems are designed to adapt to the customer’s needs. It has the feel of a 100% customizable system without the immense cost, time to build, and limited flexibility. Any degree of customization (even as little as 10–20%) involves coding, which follows the traditional waterfall process of designing, developing, testing/validation, and deployment. That has a direct impact on your study agility.
3) What is the feedback process during system development? When will I see the full, deployable RTSM?
An RTSM developed using cloud-based, agile software methodologies should have the ability to show customers the complete, deployable system before signing off on specifications. Customers then provide feedback and influence system design and development priorities by reviewing and refining several iterations of the system before reaching a traditional timeframe for user acceptance testing (UAT).
4) Can you quantify the impact of small changes on your study timelines and budget? Do all changes require custom code?
This question goes back to how configurable vs. customizable the RTSM system is. With 100% configurable systems, updates, and changes are made without disruption to the customer. Partially configurable systems can range between 2–6 weeks to implement a small change. Changes are unavoidable in the bio/pharmaceutical industry. You should have a clear understanding of how changes impact your study progress from a systems perspective.
Agile RTSM delivery should empower client services leads to be problem-solvers, not box checkers. They should be an extension of your trial team and leverage their expertise to solve unexpected issues – feeling ownership and accountability to the solution. Understanding more about the expertise, structure, and governance of the client services team is crucial to ensuring transparency and collaboration.