21. Stakeholder Management

Chapter Contents
21.1 Introduction | 21.2 Approach to Stakeholder Management | 21.3 Steps in the Stakeholder Management Process | 21.4 Template Stakeholder Map

21.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:

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.

21.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 31.1 Basic Concepts):

21.3 Steps in the Stakeholder Management Process

The following sections detail recommended stakeholder management activity.

21.3.1 Identify Stakeholders

Identify the key stakeholders of the Enterprise Architecture.

The first task is to brainstorm 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:

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.

21.3.1.1 Sample Stakeholder Analysis

A sample stakeholder analysis that distinguishes 22 types of stakeholder, in five broad categories, is shown in Figure 21-1 . Any particular architecture project may have more, fewer, or different stakeholders; and they may be grouped into more, fewer, or different categories.



Figure 21-1: Sample Stakeholders and 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).

21.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 21-1 .

 

 

Ability to

Current

Required

Current

Required

 

Stakeholder

 

Disrupt

Under-

Under-

Commit-

Commit-

Required

Group

Stakeholder

Change

standing

standing

ment

ment

Support

CIO

John Smith

H

M

H

L

M

H

CFO

Jeff Brown

M

M

M

L

M

M

Table 21-1: Example Stakeholder Analysis

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:

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.

21.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 21-2 shows an example power grid matrix.



Figure 21-2: Stakeholder Power Grid

21.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.

21.4 Template Stakeholder Map

The following table provides an example stakeholder map for a TOGAF architecture project which has stakeholders as identified in Figure 21-1 .

 

 

 

Catalogs, Matrices,

Stakeholder

Key Concerns

Class

and Diagrams

CxO
(Corporate Functions);
e.g., CEO, CFO, CIO, COO

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
SATISFIED

Business Footprint diagram

Goal/Objective/ 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
(Corporate Functions);
e.g., Project Portfolio Managers

Prioritizing, funding, and aligning change activity. An understanding of project content and technical dependencies between projects supports portfolio management decision-making.

KEEP
SATISFIED

Requirements catalog

Project Context diagram

Benefits diagram

Business Footprint diagram

Application Communication diagram

Functional 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

Procurement
(Corporate Functions);
e.g., Acquirers

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
PLAYERS

Technology Portfolio catalog

Technology Standards catalog

Human Resources (HR)
(Corporate Functions);
e.g., HR Managers, Training & Development Managers

The roles and actors are required to support the architecture and changes to it. The key concern is managing people transitions.

KEEP
INFORMED

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
(Corporate Functions);
e.g., Corporate Risk Management, Security Officers, IT Security Managers

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
PLAYERS

Product Lifecycle diagram

Data Dissemination diagram

Data Security diagram

Actor/Role matrix

Networked Computing Hardware diagram

Network and Communications diagram

QA/Standards Group
(Corporate Functions);
e.g., Data Owners, Process Owners, Technical Standards Bodies

Ensuring the consistent governance of the organization's business, data, application, and technology assets.

KEY
PLAYERS

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
(End-user Organization);
e.g., Business Unit Directors, Business Unit CxOs, Business Unit Head of IT/Architecture

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
SATISFIED

Business Footprint diagram

Goal/Objective/ 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
(End-user Organization);
e.g., Senior Business Managers, Operations Regional Managers, IT Managers

Top-level functions and processes of the organization, and how the key applications support these processes.

KEY
PLAYERS

Business Footprint diagram

Organization Decomposition diagram

Functional Decomposition diagram

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
(End-user Organization);
e.g., Business Process Experts, Business/Process Analyst, Process Architect, Process Designer, Functional Managers, Business Analyst

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
PLAYERS

Business Interaction matrix

Actor/Role matrix

Business Service/ Information diagram

Functional Decomposition diagram

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
(Systems Operations);
e.g., Service Delivery Manager

Ensuring that IT services provided to the organization meet the service levels required by that organization to succeed in business.

KEEP
INFORMED

Technology Standards catalog

Technology Portfolio catalog

Contract/Measure catalog

Process/Application Realization diagram

Enterprise Manageability diagram

IT Operations - Applications
(System Operations);
e.g., Application Architecture, System & Software Engineers

Development approach, software modularity and re-use, portability migration, and interoperability.

KEY
PLAYERS

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
(System Operations);
e.g., Infrastructure Architect, Wintel support, Mid-range support, Operational DBA, Service Desk

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
PLAYERS

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
(System Operations);
e.g., Network Management

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
PLAYERS

Network and Communications diagram

Executive
(Project Organization);
e.g., Sponsor, Program Manager

On-time, on-budget delivery of a change initiative that will realize expected benefits for the organization.

KEEP
INFORMED

Requirements catalog

Principles catalog

Value Chain diagram

Solution Concept diagram

Functional Decomposition 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

Line Management
(Project Organization);
e.g., Project Manager

Operationally achieving on-time, on-budget delivery of a change initiative with an agreed scope.

KEEP
INFORMED

Application Communication diagram

Functional Decomposition diagram

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
(Project Organization);
e.g., Financials FICO® Functional Consultant, HR Functional Consultant

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
PLAYERS

Process Flow diagram

Business Use-Case diagram

Business Service/Information diagram

Functional Decomposition 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

Product Specialist
(Project Organization);
e.g., Portal 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
PLAYERS

Software Engineering diagram

Application/Data matrix

Technical Specialist
(Project Organization);
e.g., Application Architect

Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution.

KEY
PLAYERS

Software Engineering diagram

Platform Decomposition diagram

Process/Application Realization diagram

Application/Data matrix

Application Migration diagram

Regulatory Bodies
(Outside Services);
e.g., Financial Regulator, Industry Regulator

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
SATISFIED

Business Footprint diagram

Application Communication diagram

Suppliers
(Outside Services);
e.g., Alliance Partners, Key Suppliers

Ensuring that their information exchange requirements are met in order that agreed service contracts with the client organizations can be fulfilled.

KEEP
SATISFIED

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 page