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: 
“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:
- What individuals can best fill the stakeholder roles defined in the Stakeholder Identification process?
- Which stakeholders are important for project success?
- Which stakeholders represent potential barriers to project success?
- What are the different levels of stakeholder power, influence, interest, and legitimacy; as well as other stakeholder attributes so that stakeholders can participate in the project in the best way possible?
- What level of stakeholder engagement is best for each individual stakeholder?
- What is the relationship among various stakeholders and how might those relationships impact the project effort?
- Provide the information the project team needs to create and execute a Stakeholder Management effort.
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.
- The first is to provide the stakeholder information that underlies a project teams stakeholder management effort.
- 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.
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.
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:
- Active Opposition
- Passive Opposition
- Passive Support
- Active Support
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.
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.
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.
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.
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.
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.
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 is defined as “the degree to which stakeholder claims call for immediate attention”.  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.
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):
- Who the critical stakeholders are for the overall project
- Who are the critical stakeholders for different phases or aspects of the project
- How much and what kind of attention/information each stakeholder should get
- The best way to interact with each stakeholder
- Who are the stakeholders who need the most engagement and change in attitude to reduce the project risk. These become the most important targets of a Stakeholder Management process
- The identification of key risk areas in the project goals or solution space, where there are conflicting expectations from key or influential stakeholders.
- What are the success measures for the project in the opinion of each stakeholder? What will determine their level of satisfaction with the project results? What is their level of interest/importance for different project aspects?
- What are the relationships among the stakeholders. Which stakeholders are likely to be in conflict, or in a coalition.
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: 
- Role changes: If any stakeholder experiences a change in their role within the enterprise or project, they should be re-evaluated.
- Arrivals and Departures: If current stakeholder departs the firm, or if a new stakeholder is hired within an affected stakeholder group, the impact of the change should be evaluated.
- Scope Changes: Any change in scope should immediately trigger a re-evaluation of at least some of the stakeholders.
- Organization Structure Changes: Changes in the organization structure, especially in the organization chart, should trigger a re-evaluation of all stakeholders impacted by the changes. Org changes can influence power levels, resources controlled, decision-making and influence levels, and so much more.
There are a number of risks that arise from a Stakeholder Analysis effort. They include:
- An assumption that a Stakeholder Analysis effort early in the project successfully identified all necessary stakeholders. Stakeholder analysis efforts should be updated at a minimum at every key project milestone. If possible, a minimal stakeholder analysis effort should be a constant and ongoing part of a project.
- The project team may fail to keep abreast of shifting influence or importance levels as the project progresses. Remember that changes in scope or approach frequently mean changes in the importance (at least) of various stakeholders.
- Realistically, it may be inadvisable to put in writing that any stakeholder is “hostile” or a “potential barrier” (or similar terms) to the project goals, project team, or other stakeholders. Even verbal discussions can have unanticipated (and likely negative) impacts on the project teams effectiveness and careers. Like it not, sometimes honesty in a project can harm (or doom) your career.
- IMPORTANT NOTE: It is probable that a perfect stakeholder analysis effort is not possible, especially for complex projects. So always assume your findings and analysis are incomplete and look for missed stakeholders or impacts that need to be analyzed as the project progresses.
- Context Diagram
- Document Analysis
- Organization Modeling
- RASCI Matrix
- Stakeholder Maps
- Stakeholder Onion Diagram
- Stakeholder Radar Diagram
- Stakeholder Role Matrix
- Stakeholder Salience Diagram
- Survey / Questionnaire
- BABOK Guide v2, Section 2.2 – Conduct Stakeholder Analysis. Pgs. 24-31
- Wikipedia Entry: Stakeholder Analysis
- 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.
- BABOK Guide v2, Glossary – “Stakeholder Analysis”, pg. 232
- Research Paper: Stakeholder Analysis in projects: Challenges in using current guidelines in the real world. Anna Lund Jepsen and Pernille Eskerod. 2008.
- Research Paper: Understanding Project Sociology by Modeling Stakeholders. Ian Alexander and Suzanne Robertson. 2003.
- Article: Stakeholder Analysis – Winning Support for Your Projects. Rachel Thompson. On the Mindtools.com web site.
- Article Series: What is Stakeholder Analysis? S. Babou. On the PMHut.com web site. 2008.
- Article: How to integrate stakeholder analysis information into your project. Lauri Elliott. On the TechRepublic web site. 2001.
- Blog Post: BA Stories: Warning – Stakeholder Analysis is Not Just About Discovering Requirements (BABOK 2.2). Laura Brandenburg. On the Bridging the Gap blog. 2011.