Go-lives are a special experience. They’re exciting, stressful, ultimately bonding events that can either set you up for real success with your EHR – or get you off on the wrong foot, depending on how well they’re planned.
Nordic’s implementation experts have been through hundreds of go-lives, and they say that planning a go-live isn’t unlike planning an extremely involved birthday party. From ensuring you have snacks and Wi-Fi to keeping your people happy, our experts have plenty of tips to ensure you go live and love it.
In this podcast, Nordic’s Implementation Strategy Director Lindsey Manzuk and Senior Consultant Sara Alvarez talk through their “lessons learned” from many go-lives. If you’d prefer to read rather than listen, the transcript is below.
Call Notes
[00:00] Intros
[2:05] How to prioritize as you plan
[5:20] Communicating clearly with your team
[6:56] To-dos before the big day
[8:50] The small things that make a big difference
[12:10] Change control and management
[14:20] What to expect with ticket volumes
[19:05] The benefit of Managed Services
Transcript
Lindsey: Hi, thanks for joining us today. My name's Lindsey Manzuk, and I'm Nordic's implementation strategy director. I'm here with Sara Alvarez from our Managed Services team, and we're going to talk a little bit about supporting go-lives. Hi, Sara.
Sara: Hi, Lindsey.
Lindsey: Could you start by telling us a little bit about yourself?
Sara: Sure. I'm happy to. Thanks for having me, first of all. I am the Access team lead and service delivery manager for Nordic's Managed Services team. My primary applications are Cadence Referrals and Prelude. So you should know that's the lens I'm coming at this with. I've had about 12 years of Epic experience, with five of those being at Epic on the implementation team. I've supported many go-lives over the years. Most recently, I was on the Cadence project team at a hospital here in Wisconsin, where they were rolling out enterprise apps to five hospitals at one time.
Go-lives are such a special, unique experience. They're full of energy; they’re concentrated and focused collaboration with all the Epic and operational partners. Of course, there's the pride in seeing your hard work pay off. So I'm happy to be here today to talk about them.
Lindsey: Yeah. Go-lives – I always tell customers who haven't done them before, I'll try and explain it to you, but you're not really going to understand what it's like until you go through it.
Sara: Right.
Lindsey: So, you have to trust me, and I'll guide you through it, and then it's going to be exciting.
Sara: Right.
Lindsey: Both of us have worked at a lot of go-lives, and we've had some go well, some not go well. From the not-going-well standpoint, what are some of those major challenges that you've seen customers run into?
Sara: I think prioritization is a challenge, before go-live and during go-live. Before go-live, it’s like a hive of activity. Bees are buzzing everywhere, and you have an issues list and several things that must get fixed. But then you have lots of chatter about, Gosh, it would be really nice if we had this.
It's really important to prioritize the things that have to be fixed – the so-called “showstoppers.” Those are the things where you cannot go live if this isn't fixed. Then you ask, what can we go live with and limp along maybe for a day or two until we can focus some attention and get those “nice-to-haves” fixed?
You have to have operational buy-in to identify and prioritize those issues. It can't just be the Epic team saying, “Here are our showstoppers" and "Here are our nice-to-haves." It needs to be a true collaboration across the organization to make sure everyone's on the same page and that they know what to expect.
Lindsey: What about actually during go-live?
Sara: Same idea. I think you have to have a good plan for gathering together representatives from IT and operations in a round-table format. You may even need some C-level representatives to ensure that you're prioritizing issues correctly as they come up and acting with urgency appropriately to get the message out if there's a critical issue.
What is the workaround? What is our timeframe for fixing it? It really is important that you have a good rhythm established beforehand, such as deciding to meet every hour or every day. Everyone should know the call-in number and who's expected to be there. Creating that forum ahead of time, to make sure you're all represented at the table to discuss those issues, is key.
Lindsey: Yeah. At go-live, the team will have so much coming at them that prioritization is key to make sure they're working on the right things, and then delaying those things that aren't as critical and putting them into the optimization phase. I know customers sometimes struggle with that too. Maybe you can talk a little bit about best practices or struggles that you've seen there.
Sara: Sure. Optimization is a tough word for customers and for end-users to hear during go-live. It's almost like saying, “Your issue's not that important. We've got to work on something else.”
If you're clear and upfront about the timeframe of when the optimization phase will start, that lessens their anxiety. Let me give you an example. Let's say it's Day Three of go-live, and a nurse calls in an issue that she's feeling very passionately about. In the scheme of things, it doesn't rank up there with what else is going on. So the Epic team and the operational leaders decide to put that request or that issue onto the optimization list. That nurse is going to feel a little bit frustrated that her issue was deemed as an optimization request, so it’s important to message correctly to end users that we appreciate the request and we will get to it in X number of months. Maybe the optimization phase is two or three months out, but it will scoot up to the top of that list, and we will reach out to you and discuss that request in more detail when the time comes. Never fear, we have it on the list. Your request isn't going to be forgotten.
Lindsey: I've also seen organizations that, before go-live, think through and communicate how they're going to prioritize those optimization requests and communicate them with end users. That can be really helpful.
Sara: Mm-hmm. Yep.
Lindsey: Then an end-user doesn't just know it's on the list, they understand that there is a list and a process to review it and there's some sort of scoring system. Based on that, the team will figure out what they need to work on.
Sara: Right, it's not just a black box where it disappears and who knows what happens to it.
Lindsey: Yeah. Are there other questions or things that you think it's important for organizations to think about before go-live, before the big day comes?
Sara: Sure. I'm going to put on my Cadence hat here for a second. Appointment and case and registration conversion could not be more important for that end-user community. There are several reasons why I say that and why I'm so passionate about it. One is they are the first users to be live in the system. They get the first crack at it. They're sort of like the guinea pigs. Have we set them up correctly? Do we have a good process for addressing any issues that come up? It's like a mini go-live for them. Many customers treat it that way. It’s a bit of a celebration, and it's a long weekend or two or three, and it really is full of energy just like real go-live, except that it tends to happen a couple of weeks before.
Lindsey: Mm-hmm.
Sara: It gives the Epic team a chance to cut their teeth on their support processes before the whole hospital goes up. That's one reason why it's so important to plan the conversion well. Give it a lot of thought. Communicate a lot about it. Those users, because they’ve been live for a few weeks before go-live, end up being Epic advocates for the rest of the hospital then on Day One.
They tell their peers, “Oh my gosh, the first day is terrible, but it gets so much better." That works really well. It's not just the Epic team saying, "I promise it'll be okay," but rather their end-user peers that have experienced it already.
Lindsey: Mm-hmm.
Sara: It’s very important during conversion to make sure you treat it like a go-live. Make sure you have the support ready if there are issues. There will be issues, so you should have somebody from the security team on call, ready to fix passwords, ready to build users if they weren't built correctly.
Make sure your hardware people know that you're going to have a big subset of users in the system on that weekend, and then up until go-live. Make sure that they have workstations set up appropriately, that printers are mapped. Make sure that your project team is ready to support their users.
Lindsey: Mm-hmm (affirmative).
Sara: That can be a big strain on the project team, to have the majority of their end-users live. Maybe not on full functionality, but they're live and they're also still getting ready with the rest of the Epic team to go live on Day One. So they do have to juggle multiple things, wear two hats. Supporting end users that are live and then preparing for the big day when everyone goes live. So appointment conversion is definitely worth the time to plan.
Lindsey: Make sure it goes well.
Sara: Right. I would even advocate for dedicating at least one person, one coordinator that's from your application team and knows the applications but who won't have any build responsibilities. I actually did that for a customer and it went well. It really did. To have one person coordinating all of that effort. I almost equated it to planning a giant birthday party.
Lindsey: Yeah.
Sara: It's like, “We’ve got to think about the food. We’ve got to think about the activities. We’ve got to think about the entertainment and how we keep these end-users inspired. When's the clown coming in?" The build team just cannot think about that stuff. They are too busy getting ready and fixing issues before go-live. Having one person dedicated to planning that conversion has worked really well, in my experience.
Lindsey: Yeah. One other thing I'll add – that I've seen customers not think about before go-live and then have it become a struggle – is the escalation path for unhappy users. You really need to make sure that users, if they have a concern, know who to go to. Ideally, that's not the project team. The project team needs to be able to focus on fixing the system and changing workflows that aren't working, and having that heads-down time. So it’s about making sure that the solution for an unhappy user isn't walking to the command center and grabbing someone and then talking to them about their struggles. Ideally, there's an escalation path on the operations side you can leverage your champions. Then the champions can consolidate all of that feedback and bring it to the project team with those prioritization conversations that you talked about earlier, so that project team is able to focus in the appropriate areas.
One other thing I'll ask about is change control during go-live. What are some best practices or struggles you've seen there?
Sara: Couple of thoughts. One is, it's important to have a “business as usual” path. What are the types of changes that the build team can just put right directly into production, without having to go through the full change control approval process? Whether that means it only impacts one user, like adjusting their user security, or maybe it just impacts one provider or one department, and they're the ones requesting the change. Their manager signs off on it, boom, puts it in. Done. Issue closed. It’s about having that list very clearly identified, and I've seen lots of customers call it the “business as usual” types of changes. It's refreshing to the build team to know "Here are my boundaries. Here's what I can do without going through the rigmarole of change control."
Conversely, having the list of things that do need approval, that are super integrated topics, that require buy-in from operations, from multiple groups in operations, that require several application teams to collaborate on. You also then have to, especially during go-live, have a process for pulling the right people in quickly for urgent issues.
Lindsey: Mm-hmm (affirmative).
Sara: Again, having that forum set up to do so. Whether that's a side room in the command center, or a side table. Sometimes even dedicating the physical space for that SWAT team is helpful. Just knowing that that's where the urgent critical issues are resolved. It's good to know that you have that set up.
Lindsey: Great. Thanks.
Thinking about planning for go-live and what to expect, can you talk a little bit about ticket volumes? Because usually there's a huge onslaught, but customers often don't know what to anticipate.
Sara: Sure, I can. It varies by application, as you might imagine. The majority of tickets for user security come right at the beginning. As you can imagine, if they can't log in, that's the first thing they're trying to do, and they're going to pick up the phone and that's usually the first team to get hit at go-live. Their volume is really high that first week and then it significantly tapers off as users go through their shifts. I would certainly make sure to staff that team up that first week, and of course 24 hours a day.
The other apps that get hit are, of course, the Access apps and the Clinical apps. The first week or two are really the heavy hitters, and then it significantly tapers off, each week after that. The billing apps tend to have a pretty slow ramp up. The first two weeks are typically a little bit slower for them, and then about Week Three is when they see their peak volume. It doesn't usually taper off until about Week Six for them. So they need to staff appropriately. They probably need to be present on Day One, but just not fully armed.
Lindsey: Ready to go. Good to know.
Thinking of staffing, are there other areas of risk that customers should think about when they're considering their go-live staffing?
Sara: Sure. We've talked a lot about appointment conversion already. It's really important to almost make it a requirement for your end-user community. I've seen, when they make it optional, most people don't want to go in on a weekend and sit there for 10 hours. That doesn't sound appealing to anyone. Even if you try to say, "Well, you're going to get practice,” they say, “Well, I'd rather be at my kid's baseball game than go practice.” Making it a requirement gets people in their seats. Every single user that I have spoken with after a conversion has said, "I am so glad I came. I'm so glad they made me come. I'm so glad I came. I'm feeling so much better about go-live and this was not as bad as I thought." Making it a requirement is essential. It works out those kinks before the big day.
Cut-over – all of the slew of events leading up to the moment that we say we're live – so typically the night before. It's really important to have operational involvement there. That's when we're pulling in clinicians to help us back load patients into Epic. If we run into any issues, we don't have a lot of time to muck about. We need to have the right people to help us work through those issues, so we can go live on our target date and time. Making sure we have operational leadership involved, or at least ready to call on the phone, is important.
Another area of risk during go-live is looking out for those smaller project teams that, maybe they have just two or three people, and they also have to provide 24-hour-a-day coverage. That's a recipe for quick burnout. Go-live shifts tend to be 10 or 12 hours, and sometimes people stay longer as they're continuing to resolve issues, and there's only so much coffee in the world that can keep you going. Making sure to either beef up that team a little bit, make sure that they get their rest time in, is important.
It's also important to identify your key end-user groups. Make sure that they are appropriately supported during the first two weeks of go-live. If end-user groups are upset or are unable to get through their workflow, or if they think they're doing the right workflow but they're not, that can really mess things up. It’s important to have good, solid floor support right at their elbow, to make sure to support them. Going back to what you said, Lindsey, about making sure they know their escalation path, too, so that they know who to reach out to if they are having questions and issues.
Lindsey: The point you made about the small project teams and needing to provide 24-7 support and potentially having some struggles there made me think of a question. One of the things that you do as part of the Managed Services team here at Nordic is provide go-live support to help augment some of those teams. Can you talk a little bit about how that works and some successes we've seen, and maybe some areas where customers have been surprised with what we've been able to offer?
Sara: Sure, I'm happy to. One of the benefits to bringing our team in is that we’re really good at taking tickets. That's what we do. We support customers across the country in their day-to-day, live production system work. Tickets is what we do. I would highly recommend, if you're looking to augment your go-live team, bring in the Managed Services team to work those tickets. Put us in the command center at the desktops. Put your team out on the floor. They are the ones that know the end-users the best. The full-time team is the faces that the end-users know. They've built relationships with them, they designed their workflows and collaborated with them to build Epic's system. They are the most qualified to go support those end-users. Even if an end-user isn’t saying it, they’ll be able to tell, "Oh you're not, maybe, doing that exactly right." The end-user may be not even aware. They will be able to catch those things. Put us behind the desks. Let us answer the phones. Let us take the majority of your production tickets. Use your team for their organizational knowledge that they have. That's what's really hard to teach a group of consultants, or a group of outside Epic folks, is what makes our organization tick. That's what customers’ teams know. I suggest getting them out on the floor.
Another thing is, in our everyday business, many of my customers have remarked, when they bring Managed Services onboard, that we do a great job of blending and integrating with their full-time team. Their end-users don't know that they're talking to a Nordic person and not to one of their own. We really pride ourselves on that. We really do. Even though I'm contradicting myself a little bit, I just said that we don't know what makes an organization tick, except that that's really what we try to do – take off our Nordic hat and put on our customer hat, and do whatever it takes to make that set of end-users happy. Our customers love that. They love that, even if we may not be sitting in their four walls, that their end users feel as well-supported, maybe even a little better, by us than their own team. Their full-time team just breathes a huge sigh of relief, knowing that the onslaught of tickets is being handled, allowing them to take on the more complex challenges that come up during go-live.
Lindsey: Great. Thanks. Before we conclude, I do want to talk a little bit about successful go-lives. Can you share a few key things that you've seen customers do that have helped them have smoother go-lives?
Sara: Sure. I'm happy to.
I know we always say start early. When I hear that advice, I always think, “Oh gosh, I'm not starting early enough, and I'm already behind." The earlier you start planning go-live, and all of the events around it, the better it will be. I've seen one customer who actually designated a go-live coordinator. Everybody on the team knew that she was in charge of getting power strips, getting Post It Notes, and supplies, and food. It wasn't like people were wondering, "Are we going to have coffee? Gosh, I sure hope someone's thought of that." Well, if you didn't know, then call Deb, 'cause she's probably on it. It's really nice to have one designated person who's in charge of all of the infrastructure to make it a good experience.
Lindsey: Mm-hmm (affirmative).
Sara: Make sure that you have somebody designated, or scheduled, to pick up the trash and clean the bathrooms. People are going to be living there for about two weeks. It needs to not be a pigsty. It has to be a good, fun, positive place to work. So making sure you have good, healthy food is also important. I think diets tend to go out the window during go-live. But make sure you have good snacks to snack on. It's important, too, to have everyone in the same spot. That is always a challenge. I've seen it work really well, where you reserve a giant meeting room, and get lots and lots of tables with desktops there. There's just a really great synergy that comes when everyone's collaborating in the same physical space. It's also just much easier to resolve issues, to go and top somebody on the shoulder and say, "Hey, give me two minutes and let's talk this through,” rather than Skyping and depending on a phone call and all of that. I sort of hinted at it, but power strips are very important. Especially now that we all have cellphones, maybe we have iPads, and our computers. We need to be plugged in, literally, to keep going.
Another thing that I've seen really well is establishing the rhythm of the go-live. It almost ends up happening organically, if you haven't thought about it ahead of time. It just will happen. Everybody just settles into the routine after a couple of hours of, "Okay, we're going to meet at 10, and 2, and 7, to talk about our issues. Who's going to kick off the call? Who's taking notes in that meeting? And making sure that we have owners for each issue, and follow-up dates, and a communication planned to end-users,” and making sure that we have those meetings on everybody's calendar. That the right leadership is involved there. Just establishing that cadence of discussing those issues. Providing updates. End-users' anxiety goes way down when they know "we're gonna get an update from the project team every day at 10 and 2." I'm just making those times up, obviously, but they tend to just relax a little bit and know that they will be communicated with. That'll be their chance to ask questions, too. That maybe they didn't submit a ticket for. Just allowing that rhythm to happen, and maybe putting some smart folks in charge of coordinating that and making sure it does happen.
What ideas do you have, Lindsey?
Lindsey: I would add, maybe, two quick things. Go-live, you talked about the long shifts, 24-7. Make sure you're thinking about when your project team members can rest, both during the go-live, so making sure they get some days off, so they can sleep in, see their families, switch from nights to days. That's always a tough thing to do. Then also after your command center closes down, you're likely going to see a spike in requests for time off, so making sure you think about that before go-live and have a plan in place so you don't have all of your ASAP project team out the same week, because they just worked a go-live and they all want to rest. Make sure you plan that into your overall go-live plan.
Then, lastly, don't forget to celebrate. It's a huge accomplishment. It's a big milestone. It's sort of a turning point from when you move from implementation into the rest of your organization's EHR lifetime, and the value that you can bring from this new tool that you put in place for your end-users. So it's been a long road, you made it to go-live, and now you're sort of pivoting. Who knows what else you'll be able to accomplish in the future?
Great. So, Sara, I appreciate you being here. That was very insightful. So, thanks.
Sara: Thanks. Happy to be here.