A FRAMEWORK FOR PROJECT STAKEHOLDER ANALYSIS

As mentioned, project stakeholder analysis consists of three steps which are represented in Figure 4.1.

Figure 4.1 A framework for project stakeholder analysis

PROJECT STAKEHOLDER IDENTIFICATION

The starting point of the stakeholder analysis is to identify all individuals and groups who can affect or may be affected by the project process or the project deliverables. Both current stakeholders and potential stakeholders should be identified. The constellation of stakeholders typically is not well delimited at the beginning of project. Therefore, the identification process should be repeated several times during the project.

All individuals and representatives for entities who perceive themselves as stakeholders for the project at hand are stakeholders. Notice that it is not your perception of who is affected that counts but that of the stakeholder. if you think a group of individuals will not be affected by the project, and the individuals do not agree, you need to change their perception if you want to remove them as stakeholders. You cannot just dismiss their perception. The identification process should build a common understanding of who are stakeholders among the persons conducting it. The information should be stored for later use in a Project Stakeholder Register. The format of the stakeholder register can vary. it can be a simple collection of post-it notes with a stakeholder name noted in handwriting on each, a list of stakeholders with names and contact information, or a fully developed iT database with detailed and structured information about each stakeholder. The size and complexity of the project at hand, the number of people involved in project stakeholder management, the culture of the base organization and the administrative resources available will all help you decide on the appropriate medium for the stakeholder register.

There are several ways of identifying the project stakeholders:

• ask project team members to list stakeholders in their specific areas of expertise;

• think through the whole life cycle of the investment of which the project is a part, for example the life cycle of a new product;

• ask other members of the project organization, for example the project owner;

• use general lists or checklists of stakeholders, that can be found for example in the project management standards within the company or in the project management community;

• check stakeholder registers from similar projects for inspiration;

• ask project stakeholders you have already identified to identify more stakeholders;

• invite experts within or outside the base organization to validate the list of stakeholders and offer suggestions for any missing stakeholders.

The number of stakeholders may seem infinite and you risk wasting time on identifying too many stakeholders and even becoming paralyzed by the number of people and groups that you need to consider. Our experience, however, tells us that it is more common for organizations to identify too few project stakeholders than too many. A long stakeholder list may be difficult to overview and handle. Current literature suggests that the stakeholders should be grouped. One suggestion is that the final list should consist of six to 15 groups of stakeholders (Bradley 2006).

Stakeholders that are likely to share the same characteristics in relation to the project can be aggregated into a single group. As mentioned in the second chapter, the choice of level of stakeholder (dis)aggregation is a major challenge. It may be practical to work with groups but you must acknowledge that each person involved in the project is a separate stakeholder and it may, therefore, be relevant to treat stakeholders at the individual level. For example, employees belonging to the same employee group may be treated as a group. However, if one of these employees has a significant influence within the group, it may be a good idea to engage differently with this person. stakeholder differences may not be apparent at first glance. Therefore, it is important to realise that whilst the first version of the stakeholder list may contain formal groups such as ‘department XX’ or ‘the customer’ as stakeholders, later versions should be more fine-tuned and based on the next step in the stakeholder analysis, the stakeholder assessment.

Stakeholders may be entities rather than individuals. Examples of non-personal stakeholders are ‘the community’, ‘the union’ or even ‘the environment’. The media can also be an important group of non-personal stakeholders that potentially may help or harm the project. Stakeholder labels such as ‘the union’ may be sufficient for the stakeholder assessment process. When engaging with these stakeholders you will be talking with individuals and it is important to clarify who these people are.

PROJECT STAKEHOLDER ASSESSMENT

The project stakeholder assessment must produce various types of insights. First, you need to clarify the contributions needed (if any) from each stakeholder. Secondly, you have to get an understanding of each stakeholder in terms of the benefits that the stakeholder will value in terms of project outcomes as well as their concerns regarding potential disbenefits and costs. Thirdly, the assessment should give insights into each stakeholder’s potentials to ‘harm’ and ‘help’ the project. Finally, you may need a more fine-grained analysis for some issues. In addition, you will need to consider how to create input needed for the assessment.

Assessing each stakeholder’s harm and help potentials

Stakeholders have different potential to (1) contribute to the project success (in short: ‘help potential’); and (2) threaten the project success (in short: ‘harm potential’). The potential is determined by the stakeholder’s capacity and opportunity to contribute to or threaten the project (Savage et al. 1991). Stakeholders who have many resources that can be used to support project progress have a large help potential. Resources should be broadly understood. They can be in the form of moral support, manpower or material resources. Harm potential implies the ability to stop the project or hinder its progress. This can involve withholding resources or damaging the project image. The more dependent the project is on the stakeholder, the more harm potential.

The help potential and the harm potential should not be seen as two ends of a scale. A project stakeholder controlling important contributions has both a help and a harm potential while a project stakeholder who can offer important contributions that can also be offered by other stakeholders has a considerable help potential but no harm potential. If two independent organizations could take on the role as main supplier, they both have high help potential and low harm potential. If there is only one possible supplier, however, the harm potential of this supplier will be high. You should notice that the harm and help potentials may change during the project. A project stakeholder who has low harm potential at the beginning of the project may well gain in harm potential once the project has started because the interdependency between the project and the stakeholder typically will grow so that replacing that stakeholder (if need be) will involve higher costs and more effort. The same dynamic is often seen for the help potential. As project specific knowledge grows, the help potential of a given stakeholder becomes higher than at the outset of the project.

The help and the harm potentials must be assessed for specific project phases and for special issues in the project. Examples of issues could be the determination of scope, stop-go decisions and selection of project team members. Each stakeholder can be categorized as having ‘low/high help potential’ and ‘low/high harm potential’. In total there are four possible positions for each stakeholder for each issue. We have chosen to label these stakeholders as follows: Resourceful, Key Player, Show Stopper and Marginal. The Resourceful has help potential and thus controls resources that the project can take advantage of. The Show Stopper has low help potential and high harm potential and thus ability to stop or hinder the project but no resources for the project. The Key Player has both help and harm potential and is accordingly important to the project both in terms of relevant resources and ability to harm the project, hence the name: Key Player. Finally, stakeholders with low help and low harm potential are not significant for the project and have, therefore, been labelled Marginal. It is important to remember that Marginals cannot be completely disregarded. They are not able to affect the project but if they can be affected by the project they are, nonetheless, stakeholders. A stakeholder who is able and willing to form coalitions with other stakeholders may be able to increase his or her help potential, harm potential or both.

Figure 4.3 shows the four types of stakeholders and their harm and help potentials. Remember that potentials may change across the project course. In the execution phase, one end user out of a number of end users willing to participate in testing the product can be categorized as Resourceful – he or she can easily be substituted by another end user and is therefore not able to harm the project – while a testing expert who cannot (easily) be replaced will be categorized as a Key Player. In another phase these stakeholders will both be categorized as Marginal.

Figure 4.3 Project Stakeholder Potential Matrix

Source: Inspired by Savage et al. 1991:65

You may assess the help and harm potentials using the technique Scenario Developments (Freeman, Harrison and Wicks 2007). Assessment of a project stakeholder’s help potential can be done by imagining ‘a best of all worlds’ scenario in relation to the particular stakeholder’s possible contributions to the project. In the same way, the project stakeholder’s harm potential relates to ‘a worst of all worlds’ scenario as regards how the stakeholder can be expected to behave in relation to the project.

The questions below can help assessing each stakeholder’s capacity, opportunity and willingness to help or respectively harm the project (Savage et al. 1991):

• Does the stakeholder control key resources needed by the project?

• Is the stakeholder likely to take supportive action? To take non-supportive action? Or not to take any action?

• Is the stakeholder likely to form coalitions with other project stakeholders? With members of the project organization? Or not likely to form any coalitions?

To answer the last question, you can use network analysis to assess the relationships of the stakeholder. You may make a simple analysis by drawing a Stakeholder Management Web for each important stakeholder (Ackermann and Eden 2011). The stakeholder in question (the focal stakeholder) is placed at the centre of the web and related persons and entities are drawn in a web around the stakeholder. In the web the relationships are split into two types: the power base reflecting the possibility to help or harm and the base of interest reflecting requirements and wishes of the focal stakeholder and how these may be connected to requirements and wishes of other individuals or organizations. Figure 4.4 illustrates a Stakeholder Management Web for a supplier representative.

Figure 4.4 Stakeholder Management Web example

Source: Inspired by Ackermann and Eden 2011

The base of interest consists of the direct interests (requirements and wishes) of the focal stakeholder as well as the relevant interests of others whom he or she is related to. If interests are supported by others the interest and thereby the motivation to act will be stronger. The same picture applies to the power base of the stakeholder. Persons with a large web of power have more ability to help or harm than persons with only a limited power base. In the example presented in Figure 4.4 the supplier has an interest in delivering to the project. This is supported by his boss because delivering will result in benefits in the form of profit and esteem. Delivering is also supported by a colleague who has an interest in having a good relationship with the customer. The supplier has some power in negotiations with the customer (the project representative) because the deliverance is superior to the deliverances of other suppliers – but the existence of other alternatives weaken the power base and it may be deteriorated if the other suppliers augment their offer or lower their price. The power base is, however, strengthened by a direct relationship between the boss of the supplier and the decision maker in the project. In sum, the supplier has a large help potential and a medium to small harm potential.

The help and harm potentials of the stakeholders can be added to the Stakeholder Register as displayed in Figure 4.5.

Stakeholder	……	Stakeholder potentials Low/high
		To help	To harm
Customer X	…	High – the customer’s experience and knowledge is of great value.	High – if contract is not signed, the project will not be started.
R&D department	…	High – the department has skilled staff with relevant experience.	High – the product cannot be developed if the right staff is not allocated at the right time.
Supplier Y		High – the supplier can deliver what we need.	Low – we can substitute this supplier with other suppliers.

Figure 4.5 Example of help and harm potentials in a Stakeholder Register

Additional tools

To create a more fine-grained understanding of your stakeholders you may apply additional tools in your analysis of the stakeholders.

McElroy and Mills (2003) suggest that you create a Stakeholder Commitment Matrix containing the commitment (or attitude strength and direction) that each stakeholder holds towards the project as well as the commitment needed for project success at a given point in time. The possible states of commitment are Active Opposition, Passive Opposition, Neutral, Passive Support and Active Support. See an example of a Stakeholder Commitment Matrix in Figure 4.6.

The Stakeholder Commitment Matrix clearly shows where to focus the management efforts. Working with the Commitment Matrix enhances your awareness of the different levels of commitment needed of the stakeholders. It also highlights that it may not be necessary that all the stakeholders can be classified as Actively Supporting the project.

Note: X = current position, O = necessary/wanted position by the project

Figure 4.6 Stakeholder Commitment Matrix with example

Source: Based on McElroy and Mills 2003

You may also assess each stakeholder’s level of information concerning the project in combination with his or her attitude towards the project and place the stakeholder in an Attitude–Information Grid. Each stakeholder can be categorized into one of four categories: (I) Positive Informed; (II) Positive Uninformed; (III) Negative Uninformed; and (IV) Negative Informed. Figure 4.7 shows the grid. This assessment may help you determine which stakeholders you need to try to influence and gives a hint on how to influence them.

The underlying idea in the framework is that a stakeholder who is negative, but at the same time only has little information about the project (quadrant III), needs to be treated differently than a negative stakeholder who has a detailed knowledge about the project (quadrant IV). An example of a negative, well-informed stakeholder could be a grassroots organization which is strongly against the project. The attitude as well as the information level can be assessed in more detail by using a system of co-ordinates instead of a 2×2 grid if you find it valuable for your stakeholder management planning.

Figure 4.7 Attitude–Information Grid

GENERATING INPUT FOR THE ASSESSMENT

The stakeholder analysis tools presented in the above all assume that you familiarize yourself with the stakeholders and their characteristics in terms of requirements, wishes, concerns as well as their relationships with the other project stakeholders and their capabilities to help and harm the project. But how do you do this?

Essentially there are three ways of generating the necessary input for the assessment:

1. create primary data;

2. collect secondary data;

3. make assumptions.

Primary data are data created for the specific purpose which in this case is making the stakeholder assessment in the project at hand. You may create primary data in interactions with the project stakeholders or by observing them. Both these ways of creating data can be undertaken in workshops, meetings, interviews, e-mails, questionnaires and other forms of communication.

Secondary data has been made for other purposes and is information already available about the project or the project stakeholders. Such information may be found in official documents like for example contracts, project business case, project charter or in project role descriptions. Additional information may be found in minutes from projects meetings in which the stakeholder has participated or on company websites – for example, that of a customer.

A third way to create data is to make assumptions about the stakeholder without collecting data. An example of such assumptions could concern the stakeholder’s perception of fairness in terms of procedural interactions. The assumption could rely on an attempt to imagine what the stakeholder would do and think based on previous experiences with this particular stakeholder; observations of or informal reports on current or past behaviour; or on general expectations of a stakeholder in the role(s) this particular stakeholder is undertaking. You might ask: What would a similar stakeholder do in a situation like this? How would the stakeholder talk about our project and his or her contribution to it to his or her own stakeholders? Has the project stakeholder previously contributed to similar projects the same way we require now? Do we see a correspondence between the stakeholder’s words and deeds in situations comparable to the current or future situation? How can our understanding of the specific context, as well as our understanding of the other stakeholders’ history with the project stakeholder, help us understand what to expect? Do we have reason to believe that anything would be different from last time?

You need to consider pros and cons including costs and benefits for each method of generating input for the assessment. Creating primary data may seem to be the most resource demanding for both you and the stakeholder in question. However, research (Jepsen and Eskerod 2009) has shown that direct interactions with a stakeholder in the early phases of a project are likely to increase the stakeholder’s motivations, make the stakeholder more positively minded towards the project and also align the stakeholders’ expectations. Therefore, creating primary data can be seen both as an engagement activity and as a way for you to acquire information. A challenge related to creation of primary data on stakeholder requirements, wishes and concerns in the early phases of the project is the risk of creating expectations in terms of the project process or the project deliverables that you cannot subsequently fulfil. This is particularly risky if the interactions with the stakeholders are done on an individual basis. If you are very attentive to each stakeholder you may well end up with a number of requirements and wishes that may be incompatible, and with a number of stakeholders each of whom expects that their particular requirements and wishes will be met. To avoid this situation, you may prefer to establish a forum, such as a workshop, in which you can interact with more stakeholders at a time.

Making use of secondary data from documents can enable you to obtain important information without taking the risks associated with interacting directly with the stakeholders. However you may find it difficult to locate sources revealing a detailed knowledge about the wishes and concerns of the stakeholders. Often, only requirements – and perhaps only the most important requirements – are explicitly listed.

Because of the challenges in creating and collecting primary and secondary data and the time pressure, project managers often stick to the third method – making assumptions. This may be a risky choice because assumptions are notoriously inaccurate and you also miss opportunities for engaging the stakeholders through direct contact.

PROJECT STAKEHOLDER PRIORITIZATION

You must decide how to distribute your limited resources for giving management attention to each stakeholder. As each project stakeholder may have different requirements and wishes and these may coincide, it may be impossible for you to accommodate them all. Before making trade-offs between the stakeholders’ requirements and wishes, you should first search for win-win situations. You may do this by conducting negotiations with each stakeholder at a time or with groups of stakeholders simultaneously, for example in a workshop. once you have done this you typically will find it necessary to make some trade-offs amongst what is left – and this includes the amount of management attention given to each stakeholder. It is important that you make these trade-offs and split your management resources in a way that best supports the project progress and the creation of benefits for the base organization.

To get an overview of the stakeholders it can be helpful to represent more or all stakeholders in a single chart with axes representing various characteristics, for example the stakeholders’ power. one approach to this is to use the stakeholder Management Web (see Figure 4.4) that you produce for each stakeholder to prepare a Stakeholder Power–Interest Grid (Ackermann and Eden 2011). The grid is presented in Figure 4.8 along with some examples of possible stakeholders in the groups.

Figure 4.8 Stakeholder Power–Interest Grid with examples of stakeholders

Source: Adapted from Ackermann and Eden 2011

The Stakeholder Power–Interest Grid can be used to pinpoint which stakeholders play an important role in the project as well as why they play this role. Stakeholders with low interest and low power are not vital to the project. They do not have much at stake and they are not able to spend resources on influencing the project. They are therefore termed ‘the crowd’. As the crowd is less important to the project only very few resources should be spent on these stakeholders. In the next quadrant, ‘Context Setters’ have low interest and high power. They are influential so their requirements and possibly their wishes must be considered and revealed – but as they do not have much at stake it will not be in their interest to spend resources on the project, for example by participating in time-consuming interactive communications like workshops. ‘Subjects’ are stakeholders with low power and a high interest in the project. For ethical reasons and perceptions of fairness, their requirements, wishes and concerns must be taken into account if possible. If they have a fair claim which is not met they may become important because they may be able to create a network enhancing their harm potential and thus their power. The last group of stakeholders is the ‘Players’. These stakeholders may be individuals or groups of individuals. They have high power and a high interest in the project and it is therefore important to allocate management attention to this group of stakeholders. Remember that stakeholders may be Players due to their direct power – but their power may also stem from a large network and/or a network containing other important Players.

The Power–Interest Grid handles power as one-dimensional. However, as you have learnt earlier in this chapter, power is (at least) two-dimensional. Stakeholders may have power to harm – but they certainly also may have power to help – or both. To get an overview of the stakeholders in terms of help or harm potential you can prepare a Project Stakeholder Potential Graph in which all the stakeholders or possibly just the Players are represented by bubbles. The information in the graph may be extended by adding size or colour to the bubbles. A graph must be made for each issue considered as a given stakeholder may not represent the same help or harm potential for all issues.

Figure 4.9 shows a Project Stakeholder Potential Graph. While the Project Stakeholder Potential Matrix which was displayed in Figure 4.3 assesses a single stakeholder, the Project Stakeholder Potential Graph shows how the stakeholders are distributed on ability to help and harm the project and thus gives a feeling of the amount and combinations of harm and help potentials of the stakeholder grouping in total.

Figure 4.9 Project Stakeholder Potential Graph

Source: Inspired by Savage et al. 1991:65

As the name says, the Project Stakeholder Potential Graph shows the potential to harm and help. To know whether you can expect a stakeholder to realize any potential, you need to add an extra dimension to the assessment – the attitude towards the issue at hand. A stakeholder who has a positive attitude will probably be inclined to help if possible and not be inclined to harm the project while a stakeholder with a negative attitude will not want to help but may be inclined to harm the project – to hinder or stop it if given the opportunity. Figure 4.10 shows the framework resulting from adding this extra dimension. We call this framework a Project Stakeholder Potential and Attitude Cube. In the figure each dimension only has two states but in reality they are all continuums.

Figure 4.10 Project Stakeholder Potential and Attitude Cube

To the right in the figure, we find stakeholders who have high harm potential; at the top stakeholders, who have high help potential; at the front, stakeholders who have a negative attitude; and at the back stakeholders, who have a positive attitude. In Figure 4.11 you see the possible eight combinations of the three dimensions and the labels we have given them. Stakeholders who have high help and harm potentials are very important to consider; if they have a negative attitude it is inevitable to do something to change this in order to secure the contribution needed.

In Figure 4.11, traffic light colouring has been used to easily point to the need for management attention. Red signifies urgent need for management attention, yellow that you have to consider this group, while green signifies that this group does not need attention at the moment. It is important to notice that this does not mean that you can completely ignore a ‘green stakeholder’ – you should monitor such stakeholders to notice if they move to one of the other categories.

In addition to looking at the help and harm potential as well as attitude, you may also reflect on whether you need to make your categorization of stakeholders even more fine-grained. It may be relevant to add an assessment of the urgency and the legitimacy of the claim of each stakeholder (Mitchell, Agle and Wood 1997). Urgency refers to the extent to which a stakeholder claim is time-sensitive, critical and probable. A stakeholder with high legitimacy of his or her claim on a certain issue should, for ethical reasons, be given some attention even if you define that stakeholder as Marginal because he or she represents low help and harm potential. Along the same lines, you may need to prioritize stakeholders with urgent claims over those stakeholders with less urgent claims at any given point in time.

Figure 4.11 Management attention needed for different types of stakeholders

CHALLENGES IN UNDERTAKING PROJECT STAKEHOLDER ANALYSIS

The Project Stakeholder Register is based on an interpretation of the stakeholders and the project that you make at a certain point in the project life cycle. You should not treat it as a static entity or a universal truth. Relying entirely on an analysis made at the beginning of the project may be dangerous as new stakeholders may appear while established stakeholders may change their requirements, wishes, concerns and attitude. The influence of each stakeholder may also vary at different stages in the project process, something that may be difficult to foresee completely in the project planning phase. You may overlook important stakeholders or misinterpret their behaviour if you only go through the process once. Typically you will also have a better basis for the assessments of stakeholders and project needs once some parts of the project have been undertaken. Activities that seemed initially distant may be clearer to you later on and a rough overview may have been substituted by a more detailed understanding. It is important that you share this detailed understanding with other members of the project organization and that they act upon it. You should record the information in an appropriate way in, for example, a Stakeholder Register supplemented with some of the tools that you have discovered in this chapter.

A further challenge is that some of the information raised in the project stakeholder analysis may be rather sensitive and should not be recorded in written documents for wider consumption (Jepsen and Eskerod 2009). Therefore, you should decide which decisions and arguments to record and store as well as the level of detail.

IMPLICATIONS FOR STAKEHOLDER MANAGEMENT

In this chapter we have presented some of the tools that you may use for creating an understanding and overview of your project stakeholders through a stakeholder analysis. A stakeholder analysis consists of three steps: identification, assessment and prioritization of the stakeholders as regards their need for management attention. Identification of the stakeholders involves determination of the boundaries of the project and who, inside this boundary, have the ability to affect or will be affected by the project. Stakeholder assessment involves determining the contribution needed from each stakeholder as well as their possible motivations to contribute as needed. An important part of this assessment is to reveal the direct or indirect power of each stakeholder to help or harm the project as well as their inclination to do so. Much of the information needed for the assessment must come from the stakeholders and, therefore, you may find it valuable to spend time on conducting workshops or interviews to establish this information. Stakeholder prioritization involves assessing the relative power of the stakeholders as well as their attitude towards the project and various issues connected to the project. You should always remember the volatile and implicit nature of the information needed and you therefore have to work with this analysis repeatedly along the project course.