Analysing Stakeholders

12 June, 2014

The Project Management Institute’s Guide to the Project Management Body of Knowledge (PMBOK® Guide) is precisely that – a guide. It lists tools and techniques that are recommended as best practices for project management, but they are not explained in any great detail. For instance, the PMBOK® Guide recommends that we identify stakeholders in the initiating process group and this makes sense. If we know who may be affected, or who may affect the project, we are in a good position to deal with them.

But how do we do this? Referring to the PMBOK® Guide offers us “Stakeholder Analysis”, “Expert Judgement” and “Meetings”. These tools and techniques focus on analysing the stakeholders we know about, rather than identifying them in the first place. So where do we find our project stakeholders?

Well the PMBOK® Guide does suggest studying the Project Charter and Organizational Process Assets which may include the Stakeholder Registers from prior projects. We might find many of our stakeholders there, but for a more comprehensive search, using elements of SWOT Analysis might help. Strengths, Weaknesses, Opportunities and Threats might seem unlikely categories to file stakeholders in. But, the division is useful: Strengths and Weaknesses are internal to the organisation, while Opportunities and Threats are external. Considering stakeholders outside the project team, but within the organisation as a whole can reveal certain people we might not have considered previously – functional line managers for instance, or the purchasing department. Going outside the organization brings us to customers, suppliers, end users and regulatory bodies.

Returning to the project team, we need to look at how specific aspects of the project can be upset by (or cause upset to) stakeholders. The PMBOK® Guide does offer useful guidance now – the Knowledge Areas. Consider them in turn: who can influence the scope of the project? We might start worrying about sales and marketing people, or even market trends (to go back outside for a moment). How about the schedule? Lack of resources for the team is a big factor here. The budget will see the finance department come to light. If we are lucky, the Project Sponsor will handle our project finances.

Quality, risk and procurement will also identify people or organisations that we need to factor into our stakeholder analysis. But do not forget communications – we may need help from the IT department to set up some of our communications technologies.

Looking internally and externally, as well as considering the project from different perspectives, should result in a reasonably comprehensive Stakeholder Register. But now we are supposed to analyse them and again the PMBOK® Guide lets us down. It does introduce stakeholder maps – power / interest, power / influence and influence / impact grids, as well as the three dimensional Salience Diagram. These are all ways of prioritizing stakeholders, using a variety of characteristics. However, where do you place the stakeholders on the grid?

A useful lesson can be taken from agile project estimation. An agile pioneer, named Mike Cohn, has come up with a method of estimating that separates size from duration. He observed that human beings are extremely good at comparing things (up to an order of magnitude). So if we see two people walking side by side, we can tell immediately which of them is taller. However, if we are asked to estimate their heights, we usually get it wrong. Similarly, trying to rate our stakeholders in terms of factors like influence and power is a bit like comparing apples and oranges.

However, take one stakeholder at a time and rate that project stakeholder in terms of just one factor – power, interest, influence, impact, urgency, or legitimacy. Use a scale from one to ten. The first one will be really difficult – it might be just a guess. However, the second and subsequent project stakeholders will be easier, because you can now compare them. Is the second project stakeholder more powerful than the first? Is that stakeholder slightly more powerful, or significantly so? Soon this exercise will give you a “feel” for what the numbers between one and ten signify. At the end of the exercise, you will have the stakeholders ordered in terms of one axis (if you are using one of the two-dimensional grids). Now we need to carry out the same exercise along the other axis.

If you imagine the grid at this stage being an abacas with all the beads pressed against one side, and each row representing one or more stakeholders, our goal now is to slide those beads across the abacas to reflect how the stakeholder compares when measured against the second factor. At the end of the exercise, each stakeholder should be positioned somewhere on the grid. You might not have them in exactly the right places, but you will have them correct relative to each other. It’s a technique that is worth a go – it can be surprisingly effective.

Velopi’s project management training courses cover stakeholder management. If this area is intriguing for you, you might consider one of our project management certification courses that are held in Dublin, Cork, Limerick and Galway. Find out more by visiting our training page or by contacting us directly.

By Velopi Seamus Collins

© 2018 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital