Close
What to expect when working with ARC’s research collaborations team
Collaborating research groups need to understand and agree our ways of working as set out below. These supplement UCL’s general commitments on staff interactions for maintaining a healthy working environment, as set out in the Dignity at Work Statement. Project leads will be asked to confirm their agreement in writing before we commit to a collaboration.
Overview
Our approach is based on ARC's nature as a hybrid research institute, combining the norms associated with research cultures with professional practice in scientific computing and digital scholarship. Our aim is to help to deliver collaborative team-based digital research to projects across the university.
As research projects, objectives may be vague or open-ended, and solutions will be co-designed across the project team. Our staff scientists will co-author papers with you and your team, and will from time-to-time lead authorship of computational and data focused papers. New ideas for spin-off work will arise, and staff will follow curiosity, discussing ideas with you, perhaps leading to new funding opportunities. Their time on collaborative grants will include activities such as publication work, research group meetings, staff personal career development and training, and new grant development contributions. Work may well continue beyond the funded end date of the grant to complete publications or work on follow-up grants, and in turn, work on your project may well be combined with such leftover work from other previous research collaborations, and on grant authorship for new opportunities. Where funders expect detailed timesheets they will be generated by us on the above basis.
It is important that the expertise of our staff scientists meets both your needs and UCL’s standards of academic excellence. We will be looking to PIs to help us with interview panels, for feedback on performance management, and to help us with allocating staff scientists to projects to achieve the optimal solution for their projects and UCL overall. If you have any concerns about the development needs of ARC staff within your research team, please let us know.
Consultancy
From time to time, we may enter into projects following a more service-oriented consultancy delivery model. Research collaborations are our default, so if you would prefer your project with us to fall into this alternative model, please let us know. We would expect projects with uncertain or curiosity driven outcomes to not be treated as consultancy. We may not be able to work on a consultancy beyond the allocated research funding, and a commercial consultancy provider may be more suitable for some projects.
Project leadership and management
All projects should have a named ARC lead – a senior research specialist with relevant expertise, tasked to ensure success of our contribution to the work. This should be as a part of their core contribution to the research – we do not want to add additional co-I costs where this does not help research outcomes. Where we contribute to writing grants, this person should normally be named formally as a co-I; for existing funding it is up to you whether we do this formally with the research council, or just agree internally.
Part of ARC’s mission is to propagate best practices for software development and data science within research. We therefore aim to model these in our interactions with researchers and mentor teams in their application. What this means in practice is set out in the sections below. The primary starting point is that we use “agile methods” for project management – while these originated within industry in essence they involve applying a research mindset to the technology aspects of projects, recognising that the end point is not fully known when a project commences, that cycles of experimentation and refinement of ideas are typical, and that through reflection we regularly refine how we work. Effective management is essential to delivering on the goals and deadlines of the project.
There will therefore be regular (e.g. fortnightly) meetings organised between ARC staff and the project leads, for the purpose of demonstrating the work done during the preceding period and agreeing priorities until the next meeting. These will be arranged at times mutually convenient for all involved.
This is however the minimum required level of interaction! We favour rich collaborations, and so in-depth discussion meetings and other means of communication (e.g. project Slack channel, GitHub issues) are encouraged for efficient exchange of information.
Personnel
The staff working on the project will be chosen by ARC, based on skillset and time availability. Our preference is for at least two research technology professionals (RTPs) per collaboration, for the benefit of robustness in the event of staff leaving UCL, and to facilitate sharing of knowledge. We also reserve the right to change staff throughout the project (although will endeavour to do so in a way which is mutually beneficial, recognising the potential cost of bringing a new person up to speed). Note that staff remain managed within ARC and are not seconded to your group, unlike postdocs.
Work locations
We recognise the value of in-person interaction for building strong working relationships, and so encourage our staff to spend some time based at the premises of the research groups we support. If possible, please arrange with your building administrator to provide card access (and a building induction) to all ARC staff working on the project, suitable hot-desking space or similar, and access to room bookings in the building for the ARC project lead, so we don't need to hassle your staff when we need to arrange a project meeting.
Scheduling work
ARC supports many research projects across UCL and beyond simultaneously, and needs to manage the time commitments individual RTPs give to each project in order to ensure each one is successful, as far as it is within our power to do so. We are often under very high demand and hence need to schedule work several months in advance. While we strive to adapt to changes in research priorities and unexpected deadlines, we cannot guarantee being able to do so. In particular, if there is a lack of responsiveness from research groups during the scheduled work period, the project may need to be rescheduled resulting in significant delays. Similarly, if extra funding is found near the end of a project, we may not be able to extend it straight away and instead need to pause activity or change staffing. The collaboration will be most effective if we are informed of known deadlines well in advance, and schedule tasks together with you in order to meet these. We will update you on the forecast schedule at the regular meetings as desired and will let you know of any material changes on our side as early as we can.
Time tracking
ARC costs for work on either a pay-scale or day-rate basis. Note that we do not commit to produce specific deliverables for a given price, in the way that industrial IT contractors typically work. Instead we commit to a given number of hours worked on the project. These costs assume 100% FTE includes appropriate allowances for dissemination, training, grant writing, meetings, holidays, and sick leave.
We use tools for tracking the time spent in projects and are willing to give updates on this at catch-up meetings and when requested.
Estimating the duration of tasks accurately on research projects is by nature difficult. Where tasks take longer than anticipated, we will notify researchers as early as possible and discuss how to prioritise the remaining work. If, on the other hand, work progresses unexpectedly quickly, we can work on additional tasks up to the time agreed.
Work may well continue beyond the funded end date of the grant to complete publications or work on follow-up grants, and in turn, work on your project may well be combined with such leftover work from other previous research collaborations, and on grant authorship for new opportunities.
Research
ARC staff will always endeavour to understand the context of the projects with which we work. We do not believe effective research software can be constructed without an understanding of the code’s purpose, for instance. Researchers will commit to giving the team time to read up on the field, and will supply appropriate literature to the team, when necessary. Similarly where new specialist technical skills are needed, training time will be included within the project.
GitHub
All projects must use version control and an issue tracker with good task management features. Researchers agree to learn and use GitHub where they’re not using something else already. Researchers agree to review issues on the issue tracker, which is where development tasks will be recorded and prioritised, and review code on pull requests or otherwise provide feedback, in a timely fashion.
Refactoring
Researchers are asked to understand that developing code which is sustainable is one of the main purposes of ARC. You might see several development cycles go by with no apparent feature work while we work on the software structure. This type of work is known as refactoring. It will lead to more robust, reliable code and faster progress later.
Testing
We will always work to a software quality assurance standard based on continuous automated testing, with tests for new features typically being written before the implementation (akin to forming a hypothesis then doing the experiment in the scientific method). Therefore, researchers may see time pass while we are working on establishing the test scaffold and framework for the code, again without apparent feature work. We also expect to be given realistic test data to design meaningful tests and take rare situations into consideration.
We will provide training and mentoring for the research team in using the test framework created and ensuring their code quality remains high after our engagement. Researchers will agree to engage with this process and try to keep up a testing approach, committing to fix broken tests in a reasonable time.
Contributing to the wider community
In our work, we often make use of open source scientific software libraries, and need to make changes and improvements to these to facilitate their use in your projects. From time to time, this will include work which benefits not just your project, but all users of the library. We assume that all project PIs are happy for project time to contribute in this way to the wider research software ecosystem. We will of course acknowledge funding and offer co-authorship in publications arising from such contributions to upstream libraries.
Dissemination
ARC is a strong proponent of UCL’s Open Science and Scholarship policy, and we make all our work as open as possible. We encourage co-authorship on research papers written during our collaboration. One of our aims is also to raise the profile of non-publication research outputs within the wider research community. We are thus keen to co-author software papers with you, publish releases of software and data which can be given a DOI and cited, promote the tools and methods created at relevant conferences, and generally disseminate the work we do as widely as possible. Such activities help to enhance both of our track records for subsequent grant proposals. We expect suitable time to be set aside on projects for them.