Project Charter
The Project Charter, often called Project Specifications, PMP’s or PID’s. Getting the Project Objectives clear in a ‘Scope’ document is essential. Establishing what is to be done on the project ‘In-Scope’ and what is not to be done ‘Out-of-Scope’ is vital. This helps in communicating the purpose of the project. ‘Scope Creep’ is a big problem on projects, and communicating the project specification is essential.
This blog will look at the contents of the Project Charter, providing a rough template and examples of the information that needs to be in a Project Initiation Document (PID).
Here is a short video clip on the subject.
What Do You Call It?
Different organisations have various names for the document which describes the scope of the project. The terms can be used interchangeably, as long as the meaning is understood by everybody:
- PID Project Initiation Document (Prince2) (I use this when talking to PRINCE2 trained people)
- PMP Project Management Plan (APM)
- Project Specification – I often used this term during my Project Management training courses
- Project Charter – I use this term when teaching Project Management students
- The Project Definition Document
- Project Execution Plan
I will explore a couple of these before looking at the contents.
Project Initiation Document (PID)
PRINCE2 defines the PID as:
A focal point for all of the information on the project. Starts with the business case – the business reason for the project.
The PID has 2 purposes:
- To ensure that the project has a sound basis before asking the Project Board to make any major commitments to the project.
- To act as a base document against which the Project Board and Project Manager can assess progress, change management issues and ongoing viability questions.
The PID is the what, why, who how, and when of the project.
Project Management Plan (PMP)
The definition from the Association for Project Management (APM) states that:
The PMP is the output of the definition phase of a project or programme.
This ‘output’ is therefore a clear definition of what the project is all about.
Contents of a Project Management Plan
The content of a PMP clearly depends on your project, the scope of work, and your responsibilities. Easy projects (Runner projects) may have less detail (or will copy previous PMP templates). More difficult projects (Stranger projects) will need more detail in the plan.
A Project Specification (or Project Charter, or Project Initiation Document, or Design Document) includes the essential information about the project:
- What the project is and how it helps the business achieve its strategic goals – the business case
- Why it is being done
- A sign-off page – for team commitment
- The SMART Project Objectives
- When is it due -The overall start and end dates for the project
- Key milestones – key dates for each phase of the project
- How much is the total project costing, and how much does each phase cost? Where is the funding coming from and how the business can manage its cash flow during the development period?
- Deliverables (objectives). What are the main deliverables from the project, and what are the SMART objectives for the development and delivery of the project
- High-level stakeholders – the main parties interested and involved in the project
- High-level risks – the high level risks that may affect project success
- Roles and responsibilities. An overview of who is doing the work on the project
It will allow the group of people assigned to the project to start to align to the project objectives and become a team. It should provide enough information for a high level WBS to be created. The PMP will develop through the life of the project, as new information is discovered, and changes are applied.
The PMP should also include the following:Work Breakdown Structures
- In scope – what is included in the project
- Out of scope – what is excluded from the project
- What is Unknown – any uncertainties or unknown issues. Once these are stated, there can be no doubt that they are unresolved issues.
- What is NOT in the project. Explicitly stated, may be similar to “out of scope”.
These are important sections to avoid confusion and misunderstandings.
The Technical Chapters
The Project Charter technical chapters will depend on the type of project. A software project may have detail on database versions, operating system versions, and modules. A construction project may have details on the types of materials etc.
Stay in Issue Control
The worse thing that could happen is that somebody on the project is working on an old version of the project plans. There are benefits to issuing paper copies:
- Different colour paper could be used to highlight versions – this shows up well in meetings
- It avoids emailing the document and creating many master copies (Issue as a pdf rather than an editable document)
- SharePoint Systems can be used – but not everybody on the project may have access.
Make sure that you issue control the document, with a clear version number on the front cover.
Make the Document Readable
You need the team and stakeholders to read the document – so make it readable.
- Lots of White Space
- Use a Clear Language – Jargon free
- Add a Glossary of Terms
- Use Bullet Points
- Add Diagrams
- Take and Insert Pictures
All of these will encourage those on the project and the team to read the document.
Get the Team to Write It, and Sign It
For real team-working and leadership, get the project team to write the project charter. This will encourage:
- Commitment to the plan
- A sense of belonging and involvement
- Increased communications between team members
It is the people who will deliver the tasks on the project, so their involvement and understanding regarding the project scope is vital.
Scope Creep is a major reason why projects fail. Defining the purpose of the project is vital. That is the purpose of the project charter, specification, management plan, initiation document.
