A project charter sets the foundation for everything that follows. Learn what belongs in one, how to write it clearly, and how to attach a Gantt chart timeline for immediate credibility.
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.
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.
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:
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.
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.
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.
At minimum:
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?
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.
Open gantt-chart.io and create a high-level Gantt chart with:
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.
A charter that sits in someone's inbox doesn't achieve its purpose. Build approval into the process:
The sponsor's signature is what makes the charter authoritative. Without it, you have a useful document with no formal standing.
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.
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.