Developing a shared approach to data management is not always straightforward in a distributed environment like ELIXIR. Responsibilities, services and expertise are often spread across roles, institutions, projects and national initiatives. A strategy helps connect this existing work, clarify responsibilities and create a shared direction.
Use these for inspiration while you work through this chapter. The examples show how different Nodes used practical activities, existing resources and early discussions to begin developing a more coordinated approach.
Why a data management strategy matters
ELIXIR Nodes bring together many institutions, services and communities. Each group works with data in different ways. Without a shared direction, coordination becomes difficult. A strategy helps create this direction and provides clarity.
Strategy development is often triggered by external drivers such as funder requirements, national open science policies, infrastructure evaluations or new opportunities for collaboration.
- Direction and priorities: A strategy shows what the Node wants to achieve in data management and where it wants to focus its efforts.
- Efficiency and shared understanding: It reduces duplication, improves communication and helps staff understand their roles.
- Planning and sustainability: A strategy supports long-term planning. It helps the Node decide which services to maintain, where to invest effort and how to respond to new demands or opportunities.
- Scope and responsibilities: A strategy helps clarify what should be coordinated at Node level and what remains with individual institutions, projects, services or teams. It does not require every partner to work in the same way.
- Mandate and legitimacy: A strategy helps explain why certain activities belong at Node level. It gives a transparent basis for decisions about priorities, investments and coordination.
Changes in requirements, services or research practices can also create a practical reason to improve coordination.
Developing a strategy is not the responsibility of a single role. It requires input from coordination, data stewardship, technical teams and user-facing support to reflect the full data landscape.
What a data management strategy is and does
A strategy is not a complex policy document. It is a simple way to bring clarity to how data is managed across the Node or institution.
The exact format can differ between Nodes. A strategy may be a short standalone document of around 1–3 pages, or a clearly identifiable part of a broader Node plan. See All examples for examples of how Nodes have approached this.
A strategy has a few key characteristics:
- A short, practical document: A strategy outlines the main goals of the Node, the data landscape it serves and the principles that guide its work.
- Selective and connected: A strategy brings together information that is often distributed across multiple sources. It does not replace policies, service descriptions or Data Management Plans. Instead, it identifies what matters at Node level and links to the relevant institutional policies, services, strategies, plans and other supporting documents.
- Services and roles: A strategy shows how the Node supports good data management and FAIR practices. It describes the main services, roles and communities involved.
- A shared reference point: It gives staff a common view of the current situation and future direction.
- A living document: The strategy is light and easy to update. It can begin as a rough outline, a collection of existing materials or another simple working format and develop as the Node grows, new roles appear or priorities shift.
Developing the strategy can already be useful before the document is complete. Having the conversations, mapping existing data management activities and discussing the direction the Node wants to take can make existing work more visible, connect people who do not usually work together and clarify where responsibilities or decisions are still unclear.
Quick reflection: risks without a data management strategy
Consider your current situation:
- Which decisions are currently made case by case because there is no shared direction?
- Where do responsibilities, ownership or decision-making remain unclear?
- Where are services, expertise or support duplicated, overlooked or difficult to find?
- Are priorities mainly shaped by urgent requests rather than deliberate choices?
- Which activities depend heavily on individual people, projects or temporary funding?
- What might remain unclear for staff, partners or users?
Choose one or two risks that matter most for your Node. These can help explain why a strategy is needed and where to begin.
Exercise: define your reason for starting
Bring your observations together in a few sentences.
-
Why now?
What challenge, change or opportunity makes this a useful time to work on the strategy? -
What should the strategy help clarify or improve?
This might be coordination, responsibilities, visibility of existing support, sustainability or another issue that matters in your Node.
You do not need to solve these issues yet. The aim is to be clear about why you are starting and what you want the strategy process to help with. You will build on these observations in Chapter 3: What to include
Keep this lightweight. A clear reason for starting is enough for now.
Quick exercise: starting your strategy
Now look at what you can already build on. A strategy links existing work. Nodes often have policies, maturity assessments, training plans and service descriptions. The strategy brings these together and shows how each element contributes to the wider picture.
Before moving on, write this down. It will help you make the next steps more concrete.
-
Think about what already exists
Write down three to five concrete examples from your Node; things people already use, rely on or refer to when managing data. For example: What guidance exists? What services or tools are available? Who provides expertise or support? What training is offered? Which partnerships or working arrangements already help coordinate data management?Example: Your Node may already have a data stewardship contact point, a training programme, institutional data policies and an established collaboration with a national repository.
-
Group and connect them
Which items belong together? Who is responsible for them? Are there overlaps, unclear connections or areas that are difficult to find? -
Reflect
What feels clear and well connected? What feels fragmented, difficult to find or unclear in ownership? Before identifying a gap, check whether the activity or expertise may already exist elsewhere in the Node.
The aim is not to create a complete inventory. It is to identify where existing work can be connected and where greater clarity or coordination may be needed.
Compare your notes with a colleague. Do you see the same picture, or are there differences in perspective?
Who to involve
Developing a strategy is not the responsibility of a single role. A small group with different perspectives can help make sure the strategy reflects both the overall direction of the Node and how data management, services and support work in practice.
Consider whether you have the following perspectives involved:
- A Node coordinator or other coordination role to connect the work with Node priorities and decision-making
- A data steward, data manager or technical staff member with knowledge of standards, tools, services and workflows
- A support or training staff member who knows what researchers most often ask for help with
- An institutional, infrastructure or community representative who can bring a perspective from where activities happen in practice
You do not need everyone involved from the beginning. Start with the perspectives that are most relevant to your current starting point and involve others as needed.
If only one or two perspectives are represented, important aspects of the data landscape may be missed. If some perspectives are not available within your Node, consider involving relevant partners or checking your emerging strategy with them later. See Roles, competences and your Node team for examples of how relevant expertise may sit across different people and organisations.
What’s next
You now have a clearer reason for developing or refining your Node data management strategy and a practical starting point. In Chapter 2, you will look more closely at the context in which the strategy needs to work.