Skill Hub — Business Analysis

Stakeholder Analysis Working Skill

Map who matters, what they control, and how to get reliable information from them — before you waste time interviewing the wrong people.

What this skill is for

Every project, incident, or process change involves people who make decisions, people who do the work, and people who suffer when things break. This skill identifies all three groups, verifies their claims to ownership, and plans how to engage each one so that the right information reaches the right person at the right time. The output prevents the common failure mode where critical insights sit with unconsulted users while executives debate scope they do not operate.

When to use this skill

A project kickoff meeting ends with no clear list of who to talk to next.
An incident affects multiple departments and each blames a different root cause.
A process change crosses organizational boundaries and no one claims end-to-end ownership.
A data governance initiative needs data owners, but the org chart shows only department heads.
An integration failure spans multiple systems and each team says "not our problem."
A requirements document is rejected because "you should have asked [person no one mentioned]."

Real work situations

SAP BP replication failure between S/4 and CRM

Business partners created in SAP S/4 do not appear in Salesforce. The CRM team says it is an SAP problem. The SAP team says the IDoc was sent. The real stakeholders are: the MDM team (owns BP data model), the integration team (owns the IDoc/PI flow), the sales operations team (suffers from missing customers), and the data steward (approves BP changes). Without mapping all four, the fix addresses only the technical symptom and leaves the governance gap.

New credit management rollout

A project to implement automated credit checks needs to identify who sets credit limits, who approves exceptions, and who is notified when orders block. The finance director sets policy but does not know the SAP transaction. The credit controller uses the transaction but cannot change configuration. The sales manager wants exceptions but has no authority. The stakeholder map must separate policy authority from operational execution from system configuration.

Invoice verification delays in three-way match

Invoices sit unposted for weeks. The process spans: procurement (creates PO), warehouse (confirms GR), AP (receives invoice), and a shared service center (posts). Each team has a different system view. The stakeholder map must identify who receives the physical invoice, who enters data, who resolves discrepancies, and who approves payment — because fixing any one step without the others just moves the bottleneck.

Inputs required

Organizational chart or directory showing departments and reporting lines.
System ownership matrix or RACI chart (if it exists).
Incident tickets showing which teams were involved in past issues.
Process documentation or Process Analysis Notes for the affected workflow.
Previous project stakeholder lists (if available).
System user role assignments to verify who has access to which transactions.
List of known integration points and their technical owners.

Questions to ask

Who can confirm this process works as documented, and who can show you the actual screens they use?
Who loses money, time, or compliance standing when this process or system fails?
Who has the authority to change this configuration, rule, or workflow?
Who is consulted today but not informed? Who is informed but not consulted?
Which stakeholder's absence from the project would guarantee failure?
Who claims ownership but cannot demonstrate system access or decision authority?
Who performs the work but is not in any meeting or distribution list?
Which role is missing from the org chart but essential to the process?

Working method

List all roles that touch the process or system. Start from the process steps, not from names. For each step, ask: who performs it, who approves it, who is notified, who suffers if it fails.
Classify by influence and interest. Use a simple power grid: high influence / high interest (key players), high influence / low interest (keep satisfied), low influence / high interest (ground truth source), low influence / low interest (monitor only).
Identify the information each stakeholder holds. Document what they know that no one else knows: passwords, exceptions, workarounds, historical reasons, unwritten rules.
Map decision authority vs operational involvement. Separate people who can say yes from people who do the work. A person can be both, but rarely is.
Verify ownership claims with system evidence. Check user roles, approval workflows, and configuration change logs. If a stakeholder claims ownership but has no system access, flag as unverified.
Plan engagement method per stakeholder. Match the method to the classification: interviews for ground truth, briefings for keep-satisfied, workshops for key players.
Document in Stakeholder Interview Briefs. One brief per interview. Include facts confirmed, assumptions surfaced, needs identified, and follow-up actions.
Validate and update the map. Stakeholder maps decay. Revalidate after major project milestones or incidents.

Decision rules

If a stakeholder claims ownership but cannot show system access or documented authority, ownership is unverified — do not rely on it.
If two stakeholders claim the same ownership, document the conflict and ask who controls the budget or configuration for that area.
If a stakeholder is high-influence but low-interest, keep them informed with summaries; do not overload with operational detail.
If a stakeholder is low-influence but high-interest, they are your best source of ground truth — interview them first.
If no stakeholder can be found for a critical process step, flag it as a governance gap before proposing any process or system change.
If stakeholder analysis reveals missing roles that no one is hiring for, add them to the project risk log.
If a stakeholder was not involved in a past incident but should have been, update the engagement plan to include them going forward.

Deliverables

Stakeholder Map — Grid or matrix showing each stakeholder's role, influence, interest, information held, and engagement method.
Stakeholder Interview Brief — Per-interview record. See template below and Artifact Templates for full format.
Ownership Verification Matrix — Table mapping claimed ownership to system evidence: user roles, approval rights, configuration access.
Engagement Plan — Schedule and method for each stakeholder: interview, briefing, workshop, review.

Templates

Stakeholder Interview Brief (compact)

---
artifact: Stakeholder Interview Brief
id: SIB-001
date: YYYY-MM-DD
interviewer: Name
stakeholder: Name | Role | Area
---

## Context


## Questions asked


## Answers given


## Facts confirmed


## Assumptions surfaced


## Needs identified


## Pain points


## Constraints


## Risks mentioned


## Decisions required


## Follow-up actions


## Related interviews

Quality checklist

Every critical process step has an identified stakeholder.
Every stakeholder has a verified contact, role, and area.
Ownership claims are backed by system access or documented authority.
No critical stakeholder is missing from the map.
Engagement methods are tailored to influence/interest classification, not generic.
Interview briefs separate facts from assumptions.
The map is dated and has a planned review trigger.

Common mistakes

Assuming the org chart equals decision authority. Consequence: you interview department heads who delegate to unseen operators, missing the people who actually know the workarounds.
Treating all stakeholders equally. Consequence: key players are under-engaged while low-influence stakeholders are overloaded with detail they cannot act on.
Failing to verify ownership claims. Consequence: decisions are made by people without authority, or authority is assumed by people who only perform the work.
Not updating the stakeholder map as the project evolves. Consequence: new blockers appear late because roles changed, people left, or new teams became involved.
Ignoring stakeholders who are hard to reach. Consequence: critical information sits with remote teams, external vendors, or part-time users who were never interviewed.

Agent instructions

AI agents should use this skill to identify and map stakeholders before conducting interviews or making recommendations.

Start with process steps, not names. For each step, ask who performs it, who approves it, and who suffers when it fails.
Verify ownership claims by checking system user roles, approval workflows, or documented authority. Do not accept job titles as proof.
Classify stakeholders by decision power and operational involvement, not just by job title or seniority.
Produce a Stakeholder Interview Brief for each interview. Separate facts confirmed from assumptions surfaced.
Flag missing stakeholders as governance gaps. If a critical step has no owner, state this explicitly and do not proceed as if ownership exists.
Link to Atlas diagnostics when stakeholder gaps relate to SAP processes. For example, unclear credit management ownership should reference SAP Credit Management Diagnostics.
Do not invent stakeholders or contact details. If a role is missing, flag it. Do not fill gaps with generic placeholders.

Related skills

Related Atlas pages

SAP Process Audit — Diagnostic context for process ownership.
SAP Sales Order Block Diagnosis — Cross-functional ownership in O2C.
Master Data Issues Blocking Sales Orders — Scenario with multiple stakeholder layers.

Verification status and limitations

This skill is a public working interpretation of stakeholder analysis practices. It is not official BABOK or IIBA documentation. It focuses on enterprise and SAP contexts where system evidence can verify ownership claims.

Known limitations: the skill assumes access to organizational charts, system roles, or process documentation. In flat organizations or startups without formal roles, the classification framework may need adaptation. The skill does not cover political stakeholder management or influence strategies beyond information engagement.