From WICSA Conference Wiki

Contents 1 Stakeholders 1.1 Definition 1.2 Interacting with Stakeholders 1.3 Properties of a Good Stakeholder 1.4 Common Stakeholders for Information Systems 1.5 Stakeholder Strategies 1.6 Stakeholder Checklist

Stakeholders

Definition

A stakeholder is a person, group or entity with an interest in or concerns about the realization of the architecture. The reason that the architecture is being created. All architectural design should stem from a stakeholder concern.

Interacting with Stakeholders

Options for interacting with the stakeholders for a system include:

• Ignore a stakeholder completely.
• Take the perceived needs of a stakeholder into account, but without involving the stakeholder in the development process.
• Employ a third party to represent a stakeholder (or stakeholder group) in the development process (the third party being termed a proxy stakeholder). An example of this could be a product manager for a shrink-wrap software product, who represents the ultimate user of the product.
• Involve the stakeholder directly.

Properties of a Good Stakeholder

Important properties of a good involved, or proxy, stakeholder include:

• Informed - Do your stakeholders have the information, the experience and the understanding needed to be able to make the right decisions?
• Committed - Are your stakeholders willing and able to make themselves available, and to have the confidence to make some possibly difficult decisions?
• Authorized - Can you be sure that decisions made now by your stakeholders will not be reversed later on (at potentially high cost)?
• Representative - If a stakeholder is a group rather than a person, have suitable representatives been selected? Do those representatives meet the above criteria for individual stakeholders?

Common Stakeholders for Information Systems

• Acquirers - Oversee the procurement of the system or product.
• Assessors - Oversee the system’s conformance to standards and legal regulation.
• Communicators - Explain the system to other stakeholders via its documentation and training materials.
• Developers - Construct and deploy the system from specifications (or lead the teams who do this).
• Maintainers - Manage the evolution of the system once it is operational.
• Support Staff - Provide support to users for the product or system when it is running.
• System Administrators - Run the system once it has been deployed.
• Testers - Test the system to ensure that it is suitable for use.
• Users - Define the system’s functionality, and ultimately make use of it.
• Suppliers - Build and/or supply the hardware, software or infrastructure on which the system will run.

There are also Architects of course, responsible for the creation and ownership of the architecture. The ones to get sacked (or promoted to a management position) should the system under consideration be considered a failure by the other stakeholders.

Stakeholder Strategies

• The selection of stakeholders is a subjective activity; but in general, the wider the stakeholder community, the better your chances of delivering a successful product or system.

• If you have a large stakeholder group, you need to actively manage it to ensure that its size does not impede progress. In particular, you need to balance and prioritize the needs of the different stakeholder groups, so that when conflicts occur, you can make sound, well-reasoned decisions.

• Ensure ensure that there is adequate stakeholder representation across-the-board, including non-technology stakeholders such as acquirers and users, and technology-focused ones such as developers, system administrators and maintainers.

• Where “real” stakeholders cannot be identified (for example a user community which does not yet exist), the architect should identify proxy stakeholders to represent their interests. The proxy stakeholders should (as far as possible) meet the same criteria as their real counterparts.

Stakeholder Checklist

• Has at least one stakeholder of each class been identified, and if not, is the omission justified?
• Has each stakeholder been made aware of their responsibilities and have they agreed to these?
• In particular, does each stakeholder understand the level of commitment involved, in terms of attending meetings, reviewing documents, and making decisions?
• Is each stakeholder aware of the role they will be taking (acquirer, user etc)?
• Where a group of stakeholders is identified, has a suitable representative been identified and engaged? Does this proxy have the knowledge and authority to speak on behalf of the group?
• Where stakeholders do not exist as a group (eg customers for a new software product) has a suitable proxy been identified and engaged?
• If suppliers are to be included as stakeholders, are their responsibilities and (if appropriate) contractual obligations clearly understood by both sides?