Skip to main content Skip to navigation

Warwick Foundation Studies

Project Initiation Document (PID)

You've now received the necessary support to continue with your project and to develop a more comprehensive plan about how you will achieve your desired objectives. You'll now think about the timescale for the proposed project, the specific risks that it might pose and the people who will enable the project to succeed. The PID is intended to fully specify the nature and scale of the project before the delivery begins - reducing the likelihood of unwanted surprises once the project gets underway.

Overview

Your Project Initiation Document (PID) provides detail about how the project will run and is the 'contract' for the work. The PID provides confidence to the project manager, sponsor and other stakeholders and it ensures that there is sufficient information provided to define the size and nature of the project. While producing a PID can be a significant piece of work, it is a core component of a successful project as it ensures time is not wasted setting up the project using false assumptions of scope, timescale and constraints - that could ultimately derail it.

The PID contains four elements:

  1. A detailed project overview - this is primarily a more comprehensive version of your business case which also considers in more detail people, constraints and scope and summarises the three supporting documents (below)
  2. A Risk Log - a record to outline the risks to the success of the project and activity taken to mitigate against them
  3. Responsibility Assignment Matrix/RACI Matrix - this details who is responsible for different aspects of the project and who takes overall accountability for its success
  4. A project Plan/GANTT Chart - this maps out the timeframe for delivery and the essential elements of the project, setting critical deadlines and milestones

All four elements together make up your Project Initiation Document.

Part 1: Detailed Project Overview

Your overview should contain some elements already considered in your business case.

Project Definition

In this section, you will detail the size, scope and nature of the project.

Project Objectives

You will have already considered the business needs in your business case - your project objectives describe the specific things the project intends to achieve to meet these needs. You should be as specific as possible so that you and project sponsors/other stakeholders are clear about the specific outcomes to be expected.

Project Scope

The project scope details which elements are involved in the project activities. This might include particular teams, departments or units across the university or other external stakeholders. You should also note here things which people may reasonably believe to be within scope but are in fact not - by defining this now you can avoid 'bringing people onboard' at a later stage for primarily political reasons.

Within this section remember to include areas that might not be involved day-to-day but which might need to be involved in the background - such as by providing finance or resource.

Approach

This describes how the project will be undertaken and any particular methods to be used. Here you should explain any particular stages or governance processes (e.g. a project team supported by monthly steering group meetings) and any general approach to milestones.

Outputs

These are the things that the project will deliver. These are sometimes called 'products' or 'project deliverables'. The outputs are different to the project objectives and are the tangible outputs you expect to achieve once the project comes to an end.

Dependencies

These are things (outputs) from other projects or activities that this project needs in order to deliver or output from this project that impact on the success of another. These can be split into 'inbound' (things this project needs) and 'outbound' (things other projects need from this project). The construction industry is a useful example here: If you are project-leading the walls and windows of a new building the completion of the foundations would be an inbound dependancy, as you can't start your work until the groundwork is done. Similarly, the team putting on the roof can't start its work until the walls are completed - so the completion of the walls would be an outbound dependancy.

Constraints

These are the limits imposed on the project. These might include lack of funding or an inability to recruit staff - both of which would constrain the success of the project.

Assumptions

It is important to spell out any assumptions about the project from the beginning to avoid the risk of miscommunication or false assumptions delaying or derailing a project. Some assumptions are operational (e.g. 'contracting staff will be paid by BACS on the 23rd of the month, managed by finance team') others are strategic (e.g. 'in the event of a dispute, the project lead will be responsible for making the final decision in relation to fire safety'). It is helpful for all assumptions to include a statement explaining the impact if the assumption proves false (e.g. the deck of the aircraft carrier will cover the ship in fire-repellant foam in the event of a fire. If this does not occur the ship will explode').

Project Organisation

You should include:

  • Project Sponsor - the ultimate owner of the project and accountable for its success
  • Senior customer/beneficiary representative - the person/people who represent the end-user of the project
  • Senior supplier representative - the person representing the main contractor (if applicable)
  • Project manager - the person with day-to-day responsibility for the project
  • Project team members - the people doing the work. Their specific remits should be detailed.

The project board/steering group will comprise the Project Sponsor, customer representative, supplier representative (if applicable) and project manager - along with any other members felt necessary to oversee the project.