Contents
Introduction
Ever since the publication of Strategic Management: A Stakeholder Approach by R. Edward Freeman [1], business change initiatives have embraced stakeholder analysis as a key activity for understanding who to involve in initiatives and how to engage and communicate with them. A wide range of stakeholder mapping and visualization approaches followed, with Mendelow [2] becoming the most widely used. The approach considers the Power wielded by the stakeholder on one axis, and the level of stakeholder Interest on the other. The result is a simple two-by-two matrix, widely taught as a standard approach to mapping stakeholders. Proposed stakeholder management approaches are often applied to each of the four quadrants, as shown in this example from the BTABoK [3]:
Power - Interest Grid Template from BTABoK
Using PowerPoint, it is easy enough to plot identified stakeholders on such a grid. So, what is the benefit of modeling them in Ardoq?
Why Model Your Stakeholders in Ardoq?
By recording and mapping your stakeholders using Ardoq, you are adding information about them to your enterprise architecture knowledge graph. In addition to being able to plot them on a grid such as the Power-Interest Grid above, you can use the power of the graph database to answer further questions:
What other initiatives are they, or have they been, stakeholders in?
What applications do the stakeholder roles interact with?
What processes do they participate in?
Which people are assigned to the stakeholder roles?
What other roles and responsibilities do they have?
What business capabilities are they expert in?
What organizational units do they belong to?
By adding stakeholder information to Ardoq, you are joining together stakeholder information across your various initiatives, building an enterprise view that can be explored, rather than creating isolated islands of information.
Which Component Type Best Represents a Stakeholder?
Freeman defines a stakeholder as:
“any group or individual who can affect, or is affected by, the achievement of a corporation’s purpose” [1].
This might translate into several different component types in Ardoq. The most obvious candidates are:
Organizational Unit (representing a group)
Person (representing an individual)
Role (representing an abstract group or individual)
Fortunately, the key to describing stakeholders is the relationship that the stakeholder has with the thing they are a stakeholder in. In Ardoq, this means using the reference that lies between the two components. Since we can add characteristics to that relationship in the form of fields on the reference, we do not have to limit ourselves to only one component type to represent stakeholders. We can quickly implement a solution that allows all of the above component types to be identified as a stakeholder in something. Which you choose to allow as stakeholders is up to you.
For a more detailed discussion of using the Role component type in Ardoq, see How to use Roles in Ardoq.
What Things Have Stakeholders?
Freeman considers stakeholders from the perspective of the corporation. So reflecting his approach would involve linking the stakeholders to the Organization that represents the corporation. As mentioned earlier, it is common for business change initiatives to identify and map the stakeholders, both within their organization and beyond it, who “can affect, or are affected by” their initiative. This would result in the following metamodel, assuming that you wish to allow any combination of Role, Person or Organizational Unit components to make up your list of stakeholders:
Since a person, role or organizational unit might be a stakeholder in multiple Initiatives, and their levels of Power and Interest in those Initiatives might vary, the Power and Interest fields must live on the Is Stakeholder In reference.
You could add more fields to the reference to describe the stakeholder’s relationship with the initiative in more detail. Mitchell, Agle and Wood add a third dimension to their stakeholder map, calling it Legitimacy [4]. It enables you to take into account whether the stakeholder’s thinking is well aligned to the goals of the initiative (or do they have their own agenda?). Other similar characteristics sometimes captured include the stakeholder's level of involvement in the initiative and whether the stakeholder supports or opposes the initiative. But beware of becoming too personal. The more sensitive information you capture, the fewer people you can safely share the map with.
You might wish to record and map stakeholders in things other than Initiatives. Owners may wish to map their stakeholders, linking them to component types such as Organizational Units, Products, Applications and Technology Services. Although the above metamodel diagram only shows stakeholders being related to initiatives, the section below includes details of how to apply the same model to other component types.
Setting up Ardoq to record stakeholders
Create the Is Stakeholder In reference type. Edit each workspace that contains component types that are candidate stakeholders, and choose Manage reference types, then add a new reference type Is Stakeholder In.
Add the fields. Still editing the workspace(s), choose Manage field types, and add new fields:
Interest, a number field which you should add to the reference type Is Stakeholder In
Power, also a number field which you should add to the reference type Is Stakeholder In
Plus any other descriptive fields you wish to add that relate to the stakeholder’s relationship
Create the first Survey. Create a new Survey for the first component type you want to be able to define stakeholders for.
Select Create new to start the Survey Builder.
Give your survey a name (e.g. Initiative Stakeholders), and in the Define the data section, select the workspace and component type for your subject component type (e.g. Change Initiative Portfolio, Initiative).
In questions create a read-only question for the Name field (giving it a question title like Initiative Name)
Add a reference question for each component type that can represent a stakeholder. If you want to allow Roles and People to be stakeholders, you will need to create two reference questions.
Each of these will be an Incoming reference question coming from the workspace and component type that represents the stakeholder (e.g. the Role component type in the Roles workspace), with a reference type of Is Stakeholder In.
Decide whether to allow respondents to create components. Checking this box will allow respondents to type in a name that does not appear in the selection drop-down and have that new component automatically created. It might make sense to allow this for Role components, but is less likely for Person or Organizational Unit, as you may populate those from an external source (e.g. Active Directory or an HR system).
Add a section to each reference question for each of the fields that you’ve added to your reference. There will be a minimum of two (one for Interest and one for Power), and maybe more if you’ve chosen to add more fields that describe the stakeholder relationship (in step 2c above).
For each of these field questions, select the field and add a suitable question title and help text (e.g. “Stakeholder Interest”, “What is the level of interest that this stakeholder has in your Initiative? Answer on a scale of 1 (very little interest) to 5 (very interested).”), and make it a required field.
Save and publish your Survey.
Copy the Survey. For each additional component type for which you want to be able to define stakeholders (e.g. Application, Organizational Unit):
Make a copy of your first Survey from the Surveys overview page, giving it a suitable new name (e.g. Application Stakeholders).
Edit the new Survey and, in Define the data, change the workspace and component type to those that correspond to the additional subject component type (e.g. Applications, Application).
Save and publish the new Survey.
In summary, you’ve added the reference Is Stakeholder In to each of the component types that can represent a stakeholder, and added Interest and Power fields (and possibly others too) to the Is Stakeholder In references. And, you’ve created a survey which can be used to record stakeholders, and their levels of interest and power, for each component type for which you want to be able to map stakeholders (e.g. Initiatives and Applications).
Now you’re ready to start recording and mapping your stakeholders.
Recording Stakeholders
The task of identifying and classifying stakeholders is often conducted in a workshop, with an initiative’s business sponsor, or a product or application’s owner proposing the stakeholders and their attributes. Project managers, enterprise and solution architects may participate and/or facilitate the discussion. It can be useful to use a whiteboard to come up with an initial list, and then refine it, perhaps by merging, adding or removing, initial entries.
Once you have an agreed list, and have determined each stakeholder’s level of interest and power, you are ready to record the stakeholders and their attributes in Ardoq.
Open the survey for the component type that represents the subject of your stakeholder analysis (e.g. Initiative Stakeholders if you’ve been identifying the stakeholders for a particular initiative).
Select Existing entries, and choose the particular component that represents your subject.
The Survey will open, inviting you to select the stakeholders you’ve chosen using separate questions for each of the component types that might represent stakeholders (in the example below, they may be Roles or People).
As shown in the screenshot above, for each stakeholder you choose, you will be asked to indicate their levels of interest and power (and populate any other fields you choose to add to your Is Stakeholder In reference type).
When you’ve recorded all the stakeholders and their levels of interest and power, hit the Submit button.
Viewing Stakeholder Maps
Now let’s set up our stakeholder map using the Bubble Chart visualization. You will need to do this once for each workspace that contains components whose stakeholders you wish to view:
Open the Workspace and select a component whose stakeholders you wish to map.
Choose the Bubble Chart visualization from the choice at the top of the screen. If it is not there, choose Manage Views from the More dropdown and make sure that Bubble Chart is selected, then click Apply Changes.
Using the icons at the top-left of the chart, select Choose Field Source.
From the drop-down, select Reference fields, then Incoming / Is Stakeholder In.
Click on the next icon, which is Select X-axis field and choose Power.
Click on the next icon, which is Select Y-axis field and choose Interest.
Click on the Select Background icon and select Custom.
Enter suitable labels for each of the four quadrants (see the template at the top of this article for an example)
Set the minimum values for both X and Y to 1, and the maximums to 5.
Click Apply and view your completed stakeholder map.
If you have added any other numeric fields to the reference, you can choose one of them to set the bubble size by clicking on the Select Size field icon.
You can also add conditional formatting rules in your Perspective to set bubble colors according to the values of other fields on the reference.
These settings will remain in place for the Bubble Chart visualization for that workspace until they are changed.
See this article, Bubble Chart, if you need more information about how to configure your chart.
Bibliography
[1] R. E. Freeman, Strategic management: a stakeholder approach. Boston: Pitman, 1984.
[2] A. Mendelow, “Environmental scanning: the impact of the stakeholder concept,” presented at the 2nd international conference on information systems, Cambridge MA, 1991.
[3] P. Preiss, “Stakeholder Analysis: Power - Interest Grid,” BTABoK. Accessed: Sep. 30, 2024. [Online]. Available: https://btabok.iasaglobal.org/power-interest-grid/
[4] R. K. Mitchell, B. R. Agle, and D. J. Wood, “Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts,” Acad. Manage. Rev., vol. 22, no. 4, pp. 853–886, Oct. 1997, doi: 10.2307/259247.