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 and Document Analysis. 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?

On this page:

• Stakeholder’s Influence in Different Project Aspects
• Creating the Stakeholder Register
• Analysing and Prioritising Stakeholders

Well the PMBOK® Guide does suggest studying the Project Charter, the Business Documents 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.

Stakeholder’s Influence in Different Project Aspects

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.

Creating the Stakeholder Register

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 mapping / representation – power / interest, power / influence and influence / impact grids, as well as the three-dimensional stakeholder cube and Salience Diagram. These are all ways of prioritizing stakeholders, using a variety of characteristics.

Analysing and Prioritising Stakeholders

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.

Velopi’s project management professional (PMP)^® training courses cover stakeholder management. If this area is intriguing for you, you might consider one of our project management certification courses.