Charter examples that make the first week of a project easier

Week one of a project is the cheapest week to disagree in. Everyone is still willing to say the plan sounds wrong, nobody has built anything yet, and changing the scope costs a conversation rather than a rewrite. By week four the same disagreement costs a fortnight, and by week eight it costs the relationship with whoever is paying.

A charter is the document that forces the week one disagreement to actually happen. The examples circulating online tend to be blank templates with the interesting parts left as placeholders, which is exactly the part people get wrong. What follows is three charters written out in full, the distinction between the two documents that share the name, and the test for whether the version you are about to write will be opened again.

Two different documents share the name

Searching for charter examples returns two kinds of document mixed together, and they do different jobs.

	Project charter	Team charter
What it settles	Why this project exists, what counts as done, who can decide	How this group of people works together
Written when	Before the work starts, once	When a team forms, or when the way it works stops working
Who agrees to it	Whoever is funding or sponsoring the work	Everyone in the team
Lifespan	The length of the project	Until the team changes shape
Length that survives	One page	One page
The failure mode	Written by the project manager alone and signed without being read	Written in a workshop, felt good, never referred to again

The overlap is real, which is why they get confused. Both name people, both set expectations, both are written at a beginning. The difference is what question they answer when somebody opens them under pressure. A project charter answers "is this in scope and who decides". A team charter answers how this team is supposed to handle it.

A team running one project at a time can reasonably merge them into a single page. A team running several projects should not, because the team charter outlives any individual project and will be rewritten every time if it is buried in a project document.

What a charter has to settle to be worth writing

The sections a template offers are not all load-bearing. Five of them do the work, and a charter with only those five beats a thorough one that nobody reads.

The reason, stated as a problem and not as a solution. "Replace the booking system" is a solution. "Staff spend around two hours a day re-entering bookings by hand and mistakes reach customers" is a problem, and it survives the discovery that replacement is the wrong answer.

What done looks like, in terms somebody outside the team could check. Not "improve the process". Something observable, by a date.

What is explicitly not included. The single most valuable section and the one most often left blank. Scope is defined by its edges, and a charter without exclusions has not defined anything.

Who decides what, by name. One person who can approve a change of scope. One person who can approve spend. Where those are the same person, say so. Where they are two people who disagree, that is the finding, and it is better found in week one.

What would make this stop. The conditions under which the project should be cancelled or paused. Almost nobody writes this, and it is the section that saves the most money, because a project without a stopping condition runs until somebody is embarrassed.

Example: a one page project charter

Written for a small team replacing a manual process. The wording is deliberately plain.

Project: Booking intake replacement

Problem: Two staff spend most of each morning copying booking requests from email into the scheduling sheet. Mistakes reach customers roughly once a week, and each one costs a phone call and a goodwill gesture.

Done looks like: Booking requests arrive in one place, are assigned to a day without retyping, and the error rate drops to under one a month for two consecutive months.

In scope: Intake of new bookings. Assignment to a day and a person. Notification to the customer that the booking is confirmed.

Not in scope: Payments. Cancellations and refunds. Reporting. The existing scheduling sheet stays as it is for now. Anything touching the till.

Decisions: Scope changes are approved by the operations lead. Anything requiring new spend goes to the owner. Day to day choices about how it works are made by whoever is building it, without asking.

Stop if: The error rate has not moved after six weeks of the new intake being live, or the two staff report that the new way takes longer than the old one.

Timeline: Eight weeks, reviewed at week four.

That fits on one page and answers every question likely to be asked in the first month. The exclusions section is doing most of the work, because payments and refunds are exactly what somebody will suggest adding in week three.

Example: a team charter for a team that already exists

Team charters are usually written for new teams, which is the wrong moment. A new team has no evidence about how it works. A team six months in has plenty, and the charter it writes is about specific friction rather than about values.

Team: Product delivery, five people, two of them part-time

How work arrives: Everything goes on the board. Requests that arrive by direct message get put on the board by the person who received them, or they do not exist. No exceptions for urgent items, because urgent items are the ones most worth having a record of.

How decisions get made: Whoever owns the item decides. If it affects someone else's work, they ask first. If two people disagree and neither will move, the team lead decides that day rather than scheduling a discussion.

Response expectations: Comments on a card get an answer within one working day. Messages outside working hours have no expectation attached, including from the lead.

Meetings: One planning session a week, thirty minutes, cancelled if the board is current. No status meeting, because status lives on the board.

What the team stopped doing: Copying decisions into a separate document. Anything decided in a comment stays in the comment.

Review: Reread this in three months, or the first time two people are surprised by the same thing.

Notice that none of these lines are aspirations. Each one is a rule somebody could be held to, which is the difference between a team charter and a poster.

Example: a charter for work with an outside client

The third common case, and the one where a charter earns its keep most obviously, because the other party has their own understanding of the deal.

Engagement: Website rebuild for an outside client

What the client is buying: A rebuilt public site with the existing content migrated, on the platform agreed at kickoff.

What the client is not buying: New copywriting. Photography. Ongoing maintenance after handover. Migration of the old blog archive, which stays where it is under redirects.

What is needed from the client, and by when: A single named approver. Brand assets in week one. Feedback on each design round within three working days, since the timeline assumes it.

How change requests work: Anything outside the scope above gets quoted before it gets built. Nothing is added on the strength of a conversation.

Handover means: Access transferred, a walkthrough recorded, thirty days of fixes for anything that does not match what was agreed.

The section that matters here is the one naming what is needed from the client. Most overrun on client work is not caused by the work taking longer. It is caused by waiting, and a charter that fixes a feedback window converts waiting from an accident into a documented decision by the other side.

What makes most charter examples misleading

Three things, and they are why downloading a template often produces a worse document than writing a page from scratch.

Length signals seriousness, and it should not. Templates run to eight sections with subsections because a long template looks more professional. A charter that takes an hour to read will be skimmed at signing and never reopened. One page is not a compromise, it is the working size.

The interesting sections are left blank. Every template has a box labelled "risks" and no guidance on what a useful risk looks like. A risk written as "scope creep" is not a risk, it is a word. A risk written as "the client's approver is on leave for two weeks in month two" is something that can be planned around.

The examples are written for organizations nobody reading them works in. Most published charter examples come from consultancies and large programme offices, so they carry governance structures, steering committees and escalation paths that a team of six does not have. Copying the structure imports the ceremony without the people to run it, and the result reads as though somebody is pretending to be a bigger company than they are.

They assume a signature is agreement. Plenty of charters are approved without being read, and an unread charter is worse than none, because it creates the impression that scope was agreed. The only evidence of agreement is somebody having objected to something and the objection having been resolved. A charter that generated no objections was not read.

Where the charter should live

A charter kept in a folder of planning documents is consulted twice: once at kickoff and once during the argument that it could have prevented, usually too late.

The version that works is pinned somewhere people already look, which in practice means the board the work runs on. A card or a board description holding the five load-bearing sections, with the exclusions visible, does more than a well formatted document in shared storage, because the question a charter answers arrives while somebody is looking at the work. Whether that is comfortable depends on whether a card can hold a real document, and the kinds of content a card supports decide it.

The other habit worth building is rereading it on a fixed date rather than when trouble starts. Week four for a short project. Quarterly for a team charter. The reread takes five minutes and its purpose is to catch the sections that have quietly become untrue, since a charter that is half wrong gets ignored entirely rather than corrected.

What to change first

Take the project currently underway and write only the exclusions section, listing what is not included, then send it to whoever is paying for the work. The replies will tell you within a day whether the scope is agreed. Put the finished page where the work is tracked rather than in a documents folder, which Pinateca will hold on the board itself for a team of up to five at no cost.

Q1. What is the difference between a project charter and a project plan?

A charter settles why the work exists, what counts as done, what is excluded and who decides. A plan settles how and when, task by task. The charter is written once and changes rarely, while the plan changes constantly, which is why keeping them in the same document causes the charter to be rewritten every time the schedule slips.

Q2. How long should a charter be?

One page. Longer charters are read once at signing and not again, which removes the only value a charter has. If a section cannot be summarised into a few lines, it usually belongs in a separate document that the charter references rather than absorbs.

Q3. Who should write a project charter?

Whoever will be held to it, drafted in a room with the person sponsoring the work rather than circulated for comment afterwards. A charter written alone and approved by silence records one person's assumptions. The objections raised while writing it are the actual product.

Q4. Does a small team need a charter at all?

For a two week piece of work, no. For anything running longer than a month, or any work with an outside client, the exclusions section alone pays for the twenty minutes it takes. Small teams can skip the formal template entirely and keep five headings: problem, done, excluded, decisions, stop conditions.

Q5. When should a team charter be rewritten?

When the team changes shape, or the first time two people are surprised by the same thing. Rewriting on a schedule tends to produce cosmetic edits, while rewriting after a specific misunderstanding produces a rule that prevents the next one. A three month reminder to reread it is enough to catch the lines that have gone stale.