Project Charter « Full » version Template

Project Charter « Full » version Template (Word Version, 475KB)

Project Name

Branch

National Project Management System
Business Projects-Information Technology-Enabled
Analysis Phase

This NPMS document template is based on the Treasury Board Project Charter Template.
© Her Majesty the Queen in Right of Canada, represented by the President of the Treasury Board, 2008
Catalogue No. International Standard Book Number (ISBN)
This document is available in alternative formats
and on the Treasury Board of Canada Secretariat's Web site at the following address: Treasury Board of Canada Secretariat

Instructions

This document is your template for producing a project charter, a mandatory National Project Management System (NPMS) deliverable.

Document Purpose

A 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." Footnote 1

The purpose of the charter is to obtain formal approval on the general parameters and structure of the proposed project, including:

Using this template

To create a project charter from this template:

On this page

Section 1. Charter Introduction

1.1 Document Change Control

This section serves to control the development and distribution of revisions to the project charter. It should be used in accordance with the recommended Public Services and Procurement Canada (PSPC) Information Management process (see the NPMS Business Projects-IT-Enabled Information Management Knowledge Area). It is recommended that changes to the project charter be documented only by adding annexes to the original project charter. This will keep an accurate history of the original document that was first approved.

Note: This table is only for example and contains no data.

Revision Number Date of Issue Author(s) Brief Description of Change
1.0 yyyy-mm-dd Author name Creation of the document.
       
       

1.2 Executive Summary

Provide a brief summary of the project in business terms, demonstrating alignment with the departmental strategic outcomes and the desired business outcomes that were identified by the participating organization(s) in the business case.

Summarize the most important aspects of the project by answering the questions:

The following elements are usually covered in the Executive Summary:

1.3 Authorization

This section contains the signatures of the key stakeholders, signifying agreement of roles and the description of the project as it appears in the project charter.

This project charter formally authorizes the existence of the project, <Project Name>, and provides the project manager with the authority to apply organizational resources to project activities described herein. If there is a change in the project scope, the project charter will be updated and submitted for re-approval.

Full Name:

Date:

Executive Sponsor:

Position, Client Organization:

Full Name:

Date:

Project Sponsor:

Position, Client Organization:

Full Name:

Date:

Project Manager:

Position, Your Organization:

Full Name:

Date:

Title:

Position, other supporting organization:

Full Name:

Date:

Title:

Position, other supporting organization:

Section 2. Project Overview

2.1 Project Summary

This section briefly summarizes the entire project charter, highlighting the significant points of interest to the reader. It includes all of the information required for approval by the key stakeholders. The summary should also include some background information on the project that:

2.1.1 Project Goals, Business Outcomes and Objectives

This section describes project goals and links each of them to related measurable business outcomes that are to be derived from the project goals. Measurement criteria must also be provided to confirm that an objective and desired outcome have been reached.

Keep in mind that goals are high-level statements, project objectives are concrete, and measurement criteria usually confirm if an objective has been met. Business outcomes are results expected at the end of the project.

Add rows as required.

Note: This table is only for example and contains no data.

No. Goals Objectives Business Outcomes
1  
2  
3  
2.1.2

Project Scope

2.1.3 Scope Definition

Provide a high-level description of the features and functions that characterize the product, service, or result that is to be delivered by the project.

2.1.4 Boundaries

Expand on the scope definition and outline the major activities required to successfully complete the project (for example, develop module ABC, develop requirements document, etc.). Out of scope activities are identified to reduce ambiguity.

Add rows as required.

While the table provides a summary view of the project boundaries, further explanations should be provided in a narrative form following the table.

Note: This table is only for example and contains no data.

Activities In Scope Activities Out of Scope
1. 1.
2. 2.
3. 3.

Insert additional explanations for project boundaries here.

2.2 Milestones

Identify the significant points or events in the project (for example, NPMS stages, phases, control point approval gates, etc.). This table can also represent a high-level project schedule.

Note: This table is only for example and contains no data.

Project Milestone Description Expected Date
1.    
2.    
3.    

2.3 Deliverables

Identify and define what the project must deliver in order to achieve the stated objectives. Include internal project deliverables required by the project management process for review and approval purposes (for example, project transition plan, communication plan, lessons learned register, etc.).

Determine criteria that will be used to assess the quality and completion of each deliverable.

Indicate stakeholder(s) responsible for approving each deliverable and the deliverable's due date.

Add rows as required.

Note: This table is only for example and contains no data.

Project Deliverable 1: Deliverable Name
Stakeholder:  
Description:  
Acceptance Criteria:  
Due Date:  
Project Deliverable 2: Deliverable Name
Stakeholder:  
Description:  
Acceptance Criteria:  
Due Date:  

The deliverables section can be used to build the project's high-level work breakdown structure, breaking the major deliverables into smaller, more manageable parts.

2.4 Project Cost Estimate and Source of Funding

2.4.1 Project Cost Estimate

Record cost estimates for all resources (i.e., human, material and financial) required to produce the deliverables and meet the objectives established for the project. To ensure the full project scope is covered, refer to items listed in the initial work breakdown structure and in project effort estimates. Include one-time as well as on-going costs. For example, provide the estimated on-going cost to sustain product(s)/service(s) that are to be produced by the project. Modify the table as required.

The business case for the project should contain cost estimates that can be used as the basis for this summary.

Note: This table is only for example and contains no data.

Phase 1/Deliverable
Salary        
Professional Services        
Capital        
Operations and Maintenance (O&M)        
Ongoing cost        
Other        
Sub-Totals        
Phase 2/Deliverable
Salary        
Professional Services        
Capital        
O&M        
Ongoing cost        
Other        
Total        
2.4.2 Source of Funding

State various sources of funding that will be used to support the project. It should be clear to the project sponsor and to the project manager where the funds will come from and that human resources have been committed to this project.

2.5 Dependencies

List project dependencies such as:

Note: This table is only for example and contains no data.

Dependency Description Critical Date Contact
     

2.6 Project Risks, Assumptions, and Constraints

2.6.1 Risks

This initial risk assessment does not replace the full risk assessment conducted during the planning phase. The following table records strategic risks that have been identified at the start of a project. For each risk, list both the level of impact and the degree of probability (i.e., high, medium, low). Identify the possible responses needed during the project to lessen the impact or lower the probability of the risk, and assign an Office of Primary Interest (OPI) responsible for resolution. Enter the top five or fewer risks. In accordance with PSPC Risk Management Procedures, acceptable responses to risk include accepting, transfering, mitigating, or eliminating the risk.

Note: This table is only for example and contains no data.

No. Risk Description Probability (H/M/L) Impact (H/M/L) Risk Management Plan OPI
1          
2          
3          
2.6.2 Assumptions

State assumptions that, for planning purposes, are considered to be true, real, or certain. These assumptions will be validated during the planning process. Inaccurate, inconsistent, or incomplete assumptions result in project risks.

Add rows as required.

The following table lists the items that cannot be proven or demonstrated when this project charter was prepared, but they are taken into account to stabilize the project approach or planning.

Note: This table is only for example and contains no data.

No. Assumptions
1  
2  
3  
2.6.3 Constraints

Identify the specific constraints or restrictions that limit or place conditions on the project, especially those associated with the project scope (for example, a hard deadline, a predetermined budget, a set milestone, contract provisions, privacy or security considerations, etc.). Categorize the constraints if there are several.

Add rows as required.

The following table lists the conditional factors within which the project must operate or fit.

Note: This table is only for example and contains no data.

No. Category Constraints
1    
2    
3    

Section 3. Project Organization

3.1 Project Governance

Describe how the project will be governed and identify the corporate governance bodies that may be involved in the approval process. In other words, show how decisions are made and who makes which decisions.

A diagram should be used. If committees are shown in the diagram, the project is to include a description of these committees in the Roles and Responsibilities section.

3.2 Project Team Structure

Use an organizational chart to show the structure of the project team as well as the relationships between team members.

Illustrate how the team interacts with, or relates to, the governance structure for the project.

For small projects, roles of team members can be included; for larger projects, the organizational chart should name the groups or entities that form the project teams.

3.3 Roles and Responsibilities

Define the roles and responsibilities assigned to each member of the project team as well as those of any stakeholders and working groups that have a significant influence on the project.

Include all committees and entities identified in the sections 3.1—Project Governance and section 3.2—Project Team Structure.

Note: This table is only for example and contains no data.

Project Role Responsibilities Assigned to
Project Manager    
Business Analyst    
Project Review Committee    

3.4 Project Facilities and Resources

Describe, if applicable, the project's requirements for facilities and resources, such as office space, special facilities, computer equipment, office equipment, and support tools.

Identify the person or team responsible for obtaining the specific items needed to support the project's development environment.

Section 4. Project References

In this section, identify and describe the location of the key documents that define and establish the project such as the business case, the departmental investment plan, departmental long-term strategy, outcome management plan, outcome map, Speech From the Throne, Cabinet directions, horizontal government initiatives, etc.

More information concerning this project can be found in the following documents:

Note: This table is only for example and contains no data.

Document Title Version # Date Author and Organization Location (link or path)
         
         

Section 5. Glossary and Acronyms

Define all terms and acronyms required to interpret the project charter properly.

Note: This table is only for example and contains no data.

Term or Acronym Definition
   
   
   

Checklist for reviewing your project charter

[ ]: Check box

After you have completed filling in the template for your project charter, use the list below to review the different sections to make sure you have included all the information required.

If all of these are checked as complete, then delete this checklist, update the Table of Contents, and save the document to file.

Date modified: