Stakeholders Management: The Person Everyone Checks With Before They Say Yes
| Informal authority runs quietly underneath every org chart. How to spot it, how to read it, and why formalizing it always backfires. Today, we will continue talking about the important role of managing stakeholders in your project. So, you looked at the project, you found the quiet stakeholder, and you started the conversations early. Good. That already puts you ahead of most. And then one day, a decision everyone had agreed on quietly comes undone. Nobody on your list changed their mind. The sign-offs are all still there. But something shifted, and you can't quite trace where. Let me tell you where... There was a person you never talked to. Their name isn't on the RACI chart. They don't sit on your steering committee. On paper, they have nothing to do with your project. And yet, somehow, three of the people who do matter all checked with this person before they committed to anything. That is informal authority. And it runs almost every organization quietly, underneath the official one. You know this person. Maybe it's a senior engineer with no management title, but fifteen years in the building and a memory of why the last three versions of your idea failed. Maybe it's the person whose desk everyone stops at on the way to the coffee machine. Maybe it's someone in a completely different team whose blessing, for reasons nobody ever wrote down, simply matters. They're not on any chart. But when they think something is a bad idea, people listen. Not because they have to. Because they trust this person more than they trust the org chart. The org chart shows you who reports to whom. It tells you almost nothing about who trusts whom. And projects don't move on reporting lines. They move on trust lines. You can have every formal approval in place and still watch a project stall for weeks, for reasons nobody can name, because one person who was never in the room had a quiet doubt. So how do you find them? First of all... You watch! Observation is also a Project Management skill. A quite of skill that does not appear in certification programs. You notice who people glance at before they answer a hard question. You listen for the phrase "let me just check with someone first," and you pay attention to who that someone is. You notice whose name keeps coming up when you weren't the one who brought it up. Informal authority is rarely loud. It doesn't need to be. The influence does the talking. There's a simple test I use. When I float an early idea, I watch the room for a half-second pause before people respond. That pause usually means someone is mentally checking the idea against what a third person, who isn't there, would think. Find out who that third person is. That's your real stakeholder. Now, here is the part most people get wrong. Once they finally spot this person, they try to make it official. They put them on the stakeholder map. They give them a role, a title in the project, and a recurring meeting. And it backfires every time. Because the moment you formalize informal authority, you kill the thing that made it work. Their power was never positional. It was relational. The second you turn it into a box on a chart, it stops being trust and starts being process. And process is exactly what these people are trusted to see through. So you do the opposite. You bring them in the way their influence already flows. Quietly. Early. Informally. A coffee, not a calendar invite. A "I'd really value your read on this before I take it any further." You're not asking for a sign-off. You're asking for an honest take, and you're signaling something underneath the question. That you see how things actually work here. That you know the real map isn't the one HR drew. That signal matters more than the input itself. People with informal authority earned it partly by paying attention to who respects the real dynamics and who only respects the formal ones. When you come to them with genuine curiosity instead of a checklist, you're telling them which kind of project manager you are. And that tends to come back to you later, in a meeting you're not even in, when your idea comes up and the quiet doubt doesn't. There's a risk here, and it's worth naming. Informal authority can be a wonderful thing or a quietly destructive one. The same person who can carry your project can also sink it from outside the room, with no accountability, because none of this is written down anywhere. Your job is not to neutralize them. It's to understand them. To know what they care about, what they've seen go wrong before, and what would make them an ally instead of a silent veto. Most of the time, they want the same thing the quiet stakeholder wanted in the first place. To be seen. To be asked. To not find out about something important after everyone else already has. The truth is, every project runs on two maps. There's the official one, with its roles and approvals and reporting lines. And there's the real one, the web of trust and history and quiet influence that actually decides what happens. The first map is handed to you. The second one, you have to draw yourself, slowly, by paying attention. Most project managers only ever read the first map. The good ones learn to read in the second. So before your next decision, ask yourself one quiet question. Who is the person everyone checks with before they say yes, and have you ever actually talked to them? |
Posted on: July 27, 2026 01:00 AM
| Permalink |
Comments (2)
Stakeholders Management: The Storm Is Never the Problem
| By the time a stakeholder issue surfaces, you are already managing fallout. What project managers miss is the silence that builds long before anyone speaks up. A colleague came to me frustrated after a project review. "I don't understand," she said. "Everything was on track. The team delivered. And now, at the very end, this stakeholder appears and questions everything." I asked her when she had last talked to that person. Not updated. Talked. She thought for a moment. "In the kickoff meeting, I think." That was four months earlier... The thing is, the problem didn't start at the review. It started at month two, when an assumption was made that nobody checked. And at month three, when a risk came up that nobody mentioned because it didn't feel urgent yet. And at month four, when the stakeholder sent a short reply to an update email and everyone read it as agreement. It wasn't agreement. It was silence. And silence, in a project, almost never means what we think it means. The storm is never the problem. The silence before it is. Most stakeholder issues don't announce themselves. Actually, they grow quietly, in the space between conversations that should have happened and didn't. By the time something surfaces, you're not leading anymore. You're managing the fallout. And there's a big difference between those two things. The fix is less complicated than it sounds. But it requires doing something that feels almost too simple to matter. Show up early. Before you have anything important to say. That early presence does something that no status report can do. It builds trust. And trust, in a project, works a lot like a battery. You don't charge it when the power is out. You charge it in advance, in small moments that feel almost irrelevant at the time. Every check-in that wasn't strictly necessary. Every question asked before there was even a problem to solve. Every "just wanted to hear how this looks from your side" sent on a Tuesday with no agenda attached. Those are deposits. They feel like nothing. But they accumulate. And when the hard moment comes, and it always comes, you find the battery isn't empty. Here is what I've learned about what stakeholders actually want. Not from a book. From watching projects go right and wrong for a long time. They want to feel heard. Not informed. Heard. There's a difference. An update tells them what's happening. A conversation makes them feel like they're part of it. They want to be included, even when they're not the one deciding. And they want to feel safe. Safe from being surprised. Safe from being blamed for something they didn't fully shape. Safe from waking up in month four and realizing the project went somewhere nobody told them it was going. You can't fix all of that with a stakeholder map. You fix it with a few honest conversations, started early enough that there's nothing at stake yet. Ask how the project connects to what they're already carrying. Ask what success looks like from their side, not the project plan's side. Those are different things more often than you'd expect. Ask what worries them most. Ask what usually goes wrong in projects like this one. That last question is underrated. Most stakeholders have seen this kind of project before. They have pattern recognition you don't have yet. And when you ask, you get something more useful than their approval. You get their real experience. You don't do this all at once. You make it part of the rhythm. And then, the hard part: you actually listen to what they say. The mistakes that cost the most are embarrassingly simple. Waiting too long to engage because you want something real to show first. Sending everyone the same update and calling it communication. Going quiet about a risk because you're not ready to explain it. Getting defensive when someone pushes back instead of getting curious. Forgetting the quiet stakeholder, the one who never replies much, who turns out to have the most influence in the room. None of those are process failures. They're attention failures. And that is actually human, not based on certifications or project management qualifications. Which means they're fixable, starting today, without a new framework. Pick one stakeholder. The quiet one. The one you haven't really spoken to since the kickoff. Send a short message. Something close to this: "I'd love to hear how this project looks from where you sit. What am I missing?" One sentence. It costs almost nothing. And it can shift the entire dynamic of a project. Projects run on schedules and budgets. But they move forward on relationships. So who is the one stakeholder you haven't really talked to yet? |
Posted on: July 20, 2026 01:00 AM
| Permalink |
Comments (11)
The Plan Will Not Save Your First Project
| A beginner's guide on what actually keeps a first project alive when the schedule meets reality and starts to fall apart. A new project just landed in your hands. It's your first one! The expectations feel heavy. Your experience feels thin. And somewhere in the back of your head, a small voice keeps asking the same thing. What if I fail? Here is something worth knowing before that voice gets louder. A project does not live or die by how perfect your plan looks on day one. It lives or dies by how you move when the plan stops matching reality, which sometimes can happen... quite fast! That is the whole game. Think of it like driving with a GPS through a city under construction. The route on the screen is perfect. The road in front of you is closed. You can keep staring at the screen, or you can look up and find the next turn together with the people in the car. So if you are standing at the door of your first project, here is a compass to carry in. Not theory. Survival. See the mission before you see the tasksForget the deliverables for a minute. Forget the templates and the task list. Ask the uncomfortable question first. Why does this project exist at all? Strip it down to the real change your team is supposed to create. If you cannot say it in two sentences, you do not understand it yet. And if you do not understand it, your team never will. Map the people, not the boxesThe hard parts almost never live in the project plan chart. They live in people. Who actually cares about this one? Who might quietly resist it? Who knows the thing you do not? Draw that map early, before anything goes wrong. On unfamiliar ground, understanding your people is the closest thing to a compass you get. Keep the plan human-sizedYour first instinct will be to build the perfect roadmap. Resist it. Complexity buries you before the work even starts. Think sticky notes on a wall, not a 200-slide deck nobody opens twice. Big steps. The few checkpoints that matter. The names attached to each one. Communicate until it feels like too muchThis is where most new project managers slip. Silence kills projects faster than a bad schedule ever will. PMI research has pointed at broken communication as one of the main reasons projects fall apart. In one of its most cited studies, ineffective communication was the primary contributor to project failure about a third of the time. So your job is not only to track progress. It is to keep everyone aligned, every week, every step. If you feel like you are over-communicating, you are probably doing it about right. Close it like it matteredA project does not end when the last task turns green. It ends when the team feels they finished something together. Celebrate it. Write down the lessons while they are fresh. Thank people by name. Skip this part, and the team forgets the project. So will you. Now step back for a second, because those five moves matter far more than the technicalities you collect in certifications. The soft stuff is the hard stuffPatrick Lencioni, in The Five Dysfunctions of a Team, puts trust at the bottom of everything. No plan builds trust for you. Only real conversations do. Daniel Pink, in Drive, says people move for autonomy, mastery, and purpose, not for pressure. Explain the mission clearly and you hand your team purpose. Pull them into the decisions and you hand them autonomy. Notice their growth out loud and you feed their mastery. The old Standish CHAOS Report says the same from another angle. Projects fail less from missing process and more from missing user involvement and fuzzy requirements. Which means the soft side of this job turns out to be the hard side. That is the part the training rarely tells you. And no, agile is not only for the software crowd. Jeff Sutherland, in Scrum, makes one simple point. Small visible wins, delivered fast, build the momentum that carries everything else. That is exactly what a first project needs. Proof, for the team and for the person leading it, that the thing is actually moving. Maybe the real shift is this in the end! Stop treating project management as a control panel where you push every button yourself. Start treating it as the quiet work of connecting people around something that matters, then making the progress visible, one step at a time. So here is a small thing to do right now: Write the real mission of your project in two sentences. Write it so plainly that someone outside your industry would understand it instantly. That sentence is your North Star. Without it, you are steering in the dark. One more thing. That knot in your stomach? Good... Keep it. That knot does not mean you are failing. It means you are paying attention and that you are already leading. So what does your first project actually need from you this week? |
Posted on: July 15, 2026 01:00 AM
| Permalink |
Comments (2)
How Project Leaders Engineer a Culture for Delivery
| When a project underperforms, the instinct is to examine the process. Tighten the schedule. Sharpen the risk log. Add a status meeting. And yet the most persistent delivery problems resist that kind of fix, because the process was rarely the root cause. What separates high-performing teams from struggling ones is usually not the quality of their plans. It is the unwritten rules that govern how they communicate, respond to failure, and protect the time for serious work. Call it culture: the operating system beneath the visible machinery of project management. When culture is left undefined, teams under pressure do not drift toward openness. They drift toward self-protection. Hoarding information. Avoiding difficult conversations. Absorbing delays in silence. These patterns are predictable, and they destroy delivery performance long before any status report reflects the damage. Culture can be designed. A project leader who understands this stops compensating for a broken environment through harder scheduling and starts engineering the conditions that make consistent delivery possible. Three of those conditions are well supported by management research:
Why Errors Stay Hidden Until It Is Too LateHarvard researcher Amy Edmondson defined psychological safety as the shared belief that a team environment is safe for interpersonal risk taking. In practice, it means a person can admit a mistake, ask a basic question, or challenge a decision without fear of humiliation. When that belief is absent, the consequences are structural. Teams learn that concealment is safer than disclosure. Errors go underground. They surface later, compounded, when the cost of correction has multiplied. The response to failure teaches the team what honesty costs. A leader who shifts that response from finding fault to finding systemic cause changes the calculation. The blameless post-mortem, formalized in aviation and high-reliability engineering, asks not who failed but what process or safeguard allowed the failure to occur. Each review closes with one documented fix owned by one person, converting a single error into a permanent improvement. A related practice addresses a quieter risk. Silent assumptions, where one team member infers the status of another's work rather than confirming it, are among the most common causes of rework. Replacing inference with explicit confirmation requires no structural change. It requires a leader who models and enforces the behavior consistently. The Two Things Most Teams Treat as Flexible That Are NotTime and decision-making authority are the two resources project leaders most often allow to erode. Research on task switching shows that interruptions cost more than their duration. Regaining deep focus after a context switch takes significant additional time, and that accumulated loss never appears in a project plan. A culture that treats the team as continuously available pays that cost repeatedly, in the form of delays and quality degradation that look like execution problems but are environmental ones. The countermeasure is structural. Recurring blocks of uninterrupted time, negotiated with functional managers and defended by the leader, give the team the cognitive conditions that complex work requires. The leader's specific role during those blocks is to absorb outside interference, not to participate in it. On decisions: teams slow down when choices accumulate at the top. A practical discipline is to require that no problem reaches the leader without a proposed solution attached. The team member brings the question, the context, and a recommendation. The leader decides and moves on. Over time, this builds a team that defaults to problem-solving rather than upward deference. Accountability is an agreement made before work begins, not a judgment assigned after something goes wrong. Making weekly commitments visible, which work packages are due and who owns each one, creates peer accountability that outlasts any private commitment to a manager. Escalation follows the same logic. A team that can hand an unresolvable blockage upward without penalty becomes an early warning system. A team that cannot becomes a passive absorber of delay. Culture is often framed as the soft side of project management. The framing is misleading. Culture is the mechanism that determines whether good planning converts into actual results. It is not background. It is infrastructure. For an early-career project manager, the shift is practical. When a team underperforms, resist the reflex to add process. Ask instead what conditions the team is working in: whether they can speak up without risk, whether they have time for deep work, and whether ownership is clear before problems surface. Those conditions are buildable. Building them is the job. |
Posted on: July 13, 2026 01:00 AM
| Permalink |
Comments (3)
How to Measure the Value You Create as Project Manager When No Spreadsheet Can
| "What are we actually paying this person for?" Sometimes... It is a fair question. Most people, unfortunately, use it badly. Once a year, I sit with a version of it myself. Not the salary, not the title, but something harder to put on a payslip. What difference did I make, and how would things have gone without me? I mentioned in another article that I use a note-taking system to highlight a few of the contributions I made to the projects I was working on, and try to be very specific about the things that are not easily showcased in a "project overview". Because, of course, many of those will not be quite clear. For example, if I took the lead to avoid a big project risk or remove an impediment, or the way I negotiated a scope trade-off with a stakeholder, etc However, there was a point in my career when I learned a term from economists that supported this whole thinking about "project management ROI": Utility. Utility is one of those words that sounds academic until it describes your normal Tuesday morning. In economics, utility is the satisfaction or benefit you get from something. It is personal, it shifts with the moment, and it almost never matches the price tag. Picture the first coffee of the day. You are tired, foggy, three emails behind. That three-dollar cup feels close to priceless. Now picture the third cup. Same coffee, same price, far less benefit. Economists call this diminishing marginal utility, the idea that each extra unit of the same thing gives you a little less than the one before. The lesson hiding in there is simple. Value is not a fixed property of the thing. It depends on what it does for someone, at a specific moment, under specific pressure. A project manager is worth thinking about the same way. Some of what we deliver is easy to count. A project kept on time and on budget. Scope creep stopped before it quietly doubled the work. A vendor rate renegotiated. These land in numbers a CFO recognizes, and the numbers can be large. The data backs the instinct. PMI's research, through the Salary Survey and the Pulse of the Profession, keeps pointing the same way: organizations lean harder on project management precisely because complex work fails expensively without it. I think about one project that taught me this the hard way. After enough digging and a few honest conversations, the math became clear. Finishing it would burn more than a million dollars on something that was not going to work. My recommendation was to cancel. Stop it. Not a popular thing to say in a room that had already spent and promised. But it helped executives make a decision, freed the money, the people, and the calendar for work that had a real chance. Here is where the spreadsheet runs out of room... A team that trusts each other solves problems faster. A risk caught early never becomes the crisis everyone remembers. A confused goal made clear on a Tuesday saves a hundred small wrong turns later. None of that lands cleanly in a budget line. All of it changes how a project ends. Not only what we deliver, but how. The same result can leave a team burned out and quietly job-hunting, or steady and willing to do it again. How we deliver shapes whether anyone wants to work with us a second time. That part rarely makes the performance review. It is often the most durable value we create. How to Catch Your Own Impact Before You Forget ItThe trouble with utility is that it is forgettable, especially your own. By December, you cannot remember the March decision that saved the project delivery. So I keep a running note I have kept for years, sometimes a plain file where I drop the moments that mattered as they happen. If you want to track your own, a few honest categories help:
They are evidence, the kind you want in your hand during a performance conversation, when good work rarely speaks for itself. The Better QuestionMost organizations ask what a project manager costs. Far fewer ask the question that matters more: how much worse off would we be without one? Measured well, a good project manager tends to create more value than they ever take home. That is not a flattering story we tell ourselves. It is the arithmetic of utility, applied to a role that spends most of its time preventing the disasters nobody ends up seeing. So maybe the year-end question is worth stealing. Not what you were paid, but this: If your seat had been empty all year, what would have gone wrong that nobody would have thought to blame on the absence? |
Posted on: July 08, 2026 01:00 AM
| Permalink |
Comments (2)
