ELITMa is currently under development and may change at any point - it is not meant for production use
Skip to aside Skip to content Skip to footer

Real world example: From mandate to service scope

This case study draws on presentations and discussions from the Finland edition of the ELIXIR Node Data Management Strategy (NDMS) module in 2023. The original training materials and shared notes are available through the ELITMa Finland workshop materials.

A recurring question during the workshop was simple: if researchers need better RDM support, does that mean the Node should provide it?

One example came from ELIXIR Sweden, where the Node had started to define its RDM support by asking practical questions: who do we serve, what is our mandate, what do researchers need, which services already exist elsewhere and what can we realistically offer with the staff and funding available?

Here, mandate means the authority and remit a Node has to act. These questions helped participants distinguish between identifying a need and deciding what the Node should actually take responsibility for.

Why is this relevant?

Finding a gap does not automatically mean creating a new Node service.

Researchers may, for example, need better support with data management planning, metadata or data deposition. That support might already exist within universities, national infrastructures or ELIXIR. The problem may instead be that researchers cannot find it, that responsibilities are unclear or that support is fragmented.

This changes the question from what is missing? to what should the Node contribute?

The answer will differ between Nodes. Their mandate, national context, expertise, capacity and relationships with other organisations are different.

What can Nodes learn from this?

The Espoo discussions suggest a useful way to work through this:

  1. Start with the need. Who needs support and what is difficult for them?
  2. Check what already exists. Is suitable support already available elsewhere?
  3. Define the actual gap. Is a service missing, or is the problem visibility, access or coordination?
  4. Consider the Node’s role. Is this within the Node’s mandate, and where could it make a useful contribution?
  5. Choose the right level of involvement. The Node might lead, coordinate, connect or support. It may also decide that another organisation is better placed to take responsibility.

Participants also stressed that not every Node needs the same set of functions. What a Node can realistically offer depends on its competences, capacity and funding.

What can you do?

Take one of the areas for improvement you have identified and work through the questions above.

Suppose researchers have difficulty finding suitable data deposition support. Before adding a new deposition service to your strategy, check what is already available. You may find that repositories already exist and that the real problem is choosing between them or finding the right expertise.

In that case, the Node might add more value by connecting researchers to existing support than by creating another service.

Use the same reasoning for your other areas for improvement. This should help you decide where the Node should take a stronger role, where coordination is enough and where responsibility is better left elsewhere.

Together, these choices define the service scope of your strategy: the areas where the Node intends to contribute and the type of role it wants to take.