Your EU Project Is Approved, Now What? The First Months for Coordinators

Treat approval as an operating handover

Once your EU project is approved, your first job is to turn the proposal into a working operating system. Do not wait for the kick-off meeting to discover who owns documents, channels, the website, or passwords. Use the first month to confirm the grant agreement path, align partner commitments, and set the digital ground rules that will carry every work package.

Start with the legal and financial base. Check that partner legal names, bank details, budgets, co-financing assumptions, reporting roles, and contact persons match the approved file. For Horizon Europe projects, this usually means working through the Funding & Tenders Portal. For Erasmus+ projects, use the instructions from your National Agency and the Erasmus+ programme site.

Then prepare the partnership or consortium agreement before habits form. The agreement should not only cover money and liability. It should also state who can approve public content, who stores evidence, who signs off deliverables, who can speak for the consortium, and what happens when a partner changes staff. Approval creates momentum. Your task is to turn that momentum into repeatable operating routines.

Build the kick-off around decisions, not presentations

A weak kick-off is a tour of the proposal. A useful kick-off converts the proposal into shared decisions. Send the agenda early, attach the latest approved budget and work plan, and ask every partner to confirm their operational lead before the meeting.

Your kick-off agenda should cover:

• Grant agreement status, contract milestones, and any pending documents
• Partner roles, named leads, substitutes, and approval routes
• Budget rules, evidence rules, travel rules, and internal payment timing
• Work package starts, dependencies, risks, and the first visible outputs
• Reporting rhythm, meeting rhythm, minutes format, and decision log owner
• Dissemination channels, brand basics, website responsibility, and content approval
• Shared workspace, folder structure, file names, and access rights

Keep each agenda item attached to an owner and a decision. For example, do not end with “website to be discussed.” End with “coordinator registers domain, dissemination lead manages content, technical admin keeps backup access.” Minutes should record decisions in plain language, not as meeting atmosphere. After the kick-off, send a short operating memo. Partners should know where to work, where to ask, where to store proof, and who can approve publication.

Set the digital workspace in month one

Platform setup is a project management task, not a late dissemination task. The shared workspace becomes the place where evidence, drafts, meeting notes, partner inputs, and deliverables either stay usable or slowly decay. If you make the rules after partners have already created private folders and side channels, you will spend the rest of the project cleaning up.

Decide these items before the first real drafting sprint:

• Main workspace and backup location
• Folder structure by work package, deliverable, meeting, finance, communication, and evidence
• File naming pattern for drafts, final files, signed documents, and templates
• Who can create folders, delete files, invite users, and change permissions
• Where meeting minutes, decisions, risks, and action points live
• Which tools are allowed for personal data, survey data, photos, and participant lists
• How departed staff are removed and replacement staff are onboarded

The aim is not bureaucracy. The aim is continuity. A partner coordinator may change jobs. A dissemination officer may go on leave. A financial officer may need proof long after an event. If the workspace has clear ownership and simple conventions, the consortium can keep moving without asking one missing person to forward a file.

Do not let the domain become the quiet failure

The website domain looks small at the start. It becomes painful near the end if nobody knows who registered it, which email receives renewal notices, which card pays the renewal, or which individual holds admin access. This is the quiet failure behind many “deliverables die” situations: the project ends, the website is still online for a while, then a renewal is missed, an account owner leaves, and the public record disappears.

Set a domain rule in writing. The safest pattern is institutional ownership by the coordinator or a named long-term host, with at least one backup admin from another role. Avoid domains registered to a personal email address. Avoid passwords held by a single consultant. Avoid website builders where the person who clicked “create” is also the only legal owner.

Also decide what happens after the final report. Who pays hosting. How long the site stays live. Where public deliverables are mirrored. Who can update broken links. Who answers contact form messages. If the project needs a platform, knowledge base, member area, or AI assistant with sourced answers, choose the operating model early. StrandsUnited can help set up and operate this layer, as part of our platform work, but the key principle is the same in any tool: ownership must outlive the work package.

Where this comes from

We write this from work with EU cooperation teams that need their projects to keep functioning after approval, after the kick-off, and after staff change; our internal consortium graph covers 83,490 projects, 114,731 organisations, and 461,953 participation edges from CORDIS and Erasmus+ open data, so we see how coordination depends on durable relationships as much as strong proposals. We also operate Impactful and build knowledge systems, catalogues, member areas, event platforms, and AI assistants that answer with sources, which means we see the same pattern in live systems: unclear ownership creates avoidable recovery work. Before your kick-off, create one operating memo that names the workspace, domain owner, admin backups, approval route, and evidence rules, then share it with every partner for confirmation.