ITA Pro Magazine - February 2014

For many of us the idea of going through a vendor selection process can be a daunting task. The day-to-day task of running an IT department has its own schedule with staff meetings, working with business management, and keeping the systems available for the general corporate workforce. These are enough to challenge a typical workday to say nothing of adding a strategic initiative on top of everything else. However, like most things in the IT management process, you have the task of getting it done.

My goal with this article is to bring some process and methodology to the task for IT managers who may not have been through the process before, or for tried-and-true managers that may want to reaffirm their practice. For a significant vendor selection process, such as searching for a claim, policy, or billing system, plan for six to eight months to do it properly.

The first set of tasks is to establish a vendor selection committee. In our organization, this is usually comprised of a business sponsor, a member or two from their department, other business stakeholders, and IT resources. From this group, we select a subcommittee that will follow the vendor selection process through the selection of three vendors. The full committee is then responsible for the final vendor selected.

The selection process begins with determining what your requirements are. Without solid requirements generated from business stakeholders, the rest of the progression will be in vein. This step in the process may be more challenging than originally anticipated as stakeholders may not agree on what the requirements should be. However, getting the stakeholders on the same page is critical and fundamental to the success of the vendor selection and the final system implementation.

My preferred method for documenting high-level requirements in the vendor selection process is using Excel with the requirements in the first column, and assigning a relative point factor to the requirement in the second column. The relative point factor is the importance placed on the requirement as it relates to the organization. As an organization, we recently went through a vendor selection process for a claims system. Figure 1 provides two examples. First, an example of what is meant by high-level business requirements for a claims system, and second what the relative point factors are for each requirement.

The requirements shown in Figure 1 are business-related
requirements. The requirement gathering step should also take
into consideration technical, financial, implementation risk, and
contractual requirements. In our claims system example, we pro-
vided technical requirements where the system must be written
in .Net and support the use of SQL server. The financial require-
ments were around company size (revenue), number of employ-
ees (onshore, offshore, near shore) with the proper skill set, and
contract requirements (fixed vs. time and material). Lastly, we
included factors that would reduce implementation risk (experi-
ence, unofficial references, and key vendor employees).

Now that a list of high-level requirements are in place with business representatives in agreement as to the relative priority to the organization, the focus can shift to generating a list of potential vendors. For a claims, or policy system, our goal was to identify 12-15 potential vendors. To generate a list of potential vendors, reach out to your personal network of industry IT managers, insurance and technology conferences, research analysts, and trusted consultants.

Leveraging Social Networks

There are several social networks that you can leverage. I belong to a couple of IT management LinkedIn groups that are specifically focused on the insurance industry. Following a couple of groups will allow you to post questions about potential vendors as well as interact with individuals that have specific experience with different products. The new Insurance Technology Association (ITA) group provides a forum for IT managers to interact.