Examples of a project charter: what a good one looks like

Every single thing any project manager has ever worked on has likely started with a common step one, and its name is a project charter. 

Only once the project charter is ready does it make sense to move on to more flexible planning approaches, whether that means building a hierarchy of organizational goals, epics, tasks, and dependencies or adapting the plan as the project evolves. Without that foundation, even a well-organized Jira project can quickly turn into a collection of tasks without a clear connection to the bigger picture.

In this article, we’ll figure out what a project charter is, why it’s dangerous to ignore it, and have a look at some real examples of the good ones.

TL;DR

• A project charter formally authorizes a project, defines its goals, scope, responsibilities, constraints, and success criteria, and gives the team a shared foundation for planning.
• Unlike a project plan, the charter sets the project’s fixed boundaries, while the plan remains flexible and evolves as the work progresses.
• Once the charter is approved, teams can turn it into a detailed project plan by visualizing timelines, allocating resources, and managing work and dependencies across projects.

What is a project charter?

A project charter is a document issued by the project sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities, according to PMBOK 6th Edition.

Typically, the project charter is written at the beginning of a project, during the initiation phase and before stakeholder alignment is needed. It serves as an agreement between the sponsor and the project manager that provides clarification on two things:

• What has to be done?
• Who is responsible for the result?

In the entire project lifecycle, a charter would sit within the initiation stage, shortly after the idea appears.

Why do you need a project charter?

Basically, a project charter can be compared to game rules — without them, it’s impossible to win, because no one has agreed on the victory conditions.

Imagine you're a middle school student eagerly waiting to play soccer after school. The bell rings, and you and your friends rush to the schoolyard. You have a ball and form teams, but there's a problem: you don't have goalposts. You use backpacks instead, and the game begins. However, the ball frequently flies into the neighboring yard, causing interruptions, and some players stand by the goalposts, making the game frustrating.

In this scenario, setting clear rules beforehand would have made the game more enjoyable. Similarly, in project management, a project charter summarizes all the rules of the “game”, except the “game” is your project.

So, if we put this metaphor into PM terms, here’s what a good project charter does for you:

• Sets clear project goals. Everyone can see what the project is supposed to achieve and what success looks like.
• Defines the project scope. A charter draws the line around what belongs in the project and what doesn’t, making it easier to handle new requests without letting scope creep take over.
• Provides a basis for planning. Once the project’s direction is clear, you can break it down into goals, epics, tasks, milestones, and dependencies and build a more detailed plan in Jira.
• Makes decision-making easier. When trade-offs come up, the charter gives the project management team a reference point to see whether a proposed change supports the agreed project goals and scope.

Example project charter: 2 Excel templates

Each specific project will require its own charter, so there’s no template that could fit absolutely everything. However, all charters do share some basic things such as project purpose, scope, roles, budget, timeline, and others.

• The format of the project management charter is crucial. Since it is immutable, it is best maintained as an uneditable electronic document or printed on paper. Bringing a paper document to a sponsor/director for signature is generally the most reliable way to ensure they have actually read it.
• Then, the charter can be scanned and uploaded as an electronic document. It is also important that the entire team sees the charter. Because it contains goals and constraints, everyone understands whether the system has been implemented or not, what the KPIs are, what we are doing, and whatnot.

For paper or electronic documents, you may still need a basic template to start or to take inspiration from. To save you the setup time, here are two useful project charter templates for Excel: one of them is brief, and another one contains multiple sheets if your project is more complex.

What does a project charter include?

Charters may vary for different projects, but all of them do share something in common. Here are the project charter basics to keep in mind:

• Project purpose. Defines the project's objectives and the problem it aims to solve.
• Scope and deliverables. Outlines what is included in the project scope and the expected deliverables.
• Roles and responsibilities. Specifies the roles of everyone involved in the project, from team members to sponsors.
• Budget and resources. Details the budget, including financial limits and available resources.
• Timeline. Provides a high-level timeline or milestones for the project.
• Risk management. Identifies potential project risks and strategies for mitigating them.

Who writes the project charter?

The short answer is: the project manager writes the charter, and the project sponsor approves it.

The reason for this division is that the charter grants the project manager authority, and you can’t grant your own authority yourself. That’s why it has to be signed by someone who’s above the PM — which is the person who controls the resources, a sponsor or an initiator.

Here’s how other people may be involved in the making-of process of a project charter:

• Customer and users — supply the requirements and expectations that end up in the charter (objectives, project success criteria).
• Key stakeholders — the source of constraints, assumptions, and risks; they're identified before or during the writing of the charter.
• Team — usually not fully assembled yet at charter time; but it comes together after the charter is approved.

The most important thing about the charter — it is fixed before work starts, and cannot be changed afterwards, unlike the project schedule or timeline. If something changes fundamentally, it means you either create a new charter, or the project gets closed.

Project plan vs project charter

It’s important to see a clear difference between a project plan and a project charter, too.

While they are both essential documents, they serve distinct purposes and are utilized at different stages of a project.

A project charter is the formal document that authorizes the existence of a project. It is created early in the project initiation phase and serves as an official statement of the project's scope, objectives, and stakeholders. The charter outlines the project's purpose, the business needs it addresses, and the expected outcomes. The project charter is essential for gaining stakeholder approval and securing the resources required to move forward. It provides a high-level framework and sets the stage for detailed planning.

The project plan, on the other hand, is a comprehensive document that guides the execution and control of the project. It is developed during the project planning phase after the charter has been approved, and dives into the specifics of how the project will be executed, monitored, and controlled — from the detailed scope statement and Work Breakdown Structure (WBS) to the schedule, resources, and budget. It also sets the project processes for quality and risk management, defines how project information is communicated to stakeholders, and lays out procedures for scope management and procurement as the project evolves.

The project plan serves as the roadmap for the project team. Unlike the charter, it is a living document, often updated as the project progresses and new information becomes available.

Business case vs project charter

The business case and the project charter are also not the same — even though, just like the above, both are critical documents that serve distinct purposes and are used at different stages of the project lifecycle.

But the primary purpose of a business case is to justify the investment in a project. It provides a comprehensive analysis of the business need, potential benefits, costs, identified risks, and alignment with organizational objectives, whereas the project charter authorizes the project and sets the foundation for detailed planning and execution.

The key differences are best seen in comparison:

How to write a project charter: step by step

A 20-page project charter document is not exactly what you need. In most cases, the goal is to capture enough key information to get the project formally authorized and give the team a shared understanding of what they’re about to build.

The exact format can vary by organization, but the following steps cover the essentials.

Step 1. Start with the information you already have

Pull together the following:

• Approved business case
• Project proposal
• Requirements
• Stakeholder* expectations
• Available project budget information
• Any relevant technical or product documentation

*Who is affected, who has influence, who has to be consulted. Note the order here: stakeholders are identified before the charter, not after. Their expectations, constraints, and fears are the raw material you are about to compress into one page.

If the project is an extension of existing work, look at what’s already in Jira as well. Existing epics, issues, dependencies, and project data can reveal constraints or assumptions that aren’t obvious from the original proposal.

Step 2. Identify who will sign it

Find the person who controls the money and the resources, and confirm early that they are willing to sign.

Usually, this is the project sponsor or another senior stakeholder who owns the business outcome and can commit organizational resources. If the charter says the project needs three engineers, a designer, and a six-month delivery window, someone with the authority to commit those resources needs to agree to those conditions.

Name the approver in the charter and make sure they understand what they’re signing off on before the team starts turning the document into a detailed plan.

Step 3. Define the goal and how it will be measured

Write the business goal, not the activity:

"Migrate the CRM" — Too vague to be a goal.

"Cut order processing time from 4 days to 1 day by Q3" — A solid measurable goal.

Now the project team members have something concrete to work toward. It also gives you a way to evaluate whether the project delivered what it promised. Attach the key KPIs — it would also help to measure effectively later.

Keep the distinction between outputs and outcomes in mind. 

Launch a new returns page = Output.

Reduce returns-related support requests by 20% = Outcome.

Step 4. Fix the constraints triangle

A solid project charter should make the intended outcome clear, while the outputs can later be broken down into epics and tasks in your master project management system.

Every project has limits, and your charter should make them visible from the start. The classic constraints triangle covers scope, time, and cost, with quality often affected by changes to any of them.

Let’s suppose the returns project has:

• Scope: Web and mobile returns for existing customers
• Time: Launch before the holiday shopping season
• Cost: Four engineers and one designer for six months

These constraints give the team a framework for making trade-offs later. If a stakeholder asks to add international returns, for example, you can’t simply add it to the backlog and hope everything else stays unchanged. You’ll need to decide whether to stretch the project timeline, add resources, or reduce something else in the scope.

Step 5. State the deliverables — and what is out of scope

A list of deliverables tells everyone what the project is expected to produce. Just as importantly, an out-of-scope list tells everyone what it isn't expected to produce.

The out-of-scope list is the cheapest scope protection you will ever get. Everything you write there is a request you do not have to argue about in month four, because the sponsor already signed off on excluding it.

Step 6. Record the top risks, assumptions, and resources

It’s too early for a full risk register. Estimate just the five or six things that could genuinely sink the project, plus the assumptions the whole plan rests on ("the vendor's API will be available in March", "two backend engineers are allocated full time").

Assumptions are especially valuable here. When one of them turns out to be false, the charter shows the sponsor that the project was authorized on that basis, and reopens the conversation on your terms rather than as an excuse.

Step 7. Review, sign, and publish to the team

Before the charter becomes official, review it with the key project stakeholders and resolve any disagreements. Pay particular attention to scope, success criteria, deadlines, and resource commitments, since these are usually the areas where different expectations surface. 

Then make it visible to the entire team. A charter locked in the sponsor's drawer protects nobody. The team needs to see the goals, the constraints, and the KPIs.

Once signed, the document becomes uneditable.

What to do when the project charter needs to change

But what if it does need to become editable?

The reality does change sometimes in project management. If it happens, you need to assess what kind of change you are looking at. Usually, there are two.

Changes inside the frame

Most changes are not charter changes at all. A task takes longer than estimated, a feature is redesigned, a vendor is swapped, the sequence of work is reshuffled, a sprint goal is dropped. All of this happens inside the boundaries the charter set, leaving the goal, the budget, and the deadline intact.

These belong at the plan level, so update the schedule, the backlog, the resource plan. The charter is not involved, and touching it would be a mistake.

Changes that break the frame

However, sometimes the frame itself no longer holds: the business goal is no longer relevant, the budget has to double, the deadline moves by a quarter, or the constraint you fixed in step 4 turns out to be unfixable.

In fact, you don’t need an edit here. Instead, you have two options:

1. Write a new charter and have the sponsor approve it. It is a different project now — treat it as one, with a new authorization.
2. Close the project. If the goal has evaporated, continuing to spend money on it is worse than stopping. Closing a project because its rationale disappeared is a success of governance, not a failure of management.

What you must not do is amend the old document in place. A charter that is edited whenever it becomes inconvenient stops being a set of rules and becomes a record of whatever everyone currently feels like doing — which is exactly the situation it was written to prevent.

Who makes the call

Just like it was at the beginning, the project manager has to raise the issue, and the sponsor has to make the final decision.

Do you need a project charter in Agile and Scrum?

Yes. The confusion comes from treating "agile" as "no fixed anything", but the two are separate layers.

It can be helpful to think of the charter as the shell of an egg. The shell is rigid and set once. Everything inside it — the plans, the backlog, the priorities, the design decisions — stays soft and adaptive for the whole life of the project.

Agile removes the rigidity inside the shell, but does not remove the shell itself. Still, there are some key differences you need to keep in mind.

What looks different in an agile charter

• Scope is written as an outcome, not a feature list. The backlog decides which features get built; the charter decides what the features are for.
• Time and budget are usually fixed. Scope is the vertex that flexes — which is exactly what agile is designed to do well.
• Roles are named in agile terms. Product owner, scrum master, development team, plus the sponsor who signs. The sponsor role does not disappear in Scrum; funding and authority still come from somewhere.
• Definition of done and KPIs matter more, not less. With flexible scope, the metric is the only thing anchoring the project to its purpose.

The real value of an Agile project charter is that it gives the team a stable destination without dictating every single part of the journey.

From project charter to project plan

A project charter gives your team a shared understanding of what you’re building, why it matters, and what constraints you’re working with. But once the project gets underway, you need more than a document to keep that plan on track. You need to see the work, timelines, resources, and dependencies as they change.

Planyway for Jira gives you that planning layer on top of Jira. Visualize timelines, allocate resources, track effort, and see work across multiple projects in one view — so the project plan stays connected to the work your team is actually doing.