I recently talked about right-sizing your software selection process. An equally important topic is understanding the difference between a software selection process and a vendor selection process.
Before you begin a software selection process, conduct an internal assessment to evaluate the reason for the wanting new software.
- Lack of features, functionality, and compatibility with other systems are all valid reasons to look for a replacement product. If you are not already using the most recent version of the system, explore upgrading the existing solution and compare it alongside other options.
- Lack of training or documentation for staff is an internal management problem, not a vendor problem. When we roll out a new software, the vendor provides training to all of the staff who will use the tool. Then, as staff turnover within an organization, the new hire is often trained on the basics by a co-worker. Internal training rarely provides a deep understanding of how the software works or how the tool can be used as things change. Many vendors offer great training courses. They also provide documentation to help maintain staff knowledge about the system in use.
- When customer support is lacking, then it may be appropriate to begin shopping for a new vendor.
When the root cause of the system discontent is related to software support, it is important to know if the software in use is a proprietary system that is supported by only that one vendor or if it is a common system that is supported by other vendors. When a system is supported by multiple vendors, it may be much easier to change vendors rather than to change systems.
In the association industry, several of the commonly used association management systems (AMS) are supported by more than one vendor. The iMIS solution partner community is a perfect example of diverse vendors with expertise needed to support the ASI product. Common website platforms are also supported by a host of qualified vendors.
When considering switching vendors, be fair to your existing vendor by letting them know your concerns. If they are unresponsive or unable to meet your expectations, then, by all means, shop your business to other vendors.
Even when the underlying system is an enterprise tool used across the organization, the vendor selection team can be made up of a few key staff that regularly interact with the vendor. You eliminate much of the risk associated with the project. Compared to the implementation of a whole new system, the potential cost of a vendor change is minimal. You avoid the hefty implementation fee and the data migration cost. The selection team can be small because you are not having to involve a broad team of subject matter experts to review features and functionality. Those things stay the same.
Rather than a typical RFP process, research review sites and solicit feedback from existing customers. When you have narrowed the list of potential vendors to a small handful, conduct a call with each to discuss support methodology, the expertise of the people on their team and their rates.
When interviewing potential support vendors, it will be helpful for them to learn how you use the system. I would recommend that your team host a meet-and-greet with a few people from the vendor’s support team so they and the staff can get to know each other. It is customary for the vendor to charge a reasonable system review fee to allow them time to ramp up on the specifics of your organization and any customizations in use.
Sometimes it is the right decision to shop for and implement and entirely new software system. But don’t rule out a potential change with the support vendor when the product can continue to be successfully supported by a healthy partnership between you and a different vendor.