For most researchers, the data management plan is the two pages of a grant proposal written last, in a hurry, the night before the deadline. Reviewers can tell. A vague plan does not usually sink an application on its own, but it signals that the applicant has not thought carefully about the work, and on a competitive panel, that impression is expensive.
The good news is that a data management plan (DMP) is one of the most learnable parts of a proposal. It asks a small set of concrete questions, and once you have answered them well for one project, most of your answers carry over to the next. This guide walks through what each required section is really asking, the mistakes that get plans flagged, and an outline you can reuse.
What a DMP is actually for
A data management plan describes what will happen to the data your project produces, during the work and after it ends. Funders ask for one because they are paying for the data as much as the paper, and public and non-profit funders increasingly expect that data to be preserved and, where appropriate, shared. Many major funders now require a plan of this kind, and several have moved toward expecting data to be shared by default rather than on request.
Underneath the varied templates, they are all asking the same six questions. Answer these clearly and specifically and you have a strong plan.
A good DMP is not a promise to be careful. It is a set of specific, checkable decisions someone else could carry out if they had to.
The six questions every plan answers
1. What data will you produce?
Describe the data by type, format, and rough volume. Not "we will collect survey data," but "approximately 1,200 responses in CSV exported from Qualtrics, plus 30 interview transcripts in plain text." Name file formats (the file formats guide helps here), and prefer open, non-proprietary ones (CSV over XLSX, plain text or PDF/A over a vendor format) so the data stays readable in ten years. This section tells the reviewer you know the shape of your own project.
2. How will it be documented?
Data that no one can interpret is not preserved in any meaningful sense. Explain how someone outside your team would understand your files: a README that lists every file and variable, a data dictionary defining each column and its allowed values, and a note on any standards or controlled vocabularies you follow. Documentation is the single most common weak spot, and the cheapest one to fix.
3. How will you store and back it up during the project?
State where the working data lives and how it is protected against loss. Institutionally managed storage with automatic backup is the expected answer; a single laptop or personal cloud drive is a red flag. If any data is sensitive, this is where you describe access controls, encryption, and who is allowed to touch it.
4. How will you handle privacy, ethics, and sensitive data?
If your data involves people, connect the plan to your IRB protocol. Describe how identifiers are removed or protected, how consent covers any future sharing, and what safeguards apply to restricted data. Reviewers want to see that your sharing commitments and your ethical commitments do not contradict each other: "we will share everything openly" and "participants were promised confidentiality" cannot both be true without a plan for how you reconcile them.
5. How, when, and where will you share it?
Name the repository you will deposit in, not just "a repository." A domain repository or an established general one (for example, an institutional repository, ICPSR for social-science data, or a discipline-specific archive) signals that your data will be findable and preserved. Say when you will deposit, commonly at publication or project end, and under what license or access conditions. Where data cannot be fully open for ethical or legal reasons, say so plainly and describe controlled access instead. A restricted-but-documented plan beats a vague promise of openness. If the funder asks whether your data will be "FAIR," answer with these same specifics; the plain-language FAIR guide shows how.
6. Who is responsible, and what will it cost?
Name a person or role accountable for the plan, and account for the effort and any fees involved: curation time, repository deposit costs, storage. Many funders let you budget for data management directly (the budgeting guide shows how). A plan with an owner and a line item reads as one that will actually happen.
The mistakes that get plans flagged
- Being generic. "Data will be stored securely and shared as appropriate" says nothing. Every sentence should contain a specific: a format, a repository name, a timeframe, a person.
- Ignoring the after. Plans that cover the project but go silent on preservation and sharing miss the point of the requirement. Say how long the data will be kept and where; the retention guide gives the numbers.
- Contradicting the ethics section. Promising open data for material collected under confidentiality is the fastest way to draw a reviewer's pen.
- No documentation plan. Sharing files without a README or data dictionary means sharing something no one can reuse.
- No named owner. If everyone is responsible, no one is. Assign it.
A reusable outline
Keep a template with these headings and adapt it per project rather than starting blank each time:
- Data description: types, formats, estimated volume.
- Documentation and metadata: README, data dictionary, standards.
- Storage and backup: where it lives during the project, how it is protected.
- Privacy and ethics: IRB link, de-identification, access controls.
- Sharing and preservation: repository, timing, license or access level.
- Roles and cost: who owns it, what it costs, where it is budgeted.
Most institutions with a research-data service can review a draft before you submit, and free tools exist to build plans against specific funder templates. Using them a week before the deadline instead of the night before is most of the battle.
The takeaway
A data management plan rewards specificity over polish. Name your formats, your repository, your safeguards, and your owner, make sure your sharing and ethics commitments agree, and you will have a plan that reads as the work of someone who has thought it through, because you will have.
Common questions
How long should a data management plan be?
Most funders cap it at one to two pages. NSF's current template allows up to two pages for most directorates; NIH's plan is typically shorter, often under a page, since it is one part of a larger resource sharing plan. Check your specific funding opportunity for the exact limit, since it varies by program.
Do I need a plan if my project doesn't collect new data?
Usually yes. If you're reusing an existing dataset, the plan still needs to describe what you'll produce: derived datasets, code, analysis outputs, or a curated subset. Explain how that output will be documented and shared, even though the underlying source data already exists elsewhere.
What if my data can't be shared openly?
Say so directly and explain why: participant confidentiality, proprietary agreements, national security, or something similar. Then describe the closest workable alternative, such as controlled access through a repository, a data use agreement, or sharing a de-identified or aggregated version. A clearly justified restriction is a normal answer; a vague one is not.
Which repository should I name?
Pick the most specific one that fits your data: a discipline repository if your field has one (ICPSR for social science, GenBank for sequence data, and so on), your institutional repository if not, or a generalist option like Dryad or Zenodo as a fallback. Naming a real repository, instead of "a repository will be selected," is one of the clearest signals reviewers look for.
Can I reuse the same DMP across grant applications?
The core structure and most of the language can carry over, since the six questions above stay the same from project to project. What changes each time is the specifics: the data types and volume for that project, the applicable IRB protocol, and any funder-specific formatting. Keep a master template and adapt the details instead of starting from a blank page.