When something goes wrong on a project, the first instinct most early-career PMs have is to make sure no one is left out of the loop. So they loop everyone in on everything. More syncs, more updates, more people on every thread. The logic feels right. But that's not how communication breaks down on real projects. It breaks down because the right information didn't reach the right person at the right time in a way they could act on. And looping everyone in on everything actually makes that harder, because now the critical update sits alongside 40 things that don't matter to that person. The experienced PMs I've watched work do the opposite. They narrow the paths instead of widening them. Curious what other lessons about project communication only clicked after running enough projects.
PMO Leader | Speaker & Mentor | Content Leader – PMOGA Latin America
Hub| Catholic University of UruguayMontevideo, Montevideo, Uruguay
One of the hardest lessons I learned after managing enough projects is that communication isn’t about volume, it’s about precision. Flooding everyone with updates creates noise; what really matters is ensuring the right person receives the right information at the right time in a way that enables action. Experienced PMs design lean communication paths, not wide ones. What other communication practices have you found only become clear after leading multiple projects?
...
1 reply by Sandeep Kashyap
Sep 24, 2026 1:27 AM
Sandeep Kashyap
...
Well, something along the same lines. I believe that matching the scope of communication to the scope of the work is just as important as having the communication in the first place. A piece of feedback that only matters to a document should live with the document. A decision about a task should live with the task. An update that matters for the rest of the sprint should live with the sprint. A project-level decision should live at the project level.
The idea is to make sure context stays where the people doing the work will need it.
Otherwise, even when the right information exists, people still end up searching for it, asking someone to repeat it, or reconstructing what happened.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Sandeep, from my experience managing large complex projects, I’ve learned a few things about project communication:
1) Communication is a two-way stream. It’s not just about getting the right information to the right person at the right time. It’s also about getting the right response, decision, or confirmation back in time to take action otherwise, you’re just broadcasting information.
2) Communication is as much about listening as it is about communicating. Active listening helps you understand what is actually being said, what might be missing, and what the other person needs before you decide how to respond or move forward.
3) More communication doesn’t necessarily mean better communication. One of the things you learn with experience is that the goal isn’t to keep everyone informed about everything. It’s to make sure the people who need to know something have enough context to make the right decision or take the right action.
4) Clarity beats volume. A short, clear message that answers what happened, what it means, what’s needed, and by when is often more valuable than a long status update that leaves people figuring out what they’re supposed to do.
I think that’s one of the biggest shifts that happens with experience: you stop thinking about communication as “keeping people in the loop” and start thinking about it as enabling people to act.
...
1 reply by Sandeep Kashyap
Sep 24, 2026 1:28 AM
Sandeep Kashyap
...
I really like your first point. Communication is not complete when the message goes out. The response has to make its way back too.
That’s why I think the place where we communicate matters more than we often realize. We tend to design communication around sending information, but rarely think about what makes it easy or difficult for the other person to respond. And responding often asks more of people than we realize. They may need more context to figure out what to say and how to respond.
The easier it is for them to find that relevant context, the easier it is to give a useful response and keep the work moving.
One of the hardest lessons I learned after managing enough projects is that communication isn’t about volume, it’s about precision. Flooding everyone with updates creates noise; what really matters is ensuring the right person receives the right information at the right time in a way that enables action. Experienced PMs design lean communication paths, not wide ones. What other communication practices have you found only become clear after leading multiple projects?
Well, something along the same lines. I believe that matching the scope of communication to the scope of the work is just as important as having the communication in the first place. A piece of feedback that only matters to a document should live with the document. A decision about a task should live with the task. An update that matters for the rest of the sprint should live with the sprint. A project-level decision should live at the project level.
The idea is to make sure context stays where the people doing the work will need it.
Otherwise, even when the right information exists, people still end up searching for it, asking someone to repeat it, or reconstructing what happened. Saving Changes...
Sandeep, from my experience managing large complex projects, I’ve learned a few things about project communication:
1) Communication is a two-way stream. It’s not just about getting the right information to the right person at the right time. It’s also about getting the right response, decision, or confirmation back in time to take action otherwise, you’re just broadcasting information.
2) Communication is as much about listening as it is about communicating. Active listening helps you understand what is actually being said, what might be missing, and what the other person needs before you decide how to respond or move forward.
3) More communication doesn’t necessarily mean better communication. One of the things you learn with experience is that the goal isn’t to keep everyone informed about everything. It’s to make sure the people who need to know something have enough context to make the right decision or take the right action.
4) Clarity beats volume. A short, clear message that answers what happened, what it means, what’s needed, and by when is often more valuable than a long status update that leaves people figuring out what they’re supposed to do.
I think that’s one of the biggest shifts that happens with experience: you stop thinking about communication as “keeping people in the loop” and start thinking about it as enabling people to act.
I really like your first point. Communication is not complete when the message goes out. The response has to make its way back too.
That’s why I think the place where we communicate matters more than we often realize. We tend to design communication around sending information, but rarely think about what makes it easy or difficult for the other person to respond. And responding often asks more of people than we realize. They may need more context to figure out what to say and how to respond.
The easier it is for them to find that relevant context, the easier it is to give a useful response and keep the work moving. Saving Changes...
Priyanka KathiresanDigital Project Manager| ConsertusBoston, MA, United States
After working as a project manager for years, the hurdles related to how PM applications work (Jira, SharePoint, Confluence, etc.) are only the tangible ones. The challenges that lie in the intangible aspects of project management are rarely discussed. Soft skills such as emotional intelligence, empathy, and adaptability are rarely explained in practical terms. Currently, I am facing the following difficulties at work:
1. Not being able to close a set of tasks because of endless revisions
Stakeholders did not agree to create new user stories for the revisions.
Stakeholders confirmed that these are only revisions and not new requirements.
Ultimately, with so many user stories remaining open, it looks like none of these tasks are complete on paper, even when significant work has been done.
2. Having difficulty getting hold of stakeholders whose input is needed but who have the least interest in getting involved
Stakeholders do not agree to meet frequently.
Multiple, often endless, follow-ups are needed to get their input.
The primary stakeholder, despite having high power and interest, may not be able to do much in most cases.
3. When a critical resource or SME leaves the organization
The resource had numerous responsibilities related to a major deliverable.
Even with multiple knowledge transfer documents and repositories, there are gaps in understanding how certain activities concluded, and no one knows the full context.
Going back to the client to ask where we left off puts us in an uncomfortable position.
...
1 reply by Sandeep Kashyap
Oct 15, 2026 8:18 AM
Sandeep Kashyap
...
These are some practical challenges, especially the third one. Documentation can capture what was done, but it doesn't always capture why a decision was made or what led to it. That missing context can become a real problem when someone leaves.
I also think endless revisions and delayed stakeholder inputs are connected to how we define completion and ownership. If those expectations aren't clear upfront, tasks can remain open even when most of the actual work is done.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Sandeep, one thing I have learned is that effective project communication is not primarily about increasing or reducing the flow of information.
It is about designing communication around what it needs to make possible.
I agree that copying everyone into everything can bury the signal in the noise.
But I would be equally cautious about making “narrower paths” the rule.
A path can become so narrow that relevant knowledge, affected stakeholders or necessary challenge are excluded.
So, before communicating, I would ask not only “Who needs to know this?” but also “Why do they need to know it, and what should this enable them to understand, contribute to, decide or do?”
That also means considering whether they have the context, attention and, where action is required, the authority needed to respond.
And communication needs a return path: some way of knowing whether the necessary understanding, response or decision has actually occurred.
For me, the lesson is that good communication is not measured by how much information we distribute, or how few people receive it.
It is measured by whether communication supports the understanding, coordination and informed action the project actually requires, with enough feedback to know whether the intended communication loop has been completed.
...
1 reply by Sandeep Kashyap
Oct 15, 2026 8:18 AM
Sandeep Kashyap
...
I like your point about the return path. Sending an update doesn't necessarily mean the message has been understood or that the required action will happen. Sometimes we assume communication is complete simply because we've shared the information.
I think the challenge is knowing when a response or confirmation is actually necessary and when it just adds another layer of communication. Otherwise, even well-intentioned follow-ups can become noise.
After working as a project manager for years, the hurdles related to how PM applications work (Jira, SharePoint, Confluence, etc.) are only the tangible ones. The challenges that lie in the intangible aspects of project management are rarely discussed. Soft skills such as emotional intelligence, empathy, and adaptability are rarely explained in practical terms. Currently, I am facing the following difficulties at work:
1. Not being able to close a set of tasks because of endless revisions
Stakeholders did not agree to create new user stories for the revisions.
Stakeholders confirmed that these are only revisions and not new requirements.
Ultimately, with so many user stories remaining open, it looks like none of these tasks are complete on paper, even when significant work has been done.
2. Having difficulty getting hold of stakeholders whose input is needed but who have the least interest in getting involved
Stakeholders do not agree to meet frequently.
Multiple, often endless, follow-ups are needed to get their input.
The primary stakeholder, despite having high power and interest, may not be able to do much in most cases.
3. When a critical resource or SME leaves the organization
The resource had numerous responsibilities related to a major deliverable.
Even with multiple knowledge transfer documents and repositories, there are gaps in understanding how certain activities concluded, and no one knows the full context.
Going back to the client to ask where we left off puts us in an uncomfortable position.
These are some practical challenges, especially the third one. Documentation can capture what was done, but it doesn't always capture why a decision was made or what led to it. That missing context can become a real problem when someone leaves.
I also think endless revisions and delayed stakeholder inputs are connected to how we define completion and ownership. If those expectations aren't clear upfront, tasks can remain open even when most of the actual work is done. Saving Changes...
Sandeep, one thing I have learned is that effective project communication is not primarily about increasing or reducing the flow of information.
It is about designing communication around what it needs to make possible.
I agree that copying everyone into everything can bury the signal in the noise.
But I would be equally cautious about making “narrower paths” the rule.
A path can become so narrow that relevant knowledge, affected stakeholders or necessary challenge are excluded.
So, before communicating, I would ask not only “Who needs to know this?” but also “Why do they need to know it, and what should this enable them to understand, contribute to, decide or do?”
That also means considering whether they have the context, attention and, where action is required, the authority needed to respond.
And communication needs a return path: some way of knowing whether the necessary understanding, response or decision has actually occurred.
For me, the lesson is that good communication is not measured by how much information we distribute, or how few people receive it.
It is measured by whether communication supports the understanding, coordination and informed action the project actually requires, with enough feedback to know whether the intended communication loop has been completed.
I like your point about the return path. Sending an update doesn't necessarily mean the message has been understood or that the required action will happen. Sometimes we assume communication is complete simply because we've shared the information.
I think the challenge is knowing when a response or confirmation is actually necessary and when it just adds another layer of communication. Otherwise, even well-intentioned follow-ups can become noise. Saving Changes...
Community Champion
