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, 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.
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. 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.
- 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.