Why Salesforce Implementations Fail: The Change Management Diagnosis

The Diagnosis Nobody Wants to Make

When a Salesforce implementation fails, the post-mortem usually blames the technology. The system was too complex. The customisations were poorly designed. The integration with the legacy ERP never worked properly. The vendor over-promised. These are convenient diagnoses because they point outward — at the platform, at the partner, at the scope. They rarely point at the room where the post-mortem is being held.

The honest version of that post-mortem is almost always a change management failure. Not in the generic, consultant-speak sense of "change management wasn't done well." In the specific, traceable sense that the programme ran into a set of entirely predictable problems — stakeholder misalignment, scope that nobody controlled, users who never intended to adopt the system, data that everyone knew was broken — and those problems were visible weeks or months before they became crises. They just weren't named.

This tutorial names them. Not as a retrospective exercise, but as a diagnostic framework you can apply at the start of a programme, at the midpoint, and at any moment when your instinct is telling you something is wrong but you can't quite articulate what.

I've run or overseen enough Salesforce implementations to have seen every failure mode described in this tutorial play out in real programmes, sometimes multiple times in the same programme. The pattern recognition is not theoretical. The warning signs I'll describe appear, reliably, in weeks two through eight of a programme. If you know what to look for, you have time to act. If you don't, you'll be writing a post-mortem about the technology.

The Six Root Causes of Salesforce Implementation Failure

Before working through each cause in depth, it's useful to see the full set together. Six patterns account for the overwhelming majority of Salesforce programme failures. They rarely appear in isolation — programmes typically fail for two or three of these reasons simultaneously, which is part of why the failure feels sudden even when the trajectory was visible.

1. Stakeholder Misalignment: Different Definitions of Done

The business sponsor believes the programme is delivering a tool that will transform how the sales team works. The IT lead believes it's delivering a configured instance of Salesforce Sales Cloud. The operations director believes it's delivering an integration with the ERP. The Salesforce partner believes it's delivering the requirements documented in the statement of work. None of them are wrong — they simply have never been in the same room long enough to discover they're describing different programmes.

Warning signs in weeks 2–8: Status meetings where different attendees describe the programme's objectives in incompatible ways. A requirements document that has been reviewed and signed off by IT but never presented to the business sponsor. Scope decisions being made at the working level without visibility to programme governance. Steering committee meetings where the agenda is all RAG status and no decisions.

2. Scope Creep Enabled by Lack of Change Control

Salesforce's customisation model makes it easy to add things. A new field here, a new workflow there, a report that one regional VP needs for their monthly review. Each addition is small. None of them individually feels like a scope change. Collectively, they represent months of additional build, testing, and training — none of which appears in the project plan, the budget, or the go-live criteria.

Warning signs in weeks 2–8: User story counts that grow between sprint planning sessions without a corresponding change request. Build velocity that slows without an obvious cause. A product backlog that is being refined upward, not downward, as the programme progresses. Developers answering requirement questions directly from business stakeholders, bypassing the business analyst.

3. User Adoption Failure: The System Goes Live, Nobody Uses It

This is the failure mode that most often gets attributed to the technology. "The system is too complicated." "It doesn't work the way we work." "We preferred the old system." What's actually happening is that the programme was designed to deliver a configured system, and adoption was treated as a training event rather than a programme workstream. The users weren't involved in design. Their feedback wasn't incorporated. Their workflows weren't mapped. On go-live day, they were handed login credentials and a training manual.

Warning signs in weeks 2–8: User representatives absent from design workshops. Process maps built by business analysts without validation from the people who do the work. A training plan that's a single line in the project plan rather than a named workstream with a named owner. Super-user selection left to "after the build is done."

4. Data Quality Denial: Known Problems Deferred to Post-Go-Live

Almost every organisation moving to Salesforce knows their data has problems. Duplicate accounts. Contacts with no email addresses. Opportunities with no close dates. Accounts associated with territories that no longer exist. The data quality assessment, when it happens at all, produces a report that everyone reads and nobody acts on — because remediating data quality is unglamorous work that doesn't appear in a product roadmap, and because the business owners who need to clean the data don't have capacity allocated to do it.

Warning signs in weeks 2–8: A data migration plan that includes the phrase "data quality remediation to be completed by business in parallel." Data quality metrics not included in the go/no-go criteria. Migration scripts written against source data that hasn't been profiled. A data owner identified on the RACI who hasn't been in a migration meeting.

5. Executive Sponsorship in Name Only

Every Salesforce programme has an executive sponsor. They are named on the project charter, they appear in the kickoff slide deck, and they attend the monthly steering committee. They do not make decisions. Requests for direction go unanswered for weeks. Escalations are deferred to the next steering committee. When a critical design decision requires a call between two business directors who disagree, the sponsor is unavailable. The programme manager learns to work around the sponsor, which means the programme has no executive authority and every hard decision gets deferred or compromised.

Warning signs in weeks 2–8: Steering committee meetings that end without decisions recorded. Escalations that cycle back to the programme level without resolution. A sponsor who asks for "a summary deck" rather than engaging with the detail. A pattern of "let's take that offline" that never results in an offline conversation.

6. Requirements Captured but Not Validated Against Actual Usage

The discovery workshops run. Requirements are documented. The business analyst produces a requirements specification that accurately reflects what stakeholders said in workshops. None of the stakeholders in those workshops actually do the work being described — they manage the people who do. The people who do the work are never consulted. At UAT, for the first time, actual end users open the system and discover that it doesn't reflect how the work actually happens. The gap between the documented requirements and the actual requirements is six months of build.

Warning signs in weeks 2–8: Workshop attendees who are all management-level. User stories that don't have an identifiable user behind them. Acceptance criteria written by the business analyst rather than validated with the user. No process observation or shadowing in the discovery phase.

Stakeholder Alignment: What It Actually Requires

Stakeholder alignment is one of the most over-used phrases in project management and one of the least well-executed activities in practice. Being aligned doesn't mean everyone has been invited to a meeting. It means everyone who has decision-making authority over the programme outcome has a shared understanding of what the programme is trying to achieve, and a shared model of how decisions will be made when the programme encounters problems — which it will.

Decision Rights: The Single Most Important Thing to Establish in Week One

The most valuable thing you can do in the first week of a Salesforce programme is not write a project plan. It's answer this question clearly: who has the authority to make which decisions, and what happens when those people disagree?

This means mapping decision rights explicitly. Not a generic RACI matrix with "A" columns filled in by job title. A specific document that answers: who decides when a requirement is out of scope? Who decides when a design trade-off is made between user experience and delivery timeline? Who decides whether the programme goes live if data quality is below threshold? Who decides if the budget needs to increase?

The reason this is the most important thing to establish in week one is that you have the most leverage before the programme is under pressure. Once a programme is in flight, any discussion of decision rights becomes political — it reads as either a power grab or a defensive manoeuvre. In week one, it reads as good governance.

The RACI Matrix That Nobody Follows vs the One That Works

Every programme has a RACI. Most of them are produced by the programme manager, reviewed briefly, and never consulted again. The RACI that actually gets used is different in two ways.

First, it's built with the stakeholders, not for them. The programme manager facilitates a conversation where the stakeholders themselves agree on accountability. When the VP of Sales agrees in a room with the CIO that she is accountable for business requirements sign-off, she is more likely to honour that accountability than if she received an email with a RACI attached.

Second, it's specific about the consequences of the "A." Accountable doesn't mean "receives a copy." It means: if this deliverable is late or wrong, this person's name is on it. That specificity is uncomfortable to introduce, which is exactly why it's valuable. Resistance to it in week one is a signal worth paying attention to.

Champions and Blockers: How to Identify and Manage Both

Every Salesforce programme has people who will actively make it succeed and people who will quietly ensure it doesn't. Identifying both early is one of the most important pieces of intelligence a delivery leader can develop.

Champions are not just enthusiastic stakeholders. A champion is someone with credibility among their peers who is willing to be publicly associated with the programme's success. Their value is not in attending steering committees — it's in the informal influence they carry in corridors and team meetings. A sales director who tells her team that the new system is going to be good for them is worth more than any training communication you can send.

Blockers operate differently. They rarely oppose the programme openly. They miss meetings. They send deputies who can't make decisions. They raise process concerns in escalation meetings that, coincidentally, require months of investigation. They are frequently senior people who feel threatened by the change the programme represents — not because they're obstructionist by nature, but because nobody has spent any time understanding what they're worried about. The most effective intervention for a blocker is a direct conversation with them, alone, in which you ask what success looks like for them. The answer is usually more specific and more addressable than you expect.

Board-Level vs Operational Sponsorship: You Need Both

A common mistake is to conflate the executive sponsor with the person who can resolve operational blockers. The board-level sponsor provides air cover — they signal to the organisation that this programme matters and that non-cooperation has consequences. But they cannot resolve a dispute between the head of sales operations and the head of IT about data ownership. That requires an operational sponsor who is close enough to the detail to make informed calls, and senior enough to make them stick.

On a programme of any significant scale, you need two named sponsors: one at the executive level who will intervene when politics threaten the programme, and one at the operational level who attends the programme weekly and can make design decisions. If you have only one, you have a gap — and that gap will be where your hardest decisions disappear.

The Mid-Programme Stakeholder Map Refresh

Stakeholder maps are produced at the start of a programme and then filed. In a twelve-month programme, the organisation changes. People leave. Reporting lines shift. A new CRO arrives who has strong views about CRM. Ignoring these changes means the programme's political map is months out of date at the moment when stakeholder management matters most — the final stretch before go-live.

A mid-programme stakeholder map refresh — typically at the three-to-six month mark — should be a standard delivery practice. It takes half a day. It asks who has changed in the stakeholder landscape, what the new entrants' positions are, and whether any of the original alignment assumptions need to be revisited. The fact that most programmes don't do this is a symptom of treating stakeholder management as a planning activity rather than an ongoing delivery activity.

User Adoption: The Problem That Starts Before Go-Live

User adoption failure is the failure mode that most reliably gets reattributed to technology problems after the fact. "The system is clunky." "The interface doesn't make sense for our business." "It takes too many clicks to do what we need." These observations may be accurate. They are not the root cause. The root cause is that user adoption was not designed into the programme from the beginning.

Why Training Is Not the Same as Adoption

Training is the transfer of procedural knowledge: how to create a record, how to run a report, how to advance an opportunity stage. Adoption is the sustained change in how people do their work. These require different interventions and different timelines.

Training can be delivered in a week before go-live. Adoption takes months and requires that users have a reason to change their behaviour — not just the capability to use the new system. That reason is almost never "because we have a new system." It is usually one of: the new system makes my specific job demonstrably easier, my manager is using the new system and expects me to as well, or the old way of doing things is no longer available.

Programmes that treat training as the adoption strategy are doing one of these three things: delivering capability without motivation, without reinforcement, or without removing the old option. All three produce the same result: people are trained, go-live happens, usage figures are low at 90 days, and the post-mortem attributes it to the technology.

The Adoption Metrics That Matter vs the Ones That Get Reported

The adoption metric most commonly reported is login rate: what percentage of licensed users logged in this week. This metric is nearly useless. A user who logs in to check their email notifications and then continues managing their pipeline in a spreadsheet is counted as an active user.

The adoption metrics that actually tell you whether the system is being used for its intended purpose are process completion rates: what percentage of opportunities were advanced through the defined stages in the system (versus being updated in bulk at end of month)? What percentage of customer contacts created in the last 30 days have a complete data record? What percentage of cases were resolved within the system workflow versus resolved by email with a retrospective update?

These metrics require that you define your intended usage patterns before go-live, instrument the system to measure them, and have someone whose job it is to review them weekly in the 90 days post-go-live. On most programmes, none of these three preconditions exist.

Super-Users: Selection, Role, and Numbers

The super-user model is well-established in enterprise software deployments. It works when it's done properly and fails visibly when it isn't.

Super-users work when: they are selected by the users they will support (or at minimum with their input), not assigned by management; they are given meaningful system access that lets them answer questions without escalating to IT; they have protected time allocated to the super-user role and are not expected to maintain full productivity in their day job simultaneously; and they are connected to each other and to the programme team so that common questions get consistent answers.

Super-users fail when they are the most IT-literate people in the team rather than the most respected. Technical aptitude is less important than peer credibility. The super-user who their colleagues trust to give them a straight answer about whether the new system is actually better is worth far more than the one who knows how to configure dashboards.

On headcount: a ratio of one super-user per fifteen to twenty users is the minimum for a successful deployment. Programmes that try to run one super-user per fifty users typically find that the super-user is overwhelmed, questions go unanswered, and adoption plateaus at whatever level it reaches in the first two weeks — which is always lower than target.

Change Network Design: Adoption Is a Peer Influence Problem

People change their behaviour because of peer influence far more than because of management directives or training. The change network — the group of people who will carry the adoption message through the organisation — is therefore the most important adoption infrastructure a programme can build. It is also the one most commonly omitted from programme plans.

A change network is distinct from the super-user network. Super-users provide technical support. Change network members provide social proof: they are the people whose visible adoption of the new system signals to their peers that the change is real and positive. They do not need to be enthusiasts. They need to be respected, and they need to be willing to use the system visibly and speak honestly about it.

The 90-Day Post-Go-Live Adoption Plan

Go-live is not the end of the adoption challenge. For most programmes it is the beginning of the hardest phase. Users are encountering the system under real work conditions for the first time. The gap between the designed experience and the actual experience becomes visible. Early adopters are managing their own confusion while also fielding questions from their colleagues.

A 90-day post-go-live adoption plan should include: weekly adoption metric reviews with named owners, a feedback mechanism that captures user experience issues quickly enough to be acted on, a sprint cadence for fixing high-impact usability issues identified post-go-live, and a named accountability for adoption outcomes in month three. That last point is the most commonly absent: every programme has a named owner for go-live, but very few have a named owner for the adoption outcome.

Requirements: The Gap Between Captured and Correct

Requirements failure is the most technically complex of the six root causes, because it happens through a series of individually reasonable decisions that collectively produce a system that doesn't reflect what the business actually needs. Nobody in the process is trying to document the wrong thing. The failure is structural.

The Discovery Workshop That Produces 400 Sticky Notes and No Decisions

The discovery workshop is the most common first act of a Salesforce implementation. A room full of stakeholders. Sticky notes on whiteboards. A business analyst facilitating. At the end of the day, the business analyst has a photograph of the whiteboard and a commitment to document the outputs. Three weeks later, a requirements specification appears that faithfully records everything that was said — and makes none of the trade-offs implicit in those conversations explicit.

The sticky-note workshop produces inputs. Requirements are outputs. The gap between them is the set of decisions that need to be made about priority, scope, and design. Those decisions cannot be made by the business analyst alone. They require the stakeholders who will be accountable for the outcomes. A discovery process that does not end with a set of prioritised, scoped, decision-quality requirements — not a list, a set of decisions — has not produced requirements. It has produced a problem backlog.

How Requirements Get Corrupted Through the Project Lifecycle

Requirements that start as business intent go through several translations before they become built functionality. The business stakeholder describes a need. The business analyst captures a requirement. The architect designs a solution. The developer implements a component. The tester writes a test case. At each translation, information is lost, assumptions are introduced, and the original intent drifts further from what gets built.

This is not a Salesforce-specific problem. It is fundamental to software development, which is why practices like continuous stakeholder involvement, short feedback loops, and working software as the measure of progress exist. On Salesforce programmes that run large-scale discovery phases followed by multi-month build phases, the translation chain is at its longest. By the time the business sees the system at UAT, the requirement has been through six people. The original intent is sometimes unrecognisable.

The "That's Not What I Meant" Conversation at UAT

Every delivery leader who has run a Salesforce programme has had this conversation. The stakeholder opens the system at UAT, looks at a screen, and says: "that's not what I meant." What they mean is: the system does what I said, but it doesn't do what I needed.

The diagnosis for this conversation is almost always the same: the requirement was written without acceptance criteria, or the acceptance criteria were written by someone other than the person who will be doing the accepting. A requirement without acceptance criteria is not a requirement. It is a description of intent. Whether the implementation satisfies that intent is a judgement call — and judgement calls made by developers or business analysts in the absence of the business stakeholder produce the "that's not what I meant" response at UAT.

Acceptance Criteria: Written Before Build, Not During UAT

Acceptance criteria must be written before the build begins, by or with the business stakeholder who will sign off the functionality, and in terms that can be tested against a working system. "The system should be easy to use" is not an acceptance criterion. "A sales representative should be able to create an opportunity from a lead record in fewer than three clicks" is an acceptance criterion.

The value of pre-build acceptance criteria is not just technical — it's political. When a stakeholder has written or co-written the criteria against which their own sign-off will be assessed, the "that's not what I meant" conversation changes character. The question is no longer whether the system meets their expectations; it is whether the system meets the criteria they agreed to. That is a fundamentally different conversation, and a much more productive one.

The Sign-Off Process That Actually Holds Up

Sign-off processes fail when they are treated as administrative events rather than governance events. A stakeholder who receives a PDF requirements document and returns a signed email has not actually reviewed the requirements. They have acknowledged receipt. The sign-off that holds up under challenge has three properties: the stakeholder has reviewed the requirements against a working prototype or wireframe (not a text document), the sign-off is explicit about what is being confirmed (scope, not quality), and the consequences of the sign-off are clear (changes after this point go through change control).

Data Quality: The Deferred Crisis

Data quality is the issue that every experienced delivery leader knows about, half of them raise, and almost none of them successfully resolve. The pattern is consistent enough to be predictable: a data quality assessment is commissioned, it finds problems, the findings are presented to the business, the business acknowledges the problems and commits to remediation, and three months later the problems are still there because nobody with the authority to act has prioritised the work.

Why Data Quality Issues Are Always Discovered at Migration, Never Before

This is not literally true, but it describes the experience of most programmes. Data quality assessments are commissioned early and find general categories of problems. What they don't find, because they don't look, are the specific records that will fail the migration scripts. Those records are discovered at migration — which is typically in the final two to three months of the programme, when there is no remaining contingency to fix them.

The reason assessments don't find specific records is that they're profiling exercises, not migration dry runs. A profile tells you that 23% of Account records have no associated address. A dry run tells you which 23% — and whether those accounts are the ones you were planning to migrate first, and whether the accounts with no address are the ones associated with your top 100 customers.

Running migration dry runs from month two of a programme rather than month eight is the single most effective data quality intervention a delivery leader can make. It converts a late crisis into an early problem — which is a fundamentally different thing to manage.

The Business Owner Who Owns Data but Hasn't Looked at It

Data has an owner on the RACI. That owner is typically a senior business stakeholder — VP of Sales Operations, Head of Customer Data, Chief Data Officer. Their accountability on the RACI is "Accountable for data quality." In practice, the last time they looked at the actual data was when the last CRM was implemented, which was six years ago.

The programme cannot remediate data that the business hasn't reviewed. And the business will not review data unless someone creates a specific forcing function: a named owner, a defined scope of review, a timeline with milestones, and a consequence for non-completion. "The business will clean up the data in parallel with the build" is not a data quality plan. It is a statement of optimism.

Data Quality Remediation Timelines: What "We'll Fix It in the Migration" Actually Means

When a business stakeholder says "we'll fix it in the migration," what they mean is: the programme team will write migration scripts that transform the data from its current state into an acceptable state. This is sometimes a legitimate plan — transformation rules can address formatting inconsistencies, normalise picklist values, apply default values for missing fields. What it cannot do is create data that doesn't exist, disambiguate genuinely ambiguous records, or make a business decision about which duplicate to keep.

The records that require human review — duplicates, records with conflicting information, records that are associated with the wrong account — cannot be fixed in migration scripts. They require a business person to look at each one and make a decision. If there are 50,000 such records and the remediation timeline is six weeks, the delivery leader needs to calculate whether the business has the capacity to review approximately 1,200 records per day for six weeks, or whether the go-live date needs to move.

The Go/No-Go Data Quality Threshold

Every programme needs a data quality threshold that is a genuine go/no-go gate, not a target. The threshold should be defined before migration testing begins, agreed with the executive sponsor and data owner, expressed in terms of specific measurable criteria (not "acceptable quality"), and accompanied by a clear statement of what happens if the threshold is not met on the planned go-live date.

The reason most programmes don't have this is that agreeing to a genuine go/no-go gate requires someone to be willing to say "we might delay the go-live for data quality reasons." That conversation is uncomfortable in week three of a programme. It is far more uncomfortable on the week before go-live. The discomfort is an argument for having it in week three, not an argument for deferring it.

The Delivery Leader's Change Management Toolkit

The preceding sections have described what goes wrong and why. This section is about what to do — specifically, the practical tools that let a delivery leader identify and address change management problems before they become programme-ending crises.

The Five Questions to Ask in Week One of Any Programme

These questions are not diagnostic in the sense of testing the organisation's health. They are diagnostic in the sense of making the health of the programme visible to the people who are accountable for it. Ask them directly, in separate conversations, and compare the answers.

1. "What does success look like for you personally when this programme is done?" — asks each stakeholder to articulate their personal definition of success, which will usually reveal whether the programme's stated objectives align with individual stakeholder motivations.
2. "Who has the authority to change the scope of this programme?" — tests decision rights. If different stakeholders give different answers, you have a governance gap.
3. "What does the data we're migrating look like today, and who last looked at it?" — surfaces data quality awareness and data ownership clarity simultaneously.
4. "How will we know in six months whether the users have actually adopted the new system?" — tests whether adoption has been designed in or left to chance.
5. "What would have to be true for this programme to fail?" — the most valuable question, because it asks stakeholders to name the risks they're aware of but haven't said out loud. The answers are almost always more specific and more concerning than anything on the risk register.

The Weekly Change Management Health Indicator

A weekly change management health check takes 20 minutes and answers six questions on a simple red/amber/green basis: Are decision rights being exercised as agreed? Is scope change going through change control? Is adoption design progressing against plan? Are data quality milestones being met? Is executive sponsorship active and visible? Are requirements being validated (not just documented)?

The value of this check is not the RAG status itself — it's the discipline of asking the questions weekly, which forces the programme team to look at change management as an ongoing delivery activity rather than an upfront planning exercise. A change management health check that goes amber on "adoption design" in week six is actionable. The same problem discovered in week twenty is a crisis.

How to Escalate a Change Management Problem Without Losing Credibility

Escalating a change management problem is politically complex. Saying "our stakeholder alignment is poor" reads as a criticism of the sponsor. Saying "user adoption is at risk" reads as predicting failure. The framing that works is decision-focused rather than problem-focused.

The escalation that lands is: "I need a decision from the steering committee on [specific issue] by [specific date] because [specific consequence]. Here are the three options and my recommendation." This framing treats the change management problem as a governance gap rather than a people problem, makes the ask concrete rather than atmospheric, and gives the sponsor something to do rather than something to be concerned about.

Delivery leaders who raise change management problems without a specific ask tend to get sympathy and no action. Delivery leaders who raise them with a specific decision request tend to get a decision — which may be "not our problem," but that at least moves the accountability somewhere.

The Retrospective Framework That Surfaces the Real Issues

Standard Agile retrospectives ask three questions: what went well, what didn't, what should we change. On Salesforce programmes with significant change management challenges, this format reliably produces surface-level observations ("the sprint planning sessions are too long") rather than structural ones ("the business stakeholders are not available to answer requirements questions in sprint, which is why the sprint planning sessions are too long").

A change management retrospective adds a fourth question to the standard set: "What problem did we not talk about this sprint?" This question is deliberately uncomfortable. It asks the team to name what they avoided naming — the stakeholder who isn't engaged, the data quality issue that nobody acted on, the scope that was added without challenge. The answer to this question, asked honestly, is usually more valuable than everything in the first three answers combined.

Conducting this retrospective with external facilitation — someone not from the programme team — dramatically increases the honesty of the answers. The programme team's social dynamics will suppress uncomfortable truths if the facilitator is the programme manager. An external facilitator creates the psychological safety to say what the team already knows but hasn't said.