Let me begin this post by saying that anyone who is in the business of creating and selling medical software wants every project and customer to be a complete success. Not only for financial reasons, but for the simple fact that you don’t go into the business of solving problems for people only to let them down. What doctor wants his patients to fail and die? Probably none. So let’s begin with the understanding that both sides (vendor partner and medical group/hospital) are hoping that each project is a huge success. For more info on vendor partners check out my blog post "11 traits that your physician scheduling vendor should have".
Sometimes no matter how great your intentions are, the software implementation fails and the customer stops using your product. I have taken some time to examine some of the similarities in projects where we have not had successful implementations in order to learn how to do a better job. Although not all projects are the same, when it comes to failure there are some striking similarities.
Lack of clear goals. If everything is important than nothing is important. Each project should begin with a clear understanding of the top 3-4 things that they wish to accomplish immediately. For many of our new customers it is to (1) get the physician schedule online, (2) simplify the scheduling process through automation (3) get the physicians schedule into his/her smartphone. If you are a medium size Cardiology practice and you are using paper and pencil or Excel today, accomplishing those first three items would be a big step forward. Without clear goals, that are reasonable and achievable, everything becomes important and a priority.
Lack of time. Physicians and or management sometimes forget that like themselves, everyone on their team is busy. This can become a problem if someone is given an implementation assignment without having some relief of current tasks. Adding more work to someone’s plate who is already overwhelmed is a clear receipt for failure. If the project is as important as a new physician workforce automation system, then it deserves to have someone who has time to complete the project. In addition, this does not mean having access to someone who is supposed to be answering the phone or is with patients who are “under” while they are trying to learn or assist with implementation.
Lack of understanding. People who do not understand the “why” can inadvertently sabotage the project. Whenever we kick-off an Enterprise level implementation we try to begin by having the CEO or a senior executive send out a note to each person who will be involved in the project explaining why, out of all of the stuff that is going on, they have decided to implement this new solution. In healthcare every project should be able to be tied back to the goals and master vision of the organization. For most, everything begins and ends with patient care. If your team does not understand who this project benefits and why, they are unlikely to want to participate. This can be even more challenging if the “daily users” are not the direct beneficiaries. In this case it is even more important. Clear, concise messaging, from senior administration is key to implementation success.
Scope creep. Scope creep is a direct descendent of not having clear project goals. Without clear goals, everyone is wondering “what’s in it for me”. And if there is nothing in it for them, they will try and add things to make their life’s easier. Scope creep happens typically after people’s initial understanding of what needs to be accomplished gets completed. Then users begin to want more, and often what they are looking for are things that they feel are complimentary based on their roles within the organization. For example, someone who works with the physician scheduling and also works with compensation will often advocate for payroll integration. Not that payroll integration is bad, in fact it’s a great idea, but more often than not most organizations have a sophisticated HR system that manages this function, alone with other things, perhaps like PTO. Scope creep is typically at an end user level. For example, if payroll integration is important, then it becomes an organizational goal that is discussed in the beginning of the project and there is a lot of thought put into how payroll and scheduling work together. If everyone is crystal clear in what the organization is trying to accomplish in the beginning, then once complete the scope creep can be channeled into brainstorming future features to help solving the organizations next set of needs.
Lack of follow through. This one is and has always been the toughest for me to understand. We have seen project failure plainly due to people’s unwillingness to get the work done. What is even crazier is that typically these are people who are supervised by others who also do not follow-through. Part of this comes back to a “lack of understanding” of why this is important. Especially if it is not going to directly benefit them. During an implementation, leadership needs to choose people who have proven themselves in the past to be able to accomplish their assigned task. Assigning even a small part of an implementation to someone who does not follow-through will place the entire project in jeopardy. People need to be held accountable for their assigned work.
Resistance to change. “The current way of doing things has worked well and I’m not going to change.” Or, “this new way takes way too much time and I’m not going to participate.” “We’re going to keep doing it the old way.” Sometimes hearing these comments makes me want to burst inside. Resistance to change often comes from someone with little authority, but a lot of power within the organization. Resistant users camouflage themselves really well. Most often the power they have amassed has come from either time on the job or the difficulty of the job. They see themselves as irreplaceable or in a position where they know that they have the organization by the preverbal balls and aren’t afraid to twist. Change is difficult, every book on change acknowledges that fact on page 1. Typically change happens for a reason, often to make something ultimately better. When you have someone who is very resistant to change one of the only levers that you can pull is to appeal to their sense of team and patient care. This new system is necessary because … As we grow, in order to provide better patient care, we need to … Once they understand the “why” sometimes your resister can actually change to become an advocate. Identify the resisters early, it might take some time to bring them around.
As you can tell, this is not a comprehensive list of reasons why software implementations fail, but it is most of the biggies. One key theme throughout this post is around communication. There is no substitute for having senior leadership communicate the “why”. Not only should this be done first, but a best practice would be to continue the “why” campaign throughout the project. People tend to support things that they understand, even if they don’t fully agree. Implementing physician scheduling software has many benefits that are worth some of the trials and tribulations of getting up and running. There is not much worth doing that isn’t a bit challenging when you are in the middle of it.
Key Takeaway: Spend as much time on planning and communicating your implementation as you did on purchasing the physician on-call and work scheduling software.
Image courtesy of pakorn at FreeDigitalPhotos.net