An Overview of Stakeholder Analysis
By Declan Chellar
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.
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.
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 Your Stakeholders
Below is a list of some of the stakeholders you might have to deal with:
- Owners (e.g., individual, shareholders, even the public)
- Partners (e.g., other companies providing related services)
- Department heads
- Staff (e.g., end users)
- Regulatory bodies
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 Your Stakholders
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)
|P. Delaney||Executive management||Decision maker||Project sponsor with authority to approve and cancel the project.|
|D. Collins||Human resources||Decision maker||Authority to approve any HR requirements|
|M. Kraus||Human resources||Information provider||SME regarding HR processes.|
|X. Bosch||Equal Opportunities Board||Regulatory||Government contact regarding equal opportunities legislation.|
|F. O’Toole||ABC Software Testing||Implementer||Test manager.|
|T. Vincent||Team A||End user||End user of new processes and software.|
|B. Gaston||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 BA’s perspective, an individual might belong to one or more of these categories.
Stage 3: Analyse Your Stakeholders
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.
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.
Declan Chellar is a freelance consultant based in the European Union. He provides consultancy on Business Process Management (BPM) projects (particularly those using Pegasystems’ PRPC). He has worked in IT since 1996 and primarily as an analyst since 1998 for companies such as Electronic Data Systems, Capgemini and Knowledge Rules. Declan’s blog can be found at http://www.chellar.com/blog/.