Create a project charter for [PROJECT NAME]. The business reason and intended outcome are [BUSINESS CASE AND OUTCOME]. The sponsor and core team are [SPONSOR AND TEAM]. The known requirements, constraints, and dependencies are [REQUIREMENTS AND CONSTRAINTS]. The target dates or deadline are [TIMELINE]. Success will be measured by [SUCCESS MEASURES]. Write a concise charter that allows the sponsor, delivery team, and affected stakeholders to make the same decisions. Do not turn uncertain assumptions into commitments. Produce these sections: 1. Purpose and decision statement: the problem, intended outcome, and decision this project authorizes.
2. Scope: in scope, out of scope, and future consideration, each with concrete boundaries. 3. Deliverables and acceptance criteria: specify what must be true for each deliverable to be accepted, who accepts it, and what evidence is required. 4. Roles: a RACI-style table for sponsor, project lead, contributors, approvers, and consulted groups. Give each workstream one accountable owner. 5. Milestones: a timeline table with milestone, date or date range, owner, prerequisite, and exit criterion. Include a decision gate before any irreversible commitment. 6. Risks, assumptions, issues, and dependencies: separate the four categories; rate risks by likelihood and impact, then assign an owner and mitigation or trigger. 7. Governance: meeting cadence, status format, escalation path, and the changes that require sponsor approval. End with the five highest-priority open decisions. Flag missing owners, impossible sequencing, unmeasurable success criteria, and timeline assumptions. Before answering, self-check that every deliverable has an acceptance owner and every milestone has an exit criterion. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT NAME] | Enter a clear name for the project. | Customer support knowledge-base migration |
| [BUSINESS CASE AND OUTCOME] | Describe the problem, opportunity, and desired outcome. | Move 420 help articles from a legacy site to a searchable platform before the legacy contract ends; preserve URLs and improve article ownership |
| [SPONSOR AND TEAM] | List the sponsor, project lead, contributors, and affected groups. | Sponsor: VP Support; lead: Maya Chen; contributors: support ops, content, web engineering, legal reviewer |
| [REQUIREMENTS AND CONSTRAINTS] | List known requirements, budget, systems, policies, dependencies, and limits. | Legacy contract ends March 31; no downtime for the help center; legal must approve policy articles; engineering has two weeks available in February |
| [TIMELINE] | Enter deadlines, key dates, or date ranges already committed. | Platform selection by January 15; migration complete by March 15; launch by March 24 |
| [SUCCESS MEASURES] | State the measurable outcomes or acceptance measures for the project. | All priority articles migrated, redirects tested, named owner on every article, and support agents can find top 50 articles in usability testing |
How to use
- Paste only confirmed dates and constraints, then label uncertain items as assumptions.
- Check that “out of scope” is concrete enough to prevent extra work being silently added.
- Confirm that one person, not a committee, is accountable for each milestone and acceptance decision.
- Follow up with: "Convert the milestones and risks into a weekly status report template that highlights decisions due in the next 14 days."
Variations
Project kickoff brief
Use this when the project is approved but the team needs a focused kickoff document.
Create a kickoff brief for [PROJECT] for [AUDIENCE]. The approved goal is [GOAL], team roles are [ROLES], first 30-day work is [WORK], and known risks are [RISKS]. Produce a one-page agenda, a decisions-needed list, working agreements, and a first-month milestone table with owners and exit criteria. Separate confirmed decisions from open questions. Do not assign work to people not named in my inputs. Ask up to 3 questions only if required inputs are missing.
Scope reset
Use this when a project has expanded and needs an agreed boundary.
Help reset the scope for [PROJECT]. Original commitment: [ORIGINAL SCOPE]. New requests: [NEW REQUESTS]. Constraints: [CONSTRAINTS]. Stakeholders and approver: [STAKEHOLDERS]. Produce a scope decision memo with retain, defer, decline, and investigate categories; impact on time, cost, and risk; and a sponsor decision request. Do not assume estimates or approvals. Flag dependencies that need validation. Ask up to 3 questions only if required inputs are missing.
Risk register
Use this when the charter exists but risks and ownership need more detail.
Build a project risk register for [PROJECT] using [PROJECT CONTEXT]. Known dependencies and uncertainties are [DEPENDENCIES]. Produce a table with risk statement, category, likelihood, impact, early warning signal, mitigation, contingency, owner, and review date. Include only risks supported by the context and clearly label assumptions. Add a short section identifying the three risks requiring sponsor attention. Ask up to 3 questions only if required inputs are missing.
Tips
- Phrase scope boundaries as observable work or deliverables, not broad labels such as “phase one,” which different people can interpret differently.
- Acceptance criteria should identify the evidence required, such as a tested redirect list or signed policy review, rather than simply saying “complete.”
- Separate risks from issues: a risk may happen, while an issue is happening now and needs an owner and decision.
- Put external approvals and scarce-team dependencies on the milestone plan early, because they often determine the real schedule.
FAQ
Is a project charter the same as a project plan?
No. A charter authorizes the purpose, boundaries, ownership, and governance; the project plan details tasks and scheduling needed to deliver it.
How detailed should a charter be?
It should be detailed enough to resolve scope, ownership, acceptance, and escalation. Leave task-level work breakdowns to the delivery plan.
Can AI assign project owners?
It can identify missing ownership and suggest roles, but named people and authority should be confirmed by the sponsor or team.