Where did it all go wrong – 11 reasons CRM projects fail

June 3, 2018 Richard Boardman

The subject of this post was prompted by a discussion about CRM implementation failure that I saw in the CRM Experts forum on LinkedIn this week, which prompted me to summarise my thoughts on the main reasons CRM projects fail.

Just to give this a bit of definition, when I say fail, I mean projects that fail to generate any significant operational benefit, rather than outright fail as in they don’t go live – though this could clearly also be the case.

And to give this some sense of scale, in another recent forum I posited the notion that 80% of existing CRM deployments are failing to generate significant results.

Though this figure is based on gut feel rather than methodical research, and, it has to be said, not everyone agrees with me, enough other contributors had estimates in the same ballpark as to suggest this figure isn’t entirely outlandish.

Whatever the figure, I think it’s safe to say a reasonable number of implementation projects fail. I would also say there isn’t any reason why they should. Implementing a successful system isn’t rocket science, it’s just a case of avoiding the common pitfalls. So, the following are my take on the main reasons that CRM projects go astray:

Lack of clear objectives – I was at a conference recently speaking to a senior IT guy whose chief exec had decided to negotiate a multi-million pound deal for CRM software. I asked how the project was going. It wasn’t. The deal had been done 18 months ago, but so far they hadn’t figured out how they were going to use the software. The nub is that CRM software doesn’t just magically do stuff. You have to have a clear vision as to what you want it to improve. Too often this clarity of purpose is missing, and, as the saying goes, if you don’t know where you’re going, every road leads there.

Requirements aren’t done up front – regular visitors to this blog probably know I’m something of a pedant for the practice of doing detailed requirements before you start to procure. Too often I see situations where people invest substantial money in software and services with often only a bullet-point list of functional needs.

When the chosen implementer does their detailed ‘discovery’ exercise, the costs can suddenly escalate, sometimes multiple times the initial estimates. The problem at this point is that you’ve generally invested a fair amount of time and money going down this route, which means you either live with the hiked price or start the process all over again with another supplier. I have seen projects extended very literally by years, as customers go through the same exercise with multiple vendors. By the time the project is finally delivered, enthusiasm for the project is long lost and the business need may no longer exist, or have been addressed in some other way

Getting requirements done up front avoids these false starts, but also allows you to procure the system more cheaply as there’s a detailed spec for vendors to give firm pricing on, reduces the risk of selecting the wrong technology, and delays through ‘scope-creep’ where requirements are uncovered late in the day.

The wrong solution – This might be selecting the wrong technology, but can also be about selecting the ‘right’ technology, but incorrectly architecting it to address the operational need.

The wrong implementer – While there are a myriad of CRM implementation partners out there, in my experience the quality is very mixed. But I think the operating assumption by customers is that the quality is generally high. This assumption often results in a lack of rigour in the selection process, which sees many team up with suppliers who aren’t competent to implement the system.

Lack of sponsorship – Successful CRM projects need an internal sponsor. The sponsor doesn’t have to be at the highest level of the organisation – though this helps – but they do need to have the gravitas and commitment to make things happen.

Insufficient resources – CRM projects consume as lot of resources. It generally takes a significant investment in software and services, but also requires a lot of man hours from internal staff. The problem is that the internal staff involved in a project generally have day jobs, and, given the required time commitment, more often than not have insufficient time available to properly fulfill their role in the project.

Supplier management – As I noted earlier, one of the key reasons for failure is that customers recruit poor quality implementers, but there can also be issues where they get the implementer selection right, but don’t manage the relationship well. A lot of implementer/customer relationships that I see are pretty fraught, and even if the relationship survives to initial live, there isn’t the long term rapport to successfully evolve the system.

Too much too soon – I think one of the problems that CRM customers have is that the project becomes all things for all people, rather than focusing on a solving a specific problem well and building on this success to extend the system over time.

User adoption – Alongside the failure to detail out requirements up front, that I dwelled on earlier, user adoption is the biggest CRM killer, in my opinion anyway. There are a lot of, otherwise, perfectly good systems, that don’t give the results they should because they don’t get used.

To illustrate the point, I was asked to review a system a few years back and suggest improvements. The customer was clearly very proud of their system. They’d lavished a lot of money on it and were a high-profile reference site for the CRM software they were using.

There was nothing obviously wrong with it, it looked well set up to support their processes. The problem was when I looked at the usage stats only nine of their one hundred and twenty salespeople had even logged in to it in the previous 30 days, and those that had were using and updating the system in completely different ways.

User adoption isn’t a new issue. It’s haunted the industry from day one, but it isn’t routinely addressed, perhaps in the mistaken belief it will just go away. It requires a well thought out strategy and plenty of resources. In my view as much work should go into the post-live phase of a project as pre-live, though that’s rarely the balance that’s achieved.

Post live support – As I mentioned in the previous point, achieving consistent initial adoption of the system is generally challenging, but even when achieved this needs to be maintained over the long term. CRM systems are fragile flowers, and to survive and flourish, they need careful administration, both of the system, and especially the data quality.

New users need to be successfully inducted to adopt the system, and the system will need to evolve and grow over time. The resources, however, often aren’t in place to make this happen, and otherwise successful projects, can quickly become obsolete.

Unwillingness to take advice – While I accept, as an independent CRM consultant, that this is a tad self-serving, customers are spending a lot of money on technology, committing a lot of internal resources, and putting reputations on the line, it’s surprising that more of them don’t seek advice more often than they do. In this respect I’m not just talking about external advice, but also internal knowledge. Many organisations have a legacy of failed CRM projects, or staff who have worked for organisations that have had failed projects, but this experience isn’t always accessed, and necessary lessons learned from the past.

Oddly enough, if I’d written this piece ten years ago when I first started blogging (and I probably did but have long since forgotten) I’d have probably listed the same eleven. While as an industry I think we’ve got better at implementing CRM technology, it seems a little odd that we keep finding the same old traps to fall into.