Writing a technical narrative that survives review
The narrative is the one document every reviewer reads. Most are written by the wrong person, in the wrong order, about the wrong thing. A structure that works in every jurisdiction, and how to write it with the people who did the work.
Most schemes ask for a written description of the technical problem and the work done, at registration, approval or claim stage, and every authority expects one to be available if the claim is reviewed. The forms differ in length and headings, but the questions underneath are the same. A narrative that answers them plainly transfers between jurisdictions with light editing. A narrative that sells the product does not survive the first review anywhere.
Three questions, in this order
1. What did you not know how to do?
State the technical unknown in one or two sentences, in terms a competent professional in the field would recognise. Say why the public state of knowledge did not answer it. Avoid the words "innovative" and "cutting edge": reviewers read them as a signal that the author could not describe the problem.
2. What did you do to find out?
Describe the approaches considered, what was tried, what failed, what was learned and what changed as a result. The account of the work done to resolve the uncertainty is central, because it shows the systematic approach every scheme requires. Write it chronologically. Refer to dated documents by name.
3. What was the result?
State what was resolved, what remains uncertain, and where the R&D ended. A narrative that admits partial failure is more credible than one that reports total success, and it draws the boundary of the claim honestly.
Who should write it
The person who led the technical work drafts it, or at least dictates it. Finance and advisors edit for structure and consistency with the cost schedule; they do not originate the technical content. A narrative written by someone who was not there reads that way, and the reviewer's first interview question will expose it.
How long
Long enough to answer the three questions with specifics; short enough that a reviewer reads all of it. For most projects that is one to two pages. If a scheme's form imposes a character limit, write to the limit and keep the longer version in the file.
Language that helps
- Concrete nouns: the algorithm, the alloy, the tolerance, the throughput target.
- Numbers where they exist: the target that could not be met, the result achieved.
- Names of methods tried and rejected.
- Dates, or at least months, for the start, the key turning points and the end.
Language that hurts
- Marketing adjectives and superlatives.
- Descriptions of features and benefits to customers.
- Claims that "nobody had done this before" without saying what was searched.
- Passive constructions that hide who did what.
- Copying the previous year's narrative and changing the dates.
A template
Project: name used in finance and engineering records.
Period: start and end of the R&D work.
Field: the science or engineering discipline.
The uncertainty: two sentences.
Why existing knowledge did not resolve it: what was consulted, tried or known.
The work: approaches, experiments, results, changes of direction, in date order.
The outcome: what was resolved, what was not, when the R&D ended.
People: who did the work and their roles.
Evidence: the documents the narrative is drawn from.
Before it goes in the claim
Have the technical lead read the final version and confirm every sentence. Then check that project names, dates and people match the cost schedule and every form. The narrative and the numbers are read together, and a mismatch between them is the fastest way to turn a short review into a full one.
Educational material, not advice. Each scheme's form has its own headings; map this structure onto them.
Educational content only, not tax advice. Rules change and eligibility depends on your circumstances, so check the official guidance or speak to a qualified advisor before you claim. See the disclaimer.