It cannot be said enough – winning a Horizon Europe grant is no easy task. After months of proposal preparation and writing, all researchers want to arrive at the finish line having the most competitive proposal at hand. With a gruelling evaluation process to pass, the general discussion is that there are some specific sections of the grant application that need to be absolutely solid in order to further ensure your overall success. One such section is the Implementation structure under chapter 3 of the project proposal. We hear it often that if your Implementation structure is not all geared up and shiny, the reviewers will not find it impressive enough. But, in the midst of conjuring up a golden Implementation structure, many researchers neglect the fact that once their project is funded, this plan becomes a contractual obligation that must be thoroughly executed.
To put it simply – creating an “over-the-top” Implementation structure without ensuring its ultimate execution is a dangerous path to take. Over time, we have been able to identify a list of misleading “practices” referring to the parts that must be included in the Implementation structure. Experience shows that fully complying with such practices generally means having a structure that is far too difficult to manage, suffering from too many unnecessary assignments, issues with budget, and the list goes on. We are here to help! First, we will debunk such misleading practices. Next, we will offer our recommendations for writing an Implementation structure that is both highly competitive and feasible for execution.
Work Packages in the Implementation Structure
Practice #1 – Work Packages and tasks. One of the main issues in Horizon Europe applications is the case where different work packages (and their corresponding tasks) are written by different partners. It is quite a common (yet unrecommended) practice to ask each partner to write his/her “own” work packages. The outcome of this is a work plan with questionable logic, typically not well-orchestrated, consisting of logical gaps and unwanted overlaps in functionality. In severe cases, this practice leads to a project presentation that actually lacks a clear backbone, rendering the entire implementation structure to be fragile, incoherent, inconsistent and hard to manage. Worst case scenario is a project that is near impossible to execute. These practices are usually also manifested in the budget plan (see more below) of these projects.
Surely enough, despite doing the above, these kinds of projects can still be selected for funding. But – if the work plan was poorly constructed, managing them will become a true challenge.
We’d like to offer a different approach. One that will not only make the work plan ready for execution but may also gain extra points from the reviewers for presenting an improved plan.
Our recommendations for composing the work packages in a way that ensures both competitiveness and feasibility:
- Logic and coherence are key. A coherent logical framework is the best way to go. Invest in planning and ensuring this kind of presentation. In order to reach this level of presentation ask the partners for input about their capabilities, capacities, needs and expectations from the project. However, do not ask them to write the work packages themselves. It is imperative to have a unified single voice, presenting a single logical pathway in the way the plan is presented. Use the partners’ input to structure the work plan. Clarify what is the ‘backbone’ of the work, which should directly correspond to the overall project objectives and can lead the entire project to the desired outcomes. Then- breakdown to clear blocks of work – the work packages – while ensuring that all work packages are tightly ‘glued’ to the ‘backbone’ and that there are no logical gaps on one hand, and no overlaps in functionality on the other. When referring to the inputs from the partners, use only the parts that comply with the plan that you have illustrated, and leave out any other elements. This may require negotiations with the partners. If any component is still missing, consider adding another function/role to a relevant partner, or recruiting an additional partner altogether.
- Go deep into the details. Ask the partners to estimate the time and resources for each of the tasks (not only at the level of the work package, as expected according to the official proposal template). This means specifying in the work program description person-months allocation per task, per partner, and any other associated costs. Work with the partners to agree on the timeline of the various tasks and how they feed each other. This, again, should be done at the level of tasks and not just at the level of work packages. Making this effort will force the partners to think in more depth about their suggested work, and this is going to be beneficial to all on both fronts, the evaluation front (and how the reviewers will look at it) and the execution front (which will make the plan more accurate and feasible). Sometimes, these details might be based on a rough estimation at the time of the proposal making. It is better to have rough estimations than no estimations at all.
An implementation plan with clear deliverables
Practice#2 – Deliverables. These serve as a means of progress assessment throughout the lifetime of the project. As well, they become official contractual obligations under the grant agreement. It is crucial to remember that the Deliverables are produced on top of the progress reports required by the EC in each reporting period. The typical mistake that we see is having too many deliverables in the project proposal in general, and per work package in particular. Many believe that the reviewers seek out as many deliverables as possible. However, this is not true. The reviewers seek mainly for a logical framework in the way the work plan is presented, which may contain also a logical set of deliverables. This need not be morphed into a long list of deliverables.
Our recommendations for feasible Deliverables that won’t take away from your competitive edge:
Instead of complying with the above, we recommend listing around 2-3 well-defined and well-thought-out logical deliverables per work package. Experience shows us that this number of deliverables generally does not become an issue, but rather creates the base for successfully complying with the expected work. In most cases, this will satisfy the reviewers and will likely prevent overload during the project’s execution.
Achieving a solid number of Milestones
Practice#3 Milestones. Similar to the Deliverables, these also serve as a means of progress assessment during the execution of the project. As well, they become official contractual obligations under the grant agreement. Since these milestones will be monitored and assessed during the project lifetime, your motivation is to have as few milestones as possible. The typical mistake in this context is applicants listing too many milestones on the application file.
Another aspect about the milestones in Horizon Europe project proposals is the issue of “means of verifications”. The EC, as well as the reviewers, would like to know how you are going to demonstrate reaching each milestone. There are plenty of ways to do that. Generally, any kind of dedicated written evidence for that matter will suffice.
Our recommendations for feasible and competitive Milestones:
Our recommendation is to have about 5 milestones for the entire duration of a 3-years project (for longer durations, add 1-2 milestones max). More than anything else, and similar to the issue with deliverables, here as well the reviewers are looking for logic in the plan. So, if you manage to define 3-5 well-defined and well-thought-out milestones (for a 3-years project), it should be enough.
Additionally, try and link milestones to one (or more) of the existing deliverables. In doing so, you will provide means of verification to the milestones and avoid writing yet another document. Doing that will surely save you time and work during the project execution.
Budget Budget Budget
Practice#4 – Budget. Experience shows that there are two main approaches for constructing a Horizon Europe project’s budget. The first approach is the top-down approach in which the coordinator and/or the partners decide to split the budget in a predefined manner, while each of the partners is responsible for the inner structure of the budget share they receive. A second approach is a bottom-up approach during which the budget is constructed based on the actual specific details of the project’s work plan.
How to create your budget the right way:
It is our very clear recommendation to apply the second approach when constructing the budget of the project. This recommendation takes into account both the evaluation process and the execution phase. On both counts, the second approach is more realistic, accurate, reliable, convincing and eventually more relevant for execution. Our experience shows that using the first approach ends up with multiple problems during execution, not to mention evoking negative feedback and many unwanted questions from reviewers during the evaluation phase.
Linking the budget tightly to the detailed work plan will be beneficial to both the project and the partners. Having such a high-resolution plan with high level of details is important both for making the right impression in the eyes of the reviewers and clearly running a more efficient project’s budget during the project execution.
For more information on structuring the Horizon Europe budget – check out our complete guide.
Now that we have debunked some of the leading practices associated with the Implementation structure of the Horizon Europe proposal, we can set off to writing a plan that is both competitive and feasible. Doing so will surely help you move steps closer towards a Horizon Europe proposal that is highly competitive and answers to the requirements and expectations of the reviewers. If you have any additional questions, please do not hesitate to contact us or refer to our available services for assistance.