A Practical Approach to Stakeholder Analysis

What’s the issue?

In the hunt for a decent Stakeholder Analysis template, I’ve found that there are too many options available, written by too many clever people and adapted for too many different applications. Some are too simplistic, and some vastly complex. Every organisation and project seems to have a different template. I’ve come across all sorts of intelligent sounding but essentially pointless terminology for column headings including perceptions, emotions, constraints, influence, motivations, engagement, and commitment. Consequently too often stakeholder analyses fail to end up as the points of reference they ought to be. The way I see it, for delivering small to medium scale Information Systems projects, what we need is a broad, straightforward, filterable, and useful way of looking at stakeholders, particularly in cases where time/support/resource for due diligence is limited.

What’s the real point of the Analysis?

If you are doing this for more than just a formality or high level representation, the real point is to identify and manage the human goals and needs of the project. In other words figure out who’s involved, which group’s goals take precedence, who you need to worry about, and what you need to do about it. It is worth noting that sometimes completely contrary to user-centric ideals, the end-user is not always the primary concern in the short term, with delivery success more likely assured by ticking off the primary stakeholder’s key goals. However this is a highly short-termist view, because in the end if users don’t take to the system, it will eventually adversely affect the key stakeholder, who of course will pass the blame onto design failures for the change in fortune. Longer term credibility can therefore only be ensured through end-user satisfaction, so if you have to choose only one group to satisfy, try and pick them, or at least convince the key stakeholder of their importance.

What is a stakeholder?

From a practical perspective, a stakeholder is any group or individual that is related to the project, either because they impact on it, or are impacted by it. They represent the entire human interface along the route from kick-off, to delivery and end use.

Components in a practical Stakeholder Analysis template

The following covers the range of information that you will find useful to know about the stakeholders that comprise your project environment. Delete or adapt as applicable to your needs. You should be able to outline a lot of the content by just talking to the project owner. An initial draft will quickly throw up the holes in your understanding of the project environment.

• Group: Depending on whether or not you are dealing with representatives of departments or users, or directly with individuals who represent themselves, this column should demonstrate high level context with titles like Business Group, Business owners, Marketing Managers etc


• Key Representative: You can add this field if you are dealing with specific individuals and feel that it would be helpful to see how they fit in the overall environment. In this case multiple individuals may belong to the same group.


• Type: Stakeholders fit into a range of types (sometimes multiple types) as follows: Reviewers, Providers, Related Projects, Output Deliverers, Outcome Accountable, Outcome Impacted, Output Utilisers. Building tick columns for these into your template will allow you to filter by stakeholder type, which is particularly useful when designing communications.


• Internal or External: External stakeholders can be hard to manage, so it is particularly useful to be able to identify external stakeholders with high impact on the project.


• Priority: High, medium, or low in terms of how important their goals and needs are as success criteria for the project.


• Delivery Involvement: Direct or Indirect. Are they directly involved in the delivery of the project or peripheral players?


• Relationship with / Interest in project: Their role in the project.


• Goals / Success Criteria: At this stage you will not need to worry about specific metrics, so success can effectively be viewed as the achievement of their goals. You can separate this into another column when you being to understand the specific outcomes that result from these goals.


• Impact on Project: Details on how they affect the project in terms of role, and responsibilities, or how the project needs to adapt to fit them.


• What does the project need from this group?: In terms of inputs or support.


• Impact of Project: How the delivery or end product of the project will affect the user group.


• Potential Issues or Concerns: What are they concerned about in terms of project delivery and outcome?


• Needs: What do they need from you and/or the project delivery team


• Management Strategy / Method of Communication: How you plan to communicate with the stakeholder and satisfy their needs as above.

Here's a sample excel template you can use for stakeholder analysis and management.