Resource Allocation

Contents

Introduction

ICCS offers individual researchers and research teams the opportunity to collaborate with our research software engineers (RSEs) on climate related projects to advance groundbreaking climate research, through our resource allocation process.

All project requests submitted via the resource allocation are reviewed and selected by the ICCS Resource Allocation Board (comprised of ICCS Directors, Principal RSEs and external members of the community). 

Projects that are selected will benefit from:

  1. Collaboration with RSEs to support your research project and improve how models are developed, maintained and shared
  2. Operational support and assistance to help improve software engineering capabilities
  3. Assurance that codebases and software are trustworthy, and are produced and maintained to a quality standard using robust working practices.

The Resource Allocation Board will be looking to support projects that will achieve excellent scientific outcomes, whilst seeking to provide a balance between project needs and availability of RSE skills. The assessment criteria have been designed to reflect this and outcomes will be monitored using a process of impact assessment.

Projects are expected to have a defined duration and output(s). If you are not part of a VESRI team, the cost of any RSE time allocated to your project will be charged to your grant. If you would like to find out more about costs please get in touch with the operations team at iccs@maths.cam.ac.uk. 

RSEs are usually assigned for 3–12 months at 0.5–1.5 FTE, depending on the needs of the project. Requests to extend collaborations will also be considered. 

Project duration and commitment options 

Project duration options

  • 1-2 weeks (high priority track only)
  • 3 months
  • 6 months
  • 12 months

RSE commitment options

  • 1/2 RSE = 1 person 2 days a week

  • 1 RSE = 2 people at 2 days per week each

  • 1.5 RSE = 3 people at 2 days per week each

Application process overview

  1. Scope your project and discuss with one of our RSEs or directors prior to submitting a request, ensuring that your project meets the assessment criteria
  2. Submit a resource allocation request form by the quarterly deadline
  3. Resource allocation request reviewed internally and by the Resource Allocation Board within 2 weeks of submission.

The outcome of your request will be one of the following:

  • Accepted for immediate support – RSE staff have been allocated to your project
  • Accepted for deferred support – The project can be supported but is unable to have resources allocated immediately. This may be due to availability of RSEs (or a requirement for a specific set of RSE skills) or a result of resources being allocated to higher ranking proposals (see Assessment Criteria and Assessment). Resource allocation will be considered at the next panel.
  • Deferred (with option for resubmission) – The project cannot be supported in its current form and will need to be resubmitted to the next call with additional information following feedback from the review
  • Rejected (without option for resubmission) – The project cannot be supported or resubmitted
  • Feedback will be sent to the researcher who submitted the grant.

High-priority track applications

In addition to the 'regular call' for collaboration requests there is an alternative 'high-priority' track in which urgent requests can be considered at any time. This route for submission will require explanation as to why it is high-priority and unsuitable for regular submission. 

High-priority track applications will be assessed by the same review criteria and will have the same potential set of outcomes, but will only be accepted for immediate support in exceptional circumstances and where staff resources are available. Within the high-priority track, a shorter, minimum one week, project request can be made.

Flowchart of the Resource Allocation Process

Assessment criteria

The purpose of the assessment process is first to determine if a project collaboration request should be supported. Furthermore, the assessment will be used in prioritisation of projects between teams where there are competing requests for resources or a limited specific technical skill. In assessing a request for collaboration, the following items are used as assessment criteria:

  • Scientific and Technical quality – This criteria considers the quality and excellence of the project and specifically how the technical value of the RSE collaboration will have an impact on the scientific or technical goal. The focus of this assessment criteria is on the specific scientific or technical question being investigated. Projects which clearly define a technical challenge which will be transformative on a scientific outcome will score highly. Projects will be ranked in terms of their potential for impact on the scientific field, with broader impact given more weight in the ranking. The project proposal should clearly indicate the novelty of any technical or scientific approach highlighting the ambition and/or timeliness.
     

  • Outcomes Including Software Quality – This criteria will focus on the outcomes of the project. This may consider a mixture of traditional research outputs (i.e. papers) and alternative outputs, as defined by the San Francisco DORA initiative, such as software and datasets. Where publications are planned as outputs of the project, emphasis will be given to reproducibility of the research. The proposal should describe how effort will be made to ensure that software and data attributed to papers is FAIR. An excellent mechanism to understand software sustainability is a code review which will consider software quality and sustainability. For existing software, the ICCS team can provide software sustainability and reproducibility reviews prior to your application so that specific plans can be proposed.
     

  • Urgency – We will consider the resource request and any flexibility indicated regarding the potential start date. 
     

  • Work Plan and Scope – The work plan and scope should define any final or interim deliverables or milestones that will be used to assess progress. An assessment will be made on the technical feasibility given the scale of resources requested. This will consider the broader team in which the RSE will collaborate. Details of the scale of the collaboration should be provided including names of key collaborators and the time commitments of anyone who will contribute to the project. The RSE component of the project should not be seen as simply a coding exercise but as a collaboration where team members are guided and mentored by the embedded RSE to improve their own research software practice. As part of the project proposal any additional request for resources such as code review, training, delivery or workshops, or mentoring of staff related to the project should be included with justification provided.

Each application must meet a minimum threshold for each of these criteria. Eg. If a scientifically-excellent proposal is received, it will not be supported if the work plan for the RSE collaboration is not feasible.

Over the course of the project each collaboration will be monitored by the Executive Programme Director and relevant Co-Directors via monthly meetings to identify areas to improve and areas where further training, or even research, is required. These reports will also feed into the meetings of the Resource Allocation Board.

After staff have been assigned to your project there is a small possibility that staff may need to be recalled. This would be in exceptional circumstances to meet short-term, high-priority needs or where there has been a determination from the ICCS executive team that either a project should be ended early. 

There are also a number of specific compulsory events which ICCS staff are expected to engage with, such as the ICCS summer school, which may result in time being diverted from a particular project. If RSEs become unavailable to the project due illness or resignation from the team the project will re-enter the resource allocation process as an 'urgent track' application.

Project end and renewal

As the majority of development is expected to take place on GitHub (or another version control system) the final project handover is expected to be lightweight. The RSE team strives to reduce the 'bus factor' of software development expertise and therefore it is anticipated that at any stage of the project it should be clear what development progress has been made and the progress of any particular task or deliverable should be clear. 

Although a project has a defined end, it is expected that the RSE involvement will have embedded changes to software development practice of science teams which will benefit further development activities and we expect to report on this.

The ICCS RSE team utilises an agile development process in which prioritisation of work will have been communicated throughout the lifecycle of the project. It is the responsibility of the PI to work with the development team to set and review regular priorities to ensure that deliverables can be met within the time frame that resources have been allocated. Support can be provided from the RSE Principles in using Agile processes for software project management. 

If there is scope for further work this can be submitted at any stage as a new request for collaboration. It is possible for work on a particular technical or scientific problem to receive long term support but this must always be delivered via the assessment and resource allocation process.

As part of the assessment of the impact of the ICCS, the Resource Allocation Board will request information from project PIs. This will include:

  1. Qualitative feedback from the science teams collected at delivery milestones
  2. Measures of uptake or interest in software beyond the originating science team
  3. Publication records and citation counts
  4. Team sizes, development, and career tracking of those engaged by our activities.

Upcoming deadlines

  • 18 August 2026: Deadline for submission of Q4 support requests
  • 8 September 2026: Resource Allocation Board meets
  • 1 October 2026: Q4 projects start
  • 17 November 2026: Deadline for submission of Q1 support requests
  • 8 December 2026: Resource Allocation Board meets
  • 4 January 2027: Q1 projects start

Submit a Resource Allocation Request Form