What a CRM consultant would tell you about buying CRM software - part 3

As I’ve noted previously, the key foundations to effective purchasing are to define a detailed set of requirements, and in light of those requirements assemble a group of relevant technologies and capable vendors to select from. Step three is to prepare and distribute a request for proposal (RFP) document in order to better evaluate the available options. While some purchasers are inclined to skip this stage, and start directly auditioning potential suppliers, as I’ve mentioned in a previous post (from which I’ll briefly quote) this can be a risky approach:

‘From my time as a CRM vendor, I'm all too aware how easy it is to script a demonstration in a way that showcased the offering’s strengths and skated over the weaknesses. As a CRM purchaser, faced with assessing a dozen seemingly similar CRM offerings, I’m acutely aware how difficult analyzing the differences can be - even with the benefits of years of experience, and a reasonably tutored eye.’

When you initially receive written submissions from a vendor it gives the opportunity to compare and contrast the offering in a much more structured and analytical manner, and gives you a basis for action should disputes over what was promised arise in the future.

Our goal though with the RFP document is to strike the balance of getting the information we need, while making it as easy as possible for the vendor to respond. If we make the RFP too onerous then we run the risk of potential suppliers electing not to bid. As I mentioned before a good vendor is likely to be a busy vendor, and they will weigh carefully the potential for successfully winning the business and the time/cost involved in preparing the response, so I like to keep the latter element as light as possible.

Our RFP document sets out how and when the vendor should respond, and then prompts the would-be supplier to respond in a number of areas as follows:

Questions relating to the profile of the software and its developer.

Questions relating to the profile of the software vendor/implementer, particularly in relation to support capabilities, implementation approach, and experience with similar projects.

Cost structure including a detailed breakdown of both vendor supplied elements such as software, services, training, and support and maintenance, as well as any non-vendor supplied elements that will incur costs such as hardware and database software.

The final element is a table referencing the detailed requirements document asking potential vendors to confirm whether they meet each item, and provide man-day estimates for any that will require customisation/development to deliver.

While some of the vendors we work with may choose to disagree, we find this approach is light enough not to discourage responses, while providing us with sufficient information to make informed judgments about suitable candidates for the next phase…to be continued.