1. University of Bristol Service Management Project
Ann Field
15 July 2008

2. Contents Recommendations summary Management buy-in
Other Pre-requisites
ITIL Programme workstreams – key activities, broad timelines, dependencies

3. Recommendations – to develop during workshop on Tues 15th and updated here to reflect that discussion
Use the existing Business Case drivers to gather support for an Improvement project with the following priorities:
Acceptance that Service Management introduces an effective Governance model that supports good quality IT service delivery NEW – not in the current draft of the business case
Including the introduction of a ‘Service Level Management’ concept and culture, to aid prioritisation
Formalises some aspects of the existing management structures, and invests them in the responsibility for driving service strategy and policy changes
Introduce Change Management – a process has been defined, although not implemented
Introduction of an effective Incident Management process to support the HelpDesk in tandem with revised Call Handling function – a decision is needed (governance) regarding the management policy change this implies
Introduce Service Level Management
Revamp or replace the HelpDesk tool – Requirements capture is mostly complete
Project to define & prioritise requirements for the tool, including:
Incident Mgt
Problem Mgt
Change Mgt
Configuration Mgt
Reporting (supports SLM)
Tool selection & implementation
Agree on the level of integration and definition that is required for Configuration Management at a University Level – agreed that it is important to define this scope and then to progress the project in stages.
Define Configuration Management objectives and phases
Business Case for Phase 1

4. Workshop Recommendations to Project Board
Introduction of an integrated support model, with all IT Support staff including department-based staff, operating within the ITIL framework, within which their process Roles/Responsibilities defined by a RACI model (RACI: Responsible, Accountable, Consulted, Informed)
The meeting believes that a willingness exists to work this way – but needs selling via a ‘hearts and minds’ campaign, particularly aimed at Departmental Management
Senior management understand the benefits that a formal framework will bring, in terms of removing single points of failure, bridging skills and knowledge gaps, etc.
IT Staff do informally work in a co-operative way, e.g. mobile IT Staff support model is developing
Heads of departments may fear a loss of control
Education
Trust
Understanding the benefits that skills and knowledge sharing can bring, with specialists working within a broader IT team
Developing a formal knowledge base
Sensitively introducing centralised logging, in support of the IT staff network
Enables local staff to develop pro-active aspect of their role
Introduce formal skill and knowledge management process to:
Reduce possibility of single points of failure / improve support matrix
Help staff ‘buy-in’ to their roles within the integrated model by enabling them to see the development opportunities that it offers

5. Key Dependencies & pre-requisites
Management ‘buy-in’ and genuine commitment to the service management initiative
Help Desk structure needs a review if it is to operate effectively in the new service model
Structure, location, size
Decide incident management model
Current call volumes are not representative of the support call volumes in ‘new world’ structure
Compare with other universities (e.g. UWE) who have introduced centralised logging
Consider manpower required to develop and implement ITIL
Process development and implementation takes time, on top of ‘day job’
Existing cross-team working (e.g. around configuration management) means that an understanding of both the amount of effort required is developing, as is an appreciation of the benefits of working this way
New role (e.g. Change Manager) required Full time during process implementation; may reduce thereafter
Make sure the processes aren’t bureaucratic
E.g. a slick standard change model will be required to ensure Network engineers adopt Change Mgt
Sell the processes in terms of ‘what it means to me’ not overly formal process
Use RACI model to explain process interactions to staff

6. Raise & Log RFC (Case Handling)
Requests for Change are logged into the Change Management Process in order that they can be tracked through to completion. The entry to EARS (Capgemini’s Change Logging system) may be directly through those users with access or requests may be submitted to the Change Administrator for entry to the system.

7. Filter Change Requests
An initial filtering of Change Requests is undertaken to remove any requests which are judged to be obviously impractical. The judgement will be taken in dialogue with the originator and all parties made aware of any filtering and the reason.

8. Assign
All resources with tasks to perform to implement the change are to be assigned their work packages formally for the Change Administrator to track progress through feedback from the Build Teams. It is assumed that original estimates and risks are reasonably accurate unless or until any problems are flagged for discussion.

9. Service Support processes: Straw man targets & timescales for consideration
Level 1 Prerequisites
Level 1.5 Management Intent
Level 2 Process Capability
Level 2.5 Internal Integration
Level 3 Products
Level 3.5 Quality Control
Level 4 Management Information
Level 4.5 External Integration
Level 5 Customer Interface
6 months
12 Months
Maturity level
Equates to in OGC assessment
1, Initial, Ad-hoc
1 & 1.5
2, Repeatable but intuitive
2 & 2.5
3, Defined
3 & 3.5
4, Managed and measurable
4 & 4.5
5, Optimised 5

10. Interviewees – 8 July 2008 John Richards Lucy Shepherd-Hucker
Henryk Glogowski
Bob Walker
Paul Buttner
Luke Taylor