Stakeholder Identification | Wiki

What is it?

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).

Why do it?

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.

How do I do it?

There are a number of different ways to identify stakeholders. Some of the approaches are:

Category Approach

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:

Those who interact directly with a system
Those with interests in the project outcome
Those who fund the project

Be careful of making the categories too broad, as that can make it easier to overlook stakeholders. ^[2]

Role Approach

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:

User
System Admin
Maintenance
Regulator
Sponsor
Technical Architect
Business Architect
Project Manager
Client

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.

Interview Approach

The interview approach consists of the following four-step process:

Search Approach

The search approach ^{[1, 2]} combines features from all three of the prior methods. The process works as follows:

Step 1

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.

Step 2

Once the project roles for each of the categories above have been identified, the group of stakeholders is expanded by searching for the following:

Are any of the initially identified roles too broad? Should a role be broken apart into one or more separate roles?
What are the 'supplier' stakeholder roles for each of the roles above?
What are the 'client' stakeholder roles for each of the roles above?
What are the 'satellite' stakeholder roles who interact with each of the roles above, but who are not suppliers or clients?
Repeat steps 1-4 for each new role identified in 2-4.

Step 3

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.

Following Approach

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. ^[4] The difference is that you follow more than just the money. Among the options to follow are:

Goals Approach

The goals approach to stakeholder identification consists of the following six step process: ^[5]

Identify a vision or objective
Describe a number of future states in terms of goals understandable by the stakeholder group
Break the goals down into the process, technology, organization and culture steps necessary to achieve the goals
Identify the stakeholder groups whose commitment is necessary to achieve each goal
For each type of stakeholder, describe the:

Needed changes,
Perceived benefits, and
Expected kinds of resistance

Within each stakeholder group, identify specific stakeholder participants who have the knowledge, power, interest, and capabilities to:

Implement the changes correctly,
Support the benefits realization, and
Overcome the expected resistance

What Should the Results be?

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.

Role Identification and Assignment

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:

Sponsor
Project Manager
Technical Analyst
Enterprise or Business Architect
System Architect
End User - Advanced skill
End User - New / Low skill
Technical maintenance expert
Developer (there may be different developers for specific aspects of the solution)
Data architect / management expert
Legal / Compliance representative

A more generic set of Roles includes: ^[6]

Beneficiaries

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.

Consultants

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.

Decision-Makers

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.

Developers

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.

Experts

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.

Operators

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.

Regulators

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.

Risks

There seems to be an assumption that Stakeholder Identification is an easy and relatively straightforward process. In reality, achieving a complete stakeholder list seems to be anything but simple. ^[1]
Remember that the purpose of the Stakeholder Identification process is to identify all stakeholders, not which specific stakeholder will best fit a specific stakeholder role. That is determined in Stakeholder Analysis. If you stop looking for possible stakeholders once you have identified one person who could fill a possible role, you can easily miss other stakeholders who may be better options or who may have important information or insight.

Associated Concepts

Stakeholder
Stakeholder Analysis
Stakeholder Management

Associated Techniques

Brainstorming
Document Analysis
Interviews
Organization Modeling
Stakeholder Role Matrix

Tips

A good way to identify important stakeholders related to a specific application is to check the issue logs for the users who reported the issue and the technical staff that analyzed and/or fixed and issue. These are often high-knowledge stakeholders who may not have much power or prominence, but who often have a wealth of knowledge.
When identifying stakeholders who could fill a particular role, the organization chart is a great way to get you started. If you know you need a representative from a particular department, use the org chart to identify all of the managers and supervisors as stakeholders who could potentially fill a role.
Don't ignore opponents! They are stakeholders too!

References

Research Paper: Stakeholder Identification in the Requirements Engineering Process. Helen Sharp, Anthony Finkelstein, and Galal Galal. 1999
Research Paper: StakeNet: Using Social Networks to Analyse the Stakeholders of Large-Scale Software Projects. Soo Ling Lim, Daniele Quercia, and Anthony Finkelstein. 2010
BABOK Guide v2, Section 2.2: Conduct Stakeholder Analysis.
Article: Identify your project stakeholders - and only then plan communications. By Dansar. On the Bright Hub PM web site.
Research Paper: Aspects of the Stakeholder Concept and their Implications for Information Systems Development. Athanasia Pouloudi. 1999
Research Paper: Method for stakeholder identification in interorganizational environments. Luciana C. Ballejos and Jorge M. Montagna. 2008.

Related Resources

Article: Agile Analysis: Stakeholder Identification. By Angela and Tom Hathaway. On the BA Experts web site.

Stakeholder Identification | Wiki | BAwiki (2024)