The three people who decide whether it survives

Most deployments that fail technically correct fail politically simple. The budget holder approved it, the system works, and nobody uses it. The cause is almost always the same: the people with the three different kinds of power were treated as one person.

Three powers, rarely in one person

The sponsor can spend money and defend the project in a room you are not in. Their interest is usually a number on their own scorecard, and it is usually not the number in your metric table. Ask what they will be asked about at the end of the quarter.

The owner runs the process the deployment changes. They can say yes to adoption, and they are the person whose head is on the line when the new process breaks on a busy day. They are also the person most able to stop it without ever saying no — by not telling their team.

The operator does the work. They have the least formal power and the most practical veto. Every deployment that dies of "nobody uses it" died here, in a hundred small decisions to keep using the old sheet.

A fourth role matters in some organisations: the blocker with standing, often IT security or a works council or a long-serving middle manager who was not consulted. They rarely win openly and they rarely need to.

The discovery move

In the first session, draw the three names and one line of text each: what they gain, what they lose, what they are measured on. Then verify the map — not by asking "who is the sponsor", which produces the org chart, but by asking: who will be annoyed if this works, and what will they say?

Anyone who can be named as "annoyed if this works" is on the map, and the answer usually surfaces the operator's real fear: that the system will be used to measure them.

What each one needs to hear

Role	The question they are actually asking	What answers it
Sponsor	"Will this show up on my review as a win or a cost?"	One number, moving, in their vocabulary, before the quarter ends
Owner	"What happens to my Tuesday if this breaks?"	A named fallback, and a person to call
Operator	"Is this going to judge me?"	Evidence that the system reports the process, not the person
Blocker	"Was I consulted, and is the risk bounded?"	A written boundary, the data flow, and a review date

Most of those answers are cheap and most projects never produce them. A one-page fallback procedure costs an hour and buys the owner's cooperation; a line in the design note saying the tool records case outcomes rather than individual keystrokes costs nothing and removes the operator's main reason to sandbag.

The meeting that predicts month two

Ask for a session with the owner and the operator together, without the sponsor. Twenty minutes, one question: walk me through the busiest day of the month, and tell me where this would get in the way.

Two outcomes are informative. If they describe the busy day in detail and name concrete clashes, you have a partner and a scope. If they describe a process that does not resemble what the sponsor described, the sponsor's version is a wish and you have found that out before building. If they will not meet without the sponsor present, the deployment has no owner, whatever the signature says.

What to do when the map is wrong

Three repairs, in order of preference.

1. Get the operator a win in week one. Small, visible, reduces their work rather than adding a step. Adoption is a sequence of decisions made by tired people, and the first one has to cost nothing.
2. Give the owner a fallback they can operate. A documented way to switch off, with their name on the runbook, converts a threat into a tool they control.
3. Escalate the missing sponsor only when the project is already dying. Escalation converts a quiet problem into a visible one, which is sometimes necessary and always expensive.

The honest limit

An FDE cannot create executive sponsorship, cannot fix a broken incentive, and cannot make an operator trust a system that their manager intends to use against them. Recognising that early is not defeat; it is the difference between a two-week investigation that ends with a clear "this cannot succeed until X changes" and a six-month build that ends with the same sentence, spoken by someone else.

How to write down what the map tells you belongs in the discovery output; how adoption gets measured afterwards is the four-week rule; and why the sponsor's sign-off alone is not enough is the second case in the case library.