<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Who Should I Listen To? Prioritizing Organizational Stakeholders	</title>
	<atom:link href="https://www.projectmanagementplanet.com/who-should-i-listen-to-prioritizing-organizational-stakeholders/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.projectmanagementplanet.com/who-should-i-listen-to-prioritizing-organizational-stakeholders/</link>
	<description>Tutorials and tools for managing, estimating, planning and tracking software development projects: PMP, Agile, Scrum, Lean, Kanban</description>
	<lastBuildDate>Mon, 24 Oct 2022 15:37:53 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: tom gilb		</title>
		<link>https://www.projectmanagementplanet.com/who-should-i-listen-to-prioritizing-organizational-stakeholders/#comment-400</link>

		<dc:creator><![CDATA[tom gilb]]></dc:creator>
		<pubDate>Mon, 26 Nov 2012 19:00:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.projectmanagementplanet.com/?p=1292#comment-400</guid>

					<description><![CDATA[Good paper Ulf, but of course I have some thoughts -
It is logically necessary to include non human stakeholders, such as law and standards, if we are to derive all necessry requirements. Most people miss this point. 

DETAILS
Consider the definition of stakeholder (from my Planguage and CE book)
Planguage Concept Glossary as edited in Competitive Engineering book 2005
http://www.gilb.com/tiki-download_file.php?fileId=387



Stakeholder						Concept *233 May 10 2011 (‘defined’)
A stakeholder is any person, group or object, which has some direct or indirect interest in a defined system. 

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).

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.

	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
NOTE Stakeholders include, but are not limited to, end users, end user organisations, supporters, developers, producers, trainers, maintainers, disposers, acquirer, supplier organisations and regulatory bodies

Notes:
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. 

 
Some stakeholder concepts. Courtesy Gerrit Muller, Philips, Eindhoven, NL. In 
“Requirements Capturing by the System Architect” 
[Editor Note to Publisher: EDIT NOTE: PERMISSION GRANTED TO USE THIS IN EMAIL 9 NOV 2001 FILED IN PERMISSIONS FOLDER TG]

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!

Example:
Goal [Stakeholders = {Stakeholders = Installers, Service People}, Deadline = End This Year]: 60 hours ← Marketing Authority.
Marketing Authority: Stakeholder: Our Service Organization.
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. &#060;- 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 *233]:
: - &#124;	Stakeholder or Neutral Stakeholder converts in Word to :&#124;
: - )	Happy/Satisfied Stakeholder converts in Word to ☺
: - (	Unhappy Stakeholder. Converts in Word to ☹
 
Related Concepts [Stakeholder *233]:
• Owner *102
• Client *235: Synonym is Customer
• Sponsor *396
• Consumer *038: Synonym is Customer
• Decision-Maker *237
• User *234
• Designer *190]]></description>
			<content:encoded><![CDATA[<p>Good paper Ulf, but of course I have some thoughts &#8211;<br />
It is logically necessary to include non human stakeholders, such as law and standards, if we are to derive all necessry requirements. Most people miss this point. </p>
<p>DETAILS<br />
Consider the definition of stakeholder (from my Planguage and CE book)<br />
Planguage Concept Glossary as edited in Competitive Engineering book 2005<br />
<a href="http://www.gilb.com/tiki-download_file.php?fileId=387" rel="nofollow ugc">http://www.gilb.com/tiki-download_file.php?fileId=387</a></p>
<p>Stakeholder						Concept *233 May 10 2011 (‘defined’)<br />
A stakeholder is any person, group or object, which has some direct or indirect interest in a defined system. </p>
<p>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).</p>
<p>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.</p>
<p>	Stakeholder  :<br />
An interested party having a right, share or claim in the system or in its possession of qualities that meet their needs.<br />
Source: Standard   ISO/IEC 15288:2002] and ISO/IEC 25000<br />
NOTE Stakeholders include, but are not limited to, end users, end user organisations, supporters, developers, producers, trainers, maintainers, disposers, acquirer, supplier organisations and regulatory bodies</p>
<p>Notes:<br />
1. The views and needs of stakeholders have to be sought and listened to. For example, stakeholders might have an interest in:<br />
• setting the requirements for a process, project or product<br />
• evaluating the quality of a product<br />
• using the product or system, even indirectly<br />
• avoiding problems themselves as a result of our product or system<br />
• the system or product being compatible with another machine or software component<br />
• determining the constraints on development,  operation or retirement of the system or product</p>
<p>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. </p>
<p>Some stakeholder concepts. Courtesy Gerrit Muller, Philips, Eindhoven, NL. In<br />
“Requirements Capturing by the System Architect”<br />
[Editor Note to Publisher: EDIT NOTE: PERMISSION GRANTED TO USE THIS IN EMAIL 9 NOV 2001 FILED IN PERMISSIONS FOLDER TG]</p>
<p>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!</p>
<p>Example:<br />
Goal [Stakeholders = {Stakeholders = Installers, Service People}, Deadline = End This Year]: 60 hours ← Marketing Authority.<br />
Marketing Authority: Stakeholder: Our Service Organization.<br />
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.</p>
<p>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:<br />
• to help us develop better lists of stakeholders<br />
• so we don’t get fixated on the ‘customer/user’ as the only requirements source<br />
• 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.</p>
<p>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. &lt;- Erik Simmons</p>
<p>6. : I suggest we can generally classify stakeholders with these concepts:<br />
	Stakeholder Hierarchy<br />
	= any set of Client Stakeholders and their Server Stakeholder relationships.<br />
Client Stakeholder<br />
	=  any stakeholder with needs that any server stakeholder might satisfy.<br />
Server Stakeholder<br />
	= any stakeholder that plans to satisfy some client stakeholder needs.</p>
<p>Keyed Icons [Stakeholder *233]:<br />
: &#8211; |	Stakeholder or Neutral Stakeholder converts in Word to :|<br />
: &#8211; )	Happy/Satisfied Stakeholder converts in Word to ☺<br />
: &#8211; (	Unhappy Stakeholder. Converts in Word to ☹</p>
<p>Related Concepts [Stakeholder *233]:<br />
• Owner *102<br />
• Client *235: Synonym is Customer<br />
• Sponsor *396<br />
• Consumer *038: Synonym is Customer<br />
• Decision-Maker *237<br />
• User *234<br />
• Designer *190</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
