Overcome The Challenges Of Selecting A New Clinical Technology
By Ed Miseta, Chief Editor, Clinical Leader
Despite the best intentions, most companies will struggle to execute new technology selection and implementation. This fate may be more pronounced in the biopharma clinical development arena where the highly regulated, conservative, and somewhat luddite nature of our industry makes us averse to adopting and implementing new technologies. Still, this aversion does not deter companies from wanting to employ new technologies that can positively impact their operations. As Rob Scott, chief medical officer at AbbVie noted, “You cannot do today’s job with yesterday’s methods and be successful tomorrow.”
“Over the past several years, clinical teams seem to be willing to push past this intrinsic aversion and profit from the benefits new technologies can offer,” says Larry Florin, president of LBF Biopharma Consulting. “However, this enthusiasm is tempered by multiple factors including a risk of failure. Biopharma leaders want to ensure their investments of time, money, and effort will result in useful and quantifiable outcomes that bring tangible value to their organizations.”
There are valid reasons why the pharma industry can be perceived as a laggard in terms of embracing emerging technologies and novel applications. However, Florin believes there are steps that can be taken to help ensure success when electing to make a technology investment.
This article is the first in a four-part series where Florin will share his advice and expertise on overcoming the common challenges biopharma companies face in identifying, selecting, and implementing new technology.
Get To Approval
Your straightforward answer should address one or more of the following value propositions, in no particular order of importance:
- Improve quality and/or productivity
- Decrease risk
- Lower cost
- Increase data velocity
- Enhance data analysis and interpretation
- Accelerate cycle times
- Replace less effective (and often more costly) legacy systems and/or processes
- Reduce patient/investigator burden
If you prepared well, then you should expect a third question, ‘Will the new technology replace (an) existing systems or processes?’ Your answer should illustrate the limitations of the incumbent system(s) and/or process(es) and succinctly point out the improvements to be gained by the new technology. Those improvements should be aligned with the value propositions cited above. Do not, however, try to argue for a new technology investment just for the sake of trying to be innovative.
To illustrate this point, Florin provides a quasi-fictional example: Procuring an analytics platform. You can answer the first question by identifying key value elements to support the proposition, such as accelerating and enhancing data analyses and interpretation by permitting multiple functional areas to have a single, comprehensive application. The application can take data from disparate sources to permit users to view and analyze data in one location, which leads to faster, better-informed, actionable decision-making that will improve overall quality.
According to Florin, the first two questions naturally segue to the third, describing how this fictional organization currently views and collates data to make decisions. A labor-intensive process may involve dozens of people. They must find and collate data from individuals, systems and spreadsheets (e.g., EDC, clinical laboratory reports, CTMS, IRT, startup teams, other 3rd party vendors, finance, etc.) just to prepare their output. This is done to permit others to monitor what is going on within each functional area, as well as across a complex, global project. These outputs generally are not in a form that allows for additional analyses, thereby making cross-functional decisions more daunting.
“However, the analytics platform can obviate much, if not all, of this time-consuming effort by integrating these data and presenting them in an intuitive visualization format that can be further interrogated,” says Florin. “Additionally, it can permit functional teams and individuals to develop their own visualizations and reports. Therefore, after amortizing the upfront investment costs to purchase and to implement the system, one can measure the time, quality, cost savings, and efficiencies gained as information will be readily available that is both informative and actionable.”
Florin adds you should have a clear understanding of how the technology will impact your development programs, particularly the affected functional departments, each individual trial, and/or your own ability to do your job better. Adopting a new technology, will not necessarily, by itself, add value. You need to take the time to think through how you’re going to use the technology and what important value contributions it will make to the business and particularly the affected stakeholders.
A Management Conundrum
Florin describes this situation as a common project IT (and process) management conundrum. You believe the new technology offers value, but you may not fully appreciate the difficulty of building enthusiasm for it with colleagues and key stakeholders. Unfortunately, not properly setting expectations almost always spells failure.
“To avoid setbacks, always be mindful of organizational dynamics,” suggests Florin. “Beyond keeping senior leaders informed, identify all key stakeholders including influencers and ensure their input is effectively utilized while managing naysayers who will be circling like vultures waiting for an opportunity to sabotage the project. Also be sure to solicit input and approval from primary business users and ancillary groups such as finance and quality assurance. The opinions, feedback and support of these stakeholders will be valuable and beneficial. Get them onboard and keep them informed. Anticipate their questions and concerns and be prepared to address them.”
Now that you have garnered support, forge ahead and find that new technology. This is also a good time to make an honest appraisal of your knowledge, skills, and available time. There are many components associated with a complex and expensive technology procurement and implementation exercise. Identify a selection team comprised of individuals that will fill expertise gaps and who can be allocated to the project. Remember that most of them will still have to perform their regular daily activities. Once the team is identified, you may also consider engaging consultants.
Start On Your To-Do List
Now that your team has been selected, it is time to complete the first three items from the project’s to-do list: (1) craft a project budget; (2) create a rank-ordered list of business and technical requirements; and (3) develop a set of quantitative and qualitative value measures (to be discussed in a future article).
If you cannot ‘follow-the-money’ and provide a realistic time and cost financial projection for the entire project, Florin believes you may be stepping on a career-altering land mine. Though crafting a financial plan is beyond the scope of this article, he believes you should ensure it takes into account a comprehensive list of direct and indirect costs, includes a reserve fund, since most projects will exceed estimates, and is synced with the project timeline’s key milestones to ensure there are no cash flow funding problems.
Next, Florin believes the requirements list might be the most critical output of the entire selection process. It needs to be carefully curated and properly prioritized. He recommends tagging the product’s functional and technical requirements as ‘must-have’, ‘nice-to-have’, and ‘wish we could have’. Within these categories, a second tier of high/low or a one to three ranking system can help clarify what is really needed. While this can be a tedious process involving many group and one-on-one meetings, the success of the project will be determined by stakeholder satisfaction with all three elements.
Allocate adequate time to refine and discuss the requirements. Although you will have to act as a cheerleader for the project, do not shrink from challenging questions. Point out use cases where the new technology will make a positive impact and cases where it may not be best suited. Provide guidance by suggesting alternatives which can range from a different application to a process improvement, or perhaps recommend not changing the current way-of-working. And always be mindful of the human element. Team members and/or stakeholders will be reluctant to endorse a technology that could reduce or eliminate their roles.
Florin cites the following quote by Roy Rosin, chief innovation officer for Penn Medicine: “You have to understand what they are worried about, what are their fears, what are they trying to do? If we don’t engage with them that way, it doesn’t matter what technology we use.”
Avoid Overhyped Enthusiasm
If not well conceived, unfeasible business and technical requirements will become a source of frustration to vendors and business stakeholders when expectations are not met. The root causes of this all too common misstep include overhyped enthusiasm and/or misinformation about a new technology. Stakeholders, particularly end users may not appreciate that no product exists that can meet all their needs. Additionally, be mindful of imposing excessive technical requirements that far exceed industry practices and standards or that are dependent on antiquated technology applications. These elements also can spell doom for a project.
As the requirements list is prepared and refined, the discussion also should include tradeoffs that stakeholders will accept should the selected technology not meet all specifications. Remind your team and your stakeholder audience that this will be an ongoing discussion that will recur during the selection and implementation processes. The former will impact the technology selected and the latter will result from any number of unexpected issues that will arise, particularly for more complex applications.
“Assuming you already know what type of technology is needed, you can begin to contact potential suppliers and assemble information about their products,” says Florin. Usually this is done through a structured, formal Request for Proposal (RFP). The RFP will contain necessary legal language, guidance about how the vendors should respond, including how to submit questions, as well as an outline of key milestones and delivery dates. You may also elect to first send a Request for Information (RFI) prior to the RFP to collect basic product information and to avoid overlooking less familiar alternatives.”
A well-crafted RFP will collect the needed information in a semi-structured format that will permit key team members and stakeholders to review the product information and score responses. Avoid overly complex questions without providing adequate means for the vendor to prepare detailed responses. Insist that vendors clearly address features and functionalities that currently exist versus those that are planned for future releases or that can only be addressed via custom programming. Consider selection choices that allow the vendor to confirm if the current release of the product fully, partially or does not meet a requirement, as well as when it will do so.
“The RFP should also include a useful pricing template that incorporates the most common cost elements and drivers,” states Florin. “However, suppliers often grumble that it is challenging to conform to a template that is too rigid. While I appreciate this legitimate objection, failing to include a template structure will make it more difficult to compare pricing. To alleviate this challenge, you may opt to permit vendors to provide their own pricing template and information to supplement their proposal.”
More importantly, Florin notes the pricing information should include all the direct costs that will be billed by the vendor including annual product costs, implementation fees, and ongoing maintenance. The vendor should explicitly describe any implementation support services they can or cannot offer and to separately highlight any additional costing elements inadvertently overlooked or not fully addressed by the RFP.
Review The Roadmap
You want to ensure any product you purchase will meet your needs today as well as in the future. For that reason, the RFP should request the product’s roadmap for the next 12 to 24 months along with an explanation about what each release will include. Florin advises to be cautious if a company refuses to share their roadmap. Although roadmaps are not set in stone and are subject to revision, failing to understand the roadmap can leave your organization exposed if must-have requirements are not currently available and will not be available in an acceptable time frame.
Another key piece of information to be gleaned from the RFP is key personnel that will be involved in the project, as well as the senior leadership escalation pathway. Insist that names and CVs be included in the response. However, be aware that if the expected project start date is more than a few months out, it may not be realistic or feasible to identify the team. Other items in the RFP can include, but are not limited to, additional product information, case studies, and references.
“Taken together, the RFP should allow you to understand the product’s capabilities, the total cost of ownership, the costs of various elements, how it matches up to the functional and technical requirements, and how it compares to competing products,” says Florin. “The review process should be formalized and focused on those business and technical requirements deemed most important. This can be done using an assessment process that requires individuals to submit their scores/rankings prior to any discussion.”
Following the RFP review, it may make sense to using the RFP scoring to eliminate some vendors and concentrate on two or three for the remainder of the process. This will help with direct side-by-side product comparisons of features, functionalities, roadmaps, interoperability, and total cost of ownership. Once pared, the next step is to invite vendors to a proposal defense meeting to review their proposal, answer questions, and demonstrate the product.
“At this point, you can provide a formal update to the stakeholder community, including senior management, describing what has been done, how the various products compared, and the expected cost and timeframe,” adds Florin. “The expected cost and timeframe can include any variances from your preliminary time and cost estimates. This will permit you to reaffirm support for the project by senior management, prepare for the final stage of the selection process, and begin the product implementation period.”
Final product selection will be discussed in the second article of this series.