4. Right-Sizing Change Management in S/4HANA — Why Timing Matters More Than Headcount

Introduction

In many programmes, the focus quickly turns to how many people are needed, what training is required, and when communications should begin.

But in practice, the success of change management is rarely determined by headcount.

It is determined by timing.

And getting that timing wrong is one of the fastest ways to slow down a programme.

Change management is widely recognised as critical to the success of S/4HANA transformations. One of the most common mistakes is not whether to invest in change — but when and how to scale it.

In many programmes, organisations mobilise large change teams too early, expecting detailed impact assessments before the design has been stabilised. The result? Slower progress, frustrated delivery teams, and change outputs based on assumptions rather than reality.

Aligned to SAP Activate, effective change management should be progressive — not front-loaded.

The Early Phase Trap: Too Much, Too Soon — and Too Detailed

In the early stages of a programme (Discover and Explore), design is still evolving:

• Processes are being challenged through fit-to-standard

• Requirements are not fully understood

• Decisions are iterative and subject to change

Introducing a large change team at this point often leads to:

• Requests for detailed impact assessments before processes are defined

• Excessive stakeholder mapping based on incomplete information

• Pressure on design teams to provide certainty that doesn’t yet exist

• Administrative overhead that slows down workshops and decision-making

In short, change activity becomes prematurely detailed and operationally heavy.

What Good Looks Like Early On

This doesn’t mean ignoring change management — far from it.

The early phase requires a small, focused change capability that:

• Identifies potential change hotspots (high-impact areas)

• Surfaces early risks and resistance points

• Ensures the programme understands where significant business disruption may occur

• Begins shaping the change narrative at a high level

At this stage, the goal is not precision — it is awareness, foresight, and direction.

Scaling at the Right Time: The Realise Phase

The point at which change management becomes truly critical is during the Realise phase.

By this stage:

• Processes are defined and largely stable

• System behaviours are visible through demonstrations

• Cross-functional impacts are clearer

• The scale of change can be properly assessed

This is when organisations should mobilise a larger, fully structured change team.

Because this is the point where change becomes real to the business — not theoretical.

Their focus shifts to execution:

• Detailed change impact assessments based on actual designs

• Stakeholder engagement and alignment across functions

• Communication planning and delivery

• Training needs analysis and rollout

• Tracking and closing change actions

Importantly, this is also when cross-functional impacts become real — and need active coordination.

The Risk of Getting the Timing Wrong

If change teams are scaled too early:

• Design slows down due to excessive information requests

• Impact assessments are repeatedly redone as designs evolve

• Programme teams become frustrated with perceived bureaucracy

• Change outputs lose credibility because they are based on shifting assumptions

If change is introduced too late:

• Users are unprepared for new processes

• Resistance increases

• Adoption suffers

• Benefits are delayed or lost

The balance is critical.

In both cases, the outcome is the same — reduced confidence in the programme.

Change is Not Static — It Evolves With the Programme

Effective change management mirrors the maturity of the programme:

Early Phase (Discover / Explore)

• Small team

• High-level impact identification

• Focus on risks and hotspots

Mid to Late Phase (Realise)

• Expanded team

• Detailed impact assessments

• Active stakeholder engagement and communication

Final Phase (Deploy and Beyond)

• Reinforcement and adoption tracking

• Issue resolution and continuous improvement

• Embedding new ways of working

This phased approach ensures that change activity is relevant, timely, and actionable.

Supporting Design — Not Slowing It Down

At its best, change management enables delivery.

At its worst, it becomes a constraint.

The difference is rarely intent — it is how and when it is applied.

The difference lies in how it interacts with design teams:

• Good change teams adapt to uncertainty and evolve with the design

• Overloaded early teams demand certainty too soon and create friction

Change should support design by:

• Highlighting risks early

• Preparing the organisation progressively

• Stepping in with detail when it adds value

Not by trying to lock down impacts before they are fully understood.

Final Thought

S/4HANA transformations are not just system implementations — they are business transformations.

Change management is essential — but more people does not always mean better outcomes.

The key is timing.

Start small. Stay focused. Scale when the design is ready — not before it.

Based on what I’ve seen across multiple S/4HANA programmes — getting the timing right is often the difference between adoption and resistance.

S/4HANA Transformation Series

1. When “Agile” S/4HANA Programmes Quietly Revert to Waterfall — and Why It Matters

   
   

2. Fit-to-Standard — But Which Standard Are You Actually Choosing?

   
   

3. Why Data Will Make or Break Your S/4HANA Programme — Long Before Go-Live

   
   

4. Right-Sizing Change Management in S/4HANA — Why Timing Matters More Than Headcount

   
   

5. Rationalising External Systems in S/4HANA — Why Integration Simplicity is a Strategic Advantage

   
   

6. Documentation from Day One — Why Documentation from Day One Matters

#SAP #S4HANA #ChangeManagement #Transformation #SAPActivate #OrganisationalChange #ERP #LondonSAP