How to Write a Project Charter [Free Template + Step-by-Step Guide]

What Is a Project Charter and Why Do You Need One?

A project charter is a formal document issued by the project sponsor that does three things: authorizes the project to exist, defines what success looks like, and gives the project manager authority to allocate resources. Without it, your project has no official standing — you're just a person with a plan and no mandate.

Projects with a clear vision of success achieve a +41 Net Project Success Score, compared to -18 when there's no clear vision (PMI, 2025). The charter creates that clarity by forcing stakeholders to agree on purpose, scope, and success criteria before work begins.

Here's what a charter is NOT:

• Not a project plan — the plan details "how." The charter defines "why" and "what" at a high level
• Not a statement of work — the SOW defines deliverables between parties. The charter authorizes the project internally
• Not a business case — the business case justifies the investment. The charter authorizes the execution

Think of the charter as the project's birth certificate. The project plan is its operating manual.

Before You Start: Gather Your Inputs

Don't sit down to write a charter in isolation. You need input from three sources:

From the project sponsor:

• Why does this project exist? What business problem does it solve?
• What's the budget ceiling?
• What's the deadline, and is it fixed or flexible?
• Who needs to approve this?

From key stakeholders:

• What does success look like from their perspective?
• What are their concerns or constraints?
• Who else should be involved?

From your own analysis:

• What's feasible given the team, timeline, and budget?
• What are the biggest risks?
• What similar projects have been done before? How did they go?

Spend 2-3 meetings collecting this information before you write a single word. A charter drafted without stakeholder input is a charter that gets rejected.

Section 1: Project Purpose (The "Why")

Start here. If you can't articulate why this project exists in 2-3 sentences, you're not ready to write a charter.

The purpose section answers: What business problem are we solving, or what opportunity are we capturing?

Weak example:

"Upgrade the company's IT infrastructure."

Strong example:

"Replace end-of-life network equipment across three offices that caused 14 unplanned outages in the past 12 months, costing an estimated $340,000 in lost productivity. The upgrade will support the planned VoIP and video conferencing rollout scheduled for Q3."

The strong version quantifies the problem ($340K), specifies the scope (three offices), and connects to a strategic initiative (VoIP rollout). Your sponsor didn't approve this project because they enjoy buying switches — they approved it because downtime costs money.

Section 2: Project Objectives (The "What Done Looks Like")

Objectives are measurable success criteria. Write 3-5 using the SMART format: Specific, Measurable, Achievable, Relevant, Time-bound.

How to write each objective:

• Start with a verb (reduce, achieve, complete, deliver, increase)
• Include a specific number or percentage
• Set a timeframe

Example objectives for an IT infrastructure upgrade:

• Reduce unplanned network outages by 90% within 6 months of completion
• Achieve 99.95% network availability (up from current 98.7%)
• Complete migration with zero data loss and less than 4 hours total planned downtime per site
• Support 2x current bandwidth capacity for planned VoIP rollout

If you can't measure it, it's not an objective — it's a wish. "Improve network performance" is a wish. "Achieve 99.95% uptime" is an objective.

Section 3: Scope (The Boundary)

The scope section has two equally important lists: what's in scope AND what's out of scope. The out-of-scope list is actually more important — it's your primary defense against scope creep, which affects 52% of projects (PMI, 2024).

Format it as two columns:

The out-of-scope items aren't random exclusions. They're things that stakeholders might reasonably expect to be included but aren't. WiFi access points are networking equipment — someone will ask "are we upgrading WiFi too?" If it's not in the out-of-scope list, the answer defaults to "I guess so," and your project just grew 30%.

Our finding: In 17 years of managing projects, every scope dispute I've seen could have been prevented by a more specific out-of-scope list. When in doubt, add it to the exclusion list. It's easier to add something back later than to remove it once a stakeholder expects it.

Section 4: Key Stakeholders (The "Who")

Every charter needs a stakeholder table with real names — not departments, not titles, actual people. Each person needs a defined responsibility.

Two rules for this section:

1. The sponsor must be a person, not a committee. Someone needs to make the final call when stakeholders disagree. If it's a committee, decisions stall.
2. Every name needs a backup. What happens when the Technical Lead is on PTO during a critical decision? Name a backup for every key role.

Fewer than 2 in 3 projects have engaged project sponsors, and projects without active sponsors face significantly higher failure rates (PMI, 2025). If your sponsor is disengaged, fix that before you finalize the charter.

Section 5: Budget Summary

The charter doesn't need a detailed cost breakdown — that comes in the project plan. It needs a total budget with major category splits so the sponsor knows the financial commitment they're authorizing.

Example:

Total Budget: $485,000

Always include a contingency line (5-10% is standard). Budgets without contingency are budgets that will be exceeded. If the sponsor asks you to remove the contingency, that's a red flag — they're setting you up to overrun.

For detailed budget templates, see our IT budget planning template and our guide on how to create an IT budget from scratch.

Section 6: Timeline and Milestones

List 4-8 major milestones with target dates. These are decision points and deliverables, not tasks. Use a Gantt chart for task-level scheduling.

The "Gate" column is important — it defines what decision happens at each milestone. "Go/no-go for Site 2" means the team reviews Site 1 results before proceeding. This prevents cascading failures across all three sites if something goes wrong at the first one.

Section 7: Risks and Assumptions

List 3-5 significant risks and 3-5 assumptions. Don't try to be exhaustive — the detailed risk register comes later. The charter just needs the big ones that could change the project's viability.

Risks:

Assumptions:

• Current network documentation is accurate (will verify in discovery phase)
• All three offices can accommodate weekend migration windows
• Existing cabling infrastructure can support new switch bandwidth requirements
• Vendor can deliver all hardware within 30 days of order

If any assumption turns out to be wrong, the charter should be re-evaluated — not silently adjusted.

Section 8: Approval Signatures

This is the part that makes the charter official. Without a signature, everything above is just a proposal.

The sponsor's signature means: "I authorize this project, this budget, and this project manager's authority to execute." Don't start work without it.

Putting It All Together: A Complete Charter in 8 Steps

Here's your writing sequence:

1. Start with Purpose — write 2-3 sentences about why this project exists
2. Define objectives — 3-5 SMART success criteria
3. Draw the boundary — in-scope AND out-of-scope lists
4. Name the team — real names, defined roles, named backups
5. Set the budget — category totals with contingency
6. Mark milestones — 4-8 decision points with gates
7. Flag risks — top 3-5 risks and assumptions
8. Get the signature — don't start without it

The whole document should take 4-8 hours to draft, 1-2 meetings to review, and one signature to approve. If it's taking weeks, you're overthinking it.

Download our free project charter template to follow this structure, or see 5 filled-in project charter examples to see what the finished product looks like across different project types.

For detailed project planning after the charter is approved, see our IT project management template guide and statement of work template.

Frequently Asked Questions

How long should it take to write a project charter?

A project charter should take 4-8 hours of focused writing time, plus 2-3 stakeholder meetings to gather inputs and review drafts. The total elapsed time from first draft to signed approval is typically 1-2 weeks. If it's taking more than 3 weeks, you're either writing a project plan instead of a charter, or you have a stakeholder alignment problem that needs to be resolved before the document can be finalized.

Can I use the same charter template for every project?

Yes — the structure is universal. The 8 sections (purpose, objectives, scope, stakeholders, budget, timeline, risks, approval) apply whether you're upgrading servers or launching a marketing campaign. What changes is the content depth: a $50,000 project might need a 1-page charter, while a $500,000 initiative warrants 3-5 pages. Our project charter template works across all project types and sizes.

What's the biggest mistake people make when writing a project charter?

Skipping the out-of-scope section. Scope creep affects 52% of projects (PMI, 2024), and most scope disputes happen because something was neither explicitly included nor excluded. The second biggest mistake: writing objectives that aren't measurable. "Improve performance" means something different to every stakeholder. "Achieve 99.95% uptime within 6 months" means the same thing to everyone.

Does the project manager or the sponsor write the charter?

The project manager drafts the charter. The sponsor reviews, provides business context (especially the purpose and budget ceiling), and signs it. In practice, the PM does 80% of the writing based on stakeholder inputs. The sponsor's job is to ensure the charter aligns with organizational strategy and to authorize the resources. Some organizations have a PMO that provides templates and quality checks before the sponsor reviews.

Should I include a detailed risk register in the charter?

No — the charter should list 3-5 major risks that could affect the project's viability. The detailed risk register with probability scores, impact assessments, and mitigation plans belongs in the project plan. The charter's risk section answers: "Are there any risks big enough to make us reconsider doing this project?" If yes, those need to be visible before the sponsor signs.

What happens after the charter is approved?

Once signed, the project manager has formal authority to begin detailed planning. The next steps are: develop the project plan (detailed tasks, schedule, resource assignments), create the work breakdown structure, set up the project tracking tools, and hold the kickoff meeting. The charter becomes the reference document for scope decisions throughout the project — when someone asks "is this in scope?", you check the charter.