Stakeholder engagement is the foundation of good architecture.
In the real-world, stakeholder engagement is usually discussed as stakeholder management. All too often it is delivered as stakeholder manipulation, where the EA sells their preferences to the stakeholder.
It is a common saying that initiatives have about as much ability to choose their stakeholders as children have to choose their parents. You need to identify who the stakeholders are, assess their impact, classify their concerns and clarify their requirements.
Stakeholder mapping is an early activity. At this point, it is important to avoid two temptations of simplifying or reducing the set of stakeholders and confusing the stakeholder with those who claim to represent the stakeholder or the common communication channel. It is important to include all the relationships initiative affects and who can influence the initiative.
Thinking broadly about stakeholders will create a list that is too long to be of any practical use. Avoiding engagement burnout requires classifying your stakeholders to understand common concerns, power, and interest.
TOGAF provides a simple template that classifies stakeholder along an interest & power. Interest in the outcome of the initiative and their power to shape the initiative are starting points.
ISO 42010 defines concern as an interest in a system by one or more of its stakeholders. In practical terms, concerns are subjects – containers that classify the objectives, requirements, preferences and worries of the stakeholders.
Putting together a map demonstrating interest, power and concern immediately surface a central focus of good enterprise architecture: stakeholder conflict. Look for overlap and gap – it is as important that key stakeholders have overlapping concerns as dissimilar concerns. In the former your initiative may have to address edge-of-scope issues; while in the latter there is the real possibility of conflicting requirement.
Requirements: wants, objectives, preferences & fears
Requirement is a busy word in stakeholder management – nothing else requirements the set of wants, objectives, preferences and fears that shape the acceptability of an enterprise architecture to the set of stakeholders who must be served.
Classic stakeholder management tries to nail these down early – following the practices of project management and engineering where there is a clear end-goal. Best-in-class enterprise architecture recognizes that until the last architecture trade-off is made requirements are fluid, as is the architecture. Interesting, for best-in-class enterprise architecture constraints, are usually fluid as well.
Represent everything with a Stakeholder Map
There are a range of methods to represent this set of stakeholders, power, interest and concerns in a ‘Stakeholder Map’. Usually, the set of relationships is too complicated represent everything in a graphical format. In Navigate, we often use a Business Alignment Model, a traceability diagram or a gravity well. In the end, we are trying to represent the variety of stakeholder relationships, their relative proximity or strength.
Real stakeholder engagement – weighing organization and stakeholder preference, internal and external constraints is a critical first step. Without understanding the set of Stakeholders, requirements, objectives, influences, and preferences the trade-off necessary to develop a Target Architecture will be incomplete. Then we are forced into an anti-pattern selling the Target to obtain agreement to a Target Architecture that addresses a subset of stakeholder requirements.
Real stakeholder management is effective stakeholder engagement.