My CRM project failed because of lack of user adoption. Really?

We all like successful projects and rightly take satisfaction from the adoption of new technology into the business. Sometimes, though, they don’t quite work as intended; often, it’s a lack of “user adoption” of the technology that is cited as the cause. But is this the real issue? Isn’t it more likely that user adoption, or a lack of it, is a symptom rather than a cause? Is it not more likely that those users, accused of not adopting, are actually unable to adopt because of inappropriate software, lack of guidance or lack of support?

Software is ultimately just a tool to do a job and CRM is no different; users don’t necessarily care whether it’s called ERP, CRM, Word, Excel, or anything else; they just want to know when and what information to record and to be able to record it easily and consistently. When they save information, the software tool should respond in a way that indicates that that part of the job has been successfully completed or not (with suitable guidance if not) and what to do next.

Implementing new or upgraded CRM obviously demands that the users of that tool behave in a different way after go-live than they did before. So what’s stopping them? Well, a number of things, potentially.

I often ask my clients at the beginning and during CRM projects “What problem is it that you are trying to fix?” It’s remarkable how often the response lies at the non-existent, unclear, muddied or indefensible end of the spectrum. However, if you’re not clear on this, how is it possible to make the software, that tool to do a job, behave in a way that clearly supports and guides the users of that software? Ultimate result? An inappropriate tool that isn’t understood by users.

Of course, we all know that CRM projects rarely succeed or fail because of the technology – it’s all about people, processes, change, politics, leadership and culture. These days, CRM technology can cope with huge amounts of complex logic in the way that it behaves. Therefore, the challenge is not so much about identifying the limitations of the software as it is about working out what is really needed and what level of complexity is actually digestible. I once worked on a project where the organisation undertook identical processes in a different manner on different days of the week! The organisation had, over time, put in alternative steps to cope with the fact that certain members of staff only worked on certain days of the week. The requirement was then to replicate these “if – then – else” scenarios in the software. While it was technically quite easy, the result was a bowl of spaghetti – untestable and unusable. It might have been workable for a limited number of simple processes, but when applied to multi-step processes and then extrapolated across a number of departments, themselves with their own flavour of each process, what resulted was expensive and a failure.

There are obviously times when this level of complexity is absolutely critical but, more often, it’s best that the consistency of behaviour that software tends to demand is applied to the business processes, rather than making the software cope with every eventuality. So, where the problem that is trying to be fixed is clear, make sure it remains clear and achievable. Trying to cope with every eventuality will deliver up something to the user that they cannot understand and is very difficult to train. So, CRM user adoption is often scuppered by the creation of something that is just too big to take on, or has attempted to deliver everything in one go. Tight focus on the real needs of the solution and the consideration of phased approaches are the best ways of making software deliveries relevant and of benefit.

That might not be enough though. There are many studies that describe the reasons for and the steps of change management. Communication and support for users through the process of bringing about change into an organisation is critical. Users need to clearly understand why their processes or tools are changing and where to go to get advice and support. They need to have time invested in them in order that they become both knowledgeable and skilled and, ultimately, they should be rewarded for keeping going! The easiest trap to fall into is when, particularly under pressure or from a lack of support, users revert to old tools or processes. Highly-dynamic organisations often fall into this trap. Hunger to address the next challenge and next set of changes often results in senior management failing to reinforce and reward the new behaviour because they’re already on to the next project. What is really needed is for senior management to show leadership and guidance so that people can, essentially, dive off the diving-board.

So, for me, lack of CRM user acceptance may well be the manifestation of the doomed project but that lack is always just the result of something far more profound. It is always a symptom that something, somewhere else, was not recognised or managed with the level of diligence necessary to enable users to confidently pick up the new tool.