Stakeholder Analysis

Stakeholder Triad - Analysis Phase

What is it?

Stakeholder Analysis is the 2nd phase of the Stakeholder Triad. However, it is tightly intertwined with the Stakeholder Identification process and the two phases run concurrently after an initial set of stakeholders or stakeholder roles are defined by the project team. Indeed, many authors or parties make no attempt to differentiate the Identification and Analysis processes at all. For example, the IIBA has provided a specific definition of Stakeholder Analysis, which is: [4]

The work to identify the stakeholders who may be impacted by a proposed initiative and assess their interests and likely participation.

It involves analyzing specific stakeholders, their interests, their goals, their relationships, their functions, and their characteristics in order to understand:

Or, in a more generic way, Stakeholder Analysis is the process of identifying stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables.

Why do it?

Stakeholder analysis is undertaken in the service of two different needs.

  1. The first is to provide the stakeholder information that underlies a project teams stakeholder management effort.
  2. The second is to help the business analyst identify potential stakeholders and what knowledge they may have so that they can be correctly engaged in the requirements process.

For Business Analyst's, the second reason is critically important. While "missed or incorrect requirements" is a commonly cited cause of project failure, it is frequently assumed that this was due to an oversight or lack of skill on the BA's part in Requirements Elicitation. However, in many cases these requirements were missed simply because important stakeholders were never identified. When stakeholders are not identified, whole groups of requirements are either entirely missed or competing needs that would modify captured requirements are missed.

How do I do it?

Stakeholder analysis begins with identifying stakeholders who may be affected by the business need or a new solution. Stakeholders may be grouped into categories that reflect their involvement or interest in the initiative. The roles, responsibilities, and authority over the requirements for each stakeholder or stakeholder group must be clearly described. Stakeholder analysis also involves understanding stakeholder influence on and attitude towards the initiative, and assessing positive and negative attitudes and behaviors which may affect the outcome of the initiative and acceptance of the solution.

Identification

The first step in stakeholder analysis is the identification of project stakeholders. This is covered in more detail in the Stakeholder Identification entry. However, during the Stakeholder Analysis phase specific stakeholders should be found, evaluated, and assigned to fill any stakeholder roles that remained unfilled after the Stakeholder Identification effort.

Interview, Assess, and Analysis

As stakeholders are identified (as either new stakeholders or to fill an identified role), they should be interviewed (where possible), assessed, and analyzed. This includes categorizing and prioritizing stakeholders; identifying their goals, areas of expertise and interest, and resources; and determining what sort of communications they want and how they prefer to be communicated with.

Categorization

Stakeholder categorization is both one of the most important and most difficult activities undertaken as part of a stakeholder analysis effort. As stakeholders are identified, the project team should attempt to categorize each stakeholder along multiple lines. Among these are:

Attitude towards the Project

Determining a stakeholders attitude towards the project itself is one of the most important factors to determine. It can also sometimes be one of the most difficult. Stakeholders attitude are frequently categorized as one of the following five options:

Attitude towards the Project Team

It is sometimes useful to categorize stakeholders based on their attitude towards the project team or specific project team members that will play a prominent or critical role in the project. Knowing if the Project Manager, Business Analyst, or other key project member has had a difficult relationship with a stakeholder in the past, or worked with the stakeholder on a failed or unsuccessful project previously can help the project team in identifying potential stakeholder bias or attitudes that may prove a hindrance to project success.

Attitude towards Other Stakeholders

Just as it is sometimes useful to determine if stakeholders may have a hostile or uncooperative attitude towards members of the project team, it can also be useful to identify stakeholders that may have a hostile or uncooperative attitude towards other stakeholders. This can help identify potential areas where there may be significant differences in perception over the project goals or requirements. They can also provide valuable information for stakeholder management efforts.

Expected Results

One of the single most important ways of categorizing stakeholders is by their expected results from the project. This information is critical for not just the stakeholder management effort, but in identifying what project success looks like for each stakeholder.

Note that expected results can take multiple forms. For an external stakeholder, such as a consultant or contract development firm, expected results may simply be on time payment for services delivered. Other results external stakeholders may desire include positive publicity, a new business relationship, maintenance of an existing business relationship, access to the project results, or even goodwill from the business or organization.

For internal stakeholders expected results can range from new software, improved processes, greater influence, personal rewards such as a promotion or salary increase, or even a feeling of importance or meaningfulness to the organization.

By categorizing (and grouping) stakeholders who have similar expected results, the project team identifies potential coalitions among the stakeholders. Additionally, by knowing what results are important to each stakeholder, the project team can ensure they are engaged during project activities that are related to their area of concern.

Influence

Stakeholders can be categorized by the amount of influence they can have over the project success. This means not only identifying the level of influence the stakeholder has within the business overall, but also the level of influence they may have on the projects budget, access to resources, implementation, persuasive influence over key decision-makers, or control of critical knowledge. Indeed, the project team may want to map each stakeholders influence level across multiple aspects of the project space (such as budget, resources, knowledge) in order to more fully understand their potential impact as well as when to best engage with each stakeholder. An important point to remember is that Influence is not the same thing as Power. A stakeholder can have a small amount of Power in the capability of making and enforcing decisions, but they may be a trusted advisor to someone who does have that making, making their influence higher than their power.

Impact

Stakeholders can also be categorized by the level of impact the implemented project will have on them personally or on the business units they represent. Note that a stakeholder can be highly impacted by a project without having much influence over its direction, decisions, or implementation.

Impact is frequently categorized on a simple primary or secondary level, where primary stakeholders are those directly impacted by the project results, while secondary stakeholders are only indirectly impacted by the project results.

Importance

It is a good idea to categorize stakeholders as to their importance in the delivery of specific project outcomes or deliverables. For example, if the project is delivering an IT solution, certain technical staff such as a database administrator may be extremely important for the successful outcome of a project, while having little influence over the project and not being impacted by the project results very much. Note that a stakeholders importance can vary by project phase or deliverable.

Legitimacy

Stakeholders should be evaluated on their level of legitimacy in regards to the project goals. An evaluation of legitimacy is based on a generalized perception or assumption that the action of an entity are desirable, proper, or appropriate with some socially constructed system of norms, values, beliefs and definitions. So the project team will need to define what factors will convey levels of legitimacy for their analysis. But factors such as who is funding the effort, who is impacted by the effort, and who has control of specific assets needed to execute the project are common factors of legitimacy.

Power

Stakeholders have to be categorized by their level of power over the project. There is a reason that almost every Stakeholder Map, and the Salience Diagram, and virtually every other stakeholder analysis technique involves power along at least one of the dimensions. If you need a working definition of Power, try this one: The extent to which individuals or groups are able to persuade, induce or coerce others into following certain courses of action (Johnson & Scholes 1999). Power can be based on: coercion (based on force or threat), utilitarian (based on resource control or incentives offered), or normative (based on symbolic influences such as moral authority). As with importance, stakeholders can have different levels of power in different parts of the project, and in regards to different aspects of the project.

Urgency

Urgency is defined as the degree to which stakeholder claims call for immediate attention. [3] In general, there are two dimensions of urgency, a timeliness factor and an importance factor. A stakeholder requirement that does not have to be met NOW, but HAS to be met as some point, is still an Urgent need for that stakeholder. One important factor in evaluating the timeliness aspect of urgency is when has the claim/issue been raised? If the project scope has already been set, as solution defined, and development began; a urgent claim for a feature by a stakeholder my be assessed at a lower urgency level due the cost and difficulty of incorporating the request.

Prioritization

Once you have categorized your stakeholders (or at least their roles), you should then be able to begin prioritizing stakeholders. Stakeholders should be prioritized according to how critical they are in successfully delivering the expected project outcome. You should also generally prioritize stakeholders on how critical they are for successfully delivering specific project milestones or meeting specific goals.

What should the results be?

The results from a stakeholder analysis effort should make it possible for the project team to determine (to the greatest degree possible):

Triggers

Although Stakeholder Analysis should be an ongoing process during a project, there are specific triggers which should cause an immediate re-evaluation of certain stakeholders (if not all stakeholders). These triggers include: [6]

Risks

There are a number of risks that arise from a Stakeholder Analysis effort. They include:

Tips

Related Techniques

References

  1. BABOK Guide v2, Section 2.2 - Conduct Stakeholder Analysis. Pgs. 24-31
  2. Wikipedia Entry: Stakeholder Analysis
  3. Research Paper: A project lifecycle perspective on stakeholder influence strategies in global projects. Kirsi Aaltonen and Jaakko Kujala, Scandinavian Journal of Management (2010) 26, 381-397.
  4. BABOK Guide v2, Glossary: "Stakeholder Analysis", pg. 232
  5. Research Paper: Stakeholder Analysis in projects: Challenges in using current guidelines in the real world. Anna Lund Jepsen and Pernille Eskerod. 2008.
  6. Research Paper: Understanding Project Sociology by Modeling Stakeholders. Ian Alexander and Suzanne Robertson. 2003.

Related Resources