Stakeholder Identification

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

Stakeholder Triad - Identification Phase

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:

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:

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:

  1. Identify obvious stakeholder roles and possible stakeholders to fill that role.
  2. Interview the stakeholder to learn about other possible stakeholders to fill that role, and other stakeholder roles that have not been identified yet.
  3. Add the newly identified roles and possible stakeholders to fill those roles to the stakeholder list.
  4. Repeat steps 2 and 3 until no new stakeholders are identified.

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.

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:

  1. Are any of the initially identified roles too broad? Should a role be broken apart into one or more separate roles?
  2. What are the 'supplier' stakeholder roles for each of the roles above?
  3. What are the 'client' stakeholder roles for each of the roles above?
  4. What are the 'satellite' stakeholder roles who interact with each of the roles above, but who are not suppliers or clients?
  5. 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:

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

Goals Approach

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

  1. Identify a vision or objective
  2. Describe a number of future states in terms of goals understandable by the stakeholder group
  3. Break the goals down into the process, technology, organization and culture steps necessary to achieve the goals
  4. Identify the stakeholder groups whose commitment is necessary to achieve each goal
  5. For each type of stakeholder, describe the:
    1. Needed changes,
    2. Perceived benefits, and
    3. Expected kinds of resistance
  6. Within each stakeholder group, identify specific stakeholder participants who have the knowledge, power, interest, and capabilities to:
    1. Implement the changes correctly,
    2. Support the benefits realization, and
    3. 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:

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

 

Associated Concepts

 

Associated Techniques

 

Tips

 

References

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

Related Resources