Why Salesforce Projects Fail: The "Seven Deadly Sins"

After two decades in the weeds of APAC's biggest Salesforce transformations, I can usually tell you how a programme will end by the second meeting. The signals are consistent. Here are the "Seven Deadly Sins" (aka mistakes) I keep seeing, and the research that says they're costing something north of two trillion dollars a year, globally.

I got the call on a Tuesday night. Sydney was doing its neon thing outside my apartment window and I'd just come back from dinner when my phone lit up. A Program Director I'd worked with two companies ago. She didn't say hello.

"Robin, we're way over budget. The Board is meeting on Monday. Our partner told us everything was fine three weeks ago. I need your advice."

I've been on about a hundred of these calls now. Different country, different company, different industry. Same conversation. A CIO or a Program Director calls, there's a long pause, and then the real question lands. "How bad is it really?"

My honest answer, nine times out of ten, is worse than you think. And the reason is almost never the technology.

I've led, advised on, or been called in to resuscitate countless Salesforce programmes across Australia, New Zealand, and the broader Asia Pacific. Every organisation is its own special snowflake. The failure patterns, depressingly, are not. They're the same seven mistakes on rotation, and the research backs it up.

What's at Stake?

First let's talk about the numbers, because the industry loves to dress this up.

Gartner puts the CRM failure rate at roughly 50%. Forrester has it at 47%. A 2025 survey of operators across regions landed on 55% of deployments failing to hit their stated objectives (Johnny Grow). The Standish Group's most recent data has only 31% of IT projects classified as fully successful. Fifty percent are "challenged" and 19% outright fail (CHAOS). Projects over $10 million are more than ten times more likely to be cancelled than projects under $1 million. Gartner has estimated the global cost of failed projects at roughly $2.3 trillion a year (Gartner research).

Source: Johnny Grow Research

"If a major airline crashed 50% of the time, we'd ground the fleet."

Salesforce itself now runs about 90% of the Fortune 500. This platform isn't the new thing anymore, it's the plumbing. And yet a majority of the programmes attempting to install that plumbing are leaking. Loudly.

Every one of the seven reasons below I've watched happen in the last three years. These are not theoretical.

Sin #1: No Executive Sponsor

This is the one that kills the most implementations, so I'm leading with it. It's not an IT project. It never was.

A telco put a full program team on the ground for fifteen months. The CIO was great. The Program Director was a machine. The engineering crew shipped on time. At the twelve-month budget review, a new CFO walked in, saw a line item that had nothing to do with the current earnings call, and quietly reassigned half the budget to something with a shorter payback window. There was no executive champion above the CIO willing to fight for it. The program wasn't cancelled. It was slow-starved. By month eighteen the team had been reassigned and the system was running at about 30% of what it was meant to do. The investment was still on the balance sheet. The value was not.

Prosci's longitudinal research on change programmes is unambiguous on this point: initiatives with excellent change management and visible executive sponsorship are six to seven times more likely to meet their objectives than those without it (Prosci research). Not twice as likely. Six times. McKinsey goes further. In their work on digital transformations, organisations that treat culture and leadership as a first-class investment see a 5.3x higher success rate than those that focus primarily on the tech (McKinsey digital transformation research).

The fix isn't a steering committee. It's a named, accountable C-level champion whose incentives are explicitly tied to the business outcome.

"If your Salesforce programme can't name its exec sponsor, you don't have an exec sponsor."

Sin #2: Skipping Discovery

A large NDIS provider I spoke to spent six months telling their board they were "de-risking" their Salesforce project by going straight to build. Agile, they said. Ship fast, they said. Four months in they discovered their clients lived in seven disconnected platforms, none of which spoke to each other, and the master data nobody had audited was about 40% duplicated. Their timeline doubled and the budget ballooned, while the executives had to explain it to the Board.

I'm yet to meet a CFO who likes hearing that discovery should cost 20–30% of a programme budget. I'm also yet to meet a CFO who enjoys a 60% cost overrun.

The specific failure mode is brutal. According to research on scope creep and budget blowouts, projects that skimp on discovery see scope creep add an average of 30% to cost, while poor data preparation extends timelines by an average of 25% (Pletra). A shop that starts at $250k and skips discovery regularly ends up somewhere near $500k. The number nobody publishes in the case study.

Discovery isn't a phase, and it is biased and shortened if done during pre-sales. If done correctly, it's the insurance policy for every other phase. Map current state processes. Audit data quality and readiness. Identify every integration point. Document real user pain, not assumed user pain. Then and only then do you start building.

Sin #3: Trying To Rebuild Your Old CRM Inside Salesforce

Three years ago I walked into a financial services firm in Auckland and asked them why their case object had 312 custom fields. The business analyst shrugged. "That's what we had in the old system." They'd spent eight months rebuilding, field for field, workflow for workflow, a 2008-era on-prem system inside a modern cloud platform.

The result was exactly what you'd expect. A slower, uglier version of the thing they already had, with few of the platform's native capabilities activated.

"They'd paid for a Ferrari and were driving it like a Corolla."

This mistake has a specific tell. Every time anyone says "but that's how we've always done it," a small kitten dies. Challenge every single legacy requirement. The default position should be to stick to native Salesforce only. You only customise when you can articulate the business value in a sentence a Board member would understand.

The 80/20 rule saves more programmes than any methodology ever invented. Configure for 80% of use cases out of the box. Handle the remaining 20% through training, policy changes, or a conscious decision to simply stop doing the thing.

Sin #4: Data Migration As An Afterthought

Oh, data migration. The discipline that enterprise sponsors treat as "just a technical task" and that routinely eats more budget than the rest of the programme combined.

An organisation in Melbourne decided to migrate fifteen years of customer data without cleaning it first. "We'll clean it in flight," the PMO said. What actually happened: duplicate accounts three or four deep, contacts missing required fields, entire cohorts of customers who'd had their addresses typed differently by seventeen different call centre operators over the years. The sales team stopped trusting the system within a month. It took eighteen months of dedicated data work to get the system to the state the business thought it was in at go-live.

Gartner's research on AI initiatives notes that 85% of AI projects fail due to poor data quality or lack of relevant data (Informatica summary of Gartner). Agentforce is built directly on top of your Salesforce data model. Which means if your CRM data is rubbish, your agent will be a very confident liar. I cannot emphasise this enough. Fix the plumbing before you turn on the taps.

ANZ Bank completed its national Agentforce rollout earlier this year, the first bank in APAC to deploy agentic AI at scale. The secret to that deployment wasn't the agents. It was the two-year "simplicity agenda" that consolidated data from twenty separate platforms into a single unified dashboard before anyone went near an AI feature (iTnews). CBA is grinding through a similar consolidation of nineteen Salesforce instances into a central governance structure (iTnews). Boring work. Essential work. Precisely the work most programmes refuse to fund.

Plan data migration from day one. Budget for cleansing. Build governance rules. Test migration three times before go-live, minimum, on production-sized data. And if your partner tells you "we'll figure out the ETL during UAT," show them the door politely and call someone else (me!).

Sin #5: Death By Configuration

I once audited a Salesforce org in Sydney that had 847 custom fields across 23 custom objects, 156 workflow rules, and page load times of forty-five seconds. I am not making up a single digit of that. The business had 400 users. One admin had been promoted to Solution Architect with no formal handover. The other had left to go travelling. Nobody could explain what half the automations did. Nobody wanted to turn anything off in case something broke.

The system wasn't supporting the business. The business was supporting the system.

This happens because the first instinct of a good Salesforce admin is to say yes. "Can we add a field for that?" Yes. "Can we automate that approval?" Yes. "Can we customise the layout for that team?" Yes, yes, and yes. Two years later you have a platform held together with duct tape.

Simple scales. Complicated does not. If you're consistently customising more than 20% of a cloud, you have probably picked the wrong platform, or you have a business analysis problem dressed up as a technology problem. And every custom object you add today is an inheritance tax on future enhancements, releases, and new capabilities you might want to switch on later.

One pattern that saves clients real money: a standing "configuration council" that meets fortnightly and has the authority to say no. Every significant customisation needs a business case. Every automation needs a named owner. Every custom field has a sunset review. It's not glamorous. It works.

Sin #6: The Wrong Partner, For The Wrong Reasons

Right. I'm going to speak plainly here because it's my industry and nobody else will.

A recent client I spoke to chose the lowest bidder for a major implementation. The partner had never worked in that industry. Inside six months the project had missed three critical requirements, the delivered system had an ACMA liability, and the client was paying a second partner to rectify the first one's work. Total cost ended up at about 2.3x the winning bid. The "cheap" option was the most expensive money they spent that year.

Procurement teams love a low price because it's easiest to get approved. The problem is the rectification costs never show up on the same line item.

Here's the bit nobody likes talking about. I wrote a piece on LinkedIn a while back asking whether Salesforce has an issue with bad consultancy and the response surprised me. Hundreds of engagements. Partners, clients, Salesforce employees, ex-employees. The pattern was depressingly consistent.

"Salesforce AEs are rewarded on licence sales, not on outcomes."

The path of least resistance is usually a Salesforce Partner with a quickstart package.

Tailored delivery looks expensive in the model and lengthens the sales cycle. Quickstarts look cheap and close fast. The AE wins, the partner wins, the licences are booked, and twelve months later the CIO is on a call to someone like me asking how bad it really is.

Pick your partner like you're picking a doctor. Industry expertise. Team stability. Methodology. References you can actually ring. A named delivery lead you will have a coffee with before you sign. If the pitch is dominated by the salesperson and you meet the delivery team the day after contract signature, that's a red flag the size of Uluru.

If your Salesforce AE is nudging you towards a particular partner with indecent enthusiasm, ask why. The answer might be fine. It might not. Either way, it's your job to know.

Sin #7: Ignoring The Human Change

The final sin is the one that haunts me most, because it's so preventable and we keep making it.

A professional services firm in Auckland built a beautiful Salesforce implementation. Clean architecture. Sensible customisation. Fast. Proper integrations. And then they allocated two hours of training per user and sent a launch email. Six months in, user adoption was sitting at 23%. The system had become a very expensive reporting tool. The partners were still using their spreadsheets. The CEO was livid.

Projects with change management are six times more likely to meet their objectives and five times more likely to stay on schedule. Harvard Business Review has reported 60–70% of digital transformation initiatives fail specifically because of poor change management (Vantage Point). The technology is almost never what breaks. The people are.

The budget split that actually works looks roughly like this. 30 to 40% on build. 20 to 30% on data. 25 to 40% on change, training, and adoption. The number that's wrong almost everywhere I go is that last one. Change is treated as a training plan, an email from the CEO. It needs to be a sustained, funded programme that runs for at least six months past go-live. Super users. Role-specific enablement. Office hours. Somebody the frontline team can actually ring at 10am on a Tuesday when something breaks.

The other consideration with change and Salesforce is that a good Salesforce programme will have regular releases, every month. So a change programme needs to be always on and running in parallel.

"If you are not changing Salesforce regularly, you're not doing Salesforce correctly."

The Eighth Sin: Post Go-Live

I promised seven, I know. But this one's been biting more often lately and it belongs in the conversation.

Nobody plans for life after go-live. Salesforce projects are often funded like events, not capabilities. You light the candles, you cut the cake, the consulting partner goes home, and then a year later the business is complaining that "Salesforce is slow" because nobody is running the platform as a product. Release management has no owner. Feedback loops don't exist. The CoE that was promised in the slide deck never got resourced. The backlog becomes a graveyard.

Benioff himself, to his credit, acknowledged this openly at Dreamforce last year. His line was that customers needed help "bridging the gap between AI innovation and AI adoption". Translation: the tech is ready, most of the organisations trying to use it aren't.

The fix is an operating model for after the launch. A Centre of Excellence with real funding. A product owner accountable for platform outcomes. A release cadence that clients can rely on. And a genuine feedback loop from frontline users back into the backlog. It's the cheapest, most under-invested bit of the entire lifecycle.

The Common Pattern

Here's the thing. Every one of these sins is a symptom of the same root cause: treating Salesforce as a thing to be installed rather than your next super employee. Install once and walk away is how you end up in a wrestling match with 847 custom fields. Train Salesforce to automate human labour, and you've got a platform that gets more valuable every quarter.

Winning organisations share three traits:

The enterprises I've watched lose typically reversed all three. They started with ambition, ignored the data, and treated people as an afterthought. And then they called me, a year too late.

What To Do About It NOW

If you're reading this because you've got a Salesforce project in-flight, or one on the runway, here are the questions I'd want answered honestly:

• Can you name your exec sponsor?


• What percent of your programme budget is allocated to data and change?


• How many custom fields, objects, and automations have been added in the last six months, and who has authority to say no?


• When was your last honest partner review?


• What does the operating model look like the week after go-live?

The Bottom Line

There is no shortage of smart people, project methodologies, or good intentions in this industry. What there's a shortage of is the honest conversation at the beginning of the investment about what's actually going to kill it. Most of the failures I get called in to fix were entirely preventable.

You've got three choices: A. Learn from other people's expensive mistakes; B. Pay to learn from your own mistakes; or C. hire someone who's already paid for that education.

I know which one I'd pick. I also know which one most organisations still pick by default. It's not the first one.

I'll meet you in the comments — or book a 30-minute consultation if you'd rather have the conversation off the record.

---

Robin Leonard is Partner at Xenai Digital, specialising in enterprise Salesforce and agentic AI transformations across APAC. He helps organisations deliver implementations that actually land, without the six-figure surprises. Connect on LinkedIn or read more at robinleonard.co.