Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

What to do when your CRM project fails

David Taber | Oct. 9, 2013
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.

With all this information, you may determine that, in an objective sense, the project wasn't really a failure. It very well may have achieved the goals that were realistic given the time, attention and budget available. In the eternal wisdom of George Carlin, "Some people say that the glass is half-empty, others say that it's half-full ... Me, I think the glass is too big."

Sure, users may not be happy. In most projects, though, that's because they expected more to be achieved before they started using the system. In other words, it's not that the project delivered a broken system. The project delivered only fragments of a system that's not easy or friendly enough.

Assessing Why Your CRM Project Blew Up
A classic reaction to this situation is blaming the project team, getting a new project manager, changing consultants and holding a crash "get well" program. At the extreme, the new system gets thrown out altogether.

Although such a reaction is emotionally and politically satisfying, it's typically costly, as all changes incur friction and learning-curve effects. Worse still, the get-well program usually heads straight down the road of the mythical man-month.

Let's see if we can do better by asking a series of tough questions:

  • Was the original project conception viable?
  • Is the organization ready for big advancements in automation, sophistication and management?
  • Were users on board with the changes required in discipline and process? Did they want to keep things ad-hoc?<
  • Did management invent a micro-managing monstrosity?
  • Are the IT systems and data sources with which the CRM system must integrate of sufficient flexibility and data quality to support the use cases?
  • Was the budget in line with functional expectations?
  • Are there still unstated requirements?
  • Did anyone do a bottom-up cost estimate of what it would really take to complete all the requirements? (My recent favorite situation: A 68-page spec for the behavior of a single CRM field, with no budgetary estimate by any of the three vendors involved with implementing it.)
  • Was there a "fixed price or die" attitude held by the project management or executive sponsors?
  • Were stakeholders able to dedicate enough time to the project?
  • Were key stakeholders unable to commit the time to make project decisions smoothly?
  • Were there big gaps in the schedule during which nothing moved?
  • Was there real trust between the users and the project team?
  • Did either side suspect the other?
  • Were honest questions sometimes interpreted as challenges or even threats?
  • Did anyone throw a temper tantrum?
  • Were some people simply unable to work together effectively?

If you get enough "Yes" answers to those 18 tough questions, the get-well project is already sick. It may make sense to call in a management consultant or organizational development specialist before kicking the new project into full gear.


Previous Page  1  2 

Sign up for CIO Asia eNewsletters.