Project Charter Guide

An Enhanced Framework for the Management of

Information Technology Projects
Project Charter Guide

December 2008
IT Project Review and Oversight Division
Treasury Board of Canada Secretariat

Feedback and Questions

To help maintain the currency of this document, feedback and questions are welcomed.

Please contact:
IT Project Review and Oversight
Chief Information Officer Branch
Treasury Board of Canada Secretariat
Ottawa ON K1A 0R5
Canada
Email: itprod-despti@tbs-sct.gc.ca

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]

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[2] as defined in A Guide to the Project Management Body of
Knowledge.

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.

How to create a project 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 at http://www.tbs-sct.gc.ca/emf-cag/index-eng.asp.

This guide also contains a section called "Use of the Project Charter Template" that
explains how to complete each topic covered in the template.

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.

Adapting the project charter to the Treasury Board of Canada

Secretariat's Project Complexity and Risk Assessment Tool

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.

2
 Risk Project Charter
Project Class Description
Considerations Considerations
The primary Low to no Scope definition and
project goal is to requirements risk. boundaries should
sustain service Business be limited to a single
from an existing changes are system or asset
asset by largely cosmetic within a single
addressing —e.g. a service program.
aging enhancement or
components or versioning Usually one or few
deficiencies that updates. stakeholders.
limit its ongoing
use. It is not a
Business
redevelopment. Prerequisites,
processes are assumptions, and
essentially constraints should
Negligible new unchanged,
address potential
capability or although
disruption to
functionality technology
current
added. interfaces may operations.
be different—
Business- minimal
retraining is Deliverables
initiated
required at the should be
changes are
business level. expressed mostly
likely
Minimal change in terms of
minimal.
management. updates to
existing product,
Sustaining Project Scope service, or result.
confined to a Risks more
single system likely
associated with Cost estimate
or asset
technology should determine
within a single
than business. if the updates
program; one
Higher affect the ongoing
or few
implementation costs (operation).
stakeholders.
risks in
systems with Risks and
demanding interdependencies
performance or should include
availability (i.e. technology and
non-functional) implementation
characteristics. risks (such as
parallel run or
business
disruption).

"Project
References"
section should
refer to a
requirements
document.
Tactical Project Usually driven Changes and The charter and
by an additions to risks should show a

3
 immediate business greater progression
business need processes are in the level of project
to deliver an required with management from
additional small- to medium- Sustaining to
capability, often scale change Transformational,
within a limited management. i.e. identify more
time frame, or to Effect is often detailed
position an localized to a considerations with
existing asset specific segment increased complexity
for anticipated of the business. and risk to support
needs by project scope, time,
adding Medium to high and cost
capability. requirements management
requirements.
risk and related
Capability risk of scope
added may be creep; Scope should
functional or development clearly indicate
non- risk increases the business
functional. according to processes that are
portion being affected.
Scope may redeveloped or
involve added. Time constraints
multiple should be
systems, Technology risk documented.
programs, or may be high if
organizational significant Interdependencies
entities performance or with multiple
(departments) availability (i.e. systems,
but with a non-functional) programs, or
clear enhancements organizational
authority and required. entities
a simple (departments)
governance Implementation and consequent
structure. risk medium, risks should be
ranging to high addressed.
if underlying
technology The governance
base replaced. and roles and
responsibilities
should be well
defined.

"Project
References"
section should
refer to a
requirements
document.
Evolutionary Project Major changes High business Conversion and
and additions to risk due to implementation
capability, significant change activities should be
affecting management and visible in the
business business process schedule and cost
processes, job change. The estimates.

4
 content, and more pervasive
service delivery
the effect of the Special attention
model. Often asolution across should be paid to
combination ofthe business, the
interdependencies
business and greater the risk.
between the
technology
evolution is project and
High business
involved. requirements processes.
risk and related
Some base risk of scope
components Governance
creep, hence
are reused to significant should be well
provide a documented.
delivery risk.
working
platform on Roles and
Governance
which to add risk responsibilities of
function. the stakeholders
proportional to
and the
number and
Scope may governance
diversity of
involve bodies should be
stakeholder
multiple described.
interests.
systems,
programs, Human resources
Conversion and
entities, or strategy to
implementation
jurisdictions address changes
risks likely to
and may to the
be high,
overlap with including organization
client and should be
organizational
business documented.
change.
systems,
requiring an
appropriate
governance
structure.
Transformational Project Project will Carries all the Interdependencies
change risks of the with processes,
fundamentals Evolutionary systems, and people
about the way class of projects, should be
the business further increased documented.
area works, by the absence of
such as any significant Significant risk
processes, job reuse. contingency
content,
should be applied
organization, High to very to the cost and
outsourcing, high business
client and effort estimates.
risk due to
business
project size; The "Project
involvement,
and service very high Organization"
model. change section should be
management the object of
implications; particular
Few if any
and pervasive attention.
existing
effect of
components
change across
will be Project facilities
the business.

5
 reused. High to very and resources are
high often a
Project likely governance consideration for
spans risk. Transformational
organizational projects.
entities; may High
be multi- conversion and Interdependencies
jurisdictional, implementation between the
involve risk, variable different
multiple technology stakeholders
stakeholders, risk. should be
and require a presented in the
complex Few if any risk project
governance mitigators are governance
structure. visible. section.

The change
management
strategy should be
described.

Organizational Project Management Capacity Assessment

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.