Disclaimer: This is an example of a student written assignment.
Click here for sample essays written by our professional writers.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UKEssays.com.

Proposed Service Management Solution

Info: 8000 words (32 pages) Assignment
Published: 21st Apr 2021 in Assignment

Reference this

Proposed Solution for The University of Bolton Creative Technologies IT Infrastructure


This report covers the proposed service management solution based on the specified requirements for the specialist creative technologies at the University of Bolton.  It recommends solutions based around the Information Technology Infrastructure Library (ITIL); this framework will allow the improvement of service levels within the University. It provides a clear breakdown of each level of ITIL management with proposed solutions.



1. Service Level Management

1.1 Service Level Manager

1.2 Service Level Agreement

2. Service Desk

2.1 What the Service Desk Will Be

2.2 Service Desk Functionality

3. Incident Management

3.1 Incident Manager

3.2 Incident Procedure

4. Problem Management

4.1 Problem Management Procedure

5. Change Management

5.1 Change Manager

5.2 Change Advisory Board (CAB)

5.3 Change Procedure

5.4 Change Priorities

5.5 Change Team

6. Configuration Management

6.1 Configuration Management Database(CMDB)

6.2 Configuration Lifecycles

6.2.1 Hardware Lifecycle

6.2.2 Software Lifecycle

7. Release Management

7.1 Release Schedule

7.2. Definitive Media Library

7.3 Virtual Definitive Media Library Classifications

7.3.1 Hardware

7.3.2 Software

7.3.3 Teaching Materials

7.4 Enforcement of the DML

8. Continuity and Capacity Management

8.1 Continuity and Capacity Management of Services

8.1.1 Private Study Facilities

8.1.2 Separate Networks

8.1.3 Safe Student Storage (Backups)

8.1.4 Dedicated Webservers

8.1.5 Remote Access

8.1.6 Lecture Facilities

8.1.7 Specialist Computer Labs

9. Conclusion

10. Bibliography

11. Appendix

11.1 Service Level Agreement

Agreement Overview

1. Goals & Objectives

2. Periodic Review

3. Service Agreement

3.1. Service Scope

3.2. Customer Requirements

3.3. Service Provider Requirements

3.4. Service Assumptions

4 Service Management

4.1 Service Availability

11.2 Change procedure

11.3 Problem Management

1. Service Level Management

This section within the document will cover service level management and its proposed implementation. The goal of service management is to: ensure that levels of agreed service are consistently provided and that any future services are operational within agreed deadlines.

Get Help With Your Assignment

If you need assistance with writing your assignment, our professional assignment writing service is here to help!

Find out more

1.1 Service Level Manager

Within the creative technologies provisions at the University, the Service Level Manager is proposed to be the most senior technician. This manager will need to be available throughout the day and is recommended due to the level of experience. Other candidates, such as course leaders or department heads, may lack the technical skill and availability for the requirements of the position.

The Service Level Manager will be responsible for ensuring that the Service Level Agreement(SLA) is adhered to, consequently resolving any issues and performing tasks outlined within this document as discussed within the next section.

1.2 Service Level Agreement

The Service Level Agreement Appendix 11.1 outlines the services that will be provided by the Technology Department to the University.  This ensures that a mutually agreeable definition of the service is met.

The following services are covered by the agreement:

  • Private study facilities – Private study services will be internal dedicated rooms with specialised hardware and software dependent on pathway. This will allow enclosed private environments for students to work outside the classroom.
  • Separate networks – The service of separate networks will facilitate an additional network that is separate to the University’s main network. This will allow students to practise skills without damaging main infrastructure.
  • Safe student storage (backups) – The Safe storage service will compromise of the facilitation of safe storage and backups of student files.
  • Dedicated webservers – The dedicated webservers service provides each student with a web server for testing and deployment of website onto a live environment.
  • Remote access –  The Remote access service allows students to access files stored within the University off campus to allow private study at home.
  • Lecture facilities – Lecture facilities enable staff to give lectures to students.
  • Specialist computer labs –  The Specialist Lab service provides computer rooms with specific operating systems or machines that can be adapted. This allows students to use computers specifically designated for testing and development and not affect main machines.

The SLA is to be reviewed at intervals specified within the document, thus ensuring that expectations are being met by both parties.

2. Service Desk

The role of the service desk will be discussed in this section, with the suggested implementation to how this service should operate within the University.  The service desk will act as a single point of contact between the Technology Department and the users daily.

2.1 What the Service Desk Will Be

Within the University, it is suggested that this desk will be physically located and centralised, therefore offering efficiency and being more cost effective. This is due to having one desk rather than several localised desks around the University. However, due to this, staff will be required to travel around the University when needed, but this will be controlled from the service desk when required. It is suggested that the hours of operation are consistent with the opening hours of the University.

2.2 Service Desk Functionality

The service desk will be responsible for performing initial diagnostics and documenting incidents. The desk will differentiate if a user has reported an incident or a service request. Service requests are when users require help or information also including pre-approved changes such as password resets.

It is advised that incidents are to be recorded upon a database. This database will contain information regarding the incident with a unique reference number. In addition, listing the date and time the issue was raised and resolved, with any workaround solution if available. These initial diagnostics are to include checking against any databases containing known issues to see if there are any solutions or workarounds available. Consequently, this will allow first fix solutions and the reduction of downtime, allowing incidents resolved as quickly as possible and increasing user satisfaction as well as improving efficiency.

After initial diagnostics, if no solution is found then the incident will be escalated to the Incident Management Team where required. The desk will monitor and communicate incidents, close incidents and progress follow up action to management if needed.

Users are to report incidents and raise service requests through the desk; interaction with the service desk is to be through the following methods:

  • Physically in person
  • Through designated telephone number
  • Through designated email
  • Through single web desk contact page

The service desk will require users to report issues effecting services as follows:

  • Computer failures
  • Network failures
  • Application failures
  • Server issues
  • Hardware failures

Users who report issues will updated by email regarding their issue or to request more information if needed.  Upon receipt of a request for more information from the user who reported the incident there is a suggested maximum response time of three hours.

To allow the management of common issues, it is advised that sessions are to be held every week to give advice and help on a drop-in basis for resolution. If there are multiple reports of the same incident, then the issue will be raised to the problem management team for investigation.

Further to user and incident management, the desk will provide an interface for other forms of management such as, incident, problem, change, configuration and release management as discussed further in the document.  This interaction will allow the IT department to coordinate and manage issues effecting service as efficiently as possible.

To ensure the successful operation of the service desk it is suggested that it is to be assessed on a three-monthly basis by the following constraints:

  • Incident resolution time
  • Average incident response rate
  • Number of incidents incorrectly allocated
  • Number of incidents handled per technician
  • Number of incidents resolved at first contact by the service desk

These constraints will allow identification of any issues within the service desk, allowing changes to be made if necessary to improve service desk efficiency.  The next section of the document will cover incident management, its purpose and proposed implementation.

3. Incident Management

Incident management will allow the categorisation of incidents to allow resolution as quickly as possible. Incident management will closely work with the service desk utilising the incident database. This will allow the gathering of information partaking to current incidents and enable a resolution in a timely manner. When an incident occurs that is affecting or has the possibility to affect the agreed level of service, incident management will allow resolution as quickly as possible.

Users may experience incidents relating to hardware or software. An example of this is an application not loading or a printer not printing. Although, some incidents may not be noticed by users, incidents such as full disk capacity or an intermittent fault on a network card. Resolution of these incidents before affecting users will offer greater service overall, also reducing the number of incidents reported.

3.1 Incident Manager

It is recommended that the incident manager is a technician within the department with high experience levels who has a history of handling issues in the past.

3.2 Incident Procedure

After identification of an incident, incidents will be categorised by priority relating to the severity of how services and users are effected, detailing the item causing the incident to occur.

Incidents will be categorised as follows:

  1. Low-priority –  Incidents that have minimal or no affect to service and users service still functions.
  1. Medium-priority – Incidents mildly affecting user’s ability to do work or use services causing inconvenience.
  1. High-priority-  Incidents that are affecting many users, disrupting service and causing inability to use services. Also, any incident that is directly affecting the agreed level of service.

Following this the incident will then by delegated to the most appropriate member of the IT team to resolve the issue. The incident team may need to liaise with change management as discussed within Section 5, if an identified incident requires new software a change request will need to be raised. Also, many incidents may be caused by recent changes that have been deployed so it is essential that these teams work together on a resolution.

The forthcoming section will discuss problem management whilst detailing how issues causing incidents are to be resolved.

4. Problem Management

Problem management will allow the IT department to identify issues that have caused incidents. To ensure problems are resolved as quickly as possible, the incident database used by the service desk and incident management will also be used for problem management giving a unified source of information.

4.1 Problem Management Procedure

Initial steps will be to identify the problem; this can be from incidents that have been reported by users or known problems. All major incidents are to be followed up with a problem management case.

After the identification of the issue a problem management case will be raised. This will include the following information:

  • Specifics regarding failing component such as applications, networks and servers
  • The number of users affected and the impact to business
  • User Contact Details
  • Description of the Incident with all details linked to all other known incident records.
  • Information of troubleshooting steps taken and any changes made for resolution.

When a problem management case has been raised, the problem needs to be categorised and prioritised. This will be achieved by determining the impact on business and the cost or value if resolved quickly, therefore determining the order the problems will be managed.

Following the determination of priority, the cause of the issue will then be identified, giving the foundation to establish the solution. If the solution devised involves new software, then liaising with the Change Manager will be needed for the implementation and agreement of new software. Final steps in the process are to verify problem resolution and then to close the case.

This process is outlined within Appendix 11.3

5. Change Management

Change management allows the management of any changes to infrastructure within the University, this will ensure that all changes are managed from start to finish and effectively assed on the viability of the change. Change management will liaise with configuration management discussed within section 6 to allow the successful delivery of new hardware and software within the University.

5.1 Change Manager

It is suggested that the Change Manager will be the Service Level Manager; this will ensure transparency across processes and ensure if needed the SLA is updated to reflect changes. The Change Manager will be responsible for leading the team to effectively deliver new changes using a methodical process.

5.2 Change Advisory Board (CAB)

Further to the Change Manager, to effectively facilitate change, it is proposed there is a Change Advisory Board. The CAB will need to meet on a regular basis, which is advised to be at least once a week to discuss any changes, comprising of the Change Manager, Head of School and IT staff. When a student request for change is on the agenda, it is advised that a student representative will need to be present at meetings.

The board will be responsible for the initial review of all changes and the subsequent approval or rejection. Further to the initial approval, the team in charge of implementing the change will submit a plan for the changes, requiring final approval.

Following the approval of the plan to implement changes, information on any configuration items affected will be requested, to ensure that the configuration database discussed within section 6 is updated.  It is suggested that changes are recorded within a change log spreadsheet that details requested and approved changes with their outcomes, this will allow the tracking of changes made and any issues. The change log will include the following information regarding every request for change received:

  • Details of change
  • Cost of change and possible associated cost with not performing the change
  • How long it will take to implement the change
  • Contingency plan
  • Rollback plan for failure
  • Clarify the risks associated with the change going wrong
  • Impact to the services and business if the change does go wrong
  • Alternative routes for resolution rather than making the change
  • Detailed description of how the change will be made
  • Any issues when change is made

The log is to be available to the service desk so if any reported incidents occur due to changes, this can then be notified for discussion by the CAB.  Within the weekly meetings reviews of changes from the previous week are to be discussed, highlighting any areas in which changes failed or issues reported by the desk. This will allow the identification of why the change failed and allow adaptation of deployment strategies.

Only the CAB will be able to authorise a change within the University; unless in the event of an emergency where the CAB cannot meet, it will be the responsibility of the Change Manager to make the decision. Normal technological staff will be able to make changes to resolve issues only when using already approved software and hardware. For example, reinstalling approved software that has failed due to an update or corrupt files.

5.3 Change Procedure

The process for requesting a change will be through webform or through the service desk, Appendix 11.2 shows the change request process. Requests for change can be made by staff and academics. However, if a student wishes to make a request then this must be requested through an appropriate member of staff ensuring that only needed requests are made.

The Request for change will cover –

  • Name of proposer
  • Student who requested change and what pathway they are on (If applicable)
  • Motivation behind the change request
  • Software/hardware effected
  • Urgency of the change with priority of low – high

Requests will be submitted with a priority of low to high attached from the perspective of whomever is submitting the request, when received the service desk will re-evaluate the request determining the priority. The service desk will also check to see If the change is associated with ongoing problems reported within the service desk.

5.4 Change Priorities

The priority assigned by the service desk is dependent on the severity of change; how many users are affected and how urgent the change is needed. Changes are to be allocated accordingly on need of priority detailed below:

  • priority 1 – immediate, emergency change that requires immediate attention
  • priority 2 – within a week, needs to be implemented as soon as possible
  • priority 3 – within a month, cannot wait until next upgrade or update
  • priority 4 –  a change that is needed but can wait until next upgrade or update

Once allocated priority it will then be submitted to the CAB for consideration. Following consideration and approval it will then be looked at by the technical team, discussed in the next section.

5.5 Change Team

It is suggested that there is a technical team formed from the technicians within the University to implement changes. This team after receiving initially approved changes would then set out to create a change plan. The change plan will set out what needs to be changed and how it is planned to be implemented. The goal of the plan is to highlight any issues that may occur and steps to resolve issues that are predicted, outlining backups and rollback procedures.  Once completed, it will then be re-referred to the board for approval. Following approval and implementation the team will update the change log with outcomes and issues. This will then be reviewed at stated at the next CAB meeting.

It is advised that change procedures are reviewed initially after 6 months then once per 12 months to ensure maximum efficiency.

6. Configuration Management

Configuration management allows the mapping of relationships between hardware and software within the services covered within the University.  This will ensure control of all assets that are used to deliver services. The following section will discuss the proposed plan for management of configuration items within the infrastructure.

Find out how UKEssays.com can help you!

Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.

View our services

6.1 Configuration Management Database(CMDB)

It is recommended that a configuration management database stored upon its own server is created to allow the understanding of relationships between the components and to see how they are configured, allowing a greater overview. It is proposed that there is a main CMDB database containing all the current hardware and software configurations currently deployed within the University. Alongside this database it is also recommended that there is a test CMDB database to contain all new configuration items identified, until deployment following testing where it will then be pushed to the main database.

The database is advised to be stored upon own its own server separate to the incident management database, interacting with release management database with all new releases, being automatically pushed into the configuration database.

The configuration database will contain all hardware that specifies each individual component such as the motherboard, central processing unit and the ram size and type. This will allow in the event of a component failure for the specific component to easily be replaced. The database will also contain details of all software, specifying version number and release. This will again allow quick identification of effected machines once known issues are realised.

The following section will cover the Lifecyle for hardware and software.

6.2 Configuration Lifecycles

6.2.1 Hardware Lifecycle

The hardware lifecycle for each component will be as follows:

  • Purchased – Awaiting delivery
  • Out of Use – Awaiting Configuration
  • Out of use –  Standby
  • Out of use – Damaged
  • Out of Use – ongoing repair
  • Out of Use – Retired
  • Out of Use – Lost or stolen
  • In use – damaged
  • In use – functioning
  • In use – redundant (every 5 years)

6.2.2 Software Lifecycle

  • Purchased – Waiting Delivery
  • Out of Use – Testing
  • Out of use – Standby
  • Out of Use – faulty
  • Out of use – repair
  • Out of Use – awaiting renewal
  • In Use

7. Release Management

Release management will allow the testing and successful delivery of services. This process will allow the release of services in a managed and coherent way. It ensures that all releases are planned, managed and effectively deployed with suitable training and documentation for ongoing support of the service.  Allowing all technology that comes in and out of the business to be approved and verified.

All new software and hardware will require approval by the Change Manager before implementation or distribution. All new releases must not conflict with the SLA and the agreed level of service, as such it will follow the approved release schedule as detailed in section 7.1.

7.1 Release Schedule

To effectively manage releases, it is suggested that the following information regarding releases is stored within a releases database that documents:

  • Release # – The unique release number allocated to identify each new release.
  • Release type – Definition of the type of the release and its impact for example, minor, major or emergency.
  • Description – Description of the release
  • Status- status of the release and its progression, pending, installed etc.
  • Risk determination- Indication of the risk of the release effecting business.
  • Priority – The priority will determine the rate in which the release will be processed, changeable dependent on the current business needs.
  • Performed by – who has performed the new release.
  • Planned start date: planned date to implement the release
  • The planned start date for starting the release.
  • Planned end date – the expected date for release completion.
  • Release date – the actual date the release was completed.

To manage software that is installed and to have a central point of information it is advised that the releases are contained within a definitive media library as discussed within the next section.

7.2. Definitive Media Library

The Definitive media library(DML) will list all approved software and hardware within the University and any approved teaching materials used. The DML will take two forms, one physical and one virtual. The physical library will take the form of a storage room; this room will contain all hardware that is currently approved but not in use by the University. This hardware will be stored with documentation of its specification and any installation guides specific to its use. Also, stored will be any software installation disks and teaching materials that are used such as books and video guides.

The following sections will detail how the virtual DML will be classified, detailing what is to be contained within each.

7.3 Virtual Definitive Media Library Classifications

7.3.1 Hardware

Within the hardware classification of the library it will detail all hardware approved for use. This information will be split up into the pathways at the University.  It will detail each hardware component specific to each pathway as follows, games pathway, networks pathway, computing pathway and general.

7.3.2 Software

The software classification will contain details of software approved for use detailing version number and any associated subversions or subsequent releases. Software will be split into two categories; the first category will be package software detailing how many licences it permits and support information. The second category will be for open source software detailing any known issues.

7.3.3 Teaching Materials

Information regarding all online teaching materials will be stored, with only access permitted by faculty staff. If a student needs access to materials, then this will be shared from the appropriate staff member.

7.4 Enforcement of the DML

Within the Universities infrastructure only technology personnel will be able to install software and hardware, with all installation privileges revoked from all other users. All academic staff are to have access to teaching materials.  If unauthorized software or hardware is used or installed, then the user will be subject to disciplinary offences.  If required software is not contained within the library, then it must be requested and follow the approval cycle.

8. Continuity and Capacity Management

Continuity management allows for planning in the event of service failure to ensure that the minimum level of service can always be met.

Capacity management allows the assessment of resources to ensure that the University can meet current and future needs.

Both continuity and capacity management plans will be discussed within the next section outlining how both apply to each service outlined in the SLA.

8.1 Continuity and Capacity Management of Services

8.1.1 Private Study Facilities

Continuity management – In the event of private study failure, it would leave students without access to facilities to do work outside of the classroom. To manage this in the most cost effective way it is suggested that there are a number study room independent from other rooms. In the event of a failure this can then be fixed with the availability for students to use other study rooms as needed.

Capacity Management –  There is not a great need for increased capacity for this service due to students leaving every year as new students start. If the University were to expand the student intake, this would need to be requested as a change to facilitate the need.

8.1.2 Separate Networks

Continuity management –  In the event of service failure it would impact a minority of students. However, students would be left unable to do work and it may possibly affect examinations. Therefore, it is proposed that this service is high availability with a separate backup network available if the primary network used should fail.

Capacity Management –  There is no need for capacity management with this service as the number of students on the networking pathway every year stays around the same number. Again, as mentioned with other services if there was a need to facilitate this it should be requested as a change.

8.1.3 Safe Student Storage (Backups)

Continuity Management –  In the event of this service failing it could be detrimental with loss of student data and services. It is recommended that this service is high availability so students can always access data. Further to this it is recommended that backups are performed at the end of each day when the University is closed to ensure minimal loss of data.

Capacity Management

This service will need to be regularly reviewed which is recommended to be on a weekly basis to assess the need for expansion. Backups and constant updating and storage by students will require this service to be continuously expanded. It is recommended that storage is increased by 25% every time available space is below 15%.

8.1.4 Dedicated Webservers

Continuity management –  If the webservers service were to go down it would not affect most students at the same point. It is suggested there is a 10% availability of extra servers at hand to transfer over students affected to allow the repair of the effected servers.

Capacity Management –  Due to the increasing number of students every year the service will need to expand allowing for possible need for increased storage as students’ progress.  This should be assessed before the start of every academic year with the recommendation that student servers are cleared and reused one year after graduation. As the number of students usually rise year on year, then the service needs to expand with that.

8.1.5 Remote Access

Continuity management –  I the remote access service were to fail it would leave students unable to access work stored upon the universities infrastructure. Due to the impact that this could have on students learning and assignments it is suggested that this service is high availability.

Capacity Management– Due to the increasing number of students every year this service will need to be reviewed on an ongoing basis recommended to be monthly. This will allow for identification of peak traffic times and help to ensure that the service can cope with this increasing demand.

8.1.6 Lecture Facilities

Continuity management If this service were to be unavailable it would have a large impact on students, leaving them unable to receive lectures. Although this service should be of high availability to allow all lectures to take place when needed it would pose unnecessary cost due to duplicate hardware, therefore it is proposed that there is two weekly testing to ensure facilities are operational. Further to this any incidents reported are of a high priority.

Capacity Management –  Although student numbers increase yearly there are also around the same number of students who leave. Therefore, increased capacity will not be need. However, if the University makes the decision to take on more students, this will need to be expanded as required and submitted as a change request.

8.1.7 Specialist Computer Labs

Continuity management – If the specialist’s labs service was to have a failure, it would leave students unable to continue work specific to their degrees that cannot be completed in other rooms. It is suggested that there is a lab available specific to each pathway with the capacity for 30 students as a minimum to use. In the event of a fault then temporary access will be given to other rooms if facilities meet needs where required.

Capacity Management–  Due to increasing student number every year this service will need to expand in line with this need. If the University plans to take on significantly more students than usual, then this facilitation will be needed to be requested as a change.

9. Conclusion

In conclusion, this document has looked at different levels of management, their purpose and how it is advised how to implement them within the creative technologies department within the University.  It had advised implementation for each section looking at standard ITIL practices. Also, looking at continuity and capacity management giving recommendations on each service provided.

10. Bibliography

Atlassian. 2017. Help desk vs. service desk vs. ITSM: What’s the difference? | Atlassian. [ONLINE] Available at: https://www.atlassian.com/it-unplugged/itsm/help-desk-vs-service-desk-vs-itsm. [Accessed 15 May 2017].

Essential Guide to ITIL Incident Management – Process Flow & Best Practices by Anthony Orr. 2017. Essential Guide to ITIL Incident Management – Process Flow & Best Practices by Anthony Orr. [ONLINE] Available at: https://www.cherwell.com/products/it-service-management/itil-processes/essential-guide-to-itil-incident-management. [Accessed 15 May 2017].

Essential Guide to ITIL Problem Management – Process Flow & Best Practices by Anthony Orr. 2017. Essential Guide to ITIL Problem Management – Process Flow & Best Practices by Anthony Orr. [ONLINE] Available at: https://www.cherwell.com/products/it-service-management/itil-processes/essential-guide-to-itil-problem-management. [Accessed 15 May 2017].

ITIL Asset and Configuration Management – BMC UK. 2017. ITIL Asset and Configuration Management – BMC UK. [ONLINE] Available at: http://www.bmcsoftware.uk/guides/itil-asset-configuration-management.html. [Accessed 15 May 2017].

ITIL Incident Management: Best Practices & Process Flow – BMC UK. 2017. ITIL Incident Management: Best Practices & Process Flow – BMC UK. [ONLINE] Available at: http://www.bmcsoftware.uk/guides/itil-incident-management.html. [Accessed 15 May 2017].

ITIL Best Practices – ITIL Service Management | Web Help Desk. 2017. ITIL Best Practices – ITIL Service Management | Web Help Desk. [ONLINE] Available at: http://www.webhelpdesk.com/help-desk-software/itil. [Accessed 15 May 2017].

ITIL Definition: Configuration Management (v2, v3). 2017. ITIL Definition: Configuration Management (v2, v3). [ONLINE] Available at: http://www.knowledgetransfer.net/dictionary/ITIL/en/Configuration_Management.htm. [Accessed 15 May 2017].

ITIL Definition: Service Level Management (SLM). 2017. ITIL Definition: Service Level Management (SLM). [ONLINE] Available at: http://www.knowledgetransfer.net/dictionary/ITIL/en/Service_Level_Management.htm. [Accessed 15 May 2017].

ITSM Foundation: ITIL Service Level Management. 2017. ITSM Foundation: ITIL Service Level Management. [ONLINE] Available at: https://www.itil-itsm-world.com/itil-6.htm. [Accessed 15 May 2017].

ITSM: The ITIL Configuration Management Plan. 2017. ITSM: The ITIL Configuration Management Plan. [ONLINE] Available at: https://www.itil-itsm-world.com/itil-1.htm. [Accessed 15 May 2017].

ITIL Problem Management: Best Practices & Processes Flow – BMC UK. 2017. ITIL Problem Management: Best Practices & Processes Flow – BMC UK. [ONLINE] Available at: http://www.bmcsoftware.uk/guides/itil-problem-management.html. [Accessed 15 May 2017].

ITIL v3 Problem Management. 2017. ITIL v3 Problem Management. [ONLINE] Available at: https://www.slideshare.net/Josep_Bardallo/gsx-problem-management. [Accessed 15 May 2017].

ITIL Release Management|What is ITIL Release Management|Release ITIL. 2017. ITIL Release Management|What is ITIL Release Management|Release ITIL. [ONLINE] Available at: https://www.cupe.co.uk/itil-release-management.html. [Accessed 15 May 2017].

ManageEngine. 2017. ITIL Service Desk / ITIL Help Desk Features – ManageEngine ServiceDesk Plus. [ONLINE] Available at: https://www.manageengine.com/products/service-desk/itil-features.html. [Accessed 15 May 2017].

Pink Elephant United Kingdom. 2017. Incident Management I ITIL. [ONLINE] Available at: https://pinkelephant.co.uk/it-service-management-2/incident-management/. [Accessed 15 May 2017].

Plutora. 2017. ITIL Release Management System – Plutora. [ONLINE] Available at: http://www.plutora.com/blog/itil-release-management-system. [Accessed 15 May 2017].

ServiceNow. 2017. ITIL Change Management – ServiceNow Wiki. [ONLINE] Available at: http://wiki.servicenow.com/index.php?title=ITIL_Change_Management#gsc.tab=0. [Accessed 15 May 2017].

ServiceNow. 2017. ITIL Release Management – ServiceNow Wiki. [ONLINE] Available at: http://wiki.servicenow.com/index.php?title=ITIL_Release_Management#gsc.tab=0. [Accessed 15 May 2017].

20000Academy. 2017. ITIL Service Level Management – one of the most important ITSM processes | 20000Academy. [ONLINE] Available at: https://advisera.com/20000academy/blog/2014/04/08/itil-service-level-management-making-sure-want-get/. [Accessed 15 May 2017].

11. Appendix

11.1 Service Level Agreement

Agreement Overview

This document represents a Service Level Agreement(SLA) between the University of Bolton and ryan kenyon for the management and support of IT services required for the universities IT infrastructure. It outlines all services to be provided and how these services will be managed.

1. Goals & Objectives

This agreement aims to outline the procedures and commitments that are in place to provide IT management services for the University.

The objectives are to:

  • Define accountability, roles and responsibilities
  • Present a concise detailed description of services to the customer

2. Periodic Review

This agreement is valid from the effective date outlined above, to be reviewed after three months to ensure operational constraints are sufficient.

If found to be sufficient, the document will remain in effect to be reviewed as a minimum once per year.

If the document constraints found to be inadequate by either party, then adjustments will be made to be reviewed in a 6-month period.

The Service level manager is responsible for regular reviews of this document. Amendments may be done as required if agreement is made between all parties. This document will include all revisions and approvals.

Service Level Manager: University of Bolton

Review Period: Bi-Yearly (6 months)

Previous Review Date: N/A

Next Review Date: 01-04-2018

3. Service Agreement

The following parameters outline the responsibilities of the provider during the duration of the SLA.

3.1. Service Scope

The following Services are covered by this Agreement;

  1. Private study facilities 
  2. Separate networks
  3. Safe student storage (backups) 
  4. Dedicated web servers
  5. Remote access
  6. Lecture facilities
  7. Specialist computer labs

3.2. Customer Requirements

Customer requirements and responsibilities in respect to this agreement are as follows:

  • Reporting of incidents within a reasonable time
  • Maintain reasonable contact if necessary further information required regarding logged incidents.

3.3. Service Provider Requirements

Service requirements and responsibilities in respect to this agreement are as follows:

  • Responding to incidents as outlined within the agreement
  • Reasonable notification of all scheduled maintenance within services.

3.4. Service Assumptions

Assumptions in relation to scope services are as followed:

  • Any changes to services will be document and agreed between all parties.

4 Service Management

Support of in-scope services to be maintained at consistent levels are outlined in the following sections. Covering availability and monitoring of services.

4.1 Service Availability

Coverage specific to the service covered within this Agreement are as follows:

Private study facilities – private study facilities will be available as outlined below:

During Term time –

8:45 A.M. to 5:00 P.M. Monday – Friday

9:30 A.M. to 12:30 PM – Saturday

9:30 A.M to 12:30 PM – Sunday

During Non- term time –

9:30 A.M. to 3:00 P.M. Monday – Friday

This service will be medium priority as in the event of a failure a minority of students will be affected. The response time will be within two hours with target resolution time of one hour.

Separate networks – Separate networks will be available 9am -9pm during term time due to the need for use during lecture periods. This service will be of medium priority with a response time of within two hours and resolution time of an hour.

Safe student storage (backups) – The backup service will be available 24 hours allowing recovery if needed at any point. This service will be high priority due to consistent storage and backups being needed always. The response time will be within three hours of identification with a resolution time of one hour.

Dedicated web servers – The webserver will need to be available 24 hours a day allowing for student access, due to this the service with be high availability. The service will be classed as high priority if there is any disruption due to affecting all students. Response times for the webserver will be within two hours of reporting with target resolution within an hour of response.

Remote access – Remote access will be deemed as high priority due to service unavailability affecting all remote access. The service needs to be available 24 hours with a response time of two hours of notification to be resolved within an hour.

Lecture facilities – Lecture facilities will be available 9am -9pm during term time due to the need for lectures to take place. This service will be of high priority with a response time of within an hour and resolution time of an hour.

Specialist computer labs– The specialist labs will be available 9am -8:30pm during term time due to the need for usage when the University is open. This service will be of low priority due to affecting minimum students with a response time of within a 24 hours and resolution time of 2 hours

11.2 Change procedure

11.3 Problem Management


Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this assignment and no longer wish to have your work published on UKEssays.com then please: