Killer misconceptions – 8 common misunderstandings about buying and implementing CRM software…

August 3, 2010July 27, 2018 Richard Boardman

The following is a piece I wrote for Conspectus Magazine recently:

I recently put together an e-book, well, probably to be fair, an e-guide, on how to buy and implement CRM software; which was a roll up of a lot of the content I’d posted to ‘The CRM Consultant’ blog over the years. In the process it was apparent that there are popular misconceptions about many aspects of purchasing and implementing CRM technology – and perhaps for that matter many other types of technology. It struck me that the sooner we dispelled these myths, then the sooner we can better harvest CRM’s potential, so what follows are what I consider to be the key areas of misunderstanding:

That CRM is about choosing the right software – while technology selection is important, it’s not as important as people think. We’re blessed to live in an age where there are a host of flexible, highly functional, low-cost CRM technologies available for purchase. Yes, you need to exercise caution, but there’s considerably less scope to get things wrong as there was five years ago.

The problem is that many buyers see the selection of the technology as the entirety of the challenge rather than a step in the process, and that if they get the right package benefits are going to miraculously accrue. They miss a key point that CRM technology is a tool-set, it doesn’t do anything on its own; it needs to be used in the pursuit of well defined objectives if it’s going to generate any value.

This might be less of a consideration if CRM technology did one thing, but the reality is that CRM can be deployed in a myriad of different ways. Even similar businesses, in the same market, with similar strategies, might use CRM software to achieve vastly different objectives. While I wouldn’t go so far as to say it was unimportant – technology and, in particular implementation partner selection, still trips many – it’s the relatively easy bit. Working out what you want to achieve, how to achieve it with technology, and how to get people to use it are the tough challenges.

That the CRM vendor or implementation partner will resolve this issue – if you accept my previous point then you might suggest that the software vendor themselves, or an implementation partner, should be able to help you. That’s not my experience, and I’ve been round the block a few times. Vendors tend to be focused on the technology not on the solution. If you asked them how to get their product to do x,y,z, they can help, but ask them to really explain how their technology can grow your business then I suspect you will find they come up short. The nub here is that if you are unclear on how CRM technology should be beneficially used for your organisation, don’t look for the vendor to fill in the blanks. You will either have to work it out for yourself or use other sources such as third party consultants.

That your requirements document is a three page list of bullet points – in my experience a solid requirements document forms the foundation of a successful CRM project, but all too often it’s a skimpy list of functional requirements that don’t facilitate cost effective vendor selection. More importantly, as I touched on earlier, they generally fail to articulate a compelling vision for the project, and completely ignore the process dimension of how the system will be used. A good set of requirements in my opinion encompasses the following key areas:

· What problem you are looking to solve or beneficial outcome you are trying to achieve?
· What are the processes that will be used to solve the problems, or achieve the beneficial outcomes, and how exactly will these work within the technology?
· What is the supporting functionality that will be required to support the processes?
· What data integration and migration will need to happen to facilitate the above?

While it’s a crude estimate, a good CRM requirements document that follows the above approach will weigh in at fifty to a hundred pages for the average CRM project. This means that a lot of work gets done before the vendor selection phase, but the benefit is that vastly more value is more predictably generated, with less risk, and at lower cost.

That vendor pricing is logical and predictable – in my experience nothing could be farther from the truth. It’s not uncommon for us to ask for bids from four or five prospective implementation partners, all of whom offer the same CRM software platform, and see quotes coming through with wild variations in price – and that’s when bidding to a detailed specification. This variation not only occurs between implementation partners, but even with the same implementation partner bidding on similar projects.

This phenomenon means that if you are not careful you can significantly over-pay for a system or dispense with an otherwise attractive technology, if the bidding vendor happen to be in the wrong mood when they put the pricing together. The answer is to keep you options open, even if this means several suppliers bidding the same technology. By following this approach, using the front-loaded requirements gathering approach outlined above, combined with smart negotiation, means, in my experience, you should be able to purchase your system 30-40% cheaper than otherwise would be the case.

That system configuration and development is the time consuming phase – given the flexibility of most CRM technologies, configuring and customising systems is a relatively brief affair. This contrasts directly with other core activities which people dramatically underestimate. For example, requirements definition, system design, user acceptance testing, and user adoption, are often significantly longer processes than most people appreciate. Misconceptions around the duration of a CRM project and its constituent parts are potentially fatal from a project standpoint, because the project team get pressured to hit unachievable time-lines, and key activities get rushed or overlooked. It’s essential therefore that would-be implementers of CRM technology appreciate what the key components of the CRM project plan are, and how long they should take, and set everyone’s expectations accordingly.

That data is a side consideration – as I’ve mentioned, technology is generally the star of the CRM show, and the implementation of that technology becomes the focus of attention. However when people come to use their brand new system and find the data is old, duplicated, and incomplete, usage can suddenly fall off a cliff. The problem with data is that while it’s essential to a good system, reconciling and preparing data from potentially many, many unrelated sources can be a long, manual, and time-consuming task that often doesn’t get started soon enough in the majority of projects.

That half a day’s training will do – there’s a really tough adversary that you’re going to have to take on when deploying CRM technology – user adoption – and poor user adoption is the most common cause of death for CRM systems. The traditional thinking has been to give users a few hours of classroom training and then expect them to go off and use the system in a consistent and systematic way. While this may indeed work for a minority of users, in practice the majority require considerable training, hand-holding, monitoring, and a lot of other resources before they develop usage habits appropriate to an effective system. In no aspect of CRM implementation has less progress been made in the life of this technology, than user adoption. Understanding how tough a challenge this will be, and gearing up appropriately, is essential to realising value from a system.

Leave the reports until later – for reasons I won’t dwell on here (but can be found in this blog post) vendors tend to underplay the importance of reporting. For many organisations though, improving the depth, quality, and immediacy of management information, is a key project driver. Reports also have a critical role to play in determining whether staff are actually using the system, and using it in line with the agreed processes. It’s important therefore that as much focus is paid to delivering the reporting requirements as the functional requirements, and making sure these are available to support the effective adoption of the system in the first phase of the project.

These and other points are covered in more depth in the e-book which can be downloaded for free, (and without the need to leave your details), from here. If you are looking to implement a CRM system, or any other complex technology for that matter, dispelling popular misconceptions, many of which have arisen from the software industry’s need to mask complexity in order to sell software, is critical to maximising CRM’s rich potential.