Skip to main content

IT Services

Managed Research Desktop Service


The Managed Service Rollout Project aims to roll out a centrally-managed service across the University. When preparing for the rollout of the project in the Faculty of Science and Engineering, end users highlighted that they frequently required use of non-QM provisioned software and applications to support their research work. 

It was identified that the current design of our Managed Service could negatively impact some end users within our research community whose research activities demand flexibility regarding the frequent use of non-QM provisioned software and applications mainly required for development/testing purposes. The pace at which researchers have demonstrated that these changes would be needed to take place couldn’t be achieved using the existing service. In order to successfully deliver the outputs of this project and gain business/end user buy-in it is vital to build and deploy a ‘Research Desktop Service’ aka Play Area/Dev Environment, which fulfils these research requirements, whilst not compromising the security of the wider QM network.

Therefore, we now plan to design, build and deploy a managed ‘Research Desktop Service’ that will fulfill these requirements without compromising the security of the wider QM network.      

To ensure IT Services can deliver the right, best fit solution(s), it is essential that we capture the requirements/user cases from Staff and Research Students from all Schools and Institutes across the three Faculties.

Goal & Actions

To design, build and implement a new managed service -  ‘Research Desktop Service’ (mRDS) with the aim to fulfill the research requirements whilst not compromising the security of the wider QM network.

In order to ensure that the proposed solution(s) fulfills our end user’s needs, it is essential to carry out a requirements gathering exercise to capture these. 

In late March 2021, colleagues across all three Faculties have been asked to submit their requirements/use cases.
Use cases should outline a specific situation in which the user would need ‘Administrative Privilege’ to perform their work and should provide context such as when, where and how often the activity would take place.  
You can submit your use cases via this online form.
The survey deadline was 14th April 2021, however the survey is still accessible so if you wish to submit your use case(s) please do so by using the original link above.

To Date

  1. Team who worked in collaboration to propose HL design of mRDS are ITS Tech leads, ITS Research, InfoSec Team and Head of Enterprise Architect
  2. A high level technical design has been agreed with the relevant ITS Tech leads (Network, Client Devices, Data Centre and IT Research)
  3. A risk workshop was held on the 26th April 2021 to identify risks 

Next Steps

  1. Follow-up risk workshop to agree mitigation plans and risk scores
  2. Approval of High Level Technical Design & Risk Document by service owner and submit to ITS Information Security Team
  3. ITS Information Security Team to perform Security Risk Assessment 
  4. Action feedback from Security Risk Assessment
  5. Design and agree detailed technical design - write Service Design Documentation (SDD)


It is proposed that the project will adapt Agile - an interative approach to delivering the mRDS and this will align with the Managed Service Rollout plan - SBBS, SPCS then EECS.

Seperate laptop devices with the new mRDS will be delivered to a pilot group of users in SBBS.

Example of an iterative process:

  1. ITS will plan, build, test, deploy and deliver the initial mRDS 'build' to pilot users to test
  2. Pilot users will have 2 weeks to test/review - identify issues/provide feedback
  3. ITS will have 2 weeks to review issues/feedback, plan, build, test and deliver a new 'build' to the pilot users to test
  4. Pilot users will have 2 weeks to test/review - identify issues/provide feedback
  5. ITS will have 2 weeks to review issues/feedback, plan, build, test and deliver a new 'build' to the pilot users to test
  6. Pilot users will have 2 weeks to test/review - identify issues/provide feedback

The process 'iteration' will repeat until no further issues are identified.

Adopting an agile iterative approach requires full commitment from our pilot users, but the benefits are that this will ensure that the mRDS meets user requirements. 

Return to top