Module 7: Working with technical teams

Finance teams do not find R&D projects in the ledger. They find them in conversation with the people who did the work, and the quality of the claim is set in those conversations. This module shows how to get engineers, developers and scientists to describe what they did not know at the start, in their own words, and how to turn those descriptions into a candidate project list that modules 2 to 6 can cost and module 9 can test.

What this module covers

Why technical staff describe outcomes rather than uncertainty, and how to ask so they describe both.
A question set for interviews and workshops.
Turning notes into a candidate project list with boundaries, people and evidence.
The three ways a list goes wrong: business goals, known methods and whole-product scope.
What each country's definition asks the technical team to be able to say.

The language gap

Ask an engineer what they worked on this year and you will hear about what was built: a new controller, a faster pipeline, a reformulated coating. That is the product. Every scheme asks a different question: what was not known at the start, why a competent person in the field could not have answered it from existing knowledge, and what was done to find out. Technical people rarely volunteer that: resolved uncertainty feels obvious in hindsight, admitting a problem was hard can feel like weakness, and "research" sounds like something done in universities.

Keep asking until the answer comes in technical terms. The signal that you have arrived is a sentence with a verb of not knowing: "we could not predict", "there was no published way to", "the standard approach failed because", "we had to test whether". Write those sentences down in the words used; they become the first line of the project description.

Running the conversation

Use a workshop for the first pass across a department and one-to-one interviews for the projects that come out of it. The guide How to run a project identification workshop with your technical team covers the format; this section covers the questions. Hold the session soon after year end, while memories and records are fresh. Invite the people who did the work, not only their managers, and bring the list of initiatives from the project system.

Question	What it is for	A weak answer	A usable answer
What were you trying to achieve, in technical terms?	Separates technical from commercial objective	"A product customers wanted"	"A gripper that holds 2 kg at 1 m/s without slip on wet surfaces"
At the start, what did you not know how to do?	Locates the uncertainty	"How long it would take"	"Whether the force sensor could sample fast enough to correct before slip"
Why could a competent engineer not have looked that up?	Tests that the uncertainty is in the field, not only the company	"We had never done it"	"Published methods assume dry contact; nobody had characterised wet grip at that speed"
What did you try, and what happened?	Shows the systematic work	"We iterated until it worked"	"Three sensor placements tested on the rig; two failed at speed; the third worked with a new filter"
When did you know the answer, or stop trying?	Sets the end of the project	"When we shipped"	"After the March test series; everything after that was integration"
What on this initiative was routine?	Marks the boundary of the claim	Silence	"The interface, the documentation and the certification tests were standard work"

Keep the interview to the technical story. Do not mention rates, benefits or money in the room; it changes the answers. Ask open questions, write down the words used, and apply the definition afterwards.

Building the candidate list

Within a week, turn the notes into a single list: one row per candidate project, where a project is the work done to resolve one uncertainty or a closely related set, not a product or a team. The columns are fixed so every project is tested the same way in module 9.

Working name and technical objective, in the engineer's words.
The uncertainty, as a sentence with a verb of not knowing, and why existing knowledge could not resolve it.
Start and end of the work, with the event that marks each.
The work done: approaches tried, tests run, results.
People and roughly how much of their time, firmed up in module 3.
Records that exist, by location: test logs, design reviews, tickets, commits.
Routine work excluded from the project boundary.
Status: candidate, needs a follow-up interview, or excluded with a reason.

Send each row back to the person interviewed to correct. Their sign-off now is worth more than any later narrative: their words, checked by them, recorded at the time.

Three ways the list goes wrong

Business goals in place of technical uncertainty. "We needed to cut unit cost by 20%" is a reason to start a project, not an uncertainty. Ask what technical problem stood between the company and the cost reduction.

Known methods. Work that applies established techniques to a new product is new to the company but not uncertain in the field. Guidance in six of the seven countries makes the same point for software, and the United States reaches the same place by requiring uncertainty about capability, method or appropriate design at the outset.

Whole-product scope. If the project boundary is "the new controller", the claim will include routine work. Draw the boundary around the uncertainty. The United Kingdom guidelines put it directly: R&D begins when work to resolve the scientific or technological uncertainty starts and ends when the uncertainty is resolved or work on it ceases (see Eligibility: United Kingdom).

Illustrative example

Illustrative example. Harbour Robotics Ltd, a hypothetical company, has 40 engineers and 12 development initiatives for the year. The finance lead runs a workshop with the engineering leads and follows up with six interviews. Four initiatives are ruled out in the room: two were configuration of bought-in systems, one a cosmetic redesign, one support tooling built from standard components. Eight go on the candidate list. The interviews move two more to excluded: in one, the only uncertainty was whether a supplier would deliver on time; in the other, the method came from a published paper and worked first time. Six candidates remain, each with a one-sentence uncertainty, start and end dates, named staff and a list of records. Staff time on the six comes to 10 engineer-years out of 40, so around a quarter of engineering cost goes forward to costing, not the whole department. The two exclusion decisions are written up and kept with the list.

Across the seven countries

The questions are country-neutral; what changes is the wording the description must support. Each row quotes the country page.

Country	What the description must show
United States	At the outset, you must have been uncertain about capability, method or appropriate design. Substantially all of the activity must constitute a process of experimentation, evaluating alternatives.
United Kingdom	A project qualifies if it seeks an advance in science or technology by resolving scientific or technological uncertainty. Uncertainty exists when knowledge of whether something is scientifically possible or technologically feasible, or how to achieve it in practice, is not readily available or readily deducible by a competent professional working in the field.
Ireland	Qualifying R&D activities are systematic, investigative or experimental activities in a field of science or technology. They must seek to achieve scientific or technological advancement, and must involve the resolution of scientific or technological uncertainty.
Canada	Two questions. Why was the work done: this requires a scientific or technological uncertainty that could not be resolved by standard practice. How was the work done: was it a systematic investigation or search by means of experiment or analysis, involving a hypothesis, testing and conclusions.
Australia	Core R&D activities are experimental activities whose outcome cannot be known in advance from current knowledge. They follow a systematic progression of work, from hypothesis to experiment, observation and evaluation, leading to logical conclusions.
New Zealand	A core activity uses a systematic approach to create new knowledge or new or improved processes, services or goods, and to resolve scientific or technological uncertainty. Uncertainty exists if knowledge is not publicly available or deducible by a competent professional in the relevant field.
Singapore	R&D means systematic, investigative and experimental study that involves novelty or technical risk. Technical risk exists where the probability of achieving the technical objective cannot be known or determined in advance by a competent professional based on current knowledge.

Where to go next

How to run a project identification workshop with your technical team.
Writing a technical narrative that survives review, from interview record to narrative.
Qualifying versus non-qualifying activities.
Technical Teams Program, the same ground from the engineer's side.
In-House Finance Team Program overview and country tracks.