Common NIH DMSP Mistakes and How to Fix Them

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

The most common NIH DMSP mistake is writing the plan as a compliance formality instead of a project document. A Data Management and Sharing Plan (DMSP) is the short document that describes what scientific data a proposed NIH-funded project will generate, where the data will be stored and shared, and who will oversee the process. Reviewers and program officers read it to judge whether the data sharing promise is realistic. When the plan is copied from a colleague's old grant or pasted from a generic template, it usually describes a project that does not exist, and the mismatch shows up at review, at award, or at the end of the project when the data never arrive in a repository.

The pattern is documented. In a survey of researchers at an academic medical center, 67% said they understood the NIH Data Management and Sharing Policy, but only 47% felt comfortable actually developing a DMSP, and only 29% had ever used DMPTool.org, a free web-based tool for drafting these plans [1]. Understanding the policy and writing a workable plan are two different skills, and that gap is where most mistakes are born.

The first thing to check, if you already have a draft plan, is simple. Read your Specific Aims page and list every distinct data type your project will generate, then compare that list against the data types named in your DMSP. If the aims mention single-cell RNA sequencing, electronic health record extracts, and survey data but the plan only says "genomic data will be shared," you have the most common failure mode, and the fixes below apply directly to you.

Why NIH DMSP Mistakes Happen

Most NIH DMSP mistakes come from a small set of causes, and knowing the cause tells you which fix will work.

The policy is new relative to research careers. The 2023 NIH Data Management and Sharing Policy changed expectations for everyone, including well-funded laboratories that had successfully managed data for decades under older, looser expectations. Many researchers learned data management by practice, not by policy, so their instincts about what to promise in a plan are calibrated to the pre-2023 era.

Support is uneven. The same survey found that 87% of researchers wanted tailored, discipline-specific templates, and confidence was lowest for exactly the two tasks that decide whether a plan is realistic, namely identifying an appropriate repository (40% expressed confidence) and budgeting for data management and sharing activities (38% expressed confidence) [1]. A researcher who does not know which repository accepts their data type will invent one or promise something vague, and a researcher who does not know what costs are allowable will either omit the budget entirely or pad it with unjustified lines.

Plans are written alone and under deadline pressure. Grant proposal planning usually concentrates on aims, approach, and budget pages because those determine the score. The DMSP is often written last, by one person, the week before the deadline. Documents written that way inherit template language and describe idealized versions of the project.

Writing the plan and executing the plan are different jobs. In the survey above, 68% of respondents perceived executing the plan as burdensome, and qualitative responses described administrative overload and uncertainty about handling sensitive data [1]. A plan can be approvable on paper and still fail in practice if nobody on the team owns the execution.

Implementation is the hard part everywhere. The same pattern appears across health research more broadly. Reviews of implementation science note that well-designed interventions often underperform in practice because the systems, standards, and day-to-day workflows around them are not addressed, which is why implementation planning is now treated as a discipline of its own rather than an afterthought [2]. A DMSP is a small implementation plan, and it fails for the same reasons larger ones do.

The First Checks: A 15-Minute Diagnostic Sequence

If you have a draft DMSP, or a rejection or program officer comment about one, work through this sequence in order. Most people find their problem within the first three steps.

1. Match data types to aims. List every data type in the Specific Aims and Research Strategy. Confirm each one appears in the DMSP with a storage and sharing statement. Flag any data type in the plan that the aims never mention.
2. Check repository names. Every repository named in the plan should be real, currently accepting submissions, and appropriate for the data type. Search the repository name plus the word "submissions" and confirm your data type appears in its scope.
3. Read the sharing promise aloud. Sentences like "data will be made available upon reasonable request" fail NIH expectations for named repositories. If the plan promises sharing without naming where, that is the error.
4. Check consent language for human data. Pull the informed consent form and the IRB protocol. Confirm the consent covers future sharing and de-identified secondary use, and that the plan's sharing promises match what participants agreed to.
5. Check the budget justification. Confirm data management and sharing costs appear in the budget justification and that each cost is tied to a named activity, such as curation hours, repository deposit fees, or secure storage.
6. Check the timeline and oversight. The plan should state how long data will be preserved and name a person responsible for oversight. If neither appears, add both.

Troubleshooting Table

This table covers the failure modes reviewers, program officers, and data librarians see most often. Work top to bottom, because the most common problems are first.

Mistake by Mistake, From Most Common to Rarest

Mistake 1: Submitting a template with the project stripped out

This is the single most frequent failure. A plan lifted from a previous grant, a colleague's grant, or an online example keeps the template's structure but loses the specific facts reviewers look for. The mechanism is straightforward. Templates exist to remind you which elements to address, not to supply the answers. NIH expects the plan to describe the data types the project will generate, the standards for those data, the repositories, the preservation timeline, and the oversight approach, all for this project.

The fix is a rewrite pass, not a rewrite from scratch. For every sentence in the plan, ask whether it could appear in any other grant. If yes, replace it with a sentence that names your data, your instruments, your population, or your formats. A sentence such as "standard metadata will be used" becomes "each scRNA-seq library will be deposited with cell-level metadata following the Human Cell Atlas schema, including donor ID, tissue source, and processing batch." Specificity is the fix, and it costs about an hour per data type.

This is also where discipline-specific templates earn their keep. Standardized templates and proformas have been shown in clinical settings to improve compliance with protocols and consistency of documentation, because the structure prompts people for the fields they would otherwise omit [3]. In the researcher survey, 87% of respondents requested tailored templates for exactly this reason [1]. If your institution or your professional society offers a DMSP template for your field, use it as the prompt list, then fill every field with project facts.

Mistake 2: Promising "data available upon request"

Under the 2023 policy, NIH expects plans to name repositories wherever feasible. "Available upon request" is the legacy language of the pre-2023 era, and it fails for a mechanical reason: it transfers the burden of finding, verifying, and transmitting data onto individual requesters and onto a lab email account that may not exist in ten years. It also produces no persistent identifier, which means the shared data cannot be cited, and it provides no usage records that demonstrate the sharing actually happened.

The fix is to name a repository for each data type. Community-recognized repositories exist for most major data types, including sequence archives for nucleotide and protein data, structured repositories for imaging and structural data, and generalist repositories that accept heterogeneous data when no domain repository fits. If you believe no repository is appropriate for a given data type, the plan must say so explicitly and justify it, for example when data cannot be de-identified or when the volume makes repository deposit infeasible. A justified exception is acceptable. An unexplained default to "upon request" is not.

Mistake 3: Promising to share human data the consent does not cover

This mistake has the highest stakes, because it creates a conflict between a federal promise and a research ethics obligation. The mechanism looks like this. The study team writes an ambitious DMSP promising individual-level genomic and clinical data in an open repository. The consent form, written years earlier, says participants' data will be kept confidential and says nothing about deposit into public databases. The plan and the consent now contradict each other, and the consent governs.

The fix starts before you write the plan. Read the consent form and the IRB protocol first, then write sharing promises that match them. Options, in rough order of increasing openness, include not sharing the data at all with a justification, sharing only summary or aggregate results, depositing de-identified data in a controlled-access repository, and depositing fully open data where consent and law permit it. Matching the plan to the consent at the proposal stage is far easier than amending consent retroactively.

Safety note on human data. De-identification failures cause real harm, including re-identification of participants, loss of employment or insurance, and stigma, particularly for data on mental health, substance use, reproductive health, and rare diseases with small populations. Treat de-identification as a hazardous step that requires verification before any deposit, never upload raw files containing direct identifiers, and confirm that the chosen repository's access controls match the sensitivity level of the data. Uncertainty about handling sensitive data was one of the top implementation burdens researchers reported in the academic medical center survey [1], so escalate to your IRB and institutional data security office rather than guessing.

Mistake 4: Getting the budget wrong in both directions

Two budget errors dominate, and they pull in opposite directions.

The first error is omitting data costs entirely, usually because the writer believes data management must be cost-free or because they fear reviewers will penalize the request. The second is padding the budget with lines that are not tied to specific activities. Both fail for the same reason. NIH expects data management and sharing costs to appear in the budget justification, tied to named activities such as personnel effort for curation, secure storage fees, repository deposit fees, and hardware or software needed to prepare data for sharing.

The fix is itemization. List each data type, list what must happen to it before deposit, assign a cost to each step, and write one justification sentence per cost. In the survey, only 38% of researchers felt confident budgeting for DMS activities, and budget guidance was among the most requested forms of institutional support [1], so if you find this hard, you are in the majority and your institution's grants office or library is the correct first call.

Mistake 5: Naming the wrong repository, or a fictional one

Reviewers occasionally see plans that name repositories which do not exist, have stopped accepting submissions, or do not accept the stated data type. The mechanism is usually a drafting shortcut, where the writer remembered a repository name from a talk or a paper and never verified it. Confidence in identifying appropriate repositories was low in the survey, with only 40% of respondents expressing confidence [1].

The fix is verification, which takes minutes per repository. Confirm the repository exists, confirm it currently accepts submissions, confirm your data type is in scope, confirm it issues persistent identifiers, and note its access model, whether open, controlled, or managed. When a domain repository does not exist for your data type, the plan should say so and route that data to a generalist or institutional repository, with the reasoning stated. Institutions vary widely in the support they can provide here, which is why the survey's qualitative findings emphasized centralized consultation and equitable access to data expertise across departments [1].

Mistake 6: Vague standards, formats, and metadata

A plan that says data "will be shared in standard formats" has not said anything. The mechanism behind this mistake is that metadata feels like a detail during grant writing, so the writer postpones the decision, and the postponed decision becomes a vague sentence. The problem is that reviewers use the standards section to judge feasibility, because a data type with no workable format or metadata plan cannot be reused by anyone, which defeats the purpose of sharing.

The fix is to name, for each data type, the file format, the metadata standard or minimum information checklist where one exists, and any identifier scheme the data will carry. If your community has no established standard, the plan should say which format you will use and why, and that honest statement is stronger than a fake reference to a standard you will not follow. Methods guidance research shows that guidance documents work best when they are developed with input from the people who will use them and are tested against real cases rather than issued as abstractions [4]. Apply the same principle to your own plan. Test each standards statement against the last real dataset your lab produced and confirm the statement describes something you actually did.

Mistake 7: Treating the DMSP as one-and-done

A DMSP is a living document. Projects change. Instruments break and get replaced, a subaward drops out, a new aim adds a data type, the chosen repository changes its policies. A plan that was accurate at submission and never revisited becomes a quiet record of promises the project no longer intends to keep, and that gap surfaces at reporting time or at renewal.

The fix is procedural. At each award reporting period, compare the current state of the project against the approved plan, and if the plan no longer reflects reality, submit an updated plan through the NIH mechanisms for post-award changes. Name one person, by role, as the plan's owner, and put two calendar entries in the project schedule, one mid-project review and one before the final reporting period, with the explicit task of verifying that promised deposits actually exist and carry persistent identifiers.

Mistake 8: The plan is approved, then nothing happens

The rarest-looking mistake is actually the most expensive one, because it occurs after the award, when fixing it costs time, credibility, and renewal prospects. The mechanism is diffusion of responsibility. The principal investigator wrote the plan, a co-investigator agreed to deposit data, and nobody's calendar contained the task. In the survey, 68% of researchers perceived plan execution as burdensome, and respondents called for centralized consultation and clearer institutional guidance rather than more policy documents [1].

The fix borrows from how health systems structure complex multi-step processes. Perioperative teams organize recurring tasks into named functions that recur at each critical transition, which keeps shared situational awareness high when many people and phases are involved [5]. Translate that to data. Define the recurring functions of your data plan, such as PLAN for what gets deposited, PREPARE for curation and de-identification, PERFORM for the deposit itself, and PASS ON for handover when personnel leave the project. Assign each function to a named person, and verify completion at each reporting milestone. When a team member departs, the handover task is what prevents the deposit from silently dying with their account.

A related fix comes from knowledge management practice in hospitals, which distinguishes between storing knowledge and validating that the stored knowledge remains correct and usable [6]. A deposited dataset nobody validated is storage without sharing. Before the final deposit, one person who did not create the dataset should confirm it opens, matches the described metadata, and can be understood by an outsider.

Mistake 9: Skipping the support that exists

The least excusable mistake is working alone when structured help is available. Only 29% of respondents in the survey had used DMPTool.org, a free tool that walks writers through DMSP elements with institutional templates and guidance built in [1]. Many universities embed data librarians in grant support, and professional societies increasingly run grant proposal planning workshops that include the DMSP as a module. If you learn better in a structured setting, a research grant writing course that covers the DMS Policy alongside aims and budgets will place the plan in its full context, which prevents the isolation error that causes most template mistakes in the first place.

For teams designing their own institutional support, the evidence on iterative co-design is relevant. In the eRIKA project, a living lab approach structured the development of a digital health workflow into thematic sprints with the actual end users, allowing the workflow to be tested and adapted before full rollout [7]. A research group can apply a miniature version. Draft the plan with the entire data-producing team in the room, walk through it against a real dataset from the pilot experiment, and revise before submission. One hour of that exercise routinely catches the repository, consent, and format errors that otherwise reach reviewers.

Common Mistakes and Limitations

Beyond the nine failure modes above, several recurring problems deserve their own short treatment.

Confusing scientific data with all project outputs. The policy targets scientific data, meaning the data needed to validate research findings, not every lab notebook, protocol file, and email. Writers who promise to share everything create plans nobody can execute. Writers who define scientific data so narrowly that the main findings are excluded create plans reviewers will challenge. Define the boundary honestly, data type by data type.

Overselling reuse value. Plans sometimes describe datasets as broadly reusable when the data are instrument-specific, single-center, or valid only under narrow conditions. Reviewers with domain expertise notice. Describe the actual reuse audience, such as other labs using the same pipeline or modelers needing the same parameter sets.

Ignoring institutional requirements. Your institution may have its own data policies, repository contracts, or export controls that constrain what the DMSP can promise. A plan that conflicts with institutional policy will fail after award even if it satisfied reviewers.

The limits of surveys about readiness. Much of what we know about researcher readiness comes from single-institution surveys, including the academic medical center study cited here, which gathered 55 responses from 155 invited researchers, a 35% response rate [1]. Response rates like that can overrepresent researchers who already care about data sharing, so the confidence percentages are directional, not exact. Individual situations vary, and for specific decisions about human data, consent, and export controls, consult your IRB, your institutional data office, or your grants office, because this article cannot substitute for those reviews.

Assuming the plan affects only compliance. A realistic DMSP is also a project management document. The exercise of writing one surfaces real costs, real personnel needs, and real consent gaps before they become crises. Teams that treat it as paperwork lose that value.

Prevention Practices That Keep Plans Out of Trouble

Prevention is cheaper than repair, and the practices below map directly onto the causes described earlier.

1. Start the DMSP during grant proposal planning, not after the budget is done. Write it alongside the data analysis plan, because both depend on the same decisions about data types, formats, and access. Plans drafted early inherit project facts instead of template language.
2. Use a structured tool with institutional templates. DMPTool.org and similar tools prompt for every element NIH expects and let your institution embed local guidance [1]. A prompted draft beats a blank page.
3. Build a discipline-specific prompt list. Adapt a generic template once, list the repositories and metadata standards your field actually uses, and reuse the list across proposals. Standardized templates measurably improve documentation consistency in clinical settings, and the same principle applies here [3].
4. Verify every repository at every submission. Repository policies change. A five-minute check of scope, status, and identifier issuance prevents the most embarrassing category of error.
5. Read consent before writing about human data. Make the consent review a required step in your proposal checklist, not an afterthought.
6. Itemize costs and justify each one. One sentence per budget line, tied to a named activity, protects you from both omission and padding.
7. Assign plan ownership by name and role. A plan with an owner gets executed. A plan owned by everyone is owned by nobody.
8. Do one full rehearsal against a real dataset. Walk the plan end to end using data from a pilot or a prior project, exactly as the living lab approach tests workflows with real users before full deployment [7]. Every mismatch you find is a reviewer comment you never receive.
9. Schedule plan reviews at reporting periods. Two calendar entries per award, mid-project and pre-final-report, keep the plan aligned with reality and satisfy the expectation of ongoing oversight.
10. Invest in your own skills once. A research grant writing course, a library workshop, or a society short course on the DMS Policy is a one-time cost that pays out across every future proposal. Evidence from methods guidance research indicates that guidance works best when users test it against real cases [4], so prefer courses with exercises over lecture-only formats.

Frequently Asked Questions

What is an NIH DMSP and when do I need one?

A Data Management and Sharing Plan is a document describing the scientific data your project will generate and how you will manage, preserve, and share it. Under the 2023 NIH Data Management and Sharing Policy, most NIH research applications that will generate scientific data require one, with limited exceptions, so check the funding announcement and your institution's guidance for your specific mechanism.

What is the most common NIH DMSP mistake?

The most common mistake is submitting a generic, template-derived plan that does not match the project's actual data types, repositories, and constraints. The fix is a specificity pass, replacing every sentence that could appear in any other grant with a sentence naming your data, formats, and population.

Can I just say data will be available upon request?

No. NIH expects plans to name repositories wherever feasible, and "available upon request" shifts the burden onto requesters, produces no persistent identifier, and provides no evidence that sharing occurred. If no repository is appropriate, say so explicitly and justify why.

How much should I budget for data management and sharing?

Budget enough to cover the named activities in your plan, typically personnel effort for curation and de-identification, secure storage, and repository deposit fees, and justify each cost in the budget justification. Only 38% of surveyed researchers felt confident budgeting for these activities, so use your grants office and institutional budget guidance early [1].

Where do I find an appropriate repository for my data?

Start with the community-recognized repository for your data type, such as the major sequence archives for nucleotide and protein data, then confirm the repository currently accepts submissions, covers your data type, and issues persistent identifiers. If no domain repository fits, use a generalist or institutional repository and state the reasoning in the plan.

Do I have to share human participant data?

Not necessarily. Sharing must respect informed consent, privacy, and confidentiality, and the plan should match what participants actually agreed to. Options in increasing order of openness include a justified decision not to share, aggregate results only, de-identified deposit in a controlled-access repository, and open deposit where consent permits.

What happens if I cannot follow my approved DMSP?

Circumstances change, and NIH provides mechanisms for submitting updated plans after award. The failure to avoid is silence. Compare the project to the approved plan at each reporting period, and if reality has diverged, submit an updated plan rather than letting the original promises lapse quietly.

Are there tools or courses that help me write a DMSP?

Yes. DMPTool.org is a free, widely used tool that walks you through each plan element with institutional templates [1]. Many university libraries offer consultations, and a research grant writing course or society workshop that covers the DMS Policy will place the plan in the full context of proposal preparation.

Sources

1. Supporting researcher compliance: assessing institutional readiness for the 2023 NIH Data Management and Sharing Policy.
2. Implementation Science for Effective Risk Management of Medicines: A Call for Global Action.
3. Standardised proformas for the management of hypodontia patients: A new standard for clinical documentation.
4. Developing methods guidance for health researchers: literature review of proposed and applied strategies.
5. Multidisciplinary perioperative management of robot-assisted renal surgery: practical considerations for partial nephrectomy and nephroureterectomy.
6. Linking Healthcare Quality and Knowledge Management in Traditional and Ethnomedicine-Oriented Hospitals: A Scoping Review and Implementation Framework.
7. Using a Living Lab to Refine an Electronic Prescribing Workflow: Insights From the eRIKA Project.