Writing a software management plan for a grant
A software management plan says what code a project will produce, how it will be built and shared, and what happens to it when the money ends. It can be a page long and still be useful, to reviewers and to you.
- A software management plan covers purpose, development practice, licensing, sharing, archiving and sustainability of the code a project produces.
- Some funders and institutions ask for one, often alongside or inside a data management plan. Check each call.
- Keep it short and concrete, scale it to the software, and treat it as a living document you revisit during the project.
Most grant proposals now include a data management plan. Fewer include a plan for software, even when the project will spend years writing code. That gap shows up later: analysis scripts nobody can run, a tool that disappears when a postdoc leaves, a licence chosen in a hurry the week a paper is submitted.
A software management plan, or SMP, is a short document that answers these questions at the start. It is not a technical specification. It is closer to a promise about how the code will be handled. This post covers what an SMP contains, who asks for one and how to write a lightweight version that reviewers will read.
What is a software management plan?
It is a description of the software a project will create or significantly change, and how that software will be developed, shared, preserved and maintained. The idea grew out of data management planning and borrows its structure. Groups such as the Software Sustainability Institute and the Netherlands eScience Center have published guidance and checklists that many templates build on.
An SMP is different from a data management plan in a few ways. Software changes constantly, so versioning matters more. Licensing is about reuse and modification, not only access. And software needs ongoing maintenance to stay usable, which raises questions about sustainability that data plans rarely ask.
Who asks for one?
Requirements vary by country, funder and call, so treat this as a general picture rather than a rule. In general:
- Some research funders ask for a software plan in calls where software is a major output, either as a separate section or as part of the data management plan.
- Data management plan templates increasingly include questions about code, scripts and software, even when they do not use the term SMP.
- Institutions sometimes ask for one as part of internal research data or open science policies.
- Infrastructure and software-focused calls are the most likely to expect a detailed plan, since the software is the deliverable.
Even when no one asks, writing one is worth an hour. Reviewers notice proposals that have thought about software, and the plan becomes a checklist for the project team.
What should a software management plan cover?
Six areas cover most cases. Answer each briefly and concretely.
Purpose and scope
What software will the project produce or extend? Who is it for: the project team only, a research community, or the public? A set of analysis scripts for one paper needs a very different plan from a library meant for wide use.
Development practice
Where will the code live, and how will it be developed? Name the version control system and hosting platform. Say whether you will use code review, automated tests and continuous integration. If the team is new to this, plan a short training session early in the project.
Licensing and ownership
Which licence will the software use, and who owns the copyright? Institutions often have policies on this, so check with your technology transfer or research office early. Our post on choosing a licence for research code explains the main options.
Sharing and documentation
When will the code be public, and what documentation will come with it? A README, installation instructions and examples are the minimum for anything others will use.
Archiving and citation
How will specific versions be preserved and cited? A typical answer is: tagged releases archived in Zenodo with a DOI, plus a CITATION.cff in the repository. See archiving code with a DOI.
Sustainability
What happens when the grant ends? Be honest. "The software will be archived and no longer maintained" is a legitimate answer for project-specific code. For tools with users, say who will handle issues, whether there is a community to hand over to and whether follow-on funding is planned.
What does a lightweight template look like?
A table is often enough. It keeps answers short and makes gaps obvious. Adapt the rows to the call and delete what does not apply.
| Topic | Question | Example answer |
|---|---|---|
| Software outputs | What will be produced or changed? | A Python package for processing sensor data, plus analysis scripts for each paper. |
| Audience | Who will use it? | Package: researchers in the field. Scripts: reviewers and readers of our papers. |
| Repository | Where will code live? | Public Git repository on the institutional GitLab from month one. |
| Practice | How will quality be maintained? | Code review on all merges, automated tests, continuous integration. |
| Licence | Which licence and who owns it? | MIT licence, copyright held by the university, agreed with the research office. |
| Documentation | What will users get? | README, install guide, tutorial notebook, API reference. |
| Archiving | How are versions preserved? | Each release archived in Zenodo with a DOI, also captured by Software Heritage. |
| Citation | How should it be cited? | CITATION.cff in the repository, version DOIs in all papers. |
| Roles | Who is responsible? | Research software engineer leads development, PI approves releases. |
| Resources | What is budgeted? | Part of an RSE's time, CI minutes, no paid services. |
| After the grant | What happens at the end? | Package maintained by the lab for two years on a best-effort basis, scripts archived. |
For a small project, this table plus a sentence or two of context is a complete SMP. For a large software project, each row may become a paragraph.
How much detail is enough?
Enough that a reviewer believes the plan and a new team member could follow it. Scale the plan to the software:
- Analysis code for a single study needs version control, an archived release and a code availability statement. Half a page is fine.
- A tool for a research community needs the full table, with real answers on documentation, testing and support.
- Infrastructure software needs a governance model, a release policy and a credible sustainability plan.
Avoid promises you cannot keep. "Maintained indefinitely" is not a plan. A clear, modest commitment is more convincing than an ambitious one with no resources behind it.
Who should write it, and when?
The people who will build the software, with the principal investigator signing off. A plan written by someone who will never touch the code tends to promise practices nobody follows. If the project will hire a research software engineer, involve an RSE from your institution or a partner group in drafting it, even if the post is not yet filled.
Write the first version while the proposal is being drafted, because the plan affects the budget and the work plan. Then revisit it at fixed points:
- at the start of the project, once the team is in place;
- at each major release or milestone;
- before the final report, when sustainability decisions become real.
Keep the plan in the project repository as a Markdown file. That way it is versioned alongside the code, visible to new team members and easy to update when something changes.
How does an SMP relate to FAIR and other frameworks?
It is a practical way to make software FAIR: findable, accessible, interoperable and reusable. The FAIR principles for research software, developed with input from the Research Data Alliance and others, describe goals. An SMP turns those goals into concrete steps for one project: a DOI makes code findable, a public repository and licence make it accessible and reusable. Our post on FAIR principles for research software goes further.
If the call also requires a data management plan, cross-reference the two rather than repeating yourself. Data and code that produced a result should point to each other.
How do you budget for it?
Put the work of the plan into the budget. Documentation, testing, review and release management take time, and they rarely happen if no one is paid to do them. Common lines are a share of a research software engineer's time, computing costs for testing and, for larger projects, time for community support. Our post on funding research software covers where that money can come from.
What can you do this week?
Copy the template table into a document and fill it in for your current project, even if no proposal is due. It should take under an hour. Any row you cannot answer is a decision the team has not made yet. Make it now, write the answer down and keep the file in the repository, so you can update it as the project changes.
Questions
Is a software management plan the same as a data management plan?
No, but they overlap. A software plan focuses on versioning, licensing, development practice and maintenance, which data plans often cover only briefly. Many projects reference one from the other.
Do I need an SMP if my funder does not require one?
It is not mandatory, but a short plan helps reviewers see that software has been thought through and gives the team a shared checklist.
How long should a software management plan be?
As long as the software needs. For analysis scripts, half a page or a short table. For community tools or infrastructure, a few pages with clear roles and a sustainability plan.
Keep reading. More from the desk.
Why journals should require code
Journals already require data, methods and conflict of interest statements. Code that produces the results is part of the evidence too. Here is the case for asking for it, and how to do it without wrecking anyone's week.
Archive your code with a DOI
A GitHub link in a paper is a bet that the repository will still exist, unchanged, years from now. Archiving a release with a DOI removes the bet. It takes about fifteen minutes the first time.
How to organise a research project folder so others can follow it
A research project that only its author can navigate is hard to review, hard to hand over and hard to reproduce. A simple, consistent folder layout fixes most of that, and it takes an afternoon to set up.