Proposal engineering · the method
One engineeredsystem.
We build your proposal as one engineered system: the argument, the consortium, the budget, the evidence, the documents and the public face, under version control, from the call text to submission and beyond.
Sevenprinciples.
Our method comes from building a large Horizon Europe proposal under exactly the pressures that sink most of them, and from keeping an unusually detailed record of what went wrong and how it was fixed: nearly 600 lesson records, condensed into 96 operating rules.
- Verbatim first. We capture the call word for word and trace every rule, quote and figure to its primary source.
- One source of truth per object. There is one partner list, one effort table, one live document and one version ledger. Everything else is derived from them.
- Assert, don’t assume. Every scripted change states what it expects and stops if reality differs. Every total is recomputed. Every “sent” is checked for delivery.
- Measure where it counts. Pages are counted in the software the evaluators will use. Money is checked in the funder’s own model. The proposal is scored with the evaluator’s criteria.
- Design for the evaluator’s reading and the funder’s payment logic. Under lump-sum funding, the work package is the payment unit, so a work plan that pays nothing until month 40 is a design error.
- Keep a contingency line. Any partner not signed off a month before the deadline gets a version of the proposal built without them.
- Say what was not done. Every review we deliver lists what it did not check.
Nine stages,four systems.
T is the call deadline. The stages are a sequence; the four systems run through all of them.
| Stage | What happens | When |
|---|---|---|
| 0 · Qualify | Base success rate, fit against the current evaluation criteria, whether the topic returns next year, national co-funding for your preparation, a written go/no-go. | T−6 months |
| 1 · Decode the call | Verbatim capture checked across page breaks; every research question mapped to an objective, section and instrument; the template’s hard rules; a post-mortem of past winners; a map of related projects. | T−5 → T−4 months, re-verified at T−90/60/30 |
| 2 · Architect the consortium | Partner qualification gates, graded roles (beneficiary, associated partner, advisory board), institutional roles, governance clauses that survive stress, Advisory Board recruited by function. | T−5 → T−2 months |
| 3 · Design the evidence and work plan | Work packages derived from how the work actually runs, a payment profile per reporting period, a solidity matrix (results × work packages × deliverables × milestones), a quality gate per evidence strand, a naming system, an ethics and data regime. | T−4 months → freeze at T−45 days |
| 4 · Build the budget | An effort model per partner and work package, unit-cost build-ups using public price indices, partner-budget intake with error flags, proportionality tests, a cash-flow check per partner, an independent recompute. | T−60 → lock at T−14 |
| 5 · Write and engineer the Part B | Drafting inside the official template, impact written for the current rules, page-limit engineering (layout first, words last), figures generated from the proposal’s own tables, a verified and linked reference system, a compliance audit. | T−90 → freeze at T−7 |
| 6 · Run the consortium | Partner kits, one-pagers, a living requests register, a secretariat across every channel, meeting briefs, a written decision trail. | Continuous |
| 7 · Submit | Portal entry from a single execution map (the portal follows the Part B), budget justifications, ethics pages, a consistency check, full upload at T−5, a checked PDF. | T−10 → T |
| 8 · After submission | Public status, a visual summary, a publication plan, a lessons note, grant-preparation readiness. | T+1 → result |
Four systems
- Document control: an asserted edit pipeline, a version ledger, protected comment threads, safe publishing to shared drives.
- Visibility: a project website that stays in sync with the proposal, a brand, figures and visual summaries.
- AI discipline: a single orchestrator, verification at the primary source, an AI-use statement and a citation log in every delivery, and EU-resident or local models for personal data.
- Programme control: a secretariat, a cadence, registers and calendar gates.
What you receive
- A go/no-go memo with the base rate and a co-funding map.
- A call decoding pack: verbatim brief, coverage matrix and template digest.
- A consortium file: partner list, roles, governance clauses, kits and one-pagers.
- A work-plan architecture with its payment profile and solidity matrix.
- A budget model consistent with the Part B tables and the portal, with written justifications.
- A Part B at the page limit, compliant with the template, with figures and working internal links.
- A submission file: execution map, portal entry record and the checked PDF.
- An AI-use statement and a citation-verification log.
- On request, a project website and a visual summary of the proposal.
How we work with you
You own thescience.
- You own the science and the decisions. We own the engineering and the verification.
- Fixed scope and fixed price, paid by milestone, with dates agreed for the architecture freeze and the partner returns.
- Drafts, never sends. We prepare, and you (or your coordinator) send to third parties, hold EU Login and press submit.
- Confidentiality: an NDA as standard, your data kept in your space, and nothing reused across clients.
- No promises of funding. We quote the base rate in every proposal, and we publish no success rate until we have a meaningful sample.