How to Write a Project Charter (Step-by-Step Guide With Template)

how to write a project charter is a key topic in modern project management and teamwork. You have been asked to write a project charter, and it feels like a document with high stakes: get it right, and the project is approved with the authority and budget it needs; get it wrong, and you are back in meetings for another round of revisions. The good news is that a charter is one of the simplest documents in project management — if you know what goes in it and in what order.

This guide walks you through writing a project charter step by step, section by section, with a practical template and a condensed example you can adapt. You will learn what to put in each section, how much detail is enough, how to avoid the classic mistakes, and how to get your charter approved the first time.

Quick Answer: How Do You Write a Project Charter?

Write a project charter by capturing, in this order: project name and sponsor, purpose and justification, SMART objectives and success criteria, scope (in and out), summary budget, summary milestones and timeline, key stakeholders and roles (including the project manager’s authority), assumptions, constraints, high-level risks, and the approval signature line with a revision date. Keep it to one to three pages, use clear plain language, and get the sponsor to sign it.

The process has three phases: gather inputs (business case, statement of work, agreements), draft the sections in the logical order below, and then negotiate and obtain approval. The drafting is the easy part; the approval is where charters actually succeed or fail.

Step 0: Gather the Inputs Before You Write

A charter is not written from a blank page. Before drafting, collect everything that describes the opportunity and the constraints around it.

Typical inputs include a statement of work (what the work is), a business case (why it is worth doing, with costs and benefits), any agreements or contracts already in place, enterprise standards and regulations, known assumptions, and organizational templates or processes. If no business case exists, the purpose section will have to carry the justification on its own — which is fine for smaller projects, but flag it if the project is a large investment.

Gathering inputs up front saves you from writing a charter that contradicts a signed agreement or an existing strategy. It also gives you the material you need to make objectives measurable and constraints accurate.

How to Write a Project Charter: Step by Step

The sections below follow the order most people find natural: why, what, who, then the surrounding conditions, then approval. Write them in this order and the document builds itself.

Step 1: Write the Purpose and Justification (the “Why”)

Start with the reason the project exists, connected to an organizational goal. This is the core of your pitch: it tells a decision-maker why this project deserves budget and attention now.

Write one or two sentences that state the problem or opportunity and the business reason for acting. Avoid vague phrasing. “We are building a customer portal” says nothing about why. “We are building a customer portal to reduce support tickets by automating order-status queries” says why the work matters.

Step 2: Define Objectives and Success Criteria

Objectives are what success looks like, in measurable terms. The SMART test — specific, measurable, achievable, realistic, time-bound — is the practical filter.

For each objective, include a number and a date. “Improve onboarding” becomes “reduce average onboarding time from 6 weeks to 4 weeks by the end of Q3.” Then state the success criteria: the evidence that the objective was met, such as a measured conversion rate, an acceptance test passed, or a milestone reached. If a reader cannot tell whether an objective was achieved, it is not an objective yet.

Step 3: Define the Scope (the “What”), Including What Is Out

Scope sets the boundaries of the project: what is included in the deliverables and what is not. This section has two halves, and the second half is the one that protects you.

Write the in-scope list as the main deliverables and activities the project will produce. Then write the out-of-scope list explicitly. For example: “In scope: email nurture flows, landing page refresh, analytics setup. Out of scope: CRM implementation, brand redesign.” The out-of-scope list is your first defense against scope creep, because when a stakeholder proposes an addition, you can point to a written agreement that it is not part of this project.

Step 4: Set the Summary Budget

A charter needs a budget summary, not a detailed cost breakdown. State the overall estimated cost, how it is roughly distributed (people, tools, materials), and the key financial assumptions behind the estimate — for example, contractor rates or tool subscriptions.

Keep it honest. A budget that was never validated will be the first thing challenged in approval, and the charter’s credibility — and yours — goes down with it. If the estimate is rough, say so and name what would change it.

Step 5: Lay Out Summary Milestones and Timeline

Include the key dates, not the full schedule. Think of the five or six moments that matter: approval date, design freeze, first build complete, launch, acceptance. Each milestone gets a date.

This is deliberately high-level. The detailed task-level schedule belongs in the project plan, which you write after the charter is approved. Putting a day-by-day timeline in the charter makes it a plan and makes it unapprovable in one sitting.

Step 6: Name Stakeholders and Roles (the “Who”)

List the people who matter: the sponsor, the customer, the project manager, and the key approvers. Be explicit about authority — the single most important sentence in the charter is the one that says the project manager is authorized to manage the project and use its resources.

If roles are unclear, a RACI-style clarification can help, but inside the charter a simple list of names and roles is enough. The key stakeholders section should make it obvious who approves what and who will make the project succeed or fail.

Step 7: Record Assumptions, Constraints, and High-Level Risks

Assumptions are things you take for granted and that would change the project if they proved false (“the vendor contract will be renewed at current pricing”). Constraints are limits you must work within (“the launch cannot overlap the product release window”). High-level risks are the few things that could derail the project and deserve a named owner and a planned response.

Keep this short — five to ten assumptions and constraints and a handful of risks at most. This section is not the risk register; it is the high-level conditions the project is betting on.

Step 8: Add Approval, Versioning, and Store It

Finish with the approval block: who approves, the signature line, and the date. Add a version number and a revision date, because the charter is a living document that will change as the project evolves.

Then store it where the team can find it — in a shared drive or in your project management tool — and make the “this is the current version” rule explicit. An approved charter that lives only on the project manager’s laptop is a charter that never happened.

Checklist of Must-Have Sections

Use this checklist to verify your draft before you send it for approval.

A Mini Example You Can Adapt

Here is a condensed example (fictional figures) showing how the sections come together.

Project: Q3 Lead Generation Campaign Refresh — Sponsor: VP of Marketing — PM: Jordan Lee Purpose: Rebuild the quarterly campaign to reduce cost per qualified lead, projected to reach 120% of target by year-end. Objectives: Reduce cost per qualified lead by 20% in two quarters; deliver 15% more SQLs on the same budget; launch by July 15. Scope in: Nurture flows, landing page refresh, analytics setup. Out: CRM implementation, brand redesign. Budget: $40,000 (tools $12,000; content and testing $28,000), assuming current platform pricing. Milestones: Concept approved Jun 10; assets final Jul 5; launch Jul 15. Stakeholders: Marketing director (approver), sales ops lead, analytics lead. PM authority: Jordan Lee is authorized to manage the project and its resources. Assumptions: Platform contract renews at current pricing; two contractors available in Q3. Constraints: No launch during the product release window in early July. Risks: Contractor availability (owner: marketing director); landing page conversion uncertainty. Approved by: VP of Marketing, May 28.

This example fits on one page and contains everything an approver needs. There is no task list, no dependency diagram, no cost line items — those all come in the project plan.

Charter Writing Scenarios With Real Numbers

Scenario 1 — Writing the charter before the business case exists. A small internal team is asked to write a charter for a customer support overhaul with no business case. The writer researches the data anyway and finds the team spends roughly 120 support hours a month answering the same order-status questions. The purpose section states that number and targets a 40% reduction in those tickets within two quarters. The charter is approved because the objective carried a number and a date — the thing vague charters always miss.

Scenario 2 — The out-of-scope list that saves the budget. A website redesign charter has a $60,000 budget and an out-of-scope line that excludes blog migration. In week three, a stakeholder proposes adding the migration “for free.” The project manager reads the out-of-scope line, opens a change request quoting 140 hours and $18,000, and the stakeholder withdraws the request. The one sentence in the charter saved the project’s entire contingency.

Scenario 3 — Approval by negotiation, not submission. A project manager sends a charter to a sponsor who pushes back on the budget estimate of $45,000, saying it should be $38,000. Instead of just lowering the number, the manager walks through the assumptions — tooling at $9,000, content at $36,000 — and the sponsor agrees to $42,000 with a reduced content scope. The charter was approved in one meeting because the numbers were backed by assumptions, not wishes. Without that grounding, the negotiation would have gone in circles.

How to Get Your Charter Approved

Approval is a negotiation, not a formality. Three habits make it go smoothly.

Involve stakeholders before the draft. If the sponsor and key stakeholders have seen the purpose, scope, and objectives in conversation before you write, the document is a confirmation, not a surprise. Charters that fail in review usually fail because the conversation never happened first.

Keep it short and readable. An approver with ten other documents to read will react differently to one page than to twelve. Plain language, a clear budget line, and an explicit scope boundary make it easy to say yes.

Negotiate the real disagreements out loud. If a stakeholder disagrees with the scope or the budget, that disagreement will surface now or during execution — and it is much cheaper now. Use the review to resolve conflicts about what is in and out of scope, who has authority, and what success means.

Common Mistakes When Writing a Project Charter

• Writing a plan instead of a charter. A charter full of tasks, dependencies, and day-by-day detail is unreadable and unapprovable. High-level is the point.
• Vague, unmeasurable objectives. “Improve efficiency” authorizes nothing. “Cut onboarding time from six weeks to four by Q3” gives the project a target it can be held to.
• No out-of-scope list. Without it, scope creep enters through the door you left open. Name what you will not do.
• An approver with no authority. If the person who signs cannot actually grant the project manager authority or commit resources, the signature is theater.
• A budget nobody validated. A number you made up will be the first thing questioned. Ground the estimate in assumptions.
• Skipping the signature and version date. An unsigned, unversioned charter cannot protect any decision. Make approval and revision tracking part of the document.
• Writing it alone. A charter written in isolation misses the disagreements that a short stakeholder conversation would have surfaced — and it will surface them later, at higher cost.

Know This Before You Choose

Before you finalize your charter — and choose the tool you build it in — answer these questions.

• Can you state the purpose in one sentence tied to a business goal?
• Are your objectives measurable, with a number and a date?
• Is the out-of-scope list explicit, and have stakeholders accepted it?
• Is the approver senior enough to grant real authority?
• Does the budget carry its own assumptions, or will it be challenged at approval?
• Will the charter be stored somewhere shared, with versioning, and revisited on major changes?
• Have you resolved the scope and authority disagreements before sending the document for signature?

When your charter is approved, the next step is turning it into a plan — tasks, milestones, schedules, and risk tracking. For teams that want the charter and everything that follows to live in the same workspace, Doitify’s project management workspace supports that workflow, from the signed charter to the tasks that execute it. To be transparent: Doitify is our product, which is why we know its capabilities from the inside; for a very small project, a one-page document in a shared drive is enough.

Conclusion

Writing a project charter is a small effort with an outsized payoff. Gather your inputs, then write the why (purpose and objectives), the what (scope and budget), the who (stakeholders and authority), and the surrounding conditions (assumptions, constraints, risks) — then get it signed by someone who can actually grant authority.

Keep it to one to three pages, make the objectives measurable, name the out-of-scope list, and store the approved version where the team can find it. A good charter takes an afternoon to write, saves weeks of argument during execution, and turns “we are thinking about this” into a project that is authorized, resourced, and ready to plan.