AI Glossary / Data engineering and architecture / Advanced
Data management plan
Definition
A data management plan, often shortened to DMP, is a document describing how a project's data will be created or obtained, organized, protected, documented, shared and retained. It assigns responsibilities and identifies the resources needed to carry out those decisions. A useful plan covers both active project work and what happens afterward, and is revised when the project's data practices or requirements change.
What it means
A team may agree that its data should be well managed while leaving basic questions unanswered: where files belong, who maintains descriptions, how versions are identified and what happens when a team member leaves. A DMP turns those intentions into practical arrangements. It is common in research and also useful in business and AI projects. The document itself is not evidence that the arrangements have been implemented. Its value comes from guiding work that people can perform, check and maintain.
How it works
Describe the expected data and its lifecycle, then identify the methods, responsibilities and resources for each relevant stage. The Digital Curation Centre's checklist covers collection, documentation, storage, access, sharing, preservation and accountability. Apply those themes to the actual project rather than copying generic promises. Review the plan when sources, outputs or working arrangements change. Where a funder or institution has specific requirements, those need separate checking; a general glossary explanation is not a substitute for the applicable project template or policy.
Three practical examples
- A research team records which formats and metadata will accompany its measurements so another team can interpret them later.
- An AI project identifies who maintains the training-data versions and the record linking them to model experiments.
- A business study assigns responsibility for transferring final datasets and documentation to the agreed long-term location when the project closes.
Think of it this way
Imagine planning a shared expedition. The itinerary matters, but so do equipment, responsibilities, supplies and what happens when conditions change. Writing everyone will be careful does not identify who carries the map or checks the route. A data management plan has the same practical requirement: it should connect each important intention to an action and responsible role. It remains useful only while it reflects how the project actually operates.
Worked example
Consider an original hypothetical project expecting 40 gigabytes of source data and 20 gigabytes of derived results. If its design keeps one working copy and one separate backup copy of each, the initial data-copy requirement is 2 × (40 + 20) = 120 gigabytes. This is not a complete storage estimate: version history, temporary files, metadata and growth can add space, while compression could change physical usage. The DMP should record these assumptions and the role responsible for revising the estimate. Specifying two copies also does not by itself demonstrate recoverability; the actual backup and restoration arrangements need to be implemented and checked.
Illustrative case study
A fictional analytics team starts with a small customer-service dataset and a brief plan. Midway through the project, it adds audio files and produces several derived datasets. The original storage estimate and documentation approach no longer fit. The team revises the plan, assigns ownership of the new material and records how final outputs will be handed over. The scenario illustrates a plan evolving with the work. It does not imply that a longer document is automatically better or that adding a source is merely a storage decision without implications for interpretation, access and future use.
Common misconceptions and mistakes
A DMP is not just a backup schedule. It also addresses meaning, responsibility and the eventual disposition of data. It is not necessarily a promise to publish every record openly; appropriate sharing arrangements depend on the data and project context. Another mistake is writing the plan once and ignoring later changes. Naming a storage service does not establish that someone configured or tested it. Finally, copying a previous plan can preserve assumptions that no longer apply, such as expected formats, project roles or the intended audience for the outputs.
Business use
The concept helps expose data work that otherwise appears late in a project. Agree on the expected inputs and outputs, assign responsibility for maintaining them and include the required effort in planning. Make the arrangements specific enough to verify, without burying the team in irrelevant detail. For AI initiatives, describe how dataset versions and processing records will remain linked to experiments and outputs. Review the plan at meaningful project changes and handover points so it continues to support usable data rather than merely documenting an intention from the launch meeting.
People also ask
Is a data management plan only a storage plan?
No. It also covers documentation, access, responsibilities and future handling.
Must the plan remain unchanged after approval?
No. It should reflect relevant changes in the project and its requirements.
Does writing a backup promise prove the data is recoverable?
No. Implementation and restoration evidence are separate from the written plan.
Check your understanding
What was the toy project's initial data-copy estimate?
Answer: One hundred and twenty gigabytes.
What did it exclude?
Answer: Additional space for versions, temporary material, metadata and growth.
Why did the plan need an assigned owner for the estimate?
Answer: Someone must revisit its assumptions when the project's data volume or practices change.
Related terms
- Data lifecycle
- Metadata
- Backup
- data stewardship
- digital preservation
- reproducibility
Learn next
Draft a short plan for a hypothetical project with two data sources and one derived output. State where each will be kept, who maintains its description and what happens at project closure. Then introduce a new file type and identify which parts of the plan need revision rather than assuming the original arrangements still suffice.
More in Data engineering and architecture
- Data auditing - Data auditing is a systematic examination of data and, where relevant, the processes that handle it against stated criteria.
- Data binding - Data binding is a mechanism that connects data values to another representation so that values can be displayed, transferred or updated according to defined...
- Data blending - Data blending combines information from separate sources for an analysis or view, using agreed links and compatible levels of detail.
- Data-centric computing - Data-centric computing is an approach to computer-system design that treats the location, movement and access patterns of data as central concerns.
- Data-centric programming language - A data-centric programming language emphasizes describing, querying and transforming collections of data.
- Data-centric security - Data-centric security is an approach that organizes protection around the information itself: what it contains, how sensitive it is, who may use it and...
Sources
Digital Curation Centre, Data Management Plans: https://www.dcc.ac.uk/dmps Digital Curation Centre, Checklist for a Data Management Plan: https://dcc.ac.uk/DMPs/checklist The storage calculation, expedition analogy and analytics-team case are original educational illustrations. DCC guidance supports the planning themes; the example is not a statement of any particular funder's current requirements or a complete storage and retention policy.
Previous: Data loading Next: Data manipulation language