Requesting software in the shared teaching and learning spaces

Software requests

Towards the end of each year an email is sent to department representatives asking them to submit the bulk of the requests for the software required for teaching and learning in the following year. These representatives in turn contact the academics within their department to facilitate the negotiation of various versions of the software required. Each software request can be submitted by the academics or their department representatives by filling out the appropriate software request form:


Previously requested software

The software request is for previously requested software, for which proof of purchase has already been supplied and the licence is still valid.


New or upgraded software

The software request is for new software or upgraded versions of software, not previously requested.

Additional software requests are processed throughout the year, however there is usually an influx of software requests ahead of the start of each semester and ITS cannot always guarantee the software will be ready by the start of the semester, which is why users need to to submit the bulk of their requests well in advance.

Once the software and licence keys are received by the ITS Software Build Team, each software request typically takes up to three weeks to process and deploy. This includes testing to mitigate any potential issues associated with the rollout of the additional software i.e. software already deployed is not retrospectively tested (by the academics that made the original request) alongside the additional software being requested. This means there is always a chance that the additional software installed could break one of the original software packages already deployed. Asking all academics to re-test all the software each time additional software is deployed is very disruptive; instead the "Software image development process" outlined below is followed.


Software image development process

Want to know more about the software image development process? — take a look inside.

1. Requesting software

Academics, or their delegates, submit their software requirements using the software request system above.

Note: While requests for new or upgraded versions may be financially pre-approved by departments,  with the inclusion of a ledger code on the form, these still need to be assessed by ITS on financial and other grounds before the request is accepted.

2. Acceptance of the request

If new or updated versions of the software are being requested for purchase, the Service Desk will assess the requirements to ensure that the appropriate licencing model has been selected and that the department agrees to pay for it. The Service Desk may seek advice from the following sections if required:

  • Licencing advice from the ITS Licence Administrator
    • e.g to obtain the best funding option for the University as a whole; including options to split costs across departments if appropriate
  • Technical advice from the ITS Software Build Team

The ITS Service Desk will also ensure that all required information has been supplied in the software request, and will then ask the ITS Software Build Team to coordinate the acceptance of the request by: 

  • Ensuring development costs and delivery time-frames can be met
    • e.g. making sure the software can be remotely deployed and installed on the computers for all users, i.e. some software requires "per user" installation.
  • Checking the change is supported by the appropriate change authority including:
    • Change Approval Board (CAB) for staff computers
    • Change Approval Board for teaching and learning computers
    • Service Level Agreement (SLA) contacts for departmental spaces (e.g. specialist labs) 
    • compliance with regulatory and University policies

If the request is approved, the Service Desk will work with the ITS Licence Administrator to organise purchase of the licence (if required). This will then be supplied to the ITS Software Build Team.

3. Software Development cycle

The ITS Software Build Team will commence the work, building, peer reviewing and internally testing the changes:

  • A remotely deployable/silent installation package is built from the original media for each software being requested
  • The package is deployed to a test computer which is then peer reviewed and tested by at least one other member of the ITS Software Build Team to ensure that:
    • software can be opened and closed without errors 
    • required settings and customisations are included
    • first run dialogs are disabled (except for staff images)
    • auto updates are disabled (except for staff images), as these can be managed during the allocated maintenance slots for the shared teaching and learning spaces
    • software is properly licenced
    • software does not break any installed software 

4. User Acceptance Testing cycle

When the software development cycle is complete, a member of the ITS Software Build Team will contact the appropriate academic or their delegate to arrange User Acceptance Testing (UAT):

  • The package will be deployed to an agreed test computer for the  the appropriate expert user(s) to complete the testing of the application to ensure the software is configured and works correctly
  • It is recommended that a copy of the User acceptance test register template is downloaded, named and dated appropriately for the image being tested and then used to track all test feedback and progress during the UAT cycle of fixes, re-releases and re-testing of the image. Once completed it should be sent to the Service Desk.

5. Release into Production

  • The final version of the installation package is to be signed off by the appropriate change authority for release into production (if significantly different from the original request for change submitted during step 2.)
  • A Notification of Intent (NOI) is sent to ITS, campus support, the Lab and LT departmental representatives and other affected staff advising when the change will occur
  • In the case of remote deployment to computers in the shared teaching and learning spaces, deployment will occur at a time that will not interfere with teaching, learning or any other maintenance planned for the network infrastructure.

Additional Information

Requested software does not automatically roll over from one year to the next as:

  • Computer images can become bloated with software that was requested once upon a time and forgotten about.

  • Performance of the PCs and user experience suffers due to software conflicts and bloated images. Bloated images also take longer to deploy to computers and are harder to manage.

  • When software stops working, it is difficult to identify the academics that are using it, to give them prior warning to make alternate arrangements for their lectures (also, there may be other academics using the software apart from the original requestor).

  • When licences expire, ITS does not know who to go back to in order to check if the renewal is required. e.g. academics leave Massey and there is no replacement contact for the software previously requested. ITS manages approximately 2000 computers at Massey, with the software catalogue containing over 300 different software packages. Re-requesting the required software for teaching and learning each year is therefore the only way to maintain good computer performance and to ensure positive end user experience. It also ensures Massey is in compliance with licensing agreements.

Contact the Service Desk

Phone 06-356-9099 ext. 82111 (preferred method)

7:45am - 5pm, Monday to Friday
(excluding Public and University holidays)

Out-of-hours Support

AskUs Self-Service to log a request online (staff)

Full contact details

Other ITS Information

IT Services Dashboard (staff)




Contact us Mon - Fri 8:30am to 4:30pm 0800 MASSEY (+64 6 350 5701) TXT 5222 Web chat Staff Alumni News Māori @ Massey