Appendix C - Example Project/Program Charter Template

The Project Manager's Guide to Mastering

Agile: Principles and Practices for an Adaptive
Approach, Second Edition
by Charles G. Cobb

John Wiley & Sons © 2023 Citation

Appendix C: Example Project/Program Charter Template

Overview
This appendix contains an example of an optional Project Charter template that can be used
to define the macro layer in a hybrid, managed agile development approach. This template is
provided as an example and is intended to be customized to fit the project and business
environment that it is used in.

Project Overview

Background
Provide a brief description of the background behind the problem that the project or program
is intended to address to a sufficient level to allow the reader to understand the context of the
problem.

Problem Statement
Provide a brief description of the problem that the project or program is intended to address
from a business or operational management perspective.

Project Vision
Write a concise vision statement that summarizes the purpose and intent of the project and
describes what the world will be like when the project is completed. The vision statement
should reflect a balanced view that will satisfy the needs of diverse customers as well as
those of the developing organization. It may be somewhat idealistic, but it should be grounded
in the realities of existing or anticipated customer markets, enterprise architectures,
organizational strategic directions, and cost and resource limitations. Consider using the
following template:
 For (target customer)
  Why (statement of the need or opportunity)
 The (product name)
 Is a (product category)
 That (key benefit, compelling reason to buy or use)

Success Criteria
What are the success criteria for the project? How do you know if the project has been
successful?

Project Approach/Development Process

Identify the development process and/or any deviations from the standard methodology that
will be used for this project or program.

Project Plan
This section outlines the plan for managing the project.

Scope
The project scope defines the range of the proposed products and services the project will
deliver. Scope can be represented using a context diagram, an event list, and/or a feature
table. Scope might be subdivided into the scope of the initial product release and planned
growth strategies for subsequent releases. It is also important to define what the project will
not include, so describe limitations and exclusions, such as product features or characteristics
that a stakeholder might anticipate, but which are not planned to be included in the project.

In Scope
The project scope provides an overview of the user stories that the project will deliver. Scope
might be subdivided into the scope of the initial product release and planned growth
strategies for subsequent releases.
Open table as spreadsheet
Release Priority Story # Story Name Description

Out of Scope
It's also important to define what the project will not include, so describe limitations and
exclusions, such as product features or characteristics that a stakeholder might anticipate, but
which are not planned to be included in the project.
 Out of Scope Item #1
 Out of Scope Item #2
 Etc.
Related Projects and Systems
Identify any related projects or systems and describe the interrelationship.
Open table as spreadsheet
Project or system Interrelationship

Project Participants
Identify key project participants and the role that they will play in the project.
Open table as spreadsheet
Role Name Organization
Business Sponsor
Product Owner
Business Process Owner
Subject Matter Experts
Stakeholders
Project Manager
Business Analyst

Constraints, Assumptions, and Risks

Constraints
Constraints are impediments and other factors that must be considered when executing the
project or program. The constraints that are applicable to this program include: ___________
Identify known project constraints, such as products to be reused, components to be
acquired, interfaces to other projects or products, or technologies to be employed.
Open table as spreadsheet
Constraint Impact
Assumptions
Record any assumptions that were made (as opposed to known facts) when conceiving the
project. An assumption is a statement that CANNOT be proven to be true, but needs to be
taken as being true in order to proceed with the solution. Since the assumption is essential to
progress, it is also a dependency that carries some risk because of its indeterminate nature,
and the associated risk should be noted in the Business Risks section below.
 Assumption #1
 Assumption #2
 Etc.

Dependencies
Note any major external dependencies the project must rely upon for success, such as
specific technologies, third-party vendors, development partners, or other business
relationships. Also, identify any other projects that are related to this project in some way or
may have a bearing on its outcome.
 Dependency #1
 Dependency #2
 Etc.

Risks
Summarize the major business risks associated with this project or program, such as
marketplace competition, timing issues, user acceptance, implementation issues, or possible
negative impacts on the business. Estimate the severity of each risk's potential impact and
identify any risk mitigation actions that could be taken. This is not the place for the project's
overall risk list.
Open table as spreadsheet
Risk Mitigation strategy

Timeline Estimate
The following table contains an estimated schedule for the major milestones in the project.
Include a list of major project milestones and key deliverables with estimated target dates.
Open table as spreadsheet
Dates Milestone Deliverables