The Communication Loop: Why Keeping Project Managers Informed is Key to Project Success

In the fast-paced world of project delivery, especially within the intricate web of software development and IT, effective communication isn't just a nicety; it's the lifeblood of success. Recently, a seemingly minor oversight on my part served as a potent reminder of this fundamental truth, highlighting how easily crucial stakeholders can be left out of the loop and the potential ramifications of such an omission. It all started with an email from another Program Manager (PgM). While her official title might have been slightly more junior than mine, we both fulfilled the same vital role within our respective teams – and in the trenches of project execution, it's the role and responsibilities that truly matter, not the hierarchical label.

Her team was responsible for delivering certain modules that our team consumed for a larger project. We had a history of successful collaboration, and the coordination between our teams had generally been smooth. However, with a new request on the table, one of our senior developers initiated a discussion directly with a senior developer from her team. This technical dialogue continued for some time between these two experts, focusing on the nitty-gritty details. Eventually, our developer looped me into the email chain. I reviewed the progress, added my comments regarding schedules, dependencies, and broader project alignment, and proceeded with the discussion. My critical mistake? I didn't take the elementary, yet crucial, step of ensuring the Program Manager from the other team was also included in this evolving conversation.

It was about a week later that she discovered she was out of the loop on discussions concerning features, potential delivery timelines, and work that her team would ultimately be tasked with executing. Understandably, she sent me an email (and I'm sure had a similar conversation with her developer) politely but firmly inquiring why she hadn't been included in these critical discussions about a delivery her team was accountable for. I had no "great answer" for this oversight, other than to acknowledge the mistake and affirm that she absolutely should have been part of the conversation from a much earlier stage.

This incident, though resolved amicably, underscores a tricky yet persistent point in project collaboration: at what stage, and to what extent, should various stakeholders, particularly Program or Project Managers (PMs), be involved in ongoing discussions?

The Shifting Sands of Involvement: Team Dynamics and Established Norms

The dynamics of when a PgM or PM steps into detailed discussions can vary significantly from one team or organization to another. There's no single "right" moment that universally applies.

• Developer-Led with Later PM Engagement: In some highly experienced or autonomous teams, developers might carry technical discussions quite far, hashing out feasibility, initial approaches, and even preliminary estimates amongst themselves. The PgM might only be brought in when concrete scheduling commitments are needed, resource conflicts arise, or formal agreements need to be documented. This often works well when the scope is well-understood by the developers and the project has a history of smooth execution.

• Early and Continuous PM Involvement: In other groups, or for projects with greater complexity, ambiguity, or cross-functional dependencies, the PgM or PM might need to be involved from the very outset of any significant discussion. They might facilitate initial requirement clarifications, ensure alignment with broader program goals from day one, and proactively identify potential roadblocks.

It’s crucial to understand that the point at which a PgM/PM typically enters detailed discussions is not necessarily a reflection of a team's "maturity" or "value system." More often, it's simply a reflection of how the working dynamics and communication protocols of that particular group or interacting groups have become established over time. Sometimes these established norms work efficiently; other times, as my recent experience showed, they can lead to unintended communication gaps.

Why the Program/Project Manager's Involvement is Non-Negotiable (At Some Point)

Regardless of a team's specific dynamics, there is no denying the fact that the Program Manager or Project Manager does need to be involved at a certain stage. Their perspective and responsibilities extend beyond the purely technical, encompassing a range of factors that developers, however skilled, may not have full visibility into or authority over.

Here are just a few compelling reasons why their inclusion is critical:

1. Strategic Alignment and Prioritization:
   A PgM often has a broader view of the overall program or portfolio of projects. They understand the strategic objectives and can ensure that new requests or proposed solutions align with these higher-level goals. At an extreme level, as you rightly pointed out, the team may have been directed by senior management to focus on entirely different critical work, making them unable to cater to a new request, no matter how technically sound. Only the PgM might have this overarching visibility.

2. Resource Management and Conflict Resolution:
   This is a primary responsibility of any PgM/PM.

   • Scheduling Conflicts: A developer on one team might agree to a timeline with a developer on another, unaware that their own team's PgM has already committed those resources to a different, higher-priority task.

   • Resource Conflicts: Is the required expertise available? Are team members already over-allocated? Are there dependencies on shared resources (e.g., testing environments, specialized equipment)? The PgM is typically the one tracking these allocations and is in the best position to identify and resolve such conflicts, often through coordination with other PgMs or managers.

3. Budgetary Oversight:
   Many technical discussions can lead to solutions with varying cost implications (e.g., using a new licensed tool, requiring additional cloud services). The PgM is usually responsible for managing the project budget and needs to be aware of any decisions that could impact it.

4. Dependency Management:
   Software projects rarely exist in a vacuum. There are often dependencies on other teams, third-party vendors, or infrastructure changes. The PgM tracks these external dependencies and ensures they are managed to avoid bottlenecks.

5. Risk Management:
   Early discussions might reveal potential technical risks, scope uncertainties, or external dependencies. A PgM is trained to identify, assess, and plan mitigation strategies for such risks. Keeping them informed allows for proactive risk management.

6. Stakeholder Communication (Broader Audience):
   While developers might communicate effectively with their technical counterparts, the PgM is often responsible for communicating progress, issues, and decisions to a wider range of stakeholders, including non-technical business users, senior management, or even clients. They need to be party to the core discussions to fulfill this role accurately.

7. Scope Management:
   As technical discussions evolve, there's always a risk of "scope creep" – where well-intentioned additions or changes gradually expand the project beyond its original objectives. The PgM plays a crucial role in managing scope, ensuring that changes are evaluated, approved, and their impact on schedule and resources is understood.

8. Tracking Agreements and Action Items:
   As highlighted, once discussions reach a certain stage, especially if they involve multiple people or teams, there's a clear need for regular interactions and for somebody to meticulously track the agreements made and the action items arising from these meetings or discussions. This formal tracking is a classic PgM/PM responsibility, ensuring accountability and progress. Without it, valuable decisions can be lost, and momentum can stall.

The "When" and "How": Best Practices for Inclusive Communication

So, how do we avoid the "missed CC" scenario and ensure the right people are in the loop at the right time?

• Err on the Side of Inclusion (Initially): It is almost always better to include the relevant Program/Project Manager (from all involved teams) in initial discussions or as soon as a request starts to solidify beyond a very preliminary technical query. As suggested, "it is best if the person gets included and they then can figure out their level of involvement at different stages of the discussion." A good PgM will appreciate being informed and can choose to monitor passively, delegate follow-up on certain threads, or step in more actively as needed. They can always opt-out of threads that become too granular for their immediate attention, but they cannot opt-in if they are unaware.

• Establish Clear Communication Protocols: For recurring inter-team collaborations, it's beneficial to have agreed-upon communication protocols. This might include:

  • Always CC'ing respective PgMs/PMs on initial requests or significant updates.

  • Defining clear points of contact for different types of queries.

  • Establishing regular inter-team sync-up meetings led or attended by the PgMs.

• Developer Responsibility: Encourage developers to proactively include their PgM/PM when discussions start to involve timelines, resource commitments, scope changes, or potential impacts on other projects. It’s not about micromanagement, but about shared awareness.

• Use Centralized Communication Tools: Utilizing project management software (like Jira, Asana, Trello) or shared communication channels (like Slack, Microsoft Teams dedicated channels) can help keep discussions visible to a wider relevant audience, reducing the chances of someone being inadvertently excluded from an email thread.

• The "No Surprises" Rule: A good guiding principle for any team member is to ensure their PgM/PM is never surprised by a major development, commitment, or roadblock. This fosters trust and allows the PgM to manage expectations effectively with other stakeholders.

• Regular Check-ins, Even for Technical Threads: Even if a technical discussion is ongoing primarily between developers, a brief summary update to the PgMs at key junctures can be invaluable.

My Learning: The Value of the Elementary Step

My oversight in not including my counterpart PgM was a simple lapse, an "elementary step" missed in the flow of a busy project. Yet, it highlighted a critical truth: the project's health depends on these connections. Her being out of the loop could have led to misaligned expectations for her team, potential scheduling conflicts that would only surface later, or her team being blindsided by commitments made without their managerial oversight. The potential "boo-boo" mentioned, and the subsequent "uncomfortable words with the boss," are very real consequences that can arise from such communication failures, eroding trust and efficiency.

Conclusion: Weaving a Stronger Web of Collaboration

In the complex tapestry of software development and project management, ensuring that key stakeholders – particularly Program and Project Managers – are kept consistently in the communication loop is not just good manners; it's a fundamental prerequisite for success. While the exact timing and depth of their involvement may vary based on team dynamics and project specifics, the principle of proactive inclusion should always be favored.

The Program Manager acts as a vital hub, connecting technical execution with strategic goals, resource realities, and stakeholder expectations. By ensuring they are informed, we empower them to navigate conflicts, manage risks, and steer the project effectively. My recent experience served as a valuable, if slightly humbling, reminder that even the most seasoned professionals can benefit from revisiting these elementary principles of communication. It's through these conscious acts of inclusion that we build stronger teams, foster more transparent collaborations, and ultimately, deliver better outcomes for everyone involved.

Further References & Learning:

Books on Project Management, Communication, and Team Collaboration (Available on Amazon and other booksellers):

"A Guide to the Project Management Body of Knowledge (PMBOK® Guide)" by Project Management Institute (Buy book - Affiliate link): The standard reference, with extensive sections on stakeholder management and communication planning.

"The Five Dysfunctions of a Team: A Leadership Fable" by Patrick Lencioni (Buy book - Affiliate link): Highlights the importance of trust and communication in team effectiveness.

"Making Things Happen: Mastering Project Management" by Scott Berkun (Buy book - Affiliate link): A practical and insightful guide to project management, emphasizing communication.

"Agile Project Management with Scrum" by Ken Schwaber (Buy book - Affiliate link): Details communication and roles within the Scrum framework.

"Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister (Buy book - Affiliate link): Focuses on the human elements of software development, including team dynamics and communication.

YouTube Videos Explaining Project Communication and Stakeholder Management (too many to show here, just search for these topics below):

1. Search "Project Management Communication Plan": Many PMP training channels and project management experts cover this topic.

2. Search "Stakeholder Management in Projects": Understanding who to keep in the loop and why.

3. Search "Effective Communication for Project Managers": Tips and techniques.

4. Search "Agile Communication Practices" or "Scrum Daily Standup Purpose": For insights into communication within Agile teams.

5. Search "Avoiding Common Project Management Mistakes": Communication gaps are often high on these lists.

6. Channels like:

   • Project Management Institute (PMI) Channel: Official talks and resources.

   • Adriana Girdler - Project Management & Leadership Coach: Practical tips for project managers.

   • Praizion (YouTube channel by a PMP trainer): Detailed explanations of PMBOK concepts.

   • Business and leadership channels that discuss effective communication and teamwork.

Emotional stability - Somebody's got to remain in control during a heated discussion

This was a painful episode when seen in highlight, and something that has stayed with me the rest of my career and even intruded into my personal life. I did not do something outrageous, but the concept of making your way down a path where there is no easy way back has remained with me ever since, and everytime I get into a situation where it could become problematic, I recall the incident to see that I am not boxing myself into a corner.
The exact incident could vary, but the scenario is the same. You are Project Manager / Program Manager of a team with colleagues who have different roles, and their emphasis at different parts of the schedule is different. At a particular point in the schedule, even though both Development, Usability and Testing are supposed to be on the same wavelength, their focus and push could be different, and that is very natural. In this particular case, the situation happened at the time of the schedule when we were supposed to stop all new feature work, from that point on, all the focus would be on resolving defects in the features already implemented.
This is a critical moment for the testing team, since they essentially consider this the time when the entire product comes together, with all features working to some degree or the other (one is really considering a development process that is not ideal scrum). The integration testing happens more critically from this point onwards, and it can take a lot of time from this point in the schedule to thrash through most of the defects and make the product stable (of course, you cannot find all the defects in the product). The testing team is expected to not welcome any addition of new features from this point onwards.
This was a critical time. Some of the members of the development team had come in mid-cycle, so there was already some instability in the team, and it did take them some time to understand the product code and understand the team dynamics and work together as a team. At this time, the Product Management came in with a critical new feature (that had been introduced by the competition) which was expected to take another 2 weeks to develop, with the remaining testing time being around 1.5 months. Now, this was not an easy situation. The testing team was well justified in terms of not agreeing to take this feature, since in the end, it was their responsibility to ensure that the product was stable and had the least number of defects possible. The product manager was quite serious in terms of the need for this feature, and was pushing for it. The development team was ready to implement it.
The first meeting to discuss this was a disaster, with these stated positions being discussed, and getting heated. For me, unfortunately, being the Program Manager, it was my responsibility to ensure that the discussion remained in reasonable limits of discussion, without getting heated, and nobody getting into an inflexible position. However, in this case, at some point, the discussion went into a thread of policy and schedules, and it turned out that I started taking a more inflexible position, whereby such a change would not be possible. The discussion terminated soon after, and it got escalated, and during the midst of a discussion with my manager, I realized my mistake (while I was being chewed out). In every discussion, typically the managers need to ensure that discussions need to remain on a civil level, discussions can get heated, but nobody should reach a point where they get into a position from there was no roll-back, and certainly not the Project Manager / Program Manager. 

Getting technical teams to talk to each other for technical discussion of features

We work in a world where a software development team cannot exist entirely on its own. It is true that the software team develops a large chunk of the features of the application, with coding and testing of most of the features of the application. However, software teams do end up using code written by other persons or teams, in the nature of components and functions written by other teams. One of the most common cases is when there are large software organizations, where there are central teams that create common components. Such components could be used for specialized purposes such as reading and writing to the disk and to optical disk drives, reading and writing varied video and imaging formats / codecs, components that are meant to create a specialized user interface, and so on. If you are working for a large organization, there is a good chance that you will be using such examples of components in your product, and also using other bits of code that is written by other people or teams.
As a consequence of this dependency on other teams, there is a need to have a regular synch-up with these teams to ensure that there is a ongoing discussion with these teams - these regular discussion could be related to the requirements, the schedule, the process of coordination, and and so on. However, some of the discussion that gets missed unless the teams have already had an agreement over the requirements and the schedule is that of the technical teams and the architecture. A lot of time there is the assumption that unless there is an agreement between the teams, there is no need for a regular technical discussion.
However, this can be a fallacy. When the discussion is between teams within an organization, there are far greater chances that there will be an eventual agreement between them. And in many other cases, this would not be the first time that the component will be integrated into the product, the discussion would be related to a newer version of the component that will be integrated into a newer version of the product. In such a case, it makes sense to have an ongoing technical discussion between the product team and the component team. It is also very likely that the technical discussion will be as important as the requirements discussion, since most of the issues in such an integration are of a technical nature. Further, having an ongoing discussion also means that then needs of your team remain high in the attention span of the product team, and that also makes it easier to get what you need from the requirements team.