The Project Charter (One-Pager)

The one-on-one agenda kept your connection with a person on the rails. This page does the same job for a piece of work. When several people set out to build, fix, or launch something together, the most expensive failures rarely come from bad execution. They come from everyone quietly assuming a different version of the goal — and only discovering the mismatch three months in, when it’s costly to unwind.

A project charter is one page, written before work starts, that answers the questions everyone thinks are obvious and almost no one actually agrees on: Why are we doing this? What does done look like? Who decides? What are we deliberately not doing? This page gives you a template you can copy, a guide to using it, and a filled-in example for a realistic cross-team project.

The template

Keep it to one page. The constraint is the point — if it doesn’t fit on a page, you haven’t decided enough yet.

PROJECT CHARTER — <project name>
Owner: <one named person>   Sponsor: <who wants this / pays for it>
Date: <written>   Last reviewed: <date>   Status: <draft / active / done>

PROBLEM
  What's wrong today? Who feels the pain, and how much?
  (2–4 sentences. No solution language yet.)

GOAL & SUCCESS METRICS
  What are we trying to achieve? How will we KNOW we succeeded?
  - Metric 1: <from X to Y by when>
  - Metric 2: <observable, not vague>

SCOPE (in)
  - <thing we WILL do>
  - <thing we WILL do>

NON-GOALS (explicitly out)
  - <thing we are NOT doing, even though someone might expect it>
  - <thing we are NOT doing>

TIMELINE
  - Start: <date>   Target: <date>
  - Milestone 1: <what / when>
  - Milestone 2: <what / when>

PEOPLE
  - Owner (drives it): <name>
  - Decider (final say): <name>
  - Contributors: <names / teams>
  - Must be kept informed: <names / teams>

RISKS & UNKNOWNS
  - <risk> → <what we'll do about it>
  - <open question we still need to answer>

How to use it

Write it before the work, not after. The charter’s value is the conversation it forces. A vague project lets everyone nod along while privately holding different pictures of success. The act of writing “success = X by Y” makes those private pictures collide on paper, where disagreement is cheap. If you can’t get two key people to agree on the goal line, you have just found the most important problem on the project — before you spent a quarter building the wrong thing.

Fill in the sections in order, and stop when a section is hard. If the Problem section is easy but the Success Metrics section is a struggle, that struggle is information: nobody actually knows what winning looks like. Don’t paper over it with a fuzzy phrase like “improve the experience.” Push until you have something you could later check.

Assign exactly one owner. The owner is the single person who loses sleep over the project. This is not the same as the decider (who has final say) or the sponsor (who wants it). One name here prevents the diffuse, everyone-and-therefore-no-one ownership that stalls cross-team work. If you find yourself wanting to list two owners, you have two projects or an unresolved turf question.

Write the non-goals last and out loud. This is the section people skip, and it’s the one that saves you. See below.

Keep it alive — review it, don’t bury it. A charter written once and filed away is just paperwork. Put the link where the work happens and revisit it at each milestone: does the goal still hold? Has a non-goal quietly crept back in? Update the “Last reviewed” date each time. A living charter is the reference you point to when someone asks “wait, are we supposed to be doing this too?”

Why explicit non-goals matter

Scope creep rarely arrives as one big decision. It arrives as a dozen reasonable-sounding additions, each too small to refuse. “While we’re in there, could we also…” A written non-goal turns a hard interpersonal no into a simple pointer: “That’s a good idea, and it’s listed as out of scope for this project — let’s log it for later.” You’re not refusing the person; you’re refusing to quietly change the deal everyone agreed to. Naming what you won’t do is how you protect what you will.

The common trap — the charter that’s really a plan

The most common mistake is stuffing the charter with how: task lists, technical approaches, week-by-week Gantt detail. That belongs in a plan, and it will change constantly. The charter is about why, what, and who — the things that should stay stable even as the plan churns. If your charter needs rewriting every week, you’ve mixed the two. Keep the charter about intent; let the plan hold the moving parts.

A filled-in example

A realistic cross-team project: a mid-sized company’s customer support and engineering teams want to cut how long customers wait for a reply. Notice how the non-goals do as much work as the goals.

PROJECT CHARTER — Faster First Response
Owner: Priya Nair (Support Lead)   Sponsor: VP Customer Experience
Date: 2026-07-08   Last reviewed: 2026-07-08   Status: draft

PROBLEM
  Customers wait an average of 9 hours for a first human reply to a
  support ticket. Complaints about slowness are our #1 negative review
  theme this quarter. Agents lose time manually sorting and routing
  tickets before anyone even reads them.

GOAL & SUCCESS METRICS
  Cut the wait for a first human reply, without hiring more agents.
  - Median first-response time: from ~9 hours to under 2 hours by Oct 31
  - No drop in customer satisfaction score (stay at or above current 4.2/5)

SCOPE (in)
  - Auto-routing incoming tickets to the right team
  - A triage view that surfaces the oldest unanswered tickets first
  - Templated first-reply drafts agents can edit and send

NON-GOALS (explicitly out)
  - NOT automating the full resolution — a human still answers
  - NOT changing which support tool we use (no migration this project)
  - NOT touching phone or live-chat channels — email/tickets only
  - NOT hiring; this is about the same team responding faster

TIMELINE
  - Start: Jul 14   Target: Oct 31
  - Milestone 1 (Aug 15): auto-routing live for one product line
  - Milestone 2 (Sep 30): triage view + templates in agents' hands

PEOPLE
  - Owner (drives it): Priya Nair, Support
  - Decider (final say): VP Customer Experience
  - Contributors: 2 engineers (Platform team), 3 senior agents
  - Kept informed: Sales (they field the complaints), Finance

RISKS & UNKNOWNS
  - Engineering time is shared with the billing project → sponsor to
    confirm the 2 engineers are protected for this work
  - Templates could feel robotic and hurt satisfaction → agents review
    all templates before launch; watch the CSAT metric weekly
  - Open question: is "first human reply" measured in business hours
    or clock hours? (decide before Milestone 1)

Look at what those four non-goals prevent. Without the “not automating full resolution” line, someone reasonably asks for chatbots and the project doubles. Without “not changing tools,” a well-meaning suggestion to migrate platforms swallows the whole timeline. The non-goals aren’t there to be negative — they’re the fence that keeps a focused project from sprawling into an impossible one.

In practice — the disagreement that surfaced early

On a real project like this one, the charter draft is often where the sponsor and the owner discover they disagree. The owner assumed “faster response” meant faster first reply; the sponsor meant faster full resolution. That’s a huge difference in scope, and it would normally stay hidden until a frustrated review meeting months later. The charter surfaced it in an hour, in a room, when the only cost was a conversation. That single caught mismatch usually pays for the whole practice of writing charters.

Case study — Amazon’s written-narrative culture

Since the early 2000s, Amazon has been known for opening major meetings by having everyone silently read a written document before any discussion. The reported reasoning is simple: writing forces clear thinking in a way slides and verbal pitches don’t, and it exposes fuzzy logic that bullet points hide. A charter works on the same principle at smaller scale — the discipline of writing the goal down in full sentences is what makes vague thinking visible. Treat the difficulty of writing the page not as an obstacle but as the diagnosis.

How it connects

The charter names one owner and a decider; when the roles get more tangled across a big team, reach for the RACI matrix to lay out who’s responsible, accountable, consulted, and informed. Once work is underway, the weekly status report tracks progress against the charter’s metrics, and any significant change of direction should be captured in a decision document rather than quietly rewriting the charter’s intent.

Try this

Pick one project you’re involved in right now — ideally a fuzzy one where you suspect people picture different outcomes. Fill in this template in under an hour, and pay attention to which section is hardest. Then send the draft to one other person on the project and ask a single question: “Does this match your picture of what we’re doing?” The gap in their answer is exactly what the charter exists to catch.