Project Initiation and the Project Initiation Document – PID

Project Initiation and the Project Initiation Document – PID (#5 in the Hut Introduction to Project Management)
By JISC infoNet

Project initiation is where all the necessary analysis is undertaken to allow the project to be planned. Initiating a project usually involves a considerable amount of work, and therefore expenditure, and this is why PRINCE2 recommends that project initiation be considered as a stage in its own right i.e. it should be formally given approval to go ahead and should be planned and budgeted for as a phase of the project.

The single most important piece of documentation you will produce at this stage, and probably during the course of the entire project, is a Project Initiation Document (PID).

The Project Initiation Document takes as its starting point the Business Case, if one exists, and builds upon it using the information and analysis data produced during the initiation activities.

It will look in detail at risks and a plan to deal with them will be one of the outputs of the initiation. During this period a thorough analysis must be taken and recorded of how any business processes, that the project will affect, are structured, staffed, and run. Measurements should be taken at this point that will be key or critical success factors of the project e.g. if the project aims to increase the rate of data entry of forms to a computerised system then a comparison cannot be made at the end of the project if initial measurements during the old business process do not exist.

A Project Initiation Document (PID) should include:

  • Details of project goals and objectives and the critical success factors by which achievement of the objectives will be judged.
  • Details of the project scope in relation to the organisation, functional areas and time as well as a statement about any related areas that are considered to be out of scope.
  • Details of identified risks and any constraints affecting the project.
  • Details of any assumptions made about the project. These might be assumptions that you as the project manager are making about what support you will receive from other parts of the institution or, if you are working with a third party supplier, assumptions about what the supplier will deliver.

Let’s look at a few examples of assumptions that could trip you up unless they are stated and agreed:

  • You are implementing a piece of software and you assume it is someone else’s job to specify, procure and install the necessary hardware before you start the project.
  • You have drawn up your project plan on the basis that you will have a full team in place from day one although the team isn’t yet recruited.
  • You are assuming that the project team has the authority to change administrative processes in user departments to ensure the effective working of a new system and/or you are assuming that somebody will actually implement those changes to working practice.
  • The assumptions you make about third party involvement are best resolved as part of drawing up a contract with them (in other words there should be a formal definition of responsibilities). It may however be worth stating here that you assume they will provide goods/resources of the stated quality at the stated times otherwise there will be an impact on your plan.
  • Details of the project’s organisation structure and roles and responsibilities within the team.

JISC infoNet aims to be the UK’s leading advisory service for managers in the post-compulsory education sector promoting the effective strategic planning, implementation and management of information and learning technology.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

Leave a Reply