Onion Diagram
The onion diagram (BABOK 10.43) is a stakeholder map drawn as concentric circles. The solution under construction occupies the centre, and four rings arrange the stakeholders around it by their distance from that solution: those who build it, those whose work changes when it arrives, the organisation that surrounds them, then the outside world of customers, suppliers and regulators. Position in a ring encodes proximity: a regulator lodged in the outermost ring can stop the project with one word. Its value lies in completeness, because forcing every ring to be populated surfaces the stakeholders the team has not yet named.
Purpose
The onion diagram answers a question of distance: who touches the solution directly, who sees their work change when it arrives, who surrounds it without touching it, who lives with its effects from outside the enterprise. It arranges stakeholders in concentric rings around the solution under construction, and that position then dictates the mode of contact, from daily work with the inner ring to formal consultation of the outer one.
Two decisions depend on it. The first is the solution scope: the centre must be named before the first stakeholder name is placed, and the placement exercise forces a ruling on what the solution encompasses, since every name is judged by its distance from that centre. The second is the engagement plan: who to consult directly, who to observe at their workstation, who to inform, who to reach through a representative. The ring gives the default answer to that question, before anyone's power has been weighed.
Its own contribution is completeness. A team spontaneously names those who build the solution and those who will use it every day. Regulators, suppliers, integration partners and end customers arrive late, often after the architecture has been frozen without them. The diagram makes that omission visible: an empty outer ring is a question put to the room.
The deliverable is one page: four labelled rings, each populated with named roles, the solution at the centre. It is read at a glance and challenged just as fast. Position in a ring encodes proximity. Power and interest are read on the stakeholder matrix, the register of names, roles and interests comes from the stakeholder list that feeds the onion, and the user archetype that serves design decisions is the persona.
Usage
When to use it
- Solution scope still open: placing stakeholders forces the room to state what the centre contains.
- Several layers of organisational distance: team, affected unit, enterprise, outside, every ring carries people.
- Before planning elicitation: distance from the centre dictates who is consulted directly and who is informed.
- Stakeholder list already established: the onion positions it in one session, without rebuilding it.
- Doubt about completeness: an empty outer ring is visible and challengeable, regulator, supplier, host.
- Disagreement on the word "user": placing the names separates the internal handler from the end customer.
- Material change of scope: a new integration partner repopulates a ring, the map is redrawn.
Description
The centre and the four rings
The centre carries the solution, defined by its boundary: what the system does, what it replaces, what it leaves out. Until that boundary is stated and accepted by the sponsor, placement is discussed in a vacuum, since the question put to every name is precisely its distance from that centre.
BABOK sets four rings, from the centre outwards. Each is defined by the test that qualifies a stakeholder for it.
- Ring 1, solution delivery: the people directly involved in creating the solution. Project manager, business analyst, architect, developers, testers, user-experience designer. The qualifying test is the act of creation: does this person design, build, test or deliver the solution itself? Operating the solution once it has been delivered belongs to another ring: the help desk that will keep it running sees its work change, and it sits in ring 2. An external supplier who develops the solution does sit in ring 1, despite standing outside the enterprise, because this ring qualifies by the act.
- Ring 2, affected organisational unit: the people whose daily work changes when the solution is delivered. Business users, front-desk staff, help desk, the immediate management of those teams. The qualifying test is the change of work: will this person do their job differently on Monday morning?
- Ring 3, organisation or enterprise: the people in the enterprise who interact with the affected unit without their own work changing. Sponsor, executives, domain experts, legal, compliance, finance, internal audit. The qualifying test is interaction without transformation: this person steers, arbitrates, advises or controls the ring-2 unit and goes home in the evening with the same tasks as before.
- Ring 4, affected external stakeholders: the parties outside the organisation who are reached by the solution's effects. Customers, suppliers, integration partners, hosts, regulators, professional associations. The qualifying test is the enterprise boundary: is this stakeholder outside?
Placement is decided by putting these tests in order, and the first yes files the stakeholder. Does it design, build, test or deliver the solution? Ring 1. If not, does its daily work change? Ring 2. If not, does it belong to the enterprise that sponsors or supervises the affected unit? Ring 3. If not, it is outside, and that is ring 4. The order is what makes the test decidable: an external integrator is both a builder and an outsider, and the first question rules before the last one is even asked. A stakeholder occupies a single ring, and when two rings fight over a name, the role is a double role. The remedy is then to split the role.
The model has a documented origin, worth knowing for two ideas it yields. Ian Alexander published the shape in 2004: a core that carries the product and no people, then our system, meaning the product together with those who operate it, then the containing system, then the wider environment, with named role slots inside each ring (normal operator, maintenance operator, functional beneficiary, purchaser, champion, regulator, developer). The two models diverge on one point that has to be held: Alexander places the operators in his second ring, BABOK places only the makers in its first. It is BABOK's ring names and BABOK's tests that are to be reproduced, because those are the ones the reader will meet again in the standard. The Volere method of Suzanne and James Robertson turns the model into a stakeholder analysis template. Two notions from that lineage earn their keep daily. The empty slot: a foreseen slot that nobody occupies is a question asked, and the standard phrasing is "are you certain no regulator touches this solution?". The negative stakeholder: the one the solution harms, or who will oppose it, exists and is dealt with, even when their name is not on the workshop wall.
Running the exercise
- Fix the centre with the sponsor, in writing, before the session. One sentence is enough, but it must name what the solution replaces and what it leaves out. Most placement disputes are scope disputes in disguise, and they are settled here or nowhere.
- Bring the stakeholder list as raw material. The onion positions existing names; it works badly as a brainstorming session from a blank sheet.
- Draw the four rings at large format, physical or digital, and label them before the first name is placed. An unlabelled ring fills up according to each person's intuition.
- Populate ring 1 by asking the single question that qualifies for it: who designs, builds, tests or delivers this solution? The answer is short and rarely contested, which makes it a good warm-up.
- Populate ring 2 by putting each remaining name through the change-of-work test. A role whose day nobody can say has changed does not belong in this ring, and the question has already produced its information.
- Populate ring 3 with those who steer, arbitrate, advise or control the affected unit. The sponsor almost always sits there, which surprises the room and deserves explaining in the session.
- Sweep ring 4 by category, out loud: customers, suppliers, integration partners, host, sector regulator, data protection authority, public bodies co-financing the service, professional associations. The category sweep finds what memory does not.
- Hunt for the gaps. A thin ring or an unoccupied role slot is challenged before concluding. The absence of a regulator in a regulated domain is a hypothesis to validate.
- Validate the map with the sponsor and a sample of the people named. A disagreement about a placement is information: it almost always signals an ambiguity of scope, and it is escalated as such.
- Date the map and redraw it at every material change of scope. Stakeholder analysis is iterative in BABOK, and the onion is the fastest artefact to correct.
What makes the exercise fail
Confusing power with proximity
This is the most frequent placement error, and it comes from the analyst more often than from the room: the sponsor decides everything, so the sponsor goes in the centre. The test refuses him, because he does not create the solution, and he sits in ring 3. Power is read on the stakeholder matrix.
Reading distance as importance
This is the same error seen from the outer ring, and it costs more. A ring-4 regulator can suspend a release that the whole of ring 1 has approved. The ring locates a stakeholder relative to the solution, and engagement priority is decided on the matrix.
Leaving the outer ring empty
The team thinks first of those who build and those who use and stops looking once those two rings are full. Regulators, data protection authorities, suppliers and integration partners are then discovered late, after the interfaces have been settled. The category sweep at step 7, conducted out loud, is the only remedy that works, and it costs ten minutes.
Letting the word "user" pass
It covers at least two roles filed in different rings: the claims handler who works in the portal eight hours a day (ring 2) and the insured person who files an invoice there twice a year (ring 4). Their needs, their tolerance for complexity and their engagement plan have nothing in common. Naming the role rather than the category surfaces the difference.
Confusing the ring hierarchy with the org chart
A chief executive sits in ring 3 and a junior developer in ring 1: the rings measure a distance from the solution, the org chart measures authority, and nothing obliges the two to coincide.
HERMES, the Swiss Confederation's project management method, is a case in point: its role model files every project role on two axes at once. The first is the partner group (§6.1.3.2): the user, who defines the requirements, tests and accepts; the developer, who builds and integrates the solution; the operator, who provides the infrastructure and runs the system. The second is the hierarchy level (§6.1.3.3): steering, management or execution. The project sponsor belongs to steering and sits in ring 3, since the role builds nothing; an execution role falls in ring 1 or ring 2 depending on whether it builds the solution or will use it. Copying the role grid into the rings produces a false map.
Drawing the map once
An integration partner comes into scope, a supplier leaves it, a new regulator invites itself in, and the map goes false with nothing to signal it. It is dated, like a plan, and redrawn at every scope review. A stakeholder map eighteen months old documents the project of eighteen months ago.
AI considerations
The most productive use of a language model bears on the outer rings, where the team's memory fails. Fed with the scoping note, the contracts in force, the org chart and the register of applicable regulations, it produces a list of candidates for rings 3 and 4, which feeds the sweep at step 7. The same mechanism works as a control question: "for a claims portal at a Swiss health insurer, which categories of external stakeholder are usually concerned?" The answer is a list to be confronted with the real project, and its value lies in naming categories nobody in the room would have proposed.
It renders a second, quieter service on the word "user". A model asked to enumerate the distinct roles hidden behind a generic label (user, customer, partner, supplier) produces in seconds the decomposition a workshop takes half an hour to reach, and placing those separated roles in their respective rings does the rest of the work.
Placement itself escapes the machine. Knowing whether a department's daily work changes (ring 2) or whether it merely interacts with the affected department (ring 3) depends on facts internal to the organisation that a model does not have, and that it will invent plausibly if asked to place real people. The risk is acute on ring 4, where the model fills the gaps with generic sector knowledge: it proposes a plausible regulator that does not exist, or it forgets the cantonal authority that does. Every suggestion concerning a regulator is verified at source. Finally, designating a stakeholder as opposed is sensitive data about an identifiable person: that annotation stays in an internally approved tool, or it is anonymised before it leaves, and it is not submitted to a public model in named form.
Examples
A Swiss health insurer (caisse-maladie), operating basic compulsory health insurance under the LAMal, is putting an online claims portal into service. The centre was fixed in writing with general management before the session, and it carries three things: the self-service portal where the insured file their claims, the automated intake of invoices sent by healthcare providers (physiotherapists, medical practices, hospitals) and the digital claim file that internal roles open to handle the case. Paper leaves the circuit. The diagram is the product of the scoping session, before elicitation was planned.
The Federal Office of Public Health (FOPH), supervisor of basic compulsory health insurance, and the insured, who are the customers, share ring 4. They stand at the same distance from the solution and do not carry the same weight: one can suspend the release, the other is the person it is built for. That is the reading the map imposes, the one that settles the most common misunderstanding about this technique.
Visualisations
The geometry carries the meaning. The nesting states the distance: a stakeholder placed in ring 3 is seen further from the centre than those in ring 2, with no legend needed to explain it.
| Ring | Test that qualifies a stakeholder for it | Default engagement mode |
|---|---|---|
| 1. Solution delivery | It designs, builds, tests or delivers the solution. | Daily contact, the team itself. |
| 2. Affected organisational unit | Its daily work changes when the solution arrives. | Workshops, workplace observation, acceptance testing. |
| 3. Organisation or enterprise | It interacts with the affected unit, its own work stays the same. | Interviews, steering committee, arbitration, reviews. |
| 4. Affected external stakeholders | It sits outside the organisation. | Formal consultation, representatives and associations, regulatory watch, user testing. |
The ring sets the default mode of contact. Its frequency and intensity are then tuned on the stakeholder matrix, which weighs each party's power and interest.
Cost
The effort lies in the prior agreement on the solution's boundary. The drawing itself is quick, and it is the upkeep of the map that costs over time.
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | The solution's boundary must be written down and accepted by the sponsor before the session, which is a negotiation in itself. The stakeholder list must exist as raw material or be produced first. |
| Execution | Low | One facilitated session of one to two hours is enough to place the names in the four rings, challenge the gaps and record the disagreements. No tool, no data and no rare skill is required. |
| Documentation | Medium | The map is redrawn at every material change of scope: integration partner coming in, supplier going out, regulator newly concerned. The upkeep is recurrent across the life of the project and is the technique's real cost. |
Tooling
The original format remains the most effective for the session itself: four circles drawn in marker on a whiteboard or a flip chart, with repositionable notes carrying one role each. The physical support makes moving a name from one ring to another trivial, which matters since moving is the central act of the exercise, and it puts everyone on their feet around the same object. The cost of entry is nil.
Remote or hybrid, collaborative whiteboards (Miro, Mural, FigJam) keep the metaphor of the repositionable note and add persistence, versioning and voting. They are the right choice as soon as the map has to survive the session, which is the general case. General-purpose diagramming tools (diagrams.net, Lucidchart, Visio, a slide with four stacked circles) suit the tidying-up of the deliverable, but they facilitate the workshop itself badly, because moving a shape there takes an intention where moving a note takes none.
On the specialised side, the stakeholder analysis template of the Volere method (Atlantic Systems Guild) provides a ready-made onion diagram, with named role slots to fill. Its interest is the inverse of a whiteboard: it imposes a checklist of roles, so it makes the empty slot visible, and it repays its formalism when the map has to live for several months on a programme. Some requirements management and enterprise architecture tools offer a stakeholder-map view, which carries the same advantage and links the map to the rest of the repository, which justifies their cost only when that repository already exists.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.43 Stakeholder List, Map, or Personas (figure 10.43.2, Stakeholder Onion Diagram).
- Ian F. Alexander, A Better Fit: Characterising the Stakeholders, REBPS 2004 workshop, CAiSE'04, Riga: primary source of the onion model, of the notion of the negative stakeholder and of validation by empty slots.
- Ian F. Alexander, A Taxonomy of Stakeholders: Human Roles in System Development, International Journal of Technology and Human Interaction, vol. 1, no 1 (2005), pp. 23-59: taxonomy of the rings and the roles and documented pitfalls (the overloaded word "user", distance read as importance, confusion with the org chart).
- Suzanne Robertson and James Robertson, Requirements: A Socio-Technical Discipline, Atlantic Systems Guild (Volere): the stakeholder analysis template and its use for identification.
- Swiss Confederation, Federal Chancellery, HERMES 2022, Project Management Reference Manual, ch. 6 Roles, §6.1.3.2 Partner groups and §6.1.3.3 Hierarchy levels: the role model of the federal method, which assigns every project role to one or more partner groups (user, developer, operator) and to a hierarchy level (steering, management, execution), two axes neither of which measures distance from the solution.