How do I keep operations happy when a project causes disruption?

I spent the first few years of my career thinking that a perfectly balanced Gantt chart was the ultimate shield against project failure. If the dependencies were linked correctly and the critical path was optimised, surely, the project would succeed. Then, reality hit. I learned the hard way that you can have the most beautiful, logic-checked schedule in Microsoft Project, but if the Operations Lead is gritting their teeth every time you walk into the room, your project is already effectively dead in the water.

After twelve years of navigating the trenches of UK organisations, I’ve come to realise that project management isn't about managing tasks; it’s about managing the friction between change and business-as-usual (BAU). If you are looking to minimise disruption and keep your operations stakeholder on side, you need to stop acting like a task-master and start acting like a diplomat.

The Soft Skills Illusion: Why EQ beats IQ every time

There is a dangerous myth in our industry that says if you provide a watertight business case and a transparent budget, operations will naturally fall in line. They won't. Operations teams are measured on stability, throughput, and consistency. Your project is, by definition, the enemy of those three things.

I keep a running notebook of 'things people said in corridor chats'—those throwaway comments like, “Well, if it goes wrong, at least it’s not my department doing the rework.” Those are your risks. They are the weak signals of future resistance. If you ignore them, you aren't managing a project; you are waiting for an explosion.

Soft skills are the real driver of project outcomes. You need to be able to sit in a room with someone who is terrified that your deployment will break their monthly KPIs and acknowledge that fear. Don't dismiss it. Validate it. When you make them feel heard, you move from being an adversary to a partner.

Communication: Tailored to the reader, not the writer

I have a personal rule: I never send meeting notes as a chronological list of 'who said what'. Nobody has time to read a transcript of a meeting they were already attending. When I write my summary notes, I rewrite them for the recipient. If the Ops Lead is reading, the notes should be structured around:

• Impact: What changes for their team today?
• Mitigation: What are we doing to protect their BAU targets?
• Action: What is the one thing they need to decide or approve?

Stop sending status updates that say nothing. If your update contains phrases like “progressing as expected” or “on track”, delete it and start again. If the project causes disruption, say so. Own it. Transparency builds trust; obfuscation builds resentment.

The Art of Deployment Planning

Effective deployment planning isn't just about technical cut-overs. It’s about socialising the pain. You need to map out the journey of the project from the perspective of the people who actually do the work.

Comparison: The "Project-First" vs. The "Ops-Centric" Approach

Feature The "Project-First" Way The "Ops-Centric" Way Gantt Charts Fixed dates forced on teams. Co-authored dates based on peak work cycles. Budgets Focused on 'keeping costs down'. Includes buffer for overtime/temp staff for Ops. Bad News Hidden until the last minute. Shared immediately to allow for contingency. Stakeholder Plan Copy-pasted from a template. Tailored to individual motivations and fears.

Why you should never hide the bad news

One of the biggest triggers for my 'project coach' rage is people hiding bad news until the last possible second. In an operational environment, this is a cardinal sin. If you know that your software update is going to increase the call handling time for the customer service team by 20% for the first week, tell them. Tell them three weeks ago. Tell them the plan to get it back down to baseline.

If you wait until 24 hours before the go-live to mention the "minor dip in efficiency," you lose your credibility. And once your credibility is gone, you can have the most expensive, well-resourced project in the world, and it will still be sabotaged by an operations team that doesn't trust your judgment.

Writing for Non-Specialists

Complexity is the enemy of buy-in. If your documentation is filled with jargon and high-level project management speak, you are creating a barrier. When you are writing for operations, use clear, plain English. Avoid the "project dialect".

1. Avoid technical jargon: Instead of "We are migrating the legacy database to a cloud-native architecture," say "We are moving the customer data to a faster, more secure system."
2. Focus on outcomes: What is the tangible benefit for the staff on the ground?
3. Keep it short: If you can’t say it in three bullet points, you’ve lost their attention.

The Checklist for Minimising Disruption

If you want to keep operations happy while moving the needle, start using this checklist as your primary project tool—not just your Gantt chart.

1. Early-Stage Empathy Mapping

Sit down with the operational leads before you finalise the project plan. Ask them: "When are your busy seasons?" "What is the one thing you are most worried about us breaking?" "What does success look like for your team?" Write these down.

2. The "Buffer" Budget

If you know a transition is going to be painful, advocate for a budget that accounts for it. If you need to pay for extra staff to handle the teething problems, build that into your project budget. Don't try to deliver the project "on the cheap" at the expense of operational morale.

3. Active Listening for Weak Signals

Pay attention to the corridor chatter. If you hear whispers of “I don't think this will work” or “Management hasn't thought about X,” stop and investigate. These are your red flags. Bring them into the light in your steering meetings. The sooner you discuss them, the less likely they are to become terminal risks.

4. Iterative Transparency

Don't wait for a skillsyouneed.com monthly report to share news. If something goes off-track, walk over to the Ops Lead's desk and explain the situation. Let them see the sweat on your brow. It sounds counter-intuitive, but being human and vulnerable about project struggles creates a level of psychological safety that a polished presentation deck never will.

Final Thoughts: The Project Manager as a Servant Leader

Ultimately, your role is not to impose a project upon an organisation. Your role is to guide an organisation through a transition that they should be better off for having experienced. If you can bridge the gap between the project world of "what's new" and the operational world of "what's now," you won't just deliver a successful project—you will become a partner they actually want to work with.

Remember: nobody reports to you. You are relying on influence. And there is no greater influence than being the person who understands the operational impact of your work and proactively plans to protect the people who make the business run.

So, clear your calendar. Go have those conversations. Write better notes. And please, for the love of everything, stop using copy-paste stakeholder plans. Your operations teams deserve better.