Horizon work plans: expose hand-offs before the Gantt chart

Horizon Europe work plans are usually reviewed as tables and timelines. That format can conceal the most common implementation weakness: one task finishes, another task starts, but the proposal never defines what must pass between them or how the receiving partner will decide that it is usable.

The current full RIA/IA and CSA forms ask applicants to describe the work plan through work packages, tasks, deliverables, milestones, critical risks, effort and resources. These elements create a formal structure, but coherence still depends on the interfaces between them.

A hand-off is any point where a result, dataset, protocol, specification, approval, user input, component or decision produced by one activity becomes necessary for another. If the hand-off is late, incomplete or below the required quality, downstream work may continue on false assumptions.

PRINCEPS recommends a hand-off map with eight fields: required input; providing task and partner; receiving task and partner; due point; acceptance evidence; quality threshold; dependency or decision enabled; and fallback if the input fails. The map should cover both technical and non-technical interfaces.

Acceptance evidence matters. 'Dataset delivered' does not show whether the dataset is complete, lawful to use, interoperable, documented and representative enough for the next task. 'Stakeholder workshop completed' does not show whether an agreed decision, validated need or usable requirement emerged.

Milestones should be placed where the project genuinely needs control. The application-form definitions recognise that a milestone can enable the next phase, support corrective measures or serve as a critical decision point. A date alone is therefore weak. The proposal should state what evidence is reviewed, who decides and what changes when the condition is not met.

The map also improves risk design. A critical risk is not simply that a task may be delayed. The stronger description identifies which dependency would fail, the consequence for objectives, the earliest warning signal, the mitigation already built into the work plan and the fallback owner.

For cross-border consortia, hand-offs should include practical transfer conditions: data access, language, time zone, ethics or permit status, equipment compatibility, local validation, procurement lead time, travel, customs and authority to accept the result. These are implementation conditions, not administrative footnotes.

African pilot sites and implementation partners should define the acceptance rules for outputs they are expected to use. A method prepared elsewhere is not locally validated merely because it has been sent to the site. The receiving partner needs authority, time and resources to test fit and require correction.

Before freezing person-months, trace every major deliverable into the task or decision that consumes it. Then trace every major downstream task backwards to its required inputs. Unused deliverables, unowned inputs and circular dependencies should be removed or redesigned.

The final work plan should use consistent names and numbering across the narrative, work-package descriptions, deliverable list, milestone table, risk table, Gantt chart and budget. Small naming differences can hide material breaks in responsibility and make the proposal harder to evaluate.

This analysis is strategic and editorial. It does not replace the live application form, topic conditions, grant rules, ethics requirements, consortium agreement or professional project-management advice, and it does not guarantee funding or successful implementation.

Editorial note: This is PRINCEPS analysis for general information. It does not replace the official work programme, topic conditions, submission system, grant rules or professional advice specific to an application.