A project charter is the short document that turns a good idea into an authorized piece of work. It explains why the project exists, who owns the call, what the work includes, and what must be true before the team starts spending serious time on it.
It is not a full project plan. It is not a polished pitch deck. It is the first agreement about the shape of the work.
The Project Management Institute describes a project charter as the document that formally authorizes a project and gives the project manager authority to apply resources to it. That definition matters because a project can have a goal, a deadline, and a group chat and still lack permission, boundaries, or a clear owner. A charter closes that gap. You can compare the formal definition with PMI's guidance on managing small projects.
For a small team, the best charter is usually short enough to read in one sitting and specific enough to prevent three different versions of the project from forming. Here is how to write one.
What a project charter is for
A charter answers a narrow set of start-up questions:
- Why does this project need to exist?
- What outcome are we trying to create?
- Who is accountable for moving it forward?
- Who can make the important calls?
- What is in scope, and what is deliberately out?
- What evidence will tell us that the work is ready to begin?
If those answers are missing, the team is likely to use every meeting to renegotiate the project. That creates motion without shared direction. A charter gives the work edges before the work gets expensive.
Project charter vs. project brief vs. project plan
These documents overlap in practice, which is why teams often use the names interchangeably. The distinction is still useful because each document serves a different moment.
| Document | Main question | Useful level of detail |
|---|---|---|
| Project proposal | Should we choose this work? | The case for the idea, its value, and the decision requested. |
| Project charter | Are we authorizing this work, and who owns it? | Purpose, outcome, boundaries, authority, constraints, and start conditions. |
| Project brief | What are we making and for whom? | Audience, requirements, message, deliverables, and working direction. |
| Project plan | How will the work happen? | Tasks, dates, dependencies, resources, reviews, and operating cadence. |
A charter can point to a proposal or brief. It does not need to contain every detail from either one. The point is to authorize a bounded effort, not to pretend that every planning question has already been answered.
The six blocks of a one-page project charter
1. State the reason without selling the solution
Start with the problem, need, or opportunity in one or two sentences. Avoid turning this section into a slogan for the preferred answer.
Weak: "Build a world-class platform that transforms the customer experience."
Stronger: "Customers cannot see the status of an open request, so the support team receives repeated follow-up messages and loses time to manual updates."
The second version gives the team something to test. It also leaves room to discover whether the right answer is a new feature, a clearer process, or a smaller communication change.
2. Name the outcome and the evidence
Describe what will be different when the project is complete. Then name the evidence that would make the statement credible.
Do not write "improve the process." Write what will exist, change, or become easier to verify. The outcome might be a published workflow, an approved asset, a working handoff, or a decision supported by a defined set of inputs.
The evidence does not need to be a grand metric. It can be a reviewable deliverable, a user action, a sign-off, or a before-and-after comparison. A project that cannot say what proof it intends to create is still describing an aspiration.
3. Set the boundaries
Write a short in-scope list and an out-of-scope list. Three items on each side are often enough to expose the real shape of the work.
In scope might include the first release, one audience, one channel, and one approval path. Out of scope might include a full redesign, a second market, legacy cleanup, or future automation.
Out-of-scope language is not a rejection of future work. It is a promise that future work will not quietly enter the current project. That distinction protects the team from scope expanding through casual conversation.
4. Name authority and decision rights
List the project owner, the sponsor or approver, and the people who must be consulted. Then state what each role can decide.
"The team will collaborate" is not a decision structure. A usable charter says who can approve the direction, who can accept the deliverable, and what happens when two valid opinions conflict.
For a solo project, this still matters. You can be the owner and the approver, but write down which trade-offs you will make when time, quality, and scope collide. A private decision rule is better than a vague promise to do everything.
5. Add constraints, assumptions, and first risks
Keep this section high level. Note the limits that can change the decision: a fixed launch date, a known budget ceiling, a required platform, a dependency on another person, or a missing input.
Separate facts from assumptions. "The customer list is available" is a fact only after it has been checked. "The customer list will be available next week" is an assumption until an owner confirms it.
You do not need a complete risk register inside the charter. Name the few uncertainties that could change whether the project should start, then give each one an owner or a date for resolution.
6. Define the start line
End with the condition that moves the project from approved idea to active work. This might be sponsor approval, access to a source file, a confirmed decision, or a first review date.
A start line prevents a common failure mode: the team says yes to the project, then spends weeks doing unstructured preparation because no one knows what counts as the first real step.
Write the first proof-producing action in plain language. "Schedule kickoff" is useful, but "bring the approved scope and the first draft to a 30-minute review on Tuesday" is better. It tells the team what will be inspected.
How to write the charter in 30 minutes
- Minutes 1 to 5: Write the problem and the reason the work matters. Remove adjectives that do not change a decision.
- Minutes 6 to 10: Describe the outcome and the proof that would show it exists.
- Minutes 11 to 15: Draw the scope boundary. List what the project will do and what it will not do.
- Minutes 16 to 20: Name the owner, approver, consulted people, and unresolved authority questions.
- Minutes 21 to 25: Add constraints, assumptions, first risks, and the date or condition for resolving each important unknown.
- Minutes 26 to 30: Read the charter aloud. If a sentence cannot help someone decide, approve, limit, or begin the work, cut it.
Thirty minutes is a working limit, not a promise that every project can be chartered that quickly. A complicated effort may need more discussion. The discipline is to keep the first document proportional to the decision it needs to support.
Five signs the charter is not ready
- It reads like a plan. You have listed every task before agreeing on the work.
- The outcome is a feeling. Words such as "better," "seamless," or "world-class" have no observable proof attached.
- No one owns the call. A group can contribute, but a project still needs a person who resolves an open decision.
- Everything is in scope. If the boundary includes every audience, channel, feature, and future improvement, there is no boundary.
- The start condition is missing. Approval is not the same as readiness. The team needs a first action that creates evidence.
What to do after the charter is approved
Once the charter is accepted, turn it into the next useful working document. Use a project brief when the team needs a clearer description of the audience, message, or deliverable. Define the proof of completion with acceptance criteria. Then use a project kickoff meeting to turn the agreement into named work.
Keep the charter visible as the work changes. If a new request alters the purpose, owner, boundary, or authority, it is not just another task. It is a decision about the project itself.
The visible parts of the work can stay simple. If you want a clean everyday layer for the first working session, the Form Organic Crew is a black women's crew neck sweatshirt with a regular fit, soft brushed fleece interior, and restrained branding on its live product page. The apparel is secondary. The agreement, and the work that follows it, carries the weight.
For more practical frameworks on building with intention, return to The Self Made Journal. A project charter is not bureaucracy for its own sake. It is a way to make the promise legible before the effort begins.
0 comments