Communication Models

Communication models in project management are conceptual representations that describe how information is transmitted, received, interpreted, and confirmed among project stakeholders. They explain the conditions under which a message moves from a sender to a receiver and the points at which meaning can be lost, distorted, or clarified. The concept does not refer to a single diagram or software tool. Rather, it encompasses a family of frameworks that project managers, program managers, and team leads use to diagnose communication breakdowns and design more reliable information flows. In project work, these models underpin communication planning, execution, and monitoring, even when team members are not consciously aware of using them.

The value of a communication model becomes visible when a message that was sent with clear intent produces an entirely different result. A project sponsor may believe that approving a change request in writing is sufficient, while the project team remains uncertain about what the approval means for scope, schedule, and budget. The model directs attention to encoding, channel, noise, feedback, and shared context. Without that structure, a project manager has only intuition to explain why a well-written email did not produce the intended action. This is why the term appears repeatedly in project management standards, from the PMBOK Guide to various Agile guides, even though each framework applies it differently.

Communication Models at a Glance

Key Concept	Summary
Definition	A communication model is a structured framework that maps how information flows from sender to receiver, how the receiver interprets it, and how the sender confirms whether the intended meaning was accurately understood.
Shannon-Weaver Model	The foundational model introduced by Claude Shannon and Warren Weaver describes communication as a linear sequence in which a source creates a message, a transmitter encodes it, a signal moves through a channel, and a receiver decodes it.
Schramm's Model	Wilbur Schramm expanded the linear view by adding feedback and the shared field of experience between sender and receiver, making the model more representative of genuine human interaction.
Noise	Noise is any interference that degrades message clarity, including physical noise, semantic confusion, cultural misalignment, cognitive overload, and technical failures.
Interpretation	A schedule update, risk escalation, scope clarification, or steering committee decision creates value only when the people who need it interpret it correctly and can act on that understanding.
Ambiguity	A project sponsor may believe that a written change request approval is sufficient, while the project team remains uncertain about what the approval implies for scope, schedule, and budget.
Cross-Industry Influence	Beyond project management, communication models have shaped practice in aviation, healthcare, military operations, and manufacturing, where structured information exchange reduces operational risk.
Project Management Application	Project management applies these models by standardizing status reports, change notifications, risk escalations, and stakeholder updates, while also adapting them to softer relational outcomes and longer planning horizons than typical operational environments.

What Is a Communication Model in Project Management?

A communication model definition in project management describes a structured representation of how information moves from a sender to a receiver, how the receiver interprets it, and how the sender learns whether the intended meaning was understood. Communication models do not prescribe specific tools such as email, meetings, or dashboards. They operate at a level above those choices by explaining the sequence of events that must happen for any message to accomplish its purpose. In formal terms, a model usually includes an information source, an encoded message, a channel or medium, a receiver who decodes the message, and some form of feedback. Noise can interfere at any point from the sender’s choice of words to the receiver’s attention, assumptions, or environment.

A familiar analogy is sending a package through a courier service. The sender selects an item, packages it in a way that protects it, chooses a delivery method, and receives a signature or tracking update. If the contents arrive damaged or never arrive, the sender needs to know where the process broke down. The package analogy omits the more complex human aspect of meaning, but it captures why the sequence matters. In project communications, the package is the message, the courier is the communication channel, the signature is feedback, and damage represents distortion or misunderstanding.

Formal Meaning and Scope

Within project management, communication models are often discussed under Project Communications Management. The PMBOK Guide treats them as a tool or technique used during the Manage Communications process. They help a project manager think systematically about sender-receiver dynamics. Although the Guide does not mandate one specific diagram, its discussion incorporates the interactive nature of communication by emphasizing acknowledgment and feedback. The model is therefore a diagnostic lens rather than a deliverable. It supports the creation of a communication management plan but is not the plan itself.

Why the Concept Matters

The concept matters because project outcomes depend on shared understanding. A schedule update, a risk escalation, a scope clarification, or a decision from a steering committee only becomes useful when the people who need it interpret it correctly. This seems obvious until a project manager realizes that a status report read by no one is still considered sent. Communication models give practitioners a repeatable way to think about what happened between sending and understanding. They also provide a vocabulary for explaining communication failures without immediately blaming individuals.

Key Insights on Communication Models

Tracks sender to receiver flow

A communication model traces the path of a message from sender to receiver, clarifies how interpretation shapes meaning, and positions feedback as the mechanism that confirms whether mutual understanding has been achieved.

Applies beyond tool selection

Communication models define the underlying process required for a message to be received successfully, independent of any particular channel or tool such as email, meetings, or dashboards.

Noise can distort any message

Meaning can be distorted at any point by poor word choices, unchecked assumptions on the receiver's side, attention lapses, or environmental distractions, all of which function as noise in the communication process.

Origins and Cross-Industry Context

The origins of communication models lie primarily in mid-twentieth-century information theory and telecommunications research. Early work by Claude Shannon and Warren Weaver introduced a linear model in which an information source produces a message, a transmitter encodes it into a signal, the signal travels through a channel, and a receiver decodes it at the destination. Noise was treated as any interference that could corrupt the signal. This engineering-based view was not designed for human conversation, but its vocabulary spread quickly into organizational and management thinking. Later researchers such as David Berlo added attention to source credibility, message structure, channel selection, and receiver interpretation. Wilbur Schramm introduced feedback and the idea that sender and receiver share a field of experience, moving the model closer to real human interaction.

Cross-Industry Influence

Outside project management, communication models have shaped practice in aviation, healthcare, military operations, and manufacturing. Crew resource management in aviation applies structured, closed-loop communication to prevent misunderstandings in high-risk situations. Healthcare handoff protocols use read-back and confirmation to reduce errors during shift changes. Military after-action reviews rely on feedback loops to build shared understanding after operations. Manufacturing shift handovers and safety briefings use similar patterns. These disciplines did not simply import a diagram; they used communication models to design reliable routines where partial understanding carries severe consequences. Project management borrows this discipline when it standardizes status reports, change notifications, risk escalations, and stakeholder updates, though project communication often involves softer outcomes and longer time horizons.

Key Components of Communication Models

The key components of communication models include the sender, receiver, message, medium, feedback, noise, and context. The sender initiates the communication by translating an intention into words, symbols, images, or actions. That translation is called encoding. The message travels through a selected medium, which might be synchronous, like a face-to-face conversation, or asynchronous, like a written report or recorded video. The receiver decodes the message by interpreting it through personal experience, professional background, language, culture, and emotional state. Feedback closes the loop, allowing the sender to know whether the message was received at all and whether the meaning matched the intent. Noise is any interference that degrades clarity, including physical noise, semantic confusion, cultural misalignment, cognitive overload, and technical issues. Context shapes all of these elements, because the same phrase can carry different weight in a steering committee than in a casual team chat.

Encoding, Decoding, and Shared Meaning

Encoding and decoding are the most underappreciated parts of a communication model in project work. A risk owner may encode a concern using probabilistic language such as there is a moderate chance of delay, while the receiver decodes that as a meaningless hedge. A shared field of experience reduces this gap. Project teams develop shared language through common deliverables, templates, roles, and decision history. When a new team member joins, that shared context is absent, and messages that once seemed obvious become ambiguous. A model helps explain why onboarding communication requires more explicit context and more frequent feedback loops than routine communication among an established team.

The Role of Feedback

Feedback is what distinguishes communication from broadcasting. In a linear model, a project manager can issue a change request and consider the communication complete when the email is sent. In an interactive or transactional model, the communication is not complete until the receiver acknowledges understanding and, where applicable, confirms the intended action. Feedback can be verbal, written, behavioral, or even silence, though silence is often weak evidence. A contractor who does not respond to a scope clarification has not necessarily understood it. The model directs a project manager to seek explicit, observable confirmation before relying on the message as a basis for future work.

Core Insights on Communication Components

Seven essential elements

Communication models are structured around seven interdependent components: sender, receiver, message, medium, feedback, noise, and context, all of which jointly determine how meaning is created, transmitted, and interpreted.

Encoding and decoding roles

The sender translates intent into words, symbols, or actions, and the receiver interprets that message through the lens of personal experience, professional background, language, culture, and emotional state.

Feedback and noise effects

Feedback enables the sender to confirm that the message was both received and accurately understood, whereas noise encompasses physical, semantic, cultural, cognitive, or technical interference that erodes clarity and distorts meaning.

Context and shared language

Context changes how the same phrase is weighted across different environments, and project teams cultivate a shared language through recurring deliverables, templates, roles, and decision history.

Types of Communication Models

The main types of communication models in project management are linear, interactive, and transactional. Linear models describe one-way communication from sender to receiver, with no immediate feedback mechanism. They fit formal announcements, broadcast status updates, or archived project records where the goal is distribution rather than dialogue. Interactive models add a feedback loop, often with a turn-taking structure, such as a question-and-answer session, a review meeting, or a request for approval. Transactional models treat communication as simultaneous and continuous, where both parties are senders and receivers at the same time and meaning is negotiated through body language, tone, interruptions, and evolving context. Most effective project communication sits somewhere between interactive and transactional, though linear messages still have a place for compliance and documentation.

Linear Models

In a linear communication model, the flow is sequential: a sender encodes an idea, transmits it through a channel, and a receiver decodes it. The model is borrowed from early information theory and works reasonably well for one-way notifications such as project announcements, policy changes, and formal contractual notices. Its chief limitation is that it assumes decoding will happen as intended and offers no built-in way to discover otherwise. Project managers who rely exclusively on linear communication often mistake message delivery for message comprehension.

Interactive Models

An interactive communication model introduces feedback into the sequence. The sender transmits a message, the receiver responds, and the sender adjusts the next message accordingly. This turn-taking structure appears in status meetings, design reviews, and risk workshops. The model is more realistic for most project conversations because it recognizes that interpretation is not automatic. It still treats sender and receiver as distinct roles separated in time, which is adequate for structured exchanges but less accurate for fast-moving collaborative work.

Transactional Models

A transactional communication model describes communication as a simultaneous process of mutual influence. Participants create meaning together rather than exchanging prepackaged messages. In a workshop to resolve a technical conflict, the project manager, architect, and business analyst may all speak, sketch, interrupt, and revise their understanding in real time. The message is not simply transmitted; it emerges from the interaction. Transactional models align with high-collaboration Agile environments, negotiation, conflict resolution, and any setting where shared understanding is not just confirmed but built.

Formal, Informal, and Unofficial Communication

Communication models also help distinguish formal and informal flows. Formal communication follows the project’s defined hierarchy and documentation requirements, such as a change control board submission or a contractual notice. Informal communication occurs through ad hoc conversations, hallway discussions, and quick chats that may never be captured in project records. Unofficial communication often carries unverified information and can shape team morale or stakeholder opinion without formal status. A model with strong feedback and context awareness helps a project manager track these different flows rather than assuming that only documented communication matters. In project environments, the most consequential risks sometimes surface through informal channels before they appear in formal reports.

Communication Models in PMBOK

Communication models PMBOK guidance appears within the Project Communications Management knowledge area. In the sixth edition of the PMBOK Guide, communication models are listed as a tool and technique in the Manage Communications process. The model draws attention to encoding, message transmission, decoding, acknowledgment, and feedback. It reminds project managers that a message can be sent through the correct channel and still fail if the receiver lacks the background to interpret it or if noise interferes. The Guide also distinguishes communication models from communication methods and communication technology, even though these elements are used together in practice. The seventh edition of the PMBOK Guide shifts toward principles and performance domains, and communication models are treated as one of several models that help project professionals deliver outcomes in context. The underlying concern remains consistent: projects depend on accurate, timely, and appropriately understood information.

Connection to Communication Processes

Communication models inform the Plan Communications Management, Manage Communications, and Monitor Communications processes. During planning, a project manager uses the model to identify who needs what information, when, through which channel, and with what degree of feedback. During execution, the model helps select an appropriate interaction pattern for each situation. During monitoring, it supports evaluation of whether messages are reaching stakeholders and producing the intended understanding. A common mistake is to isolate communication models as an academic idea. In practice they clarify why a stakeholder matrix, a communication plan, and a well-designed meeting agenda are not enough unless the exchange itself is tested through feedback.

Sender-Receiver Dynamics

The sender-receiver model is the core communication model referenced in PMBOK-style project management. It assumes that the sender is responsible for ensuring the message is clear, choosing an appropriate channel, confirming understanding, and removing barriers. The receiver is responsible for paying attention, decoding, and responding. This division of responsibility may seem simple, but it has practical consequences. A project manager who sends a poorly structured status update and then blames stakeholders for not reading it has failed the sender’s responsibility. At the same time, a stakeholder who ignores an actionable request without responding has broken the feedback loop. The model reveals that communication is a shared obligation, not a one-time event.

Key Takeaways on Communication Models

Tool in Manage Communications

In the sixth edition of the PMBOK Guide, communication models are identified as a tool and technique for the Manage Communications process within the Project Communications Management knowledge area.

Components and failure modes

The model encompasses encoding, transmission, decoding, acknowledgment, and feedback, while recognizing that choosing the correct channel alone cannot prevent failure when the receiver lacks background knowledge or noise disrupts the message.

Distinct from methods and technology

The PMBOK Guide separates communication models from communication methods and communication technology as distinct concepts, even though project teams apply all three together in practice.

Sender accountability and planning

The sender must ensure message clarity, choose an appropriate channel, confirm understanding, and remove barriers, while planning uses the model to identify stakeholder information needs, timing, channel selection, and feedback mechanisms.

Communication Models in PRINCE2

A PRINCE2 communication model is not prescribed as a standalone diagram, but the framework embeds communication thinking directly into its Communication Management Approach. This approach is one of the management products used to define the means, frequency, format, and audience for project communication. PRINCE2 treats communication as a controlled and deliberate activity tied to roles, stages, exception handling, and stakeholder engagement. A project manager using PRINCE2 would not normally draw a Shannon-Weaver diagram for the team. Instead, the communication model emerges from the principles and themes: every message has a defined owner, a defined audience, and a defined expectation of feedback or decision. The emphasis on management by exception also shapes the model, because routine status information is communicated within agreed tolerances, while exceptions trigger escalation through predefined channels.

Communication Management Approach and Feedback

In PRINCE2, the Communication Management Approach is created during the Initiating a Project process and may be refined at stage boundaries. It records stakeholder communication requirements, methods, timing, and owners. The underlying communication model assumes that different stakeholder groups require different information and different channels. Senior users, senior suppliers, and the project board do not need the same level of detail as team managers and specialist resources. Feedback mechanisms such as stage assessments, highlight reports, and end stage reports provide structured points for confirming understanding. PRINCE2’s controlled approach reduces the risk of informal, unverified communication driving project decisions, though it can become bureaucratic if the feedback loops are too slow.

Communication Models in Agile and Hybrid Environments

Communication models in Agile environments tend to be transactional and feedback-heavy rather than linear. The Agile Manifesto’s preference for individuals and interactions over processes and tools is, at its core, a statement about communication. Co-located teams rely on osmotic communication, where team members pick up relevant information by overhearing conversations and observing work in progress. Daily standups, sprint reviews, and backlog refinement sessions are structured feedback loops that verify shared understanding quickly. Information radiators such as task boards and burn charts make work visible without requiring a formal written report. In this setting, the communication model is not a document; it is embedded in the team’s working agreements and cadence.

Scrum, Kanban, and Face-to-Face Communication

Scrum formalizes feedback through the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. Each event is a communication checkpoint with specific participants and a defined purpose. The model assumes that small batches of information discussed frequently reduce the cost of misunderstanding. Kanban uses visual signals and work-in-progress limits to make bottlenecks and blocked work visible, shifting status communication from asking a manager to observing a board. Hybrid environments create more complexity because some team members may be co-located while others are remote, and some stakeholders may expect formal written reports while the team works in short iterations. A hybrid communication model often combines asynchronous written updates with synchronous checkpoints, but the essential insight remains that feedback frequency and shared context determine whether the message lands.

Key Insights on Agile Communication Models

Transactional feedback-heavy model

Agile communication works as a continuous loop of small, feedback-rich exchanges rather than a linear broadcast, making misunderstandings cheaper to catch and correct before they compound.

Osmotic communication value

Co-located teams absorb relevant context through overheard conversations and visible work in progress, reducing day-to-day coordination to informal cues rather than formal written reports.

Visual information radiators

Task boards, burn charts, and work in progress limits act as information radiators that expose bottlenecks and real-time status, shifting communication from asking a manager to reading the board.

Hybrid sync and async blend

Hybrid models pair asynchronous written updates with synchronous checkpoints, but their effectiveness depends less on the format and more on how often feedback loops run and how much context the team shares.

BVOP and Communication Models

The BVOP communication approach connects communication models to value delivery by mandating that brief planning documents be readable by everyone, including new joiners, and by using hiring-and-training-based dependency analysis. In a communication model sense, BVOP treats planning documents as shared boundary objects whose meaning must survive across roles and time, which places a high burden on clarity and accessibility rather than dense jargon.

Communication Models in Practice

In real project work, communication models in practice help project managers diagnose breakdowns before they become disputes. A project manager might notice that the same issue keeps resurfacing in steering committee meetings even though it was covered in a status report. Instead of simply resending the report, the manager can examine the model: the message was sent through a linear channel, the receiver’s context was not considered, no feedback was requested, and the report was competing with significant noise from other projects. The model points to a different approach, such as a brief oral summary with a direct question to confirm the sponsor’s interpretation. This is not a rigid procedure; it is a diagnostic habit.

Where and When It Is Used

Communication models are used throughout the project life cycle. During initiation and planning, they inform stakeholder analysis and the communication management plan. During execution, they shape meetings, reviews, and status reporting. During monitoring and controlling, they help the project manager assess whether change requests, risk responses, and performance data are being understood as intended. During closing, they matter in lessons learned discussions, where the team reflects on which messages were clear and which created repeated confusion. Project managers, program managers, portfolio governance bodies, Agile coaches, and business analysts all use elements of communication models, even when they do not name them. A portfolio manager deciding which projects to escalate to an executive committee is using a communication model when considering the amount of context the committee needs to make a sound decision.

Common Scenarios

Several project scenarios illustrate the practical value of these models. A remote team member misses a design decision because the decision was made in a hallway conversation and never transmitted through a shared channel. A contractor builds the wrong feature because the requirements document used specialist language the contractor decoded differently. A stakeholder becomes hostile after receiving a terse risk notification with no context. In each case, the project manager can trace the failure to encoding, channel selection, noise, feedback, or shared context. The model transforms the postmortem from people are not communicating into an actionable inquiry about which element failed and what correction will prevent recurrence.

Key Insights on Practical Communication Models

Diagnosing recurring communication breakdowns

Applying a communication model allows project managers to trace recurring breakdowns to specific sources such as one-way channels, overlooked receiver context, missing feedback loops, or environmental noise instead of simply repeating the same message.

Model application across project phases

Project managers can apply communication models during initiation and planning to shape stakeholder analysis and the communication management plan, during monitoring and controlling to evaluate how change requests and risk responses are interpreted, and during closing to surface lessons learned about information flow.

Turning blame into actionable correction

Project managers, Agile coaches, and portfolio governance bodies use communication models to replace vague postmortem claims that people are not communicating with precise questions about which element of the model failed and what corrective action will prevent recurrence.

Common Challenges, Pitfalls, and Misconceptions

Several misconceptions about communication models persist in project environments. The most common is that sending a message is the same as communicating it. A project manager who emails a risk register to the sponsor may believe the sponsorship risk is now understood, but unless the sponsor acknowledges the risk in a way that confirms shared meaning, the communication is incomplete. Another misconception is that more communication is always better. More frequent meetings and longer reports can increase noise rather than clarity, especially when the additional messages lack prioritization or audience-specific framing. A third misconception is that a single communication model works for all project stakeholders. Executives, technical teams, vendors, and end users bring different fields of experience, and the same message may need different encoding and channels for each group.

Common Pitfalls

A common pitfall is treating feedback as optional. When a project manager says let me know if you have questions, the absence of questions is often interpreted as understanding, but it may actually indicate that the receiver has not read the message or is reluctant to expose uncertainty. Another pitfall is ignoring noise. Noise is not just a noisy room; it includes competing priorities, unclear terminology, organizational politics, cultural differences, and the sheer volume of project communications. A message that is theoretically clear can become unreadable when it arrives in a cluttered inbox or during a period of urgent operational pressure. Project managers also underestimate context. A steering committee that meets monthly has far less context than a delivery team that meets daily, so the same update requires a different framing for each audience.

When Not to Overapply the Model

Communication models should not be applied as rigid checklists in every interaction. A quick informal chat between a developer and a tester does not require an explicit feedback protocol. Overformalizing communication can slow down decision-making and damage team trust. The model is most useful when the stakes are high, the audience is diverse, the message is complex, or previous communication has failed. In low-risk, high-context, face-to-face situations, the transactional model operates naturally without deliberate analysis. The discipline is knowing when to pause and apply the lens, not turning every message into a formal sender-receiver event.

Communication Models vs Communication Methods

The distinction between communication models vs communication methods is important for project managers. Communication models are conceptual frameworks that explain how meaning is created and confirmed. Communication methods are the specific mechanisms used to exchange information, typically categorized as interactive, push, or pull in PMBOK guidance. Interactive methods include meetings, phone calls, and video conferences. Push methods include emails, memos, and reports sent to stakeholders. Pull methods include document repositories, dashboards, and intranet sites where stakeholders retrieve information as needed. A communication model informs the choice among these methods by clarifying whether the situation requires immediate feedback, one-way distribution, or self-service access.

Connections to Communication Planning and Stakeholder Engagement

Communication models also relate closely to the communication management plan, stakeholder engagement plan, and stakeholder register. The stakeholder register identifies individuals and groups, their interests, influence, and communication requirements. The engagement plan defines how the project will involve them. The communication management plan operationalizes the chosen methods, timing, and owners. The underlying model explains why those choices matter. It sits behind the artifacts, not as a deliverable but as a reasoning tool. For example, a stakeholder engagement assessment matrix may show that an important sponsor is unaware of project progress. The communication model helps the project manager decide whether a pull-based dashboard is sufficient or whether a synchronous feedback-rich conversation is required.

Difference from Information Management and Communication Skills

Communication models are sometimes confused with information management systems and communication skills. Information management systems handle the storage, retrieval, distribution, and security of project information. They are tools or platforms. Communication skills such as active listening, facilitation, persuasion, and presentation technique are individual competencies. The model is neither a system nor a skill, though it uses both. A skilled communicator can still fail if the model is wrong, such as choosing an asynchronous channel for a message that requires negotiation and real-time feedback. Likewise, a perfect information system cannot compensate for a sender who encodes a message in language the receiver does not share. These distinctions help project managers allocate effort correctly across technology, skills, and conceptual design.

Key Takeaways on Communication Choices

Models frame, methods deliver

Communication models explain how messages are encoded, transmitted, and interpreted, while methods are the specific channels used to deliver information to stakeholders.

Three method categories exist

PMBOK guidance categorizes communication methods by information flow: interactive exchanges such as meetings and video calls enable simultaneous dialogue, push channels such as emails and memos distribute information outward, and pull options such as dashboards and intranet repositories allow users to retrieve information on demand.

Model guides method selection

The communication model clarifies whether a situation requires immediate feedback, one-way distribution, or self-service access, and this decision informs both the stakeholder register and the communication management plan.

Evolution and Current Thinking

The evolution of communication models in project management reflects a move from linear, mechanistic thinking toward dynamic, context-sensitive, and human-centered understanding. Early project communication often relied on formal memos, hierarchical reporting, and one-way distribution. As project teams became more cross-functional and geographically dispersed, the limitations of linear models became obvious. Interactive and transactional models gained relevance, especially in Agile and hybrid delivery. Modern thinking also recognizes the role of psychological safety, emotional intelligence, cognitive load, and cultural context in determining whether a message is actually understood. A project manager can no longer assume that a clear email is clear simply because it uses correct grammar.

Digital and Asynchronous Communication

Digital tools have changed the channel landscape without removing the need for communication models. Instant messaging, shared workspaces, video calls, and AI-assisted summaries compress time but do not guarantee shared meaning. Asynchronous communication allows global teams to collaborate across time zones, yet it also removes the immediate nonverbal cues and feedback loops that transactional models rely on. Modern communication practice therefore balances asynchronous documentation with synchronous checkpoints. A distributed team may use a written decision record for traceability, then verify understanding in a short video call or through an explicit acknowledgment protocol. The model has not disappeared; it has become more important because the channels are more diverse and the potential for noise is higher.

Current Debates and Context Sensitivity

There is no single universally accepted communication model in project management. Different schools of thought emphasize different aspects. Some practitioners prefer structured sender-receiver discipline for high-stakes project governance. Others argue that too much structure stifles the informal, trust-based communication that actually makes projects work. The truth is situational. In regulated environments with contractual obligations, linear and interactive models with documented feedback loops remain necessary. In creative or exploratory project phases, transactional and informal communication may produce faster and better outcomes. Best practice is not to choose one model permanently, but to recognize the model implied by the project context, the stakeholders, the phase, and the risk of misunderstanding, then adjust the approach accordingly.