Project Stakeholder and Communication Management (Rhodes MAN Module) Exam Notes

Project Stakeholder and Communication Management is one of the core competencies assessed in the Rhodes University Project Management & Leadership space—particularly within modules often delivered as MAN (Management) and aligned to the project management knowledge areas. This topic focuses on identifying stakeholders, analyzing their influence and interest, planning what each stakeholder needs, and ensuring project information flows accurately and on time through structured communication processes. Strong exam answers typically show you understand both the tools (stakeholder registers, power/interest grids, communication matrices) and the behavioural side (managing expectations, avoiding information overload, building trust, and choosing the right channel and frequency).

These notes are written for exam preparation in a way that also matches how South African universities structure answers, including concepts commonly taught in modules such as MAN 0001/0002-style introductory management, and aligned project communication content you may see in UNISA project management and CUT management/leadership related learning outcomes (even when the exact code differs). Use these notes to build coherent “mark-earning” responses: definitions → processes → tools → examples → risks/mitigation → mini-answers for common exam prompts.

Stakeholder Identification, Analysis, and Mapping (Rhodes MAN Module)

Stakeholder management begins long before any communication plan is written. In most Rhodes-style exam questions, the assessor expects you to demonstrate a structured approach: identify stakeholders, categorize them, analyze influence, and translate findings into communication and engagement strategies. A frequent “high marks” pattern is to explicitly link stakeholder analysis to communication decisions (e.g., “because this group has high power and high interest, we communicate frequently and involve them in key decisions”).

What counts as a stakeholder?

A stakeholder is any individual, group, or organization that can affect the project or is affected by it. Stakeholders are not only “clients” or “sponsors.” In a project environment, stakeholders usually include:

Project sponsor / executive / steering committee
Project manager and project team
Customers / end users
Functional departments (HR, procurement, engineering, finance, IT)
Regulators and government bodies
Contractors and subcontractors
Community / local interest groups
Suppliers and vendors
Internal leadership impacted by resource allocation
Vendors of dependent systems (e.g., software, infrastructure)

A key exam point: stakeholders may change over time. Someone who starts as “low interest” can become “high power” if they control approvals, budget releases, or compliance sign-off later in the project.

The stakeholder management process in practical terms

A typical project stakeholder management flow can be written as a staged process:

Identify stakeholders
Plan stakeholder engagement
Manage stakeholder engagement
Monitor stakeholder engagement

Exams often reward you if you add that this process is iterative: you keep revisiting the stakeholder register as the project evolves.

Stakeholder identification methods (what examiners expect)

Common identification methods include:

Stakeholder interviews (structured conversations with key people)
Workshops with cross-functional teams (to surface “unknown stakeholders”)
Document review: charters, contracts, organisational plans, policy requirements
Brainstorming (often combined with influence mapping)
Historical data: lessons learned from similar projects
Assumption and risk review: people impacted by risks are often stakeholders

A strong answer clarifies that identification is not “one meeting then done.” It’s a discovery process. For example, procurement may know a vendor will be capacity constrained, while compliance may reveal an approval authority that was not initially listed.

Power/interest mapping (the classic exam tool)

One of the most commonly taught stakeholder analysis tools is the power/interest grid, which classifies stakeholders by:

Power: ability to influence project outcomes (e.g., approve budget, block progress, enforce compliance)
Interest: degree of concern or involvement in project outcomes

This produces four typical quadrants:

High power, high interest: Manage closely (high engagement)
High power, low interest: Keep satisfied (ensure minimal risk)
Low power, high interest: Keep informed (communication without heavy involvement)
Low power, low interest: Monitor (low effort, watch for changes)

Example (mapping in a university project setting)

Imagine a hypothetical Rhodes-aligned project: implementing a learning management system upgrade across multiple faculties. Stakeholders may include:

Executive sponsor (high power, high interest)
IT department (high power, high interest or high power, low interest depending on involvement)
Faculty coordinators (high interest, low/moderate power)
Students (high interest, low/moderate power in governance terms)
Regulatory/privacy office (high power, low interest until compliance review dates)
Vendors (high power in technical delivery, varying interest levels)

In exam answers, you should explicitly show how you would tailor communication for each quadrant.

Stakeholder attributes beyond power and interest

High-grade exam responses often go beyond power/interest by including additional stakeholder attributes such as:

Influence and authority (formal vs informal authority)
Attitude toward the project (supportive, neutral, resistant)
Impact level (how strongly they are affected)
Risk sensitivity (concerned about compliance, time, cost, quality)
Urgency (who needs information immediately)
Communication needs (technical vs non-technical understanding)
Cultural or language considerations (especially in South African multi-stakeholder contexts)
Relationship strength between stakeholders and the project team

A useful exam phrasing

“Stakeholder influence determines what they can block or accelerate; stakeholder interest determines how often and how detailed our engagement should be. Therefore, both attributes shape the communication frequency, channel, and level of involvement.”

Stakeholder register: what it contains and why it matters

A stakeholder register is a structured document listing stakeholders and key information. A typical register entry includes:

Stakeholder name / role
Organisation or department
Contact details (often phone/email in practice)
Influence/power rating
Interest rating
Impact level (high/medium/low)
Current engagement level
Preferred communication method
Language preferences (if relevant)
Potential concerns or requirements
Engagement strategy (e.g., manage closely, keep satisfied)
Owner (who is responsible for managing that stakeholder)
Notes and updates

Why examiners like registers

Registers show discipline. They transform stakeholder management from “general talk” into actionable planning. In many marking schemes, an answer with a well-structured register template earns marks because it’s directly aligned to how projects are run in real organisations.

Common stakeholder risks you can mention in exams

Stakeholders introduce risks—many candidates forget to connect stakeholder analysis to risk management. Add these risks:

Resistance to change (fear of job loss or process disruption)
Unclear decision rights (stakeholders who can delay approvals)
Conflicting stakeholder objectives (e.g., cost vs quality)
Misaligned incentives (departmental KPIs conflict with project goals)
Information asymmetry (some stakeholders are informed too late)
Communication overload (stakeholders ignore messages due to volume)
Hidden stakeholders (missed regulators or procurement stakeholders)

A high marks response explains mitigation: early engagement, clear communication matrices, decision logs, and escalation pathways.

Stakeholder Engagement Planning and Communication Strategy (Rhodes MAN Module)

This section converts stakeholder analysis into engagement and communication planning—where exam questions often focus: “Design a communication plan,” “Explain engagement strategies,” “Discuss methods and frequency,” or “Analyse communication risks.”

A strong communication strategy is not just “send an email.” It’s a logic system: who needs what information, when, through which channel, and with what purpose.

Engagement strategies by stakeholder category

After mapping stakeholders, you choose an engagement approach. Common engagement strategies include:

Manage closely: frequent communication, involvement in planning/review, co-creation of solutions
Keep satisfied: periodic updates, ensure needs are addressed, avoid surprises
Keep informed: regular information sharing appropriate to interest level
Monitor: lightweight updates, watch for shifts in influence/interest

In exams, you can illustrate “manage closely” as a steering committee pattern: leadership meetings, structured governance, and clear escalation rules.

Communication objectives: what communication is trying to achieve

Different communications serve different objectives. Typical communication objectives are:

Inform (raise awareness, provide status)
Report (formal updates for accountability)
Consult (collect input before decisions)
Involve (co-design, collaboration)
Collaborate (solve problems jointly)
Negotiate (resolve conflicts, trade-offs)
Confirm (secure approvals and sign-offs)
Educate (training, process adoption)

A high-value exam approach: link objectives to stakeholder types. For example, regulators often require confirm and report communications (evidence and compliance documentation), while end users may need educate and consult communications.

Communication methods and channels (exam-friendly categorisation)

Communication methods can be grouped into formal and informal categories:

Formal:
- Project steering committee reports
- Governance minutes
- Official memos
- Signed approvals
- Compliance submissions
- Contractual notifications
Informal:
- WhatsApp/Teams messages for quick coordination
- Brief check-ins (15-minute syncs)
- Casual stakeholder discussions
- Informal demos and hallway feedback sessions

In South African contexts, channel choice may also reflect accessibility and language preferences. If a stakeholder group has limited access to certain systems, a project must adapt.

Building a communication matrix (the “golden framework”)

A communication matrix (sometimes called a communication plan table) usually specifies:

Stakeholder group
Information required
Purpose (inform/consult/involve/report/confirm)
Format (report, dashboard, meeting, training session)
Frequency (weekly, monthly, milestone-based)
Owner (who sends)
Channel (email, meeting, MS Teams, printed brief, etc.)
Timing (e.g., “two weeks before milestone”)
Feedback mechanism (how stakeholders respond)

Example communication matrix logic (illustrative)

Stakeholder	Info needed	Purpose	Format	Frequency	Channel	Owner
Executive Sponsor	Overall progress vs plan; key risks	Report/Confirm	Steering pack; dashboard	Monthly + milestone	Email + meeting	PM
IT Department	Technical decisions; resource plans	Involve	Technical brief	Weekly	Team meetings	Tech Lead
Faculty Coordinators	Change impacts; training schedule	Educate/Involve	Workshop + FAQ	Bi-weekly during rollout	Workshops + email	Change Manager
Compliance/Privacy Office	Evidence for compliance	Confirm/Report	Compliance pack	Milestone-based	Email + submission	Compliance Officer
Students / End users	Benefits; how to use system	Inform/Educate	Demo; guide	Before and during go-live	Email, website	Product Owner

In exam writing, you can avoid overloading with exact channel technologies, but the structure and purpose must be clear.

Frequency: how to justify “weekly vs monthly”

Examiners often ask students to “justify frequency.” Good justification links frequency to:

Decision points: decisions require more frequent communication before dates
Risk exposure: higher risk requires tighter cadence
Stakeholder impact: if a stakeholder is strongly affected, they need more timely updates
Complexity: complex workstreams require more regular alignment
Governance requirements: legal/regulatory bodies may demand milestone reporting

A good exam sentence:

“Frequency is increased when stakeholders are required to review, approve, or provide inputs that directly affect upcoming milestones; frequency decreases for low-risk, low-interest monitoring.”

Managing expectations: the behavioural core of engagement

Communication is also about expectation management. Mismanaged expectations often cause resistance even when the project is objectively on track.

Key expectation variables:

Scope expectations: what is included vs excluded
Timeline expectations: when something will be ready
Quality expectations: what “good” means
Cost expectations: budget constraints and trade-offs
Responsibility expectations: who does what
Change impact expectations: what will change for stakeholders

Common failure modes you can mention:

Promising deliverables without confirmation of dependencies
Overly optimistic reporting that erodes trust
Vague statements that prevent stakeholders from acting
Delaying escalation until “too late” for decisions

Mitigation strategies:

Use a RACI (Responsible, Accountable, Consulted, Informed) to clarify decision and ownership
Maintain a decision log
Use change control to formalize scope/timeline modifications
Share risk and mitigation plans openly with relevant stakeholders

Consultation and feedback loops

Consultation is more than asking for comments. The project must define:

When consultation happens (before decisions)
What stakeholders should weigh in on (scope options, training design, rollout timing)
How feedback is captured (surveys, workshops, structured interviews)
How feedback affects decisions (recording and responding to feedback)

A strong exam answer states:

Consultation should influence decisions.
The team must close the loop by reporting what was accepted, modified, or rejected—and why.

Handling resistance: strategies for resistant stakeholders

Resistant stakeholders often appear as “low interest” initially but can become “high power” when they control approvals. Engagement strategies for resistant stakeholders include:

Root-cause analysis: resistance may reflect fear, lack of understanding, resource constraints, or mistrust
Information and education: provide clear evidence and training
Involvement: involve them early in solution design
Negotiation and trade-offs: align project benefits with stakeholder needs where possible
Escalation: if resistance blocks approvals, use governance processes

In exam answers, a counter-argument is expected: sometimes resistance is rational. For example, a stakeholder may reject a rollout date because systems are not ready. The correct response is not to dismiss them but to adjust the plan through change control or revise dependencies.

Executing, Monitoring, and Controlling Stakeholder Communications (Rhodes MAN Module)

Planning is only the beginning. In many exams, candidates lose marks by describing processes but failing to show how execution and control work in real project life. This section focuses on monitoring, controlling, and closing the communication loop—including how to measure whether stakeholder engagement is actually working.

Communication execution: roles and responsibilities

In project stakeholder communication, not everything is owned by the project manager. Execution typically involves:

Project Manager: governance cadence, overall status reporting, escalation coordination
Workstream/Team Leads: technical progress updates and dependency communication
Change/Training Lead: user readiness, adoption communications
Procurement/Contract Lead: supplier communication and contract updates
Compliance Officer/Legal Advisor: compliance communications and evidence
PMO/Secretariat (if present): document control, meeting scheduling, tracking actions

A clear RACI supports execution by preventing gaps like “nobody owns stakeholder feedback responses.”

Information control: avoiding the “wrong message” problem

Projects often fail to communicate not because communication didn’t happen, but because:

The wrong audience received the wrong level of detail
Outdated documents were shared
Conflicting updates were sent from different team members
Stakeholders did not know which version was final
Communications lacked action items or decisions

Mitigations:

Use version control (one source of truth for documents)
Maintain a single dashboard/report pack for governance
Assign message owners for each audience type
Use templates: status report structure, risk register layout
Keep a meeting actions log with clear owners and due dates

Monitoring stakeholder engagement: what does “success” look like?

Success metrics must be realistic and measurable. In an exam answer, you can present indicators across three layers:

Process indicators (did we communicate as planned?)
- % governance packs delivered on time
- attendance/participation rate in key meetings
- completion rate of action items from meetings
Content indicators (was information useful and accurate?)
- stakeholder feedback on clarity
- reduction in misunderstandings or rework due to unclear scope
- timeliness of escalation when risks occur
Outcome indicators (did engagement improve delivery?)
- number of approvals obtained on time
- fewer scope disputes
- adoption/training completion rates for end users
- reduction in project delays due to dependencies

Even if your exam doesn’t require numbers, you should be able to explain how these indicators would be monitored.

Using key artifacts to support control

Projects rely on artifacts that support communication control:

Project charter: purpose and scope boundaries
Stakeholder register: who needs what and engagement strategy
Communication matrix: cadence and ownership
Status reports: weekly/monthly progress, issues, risks
Risk register: probability/impact and response owners
Issue log: actions and resolution tracking
Change log: formal changes to scope/time/cost
Minutes and action lists: decisions and follow-ups
Decision log: why decisions were made

A high-mark exam answer often mentions at least 3–5 of these and explains how they connect to communication.

Managing escalations and conflict through communication

Stakeholder conflicts can appear as:

disagreement about priorities (“cost vs quality”)
disputes over scope (“this is not included”)
competition for resources
resistance due to political dynamics

Communication control requires:

Structured escalation: clear thresholds for when to escalate (e.g., missed milestones, unresolved issues)
Fact-based reporting: status aligned to evidence, not opinions
Decision framing: what decision is needed, options, recommendation
Governance mechanisms: steering committee decisions, documented sign-offs

A good exam counter-argument:

Some students argue that “more communication always reduces conflict.”
Correct response: more communication can increase confusion if it’s not structured. The solution is not volume; it’s clarity, governance, and decision documentation.

Capturing and responding to feedback

Communication is two-way. Projects need feedback mechanisms like:

surveys (end-user training satisfaction)
meeting Q&A sessions
hotline or help desk logs during rollout
stakeholder interviews after key milestones

Then you must respond:

Triage feedback: what is a requirement, suggestion, complaint, or misunderstanding?
Log into issue/change records
Assess impact: timeline, cost, risk
Decide: accept, modify, defer, reject
Close the loop: communicate what changed and why

Exams often award marks for showing the loop, not just collecting feedback.

A mini case scenario: controlling communication during a rollout

Consider a scenario: a project is rolling out a new online registration process at a university faculty. Stakeholders include:

students (end users)
faculty coordinators (process owners)
IT (system readiness)
compliance/privacy office (data protection)
executive sponsor (oversight)

During rollout week, student complaints increase. A communication breakdown could look like: students contact random staff via informal channels, faculty coordinators send conflicting instructions, and IT delays updates because they are not attending governance meetings.

A strong response is:

establish a single incident communication channel (e.g., weekly helpdesk summary to PM and IT lead)
provide daily short updates to faculty coordinators during peak disruption window
share a formal status bulletin to executive sponsor (with actions and expected resolution date)
involve compliance quickly if errors relate to personal information handling

This scenario shows how communication control is a “delivery system,” not a messaging habit.

Stakeholder Communication Tools, Techniques, and Common Exam Answer Patterns (Rhodes MAN Module)

This section consolidates the tools and techniques you’re most likely to list in exams, and it also gives you reusable answer patterns. In South African university project management assessments, graders typically reward structured logic, correct terminology, and practical linkages between stakeholder analysis and communication planning.

Communication tools and documentation techniques

Common tools include:

Stakeholder register: central record of stakeholders and engagement approach
Communication matrix: who gets what information, when, and how
RACI matrix: clarifies roles in communication and decisions
Project dashboard: a visual summary for executives (traffic-light status, KPIs)
Status report templates: consistent reporting format
Risk heat maps: highlight high-priority risk areas requiring stakeholder attention
Issue logs and change logs: track actions and scope/timeline changes
Minutes and action lists: ensure governance decisions become tasks
Decision tree / decision log: keeps decisions transparent and auditable
Meeting agendas: prevent unstructured discussions
Communication calendar: planned cadence by milestone

For exams, it’s good practice to describe what each tool does and why it matters for stakeholder management.

Example RACI to support communication planning

A sample RACI pattern for a milestone approval can be written as:

Responsible: PM and compliance officer (prepare evidence and documentation)
Accountable: Executive sponsor (final sign-off)
Consulted: IT lead and end-user representative (confirm system readiness and user impact)
Informed: procurement, project team, affected stakeholders (awareness of decision outcome)

In an exam, don’t get lost in fancy details. Show you can connect roles to communication outcomes: who must receive the decision, who provides evidence, and who must act.

Stakeholder analysis techniques beyond power/interest

You may encounter other mapping methods:

Salience model (stakeholder is defined by power, legitimacy, urgency)
Influence/impact grids (different from power/interest but similar)
Interest vs impact (useful when “impact” is not necessarily controlled by power)

If an exam asks only “explain stakeholder analysis,” you can choose the power/interest grid as the primary tool and mention others as extensions.

Negotiation and conflict communication techniques

Stakeholder engagement includes communication that negotiates:

Win–win framing: highlight benefits for both sides
Option-based proposals: offer alternatives with trade-offs
Evidence-based reasoning: use data to justify timelines/technical decisions
Empathy and listening: acknowledge concerns and demonstrate understanding
Documented agreements: avoid “verbal-only” commitments

A common incorrect exam approach is to focus only on talking. The correct approach shows that negotiation communication must create clarity and commitments through documentation.

Communication quality: clarity, timing, and relevance

Three dimensions of communication quality are frequently tested:

Clarity: stakeholders can understand the message and action required
Timing: messages arrive early enough for decision-making
Relevance: stakeholders receive only what matters to them

Poor communication quality leads to:

wrong actions
late approvals
rework
stakeholder frustration and distrust

A high marks paragraph may explicitly mention these three dimensions and link them to stakeholder engagement outcomes.

Common exam questions and mark-friendly answer outlines

Below are typical Rhodes/SA-style question formats and how you can structure answers.

Question type 1: “Explain stakeholder management and communication planning”

Mark-friendly outline:

Define stakeholder management
Describe the four process stages (identify → plan engagement → manage → monitor)
Explain stakeholder analysis (power/interest grid)
Explain communication matrix (purpose, frequency, channel, owner)
Mention engagement strategies and feedback loops
Conclude with monitoring/control using registers, logs, and governance cadence

Question type 2: “Design a communication plan for a project”

Mark-friendly outline:

Identify stakeholder groups and classify by power/interest
Define communication objectives per group (inform/consult/involve/report/confirm/educate)
Provide a communication matrix table
Justify frequencies by decision points and risk
Explain feedback mechanism and escalation pathways
Mention control artifacts: version control, action log, decision log

Question type 3: “Discuss communication risks and mitigation”

Mark-friendly outline:

Define communication risks (misinformation, late info, overload, conflicting messages)
Provide examples (version mismatch; delayed escalation)
Link mitigation to control tools (single source of truth; governance templates)
Mention behavioural mitigation (trust-building, transparency, closed-loop feedback)

South African university style phrasing that earns marks

In SA examinations, phrasing that signals “project management vocabulary + structure” often performs well. Use phrases like:

“stakeholder engagement strategy”
“communication objectives”
“governance cadence”
“single source of truth”
“feedback loop”
“escalation and decision-making”
“version control and document control”

You don’t need to overuse jargon, but using the correct terminology helps align with marking rubrics.

Putting It All Together: Integrated Stakeholder and Communication Management Workflow (Rhodes MAN Module)

This final section integrates everything into a coherent workflow—how a project team would actually move from stakeholder identification to controlled communication execution. The best exam answers often show a full lifecycle view, not disconnected theory. This section therefore presents a “start-to-finish” method with examples and decision points.

Step-by-step workflow (integrated method)

A realistic workflow you can write in an exam follows this logic:

Start with project objectives and governance
- Confirm what decisions must be made, by whom, and when.
- Identify reporting requirements (internal governance vs external compliance).
Identify stakeholders
- Conduct interviews/workshops.
- Review documents: charter, contracts, policies, risk register.
- Capture stakeholders in a stakeholder register.
Analyse stakeholders
- Apply power/interest grid.
- Add attributes: attitude, urgency, impact, legitimacy.
- Determine stakeholder engagement level and likely concerns.
Plan engagement and communication
- Choose engagement strategies for each quadrant.
- Create communication matrix:
  - who receives what
  - purpose (inform/consult/involve/report/confirm/educate)
  - frequency and timing
  - channel and owner
  - feedback mechanism
Set up communication control mechanisms
- Version control for documents and reports
- templates for status packs
- decision log
- action log
- escalation thresholds and escalation path
Execute communications
- Hold meetings as per governance cadence.
- Deliver stakeholder-specific updates.
- Ensure technical updates are aligned and consistent.
Monitor and adjust
- Compare actual communication activities vs plan.
- Gather stakeholder feedback.
- Track whether engagement leads to approvals and reduced conflict.
Close loops and learn
- Confirm approvals, sign-offs, and adoption milestones.
- Capture lessons learned about what communication worked and what didn’t.
- Update stakeholder register for future phases.

Example integrated plan: a multi-stakeholder project timeline (exam-style narrative)

Consider an integrated plan for a project with these phases:

Phase 1 (Weeks 1–4): Initiation and requirements
Phase 2 (Weeks 5–10): Design and procurement
Phase 3 (Weeks 11–16): Build and testing
Phase 4 (Weeks 17–20): Rollout and training
Phase 5 (Weeks 21–24): Stabilisation and close-out

(These weeks are illustrative for exam explanation; the logic is what matters.)

Stakeholder communication must align to these phases:

Weeks 1–4 (high need for consultation):
- consult faculty coordinators and end users to validate requirements
- frequent discovery workshops with IT
- compliance office briefings to identify evidence needed later
Weeks 5–10 (approval and procurement controls):
- executive sponsor updates on procurement status and budget controls
- compliance confirmations of documentation requirements
Weeks 11–16 (technical risk management):
- regular technical status reports to IT and project governance
- risk escalations if testing outcomes threaten deadlines
Weeks 17–20 (educate and confirm):
- training schedule communications to end users
- formal sign-off communications for rollout readiness
Weeks 21–24 (stabilisation and close-out):
- adoption feedback collection
- lessons learned workshops
- final reports to steering committee and compliance bodies

An exam marker will value that the student explicitly ties communication to phases, not just to stakeholder types.

Counter-argument: “Why not communicate everything to everyone?”

Some students claim that open transparency means “everyone should receive everything.” A stronger answer provides the counter-argument:

Stakeholders require different levels of detail.
Over-communication increases noise, causing stakeholders to miss key decisions.
Different stakeholders have different authority and responsibilities.
Sharing sensitive information with the wrong group can create compliance or reputational risk.

Instead, the project should use:

a communication matrix,
clear reporting templates,
controlled document access,
and a decision log that captures what matters for governance.

Building trust with stakeholders: transparency and consistency

Trust is a communication outcome. Trust improves when the project demonstrates:

consistency between what is promised and what is delivered
honesty about risk and issues
timeliness of escalation
respectful listening to stakeholder concerns
fairness in decision-making processes

In exams, you can tie trust to governance and to communication control. If stakeholders see that decisions are documented and action items are tracked, they are more likely to engage constructively.

Common pitfalls in stakeholder and communication management

To score well, show awareness of what goes wrong:

Ignoring low power/high interest stakeholders: these groups often become vocal and influence the adoption process.
Sending generic updates: stakeholders need tailored information, not one-size-fits-all messaging.
Missing milestone communications: approvals and sign-offs can stall if evidence arrives late.
No feedback loop: stakeholder frustration grows when input is requested but not responded to.
Unclear ownership: if no one owns stakeholder responses, communication becomes reactive.
No version control: stakeholders act on outdated information, causing rework.

In an exam, each pitfall paired with mitigation is ideal: “Pitfall → effect → mitigation.”

Closing the project: stakeholder communication at close-out

Close-out communications are also stakeholder management. End-of-project activities include:

final status report and lessons learned summary
handover documentation to operations/support teams
final approvals/sign-offs
evaluation of stakeholder satisfaction
communication of “what happens next” (maintenance, support, monitoring)

A common exam expectation is that close-out communications include lessons learned—especially those related to communication breakdowns (e.g., “what should have been escalated earlier” or “which stakeholder category required different cadence”).

Exam-ready checklist (write this during preparation)

Use this as a final revision checklist:

Defined stakeholder and distinguished internal/external stakeholders
Used stakeholder identification methods (interviews/workshops/document review)
Applied a stakeholder analysis tool (power/interest grid) and described quadrants
Explained engagement strategies (manage closely/keep satisfied/keep informed/monitor)
Built a communication matrix conceptually (information, purpose, frequency, channel, owner)
Justified communication frequency by decision points and risk
Mentioned communication risks and mitigations (overload, misinformation, version control)
Showed monitoring and control (action logs, decision log, dashboards, stakeholder feedback)
Included a feedback loop and closed the communication cycle
Addressed common pitfalls (generic updates, missing approvals, no ownership)

Final synthesis: what exam markers look for

An excellent Rhodes MAN module stakeholder and communication management answer demonstrates:

Structured stakeholder identification and analysis
Clear translation into engagement and communication strategies
Practical communication planning (matrix, objectives, frequency, channel)
Execution control (version control, logs, escalation governance)
Monitoring and feedback loops
Awareness of risks and behavioural realities (expectations, trust, resistance)

If you cover those elements with consistent terminology, coherent examples, and a clear workflow narrative, you will be well positioned to score highly in exam scenarios that test both theoretical understanding and applied project communication design.