Phase 1:  Conceive & Justify [Project Initiation]

Project Charter (PID)

Produced by the project manager at project start, the Project Charter (or Project Initiation Document) sets out: -

  1. What the project is aiming to achieve
  2. Why it is important to achieve it
  3. What benefits are expected to be delivered to what Stakeholders
  4. Who is going to be involved in managing the process and what are their responsibilities
  5. How and when is it all going to happen

In effect it is a contract between the project manager and the project board or sponsor.

It ensures that the project has a sound basis before asking the project board or sponsor to make any major commitment to the project.

And it acts as a base document against which the project board and project manager can assess progress, change management and ongoing viability.

Why do we need this?

  1. It allows the project manager and project board or sponsor to agree the terms of reference and scope at the start of the project
  2. It is good practice and increases the likelihood of the project being successful and delivering the required benefits and is used in many organisations
  3. It ensures that the project manager has thought through the project, its constituent parts and gained acceptance of the document
  4. It protects against others who may say the project should be doing something that was not in the original scope.

How should I go about producing a Project Charter (Project Initiation Document)

Here’s a suggested step-by-step approach:

Research

Prince2 is the standard. But check if there are any supplementary guidelines within your organisation

Get hold of a copy of the standards including the official Prince2 template (see Show me! opposite), and of examples of recent Project Initiation Documents that are considered to be ‘well done’ and related to successful projects

Read the documents available relating to the project you are undertaking

Engage other project managers: ask them how they went about it and any tips they may have to help you achieve what is required

Engage the project board sponsor to understand what is required, and how it fits in with other work. This may take several iterations as you develop the document.

Developing the document

  1. Get your filing system set up, use organisation standards if available
  2. Get all the main Project Initiation Document headings down which acts as a checklist to ensure you don’t miss anything
  3. Keep the document as concise as possible
  4. The document will be a Word document with a few tables for project plan, risk, communications plan etc.
  5. Complete the parts that you have the information for and highlight the parts you can’t
  6. Engage other stakeholders who have the information you require
  7. If possible get a friend to quality review your work prior to sharing with the project board

Reviewing the document

  1. Send the document to those identified on the Communication Plan
  2. Receive comments either in writing or at a Project Initiation Document review meeting
  3. Incorporate agreed changes
  4. Present to project board and gain
  5. Approval, amendments required or rejection
  6. Manage the process depending on the outcome from the board
  7. Get document sign off from the project board chair or sponsor

Change Control of the document

  1. The Project Initiation Document is a living document; it is very likely that changes to the project will be required during the life of the project
  2. Each time any change is suggested, go back to the approved PID and check the consequences of the change (see Change Management)
  3. Give each iteration of the document a new version number

An example of a Project Charter

Newcastle City Council FAME Children with Disabilities Project Initiation Document

A template for producing my own PID

Official Prince2 template

See also: Prince2 Home Page All Prince2 templates

The main chapter headings of a PID

Background: the context of the project

Project definition: explaining what the project needs to achieve

Objectives: method to be used, deliverables and outcomes, scope, constraints, exclusions, interfaces

Assumptions: especially what you’re expecting from others

Reference initial business case (see Toolkit guide on Business Case)

Project Organisation Structure of the project, who is involved

Communications plan: who are we communicating with, about what, when and how will it be done (see Toolkit Guide on Communication Plan)

Quality plan: to define the level of quality required and how it will be achieved eg don’t over-engineer but ensure fit for purpose

Initial project plan: showing tasks, key dates and who owns the task

Information Security Plan: especially import in multi agency information sharing arrangements

Project controls: showing how control will take place

Exception process: what happens when things don’t go as planned

Risk log: documenting initial risks, how they will be managed and how progress and issues will be monitored

Contingency plans: showing how it is intended to deal with risks if they occur

Project filing structure: how documents are to be filed and retrieved, who is allowed to update them and version control.