[music]
Katlyn Graham: Hello, I'm Katlyn Graham. I'm here with Mike Lucey, President of Community Hospital Advisors. Mike formerly worked with McKesson. He was part of the team that reintroduced Paragon to the market in the early 2000s.
Then, he created Community Hospital Advisors, a consulting firm dedicated to helping hospitals effectively install Paragon. Welcome, Mike, thanks for joining us today.
Mike Lucey: My pleasure, how are you, Katlyn?
Katlyn: I'm great, thanks. Today, we're discussing managing the vendor in a McKesson Paragon project. One of the things I've heard you say before is, "Managing the vendor." What does that mean?
Mike: We'll go right to the hard question first I guess. This is a question that can get me in trouble if I'm not too careful with my good friends at McKesson, but "managing the vendor" really goes down to the essential relationship that needs to exist between the hospital and McKesson, that is the most important relationship.
The relationship with us at CHA is important, but the reality is you're going to be living with McKesson for a long time after you put this product in, and it has to be a relationship of equals, of strength, of shared accountability.
When I say "managing the relationship" in the project process, it's very important to understand what the roles are that need to be played so that you can gauge whether everyone is playing their role effectively.
That's what I'd say, managing McKesson really comes down to understanding what should I expect from them so then I know if I'm getting what I should expect, does that make sense?
Katlyn: Yes, I think so. Doesn't McKesson build this system?
Mike: No, [laughs] that's really where it starts. In fact, there's a lot of confusion around that. When I was selling products for McKesson, you understand the relationship changes very dramatically the moment that contract is signed.
In selling Paragon, in some respect in selling any software product, you want to diminish the pain the customer goes through to put it in, you want to diminish that part of the struggle, if you will, to get that signature on the page.
Once the contract is signed, it's very important that the effort now that needs to take place is clearly understood, and that those roles again are very well defined.
The analogy that I would make is, "When you sign that contract, think in terms of moving." You're moving from one house to another house, all that you're buying from McKesson is the truck.
You're buying the truck, that's going to get you from one place to another, but you're not buying the driver, you are the driver. What you get from McKesson when you sign that contract is, "They will train you on how to drive the truck, they will train you on how to build this software, how to build this bridge from your old house to your new house."
My analogy is getting a little mixed up there, but what they will not do is, as I say, drive the truck because they don't know where you live and they don't know where you're going, quite frankly from your old house.
They don't know what you want to bring with you and they don't know where you're going to put it in your old house. Back to your project, they don't know what your current operation priorities are, they don't know how you're flexible, and how open you are to changing them in your new environment.
You have to make all those decisions. The essential part though, the piece that McKesson does deliver, is teaching you how to "Drive the truck."
You're not going to drive it, but they're going to teach you how to drive it, they're going to teach you how to build this software so you can build it to your standards.
Now, once you understand that, you don't expect them to drive the truck. Once you understand that, you don't expect McKesson to make decisions for you, that's really the critical piece is what should I expect them to decide for me, what do I have to decide for myself as I go down this process.
When I get back, then I can understand, I will hold McKesson accountable to deliver very good training on how to build, but I won't hold them accountable for the decisions that I make. Does that make sense?
Katlyn: That does. They're providing the vehicle, it sounds like, to get you to this new technology. What is the vehicle, is it software or...?
Mike: There's three things that you'll get from them. You'll get software, in fact over the period of your project, that software is going to change to a certain degree so they will be updating it for you and they'll be telling you about those changes, you get the software.
Secondly, you get this build training. You're going to get a series of people who're going to come into your hospital and teach you how to build physician documentation, order management, registration, they will teach you how to build it.
The third thing you're going to get is this technical support. They will be setting up your databases for you, they'll be setting up your environments, they'll be updating them, they'll be helping enable your conversion process so you have this technical team over here, you have the build training team that's going to come in, and then you have the software in those software updates.
Those are the three things that you're paying for from McKesson. Now, on the hospital's side of it, I learn how to build and I have to do the build, that really is that series of decisions that I pointed out.
You have to make all these decisions about, "How do I want my orders to work? How do I want my screens to look? How do I want my registration process to flow?"
All that stuff has to be done internally, based on what your priorities are.
Katlyn: It's very individualized, it sounds like, on the hospital, very specific to how they operate.
Mike: It is, in fact when we do multiple hospital sites, it gets down to if you have a medium, small, and a large hospital, each of those hospitals will have different workflows that have to be considered.
There, you have an executive team that's deciding what do we want to standardize, what are we going to allow each hospital to make more individual, that decision processes is the big challenge.
Katlyn: What role does CHA play? What does CHA do?
Mike: It really goes back to those decisions. Since we've worked with a couple of dozen different hospitals, in any one time, we'll be working with 13 or 14 different hospitals, either during implementation, supporting past implementations, or doing upgrades.
We have a very broad and deep view of what hospitals are faced with and are challenged with, we have the ability to say, "OK, you're looking at these decisions, these are your alternatives."
The struggle with decision‑making is the alternatives, is saying "OK, how many alternatives do I have? How do I prioritize them so that I can then make an informed decision?"
Too few alternatives, which we see very often. Remember, you have a series of build advisers who are coming in from Paragon, coming in from McKesson, they have a very limited view of the world.
They have their application in the hospitals they've worked with. They may only show the limited amount of alternatives for using that application that they've seen, that can be very frustrating because if my workflows don't fit in that limited view, then I'm stuck.
Then, there's the other one. I may really think at my hospital that I need to do a certain workflow, I have to do it this way, "It's better to have a third‑party," someone from, for instance, CHA sitting there and saying, "I understand you'd like to do it that old way. The product cannot do it."
We have today very often is we can sit down and say, "The product was built this way because the regulations require this kind of workflow," It's not really McKesson's fault that, for instance, medication reconciliation works this very specific way, it's the regulation requires it.
That's easier to hear from an objective third‑party than hear it from the vendor where you're thinking, "Maybe you're just telling me that because your system doesn't work right." We can sort those alternatives out.
Again, I look at my alternatives, I prioritize them, I make a decision, and I move on. Projects get crushed with delayed decisions, it just kills them, drives people crazy.
Katlyn: You have that overall view, that overall expertise, and can really provide feedback to people. I'm sure that you appreciate that. It sounds critical with what they're going through.
Mike: If you make bad decisions, you're going to get a bad result. There's two things that we see pretty chronically with failed or damaged projects.
The first is "I put the wrong driver in the seat." A hospital says, "OK, I'm going to buy this software for you, I'm going to buy this truck from you, drive me to my new house."
They drive you to your new house, it's the wrong place, you don't like it, you've got no one to blame. They didn't know where they were going and they didn't know where they were coming from, that's the first area where we see our problem is accountability.
I've given McKesson the wrong role in this project. The other one is if I have bad decision‑making so that all decisions are delayed, well, then don't be surprised if your dates keep moving.
Probably, the worst one though is if I had bad decision‑making so that I have now built my system incorrectly because I did not see all the alternatives, I did not prioritize them correctly, and I did not pick the good one.
You never get the best, it's a thing in one of the speeches I make. Do not fall into the trap thinking you're going to build the best system in the history of the world. Build a good system, and then make it better through use. We will get folks focused on those decisions, get the decisions made, and keep on track.
Katlyn: Sounds like hospitals should give you a call. For more information, you can visit the Community Hospital Advisors' website at commhospital.com, that's "comm" with two Ms or you can call (888) 811‑4687.
Thank you so much, Mike, for joining us today.
Mike: My pleasure.
[music]