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 customers 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 projects 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 customers organisation structure is essential. You should also use the customers intranet as well as the internet. Where identified stakeholders are external to the customers 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 herefor an example). Keep drilling down and refining your diagram until you can start listing actual peoples names against each group or sub-group. Its better to identify as many as you can, as you can always eliminate them later. Its far worse to go through the project not having identified a key stakeholder. Projects have failed for this reason. Stage 2: Categorise Its 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)

Name P. Delaney D. Collins M. Kraus

Group Executive management

Function

Notes Project sponsor with authority to approve and cancel the project. Authority to approve any HR requirements SME regarding HR processes.

Decision maker

Human resources

Decision maker

Human resources Equal Opportunities Board ABC Software Testing

Information provider

X. Bosch

Regulatory

Government contact regarding equal opportunities legislation.

F. OToole

Implementer

Test manager.

T. Vincent B. Gaston

Team A

End user

End user of new processes and software.

Training and Development

Post-implementation support

Software trainer.

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 BAs 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 thats 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):