Project Handover to Operations Template
User Guidelines
UPMA Project Management Methodology: CP0007-01
22 March 2016
Introduction
These guidelines indicate how to complete the Project Handover to Operations Template. Sections
referred to within this document are the same as detailed in the Project Handover to Operations Template
which is available on the Programme Office web site at:
http://iss.leeds.ac.uk/downloads/download/453/tools_and_guides
For further information or guidance please contact the Programme Office at isscal1@leeds.ac.uk.
Purpose/Description of the Project Handover to Operations
The Project Handover to Operations document records the transfer of all the information required for the
ISS Support Teams to manage the support of the hardware, software and infrastructure associated with the
products delivered by the project.
This includes confirming which ISS Support Teams are affected by the products delivered and any risk,
issues or lessons learned which need to be monitored after the project has been delivered.
Front Page


Replace the wording “Project Name” with the project name. Please ensure that the name is
consistent with the information on the Shared Project folder on the N drive N:\AcademicServices\ISS\PMO\PDS\Projects
Insert the date of the current document version.
Contents
The contents page can be updated automatically using the following commands:

Position the mouse over the contents (shaded) section.

Right click and choose the option Update Field

If the options “Update Page Numbers Only” or “Update Entire Table” is displayed, choose the option
”Update Entire Table”.
Footer (Page 2 onwards)
Project ID:

Insert details of the Project Nr provided by the PO and available on the share Project folder
Author:

Insert details of the report author.
Version:

Insert details of the current version number of the document.
Document1
Version: 2.1
Page 1 of 6
File Name:

This field can be updated automatically by highlighting the text, right click and choose the option
Update Field.
Report Generation
The following sections are split into the sections as displayed in the Project Handover to Operations
Template, brief guidelines as to the contents of each section are detailed.
1.0
Document Purpose
This outlines the purpose of the document, initial text has been included by the Programme Office but can
be altered as necessary.
Location:

Please include full details of the location of associated key project documentation.
2.0
Outline of Changes/Enhancements
2.1
Brief Indication of Changes/Enhancements
The purpose of this section is to detail the changes/enhancements each service area has made to existing
setups/configurations/processes during the course of the project.
Consider all the service areas as detailed on the ISS Organisation Chart and list any associated
changes/enhancements.
The ISS Organisation Chart is regularly updated by the HR and is available on the ISS Intranet using the
following hyperlink: http://issintranet.leeds.ac.uk/hr/Organisation_Chart/organisation_chart.html
For Example (indication only, not true reflection of the project):
Outlook/Exchange Project
PC Support:

Outlook/Exchange 2002 implemented.

Email services other than Outlook/Exchange no longer supported by ISS.

Etc.
Customer Services:

Generating new users on the Global Address List (GAL).

Removing user accounts from the GAL.

Etc.
Etc.
2.2
Brief Indication of New Products
The purpose of this section is to detail the new products introduced to each service area during the course
of the project.
Document1
Version: 2.1
Page 2 of 6
Consider all the service areas as detailed on the ISS Organisation Chart and list any associated with the
new products.
The ISS Organisation Chart is regularly updated by the Programme Support Unit and is available on the
ISS Intranet using the following hyperlink:
http://www.iss.leeds.ac.uk/hr/Organisation_Chart/organisation_chart.html.
For Example (indication only, not true reflection of the project):
Outlook/Exchange Project:
PC Support:

New server infrastructure in place.

Department Exchange Administrators (DEA) nominated within each department.

Etc.
Customer Services:

Online Training.

Ability to create resources on the GAL (e.g. meeting rooms).

Etc.
3.0
Support Flow Diagram
In conjunction with the Helpdesk Service Leader, it is recommended that a flow diagram is produced to
identify the types of support queries which may be received and the recommended escalation route via the
Helpdesk process.
The flow diagram should be built up during the project, any support queries taken during the project should
be considered when developing the flow diagram. Once finalised, the flow diagram should be copied into
this section of the Project Handover to Operations document.
4.0
Support Implications
The purpose of this section is to review and identify what each area will have to know/do as a result of the
project, the impact on existing processes and new processes which have been defined during the project.
It is imperative that these requirements are developed and are ready for implementation before the project
closes. Close liaison will therefore be required during the project with all teams who will be involved in
supporting the product when operational.
Document1
Version: 2.1
Page 3 of 6
4.1
Impact on Existing Processes
Generate subheadings to indicate the Support Teams affected by the products delivered by this project and
the implications on existing processes.
Reference should be made to the location and/or owner of the processes, if available, hyperlinks could be
included.
For Example (indication only, not true reflection of the project):
Outlook/Exchange Project:
4.1.1

PC Server
New server infrastructure in place: processes altered to include new servers and the
escalation routes of related faults.
Email services other than Outlook/Exchange no longer supported by ISS : activity definition
reports altered to advise that email services other the Outlook/Exchange are no longer part of
the standard support contract, record only ‘best endeavours’ support can be offered.
Process documents relating to the PC Server team can be located using the following
hyperlink……..
Etc.



4.1.2

User Administration
Process documents updated to show amended/additional actions relating to generating new
users on the Global Address List (GAL) and removing user accounts from the GAL.
Process documents relating to the User Administration team can be located using the following
hyperlink……..
Etc.


4.1.3
4.2
Etc.
New Processes Developed/Required
Generate subheadings to indicate the Support Teams affected by the products delivered by this project and
the new processes which have been developed.
Reference should be made to the location and/or owner of the processes, if available hyperlinks could be
included.
For Example (indication only, not true reflection of the project):
Outlook/Exchange Project:
4.2.1


Document1
PC Server Team
Department Exchange Administrators (DEA) have been nominated within each department,
processes developed to update/communicate to DEA’s where necessary and also to deal
with any urgent actions (via the Helpdesk) should the DEA not be available.
Process documents relating to the PC Server team can be located using the following
hyperlink……..
Version: 2.1
Page 4 of 6

Etc.
4.2.2



User Administration
Process documents developed to identify best practice when setting up resources (e.g.
meeting rooms) on the GAL.
Process documents relating to the User Administration team can be located using the
following hyperlink……..
Etc.
4.2.3
ISS Training Unit
Processes defined to monitor the usage of Online Training and to ensure ownership should any
areas need to be amended/reassessed.
4.2.4
Etc.
5.0
Handover Documentation
5.1
Risk Log
As part of the project closure process, the Risk Log should have been reviewed and updated to include
information as to whether or not the risk materialised.
There may be occasions where risks cannot be closed as they are still a potential risk to the product during
its operational lifetime. In this instance please either:


Detail the Risk(s).
Embed a copy of the Risk Log which details the live risks only (keeping the original risk ID number). It
is recommended that the full Risk Log is not embedded as this should be located on the Project
Folder.
5.2
Issues Log
As part of the project closure process, the Issues Log should have been reviewed and updated to include
information as to whether or not all issues have been closed. Live issues should be reviewed and
categorised as Follow-on Actions or issues that should be transferred to operations.
If any live issues are categorised as operational issues then please either:


Detail the Issue(s).
Embed a copy of the Issues Log which details the appropriate issues only (keeping the original issue
ID number). It is recommended that the full Issues Log is not embedded as this should be located on
the Project Folder.
5.3
Lessons Learned
As the project progressed a Lessons Learned Log should have been developed to identify lessons learned
when things went well or badly during the project.
Review the Lessons Learned Log and assess if any of the lessons should be highlighted, consider if they:

Affect the product whilst operational.
Document1
Version: 2.1
Page 5 of 6

Are generic lessons learned which should be considered as part of a generic support process.
If any lessons learned need to be highlighted then please either:

Detail the Lesson(s) Learned.

Embed a copy of the Lessons Learned Log which details the appropriate lessons only (keeping the
original lesson ID number). It is recommended that the full Lessons Learned Log is not embedded as
this should be located on the Project Folder.
6.0
Appendices
Include appendices as necessary,
For example:


List of frequently asked questions (FAQ’s). This could be related to lessons learned during the
project including any support queries received during the project.
Activities that are not considered the ‘norm’, e.g. dealing with specific departments who have their
own processes and do not have a formal support agreement with ISS.
Document1
Version: 2.1
Page 6 of 6