Techniques BABOK Guide v3, 10.43
Stakeholder List, Map, or Personas
In short A family of simple tools for finding everyone affected by a change and understanding how much they matter, what they want, and how they feel about it. You end with a stakeholder register, a map of influence, clear task responsibilities and, for user-facing products, personas the team designs for.
Based on: IIBA, BABOK® Guide v3, technique 10.43 “Stakeholder List, Map, or Personas”; business analysis training materials; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 6; A. Cooper, The Inmates Are Running the Asylum, ch. 11.
On this page
What it is#
The BABOK® Guide groups several tools under this technique. All of them answer three questions: who the stakeholders are, how much authority they have, and what their attitude to the change is.
- Stakeholder list: an exhaustive list built through brainstorming and interviews, then grouped into categories.
- Stakeholder map: a diagram of how stakeholders relate to the solution and to each other. Start from the solution boundary and refine it as you learn.
- Influence/interest matrix: a 2×2 grid of how much influence a stakeholder has against how strongly the change affects them. High on both: work closely with them. High influence, little impact: keep them satisfied (the training materials put it bluntly: do not annoy them). Low influence, high impact: keep them informed. Low on both: monitor.
- Onion diagram: concentric circles showing how close each group is to the solution, from the delivery team in the center to the outside world.
- Responsibility matrix (RACI): for each task, who is Responsible (does the work), Accountable (owns the result and decides; exactly one per task), Consulted (gives input, two-way), and Informed (receives results, one-way). The BCS book also describes RASCI, which adds Supportive: someone who provides help or resources to the Responsible person.
- Personas: fictional but specific user archetypes, written as a short narrative, that help the team empathize with how real people will use the product.
What the BCS book adds. It names common stakeholder categories (customers, partners, suppliers, competitors, regulators, owners, employees, managers) and warns that one formal category, such as “managers”, can hide very different interests. It extends the power/interest grid to six responses: ignore (but use general channels), keep informed, keep onside, watch, keep satisfied, and actively manage the key players. It rates current attitude on a scale from champion through supporter, neutral, critic, and opponent to blocker. It also reminds you that individually weak stakeholders can become powerful together, citing Coca-Cola’s return to its original recipe after mass consumer protest.
What Cooper adds about personas. Alan Cooper builds design personas on users’ behavior and goals, not on demographics; that is what separates them from marketing segments. He picks a primary persona, whose needs no interface designed for someone else could meet, and sometimes a negative persona to state who the product is not for. See Personas for the full method.
When to use it#
- At the start of any initiative, to plan engagement (BABOK task Plan Stakeholder Engagement, 3.2), and again whenever the scope or organization changes.
- To decide whom to involve in elicitation and how to communicate with each group.
- To track how groups and attitudes shift over time.
- Personas: whenever the solution has end users with different goals.
Two cautions. In a long-standing team the exercise can become a formality, because little seems to change. And ratings of influence and attitude are politically sensitive: keep them in a working document with limited circulation.
How to do it#
- Start from the scope and ask: who is affected, who decides, who supplies, who regulates, who could block?
- Brainstorm a list, then extend it in interviews by asking every interviewee who else you should talk to.
- Group the list into categories; split categories that hide different interests.
- Rate power and interest, place each group on the grid, and choose a response.
- Record current and desired attitude, and what would move it.
- Build a RACI (or RASCI) for the main analysis tasks and deliverables. Check there is exactly one A per row.
- For user-facing solutions, draft personas from research, not imagination, and pick a primary persona.
- Update the register at each milestone.
Example#
The Workshop, a fictional chain of bike-repair workshops, builds a register for its online booking project:
| Stakeholder | Power | Interest | Attitude now | Response |
|---|---|---|---|---|
| Owner (sponsor) | High | High | Champion | Manage actively |
| Workshop managers | High | High | Mostly supporters, two critics | Manage actively; address the critics’ concerns |
| Mechanics | Low | High | Neutral | Keep informed; involve in status design |
| Front-desk staff | Low | High | Critic | Keep informed; show how phone calls will drop |
| Customers | Low alone, high together | Medium | Neutral | Keep informed; test with real users |
| Parts supplier | Medium | Medium | Supporter | Keep onside |
RACI for key analysis tasks, adapted from a practice example in business analysis training materials (one person may hold two letters):
| Task | R | A | C | I |
|---|---|---|---|---|
| Elicit booking requirements | BA | BA | Managers, front desk, mechanics | Development team |
| Prioritize release 1 features | BA | Owner | Managers, development lead | Front desk, mechanics |
| Acceptance testing | Front desk, managers | Owner | BA, development team | Mechanics |
Persona (fictional): Marta commutes by bike every day; it is her only transport. She wants her bike back by the next evening without phoning anyone. Her frustration: not knowing whether the repair has even started. Designing for Marta made status messages a higher priority than a polished booking page.
Common mistakes#
- Listing only people you already know → ask every interviewee who else is affected; check for regulators, suppliers, and other easily missed categories.
- Treating a category as one voice → split it when interests differ.
- A map drawn once and filed → revisit it at each milestone.
- Two or more A’s on a task → keep exactly one accountable role.
- Personas from demographics or guesswork → base them on observed behavior and goals.
- Designing for the buyer instead of the user → Cooper warns that the person who buys is often not the person who uses.
- Sharing frank ratings widely → keep sensitive assessments private.
Template#
Stakeholder plan: <name / group>, <role>
Power: H/M/L Interest: H/M/L Response: <manage / satisfy / inform / watch / onside>
Interests and likely questions: <list>
Current attitude: champion | supporter | neutral | critic | opponent | blocker
Desired attitude and role: <e.g. supporter, steering group member>
What we need from them: <actions>
Key messages: <list>
Planned actions and communications: <what, when, who>
| Task / deliverable | R | A | C | I |
|---|---|---|---|---|
Persona: <name>, <one-line context>
Goals: <list> Frustrations: <list> Primary persona: yes/no
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.43 “Stakeholder List, Map, or Personas”.
- Business analysis training materials, module on Business Analysis Planning and Monitoring, and a RACI practice example.
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010, ch. 6 (stakeholder categories, power/interest grid, attitudes, RASCI).
- A. Cooper. The Inmates Are Running the Asylum. Sams, 1999, ch. 11 (personas).