6.1 Stakeholder Analysis: Power/Interest Grid, Salience Model & Onion Diagrams
Key Takeaways
- The Power/Interest Grid classifies stakeholders into four operational quadrants—Manage Closely (High Power, High Interest), Keep Satisfied (High Power, Low Interest), Keep Informed (Low Power, High Interest), and Monitor (Low Power, Low Interest)—establishing baseline communication protocols and engagement cadences.
- Mitchell, Agle, and Wood's Salience Model evaluates stakeholders dynamically across Power, Legitimacy, and Urgency, mapping them into seven distinct classes: Latent (Dormant, Discretionary, Demanding), Expectant (Dominant, Dangerous, Dependent), and Definitive (possessing all three attributes).
- The Stakeholder Onion Diagram models stakeholder proximity to the solution core through concentric rings: Core Team (project delivery members), Direct Users (daily hands-on system operators), Indirect Users (consumers of reports and downstream business functions), and External Entities (regulators, customers, and external partners).
- The RACI Matrix enforces clear business analysis governance by defining Responsible, Accountable, Consulted, and Informed roles for each deliverable, strictly adhering to the rule that exactly one individual must be designated Accountable ('A') per deliverable.
- Stakeholder analysis is an ongoing, dynamic process; stakeholder power, interest, and salience attributes shift across project phases, organizational changes, and external events, requiring the Business Analyst to continually update the Stakeholder Register.
6.1 Stakeholder Analysis: Power/Interest Grid, Salience Model & Onion Diagrams
[!NOTE] PMI-PBA Examination Alignment: Domain 2 (Planning) accounts for 22% of the scored items on the PMI-PBA examination. Task 1 within the Planning domain mandates that a business analyst "Review business analysis plans and other project artifacts to establish a shared understanding of stakeholder needs, communication requirements, and governance." Analytical stakeholder models are frequently tested to assess your ability to calibrate engagement intensity, prevent project disruption from overlooked stakeholders, and establish clear decision-making governance.
In business analysis, solutions are conceived, designed, and implemented to deliver value to people and organizational entities. However, no enterprise initiative operates in a vacuum. Every business problem and proposed capability intersects with individuals, groups, and institutions whose interests may align, diverge, or directly collide with the project's objectives.
According to The PMI Guide to Business Analysis, a stakeholder is defined as an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a program or project. Conducting rigorous stakeholder analysis during the Planning phase prevents one of the most pervasive failure modes in business analysis: discovering critical, unaddressed business requirements or compliance constraints late in the development lifecycle because a key stakeholder was ignored, misclassified, or identified too late.
+-----------------------------------------------------------------------------------+
| Stakeholder Analysis Lifecycle in Business Analysis |
+-----------------------------------------------------------------------------------+
| 1. Identify Stakeholders (Elicit roles, departments, external parties) |
| ↓ |
| 2. Analyze Stakeholder Profiles (Power, Interest, Legitimacy, Proximity, Impact) |
| ↓ |
| 3. Apply Analytical Models (Power/Interest Grid, Salience Model, Onion Diagram) |
| ↓ |
| 4. Define Governance & Accountabilities (RACI Matrix Construction) |
| ↓ |
| 5. Populate & Dynamically Maintain Stakeholder Register |
+-----------------------------------------------------------------------------------+
The Power/Interest Grid (Power/Influence Grid)
The Power/Interest Grid (also referred to across PMI literature as the Power/Influence Grid) is a foundational two-dimensional classification model that maps stakeholders based on two primary variables:
- Power (or Authority/Influence): The level of organizational authority, budgetary control, political standing, or structural leverage a stakeholder possesses to direct resources, mandate changes, or halt project execution.
- Interest (or Concern/Involvement): The degree to which the stakeholder's day-to-day operations, workflows, job performance metrics, or strategic outcomes are impacted by the project's deliverables.
Plotting stakeholders across these two intersecting axes creates four distinct operational quadrants, each requiring a specific management and communication strategy:
High ^
| Quadrant 2: KEEP SATISFIED | Quadrant 1: MANAGE CLOSELY
| - High Power / Low Interest | - High Power / High Interest
| - Executive Gatekeepers, CISO, | - Project Sponsor, Product Owner,
| CFO, Regulatory Compliance | Primary Business Unit Heads
P | - Strategy: Concise briefings, | - Strategy: Intensive co-design,
O | respect constraints, align | continuous collaboration,
W | governance | active steering participation
E | ----------------------------------+----------------------------------
R | Quadrant 4: MONITOR | Quadrant 3: KEEP INFORMED
| - Low Power / Low Interest | - Low Power / High Interest
| - Peripheral staff, general | - Frontline end users, customer
| employees, indirect depts | service agents, SME operators
| - Strategy: Automated portals, | - Strategy: User demos, detailed
| passive newsletters, minimal | elicitation, user story reviews,
| direct communication | workflow feedback loops
Low +------------------------------------------------------------------->
Low High
INTEREST
Detailed Analysis of the Four Quadrants
1. High Power, High Interest: "Manage Closely"
- Stakeholder Profile: Executive project sponsors, lead product managers, primary business unit heads whose departments will operate the new system, and client executives.
- Behavioral Nuance: These individuals hold both the authority to make binding project decisions and a profound personal or operational stake in the project's success. Neglecting them leads to immediate project cancellation, resource withdrawal, or radical scope redirection.
- BA Strategy: Partner with these stakeholders directly. Involve them in high-level elicitation sessions, charter reviews, scope definition, and governance steering committees. Provide continuous, transparent visibility into risks, dependencies, and requirements baselines.
2. High Power, Low Interest: "Keep Satisfied"
- Stakeholder Profile: Chief Financial Officers (CFOs), Chief Information Security Officers (CISOs), Corporate Legal Counsel, Enterprise Data Architects, and external regulatory auditors.
- Behavioral Nuance: These stakeholders are not concerned with day-to-day functional behaviors or UI button placements; their interest is narrow and constraint-oriented (e.g., "Does this solution stay within the approved CapEx budget?" or "Does this cloud architecture comply with PCI-DSS 4.0 data security mandates?"). However, if their constraints are violated, they possess the formal authority to unilaterally freeze the project.
- BA Strategy: Do not overwhelm them with granular user stories or technical sprint details. Engage them through targeted, concise milestone reviews, compliance verification checkpoints, and formal architectural gates. Ensure all statutory, financial, and security requirements are explicitly captured in the Non-Functional Requirements (NFR) baseline.
3. Low Power, High Interest: "Keep Informed"
- Stakeholder Profile: Frontline operational staff, customer service representatives, claims adjusters, warehouse logistics clerks, and end-consumer user groups.
- Behavioral Nuance: These stakeholders will use the system every day. Their operational productivity, job satisfaction, and workflow efficiency will be directly shaped by the solution. However, individually they hold virtually no formal power to approve budgets, alter vendor contracts, or override executive decisions.
- BA Strategy: Treat these stakeholders as the primary wellspring of functional requirements, business rules, edge cases, and usability acceptance criteria. Because they lack formal authority, they often feel vulnerable to top-down organizational disruption. Keep them actively informed through sprint reviews, solution demonstrations, prototyping feedback sessions, and user journey mapping workshops. Cultivate them as change champions to ensure seamless post-implementation adoption.
4. Low Power, Low Interest: "Monitor"
- Stakeholder Profile: Peripheral departments (e.g., facilities management in a core software upgrade), general employees, distant subsidiary teams, or third-party vendors whose systems are unaffected.
- Behavioral Nuance: These groups have minimal influence over project governance and minimal impact from its outcomes. Excessive engagement wastes valuable business analysis resources and creates communication fatigue.
- BA Strategy: Monitor them through low-bandwidth, passive communication channels, such as general enterprise intranet postings, project milestone bulletins, or self-service documentation repositories. Re-evaluate their standing periodically to detect changes in status.
Dynamic Quadrant Migrations
A critical insight for the PMI-PBA examination is that stakeholder classifications are never static. Stakeholders frequently migrate across quadrants during the initiative lifecycle:
- Low Power/High Interest to High Power/High Interest: A frontline user community (initially Low Power/High Interest) forms an organized union, employee council, or gains the ear of an influential executive, suddenly acquiring the political power to block deployment if ergonomic or workload concerns are unaddressed.
- High Power/Low Interest to High Power/High Interest: A corporate compliance officer who initially showed minimal interest becomes intensely engaged (High Interest) following an unexpected regulatory inspection or security breach in a sister business unit.
- High Power/High Interest to High Power/Low Interest: An executive sponsor transfers operational ownership of the initiative to a designated Product Owner following charter sign-off, stepping back into a passive governance role.
The Mitchell, Agle, and Wood Salience Model
While the Power/Interest Grid provides an intuitive two-axis categorization, enterprise initiatives frequently involve complex stakeholder ecosystems where interest alone does not capture urgency or contractual legitimacy. To address this complexity, business analysts apply the Salience Model, formulated by Ronald K. Mitchell, Bradley R. Agle, and Donna J. Wood (1997).
The Salience Model analyzes stakeholders based on the presence, absence, or combination of three dynamic attributes:
- Power: The perceived ability of a stakeholder to impose their will upon the project through coercive means (force/penalties), utilitarian means (material/financial incentives), or symbolic means (normative influence, status, prestige).
- Legitimacy: The perceived validity, social appropriateness, legal standing, or contractual right of the stakeholder's involvement in the project.
- Urgency: The degree to which the stakeholder's claim calls for immediate attention. Urgency exists only when two conditions are met: the claim is time-sensitive (delay is unacceptable to the stakeholder) and critical (of profound importance or high consequence).
[ POWER ]
/ \
/ \
/ Area 4 \
/ Dominant \
/ \
Area 1 / Area 5 Area 6 \ Area 2
Dormant / Dangerous Depend. \ Discretionary
[P] ( [P+U] [L+U] ) [L]
\ /
\ Area 7 /
\ Definitive /
\ [P+L+U] /
\ /
\ /
[LEGITIMACY] ----------- [URGENCY]
Area 3: Demanding [U]
The Seven Stakeholder Typologies
The intersection of these three attributes yields seven distinct stakeholder classes, grouped into three overarching priority tiers:
Tier 1: Latent Stakeholders (Possessing Exactly ONE Attribute — Low Salience)
- Dormant Stakeholders (Power Only):
- Profile: Hold significant power to impose will, but have no legitimate relationship or urgent claim.
- Example: A corporate holding company executive who has had no operational contact with your business unit, or an activist institutional investor.
- BA Strategy: Acknowledge their potential power. Monitor their posture because acquiring legitimacy or urgency instantly elevates them into high-salience classes.
- Discretionary Stakeholders (Legitimacy Only):
- Profile: Have legitimate claims and proper standing, but possess no power to enforce them and no urgent timeline.
- Example: Environmental non-governmental organizations (NGOs), corporate social responsibility (CSR) committees, or university research partners receiving charitable data grants.
- BA Strategy: Engage them through structured corporate communication. Because they lack power and urgency, business analysts are under no immediate pressure to prioritize their requirements, though ethical and brand considerations apply.
- Demanding Stakeholders (Urgency Only):
- Profile: Have urgent, noisy claims, but lack both legitimacy and the power to enforce them.
- Example: An individual vocal user lodging repeated complaints about a minor visual styling detail on a public web page, or an unauthorized protestor demanding project cancellation.
- BA Strategy: Do not allocate disproportionate requirements elicitation or analysis time to demanding stakeholders. While their urgency makes them vocal, their lack of power and legitimacy means their claims should not disrupt baseline project scope.
Tier 2: Expectant Stakeholders (Possessing Exactly TWO Attributes — Moderate Salience)
- Dominant Stakeholders (Power + Legitimacy):
- Profile: Possess formal authority and legitimate contractual or organizational standing, but lack immediate urgency.
- Example: Corporate steering committees, the Enterprise Architecture Review Board, or the Chief Legal Officer during early design phases.
- BA Strategy: Treat them as formal authority figures. Establish formal reporting mechanisms, management reviews, and governance gates to ensure their legitimate requirements are satisfied.
- Dangerous Stakeholders (Power + Urgency):
- Profile: Possess coercive power and urgent demands, but lack legitimate authority or contractual standing. They are prone to using disruptive, coercive, or non-traditional tactics to force compliance.
- Example: A rogue business unit leader who bypasses corporate IT governance to commission a shadow IT system, or an aggressive external pressure group threatening public boycotts during a system launch.
- BA Strategy: Identify them immediately and coordinate with project and executive leadership. Mitigate their disruption by neutralizing urgent triggers or channeling their concerns into legitimate governance discussions.
- Dependent Stakeholders (Legitimacy + Urgency):
- Profile: Have legitimate, deeply impacted claims and urgent timelines, but lack the organizational power to enforce them.
- Example: Frontline workers facing imminent replacement or severe workflow upheaval who cannot approve budgets or dictate system architectures.
- BA Strategy: Dependent stakeholders rely on third parties to champion their cause. The business analyst must serve as their advocate, ensuring their legitimate operational needs and transition requirements are heard by Dominant and Definitive decision-makers.
Tier 3: Definitive Stakeholders (Possessing ALL THREE Attributes — High Salience)
- Definitive Stakeholders (Power + Legitimacy + Urgency):
- Profile: Possess formal authority, legitimate standing, and urgent time-sensitive demands.
- Transformation Dynamic: Definitive stakeholders often emerge when a Dominant stakeholder experiences an urgent trigger. For instance, when a new financial regulation takes effect on a mandatory statutory date, the Chief Compliance Officer (previously Dominant: Power + Legitimacy) suddenly gains Urgency, transforming into a Definitive stakeholder.
- BA Strategy: Provide immediate, top-priority focus. Their requirements and constraints take precedence over all lower-salience classes. The business analyst must maintain direct, continuous engagement to ensure full scope alignment.
The Stakeholder Onion Diagram
The Stakeholder Onion Diagram is an intuitive visual modeling technique that conceptualizes stakeholders based on their physical, operational, and organizational proximity to the solution.
Unlike two-by-two grids that focus purely on political metrics, the Onion Diagram helps the business analyst structure elicitation scopes by peeling back concentric layers of operational impact:
+-----------------------------------------------------------------------------------+
| STAKEHOLDER ONION DIAGRAM |
+-----------------------------------------------------------------------------------+
| Layer 4: EXTERNAL ENTITIES |
| [Regulators, Industry Standards Bodies, Competitors, External Customers] |
| +-----------------------------------------------------------------------------+ |
| | Layer 3: INDIRECT USERS / WIDER ORGANIZATION |
| | [Billing Dept, Data Warehouse Teams, IT Infrastructure, Internal Audit] | |
| | +-----------------------------------------------------------------------+ | |
| | | Layer 2: DIRECT USERS (Hands-on System Operators) | | |
| | | [Call Center Reps, Underwriters, Branch Staff, Mobile App Users] | | |
| | | +-----------------------------------------------------------------+ | | |
| | | | Layer 1: THE CORE SOLUTION & DELIVERY TEAM | | | |
| | | | [Business Analyst, Project Manager, Tech Lead, QA, Devs] | | | |
| | | +-----------------------------------------------------------------+ | | |
| | +-----------------------------------------------------------------------+ | |
| +-----------------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------------+
The Four Concentric Layers
- The Core Solution & Delivery Team (Layer 1): The innermost layer consists of the practitioners responsible for designing, building, testing, and managing the deliverable. This includes the Business Analyst, Project Manager, Solution Architect, Scrum Master, Developers, and QA Engineers. Communication is continuous, daily, and highly technical.
- Direct Users (Layer 2): The individuals who directly interact with the solution's user interfaces, hardware devices, or physical touchpoints on an operational basis. Examples include underwriters entering loan applications, warehouse operators scanning barcodes, or external retail customers using a mobile checkout flow. Elicitation here focuses on user personas, user stories, ergonomic workflows, usability non-functional requirements, and acceptance criteria.
- Indirect Users / Wider Enterprise (Layer 3): Individuals and organizational functions that do not physically touch the system daily, but rely upon its downstream outputs, reports, data streams, or operational health. Examples include finance directors receiving end-of-month reconciliation feeds, enterprise data architects maintaining cross-system schemas, and internal compliance auditors. Elicitation here focuses on interface specifications, data integrity rules, reporting requirements, and transition requirements.
- External Entities (Layer 4): Stakeholders operating outside the enterprise boundary who interact with or regulate the organization. Examples include statutory regulatory agencies (e.g., SEC, FDA, OSHA), external audit firms, logistics suppliers, payment gateway providers, and industry standards consortiums. Elicitation here focuses on legal compliance, statutory reporting formats, security protocols, and external API contracts.
The RACI Matrix for Business Analysis Deliverables
Once stakeholders have been analyzed using the Power/Interest Grid, Salience Model, and Onion Diagram, the business analyst must establish unambiguous operational governance. The standard governance framework recognized by PMI is the RACI Matrix (Responsible, Accountable, Consulted, Informed).
RACI Component Definitions
- Responsible (R): The practitioner(s) tasked with performing the actual work to create, draft, or execute the deliverable or activity. Multiple individuals can share the 'R' designation.
- Accountable (A): The single individual who holds ultimate, non-delegable ownership and decision-making authority over the deliverable. The Accountable person has the power to approve, sign off on, or veto the deliverable and answers for its success or failure.
- Consulted (C): Subject matter experts (SMEs), technical specialists, or functional leaders who provide vital two-way input, technical data, or domain expertise before the deliverable is finalized. Consultation is an interactive, bi-directional dialogue.
- Informed (I): Individuals or groups kept up-to-date on deliverable status, approvals, or milestones via one-way communication. They do not contribute input or hold approval authority.
Cardinal Construction Rules for the RACI Matrix
To preserve governance integrity and prevent operational paralysis, business analysts must enforce three non-negotiable construction rules:
[!IMPORTANT] The Three Cardinal Rules of RACI Governance:
- Strictly ONE 'A' Per Deliverable: Every row (deliverable or activity) must have exactly one Accountable individual. Assigning two or more 'A's creates ambiguous ownership, encourages diffusion of responsibility, and causes deadlocks when controversial scope decisions arise. If no single 'A' exists, nobody is truly accountable.
- At Least One 'R' Per Deliverable: Every row must have at least one individual assigned to do the work. An activity with an 'A' but no 'R' represents an approved goal that nobody is responsible for executing.
- Avoid Over-Consultation: Designating too many stakeholders as Consulted ('C') leads to analysis paralysis, where endless review meetings and conflicting SME opinions delay requirements baselining. Restrict 'C' assignments to essential subject matter experts.
RACI Matrix Table for Business Analysis Deliverables
The following table illustrates a standard, PMI-compliant RACI matrix governing core business analysis deliverables across an enterprise initiative:
| Business Analysis Deliverable / Activity | Business Analyst (BA) | Project Manager (PM) | Business Sponsor | Business SME / Product Owner | Solution Architect / Tech Lead | Quality Assurance (QA) Lead | Compliance / Security Officer |
|---|---|---|---|---|---|---|---|
| Needs Assessment & Business Case | R | C | A | C | C | I | C |
| Business Analysis Plan & Elicitation Strategy | R / A | C | I | C | C | I | I |
| Stakeholder Register & Engagement Plan | R / A | C | I | C | I | I | I |
| Requirements Management Plan (RMP) | R / A | C | I | C | C | I | I |
| Functional Requirements Specifications / User Stories | R | I | I | A | C | C | I |
| Non-Functional Requirements (NFR) Specifications | R | I | I | C | A | C | C |
| Requirements Traceability Matrix (RTM) | R / A | C | I | C | C | C | I |
| Requirements Verification & Quality Review | R / A | I | I | C | C | C | I |
| Scope Baseline Change Impact Analysis | R | A | C | C | C | I | C |
| User Acceptance Testing (UAT) Sign-Off | C | C | I | A | I | C | C |
Key Governance Takeaway: Notice how the single 'A' shifts appropriately based on the nature of the deliverable. For the overall Business Case, the Business Sponsor holds accountability ('A') because capital investment is their ultimate prerogative. For Functional Requirements, the Business SME or Product Owner holds 'A' because they represent the business domain. For Non-Functional Requirements (such as performance, concurrency, and security), the Solution Architect holds 'A'. For Change Control Impact Analysis, the Project Manager holds 'A' because scope changes alter the Triple Constraint (cost, schedule, and resources), while the BA acts as 'R' to perform the requirements dependency analysis.
Skills Assessment and Job Analysis: Profiling What Stakeholders Can Actually Do
The ECO lists job analysis and skills assessment alongside personas and RACI as stakeholder analysis techniques, and they answer a question the power/interest grid cannot: not how much influence does this stakeholder have, but what is this stakeholder actually capable of contributing and absorbing. Two failures follow directly from skipping this step. Elicitation sessions get designed for a level of abstraction the participants cannot work at, and transition requirements underestimate the training the future state demands.
Job Analysis
Job analysis decomposes a role into its constituent tasks, decision authority, tools used, and the frequency and criticality of each task. It is the technique that tells the business analyst which of the twelve people holding the title "Loan Processor" actually perform the exception handling that the new system must automate.
Skills Assessment
Skills assessment rates each stakeholder or role against the competencies the engagement and the future state require, exposing gaps before they become schedule risk.
| Stakeholder Role | Domain Expertise | Requirements Literacy (Reading Models) | System/Tool Fluency | Decision Authority | BA Response Dictated by the Gap |
|---|---|---|---|---|---|
| Branch Loan Officer | High | Low | Medium | Low | Elicit with job shadowing and concrete scenarios; validate with prototypes, never with BPMN diagrams |
| Corporate Treasury Controller | High | High | High | Medium | Suitable for formal model walkthroughs and decision-table review |
| Compliance Director | High | Medium | Low | High | Written specifications with regulatory citations; brief in prose, not notation |
| Product Owner (new hire) | Low | High | High | High | Pair with a domain expert before backlog refinement; high authority combined with low domain knowledge is the highest-risk cell in this table |
[!TIP] Exam Application: When a scenario reports that a requirements workshop produced silence, confusion, or blanket agreement from operational staff, the diagnosis is usually a skills mismatch rather than stakeholder disengagement. The corrective action is to change the elicitation technique and the representation to match assessed requirements literacy, not to escalate the stakeholders' non-participation to the sponsor.
Skills assessment also feeds Evaluation directly. The training volume, role-based curricula, and knowledge-transfer scope captured in transition requirements should be derived from the assessed gap between current competency and future-state demand, not estimated from headcount.
Dynamic Stakeholder Reassessment
Stakeholder analysis is not a static milestone that terminates once the project charter is signed. Experienced business analysts maintain the Stakeholder Register as a live, dynamic artifact. A formal review and update of stakeholder classifications must occur upon:
- Phase Gate Transitions: Moving from Needs Assessment to Planning, or from Analysis to Implementation, alters the operational involvement of direct versus indirect stakeholders.
- Organizational Restructuring or Personnel Turnover: Executive departures, mergers, or promotions frequently introduce new sponsors or change the political power balance.
- Scope Baseline Modifications: When a Change Request (CR) expands product boundaries into a new department or geography, previously unimpacted groups suddenly become direct or indirect stakeholders.
- Emergence of External Triggers: New statutory legislation, cybersecurity threats, or market disruptions can instantly elevate Dormant or Discretionary stakeholders into Definitive decision-makers.
An enterprise financial institution is launching a digital loan origination engine. The Chief Risk Officer (CRO) possesses formal executive authority to veto any architecture that violates credit risk underwriting policies, but she rarely attends sprint meetings and delegates daily requirements reviews to an operational risk manager. According to the Power/Interest Grid, which stakeholder management strategy should the lead business analyst implement for the CRO?
A regional hospital system is preparing to replace its clinical bed management software. A coalition of frontline triage nurses will experience massive disruptions to their daily clinical intake workflows once the system deploys in three weeks. While the nurses hold legitimate, urgent operational concerns, hospital governance grants them no budgetary authority or contractual veto power over the software vendor. According to Mitchell, Agle, and Wood's Salience Model, how should the business analyst categorize this nursing group?
During the formulation of a business analysis governance plan, the lead business analyst creates a RACI matrix for core project artifacts. On the row corresponding to the 'Functional Requirements Specification', the matrix lists both the Lead Business Analyst and the Department Business Sponsor as 'Accountable' (A). What is the primary governance risk of this configuration?