Your SlideShare is downloading. ×
Project Initiation Document
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Project Initiation Document

2,317
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,317
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
143
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Information & Communication Services PROJECT INITIATION DOCUMENT Based on PRINCE2 IT Service Management System – Phase 1 Release: Final Date: 15 January 2007 Author: Susan Hall Owner: Tom Mortimer Client: I.C.S. Document Number: ITSMSP1/PID/0611/01/V14.0 Document History Document Location - The source of this document is on the University network in location: Revision History Revision Previous Summary of Changes Changes date revision marked date First issue Distribution - This document has been distributed to: Name Title Date of Version Issue ICS-Management Team 5th 5 January 2007 ITIL Process Owners 5th 5 January 2007 Service Development Programme Board 15th 11 January 2007 Approvals - This document requires the following approvals (signed approval forms are filed in the Management section of the project file): Name Signature Title Date of Version Issue /home/pptfactory/temp/20100525090449/project-initiation-document1705.doc Printed 25/05/2010
  • 2. Project Initiation Document IT Service Management System – Phase 1 1. Project Initiation Document............................................................................................................4 1.1. Purpose of Document.............................................................................................................4 1.2. Background..............................................................................................................................4 1.2.1. Service Development Programme....................................................................................4 1.2.2. ITIL Roadmap..................................................................................................................4 1.3. Introduction to Service Desk and Incident Management – Where do we want to be?............5 Service Desk...........................................................................................................................5 Ist line Support........................................................................................................................6 Standard Incident Management Process.................................................................................6 Service Requests.....................................................................................................................6 Service Level Management....................................................................................................7 Software tools.........................................................................................................................7 1.4. Current Status – Where are we now?......................................................................................8 1.4.1. Service Desk.....................................................................................................................8 1.4.2. Ist Line Support................................................................................................................8 1.4.3. Standard Incident Management Process ..........................................................................8 1.4.4. Service Requests...............................................................................................................9 1.4.5. Service Level Management..............................................................................................9 1.4.6. Software tools...................................................................................................................9 1.5. Project deliverables................................................................................................................10 1.5.1. Service Desk...................................................................................................................10 1.5.2. Ist Line Support..............................................................................................................10 1.5.3. Standard Incident Management Process.........................................................................10 1.5.4. Service Requests.............................................................................................................10 1.5.5. Service Level Management............................................................................................10 1.5.6. Software tools.................................................................................................................10 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..............................................................13 1.6.5. Exclusions.......................................................................................................................13 1.6.6. Constraints......................................................................................................................14 1.6.7. Interfaces........................................................................................................................14 1.6.8. Assumptions...................................................................................................................14 1.7. Project Organisation Structure...............................................................................................14 1.8. Communications Plan ...........................................................................................................14 1.9. Project Quality Plan...............................................................................................................15 1.10. Initial Project Plan...............................................................................................................16 1.10.1. Financial Budget...........................................................................................................17 1.10.2. Staff resource requirements..........................................................................................17 1.10.3. Tolerance......................................................................................................................19 1.11. Project Controls...................................................................................................................19 1.11.1. Reporting and monitoring mechanisms........................................................................19 1.11.2. Exception process.........................................................................................................19 1.12. Initial Risk Log....................................................................................................................20 1.13. Contingency Plans...............................................................................................................20 1.14. Project Filing Structure........................................................................................................21 Page 2
  • 3. Project Initiation Document IT Service Management System – Phase 1 Attachments..........................................................................................................................21 2. Appendix A .................................................................................................................................22 2.1. Presentation – What is Service Desk and Incident Management..........................................22 2.2. Stakeholders in the IT Service Management System project................................................22 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?.....................................................................23 2.4. Major Incident Review – Example of response to a major incident: <insert title of incident> ......................................................................................................................................................27 Page 3
  • 4. 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 UK’s 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 be referred to as the process improvement model. Page 4
  • 5. Project Initiation Document IT Service Management System – Phase 1 Vision and Where do we want ICS Unit 3 business to be? objectives Where are we Assessments now? How do we get to Improvement and where we want to re-engineering be? How do we know Metrics and we have arrived? Measurements 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 improvement1. 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 2. 2-way communications including information to users on status 1 Notes from this workshop can be found in Appendix A. Page 5
  • 6. Project Initiation Document IT Service Management System – Phase 1 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 department which 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 process 9. 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 IT department 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 21. Standard procedures for making changes means that operational tasks can be shared easily thus reducing risk associated with single point of failure Page 6
  • 7. Project Initiation Document IT Service Management System – Phase 1 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 they don’t 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 which can 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 Requests 33. Allow evidence based management decisions using information that is timely and give confidence to decision making by having accurate data Page 7
  • 8. 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 via Communications 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 don’t 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 1 Level knowledge and problem solving skills are good and many Incidents are solved at 1st level, st however there is room for improvement. 7. In the IT Suites many Incidents are solved at first contact, however the Helpdesk operates as a call 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 / individuals 18. Users don’t always know when work has been carried out on their request for help Page 8
  • 9. 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 the user), 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. 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 processes 13. 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 1.5.6.Software tools 28. Web Portal Page 10
  • 11. Project Initiation Document IT Service Management System – Phase 1 29. Basic CMDB database as defined by Configuration Manager 30. Automatic escalation 31. 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. 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 Define Measure Analyse Improve Control Report Page 12
  • 13. 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) • Implement changes using an operations checklist o Policies o Procedures o Roles o Responsibilities o Training o Technology (checklist of Touchpaper components that have configuration requirements) o Documentation 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. Page 13
  • 14. Project Initiation Document IT Service Management System – Phase 1 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. Project board (Project Manager) Senior Supplier Senior User Project team Tom Mortimer (Sponsor) Emily Patterson (Service Desk and Incident Manager) Susan Hall (Project Manager) Damien Mcguiness (Problem Manager) Business analyst Database/portal designer Unit heads + Unit representatives (from each ICS unit to provide 2-way channel for communication) ICS Unit 1 ICS Unit 2 ICS Unit 3 1.8.Communications Plan Page 14
  • 15. 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 • via Incident Manager (comprising support • regular meetings staff – to be • email established) • workshops Problem manager • Project team meeting Problem team • via Problem Manager (comprising support • regular meetings staff – to be • email established) Department support • via Incident Manager staff • regular meetings • email • workshops User community • via Service Desk • (guidance on mechanism to be advised by the Project Board) Other Service • Via Service Development Programme meetings Management initiatives – e.g. ITSCM project 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 the appropriate 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 15
  • 16. 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 16
  • 17. Project Initiation Document IT Service Management System – Phase 1 1.10.1.Financial Budget Item Cost Date required Training Core Touchpaper training Possible additional cost – to be Additional Modules identified as required Additional staff resources 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 Notes required for duration of project Tom Mortimer Leadership and direction: 0.2 IT Service Management leadership Process: ITIL Incident Management Emily Patterson 0.3 Leading work packages (Manager level) and writing documentation ITIL Incident Management (Line Unit Heads 0.4 Approx 2 hours every 2 Manager level) weeks for every UH to be involved in project meetings Problem Manager Damien Mcguiness 0.2 Interface between incident management and problem management ITIL Incident Management Specialists 0.3 Approx 1 hour a week for (Analyst level) a representative from each unit to be involved in the project. Page 17
  • 18. Project Initiation Document IT Service Management System – Phase 1 General ITIL Susan Hall 0.3 Service Level Management Dave Murie 0.2 Leading Service Level management component of SD&IM Configuration Management Chris Reid 0.2 Leading Configuration Management component of SD&IM Service Desk: ITIL Service Desk Emily Patterson 0.1 Leading Service Desk component Service Desk staff To be allocated 0.2 Documentation e.g operations manuals, templates etc. Communications Julie Christie 0.2 Advising on project communications as well as products with communications element e.g. Service Desk Database: Administration 1 Emily Patterson 0.2 Shoadowing of Touchpaper consultant during setup and configuration of the system Adminstration 2 To be allocated 0.2 Data Input / design / reports etc. Data Input (workflow) Brian Yeomans 0.3 Service Portal and Client design Brian Yeomans 0.3 Business analysis/project management: PRINCE2 and MS Project Susan Hall 0.2 Data analysis and statistics Susan Hall / Ann 0.05 Muir Process mapping and analysis “ 0.2 Workshop facilitation “ 0.4 Technical integration and support: Page 18
  • 19. Project Initiation Document IT Service Management System – Phase 1 Window Server Tobi Wood 0.1 Solaris Brian Russell 0.1 Oracle Database Stephen Jones 0.1 eDirectory Kevin Shrimpton 0.1 Email Mary Shrimpton 0.1 Network (including Security) Simon Bennet 0.05 Windows Workstation Mark Stephenson 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 programme board 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 1.11.2.Exception process Exceptions to be approved by Service Development Programme Board / NIPB Page 19
  • 20. Project Initiation Document IT Service Management System – Phase 1 1.12.Initial Risk Log Item Risk category Probability Impact Owner (Time, quality, benefit, resources) Internal resources Organisational / High High – T, Q, B, R ICS management / Management human team External resources – Technology Med High – T, R ICS server hardware Management External resources – Partner Low High – T, B, R Project Touchpaper management consultant availability Lack of integration Organisational / Med High – Q, B ICS Executive with other processes – management / implementation in human isolation Possible lack of Organisational / Med High – T, Q, B ICS mgmt visible management or management / staff commitment human Software tools Technical / Low Med – T, Q, B, R ICS Executive unsuitable for solution operational / infrastructure Poorly defined service Organisational / Med High – T, Q, B ICS mgmt objectives or goals management / human Lack of clarity about Organisational / Med High – T, Q, B ICS Executive business needs management / human Lack of representative Organisational / Med High – T, Q, B, R Senior User user commitment to management / define requirements human Resistance to change Organisational / Med High – T, Q, B, R ICS mgmt management / human 1.13.Contingency Plans Plan based on risks outlined in risk log Item Probability Contingency plan Cost Internal resources – High Monitor resource usage and quality and quantity performance against estimates on a weekly basis to avoid suprises. External resources – Med Careful planning server hardware External resources – Low Training for internal staff Touchpaper Page 20
  • 21. Project Initiation Document IT Service Management System – Phase 1 consultant availability Lack of integration Med Ensure that all relevant process with other processes – owners are involved implementation in isolation Possible lack of Med Regular and frequent visible management or communications staff commitment Software tools Low Touchpaper consultancy can help unsuitable for solution reduce chance of this happening by helping with decision making on design and responding to enhancement requests Poorly defined service Med Involve ICS management team in objectives or goals planning, design and decision making Lack of clarity about Med Involve ICS management team in business needs planning, design and decision making Lack of representative Med Employ all available mechanisms user commitment to to communicate with users. define requirements Where necessary use existing mechanisms 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 21
  • 22. 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 Terminology Measures Changes Service requests Agree pre-approved changed Predefined Service Objectives/Operational Level Defined levels of service Agreements Initial response Tracking Management info Meanigful Timely Accurate Review Incident Management <diagram to be inserted> 2.2.Stakeholders in the IT Service Management System project Group Abbrev. Examples Mechanism of representation End-users U Students Page 22
  • 23. Project Initiation Document IT Service Management System – Phase 1 Members of staff LISC Other Customer C University Vice Principal/Deans Suppliers S–I Internal – e.g. Estates & ? Buildings, Purchasing Office S–E External ? ICS – ICS-LM Line Managers ? Central IT Provider ITSM IT Service Management – ? process owners ICS-A Operational staff (support and development analysts) ? All staff Other IT Other-A Analysts based in University ? Providers 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 S We expect suppliers to be able mechanism to give us an update on progress of products they are providing to us. Once these products are delivered they should be traceable within our system so that we can let ITSM 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 and Problem Management, asset management (Financial management) and account Page 23
  • 24. Project Initiation Document IT Service Management System – Phase 1 management (Service Level Management). 2 Tracking and Other A To fulfil their service transparency of objectives incidents 3 Prioritisation to Other A Timely incident resolution agreed service Realistic Expectations levels 4 Communications Other A Updates allows planning. including Makes other analysts feel part proactive updates of the overall service of status of provision for the University Incidents rather than being out on a limb. 5 Automatic logging Other A Knowledge of what is of alerts from happening so that they can be infrastructure pre-warned of possible monitoring ITSM breaches to service. Awareness of issues will allow Other A to offer assistance where they have expertise. 6 Efficient, Other A Should be convenient and accessible routes have multiple routes e.g. to logging phone, web etc incidents. 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 Other A Value for money. resolved – fast, Reduce pressure on IT support effectively and staff. closed. 8 Participation e.g. Other A Calls only closed when agreed in closing calls = clarity Sometimes the ICS analyst has misunderstood the call so closer communication with the user would be better. Sometimes users don’t know that the call has been closed. 9 Department IT Other A Support staff have a similar role as analysts. 10 Service catalogue Other A Visibility of Services and Page 24
  • 25. Project Initiation Document IT Service Management System – Phase 1 what they deliver 11 FAQs Other A Better understanding – better ITSM service Sharing of knowledge, U contributing to organisational learning Improving quality of service 12 Documentation Other A Better understanding – better ITSM service Sharing of knowledge, U contributing to organisational learning Improving quality of services 12 Effective web S–E Ease of interface, accessibility access (PC mobile and others) 14 Service Catalogue S–E Clarity about services – Focus on Simple start then develop External but develop for ICS 15 Communications ICS and Clarity of purpose plan S-E Approach that will be used Changes/impact 16 Clear program to ICS-A Key for ICS switch from ICS-LM This will help staff to plan for Helpline to the changes with respect to: Touchpaper – Training in using Touchpaper risks, how and Training in using the new knowledgebase procedures for IM Understanding the new SPOC interface Roles and responsibilities Maximum benefit from the new Touchpaper Portal Transparency will maximize the value of using the Touchpaper system for ICS staff. 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. There is an appreciation that this implementation should involve all staff and the commitment to making key Page 25
  • 26. Project Initiation Document IT Service Management System – Phase 1 resources across the department available is a critical success factor. 17 Training (Timely ICS – Good training will allow staff and properly LM to pick up the new system focused) ICS – A 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 Hit ICS – Will allow standardisation, of processes / ITSM procedures offering workflow repeatability and consistency. (Service Requests) Management information can Early visibility for also be produced. ICS and Users With automatic closure this ICS – A will help to ensure quality of IT service delivery/customer care. Documentation / knowledge available for better team working (resilience, reducing single points of failure). Better reporting and visibility U 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 perceived service. 19 Define ITSM Management information will Management Info be used for planning (ITIL and Reporting service Delivery as well as needs support processes) and ICS – A reporting on service U performance. Show the value of the services to staff, morale. Show the value of the services to users and how they are performing against published targets. Providing feedback to users increases perception of Customer Care. Page 26
  • 27. Project Initiation Document IT Service Management System – Phase 1 20 Define Initial ICS - Support all of the ITSM CMDB ITSM processes. 21 Clear methods for U To enable quick reporting of reporting incidents faults or requesting access to services 22 Ability to track U Know that something is being reported done incidents / requests online 23 Consistency of U Know what to expect response to incidents reported 24 Confirmation of U Know that incidents have been resolution and dealt with agree closure 25 Information if U Indication that incidents incident is cannot be resolved difficult to resolve immediately and requires – if escalated to further work – user can review problem workaround 26 Feedback – U Users feel engaged – service – opportunity to continuous improvement – feedback to users input on service 27 Service portfolio U Know what services IT offer 28 Better information C Value for money – directing and analysis to resources support decision- making 29 Visibility of C Understanding value added by services provided IT and to assist decision- making for spending. 2.4.Major Incident Review – Example of response to a major incident: <insert title of incident> Summary: • Mostly ITIL Service Support disciplines that were involved in responding to the major incident • The response was managed well and served as a good learning opportunity • A full review would inform the Service Development Programme • 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 Page 27
  • 28. Project Initiation Document IT Service Management System – Phase 1 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 fix the 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. Page 28

×