Blog – Rosana Inacio

The Soft Skills Nobody Warned Me About

June 14, 2026

When I started in project management, I thought success came from mastering schedules, budgets, risks, and processes.

And to be fair, those things matter.

But after years of managing projects, I’ve learned that projects rarely struggle because the schedule wasn’t perfect or because someone forgot a process step.

More often, they struggle because people are not aligned.

Teams have different expectations.

Stakeholders have different priorities.

Important concerns go unspoken.

People assume they are working toward the same goal, only to discover later that everyone had a different understanding of what success looked like.

Early in my career, I thought project management was about managing projects.

Today, I believe it is largely about creating alignment.

That alignment doesn’t happen through schedules or status reports alone.

It happens through communication.

Through listening.

Through difficult conversations.

Through trust.

Through helping people understand not only what needs to be done, but why it matters.

I’ve seen well-structured projects struggle because teams didn’t trust each other.

I’ve seen strong technical solutions fail because stakeholders weren’t aligned.

I’ve seen risks remain hidden because people didn’t feel comfortable speaking up.

None of those problems were caused by a lack of technical knowledge.

They were caused by human dynamics.

Technical skills help us organize the work.

People skills help us move it forward.

The more experience I gain, the more I value empathy, adaptability, emotional intelligence, and active listening. Not because they sound good on a competency model, but because they directly influence our ability to create alignment and lead effectively.

A project manager without technical skills will struggle.

But a project manager without strong people skills may never gain the trust needed to bring people together around a common goal.

Projects are delivered by people, not by schedules.

That is a lesson I wish someone had told me on day one.

What people skill has made the biggest difference in your career?

Rosana Inacio – PM Insight
Why Most Lessons Learned Processes Fail

June 7, 2026

Most project management frameworks include a lessons learned process.

The concept is straightforward. At the end of a project, the team reflects on what went well and what did not. The findings are documented. Recommendations are captured. The organisation learns and improves.

In theory, every project makes the next one better.

In practice, it rarely works that way.

What Usually Happens Instead

Lessons learned sessions get scheduled at project close-out, when teams are already exhausted and mentally moving on to the next priority.

When they do happen, the conversation is often surface-level. People highlight what went well. Critical issues get softened. Nobody wants to assign blame this late in the game.

The output gets documented, usually in a shared drive or a project management tool.

And then nobody reads it.

Six months later, a new project starts. The team repeats the same mistakes. The documentation exists, but it did not influence anything.

This is not a documentation problem.

It is a timing problem.

Why Lessons Learned Fail to Transfer

The PMP framework treats lessons learned as a process output. Something you produce at the end of a phase or project.

But learning does not work that way.

By the time you sit down to formally document what happened, the project is over. The team has dispersed. The context has faded. The moment when that learning could have changed a decision has already passed.

There is also an organisational reality that frameworks do not address directly.

Lessons learned documentation assumes the next team will find it, read it, understand the context behind it, and apply it to a different situation.

That is a lot of steps.

Each one is a point of failure.

Most organisations have a lessons learned library that nobody uses. Not because people are careless, but because the format does not transfer learning effectively.

What Experienced PMs Do Differently

The PMs who actually make retrospective thinking work do not wait for close-out.

They build reflection into how they run the project week to week.

That looks like:

• Brief check-ins during project reviews, not just status updates. What is working? What is slowing us down? What should we do differently?

• Capturing concerns when they arise, not months later when the detail is gone.

• Naming patterns mid-project when there is still time to adjust. If a dependency keeps causing delays, that becomes a conversation now, not a note in a close-out document.

• Sharing observations with stakeholders in real time, rather than saving everything for a retrospective that most of them will not attend.

The goal is not to skip the formal process.

The goal is to make sure real learning happens before the formal process runs.

Because by close-out, the most useful lessons are the ones that have already changed how the project ran.

The Real Question

The real question is not what we learned.

It is when.

Lessons learned only have value if they influence decisions.

A document that sits unread in a repository does not improve the next project.

A conversation that happens mid-sprint, when there is still time to act, might.

The PMP process gives you the structure.

What it cannot give you is the discipline to apply it continuously rather than just at the end.

That discipline is what separates PMs who document lessons from PMs who actually learn from them.

Rosana Inacio – PM Insights
How Much Project Documentation Is Actually Enough?

May 31, 2026
A newer PM asked me recently how much project documentation is actually enough.

It is a simple question.

But most experienced PMs know the answer is rarely simple.

Some organizations create documentation for everything. Status reports, meeting notes, approvals, trackers, templates, governance reviews, decision logs.

Other teams avoid documentation almost entirely because they see it as bureaucracy that slows execution.

Both approaches create problems.

Too little documentation creates confusion.

Teams forget decisions. Priorities shift without alignment. Stakeholders remember conversations differently. New people join projects with no context.

Eventually, the PM spends more time clarifying the past than managing the future.

But too much documentation creates a different kind of failure.

Projects slow down.

Teams spend more time maintaining the process than moving work forward. Meetings become focused on updating artifacts instead of solving problems. Documentation becomes something people produce because the process requires it, not because it creates value.

That is usually the moment when teams start calling PM work “bureaucracy.”

The mistake is assuming documentation itself is the problem.

Usually, the real problem is documentation without purpose.

Good documentation should do one of three things:
- Create clarity,
- Support decisions,
- Or reduce future confusion.
If it is not doing one of those things, it is probably unnecessary.

That does not mean everything needs to be lightweight.

Highly regulated industries, large enterprise programs, external vendors, compliance requirements, and safety-critical environments naturally require stronger controls and traceability.

In those environments, documentation protects the organization.

But not every project needs the same level of structure.

A small internal initiative should not necessarily carry the same process weight as a multi-million-dollar enterprise rollout involving multiple business units and external dependencies.

Strong PMs learn to scale documentation to the level of complexity and risk.

Not to personal preference.

That balance is harder than it sounds.

Because documentation problems usually appear slowly.

Too little documentation creates operational chaos later.

Too much creates delivery friction immediately.

PMs are constantly navigating between those two extremes.

Over time, I started asking a simpler question:

“If someone joins this project three months from now, will they understand what was decided, why it was decided, and what still matters?”

If the answer is yes, the project probably has enough structure.

If the answer is no, something important is missing.

Documentation should support execution.

Not become the work itself.

Rosana Inacio — PM Insights
Risk and Opportunity: Why One Gets Attention, and the Other Doesn’t

May 24, 2026
Most organizations are very good at managing risk.

We identify it, assess it, track it, escalate it, and build mitigation plans around it.

Entire governance structures exist to prevent projects from failing.

Opportunities usually receive a very different response.

“Interesting idea.”
“Maybe next phase.”
“Let’s revisit later.”

And then the project continues exactly as planned.

The imbalance makes sense. A risk ignored can damage delivery. An opportunity ignored usually means value was left unrealized.

One protects the business. The other improves it.

Naturally, organizations prioritize protection.

In highly regulated industries, that is often the correct decision. Healthcare, finance, compliance-heavy environments, and critical infrastructure cannot afford unnecessary risk.

But not every organization operates in that context.

In product and technology environments, missed opportunities can quietly create long-term problems:

A process improvement that never happens.
A design decision that creates avoidable technical debt.
A small enhancement that could have improved adoption or scalability.

Over time, those decisions compound.

The Most Valuable Opportunities Usually Appear Mid-Execution

This is something experienced PMs eventually learn:

The best opportunities often appear after execution has already started.

Not because teams suddenly become more creative, but because they finally have enough context to recognize what was invisible during planning.

A timeline discussion reveals activities that can safely run in parallel.

A technical review uncovers a relatively small change that could eliminate future operational overhead.

A scope discussion reveals additional value with minimal implementation effort.

These moments happen constantly.

What is less common is for organizations to evaluate them properly.

Too often, opportunities are dismissed simply because they were not part of the original plan.

The Other Side PMs Need to Recognize

Pursuing every opportunity is also a mistake.

Evaluating alternatives takes time. Reframing priorities creates disruption. Constantly introducing new ideas can easily become analysis paralysis disguised as strategy.

Good opportunity management is not about generating more ideas.

It is about recognizing the few opportunities where the value clearly outweighs the disruption.

That requires filters:

Effort vs. Impact
Is the improvement meaningful relative to the effort required?

Strategic Fit
Does this align with current organizational priorities?

Timing
Should this happen now, or in a future phase?

Organizational Capacity
Can the team absorb this change without compromising delivery?

Without these filters, opportunity management quickly turns into scope creep with good intentions.

How PMs Should Frame the Conversation

Experienced stakeholders do not want endless possibilities. They want clarity.

A strong opportunity discussion usually sounds like this:

“We identified an opportunity. Here is the value, the trade-off, and the recommendation.”

Then explain:
- What improves
- What it requires
- Why it matters now
- What happens if nothing changes
That is not scope creep.

That is responsible leadership.

A PM’s role is not just protecting the plan. It is helping decision-makers understand meaningful trade-offs while there is still time to act on them.

Final Reflection

Adequate PMs execute the plan.

Strong PMs execute the plan while continuously assessing whether it remains the best.

That does not mean chasing every new idea.

It means maintaining awareness, revisiting assumptions when new information appears, and recognizing when a small adjustment could create disproportionate value.

That balance is difficult.

But over time, it is what separates organizations that simply deliver from organizations that continuously improve while delivering.

Rosana Inacio — PM Insights
When the Deadline Was Never Realistic

May 17, 2026
Every PM has been there.

You walk into a project, and the timeline is already set. Nobody asked whether it was achievable. The date was decided, announced, and now it’s yours to deliver.

The first thing you notice is the gap.

You look at the scope. You look at the team. You look at what’s already been done and what still needs to happen.

And the math doesn’t work.

But the pressure is real. The deadline is real. And everyone around you is acting like if people just work hard enough, somehow everything will come together.

This is where many PMs struggle.

The job is not to magically make the impossible possible. It is not to absorb pressure, transfer it to the team, and hope things somehow work out in the end.

The job is to give people the right information to make the right decisions.

What Real Data Actually Looks Like

That means building a realistic plan. Not a hopeful one.

A plan that shows three things clearly:
- where you’re confident about the timeline and why
- where you’re uncertain and what information could change that
- where you need answers you don’t have yet
When you do that, you’re not complaining. You’re not being difficult. You’re presenting data.

“This is impossible” is an opinion. Anyone can have that opinion.

But a plan that says “if we get design approval by X date and the API team has capacity for Y weeks, we can hit the deadline. If either shifts, here’s where we land instead.” That’s not an opinion. That’s a map. And maps are much harder to ignore than feelings.

Why These Situations Even Exist

What makes this difficult is that unrealistic deadlines are rarely created with bad intentions.

Sometimes there’s customer pressure that’s very real. Sometimes, a market window that won’t stay open. Sometimes, leadership is trying to align multiple moving pieces before all the information exists. Sometimes people are genuinely optimistic based on what they know.

The problem is not ambition.

The problem is that ambition and uncertainty got treated as if they were the same thing.

Two Patterns I’ve Seen

In some organizations, when you bring data forward, something shifts.

They may not like the news. They may push back. But they listen. They ask questions about the assumptions. They adjust the scope. They revisit timelines. They make trade-off decisions as new information appears.

It takes longer than originally planned, but when the product launches, it works.

In other organizations, something different happens.

The risks are known. The concerns are raised. The plan shows the gap clearly. But the project pushes forward anyway because changing the date feels harder politically or organizationally than accepting the risk.

That’s when you start to see a shift in how the work actually gets managed.

What Changes When the Date Doesn’t Move

Risk conversations become careful. Then they become infrequent. Then they stop happening in the open.

People stop flagging problems early because nobody wants to be the person who’s “slowing things down.”

Problems start getting solved in corners instead — small workarounds that compound, shortcuts that don’t get documented, decisions made without full context.

By the time leadership sees the real cost, weeks have already passed.

That’s when you realize the culture has shifted. It’s no longer about solving problems. It’s about protecting the date.

And that’s usually when quality starts to suffer. Not because anyone wanted it to. But because the incentives changed.

When You Can’t Control the Outcome

Sometimes the deadline stays. The scope stays. The pressure stays. And despite everything, the project moves forward.

In those situations, your role does change. You may not be able to control the outcome anymore, but you can control something just as important: how you show up as a professional.

Document what you recommended. Not defensively. Not building a case.

Document it clearly:
- What you recommended
- When you recommended it
- What information did you base it on
This matters for a reason that has nothing to do with protecting yourself.

It matters because it’s a record of what was knowable at the time.

If the risk materializes, leadership sees it coming from a mile away. If it doesn’t, you understand why your assumption was wrong. Either way, you learn.

Speak up when it matters, even when the conversation is uncomfortable. Especially then.

Even when you suspect the message won’t be well received.

People remember who told them the truth when it mattered, long after they’ve forgotten the deadline.

Protect the team.

Your job isn’t to sacrifice them to protect a date. It’s to keep them informed about what’s actually happening and why, so they can make decisions about their own work and their own careers.

The Hardest Lesson

One of the hardest things you learn in project management is that not every environment can be fixed through better planning or harder work alone.

Sometimes you do everything right. You bring data. You communicate clearly. You build the right plan. You identify the risks.

And the organization still chooses the deadline over reality.

That’s not a failure of planning. That’s an organizational choice.

When that happens, your job isn’t to change the outcome.

Your job is to be the person who saw clearly and said it clearly. The person who protected the team. The person who kept their integrity when it would have been easier not to.

Those things stay with you long after the deadline is forgotten.

They’re what build your reputation, not just in one organization, but across your whole career.

Your integrity is the one thing that’s entirely yours to control.

Rosana Inacio — PM Insights
Keep Up or Fall Behind: AI for Project Managers

May 10, 2026

A few weeks ago, my company approved Claude for use across our teams.

I was skeptical at first. I had been using another AI tool for over a year. It worked. It was fast. I knew how to use it. Why change?

But I was curious, so I decided to explore.

What I found surprised me.

My Process

Here’s how I work. A product manager gives me a scope. I take that scope and feed it into an AI tool along with everything I know about the project, team size, sprint velocity, sprint length, timeline, constraints, dependencies, everything.

Then I ask for a complete project plan. I need a work breakdown structure, Jira tickets, an MS Project timeline, risk assessment, stakeholder management strategy, all of it.

The AI produces a draft. I review it with my team. They give feedback. I adjust. Then it goes into the official systems.

I do not create these from scratch myself. But I also do not take AI output and run with it. I validate everything with the people who will actually do the work.

What My Previous Tool Did

I provided the scope and all the context. It was executed immediately. No questions. Straight to the output.

It produced everything I asked for: project summary, WBS, Jira tickets, MS Project plan, risk register, stakeholder plan. But it gave me one piece at a time. Separate outputs that I had to compile, organize, and structure into something coherent.

Then came the rework. Review. Gap analysis. Refinement. Adjustments. More questions. More iterations.

It was still faster than doing everything manually, but it required significant effort before I had something solid enough to bring to the team.

What Claude Did

I gave Claude the exact same scope, context, and request.

But before producing anything, it asked questions.

Is the team experienced with this type of work? Is the sprint length fixed or flexible? Have you accounted for dependencies? What is your risk tolerance?

These were not obstacles. They were clarifications I should have thought through anyway. They highlighted gaps I might have missed.

Then it produced everything, not one item at a time, but one organized Excel file with multiple tabs. Project summary. WBS. Jira tickets with detailed descriptions. MS Project plan with predecessors and dependencies already built in. Risk assessment. Stakeholder strategy.

Everything is organized in one place.

I honestly did not expect it to be this complete on the first pass.

Why This Matters

Both tools helped me move faster than doing everything manually. That’s table stakes now.

The real difference was the rework. With my previous tool, I spent multiple rounds reviewing, restructuring, refining, and validating before I had something usable. With Claude, I started much closer to a solid final product.

That’s not just speed. That’s accuracy the first time.

But Here’s the Important Part

The tool I’m using today may not be the best one six months from now.

AI is moving fast. What leads today may be challenged tomorrow. New capabilities are emerging constantly.

I’m not saying stick with Claude forever. I’m saying stay curious.

Don’t assume the tool you already know is still the best option. Keep exploring. Try new things. Test them against real work. See what genuinely improves the way you deliver projects.

And honestly, that makes me excited for what comes next.

I’d also be curious to hear what AI tools other PMs are experimenting with right now.

Rosana Inacio — PM Insights
Consistency Isn’t About Control. It’s About Trust.

May 3, 2026

When multiple people are doing similar work in the same organization, consistency is often treated like a nice-to-have. A best practice. Something for a process improvement initiative.

But it’s not.

Consistency is how you make a team functional.

The Cost of Everyone Doing It Their Way

When people work independently, they develop their own approaches. Their own templates. Their own ways of communicating, planning, and deciding. This feels natural. People trust what has worked for them before.

But when those approaches sit next to each other in the same organization, they create noise.

Stakeholders see different formats. Different language. Different timelines for the same type of work. They can’t compare. They can’t predict. So they stop trusting the system and start managing individual people instead.

The work gets harder, not easier.

What Consistency Actually Does

Consistency doesn’t mean everyone thinks the same way. It means everyone speaks the same language about the work.

When a stakeholder sees a project dashboard, they understand it instantly because they’ve seen that format before. When a decision gets documented, it’s in a place they know to look. When a status update arrives, it has the structure they expect.

That predictability matters more than you’d think.

It reduces friction. It builds trust. It makes the work visible in a way individual brilliance never will.

The Resistance Is Real

Experienced people often push back on consistency. Not because they’re difficult. Because they’ve built methods that work for them. Asking them to standardize feels like asking them to give up what they know.

But consistency isn’t about who’s right. It’s about making the whole system work better.

A single PM with a perfect process is still just one person. A group of PMs speaking the same language, that’s an organization that stakeholders can actually trust.

Where to Start

Consistency doesn’t mean rigid. It means intentional.

Pick the things that stakeholders actually see. The formats that matter. The decisions that need to be tracked. The communication that moves the project forward.

Not everything needs to be the same. Just the things that, when they’re different, create confusion.

Start there. Build from there.

Because when everyone speaks the same language, stakeholders stop micromanaging and start trusting. And that’s when the work actually starts to scale.

Rosana Inacio — PM Insights
Why Forcing Change Doesn’t Work in Project Teams

April 26, 2026

When something isn’t working in a team, the instinct kicks in fast.

You spot inefficiencies. You see better ways to work. You want to make an impact quickly.

But here’s what that instinct misses: teams are not a blank slate.

Some people have been doing this for years and have strong opinions about why things work the way they do. Some are still finding their footing. Some genuinely don’t see a problem. And a few have already tried to fix the same thing you’re looking at, and failed.

That gap in perspective is exactly where most change efforts quietly fall apart.

The mistake most people make

The natural reaction is to move fast. Introduce new tools. Redesign the process. Raise the bar on expectations.

All at once. All with good intentions.

But change that isn’t connected to a felt need doesn’t feel like progress, it feels like disruption. And disrupted people don’t adopt new ways of working. They wait it out.

The harder truth: the more confident you are that you’re right, the easier it is to skip understanding the team.

A better starting point

Before changing anything, take a picture of how the team works today.

Not how you think it works. How it actually works.

Sit with people. Ask where the friction is. Listen for the things that come up more than once, the meeting that always runs long, the handoff that always gets dropped, the decision that always takes too long. Those patterns are your signal.

You’re not looking for individual complaints. You’re looking for shared pain.

Start smaller than feels right

Once you’ve found a real pattern, resist the urge to fix everything at once.

Pick one problem. Ideally one that affects multiple people and creates friction in the actual work, not just something that bothers you aesthetically.

Then make the smallest possible improvement that would meaningfully help.

Not a new system. Not a process overhaul. A small, concrete adjustment that makes Tuesday easier than Monday was.

This matters for a reason beyond scale: small changes are easier to reverse if they don’t work. That safety makes people more willing to try them.

Let the results do the convincing

When an improvement genuinely helps, people adopt it without being asked.

You don’t need to sell it. You don’t need to follow up. You don’t need to put it in a slide deck.

The improvement just becomes part of how the team works, because it made their work better.

Then you repeat the cycle. Step back. See what shifted. Find the next friction point. Improve that.

Over time, this compounds. The team starts to trust that changes are worth trying, because the last one actually helped.

The bigger picture

Change doesn’t fail because the idea is wrong. It fails because it doesn’t fit.

Sustainable change in teams isn’t about introducing the right ideas. It’s about introducing them at the right moment, in the right size, connected to a real problem.

Big changes imposed from the outside rarely stick, not because people resist change, but because they resist change that doesn’t feel relevant to them.

Small improvements, applied consistently and earned through trust, move teams further than any transformation initiative ever will.

Rosana Inacio — PM Insights
The AI Tools That Match Your Project Management Style

April 18, 2026

There is no shortage of AI tools for project managers right now. New ones launch every week, and the advice to “just start using AI” is everywhere, but rarely specific enough to be helpful.

The problem isn’t access. It’s fit.

The tools that save time for one project manager can feel completely wrong for another. A lot of that comes down to how you naturally work. Your planning style, your communication habits, how you run meetings, and how you think through problems all shape which AI tools will actually stick.

This isn’t an exhaustive review of every tool on the market. It’s a practical starting point based on how different project managers tend to work, and where AI can genuinely support that.

If You’re a Heavy Planner

You think in structure. You map dependencies, build detailed schedules, and feel most confident when the plan is solid before execution starts.

Where AI helps most:
Generating first drafts of project plans, work breakdown structures, and risk registers.

AI doesn’t replace planning. It removes the blank page.

Starting from a rough draft is faster than starting from zero. You can critique and refine much faster than you can build from scratch.

Tools worth trying:

• ChatGPT or Claude, for drafting project charters, scope documents, and risk lists
• Notion AI, if you already use Notion for documentation
• Microsoft Copilot, if your organization runs on Microsoft 365

Practical starting point:
Describe your next project in a paragraph and ask AI to generate a first-draft risk register. Review it, remove what doesn’t apply, and add what’s missing. You will have a working document in minutes instead of an hour.

If You’re Execution-Focused

You care about momentum. Status, blockers, decisions, and delivery drive your day. You don’t want to spend time on documentation that doesn’t move the project forward.

Where AI helps most:
Automating the administrative work that pulls you away from delivery.

AI doesn’t move the project. It removes the friction around it.

Meeting notes, status updates, and follow-up emails are high-frequency, low-complexity tasks that AI handles well.

Tools worth trying:

• Otter.ai or Fireflies.ai, for meeting transcription and summaries
• Notion AI or Confluence AI, to summarize notes and generate updates
• ChatGPT, to turn bullet points into structured reports

Practical starting point:
Use a meeting transcription tool in your next call and compare the AI summary to your own notes. Most project managers are surprised by how much they missed and how much time it saves.

If Communication Is Your Core Skill

You manage through relationships. You understand your stakeholders, adapt your message to different audiences, and know that how you say something matters as much as what you say.

Where AI helps most:
Drafting communication faster without losing your voice.

AI gives you the structure. You bring the judgment.

AI provides a strong starting point. You refine tone, context, and intent.

Tools worth trying:

• ChatGPT or Claude, for drafting stakeholder updates and difficult conversations
• Grammarly, to refine tone and clarity
• Canva AI, for creating visual updates or presentations

Practical starting point:
Ask AI to draft three versions of a stakeholder message with different tones: direct, diplomatic, and concise. Use the best parts of each. You will often write faster and better.

If You’re a Problem Solver and Strategic Thinker

You are comfortable with ambiguity. You analyze situations, weigh options, and make decisions when the path is not obvious. People come to you with complex problems.

Where AI helps most:
Thinking through scenarios, challenging assumptions, and exploring alternatives quickly.

AI doesn’t decide for you. It expands how you think.

It works as a thinking partner, helping you see options faster and test your reasoning.

Tools worth trying:

• ChatGPT or Claude, for scenario analysis and decision frameworks
• Perplexity AI, for research-backed answers
• Miro AI, to organize and visualize complex information

Practical starting point:
Before your next major decision, ask AI to argue against your plan. Use it as a devil’s advocate. You may uncover gaps or strengthen your reasoning.

The Tool Doesn’t Matter as Much as the Habit

The most common mistake project managers make with AI is treating it like a project, something to evaluate, implement, and roll out perfectly.

Most project managers are not struggling with AI tools.
They are struggling to use them consistently.

It works better when you treat it like a habit.

Pick one task. Use AI for that task consistently for a few weeks. Then add another.

The project managers getting the most value from AI are not the ones testing every new tool.

They are the ones who made AI part of how they work.

Your project management style is not a barrier to using AI.

It is the best guide for where to start.

Final Reflection

You don’t need to use every tool.

You don’t need to follow every trend.

You just need to find what fits how you already work, and build from there.

Which of these styles resonates most with how you work? And have you found an AI tool that genuinely fits your workflow?

Rosana Inacio — PM Insights
Most Stakeholder Problems Are Communication Problems

April 11, 2026

Stakeholder management is often seen as a complex part of project management.

But in many cases, the issue is not the stakeholders.

It is the communication.

When things start to go wrong

Projects rarely fail because people don’t care.

They struggle when expectations are not aligned.

Stakeholders feel surprised.
Decisions come too late.
Priorities shift without clarity.

And suddenly, tension appears.

Many sources suggest that project managers spend about 75% to 90% of their time communicating.

That number makes sense when communication is unclear, delayed, or missing.

Without a clear communication approach, even simple situations can turn into unnecessary stress.

The real problem

Most stakeholder issues are not about the work itself.

They come from:

• unclear expectations
• late communication
• too much or too little detail
• assumptions that were never confirmed

When communication is not clear, people fill the gaps with their own expectations.

This is where communication needs to shift.

The mindset shift

Communication is not just about sharing updates.

It is about managing expectations.

Good communication means:

• people know what is happening
• people understand what might change
• people are not surprised

That is where alignment comes from.

What actually makes a difference

Strong stakeholder communication is simple, but consistent:

• align early on goals and expectations
• communicate before being asked (for example, sharing a short weekly update before stakeholders request it)
• adapt the level of detail to your audience
• keep messages clear and focused
• repeat important points when needed

It is not about saying more.

It is about saying the right things at the right time.

Choosing the right communication channel

Good communication does not mean more meetings.

In many cases, too many meetings create noise instead of clarity.

What matters is choosing the right channel for the message.

Some updates can be shared in a short written format.
Some decisions need a quick conversation.
Some topics require alignment in a meeting.

The goal is not to communicate more.

It is to communicate in a way that is clear, timely, and easy to consume.

When communication is structured and consistent, teams and stakeholders stay informed without feeling overwhelmed.

Final reflection

Stakeholder management is not about controlling people.

It is about creating clarity.

When communication is consistent and expectations are clear, most problems don’t escalate.

And when they do, they are easier to handle.

Good communication reduces surprises.

And surprises are what create tension in projects.

How do you approach stakeholder communication in your projects?

Rosana Inacio — PM Insights