Salesforce change management: why rollouts fail

Salesforce rollouts rarely fail because of the technology. They fail when sales, service and field service keep working the way they did before go-live, with Excel, email and their own lists next to the new system. Salesforce change management is the work that prevents this: introducing new processes, standards and releases so that people use them. I follow Prosci and the ADKAR model, because it shows where an adoption is stuck. Another training session only helps when knowledge is missing, not when nobody understands what the whole thing is for.

Why does Salesforce not take hold in daily work?

A release is rolled out technically in minutes. What happens afterwards decides whether anyone works differently. In Salesforce programmes the reasons why they do not are almost always the same:

• The people affected hear about it too late. Whoever first sees a change in production looks for a way around it.
• Nobody explains why. A sales team maintains opportunities because it has to and does not know that demand planning depends on them.
• Management backing is missing. Without decisions from the top, new rules stay a recommendation.
• There is no way back. Problems from daily work end up in emails, not in the backlog.

This does not only apply to business users. When a programme introduces new standards for development and release, development teams and implementation partners are just as affected. They know the rules but interpret them differently as long as nobody anchors them.

What does the ADKAR model show?

Prosci has surveyed projects about their experience with change since 1998. In the 12th edition of its study Best Practices in Change Management1 with 2,668 participants, projects with excellent change management met their objectives in 88 percent of cases, projects with poor change management in 13 percent. Participants named active and visible sponsorship by management as the most important success factor.

The ADKAR model2 describes five stages every person goes through in a change. For a Salesforce programme I translate them like this:

Stage	Question	Typical sign it is missing	Who helps
Awareness	Why is something changing?	“The old system worked fine.”	the group’s manager
Desire	Do I want to take part?	required fields filled with dots	sponsor, direct manager
Knowledge	Do I know how it works?	questions about how to find a feature	training, key users
Ability	Can I do it in daily work?	works in training, not in the customer meeting	key users on site, practice
Reinforcement	Do I stick with it?	back to Excel after three months	reports, checks, recognition

The value lies in the diagnosis. Instead of scheduling the next training when usage is low, we ask for each affected group at which stage it is stuck. If sales does not know what maintained opportunities are needed for, awareness is missing, and the head of sales has to explain that, not the trainer.

The sponsor deserves a sentence of its own, because it is the role most often missing in Salesforce programmes. It means a person from management who visibly backs the change: they explain in the sales meeting why forecasts will come from Salesforce from now on, decide when two departments cannot agree, and ask about usage in the monthly report. That is why I write a sponsor plan that defines what management does visibly and when. Without it, “management supports this” becomes a line on the first slide.

Prosci and ADKAR are registered trademarks of Prosci, Inc. I adapted the approach to Salesforce programmes together with Juliane Winterscheid, my cooperation partner for change management.

These topics belong to change management in Salesforce programmes

Change management is not a single work step. The same topics come up again and again in Salesforce programmes at manufacturers. Each one has its own article:

1. Building up key users: who answers the first questions in the business and how much time that takes.
2. Change management in a global rollout: what each country needs when a global template is rolled out.
3. Technician adoption of the Field Service app: why field service accepts the app or works around it.
4. Communicating releases to the business: how business users learn before a release what changes.
5. Reinforcement: making standards stick with partners: how new development rules stay part of the partners’ daily work.
6. Measuring adoption after go-live: which numbers show whether a process has landed.
7. Adoption in sales: why sales works around Salesforce and what helps.
8. Training plan: how to plan training by role, on real cases and through key users.
9. Hypercare after go-live: who is on hand in the first weeks and when it ends.
10. Change management process in the project: which change work belongs in which project phase, from planning to operations.

The general tools behind this are explained by Juliane Winterscheid in her own articles on the basics: the stakeholder analysis with a template, the communication plan and the change curve.

Change management runs in three phases alongside delivery

Prosci structures the work at the level of the organisation in three phases, the Prosci 3-Phase Process3. In a Salesforce programme they run alongside the release plan:

1. 01

   Prepare approach

   before the first release · client with sponsor

   Define how success is measured, which groups are affected, what changes for each and who in management carries the change.

2. 02

   Manage change

   with every release · client, key users

   One plan per group along the ADKAR stages, linked to the release plan. Measure usage and adjust where it is stuck.

3. 03

   Sustain outcomes

   after go-live · internal owners

   Check for gaps, anchor new rules in pipeline, reports and Center of Excellence calls, hand over responsibility.

Timing is what matters. Change management that starts two weeks before go-live can only inform. The question of which groups are affected and what changes for them belongs in planning, before anything is built. With a global template it is even part of the architecture, because every deviation per country is also a question of habit.

Write down groups, changes and sponsor of your next release

For your next release, answer three questions in writing: which groups are affected? What changes for each in their daily work? Who in management visibly backs it? If the third answer is missing, that is the first step. Then decide how you measure success, for example by usage numbers in Salesforce instead of the number of training sessions.

If you want to go through the five stages in order, the change management masterclass has a chapter per stage with the matching articles. How Juliane Winterscheid and I support this in programmes is described under Salesforce change management consulting.

Sources3

1. 1Best Practices in Change Management (opens in a new tab)prosci.com
2. 2ADKAR model (opens in a new tab)prosci.com
3. 3Prosci 3-Phase Process (opens in a new tab)prosci.com