What Separates a Good PM from a Great PM? (Spoiler: It’s Not the Software)

2026-04-15T19:17:35Z

Molly-fisher97: Created page with "<html><p> I spent the first few years of my career convinced that if my <strong> Gantt charts</strong> were perfectly colour-coded and my <strong> budgets</strong> were balanced to the penny, the project would succeed. I treated project management like a game of Tetris—if everything clicked into its designated slot, we were golden. </p> <p> Then, reality hit. I watched a project with a flawless schedule collapse because the Lead Architect felt ignored during a design r..."

<html><p> I spent the first few years of my career convinced that if my <strong> Gantt charts</strong> were perfectly colour-coded and my <strong> budgets</strong> were balanced to the penny, the project would succeed. I treated project management like a game of Tetris—if everything clicked into its designated slot, we were golden. </p> <p> Then, reality hit. I watched a project with a flawless schedule collapse because the Lead Architect felt ignored during a design review. I watched another sail through its financial audit while the team was burning out in silence, eventually leading to a mass exodus of talent. </p> <p> After 12 years in the trenches of UK organisations, I’ve learned the hard way: your tools are merely the scaffolding. The actual building—the stuff that determines whether you deliver value or just produce a nice report—is built on soft skills. Specifically, it’s built on how you handle the humans in the room.</p> <h2> 1. The Art of "Translational" Communication</h2> <p> One of my biggest pet peeves is the standard, copy-paste stakeholder update. You know the one: "Green status, tracking to plan, RAG rating green." It tells the reader absolutely nothing. </p> <p> A great Project Manager understands that <strong> communication</strong> is not about what *you* need to say; it’s about what the *other person* needs to hear. When I write meeting notes, I rewrite them for the reader. I don't document the hours of debate; I document the decisions, the implications, and the "what happens next."</p> <p> Consider this framework for your stakeholder engagement:</p> Audience What they care about How to communicate Executive Sponsors ROI, risks, and strategic alignment High-level impact, binary choices, financial health. Technical Leads Dependencies, technical debt, blockers Granular detail, timeline shifts, resource availability. End Users "What does this change for me?" Benefits-led, simple language, empathy for the transition. <h2> 2. Listening for the "Corridor Whispers"</h2> <p> Early on, I started a notebook—the "Corridor Chat" ledger. It wasn't formal documentation; it was a place to record the things people said when they thought the official meeting was over. </p> <p> "I’m not sure the marketing team is actually on board with this migration," or "The testing environment is always a bit flaky, but we’re used to it."</p><p> <img src="https://images.pexels.com/photos/5324974/pexels-photo-5324974.jpeg?auto=compress&cs=tinysrgb&h=650&w=940" style="max-width:500px;height:auto;" ></img></p> <p> These are "weak signals." A good PM hears them but brushes them off because they aren't on the risk register. A <strong> great</strong> PM leans into them. They know that if someone is saying it in the corridor, it is a latent risk that will manifest as a disaster in six months if left unaddressed. Active listening requires you to set aside your agenda and listen for the gaps in what *isn't* being said in the formal PMO meetings.</p><p> <img src="https://images.pexels.com/photos/163064/play-stone-network-networked-interactive-163064.jpeg?auto=compress&cs=tinysrgb&h=650&w=940" style="max-width:500px;height:auto;" ></img></p> <h2> 3. Negotiation Skills: Managing Without Authority</h2> <p> In most UK organisations, you don’t have a line management relationship with the people doing the work. You don't have "power" in the traditional sense. You are not their boss. </p> <p> If you rely on your job title to get things done, you’ve already lost. Great PMs rely on <strong> negotiation skills</strong>. You are constantly trading: "If I can get the resource approval for your sprint next month, can we bring the UAT date forward by three days?"</p> <p> Negotiation is not about winning; it’s about alignment. It’s the ability to find a path through competing priorities where everyone feels they’ve gained something. It’s about being the person who makes life easier for the engineers and developers, not the person who just adds more admin to their day.</p> <h2> 4. Writing for the Non-Specialist</h2> <p> Stop hiding behind jargon. If you cannot explain the technical blocker in plain English, you don’t understand it well enough. </p> <p> Clear documentation is an act of empathy. When you write a business case or an update, pretend you are writing it for a smart person who is extremely busy and has no idea what your technical acronyms mean. If you use "synergy" or "robust methodology" when a simple sentence will do, you aren't sounding professional; you're just creating barriers to understanding.</p> <h3> The "Five-Year-Old" Rule</h3> <p> I often challenge my project teams: "If we had to explain this project to a five-year-old, how would we describe the goal?" If we can’t, we have a strategic problem. We are lost in the weeds of our Gantt charts and have forgotten the *why*.</p><p> <iframe src="https://www.youtube.com/embed/k3q9z7KxXo0" width="560" height="315" style="border: none;" allowfullscreen="" ></iframe></p> <h2> 5. Why "Bad News" Needs a Home</h2> <p> One of the things that annoys me most is the "Status Update Theatre"—where everyone hides bad news until it’s impossible to ignore. This is usually because the PM has created an environment where bad news is treated as a personal failure rather than a reality of project delivery.</p> <p> Great PMs create safety. They encourage their teams to bring them the "bad news" early. They frame it as: "Thanks for flagging this now; we have options. If we hide it, we have zero options."</p> <ul> <li> <strong> Create a blame-free reporting culture:</strong> Focus on the fix, not the fault.</li> <li> <strong> Be the buffer:</strong> Shield your team from the heat so they can focus on solving the issue.</li> <li> <strong> Be transparent about the trade-offs:</strong> When a budget needs to be adjusted, be the one to lay out the options clearly for the board.</li> </ul> <h2> Conclusion: The Human Element</h2> <p> If you look at the most successful projects in your career, they weren't successful because the software was better. They were successful because the PM acted as the "social glue." They held the team together, managed the egos, translated the complex, and navigated the politics with grace and rigour.</p> <p> Your <strong> Gantt charts</strong> are a map, and your <strong> budgets</strong> are the fuel. But you? You are the driver. If you ignore the people in the vehicle, it doesn't matter how accurate your map is—you’re going to end up in a ditch.</p> <p> Focus on your communication, sharpen your listening, and remember that for every stakeholder you manage, there is a person with their <a href="https://www.skillsyouneed.com/rhubarb/great-project-managers.html">https://www.skillsyouneed.com/rhubarb/great-project-managers.html</a> own pressures, goals, and fears. Start there, and you’ll move from being a "good" PM to a truly transformative one.</p> <p> Are you tired of "Status Update Theatre"? Let’s talk about how to reset your communication strategy in your next project. Leave a comment or reach out for a coffee.</p></html>

Wiki Spirit - User contributions [en]

What Separates a Good PM from a Great PM? (Spoiler: It’s Not the Software)