Early in my career as a CIO, I had a mentor who described leading a major technology transformation as trying to build a better engine while the car is still moving down the highway. The metaphor stuck with me — not just for its accuracy, but for what it implies about the team you need to pull it off.
Think about it literally. You have the original engineers who designed and know the current engine intimately — that's your internal IT team. You have the people actually driving the car, depending on it to perform — that's your business. And you bring in a specialist shop to help design and install the new engine — that's your system integrator. Every one of them is essential. The job fails without all three working in genuine alignment.
The problem is that these three groups do not naturally align. And in SAP S/4HANA transformations specifically, there is one structural misalignment that I have watched — repeatedly, across organizations of every size — quietly undermine programs that had every reason to succeed.
The mechanic who gets paid by the hour
Imagine you hire that engine specialist on an hourly basis. Every hour of complexity, every additional component, every scope adjustment generates more revenue for them. They are talented. They are professional. They genuinely want to build you a good engine. But when a decision point comes — Do we take the simpler path or the more comprehensive one? Do we scope this tightly or leave room to expand? — their financial interests and yours are not the same.
This is not a critique of system integrators as organizations or of the people who work within them. Most of the SI practitioners I have worked with over the years are capable, hardworking professionals. The issue is structural. SIs are businesses. They price engagements to win work and then manage delivery to margin. Larger programs, longer timelines, and expanded scope are not problems for them — they are revenue. They are, in fact, the business model.
"When a decision point arrives — simpler path or more comprehensive? — your SI's financial interests and yours are not the same. This is not a criticism. It is a structural reality."
The 2027 SAP ECC end-of-life deadline has intensified this dynamic considerably. There is now urgency in the market, and urgency is the ideal environment for scope expansion. Organizations that feel behind are more likely to accept proposals at face value. Executive teams under pressure to show progress are more likely to approve scope additions that feel like they reduce risk. The window for careful evaluation closes when the deadline is looming.
What misalignment actually looks like on the ground
As a CIO, I saw this play out in recognizable patterns. The first was in the original proposal. Competing SI proposals for the same program scope can vary by 40% or more in total cost — not because one firm is dramatically better or worse, but because they are making different assumptions about complexity, staffing levels, and what counts as in-scope. Without an independent framework to evaluate those assumptions, the selection process often comes down to price and relationships rather than analytical rigor.
The second pattern appeared in design decisions. During the Fit-to-Standard workshops that are central to SAP Activate methodology, your SI is making hundreds of configuration recommendations. Each one is a decision about how closely your business processes will conform to SAP's standard model versus how much customization you will build. Customization means more SI work. Standard processes mean organizational change management — which your SI may or may not be incentivized to lead aggressively. The incentive calculus is not always in favor of the simpler, harder-to-sell answer.
The third and most costly pattern is scope creep during the build phase. Change orders are the mechanism by which project scope expands after contract signature. Some change orders are genuinely unavoidable — reality is always more complex than the plan. But in a well-governed program with rigorous design validation upfront, the volume of legitimate change orders drops substantially. The difference between programs that finish near budget and programs that run 30–50% over often comes down to how thoroughly design decisions were validated before build began.
Industry analysis of mid-market SAP transformations consistently shows that 92% miss their original go-live schedule and 65% significantly exceed their approved budget. These are not random failures or isolated incidents. They are predictable outcomes of incentive structures that were never designed to produce a different result.
The car still has to keep moving
Back to the engine analogy. Here is the part that made my mentor's framing so useful: the failure mode is not the specialist shop doing bad work. The failure mode is the specialist shop doing work that is optimized for what they know how to do, without enough coordination with the people who understand the car from the inside and the people who are driving it.
Your internal IT team knows where the bodies are buried — the integrations that were never documented, the workarounds that were built over a decade, the customizations that everyone forgot about until data migration surfaces them. If they are not genuine partners in the design process, not just participants, you will discover those things later. And later is expensive.
Your business users know what they actually need versus what they have been told they need. They know which processes are genuinely critical and which are artifacts of how the old system worked. If change management starts in month seven of a twelve-month program, you have already lost most of the organizational buy-in that determines whether people actually use the new system when it goes live.
Getting all three groups — your SI, your internal IT, and your business — working as a genuine team rather than as parties with separate interests is the core governance challenge of every SAP transformation. And it is a challenge that your SI, however talented, cannot solve on their own. They are one of the parties with separate interests.
What independent advisory actually does
When I advise organizations on S/4HANA programs now, I am not trying to replace the SI or undermine the relationship. A good SI is essential — you need their implementation capability, their SAP expertise, their delivery infrastructure. The goal is to ensure that every major decision in the program has been evaluated from a perspective that has no financial stake in the outcome.
That means being present when proposals are evaluated, not just to check prices but to validate scope assumptions and identify what is missing. It means being in the room when design decisions are made, not to override the SI's recommendations but to ask the questions that a party with implementation revenue at stake might not ask. It means working directly with the business to build the change management muscle early, before the SI's attention is focused entirely on delivery.
The engine analogy holds one more useful insight. The specialist shop does its best work when someone is coordinating the whole effort — making sure the new components are compatible with the rest of the car, that the installation schedule accounts for when the car actually needs to be on the road, that the people who will maintain the engine afterward understand how it was built. That coordination role requires independence. It cannot be played by someone who also builds engines for a living.
Your transformation will succeed when your internal IT team, your business, and your SI are genuinely working together — toward the same definition of success. Building the conditions for that alignment is not something any one of those parties can do for you. It requires someone in the room whose only interest is the outcome.
