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.
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." See footnote 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 group See footnote 2 as defined in A Guide to the Project Management Body of Knowledge.
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.
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.
This guide supports a template that was developed to highlight all standard elements that should be covered in the project charter to formalize a project. The template can be obtained on the TBS web site.
This guide also contains a section called
"Use of the Project Charter Template" that explains how to complete each topic covered in the template.
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 project manager is expected to provide a comprehensive overview of the project in the project charter. The following table lists, in the left column, four classes of projects and suggests some areas to consider when developing a project charter, based on the results obtained through a risk assessment. This assessment would be contained in the business case for the project. To help with a risk assessment, a Project Complexity and Risk Assessment Tool is under development.
The primary project goal is to sustain service from an existing asset by addressing aging components or deficiencies that limit its ongoing use. It is not a redevelopment.
Negligible new capability or functionality added.
Business-initiated changes are likely minimal.
Scope confined to a single system or asset within a single program; one or few stakeholders.
Low to no requirements risk. Business changes are largely cosmetic—e.g. a service enhancement or versioning updates.
Business processes are essentially unchanged, although technology interfaces may be different—minimal retraining is required at the business level. Minimal change management.
Risks more likely associated with technology than business. Higher implementation risks in systems with demanding performance or availability (i.e. non-functional) characteristics.
Scope definition and boundaries should be limited to a single system or asset within a single program.
Usually one or few stakeholders.
Prerequisites, assumptions, and constraints should address potential disruption to current operations.
Deliverables should be expressed mostly in terms of updates to existing product, service, or result.
Cost estimate should determine if the updates affect the ongoing costs (operation).
Risks and interdependencies should include technology and implementation risks (such as parallel run or business disruption).
"Project References" section should refer to a requirements document.
Usually driven by an immediate business need to deliver an additional capability, often within a limited time frame, or to position an existing asset for anticipated needs by adding capability.
Capability added may be functional or non-functional.
Scope may involve multiple systems, programs, or organizational entities (departments) but with a clear authority and a simple governance structure.
Changes and additions to business processes are required with small- to medium-scale change management. Effect is often localized to a specific segment of the business.
Medium to high requirements risk and related risk of scope creep; development risk increases according to portion being redeveloped or added.
Technology risk may be high if significant performance or availability (i.e. non-functional) enhancements required.
Implementation risk medium, ranging to high if underlying technology base replaced.
The charter and risks should show a greater progression in the level of project management from Sustaining to Transformational, i.e. identify more detailed considerations with increased complexity and risk to support project scope, time, and cost management requirements.
Scope should clearly indicate the business processes that are affected.
Time constraints should be documented.
Interdependencies with multiple systems, programs, or organizational entities (departments) and consequent risks should be addressed.
The governance and roles and responsibilities should be well defined.
"Project References" section should refer to a requirements document.
Major changes and additions to capability, affecting business processes, job content, and service delivery model. Often a combination of business and technology evolution is involved.
Some base components are reused to provide a working platform on which to add function.
Scope may involve multiple systems, programs, entities, or jurisdictions and may overlap with client and business systems, requiring an appropriate governance structure.
High business risk due to significant change management and business process change. The more pervasive the effect of the solution across the business, the greater the risk.
High requirements risk and related risk of scope creep, hence significant delivery risk.
Governance risk proportional to number and diversity of stakeholder interests.
Conversion and implementation risks likely to be high, including organizational change.
Conversion and implementation activities should be visible in the schedule and cost estimates.
Special attention should be paid to interdependencies between the project and business processes.
Governance should be well documented.
Roles and responsibilities of the stakeholders and the governance bodies should be described.
Human resources strategy to address changes to the organization should be documented.
Project will change fundamentals about the way the business area works, such as processes, job content, organization, outsourcing, client and business involvement, and service model.
Few if any existing components will be reused.
Project likely spans organizational entities; may be multi-jurisdictional, involve multiple stakeholders, and require a complex governance structure.
Carries all the risks of the Evolutionary class of projects, further increased by the absence of any significant reuse.
High to very high business risk due to project size; very high change management implications; and pervasive effect of change across the business.
High to very high governance risk.
High conversion and implementation risk, variable technology risk.
Few if any risk mitigators are visible.
Interdependencies with processes, systems, and people should be documented.
Significant risk contingency should be applied to the cost and effort estimates.
"Project Organization" section should be the object of particular attention.
Project facilities and resources are often a consideration for Transformational projects.
Interdependencies between the different stakeholders should be presented in the project governance section.
The change management strategy should be described.
At the time of the publication of this guide, a new tool called an Organizational Project Management Capacity Assessment was being test piloted with select government departments. Authors of a project charter will be invited to analyze the results of their organizations.
In this assessment, the knowledge areas with the lowest scores, which indicate lower project management capacity, should be addressed in the project management plan. This will help to ensure that the project charter addresses any issues or concerns regarding the capacity of the organization to implement the project.
This guide explains how to complete the Project Charter Template and gives some insight into the content expected for each of the subjects listed in the template document.
Using this Template Document Purpose
As any project unfolds, the project team gains more information and understanding about the project and its implementation. Consequently, the project charter may have to be adjusted as the scope of the project becomes more precise and the deliverables better understood.
This section is used to document any changes and serves to control the development and distribution of revisions to the project charter. It should be used together with a change management process and a document management system. Document management procedures of the sponsoring organization should be applied to determine when versions and sub-versions must be created. This practice keeps an accurate history of the original document that was first approved.
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.
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.