1.0 Title: Project Charter
2.0 Purpose: To establish a common understanding within a project team of a projects purpose, scope, goals, and limits at the outset
3.0 Usage: Every project should have one before the project starts serious spending time and money - very few do.
4.0 Frequency: Should be done once - either before or immediately after a project is funded. While it would seem reasonable that it shouldn't change or be revised - many projects veer off in unforeseen directions that bear little resemblance to their initial objectives.
Or as has been said:
"In projects that are allowed to change freely - the rate of change will soon exceed the rate of progress"
<source unknown>
5.0 References
5.1 https://en.wikipedia.org/wiki/Project_charter
5.2 How to Write a Project Charter
5.3 the project Task Summary (pm04) may contain redundant information with some versions of the project charter. If used - items such as cost need only be included as estimates on the assumption that actual, planned and "to complete" numbers will be found in the Task Summary.
6.0 Responsibility
The Project Manager is the default author for most projects.
The Project Owner has the final say on its contects.
7.0 Ownership
The project charter belongs to the Intellectual Property package of the project. If the Project Owner changes - the Charter belongs to the new Project Owner.
8.0 Effort
8.1 Prerequisites:
- "....For that reason, a project proposal should be written and approved before the project charter is established." <ref:5.2>
8.2 A Project Charter can become its own project if care is not taken. (Especially in large organizations with too many "stakeholders" - a.k.a. "busybodies")
- A good charter should not require more than "a days work" - whatever that is.
9.0 Risks
<using FMECA approach>
risk 1: PC doesn't exist
result: people will disagree on the objectives and work with a different endgame in mind.
detection method: usually takes until the 2nd or 3rd progress review to realize that something's wrong.
compensating factors: the objectives are usually stated in each work order from the top down.
risk 2: A whole lot of effort is spent on the PC and it gets stale immediately.
10.0 Contents
There appear to be a lot of variance on what should be in a Project Charter. After due consideration sig:pm has developed its own - not very similar version.
10.1 HRI Project Charter Version 0.1
1.0 Project Reference Number:
1.1 Project Owner Organization:
1.2 Project Name:
2.0 Project Summary:
3.0 Reasons for this project:
4.0 Project Objectives:
5.0 Project Scope:
5.1 Activities In-Scope
5.2 Activities Outside of Scope:
6.0 Project Management:
6.1 Project Status:
6.2 Project Duration:
6.3 Project Cost:
6.4 Project Deliverables:
7.0 Project Authorization:
7.1 Project Owner:
7.2 Project Manager:
7.3 Project Champion:
8.0 Project Risks:
8.1 Project Criticality:
10.2 - according to 5.1
10.3 - according to 5.2
11.0 MetaData
Some unofficial key numerical data elements produced by the charter should be:
- project cost
- project duration
other alphanumeric data elements could be (usually define already)
- project reference number
- project owner name & identification code
- project manager name and identification code
- project name
12.0 File Handling Policy
Many projects publish their Project Charter to the entire project team and keep it available as a reminder of what was supposed to happen.
If the project itself is "secret" - then the charter may also be hidden away somewhere where nobody can see it - which explains why some military projects go so woefully off track.
"This project is so secret we have no idea what we're doing....!"