University of Bristol Service Management Project

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. 6 months 12 Months 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 Service Support processes:Straw man targets & timescales for consideration

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