The Research Software Project Manager

research software project managerShoaib Sufi, Software Sustainability Institute, Robin Dasler, CERN, Chris Edsall, University of Bristol.

This post is part of the WSSSPE5.1 speed blogging series

The accidental research software project manager

For many, the role of research software project manager (RSPM) may be an accidental calling. The career path for this role isn’t well-established, and research software development in academia may itself be something of a haphazard, nigh-accidental byproduct of conducting domain research. Individuals approaching this role may have little to no wider industry experience, instead approaching the project manager role from research or research software engineering.

For those in a RSPM role who do not have prior industry experience, there is no solid basis for comparison between industry best practices for software development and the observed practices of the research environment, nor even any sense of whether or not best practices between industry and academia should be identical. How do those in this position gauge whether the practices in place in their particular work environment reflect how a project should be conducted versus how it has always been conducted? And to what extent could this lack of relevant industry examples be detrimental to the team and to the project? Should research software engineers even be following an industry example in the first place?

For the RSPM the objective is usually to enable research, whereas in industry it is somehow tied (even if obliquely) to making or saving money. Acknowledging this may help RSPMs to relax and realise that their situation is inherently different.

Challenges facing RSPMs

Costing dedicated project managers on research projects can seem a luxury, especially when costing dedicated software developers can still be a problem. The term ‘project manager’ is itself abused, with many who do this role on larger research projects focussing on box ticking and cost oversight rather than on the delivery of the work, removing roadblocks to progress and helping the team shape what is happening.

Research software projects are highly iterative. This is not for convenience or efficiency but because it matches the way that research works. We decide on a set of things to do, who is available and then work to deliver a viable product. This gives breathing space for change between iterations to help incorporate new ideas and new use cases that arise, as one thing about research software projects (or longer running programmes of activity in research) is that change is inevitable and happens often. This can sometimes lead to the perceived need for rapid change when the leader of a project or other stakeholder comes back from a conference full of new ideas about the direction, standard or technologies that should be taken or used.

This rapid change requirement needs to be tempered somewhat, for we cannot confuse agility for chaos - discipline is still needed. There are planning problems with changing things on the fly and pushing the deadlines, and it might be better practice to tidy up what one is doing and then replan in the next iteration with the new directions in mind.

Project leaders (senior academics in the context of research software) are often excellent at winning funds, writing papers, supervising PhD students, lecturing, doing the role as a professor but that does not mean they know how to manage the projects that they have won or recruit and coach the right staff for research projects. These latter two are best handled by dedicated management resource and could well be some of the foundational roles of a RSPM.

How is research software project management different from normal software project management?

Research projects tend to have fixed costs (unless new funding or bolt-ons come along), and they are also fixed in terms of the time duration of the project or set of projects. However they tend to have very variable scope. What people decided they will do at proposal time rarely remains the focus, even if the wording remains the same. For example, a deliverable may be described as ‘a catalogue’ but what this means can change as the project matures in time).

So change is constant, with new research priorities, new technology, new standards. Some of this is good and necessary and some can turn out to be a distraction but it is hard to argue against change as the business of research is new things.

The other problem is that project management is often given little time, and is normally done by someone who is also responsible for deliverables on the project. In the project management world they say ‘Don’t put your project manager on the critical path’ but in research, unless you have a particularly large team, this is inevitable as everyone has to deliver something. Sometimes the architect or senior developer/researcher really does not want to do the project management so focuses on the technical aspects, such as release management and quality but not the human side  involving clearing roadblocks, constantly assessing whether the project is on track, interacting with stakeholders and thinking about risks to the project. The available advice from the research community puts software engineering and project management together but as the lot of research software engineering improves we advocate for a dedicated RSPM function.

Where should RSPMs look for help and unanswered questions?

In the usual case you might turn to a project management podcast . Where’s the research software management podcast? Where can we find resources about project management particular to the research software context? Should there be a “carpentry” lesson for research software project management?

Who makes up the community of RSPMs and how can they be identified and share practices and experience?  Is it a large number of people? Do the funders have a role in developing a community and a body of knowledge?

There are many questions and we certainly don’t have all the answers just yet but we do have some  ideas on how to improve things.

A way forward

It is up to the RSPM to communicate the value of his or her role to the larger academic enterprise.

It is valuable to stress that not everyone needs to be expert at everything and that being an excellent researcher does not mean that one has the expertise (or desire) to be an excellent RSPM. It could be more productive for the entire research enterprise to delegate this task to someone else with the necessary expertise and desire to manage the project to efficient completion.

For researchers, funders, research software engineers (RSEs)and administration, it is appealing to point out that delegating research software project management to a qualified person frees up researchers for research and winning further funds, makes more efficient use of funds, makes best use of RSE effort and offers someone who can speak the same language as administration, making project reporting a much smoother process.

In order to advocate for RSPMs as a valuable piece of the overall research puzzle, the RSPM needs to exert influence from all sides. On the one hand, this could be easier for the RSPM than for others in similar positions in industry. Where industry PMs may struggle to advocate for change to their management staff, RSPMs often have a direct connection to this level. The lead researcher or academic attending conferences and winning funds may very well be their direct boss, so influence on requested funding could be a relatively simple hurdle to jump. On the other hand, other external forces such as the funders themselves or university-level hiring policies could have undue influence over the result of these funding and hiring requests, requiring further advocacy.

Resources and effort are needed to improve the profile of and credit for RSPMs in the minds of funders, human resource functions and senior research leaders.  A community needs to be formed around RSPMs to share best practice, case studies, templates and other related matters. RSPMs are naturally related to the RSE community but they are also a subset of traditional PM communities, but urrently have no fixed-abode. If you have any suggestions on how to take this important area forward please get in touch or leave your comments below.

Posted by s.aragon on 4 December 2017 - 10:09am