Insights / Project risk

Why CRM projects fail, and why small projects usually don't

How often do CRM projects miss?

Estimates vary with how failure is measured. Research roundups put the share of CRM projects that miss their planned objectives at roughly 30 percent, and more than half when you count benefits that were never fully realized. The same roundups attribute over 60 percent of failures to people-related causes, and only 6 to 10 percent to the platform itself.^[1]

The most-cited causes are poor user adoption, bad data and insufficient training.^[1] None of those is solved by picking a different vendor.

Size is the strongest predictor

The Standish Group has tracked software project outcomes for decades. Its 2015 report broke results down by project size, and the pattern is stark: 61 percent of small projects succeeded, against 6 percent of the largest.^[2] Its earlier analysis found that a large project is roughly ten times more likely to fail outright than a small one.^[3]

A CRM for a 100-person company isn't a small project if it's delivered all at once. It becomes one when it's split into phases that each go live on their own.

Patterns I see in rescue projects

After many rescues, the same patterns come up again and again.

The design was decided by people who wouldn't build it

Architecture agreed in the sales cycle, then handed to a different team. The builders inherit decisions they don't understand and can't change.

Everything went live at once

Sales, service, marketing and three integrations on one date. When something breaks, everything looks broken, and trust goes with it.

Data migration was left to the last month

Nobody looked closely at the old data until it had to move. Duplicates and missing fields then shaped the go-live, not the design.

Integrations were assumed to be simple

“It has an API” turns out to mean an export file once a day. That finding should come in week three, not week twenty.

Nobody owned it on the client side

Without a person who cares about the outcome and can make decisions, the project drifts toward whatever is easiest to build.

What to do instead

• Split the work into phases that each deliver something people use.
• Build the riskiest part first, usually an integration or the data migration, while the budget is still small.
• Name one owner on your side with authority to decide.
• Measure adoption weekly after go-live, not just whether the system is up.

This is why Meghoo works in fixed steps: a free first pass, a short fixed-price discovery with a demo, then a six-week proof of concept capped at 10 percent of the project, before anyone commits to the full budget.