To ensure that your organization makes an educated software purchase, you need to know exactly what a software package can and cannot do before you sign on the dotted line. There is a good possibility that no software package can do everything you want. That's OK if you agree, before you purchase the package, to accept the limitations.
But selecting the right software package is only half the battle. If the software implementation process does not go smoothly, staff can become demoralized, and the software package ultimately can fail to meet your organization's needs.
To select the “best” software package, an organization needs an accounting of all of its requirements. Many organizations purchase software without knowing what they really need, and later wonder why the software does not work.
The R2ISC Criteria
One way to determine your organization's software requirements is to use the R2ISC Criteria, which I developed. R2ISC is an acronym for:
Requirements Current are all the known requirements. Examples include the ability to produce an electronic claim in the format your state's Medicaid agency requires and the ability to produce a bill for a client, among many others.
Requirements Future is the software's ability to meet your future needs (of which you are not yet aware). If software is well-designed, well-written, and well-documented (i.e., notes in the software make it easy for someone to modify it, and good implementation, technical, and user manuals are available), it will be easy for the vendor to enhance and upgrade the software. Also, if the vendor is not financially sound and bankruptcy is a possibility, there is a good chance that the vendor will not be able to meet future needs.
Implementability is how easy it will be, and how long it will take, to implement the software.
Supportability is how easy it will be to support the software on an ongoing basis. For example, can you make changes to the software, or is only the vendor able to do so?
Cost is the total purchase and implementation costs plus all associated costs that will be incurred over the next five years (five years is considered the life of a software package before it needs major enhancements). Cost also takes into account the economic benefits that will be realized from implementing the software, such as increased efficiency, more productive staff, and so on.
Most organizations want software that meets all of their current and future requirements, is easy to implement and support, and is very cheap. Unfortunately, it's not likely you will find such a package. But you can determine the ideal software package for your organization.
Using the R2ISC method, first determine the importance of each of the five R2ISC Criteria and allocate 100 points among them, thereby determining the R2ISC Criteria Need. This is the “high-level basis” for comparing software packages, revealing if cost, functionality, or implementation time is the major consideration. High-level executive personnel should complete the R2ISC Criteria Need rating process. Once the R2ISC Criteria have been rated, each of the criteria needs to be broken down into detailed requirements or questions for a vendor to fulfill/answer.
To determine current requirements, list all known requirements. Users should be heavily involved in generating these requirements, which should be very detailed. The list is likely to be quite long.
To determine future requirements, list questions that will determine if the vendor's and technology's current and future direction are aligned with your organization's direction. For example, has the vendor been in business for more than five years? How many behavioral health customers does it have (and how many of those are in your local area and state)? How well is the software documented and written?
Many of the requirements for Implementability and Supportability are the same because many of the factors that affect implementation also will affect software support. List questions such as, how long has the software been on the market (it often takes three years for bugs to be discovered and fixed, and the needed enhancements added)? How often has the software been modified (if the software is modified often, there could be a problem with the software's initial design or quality)? How compatible is your current information technology infrastructure (operating system, database, and so on) with the software package? What is the quality of the vendor's software support personnel (such as knowledge of the product, ongoing training, etc.)?
The cost of a software package, of course, isn't just the price of the software itself. You have to take into account ancillary software programs that may be needed, hardware requirements, five years of software and hardware maintenance, internal costs (costs from time spent on software implementation, training, initially reduced efficiency, etc.), and external costs (e.g., consultants). List all of the relevant cost factors. The software might be the less expensive part of the entire implementation process.
After all the needs have been listed, each should be rated from one to ten to determine how important it is to the organization (with ten representing a “must have”). This determines the Requirement Need.