How to Write a DMP
1. Identify your DMP Guidelines
Identify your solicitation or Request for Proposals (RFP) and any guidelines regarding data management plans. Read them and jot down any specific demands.
Keep in mind: In NSF, most directorates and some divisions have unique, specific or narrower guidelines to follow than the general NSF specifications.
Example: In response to the Division of Materials Research: Topical Materials Research Program (DMR:TMRP) Solicitation, an applicant will see the following directions:
Fig.1 - Screenshot of Data Management Plan Requirements for DMR:TMRP 2021 Proposals
Within those instructions, applicants are directed to “be responsive” to the guidance in the Division of Materials Research document on the following page:
Fig.2 - Screenshot of Dissemination and Sharing of Research Results - NSF Data Management Plan Requirements
Your data management plan should be responsive to any particular demands or expectations laid out in these documents. You often are not required to follow suggestions precisely, but they expect that your plan will still follow the spirit of their guidelines. For example, they may recommend a specific repository, but others may be acceptable as well, as long as you accomplish the effect of the data shared in a FAIR-compliant manner.
2. Outline a Draft Document
Outline a document with the required sections listed in the guidelines. These may be spelled out explicitly, or these may be presented as a set of questions that you must address. In the latter case, just create sub-headings that address each question.
An example would be something like this for the NSF Solicitation above:
Fig.3 - Screenshot of an NSF-conforming DMP outline
3. Outline Your Project’s Outputs
Separately, create a simple outline for yourself of the stages of your research project and the material generated at each stage. What is meant by material? The outputs – the files, papers, documents, data, notebooks, copies of things. The stuff you generate, especially by writing, coding, or processing, or that is generated by your instrumentation or tools. It might useful to create a workflow diagram, or just a numerical list of each planned step.
4. Detail Your Project’s Outputs
Using the outline of the outputs you outlined above, write down their file formats, expected size, and any unusual or special circumstances associated with them, e.g. privacy or confidentiality steps involved.
5. Fill in the Draft with Your Information
Write answers to the questions from item 2 above using the information you’ve gathered in items 3 and 4. Everything should read clearly and simply. Please note - unless you are claiming exemptions from the idea of publicly sharing your data, you do not need to justify your formats, file sizes, etc. The point of the DMP is to lay out your steps and stages, showing that you are thoughtful about how your plan to manage your data and associated resources.
Tips For Success
Data management plans should be clear, logical, and easy to follow.
Avoid unnecessary jargon. A reader should be able to follow your project by reading your plan. Don’t bother explaining or justifying the science here (that’s what the other parts of the proposal are for), focus instead on explaining the data management. Think ‘what’ and ‘where’ of your data, more than ‘why’.
The DMP should have some unique information not in the rest of the proposal. You may not mention publishing the dataset, depositing it into a repository, or your choices of metadata schema anywhere else in your proposal. You may not mention specifics about data formatting, back-up procedures, or naming conventions (if relevant). Here’s the place to do it.
Don’t overthink it. But on the other hand, don’t treat this as an unfunded mandate or administrative burden either. Cynicism or hand-wavy dismissal of the task is easy for a reader to spot and reflects poorly on your proposal. Just do your best and get it done. The DMP is not yet (at the time of writing) a central aspect of most proposal reviews.
If there are legal or ethical restrictions, write down what you will do to meet them and/or how they constrain your ability to share or publish data. If you really don’t want to follow an expectation in the guidelines, write a justified reason for not doing it. Intellectual property and future commercialization might be perfectly valid reasons under the right circumstances for not publishing data, among others.
Boilerplate language is easy but terrible. Writing a clear and unique DMP for your project will always result in a better showing than a document clearly written for a different situation, or written to be so vague it can just be slotted into anything. A reviewer can see this.
If you don’t know, ask. Some of this might be unfamiliar – what’s a metadata schema? What are my repository deposit options? If so, just ask at the U of I Library Data Hub. If they aren’t the right people to help, they know the people on campus who can.