project-initiation-document1705.doc

7/30/2019 project-initiation-document1705.doc

1/29

Information & Communication Services

PROJECT INITIATION DOCUMENT

Based on PRINCE2

IT Service Management System Phase 1

Release: FinalDate: 15 January 2007

Author: Susan HallOwner: Tom MortimerClient: I.C.S.

DocumentNumber:

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

Revisiondate

Previousrevisiondate

Summary of Changes Changesmarked

First issue

Distribution - This document has been distributed to:

Name Title DateofIssue

Version

ICS-Management Team 5thJanuary2007

5

ITIL Process Owners 5thJanuary2007

5

Service Development Programme Board 15thJanuary2007

11

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

/var/www/apps/conversion/tmp/scratch_6/167324325.doc Printed 26/08/2013


2/29

Project Initiation Document IT Service Management System Phase 1

Name Signature Title DateofIssue

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....................................................................................................7Software 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.......................................................................................................................141.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...................................................................................................................201.11.1. Reporting and monitoring mechanisms........................................................................20

Page 2


3/29


1.11.2. Exception process.........................................................................................................21

1.12. Initial Risk Log....................................................................................................................21

1.13. Contingency Plans...............................................................................................................21

1.14. Project Filing Structure........................................................................................................22

Attachments..........................................................................................................................222. Appendix A .................................................................................................................................23

2.1. Presentation What is Service Desk and Incident Management..........................................23

2.2. Stakeholders in the IT Service Management System project................................................23

2.3. What would each stakeholder group like to see delivered by the first phase of the project?

What are the benefits of delivering these products?.....................................................................24

2.4. Major Incident Review Example of response to a major incident:

......................................................................................................................................................28

Page 3


4/29


1. Project Initiation Document

1.1. Purpose of Document

The purpose of this document is to define the project, to form the basis for its management and the

assessment of overall success.

1.2.Background

1.2.1. Service Development Programme

The University of Dundee is one of the UKs leading universities, internationally recognised for its

expertise across a range of disciplines including science, medicine, engineering and art. In 2007,the University will celebrate 40 years since it became an independent university after a 70 year

relationship with the University of St. Andrews. The University has seen some major changes in

that time. The past decade has been a particularly exciting time of progression and change - since

1994 the University has more than doubled in size. 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. Current internal processes and technology are not

enabling ICT to provide support for these services in the most effective and efficient way. The

Service Development Programme aims to provide a process oriented solution, which will provide

the foundation for a more integrated approach to IT Service Management using the IT

Infrastructure Library (ITIL).

1.2.2. ITIL Roadmap

Software tools are fundamental to the management of IT Services and a suite of tools, Touchpaper

IT Business Management, has been purchased to support the adoption of ITIL. Touchpaper will

act as the central software tool, linking with all the other tools for managing infrastructure and

applications. The order of the ITIL process implementation will be closely aligned to the

associated dependencies of the Touchpaper software modules.

Touchpaper will lead the transition to ITIL Best Practice starting with the implementation of the

core modules, Service Desk and Incident Management.

In any transition programme there are a number of standard questions to answer and this will bereferred to as the process improvement model.

Page 4


5/29


Figure 1: Process Improvement Model

1.3.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 improvement 1.

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, which

will provide the Vision for the project.

Service Desk

The goal of the Service Desk in ITIL Best Practice terms, is to act as a central point of contact

between the User and IT Service Management. The Service Desk is a function that should handle

all Incidents and requests and provide an interface for other activities such as Change, Problem,

Configuration, Release, Service Level and IT Service Continuity Management. By having a

Service desk, an organisation can realise the following benefits:

1. Consistent interface for users to contact IT; consistency of service enables quality

1 Notes from this workshop can be found in Appendix A.

Page 5


6/29


2. 2-way communications including information to users on status

3. Assurance that all queries are captured and recorded in the correct manner by trained staff

4. Fair and appropriate prioritisation by eliminating the By the back door route

5. The service provider and the user know what to expect by having consistent procedures

6. A software tool can be used to manage the relationship between Users and the IT departmentwhich can enhance the service by adding Self-Service for logging and tracking Incidents and

Service Requests.

Ist line Support

ITIL Best Practice recommends that an organisation should decide on the level of technical

expertise delivered by 1st line support. A technical/expert level Service Desk can add value to the

organisation by giving the following benefits:

7. Solve a high proportion of Incidents at first line thereby reducing impact of Incident on User

and increasing User perceptions of support

8. Reduce pressure on 2nd line support and provide high quality information into the Incident

Management process9. Provide information to other Service Management Processes by managing a feedback

mechanism

10. Lead the operation and ongoing development of the Incident Management Process

11. 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, thus ensuring that the best achievable levels of

availability and service are maintained. A standard process for managing incidents is essential and

delivers:

12. Clear expectations on what support offers and agreement between the User and the ITdepartment

13. Clarity and transparency of the support mechanism, giving confidence to the User

14. Opportunity to train staff in the standard procedures

15. A common language to allow better communication and understanding

16. A controlled process can be measured, this enables reporting

17. A documented and standard process can be changed, so if there are improvements to be made

to the process this can be done easily

18. User approves call closure

Service Requests

A Service Request is a type of Request For Change, usually both common and straightforward, to

be made for a Service. A Service Request is characterised by the fact that the Change can be made

under strict, well-defined procedural control and is therefore (virtually) risk free. Providing access

to Services for a new member of staff and relocating PCs are two typical examples. A Service

Request does not normally result in a change to the definition of the Service. Other Requests for

Change can mean a change in the definition of the service, therefore require development and

approval under the Change Management Process. By defining Service Requests value is added to

the organisation in the following ways:

19. Stakeholders are able to agree changes in advance which improves clarity and efficiency

20. Service Requests are predefined and linked to User recognised services which makes the

services more accessible to users

Page 6


7/29


21. Standard procedures for making changes means that operational tasks can be shared easily thus

reducing risk associated with single point of failure

22. Controlled procedures can be reported on, helping IT to develop an clear picture of which

services are used most and when


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. SLAs are underpinned by Operational Level Agreements. SLM gives the following

benefits:

23. Users know what to expect and support staff know what they are trying to deliver by having

defined levels of service. This can reduce pressure on support staff to achieve unrealistic

targets, and allow performance to be measured so that realistic targets can be set.

24. Initial response times can be set, giving Users more information about when they will hear

from support

25. Support tools can be configured to automatically track the progress of Incidents so that theydont get forgotten about

26. The support department can demonstrate the value it adds to Users by reporting on the

performances of services and support

27. There is an established interface with customer representatives which acts as a communication

channel.

Software tools

The Service Desk, supported by a software tool, produces reports on Service Support and Service

Delivery. The information can be used for management (i.e. for planning and operating services

through the ITIL processes) and for reporting on the performance of the services to Users and

Customers. By using a database, information can be linked to show complex relationships whichcan be used by all ITIL processes. By producing reports the Service Desk can add value in the

following ways:

28. Enhancing the interface between Users and the IT department by providing a web Self-Service

mechanism for logging and tracking Incidents and Service Requests.

29. Providing the basis for a Configuration Management Database (CMDB)

30. Provide automated escalation for Incidents

31. Make meaningful information available to all stakeholders for example to allow reviews of

service support and delivery to support continuous improvement

32. Promoting targeted organisational learning (User and Analyst) and extending the User learning

experience by providing Knowledge linked to common Incidents and Service Requests33. Allow evidence based management decisions using information that is timely and give

confidence to decision making by having accurate data

Page 7


8/29


1.4.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, this section describes how ICS is performing at the

moment for each area.

1.4.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). It

is difficult to manage the function to deliver the benefits offered by a Best Practice Service Desk.

1. The interface for users to contact IT is distributed (central Helpdesk, IT Suite Helpdesks

staffed by postgraduate students, other ICS staff); it is therefore difficult to deliver consistency

of service and to ensure quality

2. Service Desk is mainly reactive, with some communications going out to user community viaCommunications Office

3. Some queries are not captured and recorded in the correct manner by trained staff

4. Prioritisation of Incidents is unclear and undocumented

5. Procedures are not consistent so Users dont know what to expect

6. The software tool does not offer Self-Service for logging and tracking Incidents and Service

Requests.

1.4.2. Ist Line Support

1st Level knowledge and problem solving skills are good and many Incidents are solved at 1st level,

however there is room for improvement.

7. In the IT Suites many Incidents are solved at first contact, however the Helpdesk operates as acall logging function for many other support calls.

8. The correct information is not always collected from the User at first point of contact. This

could be due to lack of knowledge or lack of time.

9. The Service Desk does not have a published feedback mechanism

10. Incident Management is handled in a disparate way, with different Units / teams / individuals

adhering to different procedures

11. Reference solutions are updated regularly, although this is solely for use within the Helpdesk

and is updated by the Helpdesk without guaranteed input by Analysts

1.4.3. Standard Incident Management Process

There is no standard Incident Management process for ICS.

12. Support analysts and users are unclear about what is expected from the support process. There

is no published statement to describe support

13. Users are not sure what to expect from support i.e. 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. A common language is emerging through the uptake of ITIL

16. There is some measurement of Incident Management processes (e.g. S3 service)

17. 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 /

individuals18. Users dont always know when work has been carried out on their request for help

Page 8


9/29


1.4.4. Service Requests

There is no formal management of all Service Requests within ICS.

19. Some of the standard changes have one or more of the characteristics of a Service Request

(defined request mechanism (online form), standard workflow and closure/approval with theuser), however this is a small proportion of those on offer. It is possible to request some

Service Requests via a printed or online form available from ICS Reception / Helpdesk or

Website. The interface for these is not consistent and does not currently link with services.

20. There is no formal change management procedure for Service Requests including consultation

with all stakeholders

21. No formal workflow exists however some procedures are standardised.

22. There is currently no reporting on Service Requests.

1.4.5. Service Level Management

The Service Level Management function has been established. The Service Level Manager has

setup a mechanism for communicating with Customers through ICS Liaison.23. Levels of service are not currently defined for the User or Support Analysts

24. Stakeholders are unclear about the response times required and how to prioritise.

25. Current Support tools do not offer automated escalation according to defined Service Levels

26. There is currently no reporting to stakeholders on performance of services.

27. ICS liaison acts as a channel for communications.

1.4.6. Software tools

The current support tools (Helpline and others) do not offer a full range of features to support

ITSM. Several tools are in use and these do not offer integration between different components of

the infrastructure and ITSM processes. The support tools are not used by all Support Analysts to

manage all support calls.28. Helpline does not offer functionality for Users to manage their own Incidents via the web.

29. There is no CMDB

30. Helpline does not offer automated escalation

31. There is limited reporting functionality within Helpline.

32. There is no Knowledge Base within Helpline

33. Not all Incidents are recorded in Helpline therefore the tool cannot be used to provide accurate

reports.

Page 9


10/29


1.5.Project deliverables

In broad terms the project vision is to improve the Service Desk function and Incident

Management process within the University. Section 1.3 described this in detail with reference to

ITIL, and Section 1.4 illustrated how well IT Service Delivery and Support are performing at the

current time. This section lists the deliverables required from the project.

1.5.1. Service Desk

1. Single Point of Contact for all IT queries

2. Communications to be sent out by the Service Desk on status of IT services

3. Service Desk Staff trained in all procedures for Incident Management

4. Clear guidance on prioritising Incidents, documented and published to the User community

5. Consistent and audited procedures, owned by the Incident Manager

6. Self-Service Portal

1.5.2. Ist Line Support

7. Increased level of technical awareness for Incident Management Analysts (procedures manual,

training etc)

8. Templates and scripts for standard requests

9. Feedback mechanism available via the Service Desk

10. Centrally managed procedures for all Incident handling

11. Knowledge management

1.5.3. Standard Incident Management Process

12. Service / Support Charter describing the aims of the support processes13. Defined response times (target times initially)

14. Procedures manual and training

15. Commitment to ITIL terminology

16. Regular reports based on stakeholder requirements

17. Clear ownership of the Incident Management process and mechanism for requesting changes

18. Two stage closure with User

1.5.4. Service Requests

19. Service Requests managed and owned by the Service Desk and all Service Requests should be

made available to Users in the same way.

20. Standard template and approval mechanism for all Service Requests

21. Workflow and standard procedures for all Service Requests.

22. Regular reporting on Service Requests

1.5.5. Service Level Management

23. Defined Service Objectives

24. Defined response times

25. Automated escalation for Incidents and Service Requests

26. Service Level Management reporting.

27. The ICS Liaison Interface will be supported by the Service Management tool

Page 10


11/29


1.5.6. Software tools

28. Web Portal

29. Basic CMDB database as defined by Configuration Manager

30. Automatic escalation31. Standard set of reports available on a regular basis according to requirements.

32. Knowledge Base

33. All Incidents recorded in the Service desk tool.

Page 11


12/29


1.6.Project Definition

1.6.1. Project Objectives

O1. Develop and implement a Service Desk and Incident Management solution for ICS based on

the ITIL framework

O2. Establish metrics by which the Service Desk function can be measured and evaluated

O3. Publicise the solution within the University user community

O4. Improve overall user satisfaction with support as measured by user perception surveys or

other appropriate methods

1.6.2. Project Scope

University of Dundee, Information & Communication Services

Service Management - ITIL processes for Service Desk and Incident Management

1.6.3. Method of Approach

A standard improvement model will be used to develop each key deliverable to ensure quality.

The model will incorporate the current state and ITIL Best Practice into the solution design. In

doing so this will make best use of current good practice within ICS. The design process will

include consultation of stakeholders using a variety of mechanisms where appropriate e.g.

workshops and circulation of documents for comment.

Final approval will be made by the ICS Management Team.

Improvement model

Page 12


13/29


A template will be used to direct each improvement exercise for ease and consistency and this will

incorporate the following headings:

Heading Content

Define What we want to get out of the component (guided by ITIL

Best Practice) e.g. Service Desk to be a single point of

contact.

Scope and stakeholders

KPIs key performance indicators how do we measure how

well this component is performing?

Measure Decide what measurements should be used to illustrate

performance

Carry out the measurements Present the measurements

Analyse Assess the process capability

Determine potential influence factors propose hypotheses

Test hypotheses

Design improvements

Produce business case

Implement improvements

Improve Test the effect of implementing changes

Optimise improvements (review results of testing)

Produce report describing the business case (including cost

benefit analysis)

Page 13


14/29


Implement changes using an operations checklist

o Policies

o Procedures

o

Roleso Responsibilities

o Training

o Technology (checklist of Touchpaper components that

have configuration requirements)

o Documentation

Control Establish continuous improvement mechanisms

Report Establish method of reporting

1.6.4. Project Deliverables and/or Desired Outcomes

See project deliverables Section 1.5

1.6.5. Exclusions

Dependencies under the management of ITIL disciplines which are yet to be established within

ICS. 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.

1.6.6. Constraints

This project will require staff resources from each Unit in ICS, particularly in the Service Desk

area. The quantity and quality of commitment could limit what the project will be able to achieve

in the time allowed.

1.6.7. Interfaces

The project interfaces are described in the Project Organisation Structure and Communication plan

sections of this document.

1.6.8. Assumptions

Resources will be available when required through prior negotiation with line managers.

1.7.Project Organisation Structure

The organisation structure describes how staff working on the project will relate to each other.

Page 14


15/29


1.8.Communications Plan

Page 15


16/29


The communication plan defines the mechanism and frequency for all project communications.

Interested parties Communication mechanism and frequency

Incident Manager Project team meeting

Incident team

(comprising support

staff to be

established)

via Incident Manager

regular meetings

email

workshops

Problem manager Project team meeting

Problem team

(comprising support

staff to be

established)

via Problem Manager

regular meetings email

Department support

staff via Incident Manager

regular meetings

email

workshops

User community via Service Desk

(guidance on mechanism to be advised by the Project Board)

Other Service

Management

initiatives e.g.

ITSCM project

Via Service Development Programme meetings

1.9.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 theappropriate times recognising any dependencies between processes.

Produce a high quality implementation that covers all of the deliverables set out in the PID

to the required quality standard.

Ensure that all stakeholders (especially ICS staff and Users) are aware of the changes and

how they will impact them. Communicate the benefits to stakeholders to ensure that they

are on-board with the implementation.

Use resources effectively by providing the correct information and training to people

involved in the project to enable them to give input.

Manage risks to the project as efficiently as possible.

Page 16


17/29


1.10. 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. The Work Packages will be: Service Desk

1st Line Support

Standard Incident Management process

Service Requests


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.

Tasks:

Page 17


18/29


1.10.1. Financial Budget

Item Cost Date required

Training

Core Touchpaper training

Additional Modules

Additional staff resources

Possible additional cost to be

identified as required

Possible additional cost to be

identified as required

1.10.2. 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.

Staff skills Person identified FTE

required

for

duration

of project

Notes

Leadership and direction:IT Service Management

leadership

Tom Mortimer

0.2

Process:

ITIL Incident Management

(Manager level)

ITIL Incident Management (Line

Manager level)

Problem Manager

ITIL Incident Management(Analyst level)

Emily Patterson

Unit Heads

Damien Mcguiness

Specialists

0.3

0.4

0.2

0.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 fora representative from

Page 18


19/29


General ITIL


Configuration Management

Service Desk:

ITIL Service Desk

Service Desk staff

Communications

Susan Hall

Dave Murie

Chris Reid

Emily Patterson

To be allocated

Julie Christie

0.3

0.2

0.2

0.1

0.2

0.2

each unit to be involved

in the project.

Leading Service Level

management component

of SD&IM

Leading Configuration

Management component

of SD&IM

Leading Service Desk

component

Documentation e.g

operations manuals,

templates etc.

Advising on project

communications as well

as products with

communications element

e.g. Service Desk

Database:

Administration 1

Adminstration 2

Data Input (workflow)

Service Portal and Client design

Emily Patterson

To be allocated

Brian Yeomans

Brian Yeomans

0.2

0.2

0.3

0.3

Shoadowing of

Touchpaper consultant

during setup and

configuration of the

system

Data Input / design /

reports etc.

Business analysis/project

management:

PRINCE2 and MS Project

Data analysis and statistics

Process mapping and analysis

Workshop facilitation

Susan Hall

Susan Hall / Ann

Muir

0.2

0.05

0.2

0.4

Page 19


20/29


Technical integration and

support:

Window Server

Solaris

Oracle DatabaseeDirectory

Email

Network (including Security)

Windows Workstation

Tobi Wood

Brian Russell

Stephen JonesKevin Shrimpton

Mary Shrimpton

Simon Bennet

Mark Stephenson

0.1

0.1

0.10.1

0.1

0.05

0.1

1.10.3. 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 programmeboard must approve the exception.

o Cost if the projected costs vary by more than 1000, the programme board must approve

the exception.

o Resources if the resource required varies by more than 0.5 FTE, the programme board

must approve the exception.

o Business Case the business case must not be changed without approval by the

programme board.

1.11. Project Controls

The project will be managed using PRINCE2, 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.11.1. Reporting and monitoring mechanisms

Project reports will be made to the ICS Service Development Programme Board and Network

improvement Programme Board. Reporting will be done using the standard written report

template.

NIPB reporting SDPB reporting

19 Jan 16 Jan

16 Feb 13 Feb

16 Mar 13 Mar

13 Apr 10 Apr

18 May 15 May

15 June 12 June

13 July 10 July

Page 20


21/29


1.11.2. Exception process

Exceptions to be approved by Service Development Programme Board / NIPB

1.12. Initial Risk Log

Item Risk category Probability Impact

(Time, quality,

benefit, resources)

Owner

Internal resources Organisational /

management /

human

High High T, Q, B, R ICS

Management

team

External resources

server hardware

Technology Med High T, R ICS

Management

External resources

Touchpaperconsultant availability

Partner Low High T, B, R Project

management

Lack of integration

with other processes

implementation in

isolation

Organisational /

management /

human

Med High Q, B ICS Executive

Possible lack of

visible management or

staff commitment

Organisational /

management /

human

Med High T, Q, B ICS mgmt

Software tools

unsuitable for solution

Technical /

operational /

infrastructure

Low Med T, Q, B, R ICS Executive

Poorly defined service

objectives or goals

Organisational /

management /

human

Med High T, Q, B ICS mgmt

Lack of clarity about

business needs

Organisational /

management /

human

Med High T, Q, B ICS Executive

Lack of representative

user commitment to

define requirements

Organisational /

management /

human

Med High T, Q, B, R Senior User

Resistance to change Organisational /management /

human

Med High T, Q, B, R ICS mgmt

1.13. Contingency Plans

Plan based on risks outlined in risk log

Item Probability Contingency plan Cost

Internal resources

quality and quantity

High Monitor resource usage and

performance against estimates on

a weekly basis to avoid suprises.

Page 21


22/29


External resources

server hardware

Med Careful planning

External resources

Touchpaper

consultant availability

Low Training for internal staff

Lack of integration

with other processes

implementation in

isolation

Med Ensure that all relevant process

owners are involved

Possible lack of

visible management or

staff commitment

Med Regular and frequent

communications

Software tools

unsuitable for solution

Low Touchpaper consultancy can help

reduce chance of this happening

by helping with decision makingon design and responding to

enhancement requests

Poorly defined service

objectives or goals

Med Involve ICS management team in

planning, design and decision

making

Lack of clarity about

business needs

Med Involve ICS management team in

planning, design and decision

making

Lack of representative

user commitment to

define requirements

Med Employ all available mechanisms

to communicate with users.

Where necessary use existingmechanisms e.g. ICS Liaison

Resistance to change Med Who Moved My Cheese

Explain benefits to stakeholders

1.14. Project Filing Structure

Project documentation will be stored under:

S:\ICS Projects\.....

Attachments

Initial Business Case described in Background section

Initial Project Plan described in Approach

Page 22


23/29


2. Appendix A

IT Service Management System project phase 1

Workshop 11th December - Notes

2.1.Presentation What is Service Desk and Incident Management

Service Desk

SPOC Consistent

Capture all

No back door

Consistent procedures

Ist line support Knowledge

Fast response

Less pressure on 2nd line support

Value

Feedback

Ownership of Incident Management

Standard process for incidents Agreement

Clarity

Training

TerminologyMeasures

Changes

Service requests Agree pre-approved changed

Predefined

Service Objectives/Operational Level

Agreements

Defined levels of service

Initial response

Tracking

Management info Meanigful

Timely

Accurate

Review

Incident Management

2.2.Stakeholders in the IT Service Management System project

Group Abbrev. Examples Mechanism of representation

Page 23


24/29


End-users U Students

Members of staff

Other

LISC

Customer C University Vice Principal/Deans

Suppliers S I

S E

Internal e.g. Estates &

Buildings, Purchasing Office

External

?

?

ICS

Central IT

Provider

ICS-LM

ITSM

ICS-A

Line Managers

IT Service Management process owners

Operational staff (support and

development analysts)

All staff

?

?

?

Other IT

Providers

Other-A Analysts based in University

departments

?

2.3.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 Goal Deliverable Group Benefit

1 Tracking

mechanism

S

ITSM

We expect suppliers to be able

to give us an update on

progress of products they are

providing to us. Once these

products are delivered theyshould 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.

There is value in being able to

trace items throughout their

lifecycle for Incident andProblem Management, asset

Page 24


25/29


management (Financial

management) and account

management (Service Level

Management).

2 Tracking and

transparency of

incidents

Other A To fulfil their service

objectives

3 Prioritisation to

agreed service

levels

Other A Timely incident resolution

Realistic Expectations

4 Communications

including

proactive updates

of status of

Incidents

Other A Updates allows planning.

Makes other analysts feel part

of the overall service

provision for the University

rather than being out on alimb.

5 Automatic logging

of alerts from

infrastructure

monitoring

Other A

ITSM

Knowledge of what is

happening so that they can be

pre-warned of possible

breaches to service.

Awareness of issues will

allow Other A to offer

assistance where they have

expertise.

6 Efficient,

accessible routesto logging

incidents.

Other A Should be convenient and

have multiple routes e.g.phone, web etc

All relevant information can

be recorded efficiently

without repetition.

Makes other analysts feel part

of the overall service

provision for the University.

7 Incidents are

resolved fast,

effectively andclosed.

Other A Value for money.

Reduce pressure on IT support

staff.

8 Participation e.g.

in closing calls

Other A Calls only closed when agreed

= clarity

Sometimes the ICS analyst

has misunderstood the call so

closer communication with

the user would be better.

Sometimes users dont know

that the call has been closed.

9 Department IT

Support staff have

Other A

Page 25


26/29


a similar role as

analysts.

10 Service catalogue Other A Visibility of Services and

what they deliver

11 FAQs Other A

ITSM

U

Better understanding better

service

Sharing of knowledge,

contributing to organisational

learning

Improving quality of service

12 Documentation Other A

ITSM

U

Better understanding better

service

Sharing of knowledge,

contributing to organisational

learningImproving quality of services

12 Effective web

access (PC mobile

and others)

S E Ease of interface, accessibility

14 Service Catalogue

Focus on

External but

develop for ICS

S E Clarity about services

Simple start then develop

15 Communications

plan

ICS and

S-E

Clarity of purpose

Approach that will be used

Changes/impact16 Clear program to

switch from

Helpline to

Touchpaper

risks, how and

knowledgebase

ICS-A

ICS-LM

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 PortalTransparency will maximize

the value of using the

Touchpaper system for ICS

staff. 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.

Page 26


27/29


There is an appreciation that

this implementation should

involve all staff and the

commitment to making key

resources across thedepartment available is a

critical success factor.

17 Training (Timely

and properly

focused)

ICS

LM

ICS A

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.

How do we handle externals?

18 Quick Hitprocesses /

workflow

(Service Requests)

Early visibility for

ICS and Users

ICS ITSM

ICS A

U

Will allow standardisation, ofprocedures offering

repeatability and consistency.

Management information can

also be produced.

With automatic closure this

will help to ensure quality of

IT service delivery/customer

care.

Documentation / knowledge

available for better team

working (resilience, reducingsingle points of failure).

Better reporting and visibility

of the amount of work done

by analysts.

Automatic assignment of

Service Requests therefore

allowing more time for second

level analysts to deal with the

request.

Requests dealt with more

quickly, better perceivedservice.

19 Define

Management Info

and Reporting

needs

ITSM

ICS A

U

Management information will

be used for planning (ITIL

service Delivery as well as

support processes) and

reporting on service

performance.

Show the value of the services

to staff, morale.

Show the value of the services

to users and how they are

Page 27


28/29


performing against published

targets. Providing feedback to

users increases perception of

Customer Care.

20 Define Initial

CMDB

ICS -

ITSM

Support all of the ITSM

processes.

21 Clear methods for

reporting incidents

U To enable quick reporting of

faults or requesting access to

services

22 Ability to track

reported

incidents /

requests online

U Know that something is being

done

23 Consistency of

response toincidents reported

U Know what to expect

24 Confirmation of

resolution and

agree closure

U Know that incidents have been

dealt with

25 Information if

incident is

difficult to resolve

if escalated to

problem

U Indication that incidents

cannot be resolved

immediately and requires

further work user can review

workaround

26 Feedback

opportunity tofeedback to users

on service

U Users feel engaged service

continuous improvement input

27 Service portfolio U Know what services IT offer

28 Better information

and analysis to

support decision-

making

C Value for money directing

resources

29 Visibility of

services provided

C Understanding value added by

IT and to assist decision-

making for spending.

2.4.Major Incident Review Example of response to a major 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


29/29


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

Incident Management 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

Service Level Management Interface with customer groups

(department heads etc) to communicate

progress

No workaround available

Identify service breaches?Problem management Problem team set up with technical team

No root cause identified focus of group

was to identify root cause

Change management Elimination of potential root cause

variables dealt with by Change

Management function

Configuration Management Useful for Root Cause Analysis

(identifying relationships between

infrastructure components)

Change Management Processing RFC that would potentially fixthe problems

Forward schedule of changes would the

problem impact on any other planned

changes

Capacity Management Problem may be related to Capacity issue

Capacity Management should use the

information produced by the teams to

help with longer term planning.

Financial Management The RFC involved a Financial

commitment therefore Financial

Management was involved.

Policies A policy on Email would have helped.

project-initiation-document1705.doc

Documents