McKessons Paragon Project

John Maher:  Hi. I'm John Maher, and I'm here with Mike Lucey, President of Community Hospital Advisors. Mike is formerly of McKesson, and was part of the team that reintroduced Paragon to the market in the early 2000s. Then he started Community Hospital Advisors, which is a consulting firm dedicated to helping hospitals effectively install Paragon.

Welcome, Mike.

Mike Lucey:  Hi, John. Nice to be here.

John:  Mike, what is different about a McKesson Paragon project, as opposed to other IT projects that hospitals do?

Mike:  That's a significant challenge for me when I'm talking to CIOs, who, quite frankly, run project factories right now. They say, "What's the big deal? It's a different application..."

John:  They do this all the time.

Mike:  Exactly. The way I explain it is to say, "Take a look at your projects for the last, maybe, eight to 12 years. Take the majority of those projects, bundle them up into one big batch, then reintroduce them all on one weekend at one time."

That gives you an idea of what it's like to introduce Paragon. When you do that, then they sit back, "Wait a minute. Let me figure out how many applications that is, how much time they put into them as one very big dynamic, because that's a lot of people, that's a lot of work hours."

The other issue there is that doing it all at the same time. In the past, I did all of these projects in a series. When they interacted with other applications, I said, "We have to make sure that we get those connections correct." Now, I'm doing it all at once. I have to do all these applications at the same time and monitor those interactions, radiology to lab to pharmacy to nursing to orders. All these things have to be built concurrently and all those interactions monitored and effectively managed.

The other piece of it is really the crusher. Someone sits back and says, "OK, I'm going to deliver all these projects all at the same time. All of the people that are impacted by them, all those technicians and those registrars and those nurses and then the real big one, the big hitter, all of those doctors are all going to be impacted but all at the same time, all on the same weekend. That really gives you a much better understanding of how significant the project is.

The unique characteristic about Paragon is not necessarily the amount of software that gets flopped into place. It's the amount of people that are impacted by the software. That's the real crusher.

John:  Like you said, it's everybody who works at that hospital, all of the nurses, all of the doctors. It's hard to roll it out over a long period of time. You just have to pull the switch and then all of a sudden, everybody's on this new system.

Mike:  Exactly. You know, it's a positive and a negative. The beauty of Paragon is that it's one set of applications that all work effectively together. Microsoft technology, and it's current technology, you deliver it all at the same time, in a single database. All those pieces of the puzzle...Back in the day when I sold the product, these were, "Oh, this is terrific. You're going to be able to have this one big database that's all going to work together."

Well, the other side of that is, it all has to go in together. It all has to go on together. It all has to be Friday night, shut off all those old systems, and Monday morning, all those doctors and nurses are going to show up. All at the same time, they're going to say, "What was that log in? How do I get to that order? What does the patient look like?" All the things that they've been trained on, but now they're actually using it.

At the same time, little Johnny is throwing up in the corner and Marge needs her meds, and things have to get done. It becomes a very exciting moment. When we create that picture, then it's much more effective that we can back up the whole trade. It's like, "So, if we're going to do this on this weekend, back up 18 months. This is the time frame you've got to prepare for it and to put it together." That's why conversions become important.

John:  Mm‑hmm.

Mike:  That's why the build becomes important. That's why the structure of your project team becomes important. That really becomes another piece of it that is revealed. When we have that conversation, then I can move very quickly into the other big piece. It's unique because it's this big puzzle coming together at the same time. What that means is you have to embrace it much, much more effectively. I think a lot of CIOs, a lot of people, when they see something big, they back away from it. "I need help. I need somebody to help me with this."

John:  Mm‑hmm.

Mike:  That's true, but we really have to step forward. You have to own that project much more, and understand that McKesson has a role to play in your project. Outside consulting, somebody like me, we have a role to play. But you really have to own it, you have to own that project.

John:  Right. You're talking about ownership. What does that look like?

Mike:  Well, what ownership looks like is, build it. Don't go and hire CHA and get a bunch of cheeks in seats that are going to sit there at keyboards and clickety clickety click. Build all your screens and build all your workflow because the more that we do, the more you cede responsibility, and the more you lose the ability to understand and train folks on it.

Then the other side of it, recognize that McKesson is going to come in here with this pile of software. They have some quite effective people that are going to come in to teach you about that software, but they're all individuals. I have an individual that's going to come in to teach about registrations, an individual that's going to come in to teach about orders, an individual that's going to teach about clinical care station.

Those individuals know their product, their application to a certain depth, but they're very hesitant to cross the boundaries of their area to talk about the whole unified view.

Ownership means owning the unified view, owning how all these pieces of the puzzle are going to work together. Because once you start doing that, you start to recognize that my current state, my current system, it does a lot of things quite well. I want to keep those things.

John:  Right.

As I learn more and more about Paragon, I start to recognize that my current system also does some things flawed, or they were workarounds. The system didn't do A, so we did B, C, and D to get around that problem.

Now, I want to take what's good and leave behind what's bad. Only an owner can do that. You're not going to have the moving company come into your house and say, "I'm going to take the mirror, but I'm going to leave that couch."

John:  I have lived with it. You know what you like. You don't want you don't like. You're the only who can make those decisions of, "You know what, you can throw that mirror out. I never used that or liked that one anyway."

Mike:  That mirror stinks.

John:  "You've got to keep my couch. That's the most important thing to me."

Mike:  Exactly, exactly. When we're looking at it from a system point of view, I can see that the fact that we have this off‑site clinic, we need to keep this other process in place even though maybe other Paragon hospitals don't do that. We need to find a way to fix that.

I also recognize that since I have this Star System that worked with Horizon over here and had a Cerner Lab over there, now I have the unified environment, I don't have to do some of that workaround nonsense that we built to accommodate our problem with another break.

I know I have the unified system. That, sometimes, can be difficult for folks, because we work really, really, really hard on those workarounds. We start to own those workarounds and want to bring them into our new system.

Ownership means being able to make those hard decisions, what stays behind and what moves forward.

John:  Does a hospital have to have somebody dedicated to working with you to help make those decisions? Do they have to put somebody full time on, "You're going to deal with this change over to McKesson Paragon."?

Mike:  Absolutely critical. One of the first things that generally ask us is, "We want you guys to be our project manager." That's a real bad idea. It's a great idea if I...For billable hours it will be terrific for us to be the project manager, but the project manager has got to live in your environment, in your hospital.

Here's what you get from someone like me. You should be able to get all those things that you're not going to need later. The other thing you need to get from us is quickly the ability to develop all those skills that you will need later along the lines of project management.

Any hospitals have their project management officer, but what you want is that central person that will be the project manager. You don't send them into this blind. We've done 14 or so implementations. We've done the last five or six of them a lot better than we've done the first five or six of them. Part of it is we learned that having an in‑house project manager was critical.

Secondly, give them the tools to manage the project very, very well, the structure to manage it. We've got big old monster spreadsheets and we use Pi Matrix to actually put structure around the program, so for document management, task management, resources, schedules, all that needs to be in one web‑based place.

Get those things from us. Get some training from us, initially, to get the project started on the right path, but our job is supposed to be advising, to cross those barriers between applications. Then the other critical part, you're the owner, and you're being delivered. You're buying a new house, but you're not buying a new dog, you're not buying a new family, you're not buying a new garage, and you're not buying a new car.

You have all the other things that are coming with you. All these other ancillary products, these applications that are working outside the McKesson walls, you have to incorporate them into your process. You have to incorporate them into your new system, or, quite candidly, evaluate them, evaluate whether or not they're going to, again, make the move with you.

That's another piece that you get from that third part, the objective you to say, "OK. Here are all your alternatives. Here are all your McKesson alternatives for your decisions. Here are all your current systems, and then here are those things that are maybe outside that you should consider."

That's the proper role, the chair that we sit in. We get that project manager up and going, and then we help with the decision making down the line. Then, at the end, you're going to have two colossal events. You have this integrated test, which is a pretend go‑live, and then you have your big go‑live.

We go back to the 12 years of projects that you've rolled up, packaged, and that you shut them all off on Friday, and then you're going live on Monday. That event is your highest‑risk event.

John:  This has been 18 months or so leading up to this go‑live day?

Mike:  Sure. It's 18 months of staging, building, then you start getting into your testing. There's the integrated test event, that scenario where we have a very strict policy. We use what's called patient testing. We don't use scenario testing. Scenario testing is a nice way that...

When I was back at McKesson, we liked the scenario testing, because it tests in a very controlled way whether or not the software is working the way it's supposed to work. I've got this software. It should be working this way. I have delivered as designed, so I create a scenario to test that all the pieces of that software are going to work effectively.

That's great. The problem is that Johnny, who came in, he's not going to work necessarily based on my scenario, so we use patient testing. We will take, for instance, on this integrated test week, 100 patients. They will fulfill the scenarios that McKesson provides, but we want to take 100 patients that are going to go in their squirrelly different ways through our system, so that we make sure that those exceptions are going to be at least addressed.

You can't always build to exceptions, but you can address them and understand them, because those exceptions are going to be there on Monday of that go‑live week, so we do all the squirrelly stuff as much as we can at integrated test, again, to drive down the risk that takes place on this big event at go‑live.

John:  Right. Go‑live sounds like a pretty momentous occasion after you have done all of this work, testing, and preparation. What's involved in that weekend of go‑live?

Mike:  What's involved is you go live with something because you've killed something else. It's an accurate phrase, because there's no going back. There's no turning around. On Friday night of go‑live week, that bundle of projects that you delivered over 12 years, they're all getting shut off, and there's no turning them back on.

On Monday morning of go‑live weekend, all those doctors, nurses, registrars, and technicians are coming in and sitting down at their desks at the same time, saying, "What's that login again? Oh yeah, I remember," and they start down their path. Our objective is to put in place a process that goes about seven weeks before go‑live to mitigate all the risks that are associated with go‑live with your conversions, with your training.

How you roll out these sequence of applications, all very, very detailed and practiced, so that your team is fully able ‑‑ again, going back to ownership ‑‑ your team is fully able to manage all those consequential problems as they arise. At the same time, you'll have a whole set of folks from McKesson that will be on site starting Sunday to Monday on, because that first week is quite challenging.

You'll have a whole set from someone like us. We're usually coming the week before and are there through the weekend and into the following week. But, after you get to Friday, you should be handling it on your own. That's when that second and third week, if you're still relying heavily on either McKesson or your consultant, then something is not quite right.

John:  Right. After go‑live, when McKesson Paragon is now installed at the hospital, and, like you said, you've had a week or so where you've ironed out some bugs or just gotten everybody up to speed, is your involvement with the hospital then done?

Mike:  Pretty much. Pretty much. Like I said, if you're two, three months down the road and you're still paying me at the same rate you were before go‑live, then someone really botched something up. We do stay involved with our clients, where we have a great set of hospitals that we work with, but they will bring us in as they run into new ventures, new issues that they want to get our involvement, significant upgrades, meaningful use to some regulatory issues, or if they have an organizational change that's taking place.

Then we'll get in and we'll get involved, but the bottom line here is, going all the way back to the beginning, the less you depend on McKesson, the less you depend on outside consulting, the much more effective your system is going to be, and your program is going to be going forward.

John:  Right. Well, Mike Lucey, thanks very much for speaking with me today.

Mike:  My pleasure.

John:  For more information, you visit the Community Hospital Advisors website at commhospital.com, or call 888‑811‑4687.