At big research universities, research data services are a department: a team of specialists who help faculty write data management plans, organize files, find repositories, and meet funder requirements. At small colleges and regional universities, that department doesn't exist. But the need does. Faculty still get NIH and NSF grants with data-sharing mandates. Accreditors still ask about data governance. Students doing capstone research still need guidance on handling survey data about people.
The question isn't whether your campus needs research data support. It's how to provide it when you don't have dedicated staff, a separate budget line, or a model that fits your scale. This guide is for the librarian, IT director, or sponsored-programs officer who's been asked to figure that out, or who sees the gap and wants to fill it before it becomes a compliance problem.
Start with what researchers actually ask for
The temptation is to design a full service menu and then launch it. That's backwards. A better first move is to spend two weeks listening. Talk to five or six faculty who've applied for grants recently, or who work with human-subjects data, and ask two questions: what part of managing your data is hardest, and where have you gotten stuck?
At most small institutions, the same three or four things come up. Writing the data management plan that's now required with every federal proposal. Figuring out where to store sensitive data during a project. Choosing a repository when the journal or funder says "deposit your data." And basic file organization and documentation, especially on multi-person projects where the PI and the graduate assistant have different systems (or no system).
Those four problems are your starting portfolio. You don't need to solve them all at once, and you don't need to be an expert in all of them on day one. You need to be the person on campus who knows where the answers are and can walk a researcher through the process.
Anchor the service somewhere real
Research data services need a home, even if that home is one person spending 20% of their time on it. The library is the most natural fit at small institutions, because it already handles information management, it's neutral territory across departments, and librarians are trained to teach and consult. But sponsored programs offices work too, especially if the main driver is grant compliance. The worst option is leaving it unassigned, because then nobody owns it and nothing happens.
Wherever it lands, two things matter. First, the person doing the work needs institutional permission to spend time on it, not just enthusiasm. If it's a side project that disappears whenever something more urgent comes up, researchers will learn not to rely on it. Second, it needs a web presence, even a single page, so that faculty can find it and so the provost's office knows it exists. A service nobody can find isn't a service.
Build a DMP review as your first offering
If you're picking one thing to launch with, make it data management plan review. Here's why: every federal grant proposal now requires a DMP (NIH calls it a Data Management and Sharing Plan; NSF calls it a Data Management and Sharing Plan under the 2023 PAPPG update). Faculty often write these the night before submission, sometimes by copying one from a colleague in a different field. A bad DMP won't sink the proposal on its own, but a good one signals competence to reviewers, and a missing or noncompliant one can.
Offering to review DMPs before submission does several things at once. It's a concrete, bounded task: someone sends you a draft, you read it against the funder's requirements, you send back comments. It builds relationships with research-active faculty. And it gives you a window into what data challenges are coming down the road, because the DMP describes the data the project will produce and what will happen to it.
You don't need to write the plans from scratch (though you can). You need to know what each funder requires, what a compliant plan looks like, and what the common mistakes are. The guide to writing a data management plan on this site covers that ground.
Don't build infrastructure you can borrow
Small institutions often assume they need to buy or build a data repository, a research storage system, or a computing cluster before they can offer data services. They don't. Most of what researchers need already exists at the national level, free or nearly free:
- For data deposit, disciplinary repositories (ICPSR for social science, GenBank for genomics, many others) and generalist repositories (Zenodo, Dryad, the institutional repository you may already run on DSpace or Bepress) handle the archive and access layer.
- For computing, the OSPool and NSF ACCESS provide CPU and GPU cycles at no cost to researchers at qualifying institutions, which includes most U.S. colleges and universities.
- For storage during active projects, your campus IT likely already has some managed storage. If it doesn't meet researcher needs (capacity, sensitivity level, sharing), a conversation with IT about what would is more productive than building a parallel system.
Your role as a data services provider isn't to host everything locally. It's to know what's available, match each researcher's need to the right resource, and help with the paperwork and setup that connect the two. That's a knowledge service, not an infrastructure service, and it scales much better on a small budget.
Teach in small doses tied to real deadlines
Workshops on research data management have a reputation for low attendance, and the reason is usually timing and framing. A two-hour session on "best practices in data management" scheduled for a random Tuesday in October will draw four people, two of whom came for the free lunch. A forty-five-minute session called "Get your NSF data plan done before the deadline" scheduled three weeks before a major submission window will draw twenty.
The difference is specificity and urgency. Tie training to something researchers need to do anyway, and keep it short enough that attending feels like a shortcut instead of a detour. Office hours work well too: a standing weekly slot where anyone can bring a data question. You'll be slow at first, and that's fine. Being available and approachable matters more than being comprehensive.
Over time, the consultations and workshops create a knowledge base. The DMP template you build for one biologist works, with adjustments, for the next one. The repository comparison table you make for a social scientist is useful campus-wide. Each engagement produces material you can reuse, and that's how a one-person operation starts to look like a program.
Document what you do and who you've helped
This matters more at small institutions than at large ones, because small-institution services are always one budget cycle away from being questioned. Keep a simple log: date, researcher name, department, what they needed, what you did, and the outcome (proposal submitted, data deposited, problem resolved). At the end of the year, you can report that you supported X grant proposals representing $Y in funding requests, helped Z faculty meet funder data-sharing requirements, and trained N people. Those numbers are how the service survives and grows.
If a researcher's funded proposal includes a data management plan you helped with, note that. If a dataset you helped deposit gets cited, note that too. The story you're building is simple: this service helps the institution win and manage grants, meet compliance obligations, and produce better research. That story is much easier to tell with a log than from memory.
Grow by adding one thing at a time
Once the DMP review is running and you've done a few consultations, expand based on what people keep asking for. Common second and third additions:
- Repository guidance: a short guide or consultation helping faculty pick the right repository for their data, deposit it correctly, and get a DOI. The repository guide can help here.
- IRB data language: many IRB protocols describe data storage and sharing in vague or outdated terms. Helping PIs write the data sections of their protocol, or reviewing that language before submission, prevents problems at the compliance stage.
- File organization and documentation: a standard template for project READMEs and folder structures that new projects can adopt. The data organization guide covers this.
- Data ethics consultation: as AI and secondary data use grow, faculty increasingly have questions about what they're allowed to do with existing datasets, especially ones involving people. Having someone on campus who can discuss data ethics questions before a project starts is valuable.
Each addition should come from observed demand, not from a conference presentation about what R1 universities offer. Your institution isn't an R1, and that's not a weakness. It means you can be more responsive, more personal, and faster to adapt, because there are fewer layers between the service and the people it serves.
You don't need to do this alone
Building research data services from nothing is real work, and it's reasonable to bring in outside help for the parts that need specialized knowledge: setting up the first data management plan template to match your institution's grant portfolio, connecting researchers to national computing resources they didn't know they qualified for, or auditing your current data practices against funder requirements. That's the kind of project I work on. If you'd like to talk through what makes sense for your campus, reach out.
Common questions
Do we need a dedicated budget to start? No. Most small institutions start with one person spending a fraction of their time on it, often inside the library or sponsored programs office. The first offering costs staff time, not new money. Budget conversations get easier once you can show demand and outcomes.
What should the first service be? Data management plan review. Every federal grant proposal now requires one, faculty often write them at the last minute, and reviewing a draft against funder requirements is a bounded task you can do without buying infrastructure.
Do we need to build our own repository or computing cluster? Usually not. National and disciplinary repositories already handle data deposit, and programs like OSPool and NSF ACCESS provide free computing to researchers at qualifying institutions. Your role is to connect researchers to what already exists, not to host everything locally.
Where should the service live on campus? The library is the most common home because it already handles information management and sits outside any one department. Sponsored programs offices work too, especially where grant compliance is the main driver. The one thing to avoid is leaving it unassigned, because then no one owns it.