In brief
Use a project charter when you need a clear decision on a project's scope, ownership and authority. Follow the nine-step method, review the worked example or explore the editable template.
You have a project idea, a sponsor and perhaps even a preferred solution—but can the people responsible for approving the work see exactly what they are being asked to authorise?
That is the problem a useful project charter solves. It turns an emerging proposal into a concise, reviewable mandate. It makes the business need, intended outcomes, boundaries, ownership, initial uncertainty and requested decision visible before detailed planning or delivery gathers momentum.
A weak charter leaves important questions unanswered: Why now? What is excluded? Who can make which decisions? What assumptions sit behind the timing and budget? A strong charter does not eliminate uncertainty, but it records enough for the sponsor and project team to proceed deliberately.
This guide shows you how to draft that record section by section, review it with the right contributors and turn approval into a practical next step.
1. What a project charter is
A project charter is a high-level record of the project's mandate and the authority granted for its next stage. In PMI terminology, a charter formally authorises a project. It also records the project manager's authority to apply organisational resources to the work.
Names and governance models vary. Your organisation might use a project mandate, project brief or Project Initiation Document (PID), or combine several purposes in one artefact. Follow your internal lifecycle, approval and assurance requirements rather than assuming that every project needs a document called a charter.
The practical job of the charter is to create shared understanding of:
- the problem or opportunity and why it matters now
- the outcomes the project is intended to achieve
- the high-level scope and important exclusions
- the main deliverables and target milestones
- the governance, ownership and decision pathway
- the authority granted to the project manager—and its limits
- the assumptions, constraints, risks and dependencies known at initiation
- the exact decision requested from the approver
What a charter is not
A charter is easier to write when you separate its purpose from nearby project documents.
- A business case supports an investment or option decision by explaining the need, options, expected value, costs and risks. Where your organisation requires one, use it as an input rather than reproducing it. A structured Business Case template can help you develop that evidence.
- A detailed scope statement defines the approved scope baseline at a more granular level. The charter needs enough scope to establish boundaries, not every requirement or work package.
- A project management plan explains how the approved project will be planned, managed, monitored and controlled. The charter establishes the mandate that detailed planning works within.
- A PID can have a broader planning role in some organisations. Do not assume it is automatically identical to a lightweight charter.
Australian Government investment guidance similarly treats the business case as support for investment decision-making. Initiation and assurance may also require evidence of the mandate, governance and authority to proceed. The exact sequence and document names depend on the organisation.
Who contributes
As a practical PMOEasy operating model, the project manager coordinates the draft. The sponsor owns or champions the mandate and takes the decision through the relevant approval pathway. The business owner contributes operational outcomes, acceptance needs and constraints. Depending on the organisation, the sponsor may approve the charter directly or recommend it to another delegated approval body. A PMO may advise on governance and assurance expectations.
For a small project, one person may cover more than one role. What matters is that ownership and authority are explicit. Draft collaboratively: the people closest to the need, decision and delivery constraints usually hold different parts of the picture. The charter should reconcile those views, not conceal them behind polished wording.
What reviewers should find
A reviewer should be able to identify, without searching through supporting papers:
- the decision being requested
- the reason for acting now
- the intended outcomes and how success may be judged
- what is included and excluded
- who owns the project and who can make decisions
- the indicative time and funding boundaries
- the most material uncertainties
- any conditions attached to approval
2. When to use a project charter
A charter is commonly useful when an idea, request, discovery activity or business case has enough definition for an authorisation decision, but before detailed planning or uncontrolled delivery begins.
Practical triggers include:
- a new project entering initiation
- a sponsor being asked to approve planning, mobilisation or delivery
- a PMO needing a visible authorisation record
- unclear project ownership, boundaries or decision rights
- a material change that may require the mandate to be reconsidered
Do not wait for false certainty. At initiation, estimates and solution choices may still be immature. Record what is known, label what is assumed and make the next decision appropriate for the available evidence. Approval might authorise detailed planning rather than the entire delivery investment.
Revisit the charter when the mandate changes materially. This may follow a change to sponsorship, objectives, high-level scope, governance, funding authority or delegated authority. It may also follow a change to a target milestone beyond approved tolerance. Routine delivery adjustments within agreed tolerances can follow the project's change pathway without forcing charter re-approval.
Approval evidence also depends on organisational practice. A signature may be appropriate, but a decision may instead be recorded through an approved workflow, meeting record, email or other accepted mechanism. Follow your organisation's governance and records requirements.
3. How to write a project charter
Start with a provisional statement of the decision the charter must support. Then work through the evidence a reviewer needs. Treat the sequence as iterative: scope, funding, timing and authority will often develop together as you consult the sponsor, business owner and relevant approval owner.
Step 1: Draft and validate the approval request
Draft a provisional one-sentence decision request. Then validate it with the sponsor and relevant approval owner as the charter develops. The request might seek approval to plan, mobilise or deliver, or to proceed subject to named conditions.
Starting with a provisional decision disciplines the rest of the document without making the outcome predetermined. Refine the request when the business need, boundaries, funding and uncertainty have been reviewed. If the request is only to fund discovery and detailed planning, the charter should not imply approval of an untested delivery solution.
Common mistake—treating signatures as the decision. A signature block without a clear request leaves the meaning of approval open to interpretation. State the decision, any conditions, the approvers and the document version. Use the approval mechanism accepted by your organisation.
Step 2: Explain the business need and why now
Describe the problem or opportunity in operational terms. Explain who or what is affected, why action is timely and what is likely to happen if the organisation does not proceed. Refer to the business case or discovery evidence where detail already exists.
Common mistake—writing an aspiration instead of a decision-ready need. “Improve efficiency” says little about the current problem. Replace it with the observable issue, its significance and the consequence of leaving it unresolved. Do not invent precision when evidence is still being gathered.
Step 3: Define objectives and success measures
Turn the need into a small set of intended outcomes. Write each objective as a change the project should produce, not a list of work the team will perform. Add a measure, target or method of later evaluation where the evidence is mature enough.
If a target is provisional, label it as an assumption or a planning item to confirm. This is more credible than presenting an early estimate as a commitment.
Common mistake—using activities as objectives. “Implement a workflow” is an output. Ask what should be different because the workflow exists, then identify how the business owner will recognise that change.
Step 4: Set the high-level scope boundaries
List the major business areas, processes, systems, locations or user groups included. Then name the important exclusions that a reasonable reviewer might otherwise assume are included. Give a short reason where an exclusion could be contentious.
Keep this at the level needed for approval. Detailed requirements and a scope baseline can follow during planning.
Common mistake—leaving exclusions implicit. An inclusion-only scope invites competing interpretations. A short, deliberate out-of-scope list gives the sponsor a visible boundary to approve.
Step 5: Identify deliverables and meaningful milestones
List the main outputs required to achieve the objectives. Include an acceptance owner and indicative timing where known. Then identify a few milestones that support governance decisions: planning approved, solution decision made, pilot accepted, rollout authorised or transition completed.
Common mistake—copying a schedule into the charter. An exhaustive task list obscures the authorisation decision and will become stale quickly. Link to the detailed schedule once it exists.
Common mistake—using milestones that cannot support governance. “Work in progress” does not tell a sponsor what decision or completed state has been reached. Choose milestones that mark a meaningful commitment, acceptance or stage transition.
Step 6: Summarise the funding and timing envelope
Record the approved or indicative funding range, its source, the target start and completion window, and the assumptions behind them. Distinguish a funding ceiling from an estimate and an estimate from an approved budget.
The charter should show the boundary the project manager must work within. It should not suggest that detailed cost and schedule planning is complete.
Step 7: Define governance, roles and authority
Name the sponsor, business owner and project manager. Explain their main responsibilities, the decision and escalation pathway, and any governing body or PMO involvement. State what the project manager may do under the charter and what remains reserved for the sponsor or approval body.
A separate Stakeholder Register can then extend this high-level role picture into stakeholder analysis, influence, engagement and communication needs.
Common mistake—assigning responsibility without authority. Making someone accountable for progress while leaving budget, scope or escalation authority unstated creates avoidable ambiguity. Record both the authority granted and its limits.
Step 8: Make uncertainty visible
Capture only the important assumptions, constraints, initial risks, known issues and dependencies needed for the approval decision. For each item, identify the consequence or response and an owner where practical. Detailed assessment can continue in the appropriate registers.
Common mistake—hiding uncertainty. A charter is not stronger because it sounds certain. Recording an assumption about resource availability or a dependency on a vendor decision gives reviewers a more honest basis for approval.
Step 9: Connect the controls and record the decision
Link the charter to the plans and controls that follow it. These may include the business case, detailed scope, schedule, budget, stakeholder register, risk register and project management plan. Confirm the decision, conditions, approver, date and version.
Common mistake—allowing the charter to go stale. Identify the types of material change that trigger review. If the project’s mandate moves beyond approved tolerances, take it back through the relevant decision pathway rather than silently rewriting history.
Final quality check
Before seeking approval, ask:
- Can a reviewer explain the need, outcomes and requested decision in plain language?
- Are inclusions, exclusions and authority limits visible?
- Are activities separated from outcomes?
- Are estimates, assumptions and confirmed commitments distinguishable?
- Do named owners have a workable decision and escalation path?
- Does the version being approved match the version under review?
- Are detailed plans referenced rather than copied into the charter?
Use the Project Charter Checklist for a compact final review.
4. Project charter example
Expenditure approval improvement project
| Charter area | Illustrative entry |
|---|---|
| Business need and why now | Purchase commitments are sometimes made before the required expenditure approval is recorded, limiting budget visibility and creating inconsistent handling across teams. The organisation wants a controlled approval path before its next annual planning cycle. |
| Objective 1 | Increase the proportion of eligible purchase commitments with recorded approval before commitment. Illustrative success measure: baseline confirmed during planning. The sponsor will consider the target after the baseline is validated. |
| Objective 2 | Give budget owners a consistent view of pending and approved expenditure. Illustrative success measure: agreed reporting view accepted by the finance business owner before rollout. |
| In scope | Approval workflow for Australian corporate teams. Expenditure-request roles and delegations. Pilot with Finance and Operations. Supporting guidance and training. |
| Out of scope | Replacing the finance ledger. Renegotiating supplier contracts. Changing corporate delegation limits. |
| Main deliverables | Approved future-state expenditure process. Configured approval workflow and reporting view. Pilot, guidance and training pack. |
| Roles | Chief Financial Officer (sponsor). Head of Financial Operations (business owner). Assigned delivery lead (project manager). |
| Authority granted | The project manager may coordinate detailed planning and obtain input from nominated teams. They may also prepare the pilot within the approved scope and planning allocation. Pilot execution is subject to the approval condition below. |
| Authority limitation | The project manager may not change delegation limits, commit rollout funding or expand the project beyond Australian corporate teams without approval through the relevant decision pathway. |
| Major milestones | Planning and solution recommendation submitted within eight weeks of charter approval. Pilot acceptance decision within 12 weeks of planning approval. |
| Indicative funding envelope | Illustrative only: up to A$80,000 for detailed planning and pilot preparation from the Finance improvement allocation. This is a planning ceiling, not approval of rollout funding. |
| Assumption | Finance and Operations representatives will be available for process workshops during the first six weeks of planning. |
| Constraint | The pilot must use the current finance platform and approved identity service. |
| Initial risk | Unclear ownership of approval rules could delay configuration. The sponsor will confirm a policy owner before solution design begins. |
| Dependency | Identity team confirmation of role data and integration feasibility before the solution recommendation. |
| Decision requested | Approve detailed planning and pilot preparation, appoint the named project manager and authorise participation from Finance, Operations and Technology. Pilot launch is not included in this decision. |
| Approval condition | No pilot launch until the finance business owner approves the future-state process. Technology must also confirm that the security review required for this fictional pilot is complete and that any launch conditions are recorded. |
Business need and why now
Purchase commitments are sometimes made before the required expenditure approval is recorded, limiting budget visibility and creating inconsistent handling across teams. The organisation wants a controlled approval path before its next annual planning cycle.
Objective 1
Increase the proportion of eligible purchase commitments with recorded approval before commitment. Illustrative success measure: baseline confirmed during planning. The sponsor will consider the target after the baseline is validated.
Objective 2
Give budget owners a consistent view of pending and approved expenditure. Illustrative success measure: agreed reporting view accepted by the finance business owner before rollout.
In scope
Approval workflow for Australian corporate teams. Expenditure-request roles and delegations. Pilot with Finance and Operations. Supporting guidance and training.
Out of scope
Replacing the finance ledger. Renegotiating supplier contracts. Changing corporate delegation limits.
Main deliverables
Approved future-state expenditure process. Configured approval workflow and reporting view. Pilot, guidance and training pack.
Roles
Chief Financial Officer (sponsor). Head of Financial Operations (business owner). Assigned delivery lead (project manager).
Authority granted
The project manager may coordinate detailed planning and obtain input from nominated teams. They may also prepare the pilot within the approved scope and planning allocation. Pilot execution is subject to the approval condition below.
Authority limitation
The project manager may not change delegation limits, commit rollout funding or expand the project beyond Australian corporate teams without approval through the relevant decision pathway.
Major milestones
Planning and solution recommendation submitted within eight weeks of charter approval. Pilot acceptance decision within 12 weeks of planning approval.
Indicative funding envelope
Illustrative only: up to A$80,000 for detailed planning and pilot preparation from the Finance improvement allocation. This is a planning ceiling, not approval of rollout funding.
Assumption
Finance and Operations representatives will be available for process workshops during the first six weeks of planning.
Constraint
The pilot must use the current finance platform and approved identity service.
Initial risk
Unclear ownership of approval rules could delay configuration. The sponsor will confirm a policy owner before solution design begins.
Dependency
Identity team confirmation of role data and integration feasibility before the solution recommendation.
Decision requested
Approve detailed planning and pilot preparation, appoint the named project manager and authorise participation from Finance, Operations and Technology. Pilot launch is not included in this decision.
Approval condition
No pilot launch until the finance business owner approves the future-state process. Technology must also confirm that the security review required for this fictional pilot is complete and that any launch conditions are recorded.
Why the example supports approval
The business need describes an observable control problem without claiming an unverified financial impact. The objectives describe intended changes while leaving the quantitative target open until a baseline exists. The scope boundaries prevent the workflow project from being mistaken for a finance-platform replacement or delegation-policy review.
The authority statement allows planning and pilot preparation to begin. It reserves pilot execution and important policy, funding and scope decisions for the relevant approval pathway. The funding entry distinguishes a planning ceiling from rollout approval. The milestones mark reviewable decisions rather than project tasks. Finally, the assumption, constraint, risk and dependency expose different sources of uncertainty. This helps the approver understand the conditions that must be satisfied before pilot launch.
5. Use the PMOEasy project charter template
You can write a charter from this guide alone. If you want an editable structure for applying the method, the PMOEasy Project Charter template provides a DOCX starting point with prompts, examples and reviewer guidance.
The template turns this guidance into an editable working document, with practical prompts, examples, document controls and reviewer guidance to help your team develop and approve the charter consistently.
The template does not replace the judgement or collaboration needed to produce a credible mandate. It gives you a consistent place to record those decisions and can reduce the effort of starting from a blank document.
If you are establishing the broader initiation set, the Project Starter Bundle combines the charter with an editable Business Case, Stakeholder Register, and Kick-off Meeting Agenda and Minutes. Each artefact has a distinct job. Investment reasoning, authority, stakeholder analysis and mobilisation records should support one another rather than being collapsed into a single oversized document.
What happens after approval?
Record the approved decision and conditions using your organisation's accepted mechanism. Communicate the mandate to the delivery team and confirm owners for the conditions. Then develop the plans and registers required for the next stage. Establish the project's reporting and change-control arrangements.
The Project Initiation Checklist can help you move from an approved mandate into controlled planning and mobilisation. Keep the charter accessible as the reference point for the project's original authority. Review it when a material change challenges that mandate.
6. Explore the project charter template
Put the drafting method into practice with an editable, structured starting point.
Purchasing a template does not guarantee governance approval or project outcomes. Adapt the content to your organisation's scale, delivery approach and approval requirements.