At it’s 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, the business development projects usually face changes because deliverables are added by project stakeholders while the project’s already going on.
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.
That way, the stakeholders’ profit is influenced in a positive or negative way by the outcome of a project or it’s 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 collecting and analyses of deliverables and the analyses of project risks.
How do you evaluate your 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 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.
Stakeholder wheel is used the following way:
Step 1: define, which stakeholder categories exist on 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 stakeholder. 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 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 go 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.
Follow us