Loading...
 

definition-Stakeholder

Definition:

Stakeholders are any person, group or System, that have or we want to have an interest in our project.

Alternative Names

Concept Number: *233
English Master: Stakeholder
Synonyms, Variations & Acronyms: none

Detailing

The critical Stakeholders are the ones that can determine success or failiure of your project.
If you dont find the critical Stakeholders, they will find you!
The Stakeholders have the Requirements that the project potentially must satisfy.
The Parameter ‘Stakeholder:’ can be used to specify one or more Stakeholders explicitly. We can attach Stakeholder information to any Elementary specification, or to a set of Specifications as appropriate.


Illustrations

visual example of Stakeholders
Illustration: visual representation of a System and the many Stakeholders with a interest in the System.


Type

Parameter [Role]
Role


Examples

Stakeholder: End-User.Bank-Customer:
Stakeholder: End-User.Music-Lover: Pleasure, Beauty, Choice,
Stakeholder: End-User.Lake "or the people interested in the lake": Oxygen, Algae, Bio-Diversity, Chemicals.
Stakeholder: Customer.Bank: Profit, Happy-Customers
Stakeholder: Customer.Music-Stereo-Developer: Market-Share, Reputation, Return-On-Investment
Stakeholder: Customer.Lake-Environmentalists: Learning, Happiness, Challenges, Public-Awareness
Stakeholder: Legal: Our Legal Department, Norwegian Law
Stakeholder: Competitor: Mean Inc.
Stakeholder: System: API of mother ship.

Goal [Stakeholders = {Stakeholders = Installers, Service People}, Deadline = End This Year] 60 hours ← Marketing Authority.
Marketing Authority: Stakeholder: Our Service Organization.


Notes

We can group Stakeholders or split one Stakeholder into two or more Stakeholders. For example, if we have two types of End-Users, we could specify them together as one Stakeholder or as two sepearte End-User Stakeholders.
If they have the same or similar Requirements, I keep tham togeter as one, if they have different Requirements, I list them seperately.

I examine each Stakeholder, and identify:
1) what each one want to achieve, and
2) what we or our System can do to help them achieve it.
3) if we want to be in the business of meeting their needs.

Stakeholders can exercise control over both the immediate System operational characteristics, as well as over long-term System lifecycle considerations (such as portability, lifecycle costs, environmental considerations, and decommissioning of the System).

Stakeholder: An interested party having a right, share or Claim in the System or in its possession of Qualities that meet their needs.
Source: Standard ISO/IEC 15288:2002] and ISO/IEC 25000.

Stakeholders include, but are not limited to, end users, end user organisations, supporters, developers, producers, trainers, maintainers, disposers, acquirer, supplier organisations and regulatory bodies

1. The views and needs of Stakeholders have to be sought and listened to. For example, Stakeholders might have an interest in:
• setting the Requirements for a Process, project or Product
• evaluating the Quality of a Product
• using the Product or System, even indirectly
• avoiding problems themselves as a Result of our Product or System
• the System or Product being compatible with another machine or software Component
• determining the Constraints on development, operation or retirement of the System or Product

2. Stakeholders specify Requirements, directly or indirectly, for the System Attributes (Function, performance, Resource, Design-Constraints, and Condition-Constraints). They determine the degree of Product or System success or failure.

3. Systems-Engineers should determine which Requirements the Stakeholders need, and which Requirements they can afford. Even if the Stakeholders are not currently conscious of those needs and limitations!
The Goal Requirement applies to a set of defined Stakeholders. The Requirement Authority (the one who has requested this Goal Level) is defined as another Stakeholder.

4. Stakeholders can be internal or external to a System. Internal-Stakeholders are typically in our development organization, or related to it or to the development Process. External-Stakeholders are users and customers of the developed System. Very External-Stakeholders are instances like laws and government organizations that can impose Requirements on our System. This distinction is useful:
• to help us develop better lists of Stakeholders
• so we don’t get fixated on the ‘customer/user’ as the only Requirements source
• to give us a Systematic set of (internal) Stakeholders to deliver to, as we Evolve the System, even when it is not ready for External-Stakeholders.

5. Stakeholder classes RACI, which stands for Responsible, Approver, Consulted, and Informed. This might provide valuable detail rather than a simple clump of people within the Stakeholder. <- Erik Simmons

6. : I suggest we can generally classify Stakeholders with these Concepts:
Stakeholder Hierarchy
= any set of Client-Stakeholders and their Server-Stakeholder relationships.
Client-Stakeholder
= any Stakeholder with needs that any Server-Stakeholder might satisfy.
Server-Stakeholder
= any Stakeholder that plans to satisfy some Client-Stakeholder needs.


Keyed-Icons

: - | Stakeholder or Neutral Stakeholder converts in Word to :-| (:neutral:)
: - ) Happy/Satisfied Stakeholder converts in Word to ☺(:lol:)
: - ( Unhappy Stakeholder converts in Word to ☹ (:sad:)


Drawn-Icons

none


Owner *102
Client *235: Synonym is Customer
Sponsor *396
Consumer *038: Synonym is Customer
Decision-Maker *237
User *234
Designer *190


History-of-Concept

none









This Concept entered by Kai.

Created by system. Last Modification: Thursday 11 of July, 2019 20:46:43 CEST by Admin (Kai).