Who Can Stop You: Building a Stakeholder Management Plan for IT Projects

Most stakeholder plans are a power and interest grid drawn in week one and never opened again. They record who cares. They do not record who can stop the project, what would make them do it, and what it costs when they do. PMI's 2026 Pulse of the Profession found that delays in stakeholder decision-making are the single most common consequence of poorly managed complexity, reported by 34% of respondents. A plan that prevents that delay has three parts: a register built around veto power rather than sentiment, a trigger for each stakeholder who holds one, and a review cadence that reassesses the list as the project changes shape. This guide covers all three, with a worked example from an integration build.

Introduction

Every stakeholder plan I have inherited had the same four-quadrant grid. High power, high interest, top right. Manage closely. Everyone nodded at the kickoff, the slide went into the project folder, and nobody looked at it again until a director nobody had listed refused to sign off on the data migration in month five.

The grid answered a question nobody was asking. Interest is not the variable that decides whether a project ships. The variable is the ability to stop it, and that is a different map.

What is stakeholder management, and why do most plans fail?

Stakeholder management is the work of identifying everyone who can affect a project's outcome, understanding what each of them needs and can withhold, and engaging them at the moment their decision is required rather than after it has been missed.

The definition sounds simple, and the plans built on it fail for a specific reason: they are written once, at the point of least information, and treated as complete.

PMI's 2026 Pulse of the Profession, drawing on 2,023 project professionals and 511 senior leaders across 35 countries, found that delays in stakeholder decision-making are the most common negative outcome of poorly managed complexity, reported by 34% of respondents, ahead of missed deadlines and budget overruns.^[1] The same report found that high-performing teams practise phased stakeholder engagement, reassessing who needs to be involved as the project moves, more often than low performers do.

Read that as a diagnosis. The stakeholder problem on most projects is not hostility. It is a decision that sat with someone for three weeks because the plan did not say it was theirs, did not say when it was due, and did not say what happened to the schedule while it waited.

Key Takeaway: The plan's job is to prevent a decision from waiting. Everything else is secondary.

Running a multi-system build with a sign-off chain you have not mapped yet? Our Planning practice builds the register and the decision calendar together. Book a free consultation.

What belongs in a stakeholder management plan?

A register with six columns, a trigger for every stakeholder who can stop something, and a date on every decision the project needs from them. That is the whole document. Anything else is decoration.

The columns matter because each one forces a question the power and interest grid lets you skip.

Two of those columns do most of the work. "What they can stop" turns a list of interested parties into a list of gates. "What would trigger it" turns a vague risk into something you can design around, because once you know the finance director will withhold sign-off above 0.5% variance, you can build the reconciliation to prove you are under it before you ask.

The last column is the one that gets the plan read. Executives do not open stakeholder registers. They do open a table that says a specific late decision costs a month.

On integration and migration builds, the register is usually missing the person who owns the data in the system being retired, because that person was never on the project org chart. ID Business Analysis Canada builds the stakeholder register as a deliverable of every Requirements Engagement, with a business analyst tracing each interface and data object back to the named owner who can withhold sign-off on it, so that the register is complete before mapping starts rather than discovered at cutover.

Key Takeaway: Six columns, one row per person who can stop something. If a row has no entry under "what they can stop," ask whether they belong in the plan at all.

How do you map who can stop the project?

Start from the gates, not from the org chart. List every point where the project needs a yes to proceed, then ask who gives it, and who could refuse it even though they are not the official approver.

That second group is where projects get stopped. The official approver of a release might be the delivery lead. The person who can stop it is the security architect who has not reviewed the integration pattern, the union representative whose members' screens are changing, or the regional manager who will simply not adopt it. None of them appears on a RACI as an approver. All of them appear on this map.

Four categories of stopping power to look for:

• Formal sign-off. Gate approvers, budget holders, change board members. Visible and usually already known.
• Withheld input. People whose data, access, or expertise the project cannot proceed without. Often outside the project, often unaware they are on the critical path.
• Compliance and control. Security, privacy, legal, audit. They can stop a release without ever attending a status meeting.
• Adoption. Operational leaders who can make a delivered system fail by not using it. Rarely mapped, and the most expensive to discover late.

The pattern we see on programmes that stall is that the register covers the first category well and the other three not at all.

Key Takeaway: Map from the gates backwards. Every gate has an official approver and at least one unofficial one.

How do you keep the plan alive after week one?

Give it a cadence and a trigger for revision, and put the decisions it contains on the same calendar as the delivery milestones.

The plan decays for a structural reason. Stakeholders change as the project moves from design to build to cutover, and the plan is written at the start of design. By the time the cutover stakeholders matter, the document describing them is three phases old.

Three practices that stop the decay:

• Review the register at every phase boundary. Not every week, which nobody sustains, but at every point where the nature of the work changes. Design to build, build to test, test to cutover. Ask who is new, who has left, and whose stopping power has changed.
• Put every decision due on the delivery calendar. A decision is a milestone. If the reconciliation rule needs approval by week nine for cutover in week fourteen, week nine is on the plan next to the build tasks, with a named owner, and it goes amber the moment it slips.
• Report waiting decisions, not sentiment. Status reports that say "stakeholder engagement: green" are reporting a feeling. Reports that say "two decisions waiting, oldest is eleven days, cost of a further week is the cutover window" are reporting a fact someone can act on.

How to manage stakeholders effectively comes down to that last point. Most engagement problems are not relationship problems. They are visibility problems, where a decision is waiting and nobody senior can see it.

Key Takeaway: Decisions are milestones. Put them on the plan, give them owners, and report them when they slip.

What does a project stakeholder management plan look like on a real IT build?

The shape is easiest to see on an integration-heavy build, because that is where the unmapped stakeholders live.

Consider the pattern we see on a customer platform replacement touching four systems. The kickoff register listed eleven people: sponsor, steering committee, product owner, department heads. All formal approvers. Working back from the gates, three more appeared. The finance systems owner who controlled the nightly extract the new platform depended on and had not been told the format was changing. The privacy officer whose approval was needed for the customer data flow and who had a six-week review queue. The contact centre team lead whose agents would be the first users and who had already decided the new screens were slower.

None of the three could be found on the org chart of the project. Two of the three could stop the launch outright, and the third could make it fail after launch. The register gained three rows, three triggers, and four dated decisions. The privacy review moved from an unplanned month-five surprise to a planned week-three submission.

That is the whole value of the exercise. Not better relationships, though those help. Three decisions that would have been discovered late, discovered early instead.

Key Takeaway: On any multi-system build, expect to find stakeholders with stopping power who are not on the project org chart. Go and look for them.

Frequently Asked Questions

What is the difference between a stakeholder register and a stakeholder management plan?The register is the list: who they are, what they can stop, what would trigger it, and what they need to say yes. The plan is the register plus the cadence for reviewing it, the decisions each stakeholder owes the project with dates, and the reporting that makes waiting decisions visible. A register without the plan around it becomes a static document by the second phase.

How is stakeholder management different from stakeholder engagement?Engagement is the activity of communicating with and involving stakeholders. Management is the discipline of deciding who needs to be engaged, about what, when, and with what evidence, so that engagement happens at the point a decision is needed rather than as a standing communication rhythm. Good engagement without management produces well-informed stakeholders who are still asked for decisions too late.

How do we start building a stakeholder management plan on a project that is already running?Start from the next three gates, not from the beginning. List every yes the project needs to pass them, name the official and unofficial approvers for each, and build the six-column register for those people first. ID Business Analysis Canada runs this as a two-week piece of work inside an existing program, with a business analyst producing the register, the trigger for each stakeholder, and the dated decision calendar for the coming phase, so the plan is useful from the next gate rather than complete on paper. Backfill the earlier phases only if a decision from them is still open.

Is stakeholder management risk the same as project risk?It is a category of project risk, and usually the least well-recorded one. Most risk registers hold technical and schedule risks in detail and stakeholder risk as a single line, if at all. Each row in the six-column register is a risk statement: a named person, a condition under which they withhold a decision, and a cost if they do. Moving those into the risk register, with the same owner and review cadence as everything else, is the single change that most improves how stakeholder risk gets handled.

Conclusion

The power and interest grid is not wrong. It is answering a question that does not decide outcomes. Who can stop the project, under what condition, and what a week of waiting costs are the questions that do, and a plan built on them fits on two pages and gets opened.

If you are running an IT build where the sign-off chain has never been mapped from the gates backwards, ID Business Analysis Canada's Planning practice produces the stakeholder register, the trigger for each person on it, and the decision calendar as one deliverable. Book a free consultation and we will start with your next three gates.

Sources

1. Project Management Institute, Pulse of the Profession 2026: Driving Success in Complex Projects, 2026, Figure 5. https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse-of-the-profession_2026_pdf.pdf