Stakeholder Roles in Business Analysis
In short A stakeholder is anyone the analyst deals with directly or indirectly, or who is affected by the change. The BABOK® Guide offers a list of generic roles you can use as prompts; Tarasenko adds a different grouping and reminds you of “silent” stakeholders who cannot speak for themselves.
Based on: IIBA, BABOK® Guide v3, section 2.4; F. P. Tarasenko, Applied Systems Analysis (in Russian), ch. 5.3.
On this page
Key ideas#
Roles, not people#
The BABOK Guide describes stakeholder roles, not job titles. One person can play several roles (a workshop manager can be a domain expert, an end user and a tester), and one role can be filled by many people. Any stakeholder can be a source of requirements, assumptions or constraints. The list is typical, not complete.
The BABOK Guide’s generic roles#
| Role | Who they are, in practice |
|---|---|
| Business analyst | You. The guide counts the analyst as a stakeholder in all analysis work. |
| Customer | Buys or uses what the organization offers; may be owed obligations by contract or in good faith. |
| Domain subject matter expert | Knows the business area deeply: managers, process owners, legal staff, consultants. |
| End user | Interacts with the solution directly. |
| Implementation subject matter expert | Knows how to build parts of the solution: architects, developers, database administrators, usability specialists, trainers, change consultants. |
| Operational support | Runs and maintains the solution day to day: help desk, operations analysts, release managers. |
| Project manager | Manages delivery, balancing scope, budget, schedule, resources, quality and risk. |
| Regulator | Sets and enforces rules the solution must follow: legislation, corporate governance, audit. |
| Sponsor | Kicks off the initiative, approves the work and holds the budget and scope. |
| Supplier | Outside the organization; provides products or services. |
| Tester | Works out how to verify the solution against requirements, and does it. |
Another lens: four groups and the silent stakeholders#
Tarasenko, writing about applied systems analysis, groups stakeholders differently. He asks you to look for:
- clients: those who buy or use what the system produces;
- performers: those who do the work inside the system;
- host organizations: those where the problem sits and those responsible for solving it;
- owners of affected resources: anyone whose money, property, data or time the change uses or affects.
He then names three “silent” stakeholders that are systematically forgotten because they have no voice in the room: future generations, past generations (present through the culture, buildings and rules they left behind), and the natural environment. In everyday business work, you can read “future generations” as future customers and staff, and “past generations” as legacy decisions that still constrain you.
Using two different lenses is the point: each one catches people the other misses.
How to apply it#
- First pass with the BABOK Guide roles. For each role, write down who fills it. Leave no row blank without a reason.
- Second pass with Tarasenko’s groups. Ask who are clients, performers, host organizations and resource owners. Add anyone new.
- Ask about the silent stakeholders. Who will live with this decision in five years? What legacy rules or systems constrain it? Does it affect the environment?
- Record roles per person. One person may appear under several roles. Note them all; it changes what you ask them.
- Turn the list into a plan. Feed it into a stakeholder list, map or personas and into stakeholder engagement planning in Planning and Monitoring.
- Review it regularly. Stakeholders join and leave. Re-check the list at each major milestone.
Example#
The analyst at The Workshop, a fictional chain of 12 bike-repair workshops, maps the BABOK Guide roles first:
| Role | At The Workshop |
|---|---|
| Sponsor | The owner |
| Customer | People who bring bikes for repair |
| Domain SME | Workshop managers; the most experienced front-desk lead |
| End user | Front-desk staff, mechanics, customers using online booking |
| Implementation SME | The outside development team |
| Operational support | The front-desk lead who will administer the booking tool; the development team’s support desk |
| Project manager | The development team’s project manager |
| Regulator | Data-protection rules covering customer phone numbers and emails |
| Supplier | The parts supplier; the text-message service provider |
| Tester | The development team’s tester; front-desk staff for acceptance testing |
Tarasenko’s lens adds two names: the bookkeeper (a resource owner, because parts ordering changes cash flow) and the landlord of two workshops that have no network cabling (a host organization constraint). Asking about past generations surfaces a ten-year-old agreement with the parts supplier that fixes order days.
Pitfalls#
- Equating stakeholders with users. Regulators, suppliers and sponsors rarely use the system but can stop it.
- Forgetting operational support. If nobody plans who will run the solution, it degrades after launch.
- Listing only the powerful. People with little influence often hold the detailed knowledge you need.
- Freezing the list. A stakeholder list from the kick-off is out of date within weeks.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Section 2.4 (stakeholders).
- F. P. Tarasenko. Applied Systems Analysis (in Russian). KnoRus, 2010. Ch. 5.3 (list of stakeholders, silent stakeholders).