Tips on Finding the "Right" Application and Vendor

 

Last month’s article, "Key Functions to Consider When Looking for a Health IT Application", focused on how to determine the most important software functionalities that are essential to the success of your program.  A multitude of applications are available, each with their own different features and functions, that it is difficult to find the right application unless you have spent time determining exactly what you need before you start looking at the various systems.  Knowing what you need will allow you to identify the applications that provide the "must haves" and appreciate the extra "nice-to-haves" that you may not have thought of or that are of lesser priority. Conducting this requirements analysis will simplify the selection process.

The next step in the process is to take the identified key functionalities (requirements) and develop a Request for Information (RFI) or Request for Proposal (RFP).  An RFI is a less formal process in which vendors are asked to provide information about the products.  It may provide information about the organization and what their needs are, but usually does not provide specific, detailed requirements; is not a formal offer for the vendors to bid; is not binding; and it may or may not lead to an RFP.

 

An RFP is a more formal, structured process that informs vendors that an organization is interested in purchasing an application and offers an opportunity for them to bid on the project. The proposal provides a description of the organization’s strategy and long/short term business objectives; a description of the program the application will be used for; the proposed purpose for the application; the specific requirements for the application; and related information or requirements about deployment, training, implementation, time-frames and pricing. An RFP also asks the vendor to provide detailed information about their company, their products, customers, number of years in business, expertise of their staff, etc. The information provided by the vendor is usually considered binding and responses in the RFP can become part of the contract/agreement.  

An RFP can be open to any and all vendors or it can be sent to only specific vendors. This type of structured process does take more time and effort, but it provides an easier evaluation process, since vendors must show how their application meets your requirements instead of allowing them to just focus on their features and functions.  It also ensures that your organization has thoroughly defined exactly what is needed and how the application will benefit multiple groups within the organization.

 

However, not all organizations choose to use the RFP/RFI process. Some already know which vendors they want to approach to learn more about their products. If this is the case, an organization should not schedule demonstrations from these vendors until they have at least developed a detailed requirements list that can be used by the selection committee during the demos.  It should define exactly what is needed for each step of each workflow process and be very specific about what needs to be captured in fields, how and when automation is needed, what is to be reported and how the system handles unique business rules.  Developing this type of requirements grid can be a daunting task, but it does not have to be.  The requirements analysis (described last month) already identifies what is needed; now you just need to break down each requirement into specific steps.

 

The requirements should be presented in an objective grid format, asking vendors to rate each requirement: (1) part of basic system; (2) can be modified or configured without cost; (3) can be accomplished using a third-party software; (4) requires customization without extra cost; (5) requires customization with extra cost; (6) not available.  Listing requirements in this objective way ensures that all vendors respond to each requirement consistently and provides an easy way for you to evaluate and rank each vendor.  If requirements are presented as open-ended questions, the results will be difficult to evaluate and some vendors may not answer the questions to your satisfaction.

 

Preparing for the demo is the next step.  Case scenarios should be developed for all major workflows, processes and key functions that you want to be able to see and evaluate.  These written scenarios should be provided to the vendors at least two weeks prior to their demo.  You should ask them to develop cases in their application and have them show how each process would be documented.  This will take time for the vendor, as they will need to set up records and tasks to be able to show you the process, but it will help you determine how customer-oriented the vendor is and how well their application is able to handle your workflows without any customizations.

 

While all case management programs are similar in their overall goal of providing a collaborative process of assessment, planning, facilitation, care coordination, evaluation, and advocacy to help individuals meet their comprehensive health needs, each program tends to be developed a little differently depending on the organization’s specific business model and goals.  In my years of experience in the HIT area, I have never seen two programs that are designed exactly the same way—with the same workflow processes and procedures.  That is why it is extremely important to make sure the application you choose is flexible enough to allow you to configure it quickly and easily to meet your needs.

 

Now it is time for the demo.  Each vendor should be given specific, clear instructions explaining exactly what you need to see and how much time they will have for the demo.  To ensure fairness, the allotted time should be the same for all vendors.   The demos may also include time to discuss the vendor’s company, client base, training, implementation, pricing, etc.  Many times these items are left to a second round of demos that may be more detailed for the top two or three vendors.     
The requirements grid should be developed into a vendor checklist with a scoring system.  It should be used by each member of the selection committee during the demo, and the completed checklists should be collected before the committee moves on to the next demo.  This ensures that the information is entered while it is still fresh in everyone’s mind.  It is amazing how easy it is to get one application mixed up with another, if the evaluation is not done right away.

 

Once all demos are completed, the selection committee should meet to evaluate the scores, benefits and limitations of each application and vendor.  Remember, evaluating the vendor based on their experience and customer-orientation is just as important as evaluating the application.  You are going to be working closely with them and depending on them, so you need to make sure you feel comfortable with them and feel confident that they have the experience and willingness to do whatever is needed to help you meet your goals.

 

At this point, you may have determined the "right" application and vendor or, depending on how many vendors you evaluated, you may be ready to bring the top two or three back for a second, more detailed demo.  However, there is one area that you probably still should be thinking about: how to determine the Return on Investment (ROI) for the application.  We will talk about this next month!