Project Initiation Document Template

Project Initiation Document

Project/Programme Details
Project/Programme Name
SRO (Sponsor)
Project/Programme Manager
Group/Directorate
Start Date Completion Date

Document Details
Version Status Date Author/Editor Details of changes
(Draft or
Approved)

1. Background to the proposed work

Taken from the Project Brief, updated as necessary during preparation of the PID.

Describe the potential change, idea or problem. Describe the circumstances, decisions, previous work that
has lead to this PID being produced. This should make it clear:
 what is the overall purpose of this project?
 what previous actions/decisions lead to the current position?
 why it needs to be done?
 why it should be done now?
 what the end result of this project should be?
 what are the implications are of not doing it?

2. Objectives

Taken from the Project Brief, updated as necessary during preparation of the PID.

How does the purpose of the project break down into specific objectives?

What specific, measurable results are expected at the end of the project?

The objectives should be phrased such that they can be used to measure completeness and success at the
end of the project.

[Organization Name] [Project Name] PID, Page 1 of 7

 Project Initiation Document Template

3. Scope

Taken from the Project Brief, updated as necessary during preparation of the PID.

The scope may defined in terms of such things as:

 the boundary between this project and other projects and programmes – this helps prevent gaps or
overlaps in all the work that is necessary to achieve higher-level corporate or programme objectives
 the work that the project must do, and what it is specifically excluded from doing (you might refer to
the list of deliverables if you feel it is complete at this stage)
 the geographic spread of impact (changes affecting England and Wales but not Scotland and Northern
Ireland)
 the coverage in terms the organisation(s) and types of role/staff/people/organisations that will be
affected by changes arising from the project (all staff in Grades X-Y, stakeholders of type S, market
segments M-N)

The scope should be sufficiently detailed to form a measurable baseline for subsequent change control so
that the damaging effects of ‘Scope creep’ can be minimised.

Be specific about what is excluded from this project to avoid any misunderstandings later on.

4. Business Case (Benefits and Costs)

The information provided here (either directly or via a link to a separate Business Case document) must be
sufficient for the Project Board to decide whether or not it is justified for the project to proceed and
whether it is affordable.

The benefits identified in the Project Brief should be quantified and their timing of realisation estimated.
They should be balanced against the costs and timings estimated during preparation of the Project Plan
(see below).

For smaller projects, the Project Board might find the following to be sufficient:

 Refer to the business objective(s) that the project contributes towards

 Describe the options considered for meeting the project objectives and why the recommended option
was selected
 List the tangible benefits to be derived, expressed in quantified terms and timed. Make it clear which
benefits (if any) will be realised during the project, and which will be achieved after the project.
 Identify any intangible benefits anticipated as a result of the project.
 Identify any key risks or critical success factors affecting achievement of the benefits (NB there may be
some overlap with the section of Risks in the PID)
 Identify any known costs and person effort and timing (derived from the planning process)
 Add any other information you consider will add further weight to this justification

For large projects a business case summary may be inserted here with a document reference or link to the
full Business Case (see separate template) which should be a free-standing document in its own right.
[Organization Name] [Project Name] PID, Page 2 of 7
 Project Initiation Document Template

5. Assumptions

Taken from the Project Brief, validated and updated as necessary during preparation of the PID.

6. Constraints

Taken from the Project Brief, validated and updated as necessary during preparation of the PID.

These are things that you must take into consideration during the project but cannot change? These may
include deadlines, regulatory requirements, procurement rules, technology standards or limitations
imposed by some other project or programme.

7. Risks

A summary of the most significant threats and opportunities facing the project and how it is intended to
manage them. The detail should of risks and management actions should be in the project’s Risk Log (see
separate template). A document reference or link to the Risk Log should be provided here.

8. Other areas of business affected

Taken from the Project Brief, perhaps updated during preparation of the PID.

9. Deliverables

Taken from the Project Brief, perhaps updated during preparation of the PID.

[Organization Name] [Project Name] PID, Page 3 of 7

 Project Initiation Document Template

10. Project Quality Plan

This defines the quality expectations the project must achieve and how they will be met. It describes the
qualities that must be possessed by the project’s outputs in order that the desired outcomes are achieved.
It also describes the quality aspects that apply to the processes to be used in the project to create the
desired outputs and outcomes.

This section should not be used to say precisely who is doing what activities on what day to manage
quality: that information should be defined in the Project Plan (and/or more detailed Stage/Team Plans if
they exist).

For a small project it may be possible to define the project’s approach to quality management here,
otherwise a separate Project Quality Plan should be produced (see separate template) and a document
reference or link provided here.

11. Major dependencies

A description of any known future dependencies with other projects, programmes or initiatives which may
be internal or external to the parent organisation. This may be defined in terms of such things as
products/deliverables, resources, decisions, legislation, environmental conditions, economic conditions etc.

12. Stakeholders

A list of known stakeholder organisations and, where appropriate, individuals having a significant interest
in or influence over the project. For each stakeholder it should be made clear what is the nature of their
interest in the project (eg they will be affected by the outcome, must make changes, will provide resources,
will take decisions, must be kept informed.)

13. Project Organisation

A description of the roles, responsibilities and relationships within the project management team. An
organogram with brief description of the requirements of each role often is sufficient. If more detailed job
descriptions are to be included in the PID then they are best held in an Annex.

The basic minimum to be described would be:

[Organization Name] [Project Name] PID, Page 4 of 7

 Project Initiation Document Template

13. Project Organisation

Senior Responsible Owner (SRO)/Project Sponsor: (This role may be undertaken by a steering group as
well as a sponsor) is the person who has ultimate responsibility for the project: They should perform the
following key functions:

 Approving the PID and plans

 Ensuring that the project is subject to review at appropriate stages
 Making certain that any action points from reviews are met
 Keeping track of the business case and ensuring it remains viable
 Ensuring that benefits are realized during and after the project
 Final decision-maker on changes
 Ensuring adequate funding is available
 Approving costs at key milestones
 Committing resources as agreed in the plans
 Deciding what type of project assurance is required (including types and timing of gateway reviews
and/or health checks.
 Taking ultimate responsibility for the project

Project Board: If the project is large and/or cross cutting, it may have more than one individual who needs
to be part of the decision-making authority. If this is the case, you may wish to set up a Project Board
probably chaired by the SRO. This group will have the same overall set of responsibilities as the SRO but
will include stakeholders from those providing the solution to the business need (eg the PRINCE2 Senior
Supplier role) and those who will operate in a different fashion as a result of the project (eg the PRINCE2
Senior User role). Even with a Project Board in place the SRO is ultimately accountable to the business for
the success of the project.

Project Manager - is responsible for the day-to-day management of the project, reporting to the
SRO:

 Agreeing with the SRO what the project is hoping to achieve, the project elements (deliverables), scope
and necessary resources
 Following corporate project management guidelines and producing the agreed documentation for
review by the SRO/Project Board and senior management
 Planning and delivering all elements of the project to budget and agreed timescales
 Organizing and directing the project team
 Ensuring the external suppliers (if used) deliver the agreed solutions
 Monitoring, controlling and reporting progress/costs to all interested parties
 Ensuring business expectations are managed so no surprises on completion
 Building in quality checks so that the final solution is fit for purpose
 Controlling any risks, issues and changes that may arise during the project
 Resolving problems and conflicts that arise
 Assisting the sponsor in ensuring the business case continues to be viable
 Ensuring that the project is closed and lessons learned are captured

Team Manager (optional): In many instances, the project may involve specific input from other areas within
the organization. If Information Technology is required, they may wish to set up their own team to provide
the IT solution for the project. They then need to nominate a Team Manager/Team Leader to head up this
team and he/she needs to report to the Project Manager for all project related matters. The same would
[Organization Name] [Project Name] PID, Page 5 of 7
 Project Initiation Document Template

13. Project Organisation

apply to external suppliers working under contract to provide some of the project outputs.

14. Project Plan

A schedule of activities and resource requirements for the entire project. The level of detail will depend on
the size and complexity of the project but needs to be enough for the Project Board to understand the
commitment they are making if they approve the PID.

A summary of the plan (schedule key dates, activities, milestones, resource requirements, control points)
should be provided. The detail should be in the Project Plan itself a link to which (or a document
reference) should be provided here.

The plan presented with the PID is unlikely to be the final project plan (unless it is a very short, well defined
project). It is expected that the project plan will be updated at key milestones as the project progresses,
particularly at key decision points such as when awarding major contracts.

For large project sit is expected that more detailed stage plans will be produced to define in detail section
of the project plan. As these will normally produced as the project progresses they cannot be included in
the PID.

15. Project control and reporting

Schedule of Project Board meetings explaining purpose of each meeting and decision required from the
Project Board. These should also be shown as activities in the Project Plan.

Highlight Report recipients, frequency, content and method of communication.

Checkpoint Report source, recipients, frequency content and method of communication.

Other project management communications planned for this project.

Project tolerances and exception reporting process

Change control process (covering handling requests for changes and faults detected in signed-off
products/deliverables).

Where appropriate, an indication of the likely timing of any project health checks or Gateway Reviews
should be given.

[Organization Name] [Project Name] PID, Page 6 of 7

 Project Initiation Document Template

16. Communication Plan

An explanation of how the project will engage with and maintain communication with internal and external
stakeholders.

For each type of communication the plan will identify the purpose, message, timing, source, recipient(s),
content, response required and method of communication.

17. Document management

A description of the method and responsibilities for organising, storing, retrieving, securing, issuing and
version controlling changes to documents created in the project. An indication of which specialist and
project management documents will be controlled formally.

For projects that will create products other than documents (eg ICT, accommodation, equipment) a formal
configuration management scheme may be required.

18. Any other issues specific to this project

Add new sections to the PID as required. For example you may wish to describe the Procurement Strategy
proposed for your project.

[Organization Name] [Project Name] PID, Page 7 of 7