A team charter is a short document, agreed by the whole team, that says why the team exists, what it has to achieve, who does what, and how the team will work together. It's written at the start, usually in a single workshop, and it's what everyone goes back to when priorities clash or the plan starts to drift.
Most of what goes wrong in a new team isn't the work itself. It's two people who each thought they owned the same decision, a goal that meant something different to the sponsor, or a question that sat in someone's inbox for a week. A charter settles those things before they come up. This guide covers the seven parts a useful charter has, a filled-in example, and a template to copy.
Team Charter vs. Project Charter
The names are close and the two documents often get written in the same week, but they answer different questions. A project charter is about the project: it makes the case for it and gives someone the authority to run it. A team charter is about the people doing the work, and how they'll work together.
| Project charter | Team charter | |
|---|---|---|
| The question | Should we do this project, and who runs it? | How will this team work together to deliver it? |
| Written by | The sponsor or project manager | The team, together |
| Covers | Business case, scope, budget, milestones, the project manager's authority | Purpose, goals, roles, ways of working, how decisions get made |
| Read by | Stakeholders and the people who approve funding | The team, and anyone who joins it later |
| Lasts | Until the project closes | As long as the team exists, with reviews along the way |
A permanent team, such as a support team or a design team, may never have a project charter at all. It still benefits from a team charter.
When to Write One
- A new team, or a team brought together for one project.
- A cross-functional team, where people report to different managers with different priorities.
- A remote or hybrid team, where the habits you'd pick up by sitting together have to be written down instead.
- After a big change: a reorganization, a new manager, or a new goal for the team.
- When the same arguments keep coming back: who decides, which channel to use, who owns what.
The 7 Parts of a Team Charter
1. Purpose
Start with why the team exists: the problem it's being asked to solve, why now, and what happens if nobody solves it. Ask the sponsor to explain it in their own words at the start of the workshop. Hearing it from them shows the team how its work connects to the organization's goals, and it's the moment to ask the awkward questions.
Don't tidy the background up. Include the risks, the doubts and what nobody knows yet. People commit to a plan they were allowed to question, not to one they were handed.
2. Goals and scope
Write the mission in three sentences, as project manager Doug DeCarlo suggests: who is doing what, and for whom; what success looks like when the work is done; and why it's worth doing. Then list the two to four goals that get you there. For each one, you should be able to answer yes to three questions:
- Is it SMART: specific, measurable, achievable, relevant and time-bound?
- Does everyone on the team agree with it?
- If we achieve it, will it make a real difference to whether we succeed?
Then write down the scope: what's in, and just as important, what's out. A clear line is the best defence against scope creep, where the goalposts move once the work is underway and nobody adjusts the people, budget or deadlines to match. Changes will still happen, but they'll be decisions rather than drift.
3. Roles and responsibilities
Name the sponsor, the team lead, and what each member is responsible for. For deliverables or decisions that involve several people, a RACI matrix helps: for each one, who is Responsible for doing it, who is Accountable for the result, who must be Consulted, and who only needs to be Informed. Questions to work through:
- Is there a skill or kind of expertise the team needs and doesn't have?
- Which other teams or people must be consulted along the way?
- Does the team have enough capacity for the work and the deadlines?
- Does anyone need training before they can do their part?
Gaps found here are cheap to fix. Gaps found in week six are not.
4. Resources and constraints
List what the team has to work with: how much of each person's week the work gets, the budget, the tools, and any dates that can't move. A budget can be set top-down (a fixed amount you're given) or bottom-up (the cost of each piece of work, added up). Either way, the point is to match it against the goals now. If the team is underfunded or understaffed, it's far better to know at the start and change the goals or the dates than to find out halfway through.
5. Ways of working
This is how the work actually gets done, and it's the part teams most often skip. Agree on:
- Which meetings the team holds, how often and for how long.
- Where communication happens, and how fast people should expect a reply.
- How work is assigned and tracked, and how progress is reported.
- How decisions are made, and who has the final say when the team doesn't agree.
- How disagreements are raised and resolved.
Be specific. “We'll communicate openly” changes nothing. “Questions go in the team's workspace, not email, and get an answer within one working day” does.
6. How success is measured
The goals say what success looks like for the team. This part says how you'll check: which numbers you'll track, when you'll review them, and with whom. It should also be clear about individuals: whether work on this team counts in people's performance reviews, and what's expected of each person. Leaving that vague hurts motivation more than almost anything else in a project.
Plan the end-of-project review now, too. A few questions worth asking every member, and the team as a whole:
- How well did we work together, and why?
- Did everyone take part consistently? If not, what got in the way?
- Did we have the resources we needed: time, budget, skills, support?
- What should the next team do differently?
7. Sign-off and review
End with everyone's agreement, and the sponsor's approval. Asking each person to sign, or to confirm in writing, makes them read the charter properly, and it heads off the two most common complaints later: “I didn't know” and “that's not what I agreed to.”
Allison Rimm, a former senior vice president at Massachusetts General Hospital, learned this the hard way when support for one of her projects evaporated at the final vote. As she wrote in “How to Keep Support for Your Project from Evaporating” for Harvard Business Review, she now records everyone's position at each stage: “That way, if there is ever a disagreement about the status of one of my projects, there is a clear record of everyone's position.”
Finally, set a date to review the charter: at a milestone, at the end of a pilot, or every few months for a permanent team. Review it early, too, whenever someone joins.
Team Charter Example: A Client Onboarding Team
Here is the charter from the image above in full. The agency and the people are made up: a 25-person design and marketing agency forms a four-person team to fix how new clients are brought on board.
| Purpose | New clients wait an average of three weeks between signing and their kickoff meeting. In that time they hear nothing from us, and two of our last ten new clients asked to renegotiate before work had started. Nobody owns the steps in between. |
|---|---|
| Mission | Priya, Maya, Tom and Leo are building one onboarding process for every new client. We're done when every client who signs after 1 May has their kickoff within five working days. That protects the first month's fee, and the client's first impression of us. |
| Goals | 1. An onboarding checklist and a welcome pack, approved by the sponsor, by 27 March. 2. A pilot with the next three new clients, each with a kickoff within five working days of signing, by 30 April. 3. An average score of at least 4 out of 5 when we ask pilot clients how their first week went. |
| Scope | In: everything from the signed contract to the end of the kickoff meeting. Out: sales, contracts, pricing and billing. |
| Roles | Dana (managing director, sponsor): approves the budget and any change of scope. Priya (project manager, lead): owns the plan and the weekly update, and makes day-to-day calls. Maya (account lead): writes the welcome pack and the kickoff agenda. Tom (designer): designs the welcome pack and the client templates. Leo (operations): sets up accounts, access and the client's workspace. |
| Resources | One day a week from each member for ten weeks. A budget of $1,500 for printing and design assets. No new software. The pilot can't delay work for current clients. |
| Ways of working | A 30-minute check-in every Tuesday. All work is a task with an owner and a due date in the team's workspace. Questions go in the workspace, not email, and get an answer within one working day. If two people disagree for more than two days, Priya decides; scope changes go to Dana. |
| Success | The three goals above, reviewed with Dana every other Friday. A retrospective after the pilot. Each member's part in the project is noted in their next review. |
| Sign-off | Agreed by Priya, Maya, Tom and Leo, and approved by Dana, on 2 March. Next review: 30 April, at the end of the pilot. |
How to Write a Team Charter in One Workshop
A first charter takes about 90 minutes with the whole team in the room, or on a call. Before the workshop, the lead drafts the purpose and the constraints with the sponsor, so the team starts from something concrete rather than a blank page. Then:
| Time | Part | How |
|---|---|---|
| 10 min | Purpose | The sponsor explains why the team exists; the team asks questions. |
| 20 min | Goals and scope | Agree the mission, then the goals; write down what's out of scope. |
| 20 min | Roles | Each person says what they think they own; resolve the overlaps and the gaps. |
| 25 min | Ways of working | Everyone writes their own suggestions first, then the team picks the ones it will commit to. |
| 10 min | Success | Decide what you'll measure, and when you'll review it. |
| 5 min | Sign-off | Set the review date and agree how each person will confirm. |
Resources and constraints don't need workshop time if the lead brings them in the draft; check them against the goals as you agree each one. Send the finished charter round within a day, while the discussion is fresh, and collect everyone's sign-off in writing.
Team Charter Template
Copy this into a document and answer each question in a few lines. One or two pages is plenty.
| Part | Questions to answer |
|---|---|
| 1. Purpose | Why does this team exist? What problem is it solving, why now, and what happens if nobody solves it? |
| 2. Goals and scope | Who is doing what, for whom? What does success look like? Why is it worth it? Which two to four goals get us there, and by when? What's in scope, and what's out? |
| 3. Roles | Who is the sponsor? Who leads? What is each person responsible for? Who must be consulted, and who just kept informed? |
| 4. Resources | How much time does each person give? What's the budget? Which tools do we use? Which dates can't move? |
| 5. Ways of working | Which meetings, and how often? Where do we communicate, and how fast do we reply? How is work assigned and tracked? Who decides when we disagree? |
| 6. Success | What will we measure? When, and with whom, do we review it? How does this work count for each person? |
| 7. Sign-off | Who has agreed, and on what date? Who approved it? When is the next review? |
Keep the Charter Next to the Work in Redbooth
A charter filed in a shared drive is forgotten by the second week. In Redbooth, it can live in the same workspace as the team's tasks:
- Write it as a note. Open the team's workspace, go to the Notes tab and create a note for the charter, so anyone in the workspace can find it, including people who join later.
- Collect the sign-off in a conversation. Post the charter in Convos and ask each person, and the sponsor, to reply that they agree. The thread becomes the written record.
- Turn the goals into task lists. Give each goal its own task list, and each piece of work a task with an owner and a due date. Break bigger tasks into subtasks.
- Put the review in the plan. Add a task to review the charter, assigned to the lead and due on the review date you agreed.
Mistakes That Make a Charter Useless
- Writing it for the team instead of with it. A charter handed down is a memo. People keep the agreements they made themselves.
- Turning it into a policy manual. If it runs past two pages, nobody will reread it.
- Vague ways of working. “Be responsive” means something different to everyone. Put a number on it.
- No rule for disagreements. Decide who has the final say before there's something to disagree about.
- Never looking at it again. Review it at the date you set, and whenever someone joins or the goals change.
Questions People Ask
What is the purpose of a team charter?
To give the team one shared answer to why it exists, what it must achieve and how it will work, agreed before the work starts. It prevents the misunderstandings that slow new teams down, and it's the reference point when they happen anyway.
Who writes the team charter?
The whole team, usually in a workshop led by the team lead or project manager. The sponsor contributes the purpose and the constraints, and approves the result.
How long should a team charter be?
One or two pages. Long enough to answer the questions in the template, short enough that people will read it again.
Is a team charter the same as a working agreement?
No. Agile teams often keep a working agreement: a short list of how they work together, such as core hours or how they review each other's work. That's one part of a team charter, the ways of working. The charter also covers the purpose, goals, roles and how success is measured.
How often should a team charter be updated?
At the review date you set, and whenever the team changes: a new member, a new goal, a new sponsor. For a permanent team, every three to six months is a good rhythm.
Start with your next new team, or the one that keeps having the same argument: book 90 minutes, bring a draft purpose, and work through the template together.