Stakeholder management in an IT project is the systematic identification of people and groups the project affects, or who can affect it, and choosing a communication strategy matched to their power and interest. IT projects fail more often because of an overlooked stakeholder (e.g. legal blocking a rollout at the last stage) than because of a purely technical problem.
Quick Overview
What you’ll learn from this article:
- How stakeholder management differs from ordinary project communication
- The power-interest matrix as a tool for prioritising stakeholders
- The role split between the project manager, the sponsor, and the team in stakeholder communication
- A step-by-step plan for rolling out stakeholder management on a new IT project
Who this article is for: IT project managers building a communication plan for a new rollout, project sponsors assessing their role in stakeholder relationships, Product Owners managing expectations across multiple business groups.
Reading time: 6 minutes
Stakeholder management in IT projects: team roles and responsibilities
A stakeholder in an IT project is any person or group affected by the project’s outcome, or able to influence how it unfolds — not just the sponsor and end users, but also the security team (which can block a rollout on compliance grounds), the legal department (for projects involving personal data), maintenance teams (who will own the system after rollout), and competing initiatives in the organisation vying for the same resources. The PMBOK Guide defines stakeholder management as a distinct project knowledge area, covering identification, analysis, engagement planning, and monitoring relationships throughout the project lifecycle — not a one-off activity at kickoff.
The most common mistake is treating stakeholder management as a synonym for sending regular status reports. A status report informs but doesn’t engage — it doesn’t answer what a given stakeholder actually needs in order to support the project, or at least not block it. A stakeholder with high power and low interest (e.g. a CFO who isn’t day-to-day involved) needs a different strategy than one with high interest and low power (e.g. a support team who will work with the new system every day) — sending the same status report to both wastes one group’s attention and fails to engage the other enough.
The power-interest matrix as a prioritisation tool
| Quadrant | Characteristics | Communication strategy |
|---|---|---|
| High power, high interest | Key decision-makers actively engaged (e.g. the sponsor) | Manage closely — regular one-on-ones, joint decision-making |
| High power, low interest | Can block the project but don’t track it day to day (e.g. a CFO) | Keep satisfied — concise, infrequent updates focused on business impact |
| Low power, high interest | Day-to-day system users, support teams | Keep informed in detail — frequent communication, a channel for feedback |
| Low power, low interest | Peripheral teams indirectly affected by the change | Monitor with minimal effort — general updates, no dedicated meetings |
How to roll out stakeholder management step by step
- Identify all stakeholders at project kickoff, going beyond the obvious ones (sponsor, users) — include security, legal, maintenance teams, and competing initiatives.
- Place each stakeholder in the power-interest matrix and choose a communication strategy matched to their quadrant, instead of a single strategy for everyone.
- Split roles within the project team — the project manager usually leads day-to-day operational communication, the sponsor engages for key decisions and escalations, and the team communicates technical detail directly to end users.
- Plan checkpoints to revisit the stakeholder map — roles and engagement levels change over the course of a project (a new stakeholder can appear, another can lose influence).
- Document commitments and decisions made in stakeholder conversations — a lack of documentation leads to disputes over what was actually agreed, especially when people on the project change.
The project sponsor plays a role the project manager can’t substitute for — they legitimise the project at an organisational level and resolve cross-department conflicts the project manager has no mandate to resolve alone. Projects where the sponsor is passive (formally assigned but inactive in communication) lose leverage in conflicts over resource priorities — the project manager is left alone with a problem that needs authority beyond their own. It’s also worth remembering that the stakeholder map isn’t a static document drawn up once at kickoff — new stakeholders appear as the project progresses (e.g. a compliance team joining only when production rollout is being planned), while others lose influence once their area of responsibility is no longer directly affected by the change.
Read Also
- AgilePM® - A Guide to Agile Project Management
- Agile vs Waterfall: choosing the right model for your project
Develop Your Skills
Want to manage stakeholders more effectively in your IT projects? Check out our training led by experienced EITT instructors.
➡️ Effective collaboration with project stakeholders — EITT training ➡️ Managing project stakeholders - building a support system — EITT training
Frequently Asked Questions (FAQ)
How does a stakeholder differ from a regular project participant?
A stakeholder is any person or group affected by the project, or able to affect it — regardless of whether they formally take part in it. A project participant (team member) is always a stakeholder, but many stakeholders (e.g. legal reviewing compliance) never take part directly in the team’s work.
How often does the stakeholder map need to be updated?
There’s no fixed rule, but it’s worth revisiting the map at every major project milestone — stakeholder roles and engagement levels change over time, and a map drawn up at kickoff rarely stays accurate for the entire project lifecycle.
Who should communicate with high-power stakeholders?
Usually the project sponsor, not the project manager — the sponsor has the organisational mandate to speak on equal footing with other senior decision-makers. The project manager handles day-to-day operational communication, but escalations to high-power stakeholders should go through the sponsor.
What happens when a project overlooks an important stakeholder?
The overlooked stakeholder often blocks the project at a late stage, when the cost of change is already high — a classic example is legal or security raising objections just before rollout, even though they could have raised them at kickoff had they been included in the stakeholder analysis.