<Project name>
Project Initiation Document (PID)
Project details
Project name:
Project lead:
Project manager:
The project lead is the person ultimately responsible for meeting the project’s objectives
and the successful delivery of anticipated benefits. This role is sometimes referred to as
project executive or senior responsible officer/owner.
PID v1.0 Last updated 17.10.13
Page 1 of 6
Strategy, Planning & Governance
Document details
Status
Document
(draft or
version
approved)
Date
Author and
role
Details of major
changes
Approved by
Purpose of the Project Initiation Document (PID)
The PID provides the main description of the project and is completed at the start of the
project. The Project Manager is responsible for compiling the document, agreeing the
contents with the Project Executive and other interested parties, and then taking it to the
appropriate project governance group for approval to begin detailed planning.
The PID should be concise but provide enough information to make a rational decision
about whether this is a viable and worthwhile project, judged by looking at the balance
between cost/benefit/risk, an assessment of whether the project can deliver the outputs
detailed, and whether these outputs can deliver the benefits required. It provides a
foundation for more detailed planning.
The document will establish the terms of reference for the project and start to highlight
potential risks. It is a key discussion document that is used to inform stakeholders about
the aims of the project, establish their buy-in and develop their engagement. If external
suppliers are to provide expertise, the PID can be used to define the requirements for their
services.
The PID should be maintained as a live document, updated and re-circulated to the project
team
Throughout this document guidance is provided in grey. On completion, these grey boxes
can be deleted or they can be retained as a guide for readers.
Please contact the Projects and Change team within Strategy, Planning & Governance for
guidance projects@sheffield.ac.uk .
PID v1.0 Last updated 17.10.13
Page 2 of 6
Strategy, Planning & Governance
Project Initiation Document
1.1
Project driver
What is the trigger for the project to be initiated? This could be a directive from senior
management, a change in legislation/regulations, or a problem/ need or opportunity to be
addressed. Ideally this should link with the University’s strategic objectives
www.shef.ac.uk/ourplan .
<Enter text here …>
1.2
Project Aims and Objectives
What is the overall purpose (the aim), and the objectives, of the project? Objectives should
be SMART – specific, measurable, achievable, relevant and timely.
Aim
<Enter text here …>
Objectives
<Enter text here …>
1.3
Project Scope
What are the boundaries of the project? For instance which people, processes or systems
will be included?
Make the exclusions clear too – who/what will NOT be affected.
In scope
<Enter text here …>
Out of scope
<Enter text here …>
1.4
Project Deliverables and Outcomes/Benefits
What will the project deliver (the output(s))?
What will be the outcome(s)?
What are the planned benefits? How will we know the project has been successful?
Benefits derive from the project outcomes and should be tangible and measurable.
Benefits are often realised once the project has been implemented.
Deliverable
Eg Revised and documented
recruitment process
PID v1.0 Last updated 17.10.13
Outcome
Eg A process that reflects
best practice, complies with
new legislation, improves the
speed of recruitment and
reduces recruitment costs.
Page 3 of 6
Benefit
Eg A 20% reduction in
recruitment costs in year 1,
recruitment time from advert
to offer improved by 25% in
first 6 months, process
benchmarked against
industry best practice, no
legal challenges to
recruitment practices.
Strategy, Planning & Governance
1.5
Project Approach
This describes how the project will be run.
If there are a number of ways in which the project can be approached, provide the key
options being considered early in the project, eg how will the project objectives be
delivered? All will have pros and cons so these should be captured too. What is the
preferred approach, and why?
If the project is to be split into workstreams, you could detail these here.
<Enter text here …>
1.6
Key Milestones
State the Project’s key milestones or target dates in the table below. Milestones are points
in time so the language used to describe them should indicate this (eg. “Software
development complete” rather than “Develop software”). Include the target milestone
dates for gaining approval to plan and approval to deliver, and a project finish date.
Ref. Milestone Description
Planned date
1
2
3
4
1.7
Project Team and Governance
In this section you show how the project team will be organised. You should insert the key
roles, as far as they are known in the early stage of the project. You may need to update
this section during detailed planning.
Indicate any anticipated people resources. Try and estimate length of involvement in the
project, as well as estimate of time involved (eg 2 hours per week for six months). Early
discussion of resource needs/availability should take place with the line manager of the
resources identified. Any issues around availability and suitability of resources should be
documented below the table.
You could also enter frequency of project board meetings or reporting requirements in this
section.
Project Team
Names
Eg Mark Brown
Role
Key
Time Estimate
responsibility/accountability
Project Sponsor
This is typically a
UEB member or
senior manager
Project Lead
PID v1.0 Last updated 17.10.13
Page 4 of 6
Strategy, Planning & Governance
The person
ultimately
responsible for the
successful
Project Manager
Project Board
Members
Project Team members
1.8
Summary of Risks
You should include a section on key risks (those that are likely to have a medium/high
probability and impact). These will be updated regularly during the life of the project,
usually in a separate risk register.
A risk is an uncertain event that, should it occur, will have an effect on the achievement of
objectives.
If you are considering different approaches, fill out a risk table for each option.
No.
Risk
Comments
1
Eg Data for analysis not available in the required
format
What is the risk of NOT proceeding with the project?
<Enter text here …>
1.9
Costs
Indicative costs (if any) for the project. This could include spend on additional resources,
external suppliers or systems.
<Enter text here …>
1.10 Project Interfaces and Dependencies
This covers the known interfaces and dependencies relating to the project such as the
activities of other projects, teams or organisations. Dependencies may be:
 incoming (where this project is dependent on something happening elsewhere)
 outgoing (where another project is dependent on a task/milestone here).
Note this does not include dependencies within the project (i.e. task A cannot commence
until task B has finished) as these will be captured in the project plan.
PID v1.0 Last updated 17.10.13
Page 5 of 6
Strategy, Planning & Governance
<Enter text here …>
1.11 Stakeholders
Identify key stakeholders – people or groups who may be affected by or interested in the
development of the project.
<Enter text here …>
PID v1.0 Last updated 17.10.13
Page 6 of 6
Strategy, Planning & Governance