The One-Page Project Charter Every Support Team Should Write

A project charter is a one-page agreement between the person who wants a project done and the person who has to deliver it. It says why the project exists, what’s in and out of scope, who’s accountable, and how everyone will know it worked. Support teams need one because support projects fail in a predictable way: they start as a favour, grow into a commitment and end as an argument about what was promised.

A charter stops that argument before it starts. It takes an hour to write and saves weeks of rework, and the best ones are short enough that the sponsor actually reads them. One page is the target, and two is the maximum. A project charter works as a quick overview for stakeholders, not as a full plan.

What goes in a project charter?

Eight things, each answered in a sentence or two.

1. Purpose. Why are we doing this? Name the problem and the cost of leaving it alone.
2. Scope, in and out. What the project covers, and just as important, what it deliberately doesn’t. The “out” list is where most scope arguments get settled in advance.
3. Deliverables. The things that exist at the end that don’t exist today: a configured system, a written process, a trained team.
4. Success measure. One number you can check, with a baseline and a target.
5. Sponsor and owner. The sponsor is the person with the budget and the authority to say yes. The owner is the person who runs the project day to day. They’re rarely the same person, and the charter should name both.
6. Milestones and dates. Three to five milestones, with a finish date you can defend.
7. Resources. People, their time, and money. If someone’s giving you 20% of their week, write that down.
8. Risks and dependencies. The two or three things most likely to hurt, and who you’re relying on.

Sign-off matters as much as content. Without a signature from the sponsor, a charter is a proposal. With one, it’s your authority to ask for people’s time.

What does a charter look like for a real support project?

Take a common one: moving a twelve-person help desk from a shared mailbox and a spreadsheet to a hosted ticketing system. This is an illustrative charter, not a template to copy word for word.

• Purpose: Tickets are tracked in a shared inbox and a spreadsheet, so nobody can say how many are open or how old they are. Customers chase us instead of the other way round.
• In scope: Setting up categories, priorities and escalation rules; moving open tickets; training twelve agents; basic reporting. Out of scope: Phone system changes, a customer self-service portal, historical tickets older than 12 months.
• Deliverables: A configured ticketing system, a one-page process for each priority, a trained team, a weekly backlog report.
• Success measure: The percentage of tickets with a first response inside the agreed target rises from “unknown” to a measured 90% within eight weeks of go-live.
• Sponsor and owner: The head of operations, who funds it, and a team lead, who runs it.
• Milestones: Requirements agreed by week 2, configuration done by week 6, data moved and team trained by week 9, go-live in week 10, review in week 14.
• Resources: One team lead at 50%, two agents at 20% each, a vendor account manager, a small training budget.
• Risks: Agents revert to the old inbox after go-live; the sponsor’s priorities change in week 6; the vendor’s reporting can’t produce the weekly backlog view.

That’s about 250 words. Anyone reading it knows what they’re signing up for.

Why does a support project need a charter before a plan?

Plans describe how. A charter decides whether. Writing the charter first forces three conversations that otherwise happen late and badly: whether the problem is big enough to fix, who’s actually accountable, and what “done” means. Skip them and you end up planning detailed tasks for a project nobody has authorised.

It also protects the team from the quiet expansion of scope. When someone asks you to add a self-service portal in week 7, you point at the out-of-scope line, agree that it’s a good idea and treat it as a change request: more time, more money, or something else comes off the list. That’s a far easier conversation with a signed page on the table. If the project depends on customer commitments, line it up with your internal and external SLAs first, because a project that quietly changes what you can promise needs the sponsor to know that on day one.

How is a charter different from a PRINCE2 project brief?

They’re close relatives. PRINCE2 starts a project with a project brief that covers the definition of the project, an outline business case, the approach and the team structure, and that brief later grows into a fuller initiation document. A charter does the same first job in a lighter form. The PRINCE2 project brief is more formal and more complete, and it suits larger projects with a project board. For a support team’s typical project of a few people and a few months, the one-page charter is plenty, and if the project grows, it becomes the front page of the brief.

The same thinking fits ITIL v3’s service transition ideas. Anything that changes a service the desk supports needs an owner, a measure and a plan for operating it afterwards. A charter that names who runs the new process after go-live saves you from the usual orphan: a project that was delivered and then nobody owned.

What should you leave off the page?

Task lists, detailed schedules and anything that reads like a plan. Those belong in the project plan that follows, and putting them on the charter makes it long, which makes it unread. Also leave off aspirations you can’t measure. “Improve customer satisfaction” is a hope. “Raise the share of tickets answered within the target from unmeasured to 90%” is a commitment.

Write the charter, get it signed and keep it where the team can see it. When a decision gets difficult three months in, it’s the page that settles it.