Download the project charter template and example
The blank text template covers purpose, outcomes, scope, resources, risks, decisions, approval, and review triggers. The completed example shows a fictional SaaS export-status project with a bounded delivery commitment. Both files are editable and available without registration.
The fictional project belongs to QueueNote, an app used only as teaching material in this guide. Names, effort limits, customer references, and approval roles are invented. The example is not an announcement of a ShowMeYourSaaS feature or an authorization to change a real service.
Copy the structure into your planning tool and replace its assumptions with actual evidence. A charter can record approval from a person who already has authority; filling its approval field does not grant that authority.
What is a project charter?
A project charter is an initiation document that establishes a project's purpose, high-level scope, ownership, resources, and approval. Atlassian's guidance distinguishes it from the more detailed planning and implementation work that follows.
Use a charter when a team needs a shared commitment before spending substantial time or changing a service. A small project can use a short record; the useful test is whether another participant can explain what has been authorized and what still needs a decision.
A charter can be revised through an agreed change process. Preserve the original commitment and the reason for a revision rather than silently expanding the project whenever a new request appears.
Separate the charter from adjacent planning documents
The charter answers why this project should proceed and under which boundaries. A PRD describes the intended product behavior. A Gantt schedule coordinates tasks and dates. A RACI matrix clarifies who performs and accepts particular activities.
These views can link to the same project reference without repeating every field. If the charter promises a bounded pilot, the PRD can specify the pilot behavior and acceptance checks while the schedule holds the implementation dates.
An early idea may need a proof of concept before a delivery commitment. Record the investigation as the authorized project when feasibility is unknown, rather than describing a complete rollout as already approved.
| Record | Main question |
|---|---|
| Project charter | What are we authorizing and why? |
| Product requirements document | What behavior belongs in the change? |
| Schedule | When can the work happen? |
| RACI matrix | Who performs, decides, contributes, and receives updates? |
Start with the problem and an observable outcome
The example problem is that a coordinator cannot distinguish an export still processing from one that failed. The charter cites invented research references QN-OBS1 and QN-SUP1 as fictional inputs. A real charter would point to permitted observations with their date and context.
The proposed outcome is that an authorized coordinator can identify a selected job's current state and the agreed next action during a pilot task. That is more assessable than improve transparency. It still requires a defined test and later evidence about actual use.
Separate the expected benefit from the delivery result. Implementing a status view can be verified against criteria; reducing support effort is a hypothesis that needs observation after use. Do not promise a percentage reduction simply because the charter has a benefits field.
Set scope, exclusions, and resource boundaries
In scope are the current queued, processing, completed, and failed states for one existing export workflow. The example excludes a new queue engine, billing changes, scheduled exports, and a redesign of permissions. These exclusions help reviewers evaluate attractive additions against the original commitment.
The fictional resource limit is eight person-days across implementation, review, verification, and documentation, plus a bounded pilot with two internal test workspaces. Those are exercise constraints, not estimates recommended for another project. Use the capacity and skills actually available to your team.
Record constraints separately from assumptions. Existing job events can support an accurate status view is an assumption to investigate. No production customer exposure before the accountable owner reviews the evidence is a proposed authorization boundary in the example.
If a dependency consumes the resource limit before the outcome can be delivered, stop for a decision. A charter should make that conversation easier rather than encourage the team to hide work so a commitment still appears unchanged.
Name the decision owner and the approval conditions
The example assigns a project owner to maintain the record and an accountable sponsor to approve starting the bounded work. Engineering and Support review the implications for their workflows. These role labels illustrate a possible agreement and do not establish a universal governance structure.
Before starting, the sponsor needs the scope, resource limit, unresolved event-coverage question, and stop conditions. Approval is recorded with a date and the exact version of the charter, so later readers can identify which commitment was reviewed.
Keep the next release decision separate. Approval to investigate and implement within a test environment does not automatically approve production exposure. The example requires a later review of acceptance evidence, permission checks, the disabled path, and pilot support arrangements.
Treat risks and changes as decisions to revisit
The example risk is that old job records cannot reliably distinguish a failed attempt from a completed job with a missing acknowledgement. Its first action is to inspect a synthetic fixture and document the event contract. The charter links ongoing tracking to the risk register.
Write change triggers that are specific enough to use. A need for a queue migration, a permission-model change, or additional resources beyond the agreed limit returns the project to its sponsor. Record the proposal, reason, effect on scope and capacity, and the resulting decision.
Do not turn the charter into a daily task board. Link active work to a Kanban board while keeping the charter focused on the commitment. A status meeting should not quietly replace the approval process for a material scope change.
Review the charter before and after the bounded work
Before approval, ask a reviewer to restate the purpose, exclusions, resources, authority, and remaining uncertainty. If those differ from the author's interpretation, revise the wording before treating the document as a shared commitment.
At closure, compare the delivered result with the authorized outcome and record unfinished work and observations. A project can finish its bounded investigation by learning that the proposed implementation is unsuitable; that is different from falsely marking a feature delivered.
The downloadable example and blank fields were checked for consistent scope, separate start and release decisions, and clearly fictional evidence. They have not been used to approve or execute a real project. Source and original materials checked October 28, 2026.