2.9.3: Stakeholder Role Mapping- The Planning Leader’s First Reality Check

Stakeholder Role Mapping: The Planning Leader’s First Reality Check

A C-Bay Planning Guide for Milestone 1

Introduction: Why Stakeholder Mapping Comes Before Scheduling, Scoping, or Success Planning

Projects often fail early—not because of time or money—but due to confusion about who the real decision-makers are.

Before defining work or assigning tasks, a planner must know:

• Who will approve the project
• Who will influence but not own the plan
• Who could stop the project if not on board
• Who will be most impacted by the results

This process, called stakeholder mapping, is the first reality check for any planning leader. A strong Project Charter doesn’t just define scope—it names the people in the room and the power they hold.

What Is Stakeholder Mapping?

Stakeholder Mapping is the process of:

• Identifying all individuals/groups affected by the project
• Assigning clear roles (Sponsor, Approver, Reviewer, Contributor, Observer)
• Understanding influence—authority, veto power, or hidden sway
• Framing communication and decisions around those roles

This prevents surprises, avoids gridlock, and navigates organizational politics before work begins.

The C-Bay Approach to Stakeholder Mapping

At C-Bay, we never start a planning engagement without knowing:

• The project sponsor
• Who signs off
• Who provides input
• Who must be consulted but doesn’t own decisions
• Who could slow or block the work if unmet

In a charter, this appears in the Stakeholders and Roles section—not as a static list, but as a strategic snapshot of those shaping the project.

Step-by-Step: How to Map Stakeholders in Your Project Charter

Step 1: Identify Stakeholders from Source Documents

Use the stakeholder memo and scenario briefing to find:

• Names and titles
• Roles suggesting authority (Dean, CIO)
• Impacted departments (Admissions, IT, Academic Affairs)

UCMS key figures:

• Dr. Alok Varun – Dean of Admissions
• Dr. Alex Serman – CIO
• Dr. Wendy Sheen – Director of PMO, C-Bay

Step 2: Assign Clear Roles

Define participation beyond names:

Common roles:

• Sponsor – Owns business case and signs off
• Approver – Validates planning documents
• Contributor – Provides subject matter expertise
• Reviewer – Gives feedback but no final say
• Observer – Informed but not active in planning

UCMS example:

• Dr. Alok Varun – Sponsor and Final Approver
• Dr. Alex Serman – Reviewer and Technical Lead
• Dr. Wendy Sheen – Advisor and Project Governance

Step 3: Assess Influence Type

Authority is not always in the org chart. Consider:

• Budget control
• Veto power
• Meeting dominance
• Behind-the-scenes advocacy or resistance

Influence terms:

• Final Approver
• Technical Gatekeeper
• Compliance Driver
• Stakeholder Champion
• Change Resistor

Step 4: Present Stakeholder Information Clearly

Use a table:

Name	Title	Role	Influence Type
Dr. Alok Varun	Dean of Admissions	Sponsor	Final Approver
Dr. Alex Serman	CIO, UCMS	Reviewer	Technical Lead
Dr. Wendy Sheen	Director of PMO, C-Bay	Advisor	Governance Oversight

Common Mistakes in Stakeholder Mapping

Mistake: Listing titles only
Fix: Include names and contextual role definitions

Mistake: Using “everyone” or “the client” as a stakeholder
Fix: Identify specific individuals

Mistake: Excluding internal stakeholders
Fix: Include C-Bay and UCMS roles

Mistake: Not defining influence type
Fix: State how each can affect the project

Mistake: Missing blockers
Fix: Ask: Who could delay or derail this work if left out?

Planning Tip: Map Stakeholders Early

Stakeholder ambiguity only grows over time. Early clarity:

• Sets expectations
• Streamlines approvals
• Reduces political risk

Reflection Questions

• Have I identified everyone who can impact this project?
• Have I gone beyond titles to define influence?
• Can someone reading this table know who to approach for each issue?

If any answer is “no,” revise before finalizing. This is your first move as a planner in a human system—make it count.