Procuring a research management system

Understanding your research management needs

Identifying the underlying problem

At the heart of any procurement decision is an underlying problem that needs to be solved. Different people and parts of the institution may have different interpretations of it. You need a clear understanding of the problem before making any decisions about what kind of system is required. If everyone agrees about the problem the system is meant to address, satisfaction and buy-in are more likely.

These key questions can help you to identify the underlying problem:

• What is going wrong at the moment?
• Why can’t things carry on as they are?
• Why is this problem a priority for the institution?
• How might needs change in the future?
• What does success look like?

Considering brand new or replacement systems

The process of understanding the problem will differ, depending on whether you're looking to procure an entirely new system or replace an existing one.

New system

The challenge of an entirely new system is that some stakeholders may not know what might be possible or available. While it is a good idea to establish your needs first, it could be helpful to provide an overview of the systems available and the functionality they provide for people who aren’t familiar with them.

Think also about the time and cost of implementing a new system from scratch. If you're considering modular systems it's useful to get a realistic sense from suppliers and other users about the pros and cons of acquiring individual modules in stages, rather than buying multiple modules at the same time.

Replacement system

As well as identifying the pain points, you should note what you value about your existing system set-up. Which elements of the functionality would you like to continue?

Replacing an existing system will mean migrating data from the old to the new system. You'll need to consider how this can be done effectively, whether the migration will require data cleaning, and the cost implications of these factors.

Also think about how you're going to communicate the change to the existing users, particularly if the existing system is popular and widely used, and about the costs of migrating existing data.

Working with an existing system

Once you've understood the needs of the system users and stakeholders you might decide that these needs can be met by optimising your existing system set-up. You can then think through what changes will be necessary to make your existing systems work better.

Understanding your stakeholders

Once you fully understand the problem you can determine who is affected by it, and who will be impacted by the eventual solution.

The first step is to identify who these people are (there are always more than you think). Spend some time identifying all the stakeholders, so you're able to assess all their needs and understand which of them take priority.

The exact list of stakeholders will vary according to what kind of system is being considered and the structure of the organisation, but the ideas below will help you think it through.

Direct users

Wider stakeholders

Institutional support

It can be useful to map your stakeholders according to interest and influence to determine whose needs must be prioritised.

To fully understand the needs of users and stakeholders, put yourself in their shoes. The best way to do this is to speak to a range of different users directly. If this isn't possible, it's still beneficial to gather everything you know about each type of user, to articulate and record their needs. You could use personas (characters created to represent different user types) or user stories (simple descriptions of a feature or functionality from the perspective of the end user) to create some structure.

Determining your research management system requirements

When you have a full understanding of system users’ and stakeholders’ needs you can use the information to build a set of requirements. Think about what the system must be able to do to meet the needs you identified.

Below are some broad themes and questions to consider that might help you formulate these requirements.

Don’t forget about the level of service you require from the supplier. Support with managing problems and responding to requests for changes is likely to have a big impact on the success of the system.

It's particularly important to think about the service provided by the supplier in relation to implementing the system. Make sure you know what support each potential supplier will provide, what they require from you and how this will be managed on top of business-as-usual activities.

Procurement requirements can easily become extremely detailed and long. Having to score tenders on a very long list of criteria is time-consuming for everyone involved, and there is the risk that no supplier will be able to meet overly specific specifications. It's useful to prioritise your requirements and decide what is an absolute must. You should use a technique such MoSCoW prioritisation (deciding the requirements the system must have, should have, could have and won’t have) to provide a framework for your decision making.

To help you decide the most important requirements you can return to your core problem and focus on the requirements that really help you solve it.

Understanding the market

Knowing what's available

Although you want your needs to drive the procurement process you do need to understand what systems are on the market and what requirements are realistic. Online searches are a good place to start to get an overview of the systems available and the high-level functionality they offer, but it can be difficult to determine exactly what each system covers and how they differ from each other.

Purchasing frameworks and dynamic purchasing systems can give you an indication of the suppliers to look at. It helps to gather intelligence from other institutions about the system they use, and to speak directly to suppliers. One factor to take into account is how established the supplier and system are within the sector.

"New suppliers will often offer a better price, but you will need to commit a lot of time towards developing the system and reporting bugs etc. The advantage is that you could influence the development and have features you wish to have. The question is, are you able to commit the time and effort, or would you rather go with a system that is used by multiple universities?" Anish Kurien, head of research and knowledge exchange, University of Cumbria

Consider also whether your needs can be met by a single system, or whether you will want specialised systems to solve different parts of the problem. There are additional cost and logistical challenges to implementing multiple systems, so factor these into your decision making.

Engaging with suppliers

It's important that all suppliers are treated fairly, so make sure you engage with each one in the same way and provide them all with the same information.

Go into any meetings with suppliers with a clear idea of what you want them to show and explain to you. They'll want to focus on their system and service strengths, but you want to try and find out the weaknesses, too. Make sure you book a long-enough meeting for the demo so you have time to ask all your questions.

Meeting your obligations

Since 24 February 2025 universities in England, Wales and Northern Ireland have had to comply with the Procurement Act 2023. The rules are slightly different in Scotland; contact your procurement team if you need further advice.

Your institution will also have procurement rules and policies to follow. Make sure you engage with your procurement team as early as possible so you know what you need to do.

Managing expectations

Existing ideas about solutions

Sometimes stakeholders will come into the procurement process with pre-existing assumptions about which system would be best. This might come from comparisons with similar institutions, but every institution has a unique set of motivations and priorities so having a fixed idea of the solution before you start risks not finding the system that will best meet your needs.

It's important for all stakeholders to understand that a new or changed system is unlikely to solve all the problems that have been identified. Changes in processes, policies and culture may also be necessary to achieve the desired outcomes.

Timescales

The procurement process can be quite slow, so make sure all the key stakeholders have a realistic idea of the timescales involved. You don’t want to rush decisions at the end because of an external deadline (such as money having to be spent in a particular financial year), so start the process with enough time to complete all the steps.

Timings for the different stages will vary across institutions, but here's a rough idea of the timescales you can expect for the different stages:

• Project scoping and requirement gathering (one to two months)
• Market research and supplier engagement (two to three months)
• Tender preparation and publication (one to two months)
• Tender evaluation and supplier selection (two to three months)
• Contract negotiation and award (one to two months)
• System implementation and testing (three to six months)
• Training and go live (one to two months)

Time and skills commitment

Preparation for the procurement involves an assessment of the skills and time you have available for the different parts of the process. If there are gaps in either you may need more input from the supplier, which will need to be factored into your requirements evaluation and your budget.

Balancing functionality and complexity

It may be that only a small number of systems will meet all your requirements, so you might have to consider purchasing two (or more) systems. Make sure to balance the extra challenges and costs of procuring and implementing multiple systems against the need to get the exact functionality you require, and decide which is most important.