Be sure to check out part 1 in the series.
The primary driving document of a software selection is often the RFI or RFP, the invitation to vendors to participate in the process.. In future articles in this series, we will discuss the process of software selection and obtaining buy-in from stakeholders after the RFI has been received. For this week, we will focus on that centerpiece document, the RFI. This document sets the stage for the process, creating the tone and establishing the way that the hospital will work with the vendor during the selection.
However, far too often creating this document becomes the focus of the process rather then the actual selection. Creating an RFI should not be a large effort and done properly, can be one of the easier steps, allowing the journey to begin much faster.
The purpose of an RFI should not be to provide a laundry list of needs and wants to the software vendors. An RFI that includes pages of checklists of features can take a considerable effort to create and an even more considerable effort for the vendor, and actually adds little value. When it comes to mature software solutions, such as ERP and EHR solutions, it is very likely that the vendor understands your needs better than you do. They demonstrate software to hospitals every day, and have numerous customers who have been through the same changes and challenges that you have.
Several years ago I was working alongside an ERP software sales team and joined a meeting in which a potential customer had allowed them to present their solutions following completion of an extensive, laundry list style RFI. During the discussion the potential customer’s CIO was present and was looking through the response to the RFI carefully, with a frown on his face.
Then he looked up and asked a question. “I am reviewing your response to our RFI”, he said, “and I see that you answered no to many of the items in our requirements. Why should we choose you over another vendor who met more of those needs.” The salesperson from the ERP team was not only a seasoned salesperson, but also well versed in the business processes of ERP and was well prepared with an answer that I often reference to this day.
“Do you know what a Japanese auction is?”, he asked the CIO. “Actually”, he continued, “does anyone here know what a Japanese auction is?.” Everyone looked confused, but no one spoke.
“I don’t, but why would you ask that?” inquired the CIO.
“Because it is a requirement of the software in your RFP”, the salesperson responded, “and one of the examples where we said no”. He then went on to explain what a Japanese auction was to the hospital team, and asked if they would ever use that functionality. They all agreed that they would never have a use for it. In closing the salesperson asked what consulting firm wrote the RFI for them and if they were advised that they needed to include it, or if the consultant simply forgot to remove it from the template they were using.
This story highlights that the software vendor is well aware of the features and functionality that a hospital would typically use, and does not need a list of those features. It also demonstrates that paying a third party to develop an RFP does not always lead to a more effective document – and in some cases leads to a less effective document.
Rather than a laundry list of features, an RFP should tell a story. The story of who you are, where you are now, and where you want to go. It should explain the vision and objectives of your project, the organization’s current challenges, and your future vision for the hospital with the new software. The RFP should invite the vendor to participate and present how they will help you to achieve those goals. Each vendor can then present why their solution is the best to get you to your desired destination.
Specific features and functions are much less of a key difference between software solutions today. Feature lists have actually led many vendors to write and acquire software for the purpose of being able to check boxes in an RFP rather than reacting to actual customer needs or with the intent of producing a quality product. It is increasingly unlikely that a “smoking gun” will be found with a specific absolutely necessary feature existing in one vendor option but not the other. Rather, it is the design and the quality of the solution that is important, as well as confidence in the vendor and their ability to partner with you effectively and capability to deliver on their promises.
Indeed there is more to an RFP – and in a future article we will discuss how to define the rules of the road of the selection process and to make sure those rules are reflected in the RFP and that the vendors and staff follow those rules. However, the core content of an RFP is expressing that vision to your potential software partners.
Therefore rather than spending months of creating lists of checkboxes of features that you may or may not need, just tell your story. Explain the vision of where you want to go and invite the potential solution providers to explain to you how they will help you to achieve that vision. The result will not only be a significantly faster selection process, but also a better relationship with your vendor partners during the selection and beyond.
If you’d like to receive future posts by Brian in your inbox, you can subscribe to future Healthcare Optimization Scene posts here. Be sure to also read the archive of previous Healthcare Optimization Scene posts.
