Common misconception about implementing CRM software…

June 18, 2010 Richard Boardman

I’ve just finished writing a fairly long magazine article setting out what I consider to be some of the most misunderstood aspects of buying and implementing CRM technology. I will publish the full article once it’s gone to print, but in summary the eight key areas I identified were:

Misconception 1 – CRM is about choosing the right CRM software – it’s important, but not as important as people think. Technology won’t do anything on its own. The strategy, people and process dimensions are where the challenge is.

Misconception 2 – That the software vendor can cover off the strategy, people and process dimensions – not in my experience anyway. They may know the technology, but the application of that technology to beneficial effect, no.

Misconception 3 – That requirements documents should be three pages of bullet points – functionality oriented requirements specifications, that ignore strategy and process, do not generate successful, cost effective, CRM projects.

Misconception 4 – That vendor pricing is logical and predictable – again not in my experience, vendor pricing tends to be very erratic, and you can get caught out unless you give yourself plenty of choice.

Misconception 5 – That system development is the time-consuming phase – Customising and configuring CRM software is normally a lot quicker than people think, it’s other seemingly innocuous stages such as design, testing, or user adoption that catch people out.

Misconception 6 – That data is a side consideration – people don’t want to see old, duplicated, or incomplete data when they start using their new CRM system, but preparing data can be a bigger task than the rest of the project put together.

Misconception 7 – That half a day’s training will do – user adoption is your toughest adversary, expecting people to attend a few hours of classroom training then go off and use a system in a consistent and structured way is fatally unrealistic.

Misconception 8 – That it’s ok to leave the reports until later – vendors are notoriously squeamish about helping create reports in the early phases of a project, but improved immediacy and quality of management information is generally a key deliverable, and it’s also a key way of verifying adoption, so why delay?

Those, in summary, were my thoughts on common misconceptions, now what else did I miss?