Your EU Project Has a Communication Plan. Does It Have a Working Process?

Insights / EU project communication Your EU Project Has a Communication Plan. Does It Have a Working Process? Review audiences, languages, approvals, channels and content infrastructure. Olena Soinikova · Research & field notes · 10 September 2026 On this page Plan and readiness A route to your audience Languages and versions Approval and risk Channels and capacity Content infrastructure Proportionate preparation The practical check Sources and resources A consortium has a communication plan, a project website and two social media accounts. Six months after kick-off, the first substantial result is ready to publish. Then somebody asks for the latest approved project description.   Three versions appear in the shared drive. The Greek translation was made from an older English text. Nobody is certain whether the participant photographs can be reused. The colleague with administrator access to the website has changed jobs.   The communication plan still exists. So do the website and social accounts. The operating process is less certain.   I see this distinction particularly clearly when several EU-related projects are running at the same time. Communication can look organised at planning level while depending operationally on one colleague remembering where something is stored, which translation is current or who needs to approve a publication.   I call this communication readiness. In practical terms, it means that a project can produce, approve, deliver, maintain and preserve its communication without reconstructing the process each time.   The term is my working framework, not an official EU programme concept. Its components, however, sit underneath many of the communication requirements and recommendations already found across Horizon Europe, Erasmus+, Interreg and other EU programmes. A communication plan documents intent. Readiness tests execution. EU-funded projects already operate within communication and visibility requirements.   All recipients of EU funding have a general obligation to acknowledge the origin of that funding and ensure its visibility. Depending on the programme, projects can also face specific requirements concerning communication activities, websites, social media, events, media relations and other forms of public visibility. The European Commission explicitly advises beneficiaries to check programme-specific funding rules and financing agreements for the details. Horizon Europe adds an important distinction between communication, dissemination and exploitation. Communication makes the project, its activities and results visible; dissemination makes results available to people who can use them; exploitation concerns their actual use in further research, products, services, policy or other applications.   Erasmus+ takes another route. Its #CommsJourney guidance provides beneficiaries with a step-by-step framework for communicating projects and their results. These frameworks matter. I would not replace them with another homemade compliance system. The operational problem starts one level below them.   A communication plan can say that the project will communicate with policymakers, practitioners, SMEs and citizens through a website, newsletters, events and social media. It may still leave unanswered which municipal network can actually reach the relevant policymakers, who checks the Danish version of a new result summary, or whether a routine event reminder needs approval from seven partners.   A useful five-minute test is to ask a colleague who did not write the communication plan to find the current approved project description, the correct funding acknowledgement and the latest reusable visual assets.   If this requires several messages to several people, I would start there before adding another communication activity. An audience list needs a route to the audience “Policymakers”, “SMEs”, “stakeholders” and “the general public” appear regularly in project communication plans. They are categories. Communication starts when the project can connect those categories to an actual need and an actual route. For one project, a professional association may provide better access to SMEs than a new Instagram account. Municipal actors may already sit inside a partner’s regional network. A community organisation can be more useful for reaching a specific group of citizens than another digital campaign. This is also where communication and stakeholder engagement begin to separate. Making somebody aware that a project exists is different from involving that person in an activity, getting them to use a result or bringing them into a policy discussion. I use a simple chain when reviewing this:   Audience → need → message → desired action → realistic route The final part is easy to underestimate. A carefully described target audience that the consortium has no credible way to reach remains largely theoretical. The same principle applies to channel selection. A project should not start with “Should we create LinkedIn, Instagram and Facebook?” It should start with where the relevant people already receive information and which of those routes the consortium can realistically access. Multilingual communication needs a source of truth European projects create an obvious temptation to translate everything. That is rarely the most useful starting point.   There is no general rule requiring every EU-funded project to translate every communication asset into every partner language. Programme-specific obligations still need to be checked. Operationally, language decisions should follow the audience: who needs this information, and in which language will they actually use it?   Once several versions exist, a different problem appears.   The core project description changes in English. The website is updated. The Greek version remains unchanged. A partner translates an older PDF into Danish. Six months later, three technically correct documents describe the same project differently.   That is a version-control problem disguised as a translation problem.   For multilingual projects, I want to see one identifiable master version, agreed terminology for programme names and recurring technical terms, and a defined review route for every language that matters.   Machine translation can reduce the first production step. Responsibility for meaning remains with the project.   A concrete starting point takes about twenty minutes: identify the source-of-truth project description, add a version number and date, then list the active language versions beside it. Each needs a defined review route when the master changes.   This becomes even more relevant as projects introduce AI-supported translation, synthetic voice and multilingual video. Production capacity is expanding faster than many consortium review processes. Generating