Project charter example: one page without bureaucracy

A project charter is needed before a detailed schedule

The project charter states why the work begins and within what boundaries it is allowed to be carried out. In formal project management, it also establishes authority. A small team benefits from a brief agreed version.

Let's imagine a studio that is going to launch a website technical support service. One participant understands it as answering questions during working hours, the other as round-the-clock correction of any errors. You can already draw up tasks and argue about deadlines, but the team is still planning different services. The charter helps detect discrepancies earlier. The example is for educational purposes and does not replace legal documents.

Do not begin with an elaborate twenty-page template. First answer: what outcome is needed, who authorises the launch and what exactly is the team not promising? Without these answers, a detailed task schedule creates a sense of order over an unclear idea.

Example of a charter on one page

In a real charter, replace general restrictions with specific available resources and obligations. The phrase “doesn’t displace work” requires checking the calendar rather than believing in free time. The table shows what the agreement covers, rather than a completed budget.

The result of the pilot is not necessarily a successful mass launch. The decision to back out can also be a beneficial outcome if it is based on observation and avoids a more costly false promise.

How to set boundaries

The “not included” section is often more useful than a long feature description. It allows you to calmly respond to new requests. If a pilot's customer requests a site redesign, the team can consider the request separately rather than sneaking it into support.

Boundaries should not prohibit learning. If the pilot shows that the chosen problem is formulated incorrectly, the charter can be revised. But change should be a decision, not a random accumulation of new responsibilities in correspondence.

Who should approve the start

A small project may lack a formal sponsor, but someone still allocates time, accepts risk or promises the client an outcome. Check the goal and boundaries with that person. A manager’s presence in a group chat does not prove that resources have been agreed.

1. Show the decision owner the goal, outcome and exclusions.
2. Check the limits with those who will be doing the work.
3. Clarify who can change the project’s scope.
4. Write down significant disagreements instead of hiding them under the word “agreed.”
5. After deciding to start, move on to the next steps.

A charter does not need to resolve every unknown. Explicitly separate decisions from assumptions: “The pilot allows for two requests per day” remains a hypothesis without measurements. The team must understand which observation would require revisiting the agreement.

Charter on one page: expanding an example of pilot support

The illustrative studio wants to test a support service for two clients. “Launch support” gives the manager no basis for limiting the work. The charter states a hypothesis: standard requests can be handled during agreed working hours without violating existing commitments. This is a pilot hypothesis, not a promise of round-the-clock service.

The proposed pilot lasts two weeks and covers only pre-agreed request types. The manager allocates a limited amount of team time; the actual hours should come from available capacity rather than a number chosen to make the document look good. Before starting, check existing client commitments and agree which requests fall outside the pilot. A request for a new feature does not become support merely because it arrives through the same channel.

The sponsor or initiative owner decides whether to continue, the project manager organises delivery and participants provide results. The charter must clearly state who can approve extra scope and when work is paused. For example, if the pilot begins to displace a mandatory client deadline, the manager takes the choice to the initiative owner rather than silently increasing the workload.

Completion does not mean merely that two weeks have passed. It requires a list of requests, processing time, unresolved issues, feedback and a decision: continue, change the format or stop. A pilot that leads to a decision not to launch can still be a successfully completed project: the team has answered the original question.

How the charter helps identify new scope

On the third day, a client asks for integration changes. The person doing the work may see a quick fix while the manager sees new development. Check the charter’s boundaries: standard requests are included and new features excluded. Assess the impact and propose a separate decision. The charter allows changes while making them visible.

In the change record, it is enough to indicate the request, the reason, the additional result, the impact on time and resources, and the person who makes the decision. Until agreement is reached, the team continues to operate within the current boundaries. Once agreed upon, the charter or associated plans are updated and members receive clear communication about the new version.

Do not overload the charter with every task. At the start, it answers questions about purpose, authority, limits and completion. Keep the detailed work plan separate; it changes more often. For a small project, both may sit in the same file, but they still serve different purposes.

Review the charter with someone who missed the discussion. They should be able to explain why the project began, what was explicitly excluded and who accepts the outcome. If this needs half an hour of spoken explanation, the document has not yet fulfilled its role.

Open the template: copy it or save it as a PDF

First step after approval

For the pilot, create an action called “Agree on the list of requests included in support.” Record the expected outcome in the description: a list of included requests and exclusions confirmed by the decision owner. Then choose a preparation day that allows time for a response. This gives the project goal a testable next step.

DesktopMobile

View screenshot ↗

Close ×

The Sinqly card uses illustrative Russian data to show where to describe a task’s outcome and limitations. It is not electronic approval of a project charter.

Do not try to put every approval in the task title. The charter remains an agreed document; the task helps retain the action required to begin. If the start conditions are unmet, do not mark preparation complete simply for a tidy list.

DesktopMobile

View screenshot ↗

Close ×

The task overview, shown in Russian, helps schedule preparatory work. A date alone does not confirm resource allocation or participant agreement.

In Sinqly, you can start with your own prep list. Legal signatures, authorities, and budget approvals are checked separately from the task interface.

How do you know if a document is good enough?

Ask another participant to explain in their own words what you want to test, what outcome you expect and which work you are excluding. If answers differ, improve the wording before detailed planning. If they match, do not expand the document merely to make it look substantial.

Refer back to the charter when the goal, decision owner, or boundaries change. Minor rearrangement of activities usually refers to the plan rather than the foundation of the project. This separation helps avoid having to re-negotiate the entire plan after each operational refinement.

A short charter is useful when it reduces ambiguity. Its quality is measured by shared understanding rather than completed field counts.