Download - 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
-
7/30/2019 project-initiation-document1705.doc
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
-
7/30/2019 project-initiation-document1705.doc
3/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
4/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
5/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
6/29
Project Initiation Document IT Service Management System Phase 1
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/30/2019 project-initiation-document1705.doc
7/29
Project Initiation Document IT Service Management System Phase 1
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
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
-
7/30/2019 project-initiation-document1705.doc
8/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
9/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
10/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
11/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
12/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
13/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
14/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
15/29
Project Initiation Document IT Service Management System Phase 1
1.8.Communications Plan
Page 15
-
7/30/2019 project-initiation-document1705.doc
16/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
17/29
Project Initiation Document IT Service Management System Phase 1
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
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.
Tasks:
Page 17
-
7/30/2019 project-initiation-document1705.doc
18/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
19/29
Project Initiation Document IT Service Management System Phase 1
General ITIL
Service Level Management
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
-
7/30/2019 project-initiation-document1705.doc
20/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
21/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
22/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
23/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
24/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
25/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
26/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
27/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
28/29
Project Initiation Document IT Service Management System Phase 1
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
-
7/30/2019 project-initiation-document1705.doc
29/29
Project Initiation Document IT Service Management System Phase 1
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.