project charter ? project management subject

C Example Project/Program Charter Template

THIS APPENDIX CONTAINS AN EXAMPLE of a 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 bal-

anced view that will satisfy the needs of diverse customers as well as those of the developing organiza-

tion. It may be somewhat idealistic, but it should be grounded in the realities of existing or anticipated

387

388 E X A M P L E P R O J E C T / P R O G R A M C H A R T E R T E M P L AT E

customer markets, enterprise architectures, organizational strategic directions, and cost and resource

limitations. Consider using the following template:

◾ For (target customer)

◾ Who (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 subse-

quent 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.

Release Priority Story # Story Name Description

E X A M P L E P R O J E C T /P R O G R A M C H A R T E R T E M P L AT E 389

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.

Project or System Interrelationship

Project Participants

Identify key project participants and the role that they will play in the project.

Role Name Organization

Business Sponsor

Product Owner

Business Process Owner

Subject Matter Experts

Stakeholders

Project Manager

Business Analyst

390 E X A M P L E P R O J E C T / P R O G R A M C H A R T E R T E M P L AT E

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.

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 depen-

dency 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 tech-

nologies, 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.

E X A M P L E P R O J E C T /P R O G R A M C H A R T E R T E M P L AT E 391

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.

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.

Date Milestone Deliverables