According to Gartner, 63% of CRM implementation projects fail to deliver on their investment.
Many report CRM systems need to be re-implemented three times or more just to get it right!
14% of Managing Directors want to junk their CRM platform and start over! From our experience rescuing CRM implementations and projects, we’re surprised it’s not higher.
Why do so many businesses implement CRM so badly?
We’ve identified 6 key reasons why CRM projects fail. We see these again and again.
This exchange from Alice in Wonderland sums it up nicely!
Alice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don’t much care where.
The Cheshire Cat: Then it doesn’t much matter which way you go.
Alice: …So long as I get somewhere.
The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough.”
Sometimes the business has only the vaguest idea of what it wants to achieve from the project. All too often, the expectation is that ‘everything will be better once the CRM is in’, but no one defines what ‘better’ actually looks like. So when things are not perfect (and they never are!), CRM takes the blame for every issue.
One of our clients had to rebuild their solution twice - and they did not change the software within this timeframe. Their problems were in how they implemented the software, with too many badly done customisations. Their primary problem was very inadequate scoping, while tying their original vendor to a fixed price. They have now gone live, but with many fewer users than expected, much less functionality and a far bigger bill.
When scoping is discussed, the questions of whether users should be involved in the scoping, or just IT or senior people will be raised.
User involvement is both a blessing and a curse. Absolutely users need to be involved in the scoping as they understand their roles and therefore they should be able to help decide what functionality is required. Users should also be heavily involved in the user acceptance testing - UAT. However, both of these must be done in a co-ordinated fashion. This may seem obvious. However, this often is not how it done - the implementer in question just agrees to everything (or almost everything) that anyone asks for. Every feature that is agreed to be necessary (itself an often missed step) should then be checked by someone who knows the selected technology intimately. This is to work out firstly whether it should be implemented using standard functionality, configuration or customisation. Secondly the design needs to be checked to ensure that it does not interfere adversely with other existing functionality.
I have recently become aware of a large organisation in NSW who deployed Microsoft CRM using a partner, and because too much change was agreed to in an unco-ordinated way, the solution now has large amounts of automation that is tripping over itself, so the system runs ridiculously slowly - so much so that they have been advised to chuck out the entire solution and start again.
And when designing functionality, it is important remember that 'two out of three ain't bad'. The trifecta of desirable functionality is low cost, quick delivery and high quality, and you can only ever have two of the three. Your business priorities should decide which two.
Good scoping turns vague improvement ideas into SMART (specific, measurable, achievable, relevant, time-based) goals.
If you automate inefficient processes, they’re still inefficient. It never ceases to amaze me how often a business process has become convoluted or downright destroyed. This has often come about because users have just muddled their way through, or many small changes have been made (each of which seemed a good idea in isolation) without anyone reviewing the entire process.
Sometimes, when I ask why something is done in the way that it is, the best answer that I can get is "that is how we do things round here" without anyone knowing why.
And perhaps the worst scenario is that when I ask for details of the processes, someone pulls a folder from a shelf and shows me some professionally drawn flow charts. When questioned I discover that the flow charts were produced by a consultant, but that they do not represent what is actually done.
Often managers ‘know’ what the standard process is, but four out of five people in the team are doing things their own way. Implementing documented processes which no one actually uses doesn’t help. If users are introduced to CRM and shown a process which makes no sense to them, they will likely feel that 'management are wrong' or the consultant 'does not understand the business' and so quickly revert to using their own way of doing the job.
If you automate broken processes, they’re still broken. It is far better to review and improve them before you automate.
Make sure you spend time finding out what processes are in use and then implement these, (with any improvements you or your CRM partner identify and which your users support.)
Once the processes have been mapped, they then need to be compared to the standard functionality so that the maximum benefit can be gained from the functionality that you already have. If this is not done, you run a risk of re-inventing the wheel, by paying someone to implement something that you already have. In the projects that I have seen, I have never encountered this sort of re-invention leading to an overall improvement.
The data in your CRM system will make or break your implementation.
If data is missing or inaccurate your users will lose confidence in the system. And if you try to avoid the headache of data migration by asking people to re-enter data you may avoid a riot, but users are very likely to return to their previous systemsand carry on as before. Users, like most of us, focus on their needs, the WIIFM (what's in it for me). They will see their need to get their job done as far more important than managers accurate data or reporting.
Carefully analyse your data, clean it up and format it for import into your new system. This is especially important if you’re combining data from more than one data source.
Remember, a stitch in time saves nine. Going back and trying to correct data is a major cause of headache and a leads to users not trusting the system (which then leads to them not using it).
One of our clients is a membership organisation who moved their membership data into CRM. Several months later one of the team members noticed that the number of particular type of members was too low. Analysis of the data in the new system showed that memberships of a particular type had been migrated across incorrectly, so the type had changed.
How good is your data right now?
Testing is there to identify issues with process and bugs. Testing is not, or shouldn't be, an opportunity for users to add to the functionality. This happens and is a common cause of scope creep.
User testing is especially important. It’s about how your users will use the system in real life, rather than what a developer thinks users do. But if your users are testing in a hurry one afternoon while their ‘real job’ piles up into a backlog, how thorough are they going to be?
Plus, you need to test not just the ‘standard’ process, but also the exceptions – the weird and wonderful variations your own clients and prospects come up with. (For example, your credit card process needs to handle invalid cards, potential fraud, insufficient funds, negative transactions and more.) These may only be a small proportion of total transactions, but you have to test them to ensure a robust system.
Learn more about best practice user acceptance testing.
‘My team are smart, they’ve used a CRM before. They’ll work out how to do it on the job.’
Yes, they probably will.
But each of them will work out a different way to do things. And some (most) of those ways will not match the process your CRM was configured to support. So vital data may be missing from reports. Or workflows may not trigger when expected. And when new people joiun the team, different users will train them ‘on the job’ in two different ways.
A good CRM project includes a training plan, with different types of training at different stages.
I recently spoke to a client who was very keen to do training. The only block was getting people from numerous locations across NSW to Sydney. A couple of weeks later training was no longer needed becasue the rollout had been brought forward so there was no time. One has to ask how much planning had gone into this project and what will happen after these people are using CRM.
Training is where you will release the investment in the CRM solution that you spent time and money to build.
Not training users is not only inefficient, it is insulting to users. People who are at the frontline of your business, talking to your clients, deserve to have the systems that support them in their work made as easy as possible to use. This requires training the users in the best practice processes that the system has been designed to support and showing them how the system supports them as they do their work.
Training is often reduced or cut completely becasue of time and / or budget overruns. However, this almost always leads to increased costs in the long run. Creating a situation where people work inefficiently, or get frustrated, or worse still make mistakes when looking after your customers is rarely a good investment. People's time is a valuable resource. Training is essential if this value is to to be maintained.
CRM is a combination of technology and “business process”.
Successful CRM hinges on getting the business processes and the reporting right. In many ways the technology is immaterial. You could use any of the leading technologies and still get it wrong. (See point 3 – Garbage In, Garbage Out.)
Your IT team may be experts in your existing systems, but are they experts in 3rd party CRM? Or even in your own sales and marketing business processes? Leaving CRM implementation to in-house IT is one of the major reasons why CRM projects fail.
When you engage a 3rd party expert organisation, they not only document and implement your processes, and data and reporting requirements, they also contribute ideas and improvements based on their experience in previous projects.
And when selecting a partner,
Don’t get fooled into choosing a ‘gold partner’ because ‘they are at the highest level and must be best’. Partner status is often based on revenue or licence numbers rather than end client satisfaction. Even partner size can be misleading. What’s the benefit of a bigger company if 95% of their staff work in areas other than CRM? Or if the CRM ‘experts’ only have experience of two to three (or fewer) CRM projects each?
How confident are you about your CRM project?
Will you become one of the 63%, or worse still will you lie awake at night wishing you could turn back the clock?
Or find yourself re-doing the implementation?
At Opsis over the last dozen years we’ve helped hundreds of organisations ranging in size from two people to many hundred people implement CRM projects successfully. Often, we’ve been called in to “rescue” a project that’s already been implemented but is failing to deliver.
Please don’t let this happen to you.
For a no-obligation discussion about how Opsis can help with scoping, planning and implementing a successful CRM, or with CRM Project Rescue, contact us today on 02 8212 3480.
Or to read more, you may like these articles.
Of if you prefer to see all of our services to help you with CRM please visit opsis.com.au
Opsis is an expert Microsoft Dynamics 365 CRM consulting company. We are not an IT company, nor a management consultancy, although we often work with both of these. Our focus is wholly CRM success, with Microsoft Dynamics 365. We are based in Sydney, NSW, with clients in Sydney, Canberra, Melbourne, Brisbane and across Australia. Our range of Microsoft Dynamics 365 services include CRM strategy, CRM scoping, Dynamics 365 implementation, technical support and Dynamics 365 training.