Projects fail at the start more often than at the end — usually because nobody agreed on what “done” means or who is allowed to say yes. A project charter fixes that by capturing the purpose, scope boundaries, stakeholders, deliverables, timeline, budget, risks, and success criteria in one authorising document. This builder assembles all of those sections and a sponsor sign-off block, then gives you clean Markdown to share.
How it works
The charter is organised the way most project frameworks recommend: a purpose and business case up top, explicit in-scope and out-of-scope lists, concrete deliverables, the stakeholders who care, measurable success criteria, and known risks and assumptions. Each list is editable, the budget is formatted automatically, and the tool appends a sign-off table so the sponsor and project manager can authorise the work. Everything is generated in your browser as Markdown.
What each section accomplishes
Purpose and business case is the one-paragraph reason the project exists. It answers: what problem does this solve, what opportunity does it capture, and why is now the right time? A clear business case is what turns a project from an expense into an investment in stakeholders’ minds.
In-scope / out-of-scope is the core scope control mechanism. In-scope lists the work the project will deliver. Out-of-scope is equally important — it names related work that will not be done in this project, so there is a clear reference when someone later requests work that was never agreed. Without an explicit out-of-scope list, scope creep is nearly inevitable.
Deliverables are the tangible outputs — documents, features, systems, or events — that the project will produce. They should be specific enough that a reviewer can later check whether each one was delivered. “Improved customer experience” is not a deliverable; “a redesigned onboarding flow, a help centre with 20 articles, and a reduced time-to-first-value from 10 to 5 minutes” is.
Stakeholders maps who is involved and in what capacity. Listing stakeholders at the start ensures the right people are consulted during execution, prevents surprise objections at review gates, and makes communications planning straightforward.
Timeline in a charter is a high-level schedule — phases and major milestone dates, not a task-level Gantt. It sets the expected shape of the project without committing to detail that is premature at authorisation.
Budget establishes the approved spending envelope. Including it in the charter gives the project manager spending authority up to that figure without returning to the sponsor for each expense.
Risks and assumptions names the things that could derail the project (risks) and the things the project depends on being true (assumptions). Both should be stated explicitly so they can be monitored and challenged. An untested assumption is a hidden risk.
Success criteria defines how the project will be judged. Measurable criteria (“system uptime above 99.5% in the first 30 days post-launch”) are far more useful than aspirational ones (“successful delivery”) because they make the end-point unambiguous.
Sign-off block provides the formal authorisation. Including it as part of the document rather than as a separate email chain keeps the authorisation record with the specification it relates to.
Charter vs. project plan — when to use which
The charter is a one-to-two-page authorising document produced at the start of a project. It is high-level, relatively stable, and signed by the sponsor. It does not change unless the fundamental scope or sponsorship changes.
The project plan is a living operational document — detailed tasks, resources, schedules, and costs. It evolves constantly through execution and is owned by the project manager rather than requiring sponsor sign-off for every update.
Write the charter first. The project plan works within the boundaries the charter defines.
Practical tips
- Write the out-of-scope list before anything else — it is your strongest defence against scope creep later.
- Make success criteria measurable (“support tickets down 25% within 90 days”), not aspirational, so you can prove the project worked.
- Keep the purpose statement short enough that a busy executive can read it in fifteen seconds and understand immediately why the project matters.
- Revisit the charter at major milestones. If reality has drifted significantly from it, that is a signal to run a formal change rather than quietly rewriting history.