It's become almost fashionable to talk about the high failure rate of CRM projects. For instance, an often-cited Gartner study from late 2001 claims that over half of CRM projects fail to deliver on expected savings and business advantages. Is CRM the kiss of death? I think not. If we look behind the numbers we find much more encouraging facts.

First, many projects that are classified as failures, including in the famous Gartner study, are not failures at all in the normal sense of the word. They simply "failed" to set objective, quantifiable objectives from the start and therefore cannot claim to have achieved any specific objectives. It's certainly sloppy to start projects without defined goals, but I will let others who have never sinned throw that first stone!

Second, even projects that fail to reach their stated objectives may not be complete failures. Let's say that an SFA implementation project targeted a 10% decrease in sales costs, but finds that the decrease is only 8%. Is that a failure? Yes, in the sense that it did not achieve the goal, but the organization did save money, and a sizable amount of money at that. Considering the level of guessing, padding, and maneuvering that takes place during goal-setting sessions, especially for long-term projects, I would be tempted to consider such a project a success.

So it's not true that most CRM projects fail. But some do fail, and I've certainly seen my share of failures. Some projects don't make it to completion and are halted before deployment because of technical or other issues. Some projects are deployed but cancelled shortly afterwards because of grave shortcomings. Yet other projects are deployed and stay deployed but fail to serve their users, whether employees or customers, and are usually widely reviled as such. All those are failures in the real sense of the word. You will notice that I don't include projects that simply cost too much, and that is because I have yet to find a system that is embraced by its user community but is unaffordable. In other words, expensive failures tend to be all-around failures. Real failures are obvious.

Why do CRM projects fail? In my experience, failures occur because of the three P's: people, process, and politics, either as a single factor or, frequently, combined for a more lethal effect.

Politics

Politics can be a great hazard for CRM implementations. Simply put, there needs to be a clear political will to make a CRM project a success. This means that there should be a so-called executive sponsor, someone with the appropriate organizational and political clout to make the project happen. Ideally, this person should also be the business owner for the function(s) covered by the implementation. Right here, we can see that for a cross-functional implementation this is going to be difficult! Since companies tend to be organized by functions, a cross-functional implementation will require that a general manager be the business sponsor, and these people are often busy with other things.

Even if an appropriate executive sponsor can be found, some stability is required, as CRM projects tend to be long. There will be obstacles along the way, which will create wonderful opportunities for opponents to reopen the discussion of whether proper choices have been made. Will the executive sponsor have the tenacity and the patience to push the project through to the end? Will the executive sponsor still be around by the time the project is done? Will the executive sponsor refrain from delegating the project down so low in the hierarchy that it may lose its momentum?

People

People, even when not involved in political ploys, can easily derail CRM projects. First, there's the great fear of change. CRM implementations always require some amount of change, sometimes a lot if process changes are extensive. Some employees will resent that. Then, there is the Big Brother effect: employees can get nervous when asked to document their actions and they are not above boycotting the new system, often citing irreconcilable difficulties with the user interface. And finally there is the problem of mastery: there is almost always a dip in productivity as the new system is implemented since the users have to get used to the new system. That creates a vulnerable time when even supporters can go through a period of doubt.

In addition, CRM projects often involve a whole team of outside contributors to help select (sometimes) and implement (almost always) the system. There can be people failures with them too, although I prefer to treat them as process failures.

Process

Process failures are another source of CRM project failures. Even with good executive sponsorship and an enthusiastic team, projects may fail because they are not properly driven.

The most important process failure is failure to designate an appropriate project owner. Not the executive sponsor we discussed above, the project owner is hands-on, creates the plan, assembles the team, manages the work, and reports progress and exceptions to the executive sponsor. Put an unskilled project manager in that role and you've pretty much guaranteed failure for the entire project.

Process failure can also stem from a bungled approach to the task, for instance believing that the choice of the tool is everything and neglecting the implementation, or failing to involve both the technical team and the users from the start. Leaving out IT may result in a perfectly tailored interface on top of a hopelessly underpowered server and network infrastructure. And leaving out the users may get you a well-tuned system, but with so few actual users it would be hard to tell whether it would actually work well in high-load conditions. Both approaches are a big waste of time and money.

Most CRM projects succeed despite the obstacles. What makes the difference for successful projects? They have an executive sponsor who passionately believes that it needs to be done and it can be done. There is a strong and well-communicated business need behind which employees can rally. And there is a cohesive and effective project team, including a strong project manager, to shepherd the project through successful implementation.