The concept of Stakeholder
is used in many disciplines, including the Social Studies disciplines (Governance, Development, etc.), Business, Information Systems, Software Development and almost any discipline where there is an undertaking for change. That undertaking can be a software project, business development initiative, political or social campaign, or a large number of similar efforts. The problem with the Stakeholder concept, however, is that there are many different definitions of the term. Additionally, many authors don't provide explicit definitions of the term 'stakeholder'. If there is this level of confusion in common usage (academic, business, governmental, and others), then Business Analyst's need to ensure that there is a common understanding of what definition of 'stakeholder' the project will use. There are many definitions, among which are:
In the field of Business Analysis, the IIBA has provided a definition of a Stakeholder as:
A group or person who has interests that may be affected by an initiative or influence over it.[1]
One of the original definitions of business stakeholders [2] came from Freeman, which was:
A stakeholder in an organization is any group or individual who can affect or is affected by the achievement of the organization's objectives.Also from the business domain are these definitions: [4]
These definitions came from Information Systems research:
We define stakeholders as these participants together with any other individuals, groups or organizations whose actions can influence or be influenced by the development and use of the system whether directly or indirectly.[3]
The stakeholders are a group of people sharing a pool of values that define what the desirable features of an information system are and how they should be obtained." [4]From the Software Engineering field have come several definitions, including: [3]
As you can see from these few examples (and there are MANY more out there), there are many definitions of a stakeholder. What a Business Analyst needs to consider is how are you going to define 'stakeholder' for your current effort in a way that is broad enough to help you identify the stakeholders you need to know about, but not so broad that you spend months just trying to identify every possible stakeholder.
Stakeholders the most important actors in any project or undertaking. At a minimum, stakeholders provide:
Problems with stakeholders are also probably the single greatest factor in project failure. Whether it's a failure to include some stakeholders at all in the project, or the inclusion of the wrong stakeholder representatives, or the different goals and expectations of stakeholders. Stakeholders are at the core of project success or failure.
The differing outlooks, expectations, and success criteria among stakeholders is a particular concern. As one research team put it, "a major obstacle for the alignment of information systems and business strategies are the conflicting expectations and perceptions of information systems that different organizational stakeholders have. Senior management is mostly concerned with cost whereas users are mostly concerned with service." And technical and project teams are usually stuck in the middle trying to find a balance among these. Failure to find the right balance often results in project failure.
And of course, different stakeholders may have different levels of importance, power, and influence.
NOTE: I am looking for a better set of terms than entities and roles for defining this point. Any suggestions or comments would be welcome.
One problem in discussing stakeholders is that in any project there are really two types of stakeholders. The first are stakeholder entities. These are the actual people, organizations, or groups that have a stake of some sort in the project undertaking. Note that when talking about groups or organizations the stakeholder entities include potentially all of the people in those groups or organizations. This is an important distinction because it helps separate entities from roles.
Stakeholder roles on the other hand are the actual stakeholder participants in a project or initiative. Unfortunately, for most projects the business analyst in project team focus only on the stakeholder roles in the people filling those roles.
To better understand the difference think of a project to update a software application that is used by the customer service staff of a firm. All of the customer service staff that currently use the software, or will in the future, are stakeholders in the form of stakeholder entities. All users are stakeholders in this sense. The subject matter experts or end-user representatives who actively participate in the project are examples of people fulfilling stakeholder roles.
Understanding this difference is important because the business analyst or the project team will often focus exclusively on stakeholders who have been chosen to fill specific roles in the project effort. However, this often results in requirements that reflect a single stakeholders' point of view in which may not capture the needs of the entire stakeholder group. As a business analyst, you not only want to elicit requirements from the SME or group representatives for filling the project role. Make sure you at least reach out and review the requirements at a minimum with other stakeholders from the impacted groups who may not be actively participating in the project.
Understanding the following principles about stakeholders can help a business analyst do their job better and engage in a more effective Stakeholder Triad effort: [4]
The set and number of stakeholders for any project are context and time dependent.
The number and identity of the appropriate stakeholders to engage can change as the organizational or project environment changes over time.
Stakeholders cannot be viewed in isolation.
Stakeholders are often linked to other stakeholders in a variety of ways, and to understand a stakeholder you also need to understand their relationships.
A stakeholder's role may change over time.
Stakeholder power and interest can change during the project lifecycle. Or other factors may drive the decision to change a stakeholders role in some way, such as when the solution has been defined in such a way that a different stakeholder may be more appropriate for filling one of the roles a stakeholder is currently filling.
Stakeholders may have multiple roles.
Stakeholders may fill multiple roles within a project effort. Do not think of the stakeholder as a monolithic entity, rather think of each role that a single stakeholder may be filling in the project effort as their interests or power may be different depending on the specific role you are engaging them on.
Different stakeholders may have different perspectives and wishes.
Each stakeholder has a different perspective and frequently a different set of goals or success criteria for a project. This is frequently true even for stakeholders within the same organization or group who would frequently be thought of as having the same outlook and goals.
The viewpoints and wishes of stakeholders may change over time.
As the project involves and stakeholders gain greater knowledge and perspective of the issues being addressed or of the specific aspects of the solution being considered, their viewpoint and wishes for the project can change. It is often important to reassess stakeholder viewpoints and goals whenever significant project decisions have been made.
Stakeholders may be unable to serve their interests or realize their wishes.
Remember that stakeholders may not have the time, influence, or resources to serve their own interests or ensure there goals are achieved by the project. A lack of power or influence can often be mistaken for a lack of interest or importance. However, the project team should try to look beyond these factors to identify stakeholders who may need help in serving their interests when those interests are important to the project success.
In Business Analysis, the Stakeholder concept is intrinsically linked with the Stakeholder Triad of Stakeholder Identification -> Stakeholder Analysis -> Stakeholder Management.
Stakeholder, pg. 232