Search “how to write a project charter” and most guides hand you a PMI definition, a blank Word template, and a warning to keep it short. None of them tell you what to do when a stakeholder skips the meeting, or how long the document should actually be for a five-person company instead of a Fortune 500 program office. This guide covers the 6 parts a project charter for a small company needs, a worked example with real numbers, and the two sections founders skip that come back to bite them mid-project.
What follows is not a theory lesson. It is a format you can fill in one sitting, plus the mistakes that turn a charter into a document nobody reads past the first page.
What a project charter actually does
A project charter is a one-to-two page document that authorizes a project to start. It names the problem, the goal, the budget ceiling, and the person with the authority to make final calls when the team disagrees. Nothing more. It is not a schedule, not a task list, and not a substitute for the project plan you write once the charter is signed.
Founders often skip the charter and jump straight to a plan or a spreadsheet of tasks. That works until the project hits its first disagreement about scope, budget, or who gets the final say. Without a charter, that disagreement has no reference point to settle it. With one, you point at the document everyone already agreed to and move on. A charter is one piece of a larger operating system, too; our business systems guide covers how the rest of that system fits together.
Not every task needs one. A charter earns its place when a project involves more than one person, crosses more than two weeks of work, or spends real money. A single founder writing a landing page in an afternoon does not need a charter. A five-person team building a client portal over ten weeks does, because that project can drift for a month before anyone notices the drift, and by then the budget and the deadline have both moved.
The 6 parts of a project charter
Every project charter needs six sections. Skip one and the document cannot do its job of preventing arguments later.
- Purpose and problem. Two or three sentences naming the problem the project solves and why it matters now. Not the solution, the problem.
- Objectives and success criteria. What “done” looks like, in numbers where possible. A launch date is not a success criterion; a customer count or a revenue target is.
- Scope: in and out. A short list of what the project covers and, just as important, what it explicitly does not cover. The second list prevents scope creep more than the first.
- Stakeholders and authority. Who is the project owner, who signs off on the charter, and who makes the final call when two stakeholders disagree. One name in that last slot, not a committee.
- Budget and resources. A ceiling, not a detailed line-item budget (that belongs in the plan). State the number and where it comes from.
- Timeline and milestones. Three to five dates: the start, the major checkpoints, and the target end. Enough to track progress, not a full schedule.
A worked example: client onboarding portal
Here is how the six parts look filled in for a small business building a self-serve client onboarding portal. Use it as a reference, then replace the content with your own project.
| Section | What it says |
|---|---|
| Purpose and problem | New clients wait an average of 9 days for account setup because onboarding runs through email and manual spreadsheets. That delay stalls the first invoice. |
| Objectives and success criteria | Cut setup time to under 24 hours. Reduce onboarding-related support tickets by half within 60 days of launch. |
| Scope: in and out | In: self-serve signup, document upload, automated welcome sequence. Out: billing integration and mobile app, both deferred to a later project. |
| Stakeholders and authority | Owner: Head of Operations. Final call on scope disputes: Founder. Consulted: Support lead and one existing client for feedback. |
| Budget and resources | $14,500 ceiling: $9,800 development, $3,200 design, $1,500 project management overhead. |
| Timeline and milestones | Kickoff week 1, prototype review week 4, beta with 3 clients week 7, full launch week 10. |
The budget line adds up before it goes in the charter, not after: $9,800 plus $3,200 plus $1,500 comes to $14,500. If the number in your charter does not match the sum of its parts, fix it before anyone signs.
Common mistakes that get a charter ignored
- Writing it after the project already started. A charter written in week three is a summary, not an authorization. It carries none of the weight because the decisions it is supposed to settle already happened informally.
- Naming a committee instead of a person for final authority. “The leadership team decides” sounds fair and solves nothing when the team splits three-two on a scope change under deadline pressure.
- Listing objectives without numbers. “Improve onboarding” is a direction, not an objective. Nobody can tell you if the project succeeded, including the person who wrote it.
- Treating the budget line as a detailed estimate. The charter states a ceiling. The line-item breakdown, with contingency and variance tracking, belongs in the project plan, not here.
- Letting it go stale. Scope changes happen. When one is big enough to move the budget or the end date, update the charter and get it signed again. A charter nobody has looked at in two months is decoration.
- Writing the scope list as one paragraph. A wall of text hides gaps. Split scope into a short in-list and a short out-list so a reader can check both in ten seconds instead of parsing a paragraph for what was left out.
Project charter vs project plan
The two documents answer different questions, and confusing them is why some founders skip the charter entirely and jump to a plan that has no signed authorization behind it.
| Document | Answers | Length | Written |
|---|---|---|---|
| Project charter | Should this project happen, and under what constraints? | 1-2 pages | Before work starts |
| Project plan | How exactly will the team deliver it? | Several pages, living document | After the charter is signed |
If you already have a charter and need the next layer, our project plan guide walks through turning the charter’s goal and budget into phases, tasks, and a risk register. If your project is complex enough to need a full scope breakdown before it reaches the plan stage, our work breakdown structure guide covers that middle step.
Who signs it and how long it should be
A project charter should run one to two pages. Past that length, people stop reading it, and a document nobody reads cannot do its job of preventing arguments. If your draft runs longer, move detail into the plan and keep the charter to the six sections above.
Signatures depend on company size. In a five-person company, the founder or the department head who owns the budget signs it, and one line goes to the person who will do the work, confirming they have seen it. There is no requirement for a legal signature; a confirmed email or a name typed into the document is enough for most small businesses. What matters is that the sign-off happened before work started, not that it happened on paper.
In a larger small business, add one more signature: the person most affected by the project outside the core team, such as a support lead if the project changes what customers experience. That second signature costs one extra day of waiting and prevents the far more expensive scenario of a launch that surprises the team meant to support it.
Once the charter is signed, assign ownership for each piece of the work itself so the one-name authority line does not become a bottleneck every time a small decision comes up. If your team is choosing software to run the project in, our project management guide for small business covers a 5-question framework and a 30-day rollout checklist.
Frequently asked questions
What is a project charter?
A project charter is a short document that authorizes a project to begin. It states the problem, the objectives, the scope, the stakeholders and who has final authority, the budget ceiling, and the timeline. It gets signed before work starts and becomes the reference point for later scope disputes.
What are the parts of a project charter?
Six parts cover a founder-run project: purpose and problem, objectives and success criteria, scope in and out, stakeholders and authority, budget and resources, and timeline and milestones. Larger organizations sometimes add risk and communication sections, but those extra sections usually belong in the plan instead, not the one-page charter.
How long should a project charter be?
One to two pages. A charter that runs longer starts to duplicate the project plan and people stop reading it past the first page. Keep the six sections tight and move detailed budgets, task lists, and risk registers into the plan, where that level of detail belongs.
Who signs a project charter?
The person who owns the budget, usually the founder or a department head, signs to authorize the project. The person leading the work confirms they have seen it. Small companies rarely need a formal legal signature; a confirmed email or a typed name is enough.
What is the difference between a project charter and a project plan?
A project charter authorizes the project and sets constraints in one to two pages, written before work starts. A project plan explains how the team will deliver it, with phases, tasks, a detailed budget, and a risk register, written after the charter is signed and updated throughout the project.
The bottom line
A project charter is not paperwork. It is the one page that keeps a scope argument from turning into a stalled project three weeks in. Write the six sections, put one name in the final-authority slot, keep it to two pages, and get it signed before anyone opens a project management tool.
