What to Do When Your CRM Project Fails
Many articles written for today's CIOs discuss how to avoid project failures. According to most industry analysts, at least one-third of CRM projects fall short. Let's explore what you should try to avoid and how to conduct a post-mortem analysis should your project fail.
Tue, October 08, 2013
CIO — There are at least a dozen oft-quoted industry analyst reports that estimate the failure rate of CRM projects. The analysts' methodologies and standards vary, so the resulting failure numbers are all over the place — between 18 percent and 69 percent.
Most of the numbers seem to center around the question, "Did the project meet expectations?" This is a profoundly fuzzy standard — and, in fact, it can be a self-fulfilling prophecy. Children don't want to eat their spinach, so it tastes bad, no matter how much they may enjoy it later in life.
Taking an average of those analyst reports, about one-third of you have a failure on their hands. Whether you were part of it, or whether the project was handed to you after the fact, the real issue is, simply, "What now?"
8 Signs Your CRM Project May Be Failing
If people think is your CRM project is a failure, do a little forensic work.
- From a purely project management perspective, did the project come within 10 percent of its original schedule and budget? Was the schedule practically guaranteed to fail? Was the budget realistic, or was it a product of magical thinking?
- Look at data quality. It's a major contributor to user dissatisfaction, after all. Were any of the following problems made worse during the project?
• Duplicate records
• Mis-owned or improperly assigned records
• Record completeness coherence
• Field accuracy, particularly addresses and product numbers
- Evaluate functionality.
• For items that were "missing," or not seriously attempted, had users clearly stated the goals early enough in the project to get them done?
• For the items that were attempted but didn't make the grade, what's the key root cause: Lack of understanding, inability to execute or quality/ease of use issues?
• For items that were generally satisfactory but have reliability or consistency problems, is the real issue poor design, architecture and conception, or is it weak implementation, development and deployment skills?
- During the project, were users deeply, continuously involvement? This is a key factor to successful agile project management. Were those who are now complaining the loudest engaged in any significant way throughout the project?
- Did the people setting the expectations about what the CRM project would accomplish actually know what they were talking about?
• Happy ears is a deadly phenomenon when it occurs inside a user organization. Anything that's conceivably possible in a system becomes "the standard we expect."
• CRM product salespeople often set expectations that can only be achieved with tons of customization work, then set expectations about how cheap it will be to get consultants to do it.
- Was this project managed by the user organization? If so, was it the group's first big project? Was there meaningful participation by and cooperation from the IT department?
- Was the root cause of significant failures outside of the CRM system — for example, in other applications, in infrastructure or in external databases or data feeds?
- Did significant internal forces try to block the success of the project? CRM implementation is always political, and there are always users who don't want a project to succeed.