Why CRM projects fail, and some remedies.
Our sages ( Google ) tell us that between 50 and 70% of CRM projects fail. The question begs, why is this?
The following is a list based on some of my experiences over the years. Each reason for failure is surmountable and the upsides of success are surely worth it! But, the process requires long-term diligence and an all-hands-on-deck approach.
Reason 1. Change is hard.
By its nature, taking on a CRM project means taking on vast operational change. It means being able to be more effective and efficient, but with change, always comes challenge.
Remedy: Get the whole team on board. Make sure you have leadership buy-in, and ideally one leader or executive responsible for driving the project. practice patience!
Reason 2. CRM is not today's highest priority.
Usually, a CRM project is a medium- or long-term strategic move. It's less urgent than today's hot priorities or problems, and oftentimes gets pushed to the back burner.
Remedy: Schedule a regular weekly time for reviewing progress with key stakeholders. Stay on top of vendors and their timelines, and importantly, expect to have those involved with the CRM project occupied for a period of time.
Reason 3. The groundwork is a slog
Requirements gathering, vendor selection, partner selection and the much unloved data preparation. Each of these sub tasks is a big process unto itself. Oftentimes, it can take months before a business begins to reap the first rewards of a CRM project.
Remedy: There's little remedy for this one. Data preparation especially is one aspect that many clients fail with. Just remember, it's much faster to clean data in Excel than it is once the data is inside a CRM. Oftentimes, it's now or never.
Reason 4. The goal posts keep on shifting
In planning, the goal posts and needs of departments change. Priorities become muddled, and the project tries to say "Yes" to every requirement and every idea.
Remedy: I don't like the idea of having departments sign off on their requirements as to some extent, it's good to keep things fluid. BUT, what's most important from the outset is getting the foundations right, getting clean data, and getting the most vital cogs working. Bite off the project in chunks, taking on the whole hog from the outset isn't something I recommend. Go slow-ish.
Reason 5. The cloud dream
We blindly chase the cloud dream - that every system talks to every other system in a seamless and effortless flow of business data and exchanges. It's not really that simple. The marketing of the ease of integration between cloud platforms is a few steps ahead of the reality, and chasing the dream can lead to a tangled and complicated web.
Remedy: Yes, ideally everything is in the cloud and everything is perfect. But, sometimes there are trade-offs to be made between efficiency, effort and complexity. Some integrations may not be worth the effort or level of complication, and other features may just be over the top... for now. It's important to have a trusted technical person in your team who can help you weigh up technical considerations against business outcomes.
Reason 6. The failure of implementation partners
I've seen it a lot. Implementation partners making big promises and falling short, trying to move too quickly through important process details, or not setting clear expectations with clients about the amount of internal resource the project is really going to require.
Remedy: This is challenging. I have a few suggestions. Depending on your size, if you can afford to have a trusted insider who can provide some oversight over vendor work and advice, this is helpful. When signing off on vendor documents (requirements sheets, conditions, process outlines) go through them with a fine comb as these will be the documents that the group refers back to if things don't work. If you don't really understand the documents, get some advice. Also, where relevant, have the vendors explains your needs back to you - not by copying and pasting your text - but in their own words.
Reason 7. The wrong foundation
The first few architectural decisions relating to data structure are some of the most important of the whole process. A working system, doesn't necessarily mean a well built and scalable system.
Remedy: This happens a lot, especially on platforms like Salesforce! Before you get underway with your implementing your CRM on Salesforce or Zoho, I'd suggest to add one layer to your review process - an architectural review ensuring that the foundational data design intentions are going to meet you medium- or long-term integration dreams.
Reason 8. Leadership farm the project out and move on
CRM is a business wide effort. Leadership need to inform the strategy, and take a leading role throughout the process. It can't just be left to an IT team, or left to a third party - to some extent, everyone needs at least a little buy-in.
Remedy: Unforunately no easy fix for this one. If Leadership don't have their focus on the project, it will fail.
Reason 8. System adoption
Leadership are often the most guilty of this one. Following launch, in the all important first few weeks, is the new platform being used? Are staff following guidelines? Is data being entered correctly?
Remedy: This is all dependant on the size of your implementation. It can be easier to manage if you are a small office - you're all in it together. If you have teams in different areas or locations, there needs to be a top-down training and review approach. I also recommend that the CRM implementation partner, or an insider spends some time in the first weeks monitoring data entry and system usage. You can usually tell pretty quickly if the platform is being used correctly or not.
Reason 9. Review, review, review.
A new CRM is not a static set and forget project. CRMs shape and shift over time as businesses change and new ideas come to fruition.
*Remedy: Following launch, a schedule of project review needs to be undertaken for at minimum 6 months. Has what was envisioned been implemented? Are the analytics come to fruition? What's working, what's not working?
Reason 10. Realistic resourcing
CRM needs ongoing administration, maintenance, oversight and strategy. This all has to be planned in budgeting.
Remedy: Again, this will depend on the size of your implementation, your budget, and how you are approaching the whole project. In general, I suggest to expect that the CRM will take up technical time following research. If you have vendors, then keep them involved for a period of time following the project. If you have an internal IT department, they will surely play a very leading role in the platform moving forward.