When “Agile” S/4HANA Programmes Quietly Revert to Waterfall — and Why It Matters
- David Murphy
- 1 day ago
- 4 min read
Most S/4HANA transformations today are positioned as Agile, business-led programmes aligned to SAP Activate. The language is familiar: iterative delivery, fit-to-standard, rapid validation, continuous user engagement.
But scratch beneath the surface of many programmes, and a different reality often emerges.
During the early design phases — particularly Explore — delivery quietly slips back into a waterfall model. Not by declaration, but by behaviour. It may look like you are going faster and making progress, but detailed decisions made too early can result in costly issues later in the program.
This is one of the most common and least challenged risks in S/4 transformations.
The Subtle Slide Back to Waterfall
It rarely happens overtly. Instead, it shows up in ways that feel reasonable at the time:
Detailed functional design documents produced before users see anything in the system
Workshops focused on capturing requirements rather than validating solutions
Pressure to formally “sign off” processes early
Limited or delayed system demonstrations
Progress measured by document completion rather than user validation
From a governance perspective, this can look like control and momentum.
In reality, it is often a reintroduction of waterfall thinking — front-loading decisions before the business has experienced how the system actually works.
Why System Integrators Drift This Way
This behaviour is not usually malicious — it is structural.
System Integrators are incentivised to reduce delivery risk, manage scope tightly, and create contractual clarity. Detailed documentation and early sign-offs help achieve all three.
It creates:
A fixed baseline
Clear traceability
Protection against change requests later
From the SI’s perspective, this is good delivery discipline.
From the organisation’s perspective, it can be a trap.
Because it shifts risk away from the SI and onto the business — locking in decisions based on assumptions rather than experience.
Where This Conflicts with SAP Activate
SAP Activate is not just a phased plan — it is a fundamentally different way of designing processes.
The Explore phase is intended to:
Challenge requirements through fit-to-standard workshops
Use live system demonstrations to anchor discussions
Encourage early iteration and feedback
Minimise custom design in favour of proven best practices
When programmes replace these behaviours with document-heavy design and early approvals, they are no longer aligned to SAP Activate — even if the terminology remains.
The result is often a “waterfall wrapped in Agile language.”
A Common Scenario (and Why It Fails)
Consider a typical E2E Supply Chain process design:
A series of workshops is run to define the end-to-end process after individual design workshops on the level 3 and level 4 processes. Detailed process flows are documented, including exceptions, edge cases, and approval paths. After several weeks, the business is asked to sign off the design.
At no point have users seen the process executed in the system.
Months later, during build or testing, the first demonstrations take place. Users begin to realise:
The process flow feels different in reality
Steps they assumed were simple are more complex
Standard functionality behaves differently than expected
At this point, change becomes expensive.
What should have been early learning is now treated as deviation.
The Cost of Getting This Wrong
When programmes revert to waterfall behaviours early, the consequences are predictable:
False certainty — confidence based on documentation, not experience
Late surprises — issues only discovered during build or test
Increased change resistance — because designs are already “approved”
Higher costs — as changes are raised later in the lifecycle
Weaker business ownership — as users disengage from abstract design
Ultimately, the programme delivers what was documented, not necessarily what is needed.
What Good Looks Like Instead
Avoiding this trap requires active intervention from the organisation with support from Business Integration teams who have project experience with the business value as the only goal.
Some practical shifts make a significant difference in the risk:
1. Demonstrate early, even if imperfect. Users should see processes in the system as early as possible. A rough prototype is far more valuable than a polished document.
2. Delay formal sign-off until after validation. Approval should follow hands-on interaction, not precede it.
3. Redefine progress metrics. Measure success by validated processes and user confidence — not document completion.
4. Align governance to Agile intent. If governance demands detailed upfront approval, it will drive waterfall behaviour regardless of stated methodology.
5. Strengthen client-side leadership. Without firm direction, programmes will default to the SI’s comfort zone. Strong product ownership and programme leadership are critical often requiring Business Integration support from individuals outside the business who are veterans in S/4HANA transformation projects.
The Leadership Question
The difference between Agile and waterfall in S/4 programmes is rarely about methodology documentation.
It is about behaviours in the first few weeks of the explore phase.
Leaders should be asking:
Are we seeing the system early and often?
Are users interacting with real processes — or reviewing documents?
Are we validating assumptions — or approving them?
If the programme is asking the business to sign off detailed designs before even the simplest demonstration, the direction of travel is already clear.
Final Thought
Calling a programme Agile does not make it Agile.
Without deliberate effort, most S/4 transformations will revert to familiar delivery patterns — especially under pressure.
The organisations that succeed are not the ones with the best methodology slides.
They are the ones that actively prevent the slide back into waterfall — particularly when it feels most comfortable to do so.
Comments