pid highly complex project initiate

Project NAME – Project Initialisation Document (PID) Version v00a

Project Initiation Document (PID)

Highly Complex Project

Template & Guide

This Guide is intended to be read in conjunction with the following template for the development of a Project Initiation Document (sometimes also called a Project Proposal or Project Mandate.

Status: DraftVersion: v00aDate: Date

of 19 dd mmm yyyy


Table of Contents

0. Document control 30.1 Author(s) 30.2 Document Summary 30.3 Document History 30.4 Reference Documents 30.5 Distribution 30.6 Document Quality Assurance 3

1. Introduction 41.1 Background 41.2 Purpose of the PID 41.3 Context 41.4 Composition of the PID 4Briefly describe how the document is constructed. 4

2. Project Governance/Resourcing 53. Project Approach 9

3.1 Description of approach 93.2 Reasons for the approach 9

4. Project Controls 105. Project Plan 11

5.1 Plan Structure 115.2 Plan Description 115.3 Project Prerequisites 115.4 Dependencies 115.5 External Stakeholders 125.6 Planning Assumptions 125.7 Key Risks 125.8 Product Descriptions 125.9 Financial Budget 125.10 Change Budget 135.11 Resource Requirements 135.12 Project Level Tolerances 135.13 Contingency Plans 14

Annex A – Business Case 15Annex B – Quality Plan 16Annex C – Communications Plan 17Annex D – Project Plan 18Annex G – Product Descriptions 19

of 19 dd mmm yyyy


0. DOCUMENT CONTROL

0.1 Author(s)

Author’s Name

0.2 Document Summary

This document is the PID for Project NAME.

0.3 Document History

Version Date Changes since previous issue00a dd mmm yyyy First draft

0.4 Reference Documents

Reference all related documents (e.g. Brief)

0.5 Distribution

List all distributees (e.g. Project Board Members etc)

0.6 Document Quality Assurance

Complete table below to record document QA steps (see Quality Management Process for guidance).

Step Step Description Undertaken by Date Remarks01 Quality Review02 Project Manager Review03 Executive Review

User Review Group (Optional)QA Team Review (Optional)

of 19 dd mmm yyyy


1. INTRODUCTION

1.1 Background

Provide a short description of the business situation that led to the requirement for the Project.

1.2 Purpose of the PID

This PID defines the nature of Project NAME and fundamentally describes:

What the project intends to do.

Why it’s going to do it.

Who is responsible.

How it will be achieved

When it will be delivered.State if this PID has been created as a development of earlier documents such as the Mandate and the Brief.

This PID brings together a variety of information which justifies the project as:

being worthwhile (justifiable expenditure)

being well planned

being properly financed having properly defined and measurable business benefits.

1.3 Context

Provide short description as to what the current status is in relation to what support the Project has, stakeholder knowledge/acceptance and the development of organisational/governance structures (e.g. is the Project Manager already in place?).

1.4 Composition of the PID

Briefly describe how the document is constructed.

of 19 dd mmm yyyy


2. PROJECT GOVERNANCE/RESOURCING

If the Project’s Governance arrangements are dealt with as a separate deliverable, then the PID needs to at least reference this document.

See the following items for guidance:

SPEARMINT Governance and Management Process [GUIDANCE DOCUMENT] Project Team Roles and Terms of Reference [GUIDANCE DOCUMENT] Organisational and Governance Structure [DELIVERABLE]

Alternatively a simple diagram here will suffice. It should detail which individuals are covering the mandatory roles. See the guidance as to which roles can, and cannot, be combined under the same individual.

Select from one of the following Project/Programme organisation templates:

Figure 1 – Template organisation for typical project.

of 19 dd mmm yyyy

PROJECTBOARD

Mandatory Role

Optional Role Team Manager Team Manager Team Manager

Senior User

Senior Supplier

Project Manager

Senior Responsible Owner

Project Assurance

Programme Governance Structure


Figure 2 – Template organisation for a complex project.

of 19 dd mmm yyyy

PROGRAMME GOVERNANCE STRUCTURE

PROJECTBOARD

Mandatory Role

Optional Role

Project Management Office

(PMO)

Team Manager Team Manager Team Manager

Senior User

Senior Supplier

Project Manager


(SRO)

Project Director

Project Assurance


Figure 3 – Template organisation for a programme

of 19 dd mmm yyyy

Mandatory RoleOptional Role

PROGRAMME BOARD


(SRO)

Programme Manager

Project Board

Project Delivery Team

Project Manager

Business Change Manager

(1)Project Board escalates issues up to programme and programme provides strategic direction.

Project Board


Project Manager

(2)Programme Manager acts as project SRO and sits on Project Board.

(3)Business Change Manager ads as the SRO and sits on Project Board

Programme Management Office (PMO)

PROGRAMME ENVIRONMENT

PROJECT ENVIRONMENT

Project Board


Project Manager


Figure 4 - Example template project structure for simple

Role NameSenior Responsible Owner

Senior User

Senior Supplier

Project Manager

Project Assurance

Detail additional roles as necessary

Figure 5 – Table detailing key roles and responsibilities for Project NAME

of 19 dd mmm yyyy

PROGRAMME GOVERNANCE STRUCTURE

Senior Responsible Owner (SRO)

Senior User

Senior Supplier

Project Assurance

Project Manager


3. PROJECT APPROACH

3.1 Description of approach

Description of the approach being used to deliver the Project – for example, is the solution:

being delivered by internal staff?

being delivered by hiring in contracted expertise?

being purchased as a ready made solution?

bespoke?

contracted out?

a modification of a current product?

being designed from scratch?

For SMS projects this section should consider the following:

How will the design services be procured?

How will works be procured and why?

Will a ‘Design and Build’ contract be more suitable that separately procured designers and contractors?

What forms of contract will be used and what is the reason?

3.2 Reasons for the approach

Explanation why the selected approach is considered optimal.

of 19 dd mmm yyyy


4. PROJECT CONTROLS

This section should detail how the project board wish to control the project. It should describe the controls which will be put in place including: Standards for Planning, Risk and Issue Management and Progress Reporting. If these are dealt with as separate documents, then the PID needs to at least reference these documents.

If more information is required on common PM control processes, then the following documents contain additional guidance:

Programme & Project Management Processes

Cost Management Process

Risk & Issue Management Process

Scoping & Planning Process

Health and Safety Guidelines

Contract Management

What arrangements will be put in place to manage the various contracts?

To what extent will the various contractual functions be delegated to consultants (and why)?

Financial Control

Who will prepare and validate cost estimates?

What are the arrangements for controlling changes to the costs?

When will information on finance issues be required?

Risk Management

Who will carry out any risk analysis required?

When will these be carried out?

How will the subsequent information be acted upon?

Health and Safety

Key Health and Safety issues related to the project and proposals for managing any abnormal risks.

of 19 dd mmm yyyy


5. PROJECT PLAN

5.1 Plan Structure

Describe how the plan is structured in terms of levels of planning. How many levels of planning will be necessary to achieve the requisite level of control? What are these levels and how are they different from each other and why? Some projects may require only a high level Strategy Chart whilst other may require several levels of plan.

Describe how the plan is laid out in terms of stages. The levels and stage of the plan might be best described using a table as per the table below:

5.2 Plan Description

Stage DescriptionStage 1 Stage 1 will ….

Stage x – Stage 2 will ….

Stage n – The final Stage will….

Once a picture of the Plan’s structure has been drawn, describe how will the plan(s) be utilised on a day-to-day basis to manage the project?

5.3 Project Prerequisites

Are there any specific pre-requisites to achieve the plan? E.g. Senior Management Buy-in

5.4 Dependencies

The following external (to the Project Team/Scope) dependencies are key to the success of this Project:

External Party Dependency

For SMS projects this section should include, where relevant, the following sub-headings:

Surveys and InvestigationsThis could include examples such as railway possessions, land availability, site access and partnerships with external bodies.

of 19 dd mmm yyyy


Statutory and other approvalsList any approvals required for the scheme from external organisations

5.5 External Stakeholders

List the external stakeholders (any body which it might be necessary to contact for any reason, permission or information, during the project) in the project and what impact the project might have upon them.

5.6 Planning Assumptions

Provide a list of the planning assumptions made for each level/stage of the project. List may be provided within the main plan or included as an annex.

5.7 Key Risks

List the key risks to the delivery of the project. The risks should be categorised across the following headings:

Political e.g. changes in Government policy are likely;

Legal matters e.g. imminent changes in legislation;

Design phase issues e.g. probable difficulty in obtaining original design information;

Problems which might occur during the site works e.g. hazardous materials likely to be found;

Wider related risks e.g. change of key staff.

This section should also included, or reference as a separate annex, any risk analysis which has been carried out.

5.8 Product Descriptions

Provide detailed descriptions of the products to be produced by the project. Normally provided as separate annex (see annex G)

5.9 Financial Budget

Give summary details of the budget that the project will be working to.

Financial Year Total Budget (£k)E.g. 2004/05 £

Where applicable (e.g. Street Management Services projects), the costs should be broken down further and an expected spend profile provided. The two tables below provide an example of the appropriate level of detail.

of 19 dd mmm yyyy


CostsConsultants Technical Review £

Detailed Design £

Supervision £

Construction £

Client Costs £

Total £

2003/04 2004/05 2005/06 2006/07Current Expected Spend Profile

£ £ £ £

Profile submitted within Business Plan

£ £ £ £

5.10 Change Budget

Give details of the budget (if any) allocated to changes to the project’s scope.

5.11 Resource Requirements

List the planned resource requirements which the project will need in order to meet the plan.

Ideally listed in table format as per below:

Role Name Commitment (hrs/wk)

TOTAL

5.12 Project Level Tolerances

Detail the project tolerances as agreed with the Project Board. Where individual tolerances have been set on specific deliverables or stages these should be clearly shown.

of 19 dd mmm yyyy


5.13 Contingency Plans

Has a contingency been provisioned for? This might be either time, quality or cost based.

The following sections are annexes which should contain the relevant associated documents as appropriate to support the PID.

of 19 dd mmm yyyy


ANNEX A – BUSINESS CASE

Please refer to the following document for more detail on this Annex:

Business Case [DELIVERABLE]

of 19 dd mmm yyyy


ANNEX B – QUALITY PLAN


Quality Management Strategy [DELIVERABLE]

of 19 dd mmm yyyy


ANNEX C – COMMUNICATIONS PLAN


Communication Plan [DELIVERABLE]

of 19 dd mmm yyyy


ANNEX D – PROJECT PLAN


Project Plan [DELIVERABLE]

of 19 dd mmm yyyy


ANNEX G – PRODUCT DESCRIPTIONS


Product Descriptions [DELIVERABLE]

of 19 dd mmm yyyy