← All services

NoteI developed this approach together with Juliane Winterscheid, my cooperation partner for change management. Juliane is Prosci certified. LinkedIn profile (opens in a new tab)

02 · Change management

Change management when hardly anyone uses Salesforce

A new Salesforce release is rolled out quickly. Whether business teams, developers and partners work differently afterwards is another question. Together with Juliane Winterscheid I plan the introduction of new processes and standards following Prosci and ADKAR, so they reach daily work and stay there.

Book a call (opens Microsoft Bookings in a new tab)
Fabian Kramer explains a workflow to two colleagues at a monitor.

Change management in a Salesforce programme means introducing new processes, standards and releases so that the people who work with them actually use them. That applies to the business teams who do their daily work in Salesforce as much as to the developer teams and implementation partners who are meant to build by common rules. Juliane Winterscheid and I take on this work on the client side: Juliane guides the people through the change, I make sure architecture, partner governance and releases fit with it. Wherever this page says “we”, it means the two of us. Our approach follows Prosci, and further down you can read why.

Typical situation

  • Salesforce is live, but parts of the business still work with Excel, email and their own lists.
  • Training has taken place, yet usage stays low, and nobody can say exactly where it gets stuck.
  • New standards for development and release have been agreed, but every partner and team reads them differently.
  • Releases become smaller and more frequent, and business teams learn about changes only once they are in production.
  • Management expects results from the programme but is rarely there when decisions about the rollout are due.

What we do

  • For each affected group we use the ADKAR model to assess at which of the five stages the rollout is stuck.
  • We introduce new standards in stages and start with the most common cases.
  • We set up a fixed format in which business teams, developers and partners see upcoming changes early and can have a say.
  • We measure usage in Salesforce and adjust where it gets stuck.

What you get

  • Agreed success measures from Salesforce reports, for example on records created and maintained
  • A rollout plan per release that shows which groups are affected, what changes for them and when they hear about it
  • A sponsor plan that sets out what management does visibly and when, so that new rules become binding
  • A fixed route by which feedback from daily work reaches the backlog
  • Internal owners who carry the rollout on after the handover

Why do new processes not reach daily work?

A release is technically rolled out in minutes. What happens next decides whether anyone works differently. The reasons it does not happen are usually the same, and each one has an answer:

What we do about it

  • A rollout plan per release sets who hears about it and when.
  • The first version covers the most common cases, edge cases come later.
  • New rules come from management, not only from the project team.
  • The old way is closed as soon as the new one works.

Where it fails

  • The people affected hear about it too late and look for a way around it.
  • Everything is meant to be settled at once, so the first version arrives late and is rarely read.
  • Backing from management is missing, so new rules stay a recommendation.
  • The old way stays open, Excel lists and emails keep working.

What does ADKAR look like in a Salesforce programme?

The ADKAR model (opens in a new tab) by Prosci describes five stages each person goes through in a change. When a rollout stalls, one of them is usually missing. We often see the following: the training has taken place, yet usage stays low. Instead of scheduling another session, we ask per affected group at which stage it is stuck:

  1. AAwarenessWhy it changesWhy is something changing?
  2. DDesireTaking partDo I want to take part?
  3. KKnowledgeKnow-howHow does it work?
  4. AAbilityDoing itCan I do it in daily work?
  5. RReinforcementMaking it stickDoes it last, or do I slip back?

Awareness is missing

A sales team does not know what the maintained opportunities are needed for.

The head of sales has to explain that, not the trainer.

Reinforcement is missing

A partner's developers know the naming conventions, but nobody checks them in the pipeline.

Then an automatic check belongs in the release process.

Salesforce helps with measuring. Whether a new process is used shows more reliably in reports on created and maintained records than in a survey. We define these figures in the first phase and look at them regularly in the second. I describe the individual topics, from key users to measuring adoption, in Salesforce change management: why rollouts fail. The change management masterclass goes through the five stages chapter by chapter.

Common standards for five partners in three months

30+

developers in eight streams

5

implementation partners

3

months until people lived by the standards

80 %

of cases covered by the first version

Source: my largest programme as architect on the client side

At the start of this programme, the technical approaches of the teams had drifted far apart. So we introduced common standards for naming conventions, one automation per object, test coverage and an object ownership matrix in stages.

The first version covered around 80 percent of the cases. The edge cases were added step by step as they came up in the project. Later we raised new topics in the programme with lead time in regular Center of Excellence calls, before they turned into problems. At some point hardly any new edge cases came up. I describe the rules for several partners under partner governance.

Smaller releases need a fixed route into the business

With a clean release process, releases become smaller and more frequent. For business teams this means small changes more often instead of one large package per quarter. For that to work, they need a fixed route on which they learn in advance what changes, and a route back on which they report what does not fit their daily work. Before each release I clarify with the owners in the business which teams are affected, what changes in their processes and who informs them. That goes into the release plan before development is finished. After the release I check whether the new processes are used and bring feedback from daily work into the backlog.

Prosci is built on research since 1998

To me, Prosci is the gold standard in change management. The reason is the research behind it: Prosci has surveyed projects about their experience with change since 1998.

88 %

of projects with excellent change management met their objectives

13 %

with poor change management

7×

as often successful

Source: Prosci, Best Practices in Change Management, 12th edition, 2,668 participants

In the 12th edition of its study Best Practices in Change Management (opens in a new tab), with 2,668 participants, projects with excellent change management met their objectives seven times as often as projects with poor change management, 88 against 13 percent. Participants name active and visible sponsorship by management as the biggest contributor to success. That matches what I see in Salesforce programmes.

Together with Juliane Winterscheid, who is Prosci certified, I have applied two building blocks from Prosci to Salesforce programmes: the ADKAR model described above and the Prosci 3-Phase Process (opens in a new tab). The 3-Phase Process gives the rollout a frame at the level of the organisation: Prepare Approach, Manage Change and Sustain Outcomes. The steps under “How we work together” follow these phases.

Prosci and ADKAR are registered trademarks of Prosci, Inc. The Prosci certification is held by Juliane Winterscheid, not by FK Solution Design, and FK Solution Design is not a Prosci partner. This page describes how we apply elements of the approach in Salesforce programmes.

How we work together

  1. 01

    Prepare the approach

    We define how success is measured, which groups are affected and what changes for each of them in daily work. That includes the risks and who in management sponsors the rollout.

  2. 02

    Manage the change

    Each group gets a plan along the ADKAR stages, tied to the release plan. The most common cases come first. We measure usage in Salesforce and adjust where it gets stuck.

  3. 03

    Sustain the outcomes

    We check where gaps remain, anchor new rules in the pipeline, reports and Center of Excellence calls, and hand ownership over to internal owners.

Frequently asked questions

Why do you follow Prosci?

Because to me Prosci is the gold standard in change management. The approach rests on surveys since 1998 with more than 10,000 participants and is widely used in the industry. It gives structure to the part of a Salesforce programme that is often left to chance: whether people actually work differently.

What is the ADKAR model?

ADKAR is a Prosci model with five stages each person goes through in a change: Awareness, Desire, Knowledge, Ability and Reinforcement. When a rollout stalls, one of these stages is usually missing. The model shows which one.

How long does it take to introduce new standards in a large programme?

In my largest programme, with more than 30 developers and five implementation partners, it took about three months. The first version covered around 80 percent of the cases, and the edge cases were added over time.

Who has to take part in change management?

Everyone the change affects or who carries it: business teams, developer teams, partners and management. Without backing from management, decisions and attention are missing, and new rules become a recommendation that not everyone follows.

What changes with smaller, more frequent releases?

Business teams get small changes more often instead of rare large packages. That lowers the risk of each release but needs a fixed route on which the people affected learn in advance what is coming.

Contact

The release is live, but daily work has not changed?

In 30 minutes we clarify where new processes and standards get stuck and what the rollout needs.

What to bring

  • What the release or standard is supposed to change, and for whom
  • How you notice it is not landing, for example usage, questions or workarounds
  • Who is responsible for the rollout today

What we clarify

  • Whether the cause is the solution itself or the way it was introduced
  • Which groups you need to win over first
  • Whether Juliane Winterscheid should join for change management from the start
Book a call (opens Microsoft Bookings in a new tab)

Pick a slot in my calendar via Microsoft Bookings. Prefer to write? Use the form and I’ll get back to you.

Rather talk right away? +49 221 98656758

Send a message

Your details are only used to answer your request. More in the privacy policy.