A data management plan (DMP) is a short, structured document that describes how you will collect, organise, store, protect, and share the data your research produces. Funders increasingly require one at the application stage, ethics committees expect it, and, more practically, it is the difference between a project whose data is analysis-ready at the end and one that spends its final weeks untangling inconsistent spreadsheets. This guide walks through what belongs in a plan, how to write each section, and the mistakes that most often send a DMP back for revision.
Why a data management plan is now expected
For years a DMP was good practice; today it is often mandatory. The United States National Institutes of Health Data Management and Sharing policy, in effect since 2023, requires a plan with almost every application. Major funders in the United Kingdom, the European Union, and Australia have parallel requirements, and most university ethics boards ask for one before approval. The reasoning is that publicly funded data should be reusable, and reuse is only possible when data is documented, standardised, and preserved. Writing the plan early also forces decisions, about formats, naming, and consent, that are painful to reverse once collection has started. A good plan is therefore not paperwork; it is the operating manual for the data side of your study.
What a data management plan must contain
Most funder templates ask for the same core sections, usually in one to three pages. A complete data management plan covers the data you will create, the standards and formats you will use, how you will store and secure it, how you will document and quality-check it, and how you will preserve and share it at the end. The sections below map to that structure. Treat each as a question your reviewer wants answered concretely, with specifics rather than aspirations.
Step one: describe the data you will collect
Start by stating what data the project will generate. Give the data types (survey responses, clinical measurements, interview transcripts, sequencing reads, imaging), the approximate volume, and the format of each. Note whether data is collected first-hand or reused from an existing source, and flag anything sensitive such as personal or health information. This section anchors everything that follows, because the right storage, standards, and sharing choices all depend on what kind of data you are handling. Be concrete: "approximately 300 participant records with 60 variables each, captured as an eCRF export in CSV" tells a reviewer far more than "quantitative data."
Step two: define standards, formats, and a data dictionary
Reviewers look for evidence that your data will be intelligible to someone who was not in the room when it was collected. Commit to open, non-proprietary file formats where possible (CSV over XLSX, plain text over vendor binaries) so the data outlives any single software licence. Adopt a documented file naming convention and version control. Most importantly, promise a data dictionary: a companion file that defines every variable, its units, its allowed values, and its coding. In clinical research this extends to recognised standards such as CDISC and controlled terminology, and to medical coding dictionaries like MedDRA and WHODrug. A plan that names its standards is far more convincing than one that gestures at "consistent formatting."
