People Over Platforms: Why Most S/4HANA Projects Fail at the Human Layer, Not the Technical One
I have said the same thing to clients so many times that my own team is tired of hearing it. It goes like this: there are really two ways to do a project. You can do a project to an organization, or you can do a project with an organization. That distinction sounds small, but in my experience, the projects that you're doing with an organization tend to have the most successful outcomes.
To be clear, none of this means the technology is simple, or that projects never fail for technical reasons, because they do. Data that is not ready will sink a project, and so will a foundation that is not prepared to make the move to SAP S/4HANA.
But after years of this work, the failure I see far more often is the one where the project goes live and runs cleanly, but the people it was built for never really adopt it.
This Is the Way We've Always Done It
In almost every implementation, a single phrase tells me when it may be challenging to get a team to adopt a new tool. It usually starts with someone saying, "But this is the way we've always done it."
When I hear it, I stop. That phrase is rarely about the task. It is about an attachment to the task, and underneath the attachment is a reason worth understanding before you do anything else, so I ask the team to tell me more.
Sometimes I learn that the old way is fine, and the new system can accommodate it. More often, the old way runs straight into the best practice the new solution is built on, and at that point, the best move is to escalate it to the people accountable for the investment rather than quietly engineer around it.
What I've found is that the new solution is rarely the enemy of the old way. It usually makes the old way better, retiring a manual step or a spreadsheet nobody enjoyed maintaining. But that case lands at the human level, and you can only make it once you have stopped long enough to hear what the resistance to change is really about.
The Discipline That Gets Cut First
Change management is one of the most underrated disciplines in this entire ecosystem, and I can usually predict the moment it gets cut. It happens when the conversation turns to cost. The argument usually sounds like this: a client will say they already have a change management team internally. But the truth is, change management coming from only one side of the table gives you only one version of the truth.
What works is both sides together from the start: the client's change leads, and the partner's change leads managing the same waters, getting ahead of the anxieties in the user community. I believe this matters enough that on a project we recently kicked off, one of the first things we did was introduce the two change leads to each other, right alongside the project managers.
Because they are embedded from day one, the change team should also be the voice that delivers it when a change has to be explained to the business — not the solution architects, not the technical leads. Too often, they are treated as an afterthought instead, handed a couple of minutes once most of the room has already checked out.
Done well, this is what I mean when I talk about commitment to change management every day and twice on Sunday. An organization leaning into a project feels totally different from one bracing against it.
What It Looks Like on the Shop Floor
In an industrial manufacturing environment, the people whose platform change affects most are rarely in the boardroom. They are on the shop floor, and that is where change management has to actually reach.
While working with clients at Argano, I found that the most useful intelligence on any project comes from those users, and the only way to get it is to stand next to them and ask. What could you not imagine giving up, because losing it would make your day miserable? What would you change tomorrow if you could, because it would make the work easier? Then ask them to show you.
They will point at a screen, or hold up a stack of paper they cannot wait to be rid of, and tell you exactly what a better day looks like. Those are the golden nuggets you carry back to the project team, your real definition of success. Deliver the thing a shop floor worker told you would change their day, and you have someone who is glad the project happened and more likely to support future changes.
The Hardest Thing to Do Well
Strip it all of this down, and what remains is communication and a shared desire to reach the finish line. It sounds obvious, but it's the hardest thing to do well on any project. Communicating during good weeks takes no effort. However, the projects that succeed are the ones where both sides can still talk productively in the weeks that are not good, when there is a mistake to own or a hard truth to raise. The discipline is to use your ears as much as your mouth and to name the hard thing while it is still small, before a speed bump has the chance to grow into a mountain.
That willingness to have the hard conversation, more than any technical decision, is what separates a great outcome from a poor one.
Nobody buys SAP to keep working the way they always have, and yet many of these platforms are fifteen or twenty years old, which means the habits built around them are too. Habits that are entrenched do not give way on their own. Getting the platform live is the easy half — getting the people to adopt it is the challenge. Treat the people layer that way from the first day, and you have a good chance of convincing the team to embrace the changes and technical enhancements that come from upgrading your S/4HANA ERP system.
Connect with an Argano Expert!
Need specialized insights for your business challenges? Facing complex business technology questions? Don't navigate alone. Connect with an Argano subject matter expert who will personally respond within 24 hours.