Outputs for Developing a Charter You Should Know for the PMP Certification Exam

By Cynthia Snyder Stackpole

You will need to know about outputs for the Develop Charter Project to get your PMP certification. After all the information gathering and analysis, you can start to document information in an organized fashion, and voilà! The charter is created.

In some organizations, the charter is created by the sponsor, customer, PMO, or some other entity and then handed to the PM. In other organizations, the PM either assists in the creation or actually creates the charter and then gets approval from the sponsor, PMO, or whoever is appropriate. Regardless, it is good practice to make sure that the project manager is involved in some manner when developing the charter.

The charter should provide a summary of the project with enough information that the initial project team can read it, absorb it, and then use progressive elaboration to plan the project in detail. Here is an example of what the PMBOK Guide says are contained in the charter.

The needs of the organization and the project should determine the actual contents.

Charter Content Item What It Does
Purpose and justification The reason why the project is being undertaken. May refer to
the business case, the strategic plan, external factors, a
contract, or any other document or reason for performing the
project.
Objectives The strategic position the project is being undertaken to
deliver, or the result to be achieved.
There are usually multiple objectives, such as objectives for
scope, schedule, cost, quality, customer satisfaction, and so
on.
Success criteria Measurable criteria that correspond to each objective to
indicate that the objective has been successfully met.
High-level requirements The high-level business and compliance requirements must meet
customer expectations. (These are not detailed requirements but
merely initial, high-level requirements.)
Assumptions and constraints The initial assumptions about scope, resources, funding,
approach, and other project variables.
Constraints are the initial limitations, such as a fixed due date
or budget.
High-level project description A summary-level description of the project. May include
information on high-level project and product deliverables as well
as the approach to the project.
High-level risks The initial risks. These will later be progressively elaborated
and entered into a risk register.
Summary milestones Significant events in the project. May include the completion
of deliverables, phases or product acceptance.
Summary budget The initial range of estimated expenditures for the
project.
Stakeholder list The initial list of stakeholders who can influence or will be
influenced by the project, product, service or result.
Approval requirements Who can approve and sign off on each deliverable and the
criteria for acceptance.
PM Authority: Staffing

Technical decisions

Conflict resolution

Budget management

The authority to hire, fire, discipline, accept, or not accept
project staff.

The authority to make technical decisions about deliverables or the
technical approach.

The authority to resolve conflict within the team, the
organization, and external stakeholders.

The authority to commit, manage, and control project funds.
Includes variance thresholds.

Sponsor, PM signatures, and other relevant signatures Demonstrates commitment and approval for the project.

In some organizations, you see high-level assumptions and constraints documented in the charter. In others, you might see an Assumption and Constraint log that would start with the high-level assumptions during project initiation. While the project progresses, you would see more detailed assumptions. Examples of high-level assumptions include

  • We will use internal resources to staff the project.

  • The market will accept the new product.

  • Funding will be available.

Examples of high-level constraints can include regulations, fixed delivery dates, and a budget cap.