In this installment of StraightTalk, we’re going to explore a sometimes overlooked but all-important domain for the business architecture baseline: stakeholders. Stakeholder mapping techniques came on the scene and matured a bit later than some of the others, so it’s a good time to revisit them and their valuable role in the business architecture.
First things, first. What’s a stakeholder?
In official BIZBOK® Guide speak, a stakeholder is “an internal or external individual or organization with a vested interest in achieving value through a particular outcome.”
While this makes sense, the word (and domain) stakeholder in business architecture has a more specific meaning. These are not the overall stakeholders for the organization or a list of stakeholders for an initiative, rather they are the triggering and participating stakeholders involved in the business architecture value streams. That’s it. (P.S. please resist the urge to brainstorm any additional people to include in this definition.)
How do we identify and define stakeholders?
Stakeholders will be identified naturally during the process of defining your value streams together with your cross-functional team of business subject matter experts. Each value stream must have a triggering stakeholder and each stage must have participating stakeholders. (See Post No. 12 for more background on value streams and building the business architecture baseline.)
For example, a value stream such as Send Shipment is triggered by Sender (a type of Customer) and includes participating stakeholders such as Recipient, Shipping Company and Customs Agent. A value stream such as Onboard Human Resource is triggered by Hiring Manager and includes participating stakeholders such as Recruiter and Candidate (Human Resource).
Stakeholders are ideally described as individuals versus functions or organizational structures. For example, Hiring Manager is more suitable, as it references an individual versus HR Department, which is an organizational structure.
Are stakeholders the same as roles?
Stakeholders are intentionally abstracted to a higher level and while there may be similarities and overlaps with what we might think of as roles, they are frequently not the same – particularly compared to the more granular roles we might use for process modeling or requirements.
It is essential to recognize what this means in the bigger picture. Within the context of the business architecture domains, four of them are abstracted: capabilities, information, value streams and stakeholders. In other words, we define the content with our cross-functional team of business experts based on a rationalized, high-level representation of the business. On the other hand, the remaining business architecture domains capture actual business content, including organization (business units), strategies, policies, products, initiatives and metrics. For example, we obtain the real list of business units that an organization possesses, the products it offers, the policies it adheres to, and so on. See below for a handy visual summarizing all of this.
When should we do stakeholder mapping?
There are a couple of options:
- Option 1: Complete stakeholder mapping when you build your business architecture baseline – This means that you develop your capability map and information map as well as your value streams (an essential set of them) and stakeholder map upfront.
- Option 2: Complete your business architecture baseline first and then go back to stakeholder mapping – This means that you develop your capability map, information map and value streams (an essential set of them) upfront and use and evolve them for a while. Then later you go back to develop your stakeholder map. However, do not wait too long to build your stakeholder map. Get started when you have around 5-10 value streams so that you do not need to course-correct later on.
Which option should you choose? Honestly, either is entirely viable and effective. The truth is that Option 2 works best for most teams from a practical standpoint since it allows them to get their business architecture baseline in place quicker so they can actually start using it to deliver value. Additionally, there is much to learn upfront so giving yourself some time to use and evolve your business architecture baseline before diving into stakeholders works well from that standpoint as well.
How do we do stakeholder mapping?
Provided you’ve captured the right stakeholders at the right level during value stream mapping, you’re already half-way there. Here’s how you do it:
- Take all of the triggering and participating stakeholders from your value streams and put them in one master list. Remove any duplicates since of course a stakeholder may be involved in many places.*
- Rationalize and review your stakeholders and make any adjustments. For example, you may have inadvertently called the same stakeholder two different names (e.g., Customer and Client) or named a stakeholder after a department versus an individual.
- Capture additional attributes for each stakeholder, including its:
- Type (internal or external)
- Category (the information concept it relates to such as Customer, Partner or Human Resource)
- Description (a brief overview of the stakeholder with characteristics inherited from its related information concept)
- Review stakeholder information with subject matter experts.
- Publish and govern the stakeholder map.
Of course, going forward, as you map out new value streams you should leverage any existing stakeholders from your stakeholder map and add any new ones to it as you go.
BTW, stakeholder mapping can be introspective and enlightening, so once you are done, you may need to make some adjustments to your value streams and possibly your information map.
* P.S. If you have an automated business architecture knowledgebase tool, this step may be done for you automatically as you create your value streams.
How do stakeholders relate to information concepts?
There is a very close tie between stakeholders and information concepts, and they should always be in alignment. The relationship is:
- Information Concepts and Stakeholder Categories should align
- Information Concept Types and Stakeholders should align
See below for a diagram that illustrates these relationships, as well as alignment with the capability map and value streams.
Once we have our stakeholders mapped, then what? What’s the value?
The stakeholders of our organization are the very reason we are in business, our raison d‘être, so they should be top of mind when we think about ways to leverage our business architecture. Here are a few ideas for using the stakeholder lens to provide value:
- Identify opportunities to deliver better value and experience to stakeholders (especially customers) by assessing the effectiveness and performance of related capabilities and value streams.
- Assess the impact of potential changes (e.g., business model changes, new products, regulatory changes, etc.) to stakeholders.
- Quantify and evaluate the collective impact across initiatives to stakeholders (in partnership with organizational change managers).
- Jumpstart requirement-writing process by utilizing the scope and language readily available through value streams, stakeholders and capabilities.
Happy Mapping!
More Good Stuff…
Business Architecture Stakeholder Mapping Content (BIZBOK® Guide): Check out Section 2.8 in the BIZBOK® Guide (Business Architecture Guild® membership required) for the official word on how to map stakeholders and cross-map them to other business architecture perspectives. Check out Section 2.4 for all you ever want to know about value streams.
Stakeholder Mapping and 20 Minute Value Stream Mapping (Business Architecture Guild® webinar): Two relevant webinars that summarize stakeholder and value stream mapping and their usage. (Business Architecture Guild® membership required.)
Business Architecture Mapping Templates (Business Architecture Guild®): Templates for capturing content for all business architecture domains, including stakeholders, are available on the Member-Only Resources page. (Business Architecture Guild® membership required.)
Don’t Be a Consumer – Be a Stakeholder (TED Talk): An absolutely fascinating TED Talk by Janet Carmosky on stakeholder engagement, based on her unique experiences, and the art of the possible if we think in terms of stakeholders rather than consumers and sellers.