Stakeholder List, Map, or Personas
The BABOK groups the stakeholder analysis instruments under one number: the list, which records who exists, in what capacity and with what authority; the map, of which the BABOK names two common forms, the matrix and the onion diagram, which position the same population, one on power and interest, the other on distance to the solution; personas, which synthesise user archetypes out of research; and the RACI matrix, which assigns responsibilities activity by activity. The matrix and the onion are practised separately. The standard says the analyst applies "one or more" of them: the list produces the register, and the others consume it, each to answer a different question.
Purpose
Stakeholder analysis provides two guarantees, and the BABOK states them separately. The first is completeness: the analyst must have identified every possible source of requirements, because a forgotten stakeholder is a requirement discovered in acceptance testing. The second is fitness of engagement: each stakeholder must be understood precisely enough that the elicitation, collaboration and communication decisions taken about them are the right ones for that person and for the initiative. The first guarantee is the list's work. The second plays out on the three views built on top of it.
The scope of the sweep is wider than usually assumed. The BABOK places within it the stakeholders the initiative affects and those who share a common business need with it. The second half of the definition is almost always dropped. It is what pulls into the register people outside the change's impact radius: a unit that meets the same problem elsewhere, a department that will have to take on the same business rule, a partner whose process hinges on ours.
The family's deliverable is the register, plus the artefact the question calls for. The register is produced by the stakeholder list. The views are produced by the matrix, the onion diagram and personas; the responsibility grid, by the RACI matrix. The BABOK attaches the whole family to its task 3.2, Plan Stakeholder Engagement, which this work feeds.
Usage
When to use it
- A new initiative whose blast radius is still unknown: the sweep precedes any elicitation planning.
- A change crossing organisational boundaries: several units, external partners, a regulator.
- Before planning elicitation: the plan is a function of who is in it.
- A material scope change: scope moves the affected population, and the analysis follows it.
- An analyst long settled in the same teams: perceived stability is the trap the BABOK names, so run the sweep again.
- A shared business need outside the blast radius: the sweep extends to entities carrying the same need.
- An initiative stalled by an unexpected veto: the actor was missing from the register, or their power was underrated.
- A regulated domain: a stakeholder can be legally mandatory there.
When not to use it
- A small change inside one team, with no external touchpoint: keep the register; the three views add nothing.
- A stakeholder population verified as stable, register dated and current: refresh the register; verification replaces the full sweep.
- Low psychological safety: run the analysis on roles; keep the named assessment in the facilitator's private notes.
The shared frame
The family's instruments work on one population and in one loop: identify, analyse, maintain. They differ in what they do with the population once it is identified. Identifying the population is the work of the list alone.
HERMES sets the same division. A single task, Manage and inform stakeholders (5.4.3.43), covers identification, analysis and information, but two of the outcomes it produces are distinct: the stakeholder list and the stakeholder interests. The project manager draws up the list with the project sponsor, the interests with the user representative.
The BABOK names four characteristics to record and analyse for each stakeholder.
- Level of authority within the domain of change and within the organisation: this is one component of power, one of the two dimensions the matrix crosses. The matrix defines power as the ability to shape decisions, resources and the fate of the project: formal authority is only one part of it, alongside control of resources and informal influence. That ability is what the standard's prose calls influence.
- Attitude toward, or interest in, the change: this is the matrix's other dimension and a register column, where it is written in the stakeholder's own words.
- Level of decision-making authority: this is a register column, in natural language ("can refuse the go-live"), attached to a person.
- Attitude toward the business analysis work and role: none of the three views carries it. It lives in the register's free text.
That last characteristic is worth pausing on, because it is the one a reader will hunt for on a quadrant and not find. A stakeholder can be powerful and interested in the change while still regarding requirements work as an administrative formality that delays delivery. The fact is decisive for how elicitation is run. It drives the format of the sessions, the degree of formality and the time one will actually get, and it is recorded in the register as an observed fact: a precedent, a sentence spoken, a behaviour in session.
A last shared property is decay. The BABOK notes that a stakeholder's position moves under organisational, environmental or scope change, and it concludes that the analysis is iterative and reviewed frequently. The consequence bears on the whole family: a view built on a stale register is stale with it, and it keeps the same air of authority.
Choosing the right tool
The routing answer almost always begins with the register, then continues with the view that answers the open question. The register is the input the others consume. None of them rebuilds it, and a gap in the register propagates into every analysis built on it without any of them bringing the missing stakeholder back. The three views, for their part, are independent of one another: they answer three orthogonal questions, they coexist over one population, and once the register is in place each of them costs one session.
| The question you are asking | The tool that answers it | What you need first |
|---|---|---|
| Who is concerned, in what capacity, with what authority? | Stakeholder list | The sweep's sources: charter and mandate, org chart, process map, system interfaces, legal frame, contracts, snowballing. |
| Who weighs and what engagement strategy follows? | Stakeholder matrix | The register. |
| How close to the solution does each one stand? | Onion diagram | The register and a named solution scope to occupy the centre. |
| Who are we designing for? | Personas | A user segment recorded in the register and the research conducted on it: interviews, surveys. |
| Who answers for each activity, who does the work, who is consulted, who is informed? | RACI matrix | The register and the activity axis taken from the approved plan: the work packages, the deliverables or the decisions. |
An initiative starting out builds its register, then lays down its matrix to know where to spend an analysis budget that is finite. The same initiative, when it opens its solution scope to a neighbouring system, draws an onion over the same register to see who has suddenly become close. The same one again, when choosing between two screen flows, builds two personas on a user segment the register already carries. The three views coexist on the wall.
Each tool has a boundary. The family's most frequent confusion is asking one tool for work that belongs to another: expecting the onion to yield a priority order or the matrix to answer a design question.
| Tool | Consumes | Produces | Stays silent on |
|---|---|---|---|
| Stakeholder list | The sweep of documentary sources and snowballing. | The register, a living document: one row per stakeholder, one column per fact, a date of last verification. | Power, which belongs to analysis. The register carries no R, A, C or I code: its authority column is a fact in natural language. |
| Stakeholder matrix | The register, which it consumes without rebuilding. | The filled power and interest grid, four named quadrants, each stakeholder in one cell and one only, plus the register of justifications and of the triggers that would move them. | Distance to the solution. Accountability too: what someone answers for, activity by activity, is read off the RACI matrix. |
| Onion diagram | The register and a named centre. | One page: the solution at the centre, four labelled rings, each populated with named roles. | Power. A regulator lodged in the outermost ring can stop the project with a word. |
| Personas | The research conducted with the users of one segment: interviews, surveys. | The persona sheet, one page per archetype, and the pool of archetypes they form. | Stakeholders who are not users. The regulator, the sponsor and the internal reviewer will never become personas, and a persona carries no influence axis and no hierarchical rank. |
| RACI matrix | The register and the breakdown of the work: the packages, the deliverables or the decisions of the approved plan. | The filled grid, one row per activity and one column per stakeholder, a single accountable per row, with its legend and its review date. | Power and interest: the stakeholder matrix says how much time to spend on someone; the RACI grid says what they answer for. Buy-in too: a cell records an assignment; the agreement of the person named is obtained in the room. |
The BABOK describes a fifth tool under the same number, the responsibility (RACI) matrix, with its four assignments and its single-A rule: only one stakeholder receives that assignment. It answers a different question, the assignment of responsibilities activity by activity, and the RACI matrix is built separately. The boundary with the register runs there, and it is often crossed by mistake when an R or an A slips into an authority column.
AI considerations
On the completeness of the sweep, a language model proposes classes of stakeholder the room did not name; the practice, its guardrails and its own blind spot are covered with the stakeholder list.
Two judgements stay out of its reach, and the routing depends on them. The first is power. It is local, political and undocumented: who actually decides, whose opinion the sponsor takes before ruling, which department head has the title without the influence. A model that infers authority from job titles produces a plausible and wrong grid, which is more dangerous than a visibly incomplete one. The second is the persona: a persona not grounded in research is an opinion with a photograph, and synthetic users reintroduce the invented user the technique exists to eliminate.
The decision AI does not take is the routing itself. Which question am I actually asking and therefore which view must I produce? The answer depends on the decision the analysis has to serve, and that decision is written nowhere in the project's documents. A model asked for "a stakeholder analysis" produces everything the name covers and leaves the analyst to discover afterwards which of the views answered the question. The cost is one session per superfluous view and misplaced confidence in an artefact nobody asked for.
That leaves data protection. A register carries named people, their contact details, their interest and an assessment of their authority: these are personal data under the FADP, and an influence assessment is politically sensitive. Pouring a live register into a public online service is a disclosure of data within the meaning of the law.
Cost
The family's cost lies in keeping the register alive: the views are cheap once the register is built. Its freshness decides the value of every analysis built on it.
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Medium | Gathering the sweep's sources (charter, org chart, process map, interfaces, legal frame, contracts) and getting the right people together. Obtaining an up-to-date org chart often takes longer than the session it feeds. |
| Execution | Low | The sweep fits into one facilitated session and a few confirmation interviews. Each view laid on the register afterwards costs one more session, and the second view costs less than the first because the sweep is already banked. Personas are the exception: their cost is the cost of user research. |
| Documentation | High | The register decays. Post-holders change, delegations shift, scope widens, and none of that leaves a trace in the document. A named owner, a review pinned to the milestones and a last-verified column are the family's real price, and it runs for the whole life of the initiative. |
Tooling
The whiteboard and sticky notes serve the first pass and the two spatial views: an onion and a matrix are drawn on the wall, in session, in their natural form. They stop being suitable as soon as the register enters the picture, because a sticky note does not carry ten columns.
The spreadsheet is the implementation of the register in the great majority of organisations, and it is enough: one row per stakeholder, one column per attribute, a sort on the last-verified date that brings stale entries to the top. The shared document or the wiki-style space lifts its limit as soon as several people maintain the register, by bringing the version history that shows who changed what and when.
The choice of tool is a data protection choice, since the register carries named people and assessments about them: hosting, access rights and retention period are settled with the same seriousness as the functionality. The tools specific to each view run from a grid template to portfolio management software, which offers a stakeholder register as a first-class object.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.43 Stakeholder List, Map, or Personas: the tools and the map's two common forms, the characteristics to analyse, the use of "one or more" of them and the cross-reference to task 3.2 Plan Stakeholder Engagement.
- IIBA KnowledgeHub, Stakeholder Analysis: the identify, analyse, maintain loop on which the frame shared by the family's tools rests.
- IIBA KnowledgeHub, Analyze Stakeholders: the analysis of the characteristics once the sweep is done.
- HERMES 2022, Project Management Reference Manual, Swiss Confederation, Federal Chancellery, task 5.4.3.43 Manage and inform stakeholders: a single task covering identification, analysis and information. Two of the outcomes it produces are distinct, the stakeholder list and the stakeholder interests. The project manager draws up the list with the project sponsor and the interests with the user representative.
- Swiss Confederation, Federal Act on Data Protection (FADP), SR 235.1: the stakeholder register carries personal data, which governs its hosting, its disclosure and its retention period.