The Elements of a Project Charter

Before a project even begins, a project charter is a document that incorporates the project and appoints the project manager.

Many projects operate without a project charter, even multimillion dollar projects.  But the formal authorization of the project by the performing organization can be important to ensure the lines of authority are clear and identify what the organization is thinking when creating the project.  I can think of some project issues that could have been avoided if the project manager and/or sponsor would have created one.

In the Project Management Body of Knowledge (PMBOK), the tasks involved with developing a project charter are contained within its own process, Develop Project Charter, which falls within the Project Integration Management knowledge area.  It is one of only two processes within the Project Initiation process group.  The project charter itself is the output to the process, described in section 4.1.3.1.

Here is the overview of the process:

Often a contract between an owner organization (such as an oil company) and a project management organization (such as an engineering firm) can seem to take the place of a project charter.  But the PMBOK states that a project charter should not be substituted by a contract because there is no exchange of money.  The contract states the project’s firm deliverables, whereas the project charter has the project management function of building the project on a firm foundation, therefore the two documents should be kept separate.

A good project charter contains the following information:

1. Project purpose or justification
   Stating the business need that the project addresses can give everyone direction and clarity regarding project decisions and build a foundation of strong leadership from the performing organization.  When everyone knows why the project is being performed, they can be laser focused on the end result.
2. Measurable project objectives and related success criteria.
   A statement of the project’s goals and criteria for success creates a strong statement of what the company is expecting from the project.  It ensures everyone is working toward the same goal and is clear on what those goals are.
3. High level requirements
   There are several components which have a place within the project charter (i.e. above the project) as well as the project management plan (i.e. within the project).  The project requirements as envisioned by the organization can be placed within the project charter to make it clear what the organization is thinking by creating the project.
4. Assumptions and constraints
   Many project issues arise from unclear assumptions, and many of these assumptions are clear to the management of the organization before they create the project.  Therefore, they should be stated within the project charter and thereby passed down to the project management plan.
5. High-level project description and boundaries
   A high level scope is generally defined, if not on paper than in executive’s minds, well before the project becomes a project.  Writing this scope into a project charter makes it crystal clear what the project’s creators are thinking.  It should not, however, be considered a final project scope.
6. High-level risks
   Most projects have one or two major risks that define the project.  For example a structural failure for a bridge overpass project, or website payment software that contains security glitches.  These are the risks that are fundamental to the project’s success and are generally thought about before the project becomes a project.  Therefore, they should be included within the project charter, but they should not take the place of a project risk analysis within the project management plan.
7. Summary milestone schedule
   Most projects have milestones that are defined by executives before the project becomes a project, whether explicitly stated or implied.  For example a mine access road needs to be completed before construction equipment can move in.  These milestones define the project and should therefore be placed into the project charter, however they do not take the place of a detailed project schedule during the project planning stage.
8. Summary budget
   All projects are created in the context of organizational budget constraints.  This context should be communicated within the project charter in order to pass on the budgetary constraints into the project planning phase.
9. Stakeholder list
   Most projects have one or two major stakeholders that need alot of attention.  For example, a project for a new coal mine that requires a golf course to be moved (a real project of mine) needs to make sure it works very closely with the golf course.  Although the project charter is not the appropriate place for a comprehensive list of all stakeholders, the ones that are of primary importance to the project should be identified.
10. Project approval requirements
    Because most projects require approval from external authorities, those approvals which will have a major impact on the project can be explicitly stated within the project charter.  For example, in the mine building project mentioned above, the government approval for mine construction is so integral to the project that it could be mentioned in the project charter.  The project charter is not the place for a comprehensive list of approval requirements, however.
11. Assigned project manager
    As stated in the PMBOK above, one of the primary purposes of the project charter is to assign responsibility to the project manager.  Therefore, the project manager should be named and their authority to use organizational resources should be made clear.
12. Project Sponsor
    The project sponsor is one level above the project manager, often an organization contact for the project.  They should be named and their responsibilities in regard to the project made clear.