At its start, a project is always a challenge with a unique outcome and a lot of uncertainty. To eliminate that uncertainty and the possible risks the project manager should analyze where they come from. Often, the problems arise because of neglected or ill-defined project expectations: an inexperienced project manager expects the stakeholders to deliver their expectations, but it hardly ever happens.
What is the main reason for project change? Based on my experience, business development projects usually face changes because deliverables are added by project stakeholders while the project is already going on.
What Is a Stakeholder in Project Management?
A stakeholder is a person, a group of people, or an organization that is capable of influencing a project, or that can be influenced by the outcome of a project/separate task. Stakeholders can be both internal and external.
Stakeholders are those with an interest in your project‘s outcome. They are typically the members of a project team, project managers, executives, project sponsors, and customers.
That way, the stakeholders’ profit is influenced in a positive or negative way by the outcome of a project or its execution. Moreover, different stakeholders can have expectations that contradict each other.
That’s why project managers can often be unpleasantly surprised by actions or decisions stakeholders take. Being aware of the stakeholders’ expectations influences the collection and analysis of deliverables and the analyses of project risks.
How do you evaluate our stakeholders?
There are three key approaches known to me:
-
Stakeholder wheel
-
Stakeholder nomination
-
Inspecting project documentation
Stakeholder Wheel
The first approach is based on using a stakeholder classifier. If the stakeholder classifier is built based on department-specific roles, it will be more valuable to you. If you don’t have a specific one, you can borrow a multi-purpose one from one of the project management methodologies. For example, PMBOK is using the following list of stakeholders:
-
Project sponsor
-
Project customer
-
Users
-
Vendors and contractors
-
Business partners
-
Company departments
-
Functional managers
-
Other stakeholders (procurement organizations, financial institutions, government regulators, field experts, consultants)
The British Computer Society (BCS) defines the following stakeholder groups: project owners, managers, employees, supervisors, vendors, partners, clients, and competitors.
The authors of the “Stakeholders” section at 12manage.com define the following groups as stakeholders:
-
shareholders and investors;
-
creditors: banks and other credit organizations;
-
partners and vendors;
-
customers and clients;
-
managers and the company’s top management;
-
employees;
-
professional unions;
-
competitors;
-
government and tax authorities;
-
professional associations;
-
mass media;
-
non-governmental organizations;
-
social-ecological, religious, or other organizations;
-
local communities.
The stakeholder wheel is used in the following way:
Step 1: define, which stakeholder categories exist in your project
Step 2: define, which stakeholders from those categories are involved in your project
Step 3: Check the stakeholder list
Stakeholder Nomination Approach
The stakeholder nomination approach involves the project manager defining the main stakeholder (e.g. Project sponsor), who, consequently, nominates other stakeholders.
The quality of this decision will depend on the expertise of the key stakeholders. That’s why it’s better to use this approach in combination with the stakeholder wheel. The main drawback is paying the most attention to internal stakeholders only.
Project Connected Documentation
The third approach involves looking for any project-connected documentation, studying it, and defining roles and positions that have any relevance to the project. The weak point of the approach is that written documents usually don’t reflect reality. They are, at times, hard to get due to license agreements and they can contain too many irrelevant details.
The Best Approach
After taking into account the three different ways to evaluate stakeholders, I believe that it’s more effective to start a stakeholder evaluation with a stakeholder wheel but eventually incorporate nomination and project documentation.
Let’s imagine a company is opening a new plant. Based on the PMBOK stakeholder list we’ll have the following:
Stakeholder category |
Is this category involved in the project |
Project specific stakeholders |
Project sponsor |
Yes |
Business development manager |
Project customer |
Yes |
The manager of the plant in construction |
Users |
Yes |
Plant products’ consumers |
Vendors |
Yes |
Equipment suppliers |
Contractors |
Yes |
|
Business partners |
Yes |
Plant products’ distributors |
Company employees |
Yes |
|
Functional managers |
Yes |
Company department managers, whose employees will be involved in the project |
Financial institutions |
Yes |
The bank that provides the loan for the project |
Government regulators |
Yes |
The ministries supervising the construction |
Field experts |
Yes |
The experts who will be involved in the project management process |
To make the list more accurate, we can use the stakeholder nomination approach as an addition. To do that, we have to ask the project sponsor about which departments will be involved in the project and which business partners will be selling the goods the plant produces.
You can further improve the list by studying project documentation. To do that you have to investigate the company’s organizational structure to find out which departments are project stakeholders.
After evaluating stakeholders you should evaluate their project expectations, define the stakeholders who can provide you with project requirements, identify the risks associated with each of the stakeholders, and come up with strategies to work with them effectively.
But wait! Before you get excited and run off and evaluate your stakeholders, you have to make a list of their names and contact info. This information is super important and you’ll need it later. All in all, involving project stakeholders ensures minimizing the number of missed product requirements and risks – that’s why I recommend you use it.