Prepare A To Do List For Your Clinical Technology Implementation
Source: Clinical Leader
In November 2019 Clinical Leader Live was proud to feature Larry Florin, president at LBF BioPharma Consulting, to discuss how clinical operations executives can Overcome The Challenges of a Clinical Technology Implementation. During the presentation, Florin covered several topics, including how to be a champion for the technology, how to determine your technology selection team, managing enthusiasm, and finding and vetting the right technology vendor. In this video, Florin discusses how to prepare a to do list for your clinical technology implementation.
Ed Miseta: Once you have the team in place, or once they've been selected, you feel that's a good time to get started on your to do list. And you feel the first three items on the list should be crafting a project budget, creating a list of business and technical requirements, and developing a set of quantitative and qualitative value measures.
I feel like we could probably do one of these Clinical Leader Lives on each one of those steps, but what advice would you have for completing those first three steps, all of which seem to be pretty critical to the project?
Larry Florin: Thanks for asking me the loaded question. I think you're absolutely correct, Ed, all three components. I think people on the call might say there are even a few more that would round out, that they would view as mission critical. But having said that, my thinking is that, first and foremost, once you've built the support that you want to take an exercise forward, at the end of the day, look, you have to be able to provide two things that are really, really critical.
Number one, what's the cost? How much resource is it going to take? And then number two, what's that benefit that you're going to accrue from the technology and its implementation? The first is something that not everyone is equally well equipped. You may or not have the financial background and wherewithal to really do a budget effectively, to look at how one measures value. What tools are you going to use to measure that value?
How are you going to get the people on your team, and the necessary individuals from other parts of the organization that will be affected, to say, "Okay, here's where we're at today. Here's where we're going to be tomorrow. What value are we accruing? Is that something that could be measured quantifiably? Is it for less time? Is our productivity going to increase? Is our quality going to improve?"
All the drivers, I think, are things that we all think about every single day, but being able to synthesize that and put it into stark financial terms is really, really critical, which is why a moment ago I mentioned having other operational support people as part of your team. So, I think that's number one.
Number two, no project is going to go anywhere without being able to build your value case. And you need to, if I could say anything that you take away from this call is, if you do that effectively, you're probably on your way to having, or at least increasing the likelihood of having a very successful project. What is the problem? What is the technology looking to solve? How will you measure that improvement?
If you can do that effectively, you probably will get the needed senior leadership support to back the project and people will know what the series of goals are, or the primary goal, or maybe even a group of others that you're looking to achieve in terms of what you're doing with the overall program.
The last thing, and it maybe ties into other elements of what one needs to do in order to get there, think of it as sort of a pathway program is, what are the expectations you set? What are the requirements that you're going to outline? Remember that one of the problems of... We talked about naysayers for a couple of minutes, there's also the challenge of people that are overly enthusiastic.
If you set expectations too high, or over-promise and under-deliver in terms of what the technology will provide or what you're doing in terms of your business processes that will be modified in order to accommodate the technology, that's a major misstep that people often overlook. At the end of the day, people get disappointed if, in fact, "Hey, we didn't achieve what we thought we would."
I'm not suggesting you necessarily have to game the system and under-promise to over-deliver, but I think taking a good, honest assessment of what needs to be done, what you're looking to achieve, and how you're going to measure those achievements is very important.
It also is important to think about what the technology that you're going to select ultimately, as you go through that process, because nothing that you point out will fulfill every single expectation that one has. You need to think about how to identify them, how to prioritize them and decide on which ones you're really going to look for in terms of that selection process.
Ed Miseta: Absolutely. So, let's just dig into a couple of those topics a little more. The budget part, I have to think, is incredibly important because I'm sure there have been many technology implementations where maybe the budget didn't work out as planned, and if you end up with huge cost overruns I'm sure that can be career ending, or at least your career with that company.
You talked about direct and indirect costs, and the importance of including both of those. I'm hoping you can give a couple of examples of that, so we know what to include and not what to include. You also mentioned the importance of a reserve fund. Could you touch on that, as well?
Larry Florin: Sure. Let me address these in reverse. Very simply, and there may be people on the call that would challenge me, from their own experience, and I applaud them if they've been successful but I've never worked on a program that, even with our most conservative estimates, didn't have some challenge or other issue that arose, that was a bit unexpected. What I call the reserve fund is having extra funding available, extra resources that you may be able to take advantage of, project delays, whatever it might be. You just need to be able to have a mindset of, "Prepare for the worst," and always have that contingency plan.
What is your proactive risk management approach in terms of the overall program? And that's from a financing standpoint, a resourcing standpoint, a timing standpoint. So I think being mindful of that also gives you credibility, because you've outlined what you think is a reasonable case, you've explained what you think the potential challenges may be, and you said, "Oh, and just in case something comes up or some things don't go quite as well as anticipated," for any number of reasons.
There's lots of other things. People that'll be working your team have day jobs. They may get busy. I got called onto this meeting overseas, when I called Ed on Friday, just telling him I'll be in a different location. So, things arise that you can't anticipate. Preparing for that, I think, is just a good, thoughtful, strong project management approach.