A data management plan is the one part of a proposal that nobody enjoys writing and almost nobody reads carefully. That combination produces a particular kind of document: two pages of confident sentences about repositories and backups that describe a lab nobody actually runs.
It matters more than its length suggests. Not because a weak plan sinks a proposal — it rarely does — but because the plan is a promise you make about the next five years, and the person who has to keep it is usually a student who has not joined yet.
Anyone writing a DBT, SERB, ICMR or CSIR proposal in India who has reached the data management section and would rather not invent it. The structure works for most funders; the specifics here lean Indian. Nothing in it requires particular software.
What the section is actually asking
Strip away the phrasing and every funder is asking five questions. Answer these five and you have written the plan.
- What data will this project produce? Kinds, formats, rough volume.
- Where will it live while the project runs? And who can reach it.
- How will it be described so it means something to a stranger?
- What is shared, when, and what is not? With the reason.
- What happens when the project ends? Retention, and who is responsible.
Everything else is decoration. If a draft is long but leaves one of those five unanswered, it is a weak plan wearing a good suit.
The mistake nearly everyone makes
The commonest failure is not vagueness. It is describing infrastructure you do not have.
Plans routinely promise an institutional repository that does not exist, an automated nightly backup nobody has configured, or deposition in a public archive that has no category for the data in question. None of it is dishonest — it is copied from a template written for a different kind of lab, usually in a different country.
It also creates a problem three years later, when a student is told the data must go somewhere the lab has never used, in a format nobody has produced, because a sentence in a funded proposal says so.
Write it from what you already do
Before drafting anything, spend twenty minutes answering these on paper. This is the whole job; the writing afterwards is transcription.
Paragraphs you can adapt
These are deliberately modest. Replace the bracketed parts. If a sentence is not true of your lab, delete it rather than soften it.
Data to be generated
This project will generate [confocal image stacks, plate-reader measurements and analysis outputs]. Primary data will be produced by [instrument or facility], which writes [format], from which [open format] is exported at acquisition. We estimate approximately [N] GB per [experiment/month] and about [N] TB over the funded period. Analysis outputs will be [tabular files, scripts and figures] held alongside the primary data they derive from.
Storage during the project
Working data will be held on [institutional storage / a dedicated lab server / managed cloud storage], with a second copy on [independent medium] refreshed [frequency]. Copies are held in [two] physically separate locations. Access is limited to project members; the [PI and the senior research fellow] can restore from backup. Data are not held solely on instrument computers or personal devices, which are treated as transient.
Documentation and metadata
Each dataset is recorded with the date, the operator, the instrument and settings used, the sample or condition, and a reference to the protocol version followed. Files follow a documented naming convention [see below or attach one page]. Each stated result can be traced to the run and the original instrument file that produced it. Analysis steps, including any manual step, are recorded so a figure can be reproduced from primary data.
Sharing
Data underlying publications will be released at the time of publication [or within N months], deposited in [named repository] where a suitable one exists for the data type. Where no discipline repository exists, data will be deposited in a [general-purpose archive] with a persistent identifier and cited in the publication. Data that cannot be shared — [reason: human participant data, third-party material, protection pending] — are identified here, and processed or aggregated forms will be released instead.
Retention and responsibility
Primary data and the documentation needed to interpret them will be retained for [N] years from the end of the project, in line with [funder / institutional] policy. The Principal Investigator is responsible for the plan; day-to-day custody sits with [role, not a person]. On any team member's departure, their data and documentation are transferred to the shared store before their final month, and the transfer is checked by [role].
The documentation paragraph is the one most labs cannot honestly write, because the link between a result, the run, and the original file usually lives in somebody's memory. That is the problem woodle.cloud was built for. But the plan above is worth writing whatever you use — and most of it works on a shared drive and a spreadsheet.
See how it works →Three things reviewers notice
1. A volume estimate that was clearly calculated
“Approximately 40 GB per imaging session, roughly 4 TB over three years” reads as a lab that has thought about it. “Large volumes of data” does not.
2. A named limit
Stating clearly that something will not be shared, and why, reads as more credible than promising everything. Blanket openness is the claim reviewers most often disbelieve.
3. Responsibility that survives turnover
Roles, not names. Every plan written around a specific student expires when they submit.
The budget line nobody claims
Data storage and curation are allowable costs on most schemes, and are among the least contested lines in a budget. A modest, specific request — disks, an archive deposit fee, a share of a storage subscription — is usually approved without argument, and it makes the plan self-consistent: you have described work, and you have asked for the means to do it.
A plan that promises careful curation with no budget line is a plan that quietly relies on somebody doing it in the evenings.
These paragraphs are free to copy, edit and paste into your proposal. No attribution needed and no signup. If a sentence is not true of your lab, cut it — a shorter honest plan beats a long aspirational one.