You have a stakeholder list. It is wrong in a predictable way: it contains everyone who has to approve, and almost nobody who can stop things.

Those are different populations. Approval is visible, sequential, and mostly cooperative. Stopping is quiet, arrives late, and doesn’t require anyone to say no.

The map you were given

Most stakeholder maps are org charts with a RACI grid over them. They answer the question who signs, which matters, and they miss the question that decides outcomes: who can make this not happen without ever refusing.

Purchases rarely die at a decision point. They die in the gap between two functions, where each assumed the other had it, and the gap is invisible until the thing you bought is sitting in a queue.

Seven months in a queue

Composite from a few industrial deployments: an engineering and manufacturing group, roughly 11,000 employees across several countries, a predictive maintenance and inspection-support purchase.

Textbook process. Business case approved. Security review passed in nine weeks, which for that organization was fast. Legal negotiated a decent contract. Signature in month five, celebration email, the sponsor mentioned it at a town hall.

Then the deployment needed to authenticate against the corporate identity system, integrate with two operational data sources, and pass a works council consultation because it touched how field technicians were assigned work.

The platform team who own identity had not been consulted at any point. They weren’t opposed. They had a queue, and the queue was, illustratively, about seven months for anything requiring a new integration pattern. Nobody in that team ever said no. Nobody had to.

The works council consultation added a further period, and would have taken far less if it had begun in month two instead of month six, because by month six the contract was signed and the consultation looked like a formality being performed on a decision already made. Which it was, and they said so.

Total elapsed time from signature to a technician using it: over a year. License clock running throughout. Sponsor’s attention gone by month eight.

Not one of those groups behaved unreasonably. Each was doing its job at its normal speed, having been given the work at the last possible moment.

The map you need

Who	What they can do to you	When they should enter	The question they’ll ask
Sponsor	Pays, and loses interest	Week one, then every six weeks	Is this still the thing we said it was
Security	Blocks late, expensively	Before the shortlist	What data leaves, and to where
Data protection	Blocks late and permanently	Before the pilot touches real data	What is the lawful basis, and can it be undone
Platform and identity	Silent veto by queue	Week two, always	What integration pattern, and is it one we already support
The operating team	Silent veto by non-adoption	Before the demo, not after	Does this make my Tuesday better or worse
Employee representation	Consultation you cannot skip	Before signature, ideally month two	Who decided this affects how people are assigned work
Procurement and legal	Shape terms, slow the end	Before you name a preferred vendor	Why this one, and what are our exit rights
Internal audit	Arrives afterward with questions	Month one, informally	How will you evidence this worked

The middle four rows are where the damage is.

The two silent vetoes

The queue. A team with a backlog and no stake in your timeline doesn’t need to object. Their default is a date, and the date is theirs. You can escalate, and escalation buys you a place further up a queue that other people are also escalating into.

The fix is embarrassingly simple and almost never done: ask, in week two, what integration pattern this will need and whether it’s one they already support. If it is, you have a short queue. If it isn’t, you’ve just discovered the real timeline of your project, months before you’d otherwise have found it.

Non-adoption. The operating team doesn’t refuse. They use it for three weeks, the exceptions pile up, someone builds a spreadsheet workaround, and the tool becomes a step people perform rather than a thing people use. Utilization reports show green. Nothing improves.

This one is prevented in the same way, earlier. Put two people who’ll actually use the thing in front of the demo, and give them permission to be rude about it. They’ll ask the three questions that break it, which is the subject of a later lesson, and they’ll tell you within an hour whether it fits how the work is genuinely done as opposed to how the process document says it is.

Early is cheap

The principle underneath all of this: anyone who can stop the project later should be given the chance to stop it early, when stopping it costs almost nothing.

That feels backwards. You’re inviting objection into a process you’d rather keep moving. And yes, it will slow you down, by a few weeks in the front half.

But an objection in month two is a design constraint. The same objection in month six is a delay, and in month nine it’s a write-off. The people you’re avoiding are not going away. You’re choosing when to meet them, and the only variable you control is how expensive the meeting is.

One practical note on how to do it. Bring these groups a decision, not an update. “We’re planning to evaluate three vendors for this problem, here’s what it will touch, what would make you say no” gets you engagement. “Here’s an update on our AI initiative” gets you a nod and no information, and they’ll remember having been informed rather than consulted, which is worse than not having gone.

One thing to do differently

Name the two people who could stop this without ever saying the word no. Usually it’s whoever owns the integration you’ll need and whoever manages the team who’ll use it.

Go and see both of them in week one. Not to inform them. To ask what would make this fail, and to write down the answer.