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

Introduction

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:

1. 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.
   
   
2. 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.
   
   
3. 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."
   
   
4. 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.
   
   
5. 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.
   
   
6. The selection teams draw on the demo performance and RFQ responses to negotiate the price and terms with each of the short list vendors.
   
   
7. 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:

1. 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.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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.
   
   
5. 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.
   
   
6. 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.