Horizon Europe consortium governance: the General Assembly, the Steering Committee and how decisions get made

Table of Contents

Every multi-beneficiary Horizon Europe project needs effective internal governance. Article 7 of the Grant Agreement requires beneficiaries to establish internal arrangements for their operation and coordination to ensure the project is implemented properly — but it does not prescribe a Steering Committee or any specific governance structure.

What that structure looks like in practice is defined in the Consortium Agreement. And in many projects — particularly larger, more complex ones — it includes an operational body that sits beneath the General Assembly and handles the day-to-day governance of execution. That body is commonly called a Steering Committee, though depending on the Consortium Agreement, it may also be called a Project Management Board or Executive Board.

This article explains what that body is, how it fits within the broader governance framework, what it commonly does, and what makes one effective in practice.

What the Grant Agreement requires

Article 7 of the Grant Agreement specifies that beneficiaries must have internal arrangements regarding their operation and coordination to ensure the project is implemented properly. It does not require a Steering Committee by name, nor does it prescribe any particular governance structure. The written Consortium Agreement itself is only mandatory when the granting authority specifies it in the Data Sheet.

What is expected is that functional internal arrangements exist — not that they take a specific form. Where a Steering Committee or equivalent body exists, its authority, composition, and powers derive entirely from the Consortium Agreement and the project’s governance arrangements, not from the Commission directly.

DESCA and consortium governance options

The DESCA model Consortium Agreement — the most widely used template in Horizon Europe projects — offers different governance options depending on the project’s size and complexity.

For smaller and medium-sized projects, DESCA’s standard module centres governance on the General Assembly. In lump sum projects, this may be complemented by a Work Package Leaders Group. For larger or more complex projects, DESCA adds an Executive Board alongside the General Assembly.

Some consortia call this operational body a Steering Committee or Project Management Board — but the name, composition, and powers depend entirely on the Consortium Agreement the project has adopted. There is no single standard model that applies to all projects.

General Assembly vs operational governance body: the difference

Understanding the difference between the General Assembly and whatever operational governance body the consortium has established is the foundation for understanding how consortium governance works in practice.

The General Assembly is the supreme decision-making body, composed of representatives from all partner organisations. It is responsible for major decisions: significant changes to the project structure, admitting or removing partners, resolving disputes that cannot be resolved at a lower level. The Consortium Agreement is a private contract signed by all parties — not simply approved by the General Assembly — and significant modifications to it typically require a separate written agreement signed by all parties.

The operational governance body — whether called a Steering Committee, Executive Board, or Project Management Board — handles the governance of day-to-day execution. It typically meets more frequently than the General Assembly and handles operational decisions within the scope delegated to it by the Consortium Agreement.

The two bodies serve different functions. Much of the operational governance work may happen at the Steering Committee level — but the precise scope of its authority must always be checked against the applicable Consortium Agreement and Annex 1.

Who sits on the Steering Committee

The composition depends on the Consortium Agreement. A common practical configuration includes the coordinator — who typically chairs the committee — and work package leaders. In DESCA’s module for larger projects, the Executive Board may be composed of the coordinator and representatives appointed by the General Assembly. In lump sum projects, WP leaders and additional representatives may be included.

In smaller projects, all partners may participate in a single decision-making body, and a separate operational committee may not exist at all. The configuration should fit the project’s size and complexity — not be adopted as a default because it appears in a template.

What a very large committee may find harder is making decisions efficiently. Keeping the operational governance body focused on the people actively managing execution is generally a reasonable approach — but how this is structured depends on the project.

What the Steering Committee commonly does

Depending on the authority granted to it by the Consortium Agreement, an operational governance body of this kind may handle a range of activities. Its precise powers should always be checked against the applicable CA and Annex 1 — what follows describes common practical configurations, not universal rules.

Monitoring progress against the work plan. Each WP leader brings an update on their WP status — what is on track, what is at risk, what has been completed. The committee reviews this against the deliverables and milestones defined in Annex 1 and identifies where action is needed.

Making operational decisions and preparing recommendations. Within the scope delegated by the Consortium Agreement, the committee may make certain operational decisions — and prepares recommendations for matters reserved to the General Assembly.

Reviewing project risks. Many consortia maintain a risk register — Annex 1 typically includes critical risks and mitigation approaches. A common good practice is for the operational governance body to review risks regularly, track mitigation actions, and escalate significant new risks to the General Assembly. This is a recommended practice rather than a uniform Grant Agreement obligation.

Escalating to the General Assembly when necessary. When an issue exceeds the committee’s authority — a partner requests withdrawal, a major work plan change is required — the committee prepares the recommendation and escalates it accordingly.

Preparing for reporting periods. In the weeks before a reporting deadline, the committee can play a useful role reviewing the status of deliverables due in the reporting period and identifying any gaps that need to be addressed before submission.

Meeting cadence and documentation

A possible cadence — to be adapted to the size, complexity, and phase of the project — is:

In the first year, when governance is being established and the first deliverables are due, more frequent meetings help align the team around the work plan. In subsequent years, with stable procedures, quarterly meetings supplemented by ad-hoc calls when issues arise is a reasonable reference point for many projects. In the final months, increased frequency may be appropriate as reporting deadlines create additional governance pressure.

Every meeting should produce formal minutes recording who attended, what was discussed, what decisions were made, and what action points were assigned. These minutes can provide useful supporting evidence that governance meetings took place, decisions were documented, and identified risks were followed up — which is relevant in a project review or audit. They do not by themselves demonstrate correct compliance, but they are part of the documentary record.

Common governance failures to avoid

Status reporting instead of decision-making. A committee where WP leaders present what they have done and the meeting ends without any decisions is not governance — it is a reporting call. Every agenda should include decision points.

No risk review process. Projects without an active risk register risk managing risks informally and inconsistently. Whether responsibility sits with the Steering Committee or elsewhere, someone should own the risk review process.

Minutes that record discussions but not decisions. Minutes that say “WP3 progress was discussed” are not useful. Minutes that say “WP3 deliverable D3.2 is at risk of delay; coordinator to notify the Project Officer; WP3 leader to submit revised timeline by [date]” are.

Irregular meetings. A governance body that meets when convenient provides no continuity. The value of a regular cadence is that it creates a predictable rhythm for surfacing and resolving issues.

How Kronis PMO supports operational governance

A governance body is only as effective as the information it works from. A committee reviewing outdated spreadsheets cannot make good decisions — because the picture it is working from is incomplete.

Kronis PMO provides the operational data that can make governance meetings more productive: deliverable status, partner activity monitoring, milestone tracking, and Gantt chart views that make dependencies and timeline risks visible. Meeting management in Kronis PMO — including agenda preparation, minutes recording, and action point tracking — keeps the governance trail organised throughout the project.

The system reflects the information that partners and WP leaders enter and update within it — giving the coordinator a consolidated view that is significantly more reliable than email threads and separate spreadsheets.

Final thoughts

A well-functioning operational governance body — whatever it is called in the Consortium Agreement — is the mechanism that keeps a multi-partner project on track across three to five years of execution. When it works well, it surfaces problems early, manages risks proactively, and keeps execution aligned with Annex 1.

The investment in setting it up properly — with a clear mandate derived from the Consortium Agreement, a regular meeting cadence, decision-focused agendas, and proper documentation — can substantially improve project coordination over the project lifetime.

The precise form it takes depends on the project. What matters is that it functions.

Kronis Software: The Solution to Navigating EU Funding Complexities

Scroll to Top