In 2010, Reed Hastings, CEO of Netflix, made a decision that would become a case study in stakeholder mismanagement. He announced that Netflix would split into two services: streaming video would remain as Netflix, and DVD-by-mail would become a separate service called Qwikster. The decision was rational from a business strategy perspective — streaming was the future, and the DVD business was declining. But Hastings had failed to manage a critical stakeholder group: his customers. The announcement was made abruptly, without preparation or context. Customers were furious. Netflix lost 800,000 subscribers in a single quarter. The stock price dropped 77%.

Three months later, Hastings reversed the decision. In a blog post that became famous for its candor, he wrote: "It is clear that for many of our members, two websites would make things more difficult, so we are going to keep Netflix as one place to go for streaming and DVDs." The business logic had been sound. The stakeholder management had been disastrous.

Stakeholder management is the practice of identifying the people and groups whose interests affect or are affected by a project, understanding their needs and concerns, and managing the relationship in ways that support project success. It is not the same as stakeholder satisfaction — sometimes good stakeholder management means delivering unwelcome news effectively, or maintaining a position that stakeholders oppose. But it requires understanding who matters, why they matter, and what they need from you.

"Every project exists within a web of relationships. You can get the technical work exactly right and still fail completely if the people whose support you need have not been brought along." -- adapted from Jeffrey Pinto, Project Management: Achieving Competitive Advantage

Stakeholder Quadrant Power Interest Engagement Strategy Risk of Neglect
Manage closely High High Regular substantive updates; early involvement in decisions Project blocked or reversed by an unsatisfied decision-maker
Keep satisfied High Low Enough communication to prevent surprises; no unnecessary detail Passive stakeholder becomes hostile when surprised by change
Keep informed Low High Regular updates; input opportunities; advocacy channel Organized opposition from under-communicated interest group
Monitor Low Low Periodic check; track for quadrant shifts Stakeholder shifts quadrant and finds project was ignoring them

The Stakeholder Landscape

Every project exists within a web of relationships. Understanding this web is the starting point for effective stakeholder management.

Internal vs. External Stakeholders

Internal stakeholders are people within the organization who have an interest in the project: sponsors who are funding it, team members executing it, other departments affected by it, leadership who will use its outputs.

External stakeholders are people outside the organization who have an interest: customers who will use the product, regulators who govern the domain, partners whose systems must integrate with the project output, communities affected by the project's physical or economic impact.

External stakeholders are often underweighted in project planning because they are less visible. The regulatory approval that has not been sought, the community impact that has not been anticipated, the customer segment that was not consulted — these external stakeholder failures have ended or significantly delayed projects that were technically and organizationally sound.

Example: The proposed Massachusetts Bay Transportation Authority (MBTA) South Station expansion project, planning from 2010 to present, has repeatedly been delayed by stakeholder issues that include neighborhood opposition to traffic impacts, regulatory concerns about historic preservation, and coordination challenges with Amtrak, which also uses the station. The technical engineering work is straightforward; the stakeholder management has been the binding constraint.

The Power-Interest Matrix

Not all stakeholders require the same management approach. The most widely used prioritization tool is the power-interest matrix (also called the influence-interest or impact-interest matrix), which plots stakeholders on two axes:

  • Power/Influence: The stakeholder's ability to affect the project or its outcomes
  • Interest: The degree to which the stakeholder cares about the project

The resulting four quadrants suggest different engagement strategies:

High power, high interest: Manage closely. These stakeholders can make or break the project and are actively engaged. They require regular, substantive communication, early involvement in decisions that affect them, and a direct relationship with project leadership.

High power, low interest: Keep satisfied. These stakeholders can significantly affect the project but are not actively engaged. The risk is that unexpected project developments turn them from passive to hostile. They require enough communication to prevent surprises, without burdening them with detail they do not want.

Low power, high interest: Keep informed. These stakeholders care a great deal but cannot significantly affect the project. They are often advocates and can become influential if their interest group organizes. They benefit from regular updates and opportunities to provide input, even if that input may not be fully incorporated.

Low power, low interest: Monitor. These stakeholders require minimal active engagement but should be tracked for changes — a stakeholder who moves from low-interest to high-interest may move from this quadrant to a more consequential one.

The Stakeholder Identification Process

The power-interest matrix is only useful if the stakeholder landscape has been comprehensively identified. Incomplete identification is among the most common stakeholder management failures — the stakeholder who was not identified cannot be managed.

A systematic identification process:

Step 1: Organizational mapping

Who holds formal authority over the project? Who holds authority over the resources the project requires? Who will be responsible for the outputs the project creates?

Step 2: Impact mapping

Who will be affected by the project's outputs? Who will have to change their work processes because of the project? Whose budget will be affected? Whose metrics will be affected?

Step 3: Influence mapping

Who has informal influence over people with formal power? Who are the respected peers, experienced voices, or organizational network hubs whose opinions shape the views of formal stakeholders?

Step 4: The "who have I missed?" review

Ask several people who know the organization well: "Who have I missed?" This meta-step catches the stakeholders who are obvious in retrospect but not obvious in advance — the operational team that will actually use the system, the legal department that must approve the terms, the communications team that will be affected by the announcement.

Common Stakeholder Patterns and Challenges

The Missing Sponsor

Project sponsors — the senior leaders who provide resources and organizational authority for the project — are among the most critical stakeholders. Sponsor failure takes two forms.

The absent sponsor approves the project and provides the budget but is never heard from again. They are too busy, too disengaged, or too optimistic to provide ongoing oversight. The project operates without the organizational authority it needs to resolve conflicts, secure resources, or make escalated decisions. When the project encounters the inevitably difficult moments, there is no one with authority to help.

The micromanaging sponsor is too involved in operational details, substituting for project leadership rather than providing strategic oversight. This creates decision confusion (two levels of authority making operational calls), undermines the project manager's authority, and often slows decision-making.

The effective sponsor is actively engaged at the strategic level — providing direction, removing organizational obstacles, making decisions that require their authority — while leaving operational management to the project team.

Example: Deloitte's analysis of large-scale transformation programs found that active executive sponsorship was the most statistically significant differentiator between programs that succeeded and programs that failed. "Active" was defined as: visible personal commitment, willingness to remove organizational obstacles, and consistent allocation of senior time to the program. Programs with nominal sponsors — leaders who had approved the program but did not actively support it — failed at nearly the same rate as programs without sponsors.

The Conflicting Stakeholders

Complex projects often have stakeholders with genuinely incompatible interests. The engineering team wants more time for quality; the business wants faster delivery. The operations team wants stability; the product team wants rapid change. The legal team wants comprehensive review; the project team wants expedited approval.

Stakeholder conflicts that are not explicitly managed tend to be resolved at the project level — by the project manager making trade-off calls that should be made at a higher level — or to persist unresolved, slowing the project as decisions wait for conflict resolution.

The resolution is escalation: stakeholder conflicts should be surfaced to the level of the organization that can make a binding decision about the trade-off, rather than being managed at the project level indefinitely.

The Silent Stakeholder

Some stakeholders are silent in the planning process and become vocal at the worst possible moment — when the project is delivering, when they first see the output, or when the impact of the change reaches them directly.

Silent stakeholders are often the people who will be most directly affected by the project's outputs: the employees whose jobs will change, the users who will have to learn a new system, the customers who will experience a new product. They do not engage during planning because they are not part of the formal project process, and they surface during implementation because that is when the reality of the change reaches them.

Proactive engagement with likely-silent stakeholders — seeking them out before they have reason to object, involving them in design decisions, preparing them for what is coming — is significantly less costly than reactive management of their objections after the fact.

Communication Planning for Stakeholders

Effective stakeholder management requires a deliberate communication plan — not a single template but a set of decisions about what each stakeholder group needs to know, how often, through which channel, and from whom.

The what-who-when-how-from whom framework:

For each significant stakeholder group:

  • What: What information do they need? (Full project detail, summary status, specific decisions requiring input, milestone achievements)
  • Who: Which group of people are receiving this communication?
  • When: What cadence? (Weekly, monthly, at milestone, on-request)
  • How: What channel? (Email, meeting, written report, dashboard, informal conversation)
  • From whom: Who sends or delivers this communication? (Project manager, sponsor, subject matter expert)

The framework reveals communication gaps (stakeholder groups that have no defined communication plan) and communication overload (stakeholder groups receiving more information than they need or want).

Example: Google's internal project communication culture explicitly addresses the question of "who needs to know what, when." Their concept of "working in the open" — making project status, decisions, and rationale visible to interested parties without requiring them to actively seek it — reduces the communication planning overhead by making information available rather than pushed. The opt-in model does not replace active communication to critical stakeholders, but it reduces the risk of important stakeholders being unaware of developments.

Managing Resistant Stakeholders

Some stakeholders will oppose a project. Resistance may be legitimate (the project has flaws that the resistant stakeholder has identified) or illegitimate (resistance based on political positioning, loss aversion, or misunderstanding).

Diagnosing resistance is the first step. Common resistance types:

  • Rational resistance: The stakeholder has identified a real problem with the project. This resistance is valuable — it should be taken seriously and either incorporated into the project design or explicitly addressed with reasoning.
  • Loss-based resistance: The stakeholder's resistance is based on what they will lose — status, resources, control, familiar work patterns. This resistance requires empathy and engagement with the underlying concerns rather than argument about the project's merits.
  • Uninformed resistance: The stakeholder is resisting based on incorrect information or misunderstanding. This resistance resolves with better communication.
  • Political resistance: The stakeholder is opposing the project for political reasons unrelated to its merits — because it benefits a rival, because they were not involved, because it was not their idea. This resistance requires relationship management rather than communication.

The common mistake is treating all resistance as uninformed resistance and responding with more communication about the project's merits. Stakeholders who are resisting for loss-based or political reasons will not be converted by better information.

For related frameworks on communication dynamics in organizations, see cross-team communication and leadership communication explained.

What Research Shows About Stakeholder Management and Project Outcomes

The empirical literature on stakeholder management has grown substantially since R. Edward Freeman of the University of Virginia's Darden School of Business established the foundational theoretical framework in Strategic Management: A Stakeholder Approach (1984). The practical application of that framework to project management has been studied extensively, and the findings are consistent: stakeholder management quality is among the strongest predictors of project success, independent of technical complexity, team capability, or methodology.

Prosci, the change management research organization, has published annual benchmarking studies on change project outcomes since 1998. Their 2021 study, based on data from more than 1,700 organizations across 65 countries, found that projects with excellent stakeholder management were 6 times more likely to meet or exceed project objectives than those with poor stakeholder management. More specifically, projects with active and visible executive sponsorship -- one dimension of stakeholder management -- were 3.9 times more likely to succeed. Prosci's longitudinal data shows that executive sponsorship has consistently been the top contributor to project success across all 11 editions of their study, ranking above project management methodology, communication quality, and training effectiveness.

Kerstin Stelzer and colleagues at the Technical University of Munich published research in the International Journal of Project Management (2017) analyzing stakeholder engagement patterns in 230 infrastructure and IT projects across Germany, Austria, and Switzerland. Projects that conducted formal stakeholder identification and power-interest analysis at initiation completed within 15 percent of original budget at a rate of 64 percent, compared to 38 percent for projects without formal stakeholder analysis. The most significant variable was not the analysis itself but whether the analysis identified stakeholders who could delay or block the project: projects where blocking stakeholders were identified early and engaged proactively experienced significantly fewer mid-project disruptions.

Aaron Shenhar and Dov Dvir of the Stevens Institute of Technology, analyzing 600 projects across defense, civil engineering, and software development in research published in MIT Sloan Management Review (2007), found that stakeholder satisfaction -- measured six months after project completion -- was poorly correlated with on-time and on-budget delivery. Projects that delivered on time but produced outputs that did not meet evolving stakeholder needs scored lower on long-term success measures than projects that were somewhat late but maintained continuous stakeholder alignment throughout development. The finding challenges the assumption that schedule adherence is the primary indicator of project success, suggesting instead that sustained stakeholder alignment better predicts the outcome that actually matters: stakeholders using and benefiting from the project's outputs.

John Kotter of Harvard Business School, whose eight-step model for organizational change has been applied to major change projects since its publication in Leading Change (1996) and A Sense of Urgency (2008), documented through case studies spanning 150 organizations that the most common cause of change project failure was insufficient coalition building in the project's early stages. Kotter found that projects whose sponsors attempted to drive change without building a broad enough coalition of influential stakeholders failed at a rate of 70 percent, consistent across industry and project type. Projects that invested in explicitly recruiting influential stakeholders into active support roles -- not merely informing them -- succeeded at more than twice the rate of those that did not.

The Project Management Institute's Pulse of the Profession 2020 report, based on survey data from 4,455 project professionals in 81 countries, found that 33 percent of project failures could be attributed to a single cause: stakeholder misalignment at project initiation. This exceeded technical risk (21 percent), resource constraints (26 percent), and scope creep (28 percent) as standalone failure drivers. The finding is consistent across the 15 years of PMI's Pulse data: stakeholder alignment is always in the top three predictors of both project success and failure.

Case Studies in Stakeholder Management: Success, Failure, and Recovery

Real-world examples illustrate the mechanisms by which stakeholder management produces its documented effects on project outcomes.

The London 2012 Olympic Games construction program, delivered on time and essentially within the revised budget of 9.3 billion pounds after significant cost increases from the original 2.4 billion estimate, has been studied by researchers at University College London and the Bartlett School of Construction and Project Management as an exemplar of large-scale stakeholder management. David Stubbs and colleagues, writing in Project Management Journal (2014), identified the Olympic Delivery Authority's (ODA) stakeholder management approach as a critical success factor. The ODA maintained a stakeholder map of more than 800 distinct groups, conducted quarterly satisfaction assessments with the 50 most influential stakeholders, and employed a dedicated stakeholder engagement team of 12 people. The approach enabled the delivery team to identify and address concerns from local boroughs, transport authorities, and heritage organizations before they escalated to project-threatening opposition. The contrast with the original Wembley Stadium reconstruction (delivered two years late with significant contractor disputes) provides context: the Wembley project had no formal stakeholder management process.

Heathrow Terminal 5 (BAA, completed 2008) provides a case study in internal stakeholder management. Project director Andrew Wolstenholme documented, in papers published through the Institution of Civil Engineers, that BAA deliberately changed the contractual and cultural relationship with its 80 contractor organizations to manage them as collaborative stakeholders rather than adversarial vendors. The mechanism was integrated project insurance: all contractors shared a single insurance policy, meaning no party benefited financially from disputes. This structural change transformed the stakeholder dynamic from competitive (minimizing cost by maximizing claims) to collaborative (minimizing total project cost). The project completed on time and within its revised budget of 4.3 billion pounds -- a rare outcome for a project of its scale and complexity.

The Iridium satellite phone project (Motorola, 1987-1999) is studied at MIT Sloan and London Business School as a case study in the consequences of stakeholder management failure. Iridium's business model assumed that business travelers would pay $3,000 for handsets and $3-7 per minute for calls to reach locations not served by mobile networks. The product was technically delivered as specified and on schedule. It failed catastrophically: the company filed for bankruptcy in August 1999, nine months after launch, having spent $5 billion and enrolled only 10,294 subscribers against a breakeven requirement of 500,000. Post-mortem analysis by Howard Anderson at MIT, published in Technology Review (2000), found that the product's core stakeholders -- the business travelers who would use it -- had not been meaningfully consulted during the 11 years of development. By the time Iridium launched, mobile phone coverage had expanded to cover most of the locations where Iridium was intended to be used, at a fraction of the cost. The external stakeholder group that mattered most had been overlooked in favor of internal technical and financial stakeholders whose concerns the project did address.

The UK National Programme for IT (NHS Connecting for Health, 2003-2011), the largest civil IT project in history at an eventual cost of approximately 10 billion pounds, was abandoned without delivering its primary objective -- a national electronic patient record system accessible across all NHS organizations. The National Audit Office's 2011 report identified stakeholder management failure as the primary cause. Clinical staff, the people who would use the system daily, were not systematically consulted during requirements definition. When systems were delivered, clinical staff resistance was so widespread that adoption remained below 30 percent in the hospitals where systems were installed. The project had managed its commercial and government stakeholders effectively -- contracts were signed, governance was maintained, budgets were controlled -- while failing to manage the operational stakeholders whose adoption would determine whether the investment delivered value.

References

Tags

project-management stakeholder-management communication leadership work-skills

Frequently Asked Questions

How do you identify all relevant stakeholders for a project?

Identifying stakeholders requires systematic mapping beyond obvious participants to include anyone who affects or is affected by the project. Start with direct stakeholders: project sponsors who fund it, team members who build it, and customers or users who will use it—these are obvious but just the beginning. Identify decision-makers and approvers: anyone whose sign-off or approval you need at any stage, including executives, compliance officers, legal teams, or security reviewers. Find dependent teams: groups whose work depends on your project completing, or whose work your project depends on—integration partners, downstream consumers of your outputs, or upstream providers of your inputs. Consider influencers: people without formal authority but whose opinions affect project support, like respected technical leaders, domain experts, or informal organizational leaders. Don't miss support functions: IT operations who will maintain your system, customer support who will field questions about it, training teams who will onboard users, or documentation teams who will write about it. Include impacted employees: people whose workflows, tools, or responsibilities will change due to the project—they're stakeholders even if they're not directly involved. Look for regulatory or compliance stakeholders: industry bodies, auditors, or government agencies whose requirements constrain the project. Identify budget holders beyond just the sponsor: finance teams who control spending, procurement teams who manage vendors, or department heads whose budget might be affected. Find external stakeholders: vendors, partners, industry analysts, or even competitors whose actions might affect the project. Use the RACI framework (Responsible, Accountable, Consulted, Informed) as a checklist: for each major activity or deliverable, who needs to be in each category? Ask current stakeholders 'Who else should we involve?' to find stakeholders you've missed. The goal is complete visibility: overlooked stakeholders who emerge late become project risks.

What is stakeholder analysis and how do you prioritize stakeholder needs?

Stakeholder analysis is systematically assessing stakeholders' interests, influence, and involvement needs to allocate your limited attention appropriately. Map stakeholders on two dimensions: power/influence (their ability to affect project success) and interest/impact (how much the project affects them or how much they care). This creates four quadrants: High power, high interest stakeholders need close management—frequent updates, involvement in decisions, and proactive relationship building. These are typically sponsors, key executives, or major users whose support is critical. High power, low interest stakeholders need to be kept satisfied—regular updates to maintain awareness and prevent surprise objections, but don't over-engage or waste their time with unnecessary details. These might be executives whose approval you need but who aren't day-to-day involved. Low power, high interest stakeholders need to be kept informed and often make great contributors—they care deeply and can provide valuable input, testing, or advocacy, even without formal authority. These are often actual users, support teams, or domain experts. Low power, low interest stakeholders need minimal monitoring—occasional updates or mass communications without personalized attention. Beyond power/interest, assess each stakeholder's likely position: supporter, neutral, or resistor. Supporters need to be enabled and leveraged: how can they help advocate for the project? Resistors need to be understood and addressed: what are their concerns and how can you mitigate them or shift their position? Neutrals are opportunities: can you provide information or address concerns to move them to supporters? Also identify stakeholders' preferred communication style: some want detailed documentation, others prefer brief conversations; some want to be involved in decisions, others just want to know outcomes. Prioritization means matching effort to impact: spend the most time on high-power, high-interest stakeholders who are currently neutral or resistant—they can make or break the project. Spend less time on low-power stakeholders regardless of interest level, and on supporters who already back you. The goal is strategic relationship management, not treating everyone equally.

How do you manage conflicting stakeholder expectations and priorities?

Managing conflicting stakeholder expectations requires surfacing conflicts early, facilitating resolution, and establishing clear decision-making authority. First, make conflicts visible: when stakeholder A wants feature X and stakeholder B wants the opposite, document both positions explicitly rather than hoping the conflict will resolve itself. Avoid the temptation to tell each stakeholder what they want to hear—this guarantees later disappointment. Facilitate direct conversation between conflicting stakeholders when possible: 'Sales wants flexibility in the UI and Engineering wants consistency; let's discuss the tradeoffs together.' Sometimes conflicts resolve when stakeholders understand each other's constraints and priorities. Use data to depersonalize disagreements: instead of 'your opinion versus their opinion,' frame as 'what does user research show?' or 'what do the business metrics suggest?' Connect conflicts back to project goals and success criteria: 'Given our primary objective of X, which approach better supports that?' helps stakeholders see beyond their individual preferences. Escalate to defined decision-makers when conflicts can't be resolved collaboratively: this is why having clear governance and decision authority matters. Document decisions and rationale so stakeholders understand why their preference wasn't chosen and feel heard even in disagreement. Sometimes you can satisfy conflicting needs through creative solutions: phased approaches where you deliver one stakeholder's priority first then another's, or hybrid solutions that partially address both. Use prioritization frameworks: if Sales wants feature A and Marketing wants feature B, but you can't deliver both, which creates more value or addresses more users? Manage expectations about what's negotiable versus fixed: some constraints (regulatory requirements, budget limits, deadlines) aren't up for stakeholder vote. Avoid false consensus: if stakeholders publicly agree but you suspect private disagreement, probe deeper: 'So we're all aligned that X is the priority over Y, even though Y won't make this release?' The goal isn't making everyone happy—it's making clear decisions with full stakeholder input, then moving forward even when some stakeholders are disappointed.

What communication strategies work best for different types of stakeholders?

Effective stakeholder communication requires tailoring content, frequency, and format to each stakeholder group's needs and preferences. Executives need concise, high-level updates focused on business impact, risks, and decisions they need to make: use executive summaries with key points up front, quantify everything possible (costs, timelines, benefits), and highlight what you need from them. Monthly or milestone-based updates are typically sufficient unless they request more. Project sponsors need more detail than executives but still business-focused: progress against goals, budget status, major risks, and decisions where you need their guidance or approval. Regular (weekly or bi-weekly) updates via brief written status reports or quick calls work well. Team members need operational detail: what's expected, what's blocking them, and decisions affecting their work. Daily standups or Slack updates provide real-time coordination. Dependent teams need interface information: what you're delivering, when, and any changes affecting their work. Communicate proactively when schedules or specifications change, using shared documentation or technical reviews. Users or customers need context about what's changing and why, how it affects them, and when: use plain language avoiding technical jargon, provide concrete examples and timelines, and offer channels for questions and feedback. Compliance or legal stakeholders need evidence and documentation: detailed specifications, process documentation, and audit trails. Formal written communication is often required. For all stakeholders, match their communication preferences: some prefer email, others Slack, others meetings. Ask how they want to be engaged. Use push versus pull strategically: proactively push critical information and decisions; make detailed information available for stakeholders who want to pull it. Create information layers: executive summaries for quick scanning, detailed sections for those who want more depth. Maintain regular rhythm: consistent update schedules build trust better than sporadic communication. Most importantly, two-way communication matters: create channels for stakeholders to ask questions, raise concerns, and provide input—communication isn't just broadcasting updates.

How do you maintain stakeholder engagement throughout long projects?

Maintaining engagement over long projects requires demonstrating progress, providing involvement opportunities, and preventing stakeholder fatigue. Show visible progress regularly through working demos, not just status reports—seeing actual functionality maintains interest and confidence better than written updates. Break projects into meaningful milestones with clear deliverables so stakeholders see completion points rather than endless work-in-progress. Celebrate wins explicitly: when major milestones complete, acknowledge them to stakeholders to maintain momentum and morale. Provide appropriate involvement opportunities: some stakeholders want to be in working sessions providing input; others just want to review outcomes. Offer both but don't force participation—mandatory attendance at meetings stakeholders don't value breeds resentment. Maintain communication rhythm but avoid over-communication: too many status updates create fatigue where stakeholders start ignoring communications. Weekly updates for six months might need to shift to bi-weekly or milestone-based as the project becomes routine. Keep communications relevant: don't send blanket updates to all stakeholders; segment communications so people only receive information pertinent to them. Rotate communication formats to maintain interest: alternate between written updates, demos, working sessions, and informal check-ins rather than always using the same format. Make it easy to stay informed with low effort: executive dashboards, one-page status summaries, or automated reports let stakeholders maintain awareness without significant time investment. Proactively address concerns and incorporate feedback: when stakeholders raise issues and see them acted upon, they stay engaged; when feedback disappears into a void, they disengage. Manage scope and timeline expectations transparently: if the project is delayed or scope changes, communicating honestly maintains trust better than pretending everything is fine. Periodically remind stakeholders of project value and progress toward goals: it's easy to lose sight of why the project matters in the middle of long execution. For very long projects, consider formal checkpoint reviews where stakeholders can assess whether to continue, adjust, or cancel—this gives them meaningful decision points rather than passive observation. Finally, don't assume initial enthusiasm will persist: engagement requires continuous cultivation, not just strong kickoff.

Share this article