Free Project Charter Template
A one-page project charter to authorize the project — download or copy in one click.
Part of our free project plan templates.
Your download has started.
Didn’t start? Retry the Word file or get the PDF.
Industry template packs — coming soon.
1.Project Overview
| Project name | {{Project name}} |
|---|---|
| Sponsor | {{Sponsor / decision-maker}} |
| Project manager | {{Project manager}} |
| Start date | {{Start date}} |
| Target end date | {{Target end date}} |
| Status | {{Not started / On track / At risk}} |
Keep this block on page one so anyone can see the project, its owner, and where it stands at a glance. Name one accountable project manager and one sponsor who can unblock decisions.
2.Objectives & Success Criteria
- {{Business case — the problem or opportunity that justifies funding this project}}
- {{Primary objective — a measurable result with a target and a date}}
- {{Success criterion #1 — the number the sponsor will judge this project by}}
- {{Success criterion #2 — a second measurable outcome}}
- {{Key assumption the plan depends on (budget approved, team available, system access granted)}}
Write objectives you can measure — “launch the new checkout by Q3 with under 1% error rate”, not “improve checkout”. If you cannot tell whether it is done, rewrite it.
3.Scope
In scope
- {{Deliverable or capability this project will produce}}
- {{Teams, departments, or locations included}}
- {{Systems or processes that will change}}
- {{Phase or release boundary — what "version 1" covers}}
Out of scope
- {{Work explicitly excluded — name what stakeholders will assume is included}}
- {{A later phase deferred out of this charter}}
- {{Adjacent system or team that is NOT part of this effort}}
Naming what is out of scope is what actually prevents scope creep. Be explicit about the work people will assume is included but is not.
4.Milestones & Timeline
| Milestone | Owner | Target date | Status |
|---|---|---|---|
| {{Charter approved & funded}} | {{Sponsor}} | {{Target date}} | Not started |
| {{Discovery / requirements complete}} | {{Owner}} | {{Target date}} | Not started |
| {{Design / solution approved}} | {{Owner}} | {{Target date}} | Not started |
| {{Build & test complete}} | {{Owner}} | {{Target date}} | Not started |
| {{Go-live}} | {{Owner}} | {{Target date}} | Not started |
| {{Handover to operations & project close}} | {{Owner}} | {{Target date}} | Not started |
Milestones are checkpoints, not tasks — a handful of dates that prove the project is moving. Each should be a clear “done / not done”, with one owner.
5.Tasks & Work Breakdown
| Task | Owner | Start | Due | Status |
|---|---|---|---|---|
| {{High-level workstream — e.g. "Discovery & requirements"}} | {{Lead}} | {{Start}} | {{Due}} | Not started |
| {{High-level workstream — e.g. "Build & configuration"}} | {{Lead}} | {{Start}} | {{Due}} | Not started |
| {{High-level workstream — e.g. "Rollout & training"}} | {{Lead}} | {{Start}} | {{Due}} | Not started |
Break the work into tasks small enough to track in a week or less. Give each an owner and a due date; a task with no owner will not happen.
6.Roles & Responsibilities
| Role | Name | Responsibility |
|---|---|---|
| Sponsor | {{Name}} | Owns the business case and budget; the final decision-maker |
| Project manager | {{Name}} | Runs the project day-to-day and reports status to the sponsor |
| {{Business owner / role}} | {{Name}} | Represents the users; signs off that the solution meets the need |
| {{Technical lead / role}} | {{Name}} | Owns the technical design and delivery |
| {{Steering committee / stakeholders}} | {{Names}} | Reviews progress at milestones and resolves cross-team conflicts |
Assign responsibilities to roles so the plan survives a team change. Be clear who decides, who does the work, and who needs to be kept informed.
7.Risks & Mitigation
| Risk | Impact | Likelihood | Mitigation | Owner |
|---|---|---|---|---|
| {{The risk most likely to undermine the business case}} | {{High / Med / Low}} | {{High / Med / Low}} | {{The mitigation and who owns it}} | {{Owner}} |
| {{An adoption / change-management risk}} | {{High / Med / Low}} | {{High / Med / Low}} | {{Mitigation}} | {{Owner}} |
| {{A resourcing or vendor risk}} | {{High / Med / Low}} | {{High / Med / Low}} | {{Mitigation}} | {{Owner}} |
| {{A data, integration, or compliance risk}} | {{High / Med / Low}} | {{High / Med / Low}} | {{Mitigation}} | {{Owner}} |
List the few risks that would actually derail the project, rate impact and likelihood (High/Med/Low), and name the action and the owner. Review this table at every status check.
8.Budget
| Item | Estimate | Actual |
|---|---|---|
| {{Software / licenses}} | {{Estimate}} | {{Actual}} |
| {{Implementation / vendor services}} | {{Estimate}} | {{Actual}} |
| {{Internal effort / backfill}} | {{Estimate}} | {{Actual}} |
| Contingency | {{Estimate}} | {{Actual}} |
Estimate the main cost lines and add a contingency for the unknowns. If your project has no budget, keep the section and write “N/A” — reviewers expect to see it.
9.Approval
Both sign-offs confirm the plan, scope, and budget are agreed before work starts.
A worked example charter authorizing a company-wide CRM rollout — the why, who, scope, and risks agreed before the detailed project plan is built.
1.Project Overview
| Project name | Salesforce CRM implementation — Sales & Support |
|---|---|
| Sponsor | Robert Tan, Chief Revenue Officer |
| Project manager | Megan Doyle |
| Start date | August 3, 2026 |
| Target end date | February 27, 2027 |
| Status | Not started |
2.Objectives & Success Criteria
- Replace the spreadsheet-and-email sales process with a single CRM so every lead, deal, and customer is tracked in one place.
- Give leadership an accurate, real-time pipeline forecast — today's forecast is rebuilt by hand each month and is routinely off by 20%+.
- Achieve 90% sales-team adoption (logging every deal in the CRM) within 60 days of go-live.
- Cut average lead response time from 2 days to under 4 hours through automated lead routing.
- Assumes the CRM budget is approved, a vendor partner is engaged, and IT grants the integration access to email and the billing system.
3.Scope
In scope
- CRM setup for the 35-person Sales team and the 12-person Support team.
- Migration of accounts, contacts, and open opportunities from the current spreadsheets and help-desk tool.
- Lead capture from the website, automated lead routing, and the standard sales pipeline stages.
- Integration with email and a read-only sync from the billing system for renewal dates.
- Reporting dashboards for pipeline, forecast, and support volume — this is the "version 1" release.
Out of scope
- Marketing automation (email campaigns, nurture flows) — deferred to a phase 2 charter in Q2 2027.
- The finance/ERP system — the CRM reads renewal dates from it but does not write back or replace it.
- Custom mobile development — the team will use the vendor's standard mobile app, not a bespoke build.
4.Milestones & Timeline
| Milestone | Owner | Target date | Status |
|---|---|---|---|
| Charter approved & budget released | Robert Tan | August 3, 2026 | Not started |
| Discovery & process mapping complete | Megan Doyle | September 11, 2026 | Not started |
| CRM design & data model approved | Vendor + Megan Doyle | October 9, 2026 | Not started |
| Build & integrations complete | Liam Foster | December 4, 2026 | Not started |
| Data migrated & user acceptance testing passed | Priscilla Adeyemi | January 22, 2027 | Not started |
| Go-live & team trained | Megan Doyle | February 9, 2027 | Not started |
| Hypercare ends & handover to operations | Megan Doyle | February 27, 2027 | Not started |
5.Tasks & Work Breakdown
| Task | Owner | Start | Due | Status |
|---|---|---|---|---|
| Discovery & process mapping with Sales and Support | Megan Doyle | August 3 | September 11 | Not started |
| Configure CRM, build integrations & migrate data | Liam Foster | September 14 | December 4 | Not started |
| Train the teams & run two weeks of hypercare support | Priscilla Adeyemi | February 2 | February 27 | Not started |
6.Roles & Responsibilities
| Role | Name | Responsibility |
|---|---|---|
| Sponsor | Robert Tan (CRO) | Owns the business case and budget; makes the go-live decision |
| Project manager | Megan Doyle | Runs the project, manages the vendor, and reports status to the steering committee |
| Sales business owner | Carlos Mendez (VP Sales) | Defines the pipeline stages; signs off that the CRM fits how sales actually works |
| Support business owner | Hannah Wright (Support Lead) | Owns the support-side requirements and adoption |
| Technical lead | Liam Foster (IT) | Owns the integrations, data security, and the migration |
| Steering committee | Tan, Mendez, Wright, Foster | Reviews at each milestone and resolves cross-team trade-offs |
7.Risks & Mitigation
| Risk | Impact | Likelihood | Mitigation | Owner |
|---|---|---|---|---|
| Sales team resists logging deals and reverts to spreadsheets | High | High | Involve sales reps in design; tie pipeline reviews to CRM data only; make managers run forecasts from the CRM from day one | Carlos Mendez |
| Migrated data is dirty (duplicates, missing owners) and erodes trust | High | Med | Run a data-cleanup pass before migration; validate a sample with reps in UAT before go-live | Liam Foster |
| Vendor partner under-delivers or the timeline slips | Med | Med | Fixed-scope statement of work with milestone-based payments; weekly vendor check-ins | Megan Doyle |
| Billing-system integration exposes customer data incorrectly | High | Low | Read-only sync, scoped fields, and a security review with IT before connecting production data | Liam Foster |
8.Budget
| Item | Estimate | Actual |
|---|---|---|
| CRM licenses (47 users, annual) | $84,600 | |
| Vendor implementation services (fixed scope) | $70,000 | |
| Internal effort & backfill during rollout | $25,000 | |
| Contingency (12%) | $21,600 |
9.Approval
How it works
- Preview the project charter — business case, objectives, scope, roles, milestones and risks.
- Download Word/PDF, or copy the text to paste into a doc.
- Fill in the why, who and what, then have the sponsor approve it before the detailed planning begins.
Frequently asked questions
What is a project charter?
A project charter is the short document that formally authorizes a project and sets its foundation before any detailed work: the business case, the objectives and success criteria, what is in and out of scope, the sponsor and key roles, the high-level milestones, and the main risks. It is what the sponsor signs to say "yes, do this project". The worked example here is a CRM implementation.
What is the difference between a project charter and a project plan?
The charter is the why, who and what, agreed first and kept short; the project plan is the how and when, expanded afterward with the full task breakdown and schedule. The charter authorizes the project and aligns everyone on goals and scope; the plan is the working document you run it from. Write the charter, get sign-off, then build the plan.
Who writes and approves a project charter?
The project manager usually drafts the charter, but the sponsor — the person who owns the business case and the budget — approves it and is named as the authorizing decision-maker. Key business and technical leads are listed as roles, and a steering committee or stakeholder group often reviews it. Sign-off from the sponsor is what lets the work begin.
What should a project charter include?
Keep it to one page: an overview (name, sponsor, manager, dates), the business case and measurable objectives, an explicit in-scope and out-of-scope list, the roles and responsibilities, the high-level milestones, the main risks with mitigations, and a budget summary. This template provides each of those sections, with the scope, roles and risks made deliberately rich.