Being nice is not enough: A systematic approach to Stakeholder Management

You can deliver a project on time, in scope and in budget and still end up with a failure. It happens more often than you think. According to PMI’s Pulse of the Profession 2023, about 28 % of projects still fail to meet their business goals. A project can look clean on paper and still miss the mark if it does not bring value to the company.

Value, however, is not purely a financial or technical metric. It is perceived, shaped and judged by stakeholders across the organisation. Yet while we plan scope, time and budget professionally, we rarely plan how to manage stakeholders with the same discipline. Being a nice colleague who gets along with people helps, but it is not enough.

Stakeholder management appears in most project management textbooks, such as PMBOK, PRINCE2 or the APM Body of Knowledge, yet in practice it is often reduced to “talking to people.” Teams treat it as intuitive. People assume it is a soft skill that some naturally have and others do not. As a result many operate in a reactive mode. They answer questions as they come, put out fires and smooth conflicts on the fly.

But relationships do not grow under tension. They grow when times are calm, when people trust each other and when there is no looming delivery crisis. Only then can those relationships carry you through the stress of tough decisions or timeline pressure.

Stakeholder management is a craft and like any other craft it can be learned. This article gives you a practical system you can apply this week to move out of reactive mode. Later posts will dive deeper into details like mapping techniques or tricky scenarios.

Why stakeholder management breaks down in practice

Most of us enter work with the mindset of finishing tasks rather than managing the system around them. Write the software. Ship the feature. Prepare the presentation. Stakeholders become an afterthought until they turn into a problem. This is not because people don’t care. It is because there is no shared definition of what a stakeholder is.

The PMP defines a stakeholder as “any individual, group or organisation that may affect, be affected by or perceive itself to be affected by a decision, activity or outcome of a project.” It is a useful definition, but it is broad enough that almost anyone can fall into the category. If everyone is a stakeholder, you end up managing no one intentionally.

So people default to managing whoever shouts the loudest. When someone with authority or urgency appears, teams react instantly. They drop what they are doing and respond with ad hoc communication. This interrupts planned work and creates a cycle of reactive behaviour.

In mild cases it distracts a project manager for an hour. In tough cases it derails entire initiatives.

Once you recognise these patterns, you can switch from reacting to building a system that scales.

The mindset shift: From getting along well with people to a scalable system

You don’t need to be an extrovert or a natural communicator to excel at stakeholder management. What you need is a system.

The shift is simple: consistency beats charm. Structure beats reactivity.

Stakeholder management is not a personality trait. It is a set of methods, tools and rituals that you apply in a disciplined way. Over the years I have used a lightweight process that works across product work, delivery projects and customer success engagements.

One important note before we dive in: stakeholder management is not reserved for project managers or senior leaders. If you are an analyst, a developer or a DevOps engineer you also work with people whose expectations and influence affect your work. This system is for you too.

Four steps to understand your stakeholders

With the mindset in place, the next step is building a repeatable system. It starts with four steps.

1. Set the context
2. Identify and map stakeholders
3. Build a tailored communication approach
4. Implement and refine over time

Step 1: Set the context

A stakeholder’s role and interest depend on the specific context they operate in. A manager can be highly invested in Project A while barely caring about Project C. An enterprise architect can be passionate about a strategic migration but indifferent to UI fixes.

If the context is unclear, your stakeholder mapping will be unclear. Define the context in plain, unambiguous language. It should remain obvious even months later.

Examples:

• Delivery phase of the new CRM solution with all required integrations
• Reducing backlog of customer inquiries
• Designing and implementing a personalised recommendations feature

Once the context is defined, you can begin identifying who actually shapes the outcome.

Step 2: Identify and map your stakeholders

Start by listing everyone who interacts with the context. Remember: It doesn't need to be an individual. It can also be a working group or a department.

Pay special attention to hidden or indirect stakeholders. I have seen entire launches blocked because nobody involved Legal early enough. Sometimes the project killer is something as mundane as a missing cookie banner review.

For mapping you can use several lightweight models like Interest vs Influence or RACI. I recommend a modified Mendelow matrix plus a comment field.

Interest: Use a scale from -5 to +5 to capture how strongly a stakeholder wants the project to succeed or fail.

Power: Use a scale from 1 to 10 to capture influence or authority.

Comments: This is where the gold lives. Add context, motivations and notes you pick up over time. Without being intrusive you can also note personal details that help build rapport like hobbies or a favorite football club.

Treat this information with care. Stakeholder maps should not become public documents in company wikis. They contain personal data and require discretion.

Here are a few examples from the field:

• The CTO who defined a new tech strategy and selected a new eCommerce platform that your team must now implement
  • Interest: +5, because the project is a cornerstone of their strategy and reputation
  • Power: 9, because they control architectural direction and funding decisions
• The new Enterprise Architect who prefers MuleSoft, while the previous architect recently purchased Dell Boomi
  • Interest: -4, because the project reinforces a technology choice they do not support
  • Power: 7, because architecture often shapes integration decisions and can delay or block designs
• Your colleague in Customer Success who supports you in reducing the customer inquiry backlog
  • Interest: +5, because success directly improves customer satisfaction and their operational workload
  • Power: 4 or 5, because they influence daily processes and data, but not strategic decisions

Once you know who matters and why, you can tailor how you communicate with each of them.

Step 3: Build a tailored communication approach

Once you know who the stakeholders are and how they relate to your context, you decide how to communicate with them.

Think of it like preparing for a football match. Step 2 was analysing the opposing team. Step 3 is planning how your team will respond. Instead of sliding tackles and formations, your tools are messages, meetings and updates.

The principle is simple: provide the right information to the right stakeholder at the right time.

Your communication priorities follow the matrix:

• High Power, Negative Interest: Engage closely, understand their concerns and address them early
• High Power, Positive Interest: Keep them aligned and involved, support their goals
• Low Power, Negative Interest: Provide generic updates and monitor them
• Low Power, Positive Interest: Keep them informed and use them as multipliers

Elements of the communication plan:

• Type of communication: Email, meeting, status update, steering committee
• Level of tailoring: Town hall, personal write up, 1:1 conversation
• Frequency: Quarterly, monthly, weekly or daily for critical work

Two practical notes:

First, your plan must be executable. You cannot mark ten people as requiring weekly 1:1 conversations unless you have unlimited time.

Second, avoid too much generic communication. It becomes noise quickly. Fewer, more tailored touchpoints often have a stronger effect.

Step 4: Implement and refine

Once the plan is ready, put it into action. If you work in a team, socialise the plan first. Your stakeholder map will help you see who needs to be involved.

Remember that the mapping is a snapshot. Review it regularly. Stakeholders change jobs, priorities shift, influence grows or declines. Also assess whether your communication plan still works. Most organisations have at least one status meeting that has been superfluous for months. Don’t be the person hosting that meeting.

A living system improves over time and becomes easier to maintain.

Conclusion: What changes when you adopt a systematic approach

With a systematic approach you leave reactive firefighting behind. Your communication becomes intentional. Friction decreases. Escalations drop. Decisions become faster and ownership becomes clearer.

You can manage detractors proactively instead of hoping they stay quiet. Delivery becomes more predictable. Customer Success has more confidence when communicating with clients.

When stakeholder management works well, the entire engagement feels more predictable. Surprises still happen, but they surface earlier, when you still have room to react. Stakeholders share their intentions more openly, decisions land faster and conflicts become easier to handle because the relationships and routines are already in place. Instead of spending your days firefighting, you regain headroom to focus on the actual work you were hired to do. The system does not remove all tension, but it removes the unnecessary tension and that often makes the difference between a chaotic project and a successful one.

This article gave you the overview. Future posts will go deeper into tools, common mistakes and strategies for handling especially challenging stakeholders.