What causes a CRM implementation to fail?

The main thing that causes this is a relationship breakdown. An organisation eventually gets fed up with a vendor saying “we didn’t understand you meant this, we thought you meant that”. The board loses confidence, and they say we need to put a stop to this project. Often there is then a fall out with the current vendor and they go off to market to look for a new one.

It’s important the organisation understands how they want their new system to work and for the implementation partner to clearly understand their needs.

The thing that causes many implementations to fail is a lack of change management.

It’s critical that everybody in the organisation knows why leadership has decided it’s time for something new. It’s deciding that the current software doesn’t have the capability to achieve their strategic goals in the future. The reason for the change needs to be reiterated to the team during the selection process and during key phases of the project.

Everyone in the organisation also needs to go into the project with a mindset that things will now be done differently to how they’ve been done in the past.

Absolutely. The big unknown is what is your data going to come out of your old system like?
That is the biggest risk area of budget blow out because it needs to be turned into a specific format to go into your new system. Once it’s in the specific format, it’s usually cheap and easy to upload.

But it’s getting data out of your old system or systems, merging it all together, making sure it’s clean, making decisions on that data, and then getting it into the format.

You want clean data in your new system. That means no duplicates and correct contact information, particularly addresses. Duplication is often the biggest problem when gathering data from multiple systems.

The greatest risk of building a bespoke system is not the tech – it’s that you can build what you want. There aren’t any guidelines or templates so staff can be tempted to implement what they are familiar with. It then just turns into replicating your old systems with new technology!

The consultant needs to remind the organisation of the project’s goals and demonstrate how a process will work in the new system. The goal is to get to live as close to out-of-the-box as possible because that will give you the long-term cost of ownership reduction.

If you think about simplifying as moving something that would have been custom and turning it into being able to be delivered by the product, that’s complexity simplification. But there will be some complexities that you can’t change, they’re critical for your organisation.

In that case, you make sure you build them with tools so that the system itself is upgradable. You don’t want to get locked into a particular vendor and you want to be able to upgrade your system without it breaking every time some new version of the software comes out.

In fact, a lot of organisations are changing software because they got stuck with a vendor who: did too much customisation, only they know how to fix the system and they’ve gone out of business, or they’ve not maintained the skills to manage the product.

That the system is working for a start! You want to get a new system up and running as soon as possible so you can start getting a return on your investment.

Then, as you learn more and more about the system, you can start making changes to your organisation. Doing iterative change is far better than doing a massive change in one go.