An overview of stakeholder analysis

I have been asked to write a little more about stakeholders. In an earlier post I talked about why stakeholder management is important, but before you can have a stakeholder management plan you have to understand your stakeholders and for that you need to do stakeholder analysis.

You could say that stakeholder analysis is a structured approach to identifying and understanding the stakeholders related to a project.

Stakeholder management, on the other hand, would determine how to engage the stakeholders and the engagement itself.

You will certainly find variations of this definition.

Timing
Your analysis can begin as soon as you start to work on the business architecture. Stakeholder management is important throughout the customer’s change initiative, not just during the project to develop the To Be system. This initiative starts when the customer starts their strategy analysis and the stakeholders need to be identified as early as that.

Since your analysis will be the input into stakeholder management, it needs to be complete in time for the management plan to be produced. Prior to a system development project’s being identified, the lead business analyst will probably manage the stakeholders. Once a development project is identified, the project manager will probably take over that duty. You are likely, therefore, to need to do two main iterations of stakeholder analysis: one right at the beginning of business analysis and another before documentation of high level system requirements finishes.

Participants
The drivers of the analysis are the business analyst and the project manager. The PM during the business architecture / information architecture / scope definition phases of the change initiative would be the analysis team manager. It is likely to be a different person during the system development phase.

Other key participants could be subject matter experts (SMEs), project sponsors and team leaders. Basically, anyone you feel would be able to provide useful input.

Sources of knowledge
You will get information about stakeholders largely from the participants themselves, but you should also use any sources you can. An understanding of the customer’s organisation structure is essential. You should also use the customer’s intranet as well as the internet. Where identified stakeholders are external to the customer’s organisation, the websites of those external bodies may be useful.

Stage 1: Identify
In “Who holds the stake?“, I listed some of the stakeholders you might have to deal with. To save you the trouble of looking back, here is the list again:

• Owners (e.g., individual, shareholders, even the public)
• Partners (e.g., other companies providing related services)
• Department heads
• Managers
• Staff (e.g., end users)
• Regulatory bodies
• Suppliers
• Customers
• Competitors

This is by no means a definitive list and there may be other ways of listing potential stakeholders.

So how do you come up with your list? Simply by getting in a room with people and brainstorming on a white board. Start by listing groups of people (as above). Once you think you have exhausted all possibilities, draw a diagram to organise the groups (click here for an example). Keep drilling down and refining your diagram until you can start listing actual people’s names against each group or sub-group.

It’s better to identify as many as you can, as you can always eliminate them later. It’s far worse to go through the project not having identified a key stakeholder. Projects have failed for this reason.

Stage 2: Categorise
It’s a good idea to put some structure on your list of names before analysing each one. There are many ways to categorise your stakeholders and you may come up with a way that suits you best. Bear in mind, however, that some people may have more than one function on the project. Your attempt to categorise names may become quite complicated if you attempt to handle every function a person performs. It is probably better if you simply categorise people according to their main function on the project.

Examples of categories you could use are:

• Decision makers (e.g., sponsors, artefect approvers)
• Information providers (e.g., SMEs)
• Regulatory(e.g., legal body, COE)
• Implementers (e.g., developers, testers)
• End users
• Post-implementation support (e.g., trainers, managers)

Those categories might be of interest to the project manager. However, the business analyst may have a different view of the stakeholders (in relation the artefacts to be produced), so the BA might categorise them as follows:

• Artefact reviewers
• Artefact approvers
• Information providers

From the BA’s perspective, an individual might belong to one or more of these categories.

Stage 3: Analyse
Categorising the stakeholders gives you some focus so you can do the actual analysis. The analysis may only involve a simple matrix for each stakeholder, but may involve a lot of discussion and note taking, depending on what that matrix reveals.

Stakeholder Analysis Matrix

In the matrix above, person A has a lot of interest in the change initiative, but has little influence – perhaps one of our end users would fit this description.

Person B, on the other hand, has little interest but a lot of influence – this could be the PA to the CEO of the company.

Person C has a lot of both interest and influence – I imagine our project sponsor would fit in here.

Person D has a lot of interest and moderate influence – perhaps a department head?

We have also colour-coded the matrix to show how supportive of the change initiative each person is. Green meaning very supportive, amber meaning neutral and red meaning hostile. You might choose a fourth colour to distinguish between people who are supportive but not actively so and those who actively champion the change.

Regardless of where someone fits on the matrix and how supportive they are, we will need to make further notes:

• What is their motivation?
• What are their expectations?
• What do we expect of them?
• Where are they?
• How expert are they at what they do?
• What is their availability?

How you then engage with each stakeholder is what forms your stakeholder management plan and that’s another story.

Stage 4: Rinse and repeat
Your first pass through your stakeholder analysis is done once the PM is ready to put together the stakeholder management plan. However, you will need to revise it if stakeholders come or go, or if they change their function within the change initiative.

One final note: bear in mind that the stakeholder analysis may contain sensitive information and it should be treated sensitively.

Update (28th May 2009):
The Project Management Hut has some excellent articles on this subject. Pop over and have a look.