Stakeholder List

Purpose

The register answers an operational question: who has to be involved, consulted or informed and by what means. It records every person, group and organisation that can affect the initiative or be affected by it, and for each it sets down enough factual attributes to plan elicitation, collaboration and communication. BABOK situates the technique in the planning of stakeholder engagement (task 3.2) and gives it an objective: the analyst has identified every possible source of requirements and knows each stakeholder well enough for the engagement decisions to be the right ones.

Every decision about how to run an analysis rests on facts about people: who to interview first, who has to sign off a scope change for it to hold, who will learn of the decision once it is taken and through which channel. The register writes those facts down once and makes them contestable, correctable and transferable.

The deliverable is the register itself, kept as a living document. It is also the raw material of the three neighbouring techniques, the stakeholder matrix, the onion diagram and personas, all three of which consume it without rebuilding it. A gap in the register therefore propagates everywhere: a stakeholder missing from the list is missing from every analysis built on it. Completeness of the census is the quality criterion of the technique, ahead of the refinement of its columns.

Usage

When to use it

• Launch of an initiative: build the register before any elicitation; it determines who will be interviewed.
• Scope change: the new scope touches units and roles absent from the initial register.
• Planning an elicitation or a workshop: deciding who to invite, who to consult next, who to inform of the outcome.
• Reorganisation or phase change: incumbents change, decision authority shifts, the register follows.
• An analyst joining an initiative in flight: a current register is the fastest way to learn who counts and in what capacity.
• Foreseeable authority dispute: the authority column settles in advance who approves what.
• Solution to be operated by others: record the maintainers before the design ignores them.
• Regulated domain: record the supervisory authorities whose rules will become requirements of the project.
• Upstream of a matrix, an onion diagram or personas: all three consume this register and none rebuilds it.

When not to use it

• Stable team that knows itself, low decision stakes: direct informal engagement costs less than the register.
• Census already done and current, the question is positioning: move to the stakeholder matrix.
• Real need to formalise who approves what, activity by activity: the RACI matrix carries the R/A/C/I.

Description

What an entry carries

BABOK names four characteristics to identify and analyse for each stakeholder: their level of authority in the domain of the change and in the organisation, their attitude to or interest in the change being undertaken, their attitude to the analysis work and the analyst's role. The fourth is decision-making authority. A workable register converts these characteristics into columns that can actually be filled in and read back. Ten attributes are enough, and each holds its place because a planning decision depends on it.

• Name and point of contact: the person holding the role today, with their contact details. You open this column on a Tuesday morning to call somebody into a meeting.
• Role in relation to the initiative: the function relative to the change (sponsor, key user, operator, regulator, supplier).
• Reporting unit or organisation: the internal department or external organisation they belong to. This attribute hooks the register to the organisation chart and flags the whole unit the census forgot.
• Category: internal or external, then the nature of the relationship (sponsor, user, operator, maintainer, regulator, supplier, partner, customer, staff representation). A coarse classification that shows which category stayed empty.
• Interest in the change: what the stakeholder expects or fears from the initiative, stated in their own terms.
• Decision authority: what they can approve, block or merely comment on, written out in plain language ("can refuse go-live", "consulted, no decision-making power").
• Availability: the time and access they can actually give. A highly interested but unavailable stakeholder calls for a different engagement tactic from an available and lukewarm one, and the column makes that difference visible before the workshop is planned.
• Channel of influence: the way they actually carry weight, through the formal hierarchy or through expertise and relationships. A descriptive note.
• Communication preference: the channel and cadence that work with them (summary note, workshop slot, one-to-one interview).
• Last verified: the date the entry was confirmed and by whom. This attribute makes staleness visible. Nearly every register lacks it.

The first trap is to conflate the role and the person. An entry that says "head of production" without naming the current incumbent does not let you call anybody in. An entry that carries only the name becomes false the day that person moves to another job, and nothing in the document flags it. The two facts are distinct. The register carries both and keeps them reconcilable: the role outlives the incumbent, the incumbent gives the address.

Some entries designate a whole class. The insured on a portal number in the hundreds of thousands, the healthcare providers in thousands of practices. Neither has a phone extension. A class is entered in the register as an entry in its own right, and it carries what a named entry does not have to carry. The segmentation criterion first: the insured person who uses the portal is not the insured person who telephones the service desk, and if the design decision separates them, the register separates them. The representative next, named, with the basis of their legitimacy: an association that is party to a convention, an ombudsman, a user panel, a staff delegation. The provenance of the interest last, because the rule that interest is gathered from the interested party does not survive three hundred thousand people: the interest of a class is gathered from a sample, from the call reasons logged by customer service or from its representative, and the register writes down which of the three. A class entry is the entry point of personas: the register records the segment, personas draw the archetype from it.

The second trap is political. Recording that a senior executive has little real authority or is lukewarm about the project, in a document others will read, is delicate, and BABOK itself notes that characterising a stakeholder can be complicated and appear politically risky. The rule that holds: every characterisation rests on a verifiable fact and is worded as one. "Can stop the project" is justified by a written delegation of authority or by a precedent. What the register cannot justify, it leaves in the analyst's private notes.

The identification sweep

BABOK cites only brainstorming and interviews as techniques for producing the list. Both have the same limit: they surface the stakeholders the people in the room already know about. Yet the quality criterion of the register is completeness. Identification is therefore run as a deliberate sweep of sources, each closing a blind spot the others leave open.

• Project charter, mandate, feasibility study: the sponsor, the budget holders, the declared scope.
• Organisation chart: the reporting line, the units affected, the current holders of the posts.
• Process map: every role that executes, controls or receives a step of the modified process, including outside the commissioning department.
• System interfaces: the upstream and downstream systems and above all the teams that operate them. This is the only pass that surfaces the maintainer.
• Legal and regulatory framework of the domain: the supervisory authorities whose rules bind the initiative. This is the only pass that surfaces the regulator.
• Contracts and agreements: suppliers, service providers, partners and the commitment that binds them to the company.
• Snowballing: ask every confirmed stakeholder who else should be on the list and repeat until no new name comes out. This is the pass that surfaces informal influence and undocumented roles.

Two blind spots resist the ordinary sweep and each deserves an explicit pass. The first is the maintainer. Requirements analysis happens before go-live, and the people who will take the solution over afterwards (application support, system administration, operations, the service desk) are not yet part of the project when the census is made. They are nonetheless the ones who will live longest with the decisions taken, and they are usually discovered the day after go-live, when the first incident arrives. ISO/IEC/IEEE 29148 names them in its definition of a stakeholder, alongside end users and developers, and that definition is a guardrail: it is broader than the list a workshop produces.

The second is the regulator. Nobody in the room reports to them, nobody runs into them and no internal brainstorm surfaces them. The question is asked as a step in its own right: which bodies apply rules this initiative has to comply with? The same 29148 standard places regulatory and supervisory authorities among stakeholders. A regulatory requirement discovered in acceptance testing is a requirement discovered too late, and it almost always arrives through somebody who was not in the register.

Running the identification

1. Frame the scope of the initiative. The register relates to a precise change. A vague scope produces a list of everybody, which amounts to a list of nobody.
2. Assemble the sources of the sweep before the first session. Obtaining these documents is often the slowest step of the work.
3. Hold a facilitated session with the sponsor and the stakeholders already known, to produce the first list. It will be incomplete.
4. Sweep the sources one by one, skipping none. Each source adds names the session did not produce, and the number of additions per source is itself information about the quality of the initial census.
5. Make an explicit pass on maintainers and an explicit pass on regulators.
6. Apply snowballing to saturation: every confirmed stakeholder names the others, and you stop when a full round produces no new name.
7. Fill in the ten attributes for every entry. Interest and authority are gathered from the person concerned or from a verifiable source, never deduced from the organisation chart; the interest of a class is gathered from its representative or from a sample, and the register writes down where it came from.
8. Validate the register with the sponsor and two or three business experts. This review catches the confusion between role and person, whole units missing and empty categories.
9. Name an owner of the register and fix its review cadence before circulating it. A register published without an owner is a register already ageing.

Keeping the register alive

The most frequent failure of the technique is a register filled in once, at launch, then never reopened. Incumbents move on, a delegation of authority moves, the scope extends to a department that was not in it, a supplier is replaced. None of this leaves a trace in the document, which keeps exactly the same air of authority as it becomes false. The register then costs what it was meant to save: a workshop convened without the person who can approve, a decision circulated to a list that has been wrong for four months, a regulator discovered in acceptance testing. BABOK notes that a stakeholder's position can change under organisational, environmental or scope changes.

The remedy comes down to three inexpensive mechanisms. A named owner, usually the analyst, answers for the freshness of the register. A cadence hooked to milestones rather than to the calendar: the register is reviewed at every phase gate, every scope change, every reorganisation and every departure or arrival among the people in it. A monthly review in the diary produces a ritual, a review triggered by an event produces a fact. Finally, the last-verified column carries the date and the author of the confirmation. An entry that has not been reconfirmed since before the last scope change is suspect, and the column shows it at a glance. Without it, all rows look equally fresh, including the ones that are ten months old.

The register on a HERMES project

HERMES, the Swiss Confederation's project management method, makes the register a mandatory outcome. The Stakeholder list (outcome 4.4.1.49, Stakeholderliste) is produced in the initiation phase, then kept up to date throughout the project, and the method assigns it three uses: managing the stakeholders, working directly with them and planning the communication.

The method also names those who write it: the project manager draws up the list with the project sponsor. It files the assessment built on that register in a separate, non-public outcome, the stakeholder interests (outcome 4.4.1.48), which is where the positioning handled by the stakeholder matrix belongs.

The register in a data initiative

IIBA's Guide to Business Data Analytics (§3.16) adds two attributes specific to data work. The first is how each stakeholder consumes and generates data: who enters it, who extracts it, who receives a report without ever opening the source. In an initiative spanning several units, those habits show which sources have to be integrated, and discovering them late amounts to discovering a whole system late.

The second is the person's familiarity with data analytics, which governs the level of detail and the kind of visualisation they can be given. The same result is presented differently to an executive team and to the people who will run the model, and the register is where that difference is recorded once rather than rediscovered at every readout.

What belongs to the neighbouring techniques

The register stops where the analysis begins. The stakeholder matrix positions the entries by their power and their interest and derives an engagement strategy per quadrant. The onion diagram sorts the same entries by distance from the solution: who touches it directly, who touches only its periphery. Personas distil an archetype from a user segment recorded in the register and the research conducted on it. A design choice can be tested against that archetype. All three consume the register, none replaces it. For the full analysis of engagement, BABOK refers to its task 3.2, Plan Stakeholder Engagement.

The boundary most often crossed by mistake is that of the RACI matrix. The register's "decision authority" column is a factual statement in natural language, attached to a person: "can refuse go-live". The R/A/C/I crosses responsibilities with the project's activities or decisions, and its columns are activities. Slipping an R, A, C or I code into the register produces a hybrid that truncates the census and makes the matrix unusable.

AI considerations

A language model helps most on the document sweep. Fed the project's documents (charter, organisation chart, process map, contracts, meeting minutes, ticketing-system exports), it extracts the people and roles named faster than a manual read. It excels at the mechanical part of the work: normalising one person appearing under three spellings into a single entry, flagging duplicates, filling the columns consistently, turning the messy output of a brainstorm into a structured grid. The model does a second, smaller job for very little effort: it checks the provisional register against the grid of categories and flags the ones that stay empty. "No external entry in the regulator category" is a mechanical observation a machine produces every time and a tired room at the end of a workshop never produces.

Two columns escape the model. Authority and interest describe a lived reality. Who actually decides, whose view the sponsor takes before ruling, which rivalry makes a joint workshop unproductive, which department head has a title without influence and which expert has the influence without the title: none of that is written in any document the model can read. A model that deduces authority from job titles produces a register that is plausible and false, which is more dangerous than one that is visibly incomplete. Interest has the same property: what a stakeholder expects from the change is obtained by asking them and is recorded in their words.

The model silently reproduces the blind spot it was meant to close. Working only from the documents supplied, it leaves out every stakeholder those documents do not mention: the regulator nobody wrote down, the supplier under an informal arrangement, the support team whose name appears in no project document. The result looks exhaustive. The deliberate sweep of the categories and the human validation step remain mandatory whatever tool produced the draft.

That leaves data protection. It bears on two regimes that haste conflates. The register itself contains named people, their contact details and assessments of their authority and their interest: these are personal data under the FADP, and some of those assessments are disclosable to the person concerned when they exercise their right of access (art. 25 FADP). Those facts forbid pouring a live register into a third-party service before the processing has been assessed. The data the project processes falls under another regime: invoices and care services, hence health data, which the FADP classes as sensitive personal data (art. 5 let. c). The first regime explains why the register is handled with care. The second explains why a data protection authority appears in the register as a stakeholder.

Examples

A Swiss health insurer (LAMal) operating in several cantons, with 240'000 insured persons and some sixty claims handlers, is digitising the handling of its reimbursement claims, on a budget of CHF 1'900'000. The initial object was a self-service portal for the insured. In April 2026 the scope was extended to the automated intake of invoices sent by healthcare providers, some 2'300 medical practices, hospitals and physiotherapists who bill the insurer under the tiers payant system within the meaning of art. 42 para. 2 LAMal. Here is an extract of the register after the full sweep.

Five of the nine entries come from the sweep. L. Aebischer appeared only on the pass through the system interfaces: he attends no project meeting, he appears in no minutes and he will nonetheless take the solution over the day after go-live. The FOPH and the FDPIC surfaced on the pass through the legal framework, the first because it supervises social health insurance under the LSAMal, the second because the invoices processed are health data. The cantons arrived on the same pass, art. 65 para. 1 LAMal making them the ones who grant the premium reductions the portal displays. The healthcare providers came out of the pass through contracts and agreements, the tariff convention being what binds them to the insurer. None of the five would have surfaced from a round-table among employees, and each would have produced a late incident.

The last-verified column does its work on the medical adviser's row. His entry dates from 12 February 2026, before the April extension: it describes his role on the portal for the insured alone and says nothing of the automated intake of invoices, which is now the source of the services he will have to contest. The former project manager who confirmed it has left the insurer. The entry is therefore suspect. Without this column, the nine rows look alike and are read with the same confidence.

The grid carries the seven attributes the choice of participants depends on. The other three, availability, channel of influence and communication preference, say how to engage the person, and they sit in the entry sheet, which expands when needed. Here is C. Meylan's, complete.

These three attributes are missing every time an elicitation is planned from memory. "Does not read project emails" is the fact that changes how you approach C. Meylan.

Visualisations

The register comes in two views: the grid, which is scanned to take in a population, and the entry sheet, which is opened to prepare an interview. Its construction, by contrast, is a flow: heterogeneous sources converge on a single list.

The register is one view among several on the same population. The question asked determines which one to produce.

Cost

The cost of the technique shifts over time. Producing the first register is quick; assembling the sources that feed it is slower. Keeping it current costs effort for the whole duration of the initiative.

Tooling

The whiteboard and sticky notes suit the first pass, the brainstorming one, before the register needs a structure. They stop working once the ten attributes come into play, because a sticky note does not carry ten fields.

The spreadsheet is the real implementation of the register in most organisations, and it is sufficient. One row per stakeholder, one column per attribute. Filtering and sorting come free, and the last-verified column, sorted ascending, brings the stale entries to the top. Volere publishes a freely downloadable stakeholder analysis template, of exactly this shape, which makes a reasonable starting grid. The spreadsheet reaches its limit the moment several people have to maintain it simultaneously.

A shared document, an intranet page or a wiki-type space lifts that limit. Several people keep the register together there, and the version history says who changed which entry and when. That matters as soon as the analyst is no longer the only one touching the register.

Project and portfolio management software that offers a stakeholder register as an object in its own right brings one gain: the reminder of the review cadence becomes a system deadline rather than a personal discipline. The gain justifies the tool when the initiative is large enough that keeping the register has to be planned. Choosing the tool is a data-protection choice too, since the register carries named people: hosting, access rights and retention period are decided with the same seriousness as the functionality.

Exports from the organisation chart and the HR system, exports from the ticketing system and the contract repository supply the raw material of the sweep, and you ask for them at the framing stage.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.43 Stakeholder List, Map, or Personas: definition of the technique, characteristics to analyse, cross-reference to task 3.2 Plan Stakeholder Engagement.
• IIBA KnowledgeHub, Define Groups and Identify Stakeholders: the identification approach applied.
• IIBA KnowledgeHub, Maintain Stakeholder Analysis: keeping the register current as a continuing activity.
• ISO/IEC/IEEE 29148:2018, Systems and software engineering, Life cycle processes, Requirements engineering: the normative definition of a stakeholder, explicitly including maintainers and regulatory or supervisory authorities.
• Volere, Stakeholder Analysis Template (Atlantic Systems Guild): a freely downloadable register template.
• HERMES 2022, Project Management Reference Manual, Swiss Confederation, Federal Chancellery, outcome 4.4.1.49 Stakeholder list and task 5.4.3.43 Manage and inform stakeholders: the register produced in the initiation phase then kept up to date throughout the project, with communication planning among its three uses. The project manager draws it up with the project sponsor.
• Swiss Confederation, Federal Health Insurance Act (LAMal / KVG), SR 832.10: art. 35 (admitted healthcare providers), art. 42 (tiers garant and tiers payant), art. 57 (the medical adviser appointed by the insurer), art. 65 para. 1 (premium reductions granted by the cantons).
• Swiss Confederation, Health Insurance Supervision Act (LSAMal / KVAG), SR 832.12: supervision of social health insurance, exercised by the Federal Office of Public Health.
• Swiss Confederation, Federal Act on Data Protection (FADP), SR 235.1: art. 5 let. c (health data is sensitive personal data) and art. 25 (right of access), the regime applicable to the personal data the register carries.
• IIBA, Guide to Business Data Analytics, §3.16 Stakeholder List, Map, or Personas: the two attributes specific to data work, how a stakeholder consumes and generates data and their familiarity with analytics.