What is a Project Charter? How to Write One That Actually Works
A complete guide to project charters — what they are, why every project needs one, what each section must contain, and a step-by-step template you can adapt and use immediately for any manufacturing, engineering, or product development project.
What is a Project Charter?
A project charter is a short, formal document that officially authorises a project to begin. It defines the project's purpose, objectives, scope, stakeholders, timeline, budget, and the authority of the project manager — all in one place, agreed and signed by the project sponsor before a single hour of work is spent. Think of it as the project's birth certificate and constitution combined: it gives the project its official existence and establishes the rules under which it will be governed.
In the PMBoK (Project Management Body of Knowledge) framework, the project charter is the primary output of the Initiating Process Group — the very first formal step in the project management lifecycle. Without it, the project has no official authorisation, no agreed scope, no defined manager, and no committed resources. It is simply a collection of activities that someone hopes will happen.
A project without a charter is like a ship without a rudder — plenty of motion, very little direction, and an uncertain destination. — Project Management Principle
The project charter is not a detailed project plan. It does not contain Gantt charts, detailed task lists, or resource schedules — those belong in the Project Management Plan, which is developed after the charter is approved. The charter is deliberately high-level: it captures the why and the what of the project, leaving the how and when for the planning phase. A good charter can often fit on one or two pages.
Why Every Project Needs a Project Charter
The most common reason projects fail is not technical difficulty — it is lack of clarity at the start. Unclear objectives, undefined scope, wrong stakeholders engaged, no agreed success criteria, and competing priorities that nobody resolved before work began. A project charter directly addresses every one of these failure modes. Here is what it prevents:
When scope is written down and signed, adding new requirements requires a formal change. Without a charter, every stakeholder adds "just one more thing" until the project collapses under its own weight. The charter's scope section is the first line of defence against the single most common cause of project failure.
Without a signed charter, a project manager has no formal authority to pull resources from other departments, make decisions, or escalate issues. The charter explicitly grants the PM the authority to use specified resources — transforming them from someone making requests into someone with sanctioned organisational power to act.
The act of writing the charter forces stakeholders to agree on objectives, scope, and success criteria before any work begins. Disagreements that surface during charter development — "I thought this project included X" — are cheap to resolve at this stage. The same disagreements surfacing during execution are expensive, disruptive, and sometimes fatal to the project.
A project without agreed success criteria can never be declared finished — or failed. The charter defines exactly what "done" looks like: the OEE target achieved, the product certified, the cost saving realised, the system deployed and running. These criteria become the basis for project close and post-implementation review.
The charter's business case and objectives sections force the sponsor to articulate why this project is worth doing and what benefit it will deliver. This creates the financial and strategic justification that allows senior management to make an informed go/no-go decision — and provides the baseline for post-project ROI evaluation.
Throughout the project, questions arise: "Is this in scope?" "Who has authority to approve this change?" "What was the original timeline?" The charter answers all of these from a single, agreed, signed source. It eliminates the "I thought we said..." conversations that waste time and damage team relationships.
Who Creates, Approves & Signs the Project Charter?
Understanding who is responsible for each role in the charter process is critical — getting this wrong means the charter lacks authority or reflects the wrong perspective.
The senior leader who commissions the project, provides the budget, and has organisational authority to commit resources. The sponsor signs the charter — this is the act that formally authorises the project. Without a sponsor with genuine authority, the charter is just a document. The sponsor also resolves issues that escalate beyond the PM's authority during execution.
The PM typically drafts the charter — interviewing the sponsor, stakeholders, and subject matter experts to gather the information needed to complete each section. The PM then presents the draft to the sponsor for review, revision, and signature. Once signed, the PM is responsible for working within the charter and raising a change request if the charter needs updating.
Department heads, functional managers, and key end users contribute to the charter's scope, requirements, and risk sections. They may also sign or initial the charter as acknowledgment — not as full approval, but confirming they have read it and accept the stated scope and their defined roles. Stakeholder acknowledgement reduces "I didn't know" disputes later.
Where a Project Management Office (PMO) exists, it typically reviews the charter for completeness, consistency with organisational standards, and alignment with strategic priorities. The PMO archives the signed charter as the official project record and ensures it is referenced during gate reviews and audits. In PRINCE2, this role is performed by the Project Board.
The 10 Key Sections of a Project Charter — Explained
While charter formats vary by organisation and methodology, the following ten sections cover everything a robust project charter needs to contain. Each section serves a specific purpose — omitting any of them creates a gap that will surface as a problem during execution.
A clear, unambiguous name for the project plus a unique reference number, version, and date. Sounds trivial — but "Project Alpha" and "OEE Improvement – Press Line 3 – Q2 2025 – v1.2" are very different in their usefulness when referenced six months later or in an audit.
Why does this project exist? What problem does it solve or what opportunity does it capture? How does it align with the organisation's strategic goals? This section justifies the investment and provides the "north star" that keeps the team aligned when trade-off decisions arise during execution.
What will this project achieve? Written as SMART objectives: Specific, Measurable, Achievable, Relevant, Time-bound. "Improve quality" is not an objective. "Reduce defect rate from 3.2% to below 0.8% on Line 4 by 31 March 2026" is an objective. Each objective should have a measurable success criterion.
Defines what is included (In Scope) and — critically — what is explicitly excluded (Out of Scope). Both halves are essential. "Out of Scope" items prevent scope creep by pre-emptively ruling out additions that stakeholders might otherwise assume are included. Be specific: name the processes, systems, departments, and geographies covered.
The specific, tangible outputs the project will produce — reports, systems, trained staff, installed equipment, validated processes, approved documents. Each deliverable should be specific enough to verify: "a validated production process capable of ±0.05mm tolerance" rather than "improved production process."
A summary timeline of the major project phases and milestones — not a detailed schedule. Key dates: project start, phase gate reviews, key dependencies, and project close. Enough to establish the time constraints within which the project must operate and to identify any hard deadlines (regulatory, seasonal, contractual) that constrain the plan.
The total approved project budget, broken down at a high level into major cost categories (capital, labour, materials, external services). The contingency reserve percentage. The funding source and approval authority. This section establishes the financial envelope within which the PM is authorised to operate without seeking additional approval for each expenditure.
Names the project sponsor, project manager, core team members, and key stakeholders with their roles and responsibilities (often as a RACI matrix: Responsible, Accountable, Consulted, Informed). This section establishes who has authority, who does the work, who provides input, and who needs to be kept informed throughout the project.
High-level risks identified at charter stage (not a full risk register — that is developed during planning). Assumptions the project is making that, if wrong, would invalidate the plan. Constraints the project must work within (regulatory requirements, specific technologies mandated, supplier commitments, non-negotiable deadlines). All three must be explicit.
The sponsor's signature and date — the act that formally authorises the project. Without this, the charter is a proposal, not an authorisation. Some organisations also include acknowledgement signatures from key stakeholders and the project manager's acceptance of the role. Signatures should include printed name, title, and date.
How to Write a Project Charter — Step by Step
Writing a project charter is not a solo desk exercise — it is a collaborative process that requires structured conversations with the right people. Follow these steps in sequence to produce a charter that is complete, credible, and genuinely useful.
Before writing anything, have a structured conversation with the project sponsor. Ask: What problem are we solving? Why now? What does success look like? What are you prepared to invest? What is non-negotiable? What keeps you up at night about this project? Take notes — the sponsor's answers become the foundation of your business case, objectives, and risk sections. Never start writing from a brief alone.
"What will be different in the organisation when this project is complete?" forces the sponsor to articulate the real business objective — not just the project output.
A sponsor who cannot answer "what does success look like?" does not yet have a clear enough project to charter. Clarify before proceeding.
List everyone who will be affected by, contribute to, or have authority over the project. For each stakeholder, note their interest (what they want from the project), their influence (their power to support or block it), and their role (RACI). This informs who you need to consult during charter development and ensures no critical voice is missing before sign-off. A stakeholder you miss at charter stage becomes a problem at execution stage.
For each objective, ask: Can I measure whether we achieved this? Is the target specific enough to verify? Is it achievable with the available resources and time? Does it directly address the business case? When does it need to be achieved? Run each draft objective through the SMART filter. If the answer to any question is "sort of" or "it depends" — the objective needs sharpening. Strong objectives also make project close unambiguous: either you hit the number or you did not.
"Improve production efficiency" — unmeasurable, vague, no deadline. No one can tell when this is achieved.
"Increase OEE on Line 3 from 58% to 75% by 30 June 2026, verified by 4 consecutive weeks of production data."
List what the project explicitly covers — which processes, systems, sites, products, and departments are included. Then write an "Out of Scope" section listing things stakeholders might reasonably assume are included but are not. This dual approach is the most powerful scope creep prevention tool available. Run your draft scope statement past two or three key stakeholders and ask: "Is there anything you expected to see in this project that is not listed here?" Their answers reveal the gaps before they become disputes.
At charter stage you cannot know all the risks — but you can identify the major ones that are already visible. For each high-level risk, note: what might go wrong, how likely, what impact, and what early mitigation is planned. Assumptions are facts you are treating as true for planning purposes — each assumption is a potential future risk if it proves wrong. Constraints are conditions the project cannot change: a regulatory deadline, a fixed budget ceiling, a mandated supplier, a technology standard.
Every assumption in the charter is a potential risk. If the assumption proves false, the project plan may need to change — flag them explicitly so they can be monitored.
Share the draft charter with all key stakeholders — sponsor, team leads, affected department heads, PMO — and set a deadline for written comments. Consolidate feedback, resolve conflicts (escalating to the sponsor where stakeholders disagree), and produce a revised draft. Allow one clear review cycle before finalising. Avoid endless revision loops — two rounds maximum. If stakeholders cannot reach agreement, the sponsor must decide.
Present the final charter to the sponsor in person — not by email if you can avoid it. Walk through it section by section to confirm there are no residual misunderstandings. Obtain a wet (or digital) signature with date and title. Archive the signed original. Send copies to all stakeholders. The project is now officially authorised. The PM now has the authority to begin planning and mobilising resources. Never begin spending project budget without a signed charter.
A sponsor who is "too busy to sign" is a red flag — it signals the project does not have the priority it needs. Resolve this before proceeding.
The signed charter must be stored in the project management system or shared drive where all team members can access it throughout the project life.
Project Charter Template — Fill & Use Immediately
Below is a complete, ready-to-use project charter template. The bracketed items in blue show you exactly what to fill in for each field. Adapt the sections to your organisation's needs — but do not remove any section without a deliberate reason.
2. [Objective 2]
3. [Objective 3 — maximum 4–5 objectives; more indicates unclear scope]
2. [Deliverable 2]
3. [Deliverable 3]
4. [Post-implementation review report — always include this]
Milestone 1 — [Name]: [Date]
Milestone 2 — [Name]: [Date]
Milestone 3 — [Name]: [Date]
Project Close / Review: [DD/MM/YYYY]
Hard Deadlines & Constraints: [Regulatory dates, customer commitments, seasonal windows]
— Capital Expenditure: [₹ Amount]
— Labour (internal): [₹ Amount or FTE-days]
— External Services / Consultancy: [₹ Amount]
— Contingency Reserve: [% or ₹ Amount]
Budget Authority: Expenditures up to [₹ X] approved by PM. Above [₹ X] requires Sponsor approval.
Project Manager: [Name] — Responsible for delivery, reporting, team coordination
Core Team: [Names / Roles] — Responsible for executing work packages
Key Stakeholders: [Names / Roles] — Consulted on scope and requirements
Informed: [Names / Roles / Communication frequency]
Risk 2: [Description] — Likelihood: [H/M/L] — Impact: [H/M/L] — Mitigation: [Action]
Risk 3: [Description] — Likelihood: [H/M/L] — Impact: [H/M/L] — Mitigation: [Action]
Project Sponsor: _________________________ Date: _____________
[Printed Name] [Title]
Project Manager: _________________________ Date: _____________
[Printed Name] [Title]
Key Stakeholder Acknowledgement (optional):
_________________________ [Name / Role] Date: _____________
7 Common Project Charter Mistakes — and How to Avoid Them
| # | Mistake | Why It Matters | Fix It By |
|---|---|---|---|
| 1 | Writing the charter after the project has started | The charter becomes a description of what happened — not an authorisation of what will happen. Scope is already drifting. | Always write before kickoff |
| 2 | Vague, unmeasurable objectives | "Improve efficiency" cannot be measured, achieved, or used to make trade-off decisions. The team cannot tell when they have succeeded. | Apply SMART filter to every objective |
| 3 | No "Out of Scope" section | Without explicit exclusions, every stakeholder assumes their priorities are included. Scope creep becomes inevitable. | List at least 3–5 explicit exclusions |
| 4 | Wrong sponsor — someone without real authority signs | When the PM needs resource allocation or conflict resolution escalated, the sponsor cannot deliver. The project stalls. | Confirm sponsor can commit budget listed |
| 5 | Charter too detailed — becomes a project plan | A 40-page charter takes weeks to produce and is rarely read. The charter's value is in brevity and clarity — not exhaustiveness. | Target 1–2 pages for small projects |
| 6 | Not updated when scope or sponsor changes significantly | The charter becomes irrelevant as the project evolves. Team members reference an outdated document — confusion and disputes follow. | Review and update charter at each phase gate |
| 7 | Charter filed away and never referenced again | The charter becomes a box-ticking exercise rather than the living reference document it should be throughout the project. | Open the charter at every steering meeting |
- Every objective is specific enough that anyone can verify achievement with data
- The "Out of Scope" section specifically names things stakeholders asked for that are excluded
- The sponsor signature is from someone who genuinely controls the listed budget
- Any team member can answer "Is X in scope?" by reading the charter in under 2 minutes
- Assumptions are listed separately from facts — each one flagged as a potential risk
- The PM's financial authority limit is explicitly stated
- The charter fits on 1–2 pages (small project) or 3–4 pages (complex project)
- Team members actually reference it during the project — not just at kickoff
- Objectives written as activities ("conduct training") rather than outcomes ("reduce error rate by X%")
- Budget listed as "TBD" — the charter cannot be signed without a committed budget
- Scope so broad it encompasses multiple departments, systems, and sites simultaneously
- Risks section left blank — "no significant risks identified" at charter stage is almost never true
- No named project manager — "to be assigned" means no PM accountability exists yet
- Sponsor listed but has not actually read the document before signing
- Deliverables described as processes ("implement lean") not outputs ("a validated lean standard for Line 3")
- Charter is 20+ pages — it has become a project plan, not a charter
Summary — Your Project Charter Starts Here
Key Takeaway
The project charter is the most underused and undervalued document in project management. Most project failures — scope creep, stakeholder conflict, unclear objectives, missing authority, budget overruns — could be traced back to the absence of a well-written, sponsor-signed charter. The one or two hours it takes to produce a good project charter will save ten, twenty, or a hundred hours of rework, escalation, and conflict during execution.
A project charter is not bureaucracy — it is discipline applied at the right moment: before money is spent, before work begins, before misunderstandings harden into conflicts. It is the single most important document in a project manager's toolkit — not because it is complex, but because it creates the clarity, authority, and alignment that every successful project depends on.
No signed charter = no project. If your organisation starts projects without a signed charter, that is not a project management problem — it is a governance problem. Push for the charter, get the sponsor to engage, get the signature. The discipline of the charter is the discipline of the project. A project that cannot be clearly defined in two pages before it starts will not be clearly delivered after it ends.
