Documents
How to write a project charter
A project charter authorises a project on a few pages: the problem and a measurable objective, what is in and out of scope, the deliverables, who is on the team and what each may decide, the budget cap, key milestones, the first risks and the sponsor's signature. It fixes the deal; the project plan that follows schedules the work.
Indunil Asanka · Co-founder
6 min read · Published
To write a project charter, state the problem and an objective written as measurable targets with a date, list what is in scope and what is out side by side, name the deliverables with acceptance tests, set out the team and the decisions each person may make, give the budget cap and the key milestones, name the risks worth knowing on day one, and have the sponsor sign. Keep it to about three pages so people actually reread it when a scope argument starts.
An objective that can be measured
The objective is what the benefits review will test, so it has to be numbers with a deadline. The project charter example, for a fictional distribution company replacing paper pick sheets with a scanning warehouse system, opens with the problem in two sentences: 9,800 orders a week picked from paper at two depots. The objective follows as two targets: pick error rate from 1.8% to under 0.5%, and average dispatch time from 41 to 25 minutes, within three months of go live at each depot.
Because the objective is numeric and dated, the benefits review on 30 June 2027 is a meeting with a pass or fail, not a conversation about how the rollout felt.
Put the facts people look up first in a header block: project name and code, sponsor, project lead, approval date and version. The example’s code, WMS-01, repeats at the top of every page with the version number, so any loose page can be traced back to the charter it belongs to.
Governments that run many projects formalise this step. Queensland’s policy on portfolio, program and project management requires agencies to use endorsed methodologies to direct and report digital projects and to keep business cases updated through every stage, and the UK government’s project delivery functional standard sets expectations for how projects are directed and managed from the start. A small business needs none of that machinery, but the principle travels: nothing starts until someone accountable has approved a written objective, scope and budget.
Scope in and out, and deliverables
The scope section is the part of a charter people reread in the middle of a project, so make it readable in ten seconds. The example uses two lists side by side. In scope: the two named depots, receiving and put away, picking with handheld scanners, dispatch scanning and manifests, a driver delivery app, and invoicing integration. Out of scope: the third depot, finance integration beyond invoicing, returns processing, and fleet telematics.
The out list names exactly what someone would otherwise assume is included. That is its whole value.
Deliverables need acceptance tests, not descriptions. The example lists five, each with a measurable test: the configured system passes a 42 case test script with no severity one defects; 40 scanners each connect in every racking aisle; 14,000 SKUs are migrated with counts within 0.2% of the physical count; the driver app runs a full delivery day for 26 drivers with no paper fallback; and 58 depot staff are signed off against role checklists. The statement of work example shows how the same acceptance thinking carries into a supplier’s scope when a vendor does the work.
Team and authority
A list of names is not enough. Each role needs the decisions it may make, and the most useful column is a dollar figure. The example’s team table gives the sponsor, the Operations Director, authority over budget and scope changes above $10,000; the project lead decides day to day matters up to $10,000; each depot lead decides go live readiness at their depot; the vendor’s project manager owns delivery of the configured system; and the IT lead owns invoicing and network integration.
That $10,000 line is the change control rule. When a dispute arises about who may approve an extra scanner or a week of consulting, the answer is on page two.
Budget, milestones and risks
Budget. List the cost lines with contingency and a total that acts as a cap. The example has six lines: licences for three years at $96,000, 40 scanners at $58,000, implementation at $120,000, training and backfill at $36,000, and 10% contingency of $31,000, totalling $341,000. The contingency is 10% of the $310,000 base, and the lines add to the total.
Milestones. Five dates on a timeline: charter approved on 5 October 2026, design signed off on 6 November, the first depot live on 8 February 2027, the second on 22 March, and the benefits review on 30 June. Go lives are deliberately held outside peak season, which is also listed as a risk.
Risks. Name only the handful worth knowing before approval, each with likelihood, impact, owner and response: wifi gaps in the racking, driver app adoption, a peak season clash, SKU data quality and key staff leaving. The detailed scoring belongs in a risk register once the project starts.
Sign off, versions and change
The approval section is short and does one job. The example has the sponsor and project lead sign side by side, above a sentence saying that by signing the sponsor authorises the project to the budget and scope above, and that changes to either are issued as a new version of the charter.
Add success criteria and assumptions just before it. The example lists three success measures with targets and when each is measured, and four assumptions, including that the invoicing system API is available as documented and that spend is capped at $341,000 with changes through change control.
In PRINCE2, AXELOS’s project method, the equivalent early document is the project brief, which gives the project board a firm basis for deciding whether to initiate the project. Whichever name your organisation uses, the test is the same: could someone who missed every meeting read it and know what was approved?
The sections table
The table at the end of this article lists thirteen sections of a project charter, what each contains, and how the warehouse rollout example handles it. The note on what a project charter is covers the definition, and the guide on how to write meeting minutes covers recording the decisions made at the kickoff and steering meetings that follow.
Common mistakes
An objective with no number. “Improve warehouse efficiency” cannot pass or fail.
No scope out. Every assumption left unwritten becomes free work or an argument.
Names without authority. Without a decision limit, every change goes to the sponsor or to nobody.
A budget with no contingency. The first surprise becomes a funding crisis.
The plan inside the charter. Tasks and dependencies change weekly; keep them in the plan so the charter stays signed and stable.
Build it
A three page charter is mostly tables plus one timeline. The document builder’s Document group includes section, page break, stamp, timeline, contents, callout and QR code blocks, and its Layout group holds heading, subheading, paragraph, divider and space; a document here draws on 45 component types in all. A table of contents is used only on long documents of six pages or more, so a three page charter goes without one.
For approval, one signature block party is one signer, each with a name, email and signing order, so the sponsor and project lead can sign in sequence. The AI chat edits text only, so it can sharpen an objective or a scope line while tables and the timeline are edited in the builder. The page on data tables in a document shows the table block, and the tutorial on document builder components walks through the blocks.
| Section | What it contains | In the warehouse rollout example |
|---|---|---|
| Header block | Project name, code, sponsor, lead, approval date, version | WMS-01, sponsor and lead named, approved 5 October 2026, version 1.0 |
| Purpose | The problem in two sentences | 9,800 orders a week picked from paper at two depots |
| Objective | Measurable targets with a date | Pick errors from 1.8% to under 0.5%, dispatch from 41 to 25 minutes, within 3 months of go live |
| Scope in | What the project covers | Two depots, receiving, picking, dispatch scanning, driver app, invoicing integration |
| Scope out | What people would otherwise assume is included | The third depot, finance integration beyond invoicing, returns, fleet telematics |
| Deliverables | Each deliverable with a measurable acceptance test | 14,000 SKUs migrated with counts within 0.2% of the physical count |
| Team and authority | Roles, names and what each may decide | Sponsor approves changes over $10,000; project lead decides below that |
| Budget | Cost lines with contingency and a total cap | Six lines including 10% contingency, $341,000 total |
| Milestones | Key dates from approval to benefits review | Five dates from 5 October 2026 to 30 June 2027 |
| Risks | The risks worth naming on day one, with owner and response | Five risks with likelihood, impact, owner and response |
| Success criteria | Measures, targets and when each is measured | Pick error rate, dispatch time and scanner uptime |
| Assumptions and constraints | Conditions the approval depends on | API available as documented, staff released for training, spend capped |
| Approval | Sponsor and project lead signatures, and how changes are issued | Signed side by side; changes issued as a new version |
A finished example
A charter exists so that a project starts with a sponsor's signature on a page that says what it is and is not. This one fits a system rollout on three pages: a measurable objective, scope in and out as two lists side by side, the team with their authority, a $341,000 budget, five milestones on a timeline and the five risks worth naming on day one.
Read the project charter template with the scope in and out on one pageQuestions people ask
What is the difference between a project charter and a project plan?
The charter authorises the project: objective, scope boundary, budget cap, authority and the sponsor's signature, usually once. The plan schedules the work: tasks, dependencies and dates, owned by the project lead and revised as often as needed. A plan without a charter is a schedule for work nobody has authorised, and a charter without a plan is a promise with no route.
Who signs a project charter?
The sponsor, who owns the budget and is accountable for the benefits, signs to authorise the project. Many charters also have the project lead sign to show they accept the objective, scope and authority limits. The example has both, side by side, with a sentence saying the sponsor's signature authorises the project to the budget and scope stated.
How long should a project charter be?
Short enough that people reread it. Two to five pages covers most internal and vendor projects; the example fits a system rollout with a $341,000 budget onto three pages. If the charter grows past that, detail such as the full risk register, the schedule or the business case probably belongs in its own document with a reference in the charter.
Is a project charter the same as a PRINCE2 project brief?
They do similar jobs. In PRINCE2 the project brief is produced before initiation to give the project board a firm basis for deciding whether to start, and its contents are then extended into the project initiation documentation. A charter in the PMBOK Guide sense is the document that formally authorises the project. Use the term your organisation already uses.
What happens when scope or budget changes after approval?
Follow the change rule in the charter. The example's authority column says the sponsor approves changes over $10,000 and the project lead decides below that, and the approval section says changes to budget or scope are issued as a new version of the charter. Keep each signed version, so the history of decisions is clear later.
Should risks go in the charter or a risk register?
Both, at different levels of detail. The charter names the handful of risks worth knowing before approval, with an owner and a response, so the sponsor signs with their eyes open. Once the project starts, those risks move into a risk register with scoring scales and a review cycle, where new risks are added as they appear.
Written by
Indunil Asanka · Co-founder
Builds the generation pipelines behind OneCraft: the slide, flyer and poster layout engines, the document grid and the render workers that turn a written brief into a finished file.
LinkedIn profileWritten and checked by the OneCraft team. Last checked .
Make your own document
Describe what you need and the generator writes and designs it, then you edit anything you like.
See what it can makeRead next
How to write a risk register
A risk register lists each risk with its cause, a likelihood and consequence score on defined scales, the resulting rating, an owner, a response and a status, and it is reviewed on a fixed cycle. The scales matter most: without written thresholds, two people rate the same risk differently and the matrix means nothing.
How to write meeting minutes
Minutes are a record of decisions and actions, not a transcript. A good set can be read in two minutes by somebody who was not there, and tells them what was decided, who owns what, and by when.
How to write a meeting agenda
Write a meeting agenda as a purpose line followed by a short list of items, each with a start time, a length in minutes, an owner and the outcome it needs: a decision, input or information. Send it with the pre-reading far enough ahead that people arrive having read it, and the meeting spends its time deciding rather than presenting.
For the steps inside the builder, read the guideon this topic.