You are on page 1of 29

Information & Communication Services

PROJECT INITIATION DOCUMENT
Based on PRINCE2

IT Service Management System – Phase 1
Release: Date: Author: Owner: Client: Document Number: Final 15 January 2007 Susan Hall Tom Mortimer I.C.S. ITSMSP1/PID/0611/01/V 14.0

Document History
Document Location - The source of this document is on the University network in location: Revision History Revision date Previous revision date Summary of Changes First issue Distribution - This document has been distributed to: Name Title ICS-Management Team ITIL Process Owners Service Development Programme Board Date of Issue 5th January 2007 5th January 2007 15th January 2007 Version 5 5 11 Changes marked

Approvals - This document requires the following approvals (signed approval forms are filed in the Management section of the project file):

/var/www/apps/conversion/tmp/scratch_6/167324325.doc

Printed 26/08/2013

Project Initiation Document Phase 1

IT Service Management System –

Name

Signature

Title

Date of Issue

Version

1. Project Initiation Document............................................................................................................4 1.1. Purpose of Document.............................................................................................................4 1.2. Background..............................................................................................................................4 1.2.1. Service Development Programme....................................................................................4 1.2.2. ITIL Roadmap..................................................................................................................4 1.3. Introduction to Service Desk and Incident Management – Where do we want to be?............5 Service Desk...........................................................................................................................5 Ist line Support........................................................................................................................6 Standard Incident Management Process.................................................................................6 Service Requests.....................................................................................................................6 Service Level Management....................................................................................................7 Software tools.........................................................................................................................7 1.4. Current Status – Where are we now?......................................................................................8 1.4.1. Service Desk.....................................................................................................................8 1.4.2. Ist Line Support................................................................................................................8 1.4.3. Standard Incident Management Process ..........................................................................8 1.4.4. Service Requests...............................................................................................................9 1.4.5. Service Level Management..............................................................................................9 1.4.6. Software tools...................................................................................................................9 1.5. Project deliverables................................................................................................................10 1.5.1. Service Desk...................................................................................................................10 1.5.2. Ist Line Support..............................................................................................................10 1.5.3. Standard Incident Management Process.........................................................................10 1.5.4. Service Requests.............................................................................................................10 1.5.5. Service Level Management............................................................................................10 1.5.6. Software tools.................................................................................................................11 1.6. Project Definition..................................................................................................................12 1.6.1. Project Objectives ..........................................................................................................12 1.6.2. Project Scope..................................................................................................................12 1.6.3. Method of Approach.......................................................................................................12 1.6.4. Project Deliverables and/or Desired Outcomes..............................................................14 1.6.5. Exclusions.......................................................................................................................14 1.6.6. Constraints......................................................................................................................14 1.6.7. Interfaces........................................................................................................................14 1.6.8. Assumptions...................................................................................................................14 1.7. Project Organisation Structure...............................................................................................14 1.8. Communications Plan ...........................................................................................................15 1.9. Project Quality Plan...............................................................................................................16 1.10. Initial Project Plan...............................................................................................................17 1.10.1. Financial Budget...........................................................................................................18 1.10.2. Staff resource requirements..........................................................................................18 1.10.3. Tolerance......................................................................................................................20 1.11. Project Controls...................................................................................................................20 1.11.1. Reporting and monitoring mechanisms........................................................................20

Page 2

24 2.............................23 2........................................ Appendix A ......................................3........................................2... Initial Risk Log................... Major Incident Review – Example of response to a major incident: <insert title of incident> .......................................................................................... Contingency Plans....................................................................................................................................................2..................................22 Attachments.................................................22 2................................................................12...............................1........................................................ Stakeholders in the IT Service Management System project............................ What would each stakeholder group like to see delivered by the first phase of the project? What are the benefits of delivering these products?......14................. Exception process....23 2.........21 1...13............................................................................28 Page 3 ...................21 1.................................................................11...........................................23 2.................................................................Project Initiation Document Phase 1 IT Service Management System – 1..... Presentation – What is Service Desk and Incident Management..........21 1...4..... Project Filing Structure................

Touchpaper IT Business Management.Project Initiation Document Phase 1 IT Service Management System – 1. Andrews.since 1994 the University has more than doubled in size. ITIL Roadmap Software tools are fundamental to the management of IT Services and a suite of tools. 1.Background 1. Project Initiation Document 1. Touchpaper will lead the transition to ITIL Best Practice starting with the implementation of the core modules. internationally recognised for its expertise across a range of disciplines including science.2. In 2007. the University will celebrate 40 years since it became an independent university after a 70 year relationship with the University of St. Page 4 . Service Desk and Incident Management. In any transition programme there are a number of standard questions to answer and this will be referred to as the process improvement model.2. has been purchased to support the adoption of ITIL. 1. Purpose of Document The purpose of this document is to define the project. which will provide the foundation for a more integrated approach to IT Service Management using the IT Infrastructure Library (ITIL). The order of the ITIL process implementation will be closely aligned to the associated dependencies of the Touchpaper software modules. to form the basis for its management and the assessment of overall success. Touchpaper will act as the central software tool.2. Current internal processes and technology are not enabling ICT to provide support for these services in the most effective and efficient way. engineering and art. The Service Development Programme aims to provide a process oriented solution. Service Development Programme The University of Dundee is one of the UK’s leading universities.1.2. The University has seen some major changes in that time. linking with all the other tools for managing infrastructure and applications. Information and Communication Services (ICS) aims to provide a range of information and communication technology (ICT) services that support students and staff at the University. The past decade has been a particularly exciting time of progression and change . medicine.1.

The Service Desk is a function that should handle all Incidents and requests and provide an interface for other activities such as Change. Problem. Service Level and IT Service Continuity Management. consistency of service enables quality 1 Notes from this workshop can be found in Appendix A. which will provide the ‘Vision’ for the project. Configuration. an organisation can realise the following benefits: 1. By having a Service desk. Service Desk The goal of the Service Desk in ITIL Best Practice terms. Five key areas were identified: • • • • • • Service Desk 1st Line Support Standard Incident Management process Service Requests Service Level Management Software tools – including initial CMDB This section will describe the main features that are outlined within ITIL for each aspect. Page 5 .3.Project Initiation Document Phase 1 IT Service Management System – Figure 1: Process Improvement Model 1.Introduction to Service Desk and Incident Management – Where do we want to be? A workshop was held with the ICS Management team on 11th December 2006 to set the scope for the Service Desk and Incident Management project and to determine the areas for improvement1. is to act as a central point of contact between the User and IT Service Management. Release. Consistent interface for users to contact IT.

A standard process for managing incidents is essential and delivers: 12. Reduce pressure on 2nd line support and provide high quality information into the Incident Management process 9.Project Initiation Document Phase 1 IT Service Management System – 2. Lead the operation and ongoing development of the Incident Management Process 11. to be made for a Service. 2-way communications including information to users on status Assurance that all queries are captured and recorded in the correct manner by trained staff Fair and appropriate prioritisation by eliminating the ‘By the back door’ route The service provider and the user know what to expect by having consistent procedures A software tool can be used to manage the relationship between Users and the IT department which can enhance the service by adding Self-Service for logging and tracking Incidents and Service Requests. 6. 4. Providing accurate and up-to-date knowledge by managing the knowledge process Standard Incident Management Process The Incident Management Process aims to restore normal service operation as quickly as possible with minimum disruption to the business. Providing access to Services for a new member of staff and relocating PCs are two typical examples. Stakeholders are able to agree changes in advance which improves clarity and efficiency 20. Other Requests for Change can mean a change in the definition of the service. Solve a high proportion of Incidents at first line thereby reducing impact of Incident on User and increasing User perceptions of support 8. A Service Request is characterised by the fact that the Change can be made under strict. Ist line Support ITIL Best Practice recommends that an organisation should decide on the level of technical expertise delivered by 1st line support. giving confidence to the User 14. User approves call closure Service Requests A Service Request is a type of Request For Change. A common language to allow better communication and understanding 16. 3. A Service Request does not normally result in a change to the definition of the Service. Clarity and transparency of the support mechanism. Provide information to other Service Management Processes by managing a feedback mechanism 10. usually both common and straightforward. therefore require development and approval under the Change Management Process. 5. this enables reporting 17. so if there are improvements to be made to the process this can be done easily 18. Service Requests are predefined and linked to User recognised services which makes the services more accessible to users Page 6 . Clear expectations on what support offers and agreement between the User and the IT department 13. well-defined procedural control and is therefore (virtually) risk free. A documented and standard process can be changed. A technical/expert level Service Desk can add value to the organisation by giving the following benefits: 7. Opportunity to train staff in the standard procedures 15. thus ensuring that the best achievable levels of availability and service are maintained. A controlled process can be measured. By defining Service Requests value is added to the organisation in the following ways: 19.

and allow performance to be measured so that realistic targets can be set. The information can be used for management (i. There is an established interface with customer representatives which acts as a communication channel. Users know what to expect and support staff know what they are trying to deliver by having defined levels of service. information can be linked to show complex relationships which can be used by all ITIL processes. Provide automated escalation for Incidents 31. giving Users more information about when they will hear from support 25. Standard procedures for making changes means that operational tasks can be shared easily thus reducing risk associated with single point of failure 22. for planning and operating services through the ITIL processes) and for reporting on the performance of the services to Users and Customers.e. This can reduce pressure on support staff to achieve unrealistic targets. Support tools can be configured to automatically track the progress of Incidents so that they don’t get forgotten about 26. 24. Allow evidence based management decisions using information that is timely and give confidence to decision making by having accurate data Page 7 . By producing reports the Service Desk can add value in the following ways: 28. SLAs are underpinned by Operational Level Agreements. Initial response times can be set. helping IT to develop an clear picture of which services are used most and when Service Level Management Service Level Management ensures that service targets are documented and agreed in Service Level Objectives (SLOs) and monitors and reviews the actual service levels achieved against their SLA targets. The support department can demonstrate the value it adds to Users by reporting on the performances of services and support 27. 29. Software tools The Service Desk. supported by a software tool.Project Initiation Document Phase 1 IT Service Management System – 21. Providing the basis for a Configuration Management Database (CMDB) 30. Enhancing the interface between Users and the IT department by providing a web Self-Service mechanism for logging and tracking Incidents and Service Requests. SLM gives the following benefits: 23. Promoting targeted organisational learning (User and Analyst) and extending the User learning experience by providing Knowledge linked to common Incidents and Service Requests 33. Controlled procedures can be reported on. Make meaningful information available to all stakeholders for example to allow reviews of service support and delivery to support continuous improvement 32. produces reports on Service Support and Service Delivery. By using a database.

Current Status – Where are we now? The maturity of each aspect of Service Desk and Incident Management was assessed during the workshop with the ICS Management team.4. Ist Line Support 1 Level knowledge and problem solving skills are good and many Incidents are solved at 1st level. Incident Management is handled in a disparate way. The interface for users to contact IT is distributed (central Helpdesk.4.g. 1. Users don’t always know when work has been carried out on their request for help Page 8 . 1. Service Desk At the present time the Service Desk function is carried out by the Helpdesk in addition to other individuals and groups within ICS – the Service Desk is not a Single Point of Contact (SPOC).1. This could be due to lack of knowledge or lack of time. how long they should wait before following up on a call 14. All staff involved in the Incident Management process are not trained in how to use it 15. it is therefore difficult to deliver consistency of service and to ensure quality 2. It is difficult to make changes to the distributed procedures and this can be confusing for the Helpdesk as there are so many different procedures in operation for different Units / teams / individuals 18. IT Suite Helpdesks staffed by postgraduate students. The correct information is not always collected from the User at first point of contact. 1.4. 9. Support analysts and users are unclear about what is expected from the support process. this section describes how ICS is performing at the moment for each area. however the Helpdesk operates as a call logging function for many other support calls.e. The software tool does not offer Self-Service for logging and tracking Incidents and Service Requests. 7. Reference solutions are updated regularly. There is no published statement to describe support 13. In the IT Suites many Incidents are solved at first contact. 12. A common language is emerging through the uptake of ITIL 16. Prioritisation of Incidents is unclear and undocumented 5. with some communications going out to user community via Communications Office 3. The Service Desk does not have a published feedback mechanism 10. Service Desk is mainly reactive. Standard Incident Management Process There is no standard Incident Management process for ICS. It is difficult to manage the function to deliver the benefits offered by a Best Practice Service Desk. Some queries are not captured and recorded in the correct manner by trained staff 4. other ICS staff). S3 service) 17. Users are not sure what to expect from support i. Procedures are not consistent so Users don’t know what to expect 6. however there is room for improvement. 8.Project Initiation Document Phase 1 IT Service Management System – 1.2.4. There is some measurement of Incident Management processes (e. with different Units / teams / individuals adhering to different procedures 11.3. although this is solely for use within the Helpdesk and is updated by the Helpdesk without guaranteed input by Analysts st 1.

Helpline does not offer automated escalation 31.4. 22. 32. 1. 29. No formal workflow exists however some procedures are standardised. There is limited reporting functionality within Helpline. 19. 20. Service Requests There is no formal management of all Service Requests within ICS. There is no Knowledge Base within Helpline 33. Software tools The current support tools (Helpline and others) do not offer a full range of features to support ITSM. Stakeholders are unclear about the response times required and how to prioritise. Current Support tools do not offer automated escalation according to defined Service Levels 26. There is currently no reporting on Service Requests. however this is a small proportion of those on offer.4. Page 9 . 27.5. 28. Helpline does not offer functionality for Users to manage their own Incidents via the web.Project Initiation Document Phase 1 IT Service Management System – 1. 25. Not all Incidents are recorded in Helpline therefore the tool cannot be used to provide accurate reports. It is possible to request some Service Requests via a printed or online form available from ICS Reception / Helpdesk or Website. 23. There is no CMDB 30. Levels of service are not currently defined for the User or Support Analysts 24. Some of the standard changes have one or more of the characteristics of a Service Request (defined request mechanism (online form). Several tools are in use and these do not offer integration between different components of the infrastructure and ITSM processes. There is no formal change management procedure for Service Requests including consultation with all stakeholders 21.6. The interface for these is not consistent and does not currently link with services.4. standard workflow and closure/approval with the user). ICS liaison acts as a channel for communications. The Service Level Manager has setup a mechanism for communicating with Customers through ICS Liaison. The support tools are not used by all Support Analysts to manage all support calls. Service Level Management The Service Level Management function has been established.4. 1. There is currently no reporting to stakeholders on performance of services.

and Section 1.Project Initiation Document Phase 1 IT Service Management System – 1. documented and published to the User community Consistent and audited procedures.5.Project deliverables In broad terms the project vision is to improve the Service Desk function and Incident Management process within the University. Procedures manual and training 15. Service Level Management reporting. Centrally managed procedures for all Incident handling 11. The ICS Liaison Interface will be supported by the Service Management tool Page 10 . Knowledge management 1. 1.3 described this in detail with reference to ITIL.4. Workflow and standard procedures for all Service Requests. Service Level Management 23. 6.5. Feedback mechanism available via the Service Desk 10. Service Requests 19. Service Desk Single Point of Contact for all IT queries Communications to be sent out by the Service Desk on status of IT services Service Desk Staff trained in all procedures for Incident Management Clear guidance on prioritising Incidents. Defined response times 25. 27. owned by the Incident Manager Self-Service Portal 1.2.4 illustrated how well IT Service Delivery and Support are performing at the current time. Clear ownership of the Incident Management process and mechanism for requesting changes 18.5.5. Defined response times (target times initially) 14. 22. 20.5. Service Requests managed and owned by the Service Desk and all Service Requests should be made available to Users in the same way. Defined Service Objectives 24. 3.5. Automated escalation for Incidents and Service Requests 26. Templates and scripts for standard requests 9.1. Standard Incident Management Process 12.5. This section lists the deliverables required from the project. 1. Commitment to ITIL terminology 16. Ist Line Support 7. 2. Section 1. 5. training etc) 8. Increased level of technical awareness for Incident Management Analysts (procedures manual.3. Regular reports based on stakeholder requirements 17. Two stage closure with User 1. Standard template and approval mechanism for all Service Requests 21. Service / Support Charter describing the aims of the support processes 13. 4. Regular reporting on Service Requests 1.

Automatic escalation 31. Page 11 . Software tools 28. All Incidents recorded in the Service desk tool. Knowledge Base 33. Standard set of reports available on a regular basis according to requirements. Web Portal 29.5. 32.Project Initiation Document Phase 1 IT Service Management System – 1.6. Basic CMDB database as defined by Configuration Manager 30.

Method of Approach A standard improvement model will be used to develop each key deliverable to ensure quality.6.Project Initiation Document Phase 1 IT Service Management System – 1.2.3.1.ITIL processes for Service Desk and Incident Management 1.6.Project Definition 1.6. Improvement model Page 12 . Project Objectives O1. Final approval will be made by the ICS Management Team. In doing so this will make best use of current good practice within ICS. workshops and circulation of documents for comment. The design process will include consultation of stakeholders using a variety of mechanisms where appropriate e.6. The model will incorporate the current state and ITIL Best Practice into the solution design.g. Publicise the solution within the University user community O4. Information & Communication Services Service Management . Establish metrics by which the Service Desk function can be measured and evaluated O3. Improve overall user satisfaction with support as measured by user perception surveys or other appropriate methods 1. Project Scope University of Dundee. Develop and implement a Service Desk and Incident Management solution for ICS based on the ITIL framework O2.

Project Initiation Document Phase 1 IT Service Management System – A template will be used to direct each improvement exercise for ease and consistency and this will incorporate the following headings: Heading Define Content • What we want to get out of the component (guided by ITIL Best Practice) e.g. • Scope and stakeholders • KPIs – key performance indicators – how do we measure how well this component is performing? • Decide what measurements should be used to illustrate performance • Carry out the measurements • Present the measurements • Assess the process capability • Determine potential influence factors – propose hypotheses • Test hypotheses • Design improvements • Produce business case • Implement improvements • Test the effect of implementing changes • Optimise improvements (review results of testing) • Produce report describing the business case (including cost benefit analysis) Page 13 Measure Analyse Improve . Service Desk to be a single point of contact.

Any issues that arise will be passed on to the Service Development Coordinator and the relevant ITIL Process owner so that a decision can be made on the appropriate action to take. Page 14 .6. 1. Constraints This project will require staff resources from each Unit in ICS.5. 1.4.Project Organisation Structure The organisation structure describes how staff working on the project will relate to each other.5 1. Interfaces The project interfaces are described in the Project Organisation Structure and Communication plan sections of this document. 1. Project Deliverables and/or Desired Outcomes See project deliverables Section 1. particularly in the Service Desk area. Assumptions Resources will be available when required through prior negotiation with line managers.6.6.8. The quantity and quality of commitment could limit what the project will be able to achieve in the time allowed.7.6. 1.6.Project Initiation Document Phase 1 IT Service Management System – • Control Report • • Implement changes using an operations checklist o Policies o Procedures o Roles o Responsibilities o Training o Technology (checklist of Touchpaper components that have configuration requirements) o Documentation Establish continuous improvement mechanisms Establish method of reporting 1. Exclusions Dependencies under the management of ITIL disciplines which are yet to be established within ICS.7.6.

8.Communications Plan Page 15 .Project Initiation Document Phase 1 IT Service Management System – 1.

• Produce a high quality implementation that covers all of the deliverables set out in the PID to the required quality standard.g. Interested parties Incident Manager Incident team (comprising support staff – to be established) Problem manager Problem team (comprising support staff – to be established) Department support staff Communication mechanism and frequency • Project team meeting • • • • • • • • • • • • • • • via Incident Manager regular meetings email workshops Project team meeting via Problem Manager regular meetings email via Incident Manager regular meetings email workshops via Service Desk (guidance on mechanism to be advised by the Project Board) Via Service Development Programme meetings User community Other Service Management initiatives – e. ITSCM project 1. • Use resources effectively by providing the correct information and training to people involved in the project to enable them to give input. Communicate the benefits to stakeholders to ensure that they are on-board with the implementation.Project Initiation Document Phase 1 IT Service Management System – The communication plan defines the mechanism and frequency for all project communications. • Ensure that all stakeholders (especially ICS staff and Users) are aware of the changes and how they will impact them.Project Quality Plan The quality of the project should be assessed according to the following criteria: • Develop an efficient implementation schedule to put the right processes in place at the appropriate times recognising any dependencies between processes. Page 16 . • Manage risks to the project as efficiently as possible.9.

10. The Work Packages will be: • Service Desk • 1st Line Support • Standard Incident Management process • Service Requests • Service Level Management • Software tools – including initial CMDB In the case of ‘Software tools’ this work package may be split into further components to align with project plans produced by Touchpaper for the installation and configuration of the system. Key dates: Switch over from Helpline to Touchpaper Service Desk and Incident Management: May 2007 Launch of Service Desk: June 2007 Launch of Service Portal (to User community): July 2007 A more detailed breakdown of tasks and milestones will be made available during the project.Project Initiation Document Phase 1 IT Service Management System – 1. Initial Project Plan The initial project plan will incorporate the approach outlined above. At the start of each stage each Work Package will have a more detailed plan of activities which will be worked out between the Project Manager and Work Package leader. Tasks: Page 17 .

Financial Budget Item Training Core Touchpaper training Additional Modules Additional staff resources Cost Possible additional cost – to be identified as required Possible additional cost – to be identified as required Date required 1. Staff skills Person identified FTE required for duration of project 0.2 Notes Tom Mortimer Leadership and direction: IT Service Management leadership Process: ITIL Incident Management (Manager level) Emily Patterson 0.4 Problem Manager Damien Mcguiness 0.1.10.3 Leading work packages and writing documentation Approx 2 hours every 2 weeks for every UH to be involved in project meetings Interface between incident management and problem management Approx 1 hour a week for a representative from ITIL Incident Management (Line Manager level) Unit Heads 0.Project Initiation Document Phase 1 IT Service Management System – 1.2.10.2 ITIL Incident Management (Analyst level) Specialists 0.3 Page 18 . Staff resource requirements This project will be a short term project and it is not feasible to identify resource requirements for each stage. so an indication of average resource requirement has been made over the whole project.

Advising on project communications as well as products with communications element e.2 Service Desk: ITIL Service Desk Service Desk staff Emily Patterson To be allocated 0.2 Database: Administration 1 Emily Patterson 0.2 Leading Service Level management component of SD&IM Leading Configuration Management component of SD&IM Leading Service Desk component Documentation e.3 0. Service Desk Shoadowing of Touchpaper consultant during setup and configuration of the system Data Input / design / reports etc.2 0.2 0.Project Initiation Document Phase 1 IT Service Management System – each unit to be involved in the project.2 Communications Julie Christie 0.3 Susan Hall Susan Hall / Ann Muir “ “ 0. General ITIL Service Level Management Susan Hall Dave Murie 0.1 0.2 0.05 0.4 Page 19 .3 0.2 Adminstration 2 Data Input (workflow) Service Portal and Client design Business analysis/project management: PRINCE2 and MS Project Data analysis and statistics Process mapping and analysis Workshop facilitation To be allocated Brian Yeomans Brian Yeomans 0. templates etc.g.g operations manuals. Configuration Management Chris Reid 0.

11.1.1 0.1 0. o Resources – if the resource required varies by more than 0. o Business Case – the business case must not be changed without approval by the programme board. Reporting and monitoring mechanisms Project reports will be made to the ICS Service Development Programme Board and Network improvement Programme Board.1 0.11. Project Controls The project will be managed using PRINCE2. Tolerance The project leader can make adjustments to the project plan as long as the project stays within the tolerances defined below: o Timescale – if the projected timescale varies by more than two weeks. the programme board must approve the exception. specifically: • Project Manager to submit monthly highlight reports to the programme board • Project Manager to maintain Risk log • Project Manager to maintain Issues log • Project Manager to maintain Lessons learned log • Project Manager to submit End of project report to the programme board 1.3.1 0.10.Project Initiation Document Phase 1 IT Service Management System – Technical integration and support: Window Server Solaris Oracle Database eDirectory Email Network (including Security) Windows Workstation Tobi Wood Brian Russell Stephen Jones Kevin Shrimpton Mary Shrimpton Simon Bennet Mark Stephenson 0. o Cost – if the projected costs vary by more than £1000.05 0. Reporting will be done using the standard written report template. the programme board must approve the exception. the programme board must approve the exception.5 FTE. 1. NIPB reporting 19 Jan 16 Feb 16 Mar 13 Apr 18 May 15 June 13 July SDPB reporting 16 Jan 13 Feb 13 Mar 10 Apr 15 May 12 June 10 July Page 20 .1 0.1 1.

2. R High – T. Contingency Plans Plan based on risks outlined in risk log Item Internal resources – quality and quantity Probability High Contingency plan Monitor resource usage and performance against estimates on a weekly basis to avoid suprises. B. Item Initial Risk Log Risk category Organisational / management / human Technology Partner Organisational / management / human Organisational / management / human Technical / operational / infrastructure Organisational / management / human Organisational / management / human Organisational / management / human Organisational / management / human Probability High Med Low Med Impact (Time. B High – T. B Owner ICS Management team ICS Management Project management ICS Executive Internal resources External resources – server hardware External resources – Touchpaper consultant availability Lack of integration with other processes – implementation in isolation Possible lack of visible management or staff commitment Software tools unsuitable for solution Poorly defined service objectives or goals Lack of clarity about business needs Lack of representative user commitment to define requirements Resistance to change Med Low Med Med Med Med High – T. quality.Project Initiation Document Phase 1 IT Service Management System – 1. B. R High – T. B. Exception process Exceptions to be approved by Service Development Programme Board / NIPB 1. Q. Q. Q. R High – T. B. resources) High – T. R ICS mgmt ICS Executive ICS mgmt ICS Executive Senior User ICS mgmt 1. B Med – T. Q. B High – T. R High – T. B. Q.13. R High – Q. Q.11. Page 21 Cost .12. benefit. Q.

Project Filing Structure Project documentation will be stored under: S:\ICS Projects\... design and decision making Employ all available mechanisms to communicate with users.. ICS Liaison Who Moved My Cheese Explain benefits to stakeholders Med Low Poorly defined service objectives or goals Lack of clarity about business needs Lack of representative user commitment to define requirements Resistance to change Med Med Med Med 1.14..g. Attachments Initial Business Case – described in Background section Initial Project Plan – described in Approach Page 22 . Where necessary use existing mechanisms e. design and decision making Involve ICS management team in planning.Project Initiation Document Phase 1 IT Service Management System – External resources – server hardware External resources – Touchpaper consultant availability Lack of integration with other processes – implementation in isolation Possible lack of visible management or staff commitment Software tools unsuitable for solution Med Low Med Careful planning Training for internal staff Ensure that all relevant process owners are involved Regular and frequent communications Touchpaper consultancy can help reduce chance of this happening by helping with decision making on design and responding to enhancement requests Involve ICS management team in planning.

Presentation – What is Service Desk and Incident Management Service Desk SPOC Consistent Capture all No back door Consistent procedures Knowledge Fast response Less pressure on 2nd line support Value Feedback Ownership of Incident Management Agreement Clarity Training Terminology Measures Changes Agree pre-approved changed Predefined Defined levels of service Initial response Tracking Meanigful Timely Accurate Review Ist line support Standard process for incidents Service requests Service Objectives/Operational Level Agreements Management info Incident Management <diagram to be inserted> 2. Examples Mechanism of representation Page 23 . Appendix A IT Service Management System project – phase 1 Workshop 11th December .2.1.Notes 2.Stakeholders in the IT Service Management System project Group Abbrev.Project Initiation Document Phase 1 IT Service Management System – 2.

There is value in being able to trace items throughout their lifecycle for Incident and Problem Management.What would each stakeholder group like to see delivered by the first phase of the project? What are the benefits of delivering these products? Ref 1 Goal Deliverable Tracking mechanism Group S ITSM Benefit We expect suppliers to be able to give us an update on progress of products they are providing to us.g. Once these products are delivered they should be traceable within our system so that we can let suppliers know that they have arrived or for ongoing maintenance and support provide more detailed relationship information. Purchasing Office External ICS – Central IT Provider ICS-LM Line Managers ITSM ICS-A IT Service Management – process owners Operational staff (support and development analysts) ? Other IT Providers Other-A All staff Analysts based in University departments ? 2. asset Page 24 .Project Initiation Document Phase 1 IT Service Management System – End-users U Students Members of staff LISC Vice Principal/Deans ? ? ? ? Customer Suppliers C S–I S–E Other University Internal – e. Estates & Buildings.3.

Sometimes users don’t know that the call has been closed.Project Initiation Document Phase 1 IT Service Management System – 2 3 4 Tracking and transparency of incidents Prioritisation to agreed service levels Communications including proactive updates of status of Incidents Other A Other A Other A management (Financial management) and account management (Service Level Management). Should be convenient and have multiple routes e. effectively and closed. web etc All relevant information can be recorded efficiently without repetition. 5 Automatic logging Other A of alerts from infrastructure monitoring ITSM 6 Efficient. phone. Makes other analysts feel part of the overall service provision for the University. Knowledge of what is happening so that they can be pre-warned of possible breaches to service. To fulfil their service objectives Timely incident resolution Realistic Expectations Updates allows planning. Value for money. Reduce pressure on IT support staff.g. Other A 7 8 Incidents are resolved – fast. Calls only closed when agreed = clarity Sometimes the ICS analyst has misunderstood the call so closer communication with the user would be better.g. in closing calls Other A Other A 9 Department IT Support staff have Other A Page 25 . accessible routes to logging incidents. Participation e. Makes other analysts feel part of the overall service provision for the University rather than being out on a limb. Awareness of issues will allow Other A to offer assistance where they have expertise.

accessibility Clarity about services Simple start then develop Clarity of purpose Approach that will be used Changes/impact Key for ICS This will help staff to plan for the changes with respect to: Training in using Touchpaper Training in using the new procedures for IM Understanding the new SPOC interface Roles and responsibilities Maximum benefit from the new Touchpaper Portal Transparency will maximize the value of using the Touchpaper system for ICS staff. contributing to organisational learning Improving quality of services Ease of interface. contributing to organisational learning Improving quality of service Better understanding – better service Sharing of knowledge. ICS and S-E ICS-A ICS-LM Page 26 . Service catalogue FAQs Other A Other A ITSM U 12 Documentation Other A ITSM U 12 14 15 16 Effective web access (PC mobile and others) Service Catalogue – Focus on External but develop for ICS Communications plan Clear program to switch from Helpline to Touchpaper – risks. how and knowledgebase S–E S–E Visibility of Services and what they deliver Better understanding – better service Sharing of knowledge. A balance will need to be struck between involving staff enough to make sure they have the information and understanding they need to enable and empower them to do their job and to make efficient use of staff time.Project Initiation Document Phase 1 IT Service Management System – 10 11 a similar role as analysts.

Management information can also be produced.Project Initiation Document Phase 1 IT Service Management System – 17 Training (Timely and properly focused) ICS – LM ICS – A 18 Quick Hit ICS – processes / ITSM workflow (Service Requests) Early visibility for ICS and Users ICS – A U There is an appreciation that this implementation should involve all staff and the commitment to making key resources across the department available is a critical success factor. Good training will allow staff to pick up the new system very quickly and reduce the overhead of learning the new system while still trying to run operations as normal. morale. of procedures offering repeatability and consistency. With automatic closure this will help to ensure quality of IT service delivery/customer care. Show the value of the services to staff. Management information will be used for planning (ITIL service Delivery as well as support processes) and reporting on service performance. Automatic assignment of Service Requests therefore allowing more time for second level analysts to deal with the request. better perceived service. Documentation / knowledge available for better team working (resilience. How do we handle externals? Will allow standardisation. Requests dealt with more quickly. reducing single points of failure). Show the value of the services to users and how they are Page 27 19 Define Management Info and Reporting needs ITSM ICS – A U . Better reporting and visibility of the amount of work done by analysts.

To enable quick reporting of faults or requesting access to services Know that something is being done Know what to expect Know that incidents have been dealt with Indication that incidents cannot be resolved immediately and requires further work – user can review workaround Users feel engaged – service – continuous improvement – input Know what services IT offer Value for money – directing resources Understanding value added by IT and to assist decisionmaking for spending.4.Major Incident Review – Example of response to a major incident: <insert title of incident> Summary: • Mostly ITIL Service Support disciplines that were involved in responding to the major incident • The response was managed well and served as a good learning opportunity • A full review would inform the Service Development Programme Page 28 . Providing feedback to users increases perception of Customer Care.Project Initiation Document Phase 1 IT Service Management System – 20 21 22 Define Initial ICS CMDB ITSM Clear methods for U reporting incidents Ability to track reported incidents / requests online Consistency of response to incidents reported Confirmation of resolution and agree closure Information if incident is difficult to resolve – if escalated to problem Feedback – opportunity to feedback to users on service Service portfolio Better information and analysis to support decisionmaking Visibility of services provided U performing against published targets. Support all of the ITSM processes. 23 24 25 U U U 26 U 27 28 U C 29 C 2.

Incident Management Service Level Management Problem management Change management Configuration Management Change Management Capacity Management Financial Management Policies Page 29 . A policy on Email would have helped.Project Initiation Document Phase 1 IT Service Management System – • Feedback on the management of the Major Incident and underlying Problem should be made to ICS staff in ITIL terms to demonstrate the extent to which we are already using ITIL Users initiated incident Report from infrastructure monitoring to IT Service Management team that a major incident was about to occur Interface with users – logging new instances and reporting updates Interface with customer groups (department heads etc) to communicate progress No workaround available Identify service breaches? Problem team set up with technical team No root cause identified – focus of group was to identify root cause Elimination of potential root cause variables dealt with by Change Management function Useful for Root Cause Analysis (identifying relationships between infrastructure components) Processing RFC that would potentially fix the problems Forward schedule of changes – would the problem impact on any other planned changes Problem may be related to Capacity issue – Capacity Management should use the information produced by the teams to help with longer term planning. The RFC involved a Financial commitment therefore Financial Management was involved.