When Departments Clash: Navigating Internal Politics During Software Implementations

There's a conversation I've had more times than I can count. It usually happens around week three of an implementation, when the configuration is taking shape and the reality of change starts to set in. It goes something like this:

"I understand the GM wants this new system, but our department has been doing it this way for twelve years and it works perfectly fine for us."

The words change. The sentiment doesn't. And if you're a project manager who doesn't know how to handle that moment, it can derail an entire implementation — regardless of how good the software is.

The Real Challenge of Implementations

When most people think about software implementations, they imagine technical complexity. Servers, data, integrations, configurations. And those things are genuinely challenging. But after six years of delivering CRM and enterprise software implementations for private clubs and resort properties, I can tell you with confidence: the technology is rarely what makes or breaks a project.

What makes or breaks it is people. Specifically, it's the tension between how things have always been done and how the new system requires them to be done. And nowhere is that tension more visible — or more politically charged — than in the conflict between departments.

Understanding Why Departments Resist

Before you can navigate departmental conflict, you have to understand where it comes from. In my experience, resistance rarely comes from laziness or stubbornness (though it can look that way from the outside). It usually comes from one of three places:

1. Loss of autonomy

Departments that have been running their own systems — even imperfect ones — have a sense of ownership over their processes. An integrated CRM often means that ownership is reduced. The F&B manager who used to approve charges manually in their own system might now see those charges flowing automatically. That can feel like a loss of control, even if the new way is objectively better.

2. Fear of exposure

An integrated system creates transparency that didn't previously exist. When billing flows from POS terminals directly to member accounts and into the accounting system, errors become visible in a way they weren't before. Some departments — not necessarily through any wrongdoing — are quietly aware that their processes aren't as clean as they'd like. A new system feels threatening.

3. Genuine workflow disruption

Sometimes the resistance is legitimate. A new system might handle a specific process differently from how a department needs it to work. If the software doesn't accommodate a nuance that's actually important to that team, their pushback is valid — and you need to hear it, not dismiss it.

The GM Vision vs. The Ground Reality

In almost every club implementation I've managed, the initiative originated at the top. The General Manager — or the board — saw the value of an integrated, automated system and made the decision to implement. That's entirely appropriate. But it creates a specific challenge: the people who have to use the system every day often didn't have a seat at the table when the decision was made.

This is the most common source of inter-departmental conflict I encounter. The GM has a clear vision — streamlined billing, consolidated reporting, member-facing improvements. The department heads have an equally clear concern — their team is already stretched, this is going to create more work, and nobody asked them what they thought.

The PM's job is to bridge that gap. Not to choose a side.

What I Actually Do About It

Start with listening, not presenting

Before I show any department a single screen of the new system, I sit with them and ask questions. What does your current process look like? What works well? What frustrates you? What would make your day easier? I take notes. I ask follow-up questions. I don't rush to solutions.

This does two things. First, it gives me genuinely useful information that improves the implementation. Second — and this is the part most people underestimate — it makes the department head feel heard. When someone feels heard, they're far more likely to engage constructively with what comes next.

Translate the GM's vision into departmental benefits

The GM's goals and the department's goals are almost always compatible — they just speak different languages. The GM talks about consolidated reporting and operational efficiency. The F&B manager cares about whether the end-of-night process will be faster. The membership team cares about whether they'll have to answer more calls from confused members.

My job is to translate. To show each department not just what the new system does, but specifically how it makes their day better. That's not spin — it's communication.

Get small wins early

Resistance drops dramatically when people experience something working better. I deliberately sequence the implementation to deliver visible improvements to hesitant departments early. If the kitchen team was frustrated by the old ticket printing system, and the new POS is visibly faster in week one, they become advocates rather than critics.

Escalate carefully, not often

Sometimes a department head is simply not going to cooperate, and you need to involve the GM to move forward. That's a legitimate tool. But it should be the last resort, not the first. Escalating too quickly destroys the trust you've built, makes the department head dig in harder, and puts the GM in an uncomfortable position with their own team. Use it sparingly, and always frame it as seeking alignment — not reporting a problem.

The Outcome That Matters

The goal of a software implementation isn't a successful go-live. Go-live is just the beginning. The goal is an organisation that genuinely uses the system, gets value from it, and looks back six months later and can't imagine going back.

That outcome doesn't come from the software. It comes from the people who use it. And the people who use it best are the ones who felt respected during the process of change — who were listened to, who had their concerns addressed, and who were given the time and support to adapt.

Managing that is, in my view, the real work of implementation project management. The technical side, as hard as it is, is the easier part.