CRM Selections: When An Ounce Of Prevention Is Worth A Pound Of Cure Part One: The CRM Selection Challenge

Over the past two years it seems not a week has gone by without an editorial about a failed Customer Relationship Management (CRM) project. Many articles relate CRM failure to the absence and/or weakness of business objectives driving the CRM initiative. Although this is true, many projects fail due to a poor vendor selection procedure.

Starting At The Beginning

Of course software tools such as business applications are necessary for the vast majority of CRM initiatives, but you don't start building a house by conducting a search for tools. You begin by developing a vision of what you want your house to look like. The CRM vision should consist of a clear, well constructed model of how the company would like to interact with customers throughout the customer life cycle. Customer interactions need to be modeled for marketing, sales, service and support functions across various interaction channels such as marketing collateral, physical retail locations, call centers, websites and mobile sales forces. Once the vision is properly formulated it is important to model the business processes required to fulfill the vision. After the business processes have been modeled it is necessary to determine the functionality and technology requirements that enable each of the business processes. In summary, the procedure is as follows:

Document
the CRM vision -> Determine the business processes required to enable the Vision
-> Determine the functionality and technology required to enable each of the
business processes.

Two of the greatest challenges IT decision makers face when selecting a CRM package is first, having a comprehensive understanding of their functional and technical requirements and second, identifying the vendors that best match their requirements. This article will focus on determining the functionality and technology required to enable business processes, and how to compare vendor offerings once those requirements have been documented.

This
is a two-part tutorial on selecting a CRM solution.

Part
One outlines the challenges faced by companies in selecting a CRM solution.

Part
Two details how use of a knowledge base can aid this process.

The Typical Selection Process

Once the functional and technical requirements are well documented, finding the right vendor becomes the next hurdle. Traditional vendor selection procedures usually commence as follows:

The
selection team collects and documents all of the requirements from each department
and builds a lengthy Request For Information (RFI), which is essentially a
laundry list of features and functions.

The
selection team issues the RFI to vendors that the selection team has either
heard of, been told to include from executive management or learned about
through general, high-level IT research.

Weeks
later the RFI responses are returned and the selection team compares the various
responses to determine which vendors to invite for demonstrations. The selected
vendors comprise the "short list."

Once
vendors on the short list have been contacted, sales teams come on-site to
give either canned or customized demonstrations of the software to validate
the functionality and get a feel for each product's ease of use.

Selection
teams then issue a Request For Quote (RFQ) to the short list vendors. The
RFQ typically details such costs as license fees, maintenance fees, and the
implementation procedure and fee structure.

The
selection teams draw on the demo performance and RFQ responses to negotiate
the price and terms with each of the short list vendors.

Finally,
one of the vendors is chosen and a contract is signed.

The Drawbacks

Although the typical selection process provides an opportunity for the selection team to evaluate vendors, there are significant drawbacks to this procedure:

Constructing
an RFI from scratch is a lengthy, resource intensive process that can take
months to complete. Many companies do not know where to begin or how to structure
the document. Often the requirements are determined by simply combining wish
lists from various departments, rather than determining requirements from
desired business capabilities.

The
initial list of vendors that receive the RFI often lacks viable solutions
because the selection team is unfamiliar with the enterprise applications
market. This problem is prominent in the mid-market, where many vendors occupy
the market, and the product and implementation strategies can vary considerably
among the vendors.

Retrieving
RFIs from vendors can be an arduous process. Many vendors are inundated with
completing RFI work, thus can take weeks to return an RFI to a potential customer.
Furthermore, the selection team has no way of validating the data at the time
they received the RFI. The teams have to wait until they determine the short
list and invite the finalists to demonstrations before they get a chance to
validate functionality. Aggressive sales teams have been known to overstate
capabilities, only to try and sell "vaporware" when they arrive for a live
demonstration.

Selection
teams often lack a tool or method to compare the RFI responses. This is especially
problematic when selection teams do not setup a specific process for the vendors
to follow when answering RFIs. Leaving the potential for open-ended responses,
having illogical response categories and not requesting the responses in a
structured electronic format that can be easily used to compare results are
a few of the problems. Even selection teams that have the foresight to avoid
these problems are usually left with simple MS Excel or MS Access based tools
to compare the results. These tools often lack the ability to do sophisticated
analysis such as identifying and quantifying gaps between vendor offerings
and the company's requirements.

During
the demonstration phase vendors are left to give their own canned demonstrations
where they lead the selection team through a well choreographed display of
their product. Allowing vendors to give canned demonstrations causes two problems.
First, after the selection team has seen three or four canned demonstrations
they have no way of comparing the results. Without a structured demonstration
process where the selection team dictates that the same functionality be demonstrated
for every vendor, the teams have to compare apples and oranges. Second, canned
demonstrations make it very easy for the vendor to sell vaporware and make
the product look very easy to use.

Some
of the problems that haunt the RFI phase can return during the demonstration
phase. Selection teams that avoid canned demonstrations by detailing the functionality
to be displayed in the order they would like to see it face the same problem
comparing results experienced during the RFI phase.

This
concludes Part One of a two-part tutorial on the CRM selection process.

Part
Two details the Use of a Knowledge Base to facilitate the selection process.