Any consultant who’s survived more than one SAP go-live recognizes the scene in a meeting where half the team is nodding, the other half is staring into space, and no one is quite sure whether the comment “that’s your issue” was meant as a joke.
That familiar divide between internal and external delivery teams is the focus of this article from IgniteSAP. We’ll look at where this “us vs them” mentality comes from, why it shows up so often in SAP delivery, and what practical steps consultants and SAP leaders can take to keep it from derailing implementations.
Humans form into groups. Long before business process mapping or system landscapes, people picked sides based on who they felt safest around.
In delivery teams, those lines are often drawn by who’s on payroll, who’s on contract, and who’s been told not to speak to the client.
Once people are grouped, they start to protect their own. They attribute good intentions to their group, and flawed reasoning or motivations to everyone else. This is a function of the brain trying to reduce uncertainty in an environment where there’s too much of it. In SAP projects, this tendency tends to magnify because of the pressure, the pace, and the sheer volume of decisions being made by people who barely know each other.
It starts small: consultants sit on one side of the room, internal teams on the other. Then it spreads: jokes about “the business not knowing what they want,” comments about “the consultants not understanding how we operate,” and eventually, requests that bypass certain team members because “it’s faster that way.”
The complex structure of SAP delivery models, with multiple partner firms, distributed workforces, internal stakeholders with shifting priorities, and complex contractual arrangements, can create more caution than trust.
Add a few reorganizations or leadership changes, and you have a severely fragmented team, yet well-intentioned SAP methodologies tend to assume a level of mutual goodwill that doesn’t always survive the first planning session.
In SAP Activate, for example, the structure suggests co-ownership: business process owners working alongside functional consultants, with joint workshops, and shared KPIs. Unless these are actually practiced with a degree of discipline and openness, they function merely as signposts, undermining the effectiveness of the model.
The problem deepens when you add different delivery models, employment models, and overlapping roles into the mix.
Embedded consultants are often treated like internal staff until a tricky decision needs cover. Strategic advisors operate at a level where they’re rarely questioned, and temporary external contractors might end up doing foundational work with no input into scope or timelines. Each of these arrangements creates a slightly different relationship to the project, and a slightly different degree of loyalty to the project as a whole.
Contractual setups can contribute to the problem too. Fixed-price arrangements make consultants wary of overextending. Time-and-materials deals make clients hypersensitive to timekeeping. Outcome-based models sound promising, but while they are gaining traction in RISE with SAP and managed services contexts, they can be difficult to apply cleanly in complex transformations unless outcomes are tightly scoped and jointly defined.
Consultants have more influence on delivery culture than they might admit, so they hold some of the power to break down social barriers.
The tone consultants use in daily stand-ups, how they react to pushback, the way they document (or fail to document) decisions, all send signals about whether this is a shared project or just a process to get through.
First, it helps to drop the notion that technical expertise earns you unquestioned authority.
The fact that you know how to build the integration isn’t proof that you should bypass the internal team to get it done. Equally, if you’ve worked on ten other S/4HANA programs, that doesn’t automatically mean you understand the constraints of this particular business.
Second, consultants who treat knowledge transfer as a formality are missing a chance to build genuine cohesion.
Pairing on tasks, inviting internal teams to lead sessions, and explaining configuration decisions are how shared ownership is established. And shared ownership, in an SAP program, is the best insurance policy you’ve got against “us vs them” causing problems later on.
Staying neutral doesn’t mean saying nothing when things go wrong. It means raising issues without picking sides, and offering challenge without inviting conflict. There’s a difference between being diplomatic and being passive.
SAP delivery doesn’t lack structure, but it often lacks shared structure.
The rituals of sprint planning, daily stand-ups, retrospectives, and phase gates exist for a reason, but whether they bring teams together or quietly split them apart depends on how they’re run.
Too often, onboarding focuses on little more than technical access, but it’s the unspoken expectations: who to talk to about what, what counts as an “acceptable” challenge, or when it’s okay to say you don’t know, that make or break collaborative delivery. Treat onboarding as a cultural introduction, not just a technical exercise.
The simplest way to start building cohesion is to make these routines inclusive by default.
That means sharing as much information as possible: joint sprint reviews where everyone gets to present work, shared backlogs, and retrospectives with both internal and external participants. If your teams can’t access real-time information on project progress, you’re siloing your delivery teams.
SAP’s Activate method offers a few ways to put these principles into practice. Fit-to-Standard workshops, for example, are intended to be joint discovery efforts.
Shared testing cycles can also function as trust-building exercises if internal and external testers talk in detail about defects. These work best when testers collaborate directly on defect triage, rather than logging issues in isolation. And steering committees also only serve their purpose if the decisions they produce and the reasons for those decisions are made visible to all participants.
Governance in SAP delivery is meant to provide structure and accountability, but it can end up obscuring who’s responsible for what, and creating space for passive group behaviors to become entrenched.
Well-designed governance helps by reducing ambiguity. That means agreeing early who owns which decisions, how escalations are handled, and how input from different parties is weighed. RACI matrices (who is Responsible, Accountable, Consulted, and Informed) only work if they’re reviewed when the project changes shape: which it inevitably will.
Another helpful tool is the delivery charter. Written early, co-signed by all delivery parties, and kept visible throughout, a charter describes how the team intends to work together: not just how issues are escalated, but how challenges are met. Not just who signs off deliverables, but who contributes to them.
Leadership, of course, is the main way to ensure a collaborative structure and culture. And by leadership, we don’t just mean the program sponsor or the senior architect.
The tone set by team leads, scrum masters, workstream owners, and project managers has more day-to-day impact than the grand vision. It’s in the small decisions, like inviting a contractor to the planning meeting, or the habit of thanking someone publicly for work that wasn’t in their job description. These little choices shape the overall feeling of whether this is truly a shared effort.
In mixed teams, division slips in through duplicated documents, parallel meetings, and decision logs that only include half the people affected by them. The symptoms are familiar: “We didn’t know they were doing that.” “We thought that was already signed off.”
Sharing tools helps, but only when used intentionally. Having a project dashboard is almost meaningless if only one group updates it. Using solutions like SAP Cloud ALM to store documentation can support transparency, but only if access rights aren’t quietly reinforcing the divide between “real” team members and “external resources.”
Delivery boards that track cross-functional activity along with technical tickets can highlight where coordination is fraying. Weekly reviews that combine functional and business inputs help surface emerging gaps before they become rework. And meeting minutes, that most neglected of project materials, matter far more than people think, especially when trust is thin and context is fragmented.
Communication channels should follow the same principle. If consultants have their own Slack workspace, and the internal team uses Teams, and the offshore developers live in a WhatsApp group, no one should be surprised when decisions don’t line up. Choose one, and encourage everyone to stick with it.
Most SAP programs treat go-live as the finish line. The reality is more like the start of a another sequence where old habits return, handovers are rushed, and whatever cross-team cohesion existed during the build starts to dissolve.
Preserving the cultural gains of a project requires rituals that acknowledge the shift in delivery mode. Final retrospectives, for example, are often skipped in the rush to move on, but they’re essential for capturing how the team functioned, what helped it survive the harder phases, and what should be used in future work.
Consultants who walk out the door with undocumented learnings represent a lost investment, not just a gap in knowledge. Also, internal teams need a structured path towards owning the platform. That means having experienced delivery leads shift into coaching roles. It also means recognizing that confidence in managing the system takes time, and continuing support in a way that respects autonomy without abandoning people.
For all the talk of team culture, very few SAP programs bother to measure it. Project status is tracked closely, but no one seems to ask whether people feel able to speak up, whether communication is actually two-way, or whether decision-making is inclusive.
That’s a missed opportunity because cultural drift is one of the earliest signs of delivery risk. Team health checks like short surveys or structured feedback loops can flag warning signs before they become structural flaws. Tracking how knowledge moves from consultants to client teams, across business and IT, gives a detailed view on project maturity.
There’s no way to fully prevent group identities from forming in SAP projects. A healthy sense of belonging isn’t the problem. The problem is when those identities start dictating who gets heard, who gets trusted, and who gets left out.
The good news is that project cohesion is shaped incrementally by everyday routines, tools, and conversations. It’s determined by who gets included, how disagreements are handled, and what gets documented.
Consultants, internal teams, and leaders all contribute to this culture, sometimes deliberately, sometimes unconsciously. But with a little attention to how people relate across those blurry lines, SAP delivery can feel less like a series of territory disputes and more like a shared construction site, where everyone’s trying to build something they can be proud of.
If you are an SAP professional looking for a new role in the SAP ecosystem, our team of dedicated recruitment consultants can match you with your ideal employer and negotiate a competitive compensation package for your extremely valuable skills, so join our exclusive community at IgniteSAP.
Understanding the Grade Structure Inside an SAP Consultancy
Why Growth Rate Is the Wrong Metric for Judging an SAP Employer
