Consulted Is Not Coordinated

Ask a team whose programme has quietly stopped moving what went wrong, and you will rarely hear that nobody was asked. Consultation happened. There were interviews, a workshop, a survey with a respectable response rate. The stakeholder register exists and it is thorough.

And yet the thing is stuck.

Consultation produces information. Coordination produces movement.

A consultation asks each group what it thinks, one group at a time, and returns a set of positions. That is genuinely useful — it tells you where the disagreement lives. What it does not tell you is whether any two of those groups can act together, in what order, and on whose authority.

Coordination is a different object. It concerns the relationships between stakeholders rather than the views held by each: who needs what from whom, which handover has no owner, and which pair of organisations has never had a reason to trust each other and is now expected to.

Societal impact depends not only on the technical quality of an innovation, but on the quality and structure of stakeholder collaboration.

A project can score well on consultation and near zero on coordination. Those projects are the ones that stall, and they stall late — after the funding decision, after the pilot, at the point where somebody has to hand something to somebody else.

Three failures that read as resistance

When coordination is missing, the symptoms are usually attributed to individuals or to politics. More often they are structural, and they repeat:

• The unowned handover. Two parties each believe the other is responsible for a step. Nobody is obstructing anything; the step simply has no owner, and the delay gets read as reluctance.

• The asymmetric ask. One group is expected to carry cost or risk early in exchange for benefit that arrives late, or arrives to someone else. Their hesitation is rational and is usually described as scepticism.

• The absent condition. A group would participate, but only if something else is true first — a legal clarification, a peer already committed, a guarantee about data. The condition is never stated because nobody asked for conditions, only for opinions.

None of these are visible in a stakeholder list. All three are visible in a map of needs, offers, and conditions.

What to map instead

The shift is from cataloguing actors to describing exchanges. For each significant relationship, three questions do most of the work:

1. What does this party need in order to move, stated concretely enough to be satisfied or refused?

2. What can it offer that another party needs — capability, mandate, data, legitimacy, reach?

3. What has to be true first for the exchange to be acceptable to both sides?

Answering these turns a diagram of boxes into a set of testable claims. Claims can be checked, and where they fail, the failure has an address: a named condition between two named parties.

A test you can run this week

Take the next milestone your programme owes someone. Write down the handover it depends on — the moment work passes from one organisation to another. Then answer, without asking anyone: who owns the step, what do they need that they do not have, and who else has to agree first.

If you can answer all three with confidence, coordination is not your problem. If any answer is a guess, you have found the place the project will stop, and you have found it while it is still cheap to fix.

That is the practical case for treating collaboration as something to be designed rather than convened. Consultation tells you what people think. Coordination tells you what will actually happen next — and it is the second one that carries the delivery date.