Project Charter Template: A One-Page Version for Small Teams

A project charter is a short document that makes a project official: it says why the project exists, what it will deliver and what it will not, who leads it, who decides when there is a disagreement, what has been committed to it, and who agreed to all of that. For a small team it fits on one page with eight sections, and its real job is to be signed. Write it before the plan, have the person who owns the money or the business problem approve it, and keep it unchanged unless that person approves a change. The template, a filled example for a small US business and the parts you can skip are below.

What a project charter is for

Government frameworks put it formally. The California Department of Technology’s project management framework templates↗ (opens in a new tab) describe the charter as the document that “Formally authorizes a project. It describes the business need for the project and the anticipated project results.” Strip away the formal language and a charter does three jobs that nothing else on a small project does:

• It authorizes. Somebody who can commit money, people or time says yes, in writing, to this project and not some other version of it.
• It names the leader. One person runs the project day to day, and everyone can see that the sponsor gave them the job.
• It draws the boundary. The scope and the exclusions are agreed before work starts, which is the cheapest moment to argue about them.

A charter is not a plan. It answers whether, why and who; a plan answers how and when. Once the charter is signed, the one-page project plan template turns it into milestones, owners and tracking. And a charter is not a meeting: the project kickoff meeting agenda is where the team hears the charter read out and agrees how the work will run.

Proposal, charter, plan: which comes first

• A proposal asks for a yes. It argues the problem is worth solving and suggests how. See the sister post, project proposal template.
• A charter records the yes. It is shorter than the proposal, because the arguing is over, and it is signed.
• A plan says how the work will be done, and changes more often than the charter does.

On a small project the three can be written in one afternoon by the same person. Keep them separate anyway. When someone later asks “did we agree to that?”, the charter is the page that answers, and it answers better when it has not been rewritten every week.

The sections that matter

1. Why: the business problem, in the words of the person who has it. “Catering orders come in by phone and email and we lose some” is a why. “Build an online form” is a solution.
2. Goal: the outcome and how you will check it. A goal you cannot check cannot be finished.
3. Scope in and out: what the project delivers, and what it does not. The out list is the most valuable part of the page.
4. Milestones: three to five results, in order, with a rough target month for each.
5. Sponsor and lead: one name each. The sponsor approves and decides scope; the lead runs the work.
6. What is committed: people, time and budget, in words. “Marcus, two days a week until launch” is enough.
7. Risks and assumptions: the three to five things most likely to go wrong, and what you are assuming is true.
8. Approval: who signed, and on what date.

On sponsor and lead, one name each is a rule, not a preference. The federal government’s Digital Services Playbook↗ (opens in a new tab) puts it as a play of its own: “There must be a single product owner who has the authority and responsibility to assign tasks and work elements; make business, product, and technical decisions.” Two leads means each assumes the other is watching.

On approval, California’s framework is explicit that the sponsor is the one who approves the project charter↗ (opens in a new tab), alongside the preliminary scope statement, during initiation. On a small team the sponsor is usually the owner or the manager who asked for the project, and a dated “Approved” line from them is the whole ceremony.

On risks, rate each by how likely it is and how much it would hurt, which is how the NIST glossary defines risk↗ (opens in a new tab): typically a function of the adverse impact if an event occurs and the likelihood of it occurring. High, medium or low on each is enough for five lines.

A one-page project charter template

# Project charter: [Project name]
Sponsor: [one name]      Lead: [one name]
Approved: [name], [Month day, year]

## Why
[The business problem, in the sponsor's words. Two or three sentences.]

## Goal
[The outcome, and how you will check it.]

## Scope
In:
- [What this project delivers]
Out:
- [What it does not, even if someone will ask]

## Milestones
1. [A result, not a phase]            Target: [Month]
2. [ ]                                Target: [Month]
3. [ ]                                Target: [Month]

## What is committed
People: [who, and how much of their time]
Budget: [approved or not, and where it comes from, in words]

## Risks and assumptions
- Risk: [what could go wrong] | Likelihood: H/M/L | Impact: H/M/L
  Response: [what we do now]
- Assumption: [what we are taking as true]

## Changes
Scope changes need: [the sponsor's approval, recorded where]

A filled example for a small business

Harbor Street Bakery is a fictional twelve-person bakery that takes catering orders by phone and email. The owner has agreed to hire a small web studio and wants the project written down before anyone starts.

# Project charter: Online catering orders
Sponsor: Dana (owner)      Lead: Marcus (catering manager)
Approved: Dana, October 6, 2026

## Why
Catering orders arrive by phone, email and text. Some are missed,
and the kitchen often learns about a large order the day before.

## Goal
Customers order catering online, pay a deposit, and the kitchen sees
every order in one list. Check: no missed orders in December, and
every order visible to the kitchen at least 48 hours ahead.

## Scope
In:
- Online order form for the six catering trays on the current menu
- Card deposit at ordering, sales tax calculated at checkout
- Pickup, or delivery to ZIP codes within the current delivery area
- Email confirmation to the customer and the kitchen
Out:
- Wedding cakes and custom orders (stay as consultations)
- Changing the retail menu or prices
- A loyalty program

## Milestones
1. Menu, delivery ZIP codes and deposit rules agreed   Target: October
2. Ordering works end to end on a test site            Target: November
3. Live, announced to past catering customers           Target: November

## What is committed
People: Marcus, two days a week until launch; Dana, one hour a week
Budget: the web studio's fixed fee in its signed proposal; no other spend

## Risks and assumptions
- Risk: holiday rush overlaps launch | L: H | I: M
  Response: launch by November 20 or wait until January
- Risk: deposit rules confuse regular customers | L: M | I: M
  Response: Marcus calls the top ten customers before launch
- Assumption: the current point-of-sale system can export the menu

## Changes
Scope changes need: Dana's approval, recorded as a decision

Notice what the example leaves out: no stakeholder register, no organization chart, no cost breakdown and no detailed schedule. Each of those exists in larger charter templates. None of them would change what Dana is agreeing to.

What a small team can skip

Formal charter templates are written for projects with many departments, contracts and auditors, and even California’s framework offers a shorter “mini” version, which it describes as designed for “the smaller of the low complexity projects, pilot projects, and those who are exploring a proof of concept.” For a team of three to ten, skip these unless a client or a regulator asks for them:

• A stakeholder register. If everyone affected fits around one table, list them in the Why or the Approval line.
• A version history table. Date the page; if scope changes, record the change and who approved it.
• A line-item budget. The charter says what is committed; the detail lives in the proposal or the accounts.
• A change control board. One sponsor who approves scope changes is the board.
• A RACI chart for every task. One sponsor and one lead covers most small projects; if roles are genuinely tangled, a RACI matrix is a separate half hour.
• Schedules and work breakdowns. Those belong in the plan, not the charter.

Do not skip the out list, the single sponsor, or the dated approval. Those three are what make a charter worth having when the first “can we also…” arrives. The sister post on scope creep covers what to do then.

From signed charter to a board

A charter that lives in a shared drive is read once. On a fenbs board, the parts that need to stay true can live next to the work:

• Record the approval on the Decisions and rules page: what was decided, why, who decided and when. The decider is always a person, never an AI assistant.
• Ask the sponsor to sign it off there. Sign-off is for board members only, and an approval counts only for the words it was given for: change the decision afterward and it shows as approved for an earlier version.
• Record each out-of-scope line as a rule, such as “Wedding cakes stay as consultations.” A rule holds from now on, and every connected AI assistant reads the rules first, before it touches the board.
• Turn the milestones into tasks with Add many, set the project to the charter’s name, and let the tasks move through To Do, Next Up, In Progress and Completed.

Be clear about the gaps. fenbs has no due dates, no Gantt chart and no assignee field you can set, so target months stay on the charter and the lead’s name goes in the task note. The board tracks the work; the charter keeps the agreement.