Project Charter Guide
An Enhanced Framework for the Management of Projects
Introduction
This guide explains the steps needed to create a project charter for the delivery of a project. The guide is meant to be used together with a document called the Project Charter Template, and, where relevant, it includes examples to illustrate the content. The first section, titled --Use of the Project Charter,-- gives background information on the purpose of the charter, who is responsible for creating it, work that should be carried out beforehand in order to prepare the charter, how the charter should be customized, and key sections required at the beginning.
Use of the Project Charter
What is a project charter?
The project charter is a -document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.-1
In addition to its contract purpose, the project charter includes most elements of a preliminary project scope statement, which describes what is and what is not included in the project. It also helps to control changes to the scope of the project throughout its duration or life cycle. The intent is to cover, in a single document, all activities of the initiating process group2 as defined in A Guide to the Project Management Body of Knowledge (PIMBOK).
Why create a project charter?
As a comprehensive overview of the project, the project charter allows all parties involved (stakeholders) to reach agreement and document major aspects of the project such as the objectives, the scope, the deliverables, and the resources required. The charter supports the decision-making process and is also often used as a communication tool.
Who is responsible for the project charter?
The project charter should normally be developed by the project sponsor or a manager external to the project team. In practice, however, the project manager often plays a major role in the development of the project charter. The project manager works closely with the project sponsor, who provides background information for the project (e.g. purpose of the project and linkages to business needs, strategic priorities, objectives, and outcomes). The project manager also interviews stakeholders to gain more information in order to develop the charter.
Tailoring the project charter to specific projects
Regardless of the size and type of project, the elements of a project charter are the same, just as the fundamental project management processes and principles remain the same. Although the depth and scope of applying these processes and principles may change from project to project, the project framework remains constant.
The following sections refer directly to the Project Charter Template
Section 1. Charter Introduction
1.1 Executive summary
This section should give a brief summary of the project in business terms, demonstrating alignment with the strategic objectives and vision of the organization or with related horizontal government initiatives. There should also be clear links between the project and the desired business outcomes stated in the business case, as well as with projects identified in the departmental investment plan.
All projects, no matter how large or complex, are initiated in support of a departmental or organizational mandate and strategic priorities. The project charter should give the reader enough information to demonstrate that the project contributes to improving the ability of a program or a department to meet the needs of Canadians. What is the effect of the product or service on the clients of the program?
The summary provides some background information on the project that includes the reasons for creating the project (e.g. business needs or legal requirements) and mentions the key stakeholders who will benefit from the project results.
As well, the executive summary should cover the project charter and elements that require the approval of stakeholders, sponsors, or both, such as the project goals, project objectives, major milestones, key deliverables, primary risks, and estimated total costs.
1.2 Authorization
This section contains the signatures of the project sponsor or sponsors, the project manager, and other key project stakeholders, confirming that they agree to their roles, the description of the project, and the project deliverables and outcomes presented in the project charter.
Section 2. Project Overview
2.1 Project summary
This section summarizes the entire project charter and highlights the significant points of interest to the reader. It typically covers project goals and objectives, major milestones, key deliverables, key risks, and estimated total cost.
2.2 Project goals, objectives, and business outcomes
This section describes the project goals and links each of them with related, measurable project objectives. Measurement criteria for each objective must also be included because they will be used to confirm that an objective has been achieved. In addition, business outcomes to be derived from the project goals and objectives are to be presented as outlined in the business case.
• Project goals: These are high-level statements about what the project is trying to accomplish. They are broad, general intentions and are typically intangible and abstract.
• Business outcomes: These are results expected at the end of the project. Outcomes can often be expressed in just a few words that describe a general aim. This information may be presented using the outcome map, which is a visual model that shows how a project and all of its activities contribute to the realization of the outcomes.
• Project objectives: These are concrete statements describing a particular desired outcome of the project. They are tightly bound to goals. Sometimes objectives represent steps toward achieving the goals.
Measurement criteria are attributes of objectives and business outcomes that you can track over a period of time. They are used to confirm that an objective has been met.
Goal Objective Business Outcome
Greater flexibility in responding to stakeholder requests New online application form by end of fiscal year 2008–09
Measurement criteria
Online application form is in production by end of fiscal year 2009 Client satisfaction
Measurement criteria
Uptake of online capability by clients over a specified period of time against others means
2.3 Project scope
2.3.1 Scope definition
This section provides a high-level description of the features and functions that characterize the product, service, or result that the project is meant to deliver. It can include a reference to the business case. Include references like this in -Section 4: Project References- in the project charter.
This section on scope definition is to give the reader a clear sense of what is being created by the project. Scope definition should also include additional information about the nature of the project, such as its physical location and legal context, the people and processes affected, and so on.
2.3.2 Boundaries
This section outlines the major activities required to successfully complete the project and describes each activity in a way that specifies what is and what is not included in the activity. While the -Scope definition- section describes the main characteristics of the product(s) or service(s) to be produced by the project, the -Boundaries- section gives a broader view.
This section identifies activities that are -out of scope-; including these activities will greatly reduce ambiguity. It is especially important for projects that are multi-phased or part of a bigger picture (i.e. program or portfolio) to define what is being delivered in the undertaking covered by the charter.
The boundaries of small-scale projects can be defined in terms of activities while the boundaries of larger projects may be defined in terms of work streams or subordinate projects.
In Scope Out of Scope
1. Design a new business model for Program -X- 1. Building APIs with corporate applications
2. Develop a change management strategy 2. Communication with external clients
3. Develop an online catalogue of services 3. Translation services
This table is presented as an example. In many cases, further explanations may be required for a comprehensive presentation of the boundaries. The author may prefer to use the table as a summary and expand the description of each element in a narrative form.
2.4 Milestones
This section identifies the significant milestones or events in the project such as phases, stages, decision gates, or the approval of a deliverable. It presents a high-level project schedule.
Project Milestone Description Date
Phase 1: Documenting Business Requirements Translation of the requirements document into technical specifications for the building of a new water facility for a community yyyy-mm-dd
Phase 2: Contract award Request for proposal completed, winning bidder selected, and contract awarded by Acquisition Branch yyyy-mm-dd
Phase 3: Maintenance Delivery Assessment of the alternative system delivery model yyyy-mm-dd
2.5 Deliverables
This section defines the key deliverables that the project is required to produce in order to achieve the stated objectives. It also includes internal project deliverables that are required in the project management process for review and approval (e.g. project plan, transition plan, communication plan, and lessons learned).
The deliverables identified in this section could be used to develop the top levels of your work breakdown structure, which -subdivides the major project deliverables and project work into smaller, more manageable components.-3 The criteria that will be used to assess the quality and completion of each deliverable should also be included.
Project Deliverable Description
Description of Deliverable A common form and guide to annually report financial and production data with income tax return
Acceptance Criteria Single window; one application form
Due Date yyyy-mm-dd
2.6 Project cost estimate and sources of funding
2.6.1 Project cost estimate
This section summarizes cost estimates based on the project resources (human, material, and financial) that are needed to produce the deliverables and meet the agreed-upon objectives. The cost estimates from the business case can be used as the basis for this summary.
Itemize and break down the costs by project stage or phase and show multi-year projects by fiscal year. The estimate identifies other costs driven by the project in order to support decision making. Categories such as salaries and operations and maintenance (O&M) should include the A-base funding in addition to the project-specific funding. The intent is to document the full cost of the project.
Ongoing costs are those that are permanently required for operations as a result of the project (e.g. additional support, licenses, and hardware maintenance). While not technically considered pure project costs, ongoing costs provide valuable information for decision making. One-time costs can include non-recurring purchases needed for project administration and preparation for gating processes.
Project Phase Deliverable or Cost Category Estimated Cost (Y1) Estimated Cost (Y2) Estimated Cost (Y3)
Project Phase One (or Deliverable One)
Salaries
O & M
Professional Services
Capital
Other
Subtotals
Project Phase Two (or Deliverable Two)
Salaries
O & M
Professional Services
Capital
Other
Subtotals
TOTALS
2.6.2 Sources of funding
This section outlines the various sources of funding that will be used to support the project. It should be clear to the project sponsor and the project manager where the funds come from and the level of resources committed to this project.
2.7 Dependencies
Many projects depend on external factors, whether within or outside the organization, such as the following:
• A predecessor or successor relationship exists with another project (e.g. an MOU or partnership);
• A related project expects a deliverable from your project;
• Your project expects a deliverable from a related project; or
• Your project delivers a product, service, or result that will be or needs to be released with another new product, service, or result.
If any situations like this exist, it is important to identify these relationships early. If you expect to have several interactions with the project managers of related projects, include corresponding information in the -Roles and responsibilities- section under -Project managers for related projects.- Also, all dependencies should be listed and analyzed in the -Risks- section to ensure monitoring and allow response to a risk as required.
For each related project, add an entry to the table below. In the dependency description, specify the organization or stakeholder that should be kept informed of the project's progress. If there are no related projects, this should be mentioned in the form of a generic statement.
Dependency Description Critical Date(s) Contact Person
Completion of ceiling detail is dependent upon release of artisan from Project 8YB January 15, 2015 Giuseppe Verdi
555-1123
verdi@greenceilings.com
Work on database linkages dependent on purge/cleanse of data April 18, 2015 Alan Turing
555-3211
alant@computerwhiz.com
2.8 Project risks, assumptions, and constraints
2.8.1 Risks
This section outlines the risks identified at the start of the project. It includes a quick assessment of the significance of each risk (probability and effect) and how to address them. It is important to note that this initial risk assessment does not replace the full risk assessment conducted during the planning phase and documented within the project plan. (See Project Charter Template)
2.8.2 Assumptions
This section specifies all factors that are, for planning purposes, considered to be true, real, or certain but without including proof. During the planning process, these assumptions will be validated. If any assumptions are inaccurate, inconsistent, or incomplete, they will create project risks and may adversely affect project scope, timeline, and cost. (See Project Charter Template)
2.8.3 Constraints
This section identifies the specific constraints or restrictions that limit or place conditions on the project, especially those associated with the project scope such as a hard deadline, a predetermined budget, a set milestone, contract provisions, or privacy or security considerations.
The constraints can come from external factors (social, environmental, political, economic, and technological) or internal factors (resources, expertise, business requirements, legal requirements, facilities, and so on). In order to identify constraints, it is necessary to analyze the project environment.
If there are several constraints, they should be classified by category.
The following are examples of fixed or pre-set factors:
# Category Constraint
1 Deadline (time) The online registration service must be available for the 2008–09 campaign starting on October 23, 2008.
2 Legal The online registration service must meet the requirements of the Canada Water Act.
3 Resources End-user will not be available for testing during February and March 2008.
Section 3. Project Organization
3.1 Project team structure
Figure 1 illustrates the structure of the project team and stakeholders. For small projects, the names of the team members can be included; for larger projects, the chart should name the groups or entities that form the project teams. For all projects, the names of the project sponsor, project director or manager, and specialists should be clearly identified.
Figure 1: Project Team Structure
This graphic is an organizational chart of a typical project team. At the top of the chart is the project governance structure, which is headed by the client, often referred to as the Project Sponsor, and can include a Project Executive, a Senior Review Board, or an Executive Steering Committee. At the bottom of the chart is the project team structure, which is headed by a Project Manager and can include various Team Leaders. The Project Manager is the liaison between the project governance and project team structures.
A human resources strategy should be developed and included in the project charter if there are any clearly identified key positions that are vacant and must be filled for a successful project delivery. The purpose of the strategy is to address any potential staffing-related risks before the start of the project.
3.2 Roles and responsibilities
This section defines the roles and responsibilities assigned to the project team members and any stakeholders or working groups that have a significant influence on the project. All stakeholders, working groups, and committees shown in the sections -Project governance- and -Project team structure- should have their roles and responsibilities identified.
3.3 Project facilities and resources
Depending on the size and complexity of the project, the need for facilities and material resources such as office space, computer equipment, office equipment, and support tools can involve significant effort and costs. This section describes the project's requirements for such facilities and resources. It also identifies responsibilities for obtaining the specific items needed to support the project's development environment.
Project facilities and resource costs should be included in section 2.6.1, -Project cost estimate.- If these costs are significant, the activities involved in procurement and logistics activities should be documented as internal deliverables in section 2.5, -Deliverables.- The risks associated with project facilities and resources should also be considered.
Section 4. Project References
This section describes and identifies the location of key documents that define and establish the project (e.g. business case, investment plan, long-term strategic plan, requirements document, outcome management plan or similar).
Document Title Date Author Location
Business Case 2008-03-20 Kumar Dindayal - CIO Y:PPLansSystemUpgradeDocs
Section 5. Glossary and Acronyms
This section defines some terms and acronyms needed to create the project charter properly.
Data Flow Diagram (DFD): A graphical representation of the -flow- of data through an information system, modeling its process aspects. A DFD is often used as a preliminary step to create an overview of the system, which can later be elaborated.
Project Management Office (PMO): Relevant if the project is done within a large organization.
RACI (Responsible, Accountable, Consult, and Inform) Chart: A visual that describes the participation by various roles in completing tasks or deliverables. It is especially useful in clarifying roles and responsibilities in cross-functional processes.
Responsibility Assignment Matrix (RAM): A table that relates the program/ project organization structure to the work breakdown structure to ensure that each element of the program/ project's scope of work is assigned to a responsible organization or individual.
Sponsor: The person or group that provides the financial resources, in cash or in kind, for the project.
Stakeholder: Persons and organizations such as customers, business owners or program managers, performing organization and the public that are actively involved in the project or whose interests may be positively or negatively affected by the execution or completion of the project. They may also exert influence over the project and its deliverables.
Statement of Work (SOW): A formal document that captures and defines the work activities, deliverables, and timeline a vendor must execute in performance of specified work for a client. The SOW usually includes detailed requirements and pricing, with standard regulatory and governance terms and conditions.
Subject Matter Expert (SME): Persons with areas of specific expertise who may be interviewed, consulted, or added to the project team; may provide particular assistance in the estimation of resources.
Work Breakdown Structure (WBS): A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The parts of the WBS consist of work packages. The deliverables orientation of the hierarchy takes both internal and external deliverables into account.
Footnotes/Endnotes
1. Project Management Institute (2004). A Guide to the Project Management Body of Knowledge, Third Edition, p. 368.
2. Those processes performed to authorize and define the scope of a new phase or project or that can result in the continuation of halted project work.
3. Project Management Institute (2004). A Guide to the Project Management Body of Knowledge, Third Edition, p. 103.