The process of selecting a new system is often a very exciting time for an organization. But when the contract negotiation with your current vendor does not end well. You present the issue to the C suite and all of a sudden your knee deep into an RFP. Of course everyone wants to get involved and all the VP’s want to have a say in the requirements document. However, what about the folks that will be using the system eight hours a day? You know, the people that will be the most impacted by the change, the ones that will be required to work more efficiently with the new systems because….that’s what the new vendor said would happen.

We often get caught up in the RFP process and forget that the key to system selection is to use some creative thinking and design the workflow from the ground up. If you’re looking for a “replacement” to your current software, then that’s exactly what you will get. But when you think about the opportunity to really change the way you service your patients and the way your employees can be more efficient, then you can really make a difference.  

 Reach back to all your old quality training, Deming, Toyota, whatever and at the core it’s the same message; your front line workers really know what’s going on and what workarounds they are using because the existing system is so bad. They are also the first ones to create new workarounds because the brand new system now takes five mouse clicks to do what the old one did in two. So while the C suite celebrates the go-live along with the project team, the front line folks are busy creating new workflows and steps to adapt the new system to the old way of doing things.

Don’t get me wrong, super-users are great, but they are also the ones that are technology savvy. They also tend to be supervisors. You need to peel back the layer one more time to get to those users that are running around the hospital and practices trying to get the information to the people who need it. Set aside at least an afternoon with your core users and capture their pain points. Make sure you get what they are talking about in terms of the current impediments of the system, and how they would improve or change it. The result will be a gap between what the vendor promises and what you need. That gap can be addressed with workflow improvements or customization.  However you address it, make sure it becomes part of your project scope. Going through the motions with your staff and then not delivering on what they asked for is a sure moral buster. Not to mention that it is counterproductive to the efficiency you hope to gain with your software investment.    

 The key to all of this, besides engaging your staff is to make sure your selected vendor is on board. If they insist that they know best and they want you to drink their Kool-Aid, then go back to the project scope and hold them to it. However, if the C suite drinks the vendor’s Kool-Aid then you are stuck in the post go-live “dawns early light” trying to figure out why the new system isn’t “working.”