Stakeholder Roles, Analysis, and RACI

Identifying Stakeholder Roles

Business analysis work touches many kinds of stakeholders, and BABOK Guide v3 describes a set of common stakeholder categories that recur across most initiatives, even though actual titles vary by organization:

• Business analyst (BA) — facilitates understanding of the need and coordinates business analysis activities across other stakeholders
• Customer — uses or receives the outputs of the organization, typically external to the organization providing the solution
• Domain subject matter expert (SME) — holds detailed knowledge of a business domain, process, or regulation relevant to the change
• End user — directly interacts with the solution once it is implemented
• Implementation SME — provides expertise in designing or constructing the solution, such as a developer, architect, trainer, or change-management professional
• Operational support — maintains the solution and ensures ongoing operational performance after deployment
• Project manager — manages resources, schedule, and scope to deliver the solution
• Regulator — establishes and enforces standards the solution or the change must comply with
• Sponsor — authorizes and champions the work, controls funding, and is often accountable for realizing value
• Supplier — provides products or services to the organization from outside the enterprise
• Tester — determines whether a solution meets requirements and is fit for use

No two initiatives have identical stakeholder rosters, and a single person may hold more than one role.

Stakeholder List, Map, and Personas

The Stakeholder Analysis technique gives BAs three complementary tools for organizing this information:

1. Stakeholder list — a simple inventory recording each stakeholder's name or role, department, and relationship to the initiative; the starting point for further analysis.
2. Stakeholder map — a visual representation of stakeholders and their relationships to each other, to the solution, and to the organization. One common map format is the onion diagram, which places stakeholders in concentric rings by proximity to the solution: the innermost ring might hold the solution or project team, the next ring the immediate business area, and outer rings broader organizational or external stakeholders.
3. Personas — composite, semi-fictional profiles representing a class of stakeholder, particularly useful for end users, capturing goals, behaviors, and pain points to keep requirements grounded in real stakeholder needs.

Impact and Influence Analysis

Beyond identifying who stakeholders are, the BA analyzes each stakeholder's attitude toward the initiative (supportive, neutral, resistant), their level of authority or decision-making power, their level of interest, and the complexity of managing them — for example, a large, diverse stakeholder group is more complex to manage than a single point of contact. A common analytical tool plots stakeholders on a two-axis grid, typically influence/power against interest/impact, to decide how much engagement effort each stakeholder warrants: high-influence, high-interest stakeholders, often sponsors, need close, ongoing engagement, while low-influence, low-interest stakeholders may only need periodic updates.

RACI: Clarifying Roles Against Activities

Once stakeholders and their relative influence are understood, the BA often needs to clarify exactly who does what for a given set of activities or deliverables. The RACI matrix is the standard tool for this:

Example RACI for a requirements-approval activity:

The single-Accountable rule is a frequent exam trap: a stakeholder group can be Consulted or Informed, and multiple stakeholders can be jointly Responsible, but only one role is ever Accountable for a given activity — otherwise ownership becomes ambiguous.

Why This Matters for Business Analysis

Clear stakeholder analysis and RACI assignment prevent two common failure modes: stakeholders who should have been consulted are bypassed, leading to incomplete or incorrect requirements, and no one is clearly accountable for approving decisions, leading to delays or later disputes over who agreed to what. Building an accurate stakeholder list and map early, then using RACI to clarify roles on specific requirements or deliverables, keeps the initiative moving with the right people engaged at the right level.

Worked Example

Consider a scenario common on the ECBA exam: a new initiative has a highly engaged sponsor, a group of domain SMEs who support the change but hold no formal budget authority, and a set of end users who were not consulted during initial planning. Plotting these stakeholders on an influence/interest grid quickly shows the sponsor as high-influence and high-interest, warranting close, ongoing engagement. The end users, though lower in influence, may still carry high interest because the change directly affects their daily work, so the engagement plan should include structured reviews with them even though they hold no Accountable seat on the RACI matrix — otherwise the resulting design may satisfy the sponsor on paper while failing on the ground once end users actually use it.