Stakeholder Identification of the process of identifying the stakeholders for a particular project or initiative that is being undertaken. It is the first step in the
Stakeholder Triad of activities (shown below).
The Stakeholder Identification process is among the very first steps taken in initiating a new project or effort. It is both a precursor to, and a part of, the Stakeholder Analysis effort. It also plays a key role in the Stakeholder Management effort (the third step in the
Stakeholder Triad) and in the Requirements Elicitation process.
When discussed as part of the Stakeholder Triad and the resulting Stakeholder Management process, it should be obvious that Stakeholders cannot be analyzed or managed if they have not been identified.
In regards to the Requirements Elicitation process, the connection should again be obvious. Requirements cannot be elicited if you don't know who to elicit them from. Or if not eliciting from a person, you cannot elicit requirements without identifying who can give you access to system manuals, users, maintenance logs, and the myriad of other assets that can be leveraged as part of a requirement elicitation effort.
There are a number of different ways to identify stakeholders. Some of the approaches are:
The category approach is probably the most commonly used method of identifying stakeholders. In this method, categories of stakeholders are created by the project team (based on past experience and brainstorming) and these are then used to identify specific stakeholders. Examples of categories might include:
Be careful of making the categories too broad, as that can make it easier to overlook stakeholders. 
The role approach is similar to the category approach. But instead of stakeholder categories, the project team works from a generic list of specific stakeholder roles. Note that the roles include both project roles and system roles. Example roles might include:
Because the roles are usually very generic, this approach makes it easy to overlook stakeholders who don't have a direct interactive role in the system or project. For example, if the system purpose was to generate and deliver documents to clients the project team would likely define roles of: user, client, maintenance, and possibly regulator. But it would be easy to overlook a corporate communications team that controlled document style's such as formatting, logos, and other standards.
The interview approach consists of the following four-step process:
The interview method is generally more successful than the category or role approaches in identifying new stakeholder roles and new individuals to potentially fill those roles. Unfortunately, the interview approach is usually very time-consuming and may not feasible in large projects. Additionally, it may not be possible to interview some identified stakeholders if they are outside the firm (such as a regulator) or are otherwise unavailable.
The search approach [1, 2] combines features from all three of the prior methods. The process works as follows:
Beginning with four baseline categories of stakeholders, identify specific stakeholder roles within those categories that are appropriate for the project or initiative. The four baseline categories are:
Users: These are people, groups, or companies who will interact with the software or process being implemented, who will control it directly, and those who will use the products (information, results, etc.) of the system.
Developers: These are those who have a role in the creation or maintenance of the software, system, or process but who do not have the same relationship as the Users. Examples include systems analysts, programmers, testers, quality assurance staff, systems maintenance staff, project managers, business analysts, development tool vendors, and similar roles.
Legislators: These are roles that define or influence the operational guidelines of the system or process being developed. Examples include professional bodies, regulators, trade unions, quality assurance auditors, safety staff, standards agencies or bodies, and similar roles.
Decision-Makers: These are stakeholders who have decision-making role over the project or system. Examples include the sponsor, budget or finance management, development management, user management, and similar roles. Note that many decision-makers will also exist in one of the other stakeholder categories above.
Once the project roles for each of the categories above have been identified, the group of stakeholders is expanded by searching for the following:
Once all of the specific roles have been identified, specific stakeholders are identified that could fill those roles. In many cases, the specific stakeholder to fill a role is automatic because a specific role may be synonymous with a specific person.
While this approach will usually result in a more complete stakeholder list than the other approaches identified above, one key issue is knowing when to stop. For example, it may not really be necessary to know who the supplier of a supplier of a customer of a user is.
The following approach is an extension of the old saying,
Follow the money! The purpose is to follow some specific artifact through a lifecycle to identify the stakeholders who provide or use that artifact, or who have responsibility for it in some way.  The difference is that you follow more than just the money. Among the options to follow are:
This approach can help identify some non-obvious stakeholders (such as the system that uses an output resulting from the output of 4 intermediary systems that are ultimately driven by output of the project system), but it can miss many stakeholders that are not part of the specific artifact process being followed, but who are influenced by it (either directly or indirectly).
The goals approach to stakeholder identification consists of the following six step process: 
At a minimum, the results of a Stakeholder Identification effort should include as complete a list of stakeholder roles as possible given the knowledge at the time.
No matter what approach is taken to identifying stakeholders; the primary goal in most cases should be to identify the stakeholder roles that are needed to make the project a success. The idea is to identify specific roles that need to be filled and the ideal characteristics of the person who would fill that role. For example, if you have identified a need for Legal or Compliance stakeholder, you want to make sure the role specifies expertise in the areas need for the project. Or there may be multiple Legal / Compliance stakeholder roles identified with different areas of expertise.
Note that the roles identify specific stakeholder traits (business knowledge, systems knowledge, budgeting power, technical decision-making capabilities, specific Legal knowledge, etc.), not specific stakeholder representatives who will fill those roles.
By identifying specific stakeholder roles and their associated characteristics, the project team generates a check-list that ensures that they have all of the needed expertise and representation. Rather than assuming a particular stakeholder representative has the knowledge or characteristics needed, the project team can ensure that they have representatives who can fill all of the roles, even if that means one stakeholder filling multiple roles, or multiple stakeholders representing a single department or group to ensure all roles are met.
Once the roles are identified and some initial candidates found for some roles (such as the Sponsor), the Stakeholder Analysis effort will help in identifying roles that were missed as well as identifying the best people to fill the identified stakeholder roles for the project. Additionally, further information on the stakeholders, their goals and needs, their relationships, and other factors will be gathered during the Stakeholder Analysis process. This information may result in new roles being added, new role characteristics being defined, or existing roles or role characteristics changed.
These roles can be determined at least in part before there is anyone specified to fill them and include roles such as the following:
A more generic set of Roles includes: 
These roles are for those stakeholders who will benefit from the project solution. There are several sub-roles within the beneficiary category:
Financial: Those who indirectly receive a financial reward through the solution.
Functional: Those who benefit directly from the solution, its products, or its output.
Negatives: Those that receive some sort of damage or are adversely affected by the solution implementation.
Political: Those will indirectly receive a political benefit in terms of power, prestige, or influence from the solution.
Sponsors: These stakeholders are in charge of the project and are responsible for overseeing the project effort, collecting the funds for project work and solution implementation, protecting the project from interference, and other similar tasks.
These are roles for those stakeholders who will provide support for solution implementation, but who will not be engaged in ongoing operations or support. They are usually external to the firm and usually provide knowledge services in a specific aspect of the solution.
These are the stakeholder roles that will control the process and make decisions on project scope, solution, budget, and other factors. In essence, they define the project goals and solutions.
These roles are directly involved in solution development and implementation but not ongoing support or maintenance. Examples include : business analyst, project manager, designer, programmer, tester, quality tester, safety engineer, etc.
These roles are familiar with the functionality and consequences of the solution implementation. They widely know the implementation domain and can collaborate in the requirements process. An example would be Subject Matter Experts.
Often called "Users", these are roles for those who will interact directly with the system and use its results. The Operators group includes those who support the system, not just use it. Also note that Operators do not have to be beneficiaries of a system, although they can be.
These roles generate guidelines or specifications that the solution must adhere to. Examples include: government regulatory bodies; internal compliance, security, and legal staff; professional or industry associations; international treaties; and similar standard-setting bodies.