How to Write a Project Charter: A Practical Guide
A project charter is the short document that gives a project its official green light. It states what the project will deliver, why it matters, who is in charge, and what limits apply. Writing one takes an afternoon, but it saves weeks of arguments later about what was actually agreed.
When to Use This
Use a project charter at the very start of a project, before any real work begins. Typical moments: your team has approved a new initiative and someone needs written authority to start spending time and money on it; two departments disagree about who owns what; or a manager asks “who decided this project should happen?” and you want a one-page answer. It works for anything from a 6-week website refresh to a 12-month warehouse move. Skip it only for trivial one-person tasks that finish in a day.
How to Fill It Out
Section 1: Project name and sponsor. Give the project a clear name everyone will use, “Website Redesign 2026”, not “Digital Initiative Alpha”. Name the sponsor: the senior person who approves the budget and has the final say. Write “Sponsor: Maria Chen, Operations Director.” If no sponsor is named, the project has no real backing yet, stop and get one before continuing.
Section 2: Business reason and objectives. Explain in two or three sentences why the project exists and what it must achieve. Be specific and measurable. For example: “Our checkout page takes 9 seconds to load and 30% of mobile customers abandon their carts. This project will cut load time to under 3 seconds and reduce cart abandonment to 20% by 31 March 2027.” Vague reasons like “improve our online presence” are useless here, rewrite them until a stranger could tell whether the project succeeded.
Section 3: Scope, what is in and what is out. List the main deliverables (what the project will produce), then list what is explicitly NOT included. Example: In, new checkout page design, payment gateway integration, staff training. Out, changes to the product catalogue, a mobile app, new warehouse software. The “out” list matters more than people think; it is where most scope arguments start. If the sponsor wants something added later, that becomes a formal change request, not a quiet favour.
Section 4: Timeline and milestones. Give the start date, the target end date, and three to five key milestones in between. Keep it realistic: “Milestone 2: design approved, 15 May 2027.” You are not building a detailed schedule here; that comes with the project plan. The charter just pins down the dates everyone is committing to.
Section 5: Budget. State the total approved budget and who controls it. “Approved budget: £45,000. Spending above £5,000 per item requires sponsor approval.” Even a rough figure is better than none, it stops the project growing silently into something twice as expensive.
Section 6: Team and roles. Name the project manager and the key team members with their roles in one line each. “Priya Nair, Project Manager. Tom Reid, Developer (front-end). Sarah Lowe, Customer service lead (testing).” Add a line for any outside suppliers. Unclear roles cause the classic problem where everyone assumes someone else is doing the work.
Section 7: Risks and assumptions. List the top three to five risks (things that could go wrong) and key assumptions (things you are taking for granted). Example risk: “Our only front-end developer may be unavailable in June for parental leave.” Example assumption: “The payment provider’s test environment will be available by 1 April 2027.” Keep it honest, a charter that claims no risks looks unserious.
Section 8: Approvals. Leave space for signatures and dates from the sponsor and the project manager. A charter nobody signed is a draft.
Common Mistakes
1. Writing it after the project has started. A charter written in week six of a twelve-week project is decoration. It must be signed before work begins, while the key decisions are still open. If you are mid-project without one, write it now, a late charter beats no charter, but the real value is up front.
2. Letting one person write it alone. The project manager often drafts it, but the sponsor must review and sign. A charter the sponsor has never read will not protect you when priorities clash. Send the draft, ask for changes, and do not proceed until the signature is on the page.
3. Making the scope vague to avoid arguments. Writing “improve the checkout process” instead of a concrete deliverable list feels easier in the meeting, but it guarantees a bigger argument later. Precise scope is the whole point. If a deliverable cannot be described in one sentence, it is not defined well enough.
4. Treating the charter as a locked contract. The charter authorises the project; it is not a detailed plan set in stone. When business needs change, update the charter through a change request rather than pretending the original text is sacred. A charter from February that everyone knows is wrong in June has lost all authority.
Who Needs to Sign Off
The project sponsor signs, this is the person funding and owning the project at senior level. The project manager signs too, confirming they accept responsibility for delivery. For projects that touch another department’s work (for example, IT building something marketing will use), get the head of that department to sign as well. Three signatures are usually enough. If you need ten, your approval process is the problem.
How Often to Review and Update
The charter is reviewed at each major phase gate: after planning is complete, at the halfway point, and before go-live. Update it only when something material changes, a new sponsor, a revised end date, a budget change, or a major scope shift. Minor detail changes belong in the project plan, not the charter. Each update needs the sponsor’s sign-off again, and the old version should be kept on file so there is a record of what changed and when.
Download the free Project Charter Template.