Audience, Purpose, Context, and Communication Planning

Introduction

Communication is not simply the transmission of information. It is the purposeful design of meaning for particular people, in particular circumstances, through particular channels. A technically accurate message can still fail if it is addressed to the wrong audience, uses an inappropriate level of detail, ignores cultural expectations, or asks recipients to take an unclear action.

For full-stack developers, communication is central to professional practice. Developers explain technical decisions to product owners, report progress to managers, document APIs for other developers, present prototypes to clients, write release notes for users, and collaborate with designers, testers, security specialists, and operations teams. These groups differ in expertise, authority, interests, risks, and expectations. Effective communication therefore begins before drafting or speaking: it begins with analysis and planning.

This chapter presents a practical and analytical approach to communication planning. It examines audience analysis, stakeholder mapping, purpose, context, constraints, culture, channel selection, tone, personas, purpose statements, and communication briefs. It also considers ethical issues, accessibility, digital communication, and the responsible use of artificial intelligence.

Learning objectives

By the end of this chapter, you should be able to:

• distinguish audience, stakeholder, purpose, context, channel, medium, and tone;
• analyse the knowledge, interests, authority, needs, and risks of an audience;
• identify primary, secondary, internal, external, expert, and non-expert stakeholders;
• formulate precise purpose statements and measurable communication objectives;
• select communication channels according to message complexity, urgency, sensitivity, and need for interaction;
• adapt language, structure, examples, and tone without compromising accuracy or integrity;
• prepare an audience persona and a communication brief;
• evaluate cultural, ethical, accessibility, and governance considerations; and
• apply a systematic planning process to a realistic software-development scenario.

Communication as a designed activity

A useful starting point is the communication situation. Every situation contains at least five connected elements:

1. Communicator: the person or organisation creating the message.
2. Audience: the people expected to interpret, use, evaluate, or respond to it.
3. Purpose: the intended result of the communication.
4. Message: the ideas, evidence, instructions, or decisions being communicated.
5. Channel and context: the route and circumstances through which communication occurs.

Communication is successful when the audience can interpret the message sufficiently accurately and respond in a way that supports the intended purpose. This does not mean that every recipient must interpret every nuance identically. It means that important meanings, actions, responsibilities, and constraints are clear enough for the situation.

The traditional sender–message–receiver model is useful but incomplete. It may imply that meaning travels in a straight line from sender to receiver. In practice, communication is interactive. Audiences interpret messages through prior knowledge, assumptions, language, emotion, organisational position, and cultural experience. Feedback may be immediate, delayed, indirect, or absent. Noise may include technical jargon, poor audio, conflicting priorities, inaccessible formatting, ambiguous wording, or distrust of the sender.

A communication plan should therefore answer four questions:

• Who needs to understand or act?
• Why is communication necessary now?
• What must the audience know, feel, decide, or do?
• What form and channel will produce the most reliable result?

Audience analysis

Audience categories

An audience may be classified in several overlapping ways. These classifications are not labels for stereotyping; they are prompts for investigation.

The primary audience is the group whose understanding or action is most important. A secondary audience may use the message later, influence the primary audience, or be affected by the outcome. A gatekeeper controls access to a decision, resource, platform, or approval. For example, a development team may be the primary audience for an API specification, while security reviewers and operations staff are secondary audiences.

What to analyse

Audience analysis should go beyond demographic description. The following questions are more useful:

• What does the audience already know?
• What do they need to know, and what can safely be omitted?
• What decision or action is expected?
• What motivates or concerns them?
• What authority do they possess?
• What objections or misconceptions are likely?
• What terminology will they understand?
• What evidence will they consider credible?
• What constraints affect their attention, time, access, or response?
• What consequences will follow if they misunderstand the message?

A developer writing for other developers can refer to endpoints, authentication, and error codes with limited explanation. A client may need the same information expressed through user outcomes, cost, risk, delivery impact, and business value. Neither audience is inherently more important; they require different representations of the same underlying reality.

Audience personas

An audience persona is a concise, evidence-informed representation of a typical audience member. It is not a fictional biography and should not be based on unsupported assumptions. A useful persona includes:

• role and relationship to the project;
• relevant knowledge and experience;
• goals and responsibilities;
• likely concerns or barriers;
• preferred information format and channel;
• expected action; and
• accessibility or language considerations.

For example:

Persona: Priya, customer-support lead

Priya supports 25 service agents who will use a new case-management interface. She understands customer workflows but is not a software engineer. Her priorities are reduced handling time, reliable search, training effort, and clear escalation procedures. She needs a demonstration, a short workflow guide, and evidence that existing customer records will not be lost. Her likely concern is disruption during migration. She can approve training materials but cannot approve the technical architecture.

This persona helps a communicator decide what to explain, what evidence to provide, and what action to request. It does not justify treating all customer-support employees as identical. Personas should be checked against interviews, observations, support data, usability testing, or other evidence where possible.

Stakeholders and stakeholder analysis

A stakeholder is a person, group, or organisation that can affect a project, is affected by it, or believes it may be affected by it. Stakeholders may include users, clients, developers, managers, suppliers, regulators, accessibility advocates, security teams, and members of the public.

Stakeholder analysis identifies relationships and communication priorities. A simple matrix considers influence and interest:

This matrix is a planning aid rather than a rule. A person with low formal authority may possess critical expertise or represent a legally protected interest. Similarly, a user group with limited organisational power may experience the greatest consequences. Stakeholder analysis should therefore include impact, vulnerability, and ethical significance, not only organisational power.

A stakeholder register can record the stakeholder, interests, influence, information needs, risks, preferred channel, owner, and communication frequency. It should be updated as a project changes. Communication planning is not a one-time administrative exercise.

Purpose and objectives

Purpose statements

A purpose statement expresses why a communication exists. Weak purposes describe the topic: “This presentation is about the new platform.” Strong purposes describe the intended outcome: “To enable product managers to approve a phased migration by explaining the benefits, risks, cost assumptions, and rollback plan.”

A practical structure is:

To [action or outcome] for [audience] by [content, evidence, or approach].

Examples include:

• To enable junior developers to configure authentication safely by demonstrating the approved workflow and common failure conditions.
• To obtain client approval for a revised delivery date by explaining the cause, impact, recovery options, and decision required.
• To help end users complete account recovery by providing an accessible, step-by-step guide with warnings about fraudulent messages.

The purpose should identify the desired audience response. That response may involve understanding, deciding, approving, performing, changing an attitude, or providing feedback.

Communication objectives

Objectives make purpose more observable. An objective may specify what the audience should be able to do after communication. For example:

After the briefing, product owners will be able to identify the three major migration risks, compare two mitigation options, and approve one option or request further evidence.

The verbs should be meaningful and observable: identify, compare, configure, approve, demonstrate, report, test, or decide. Avoid vague verbs such as “know” or “understand” unless they are clarified through observable evidence.

A communication objective is not the same as a project objective. A project objective may be to reduce failed payments; a communication objective may be to enable support staff to explain the new payment-retry process accurately.

Context and constraints

Context is the set of circumstances that shapes interpretation. Important contextual factors include:

• Physical or digital setting: boardroom, video call, code repository, mobile application, help centre, or social platform.
• Timing: routine planning, emergency response, product launch, incident recovery, or regulatory deadline.
• Relationship: peer-to-peer, manager-to-employee, vendor-to-client, or public institution-to-citizen.
• Organisational climate: trust, conflict, uncertainty, change fatigue, or previous communication failures.
• Cultural environment: language conventions, power distance, attitudes to disagreement, time orientation, and expectations about formality.
• Risk level: the consequences of misunderstanding, delay, disclosure, or non-compliance.

Constraints may be fixed or negotiable. Common constraints include limited time, word count, budget, staff availability, confidentiality, accessibility, platform capability, legal obligations, and uneven internet access. A skilled communicator does not merely complain about constraints; they redesign the message around them.

For example, an incident update during a service outage must prioritise verified facts, user impact, immediate actions, and the next update time. A long explanation of architectural history may be valuable later but is not appropriate in the first alert.

Choosing channels and media

A channel is the route through which communication occurs, such as email, meeting, documentation, chat, telephone, or a presentation. A medium is the form in which the message is represented, such as text, speech, video, diagram, or interactive demonstration. In everyday use the terms overlap, but distinguishing them helps planning.

Channel selection should consider the message and the communication task, not personal habit. The following criteria are useful:

A short chat message may be appropriate for a routine status update. A complex architectural decision may require a written decision record followed by a discussion. A performance concern may require a private conversation rather than a public channel. A user instruction may need searchable, accessible documentation rather than a one-time presentation.

Channel richness is the capacity of a channel to convey cues, permit immediate feedback, and support clarification. Face-to-face and live video interaction are relatively rich; a static notice is relatively lean. Richer channels are often useful for ambiguity, emotion, conflict, and negotiation. Leaner channels are efficient for routine, unambiguous, and widely distributed information. Richness alone does not determine quality: a live meeting without a record may be less effective than a concise document plus a focused meeting.

A multichannel strategy is often strongest. For example:

1. send a concise announcement;
2. provide a detailed, accessible document;
3. hold a question-and-answer session;
4. record decisions and responsibilities in a shared system; and
5. follow up with reminders or feedback collection.

Message structure and information design

Audience-centred structure reduces cognitive effort. A message should make its purpose visible early, organise information logically, and distinguish essential content from supporting detail.

A practical structure for many professional messages is:

1. Situation: What is happening?
2. Significance: Why does it matter to this audience?
3. Evidence: What facts, examples, or constraints support the message?
4. Action or decision: What should the audience do?
5. Support: Where can they obtain help or further information?

The order can change according to context. In an emergency, the required action may come first. In a persuasive proposal, the problem and value may precede the recommendation. In technical documentation, prerequisites and a tested procedure may come before explanation.

Use headings, short paragraphs, tables, diagrams, examples, and meaningful lists to reveal relationships. Do not confuse visual simplicity with intellectual simplification. A message can be easy to navigate while retaining technical accuracy.

Layering information

Layering presents information at different depths:

• Layer 1: purpose, key result, decision, or immediate action;
• Layer 2: essential explanation, evidence, responsibilities, and risks;
• Layer 3: technical details, assumptions, data, references, and exceptions.

Layering allows a senior decision-maker to obtain the central point quickly while enabling specialists to audit the reasoning. It also supports responsive presentations: the communicator can move deeper when questions indicate the need.

Tone, language, and cultural intelligence

Tone is the attitude conveyed by language and delivery. It may be formal, conversational, reassuring, urgent, neutral, assertive, empathetic, or instructional. Appropriate tone depends on purpose, relationship, risk, and culture.

Tone should not be confused with politeness alone. An excessively cheerful tone during a serious security incident may undermine trust. Excessive informality with an external client may appear careless. Excessive formality in a collaborative technical team may suppress questions.

Effective language is:

• precise enough to avoid harmful ambiguity;
• appropriate to the audience’s knowledge;
• inclusive and free from unnecessary stereotypes;
• direct about responsibility and action;
• respectful when disagreement is necessary; and
• honest about uncertainty.

Technical language is not automatically professional. Jargon is justified when it increases precision for a knowledgeable audience. When communicating across expertise levels, define essential terms, avoid unexplained acronyms, and connect technical features to consequences.

Cultural intelligence involves recognising that communication norms differ. Eye contact, silence, interruption, disagreement, titles, humour, directness, and attitudes toward hierarchy can carry different meanings. A communicator should avoid turning cultural knowledge into rigid rules. Instead, investigate preferences, observe respectfully, provide multiple ways to contribute, and make important expectations explicit.

Inclusive communication also requires attention to disability and access. Use readable contrast, meaningful headings, captions or transcripts for audio and video, descriptive alternative text where appropriate, keyboard-accessible materials, plain-language summaries, and documents that work with assistive technologies. Accessibility is both an ethical responsibility and a quality characteristic: accessible content is often easier for everyone to search, understand, and reuse.

The communication brief

A communication brief converts analysis into an actionable plan. It should be concise enough to use during drafting but detailed enough to prevent avoidable mistakes.

The brief is not the final message. It is a design document. It should be revised when new evidence, stakeholders, risks, or constraints emerge.

A planning process

A reliable communication planning process can be organised into eight stages.

1. Diagnose the situation

Define the event, problem, decision, or opportunity. Establish what is known, unknown, urgent, sensitive, and changeable.

2. Map audiences and stakeholders

Identify who is affected, who has authority, who has expertise, who may be excluded, and who must be consulted. Distinguish the primary audience from people who merely receive a copy.

3. Define purpose and objectives

Write a purpose statement and specify the expected audience response. Ensure that the objective is realistic for the communication available.

4. Determine content and evidence

Separate essential information from useful background. Verify facts, sources, assumptions, dates, numbers, and responsibilities. Do not fill gaps with speculation.

5. Select channel and format

Match channel to urgency, complexity, sensitivity, feedback needs, reach, permanence, and accessibility. Consider whether multiple channels are required.

6. Design the message

Choose structure, level of detail, examples, visuals, terminology, tone, and calls to action. Apply information layering.

7. Test and revise

Ask a representative reader or listener to identify the purpose, required action, and remaining questions. Where consequences are significant, conduct usability testing or a formal review.

8. Deliver, document, and evaluate

Record decisions, owners, deadlines, and unresolved issues. Evaluate whether the audience took the intended action, not merely whether the message was sent or viewed.

Useful evaluation questions include:

• Did the intended audience receive and access the message?
• Could they identify the main point and required action?
• Did they act correctly and within the required timeframe?
• What misunderstandings or questions arose?
• Was the channel suitable?
• What should be changed in the next communication?

Worked example: planning a migration communication

A development team is migrating a small retailer’s customer accounts from a legacy system to a new platform. The migration may require a two-hour maintenance window. The team must communicate with the client’s executive sponsor, customer-support staff, internal developers, and end users.

Situation analysis

The migration offers improved search and security but creates risks of downtime, failed data transfer, and support confusion. The executive sponsor needs a decision and confidence in risk control. Support staff need operational procedures. Developers need precise technical responsibilities. End users need clear notice and instructions, but they do not need database details.

Audience and purpose analysis

The overall purpose is to coordinate a safe migration while enabling informed approval and reducing user disruption. Each audience requires a different purpose statement.

Communication design

The executive brief should begin with the recommendation, proposed date, expected downtime, principal risks, mitigations, rollback trigger, and approval required. The support guide should use user-facing symptoms and step-by-step responses. The developer plan should include owners, dependencies, test evidence, monitoring, and rollback procedures. The end-user notice should use plain language, a prominent time window, a description of unavailable services, and a support contact.

The team should not send one universal message to everyone. A single message would either overwhelm end users with technical details or leave developers without sufficient operational information. Consistency is still important: dates, service names, risk descriptions, and contact routes must agree across channels.

Evaluation

Before release, a support representative reviews the guide by attempting common tasks, a non-technical client representative explains the executive brief in their own words, and an accessibility check is performed on the user notice. After migration, the team reviews support contacts, failed transactions, downtime, and stakeholder feedback. These measures reveal whether communication supported the operational objective.

Case study: an illustrative product launch scenario

Background

A university software team develops a mobile attendance application. The product team plans to launch it to students and teaching staff at the beginning of term. The application collects attendance information and sends reminders. A launch presentation is prepared for senior administrators, while a separate message is needed for students.

Problem

The initial draft uses technical language about event-driven services, token expiry, and data schemas. It explains how the system works but does not state what administrators must approve or what students must do. It also assumes that all users have modern smartphones and uninterrupted internet access.

Analysis

Administrators are decision-makers concerned with privacy, reliability, cost, and implementation risk. Teaching staff are implementers concerned with attendance workflows and support. Students are end users concerned with ease, fairness, privacy, and access. Students with disabilities, older devices, limited data, or intermittent connectivity may experience different risks. The communication therefore has multiple purposes and cannot be reduced to a single presentation.

Approach

The team creates three communication briefs. The administrator brief requests approval of a staged launch and presents evidence from a pilot, privacy controls, support capacity, and a contingency plan. The staff guide provides screenshots, a short procedure, common errors, and an escalation route. The student message explains what information is collected, how to check or correct an attendance record, what to do if the application is unavailable, and where to obtain a non-digital alternative.

The team uses a live briefing for questions with administrators, a searchable guide for staff, and an accessible multi-channel notice for students. The student notice avoids implying that ownership of a particular device is a condition of participation. It provides a support route and states how concerns will be handled.

Outcome

The staged launch is approved. During the first week, support requests reveal that the phrase “confirm your presence” is ambiguous: some students believe it means location tracking is active. The team revises the wording to explain exactly what data is collected and what is not. This demonstrates why communication evaluation must examine interpretation, not simply delivery.

Learning points

• A technical description is not automatically an effective stakeholder message.
• Different audiences may require different channels and levels of detail.
• Privacy, accessibility, and alternative access routes should be planned from the beginning.
• Testing language with representative users can reveal meanings that the project team did not anticipate.
• Trust depends on accurate disclosure of limitations as well as benefits.

Ethics, governance, and responsible technology use

Communication planning has ethical consequences. Communicators should not manipulate audiences through selective evidence, false urgency, hidden costs, misleading visuals, or unsupported claims. They should distinguish facts, estimates, opinions, assumptions, and recommendations. Uncertainty should be stated when it affects decisions.

Privacy requires careful handling of personal, confidential, and commercially sensitive information. Share only what the audience needs for a legitimate purpose. Use appropriate access controls and avoid placing sensitive material in informal channels. Retain records in accordance with organisational and legal requirements.

In software development, communication may also support regulatory compliance, security, accessibility, consumer protection, and auditability. A decision record should make important assumptions, approvals, risks, and responsibilities traceable. Exact legal obligations vary by jurisdiction and sector, so professional communicators must consult applicable policies and qualified advisers rather than assuming that a general template is sufficient.

Artificial intelligence can assist with brainstorming audience questions, restructuring a draft, generating plain-language alternatives, or checking consistency. However, AI-generated text may contain fabricated facts, inappropriate tone, cultural bias, privacy risks, or inaccessible output. A professional remains responsible for verification, confidentiality, attribution, and final judgement. Sensitive information should not be entered into an AI system unless authorised. AI should support audience-centred thinking, not replace consultation with real stakeholders.

Challenges and limitations

Audience analysis is valuable but imperfect. Stakeholders are not homogeneous, personas may become outdated, and power relationships can influence whose preferences are heard. A communicator may also over-adapt a message and remove necessary complexity. Simplicity must not become distortion.

Channel frameworks are similarly limited. A supposedly rich channel may be inaccessible or intimidating; a written channel may enable thoughtful participation for people who do not speak easily in meetings. Communication plans can also create excessive meetings, duplicated updates, and notification fatigue. The solution is not maximum communication but purposeful communication with clear ownership and review.

Cultural adaptation presents a further challenge. Treating national or organisational culture as a fixed set of traits can produce stereotypes. Cultural intelligence is better understood as curiosity, respect, flexibility, and willingness to verify assumptions.

Finally, communication cannot solve every organisational problem. If a product is unsafe, a deadline is impossible, or responsibilities are contradictory, better wording alone will not remove the underlying issue. Communication planning should expose such problems rather than conceal them.

Best-practice checklist

Before sending or delivering a professional message, ask:

• Is the primary audience clearly identified?
• Is the purpose expressed as an intended outcome?
• Is the required action explicit, assigned, and dated where relevant?
• Have knowledge, authority, concerns, and access needs been considered?
• Are facts, assumptions, estimates, and uncertainties distinguished?
• Is the channel appropriate for urgency, complexity, sensitivity, feedback, and permanence?
• Is the tone suitable to the relationship and situation?
• Are technical terms defined or removed where unnecessary?
• Can the message be accessed and understood by people with different abilities and circumstances?
• Has a representative person reviewed or tested it?
• Is there a reliable route for questions, feedback, correction, and escalation?
• Does the message preserve privacy, honesty, and professional accountability?

Chapter Summary

Effective communication begins with analysis rather than delivery. A communicator must identify the primary and secondary audiences, understand stakeholder interests and authority, define a purposeful outcome, and account for context, constraints, culture, accessibility, and risk. Audience personas help represent typical needs, while stakeholder matrices reveal communication priorities and relationships.

Purpose statements should describe what the communication is intended to achieve, and communication objectives should express observable audience responses. Channel selection should reflect urgency, complexity, sensitivity, feedback requirements, reach, permanence, and accessibility. Tone and technical language must be adapted without sacrificing accuracy or ethical integrity.

A communication brief provides a practical bridge between analysis and message design. The planning process involves diagnosing the situation, mapping stakeholders, defining objectives, selecting evidence and channels, designing and testing the message, and evaluating audience response. In full-stack development, these practices support requirements work, technical documentation, incident communication, product demonstrations, stakeholder decisions, user support, and responsible technology adoption.

Key Terms

Audience: People expected to interpret, use, evaluate, or respond to a communication.

Audience analysis: Systematic examination of an audience’s knowledge, needs, authority, interests, concerns, and access conditions.

Audience persona: An evidence-informed representation of a typical audience member used to guide communication design.

Channel: The route through which communication is delivered, such as email, meeting, documentation, or chat.

Communication brief: A planning document that records situation, audience, purpose, message, channel, tone, constraints, and evaluation.

Communication objective: An observable response that the audience should produce after communication.

Context: The circumstances, relationships, timing, culture, and environment that shape interpretation.

Gatekeeper: A person or group controlling access to a decision, resource, platform, or approval.

Information layering: Presenting essential information first and supporting detail at progressively deeper levels.

Medium: The representational form of a message, such as text, speech, video, or diagram.

Noise: Anything that interferes with accurate interpretation, including jargon, technical failure, ambiguity, or distraction.

Primary audience: The audience whose understanding or action is most important to the communication purpose.

Purpose statement: A concise statement of the intended outcome of a communication.

Secondary audience: People who influence, reuse, review, or are affected by a communication but are not its main target.

Stakeholder: A person, group, or organisation that can affect, is affected by, or believes it may be affected by an activity or decision.

Stakeholder matrix: A planning tool that compares stakeholder characteristics such as influence and interest.

Tone: The attitude conveyed by a message’s language and delivery.

Accessibility: The degree to which content can be perceived, understood, navigated, and used by people with diverse abilities and circumstances.

Review Questions

Short Answer Questions

1. What is the difference between a primary audience and a secondary audience?
2. Identify four factors that should influence channel selection.
3. What is the purpose of an audience persona?
4. Why should a purpose statement describe an intended outcome rather than merely a topic?
5. State two ethical risks associated with professional communication.

Long Answer Questions

1. Explain how audience knowledge, authority, motivation, and risk should influence the design of a technical presentation.
2. Describe the eight-stage communication planning process and explain why testing is necessary before delivery.
3. Compare a stakeholder matrix with an audience persona. What does each tool reveal, and what are its limitations?
4. Explain how culture and accessibility affect tone, language, channel, and message structure.
5. Discuss why a multichannel communication strategy may be more effective than a single universal message in a software project.

Analytical / Application Questions

1. You must announce a two-hour service outage to executives, developers, support staff, and end users. Prepare a brief audience analysis and recommend a channel and tone for each group.
2. A client says that a project update is “too technical,” while the development team says it is “too vague.” Analyse the likely communication problem and propose a revised structure using information layering.
3. Create a communication brief for introducing an AI-assisted coding tool in a university development team. Include stakeholders, purpose, risks, channel, accessibility considerations, and an evaluation method.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a strong communication purpose?

A. To discuss the new software platform

B. To provide many technical details about the project

C. To enable product owners to approve a migration by explaining its risks and mitigation options

D. To make the presentation visually attractive

Correct Answer: C. To enable product owners to approve a migration by explaining its risks and mitigation options

Question 2

A person who controls access to a project approval is best described as a:

A. Primary audience

B. Gatekeeper

C. Secondary medium

D. Message receiver

Correct Answer: B. Gatekeeper

Question 3

Which audience characteristic most directly determines how much technical terminology should be explained?

A. Audience knowledge and expertise

B. Office location

C. Presentation colour scheme

D. Length of the project

Correct Answer: A. Audience knowledge and expertise

Question 4

Which channel is generally most appropriate for negotiating an ambiguous and sensitive issue?

A. A public social-media post

B. A private interactive conversation

C. An unattended noticeboard

D. A generic automated email

Correct Answer: B. A private interactive conversation

Question 5

What is the primary function of a communication brief?

A. To replace all stakeholder consultation

B. To record the plan for designing and delivering a message

C. To provide a final legal contract

D. To measure software performance

Correct Answer: B. To record the plan for designing and delivering a message

Question 6

Which statement about audience personas is most accurate?

A. They classify every member of an audience as identical

B. They are evidence-informed representations of typical audience needs

C. They are only useful for advertising campaigns

D. They eliminate the need for testing communication

Correct Answer: B. They are evidence-informed representations of typical audience needs

Question 7

In information layering, which content normally belongs in the first layer?

A. Every technical exception

B. The central purpose, result, or required action

C. An archive of all project correspondence

D. Unverified background speculation

Correct Answer: B. The central purpose, result, or required action

Question 8

Which practice best supports ethical communication?

A. Hiding uncertainty to increase confidence

B. Using urgency even when no deadline exists

C. Distinguishing facts, assumptions, estimates, and recommendations

D. Sharing confidential data to demonstrate transparency

Correct Answer: C. Distinguishing facts, assumptions, estimates, and recommendations

Question 9

A stakeholder with high influence and high interest should generally be:

A. Engaged closely

B. Ignored until the project ends

C. Given only public announcements

D. Excluded from decisions

Correct Answer: A. Engaged closely

Question 10

Which is an appropriate use of artificial intelligence in communication planning?

A. Submitting unverified AI-generated facts directly to a client

B. Entering confidential stakeholder data without authorisation

C. Generating draft alternatives that a professional then verifies and revises

D. Allowing AI to make all final ethical decisions

Correct Answer: C. Generating draft alternatives that a professional then verifies and revises