CRIS Event Cafe Society Write Up - Group 1: Drivers

At the JISC/ARMA Repositories and CRIS event 'Learning How to Play Nicely' held at the Rose Bowl, Leeds Met University on Friday 7th May the afternoon was dedicated to a cafe society discussion session. Four topics were explored by delegates and over the course of four blog posts we are disseminating the facilitator reports from each session.

Please use the comment option below to contribute or comment on these discussion topics.

Group 1 - Drivers
Facilitator: Andy Mc Gregor, JISC

Aim
This session was designed to explore the issues that are driving the development of research management systems, processes and policies in universities.
This document reports on the issues raised during that session by the many people who joined in over the 2 hour course of the discussion.
During the session we looked at the drivers, then considered the ways that institutions were choosing to address those issues and finally used these approaches to develop a rough and ready action plan for institutions wishing to look at research management.

Drivers
REF – the Research Excellence Framework was a clear priority for many of those present.

Efficiencies – many people felt that a joined up and embedded research management system would stop effort being duplicated and make some tasks much easier than they are at present freeing staff time to be spent on other tasks.

Funding – a good research management system could help institutions understand, monitor and manage research funding more effectively and enable it to target bids for funding in a more managed way.

Funder mandates – many funders are mandating the storage of research outputs and research data, a research management system could help institutions comply with such mandates.

Legal compliance – a research management system could help institutions manage compliance with data protection and freedom of information requirements in a more efficient and joined up way, greatly reducing staff time that needs to be spent on these tasks.

Business information – the information held by a research management system could provide valuable information about the operation of the institution such as identifying successful research clusters, or areas for potential collaboration. This would enable the institution to provide more focused support to researchers.

Business processes – the research management system could help institutions refine some of the processes and workflows for research and administrative tasks. This would make it easier for researchers to manage the administrative part of their research. It could also make it easier for researchers to fulfil obligations to funders and could support a more effective link between institutional and funder information and systems.

Benefiting research – a research management system could use the information about the institutions research to provide useful services to researchers. This could be something like a directory of expertise or a service to explore research happening in other institutions.

Open access – open access to research outputs can provide greater access to the literature for a researcher as well as enabling a greater number of people to access their research outputs. While this is an important driver, to some extent it is a result of some of the other drivers.

Collaboration (communities of practice) – a well managed research management system could help support researchers in finding suitable people to collaborate with and support the identification of communities of practice. This is an area where research management systems could link effectively with virtual research environments.

Knowledge exchange – having details of an institutions research on an easy to use website could help with knowledge exchange with business and with other nations.

In thinking about ways to address these drivers it is important to focus on the key reasons that an institution needs to implement a research management system. There is a danger that focusing too closely on one specific driver could produce a system that is only good for that particular purpose and does not meet the wider needs of the institution. This is especially serious when thinking about the REF as specifying a solution too closely aligned to the ref may produce a system that is not suitable for future research assessment purposes.

While it was clear from the discussion that the impetus for the development or revamp of research management in institutions was coming from senior managers, it was also clear that it was members of the research office, library, and IT departments of institutions that were steering the specific nature of the implementation in each institution.

Responding to Drivers
Once the drivers were identified, the group moved on to discussing how the drivers could be addressed and what tasks were important in setting up a research management system. To help structure this session and to ensure that the tasks were grounded in the reality of the institutional setting we categorised each task into three cost categories: tasks that would not require extra funding and could be accomplished with existing resources, tasks that would cost a moderate amount of money (e.g. £10,000-£50,000) or tasks that would cost in excess of £100,000.

No cost tasks

Building relationships – it was clear from the whole day that building effective relationships was a key success criteria in developing a research management system in an institution. Effective relationships between senior managers, researchers, research managers, librarians, IT, and other relevant systems are an essential early task that can be achieved without any extra resources. However, maintaining those relationships may take a lot of time and effort and therefore may need some extra resources.

Embedding the system in the institutional processes – to ensure successful uptake of any system, a number of people suggested that the system needed to be embedded in the institutional processes that affect researchers such as assessment and promotion. The group disagreed on whether this was a no cost or moderate cost task with some people feeling that the relationship building and advocacy/training that would be required would push this into the moderate cost bracket. However it was also noted that once the initial hump of getting the system embedded into institutional practice was surmounted then it could make complying with institutional requirements easier and quicker for researchers and therefore lower institutional costs.

Moderate cost tasks

Planning – obviously there is a fairly large planning overhead for implementing a research management system in an institution. This often involves a range of staff and is quite time consuming and so comes at a cost to an institution.
Publicity and advocacy – it is highly likely that any new research management system would require researchers to change their working practices, therefore significant advocacy and publicity would be required to make sure researchers were aware of the system and how it would affect and help them. This is a resource intensive process in terms of staff effort and some materials costs therefore it would require a moderate amount of resources dedicated to it.

Training – a related task to publicity and advocacy is training of researchers and administrators in the use of the system.

Understanding institutional requirements and systems – before an effective research management system can be designed a good understanding of institutional requirements, systems, existing processes and people involved must be developed. This will involve a range of departments and roles and could be quite time consuming but it is an essential step in designing a system that will fulfil institutional requirements.

User consultation – just as it’s important to understand institutional requirements and systems it is also vital to understand the needs and current practices of the people who will end up using this system. This is important in making sure the system meets their needs but it is also important in getting early buy in from users and in managing their expectations. This is a very important part of the planning and implementation process and the group concurred that this was worth dedicating a decent amount of resources to.

Developer time – this is essential if institutions choose to build a home grown system However it is also important if institutions choose to buy a system in as developer time will be needed to ensure the system links well with other institutional systems. This doesn’t come cheap and can be a significant commitment. One group member reported that they had been told that their research management system would require 400 hours of developer time, which would probably push it into the high cost bracket.

Data entry and quality checking – It is important not to underestimate the cost of data entry into the new system, both in terms of set up and in terms of ongoing cost. Even if data is bought in or cheap data entry effort is procured then there will still be an associated cost in quality checking that needs to be supported.

High cost tasks

This category was slightly more speculative than the others as many people in the group did not expect to receive high levels of funding.

Build systems – A number of people believed that this amount of money would enable their institution to build a system that could give their institution competitive advantage over rival institutions. However a note of caution was sounded here in that there may not be a competitive advantage in building your own system and building your own system may unnecessarily duplicate effort occurring in other institutions and in fact there may be advantages to collaborating with other institutions to build an open source system. Competitive advantage is more likely to be realised through the effective embedding of the system and the way it is used rather than building a unique system.

Best of breed products – given this amount of money a number of people suggested the best way it could be used was to buy best of breed products.

Staff – getting the staffing resource correct for any research management system was identified as a key success criteria and a concern for many of the group members. They were concerned with ensuring that the right staff were employed to implement a system and that those staff were then sustained by the institution where required.

An institutional scale data review - this was a scaled up version of the institutional requirements task mentioned under the moderate costs heading. Many group members felt that a really thorough review of an institutional requirement, the data that would be managed by any system and the requirements for managing that data was a step they would ideally like to take before designing a system. Many felt that CERIF could help here.

Action plan
The final part of the session was spent discussing a possible action plan. The following headings were as far as we got. They are listed in chronological order:
1. Relationships – build relationships with all relevant stakeholders.

2. Feasibility – understand the system’s users, the high level requirements for the system and identify a rough cost. (

3. Define institutional need and sustainability and get buy in from senior managers.

4. Produce a plan

5. Consult with users to gather requirements (this would need to start with a stakeholder analysis)

6. Analyse requirements gathered and report back to users with outline specification (it is probably desirable to make this process iterative and to continue the iterations throughout the building process).

7. Produce specification

8. Decide how to proceed and then move to tender or building process

9. Build it

10. Embed it (this process really started with the user consultation and needs to continue throughout the project). This will include training where appropriate.
11. Communication - this is likely to run throughout the project and have two processes:
a. Communicating over the tasks in the project with the relevant stakeholders
b. Wider dissemination and communication related to embedding the system through advocacy, traning etc.

12. Sustainability handover – this needs to include:
a. Built in review process for the software (perhaps every 4 years)
b. Ongoing support including technical and managerial.