Why CRM projects fail, and how to tell whether yours should continue

Ask why CRM projects fail and you get a percentage. The figure lands somewhere between half and three quarters. It arrives without a date, and it never says what was counted.

A rollout is the period between the decision to buy and the day the system becomes load-bearing for your business. That is the period this failure order applies to.

What the number actually asked#

The CRM failure statistic everyone quotes measured expectation shortfall, not failure. Ed Thompson of Gartner, interviewed by Bob Thompson for CustomerThink (opens in new tab) and published on 6 December 2004, described the study behind it. That study ran at the back end of 2001 across the US and Europe, covering about 500-plus organisations. In his words: "I think the figure we originally quoted was 55 percent failed to meet expectations."

⤢Full size

The chain from the 2001 question, through the answer, to the truncation the press published×

Then came the truncation. Thompson is direct about it. He says that "people took our statement: 'failed to meet expectations,' and they chopped the 'meet expectations' off it and just said, 'failure.'"

Those are not the same claim. A project that lands late, or delivers four of six features, has failed to meet expectations. Yet it may still be running your sales team today. That difference is the whole claim, and it does not survive the truncation.

The other half of the same source#

The same interview carries a second Gartner finding, from a different study on a different population. Gartner ran a reference-check study scored on a five-box scale, from absolute success down to absolute failure. Whereas the 2001 survey found 55 percent failing to meet expectations across about 500-plus organisations, this separate reference-check study put the bottom box lower. In Thompson's words: "The bottom category was absolute failure, and that was only something like 5 percent."

⤢Full size

Two Gartner studies with no arithmetic between them×

Hold those two apart. Although they come from one firm, they are not one picture. In particular, the 5 percent is not a slice of the 55 percent. Different study, different instrument, different population. The source does not state how many organisations answered the reference check. Because of that, no arithmetic connects them.

What survives is this. One number measures shortfall against expectation. Another measures outright collapse. Neither grades your programme.

The round 70 percent is not a CRM statistic#

The round 70 percent is not about CRM at all. It belongs to organisational change management, and its evidence base has been examined. Mark Hughes, writing in the Journal of Change Management (opens in new tab), volume 11 issue 4, 2011, pages 451 to 464, reviewed the five most prominent published instances of the claim. He looked at Hammer and Champy, Beer and Nohria, Bain, McKinsey and Kotter.

⤢Full size

Five prominent publications, and the study that is not underneath any of them×

His conclusion was that "there is no valid and reliable empirical evidence to support such a narrative."

Read that precisely. Hughes did not find that change usually succeeds. Instead he found that a number everyone repeats has never been evidenced by the people repeating it. Each instance either asserted the figure or pointed at another source that asserted it.

The test any figure has to pass#

Here is the test, and it takes two questions. First, what population was counted? Second, does the verb describe what was counted?

Apply it to the three figures.

One further caution. An aggregate rate cannot diagnose a specific programme, whatever its provenance. Reading a system that is already live is a different job, and it is covered in CRM best practices for a system that is already live.

Why CRM projects fail in a sequence, not a list#

The causes are easy to list. Bad data. Weak sponsorship. Poor adoption. Too much customisation. Each item is true, and the list still does not help. A cause that arrives without its earliest symptom cannot be matched to where your project stands today.

Failure modes arrive in an order.

The useful question is not what causes failure. Instead, it is what you would see this week if a particular failure had already started.

Four artefacts to ask your own team for#

A data migration is a discrete piece of software engineering, and it produces artefacts. Ask for these four. The answers tell you whether your migration exists as work or only as an intention.

1. First, the field map.

   Ask what happens to a record when a field is mapped to the wrong place, because the answer is rarely a visible error. In practice it is usually a silently wrong value that somebody acts on much later.

2. Second, the dedupe rule, plus the named person who adjudicates a collision the rule cannot settle.

   Since a rule needs an adjudicator, one without a name stalls at the first ambiguous pair.

3. Third, a dry run against a copy of the real data.

   Ask what it is meant to surface, not whether it passed.

4. Finally, a written decision about which history carries across and which does not, subject to whatever retention duties your own records are under.

   Because nobody wants to make that call, it gets deferred until the weekend it cannot be.

The one sourced number about CRM data, and its limits#

There is one recent figure here worth carrying, and it needs its caveats in the same breath.

Integrations are a liability that accrues#

Every connection your rollout creates is a standing maintenance obligation. Check whether your own quote prices keeping these connections in agreement, or only building them.

A connector is an agreement between two schemas that change independently. For example, your CRM ships an update while your finance system changes a field. Since the agreement between them does not renegotiate itself, somebody has to. The number of pairs that must be kept in agreement grows faster than the number of systems you connect. As a result, each new connection adds more agreements to maintain than the last one did.

The rollout is where you decide how much reconciliation work your business performs every year afterwards. Yet that decision is usually made by default, inside a scoping conversation about the build.

The symptom that says the debt has started#

Here is the observable one. When two systems disagree about the same customer, and somebody reconciles them by hand every week, your integration debt has already shipped.

Watch for three signs. First, duplicate records surviving a dedupe that was supposed to catch them. Second, two systems of record giving different answers about one account. Third, a recurring manual reconciliation that nobody scheduled and nobody owns.

That weekly fix is not a staffing gap. It is an unfinished connection, and it compounds while everyone treats it as temporary. While the work to close it sits outside your team, our API integrations service is the route for that specific problem.

What the sponsorship evidence does and does not establish#

Sponsorship is the contributor Prosci's own studies report most consistently. Still, the evidence for it is weaker than the advice implies. Prosci (opens in new tab), in "Top Contributors to Success" from its Best Practices in Change Management study, 2016 edition, reports that "with extremely effective sponsorship, projects were almost 3.5 times more likely to meet or exceed project objectives than projects with very ineffective sponsorship." The same document states that sponsorship "has been identified as the greatest top contributor to change management success in every Prosci study since 1998."

Now the limits. First, the extract does not state how many participants answered. Second, sponsorship effectiveness and project outcome were rated by the same respondent, so this is self-reported correlation rather than a controlled result. Third, Prosci sells change-management training, which is a fact about the source rather than an accusation about the finding.

Take sponsorship seriously. Still, do not treat the ratio as proof.

The operating model is decided during the rollout, or not at all#

The operating model is the set of rules about how your business actually works inside the system. Who owns a lead before it is qualified. What a closed-won record has to contain. Which team's definition of an account wins.

Because those decisions bind everything else, they have to be made while the system is still being built. After go-live, nobody has the standing to change them. Since changing them means telling people already using the tool that they were doing it wrong, the window quietly closes.

Meanwhile, Prosci's same 2016 document reports that 65 percent of participants, and the extract again does not state how many, said their organisations did not adequately prepare managers to lead change, again self-reported. That pattern is consistent with what stalls rollouts. Where the product genuinely cannot encode how your team sells, and further configuration has stopped helping, building the CRM around the process is the alternative worth weighing against continuing.

Writing the stopping condition before you need it#

A kill-or-continue test is honest only when it is written while nobody is defensive. Written mid-crisis, it becomes an argument about blame. Whereas written early, it is just a checklist.

It also has to be falsifiable by an observation rather than by an opinion. For instance, "the team seems demoralised" is not a condition. In contrast, "no field map exists after six weeks" is.

We would be paid to continue this work, so here is the condition under which we would tell you to stop. Our standing position is this. We come back with a scope, or we tell you that a product on the market already fits and you buy that instead.

When this is the wrong project#

What stopping actually costs, and what survives it#

Stopping does not write off everything the rollout produced. That belief is why the decision never gets taken.

Four things outlive the tool they were built for.

Those four carry forward. The licence commitment and the configuration work do not, and separating the two piles is what turns an emotional argument into a decision somebody can sign.

Three positions, three doors#

You may not have chosen a product yet. You may be mid-configuration. Or the system may already be live and not delivering. Each of those has a different next step.

⤢Full size

Three positions you might be standing in, and the one page that serves each×

First, before the decision, with no product selected yet. Then the question is which system to buy and on what test, which is the ground covered in how to choose a CRM using your own last five deals, including the case for not buying one yet.

Second, inside the rollout, with the system being configured and not yet load-bearing. The failure order set out earlier is the part that applies.

Finally, past go-live, with a system that is live and not delivering. Since the diagnosis is different there, the repair order for a CRM that is already running is where that work starts.

The one thing to check this week#

Make one observation this week, before the next configuration decision lands. Ask a person outside the project team to name who owns the operating model.

Not the project manager. Not the vendor. The person who decides what a qualified lead is and what a closed record must contain. If three people give you three names, or one person gives you none, you have found the earliest symptom, and you have found it while it is still cheap to fix.

That single answer tells you more about your rollout than any published failure rate ever will. Knowing why CRM projects fail in general cannot tell you that. Knowing who owns yours can.