A project stakeholder is someone who gains or loses something (could be functionality, revenue, status, compliance with rules, and so on) as a result of the project. In other words, a stakeholder is much more than a product’s eventual "user."

A stakeholder can be:

• someone who finances the project
• someone whose skill is needed to build the product, such as a network specialist or a database expert
• an organization whose rules the project team must obey, such development standards
• an external organization that can influence project success, such as an environmental group or a competitor.

Given this wide and complex project environment, it helps to have some way of modelling the stakeholders and their differing involvements and needs.

One way to do this is using an onion diagram (see Figure 1). This deceptively simple looking model actually conceals a wealth of project information. First, it presents a view of the project that centres on what the project has to deliver. This is the “Product”. Next is the “Business System” which includes generic roles for the people or actors who operate and maintain the equipment and deliver its results, as well as any standard rules or procedures they use to operate it. These directly interacting roles don’t begin to exhaust the range of stakeholder responsibilities in a development project. Systems invariably operate in a “Business” that is outside the project’s control and includes the system plus any of its non operational beneficiaries. Normally, the people who benefit from the product work in the Business. Last we need to consider the wider environment, which includes the Business plus any other stakeholders who affect decisions we make about the system.

Figure 1. An onion model of stakeholder relationships.

In the Onion model, a dotted line is used to represent any relationships either between stakeholders or stakeholders and “rings”. For example; Operator operates the product and Political beneficiary has a relationship with the Financial Beneficiary (See Figure 1)

The model can also be used to show stakeholder importance. Supporting roles can be placed toward the bottom of the diagram, decision makers towards the top. Closeness to the centre indicates direct operational involvement. A solid icon shows the presence of a defined stakeholder role, while graying out (indicating insubstantiality) demonstrates absence of a role. Colours can also be used to show other information such as what department they come from.

First step is usually to do a quick analysis without the participation of the actual stakeholders. However statements on behalf of stakeholders are no more than assumptions which have to be proven by active stakeholder participation. Only the stakeholders themselves can prove the assumptions to be true by involvement in the project.

To use the onion model approach, you can start either with an empty set of circles or with typical roles already present. Either way, you ask stakeholders (in workshops or interviews) what their roles are, and you populate the model accordingly. Then you can investigate any roles that remain unfilled and ask if anyone knows who might fill roles in those areas. Finally, you can check for possible conflicts. Figure 3 shows part of a stakeholder analysis template that is available from www.volere.co.uk . This is a fairly comprehensive list of the types of stakeholders there are.

Figure 3: A fragment of a stakeholder analysis template.

The Volere template can be used to help discover missing stakeholders. The template approaches stakeholder discovery by asking the question: "What sorts of knowledge are we looking for?" leading to, "Who is the source of that knowledge?". The template provides a tool for recording stakeholders’ names and responsibilities and is especially useful when you have several different stakeholders concerned with the same knowledge or multiple stakeholders occupying the same role.

Once you have identified your stakeholders, prepare a matrix in which you rank stakeholders according to their stake in the process versus their influence (to rank their importance):

Two factors must be considered when mapping out stakeholder relationships. One factor consists in power defined as the ability to influence the actions of other stakeholders and to bring out the desired outcomes. The other factor is importance/urgency to the stakeholder of the project or the project goal.

If we also add in legitimacy, a rightful claim to be involved, we get 8 different stakeholder groups:

1.Dormant stakeholders (Power, no legitimacy and no urgency)
2.Discretionary stakeholders (Legitimacy, but no power and no urgency)
3.Demanding stakeholders (Urgency, but no legitimacy and no power)
4.Dominant stakeholders (Power and legitimacy, but no urgency)
5.Dangerous stakeholders (Power and urgency, but no legitimacy)
6.Dependent stakeholders (Legitimacy and urgency, but no power)
7.Definite stakeholders (Power, legitimacy and urgency)
8.Nonstakeholders (No power, no legitimacy and no urgency)

A stakeholder who has power but no legitimacy on the project (the project does not touch them) is dangerous, since they may not be initially be considered as a  stakeholder. They can impact the project if it suits their aims to interfere with other legitimate stakeholders regarding an unrelated concern.

Onion Model

One result of modelling project stakeholders this way is that some simple metrics can be examined. The number of circles and roles in a model indicates its size (And help determine the scale of communication activity).

Roles that aren’t filled by named persons aren’t going to serve the project. Conversely, a role that is filled with multiple people suggests at the very least a fine division of responsibilities; at worst, it can indicate that serious stakeholder conflicts are possible.

Another interesting metric is whether any stakeholders exist without defined relationships (shown as dashed lines in the onion diagram). At the very least, each stakeholder should have a legitimate interest in the product or connection with another stakeholder. Identifying interactions early in a project is often helpful.

Stakeholder roles in the "Business system" circle are directly involved with the product. These roles will relate directly with UML use case actors.  Any roles in the "Business system" circle that are not defined as actors could have been overlooked.

Power/Legitimacy/Urgency

All project communications have to include and address demanding and dangerous stakeholders, and try to win dominant, dependent and definite stakeholders.

The groups a project needs to cooperate with are the dominant and definitive stakeholders; their ownership of the activities has to be won.

The capacity of discretionary and of dependent stakeholders to participate needs to be built up.

Dormant stakeholders need to be brought on board.

Stakeholders identified as demanding and/or "dangerous" stakeholders; their impact on project results needs to be mitigated.

For all projects, appropriate participation of the necessary stakeholders directly influences your chance of success. The stakeholder model is guaranteed to change during your project’s lifetime, and these changes are likely to affect your stakeholder involvement. For this reason stakeholder analysis should be an iterative process done repeatedly throughout the course of a project since stages of the project will affect stakeholders, their process, and interests; i.e., stakeholders and their interests and views may evolve, new actors may appear on the scene, or central issues and stakes may shift over time. Doing a one shot, quick and dirty stakeholder analysis may put your project at risk.

Certain indicators signal the need to do some work on stakeholder involvement and revist your communication plan.

Role changes

Leavers and Joiners

Missing feedback loops

Categories: Methods | Stakeholders