Point Prox - Project Management

Project management tools, skills, and processes




  • Home
  • Tutorials
    • Stakeholder Analysis
    • Project Scheduling
  • Posts
    • Agile Project Management
    • Project Scheduling
    • Project Risk Management
    • Project Stakeholders
    • Requirements Management
    • General PM
  • About
    • About Point Prox
    • About Alvin Lewis
    • Contact Us
You are here: Home / Featured / Stakeholder Analysis and the Salience Model – Part 2: Using the Model

Stakeholder Analysis and the Salience Model – Part 2: Using the Model

January 19, 2017 by Alvin Lewis 3 Comments

Illustration of the categories of the Salience Model as a Venn diagram.Using the Salience Model will be the subject of this second part exploration of using the technique in your stakeholder analysis practice. The theory and background is covered in Stakeholder Analysis and the Salience Model – Part 1: What is the Model. The combination of the analysis of power, legitimacy, and urgency of a proposed stakeholder yields their salience. Based on their salience we can determine the quality of interaction that the management of a project needs to apply to competing stakeholder claims or relationships. Succinct said: salience informs the project of which entities have the greatest ability to affect the outcome of the project, and the character of that effect may take.
This second part of the article will cover how to use the technique in practice.
Determining salience entails going through the list of proposed stakeholders and deciding if they possess power, legitimacy, or urgency attributes. The results of this analysis will tell you the level salience (impact) and category (character) for the stakeholder. To more fully understand how this works it helps to visualize these characteristics on a Venn Diagram:

Salience Model Venn Diagram with Category Descriptions and Relationships
Salience Model Venn Diagram with Category Descriptions

 

What Level are You Up To?

There are four levels which represent the amount of impact that a stakeholder will likely have on a project. The more attributes are possessed the more important they will be to the success of the project. The four levels represent all the possible values from no attributes to all attributes.
Salience accumulates as a stakeholder possesses increasing number of attributes. These levels are characterized as:

  • Non-Stakeholders – These entities really aren’t stakeholders as they possess none of the attributes of power, legitimacy, or urgency. As a project manager, it is a good idea to be aware of them as at some point, during the identification process, they were thought important enough to have been at least mentioned. Otherwise, they can be safely ignored as part of risk, communications, and stakeholder management planning.
  • Latent – These entities possess only one of the three potential attributes. As such, they will be unlikely to affect any impact and likely to be uninterested in project. Similar to non-stakeholders, a latent stakeholder need not occupy much of your time as a project manager. None the less, they should be at least kept in mind as they do have a relationship to the project, albeit one of little salience.
  • Expectant – When a stakeholder possesses two of the three attributes they are said to be expectant as they will anticipate influencing the project. Unlike the latent level, an expectant stakeholder becomes active and the quantity of effort applied to manage the expectations of such entities must be increased accordingly. Additionally, there is a possibility that an expectant entity will be looking for ways to achieve the missing third salience attribute. Specific understanding and planning are recommended for this level of stakeholding entity.
  • Definitive – When an entity possesses all three of the attributes they are then a definitive stakeholder and therefore highly salient and influential to the project. In preparing your risk, stakeholder, and communications management plans the needs of definitive stakeholders must be explicitly elucidated.

The Character Is in the Category

In addition to the four levels of salience, there are seven intersecting categories on the Venn Diagram. An eighth category possessing no attributes, representing “non-stakeholders”, is shown outside the diagram. The categories, represented by the intersection of possessed attributes, identify the character of the entity’s relationship to the project. Clues are provided by the salience category which indicates how the entity will need to be managed.
The salience categories are:

Category
Attributes
Description

Dormant

✓ Power

The dormant stakeholder possesses power in relationship to the project but has neither a legitimate interest or any urgent claim. An example might be a senior executive of a part of the company not directly affected by the project but who has expressed interest in the effort. They could exercise their power but have neither cause or need to do so. Dormant stakeholders need watching as the acquisition of another attribute can make them active in a dominant or dangerous way.

Discretionary

✓ Legitimacy

Typically, a discretionary stakeholder has a latent “pro bono” or charity relationship to a project. They have no power to affect a claim and no issues that require immediate attention. An example might be a local soup kitchen which is a favorite charity for the sponsoring company that is rolling out a large restaurant management system. Unless the entity becomes active or the project feels there is a benefit to performing charity work, the project need not consider a discretionary stakeholder too deeply.

Demanding

✓ Urgency

A demanding stakeholder feels that their issues have a degree of urgency in relation to a project. However, their claims have no validity and they do not possess the power attribute required to push their agenda forward. At worst, they are a likely little more than a pest. An example might be an employee that habitually promotes a particular business process that was legitimately rejected in favor of a process that will be implemented by the project. The demanding entity bears watching and potentially tolerance but little effort on the part of the project manager.

Dominant

✓ Power

✓ Legitimacy

With the combination of power and a legitimate relationship to a project a dominant stakeholder requires a lot of attention. An example of a dominant stakeholder might be a union that represents primary users of the software produced where the project does not change their contractual or work relations to the company. The question with this type of entity is if they choose to exercise their power to affect their legitimate relationship to a project they could become an important stakeholder. If, in the example above, the union feels that it has a critical issue with the adoption of a new feature on the project they already have the power and legitimacy to make their requirements enacted.

Dangerous

✓ Power

✓ Urgency

A stakeholder can affect power for urgent claims that have no legitimate claim on the project is said to be dangerous. This type of stakeholder is in a position to extort changes or concessions from a project of which they have no valid claim. If the power used is coercive then there is a chance of their activities being violent in nature. An example of a dangerous stakeholder might be a vendor that threatens members of a project team to be awarded a contract to provide services to the project. Due to the potentially disruptive nature of a dangerous stakeholder, when identified, planning is critical to mitigating potential impact of their actions.

Dependent

✓ Legitimacy

✓ Urgency

While possessing legitimate claims that have a degree of urgency, a dependent stakeholder has no power to be able to affect an action towards these claims. As such, they are dependent on another entity that has some power in relation to the project. An example might be customers that own a version of software that will be made obsolete by a new project output. Note that since there is a legitimate urgency to this entity’s claim it is attractive for other stakeholders who possesses power to align with them thereby allowing for their claims to significantly influence the project. Contingency and risk planning are in order with the dependent stakeholder.

Definitive

✓ Power

✓ Legitimacy

✓ Urgency

Possessing all three of the salience attributes, a definitive stakeholder can affect their will on the project. The management of these entities’ requirements and issues will be critical to the success of a project. An example of such a stakeholder would be the management of departments who have sponsored the project. Care should and must be taken in stakeholder and communications planning.

Non-Stakeholder

 

As these entities have no salience they are not stakeholders on the project. Other than being aware of them they can safely be ignored for planning purposes.

 

How to Put it All Together

The primary input for Salience Model analysis is a list of proposed stakeholders gleaned from the project charter, discussions with sponsors and identified participants, artifacts from previous similar projects, or other sources. When first identifying potential stakeholders, it is best to cast a wide net, erring on the side of inclusion. After that has been completed disciplined analysis techniques should be used to identify non-stakeholders and understand the impact of other entities on the project. The Salience Model is a powerful tool to determine “Who and What Really Counts”, however it is recommended that other tests be employed as well. There are a number or other techniques recommended in the PMBOK Guide .
The first thing to do is to go through the Stakeholder Register and determine whether each entity list has any of the attributes of power, legitimacy, or urgency. The initial analysis should be based on the frame of reference of the product output of the project, i.e. whatever it is that is being built by the project effort.
As we know, one of the things that never changes on a software project is change. That everything is mercurial indicates that salience assessments are dynamic too. The values of the attributes will change and should be considered at specific times during the execution of the project. As part of initial planning, salience and other stakeholder analysis should be considered for major milestones in the project. Part of stakeholder, risk, and communications planning should note stakeholders that are likely to change their character so they can be monitored correctly.

Salience Model Worksheet Screenshot Shows How To Calculate Salience
Salience Model Worksheet Screenshot

 

Download the Salience Model worksheet and we’ll walk through the analysis. The sheet is a stripped-down stakeholder register. You should include the columns needed for salience analysis in whatever stakeholder register you currently use. The spreadsheet is structured as follows:

The columns ‘C’, ‘D’, and ‘E’ are used to record your assessment of the stakeholder’s salience attributes of Power, Legitimacy, and Urgency, respectively. The cells are restricted to the values ‘Y’ or ‘N’ to determine the salience level or category.

Column ‘F’ calculates the salience level based on the attributes entered. It references a range of cells on the “Lookup Values” sheet.

Column ‘G’ calculates the salience category according to the attributes entered. Like the “Salience Level” column, the formula in the “Salience Category” column looks up the category from a range of cells in the “Lookup Values” spreadsheet. These formulas will check to see that all of the values are correctly entered before performing the lookup.

If you are going to use the formulas in your own stakeholder register, make sure you have a sheet named “Lookup Values” in the workbook configured correctly. You will likely need to change the formulas to reference the correct attribute columns if they are not the same as on the example download.

Wrapping Up the Salience Model

That covers the salience model and its usage sufficient for practice as a project manager. As mentioned above, salience analysis should be a part of your overall stakeholder analysis and not the only tool you use. Getting your stakeholder management correct is critical to the success of your project. It is not just managed as part of the Stakeholder Management process group but incorporated into the Communions and Risk process groups. We’ll cover these techniques in future posts.

References:

  • Ronald K. Mitchell, Bradley R. Agle, and Donna J. Wood: Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts
  • Mark C. Suchman: Managing Legitimacy: Strategic and Institutional Approaches

Filed Under: Stakeholders Tagged With: Project Initiating, Salience, Salience Model, Stakeholder Analysis, Stakeholder Class, Stakeholder Identification, Stakeholder Management, Stakeholder Mapping, Stakeholder Salience Theory

Comments

  1. Paul Hymans says

    November 13, 2019 at 12:37 pm

    An excellent reference and guide to using the model. Thank you

    Reply
    • admin says

      November 13, 2019 at 1:28 pm

      Thanks Paul. Much appreciated.

      Reply
  2. Fernando Chavez-Finol says

    August 23, 2018 at 4:08 pm

    Thanks

    Reply

Leave a Reply to admin Cancel reply

Your email address will not be published. Required fields are marked *




  • Email
  • Google+
  • LinkedIn
  • Phone
  • RSS
  • YouTube

Point Prox Newsletter

Sign up for free newsletter

Never miss another post!

Tags

Agile Requirements Calendar Management Creating a Project Schedule Effort Driven Scheduling Excel Tools Excel Utilities Gantt Chart Learning Microsoft Project Learning Microsoft Project 2016 Microsoft 2016 Project Tutorials Microsoft Excel Microsoft Project Microsoft Project Basics Microsoft Project Tutorial MS Project 2016 Product Backlog Project Initiating Project Management Tools Project Planning Basics Project Planning Fundamentals Project Requirements Management Project Risk Management Project Scheduling Project Scheduling Basics Project Scheduling Process Project Scheduling Skills Project Scheduling Task Types Project Scheduling Tools Project Task Types Resource Planning Risk Risk Analysis Risk Management Risk Management Techniques Salience Salience Model Scrum Software Engineering Stakeholder Analysis Stakeholder Class Stakeholder Identification Stakeholder Management Stakeholder Mapping Stakeholder Salience Theory Task Types

Contact Us
About Point Prox
About Alvin Lewis

Terms of Use
Privacy Statement

Point Prox - Project Management Logo

© Copyright 2018 Point Prox Inc · All Rights Reserved