If you are reading this, you are almost certainly already familiar with the scenario: an association, several partners, teams in different countries, a funding institution that requires reporting, a partner that works with its own method… and you in the middle, trying to get the work done without everything turning into a chain of emails.
In these contexts, most “communication problems” are not solved with a better-written message.
They are solved when you treat communication for what it really is: a coordination system. A system that defines who decides, when to speak, where it is recorded, which channel is in charge, and how to learn so that the same fire does not break out every two weeks.
I call this “communication as an operating system.” And yes, it sounds technical. But it is one of the most practical ideas you can apply in a network of partners or a public-private partnership.
An operating system is not a nice idea. It is a set of simple rules that allows many pieces to work together without colliding every five minutes.
In a multi-stakeholder network, communication fulfils this function when it is well designed: it brings order to coordination. It is the mechanism that prevents the project from depending on the memory of two people, or the goodwill of the team, or the heroism of those who “pull” the cart.
To put it bluntly: in projects with many partners, communication ceases to be “messages” and becomes coordination governance.
This implies, at a minimum, five questions that should be answered early on:
When these questions remain unanswered, project partners often compensate by holding more meetings, creating more threads and channels. It’s human nature. But the result is usually the opposite of what is desired: more noise and less progress.
The European Union has a mechanism for coordinating the political response to large and complex crises: the Integrated Political Crisis Response (IPCR). Its objective, put simply, is to support rapid, coordinated decision-making at the European political level during cross-cutting crises.
What is interesting is not the “name” of the mechanism, but the logic behind it: the IPCR includes elements for sharing information and building a common understanding of the situation, relying on tools such as an information exchange platform and “situational awareness” products for decision-makers.
In other words, when complexity increases, what sustains the work is not a brilliant message, but a system that organises coordination and information.
That same logic, adapted to the project’s scale, can save you weeks of friction.
If I had to summarise an operational communication system for a partner network project in one sentence, it would be: less improvisation, more shared minimum rules.
There are no rules to control anyone. Rules so that the project does not depend on fatigue, urgency, or each partner’s interpretation.
In an alliance of organisations, the purpose is not a website text. It is a decision-making tool.
It is noticeable when the project lacks a clear purpose: each partner pushes their own priorities, and the meeting becomes a constant negotiation. Not because there is bad faith, but because there is no standard filter.
A practical purpose usually includes three things:
When the purpose is well formulated, discussions are shorter. When it is not…
This is often where the problem lies. And it cannot be solved with good wording.
Governance, in this context, means something particular: who has the authority to finalise a decision, with what prior consultation, and what happens when there is a deadlock.
If there is no clarity, two pervasive patterns emerge:
Both are exhausting. The first because of slowness; the second because of loss of trust.
A simple (and rather elegant) solution is to assign three elements to each relevant decision:
who prepares it, who validates it, and the maximum time frame for finalising it. It seems small, but it changes the project’s atmosphere.
Alliances often break down for a reason that is less epic than we think: a lack of rhythm.
When there is no cadence, everything becomes urgent. And when everything is urgent, priorities are misplaced, decisions are made at the last minute, and communication is stilted.
There is no need for complex architecture. What is needed is consistency: a brief, stable meeting of the coordinating team, periodic reviews of each line of work, and a clear space to resolve blockages or refer them to those who can decide.
The critical detail is not the exact frequency, but the shared agreement: “this is reviewed here”, “this is decided there, “this is resolved in this way”.
From there, communication ceases to be a chain of reminders and becomes a mechanism for progress.
If there is one universal pain point in organisational partnerships, it is this: the “final” document that isn’t.
Traceability is not bureaucracy. It is the basis of order: that anyone (including those who join late or return from holiday) can understand in a few minutes what has been decided, what is still open and where the latest version is.
Above all, traceability means that there is a “place in charge”: a clear repository for documents, a single site for tasks and dates, and a simple rule for naming versions. When that exists, friction decreases.
When it doesn’t, the project becomes flooded with messages like “What’s the latest version?” and “Who’s in charge of this?” And that, cumulatively, costs hours every week.
In complex networks, learning is not about doing an annual assessment. It is about periodically reviewing which part of the system is failing and adjusting one or two rules.
The most helpful thing is usually a mini monthly review with three simple questions:
No recriminations. No finger-pointing. Focus on the system.
At the IPCR, for example, the logic of “situational awareness” exists precisely so that decision-makers can do so with a shared vision and structured information, not with scattered perceptions.
That same principle, on a project scale, translates into learning: less intuition, more evidence of how coordination is working (or not).
When a multilateral project becomes cumbersome, it is tempting to think that “people are not involved” or that “they do not understand each other”. Sometimes this happens. But often the problem lies elsewhere: the system is not designed to facilitate coordination.
There are very recognisable symptoms:
If meetings end without clear decisions, the problem is not a lack of dialogue: it is a lack of a closing mechanism.
If channels multiply and what is important gets lost, the problem is not that people ‘do not read’: it is that there is no channel that sends out relevant notifications.
If documents are repeated and versions overlap, the problem is not “disorder”: it is a lack of traceability.
And if every blockage requires a week of emails, the problem is not individual slowness: it is a lack of governance to escalate and resolve.
I like a simple idea: when the system is sound, even a tired team can function. When the system is bad, even the best team can’t hold out for long.
A common mistake is to think that, to organise a multi-stakeholder network, you have to implement a huge manual. And that usually fails: the project’s complexity doubles.
The alternative is a “minimum viable”: few rules, but clear ones. Here is a realistic four-week roadmap.
The goal of the first week is to answer an uncomfortable question: who closes what?
There is no need to come up with anything sophisticated. List the decisions that really cause friction in your project (e.g. scope changes, delivery validation, external communication, budget approval, schedule).
For each decision, assign:
This immediately shortens many discussions. Above all, it reduces team anxiety: everyone knows their role.
In the second week, the project’s pace is set.
The key is to have regular coordination meetings (short and stable), periodic line-of-work reviews, and a monthly meeting focused on strategic decisions.
This is where it is a good idea to introduce a simple habit: minimal minutes. Not a lengthy document, but a brief record with three elements: what was decided, who will execute it, and by when.
When this is done well, the project ceases to depend on “what everyone understood” and begins to move forward with traceability.
Week three is usually the most liberating if executed decisively.
You choose:
There is no need to prohibit the rest. But the team does need to know what the “rules” are.
In international partnerships, this decision is one of the most profitable: it reduces duplication and lowers the number of fundamental questions per week.
Last week was not devoted to producing more, but to adjusting.
We review which rules are working and which are creating friction. A few changes have been made, and those that have are genuinely effective.
A simple example: during the pandemic, what enabled the coordination of certificate verification between countries was not a campaign, but a common framework. The lesson applies to any network: when coordination fails, what usually fixes it is not talking more, but agreeing on minimum rules and reviewing them when they stop working.
When there are many actors, a standard protocol works better than an avalanche of messages.
Communication in projects with multiple partners is not saved by more emails or more meetings. It is saved when it is treated for what it is: a system that reduces friction, organises decisions and leaves a trace.
If you feel like it, please tell me on LinkedIn what is taking up most of your time right now: endless approvals, version chaos, meetings that don’t get anything done, or competing channels. I’m interested in seeing patterns and how you are solving them in different contexts.
Institutions keep designing messages for public feeds while their audiences make decisions in WhatsApp groups no institutional algorithm can reach. The problem is not technical. It is a question about how trust works when public visibility disappears and what remains are relationships.
When a deepfake involving your organisation surfaces, the first instinct is to treat it as a technical emergency. But what determines the real damage is not the fake content itself — it is what your organisation does, or fails to do, in the hours that follow. That is a communication decision.
Is your team already using AI without clear rules in place? This practical guide shows how to build an AI editorial policy for communication: what to allow, who reviews it, and how to disclose its use without putting trust at risk.