But first, I want to raise a point that is always controversial: everything is politics.

“A wise prince should follow similar methods and never remain idle in peaceful times, but industriously make good use of them.”

The Prince, Niccolò Machiavelli

Politics have always existed, exist today, and will continue to exist wherever people need to make decisions, and companies are no different. When I talk about politics, I do not necessarily mean something negative. I am talking about power, interests, priorities, expectations, relationships, and influence inside an organization.

A project can have an excellent schedule, an adequate budget, and a technically capable team and still be completely changed by a sponsor’s decision, resistance from another department, a conflicting executive priority, or poor communication. That is why I believe managing stakeholders is also part of managing the project itself.

What is a stakeholder?

A stakeholder is a person, group, or organization that can influence an initiative, be influenced by it, or have an interest in its results. In project management, stakeholders can include sponsors, executives, PMOs, project managers, technical teams, customers, suppliers, regulators, and many other people who may not work directly on the project but can still affect its success.

This is an important distinction because some of the most influential stakeholders may participate in only a few moments of the project. They may not attend daily meetings, update tasks, or work directly with the team, but they may control the budget, approve an important decision, own a critical dependency, or have enough influence to change the priority of the entire initiative.

Who are the stakeholders in a project?

Project stakeholders vary according to the company, industry, initiative, and type of delivery, but there are some groups that appear frequently. In a typical project, I would start by looking for:

• Sponsor
• Steering Committee
• PMO
• Project Manager
• Managers from other departments
• Technical teams
• Finance
• Legal
• Operations
• Customers
• Potential customers
• Suppliers
• Partners
• Regulatory bodies

This list is not yet a stakeholder map. It is simply the starting point. The objective is not to collect as many names as possible, but to identify the people and groups that can actually influence the project or be significantly affected by it.

And there is one principle I always keep in mind: impact works in both directions. The project affects stakeholders, but stakeholders also affect the project. Another department may depend on something we are delivering while, at the same time, we depend on its approval. A supplier may be affected by our schedule, but a delay from that supplier may also compromise our final delivery date.

How to identify the most important stakeholders

A list of names is useful, but it does not tell us who deserves the most attention. To understand that, I usually start with a few practical questions: who can approve or reject an important decision? Who controls budget or resources? Who will be affected by the delivery? Who do we depend on for information, approvals, or work? Who can block the initiative? Who can accelerate an important decision?

I also try to identify who will operate what we are building after delivery, who can influence other stakeholders, and who controls an important project dependency. Some answers will be obvious. Others will not, and those less obvious stakeholders are often the ones that create the biggest surprises.

A department that appears unrelated to the project may control a mandatory approval. A supplier may own a critical dependency. An executive who rarely attends project meetings may still have enough power to change the initiative’s priority. This is why stakeholder identification should not be treated as a one-time administrative exercise.

How to create a stakeholder map

Stakeholder mapping turns the initial list into a more structured view of the people and groups surrounding the project. A useful stakeholder map should help us understand not only who is involved, but also who controls decisions, resources, approvals, dependencies, or influence that can change the direction of the initiative.

For each stakeholder, I normally collect information such as their role, level of interest, decision-making power, influence over other people, level of support or resistance, expectations, possible impact, and the decisions that depend on them.

This is particularly important because formal authority and real influence are not always the same thing. Someone relatively low in the hierarchy may have enormous influence over the person who makes the final decision. On the other hand, someone with a senior title may have little interest in the initiative and only become involved when a specific decision reaches their desk.

So, for me, the purpose of stakeholder mapping is not to create a beautiful diagram. It is to answer a much more useful question: who can actually change the outcome of this project?

How to perform a stakeholder analysis

A stakeholder analysis takes the mapping process one step further. At this stage, I try to understand each stakeholder’s requirements, expectations, power, interest, influence, level of support, resistance, and possible impact on the project.

This information can come from interviews, individual conversations, surveys, previous projects, historical data, internal company information, and external research. Depending on the type of stakeholder, market research can also help us understand external groups. I discuss that topic in more detail in: How to Create a Market Analysis and Avoid Surprises in Your Product Launch .

I do not believe stakeholder analysis needs to become an exact science. In many cases, we are working with perceptions and incomplete information. But a structured perception is usually much better than discovering in the middle of an important meeting that someone with enormous power over the project strongly opposes what we are trying to do.

After collecting this information, we can begin to prioritize stakeholders. This is where one of the most common stakeholder management tools becomes useful: the stakeholder matrix.

What is a stakeholder matrix?

A stakeholder matrix, often associated with the Mendelow matrix, is a way of classifying stakeholders based mainly on two dimensions: power and interest. Because of this, it is also commonly represented as a power interest grid or power interest matrix.

In the most common model, one axis represents the stakeholder’s level of interest and the other represents their power or ability to influence the initiative. The combination creates four groups: low interest and high power, high interest and high power, low interest and low power, and high interest and low power.

It is a very simple structure, and that simplicity is probably one of its greatest advantages. Once stakeholders are placed on the matrix, it becomes much easier to see that different people require different management strategies.

A stakeholder with high power but low interest may not want to attend every meeting, but ignoring that person can be dangerous. Someone with both high power and high interest, on the other hand, should probably be involved much more closely in important decisions.

How to use a power interest grid

There is an important difference between classifying a stakeholder and managing a stakeholder. The power interest grid helps with classification. Stakeholder management begins when we decide what to do with that information.

In general, stakeholders with high power and high interest should be managed closely and usually need to participate in the most important decisions. Those with high power and low interest should remain satisfied and informed about anything significant enough to require their attention.

Stakeholders with low power and high interest should remain informed and may become excellent sources of feedback and support. Those with low power and low interest normally require less attention, although that does not mean they should be completely ignored.

I would avoid treating these quadrants as permanent rules. Power changes. Interest changes. People change positions, and projects evolve. An organizational restructuring can completely change someone’s influence. A stakeholder who was almost irrelevant at the beginning of the project may become critical after a change in scope.

For that reason, a stakeholder map and stakeholder matrix should not be created at the beginning of the project and then forgotten in a folder. They should be reviewed when the context changes.

From stakeholder mapping to stakeholder management

Once stakeholders have been identified and classified, we move into stakeholder management. At this point, I want to understand not only where someone sits on a matrix, but also how we should work with that person throughout the initiative.

I return to the original stakeholder map and add information such as organizational position, influence, power, interest, support, resistance, expectations, decisions that depend on that stakeholder, communication frequency, and expected level of involvement.

This is where the map stops being simply a diagram and starts becoming an actual management tool. The classification helps us understand who deserves attention. The additional information helps us decide how to act.

How to create a stakeholder communication plan

After identifying, mapping, and analyzing stakeholders, we need to decide how each group should receive information about the project. This is where the stakeholder communication plan becomes important.

For every stakeholder or group, I usually ask myself three questions: how will I inform them about what is happening? How will I convince them when I need support for an important decision? And how will I keep them engaged throughout the initiative?

We need to define communication channels, frequency, and, most importantly, what information is genuinely relevant to that stakeholder. Too little information can reduce engagement. Too much information creates noise and may hide the information that actually deserves attention.

Executives, for example, usually need overall progress, major milestones, financial status, important risks, and decisions that require their involvement. Managers may need additional details about dependencies, impacts on other departments, costs, and capacity. Technical teams need priorities, upcoming work, blockers, and potential changes. Customers need to understand meaningful deliveries and benefits, while suppliers need visibility into when their participation will be required.

Good communication with stakeholders requires data

There is one part of this discussion that I consider particularly important: the more relevant a stakeholder is, the less our communication should depend on phrases like “I think we are doing fine.”

If we have reliable information about schedule, cost, risk, productivity, capacity, and delivery progress, the conversation changes completely. Instead of simply saying that a project appears healthy, we can show what was planned, what was actually delivered, where risks are emerging, which activities are blocked, and where cost or schedule deviations are beginning to appear.

This is exactly where a Project Intelligence platform such as Saint Jude can support stakeholder management.

Saint Jude integrates the project data that already exists in Jira, Azure DevOps, Asana, Monday.com, and ClickUp and transforms it into a layer of intelligence for analyzing schedule, cost, risk, productivity, and delivery. The board remains where the team works. The objective is to use the data already available there to improve decisions and communication with sponsors, PMOs, executives, managers, and technical teams.

“All things are lawful for me, but not all things are helpful.”

1 Corinthians 6:12

Available information is not necessarily useful information. The manager’s job is to understand what each stakeholder actually needs to know in order to make a decision.

How to improve stakeholder engagement

Informing people is only part of the job. The other part is getting their support when that support becomes necessary. This brings me back to the point I raised at the beginning: projects are political environments as well.

Before trying to convince someone, I try to understand what that person can gain, lose, or protect. A director may be concerned about margin. A manager may be concerned about team capacity. A technical team may be worried about additional workload. An executive may care primarily about strategic impact. A department affected by automation may be worried about its future relevance inside the organization.

If we communicate exactly the same message to all these people, we will probably get very different results. Stakeholder engagement requires context.

“He who strives to resolve difficulties resolves them before they arise. He who overcomes his enemies, triumphs before his threats are realized.”

Sun Tzu – The Art of War

Power, influence, and persuasion in stakeholder management

When I talk about power and influence, I am not talking about manipulation. I am talking about understanding how people make decisions and what incentives, fears, expectations, interests, and ambitions influence those decisions. One framework I sometimes use to organize this thinking is Maslow’s hierarchy of needs.

I do not use Maslow’s hierarchy as a scientific formula for predicting behavior. I use it as a way to force myself to think about what actually matters to that stakeholder.

In some cases, a stakeholder may see the initiative as a threat. Automation may eliminate part of the work performed by their team, a reorganization may reduce their scope, or the project may move budget, responsibility, or power to another department. In that situation, simply repeating that the project is important for the company is unlikely to solve the problem. We need to understand the resistance, explain the impact, and, whenever possible, create alternatives.

“Men sooner forget the death of their father than the loss of their patrimony.”

The Prince - Niccolò Machiavelli

In other cases, the opposite happens. The stakeholder sees the initiative as an opportunity. It may generate recognition, improve the results of their department, increase their influence, create a promotion opportunity, generate a bonus, or simply make their work more visible inside the organization.

“For whenever men are not obliged to fight from necessity, they fight from ambition.”

The Prince - Niccolò Machiavelli

The better we understand these motivations, the better our chances of building an engagement strategy that actually makes sense for that specific stakeholder.

Stakeholders can also become project risks

There is also an important connection between stakeholder management and project risk management. A stakeholder can create an opportunity for the project, but they can also become a significant source of risk.

A sponsor who stops supporting the initiative, a department that resists a change, an executive who delays a decision, or a supplier who fails to deliver a dependency can completely alter what we originally planned.

That is why, during stakeholder mapping, I also look for signs of resistance, conflicts of interest, changing priorities, and important dependencies. If a stakeholder has a high level of power and is clearly opposed to the initiative, that should not become a surprise only after an important decision gets blocked.

When the problem has already happened, techniques such as the Ishikawa Diagram and the 5 Whys can help us understand how we reached that situation.

I discuss this subject in more detail in How to Find the Root Cause of Your Project's Problems . When the risk is related to delays and dependencies between activities, I also recommend: Critical Path in Project Management: How to Identify Dependencies That Can Delay Your Project .

Stakeholder mapping is the beginning, not the end

If you arrived here simply looking for a stakeholder map or trying to understand how a stakeholder matrix works, the technical part is not particularly complicated. Identify the relevant people, analyze their power and interest, and place them into a structure that helps you establish priorities. The real value starts after that.

Stakeholder mapping helps us understand who matters. Stakeholder analysis helps us understand expectations, power, and influence. The power interest grid helps us establish priorities. A stakeholder communication plan defines what each group needs to know. Stakeholder management turns that information into action, while stakeholder engagement helps us maintain support throughout the project.

Because projects do not happen only between tasks, schedules, and budgets. They happen between people, and people have objectives, expectations, fears, interests, and different levels of power.

A good manager needs to understand both sides: what is happening to the project and what is happening to the people who can influence that project.

That is why I still believe in the same point I made at the beginning of this article: everything is politics. The difference is that with good stakeholder mapping and stakeholder management, we can understand who is sitting at the table, what interests are at stake, and how to manage the conversation before we are forced to negotiate in the middle of a crisis.

See you soon!

Erik Scaranello