Data management plan checklist

← All writing

Most data management plans get flagged for the same handful of things, and almost all of them are catchable in twenty minutes with a list. This is that list. Work down it while you draft, then run the pre-submission review at the end.

It's deliberately funder-neutral. Templates differ, but underneath they ask the same questions, so use this to check your thinking and your funder's template to check your formatting. If you want the reasoning behind each section, the companion article walks through what each part of a DMP is really asking.

Ticks are for this browsing session only. Nothing you check is stored or sent anywhere.

Before you write a word

• I have my funder's current template or policy open, not last cycle's.
• I know the page or word limit and whether the plan counts against the proposal limit.
• I've checked whether my program or directorate adds requirements on top of the agency-wide policy.
• I know whether my institution has a research data librarian or office that reviews drafts, and I've left time to use them.
• I've asked co-investigators at other institutions what their side commits to, so the plan covers the whole team.

1. What data will you produce?

• Each data type is named specifically (survey responses, interview transcripts, instrument output, administrative records, simulation output, code).
• File formats are named, and open or widely readable ones are preferred where possible (CSV alongside the statistical package file, plain text or PDF/A alongside a vendor format).
• Rough volume is estimated (number of records, files, or gigabytes), not left as "a large dataset."
• Data you reuse from someone else is listed separately from data you create, with its source named.
• Any terms attached to reused data (a data use agreement, a license, a vendor contract) are noted, including whether they allow redeposit.
• Software and code the project produces are covered, not just the data files.

2. How will it be documented?

• A README is promised, and the plan says what it will contain: project summary, file inventory, and the order the analysis runs in.
• A data dictionary or codebook is promised: every variable, its meaning, its units, and what each code stands for.
• Any metadata standard or controlled vocabulary used in my field is named.
• File naming and version conventions are described in a sentence, so files arrive at the repository already organized.
• Documentation is described as something written during the project, not assembled at the end.

3. Storage and backup during the project

• The working storage location is named and is institutionally managed, not a personal laptop or a personal cloud account.
• Backup is described concretely: how many copies, in how many places, and how often.
• Someone has actually tested that a file can be restored, or the plan commits to testing it.
• Access controls are described: who on the team can read, write, or delete.
• If any data is sensitive, encryption at rest and in transit is addressed.
• The plan says what happens to the working copies when the project ends, including when a student or postdoc leaves.

4. Privacy, ethics, and sensitive data

• The plan states whether the project involves data about people, and links to the IRB protocol or states that review is planned.
• The consent language permits the sharing the plan promises. If it doesn't, the plan promises less.
• De-identification is described beyond removing names: dates, geography, small cells, rare characteristics, and free text are addressed.
• Any legal or regulatory frame that applies is named (for example HIPAA, FERPA, GDPR, tribal or community data governance, an export control restriction).
• Where full openness isn't appropriate, controlled access is described rather than openness quietly dropped.
• The sharing section and the ethics section don't contradict each other. Read them back to back.

5. Sharing and preservation

• A specific repository is named, not "an appropriate repository."
• The repository issues a persistent identifier (a DOI or similar), so the dataset is citable.
• The repository can support the access level I need, including restricted access if the data are sensitive.
• Timing is stated: deposit at acceptance, at publication, or at project end, with any embargo explained.
• A license is named (CC0 and CC BY are the common choices for data) or the access conditions are spelled out.
• Code has a home too, and a license, if code produced the results.
• The preservation horizon is stated: how long the data will be kept and by whom.
• Data that can't be shared are identified, with the reason given plainly rather than left unsaid.
• Nothing in the plan relies on "available from the authors on request" as the sharing mechanism.

6. Roles and cost

• One named person or role owns the plan. Not "the team."
• Responsibilities are split where they belong: who documents, who deposits, who answers questions after the award ends.
• Effort for data management is accounted for, whether that's staff time, student hours, or a percentage of someone's effort.
• Repository deposit fees, curation costs, and storage costs are in the budget, and the budget justification matches.
• The plan says what happens to responsibility if the named owner leaves the institution.

Pre-submission review

Read the draft once more with these in mind. This is the pass that catches what reviewers catch.

• Every paragraph contains at least one specific: a format, a repository name, a timeframe, a number, or a person. Delete or replace any sentence that could appear in anyone's plan.
• The phrases "as appropriate," "where possible," and "securely stored" either carry a specific with them or are gone.
• The plan covers the after, not just the project: preservation and sharing, not only storage.
• The data described here match the data described in the project narrative and the budget.
• Everything promised is something the team can actually do with the resources requested.
• Formatting follows the template: required headings, page limit, font and margins, and the file uploaded to the right slot in the submission system.
• Someone who isn't on the project has read it, ideally a research data librarian.
• The plan is saved as a reusable template for the next proposal, because most of these answers carry over.

The test a reviewer applies without saying so: could a competent stranger carry out this plan if the whole team vanished? If not, it isn't specific enough yet.

Using it after the award

A DMP isn't a document you write once and file. Put a calendar reminder at each project year to reread it and check whether reality has drifted, and again three months before the award ends, when there's still time and money to do the deposit properly. Funders increasingly ask about compliance at renewal or reporting time, and a plan you've kept up with is much easier to report on than one you have to reconstruct.