This tutorial is adapted from Web Age course Solution Architecture Training.
Stakeholders are people with a vested interest in the system. They are the people who can tell us what is needed. They are the people who can tell us if what we are building is the right thing. Stakeholders are people or things (e.g. other systems) that have requirements or expectations about a system. Stakeholders have different needs and interests, called concerns. The architect must identify all the stakeholders to understand their concerns. The architecture is defined to satisfy the stakeholder concerns.
4.2 Stakeholder Management
Stakeholder Management is a discipline that can help architects build support for building an architectural practice, conformance to architectural standards, proceeding with a project with business value, making the business changes that often come with technology change. Selling is always easiest top-down so it is important to understand the power and influence relationships in an enterprise.
4.3 When to Focus on Stakeholder Management
In a nutshell, one should focus on stakeholder management from the beginning, when visioning. Identifying the most powerful stakeholders early and gathering their input will increase the quality of the architecture, increase access to resources, provide an opportunity to educate influential leaders in the value and process of architecture, enable you to avoid pitfalls and anticipate objections, begin to identify conflicting viewpoints and where work needs to be done to build consensus, clear the path for eventual implementation.
4.4 Steps in the Stakeholder Management Process
1. Identify the stakeholders
2. Classify their positions
3. Determine the stakeholder management approach
4. Tailor the approach and deliverables to meet stakeholder needs
4.5 Identifying Stakeholders
Brainstorm architecture stakeholders ie. senior executives, program and project leadership, business unit leaders, developers, IT operations managers, suppliers etc. Carefully consider and include those with influence, not just formal authority. Start with org chart but think about who isn’t on it but is important.
4.6 Points to Consider
Who will be impacted by the change?
Who will gain the most from it?
Who will lose the most?
Who can inspire confidence in the change?
Who will need to participate in this and related projects to make them successful?
Who controls the people?
Who controls the money?
Who has specialist skills that are important?
4.7 Example Stakeholders & Concerns
Customer: Schedule estimation, Budgeting, Feasibility & risk assessment, Requirements traceability, Progress tracking
Developing Organization Management: Schedule estimation, Budgeting (low costs, keeping people employed), Leveraging existing corporate assets, Feasibility & risk assessment, Requirements traceability, Progress tracking
User: Consistency with requirements & usage scenarios, Quality attributes: Flexibility, scalability, reliability, usability
Architect: Support of trade-off analysis, Requirements traceability, Completeness, consistency of architectures, Context definition
Developer: Sufficient detail for design, Reference for selecting/assembling components, Quality attributes: Interoperability, testability
Maintainer: Guidance on software modification, Guidance on architecture evolution, Quality attributes: Interoperability, maintainability, testability
4.8 Classifying Their Positions: The Stakeholder Matrix
Stakeholders are plotted against two variables: Power & Level of Interest
Stakeholder Matrix : This matrix’s purpose is to identify the stakeholders for the architecture engagement, their influence over the engagement, and their key questions, issues, or concerns that must be addressed by the architecture framework.
4.9 Determining the Stakeholder Management Approach and Tailoring the Deliverables: The Stakeholder Map
A stakeholder map identifies stakeholders and their characteristics.
We defined the term stakeholder; and we discussed stakeholder analysis using a stakeholder matrix and stakeholder map.