Project Charter Template: What to Define Before Work Begins

A project charter should prevent expensive ambiguity before the project team becomes busy.

Its job is not to describe every task. It is to establish why the project exists, what it is expected to produce, who owns which decisions, and where the boundaries sit.

1. Project Purpose

Write the business reason in plain language.

What problem is being solved? What opportunity is being pursued? Why does this project matter now?

2. Intended Outcomes

Define what will be different when the project succeeds.

Outcomes are stronger than vague activity statements.

3. Scope

State what is inside the project and what is explicitly outside it.

Out-of-scope statements are useful because many project problems begin with assumptions about work nobody formally agreed to deliver.

4. Deliverables

List the major outputs required.

A deliverable should be specific enough that stakeholders can recognize whether it exists.

5. Success Criteria

How will sponsors decide whether the project created the intended result?

Measures may include time, cost, adoption, quality, customer outcomes, compliance, capability, or operational performance.

6. Sponsor and Project Authority

Clarify:

• who sponsors the project;
• who leads it;
• what the project manager can decide;
• what requires sponsor approval;
• what requires another governance body.

7. Key Stakeholders

Identify the people or groups who can influence success, are affected by the outcome, or provide critical input.

8. Major Milestones

At charter stage, focus on major decision points and delivery phases rather than detailed task scheduling.

9. Key Risks and Assumptions

Capture the few uncertainties that could materially change scope, timing, cost, or value.

10. Dependencies

What must another team, supplier, regulator, system, or project provide?

A Short Charter Template

• Project name:
• Business purpose:
• Outcome:
• In scope:
• Out of scope:
• Major deliverables:
• Success measures:
• Sponsor:
• Project lead:
• Decision rights:
• Key stakeholders:
• Milestones:
• Top risks:
• Critical dependencies:

Do Not Turn the Charter Into a Full Project Plan

The charter should create alignment before detailed planning. If it becomes fifty pages, people stop using it as a decision document.

Use the Charter When Scope Changes

When someone asks for additional work, return to the charter.

Does the request support the agreed outcome? Does it change a boundary? Who has authority to approve it? What happens to cost, time, or another deliverable?

Write a Better Project Purpose Statement

A strong purpose statement links the project to an organizational need.

Weak:

“Implement a new CRM.”

Stronger:

“Create a reliable shared view of customer activity so sales and service teams can manage opportunities, handovers, and account issues from the same information.”

The second statement gives the team a way to evaluate decisions when implementation options appear later.

Make Scope Boundaries Concrete

Instead of saying “training is out of scope,” clarify what that means.

For example:

• system configuration is in scope;
• end-user training materials are in scope;
• delivery of company-wide training is out of scope;
• ongoing support after the first month is operational ownership.

Specific boundaries reduce arguments later.

Define Governance Early

Projects slow down when teams do not know who can approve changes or resolve conflict.

Include:

• sponsor;
• project manager;
• steering group;
• technical or specialist authority;
• change-approval authority;
• escalation route.

Identify Assumptions That Could Change the Project

Examples:

• a supplier will deliver by a certain date;
• key staff will be available;
• a system interface already exists;
• data quality is sufficient;
• a regulation will not change before launch.

Important assumptions should be tested, not buried.

Use the Charter in Sponsor Conversations

The charter is a useful way to resolve disagreements about what the project was meant to achieve.

When a sponsor requests more work, ask:

• Does this change the project outcome?
• Does it change scope?
• What additional time, cost, or capacity does it require?
• Who has authority to approve the change?

Charter Quality Check

Before approval, ask whether a new project team member could read the charter and answer:

1. Why are we doing this?
2. What will we deliver?
3. What will we not deliver?
4. Who decides?
5. What could derail us?
6. How will we know we succeeded?

If not, the charter is not clear enough yet.

Connect the Charter to Benefits

A project can deliver every technical output and still fail to create the intended business value.

Where possible, name the benefit owner and describe what must happen after delivery for the benefit to appear.

For example, installing a new system is not itself a productivity benefit. Users must adopt it, old workarounds must stop, and the process may need to change.

Include Constraints

Projects operate inside constraints that shape what is feasible.

Typical constraints include:

• fixed regulatory dates;
• budget ceilings;
• technology standards;
• resource availability;
• contractual commitments;
• geographic or language requirements.

Making them explicit helps the team avoid proposing solutions the organization cannot actually use.

Use the Charter at the Kickoff

The kickoff should not be the first time the team sees the charter.

Use the document to confirm:

• shared understanding of the outcome;
• role and decision clarity;
• scope boundaries;
• known risks;
• how changes will be handled.

If the team disagrees with the charter at kickoff, resolve that before detailed execution begins.

Get Formal Approval

A charter should be approved by the person or group with authority to commit the organization to the project. Approval confirms that the purpose, scope, governance, and resource assumptions are accepted.

Do not treat approval as a signature exercise. If major stakeholders disagree with the charter, resolve the disagreement before planning becomes more detailed and expensive.

Where to Go Next

The Project Management Fundamentals course covers chartering, scope, planning, stakeholders, schedule, cost, risk, execution, and closure. For uncertainty management, see Risk Management in Projects.

A good project charter is a small document with a large job: making sure the team starts the same project.