3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map

3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map

Stakeholder Management is the second Level 2 topic area for Part 2, and it is one of the ADM Techniques in the TOGAF Standard, 10th Edition. The Level 2 learning outcome expects you to apply it: identify stakeholders, their concerns, the views they need, and the communication involved; use architecture views; manage stakeholder engagement and requirements; and use trade-offs to support architecture development.

---

Why TOGAF Treats Stakeholder Management as a Technique

The TOGAF Standard lists the benefits of successful stakeholder management:

• The most powerful stakeholders are identified early, so their input shapes the architecture and their support is secured.
• Support from powerful stakeholders helps the engagement win resources.
• Early and frequent communication means stakeholders understand the architecture process and can support the team when needed.
• The team can anticipate reactions to models and reports and plan for them.
• Conflicting or competing objectives among stakeholders are found early, so a strategy for resolving them can be developed.

TOGAF recommends using stakeholder analysis in Phase A to identify the key players, then updating it throughout every phase. New stakeholders often surface in Opportunities & Solutions, Migration Planning, and Architecture Change Management.

A stakeholder is an individual, team, organization, or class of these with an interest in, or concerns relative to, the outcome of the architecture. A concern is an interest in the architecture that is important to one or more stakeholders. The technique connects directly to the content concepts of Architecture View, Architecture Viewpoint, Concern, and Stakeholder (Section 13.3).

---

The Four Steps of the Stakeholder Management Process

Step 1: Identify Stakeholders

Work out who is affected by the architecture, who has influence or power over it, and who has an interest in its success or failure. TOGAF's sample analysis distinguishes 22 types of stakeholder in five broad categories:

Useful questions include: who gains and who loses from the change, who controls resources, who will make the decisions, who procures IT systems, and who has influence. TOGAF warns against relying only on the formal organization chart: informal stakeholder groups and influencers can be as powerful as formal ones. Consider both the visible team obviously associated with the change and the invisible team whose contribution is still essential, such as providers of support services.

Step 2: Classify Stakeholder Positions

Record an analysis of the most important stakeholders. TOGAF's example analysis rates each stakeholder's ability to disrupt the change, their current and required understanding, their current and required commitment, and the support required (high, medium, or low). It also asks how ready each person is to move toward the target, whether they could act as an advocate, how involved they need to be, and whether they have made a commitment to the architecture.

Step 3: Determine the Stakeholder Management Approach

Map stakeholders by power and interest on a power/interest grid to choose an engagement strategy:

                    HIGH POWER
                        |
       KEEP             |        KEY
     SATISFIED          |      PLAYERS
  (high power,          |   (high power,
   low interest)        |    high interest)
------------------------+------------------------
                        |
     MINIMAL            |       KEEP
      EFFORT            |     INFORMED
  (low power,           |   (low power,
   low interest)        |    high interest)
                        |
                     LOW POWER
  LOW INTEREST ------------------------ HIGH INTEREST

• Key Players (high power, high interest): involve them fully and engage closely; their views shape the architecture.
• Keep Satisfied (high power, lower interest): give them what they need to stay supportive without overloading them with detail. In TOGAF's template map, CxOs, the PMO, business unit executives, regulators, and suppliers are typically classed here.
• Keep Informed (lower power, high interest): keep them regularly informed; examples in the template include HR, IT service management, and project managers.
• Minimal Effort (low power, low interest): monitor them in case their position changes.

TOGAF's template places many specialist and operational roles (procurement, enterprise security, line management, domain experts, and infrastructure and application operations) among the Key Players. These are examples, not fixed rules, so classify the actual people in each scenario.

Step 4: Tailor Engagement Deliverables

Identify the catalogs, matrices, and diagrams each stakeholder group needs, so the architecture is communicated in terms they understand and they can confirm their concerns are addressed. This is how stakeholder management feeds view and viewpoint selection in Phases B to D.

---

The Stakeholder Map

The result is recorded in a Stakeholder Map, which Phase A produces as a matrix and which is updated throughout the ADM. TOGAF's template lists, for each stakeholder:

The Stakeholder Map is where concerns are captured and traced to the views that address them. The Communications Plan in Phase A then sets out how, when, and where the architects will communicate with each group.

---

Using Stakeholder Management to Resolve Conflicts

Stakeholders often want incompatible things. Picture a Head of Sales who wants frictionless onboarding alongside a CISO who wants strong authentication. TOGAF's guidance points to a disciplined approach:

1. Make the conflict visible early in the stakeholder analysis rather than letting it surface at implementation.
2. Refer to the agreed Architecture Principles, which exist to guide exactly these decisions.
3. Use the Architecture Alternatives and Trade-offs technique (Section 8.4): present alternatives, with views that let stakeholders explore their consequences, so hidden agendas and requirements come out.
4. Escalate through governance when stakeholders cannot agree. The Architecture Board is the visible escalation route for out-of-bounds decisions.

---

Practitioner Traps in Part 2 Scenarios

• Treating stakeholder analysis as a one-off. Re-check the Stakeholder Map in later phases; new or newly powerful stakeholders appear.
• Ignoring informal influence. A respected manager with no formal title can block adoption.
• Overloading powerful but less-interested stakeholders. Keep Satisfied stakeholders need concise, relevant views, not detailed models.
• Neglecting operational stakeholders. Key players such as IT operations and security can derail implementation if their concerns are missed.
• Producing generic deliverables. Step 4 exists so each group gets the catalogs, matrices, and diagrams that address its concerns.