Out-whats? Navigating research-project jargon

Some of the specialist terms in research proposals that are often essential but commonly confused

I’ve previously considered the fact that, although semantically very similar, aims and objectives are definitely not the same thing in a research project. Briefly, the project aim speaks to the very point of doing the research – the difference that the project aims to make against an identified problem (which may simply be a gap in knowledge). Project objectives are the concrete steps that the project team will take to achieve that aim. They should be SMART – specific (please!), measurable (definitely!), etc.

But there are a number of other special terms that have specific meanings, and that funders expect or require us to cover in grant applications. Once again, some of these may seem very similar to each other, so there’s plenty of scope for confusion. This blog post seeks to disambiguate and explain some of the most frequently encountered – and most frequently misunderstood – project-specific terms. How can you possibly resist reading on?

Milestones vs. deliverables

Anyone who knows me knows that I love a good analogy. And I often go for something simple that we’re all familiar with, like building a house (not all of us have built a house; but most of us have lived in one). I’d suggest that there are
just two or three main deliverables when building a house:

• Architectural drawings
• Any other design documents needed
• The completed house (of course!)

As the name ‘deliverables’ suggests, they are commonly things that can actually be handed over: the drawings passed from architect to client (and builder); other design documents handed to whoever needs them; and the house (or at least the keys to the house) handed over to the client. There’s a degree of finality about them – “there you go, that’s all done and checked, over to you.”

While a deliverable may also coincide with and be related to a milestone (handover of the completed house to the client is undoubtedly a key project milestone), there will be other important milestones along the way. Breaking ground (digging, to you and me) is an important construction milestone, as are pouring foundations, completing brickwork, ‘topping out’ (putting the highest point in place), completing a watertight building envelope, and so on. Each milestone is a control point (in project-management parlance) indicating that an important and often fairly self-contained phase of the work has been completed, and the project is on track.

In a research project, milestones might include things like gaining ethical approval, recruitment of participants, completion of testing, analysis of data, and completion of the project-closure report. The report will itself be a deliverable, as would other things like policy reports, new software tools, new research cohorts, a new dataset, a protocol for a future clinical trial, a novel prototype and so on. Essentially, if you said at the start of the project that you would have produced something by the project end, then that’s a deliverable. Your funder should hold you and your team to account and make sure you deliver everything that you promised to.

The above examples of deliverables are all tangible – they’re things that you could physically hold, or at least look at on a computer screen. But deliverables can also be intangible, and could for example include a cohort of trained participatory researchers, or the exchange of knowledge or a specialist technique to another
organisation.

Research projects that aim to achieve impact, and rely on the actions of others to achieve that impact, need to ensure that at least some of their deliverables are actionable. This simply refers to the fact that they have been designed to facilitate and support some form of next-steps action, be that a policy change or a change in behaviour. A new dataset is not necessarily immediately actionable; a policy-recommendation report or health-information video much more so.

Outputs vs. outcomes

Out-whats? Outputs and outcomes are frequently confused, but they’re neither synonymous nor interchangeable.

Outputs are the things that you will produce during the lifetime of your project. They may be tangible – things like project reports, datasets, new patient-reported outcome measures (PROMs), papers, videos, popular-science articles, patents, protypes and so on; or intangible – such as new processes, concepts and interventions (although these are likely to be tangibly documented), new collaborations, or perhaps a newly-upskilled researcher.

Hold on I hear you say – aren’t these the same as deliverables? They’re certainly very similar, and it’s true to say that every deliverable will be a project output. But not all outputs are necessarily deliverables. Academic papers and popular-science articles, for example, may well be expected of you, but they may not be part of the set of specific deliverables that you signed up to producing. The same might be said of a public-engagement event (an intangible output). Perhaps a new cohort was recruited, but this was simply in order to produce one or more of the pre-agreed deliverables. I concede, it’s subtle. And I’ve never seen a reviewer quibble over the difference between the two, so we probably don't need to sweat about this too much.

Outcomes, on the other hand, are different from outputs and deliverables. If an output is a means to an end, then an outcome is that end (although see also impact below).

To take an intangible example, if the output is three early-career researchers trained in the CRISPR-CaS9 gene-editing technique, then the outcome might be an up-scaling of capacity and capability in this particular aspect of research at their institution. If the output is a new research dataset, then the outcome might be that scientists in a particular field are able to conduct new analyses to test new hypotheses and answer previously unanswered research questions. If the output is a prototype for a new medical device, then the outcome might be that the research team can move to the next stage of development that would see it tested using human participants. In short, outputs tend to be things; outcomes tend to be things that happen.

Impacts

The terms outcomes and impacts are sometimes used interchangeably, but (and I feel there’s a theme emerging here) they’re not always the same. They are linked though, and impacts often flow in the longer term from outcomes. By way of an example, some population-health research in the area of breastfeeding might produce an informational video aimed at new mothers (an output). Widespread engagement with the video might result in new mothers in the target region being better informed about good breastfeeding practice (an outcome); and breastfeeding rates in that region might subsequently increase (an impact). Over the longer term, increased rates of breastfeeding might result in improved neonatal and later-life health outcomes, which of course is what really matters and was no-doubt the ultimate impact aim of the research project. Again, the difference here can be quite subtle, but it’s real.

Intellectual property

Intellectual property – IP – often causes confusion among research-funding applicants, who are after all typically not specialists in this area (as I am also not). We commonly equate IP with things like music composition, literary authorship, new software and commercial patents. But in the world of research, the definition of IP is broad. A number of project outputs are likely to meet this definition. And so the line “we do not anticipate that any IP will be created” just won’t cut it for the ‘IP Management’ section of a research proposal.

Given that this is a glossary of sorts, here are a couple of further definitions. Background IP is IP that will be required for/used in the project, that exists already. Foreground IP – sometimes referred to as arising IP – is produced during the course of the project.

When it comes to research, there’s quite a wide range of outputs that count as (foreground) IP and will thus need to be managed appropriately. They include, for example:

• New and updated/altered software, computer code and/or algorithms
• Inventions, including designs and patterns (for example a new medical device), whether patentable or not
• Other know-how, ideas and concepts
• Databases and datasets
• Laboratory notebooks
• Project reports and documents
• Protocols, standard operating procedures and processes developed during the project
• Any branding, symbols and words/slogans developed for the project (it is not uncommon for a large research project to have its own brand presence)

Involvement (in research)

Since we seem to be going to town on the ‘I’ section of this glossary, here’s another one – involvement. As in patient and public involvement (PPI). I’d normally advise against defining something by stating what it is not, but, when it comes to research, involvement is not engagement (i.e. getting out there, meeting people and engaging with them in some way with regard to your research). And it’s definitely not participation (i.e. being a volunteer subject in a research project).

Public (and patient) involvement is about doing research with members of the public, not just to them (as participants/volunteers), about them (as aggregations of data points) or for them (as beneficiaries). By involving people, you are bringing in their experience – and their views and ideas based upon it – and helping to ensure that the research is relevant because it has been designed, conducted and disseminated in conjunction with some of the people whom it is intended to affect. Wherever it’s appropriate, public involvement in research is a good thing.

Project partners

Once again, semantics sets a trap for the unwary. Surely any third party – whether an individual or an organisation – who does something with us in a project is a project partner? By this not-unreasonable definition, our co-investigators are our project partners, as are public-involvement contributors and any other collaborators. And yet…

Although different funders may use the term ‘partner’ somewhat differently, the UKRI definition is fairly widely applied. UKRI defines a project partner as follows (my bold):

“a third party person who is not employed on the grant, or a third party organisation, who provides specific contributions either in cash or in kind, to the project. […] As a rule Project Partners are expected to provide contributions to the delivery of the project and should not therefore be seeking to claim funds from UKRI.”

Project partners are typically businesses, government organisations such as executive agencies, NHS trusts or health boards, or third-sector organisations. It’s worth noting though that the Horizon Europe scheme takes a different approach. Here, any type of organisation can receive funding for their involvement in a project so long as they have the operational and financial capacity to carry out the tasks assigned to them. All members of a Horizon Europe project consortium are referred to as consortium partners.

Including all this information in your proposal  

Some of the above, such as project partners, PPI and IP, are usually dealt with in dedicated sections of the application. When it comes to objectives, milestones, deliverables, outputs and outcomes, it’s generally good to include these in your approach and methodology section, clearly linked to the particular work package/s (or similar tranches of the project work) to which they relate. They are all important parts of the story. If the funder requires a Gantt chart or workplan (or if you decide to include one), then this should also capture these elements of the project. Your project aim and associated impact goal/s should of course be central to the proposal, and should run through it like a thread. They provide the answer to the important but potentially devastating question – "what's the point of this project?"

The views and opinions expressed in this blog are mine alone and are in no way endorsed by my employer. Factual information and guidance are provided on a 'best-endeavour' basis and may become out of date over time. Web-links were correct at time of writing but commonly go out of date. No responsibility can be taken for any action or inaction taken or not in respect of the content of this blog.