In SAP projects, resistance doesn’t always appear as outright refusal.
It is often found in someone nodding along while inwardly disagreeing, or a task that keeps getting pushed back, or a stakeholder who smiles through discomfort.
Aside from technological issues, SAP projects fail because the people tasked with using the new system felt sidelined, unheard, or quietly unsure.
This isn’t about the personality or attitude of individual users, it’s a set of questions around organizational psychology.
This article from IgniteSAP looks at how SAP consultants and project teams can recognize this kind of resistance early, how they can reduce its grip, and how to work with it instead of against it as a means to reveal design flaws or practical consequences that may have been missed in planning.
The earliest signs of psychological resistance tend to appear long before anything is said directly. A stakeholder might repeatedly defer decisions with phrases like “whatever you think is best.”
They might avoid providing specific inputs, delay reviews, or stop responding to requests without explanation. When stacked together, these behaviors may point to a team or team member who is disengaged or uncomfortable.
Confusion can be mistaken for resistance or vice versa, so it is sometimes difficult to determine which is the cause of disengagement.
A stakeholder who asks the same question several times may simply not understand the proposed change. But someone who says nothing and later refuses to use the system may have had doubts all along. It’s important to watch not just for what’s said, but how it’s said, and for any avoidance of particular subjects.
Consultants who notice these signs early can prevent deeper problems later. They can check in informally, offer another round of explanation, or revisit a decision with more flexibility. These small moves can open space for honest feedback, before misalignment of stakeholders becomes a project risk.
Much of this comes down to how consultants gather information and read the room.
Discovery workshops and design sessions help in gathering requirements, but they’re also a chance to reveal the needs of users themselves. Asking someone directly “Do you agree with this?” might not get you a real answer. But asking “What might someone in your team find challenging about this change?” often opens a real conversation.
It also helps to ask people to imagine failure. “If this process breaks at go-live, what do you think will have gone wrong?” It sounds negative, but it’s a safe way for people to voice concerns without blaming anyone.
The same applies to tools like anonymous feedback boards or “silent mapping” exercises where people write down pain points privately before discussing them. Separating problems from people leads to more engagement.
It is also important to just watch how people behave in group sessions. Who speaks first? Who never speaks unless asked? Does someone visibly tense up when a certain process is mentioned? These are clues, and they often say a lot more than what people may share out loud.
Avoid forming opinions too early and stay receptive. People act differently for all kinds of reasons, like role pressure, workload, past experiences. Describing someone as “negative” or “checked out” without understanding their context does not solve the problem, so try to think in patterns, not personalities. When the same behavior shows up across several meetings, that’s a pattern worth exploring to find the root cause.
The conditions that allow resistance to grow exist before the first workshop begins.
Many SAP projects still start with a top-down announcement, a rigid timeline, and a set of consultants introduced as experts sent to “roll out the system.” That framing already puts internal teams on the back foot.
One way to avoid this is to flip the usual introductions. Instead of consultants listing their SAP credentials, invite the internal stakeholders to teach the consultants how their current processes work.
Another approach is to hold a co-scoping session before finalizing timelines or deliverables. Ask stakeholders what about the project makes them nervous, what success would look like in their day-to-day roles.
The communication structure has a major role in making a project inclusive. Internal emails or slide decks shouldn’t just describe features or deadlines. They should talk about what will change for the people involved, what won’t, and why. They should address common fears directly: “Will I lose control of this process?” “Will the new system make things harder?” These concerns are normal, and should be covered in detail.
Finally, a structured welcome pack goes a long way. This might include a visual timeline, a simple “meet your SAP team” intro, some FAQs in plain business language, and a contact point for any questions. When people feel informed and involved, they’re more likely to speak up when something doesn’t feel right.
Some of the best feedback doesn’t come in meetings, it comes walking back to someone’s desk, or in a quick check-in message afterward. These informal interactions often reveal what people don’t say in the group.
A question like “What did you think about today’s meeting?” in a quiet moment can bring up useful reflections.
Every week, the project team can also adopt small rituals that make space for feedback. For example, during internal stand-ups, team members can share one thing they’re optimistic about and one thing that’s still unclear or worrying.
Another technique is to make disagreement part of the process. Instead of treating dissent as a disruption, invite it. Try dedicating part of a workshop to playing devil’s advocate: “What would someone critical of this process say?” or “What’s the weakest part of this design?”
Despite best efforts, resistance will still appear. When it does, the way consultants respond can either open a useful conversation or shut it down.
The key is to avoid reacting defensively. If a stakeholder pushes back or expresses doubt, the goal is to understand where that response is coming from. A phrase as simple as “That’s helpful, can you say more about what’s not working for you?” can do far more than a counter-argument.
There are also times when consultants need to admit misjudgment. If a process feels more disruptive to users than expected, acknowledging that openly doesn’t weaken credibility. It builds trust. A line like “We may have underestimated the impact here, thank you for raising it” resets the tone and invites collaboration.
Design Thinking offers tools that help redirect conflict. Exercises like empathy mapping or process sketching make abstract disagreements concrete. When people can see and shape what the process might look like, resistance often shifts into problem-solving.
User testing is another stage where resistance often shows up. Test scripts might have been skipped, bugs reported late, or users might claim they don’t have time to test. The best response is not to push harder, but to ask why.
Occasionally, resistance comes from the top. A senior leader might disengage, delay decisions, or quietly signal that the transformation isn’t a priority. Internal teams often feel stuck in these cases, caught between a consultant’s plan and their own hierarchy.
Instead of saying “Leadership isn’t supporting the change,” reframe it as: “We’re seeing delays in approvals that may affect our next milestone.” If needed, consultants can raise these observations externally, supported by data or timeline shifts, so that the message is seen as part of project governance rather than internal critique.
Good delivery is determined by how consultants think, speak, and react in difficult environments. To do this well, teams need to be prepared for people who are wary, hesitant, or skeptical, not because they’re difficult, but because they’ve seen past projects fail.
Training consultants to respond well in these situations takes practice. One approach is to use scenario-based simulations. Along with technical walkthroughs, delivery teams can rehearse difficult conversations.
These exercises build awareness and help shift from instinctive defensiveness to thoughtful response. They also help consultants notice their own habits, whether they tend to speak in jargon, rush to explain, or avoid emotional topics.
Another part of preparation is understanding different stakeholder types. Some users are cautious and want to see proof before committing. Others are forward-thinking but lose patience with process detail. A simple way to prepare is to match these behaviors with specific approaches.
Finally, consultancies can support their teams by building resistance-awareness into their toolkits. This might mean checklists of behavior patterns to watch for, simple heatmaps that track engagement over time, or conversation frameworks that help consultants adjust their tone and message based on what they observe. The goal isn’t to script every interaction, but to give consultants more ways to respond in the moment.
Traditional SAP project metrics focus on timelines, budget, and task completion. But by the time a milestone slips or a go-live is delayed, the resistance that caused it may have been building for weeks.
That’s why it helps to pay attention to behavioral signals. A drop in meeting attendance, a slowdown in approvals, or fewer comments on shared documentation can all signal disengagement.
Some teams use simple sentiment surveys or check-ins to gather data. Questions like “Do you feel confident in your role in this phase?” or “Is there anything you’re unclear on right now?” provide an early picture of how people are feeling. Even quick polls or short comments can show trends, especially when the same concern comes up from multiple teams.
Capturing this feedback, even after completion, and folding it into internal playbooks helps delivery teams improve.
Once the consultants leave, the organization still has to live with the system, so internal teams need the skills to handle resistance on their own.
One way to support this is by creating a culture where disagreement isn’t avoided, but expected. This means running regular retrospectives, not just on what worked, but on what people are still wrestling with. It also means making space for concerns after go-live, when the initial energy fades and the real work begins.
Projects that treat resistance as something to suppress often find that it comes back, just later, and harder to fix. But teams that treat it as a useful signal tend to adapt more quickly. They use resistance to test decisions, to catch problems early, and to keep people engaged in the journey.
SAP systems are administered and used by people, so resistance is part of the environment in which systems are built. When it’s taken seriously: not as a problem to be solved, but as feedback to be heard, it can strengthen the design, deepen user commitment, and improve long-term adoption.
The best consultants listen, adjust, and create space for challenge. They treat resistance not as an obstacle, but as a signpost, because the best SAP systems work for everyone.
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.
Why Growth Rate Is the Wrong Metric for Judging an SAP Employer
How to Identify the Ceiling in Your Current SAP Career Path
