Research outputs management plans

During the talk about early career researchers’ view on modern and open scholarship I presented at the Research Data Management Forum 2017 in London, I described a short table comparing different aspects related to data and software management.

As mentioned during the presentation, I see many commonalities between data and software, and their management. In my grant applications, as a computational scientist, I use the data management plan to document the management of my software outputs (here’s an BBSRC DMP that I published recently). The table reads

As was clear from some discussions I had over coffee and lunch, most of these points could be further discussed on their own, but I would like to follow up on the bigger picture.

I stated that, for clarity, despite the many commonalities, it might be useful to have dedicated data and software management plans, and provide specific guidelines to reviewers and applicants. But, do we really want to have a data management plan, a software management plan, a material management plan, … Probably not, as these outputs are not independent anyway. Grant applicants would feel compelled to fill out as many plans as possible, thus reinforcing the box ticking feeling that is sometimes already associated with data management plans. In an ideal situation, as discussed with Kevin Ashley (thank you for bringing this up), we would rather be looking at a unique, unified and integrated output management plan, that documents all research outputs, their management, their preservation and their dissemination in a coordinated way.

Unfortunately, I feel that in the current climate, DMPs are not always taken seriously enough, or may be those that write them (senior researchers) do lack the skills and experience needed for effective data and software management. May be there is still a need to make it explicit that research has various different and valuable outputs, beyond the mere advertisement that is eventually published in a research journal, that these outputs are important, and that there is a need for explicit guidance as to how to document their management. I’m sure these alternatives must have been debated already (this was touched upon, albeit briefly, at a recent BBSRC/SSI software workshop I joined). I would be curious to hear what others think about this.