Ways of approaching an RDM Service

A few weeks back an interesting discussion took place on the JISCMRD mailinglist, picked up on this blog under the main question of ‘ What are the requirements an RDMI has to cover?’.

One of the conclusions was that requirements gathering, scope and application obviously depend on a number of factors, one major one being the remit of the project: implementing a system for (pilot) audiences is different from getting an institution-wide service into place and running. The MaDAM project between 2009 and 2011 implemented a pilot RDMI for users from the biomedical domain – and was followed up by  MiSS (MaDAM into Sustainable Service) in autumn last year. Whilst having all the crucial experience, findings, contacts and committed stakeholders through MaDAM to build upon, it was clear that a set of new challenges would arise in implementing a RDMI as a service for the whole (and benefit) of the University.

1) Especially having the main stakeholders on board for such an endeavour is of utmost importance – but soon we realised that this process basically never stops: aims, benefits and plans have to be mulled over, renegotiated and agreed upon. There is always one office and internal project more to be included.

2) The University of Manchester also released their RDM Policy in May this year – and also other internal endeavours change structures (research offices), infrastructure (storage, eDMP) and processes. As a research project implementing a service we have to closely liaise with all those stakeholders to be on the same page and coordinate our efforts (and integrate with existing systems and the IT landscape) – despite a small core project team.

3) Outreach, awareness raising and training become more and more important. To this end (also including the points made before) we had to draw up a communication plan, collaborate and plan for an interim service and training for staff. We always strived to hold as many presentations as possible for various audiences at the University about our projects – now we have to start organising dedicated events e.g. at the moment on DMPs. Also: tangible benefits have to be communicated to all audiences!

4) One major challenge for the devleopment of the service and how it will look like lies in balancing the generic with the specific needs. Trying to gather and negotiate as many views, feedback and concerns is a huge task and some evolvement over time is needed – especially as only a system (service!) in use shows all the specifics required for every user, group and discipline. The service coming into life in about a year’s time will be a ‘thin layer’ across the whole RDM lifecycle, but the development is a continuous one and the RDM Service will get more tailored, sophisticated and mature while running.

Meik Poschen  <meik.poschen@manchester.ac.uk>
Twitter:  @MeikPoschen