You have a solid research question. You’ve mastered the state of the art. The methodology holds up. The team has the necessary expertise. The project has taken several weeks of work.

And yet, it was not selected...

​

Once the disappointment has passed, one question often comes up: what went wrong?

Perhaps the project wasn’t explained well enough. Perhaps its originality wasn’t clear enough. Perhaps certain details should have been elaborated on further. Perhaps the reviewers didn’t fully understand what the team was trying to do.

All of these explanations are possible.

​​​

But what if the problem wasn’t just the application?

​​

​

Research and a research project

aren’t quite the same thing

​

Developing a research project involves defining a question, situating it within existing knowledge, choosing a methodology, and determining how to produce scientifically sound results.

Developing a research project involves answering these questions, but as this research must be conducted within a given timeframe, with defined resources, and possibly involving multiple partners, other factors come into play.

You must organise activities, assign responsibilities, create a timeline, determine the necessary resources, establish a budget, anticipate certain risks, and consider the expected results and how to make the most of them.

These elements are sometimes viewed as mere administrative tasks surrounding the scientific core of the project.

​

Yet they are an integral part of the project.

​

Let’s take a very simple example.

An activity planned for the project ultimately takes three months longer than anticipated. These three months can alter a researcher’s workload, delay a partner’s involvement, require additional resources, impact the budget, or push back another activity.

Modifying an activity, therefore, is not simply a matter of moving a bar in a Gantt chart.

​

The project itself has just shifted.

​

And it is precisely because these different dimensions are interdependent that their coherence matters in the evaluation.​

​​

​

Why does the evaluator ask you all of this?​

​​

When reviewing a funding application, it’s tempting to view each criterion as a request that must be fulfilled.

• A timeline is requested: let’s create a timeline.

• A budget: let’s fill out the budget.

• A risk analysis: let’s identify a few risks.

• An impact statement: let’s write a paragraph on the impact.

The application can then become a series of responses designed to satisfy the various sections of the call for proposals.

​

But another way to interpret these requests is to ask a very simple question:

​

Why is this information being requested?

​

• A timeline isn’t just for knowing when activities begin and end. It also helps assess whether the sequence of activities seems realistic and whether the project can be completed within the stated timeframe.

• A budget is not merely a list of figures. In particular, it allows us to assess the consistency between what the team aims to achieve and the resources it plans to allocate to it.

• Identifying risks does not mean that a research project is expected to eliminate all uncertainty—which would be paradoxical, to say the least. Rather, it allows us to assess whether certain difficulties have been anticipated and whether the team has the capacity to address them.

​• Impact is not just about stating the outcomes the project might produce, it also allows us to assess how the team links the expected results to the transformations to which they might contribute, and whether the conditions necessary for that contribution have been met.

​

An evaluation criterion is therefore not merely a piece of information that is requested. It serves to assess something.

​​​

Changing your perspective on the criteria allows you to move beyond simply asking, “What should I write in this section?” to asking, “What does this section reveal about my project?”

​

​And sometimes, the answer reveals a problem that is no longer merely a matter of writing.

​

​

Poorly explained or poorly structured?​

 

Let’s imagine that an evaluator does not clearly understand who is responsible for an important activity.

Two situations may lie behind exactly the same observation.

​

In the first, the division of responsibilities is perfectly clear within the team. It has been discussed and decided upon; everyone knows what they are supposed to do, but this organisation is not sufficiently reflected in the file.

The project is well-structured but the information has remained implicit whereas it needs to be made explicit.

​

In the second situation, responsibility is not necessarily obvious in the proposal because it is not yet truly established within the team. Several partners could take charge of the activity; the decision has not been made, and its implementation depends on an organisational structure that is still uncertain.

This time, simply rephrasing the paragraph will not suffice. The project still needs to be consolidated.

​

This same distinction can be found in many areas.

A timeline that is difficult to understand may be perfectly coherent but insufficiently explained. It may also reveal that several activities will likely not be completed within the planned deadlines.

An impact pathway may be part of the team’s thinking but remain invisible in the proposal. Conversely, the team may announce an impact without having yet credibly identified how its results could contribute to producing it.

​

On the one hand, what already exists needs to be made visible. On the other hand, there is still something to be built. This distinction is essential because the two problems do not call for the same response.

​

You cannot resolve a project’s weakness simply by improving its formulation.

 

​​

What if the application were used to put the project to the test? 

​

This distinction allows us to view the work of preparing an application in a different light. The application is no longer just the document into which the project must ultimately be fitted. The requirements specified by the funding program can also serve to test the project while it is still possible to modify it.

• If the team is struggling to develop a realistic timeline, why is that?

• If certain responsibilities are difficult to assign, what does this say about the planned organisation?

• If the budget seems difficult to justify, have the resources been genuinely planned based on the necessary activities?

• If the expected impact is hard to explain, is it simply a matter of unclear articulation in the text, or is there a logical leap between the scientific results and the stated effects?

 

​Every difficulty encountered in preparing the proposal can thus lead to two questions:

• Is it difficult to explain because something remains implicit?

• Or is it difficult to explain because we have not yet totally developed or decided on something?

​

This approach also changes the timing of the evaluation process. Instead of being introduced at the end—when research that has already been developed must be fitted into the sections of a proposal—it can be used early enough to examine the project’s coherence and identify any potential weaknesses. This does not mean, however, that the research should be artificially structured based on what we assume the evaluator wants to hear. The goal is to understand what the framework seeks to assess so that the project can be put to the test before it is evaluated by someone else.

​

​

So, can a scientifically excellent project be an imperfect project? 

.

The question is deliberately provocative.

But in reality, we must distinguish between the scientific quality of the research and the soundness of the project designed to carry it out.

​

Excellent research can be supported by a poorly constructed project. This does not make its scientific question any less relevant, its methodology any less rigorous, or its potential results any less interesting. But this scientific quality alone is not enough to demonstrate that the project can be carried out in a coherent, realistic, and sound manner under the stated conditions.

​

And this is perhaps where one of the greatest challenges lies in preparing a research project: not confusing what needs to be better explained with what still needs to be better structured.

Before seeking to present a project more effectively, it may therefore be helpful to start with another question:

Do we have something that needs to be better explained—or something that needs to be better structured?

​

​

​

© 2026 Explicita — Emmanuelle Pensec
This text is made available under the terms of the Creative Commons Attribution–Non Commercial–No Derivatives 4.0 International (CC BY-NC-ND 4.0) license.