ISS Project Management Methodology
Project Manager’s guide
(Updated to encompass University Project Management Approach)
Version 5.0
May 2011
Contents
Table of Contents
Contents ......................................................................................................................... 2
1 Purpose ................................................................................................................... 3
2 Context ................................................................................................................... 3
2.1 Alignment to the University Project Management Approach (UPMA) .......... 3
2.2 Project Governance: ........................................................................................ 5
2.3 Background to governance .............................................................................. 5
2.3.1
Project Roles: .......................................................................................... 6
2.3.2
IS projects ................................................................................................ 9
2.3.3
Non-IS projects ...................................................................................... 10
2.4 Dual roles: ..................................................................................................... 10
2.5 What constitutes a project: ............................................................................ 10
2.6 Project criteria ............................................................................................... 10
2.7 Example Project Flows.................................................................................. 12
2.7.1
Overall delivery ..................................................................................... 12
2.7.2
IS start-up (example of how project start up can work in ISS) .............. 13
3 The Project Manager ............................................................................................ 13
3.1 Role of the project manager .......................................................................... 13
3.2 Project management functions ...................................................................... 16
3.2.1
PROJECT SPECIFICATION ................................................................ 16
3.2.2
PROJECT DEFINITION & BUSINESS CASE PRODUCTION ......... 17
3.2.3
PROJECT IMPLEMENTATION - PID Production.............................. 19
3.2.4
Project Budgeting................................................................................... 23
3.2.5
PROJECT EXECUTION – start-up....................................................... 24
3.2.6
PROJECT EXECUTION - ongoing ...................................................... 26
3.2.7
PROJECT CLOSURE - Closure and Handover to Business as Usual . 32
4 Customisation of the methodology ...................................................................... 33
5 Associated documents for reference: ................................................................... 34
6 Appendix 1- Estimated Effort .............................................................................. 36
7 Appendix 2- Process flow – document production and approval ........................ 38
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 2 of 38
1 Purpose
This document seeks to define the activities that are expected to be undertaken by
projects managers. In addition to a simple list of responsibilities it contains an
assessment of the quality of output required e.g. in terms of level of detail and
complexity and the anticipated effort (estimated from experience). In addition it
provides some information about the context within which the project manager works
and specifically performs the functions of project management.
It is anticipated that the text will be used as a reference for project managers, project
teams and line managers.
2 Context
The project manager as a role and project management as a function do not operate
in isolation. Other players and processes are material to their activity and the
success they enjoy. This section outlines the context within which project managers
need to operate.
PROJECT GOVERNANCE
PROJECT
INITIATION
Project Kick-off
PROJECT
DELIVERY & IMPLEMENTATION
PROJECT
CLOSE
End Project
meetings
Stage Management
Post implementation
review
System Development
Demand
Maintenance /
Support /
Enhance
Evaluate
Package Selection
Benefit
realisation
This diagram shows
the elements of a
typical (generic)
project.
RAD Development
Infrastructure Development
TOOLS
2.1 Alignment to the University Project Management
Approach (UPMA)
This section covers how ISS have aligned their established Methodology to the
UPMA and it includes the specific changes made. The rest of this document has
been updated to reflect the new terminology.
Purpose:
This document summarises revisions to the project management methodology as a
result of developing a Unified Project Management Approach for the University of
Leeds.
Introduction:
The Unified Project Management Approach has been defined to ensure that projects
are managed and delivered in a consistent manner across the University. It has
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 3 of 38
been produced collaboratively, with ISS, Estates and Project Management Group
fully involved. It is based upon accepted best practice and the adoption of clear
processes based around stages and decision gates, straightforward documentation
and defined roles / responsibilities.
Stage 2
Project Definition
and Business
Case
Stage 1
Project
Specification
Gate 1
Initial view of why the
project is being
proposed & what it is
aiming to achieve
Why are we doing this?
What are the aims?
What are we going to
deliver? What strategic
gap are we addressing?
Stage 2a
Outline
Business
Case
Stage 2b
Full
Business
Case
Stage 3
Project
Implementation
Gate 2
Plan, manage & deliver
the outcomes
Gate 3
Stage 4
Review & Benefits
Realisation
Including handover to
business as usual
Decision
Key points of the Unified Project Management Approach:
The approach has 4 stages each of which requires specific activities.
These stages are:
o
Stage 1, Project Specification – this is the equivalent to ISS Project
Mandate preparation and (for IS) 5 year planning activities
o
Stage 2, Project Definition and Business case preparation - this is the
equivalent to ISS Project Brief (& Business case) preparation. Stage
2 may, for some projects be divided into 2a and 2b to enable a two
step business case process to be followed (to support outline and full
business cases)
o
Stage 3, Project Implementation – this is equivalent to Project
Initiation document Preparation and Execution combined. This is the
least defined element of Unified Project Management Approach as it is
recognised that the different nature of projects in areas across the
University require different approaches to delivery. Unified Project
Management Approach requires that there is appropriate levels of
planning and control in each area.
o
Stage 4, Project closure – ISS Project close is covered by this stage,
however it extends beyond the current scope and moves to ensure
realisation of benefits.
A decision gate follows each of the first three gates
Decision gates are supported by defined information requirements which translate
into key documents.
ISS documentation aligns to the key documents required by UPMA as follows:
o
Project Mandate becomes Project Specification Document - provides
a summary of what is required, benefits to be achieved and high level
estimate of resources required. It also shows how the following stage
will be performed.
o
Project Brief becomes Project Definition and Business Case
Document – provides a detailed rationale for the project, a costed
options appraisal and resource implications. Again it will outline how
the following stage will be performed.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 4 of 38
o
Project Initiation Document is retained as a local document within ISS
and is the first deliverable of the Project Implementation stage
(previously Project Execution in ISS). This will continue to be used to
summarise detailed planning and control aspects of the project and
will be agreed locally.
UPMA introduces a Capital Group style financial assessment of projects. These are
produced during stage 2 (and can potentially require a 2 step process as described
above).
This financial assessment includes a Net Present Value calculation and structured
option appraisal.
The approach requires the establishment of project governance bodies:
o
Project Delivery Groups - these are the equivalent of ISS Project
Boards and will provide the project with oversight and governance;
directing the activities of the project and the project manager.
o
Working Groups – these direct the activities of project work-streams
and as such there is no direct ISS equivalent of this body except the
project team itself.
o
Clarity is still being sought regarding the relationship between these
Project Delivery Groups and other University Committees.
A number of specific roles have been identified and these are equivalent to and
complement those already established for ISS projects:
o
Project Sponsor - provides strategic vision and leadership. Ultimate
responsibility for the successful delivery of the project.
o
Business Owner – ensure that the project outputs will bring the
positive outcomes set out in the business case. Often the same
person as the Sponsor.
o
Project Manager – provides day to day management of the project.
o
All other roles previously identified for ISS projects still remain.
All other tools, documents and reporting used during the project remain the same as
currently used in ISS
2.2 Project Governance:
Projects within ISS are formally governed, that is their worth is assessed, priorities
awarded, their start authorised and their progress monitored. The governance that is
applied to them, although different between IS and non-IS area, seeks to apply the
same rigour and ensure that the most appropriate and beneficial projects are
pursued.
2.3 Background to governance
The demand on ISS for development work far exceeds its capacity to deliver.
Therefore, ISS needs help and direction to ensure that we are delivering the work
that is most important for the University and adds the most value to the institution.
Governance can be defined as “the processes which ensure the effective and
efficient use of IT in enabling an organisation to achieve its goals."
The purpose of governance for ISS developments at the University of Leeds is to:
 provide an organisational structure for decision making and formalised
reporting lines for ISS developments
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 5 of 38






clarify the roles and responsibilities of all stakeholders in the governance
process
consolidate a university-wide understanding of system development
requirements and thus achieve the correct balance between the interests of
multiple stakeholders
align ISS development and organisational need
exert financial control over the ISS development budget
exert control on resource allocation
enhance the performance of the ISS system development plan to maximise
the Return on Investment for the University of Leeds
2.3.1 Project Roles:
The role of Project Manager
The primary responsibility of the Project Manager is to provide the day to day
management required to successfully steer the project through the planning and
delivery stages and to ensure delivery against the agreed business case. Specific
responsibilities include: The project manager is responsible for delivering the project to the agreed
project plan – and achieving the outputs that underpin the project’s business
case
 To undertake/have oversight of the planning for the project.
 To manage the day to day delivery of the project ensuring delivery against the
project plan.
 To report to the project delivery group on the delivery of the project, gathering
and presenting the necessary information to enable the project delivery group
to understand the actions and progress of the project.
 To identify and subsequently manage risks which might jeopardise the
successful delivery of the project and to communicate these to the project
delivery group.
 To maintain an accurate picture of the progress of the project
 To manage costs
 To deal with issues and risks as they occur and work closely with the project
sponsor to evaluate progress and take corrective action.
Within ISS This translates as:
 With Project Sponsor develop project documentation (Project specification /
Project definition & business case / PID)
 With the Project Team scope and define business solutions.
 Service the Project Delivery Group and Project Sponsor.
 Plan, manage and deliver projects to time, cost and quality.
 Monitor, control and co-ordinate projects, escalating issues and reporting
progress.
 Managing issues and risks.
 Communicate project information to all stakeholders.
 Formally close projects.
The role of the Project Delivery Group
The primary responsibility of the Project Delivery Group is to direct the activities of
the project and the project manager to ensure the delivery of the project against
agreed expectations and timescales as set out in the high level project plan. Specific
responsibilities include :Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 6 of 38
 To provide specialist input to ensure the successful delivery of the project
where that is required.
 To receive and appraise the information received from the project manager
regarding the delivery of the project.
 To manage inter dependencies between the project and other on-going
projects
 To communicate the purpose and activities of the project
 To undertake a project assurance role, identifying how the project is delivering
against the business case
 To monitor risks to the successful delivery of the project and to agree
mitigation
 To authorise, where appropriate, deviation form the original plan, in the light
of developments within the project or the acquisition of new information.
 To consider the allocation of time and resources required to meet the
requirements of the project
 To act as a champion of the project
 To agree the completion of the project stage and successful delivery of
expectations
On ISS projects this translates as (and includes):
Be accountable for the quality of the solution delivered
 Quality assurance of documentation (e.g. project initiation document)
 The right people with right skills are involved
 Project plan is realistic
 Communications are adequate
 The business case is sufficiently well defined & realistic
 Business is ready and able to implement solution
Provide operational support & direction for the project
 Monitor progress vs. plan
 Be a point of escalation for issues
 Advise on risk mitigation
 Authorise changes to the project
 Communicate with Business Systems Steering Group(s)
 Approve key milestones (e.g. go-live)
Ensure the business case remains valid
 Benefits are achievable, quantifiable and documented
 Measures & timing of benefits realisation are understood
 Costs are understood and realistic
 Any changes are fully assessed and don’t invalidate the business case
 The project is stopped if the business case becomes invalid
The specific roles of Project Delivery Group members
The Project Sponsor
The Project Sponsor is a key role – with overall responsibility for the project and its
outcomes, providing high level direction throughout the life of the project and acting
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 7 of 38
as the primary champion for the project, and providing ongoing high level direction
throughout the life of the project.
The primary responsibility of the Project Sponsor is to provide the strategic vision and
operational leadership necessary to ensure the completion of project planning, which
aligns to University strategic objectives and then to secure the successful delivery of
the project against the expectations of the Business Case, delivering the required
outputs and outcomes within timescale and budget. Specific responsibilities include: Overall responsibility for the success of the project in delivering the business
impact and business benefits as outlined in the original business case
 To provide strategic leadership to the project delivery group and the project
manager.
 To chair and work with the project delivery group to oversee and ensure the
successful planning and delivery of the project.
 To champion the project, communicating with stakeholders to secure their
support and commitment.
 To provide the University wide strategic context for the project
 To identify and secure the resources necessary to ensure the successful
delivery of the project.
Within ISS this translates as (and includes):
 Overall accountability for delivery of the project
 Preparation of the Project Definition & Business Case
 Appoint Project Delivery Group and ensure it fulfils its remit
 Chair Project Delivery Group meetings
 Maintain focus on project delivery : Solution good enough but not over
engineered
 Communication with groups
Additionally, ISS Projects require other project delivery group roles that need to be
filled include:
The Senior User (Role specific to ISS Projects)
 Represent the views of the user community
 Ensure that business personnel with the correct skills are made available to
the project at the right time
 Quality assurance on behalf of the user community, i.e. plan is achievable;
solution is usable; benefits can be realised
 Ensure user community risks are understood & mitigated
 Resolution of escalated issues associated with the user community
The Senior Supplier (Role specific to ISS Projects)
 Represent the views of supplier community (most of the time ISS)
 Ensure that supplier personnel with the correct skills are made available to
the project at the right time
 Quality assurance on behalf of the supplier(s), e.g. plan is achievable;
solution is usable; benefits can be realised
 Ensure supplier (community) risks are understood & mitigated
 Resolution of escalated issues associated with supplier (community)
Also additionally UPMA recognises a role of Business Owner which on ISS projects
is not always separated from Sponsor. The role is defined as:
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 8 of 38
The Business Owner is the Head of School/Service/Faculty that has the responsibility
for taking the outcomes of the project and using them to deliver the benefits outlined
in the business case. (For example – this could be a Head of School for a restructure
project, a Head of Service for a process development, or a Head of School for a
major building project). For most projects, the realisation of benefits will occur well
beyond the life of the “project organisation”, hence the importance of the Business
Owner having a considerable role and stake in the project. The Business Owner will
normally be the person responsible for the benefits realisation, reporting to the
sponsor (stage 4). Where the eventual business ownership falls across more than
one area, it is still useful to nominate one Head to represent the group of business
owners. There isn’t however a “one size fits all” Business Owner role, this should be
considered on a project by project basis taking into account the nature of the project
(and the need for specific project management skills), the project management
experience of the Business Owner, and their capacity to contribute to the project.
Models that work well include:
 Business Owner as a member of the Project Delivery Group
 Business Owner acting as the Project Manager supported by specialist Project
Management advice/support.
 Business Owner working in close partnership with the Project Manager to
deliver the project.
Business Owner - Key responsibilities
The primary responsibility of the Business Owner is to ensure that the outputs from
the project are such that they will translate into the desired positive outcomes
identified in the business case. Specific responsibilities include : To ensure that what is specified and delivered is fit for purpose, meeting user
needs and requirements
 To ensure that the project maintains a focus on user needs.
 To brief potential business users on the actions and developments of the
project, ensuring broader business engagement in the successful delivery of
the project.
 To consider business risks.
2.3.2 IS projects
Governance around IS is business led and business focussed. The highest level
governing body is the Information Systems Prioritisation Group (ISPG) which is
comprised of VCEG members and other senior management from Faculties and
Corporate Services across the University.
ISPG is supported by interaction with particular aspect of the Business, for example:
 Research
 Learning & Teaching
 Enterprise & Knowledge Transfer
 Students
 Staff
 Corporate
 Finance & Purchasing
Project Delivery Groups have responsibility for individual projects. They are led by a
Project Sponsor who is a senior manager from the business who will have a good
knowledge of the area in which the project is being implemented. The Project
sponsor is supported on the Project Delivery Group by senior representatives of the
user community and the supplier community.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 9 of 38
2.3.3 Non-IS projects
The ISS Executive (as attendees of the Programme review meeting) perform
governance for ISS projects that are not covered by ISPG (e.g. non-IS projects).
This is because there are no similar University wide bodies / external steering groups
for the non-IS aspects of the ISS Programme. They will therefore provide
governance to projects that are not directly associated with a business systems
steering group. During the meeting they will consider:
 Key project progress
 Rolling programme / initiation of new projects
 Issue and risk review
 Change management / Project exceptions
 Project closure
Again, sitting beneath the Executive, Project Delivery Groups have been established
for most projects. They are led by a Project Sponsor who is a senior manager
(normally an Exec member) who is likely to be head of the function within which the
project is being implemented. The Project sponsor is supported on the Project
Delivery Group by senior representatives of the user community and the supplier
community.
Note that it is anticipated that project governance will be affected by the
implementation of the UITD project.
2.4 Dual roles:
Should the project manager take on other roles within the project in parallel to their
project management tasks, for example some project managers also perform an
analysis function on their projects and some non-dedicated project managers
perform project management in parallel to their normal job, these tasks should be
accounted for (estimated, planned and scheduled) separately. There must be a
distinction made between the project management time and effort, and time and
effort on other tasks. Neither set of functions should be considered free with the
other.
This document concentrates solely on the project management aspects and
estimates of time given here, as guides, only concern project management.
2.5 What constitutes a project:
We should now consider a project as a “way in which a work request is delivered”
rather than as a “type of work request”. In this way it becomes more straightforward
to define exactly what a project is. There are various theoretical definitions of “a
project” and the one presented below is adequate for this document:
 temporary organisation/arrangement established to deliver specific
objectives (e.g. specific product or service) and has distinct start and
finish times.
2.6 Project criteria
In terms of this organisation, criteria are used as a guide to when a project approach
should be used and what level of effort is required top manage the project. The
information is meant as a guide and the distinction between minor and major projects
is a sliding scale. There will always be exceptions to this.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 10 of 38
Title/Level Sensitivity Risk Resource
Minor
Project
Major
Projects
Budget
Cross functional, £10,000
one team
involved
£25,000
Effort
Timescale
Impact
(Elapsed)
8-60
man
days
1.5 to 3
months
Not
sensitive
Low
Sensitive
Cross functional,
>60
several
High
>£25,000 man
resources/teams
days
involved
11-50
users
>3 months >50 users
Whether we manage a piece of work as a major or a minor project will be decided on
the merit of each project
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 11 of 38
2.7 Example Project Flows
2.7.1 Overall delivery
Decision
points
(gates)
Approval
to start
Approval
to spend
Approval
to progress
Acceptance /
closure
Approval
to launch
Review
benefit
PROJECT GOVERNANCE
Demand
Post
Implementation
Review
(report & agree)
& Benefit
realisation
End Project
meeting (report
& agree)
Manage
Handover
PROJECT
CLOSE
Manage
changes
Manage
governance
Manage risks /
issues /
dependencies
Reporting
Work
Packages /
delivery
Monitor events
/ progress
against plan
PROJECT
DELIVERY & IMPLEMENTATION
Create /
agree PDR
Set-up team
(Kick -off
meeting)
Create /
agree Brief
PROJECT
INITIATION
STAGE MANAGEMENT
Maintenance / Support /
Enhance
Handover
Deploy
Train
Test
Build
Design
Evaluate
Maintain
Handover
Deploy
Train
Benefit
realisation
Maintain
Review
Test
Pilot
Amend
Install /
configure
Requirement
Evaluate /
select
Infrastructure Development
Ad-hoc
request
Concept
design
Annual
Plan
Analysis
System Development
TOOLS: Risk log; Issues log; Action log; Lessons learned log etc
. (as appropriate)
This diagram shows the components of a typical project and illustrates that the approach taken to implementation can
vary depending on the project and the area concerned.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 12 of 38
2.7.2 IS start-up (example of how project start up can work in ISS)
UPDATED
– Nov 2009
ISS SGL
General
Project
Management Management
Business
ISPG
ISS PO / Finance
Receive work
request
Small works
or support
No
Delivery
requires a
project
approach?
Yes
Indicative costs
added to Proj
Spec by ISS (&
business)
Request Project
Specification to be
prepared by the
business
(uncosted)
ISPG approves
the Project
Specification?
PO Store Project
Specification in
Pool (of potential
projects)
Yes
No
Stakeholder
management –
stop project or
review scope
Undertake
annual
prioritisation
of Proj Specs
PO Produce
revised 5 year
plan (projects and
priorities)
ISS FIN produce /
update financial
position
ISS SGL assigns
Project
Management
resource
ISPG assigns
project sponsor
ISS produce
Project Definition
(with input from
sponsor)
1
ISS FIN update
financial position
from Budgeting
workbooks
ISS and Sponsor
approves Project
Definition
Stakeholder
management –
stop project or
review scope
ISPG review &
assess impact on
programme
ISPG authorise
project to
proceed?
No
1
Sponsor appoints
project board
No
Yes
PO receives
update
from ISPG
PO Create /
update
programme
schedule
Yes
Project Manager,
with the sponsor &
project board
produce PID
No
Project Board
Approve PID?
ISS FIN update
financial position
from Budgeting
workbooks
Yes
No
PO Produce
revised rolling plan
No significant
difference in
Time, cost,
scope.
No
Yes
ISSG approve
revised B’Case
Rework PID
Execute
project
Rework PID or
cancel?
Yes
No
Cancel project
Stakeholder
management –
stop project
3 The Project Manager
The functions described below are those expected of project managers (and others)
who have the responsibility for managing projects. They are translated into the
specific tasks that the project management performs. This is a restatement of the
principles contained in section 2.3.1.
3.1 Role of the project manager
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 13 of 38
The following items are a summary the role of the project manager. Later, in this
document, the component elements of these points are explored in more detail.
The primary responsibility of the Project Manager is to provide the day to day
management required to successfully steer the project through the planning and
delivery stages and to ensure delivery against the agreed business case.
Specifically:
Project initiation
 With Project Sponsor develop project documentation (Project specification /
Project definition & business case / PID)
 With the Project Team scope and define business solutions.
Delivery
 The project manager is responsible for delivering the project to the agreed
project plan – and achieving the outputs that underpin the project’s business
case
 To manage the day to day delivery of the project ensuring delivery against the
project plan.
Planning and control
 To undertake/have oversight of the planning for the project.
 Service the Project Delivery Group and Project Sponsor.
 Plan, manage and deliver projects to time, cost and quality.
 Monitor, control and co-ordinate projects, escalating issues and reporting
progress.
 Formally close projects.
Reporting
 To report to the project delivery group on the delivery of the project, gathering
and presenting the necessary information to enable the project delivery group
to understand the actions and progress of the project.
 To maintain an accurate picture of the progress of the project
 Communicate project information to all stakeholders.
Risk & Issue Management
 Managing issues and risks.
 To identify and subsequently manage risks which might jeopardise the
successful delivery of the project and to communicate these to the project
delivery group.
 To deal with issues and risks as they occur and work closely with the project
sponsor to evaluate progress and take corrective action.
Budgetary control
 To manage costs
Documents by stage
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 14 of 38
ISPG / PRM approve Project specification
Governance (decision
points)
2
1
Governance documents
Input
Project Initiation
Annual plan
Project Specification
Project Definition & Business Case
Assessment material
Supported by
- Project Budgeting tool
- Outline business case
- Approach (steps) / Milestones
- Outline plan
- Project Budgeting tool
- other Business Case calculations
Ad-hoc request
PROJECTS
Project Management
Working Documents
Associated documents
Governance (decision
points)
ISPG / PRM approve Project definition and
sanction implementation
Steering Group (PB) approve
detailed planning
Steering Group (PB) approve move to
next internal-stage
2
3
Project Implementation
Governance documents
PROJECTS
Project Management
Working Documents
Associated documents
Summary of detailed planning activities:
e.g. Project Initiation Documents
- Business case
- Plan (w ork schedule, Communicationsetc.)
+ other associated document (see below )
Supported by
- Project Budgeting tool
- Business case calculations
- Plan (w ork schedule, Communicationsetc.)
- Project organisation / team involvement
Set-up project logs
- Issue
Highlight reports
For end of stages
- Manage / Revise plans
- Manage / Revise Business Case
+ Other stage management documents as appropriate to the project
Work package documentation (as appropriate)
Process documentation
- Issue
- Change
Maintain project logs
- Risk
- Issue
- Change
- Risk
- Lessons learned
- Change
+ other associated document (see below )
- Lessons learned
Impact Analysis
Development doumentation e.g.
Project structure
- Business requirements analysis
Risk Analysis
- System functional & technical designs
Initial requirements
- Test specification / scripts
- Acceptance documentation
- Training documentation
- Handover material
- User / support documentation
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 15 of 38
Governance (decision
points)
Steering Group (PB) approve launch PB - Approve closure
3
Project Close
Governance documents
Handover to Business as Usual
Benefits realisation
Project Management
Working Documents
End Project report
Post implementation review
PROJECTS
Close project logs
- Issue
- Risk
- Change
- Lessons learned
Associated documents
3.2 Project management functions
This section describes the specific activities expected of those people managing
projects (e.g. project managers).
3.2.1 PROJECT SPECIFICATION
The creation of the Project Specification and the effort associated with it are “one
offs” for each project and the Project Specification is used to 'trigger' or start up a
project. The Project specification contains a very brief outline of the
proposed/requested activity, stating why it is needed, outline objectives and
deliverables and also an overview of the benefits (the reasons behind the request)
The Project specification should be seen as the pre-cursor to the Project Definition &
Business Case and by adding information to it the Project specification is
transformed into the project definition & business case.
The originator of the idea creates the Project Specification and sends it to ISS in an
un-costed form. This is then analysed for value / benefits and the costs / resources
required are estimated (plans and estimates for the next phase plus an overall –
Rough Order of Magnitude – for the project as a whole). Depending of which area of
ISS is to undertake the project a project budgeting workbook will be prepared to
capture the costs.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 16 of 38
There is very little detail required for the Project specification and as can be seen for
the estimates of time given in the appendix very little time is given. If the project
manager becomes involved in capturing the originators ideas or in any initial analysis
of the requirement then additional time will be required.
The Project Specification is agreed by ISS and the Originator and then subjected to
the appropriate governance - full details of which can be found in associated
documentation.
Template Content
Background & Context
High level
• Description
• Purpose,
• Timescales,
Objectives
Anticipated benefits
Key strategic drivers & alignment
High level cost estimate
For ISS use (consider including):
•
•
•
•
Assessment of resource requirements (roles / skills / effort)
Initial view of scheduling
Any immediate concerns
Stakeholders
In summary, if involved, the project manager will:





Prepare project costs (including, if appropriate, the set-up and population of
the project budgeting workbook).
Prepare a draft project plan. This will be in detail for the next phase preparing the Project Definition & Business Case - and in summary
(milestone level) for further phases.
Finalise the Project specification (to a point where it can be reviewed and
decisions can be made by the governing bodies).
Obtain sign-off from the appropriate stakeholders (SGLs / systems managers,
ISS Executive etc.).
Distribute to the Programme Office, SGLs / systems managers, ISS
Executive.
3.2.2 PROJECT DEFINITION & BUSINESS CASE PRODUCTION
The Project Definition & Business Case is key to the initiation stage of the project
and, again, is a one off task in terms of project delivery. It is the document that
management will:
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 17 of 38



formally sign-off to accept that effort should be expended to progress the
project to the next stage,
have an understanding of the whole project
and sanction further activity.
It is an extension of the Project Specification and provides outline details of the
project - greater detail than the Project specification but less than the PID, for
example initial statements of scope, objectives and business case etc. Planning /
estimating of costs, timescales and resources are enhanced. Where appropriate the
project budgeting workbook is updated.
The project definition & business case informs the discussions that take place to
secure resources (in principle) and supports project kick-off with the project team.
The Project Definition & Business Case contains high level information on WHAT
needs to be done and WHY, WHO will need to be involved in the process and HOW
and WHEN it will be done. Details of the job to be done are also present and the
purpose of this document is to decide whether there is sufficient justification to
warrant further expenditure.
In addition to the Project Definition & Business Case the following other activities
happen in parallel:





The Project Plan is produced which identifies the management stages and
other major control points/milestones of the project and is used by ISS
Management as a baseline against which to monitor project progress and
cost stage by stage.
Setup of Project Tools workbook - This tool provides project managers with
an integrated resource by which they are able to record and manage the
risks, issues, changes and lessons learned relating to their project. The
workbook consists of: Risk Log, Managed Risks – Control Log, Issues Log,
Change Request Log and Lessons Learned Log
Communications Plan – as part of project planning (next stage etc.)
communications are considered and planned. The PM may use the
stakeholder management material that is available.
Communications – some aspects of the project may need to be
communicated at this stage and the PM will lead this work.
The detailed level of planning will related to the PID (product initiation
document) Production.
Template Content
Background & Context
Detailed description of:
• scope,
• objectives,
• deliverables,
• outputs
• outcomes,
• project rationale
Benefits & Timescales and options appraisal
Key strategic drivers & alignment
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 18 of 38
Costs,
Resources and Funding – investment appraisal
High Level Risk Overview
Organisation,
Roles, Governance, Structure
High Level Overview of Phases / Outline Plan
Key Management Controls
Handover & Acceptance
For ISS use (consider including):
• Cross Team involvement including an assessment of resource
requirements
• Likely schedule scheduling
• Dependencies on teams, systems and other projects.
In summary the project manager will:







Produce and agree the Project Definition & Business Case - obtaining
agreement from Project Delivery Group, SGLs / systems managers, ISS
Executive etc.
Prepare a project plan. This will be in detail for the next phase - preparing
the Project Initiation Document - and in summary (milestone level) for further
phases.
Update the project costs / business case (including, if appropriate, the
updating of the project budgeting workbook).
Carry out initial stakeholder analysis and use the information to plan
communications. (Some communication may take place).
Finalise the Project Definition & Business Case (to a point where it can be
reviewed and decisions can be made by the governing bodies).
Obtain sign-off from the appropriate stakeholders (Project Delivery Group,
SGLs / systems managers, ISS Executive etc.).
Distribute to the Programme Office, SGLs / systems managers, ISS
Executive.
3.2.3 PROJECT IMPLEMENTATION - PID Production
The production of the PID as a result of detailed planning etc. is the first element of
implementation and extends the project manager’s, the sponsor’s and the project
team’s understanding what is required to further levels of detail. As its name
suggests this document contains a detailed definition of the project and what is
intended to be achieved. It should not be confused with a statement of requirements
and this distinction allows project control to be distinguished from project delivery. In
the PID this is apparent as it refer to other documentation including system delivery
documents (e.g. User Requirements) rather than holding the details within this
document.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 19 of 38
Information from the Project Definition & Business Case and/or Business Case can
be transferred directly to the PID and the detail added to.
In order to create a situation where the project can be fully understood and formally
signed off (agreeing the PID) several other activities need to happen in parallel. .









A Project Initiation Meeting or Kick-off meeting should be held – this is
mandatory for the ISS methodology.
The Plans and Estimates (costs and resources) are updated and further
details added. The Budgeting Workbook, where used, and details of
estimates (both in £s and people) are updated.
The Project Plan is enhanced and (with elements of the PID) should provide a
statement of how and when a project's objectives are to be achieved, by
showing the major products, activities and resources required on the project.
It will identify the management stages and other major control
points/milestones. It is used by ISS Management as a baseline against which
to monitor project progress and cost stage by stage.
The Project Delivery Group is established and trained / briefed in their role.
Where appropriate Timesheet Management is established.
The Stakeholder Analysis previously undertaken is enhanced and the
Communications Plan refined.
Further aspects of the project may need to be communicated at this stage
and the PM will lead this work.
Risk Management and Issue Management are enacted according to the rules
that prevail within ISS.
The Project Manager will establish the controls and facilities that they require
to perform formal document management.
To confirm the end of the start-up / initiation phase the project manager will ensure
that the PID is produced and signed off.
Contents list;
 Record of Sign-off
 Executive Summary
 Background
 Project Definition
o Concepts and Objectives
 Concept
 Objectives
o Project Scope
 Inclusions
 Exclusions
o Constraints
o Assumptions
o Interfaces
o Method of Approach
o Project Deliverables
o Summary of Impact / Implications
 Summary of Business Case
o Strategic Fit
o Benefits
o Costs (£k) and Resource Analysis (FTE)
 Project Organisation
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 20 of 38




Project Communications Plan
Summary of Plans / Controls
o Key Milestones / Timescales
o Key Project Risks
o Contingency Plans
Project Filing Structure
Associated Documents (as appropriate)
o Project Organisation
o Business Case
o Project Plan
o Communication Plan
o ISS Departments/Teams Level of Involvement Checklist
o Impact Analysis
o Project Controls and Processes
o Further Information
In summary the project manager will:










Produce and agree the project initiation document (with the Business
Sponsor) - obtaining agreement from Project Delivery Group, SGLs / systems
managers, ISS Executive etc.
Produce an updated project plan. This will be in detail for the execution
stage.
Update the project costs/ business case (including, if appropriate, the
updating of the project budgeting workbook).
Carry out further stakeholder analysis and use the information to update the
plans for communications. (Some communication may also take place).
Update the project shared area with permissions for the project team.
Update documentation within the shared area (establish “logs” for risks /
issues etc. if not already completed)
Set-up, run and minute the Kick-off meeting.
Finalise the Project Initiation Document (to a point where it can be reviewed
and decisions can be made by the governing bodies).
Obtain sign-off from the appropriate stakeholders (Project Delivery Group,
SGLs / systems managers, ISS Executive etc.).
Distribute to the Programme Office, SGLs / systems managers, ISS
Executive.
Summary on use of the PID
The PID is made up of extracts from other operational documents and logs etc. that
are maintained throughout the project.

It is these other documents and logs that are kept current as the project
continues, for example risk and issue logs and project plans.

The PID can therefore be said to be live because of these other documents
and, should the need arise it can be reissued with the current state of play.

The elements that should be maintained are, for example:
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 21 of 38
1.
The project plan and associated assumptions (which would provide
approach, milestones, teams / resources involved).
2.
The project costs and associated assumptions (maintained and reviewed
within the Project Budgeting Tool and should the need arise be used to reauthorise the project)
3.
Project risks (and issues) logs (maintained as the project progresses)
4.
Communications plan used to control stakeholder communications throughout
the project (would provide the details in this section of the PID)
There can be no hard and fast rules regarding a schedule of when the full PID should
be republished within a project. This is likely to vary between projects and as a
matter of course elements of it will be agreed with the project delivery group as the
run-of -the-mill minor changes / fluctuations occur as the project unfolds. The
guidelines should be that SGLs and Project managers will use their discretion (and
be able to justify their actions) about the severity and impact of “changes” and the
need to re-issue the document in its entirety.
With the advent of the Project Definition and Business Case and the likely use of
elements of that document to re-authorise projects that require refinancing, the
relationship with the PID requires clarification. It is envisaged that where the project
requires to be re-financed the Project Definition and Business Case is the best
vehicle as this provides mechanisms to revisit the financial assessment of the project
(e.g. risk appraisal and Net Present Value analysis).
The PIDs would then need to be re-issued in the following circumstances:





As part of the process, following a significant change to time, scope or costs.
This will be supported by change control (and will be the result of the
investigation of the implications of the change e.g. on the plan, costs etc.).
If there has been significant over-run or over-spend that has resulted in
needing governance approval for the changes (e.g. in circumstances where
we have not estimated correctly).
Where minor changes and fluctuations cannot be accommodated through
flexibility/rescheduling by SGLs and are also beyond the level of discretion of
the Head of IS.
As a response to the re-issue / reauthorisation of the business case (to
provide the PM and the Project Delivery Group with the updated tools
necessary to manage the project e.g. to summarise the detailed plan, rebaseline project costs etc.).
This essentially defines the PID as a vehicle for summarising the current and
projected position of the project, in a degree of detail that is beyond the
normal level included in the Project Definition and Business Case and project rep
========================================================
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 22 of 38
Summary of creation of Major IS documents and decisions points / sign-off
ISPG
Sponsor
(or nominees)
Project
Delivery
Group
IS SGL
IS PM
IS PO
Review
(create
some
material for
input)
Review
(either as a
group or as
individuals)
Project
Specification
Approve
Create
Project
Definition /
Business
Case -stage 1
(where
necessary)
Project
Definition /
Business
Case -stage 2
Project
Initiation
Document
Approve
Create
Update
Review
Review
(although this
document
identifies and
sets up the
PSG)
Approve
Update
(create
some
material
for input)
Review
Create /
Update
Review
Update
Review
Review
Update
Update
Review
Review
Update
Review
Review
Create
Review
Approve *
* Project Delivery Group can only approve if the costs contained within the PID are similar to
those that have been approved by ISPG in the Project Definition / Business Case. Any
significant deviation in costs must be referred back to ISPG (in most cases through a revised
Project Definition / Business Case). The IS PM will be monitoring this and will initiate any
escalation / resubmission of the Definition (required).
3.2.4 Project Budgeting
From summer 2008 the IS part of ISS is required to complete a Project Budgeting
Workbook for each of its project s (it is the intention to extend this to all of ISS at
some stage).
Project Budgeting has been introduced to:
 Standardise project costing
 Provide a basis for monitoring and control
 Visibility of project progress
 To ensure the business case remains justifiable
 Track and review actual costs against plan
 Understand resource requirements to deliver IS programme
 Provide project visibility so that management can take corrective action early
when performance varies significantly from plan
 Understanding of actual cost and time leads to improved estimating
 Maximise output from the resource available
 Forecast future costs
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 23 of 38
Use of the workbook
The Budgeting workbook is arranged by project phase and these align to the steps in
the project initiation and result in the three initiation documents (Project specification,
Project Definition & Business Case and Project Initiation Document).
At the start up of any project the representative of ISS who is producing the project
documentation (e.g. the Service Group Leader or Project Manager) is required to
complete a project budgeting workbook which will calculate the cost element of the
business case. The ISS representative is required to enter this information into the
cost / benefit sections of the Project specification, Project definition & business case
and PID.
At each stage the intention if to produce the best estimate of the project cost as is
possible and as the stages progress the estimates will become more accurate and
detailed.
For each stage of project initiation, the relevant tab is completed (explained in detail
in the Budgeting Workbook Guidelines) in the budgeting workbook and inserted into
the relevant document prior to submission.
An estimate of how much ISS resource (which is split into various categories) in days
for each future phase of the project (including execution) is entered. If it is
anticipated that the project will incur non-staff costs the values of these is entered.
For completeness if the business will be assisting on the project their effort (in days)
is also estimated and entered.
Recurrent Costs
If the project is expected to incur ongoing recurrent costs e.g. annual software
maintenance costs or support costs then these should be added against the relevant
category within the workbook. These are entered as a percentage or a monetary
value.
In summary the project manager will:







Produce and agree the Project Budgeting workbook.
Enter estimates into the appropriate section of the workbook (that
corresponds with the stage of the project).
Calendarise costs for financial planning purposes (profile of spend)
Store the workbooks in the appropriate folder.
Record the assumptions that support the calculations
Where available record actuals
Keep updated to reflect the current forecasted execution cost
For full details see ISS PRO website
3.2.5 PROJECT EXECUTION – start-up
As the project moves into execution there are final one off tasks to complete,
however these cannot be commenced until after PID sign-off. These are:
 The project manager will begin to execute their communications plan.
 Undertake a formal start-up meeting with all members of the project team to
set the scene and to explain how the project will be run.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 24 of 38
Typical start-up meeting (may also be used for earlier kick-off meeting)
Project Kick-off Meetings
This section explains the use of project kick-off meetings to begin a project and is
intended to be a guide to those organising and running such meetings.
Scope/Purpose of the meeting – The Kick-off meeting will mark the official start of
the project and should be used to ensure that all stakeholders/attendees
have an understanding of, and agree with, how the project is going to be
conducted. This will require the Project Manager (PM) to explain the
following: the project’s objectives; the processes and methods to be used to
progress the project and to govern it; any tools that will be used during the
project (that will assist its progress – logs and reports etc.); the roles and
responsibilities of the various team members; the desired outcomes; and
how success will be measured.
Topics for the meeting:
Therefore several topics should be covered at the kick-off meeting and these are
explained, below, in the form of a meeting agenda and description.
Agenda items
Introductions
o
PM ensures that all stakeholders know each other and sets the scene for
why they have been invited.
Context for project
o
The project owner, if in attendance, will explain why the project is going to
be run and why at this time. This can be delivered as part of a “vision”
statement.
o
Business vision
o
ISS rolling programme plan
Project Governance
o
The PM explains how project governance will work (in terms of Project
Delivery Groups and steering groups). The PM also explains the extent to
which they have the authority to continue.
o
Terms of reference for project delivery groups, optional Steering Groups
etc.
Project organisation
o
The PM (endorsed by the project owner) will explain the project organisation
and outline who will be involved (from which area)
o
Reference to Terms of Reference mentioned above
Roles and responsibilities
o
The PM will explain the key roles within the project organisation and will
outline responsibilities
o
Reference to Terms of Reference mentioned above
Project approach
o
PM outlines the Project Management Methodology, reporting, controls,
decision making processes etc.
o
Project Management Methodology documentation
Scope
o
PM goes through an outline of the scope of the project and captures the
input of other attendees to get to a detailed scope that can be agreed. From Project Definition & Business Case (or from previous discussions with
key stakeholders).
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 25 of 38
Timeframes
o
PM explains the desired timescales and records any constraints etc. from
attendees. - From Project Definition & Business Case (or from previous
discussions with key stakeholders).
Major Milestones
o
PM explains the likely milestones that will be used. - PM explains the
desired timescales
At any point in the meeting risks, issues or constraints may be mentioned and these
should be recorded.
Inputs:
The theory says that the Project Definition & Business Case should be prepared
before the kick-off meeting and be used as the main reference document
within the meeting. In reality this is not always available in sufficient detail
or completeness to be used in the meeting. Where this is the case the
following should be available as a minimum:

Vision / ideas, underpinning the project

An outline statement of scope,

Aims / goals for the project

The desired timescales

Sanction from the Governance Body to progress to the next decision point
Outputs:
The theory says that the Project Definition should be able to be prepared following
the kick-off meeting. In reality the information gathered at the meeting is
only part of the input to the PDR. From a practical point the following
should be minimum output that PMs should strive to achieve:

Sufficient information to confirm scope

Confirmation of team details and a common understanding of roles and
responsibilities

Common understanding of the approach to be taken to drive and govern the
project

An initial view of the major risks, issues or constraints that are likely to affect
the project
Additionally, given sufficient time, an outline of requirements should be captured /
confirmed (based around discussions of scope). Whilst this will not be
presented as part of the PDR it will be useful as input to detailed estimating
/ planning. The PM needs to guard against getting into too much detail and
straying into system design.
3.2.6 PROJECT EXECUTION - ongoing
The tasks described in this section are the recurrent tasks that must be undertaken
throughout the live of the project (for the purposes of this document and the
estimates that back it, these have been designated as weekly tasks).
 Where implemented the project manager will use the information recorded via
Activity Recording (where implemented) to control their project.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 26 of 38


Periodically the project manager with the Project Delivery Group will
undertake a PID/Business Case review to ensure that the project remains
viable. Periodically the PM will also be required to reforecast their projects.
The project manager will be actively managing their Stakeholders and will be
reviewing and assessing their importance to the success of the project.
Communications is a key element of this and underpins the management of
stakeholders.
Stakeholder Management:
Objectives:
• Understand what stakeholders are
• Understand who they are for your project
• Understand their influence on your project
• Define strategies for your project
What stakeholders are
• “For any decision or action, a stakeholder is someone who is affected by, or can
influence, that decision or action”
• They can be individuals or groups
• They are especially important where there are multiple interests and multiple
objectives.
Stakeholder analysis:
• Understanding who they are, their influence on, interest in and views of your
project
• Understand their requirements and expectations
• Understand when they need to be involved
Process:
• Identify internal and external stakeholders and map
• Remove uncertainty (meet, question, understand etc.)
• Analyse attitudes and influence; understand requirements / options
• Strategies and actions e.g. communications strategies (what do we want to do
and how do we do it) for individuals and groups
• Follow plans
• Review progress, re-analyse and replan

The project plan, including the communications plan, will be reviewed and
revised as the project progresses. This will include updating the Budgeting
Workbook where it exists and re-forecasting the finances of the project.
(Example plan template)
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 27 of 38

Risk and issue Management – the project manager will be managing project
risks and issues, resolving them within the team and escalating them through
the governance hierarchy as is appropriate.
RISK LOG
PROJECT NAME:
PROJECT MANAGER:
PROJECT ID:
Template
A N Other
ABC123
DATE CREATED:
LAST UPDATED BY:
DATE UPDATED:
Risk Details
Risk No
Date
Identified
Risk Type Raised By
Description
Deliverables /
Milestones at Risk
Effect
Consequence
Date of
Last
Update
Impact Criteria
Likelihood
E
R
F
B
Total
R-1
0
R-2
0
R-3
0
R-4
0
R-5
0
R-6
0
R-7
0
R-8
0
R-9
0
R-10
0
ISSUE LOG
Template
A N Other
ABC123
PROJECT NAME:
PROJECT MANAGER:
PROJECT ID:
Issue No Date
Issue Type
Raised By
DATE CREATED:
LAST UPDATED BY:
DATE UPDATED:
Description
Escalation
Status
Allocated
To
RAG
Status
Issue last
updated
Resolution
Resolution Details
Priority
I-1
I-2
I-3
I-4
I-5
I-6
I-7
I-8
I-9
I-10
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 28 of 38
Risks and Issues Management
Project Team
Project Manager
Decision Maker /
Resolver
PSU
PM records
issue/risk in
log
Analyse and
evaluate
impact
Estimate
magnitude of
change
Identify
action
required
Resolve in team
Decide on
action No obvious
action
Seek
advice
Resolve
without
escalation
Resolve in team
Process /
implement
change and
update log
Advise PM
Escalate outside of
team (e.g. ISS MT)
Inform
PSU
Inform / notify
resolver of
issue & action
required
(Meet / mail)
End
By exception for
major issues
Receive
Issue / risk
notification
Consider &
take action
Monitor situation
and progress
chase, as
required
Report
progress,
through HLR
process
R+PM
implement
change
Monitor
situation /
progress chase No
(if requested by /
agreed with PM)
Able to
resolve?
No
Yes
Closed
Feedback to
originator
R+PM to
escalate
to next
level
Yes
Record
resolution
Close event
in log
End
Inform PSU
To HLR
Process

PSU
record for
information
For Major
issues
PSU
record for
information
To HLR
Process
The project manager will use a series of meetings with the Project Team to
manage the project in all of its aspects and will produce reports e.g. Highlight
Reports, to show project status at appropriate intervals. The purpose of the
highlight report is to be the vehicle through which a project manager keeps
their stakeholders aware of the status of the project. It should contain
sufficient detail to inform any reader of: the purpose of the project, progress
and performance to date, planned activities for the next period, an overview of
progress against milestones and the issues that are affecting the overall
status. It will also allow the project manager to record their own assessment
of the status of the project at both high-level and in detail. The report is
produced at an agreed frequency that is appropriate to the project and will be
used to support the ISS Programme Review process. In addition it will be
used as a source for other periodic reports. See below
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 29 of 38
HIGHLIGHT REPORT
Overall Status: RED
AMBER
GREEN
Date:
Project Name:
ISS Executive/Service Manager:
Project ID:
Project Manager (ISS/Bus):
Project Start Date:
Project End Date:
Reporting Period:
Project Board Members:
Next Milestone:
Report Author:
Scope:
PROJECT STATUS INFORMATION (against original PDR)
0%
Variance:
Days/Weeks
Variance:
PROJECT STATUS INFORMATION (against changes approved by PB)
0%
Variance:
Variance:
Days/Weeks
Variance:
Variance:
On Budget:
On Time:
On Budget:
On Time:
£'s
£'s
MILESTONE INFORMATION
Baseline
Date:
Milestone:
Revised
Date:
Achieved Date: Reason for Slippage:
Key Activity This Period:
Key Activity Next Period:
RISK/ISSUE INFORMATION
Open Major Issues:
Description:
Date Raised:
Escalated to:
Impact (days):
Impact (£)
Status
Escalated to:
Impact (days):
Impact (£)
Status
Open Major Risks:
Date Raised:
Description:
Project Status


All project related documents whether project control or delivery orientated
will be subject to formal document management and the project manager will
maintain a repository of controlled documents that will contain the definitive
versions of documents. These are stored and controlled in a central location
A request for change regarding the specification or acceptance criteria for the
project will require formal management. The details and impact of such
change should be formally assessed before they are actioned and any
changes required to project costs, timescales and or scope will be subject to
authorisation. A process exists to assist in the management of project
change. (see below)
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 30 of 38
CHANGE REQUEST
PROJECT NAME:
PROJECT ID:
PROJECT MANAGER:
DATE RAISED:
AUTHOR:
ISSUE LOG NO:
DATE REQUEST LOGGED
PROJECT LEVEL:
WITH PSU:
Please refer to the comments within appropriate cells for guidance on completing this form
PROPOSED CHANGE INFORMATION:
Priority
(refer to comment)
Business area
Brief description of proposed
change
DETAILS AND IMPACT OF PROPOSED CHANGE AND OPTIONS AVAILABLE:
Option 1
Option 2
Option 3
Do nothing/retain original
specification
Details of options available
Benefits of option
Issues/Risks of option
Product(s) to be changed
Effort required (days)
Skill/resources required
Cost (£)
Timescales
Recommended option
(please detail order of preference where
1 is the preferred option)
Change within Project Team
tolerance?
If No - Date of Issue Escalation
to PSU
DECISION INFORMATION:
Project Team decision:
Escalation decision:
(if not within Project Team tolerance)
AUTHORISATION DETAILS:
Name
Signature
Date
Business Owner
ISS Executive
Project Manager
Project Plan updated to reflect
impact
Date decision/change logged
by PSU
ALLOCATION DETAILS
Allocated to:
Date allocated:
Date completed:
Date completion logged by
PSU
Management of change - process
Project team
Project manager
Project board
Complete change log
Change required
Determine course
of action
necessary
Assess magnitude
of impact of the
change
Update log (size of change
etc.)
Size of change
Complete change request
form
Gain agreement from
“suppliers”
No impact
on overall
time cost
or quality
Progress at the
discretion of the
project manager
Further analysis
required
Update log (action taken
etc.)
Significant impact on overall
time cost or quality
Feedback to
stakeholders
Send information
to Project Board
for consideration
Review of
change request
Reject the change
request
Accept the change request
Update log (action to be
taken)
Further action
required
No further action required
Implement the
change
Accommodate the
implications of not
progressing with
the change
Update log (action taken
etc.)
Feedback to
stakeholders

The Project Delivery Group will meet periodically (normally fortnightly) and the
project manager will service these meetings by preparing the paperwork –
change requests, highlight reports, agenda’s and minutes etc.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 31 of 38
General Project Management – this final section covers all of the other aspects of the
project managers role, for example the informal interactions with the project team to
encourage progress on specific work-streams and tasks etc.
In summary the project manager will:











Review the project initiation document and business case (with the Business
Sponsor and the Project Delivery Group) - obtaining agreement from Project
Delivery Group, SGLs / systems managers, ISS Executive etc.
Monitor, update and review the project plan (including accounting for time
spent of the project – if appropriate).
Monitor and update the project costs / business case (including, if
appropriate, the updating of the project Budgeting workbook).
Manage risks and issues.
Manage changes in a structured way
Capture lessons to be learned.
Conduct project meetings (project team, Project Delivery Group etc.) and
service them as appropriate.
Carry out further stakeholder management activities and execute the plans
for communications.
Maintain the project shared area.
Produce and circulate highlight reports (recipients are likely to be Programme
Office, Project Delivery Group and the project team at least).
Ensure that decisions are made when required and obtain appropriate signoffs from the stakeholders.
3.2.7 PROJECT CLOSURE - Closure and Handover to Business as
Usual
Purpose:
In this stage the outcomes / deliverables of the project are integrated
into the day to day operation of the University; this is fundamental to ensuring that
the project delivers the benefits set out in the original documentation.
Scope of stage:
The stage identifies whether the project has delivered against
the plans specified earlier. It will incorporate an assessment of how successful the
project delivery has been. It also accommodates the hand-over of the project to
business as usual.
Project Review and Benefits Realisation can assessed together or, more likely, there
will be a time lag between the completion of the project and the review of benefits to
enable the benefits to becoming apparent.
The original business case will be fundamental to this stage (actuality is measured
against the original objectives). This also enables any of the benefits not achieved to
be identified and planned for.
Who: It is the responsibility of the project sponsor to ensure the successful transfer
of the project to business as usual.
Outputs are:
 Benefits realisation process - which identifies activities required to ensure that
the benefits are achieved.
 (Where necessary) A benefits realisation plan, to include:
 how the benefits will be realised
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 32 of 38



 named individual responsible for delivery
 dates by which benefits are to be realised
 Measures by which benefit will be established
 How the plan will be managed.
Lessons learned
The extent to which the outcomes of the project have been adopted.
It may also include an appraisal of the skills of expertise of the project team
and working groups in delivering the project.
Project Management “Closure Tasks” on ISS Projects.
Once the project has delivered its objectives the project manager will undertake
several one off tasks to formally close the project and disband the project team.
These will be:
 Carry out the “End Project Review”, usually a formal meeting of the project
team and stakeholders to assess the achievements of the project.
 As a result of the above review the project manager will prepare the End
Project Report and ensure that this is formally signed off by the Project
Delivery Group. This document formally closes the project and gives an
evaluation of the management, quality and technical performance of the
project and the achievement against objectives as defined in the PID. This
details how well the project has been managed and will cover the following in
detail: achievements, lessons learned and the overall performance of the
project. When the EPR is complete it is signed-off by the Project Delivery
Group and submitted into the Programme Review Meeting for formal
Management closure.
 This is followed by the production of the Closure Notification as this indicates
that the project has been officially ended.
The final tasks for the project manager are housekeeping in nature. Project
documentation is sorted and archived and communication mechanisms that have
been used are decommissioned.
This formal closure ensures that resources are released back into the “pool” for use
on other projects and tasks.
In summary the project manager will:






Assist the Project Delivery Group by running the end project meeting.
Produce and agree the end project report.
Submit the end project report to the governing bodies (e.g. Programme
Office, ISS Executive).
Notify all stakeholders of project closure / completion.
Archive project documentation.
Decommission any specific project communication mechanisms.
4 Customisation of the methodology
This section comments on the customisation of the methodology especially relating
to “smaller” projects.
The previous situation where there was an informal “lite” version of the methodology
caused confusion and a tendency to treat all projects as a “lite” project irrespective of
size. This led to problems for example non-delivery, late delivery, scope creep or
delivery of inappropriate solutions. This situation will not be perpetuated and the
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 33 of 38
project management principles upon which the methodology is built will apply to all
projects.
However, although the principle is that all aspects of the methodology, especially
governance and decision making, apply to all projects some concessions can be
made to smaller, less risky projects, or some tasks that are managed using project
management principles for expedient and pragmatic purposes.
For example:
 At project initiation the three stage decision making process will apply,
however, for small projects the documents will be expected to be far shorter
and less detailed than for large projects.
 During execution we can consider a less frequent submission of highlight
reports. The frequency can also be varied depending upon the level of
activity of some projects.
 There will be a formal approach to determining whether concessions should
apply to a particular project. This will be process and criteria based and
decisions should be recorded for audit purposes. Suggested process: i)
define project characteristics, ii) assess the criteria, iii) customise the method,
document decisions (within a project document) iv) get agreement fro the
governing bodies.
We are striving to achieve an appropriate level of project management (and
documentation) for the size and complexity of the project and this is likely to vary by
project.
Criteria to use when considering the application of the methodology:
 Team size and complexity,
 Experience of the personnel,
 Duration,
 Number of distinct user groups / communities,
 Technical complexity of the solution,
 Impact on business (processes etc.),
 Technology or software new to the University,
 Degree of technical innovation,
 Size of risk.
5 Associated documents for reference:
To be found on the ISS PO web site
http://iss-admin.leeds.ac.uk/info/351/programme_office
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 34 of 38













Project Specification template / guide
Project Definition & Business Case template and guide
Project initiation template and guide
Project Management tools workbook (Risks, issues logs etc.) process and
guide.
Change management process, template and guide
End project report template and guide
Closure notification template and guide
Project Budgeting workbook
Key documents by project stage
Guidelines for the project initiation meeting
Project Management Model - estimate of time spent (in hours)
Information pack – containing details of project governance (including roles of
all parties and processes).
Stakeholder analysis workbook and guide.
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Page 35 of 38
6 Appendix 1- Estimated Effort
(Version circulated on November 2009)
PROJECT MANAGEMENT - estimate of time spent - in hours
any other tasks carried out by the PM fall into a different category for estimating purposes eg Business Analysis
STAGES
Small PM
Workload
PROJECT Specification COSTING - one off
Analyse if value and benefits are captured
Planning/Estimating of costs and resource
Costing Workbook - create and update
Project Specification - circulation and sign off
PROJECT Definition & Business Case PRODUCTION - one off
Review Project Specification - and other info
Planning/Estimating of costs and resource
Costing Workbook - update
Setup of Project Tools eg Risk Log
Communications Plan
Communications
Plan for PID Production
Project Definition & Business Case - production and sign
off
PID PRODUCTION - one off
Review Project Definition & Business Case - and other
info
Project Initiation Meeting
Planning/Estimating of costs and resources
Project Board - set up and train
Timesheet Management - set up
Stakeholder Analysis
Communications Plan
Communications
Costing Workbook
Risk Management
Issue Management
Document Management - set up
PID - production and sign off
PROJECT Implementation - startup - one off
Kick-off/Startup/Initiation Meeting
Project Startup Notification to all
Communications - set up
PROJECT Implementation - ongoing - weekly
Timesheet Management
PID/Business Case - review
Stakeholder Management
Project Plan
Communications Plan
Communications
Costing Workbook
Risk Management
Document1
09/02/2016
ISS/PO/AR
Version 5.0
Medium
PM
Workload
see scenarios
Large PM
workload
0.5
0.75
0.25
0.5
2
0.5
1.25
0.25
1
3
0.5
2.25
0.25
1
4
0.25
1
1
0.5
1
0.5
0.25
7
0.25
2
2
1
2
1
0.25
14
0.25
3
3
1.5
3
1.5
0.25
21
11.50
22.50
33.50
0.5
1
1.5
2
2
2
0.5
0.5
1
0.5
1.5
0.5
0.25
0.5
14
25.75
4
4
2
1
2
2
1
4
1
0.5
0.5
21
44.00
6
8
2
1.5
3
3
1.5
6
1.5
1
0.5
28
63.50
2.00
1.00
0.5
3.50
4.00
2.00
1
7.00
6.00
4.00
2
12.00
1
0.5
0.5
0.5
0.5
0.5
0.5
0.5
2
1
1
2
1
1
1
1
3
1.5
1.5
5
1.5
1.5
1.5
1.5
Page 36 of 38
Issue Management
Project Team Meetings/Reports
Highlight Reports
Document Management
Change Management
Project Board - Fortnightly - Meetings and paperwork
General Project Management
PROJECT Implementation - CLOSURE - one off
End Project Review
End Project Report - production & sign off
Closure Notification
Document Management - archive
Communications - decommission
Document1
09/02/2016
ISS/PO/AR
Version 5.0
0.5
0.5
0.5
0.5
0.5
1.5
1
9.50
2
2
1
0.5
1
1.5
2
20.00
4
4
1.5
0.5
1.5
1.5
3
33.00
1
1
0.25
0.5
0.5
3.25
2
2
0.25
1
0.5
5.75
3
4
0.25
1
0.5
8.75
Page 37 of 38
7 Appendix 2- Process flow – document production
and approval
Process – Project Documentation
authorisation
Project Specification
Spon/ISSGL/ISPM
Spon/ISMgr
Prepare project
specification +
summary sheet
(inc PBT)
Submit to ISPG for
approval
PO Update 5 Year
plan & finance
report
Project Definition & Business case
(1 or 2 stages)
ISPG
Authorisation to
prepare 1 or 2
step Business
Case
Spon/ISSGL/ISPM
Prepare / revise
Project Definition
& Business Case
+ summary sheet
(inc PBT)
Spon/ISMgr
Submit to ISPG for
approval
ISPG
Authorise to
prepare 2nd
step Business
Case or PID
Go to 2nd stage business case
Project Initiation Document
ISPM/Spon/ISSGL
PO Update 5 Year
plan & finance
report
Go to PID Prep
Prepare project
PID
(inc PBT)
PID cost
similar to
Project
Definition Cost
ISPM/Spon/ISSGL
Yes
Submit to Project
Steering Group for
approval
No
PO Update 5 Year
plan & finance
report
ISPM/Spon/ISSGL
Need to revisit
Project Definition /
Business Case
PM executes the
project
Project Implementation
Yes
One such action may be to
revisit the business case /
approach ISPG for more
funding
PM Escalates to
SGL &Sponsor
and with them
decide course of
action
No
Forecast still
shows on
budget (all
okay)?
PM Maintains
PBT:
Estimates,
Actuals
PM undertakes
monthly reforecast
PM Uses figures
in Highlight reports
(send to PSG and
PO)
Document1
09/02/2016
ISS/PO/AR
Version 5.0
PO Take figures
from PBTs for
finance report and
check 5 year plan
Page 38 of 38