Project Charter Template: The Best Way to Start a Project in 2026
A project charter is the short document that formally authorizes a project. It names the objective, the scope, the people responsible, the milestones, and the budget, and it carries a sponsor’s signature that says: this work is approved, and this person is empowered to run it. A project charter template turns that document from a blank page into a fill-in exercise, which is exactly what the four versions below are for.
It is not the project plan. The charter answers why the project exists and who has authority; the plan answers how the work gets done week to week. A good charter fits on one or two pages, takes an afternoon to write, and saves you from the most expensive failure mode in project work: discovering three months in that the sponsor and the team were building two different projects.
Four project charter templates, free to download
Each version below is a working spreadsheet, not a blank grid with a title row. The sections are pre-filled with realistic example content so you can see how a finished charter reads, then overwrite it with your own project. Every download is a plain .xlsx file that opens in Excel, Google Sheets, or any spreadsheet app. No email address required.
Classic Project Charter
The classic charter is the version most projects should start with: the standard full document for a formal kickoff, organized section by section with a detail column, a named owner, a status, and a last updated date per row. Use it when a sponsor, a budget, and a defined scope all exist and what you need is one page of record the whole team can reference. The per-section status column quietly earns its keep during drafting, because it shows exactly which parts of the charter are agreed and which are still open questions.
One-Page Executive Charter
The executive charter strips the document to what leadership actually reads before saying yes: the why, the cost, the ask, and who owns each item, on a single screen with an approved checkbox per row. Use it when you need a green light from people whose attention is measured in minutes, or as the summary layer on top of a fuller charter. If an executive reviewer wants more depth on a line, that conversation is the point; this version exists to make sure the conversation happens before the spend does.
Agile Team Charter
The agile team charter is a working agreement for a standing product team rather than a single project: mission, customer, success measures, ways of working, and boundaries, each with an owner, an agreed flag, and a last reviewed date. Use it at team formation or a deliberate reset, then revisit it every quarter, which is what the review-date column is for. It gives leadership the alignment and authorization they legitimately need while leaving the backlog free to change every sprint.
Charter with Approval Sign-Off
The sign-off charter is for organizations where the charter itself needs formal, section-by-section approval. Every section carries its approver, their role, an approval status, and the date the decision landed, and the summary row counts completed sign-offs automatically so you can see at a glance how close the document is to fully authorized. Use it for cross-department projects, regulated environments, or anywhere a single signature line would hide who has actually agreed to what.
How to write a project charter that actually gets used
Start with the problem, not the project
Write one or two sentences describing the situation that makes this project necessary: what is broken, what opportunity is closing, what it costs to do nothing. If you cannot state the problem without naming your solution, you have not found the problem yet. This section is what a sponsor reads first, and it is the test every scope decision gets measured against later.
Define the objective as a result, with a number and a date
A useful objective is verifiable: reduce order processing time from five days to two by the end of Q3, or launch the new intake portal to all three regions by November 1. Avoid verbs like improve, enhance, and streamline on their own; they cannot fail, which means they cannot succeed either. If the project has several outcomes, pick the one that matters most and list the rest as secondary.
Write the out-of-scope list before the in-scope list
The out-of-scope list is the most valuable section of the charter and the one most often left empty. Every project accumulates adjacent requests, and each one sounds reasonable in isolation. Naming the near-misses now, the integrations you will not build, the regions you will not cover, the legacy data you will not migrate, gives the project manager something to point to that the sponsor already signed. Scope creep survives on ambiguity; this section removes it.
Name people, decision rights, and one sponsor
List the sponsor, the project manager, the core team, and the stakeholders who must be consulted, each as a named person rather than a department. Then write down who makes which decisions: who approves budget changes, who signs off on scope changes, who can stop the project. Committees do not sponsor projects well. If you cannot get a single accountable sponsor to put their name on the charter, that is a finding worth escalating before work begins.
Keep milestones to the handful that matter
The charter needs five to eight dated milestones, not a full schedule: kickoff, the major deliverable dates, the go-live, the closeout. These are the commitments the sponsor is agreeing to fund and the checkpoints where the project gets reviewed. Save task-level planning for the project plan, and let the charter carry only the dates that would trigger a hard conversation if they slipped.
State the budget and the assumptions it rests on
Give the total budget, the major cost categories, and the assumptions behind them: the vendor quote that is still provisional, the internal hours that depend on another team, the exchange rate or material price you locked in. An assumption written in the charter becomes a known risk; an assumption left in someone’s head becomes a surprise. Note the top three to five risks here too, then move ongoing risk tracking into a RAID log once the project is running.
Get a real signature, then keep the charter visible
Sign-off is the entire point of the document, so make it explicit: name, date, and a line that says what the signature authorizes. After that, do not file the charter away. Link it from wherever the team works, revisit it at each milestone review, and when change requests arrive, evaluate them against the objective it states. A charter that nobody re-reads is a formality; a charter the team quotes in meetings is a working tool.
Need a project charter template in Word format?
Plenty of organizations still expect the charter as a Word document, usually because it gets attached to a governance pack or routed for signature. The downloads above are .xlsx files by design, because a spreadsheet keeps owners, statuses, and dates behaving like data, but they convert cleanly: open the file, select the charter table, and paste it into Word, where it lands as a native, editable Word table. Set the page to landscape for the wider versions and it prints exactly as it reads on screen.
If the Word document is the format of record in your organization, a practical split is to draft and maintain the charter in the spreadsheet, where the status column keeps the drafting honest, then paste the agreed version into your Word letterhead for signature. You keep one living source of truth and still hand governance the artifact they asked for.
Frequently asked questions
What is the difference between a project charter and a project plan?
The charter authorizes the project: it states the objective, scope boundaries, key people, milestone dates, and budget, and it is signed by the sponsor before detailed work starts. The project plan is the working document that schedules tasks, assigns owners, and tracks progress day to day. The charter should stay stable for the life of the project, while the plan changes constantly. If a change is big enough that the charter itself is wrong, that is a formal change decision for the sponsor, not a quiet edit.
Who writes the project charter?
Usually the project manager drafts it and the sponsor owns it. The sponsor provides the why, the business case, and the authority; the project manager turns that into concrete objectives, scope boundaries, milestones, and resource needs. The draft is then reviewed with key stakeholders before the sponsor signs. What matters is not who types it but that the sponsor genuinely agrees with every line, because the charter is only as strong as the authority behind it.
How long should a project charter be?
One to two pages for most projects. If it is shorter than a page it is probably missing the scope boundaries or the decision rights, and if it is much longer than three pages it has probably absorbed content that belongs in the project plan, the requirements document, or the risk log. Large programs with formal governance can justify a longer charter, which is what the sign-off version above is for, but length is not rigor. A tight one-pager the sponsor actually read beats a ten-page document nobody finished.
Do agile teams need a project charter?
Yes, but a different shape of one. Agile teams do not need a charter that fixes scope up front, and pretending otherwise just produces fiction. What they need is agreement on the mission: the problem, the customer, the success measures, the team, the budget envelope, and the explicit non-goals. That is exactly what the agile team charter above contains. It turns chartering from a scope-fixing exercise into a direction-setting one, which is the version of the ritual that survives contact with a real backlog.
What is the difference between a project charter and a statement of work?
They point in different directions. A statement of work (SOW) is a contractual document between two parties, typically a client and a vendor, that specifies deliverables, acceptance criteria, payment terms, and timelines with legal weight. A project charter is an internal authorization document: it gives your own team the mandate and the boundaries to run the project. On client work the two coexist, and the charter should reference the SOW rather than duplicate it, so there is exactly one source of truth for what was contractually promised.
When should the charter be updated?
Only when something it states is no longer true: the objective changes, the budget moves materially, the sponsor changes, or a scope boundary is formally renegotiated. Each update should go back through the sponsor, because an unsigned edit to a signed document has no authority. Routine progress does not belong in the charter; that is what status reporting and the project plan are for. A good rhythm is to re-read the charter at each milestone review and confirm it still describes the project you are running.
Run it live instead of in a file.
The downloads above are yours either way. In Wisegrid the same template becomes a working sheet with owner contacts, status dropdowns, reminders, and dashboards. 7-day free trial, no credit card required.