Why We Finish SAP CX Projects When Others Don't

SAP CX projects rarely fail because of the software. They stall because the scope was vague, the people who sold the project were not the people who built it, and the ERP integration was left for the final weeks. We get called into those projects regularly, and the fixes are less spectacular than people expect: the same senior people from the first workshop to go-live, a scope written as deliverables, integration work from week one, and the discipline to say no.

TL;DR: Four habits get our projects live: senior people who scope and build, a scope written as testable deliverables, ERP integration and real data in the first sprints, and turning down projects we cannot deliver as asked. The evidence is public: OPO Oeschger’s stalled V2 project was live three months after we took over, on time and on budget.

What the evidence looks like

We would rather show projects than quote a success rate. These are published, with the customer’s agreement:

• OPO Oeschger: a Sales and Service Cloud V2 project that had stalled with another partner. We restarted it, had the MVP running after two months and the complete Phase 1 in production after three, on time and on budget, connected to S/4HANA, Datasphere and Commerce Cloud.
• Franke: a stalled Commerce project. Spadoom brought the SAP Commerce Cloud platform live in 90 days, and the project received the SAP Quality Award for “Rapid Time to Value”.
• Nussbaum: a Sales Cloud V2 greenfield, from no central CRM to full pipeline visibility in five months.
• intelligentfood: Sales and Service Cloud V2 live in three months, connected to the ERP.

None of this means every project is easy. It means the patterns below work often enough that we no longer run projects any other way.

Senior people from day one

The most common failure pattern we find in rescued projects is a handover. An experienced team wins the deal, then moves on to the next pitch, and the people who arrive for delivery are meeting the requirements for the first time. Nobody intends it. It is how many large firms staff projects.

We do not have a separate sales team and delivery team. The people who scope your project are the people who build it, and they have delivered V2 projects before. At OPO Oeschger, that meant the team that analysed the stalled project also rebuilt it, without a second learning curve.

A scope written as deliverables

“Set up CRM” is not a scope. “Configure opportunity management with four custom stages, weighted pipeline and automated notifications” is. The difference between those two sentences is the difference between a project that ships and one that turns into months of renegotiation.

Every project gets a scope document with deliverables and acceptance criteria. That protects both sides. When a new requirement appears, we do not refuse it; we say what it costs and what it does to the timeline, and you decide before any work starts.

Integration and real data early

Most late surprises come from the ERP boundary: a price the quote cannot resolve, an order that does not post, customer data that does not match. So we design the integration before the first screen and load real data into a test system in the first weeks. Problems that surface in week four are cheap. Problems that surface in month six have already been built into everything else.

This is also where one team for ERP and CX pays off. Because we deliver S/4HANA Public Cloud as well as Sales Cloud V2, the interface between them is a design decision inside one project, not a negotiation between two vendors. We explain the architecture in S/4HANA Public Cloud and Sales Cloud V2 as one stack.

Iterative delivery with visible progress

We work in short iterations following SAP Activate:

• First weeks: confirm requirements and integrations, set up the systems, load test data.
• First sprints: key users see a working system with their own data.
• Every two weeks: a demo with key users, who test and give feedback, and we adjust.
• Before go-live: integration tests, migration checks, user acceptance testing and cutover preparation.

The point is not the method’s name. It is that problems become visible while they are still small.

Saying no

This one costs us deals, and it is probably the most important habit. If a prospect wants Sales Cloud V2, Service Cloud V2, Commerce Cloud, SAP Engagement Cloud and CDP in one six-month project with a team of four, we say it is not realistic and propose a sequence that is. If a company wants its fifteen-year-old CRM rebuilt field by field in the cloud, we explain why that is the wrong goal. A smaller first phase that goes live beats a large one that does not.

What we see in projects we inherit

The same five problems appear again and again in projects that come to us after stalling elsewhere:

• A vague scope that grew without a budget adjustment.
• Custom code where standard configuration would have worked.
• No integration testing until the final weeks.
• No user involvement until acceptance testing, when the sales team rejected the system.
• A big-bang go-live without a fallback plan.

All five are preventable, and none of them is a technology problem. If you are evaluating partners, our guide on how to choose an SAP CX partner turns these patterns into questions you can ask in the first meeting. The reasons budgets overrun are covered in why SAP CX projects blow their budget.

FAQ

Do all your projects go live on the planned date?

We do not publish a blanket percentage, because a single number hides more than it shows. What we publish are named projects with their timelines: OPO Oeschger, Franke, Nussbaum and intelligentfood among them. Ask us for references on your product and call them.

How do you handle changing requirements?

With a written scope and a transparent change process. Every change is estimated and approved before work starts. If a change would move the go-live date, we say so early and you decide whether to adjust the timeline or the scope.

Can you take over a stalled SAP project?

Yes. That is how the OPO Oeschger and Franke projects started. We begin with a short assessment of what exists, decide with you what to keep and what to rebuild, and set a new plan with named people. We do not patch old scaffolding if a clean restart is faster.

Where do you work?

From Zug, Wädenswil, Monza, Vienna and Tallinn, with projects mainly in Switzerland, Germany, Austria and Italy. We have supported international rollouts for companies headquartered in Europe. Our consultants work in German, French, Italian and English.

How do I verify your track record?

Read the customer stories and ask us for references on the product you are buying. Ask the reference directly: did the project go live when planned, did the budget hold, did the same people stay throughout? If you are preparing an ERP move as well, start with our S/4HANA readiness assessment or talk to us.