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. It happens to good projects run by good people, and the problem is rarely effort. Nobody had written down what “done” meant.
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. Two is the maximum. A project charter works as a quick overview for stakeholders, not as a full plan, and the moment it starts carrying task lists it stops doing its real job. I used to think a thorough charter was a good charter. A thorough charter is an unread one.
What goes in a project charter?
Eight things, each answered in a sentence or two. If any of them takes a paragraph, you haven’t decided it yet, and that’s worth knowing before the work starts.
- Purpose. Why are we doing this? Name the problem and the cost of leaving it alone.
- 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.
- Deliverables. The things that exist at the end that don’t exist today: a configured system, a written process, a trained team.
- Success measure. One number you can check, with a baseline and a target.
- 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.
- Milestones and dates. Three to five milestones, with a finish date you can defend.
- Resources. People, their time, and money. If someone’s giving you 20% of their week, write that down.
- 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. Sponsors sometimes push back on signing anything, usually because “we all agree, don’t we?” We do, today. The signature is for week 7, when the agreement gets tested and everyone remembers the meeting a little differently. It doesn’t need to be a wet signature or a formal approval workflow. A reply to an email that says “approved” is enough, as long as it’s stored where the team can find it.
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 with made-up numbers, not a template to copy word for word, but every line in it is the kind of line I’d want to see before agreeing to run the project.
| Charter field | What it says |
|---|---|
| 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. Notice that the in-scope line includes setting up categories. That one item hides more work than it looks, and if the category list is wrong on day one your reporting is wrong for a year, which is why I’d spend real time on ticket categories that survive reporting before configuration starts, not after. Notice too what’s missing: no task list, no Gantt chart, no named vendor. Those come later.
How do you work out the resources line?
Percentages on a charter look harmless until you turn them into hours. Assume a 37.5-hour working week. The team lead at 50% is 37.5 x 0.5 = 18.75 hours a week. The project runs to the week 14 review, so that’s 18.75 x 14 = 262.5 hours of the team lead’s time. The two agents at 20% are 37.5 x 0.2 = 7.5 hours a week each, so 15 hours a week between them. They’re needed up to go-live in week 10, which makes 15 x 10 = 150 hours.
Now look at what the desk loses. Twelve agents at 37.5 hours is 12 x 37.5 = 450 hours of capacity a week. Taking 15 of those for the project is 15 / 450 = 0.033, or 3.3% of the desk’s week. That sounds small. It isn’t small if you’re already short on the phones, because those 15 hours come out of the busiest part of the day unless someone plans otherwise, and the queue doesn’t care that it’s for a good cause. If your staffing already accounts for shrinkage on the rota, project time belongs in that same calculation, as another category of time agents are paid for but aren’t taking contacts. Writing the hours on the charter means the sponsor agrees to that 3.3% in advance, instead of you discovering it in week 4 when service level drops. Put the hours on the page. Percentages are how projects quietly borrow time they never pay back.
How do you check the success measure each week?
A success measure only counts if someone can rebuild it from the raw data. For the example charter, export the week’s tickets into a sheet called Tickets, one row per ticket, with headings in row 1 and data from row 2 down. Column A holds the ticket ID, column B the priority (P1 to P4), column C the date and time the ticket was created, and column D the date and time of the first response. Column E works out the minutes to respond with =(D2-C2)*1440. Excel stores times as fractions of a day, so subtracting the created time from the response time gives a fraction, and multiplying by 1,440 (the number of minutes in a day) turns it into minutes. A ticket created at 09:12 and answered at 10:47 gives 0.06597 of a day, and 0.06597 x 1,440 = 95 minutes.
Column F holds the target for that ticket’s priority, typed in or looked up from a small priority table, say 120 minutes for a P2. Column G asks whether the target was met with =IF(E2<=F2,1,0): if the minutes in E are less than or equal to the target in F, it writes 1, otherwise 0. The 95-minute P2 scores a 1. Copy E to G down every row. The weekly figure is then =SUM(G2:G265)/COUNT(G2:G265), where SUM adds up the 1s (tickets that met target) and COUNT counts every ticket in the range. If 238 of 264 tickets met their target, that’s 238 / 264 = 0.902, or 90.2%. That’s the number the review in week 14 looks at, and it’s the same logic I’d apply to choosing the right KPI for anything else: if you can’t say where the number comes from, it isn’t a measure. It’s an opinion with a percentage sign.
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’s common for a team to spend two weeks building a beautiful plan and then find out in the first steering meeting that the sponsor wanted something different. The plan wasn’t wrong. It was answering a question nobody had agreed on.
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. The charter doesn’t stop scope creep. It makes it visible, and visible scope creep usually stops itself.
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. Nothing you wrote is wasted.
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. In the ticketing example, that means naming who owns the category list, the priority targets and the weekly backlog report once the project team steps away. If that line is blank, the system will drift back toward the shared mailbox within a quarter. Projects end. Services don’t.
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. Leave off the vendor’s feature list too. It’s tempting to paste in what the new system can do, but the charter is about what your team needs, and a feature list invites the sponsor to ask for all of it.
Leave off the history as well. A paragraph on how the shared mailbox came to be, who set it up and why it made sense at the time is interesting to the people who were there and useless to the sponsor. One sentence of context is enough: what’s broken today and what it costs. If the cost is hard to put a number on, use the closest thing you can count, such as the 26 tickets in the example week that missed their target (264 – 238 = 26), or the minutes agents spend each day searching the inbox for the latest reply on a thread. A small real number beats a big guessed one. Sponsors can tell the difference.
Write the charter, get it signed and keep it where the team can see it. Pin it to the top of the project folder, so it’s the first thing anyone opens. When a decision gets difficult three months in, it’s the page that settles it.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
