Why SAP CX Projects Blow Their Budget (and How to Fix It)

SAP CX projects rarely go over budget because of the software. They go over budget because of how they are scoped, staffed, planned and integrated, and most of those causes are visible before the contract is signed.

That is not only a CX problem. BCG surveyed more than 1,000 companies and found that more than two thirds of large-scale tech programmes are not expected to be delivered on time, within budget or within their planned scope (BCG, 2024). The patterns behind that number are the same ones I see in SAP CX projects.

TL;DR: SAP CX projects blow their budget for five predictable reasons: a scope that was never really defined, too many junior consultants, waterfall planning for cloud software, an underestimated ERP integration, and change management treated as an afterthought. A pricing model that rewards delay makes all five worse. The seven-point checklist at the end of this post lets you test a partner’s offer for each of them before you sign.

Reason 1: The scope was never really defined

Not scope creep. Scope fog. The scope was never clear enough to creep from.

Many projects start with a 40-page requirements document that reads like a wish list. “The system should support all current sales processes.” What does that mean? Nobody agrees. The partner estimates based on its interpretation, the client expects something else, and three months in the gap becomes visible. And expensive.

What works instead: define scope at the process level, not the feature level. “Configure lead-to-opportunity conversion with automatic territory assignment for DACH markets, including an approval workflow for deals above CHF 50’000.” That is a scope item. “Support sales processes” is not. Getting to that level of precision before a partner prices anything is the job of business consulting before the SAP implementation.

At Spadoom, projects start with a scoping workshop that produces a fixed list of deliverables. What is not on the list is not in the project; if the client wants to add something, it is priced separately. The Nussbaum project shows what that discipline looks like in practice: pipeline first, everything else later.

Reason 2: Too many junior consultants

This is the open secret of large consulting firms. They sell the project with senior architects in the room, then staff it with consultants who have 18 months of experience and are learning SAP Sales Cloud V2 on your budget.

A task that takes a senior consultant two days can take a junior five, plus two more to fix what went wrong. Juniors build workarounds instead of using standard configuration, and they make architectural decisions that only surface as problems during testing. By then you are three months in and nobody wants to start over. The “cheaper” day rate ends up costing more.

What works instead: ask your partner exactly who will work on your project. Get names, CVs and SAP certifications. Ask how many V2 projects those people have completed (not V1: the architecture is different). If the answer is vague, that is your answer. Our guide on how to choose an SAP CX implementation partner has the full list of questions.

We name the team in our offer, and the people you meet in the workshop are the people who configure your system.

Reason 3: Waterfall planning in a cloud world

SAP CX products are cloud software with regular releases. Configured, not coded from scratch. And yet many projects are still planned in rigid phases: three months of blueprinting, three months of build, one month of testing, big-bang go-live.

By the time the blueprint is finished, the platform has had new releases and the requirements have shifted. Users see nothing working until month six. When they finally do, the feedback arrives as an avalanche of change requests.

That is not scope creep. That is a methodology problem.

What works instead: SAP Activate, SAP’s own implementation methodology, exists for a reason. Iterative delivery, a working system early, user feedback every two weeks, and course correction while it is still cheap.

We typically work in two-week sprints with a demo at the end of each one, so problems show up early, while the budget can still absorb them.

Reason 4: The ERP integration gets underestimated

“We just need to connect it to our ERP.” Few sentences have cost SAP projects more money.

Connecting SAP Sales Cloud V2 to SAP S/4HANA means mapping data models, synchronising master data, resolving conflicts, handling different update frequencies and building error handling for the night the middleware stops. Then there is the middleware itself, usually SAP Integration Suite, which needs its own design, monitoring and people who know it.

CX projects rarely fail inside the CRM. They fail at the ERP seam: the order that will not post, the price the quote cannot resolve, the customer who exists twice. When the CX partner and the ERP partner are different companies, that seam becomes a line in two contracts that nobody owns. Spadoom delivers the ERP core and the CX stack with one team, which is why we treat the seam as part of the project, not as someone else’s interface. We explain the difference in the best SAP partner for Cloud ERP and CRM in Switzerland.

What works instead: budget integration separately. Not as a line item, but as its own workstream with its own timeline and test phase. Every interface gets a technical design before any configuration starts, and interfaces are tested on their own before system integration testing begins. Our post on the Sales Cloud V2 and S/4HANA Public Cloud integration architecture shows what that design covers.

Reason 5: Change management is an afterthought

You can build the best-configured SAP Sales Cloud V2 in the world. If your sales team does not use it, every franc was wasted. The pattern is familiar: a clean system, few logins, and three months after go-live the reps are back in their spreadsheets because nobody invested in making them comfortable with the new tool.

Much of what shows up as a budget overrun is hidden cost after go-live: firefighting because users reject the system, work around it or flood the helpdesk. The project was “done”. The work was not.

What works instead: put end-user training, key-user workshops and adoption tracking into the project scope from day one, as a proper workstream with its own budget, not as whatever is left at the end.

The pricing-model problem

On top of these five causes sits a structural one: time-and-materials contracts.

Under T&M, the partner earns more when the project takes longer. We are not suggesting partners slow down on purpose, but T&M removes the pressure to be efficient, and the risk of every misjudgement stays with you.

Fixed-price contracts with a fixed scope turn the incentives around: overruns hit the partner’s margin, not your budget. They only work when the scope is defined well enough to price, which brings us back to reason 1. Where the scope allows it, we offer a fixed price; our five-day S/4HANA readiness assessment, for example, has a fixed price that is credited against the transformation if you go ahead.

A practical budget checklist

Before signing your next SAP CX contract, check these seven points:

1. Scope is granular. Every deliverable is described at the process level, with acceptance criteria.
2. The team is named. You know who works on your project and their experience level.
3. The method is iterative. You see working software within the first month.
4. Integration is scoped separately. With its own timeline and test plan.
5. Change management is budgeted. Training, documentation and adoption support are included from the start.
6. Pricing is fixed-scope. Or at least capped, with a clear change-request procedure.
7. References are real. You can speak to clients who completed similar projects.

If a partner pushes back on any of these, that tells you something.

The bottom line

SAP CX projects do not blow their budget because of SAP. They blow it because of how they are planned, staffed and managed.

The companies that succeed treat the implementation as a business project, not an IT project. They invest in a clear scope, insist on experienced teams and iterative delivery, budget the ERP integration honestly, and choose partners whose incentives match on-time delivery.

If you are planning an SAP CX implementation, or need to rescue one that has gone off course, let’s talk openly about what it takes.

Most of these overruns are decided when the partner is chosen. Our comparison of the best SAP CX consultancies in Switzerland lists the evidence to ask for, and our page on SAP CX consulting in Switzerland shows how we scope and staff a project.

Frequently asked questions

What is the average budget overrun for SAP CX projects?

There is no reliable figure specific to SAP CX. Across large technology programmes, BCG found that more than two thirds are not expected to finish on time, within budget or within scope (BCG, 2024). An Oxford study of 1,471 IT projects found that one in six had a cost overrun of around 200% (Flyvbjerg and Budzier, 2011). SAP CX projects follow the same patterns.

Is fixed-price always better than time and materials?

Not always. Fixed price works best when the scope is well defined, as in most implementation projects. Time and materials fits work whose scope is genuinely uncertain, such as advisory work or proofs of concept. Match the pricing model to the type of project.

How do I know if my partner is underestimating the integration?

If you are connecting to an ERP and the integration is a small share of the estimate with no separate timeline or test plan, be sceptical. Ask the partner to list every interface, the middleware, the error handling and the test approach. Vague integration estimates are a red flag.

Should I have my own project manager or rely on the partner’s?

Both. Your internal project manager owns the business outcomes and the stakeholders; the partner’s project manager owns delivery. If you only have the partner’s, you have delegated accountability for your own project.

How much should we budget for change management?

Enough to run it as a proper workstream: end-user training, key-user workshops, documentation and adoption tracking after go-live. The exact share depends on the number of users and how much their daily work changes, but it should be a named line in the plan from the start, not the remainder at the end.