3. Stakeholder Management
3.1 Introduction
Stakeholder management is an important discipline that successful architecture practitioners can use to win support from others. It helps them ensure that their projects succeed where others fail.
The benefits of successful stakeholder management are that:
- The most powerful stakeholders can be identified early and their input can then be used to shape the architecture; this ensures their support and improves the quality of the models produced
- Support from the more powerful stakeholders will help the engagement win more resources, thus making the architecture engagement more likely to succeed
- By communicating with stakeholders early and frequently, the architecture team can ensure that they fully understand the architecture process, and the benefits of Enterprise Architecture; this means they can support the architecture team more actively when necessary
- The architecture team can more effectively anticipate likely reactions to the architecture models and reports, and can build into the plan the actions that will be needed to capitalize on positive reactions while avoiding or addressing any negative reactions
- The architecture team can identify conflicting or competing objectives among stakeholders early and develop a strategy to resolve the issues arising from them
It is essential in any initiative to identify the individuals and groups within the organization who will contribute to the development of the architecture, identify those that will gain and those that will lose from its introduction, and then develop a strategy for dealing with them.
3.2 Approach to Stakeholder Management
Stakeholder analysis should be used during Phase A (Architecture Vision) to identify the key players in the engagement, and also be updated throughout each phase; different stakeholders may be uncovered as the engagement progresses through into Opportunities & Solutions, Migration Planning, and Architecture Change Management.
Complex architectures are extremely hard to manage, not only in terms of the architecture development process itself, but also in terms of obtaining agreement from the large numbers of stakeholders touched by it.
For example, just as a building architect will create wiring diagrams, floor plans, and elevations to describe different facets of a building to its different stakeholders (electricians, owners, planning officials), so an Enterprise Architect must create different architecture views of the Business, Information Systems, and Technology Architecture for the stakeholders who have concerns related to these aspects.
The TOGAF Standard specifically identifies this issue throughout the ADM through the following concepts (see the TOGAF Standard — Architecture Content):
- Architecture View
- Architecture Viewpoint
- Concern
- Stakeholder
3.3 Steps in the Stakeholder Management Process
The following sections detail recommended stakeholder management activity.
3.3.1 Identify Stakeholders
Identify the key stakeholders of the Enterprise Architecture.
The first task is to work out who the main Enterprise Architecture stakeholders are. As part of this, think of all the people who are affected by it, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion.
It might include senior executives, project organization roles, client organization roles, system developers, alliance partners, suppliers, IT operations, customers, etc.
When identifying stakeholders there is a danger of concentrating too heavily on the formal structure of an organization as the basis for identification. Informal stakeholder groups may be just as powerful and influential as the formal ones.
Most individuals will belong to more than one stakeholder group, and these groups tend to arise as a result of specific
events.
Look at who is impacted by the Enterprise Architecture project:
- Who gains and who loses from this change?
- Who controls change management of processes?
- Who designs new systems?
- Who will make the decisions?
- Who procures IT systems and who decides what to buy?
- Who controls resources?
- Who has specialist skills the project needs?
- Who has influence?
In particular, influencers need to be identified. These will be well respected and moving up, participate in important meetings and committees (look at meeting minutes), know what's going on in the company, be valued by their peers and superiors, and not necessarily be in any formal position of power.
Although stakeholders may be both organizations and people, ultimately the Enterprise Architecture team will need to communicate with people. It is the correct individual stakeholders within a stakeholder organization that need to be formally identified.
3.3.1.1 Sample Stakeholder Analysis
A sample stakeholder analysis that distinguishes 22 types of stakeholder, in five broad categories, is shown in Figure 3-1 . Any particular architecture project may have more, fewer, or different stakeholders; and they may be grouped into more, fewer, or different categories.
Consider both the Visible team — those obviously associated with the project/change — and the Invisible team — those who must make a real contribution to the project/change for it to be successful but who are not obviously associated with it (e.g., providers of support services).
3.3.2 Classify Stakeholder Positions
Develop a good understanding of the most important stakeholders and record this analysis for reference and refresh during the project. An example stakeholder analysis is shown in Table 3-1 .
|
Stakeholder Group |
Stakeholder |
Ability to Disrupt Change |
Current Understanding |
Required Understanding |
Current Commitment |
Required Commitment |
Required Support |
|---|---|---|---|---|---|---|---|
|
CIO |
John Smith |
H |
M |
H |
L |
M |
H |
|
CFO |
Jeff Brown |
M |
M |
M |
L |
M |
M |
It is also important to assess the readiness of each stakeholder to behave in a supportive manner (i.e., demonstrate commitment to the Enterprise Architecture initiative).
This can be done by asking a series of questions:
- Is that person ready to change direction and begin moving towards the Target Architecture? If so, how ready?
- Is that person capable of being a credible advocate or agent of the proposed Enterprise Architecture initiative? If so, how capable?
- How involved is the individual in the Enterprise Architecture initiative? Are they simply an interested observer, or do they need to be involved in the details?
- Has that person made a contractual commitment to the development of the Enterprise Architecture, and its role in the governance of the development of the organization?
Then, for each person whose commitment is critical to ensure success, make a judgment as to their current level of commitment and the desired future level of commitment.
3.3.3 Determine Stakeholder Management Approach
The previous steps identified a long list of people and organizations that are affected by the Enterprise Architecture project.
Some of these may have the power either to block or advance. Some may be interested in what the Enterprise Architecture initiative is doing; others may not care. This step enables the team to easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters of the initiative.
Work out stakeholder power, influence, and interest, so as to focus the Enterprise Architecture engagement on the key individuals. These can be mapped onto a power/interest matrix, which also indicates the strategy to adopt for engaging with them. Figure 3-2 shows an example power grid matrix.
3.3.4 Tailor Engagement Deliverables
Identify catalogs, matrices, and diagrams that the architecture engagement needs to produce and validate with each stakeholder group to deliver an effective architecture model.
It is important to pay particular attention to stakeholder interests by defining specific catalogs, matrices, and diagrams that are relevant for a particular Enterprise Architecture model. This enables the architecture to be communicated to, and understood by, all the stakeholders, and enables them to verify that the Enterprise Architecture initiative will address their concerns.
3.4 Template Stakeholder Map
The following table provides an example stakeholder map for a TOGAF architecture project which has stakeholders as
identified in Figure 3-1 .
|
Stakeholder |
Key Concerns |
Class |
Catalogs, Matrices, and Diagrams |
|---|---|---|---|
|
CxO |
The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business. |
KEEP |
Business Footprint diagram Goal/Objective/Business Service diagram Organization Decomposition diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Program Management Office |
Prioritizing, funding, and aligning change activity. An understanding of project content and technical dependencies between projects supports portfolio management decision-making. |
KEEP |
Requirements catalog Project Context diagram Benefits diagram Business Footprint diagram Application Communication diagram Organization map Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Procurement |
Understanding what building blocks of the architecture can be bought, and what constraints (or rules) are relevant to the purchase. Acquirers will shop with multiple vendors looking for the best cost solution while adhering to the constraints (or rules) derived from the architecture, such as standards. The key concern is to make purchasing decisions that fit the architecture. |
KEY |
Technology Portfolio catalog Technology Standards catalog |
|
Human Resources (HR) |
The roles and actors are required to support the architecture and changes to it. The key concern is managing people transitions. |
KEEP |
Organization Decomposition diagram Organization/Actor catalog Location catalog Application and User Location diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram |
|
Enterprise Security |
Ensuring that the information, data, and systems of the organization are available to only those that have permission, and protecting the information, data, and systems from unauthorized tampering. |
KEY |
Product Lifecycle diagram Data Dissemination diagram Data Security diagram Actor/Role matrix Networked Computing Hardware diagram Network and Communications diagram |
|
QA/Standards Group |
Ensuring the consistent governance of the organization's business, data, application, and technology assets. |
KEY |
Process/Event/ Control/Product catalog Contract/Measure catalog Application Portfolio catalog Interface catalog Technology Standards catalog Technology Portfolio catalog Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Executive |
The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and architecture to advance the business. |
KEEP |
Business Footprint diagram Goal/Objective/Business Service diagram Organization Decomposition diagram Process Flow diagram Application Communication diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Line Management |
Top-level functions and processes of the organization, and how the key applications support these processes. |
KEY |
Business Footprint diagram Organization Decomposition diagram Organization map Process Flow diagram Application Communication diagram Application and User Location diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Business Domain Experts |
Functional aspects of processes and supporting systems. This can cover the human actors involved in the system, the user processes involved in the system, the functions required to support the processes, and the information required to flow in support of the processes. |
KEY |
Business Interaction matrix Actor/Role matrix Business Service/ Information diagram Organization map Product Lifecycle diagram Business Use-Case diagram Application Use-Case diagram Application Communication diagram Data Entity/Business Function matrix Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
IT Service Management |
Ensuring that IT services provided to the organization meet the service levels required by that organization to succeed in business. |
KEEP |
Technology Standards catalog Technology Portfolio catalog Contract/Measure catalog Process/Application Realization diagram Enterprise Manageability diagram |
|
IT Operations — Applications |
Development approach, software modularity and re-use, portability migration, and interoperability. |
KEY |
Process/Application Realization diagram Application/Data matrix Application Migration diagram Software Engineering diagram Platform decomposition Diagram Networked Computing/ Hardware diagram Software distribution Diagram |
|
IT Operations — Infrastructure |
Location, modifiability, re-usability, and availability of all components of the system. Ensuring that the appropriate components are developed and deployed within the system in an optimal manner. |
KEY |
Platform Decomposition diagram Technology Standards catalog Technology Portfolio catalog Enterprise Manageability diagram Networked Computing/ Hardware diagram Processing diagram Environments and Locations diagram |
|
IT Operations — Data/Voice Communications |
Location, modifiability, re-usability, and availability of communications and networking services. Ensuring that the appropriate communications and networking services are developed and deployed within the system in an optimal manner. |
KEY |
Network and Communications diagram |
|
Executive |
On-time, on-budget delivery of a change initiative that will realize expected benefits for the organization. |
KEEP |
Requirements catalog Principles catalog Value Chain diagram Solution Concept diagram Organization map Application and User Location diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Line Management |
Operationally achieving on-time, on-budget delivery of a change initiative with an agreed scope. |
KEEP |
Application Communication diagram Organization map Environments and Locations diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Business Process/Functional Expert |
Adding more detail to the functional requirements of a change initiative based on experience and interaction with business domain experts in the end-user organization. |
KEY |
Process Flow diagram Business Use-Case diagram Business Service/Information diagram Organization map Application Communication diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
|
Product Specialist |
Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution. In a packages and packaged services environment, product expertise can be used to identify product capabilities that can be readily leveraged and can provide guidance on strategies for product customization. |
KEY |
Software Engineering diagram Application/Data matrix |
|
Technical Specialist |
Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution. |
KEY |
Software Engineering diagram Platform Decomposition diagram Process/Application Realization diagram Application/Data matrix Application Migration diagram |
|
Regulatory Bodies |
Receipt of the information they need in order to regulate the client organization, and ensuring that their information requirements are properly satisfied. Interested in reporting processes, and the data and applications used to provide regulatory return information. |
KEEP |
Business Footprint diagram Application Communication diagram |
|
Suppliers |
Ensuring that their information exchange requirements are met in order that agreed service contracts with the client organizations can be fulfilled. |
KEEP |
Business Footprint diagram Business Service/Information diagram Application Communication diagram Business Capabilities catalog Capability/Organization matrix Business Capability Map Strategy/Capability matrix Capability/Organization matrix Business Model diagram Value Stream catalog Value Stream Stages catalog Value Stream/Capability matrix Value Stream Map |
return to top of pageTOGAF is a registered trademark of The Open Group