How to Write a Project Charter with Timeline

What a Project Charter Is (and Isn't)

A project charter is the founding document of a project. It answers four questions: Why are we doing this? What will we produce? Who is responsible? When will it be done?

It's not a project plan—that comes later. It's not a business case—that was used to justify the project before the charter. And it's not a contract—though it often gets treated like one.

The charter's job is to create shared understanding and formal authorization. When a sponsor signs the charter, they're saying: this project is approved, these resources are committed, and this team has the authority to proceed.

Without a charter, projects start on ambiguous footing. Disagreements about scope, timeline, and authority emerge later because they were never resolved at the start.

The Eight Elements of a Strong Project Charter

1. Project Purpose and Business Objective

One or two sentences. Why does this project exist and what business outcome does it serve?

Weak: "We are redesigning the customer portal."

Strong: "We are redesigning the customer portal to reduce support ticket volume by 30% and increase self-service resolution rate, targeting $180K in annual support cost reduction."

The strong version ties the project to a measurable business result. This framing makes every subsequent scope decision clearer—does this feature advance the goal? If not, it's optional.

2. Scope Statement

What is included? What is explicitly excluded? Both matter. "Out of scope" items prevent scope creep by creating a documented agreement about what won't be built.

Include:

What will be delivered (features, deliverables, phases)
What is explicitly not included
Assumptions that affect scope (e.g., "assumes existing authentication system will not be modified")

3. Deliverables

A list of concrete outputs: documents, software components, processes, systems, or other tangible products the project will produce. Deliverables are the connection between scope and the Gantt chart—each deliverable becomes a phase or milestone in the timeline.

4. Success Criteria

How will you know the project succeeded? Define at least two measurable criteria tied to the business objective. Qualitative criteria ("stakeholders are satisfied") are weak because they can't be evaluated objectively at project close.

5. Constraints and Assumptions

Constraints: Limitations that are fixed (budget ceiling, team size, technology platform, regulatory requirements, must-meet deadline).

Assumptions: Things you're treating as true that could turn out to be false. List them explicitly. An assumption that proves wrong mid-project is a risk that should have been flagged at the start.

6. Roles and Responsibilities

At minimum:

Project Sponsor: The executive who authorized the project and can resolve escalations
Project Manager: Responsible for day-to-day management and reporting
Team Members: Who's doing the work and in what capacity
Key Stakeholders: Who has input, approval authority, or will be significantly affected

7. Risks

Three to five significant risks identified at project start. For each: what is the risk, how likely is it, what's the potential impact, and what's the mitigation or contingency plan?

8. High-Level Timeline

This is where the Gantt chart connects to the charter. A project charter doesn't need a detailed task-level schedule—but it should include a phase-level timeline showing the major milestones and their target dates.

Building the Charter Timeline with a Gantt Chart

Open gantt-chart.io and create a high-level Gantt chart with:

One bar per major phase (Discovery, Design, Development, Testing, Launch)
Milestone markers at key decision points and deliverable dates
Duration estimates at the phase level, not task level

This charter-level Gantt chart should fit on one page or one screen. If it's more detailed than that, it's a project plan, not a charter attachment.

Include the Gantt chart in your charter document as an image or linked URL. It communicates the timeline at a glance in a way that a list of dates cannot.

The Charter Approval Process

A charter that sits in someone's inbox doesn't achieve its purpose. Build approval into the process:

Draft the charter and share it with key stakeholders for review (give them a specific date to respond by)
Incorporate feedback and address disagreements—especially scope disputes
Present the charter to the sponsor for sign-off
Distribute the signed charter to all team members and stakeholders

The sponsor's signature is what makes the charter authoritative. Without it, you have a useful document with no formal standing.

Common Charter Mistakes

Too long. A charter should be 2-4 pages. If it's 20 pages, you've written a project plan. Executive sponsors won't read it, which means they haven't agreed to what's in it.

Vague objectives. "Improve customer experience" is not an objective. It's a direction. Tie the objective to a specific, measurable outcome.

No out-of-scope section. The most important part of scope is what's excluded. Without it, everything is potentially in scope.

Skipping the timeline. A charter with no timeline is authorizing indefinite work. Even a rough phase-level Gantt chart communicates that the team has thought through the sequencing.

No sponsor. If you can't identify an executive sponsor who is accountable for the project's outcome, the project shouldn't start. This person resolves escalations that the project manager can't.

Charter as a Living Reference

After the project starts, the charter becomes the reference document for scope disputes. When a stakeholder requests something new, the first question is: "Is this in the charter?"

If yes: it's in scope and should be in the Gantt chart.

If no: it's a change request that requires the charter to be amended or the request to be formally declined.

This discipline keeps scope manageable and keeps the Gantt chart on gantt-chart.io aligned with what the project has actually committed to deliver.