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.

What is the relationship between a developer and a tester? Who is responsible for a good software quality?

Success of a project depends on the development team. The working efficiency of the team depends on its individual members and of course on the quality of the relationships that they are maintaining. By a good relation among the team members we mean the team spirit, comradeship and communication between them. All these qualities give rise to a good team.

In a software development cycle the relationship between a program developer and tester is very crucial. Since the two processes i.e., the development of the software system or application and its testing are inter- dependent on each other.

Successful completion of both these processes is crucial to any software development cycle.

POSITION OF A DEVELOPER?

The software developers fall under the following three categories:
1. Computer programmers
2. Software applications developers and
3. Software systems developers

- Software or a program developer as we know is the one who is concerned with the development of a software system or application.
- He/ she takes care of all the phases of the software development cycle.
- His/ her work includes research, planning development, designing and developing the software system or application.
- Sometimes it may also include the facets of testing the software.
- Program developers are at the center of the whole development process and are involved with management of the software project and its programming.

POSITION OF A TESTER
- He/ she is the person involved with the testing facets of a software system or application.
- Their job is to provide the details about the quality of the software system or application to the stake holders.
- He/ she is responsible for executing the software program with the intention of discovering bugs and errors in it.

RELATIONSHIP BETWEEN DEVELOPER AND TESTER
- The relationship between a tester and a developer should be excellent.
- It is obvious that both the software developers and the software testers work for improving the quality of the software.
- Quality of software includes the design of the software system, actual core implementation, requirements, gap analysis, specifications analysis, development of prototypes, feasibility analysis, documentation, testing, software pre release and post release activities and not to forget the maintenance of the entire software system or application.

But, it is often seen that the relationships between the developers and testers are not so good. This is probably because of the roles of these two.

- Their work often clashes.
- It is obvious that something in the process of development will certainly have bugs.
- It becomes important to decide if this bug is to be left or it is to be fixed. - At this point usually the relationship between the two worsens.
- After all, it is the duty of the testers to identify the bugs in the program.

Matters like these should not hamper the relationship between the developers and the testers as it is crucial for the development.

- Team work and better individual understanding is the best solution for this kind of problem.
- Maintain the quality of software is not just the responsibility of a software tester or developer.
- It is responsibility of the whole development team.
- Therefore every stake holder holds the responsibility for the quality of the software product from the programmer to the customer.

Testers are usually held responsible for the quality sine they are the one who are responsible for finding out the weaknesses of the software and the testers accuse the developers for putting up a bad code. This puts a bad impact on the whole development team since the team spirit is lost.

What are different aspects of International Organization for Standardization (ISO)?

ISO is the short form of International Organization for Standardization. The international organization for standardization is well known for the development and publication of the standards pertaining to the international standard.

- The organizations itself constitutes many national networks from across the world.
- It is reported to have 163 countries in its network with one representative from each country.
- The office of the central secretariat of the organization is located in the city of Geneva in Switzerland.
- The purpose of the secretariat is to regulate the coordination in the system.
- It is a private organization and works with both public and private sector organizations. It is a non governmental organization.
- Most of its member organizations are either government organizations of their respective countries or are funded by the government.
- Other member organizations are private and are run in cooperation with the industry associates.
- We can say that ISO lays down a consensus that provides solutions which serves needs of both the business and society.
- The short form “ISO” was taken from Greek word “isos” which means “equal”.

Standards make a good impact on our life and they raise standards of our living too.Standards are very much needed to ensure characteristics like:


- environmental compatibility
- safety
- quality
- reliability
- economical cost
- interchangeability and
- efficiency


We never tend to notice the standard till the services and products are up to our expectations. We notice the importance of standards only when the services are not of the expected level. The products and services are said to work well and efficiently when they meet the standards set for them.

The international organization of standards is responsible for maintaining such standards all over the world.

International organization of the standards serves the following purposes:
1.It makes the manufacturing and development of services and products efficient, better than the previous and safe.
2.It aims at continually improving the marketing standards.
3.It takes are of the supply of services and products to the consumers.
4.It aims at developing a fair trading strategy between different nations of the world.
5.It lays down a basis for products and services for safety and health and environmental legislation.
6.It is responsible for carrying out the conformity assessment.
7.It shares new technological methodologies and management practices with its member organizations to lead innovation ahead.
8.It acts as a safeguard for the consumers of the services and products.
9.It provides solutions for many problems of standardization.

SOME MORE FACTS
- ISO till now has developed and maintained around 18,500 standards on an international level.
- Apart from these 18,500 standards, every year some 1000 new standards are being developed and published.
- The information about all these standards is available on the official website international organization of standards.
- The information center of ISO is operated by ISO itself in coordination with the international electro- technical commission (IEC).
- The ISO/ IEC information center has been developed to provide information regarding matters of standardization to its members and other stake holders.
- All the policies and strategies of the international organization of standards are jointly endorsed by the major governing bodies of ISO itself.
- The policies and strategies that have been serve as a guideline for all the members of the international organization of standards and its secretariat.

The 163 members of the ISO network are divided in to 3 categories which are:

- Member bodies
- Subscriber members
- Correspondent members

Introduction to Class-Responsibility-Collaborator (CRC) Modeling

Class-responsibility-collaborator (CRC) modeling is a means to identify and organize classes relevant to system requirements. CRC model is a collection of index cards and it consists of three parts:

Classes : It is a collection of similar objects.
- Entity classes or business classes are obtained directly from statement of the problem. The information contained in these classes are important to users but they do not display themselves.
- Boundary classes are used to create interface which user sees and interacts with as software is used.
- Controller classes are designed to manage creation or update of entity objects, instantiation of boundary objects, communication between objects and validation of data.

Responsibility : something that a class knows or does. Some guidelines that can be applied for allocating responsibilities to classes are:
- System intelligence should be distributed across classes to best address the needs of the problem.
- Each responsibility should be stated as generally as possible.
- Information and the behavior related to it should reside within the same class.
- Information about one thing should be localized with a single class not distributed across multiple classes.
- Responsibilities should be shared among related classes when appropriate.

Collaborator : another class that the class interacts with to fulfill the responsibilities.
- It takes one of two forms : a request for information or a request to do something.
- If a class cannot fulfill all of its obligations itself, then a collaboration is required.
- Collaboration identifies relationship between classes.