Why companies pick the right implementation partner and still struggle
By Brad Nicolaisen, Senior Vice President, Strategic Growth & AI Innovation, TotalTek
I have spent most of my career around SAP programs from different seats at the table: inside SAP, inside smaller SAP partner organizations, as the founder of an SAP partner business, as a delivery leader, as an executive sponsor, and as the person responsible for managing systems integrators when the stakes were high and the room was not always friendly.
That range has been useful. It also came with tuition.
I have seen strong SIs rescue messy situations. I have seen weak ones make already difficult programs worse. I have also seen capable SIs struggle because the client was not ready to be the kind of client a major SAP transformation requires. And yes, I have made enough mistakes myself to know which ones I do not plan to repeat.
That is why I believe many companies frame SI selection too narrowly. They think the question is, "Which SI should we choose?"
That is important, but incomplete.
The better question is this: "What must be true inside our company for the SI we choose to be successful?"
That single question changes the entire process. It moves the conversation from procurement to readiness, from vendor comparison to program design, and from sales presentations to execution reality.
A good systems integrator brings methodology, SAP depth, industry experience, delivery scale, templates, accelerators, and people who have been through the implementation cycle before. Those things matter. I would never minimize them.
But an SI cannot make the client own the transformation.
They cannot create executive alignment after kickoff. They cannot force timely business decisions if the governance model is weak. They cannot fix unclear data ownership with a methodology slide. They cannot turn part-time business involvement into full-time accountability. They cannot compensate forever for a PMO that is treated like an administrative reporting function instead of the operating system for the program.
The SI can help. The SI can lead parts of the work. The SI can challenge and guide. But the SI is still one part of the transformation model, not the whole model.
This is where many S/4HANA programs begin to drift. Not at cutover. Not during testing. Not even during design. The drift often starts before the statement of work is signed, when assumptions are still soft, ownership is still vague, and everyone is motivated to believe the plan is more complete than it really is.
Most SI evaluations cover the obvious ground: implementation experience, SAP certifications, industry references, proposed timeline, commercial model, methodology, team structure, and executive commitment. Those are necessary inputs. They are not enough.
The sales room is not the delivery room.
The partner who shows up for the pitch may not be on the daily grind of design decisions, data cleansing, testing cycles, integration triage, OCM friction, and business readiness. The methodology may be polished and still leave critical client responsibilities undefined. The scope may look comprehensive while relying on assumptions that later become delays, change orders, or finger-pointing.
Nobody puts the risky assumptions in 28-point font.
That is why due diligence has to go beyond "Can you do this?" A serious selection process should ask, "How will you behave when this gets difficult? Where do you expect us to lead? What do clients like us typically underestimate? What are you assuming that we have not validated yet?"
The best SIs will welcome those questions. The wrong ones will try to steer you back to the deck.
Most firms invited into a serious S/4HANA selection process are capable. They have SAP credentials, implementation references, experienced partners, and a recognizable methodology. Capability gets them in the room. Fit should determine whether they stay there.
Fit is not about whether the team is likeable, although working chemistry matters more than most people admit. Fit is about whether the SI's operating style matches the client's reality.
Will they challenge you when your decision process is too slow? Will they be honest about the client-side roles you are underestimating? Will they tell you where your timeline is optimistic? Will they put real delivery leaders in front of you, not just pursuit leaders? Will they explain where scope ends instead of letting ambiguity survive until the change order arrives?
I would rather have the SI that tells a leadership team the uncomfortable truth in the selection process than the SI that politely nods until the contract is signed.
The questions below are the kind I like to see before an SI is selected or before Phase 0 locks in the delivery model. They are not designed to embarrass the SI. They are designed to expose the real work.
That last question is one of my favorites. It cuts through the choreography. A good SI will answer it directly. A great SI will answer it with enough candor that the client learns something about itself before the project starts.
Many SI scorecards are built to look objective but end up confirming the preference the room already had. The categories are too broad, the weighting is too generic, and the scoring does not reflect the actual risks of the program.
If business adoption is one of the biggest risks, OCM cannot be a five percent afterthought. If the client has limited internal capacity, the scorecard should heavily evaluate client enablement, role clarity, and the SI's expectations of client-side ownership. If the program depends on manufacturing process discipline, the scorecard should test functional depth and practical operating experience, not just firm-level credentials.
A useful scorecard should measure the decision you are really making. I typically want to see categories like these:
The weighting is where the truth shows up. If everything is important, nothing is important. A disciplined scorecard should make leadership choose what matters most, then live with that choice.
A legal review of the statement of work is necessary. A delivery-risk review is different, and it is just as important.
The delivery-risk review looks for ambiguity that sounds harmless until the program is under pressure. Words like "support," "assist," "coordinate," "participate," and "as needed" deserve a second look. They are not bad words, but they are incomplete words.
Support how? Assist with what? Coordinate across whom? Participate as an owner or an observer? As needed by whose judgment?
These questions matter in PMO, OCM, data, integrations, testing, training, reporting, and business readiness because those areas often sit in the gray space between SI responsibility and client responsibility. Gray space is where delays are born.
One of the most useful things a company can do before signing is build an assumptions map. Take every material assumption from the SI proposal and SOW, then assign it an owner, a validation method, and a risk level. If an assumption cannot be validated, it should not be quietly accepted as a fact.
I have a strong bias on this one because I have watched programs underuse the PMO and then wonder why decisions, risks, dependencies, and escalations became blurry.
A transformation PMO is not there to collect status reports and schedule meetings. A real PMO creates the operating cadence of the program. It manages the integrated plan. It forces decision discipline. It tracks assumptions, issues, risks, dependencies, actions, and scope movement. It makes executive steering useful instead of ceremonial.
Most importantly, the PMO protects the business from passive drift.
The SI will have its own project management structure. That does not eliminate the need for a strong client-side PMO. In fact, it increases the need for one. The SI's PMO is designed to manage the SI's delivery responsibilities. The client PMO must manage the business transformation, the internal decision model, the client-side work, and the relationship between what the SI is doing and what the business must own.
Those are related. They are not the same.
OCM is another area where companies can fool themselves early.
The question is not whether the SI has an OCM workstream. Most do. The question is whether that workstream is connected to the real disruption the program will create.
A strong OCM evaluation should ask how role impacts will be identified, how process changes will be translated into business readiness, how leaders will be equipped to sponsor change, how resistance will be surfaced, how adoption will be measured, and how OCM will be linked to testing, training, deployment, and stabilization.
If OCM lives off to the side, it becomes newsletters and training logistics. If it is embedded in the program, it becomes a risk-management discipline for adoption.
Phase 0 is often treated as discovery. That is fine as far as it goes, but it should be more than discovery. It should be a stress test of the future program.
Before the broader program is moving at full speed, Phase 0 should clarify how decisions will get made, how scope will be controlled, what business resources are required, how risks will be escalated, what the SI is truly accountable for, what the client must own, how OCM will be integrated, and what success looks like at the end of each phase.
The worst time to invent governance is after the program is already late.
The best companies enter Phase 0 with enough structure to challenge the SI constructively, not so much structure that they stop listening. That balance matters. You want to be open to the SI's expertise without outsourcing your judgment.
The work I recommend before or during SI selection is practical. It is not theory, and it is not a 100-page binder that nobody will read. The goal is to create enough clarity to make better decisions and avoid preventable surprises.
SI Due Diligence Question Bank: A tailored set of questions designed to expose delivery behavior, staffing assumptions, client responsibilities, and risk transparency.
Weighted SI Scorecard: A decision model that forces leadership to weight what actually matters for the program, not just what looks clean in an RFP.
SOW and Assumptions Gap Review: A delivery-risk review of vague language, exclusions, dependencies, and areas likely to become future conflict or change orders.
Client Readiness Assessment: A practical review of governance, business ownership, data accountability, PMO maturity, OCM capacity, and decision rights.
Governance And PMO Blueprint: The client-side operating model for cadence, escalation, executive steering, risk management, decision control, and integrated reporting.
OCM Evaluation Lens: A way to judge whether change management is integrated into the transformation or simply bolted onto training and communications.
This is the part some companies miss. The SI can absolutely help shape Phase 0, and a good SI should bring valuable structure. But the SI is also shaping work it may deliver. That is not wrong. It is simply a reality that needs to be managed.
The client benefits from an independent lens before the delivery model is locked in. Someone needs to ask the awkward questions early, when they are cheaper to answer. Someone needs to look at the scorecard, the assumptions, the governance model, and the OCM plan from the client's side of the table.
That role should not be adversarial. The goal is not to beat up the SI. The goal is to help the client become a better buyer, a better owner, and ultimately a better partner to the SI it selects.
Before an organization commits to an SI or exits Phase 0, leadership should be able to point to a few tangible outputs:
This is not bureaucracy. This is risk reduction.
Companies that do this prework tend to be harder to sell to, but much easier to deliver for. They ask better questions. They negotiate cleaner scope. They catch unrealistic assumptions earlier. They know what they own. They make SIs better because they create a healthier operating environment for delivery.
Selecting the right SI matters. It matters a lot. But it is not enough.
The real objective is to choose the right implementation partner while building the client-side structure required to make that partner successful. That means harder questions, a sharper scorecard, a delivery-risk review of the SOW, a serious look at PMO and governance, and an honest assessment of whether the organization is ready to own the transformation.
I have seen both sides of the struggle. I have been the consultant, the founder, the executive, the delivery leader, the client-side manager, and the person looking back at a decision thinking, "We should have challenged that earlier."
That is the lesson I would offer any company preparing for an SAP transformation: do not wait until the project is under pressure to find out whether the SI selection process asked the right questions.
The project does not really start at kickoff. It starts when leadership decides how serious it is willing to be before kickoff.